Proxmox로 VM과 LXC를 나누기 시작하면 곧 이런 질문이 따라옵니다. "어떤 서비스는 외부에 공개하고, 어떤 서비스는 내부망에만 두고, 관리자 접속은 VPN 뒤로 숨기고 싶은데 이 경계를 누가 관리하지?"
이 지점에서 OPNsense가 등장합니다. OPNsense는 단순히 포트를 몇 개 막는 방화벽이 아니라, 내부망과 외부망의 경계를 설계하고, 트래픽을 통제하고, 원격 접속 경로를 정리하게 해 주는 네트워크 운영 도구입니다.
특히 Proxmox와 조합하면 역할이 선명해집니다. Proxmox는 여러 워크로드를 담는 계산 자원 호스트가 되고, OPNsense는 그 워크로드가 어떤 경로로 연결되고 어떤 정책으로 보호되는지를 다루는 네트워크 제어 지점이 됩니다. 남는 미니 PC나 유휴 컴퓨터를 활용해 self-hosted 웹 인프라를 만들 때 이 조합이 강한 이유도 여기에 있습니다.
이 글에서는 OPNsense를 "가상 방화벽 VM 하나"가 아니라, Proxmox 기반 인프라에서 네트워크 경계를 정리해 주는 운영 계층으로 소개해 보겠습니다.
이 글의 흐름
- OPNsense는 무엇인가
- 왜 Proxmox와 조합이 좋은가
- 단일 호스트에서 어떤 구조로 배치하는가
- VPN과 원격 관리 흐름은 어떻게 정리하는가
- 가상 방화벽으로 충분한 경우와 한계는 무엇인가
이번 글에서 새로 나오는 용어
- 방화벽 (Firewall): 어떤 네트워크 트래픽을 허용하고 차단할지 정책으로 결정하는 계층입니다.
- NAT: 내부 사설망이 외부 네트워크와 통신할 때 주소를 변환하는 방식입니다.
- 포트포워딩 (Port Forwarding): 외부에서 들어온 특정 포트를 내부 서비스로 전달하는 설정입니다.
- 브리지: Proxmox에서 물리 NIC와 VM/LXC의 가상 NIC를 이어 주는 소프트웨어 스위치입니다.
vmbr0에 연결된 게스트는 같은 네트워크 대역에 있는 것처럼 동작합니다. - VPN: 외부에서 내부망으로 안전하게 들어오기 위한 암호화된 터널입니다.
읽기 카드
OPNsense는 무엇인가
OPNsense는 FreeBSD 기반의 오픈소스 방화벽/라우터 배포판입니다. 하지만 실제로는 단순 방화벽보다 범위가 넓습니다. 인터페이스별 정책 관리, NAT, 포트포워딩, DHCP, DNS 포워딩, WireGuard/OpenVPN 같은 VPN, 트래픽 관찰까지 한 운영 모델 안에서 다룰 수 있습니다.
즉 OPNsense를 쓴다는 것은 "트래픽을 막는다"보다 "네트워크 경계를 정의한다"에 가깝습니다. 어떤 서비스는 인터넷에 공개하고, 어떤 서비스는 내부망 전용으로 두고, 어떤 관리 화면은 VPN을 통과한 뒤에만 보이게 할지를 한곳에서 정리할 수 있기 때문입니다.
이 성격 때문에 OPNsense는 self-hosted 환경이나 소규모 내부 인프라에서 특히 유용합니다. 서비스 수가 늘수록 네트워크 노출 규칙이 흩어지기 쉬운데, OPNsense가 그 기준점을 잡아 주기 때문입니다.
왜 Proxmox와 조합이 좋은가
Proxmox는 워크로드를 나누는 데 강하고, OPNsense는 경계를 나누는 데 강합니다. 이 두 역할이 서로 잘 맞습니다.
예를 들어 Proxmox 위에 앱 서버 VM, 리버스 프록시 LXC, 모니터링 VM, 테스트용 Windows VM이 있다고 해 봅시다. 이 워크로드를 그냥 모두 vmbr0 같은 같은 브리지에 붙여 버리면, 사실상 네트워크는 한 평면에 놓입니다. 서비스는 분리되어 있어 보여도 노출 정책과 접근 제어는 흐려집니다. 결국 "공개용 프록시도, 내부용 Grafana도, Proxmox 관리 UI도 같은 출입문을 공유하는 상태"가 되기 쉽습니다.
반면 OPNsense를 넣으면 구조가 달라집니다.
- 외부와 직접 통신하는 경로를 줄일 수 있습니다.
- 내부 서비스와 공개 서비스를 명확히 나눌 수 있습니다.
- 관리자 접속을 VPN 뒤로 숨길 수 있습니다.
- 포트포워딩, NAT, DNS, DHCP 정책이 한곳으로 모입니다.
그래서 Proxmox와 OPNsense의 조합은 "VM을 많이 띄운다"는 차원을 넘어, 남는 하드웨어를 실제 운영 가능한 인프라로 바꾸는 조합에 가깝습니다. Proxmox가 계산 자원 계층이라면, OPNsense는 네트워크 경계 계층입니다.
단일 호스트에서는 어떤 구조가 되는가
홈랩이나 소규모 self-hosted 환경에서는 보통 두 가지 형태를 많이 씁니다. 기본형은 물리 NIC 1개만 쓰는 구조이고, 확장형은 물리 NIC를 추가하거나 VLAN으로 내부망을 밖으로 꺼내는 구조입니다.
기본형: 물리 NIC 1개 + 내부 전용 vmbr1
가장 흔한 시작점은 이 구조입니다.
이 구조의 핵심은 다음과 같습니다.
- 물리 NIC 1개는
vmbr0에만 연결하고, 바깥쪽 업링크 역할만 맡깁니다. vmbr1은 물리 NIC 없이 만드는 내부 전용 브리지입니다.- OPNsense VM은 두 개의 가상 NIC를 가지며, WAN은
vmbr0, LAN은vmbr1에 연결됩니다. - 내부 VM, LXC, 관리 서비스는
vmbr1에 연결하고 OPNsense의 LAN IP를 기본 게이트웨이로 사용합니다.
이 방식이 좋은 이유는 단순하기 때문입니다. 내부 게스트가 모두 vmbr1에 붙고, 그 vmbr1이 OPNsense를 통해서만 외부로 나가도록 만들면 네트워크 경계가 매우 분명해집니다. 남는 미니 PC 한 대에서 웹 서버, 내부 도구, 모니터링, 점프박스 VM을 함께 운영할 때 특히 다루기 쉽습니다.
확장형: 물리 NIC 2개 또는 VLAN으로 LAN을 밖으로 확장
내부 VM과 LXC만 묶는 수준을 넘어서, 실제 물리 장비까지 OPNsense 뒤의 LAN에 붙이고 싶을 때는 구조가 달라집니다.
이 확장형에서는 vmbr1이 Proxmox 내부에서만 끝나지 않고, 물리 NIC 2개째나 VLAN trunk를 통해 실제 스위치와 연결됩니다. 그래서 OPNsense 뒤의 LAN이 가상 게스트뿐 아니라 물리 장비까지 포함하는 내부망으로 확장됩니다.
즉 이렇게 정리하면 됩니다.
- 내부 게스트만 OPNsense 뒤에 둘 거라면
1 NIC + 내부용 vmbr1이 기본형입니다. - 물리 PC, NAS, AP, 다른 서버까지 OPNsense 뒤 LAN에 넣고 싶다면
2 NIC또는VLAN-aware bridge + managed switch가 필요합니다. - 어느 쪽이든 내부 게스트와 관리 서비스는 OPNsense의 LAN IP를 기본 게이트웨이로 써야 실제로 방화벽 정책을 경유합니다.
여기서 가장 중요한 조건은 3번입니다. 브리지를 둘로 나누는 것만으로는 충분하지 않습니다. 앱 VM이나 내부 LXC가 vmbr1에 붙어 있어도, 기본 게이트웨이가 여전히 외부 라우터를 가리키면 방화벽 정책을 우회하게 됩니다.
특히 리버스 프록시, 백업 시스템, 내부 Grafana 같은 서비스는 이런 구조에서 훨씬 다루기 쉬워집니다. 공개용 리버스 프록시는 OPNsense 규칙을 통해 필요한 포트만 열고, 나머지 서비스는 vmbr1 내부망에 둔 채 VPN으로만 접근하게 만들 수 있기 때문입니다.
Proxmox 호스트 관리 IP도 같은 관점으로 다뤄야 합니다. 가능하면 Proxmox 관리 UI, SSH, PBS는 vmbr1 내부망이나 별도 관리 VLAN 쪽에서만 접근되게 두고, 공인 IP에 직접 노출하지 않는 편이 안전합니다.
참고로 이 구조 구분은 "기본형과 확장형"의 차이지, 아직 이중화나 HA를 뜻하지는 않습니다. 진짜 이중화는 OPNsense 자체 failover, 업링크, 스위치, Proxmox 노드 구성까지 별도로 설계해야 합니다.
OPNsense가 실제로 트래픽을 어떻게 통제하는가
이론을 실제 동작으로 바꾸면 흐름은 더 단순합니다.
vmbr1에 붙은 내부 게스트는 DHCP 또는 수동 설정으로 OPNsense LAN IP를 기본 게이트웨이로 받습니다.- 내부 게스트가 인터넷으로 나갈 때는 OPNsense가 아웃바운드 NAT를 통해 주소를 변환합니다.
- 외부에서 내부 웹 서비스로 들어올 때는 OPNsense가 포트포워딩(DNAT) 규칙으로 트래픽을 내부 프록시나 앱 서버로 전달합니다.
- VPN 사용자는 OPNsense에서 종료된 VPN 터널을 통해 별도 VPN 주소 대역이나 내부망으로 진입합니다.
예를 들어 내부 앱 서버가 10.10.0.20에 있고, 외부에서는 HTTPS만 공개한다고 해 봅시다. 이때 OPNsense는 WAN 쪽 443 요청을 내부 리버스 프록시로 전달하고, 리버스 프록시는 다시 앱 서버로 연결합니다. 반면 Proxmox UI나 내부 모니터링은 같은 내부망에 있어도 포트포워딩 규칙을 만들지 않으면 외부에서 직접 보이지 않습니다.
DHCP와 DNS도 이 구조를 단순하게 만듭니다. vmbr1 내부 게스트에게 OPNsense가 IP, 기본 게이트웨이, DNS 주소를 함께 내려주면, 내부망의 네트워크 기준점이 자연스럽게 OPNsense로 모입니다.
VPN과 원격 관리 흐름은 어떻게 정리하는가
OPNsense를 쓰는 이유 중 하나는 원격 관리 경로를 단정하게 만들기 위해서입니다. 외부에서 Proxmox UI나 내부 서비스에 바로 접속하게 두면 공격면이 빠르게 커집니다.
그래서 보통은 다음처럼 정리합니다.
- 외부 공개가 필요한 것은 HTTPS 프록시나 특정 서비스 포트만 노출합니다.
- Proxmox UI, OPNsense UI, 백업 대시보드, 내부 Git 서비스는 VPN 뒤에 둡니다.
- 관리자는 WireGuard 같은 VPN으로 내부망에 들어온 뒤 필요한 시스템에 접근합니다.
이 구조의 장점은 포트 수를 줄인다는 데만 있지 않습니다. 관리 행위 자체를 별도 경로로 분리한다는 데 의미가 있습니다. 즉 사용자 트래픽과 관리자 트래픽을 같은 문으로 받지 않게 됩니다. 공인 IP에 직접 관리 UI를 열어 두면 로그인 시도, 취약점 스캔, 인증 우회 시도 같은 공격이 곧바로 관리면에 닿을 수 있는데, VPN 뒤에 두면 먼저 VPN 인증을 통과해야 하므로 방어선이 하나 더 생깁니다.
실제로는 다음 같은 원칙이 많이 쓰입니다.
443만 공개하고 나머지는 VPN 뒤로 숨기기- Proxmox와 OPNsense 관리 UI는 공인 IP에 직접 노출하지 않기
- 내부 DNS, 모니터링, 백업 시스템은 사설망에서만 열기
- 관리자용 별도 VPN 주소 대역을 정해 접근 로그를 추적하기
이렇게 하면 원격 작업 흐름이 단순해집니다. 관리자 입장에서는 먼저 VPN으로 들어오고, 그다음 내부 서비스에 접근하면 됩니다. 반대로 서비스별로 SSH 포트를 여기저기 뚫어 둘 필요가 줄어듭니다. 이때 VPN 서버를 OPNsense에서 직접 운영하면 방화벽 룰과 주소 대역 관리를 한곳에서 묶기 쉽습니다.
가상 방화벽으로 충분한 경우와 한계는 무엇인가
OPNsense를 Proxmox VM으로 올리는 방식은 매우 실용적이지만, 항상 정답은 아닙니다. 장점과 한계를 함께 봐야 합니다.
가상 OPNsense가 잘 맞는 경우
다음 조건에서는 Proxmox 위 OPNsense VM이 충분히 훌륭합니다.
- 홈랩이나 소규모 내부망처럼 단일 장애를 감당할 수 있을 때
- 재부팅이나 점검 시간을 스스로 통제할 수 있을 때
- 방화벽, VPN, 내부망 설계를 학습하고 반복 실습하고 싶을 때
- 남는 미니 PC 한 대에서 앱 서버와 네트워크 구조를 함께 정리하고 싶을 때
특히 실습 관점에서는 장점이 큽니다. 규칙이 꼬이면 설정을 백업에서 복원하거나 VM 스냅샷을 활용할 수 있고, 구조를 바꾸는 실험도 비교적 빠르게 반복할 수 있습니다. 다만 OPNsense는 FreeBSD 기반이므로, 일부 NIC 드라이버 호환성이나 Linux와 다른 CLI 감각을 염두에 두는 편이 좋습니다.
별도 방화벽 장비를 고려해야 하는 경우
다음 상황에서는 OPNsense를 Proxmox 밖의 전용 장비로 분리하는 편이 더 낫습니다.
- Proxmox 호스트 재부팅 중에도 네트워크가 계속 살아 있어야 할 때
- 방화벽이 전체 네트워크의 유일한 관문이라 중단 비용이 클 때
- NIC 구성, VLAN, 고가용성 요구가 더 복잡해질 때
- 여러 Proxmox 노드와 물리 네트워크 전체를 묶어 통제해야 할 때
핵심은 이것입니다. OPNsense를 VM으로 올리면 관리 편의성과 학습 속도는 좋아지지만, Hypervisor와 운명을 함께합니다. 따라서 "가상 방화벽이 실용적인가"와 "가상 방화벽이 충분히 안전한가"는 별개의 질문입니다.
예를 들어 Proxmox 호스트를 재부팅하면 OPNsense VM도 함께 내려가므로, 내부 게스트는 인터넷과 VPN 게이트웨이를 동시에 잃습니다. 반대로 OPNsense 설정을 잘못 바꾸면 Proxmox 호스트는 살아 있어도 내부 게스트가 외부로 나가지 못할 수 있습니다. 그래서 가상 방화벽은 편리하지만, 복구 경로와 콘솔 접근 수단을 같이 준비해야 합니다.
흔한 오해
"방화벽 VM 하나만 올리면 보안이 끝난다"
아닙니다. OPNsense는 경계를 관리해 주지만, 게스트 OS 업데이트, 인증, 백업, 관리자 계정 보호까지 대신해 주지는 않습니다.
"Proxmox에 올렸으니 모든 트래픽이 자동으로 OPNsense를 지난다"
그렇지 않습니다. 어떤 브리지에 어떤 VM이 연결되어 있는지, 그리고 기본 게이트웨이가 어디로 잡혀 있는지에 따라 OPNsense를 우회할 수도 있습니다. 예를 들어 중요한 VM이 여전히 vmbr0에 직접 붙어 있거나, vmbr1에 붙어 있어도 외부 라우터를 기본 게이트웨이로 쓰면 방화벽 정책 바깥에 있는 셈입니다.
"VPN만 켜면 네트워크 설계는 나중에 해도 된다"
VPN도 결국 어느 인터페이스에서 종료되고 어떤 서브넷에 접근 가능한지 설계가 필요합니다. 설계 없이 붙이면 외부 노출 포트를 줄였을 뿐, 내부 경계는 여전히 흐릴 수 있습니다.
마무리
그래서 OPNsense는 Proxmox와 궁합이 좋은 방화벽이라고 볼 수 있습니다. Proxmox가 워크로드를 나누는 플랫폼이라면, OPNsense는 그 워크로드 사이의 경계와 외부 노출 규칙을 정리하는 플랫폼이기 때문입니다. 특히 남는 미니 PC나 유휴 컴퓨터를 활용해 self-hosted 웹 인프라를 만들 때, 이 둘의 조합은 "가상화 + 보안 + 원격 관리"를 한 흐름으로 묶어 줍니다.
이 글의 핵심은 세 가지입니다. 첫째, Proxmox와 OPNsense는 역할이 다르기 때문에 함께 쓸 때 구조가 선명해집니다. 둘째, 브리지 분리만으로는 충분하지 않고 기본 게이트웨이, NAT, VPN 종료 지점까지 함께 설계해야 합니다. 셋째, 가상 방화벽은 홈랩과 소규모 내부망에는 매우 실용적이지만, 호스트와 운명을 함께한다는 한계를 항상 감안해야 합니다.
다음 글에서는 이론 소개를 넘어서, Proxmox 위에 OPNsense VM을 만들 때 WAN/LAN 인터페이스를 어떻게 나누고 브리지를 어떻게 연결해야 하는지 실제 배치 관점에서 정리해 보겠습니다.
💬 댓글
이 글에 대한 의견을 남겨주세요