[OPNsense 시리즈 3편] NAT, 포트포워딩, 리버스 프록시 경로 정리하기

2편에서 Proxmox 위에 OPNsense VM을 만들고 WAN/LAN 경계를 확정했다면, 이제는 트래픽이 어떻게 흘러야 하는지 규칙을 세울 차례입니다. 여기서 말하는 "경계 확정"은 OPNsense가 vmbr0(WAN)와 vmbr1(LAN)의 유일한 라우터로 동작하고, 내부 모든 VM/LXC의 기본 게이트웨이가 OPNsense LAN IP로 설정된 상태를 뜻합니다. 홈랩이든 소규모 서비스든 결국 “무엇을 공개하고, 무엇을 내부에 숨기며, 어떤 경로로 관리자가 들어오는가”를 명확히 해야 합니다. 이 글은 OPNsense의 NAT·포트포워딩·리버스 프록시 설정을 실제 정책으로 옮기는 과정에 집중합니다.

이 글을 시작하기 전에 체크

아래 항목이 맞지 않으면 2편으로 돌아가 구성을 재점검한 뒤 다시 내려오세요.

OPNsense WAN 인터페이스가 공인망 또는 ISP 라우터 뒤 사설망에 연결되어 있고, 기본 게이트웨이가 정상 통신한다.
OPNsense LAN 인터페이스가 내부 대역(예: 10.10.0.0/24)을 제공하며, DHCP 범위에서 내부 게스트가 IP와 게이트웨이를 자동으로 받는다.
임의의 내부 VM에서 ip route | head -n1을 실행했을 때 기본 게이트웨이가 OPNsense LAN IP다.
Proxmox 호스트 자신은 여전히 WAN 브리지를 통해 관리 가능해 장애 시 복구 경로를 잃지 않는다.

이 글의 흐름

기본 아웃바운드 NAT 원리와 Hybrid 모드 이유
HTTPS만 노출하는 인바운드 포트포워딩 패턴
리버스 프록시 경로와 공개 대상 결정 기준
게이트웨이·브리지·정책과 관련된 흔한 오해
규칙 검증 및 문제 해결 절차

이번 글에서 사용하는 용어

아웃바운드 NAT: 내부 사설 IP(10.10.0.0/24 등)를 공인 IP로 변환해 외부로 나가게 하는 정책입니다.
인바운드 NAT (DNAT): 외부 특정 포트로 들어온 요청을 내부 서비스로 전달하는 규칙입니다.
리버스 프록시: 외부 요청을 받아 내부 여러 서비스로 라우팅하는 게이트웨이(LXC, VM 등)입니다.
정책 설치 순서: OPNsense에서 Firewall > NAT > Port Forward → Firewall > Rules > WAN 순으로 자동 생성되는 규칙의 적용 흐름을 뜻합니다.
게이트웨이 정책 경로: 내부 VM이 어떤 기본 게이트웨이를 사용하는지, 정책 우회를 막는 데 핵심인 경로입니다.

읽기 카드

예상 소요 시간: 20분

사전 준비: 2편까지 따라 하여 WAN/LAN이 분리된 상태, 내부 게스트가 OPNsense를 게이트웨이로 쓰는 상태

읽고 나면: 아웃바운드 NAT 모드 선택, HTTPS 포트포워딩, 리버스 프록시 노출, 일반적인 실수 교정을 스스로 할 수 있습니다.

아웃바운드 NAT: Hybrid 모드를 기본선으로

OPNsense는 Firewall > NAT > Outbound에서 세 가지 모드를 제공합니다.

자동 (Automatic): 기본 LAN 서브넷 하나, 단일 WAN이라면 손댈 필요가 없습니다. 모든 내부 대역을 자동으로 SNAT 합니다.
수동 (Manual): 모든 규칙을 직접 정의해야 합니다. 다중 WAN, 복수 공인 IP 풀처럼 세밀한 제어가 필요한 프로덕션 환경에서만 권장합니다.
하이브리드 (Hybrid): 자동 규칙을 생성하면서 특정 서브넷만 별도 번역 규칙을 덧붙일 수 있습니다. 홈랩이지만 WireGuard 서브넷이나 VLAN이 추가되는 순간 가장 다루기 쉬운 선택입니다.

홈랩이나 단일 WAN 환경이면 자동 모드로 시작해도 무방하지만, 앞으로 서브넷을 늘릴 계획이 있거나 VPN 대역을 붙일 예정이라면 Hybrid 모드로 미리 전환해 두는 편이 좋습니다. 예를 들어 WireGuard VPN 대역이나 별도 VLAN이 생기면 특정 서브넷만 다른 공인 IP를 쓰도록 수동 규칙을 넣고, 나머지는 자동 규칙으로 유지할 수 있습니다. Hybrid 모드에서는 OPNsense가 기본 규칙을 계속 생성하므로, 수동 규칙은 더 좁은 CIDR을 넣어 우선순위를 확보하고, 완전히 커스텀 정책이 필요하다면 언젠가 Manual 모드로 갈아탈 계획까지 포함해 두는 것이 좋습니다.

아웃바운드 NAT 흐름은 아래와 같습니다.

Hybrid 모드에서 해야 할 일은 두 가지뿐입니다.

Automatic rules generation을 켠 채로 두고, 필요한 경우에만 Add를 눌러 수동 규칙을 추가합니다.
수동 규칙을 추가할 때는 Source에 서브넷, Translation에 사용할 공인 IP(또는 인터페이스)만 명확히 지정합니다.

인바운드 포트포워딩: 최소 포트만 열어라

외부에서 내부 서비스로 들어오는 트래픽은 Firewall > NAT > Port Forward에서 정의하는 포트포워딩 규칙입니다. 이 글의 포트포워딩 예시는 HTTP/HTTPS처럼 TCP 기반의 웹 트래픽을 전제로 하며, UDP 게임 서버나 SIP · WireGuard 포트처럼 리버스 프록시를 경유할 수 없는 서비스는 별도 정책을 추가해야 합니다. HTTP 서비스만 소수라면 굳이 리버스 프록시를 두지 않고 개별 포트포워딩으로 노출해도 되지만, 하나의 HTTPS 엔드포인트로 모아두면 인증서·WAF·모니터링을 집중시킬 수 있다는 장점이 있습니다. 홈랩 리버스 프록시의 대표적인 예시는 아래와 같습니다.

필요 조건	설정 포인트
공인 HTTPS(443)를 내부 프록시 `10.10.0.10`으로 전달	NAT Port Forward: Interface=WAN, Destination Port=443, Redirect Target IP=10.10.0.10, Redirect Target Port=443
HTTP(80)를 HTTPS로 리디렉션	별도 프록시 정책 또는 OPNsense `HAProxy/NGINX` 플러그인
SSH나 Proxmox UI처럼 민감한 포트 비공개	포트포워딩 규칙을 만들지 않고, VPN을 통해서만 접근

포트포워딩 규칙을 만들면 기본값(Filter rule association = Add associated filter rule)일 때 OPNsense가 자동으로 WAN 방화벽 룰을 생성합니다. 만약 해당 옵션을 끄거나 pass 규칙을 직접 관리하고 싶다면 Firewall > Rules > WAN에 수동으로 동일한 조건의 규칙을 만들어야 합니다. 때문에 “NAT 규칙만 추가했더니 동작하지 않는다”는 경우는 대부분 인터페이스나 포트 번호를 잘못 지정했거나, 리버스 프록시가 실제로 해당 포트를 리슨하지 않는 경우입니다. 또한 HTTPS 이외의 프로토콜(예: SSH, RDP)은 리버스 프록시에서 처리할 수 없으므로, 반드시 VPN 경로로만 노출하거나 별도의 DNAT 규칙으로 명확히 관리해야 합니다.

흐름은 아래 다이어그램처럼 단순합니다.

리버스 프록시와 공개 대상 결정 기준

홈랩이더라도 “모든 서비스”를 인터넷에 보여 줄 필요는 없습니다. 공개 대상을 정할 때는 아래 원칙을 따릅니다.

HTTPS 프론트 하나: 443 하나만 열고, 내부 서비스는 리버스 프록시 뒤로 숨깁니다. 필요하면 *.example.com 와일드카드 인증서를 써서 서브도메인을 분기합니다.
관리용 경로 분리: Proxmox UI, OPNsense UI, 백업 대시보드, Grafana 같은 관리성 서비스는 WireGuard/OpenVPN을 통과한 뒤에만 접근하도록 둡니다.
내부 DNS 유지: 내부 도메인은 OPNsense 혹은 프록시에서만 해석하게 만들고, 외부 DNS에는 A레코드를 제한적으로 등록합니다.
로그 수준: 리버스 프록시에서 TLS, 요청 헤더, 업스트림 응답 시간을 로그로 남겨, 포트포워딩 규칙을 추가했을 때 실제 트래픽이 들어오는지 즉시 확인합니다.
SPOF 인지: 프록시가 꺼지면 모든 HTTPS가 멈춥니다. 고가용성이 필요하면 HAProxy/Keepalived로 2대 이상을 번갈아 두거나, OPNsense 내 HAProxy 플러그인과 외부 프록시를 병행해 장애 시에도 트래픽을 유지합니다.

게이트웨이·브리지·정책 관련 흔한 실수

게이트웨이 우회: 내부 VM이 DHCP가 아닌 수동 IP로 설정되었는데, 기본 게이트웨이를 ISP 라우터로 잡아 둔 상태. 해결책은 Services > DHCPv4 > LAN에서 게이트웨이와 DNS를 모두 OPNsense로 내리고, cloud-init/Ansible 등으로 배포되는 정적 VM에는 route add default <OPNsense LAN IP>를 명시해 둡니다.
WAN 규칙 과도 허용: 포트포워딩을 만들었더니 자동 생성된 pass 규칙을 그대로 둬야 하는데, 별도 생성한 allow any 규칙 때문에 공격면이 넓어지는 경우가 많습니다.
브리지 이중 연결: LXC나 VM이 동시에 vmbr0와 vmbr1에 NIC를 가진 상태에서 잘못된 NIC가 기본 라우트가 되면 일부 트래픽이 방화벽 밖으로 나갑니다. 꼭 필요한 경우가 아니라면 WAN 브리지에 내부 VM을 붙이지 않습니다.
리버스 프록시 DMZ를 만들지 않음: 리버스 프록시와 내부 앱을 동일 서브넷에 두면, 프록시가 뚫렸을 때 내부 서비스까지 바로 접근됩니다. 최소한 프록시만 별도 VLAN 또는 Alias로 구분해 WAN 규칙과 모니터링을 강화하고, 백엔드와의 통신도 TLS 또는 mTLS로 재암호화하여 패킷 스니핑만으로는 내용을 볼 수 없게 만듭니다.

규칙 검증 루틴

아웃바운드: 내부 VM에서 curl https://ifconfig.me를 호출해 공인 IP가 OPNsense WAN과 동일한지 확인합니다. 결과가 다르다면 Hybrid 규칙 우선순위를 확인합니다.
인바운드: 외부 네트워크(모바일 LTE 등)에서 curl -I https://도메인으로 응답 헤더를 확인하고, 리버스 프록시 로그에서 요청이 찍혔는지 확인합니다. HTTPS 응답이 없다면 Interfaces > Overview에서 WAN IP를 확인해 ISP 모뎀의 공인 IP와 동일한지 비교하고(다르면 이중 NAT), ISP 장비에도 동일한 포트포워딩을 추가하거나 브리지 모드가 가능한지 문의하세요.
로그 추적: Firewall > Log Files > Live View에서 interface = WAN, rule = NAT 필터로 검색해, 포트포워딩 규칙이 실제로 매칭되는지 확인합니다. 동시에 리버스 프록시, 백엔드 애플리케이션에도 공통 Request ID를 남겨 추적합니다.
정책 충돌: 포트포워딩 규칙을 여러 개인증서/도메인과 함께 쓸 때는 Firewall > Rules > WAN의 순서를 다시 정렬해, 넓은 CIDR을 허용하는 규칙이 특수 규칙 앞에 오지 않게 합니다. DHCP 범위를 수정하거나 새로운 서브넷을 추가한 뒤에는 이 순서를 다시 점검합니다.

문제 해결 팁

연결은 되는데 HTTPS가 깨짐: 리버스 프록시가 내부 서버의 프라이빗 인증서를 검증하지 못할 수 있습니다. 프록시에서 백엔드 인증서 검증을 끄고, 내부 통신에는 자체 CA를 배포합니다. 백엔드도 HTTPS를 강제한다면 Subject Alternative Name에 프록시가 접근하는 호스트명이 포함되어 있는지 확인합니다.
포트포워딩이 작동하지 않음: ISP 모뎀이 여전히 NAT를 수행하는 이중 NAT 상태일 수 있습니다. whatismyip 결과와 OPNsense WAN IP가 다르면 거의 확실히 이중 NAT입니다. 가능하면 브릿지 모드로 전환하거나, ISP 라우터에서도 동일한 포트포워딩을 추가합니다.
VPN과 포트포워딩 충돌: WireGuard와 같은 VPN이 0.0.0.0/0로 라우팅을 끌고 가면, 리버스 프록시 응답이 VPN을 통해 나가 버릴 수 있습니다. VPN 피어별로 AllowedIPs를 좁혀 써서 포트포워딩 경로와 분리합니다.

마무리

3편에서는 OPNsense 위에서 NAT, 포트포워딩, 리버스 프록시 경로를 안전하게 설계하는 법을 정리했습니다. 핵심은 다음 세 가지입니다. 첫째, 아웃바운드 NAT는 Hybrid 모드로 두어 기본 규칙은 자동화하고 필요할 때만 수동 제어를 더합니다. 둘째, 포트포워딩은 최소 포트만 열고, 리버스 프록시가 모든 공개 트래픽을 종합하도록 구조화합니다. 셋째, 게이트웨이·브리지·정책이 서로 어긋나면 방화벽을 우회하므로, DHCP와 룰 순서를 주기적으로 점검해야 합니다. 다음 글에서는 VPN·관리 경로를 포함한 고급 정책과 VLAN 기반의 세분화 전략으로 이어갈 예정입니다.