[Proxmox 시리즈 7편] 브리지부터 사설망, VPN까지 네트워크 설계하기

VM과 LXC 템플릿을 갖추면 이제 네트워크 설계를 다듬어야 합니다. Proxmox 설치 직후 생성되는 vmbr0 한 가지만으로도 모든 워크로드를 돌릴 수 있지만, 서비스가 늘어나면 트래픽이 섞이고 외부 노출 범위를 통제하기 어려워집니다. 브리지를 어떻게 나누고, 사설망을 어디에 두고, 방화벽과 VPN을 어떤 순서로 추가할지 미리 정해야 운영이 단단해집니다.

이 글에서는 단일 호스트 기준 네트워크 설계 흐름을 단계별로 정리합니다. vmbr 기본 원리, VLAN과 별도 브리지 설계, OPNsense 같은 가상 방화벽을 어디에 배치할지, WireGuard/OpenVPN 기반 VPN을 붙이면 토폴로지가 어떻게 달라지는지, 어떤 서비스를 외부에 노출하고 어떤 서비스는 VPN 뒤에 숨기는지 구체적으로 살펴보겠습니다. 각 단계마다 “무엇을 확인해야 하는지” 체크리스트를 덧붙여 실제 환경에 맞게 조정할 수 있도록 했습니다.

이 글의 흐름

Proxmox 브리지(vmbr)의 동작 원리
기본 브리지 확장: VLAN vs 전용 브리지
사설망과 OPNsense 배치 전략
VPN 원격 접속이 설계에 미치는 영향
서비스 노출·격리 기준과 흔한 실수

이번 글에서 새로 나오는 용어

vmbr: Proxmox가 생성하는 리눅스 브리지 인터페이스로, 물리 NIC와 가상 NIC를 하나의 레이어2 도메인으로 묶습니다.
VLAN: 하나의 브리지 안에서 논리적으로 네트워크를 분리하는 태그 기반 방법입니다.
OPNsense: FreeBSD 기반 방화벽/라우터 배포판으로, Proxmox VM으로 올려 내부 네트워크를 세분화하는 데 자주 쓰입니다.
WireGuard: 경량 VPN 프로토콜로, 원격 접속이나 사이트 간 터널을 구성할 때 활용합니다.
East-West Traffic: 같은 데이터센터(혹은 홈랩) 내부 워크로드 간 트래픽을 의미하며, 외부로 나가는 North-South 트래픽과 구분해 설계합니다.

읽기 카드

예상 소요 시간: 17분

사전 준비: Proxmox VE 기본 설치 완료, 최소 2포트 NIC 또는 VLAN 지원 스위치, 라우터/스위치의 VLAN·트렁크 구성 권한

읽고 나면: 브리지, 사설망, VPN을 조합해 단일 호스트 네트워크를 설계하고 OPNsense 배치를 근거 있게 설명할 수 있습니다.

5단계 설계 흐름 요약

현재 물리 연결(라우터, 스위치, NIC 수) 파악

vmbr 확장 방식 선택(VLAN vs 전용 브리지)

가상 방화벽 배치 및 서브넷 설계

VPN 진입점과 접근 권한 정의

서비스 분류(공개/내부/관리)와 방화벽 룰 확정

Proxmox 브리지의 동작 원리

Proxmox 설치 직후 vmbr0는 물리 NIC(예: eno1)를 브리지에 붙이고, 호스트 자신과 게스트가 같은 서브넷에 존재하도록 만듭니다. 브리지는 스위치처럼 동작하며, VM/LXC의 가상 NIC는 모두 vmbr0를 통해 외부 네트워크에 연결됩니다.

Internet ↔ Router ↔ (eno1) Proxmox Host (vmbr0) ↔ VM/LXC NICs

장점은 단순함이지만, 단일 브리지에 모든 워크로드를 연결하면 다음 문제가 생깁니다.

내부 서비스가 외부와 동일한 서브넷에 있어 스캔이나 악성 트래픽에 그대로 노출됩니다.
DHCP, DNS 같은 보조 서비스 테스트가 실제 네트워크를 흔들 수 있습니다.
OPNsense 같은 가상 방화벽을 넣으려면 추가 브리지나 VLAN이 필요합니다.

체크리스트

물리 스위치/라우터가 VLAN 트렁크를 지원하는가?

vmbr0에 연결된 물리 NIC가 단독인지, 본딩인지 확인했는가?

Proxmox 호스트 자체 방화벽(PVE firewall)을 활성화할지 결정했는가?

기본 브리지 확장: VLAN vs 전용 브리지

Proxmox에서 네트워크를 나누는 방법은 두 가지입니다.

VLAN 태깅: vmbr0 하나를 유지하되, 게스트 NIC에 VLAN ID를 부여합니다. 물리 스위치도 동일한 VLAN 태그를 이해해야 합니다.
전용 브리지 추가: vmbr1, vmbr2처럼 별도 브리지를 만들고, 물리 NIC 또는 Linux Bridge를 내부 전용 네트워크로 씁니다.

초보자에게는 전용 브리지가 직관적입니다. 예를 들어 두 번째 NIC(eno2)를 vmbr1로 설정해 OPNsense의 LAN 인터페이스 전용으로 쓰면, OPNsense 뒤쪽 네트워크가 자동으로 외부와 분리됩니다. 단, 물리 스위치에서 해당 포트를 별도 VLAN/네이티브 포트로 두어야 외부 네트워크와 충돌하지 않습니다.

반면 포트가 부족하거나 스위치가 VLAN을 지원한다면 VLAN 태그 방식을 쓰면 됩니다. 이 경우 Proxmox의 Linux VLAN 인터페이스를 만들고, 게스트 NIC에서 VLAN Tag 필드를 채워 브리지 안에서 논리적으로 분리합니다. 스위치에서는 동일 VLAN ID를 트렁크로 허용하고, 라우터/방화벽에서 해당 VLAN 서브넷을 라우팅해야 합니다.

결정 질문

여분 NIC가 없다면 VLAN으로 갈 수밖에 없다. 스위치가 802.1Q를 지원하는가?

VLAN을 쓰면 Proxmox 호스트도 태그를 인식해야 한다. 관리용 vmbr를 별도로 둘 수 있는가?

사설망과 OPNsense 배치 전략

가상 방화벽을 Proxmox 안에 넣으면 네트워크 흐름이 다음과 같이 바뀝니다.

Internet ↔ Router ↔ vmbr0 (WAN) ↔ OPNsense VM ↔ vmbr1 (LAN) ↔ 다른 VM/LXC

설계 시 핵심 포인트는 다음과 같습니다.

WAN/LAN 인터페이스 분리: OPNsense VM에 두 개 이상의 NIC를 연결합니다. 하나는 vmbr0(WAN), 다른 하나는 vmbr1(LAN)입니다.
LAN 서브넷 선택: 10.10.0.0/24 등 운영에 맞는 사설망을 정하고, DHCP 범위를 OPNsense에서 관리합니다.
게스트 배치: 외부에 직접 노출할 필요가 없는 VM·LXC는 모두 vmbr1을 통해 OPNsense 뒤에 위치시킵니다.
관리 트래픽: Proxmox 호스트 자체는 여전히 vmbr0에서 관리하되, 필요하면 vmbr1에도 추가 NIC를 붙여 내부망에서 관리할 수 있습니다.
가상 방화벽 운용 주의: OPNsense/pfSense를 VM으로 운영하면 Hypervisor 장애 시 방화벽도 함께 다운됩니다. UPS, 자동 부팅 순서, 백업 구성을 별도로 마련하고, 필요하면 물리 방화벽과 병행합니다.

이 구조를 쓰면 사설망 안에서만 접근해야 하는 서비스(데이터베이스, 관리도구)를 안전하게 격리할 수 있고, 포트포워딩이나 리버스 프록시를 통해 필요한 서비스만 외부로 노출할 수 있습니다. 동시에 Proxmox 자체 방화벽(PVE Firewall) 규칙을 VM/LXC 단위로 켜 두면 2중 방어선을 만들 수 있습니다.

VPN 원격 접속이 설계에 미치는 영향

WireGuard나 OpenVPN 같은 VPN을 OPNsense 또는 별도 VM/LXC에서 운영하면 아키텍처가 다시 한 번 바뀝니다.

VPN 서버 위치: OPNsense 안에 VPN을 올리면 방화벽 룰과 연동이 쉽습니다. 별도 LXC/VM에 WireGuard를 설치하면 업데이트가 간단하지만, 방화벽 규칙을 따로 관리해야 합니다. 어떤 방식을 택하든 VPN 터널이 끝나는 인터페이스와 접근 가능한 VLAN을 명확히 해야 합니다.
접속 경로: VPN 사용자는 LAN 서브넷(예: 10.10.0.0/24)에 직접 들어오므로, 외부 포트를 최소한만 열어도 됩니다. Split tunnel(필요 트래픽만 내부로) vs Full tunnel(전체 트래픽을 내부로) 정책을 사전에 정합니다.
트래픽 분리: VPN 전용 서브넷을 만들고, 내부 자원별로 접근 권한을 세분화합니다. 예: 10.99.0.0/24는 운영팀, 10.99.1.0/24는 외주팀 등.

VPN이 들어오면 공인 IP로 노출해야 할 서비스는 크게 줄어듭니다. 예를 들어 Proxmox 웹 UI, 백업 대시보드, 내부 Git 서버는 VPN 안에서만 접근하게 만들고, 외부 공개가 필요한 서비스(웹 앱, API 등)만 리버스 프록시를 통해 인터넷에 연결하면 됩니다.

서비스 노출·격리 기준과 흔한 실수

노출 기준

공개 서비스: HTTPS 리버스 프록시(Haproxy, NGINX, Caddy 등) 뒤에서 인증·TLS를 갖춘 상태로 노출합니다. 예: 외부 고객용 웹 앱, 공개 API.
내부 전용 서비스: VPN 또는 OPNsense 내부 네트워크에서만 접근하게 합니다. 예: 내부 GitLab, Grafana, 데이터베이스, 관리형 메시지 브로커.
관리 서비스: Proxmox, OPNsense UI, 백업 시스템은 반드시 VPN 뒤에 두고, 다중 인증을 적용합니다. 필요하면 별도 mgmt VLAN을 만들어 방화벽으로만 접근하게 합니다.

흔한 실수

호스트와 게스트를 같은 브리지에 모두 연결: OPNsense를 배치하고도 vmbr0에 다른 VM이 그대로 붙어 있으면 방화벽을 우회하는 셈이 됩니다.
VLAN 트렁크 미구성: 스위치가 VLAN을 처리하지 못하거나 트렁크 포트를 열지 않으면 게스트 간 통신이 끊깁니다.
VPN을 단순 SSH 포트 포워딩으로 대체: 서비스마다 SSH 포트를 열어 두면 공격면이 급격히 넓어집니다.
브리지별 MTU를 맞추지 않음: VLAN이나 터널을 쓸 때 MTU를 통일하지 않으면 특정 서비스만 간헐적으로 끊깁니다.
가상 방화벽 단일 장애점(SPOF): OPNsense VM이 유일한 방화벽인데 HA/백업 계획이 없어, Hypervisor 업데이트나 장애 때 네트워크 전체가 멈추는 경우가 잦습니다.

마무리

Proxmox 네트워크는 단일 브리지에서 시작하지만, 워크로드가 늘어날수록 브리지 분리, VLAN, 가상 방화벽, VPN 같은 요소가 필수가 됩니다. 지금 소개한 단계를 따라가면 어떤 서비스를 외부에 노출하고 무엇을 사설망에 묶어 둘지 명확해지고, 운영·보안 모두 예측 가능한 구조를 갖출 수 있습니다. 다음 글에서는 이 네트워크 구조 위에서 백업 경로와 다중 노드 확장 전략을 어떻게 연결할지 이어서 살펴볼 예정입니다.