mathbong
EN
인프라 OPNsense

[OPNsense 시리즈 5편] VLAN과 내부 세그먼트로 서비스 LAN을 확장하는 방법

#opnsense#proxmox#vlan#lan#homelab
English version

1~4편에서는 Proxmox 안에서 WAN과 단일 내부 브리지를 구성하고, 게스트 VM을 논리적으로만 분류하는 방법까지 다뤘습니다. 이제는 물리 스위치, AP, NAS까지 OPNsense 정책 아래로 끌어와야 합니다. 하나의 설계를 서비스·관리·게스트 트래픽에 동시에 적용하려면 VLAN 세그먼트가 어디서 시작되고 끝나는지, Proxmox 브리지·OPNsense 인터페이스·스위치 포트가 어떤 순서로 맞물리는지를 단계별로 살펴봐야 합니다. 이번 글은 "서비스·관리·게스트 LAN을 정의하고, OPNsense VM과 관리형 스위치가 만나는 지점을 안전하게 확장하는 방법"에 초점을 맞춥니다.

시작 전에 준비할 것

  • 현재 홈 라우터/ISP 게이트웨이가 사용하는 IP 대역 (예: 192.168.0.0/24)
  • Proxmox 호스트의 물리 NIC 수와 어떤 NIC를 트렁크로 활용할지 계획
  • 최소 두 개의 물리 NIC를 확보했는지 확인 (1개만 있으면 실습은 가능하지만 WAN/LAN이 동시에 끊깁니다)
  • 사용할 VLAN ID 목록(10=서비스, 20=관리, 30=게스트처럼 이름과 번호를 함께 적어 두기)
  • 각 세그먼트에 배정할 IP 범위와 DHCP 풀 (표로 미리 작성)
  • 설정 중 문제가 생겼을 때 되돌릴 OPNsense 설정 백업 파일

이 글의 흐름

  1. VLAN과 내부 세그먼트가 언제 필요해지는가
  2. 세그먼트를 정의하고 IP/DHCP/DNS 계획 세우기
  3. Proxmox 브리지·OPNsense 인터페이스·방화벽을 순서대로 배치하기
  4. 스위치 포트 태깅과 관리 경로 정리하기
  5. 검증/트러블슈팅 체크리스트와 실수 사례 복습

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

  1. VLAN Trunk: IEEE 802.1Q 표준 태그(총 4바이트 헤더)를 유지한 채 하나의 물리 링크에서 여러 VLAN을 동시에 통과시키는 업링크 방식입니다.
  2. 서비스 LAN: 외부 공개 서비스와 내부 백엔드가 만나는 구역입니다. OPNsense 규칙으로 포트를 제한합니다.
  3. 관리 LAN: Proxmox, OPNsense, 백업, 모니터링 같은 운영 도구만 접근 가능한 좁은 구역입니다.
  4. 게스트 LAN: 사내·가정 방문자나 IoT를 몰아넣어도 다른 세그먼트를 넘지 않도록 만든 격리 구역입니다.
  5. Tagged / Untagged 포트: 스위치에서 특정 VLAN 태그를 유지하거나 제거하며 다른 장비에 넘기는 동작을 뜻합니다.
  6. 트렁크 포트: 여러 VLAN 태그를 유지한 채 다른 스위치나 OPNsense 같은 태그 인식 장비에 전달하는 포트입니다.
  7. 액세스 포트: 특정 VLAN 하나만 Untagged로 내보내는 포트입니다. 노트북, NAS, AP처럼 VLAN을 모르는 장비가 여기에 연결됩니다.

읽기 카드

  • 예상 소요 시간: 18분
  • 사전 준비: Proxmox vmbr 생성 경험, OPNsense 인터페이스 기본 설정 경험, 관리형 스위치에서 VLAN을 나눠 본 적이 한 번이라도 있으면 좋습니다.
  • 읽고 나면: 서비스용, 관리용, 게스트용 네트워크를 분리해서 Proxmox와 물리 스위치를 동시에 다룰 수 있습니다.

VLAN과 내부 세그먼트가 필요해지는 시점

처음에는 Proxmox 내부 브리지(vmbr1)에 모든 게스트를 올려두어도 문제 없습니다. 그러나 다음 조건이 생기면 상황이 달라집니다.

  1. 리버스 프록시, 앱 서버, 데이터베이스, 모니터링, 백업 등 서비스가 서로 다른 노출 정책을 요구할 때
  2. Proxmox UI, PBS, OPNsense 콘솔, 내/외부 DNS 같은 관리 트래픽을 외부 사용자와 분리하고 싶을 때
  3. NAS, AP, 데스크톱, IoT 기기를 OPNsense 뒤로 끌어와야 할 때

이 지점에서는 "단일 내부 브리지"만으로는 부족합니다. 트래픽 경계를 세밀하게 나누지 않으면, 게스트 Wi-Fi에 붙은 기기가 관리용 Proxmox UI로 들어오는 일도 막기 어렵습니다. VLAN은 이 경계를 스위치 단위로 끌고 나가게 해 주는 도구입니다.

VM끼리만 VLAN을 나눌 거라면 vmbr2, vmbr3처럼 브리지만 몇 개 만들면 충분합니다. 그러나 물리 NAS나 AP를 같은 기준으로 나누려면 스위치가 각 포트에 VLAN 태그를 붙여 줘야 합니다. 아래 D2 다이어그램은 OPNsense VM과 관리형 스위치 사이에 세 개의 논리 세그먼트를 만든 구조이며, 각 노드가 의미하는 바는 표로 한 번 더 정리했습니다.

다이어그램 노드 의미 바로 확인하는 방법
vmbr0 Proxmox의 WAN 브리지 Proxmox UI > Datacenter > Node > Network에서 vmbr0가 물리 NIC 1과 묶였는지 확인
vmbr2 VLAN 트렁크 브리지 bridge vlan show vmbr2 명령으로 VLAN-aware 상태와 허용 VLAN 확인
nic_trunk 물리 NIC 2번(트렁크 포트) ethtool -p <인터페이스명>으로 실제 포트 LED를 깜박여 식별
svc/mgmt/guest_vlan VLAN 10/20/30 서브넷 OPNsense Interfaces > Assignments에서 vmx1_vlan10 등으로 추가
svc/mgmt/guest_hosts 각 VLAN에 속한 VM/물리 장비 Proxmox VM NIC에 VLAN 태그를 지정했는지, 스위치에서 Untagged VLAN을 올바르게 설정했는지 확인
ISP / ONTPhysical NIC 1 (WAN)vmbr0 / WANOPNsense VMWAN=vmbr0LAN Trunk=vmbr2vmbr2 / VLAN TrunkPhysical NIC 2Managed Switch(VLAN-aware)VLAN 10Service LANVLAN 20Management LANVLAN 30Guest LANReverse Proxy / App VMsProxmox UI / PBS / Admin WorkstationGuest Wi-Fi / IoT

핵심은 vmbr2를 VLAN 트렁크로 만들고, OPNsense VM의 LAN쪽 NIC를 여기에 태그된 인터페이스로 붙인 뒤, 물리 NIC 2개째로 관리형 스위치에 연결하는 것입니다. Proxmox 내부 게스트도 vmbr2에 직접 붙고, 필요한 VLAN 태그를 설정하면 물리 장비와 같은 네트워크 정책을 공유할 수 있습니다.

이때 NIC 배치는 다음처럼 정리하면 헷갈리지 않습니다.

  • Proxmox 호스트 물리 NIC 1: vmbr0에 연결되어 WAN만 담당합니다.
  • Proxmox 호스트 물리 NIC 2: vmbr2에 연결되어 VLAN 트렁크 전용으로 씁니다.
  • OPNsense VM NIC 1: vmbr0(WAN), NIC 2: vmbr2(VLAN Trunk). 필요하면 NIC 3을 별도 관리망에 둘 수 있지만, 이번 글은 2 NIC 기반 구조를 다룹니다.

서비스·관리·게스트 LAN을 나누는 기준

세그먼트를 먼저 정의해야 규칙이 단순해집니다. 추천하는 최소 구성은 다음과 같습니다.

  • 서비스 LAN (예: VLAN 10, 10.20.10.0/24): 리버스 프록시, 앱 서버, 캐시, 일부 배포 자동화 노드가 살며, 외부로 포트포워딩 되는 구역입니다. SSH나 DB 포트는 기본적으로 막고, 리버스 프록시만 필요한 포트를 엽니다.
  • 관리 LAN (예: VLAN 20, 10.20.20.0/24): Proxmox 관리 IP, OPNsense UI, 백업 서버, 모니터링, 관리자의 랩톱만 허용합니다. 외부로 나가는 규칙도 최소화하고, VPN 클라이언트 풀과 가장 가까운 위치에 둡니다.
  • 게스트 LAN (예: VLAN 30, 10.20.30.0/24): 게스트 Wi-Fi, IoT, 테스트용 장비를 격리합니다. 이 구역은 인터넷 아웃바운드만 허용하고 나머지는 모두 차단하거나, 필요한 경우 프록시를 통해서만 내부 자원에 닿게 만듭니다.

현실적인 예시는 다음과 같습니다. 게스트 VLAN 30에는 방문자 Wi-Fi AP를 붙이고, 서비스 VLAN 10에는 역방향 프록시와 앱 서버를 넣고, 관리 VLAN 20에는 Proxmox UI·PBS·OPNsense UI·관리자 노트북만 허용합니다. IoT 센서는 게스트 VLAN과 비슷한 통제 수준으로 묶으면 lateral movement 위험을 줄일 수 있습니다.

세그먼트를 정하면서 고려할 것:

  1. IP 계획: 각 VLAN은 겹치지 않는 /24 대역으로 잡고, OPNsense 인터페이스 IP를 10.20.X.1처럼 일정하게 유지하면 정책이 깔끔해집니다.
  2. DHCP 범위: 서비스 LAN은 정적 할당이 많으므로 짧은 범위를 주고, 관리 LAN은 MAC 기반 예약을 적극 활용합니다. 게스트 LAN은 짧은 리스를 사용해 추적을 쉽게 합니다.
  3. DNS 정책: 내부 도메인 해석은 관리 LAN 또는 서비스 LAN에 한정하고, 게스트는 외부 DNS로 직접 보내거나 필터링 프록시를 거치게 합니다.

가정용 라우터가 이미 192.168.0.0/24 같은 대역을 쓰고 있다면, OPNsense는 전혀 다른 10.20.X.0/24 범위를 사용하는 편이 좋습니다. 그래야 기존 LAN과 새 내부망이 겹치지 않고, 추후 전용 하드웨어로 옮길 때도 동일한 주소 체계를 유지하기 쉽습니다.

Proxmox + OPNsense + 스위치 배치 단계

이제 실제 작업 순서를 다섯 단계로 정리해 보겠습니다. 들어가기 전에 다음 사전 점검을 끝내 둡니다.

  • Datacenter > <노드> > Network에서 vmbr0(WAN)와 vmbr2(VLAN 트렁크)가 각각 어떤 물리 NIC와 묶여 있는지 확인하고, VLAN aware 체크박스가 켜져 있는지 확인합니다. CLI에서는 bridge vlan show vmbr2로 허용 VLAN 목록을 바로 볼 수 있습니다.
  • Proxmox에서 OPNsense VM의 두 번째 NIC 모델을 VirtIO (paravirtualized) 또는 VMXNET3처럼 VLAN 태깅을 지원하는 드라이버로 맞춥니다. VM을 끄지 않고 모델을 바꾸면 패킷이 드랍될 수 있으니, 유지보수 창에 맞춰 진행합니다.
  • OPNsense Interfaces > Assignments에서 기존 LAN 인터페이스와 새 VLAN 인터페이스가 충돌하지 않는지(동일 IP 사용 여부) 확인합니다. 새 VLAN을 활성화하기 전에 기존 LAN DHCP를 끄지 않으면 중복 게이트웨이가 생깁니다.

이제 Proxmox의 VLAN-aware 브리지와 OPNsense 내부의 Parent Interface가 무엇인지부터 짚고 넘어가십시오.

  • VLAN-aware 브리지: 태그된 프레임을 그대로 통과시키는 브리지입니다. 꺼두면 모든 VLAN 태그가 벗겨져 하나의 네트워크처럼 동작하므로, 여러 VLAN을 하나의 물리 NIC로 내보낼 수 없습니다.
  • Parent Interface: OPNsense VM에서 보이는 실제 NIC 이름입니다. Proxmox에서 vmbr2에 연결된 가상 NIC가 OPNsense 안에서는 vmx1이나 virtio1로 표시되며, 여기에 VLAN 태그를 올립니다.
  • MTU 주의: VLAN 태그는 프레임에 4바이트를 추가하므로, 1500바이트 MTU 환경에서는 실질 페이로드가 1496바이트가 됩니다. 장비가 점보 프레임을 허용한다면 1518바이트 이상의 MTU를 맞춰 두면 불필요한 분할을 줄일 수 있습니다.

만약 물리 NIC가 한 개뿐이라면, vmbr0와 vmbr2를 같은 NIC에 태그로 실어 보낼 수도 있습니다. 다만 이 경우 Proxmox 관리 트래픽과 게스트 트래픽이 공유되므로, 호스트가 다운되면 WAN과 LAN이 동시에 끊어지는 리스크가 커집니다. 가능하면 두 번째 NIC를 확보해 분리하는 편이 훨씬 안정적입니다.

1단계: Proxmox에서 VLAN-aware 브리지 만들기

vmbr2를 새로 만들고 VLAN aware 옵션을 켠 뒤, Physical NIC 2번을 포트로 추가합니다. 이 NIC는 관리형 스위치의 트렁크 포트(Tagged)와 연결됩니다. 브리지가 VLAN-aware가 아니면, 아래 단계에서 태그를 아무리 설정해도 스위치에는 Untagged 트래픽만 전달됩니다.

Proxmox UI 기준 절차는 다음과 같습니다.

  1. Datacenter > Node > Network > Create > Linux Bridge를 선택해 vmbr2를 만듭니다.
  2. Bridge ports에 물리 NIC 이름(e.g., eno2)을 넣고, VLAN aware 체크박스를 켠 뒤 저장합니다.
  3. 변경 후 Apply Configuration을 클릭하거나, CLI에서 ifreload -a로 네트워크를 다시 읽어옵니다.
  4. SSH로 진입해 bridge vlan show vmbr2를 실행하면, 허용 VLAN 목록이 1 PVID Egress Untagged처럼 표시됩니다. 아직 VLAN을 추가하지 않았으니 기본값(1)만 보이면 정상입니다.

2단계: OPNsense에 VLAN 인터페이스 추가

OPNsense UI에서 다음 순서로 진행합니다.

  1. Interfaces > Other Types > VLAN으로 이동해 + Add를 클릭합니다.
  • Parent Interface: vmx1(또는 virtio1) — Proxmox vmbr2와 연결된 OPNsense VM NIC입니다. Interfaces > Overview에서 어느 인터페이스가 vmbr2에 연결되어 있는지 확인하거나, Proxmox VM 설정에서 두 번째 NIC가 어느 이름으로 보이는지 확인한 뒤 선택하세요.
  • VLAN Tag: 10 입력, Description: SVC_LAN
  • Save 후 Tag 20, 30도 반복해 생성합니다.
  1. Interfaces > Assignments로 이동해 + 버튼을 눌러 방금 만든 vmx1_vlan10, vmx1_vlan20, vmx1_vlan30을 차례대로 추가합니다.
  2. 각 인터페이스를 클릭해 Enable을 체크하고 다음 값을 넣습니다.
    • IPv4 Configuration Type: Static IPv4
    • IPv4 Address: 10.20.10.1/24, 10.20.20.1/24, 10.20.30.1/24
    • Description: SVC_LAN, MGMT_LAN, GUEST_LAN처럼 명확히 작성해 두면 방화벽 규칙에서 식별하기 쉽습니다.
  3. Services > DHCPv4에서 각 VLAN 인터페이스를 선택하고 DHCP 서버를 활성화합니다. 풀 범위, 기본 게이트웨이(해당 VLAN 인터페이스 IP), DNS 서버(내부 DNS 또는 공용 DNS)를 지정한 뒤 저장합니다.

VLAN ID는 1번을 피하세요. 많은 스위치가 VLAN 1을 내부 관리용으로 쓰기 때문에 실수로 섞이기 쉽습니다. 10/20/30처럼 의미와 숫자가 매칭되면 이후 스위치와 Proxmox에서도 헷갈리지 않습니다.

3단계: DHCP와 방화벽 정책 정의

Services > DHCPv4 > <VLAN>에서 각 인터페이스의 DHCP 서버를 켠 뒤, 아래 표처럼 범위·DNS·리스 시간을 맞춥니다. 그런 다음 Firewall > Aliases에서 SVC_LAN, MGMT_LAN, GUEST_LAN, VPN_NET 같은 네트워크 alias를 먼저 만들어 두어야 규칙을 읽고 유지보수하기 쉽습니다.

세그먼트 DHCP 범위 DNS 기본 방화벽 정책 (규칙 위치)
서비스 VLAN 10 10.20.10.50-150 OPNsense 또는 내부 DNS Firewall > Rules > SVC_LAN에서 SVC_LAN net -> WAN 80/443 허용, SVC_LAN net -> MGMT_LAN net 차단
관리 VLAN 20 10.20.20.10-30 (대부분 정적 매핑) 내부 DNS Firewall > Rules > MGMT_LAN에 VPN 네트워크만 허용, 기본 규칙은 deny
게스트 VLAN 30 10.20.30.50-254 (리스 1시간) 공용 DNS(1.1.1.1 등) Firewall > Rules > GUEST_LAN에서 GUEST_LAN net -> WAN 80/443/DNS만 허용, 나머지 차단

OPNsense는 인터페이스로 들어오는(In) 트래픽에 규칙을 적용하므로, 서비스 LAN에서 관리 LAN으로 가는 트래픽을 막고 싶다면 MGMT_LAN 인터페이스 규칙에서 Source = SVC_LAN net, Action = Block을 추가해야 합니다. DNS 역시 게스트 VLAN에서 내부 Resolver를 쓰지 못하도록 Destination = This firewall, Port = 53을 차단한 뒤, 공용 DNS를 명시적으로 허용하면 됩니다.

4단계: 관리형 스위치 포트 태깅

트렁크 포트(예: 1번 포트)는 VLAN 10/20/30을 모두 Tagged로 둡니다. 동시에 Native VLAN(PVID)을 99 같은 미사용 값으로 바꿔 두면, 우발적으로 Untagged 프레임이 섞여도 운영 VLAN으로 들어오지 않습니다. 액세스 포트는 다음 예처럼 구성하면 됩니다.

포트 역할 VLAN 설정
2 리버스 프록시 서버 Untagged VLAN 10
3 NAS (관리 전용) Untagged VLAN 20
4 게스트 AP Untagged VLAN 30
5 Proxmox 추가 VM NIC Tagged 10/20 (Trunk)

이 구성을 따르면 Proxmox VM도 vmbr2에 연결된 가상 NIC에서 VLAN 태그를 지정해 서로 다른 세그먼트에 즉시 참여할 수 있습니다.

보안 주의: Native VLAN(기본 Untagged VLAN)을 명시적으로 99 같은 미사용 값으로 옮기고, 관리 VLAN과 겹치지 않게 두면 VLAN hopping 공격 위험을 줄일 수 있습니다. 또한 STP/RSTP를 활성화해 2중 연결 시 레이어2 루프를 예방하십시오.

스위치 UI가 없다면 CLI 명령(switchport trunk allowed vlan 10,20,30, switchport trunk native vlan 99 등)을 활용합니다. Port PVID 메뉴에서 액세스 포트의 PVID를 해당 Untagged VLAN과 맞추지 않으면, 해당 포트에 연결된 장비가 엉뚱한 DHCP 풀을 받게 되니 반드시 짝을 맞춰야 합니다.

일반적인 웹 UI 기준 설정 순서는 다음과 같습니다.

  1. VLAN Management > VLAN Settings에서 VLAN 10/20/30/99를 생성합니다.
  2. VLAN Membership에서 각 포트의 Tagged/Untagged 상태를 지정합니다.
  3. Port PVID 메뉴에서 각 액세스 포트의 PVID를 해당 Untagged VLAN으로 설정합니다 (예: 포트2=PVID 10).

5단계: 인터-VLAN 라우팅 검증

OPNsense 방화벽 규칙으로 기본 정책을 설정한 뒤, 다음을 확인합니다.

  1. 서비스 LAN -> 인터넷: 허용
  2. 서비스 LAN -> 관리 LAN: 기본 차단, 특정 모니터링 포트만 예외
  3. 관리 LAN -> 서비스 LAN: SSH(22)/HTTPS(443)/배포 자동화 포트 등 필요한 최소만 허용
  4. 게스트 LAN -> 서비스/관리 LAN: 전면 차단

검증 시 다음 순서로 확인합니다.

  • 서비스 VM에서 curl https://example.com을 실행해 아웃바운드가 열리는지 확인하고, 동시에 nc -zv 10.20.20.1 22가 차단되는지 봅니다.
  • 관리 LAN 관리자 PC에서 서비스 LAN에 SSH 접속을 시도해 허용 규칙이 맞게 동작하는지 확인합니다.
  • 게스트 SSID에 연결한 후 ping 10.20.10.1이 실패하는지 확인합니다.
  • 위 동작을 할 때 Firewall > Live View에서 ACCEPT/DROP 로그를 보고, 필요하면 Interfaces > Diagnostics > Packet Capture로 태그가 올바르게 붙는지 확인합니다.

세그먼트별 규칙과 자주 빠지는 함정

세그먼트 설계에서 가장 자주 놓치는 지점은 "OPNsense를 거치지 않는 우회 경로"입니다. 특히 Proxmox 호스트나 별도 서버가 여전히 vmbr0에 붙어 있으면, 아무리 VLAN을 만들어도 해당 장비는 정책 밖에 존재합니다.

또 다른 함정은 관리 LAN이 VPN과 분리되지 않는 것입니다. VPN 클라이언트가 곧바로 관리 LAN의 IP를 받으면, VPN 자격 증명이 새어나갔을 때 바로 핵심 서비스에 닿습니다. VPN 전용 서브넷을 두고, 관리 LAN 접근은 방화벽 규칙으로 명시적으로 허용해야 합니다.

가능하면 모든 VLAN 인터페이스의 기본 규칙을 deny all로 두고, 필요한 방향만 하나씩 허용하세요. 기본 허용 정책을 쓰면, 새 VLAN을 만들 때마다 의도치 않게 모든 내부 세그먼트가 서로 통신해 버립니다.

D2 다이어그램으로 올바른 접근 흐름과 차단 흐름을 한 번 더 정리하면 다음과 같습니다.

WireGuard VPN (10.30.0.0/24)OPNsense PolicyManagement LAN(VLAN 20)Service LAN(VLAN 10)Guest LAN(VLAN 30)Internet Allow SSH/HTTPS to mgmtAdmin ports 22/443 onlyBlock lateral trafficAllow outbound per policy

이 다이어그램처럼, 모든 세그먼트 트래픽은 OPNsense 정책을 한 번은 통과해야 하며, VPN 사용자도 예외가 아닙니다.

패킷 흐름 예시

게스트 스마트폰에서 HTTPS 요청이 나갈 때 어떤 경로를 통과하는지 하나의 예로 따라가 봅니다.

  1. 스마트폰이 게스트 SSID에 붙으면 AP가 VLAN 30을 Untagged로 내려주어 IP 10.20.30.x를 받습니다.
  2. AP는 스위치 포트 4에 연결되어 있고, 이 포트의 PVID가 30이라 VLAN 30 태그 없이 트래픽을 보냅니다.
  3. 스위치가 트렁크 포트(포트1)로 보낼 때 VLAN 30 태그를 붙이고, Proxmox 호스트의 물리 NIC 2로 전달합니다.
  4. Proxmox vmbr2는 VLAN-aware이므로 태그를 유지한 채 OPNsense VM NIC로 넘기고, OPNsense의 vmx1_vlan30 인터페이스가 트래픽을 수신합니다.
  5. OPNsense 방화벽이 VLAN 30 규칙을 적용해 허용 여부를 판단하고, 허용된 패킷만 NAT를 거쳐 WAN(vmbr0)으로 내보냅니다.
  6. 응답 패킷은 동일한 경로를 반대로 되돌아와 게스트 스마트폰까지 도달합니다.

이 흐름을 머릿속에 두면 "어디서 태그가 빠졌는지"를 역추적하기 훨씬 쉬워집니다.

흔한 실수

  1. VLAN 태그를 Proxmox VM NIC에 설정하지 않음: VM은 vmbr2에 붙었지만 태그가 없어 기본 VLAN(보통 1)에만 남습니다. VLAN 1은 스위치의 관리/게스트 트래픽 용도로 쓰이는 경우가 많기 때문에, 서비스용 VM이 엉뚱한 DHCP 대역을 받아 게스트 구간으로 흘러가 버립니다.
  2. 관리 NIC를 잘못된 포트에 꽂음: 관리 LAN 전용 포트를 만들었는데 Proxmox 호스트가 여전히 WAN 스위치에 물려 있으면, OPNsense를 거치지 않은 관리 경로가 열립니다.
  3. DHCP 서버를 중복 가동: 기존 ISP 라우터가 여전히 DHCP를 내보내면, 게스트 장비가 OPNsense 대신 ISP 게이트웨이를 기본 경로로 받아 버립니다.
  4. 게스트 VLAN을 무선 AP 한 대에만 적용: 무선 컨트롤러나 Mesh AP가 VLAN을 이해하지 못하면 트래픽이 다시 섞입니다. AP 측에서도 SSID별 VLAN 태그를 지원하는지 확인해야 합니다.
  5. 문제 발생 시 트렁크를 임의로 Untagged로 변경: 급한 마음에 트렁크 포트를 Untagged로 바꾸면, 다른 VLAN 전체가 끊깁니다. 문제를 추적할 때는 Packet Capture로 실제 태그를 먼저 확인하세요.

관리형 스위치와 Proxmox 호스트 관리 경로 정리

스위치 자체의 관리 IP도 관리 LAN에 두어야 합니다. 예를 들어 VLAN 20의 DHCP 범위를 10.20.20.50-100으로 두고, 스위치에는 10.20.20.254/24를 수동 지정하면 됩니다. 이때 스위치의 관리 포트는 VLAN 20을 Untagged로 받거나, Trunk 포트라도 PVID를 20으로 설정해야 합니다.

Proxmox 호스트 역시 관리 LAN에서만 접근되게 만들어야 합니다. 선택지는 두 가지입니다.

  1. vmbr2에 추가 논리 인터페이스를 만들고 VLAN 20 태그를 붙여 10.20.20.5/24 같은 IP를 할당합니다.
  2. 별도 물리 NIC를 관리 LAN 포트에 꽂아 Proxmox 호스트 전용으로 사용합니다.

어느 방식이든 Proxmox UI(8006), SSH, PBS는 관리 LAN이나 VPN을 통해서만 접근되도록 방화벽 규칙을 묶어야 합니다.

트러블슈팅 체크리스트

증상 A: 서비스 VM이 잘못된 IP 대역을 받는다

  1. 스위치 포트: Untagged VLAN이 10인지 확인합니다.
  2. Proxmox VM NIC: vmbr2에 연결되어 있고 VLAN 10 태그가 설정돼 있는지 확인합니다.
  3. OPNsense DHCP: Services > DHCPv4 > VLAN10에서 서버가 활성화되어 있는지 확인합니다.

증상 B: 관리 LAN으로 VPN이 들어오지 않는다

  1. VPN 인터페이스가 방화벽 규칙에서 MGMT_LAN net으로의 접근을 허용하는지 확인합니다.
  2. VPN 클라이언트에 푸시된 경로에 10.20.20.0/24가 포함되어 있는지 확인합니다.
  3. Firewall > Aliases를 사용한다면, 관리 LAN 대역이 최신 값으로 반영됐는지 확인합니다.

증상 C: 특정 VLAN에서 인터넷이 안 된다

  1. 해당 VLAN 인터페이스의 아웃바운드 NAT 규칙이 자동 모드에서 생성되었는지 확인합니다.
  2. 방화벽 규칙이 LAN net -> WAN을 허용하는지 확인합니다.
  3. Packet Capture로 태그가 OPNsense까지 도달하는지 확인합니다.
  4. 관리형 스위치의 STP 로그에서 포트가 차단 상태가 아닌지 확인합니다.

마무리

VLAN과 세그먼트는 "복잡한 기업 네트워크"만의 도구가 아닙니다. Proxmox 위 OPNsense VM과 관리형 스위치 한 대만 있어도 서비스 LAN, 관리 LAN, 게스트 LAN을 분리해 내는 것이 가능합니다. 핵심은 VLAN-aware 브리지 + OPNsense VLAN 인터페이스 + 스위치 포트 태깅이라는 세 가지 축을 맞추는 것입니다.

이 조합을 갖추면 물리 장비 확장 시에도 정책을 다시 짤 필요가 없습니다. 새 장비가 어떤 세그먼트에 있어야 하는지만 결정하고, 해당 VLAN을 Untagged로 받은 포트에 꽂거나 Proxmox VM NIC에 태그를 추가하면 끝입니다. 다음 6편에서는 이렇게 나눈 네트워크를 지키는 백업·업데이트·복구 전략과, 언젠가 OPNsense를 전용 하드웨어로 옮겨야 하는 순간을 다뤄 보겠습니다.

💬 댓글

이 글에 대한 의견을 남겨주세요

☰OPNsense 시리즈