Proxmox VXLAN SDN을 WireGuard 상에 구성하고 OPNsense를 edge gateway로 사용하기

2026년 5월 3일

Note

이 글의 일부는 기계 또는 AI 번역되어 있을 수 있습니다. 내용에 차이가 있는 경우 영어 버전이 우선됩니다.

세 대의 Proxmox VE 호스트 사이에 격리된 게스트 네트워크를 만들고, 노드 간 tenant 트래픽은 암호화하며, 하나의 OPNsense VM이 모든 tenant VNet의 edge gateway 역할을 하는 구성입니다.

핵심 구조는 다음과 같습니다.

Proxmox 호스트 세 대에 WireGuard full mesh 구성
Proxmox SDN VXLAN Zone의 peer 목록에 각 호스트의 wg0 주소 사용
격리된 tenant 서브넷마다 VNet 하나씩 생성
OPNsense VM 한 대가 각 VNet의 기본 게이트웨이, DHCP, NAT, 포트 포워딩 담당

VXLAN은 L2 프레임을 UDP로 캡슐화하지만 자체 암호화를 제공하지 않습니다. VXLAN peer를 WireGuard 주소로 지정하면 VXLAN underlay가 암호화된 WireGuard 터널 안에 들어갑니다.

이 글의 주소는 모두 예시입니다. 실제 환경에서는 로컬 LAN, 게이트웨이, 브리지 이름, 호스트 이름에 맞게 바꿔 사용하세요. tenant 서브넷, WireGuard 서브넷, 관리망 서브넷이 서로 겹치지 않는지도 반드시 확인합니다.

목표 구성

기존 LAN / underlay: 192.168.10.0/24
  pve-a  192.168.10.11
  pve-b  192.168.10.12
  pve-c  192.168.10.13

WireGuard underlay:
  pve-a wg0  10.255.255.1/24
  pve-b wg0  10.255.255.2/24
  pve-c wg0  10.255.255.3/24

Proxmox SDN VXLAN:
  zone: vxwg
  peers: 10.255.255.1,10.255.255.2,10.255.255.3
  mtu: 1370

VNets:
  vnet10 -> subnet 10.10.10.0/24
  vnet20 -> subnet 10.10.20.0/24
  vnet30 -> subnet 10.10.30.0/24

OPNsense VM:
  WAN   -> 기존 LAN 브리지, 192.168.10.50/24
  LAN10 -> vnet10, 10.10.10.1/24
  LAN20 -> vnet20, 10.10.20.1/24
  LAN30 -> vnet30, 10.10.30.1/24

구성 다이어그램

    flowchart TB
  subgraph LAN["기존 LAN / underlay<br/>192.168.10.0/24"]
    PVEA["pve-a<br/>LAN 192.168.10.11<br/>wg0 10.255.255.1"]
    PVEB["pve-b<br/>LAN 192.168.10.12<br/>wg0 10.255.255.2"]
    PVEC["pve-c<br/>LAN 192.168.10.13<br/>wg0 10.255.255.3"]
    WAN["OPNsense WAN<br/>192.168.10.50/24"]
    GW["상위 게이트웨이"]
  end

  PVEA <-->|WireGuard UDP/51820| PVEB
  PVEB <-->|WireGuard UDP/51820| PVEC
  PVEC <-->|WireGuard UDP/51820| PVEA

  subgraph VXWG["Proxmox SDN VXLAN zone: vxwg<br/>peers: 10.255.255.1, 10.255.255.2, 10.255.255.3<br/>MTU 1370"]
    VXPEERS["VXLAN over wg0<br/>UDP/4789"]
    VNET10["vnet10<br/>10.10.10.0/24"]
    VNET20["vnet20<br/>10.10.20.0/24"]
    VNET30["vnet30<br/>10.10.30.0/24"]
  end

  PVEA -.-> VXPEERS
  PVEB -.-> VXPEERS
  PVEC -.-> VXPEERS

  WAN --> EDGE["OPNsense<br/>NAT<br/>DHCP<br/>firewall"]
  EDGE --> LAN10["LAN10 gateway<br/>10.10.10.1/24<br/>MTU 1370"]
  EDGE --> LAN20["LAN20 gateway<br/>10.10.20.1/24<br/>MTU 1370"]
  EDGE --> LAN30["LAN30 gateway<br/>10.10.30.1/24<br/>MTU 1370"]

  LAN10 --- VNET10
  LAN20 --- VNET20
  LAN30 --- VNET30

  VNET10 --> VM10["tenant VMs<br/>10.10.10.0/24"]
  VNET20 --> VM20["tenant VMs<br/>10.10.20.0/24"]
  VNET30 --> VM30["tenant VMs<br/>10.10.30.0/24"]

  GW --- WAN

192.168.10.50은 기존 LAN에 있는 tenant 서비스의 front-door IP입니다. 이 IP 하나로 외부에서 들어오는 서비스를 포트 포워딩할 수 있습니다. 그렇다고 해서 Proxmox 관리 IP 세 개가 없어지거나 숨겨지는 것은 아닙니다. tenant가 Proxmox 관리망에 접근하면 안 된다면, 이를 명시적으로 차단하는 방화벽 규칙을 추가해야 합니다.

이 구성에서 암호화되는 것은 Proxmox 노드 사이를 지나는 tenant VXLAN 트래픽입니다. 같은 호스트 안에서 끝나는 guest 간 트래픽은 호스트 밖으로 나가지 않고, OPNsense WAN 쪽에서 기존 LAN으로 나가는 트래픽도 WireGuard 안에 들어가지 않습니다.

OPNsense VM 한 대가 단일 gateway이자 NAT 지점이 됩니다. 고가용성이 필요하다면 OPNsense HA/CARP, DHCP 동작, VM 배치, front-door IP failover를 별도로 설계해야 합니다. 이 글은 의도적으로 단순한 구성을 다룹니다.

사전 점검

SDN을 설정하기 전에 다음 가정을 확인합니다.

모든 Proxmox VE 노드에서 SDN을 사용할 수 있어야 합니다. Proxmox VE 8.1 이상에서는 핵심 SDN 패키지가 기본 설치됩니다. 오래된 버전에서 업그레이드한 호스트라면 SDN 패키지를 설치하고 /etc/network/interfaces가 /etc/network/interfaces.d/ 아래의 파일을 include하는지 확인합니다.
기존 LAN에서 각 Proxmox 노드가 다른 노드의 UDP/51820에 도달할 수 있어야 합니다.
Proxmox host firewall을 사용 중이라면 LAN 쪽 WireGuard 트래픽과 wg0 쪽 VXLAN 트래픽을 허용할 수 있어야 합니다.
OPNsense WAN IP, tenant 서브넷, WireGuard 서브넷이 기존 네트워크와 겹치면 안 됩니다.
이 글은 IPv4 중심입니다. IPv6 tenant 네트워크를 추가한다면 MTU, Router Advertisement, firewall rule, NAT 가정을 다시 검토해야 합니다.

오래된 Proxmox VE 설치라면 SDN 패키지를 설치하고 interface include 줄이 있는지 확인합니다.

sudo apt update
sudo apt install libpve-network-perl ifupdown2
sudo grep -q '^source /etc/network/interfaces.d/\*' /etc/network/interfaces \
  || echo 'source /etc/network/interfaces.d/*' | sudo tee -a /etc/network/interfaces

WireGuard full mesh 구성

모든 Proxmox 노드에서 WireGuard를 설치하고 키를 만듭니다.

sudo apt update
sudo apt install wireguard

sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/wg0.key'
sudo sh -c 'wg pubkey < /etc/wireguard/wg0.key > /etc/wireguard/wg0.pub'
sudo chmod 600 /etc/wireguard/wg0.key
sudo chmod 644 /etc/wireguard/wg0.pub
sudo cat /etc/wireguard/wg0.pub

세 노드의 public key를 모읍니다. 각 노드의 /etc/wireguard/wg0.conf에서 PrivateKey 값에는 해당 노드의 private key를 넣습니다.

sudo cat /etc/wireguard/wg0.key

pve-a

[Interface]
Address = 10.255.255.1/24
ListenPort = 51820
PrivateKey = <PRIVATE_KEY_OF_PVE_A>
MTU = 1420

[Peer]
PublicKey = <PUBLIC_KEY_OF_PVE_B>
AllowedIPs = 10.255.255.2/32
Endpoint = 192.168.10.12:51820

[Peer]
PublicKey = <PUBLIC_KEY_OF_PVE_C>
AllowedIPs = 10.255.255.3/32
Endpoint = 192.168.10.13:51820

pve-b

[Interface]
Address = 10.255.255.2/24
ListenPort = 51820
PrivateKey = <PRIVATE_KEY_OF_PVE_B>
MTU = 1420

[Peer]
PublicKey = <PUBLIC_KEY_OF_PVE_A>
AllowedIPs = 10.255.255.1/32
Endpoint = 192.168.10.11:51820

[Peer]
PublicKey = <PUBLIC_KEY_OF_PVE_C>
AllowedIPs = 10.255.255.3/32
Endpoint = 192.168.10.13:51820

pve-c

[Interface]
Address = 10.255.255.3/24
ListenPort = 51820
PrivateKey = <PRIVATE_KEY_OF_PVE_C>
MTU = 1420

[Peer]
PublicKey = <PUBLIC_KEY_OF_PVE_A>
AllowedIPs = 10.255.255.1/32
Endpoint = 192.168.10.11:51820

[Peer]
PublicKey = <PUBLIC_KEY_OF_PVE_B>
AllowedIPs = 10.255.255.2/32
Endpoint = 192.168.10.12:51820

AllowedIPs에는 각 peer의 WireGuard /32 주소만 넣습니다. tenant 서브넷인 10.10.10.0/24, 10.10.20.0/24, 10.10.30.0/24를 여기에 넣지 않습니다. 이 서브넷들은 L3 라우팅으로 WireGuard에 태우는 것이 아니라 VXLAN이 L2로 운반해야 하기 때문입니다.

wg-quick은 peer의 AllowedIPs에서 route를 만들기 때문에 tenant 서브넷을 여기에 추가하면 이 설계와 맞지 않는 L3 라우팅 동작이 생깁니다.

노드들이 같은 LAN에 있고 NAT 뒤에 있지 않다면 PersistentKeepalive는 보통 필요하지 않습니다. NAT 또는 stateful firewall 뒤에 있는 peer가 idle mapping을 유지해야 할 때만 사용합니다.

systemd로 WireGuard를 올리고 확인합니다.

sudo systemctl enable --now wg-quick@wg0
sudo wg show
ping -c 3 10.255.255.2
ping -c 3 10.255.255.3

이미 wg-quick up wg0로 interface를 수동으로 올렸다면, 이미 만들어진 interface에 곧바로 systemctl enable --now wg-quick@wg0를 실행하지 않습니다. 대신 다음 부팅용으로만 service를 enable하거나, interface를 내린 뒤 systemd가 다시 올리게 합니다.

# Option A: 수동으로 올린 세션은 그대로 두고 부팅 시 자동 시작만 활성화
sudo systemctl enable wg-quick@wg0

# Option B: 지금부터 systemd가 관리하게 전환
sudo wg-quick down wg0
sudo systemctl enable --now wg-quick@wg0

VXLAN Zone을 만들기 전에 peer WireGuard IP로 가는 트래픽이 wg0를 사용하는지 확인합니다.

ip route get 10.255.255.2
ip route get 10.255.255.3

방화벽 허용

Proxmox host firewall을 사용 중이라면 기존 LAN 쪽에서 노드 간 UDP/51820을 허용합니다.

VXLAN은 기본 목적지 포트로 UDP/4789를 사용합니다. host firewall이 wg0 입력 트래픽도 제한한다면 wg0에서 10.255.255.0/24의 UDP/4789도 허용합니다.

정리하면 다음 두 가지입니다.

LAN 쪽: 다른 Proxmox 노드 IP에서 들어오는 UDP/51820
wg0 쪽: WireGuard subnet에서 들어오는 UDP/4789

Proxmox SDN VXLAN Zone 생성

Proxmox GUI에서 VXLAN Zone을 만듭니다.

Datacenter -> SDN -> Zones -> Create -> VXLAN

ID:    vxwg
Nodes: pve-a, pve-b, pve-c
Peers: 10.255.255.1,10.255.255.2,10.255.255.3
MTU:   1370

VXLAN peer 목록에는 local node의 주소를 포함해 모든 노드의 WireGuard 주소를 넣습니다. routing table에서는 이 peer 주소들이 wg0를 통해 도달 가능해야 합니다.

WireGuard MTU를 1420으로 두었다면 VXLAN Zone MTU는 우선 1370으로 시작합니다. VXLAN 캡슐화에는 50 bytes가 필요하므로 1420 - 50 = 1370입니다. 실제 LAN underlay의 MTU가 1500보다 작다면 WireGuard와 VXLAN MTU를 더 낮춰야 합니다.

이어서 VNet을 만듭니다.

Datacenter -> SDN -> VNets -> Create

VNet: vnet10  Zone: vxwg  Tag/VNI: 10010
VNet: vnet20  Zone: vxwg  Tag/VNI: 10020
VNet: vnet30  Zone: vxwg  Tag/VNI: 10030

Zone과 VNet을 만든 뒤 SDN 변경 사항을 Apply 합니다.

이 구성에서는 Proxmox SDN의 DHCP, SDN Subnet, SNAT에 기대지 않습니다. 각 tenant subnet의 L3 gateway, DHCP, NAT는 OPNsense가 담당하게 둡니다. 원한다면 CIDR 범위를 Proxmox에 문서화할 수는 있지만, 이 VNet들에 대해 Proxmox가 제공하는 gateway, DHCP service, SNAT를 경쟁적으로 켜지 않습니다.

SDN 변경 사항을 적용한 뒤 Proxmox가 local bridge interface를 만들었는지 확인할 수 있습니다.

ip link show vnet10
ip link show vnet20
ip link show vnet30

VXLAN 트래픽이 WireGuard를 사용하는지 확인하려면, 서로 다른 노드 사이에서 VM이나 gateway로 ping을 보내는 동안 두 노드에서 다음 명령을 실행합니다.

sudo tcpdump -ni wg0 udp port 4789

OPNsense VM 배치

OPNsense VM은 우선 한 노드에 만듭니다. NIC는 4개를 붙입니다.

net0 -> 기존 LAN 브리지, 예: vmbr0  = WAN
net1 -> vnet10 = LAN10
net2 -> vnet20 = LAN20
net3 -> vnet30 = LAN30

NIC 모델은 VirtIO를 사용합니다.

OPNsense 안에서는 다음처럼 할당합니다.

WAN:
  IPv4:    192.168.10.50/24
  Gateway: <LAN_GATEWAY>
  MTU:     default 또는 1500

LAN10:
  IPv4: 10.10.10.1/24
  MTU:  1370

LAN20:
  IPv4: 10.10.20.1/24
  MTU:  1370

LAN30:
  IPv4: 10.10.30.1/24
  MTU:  1370

WAN 주소가 RFC1918 private address이므로 OPNsense WAN interface의 Block private networks 옵션은 해제합니다. 기존 LAN이 bogon 또는 special-use 주소를 사용한다면 Block bogon networks도 검토합니다.

OPNsense의 LAN10, LAN20, LAN30 interface는 VXLAN VNet 위에 있으므로 VXLAN Zone MTU와 같은 1370으로 설정합니다. WAN interface는 기존 LAN에 직접 붙어 있으므로 upstream LAN이 더 작은 MTU를 요구하지 않는 한 기본값 또는 1500으로 둡니다. 나중에 VXLAN Zone MTU를 더 낮추면 OPNsense의 세 LAN interface MTU도 같은 값으로 맞춥니다.

tenant VM과 OPNsense VM이 서로 다른 Proxmox 노드에 있으면 tenant VM의 기본 게이트웨이 트래픽은 VXLAN over WireGuard를 통과합니다. 같은 노드에 있으면 그 트래픽은 해당 host 안에서만 흐릅니다.

DHCP는 OPNsense에서 각 내부 인터페이스별로 켭니다. 작은 환경이라면 Dnsmasq DHCP로 충분합니다.

LAN10: 10.10.10.100 - 10.10.10.199
LAN20: 10.10.20.100 - 10.10.20.199
LAN30: 10.10.30.100 - 10.10.30.199

guest OS가 VNet MTU를 자동으로 사용하지 않는다면 guest interface MTU를 직접 1370으로 설정하거나, DHCP service와 client가 지원하는 경우 DHCP option 26 값을 1370으로 광고합니다. 모든 client가 DHCP로 받은 MTU option을 적용한다고 가정하지 말고 큰 packet으로 테스트합니다.

이 구성에서는 OPNsense에 WireGuard plugin을 설치하지 않습니다. 암호화해야 하는 구간은 firewall VM 안쪽이 아니라 Proxmox 호스트 사이의 VXLAN underlay입니다.

Outbound NAT

OPNsense에서 Firewall -> NAT -> Outbound로 이동합니다. 외부/front-door IP가 하나인 일반 구성이라면 Outbound NAT는 Automatic으로 둡니다.

tenant VM들은 OPNsense를 기본 게이트웨이로 사용하고, OPNsense가 192.168.10.50을 통해 기존 LAN 또는 상위 라우터로 NAT합니다. 이렇게 하면 상위 네트워크에 10.10.10.0/24, 10.10.20.0/24, 10.10.30.0/24에 대한 static route를 추가하지 않아도 됩니다.

서브넷 간 격리

VNet은 L2를 분리합니다. 하지만 10.10.10.0/24, 10.10.20.0/24, 10.10.30.0/24 사이를 라우팅할 수 있는 장비는 OPNsense입니다. 따라서 subnet 간 차단 정책은 OPNsense firewall rule로 명시합니다.

OPNsense의 일반 quick rule은 먼저 매칭된 rule이 이깁니다. block rule을 일반 pass rule보다 위에 둡니다.

LAN10 rule

Block 10.10.10.0/24 -> 10.10.20.0/24
Block 10.10.10.0/24 -> 10.10.30.0/24
Optional: 승인된 서비스 외에는 10.10.10.0/24 -> 192.168.10.0/24 차단
Pass 10.10.10.0/24 -> any

LAN20 rule

Block 10.10.20.0/24 -> 10.10.10.0/24
Block 10.10.20.0/24 -> 10.10.30.0/24
Optional: 승인된 서비스 외에는 10.10.20.0/24 -> 192.168.10.0/24 차단
Pass 10.10.20.0/24 -> any

LAN30 rule

Block 10.10.30.0/24 -> 10.10.10.0/24
Block 10.10.30.0/24 -> 10.10.20.0/24
Optional: 승인된 서비스 외에는 10.10.30.0/24 -> 192.168.10.0/24 차단
Pass 10.10.30.0/24 -> any

나중에 vnet40을 추가하면 같은 방식으로 반복합니다.

관리 LAN 차단 rule이 중요한 이유는, 넓은 Pass -> any rule이 있으면 더 구체적인 block rule이 먼저 있지 않은 한 tenant VM이 기존 LAN으로 연결을 시작할 수 있기 때문입니다. rule을 읽기 쉽게 유지하려면 tenant network, management network, allowed service에 alias를 사용합니다.

포트 포워딩

외부에서 tenant VM으로 들어오는 연결은 OPNsense의 Destination NAT, 즉 Port Forward로 만듭니다.

예를 들어 vnet20에 있는 VM의 HTTPS 서비스를 외부 8443으로 공개하려면 다음처럼 설정합니다.

Interface:            WAN
Protocol:             TCP
Destination:          192.168.10.50
Destination port:     8443
Redirect target IP:   10.10.20.21
Redirect target port: 443
Filter rule:          associated filter rule 추가, 또는 filter rule 수동 생성

filter rule을 수동으로 만든다면 WAN interface에 만듭니다. NAT가 filtering보다 먼저 처리되므로 firewall rule의 destination은 변환된 내부 주소로 잡습니다.

Interface:        WAN
Action:           Pass
Protocol:         TCP
Source:           any, 또는 제한된 source alias
Destination:      10.10.20.21
Destination port: 443

다른 예시는 다음과 같습니다.

WAN TCP 192.168.10.50:2222  -> 10.10.10.11:22
WAN TCP 192.168.10.50:33061 -> 10.10.30.31:3306

외부 포트가 서로 다르면 하나의 front-door IP로 여러 내부 서비스를 공개할 수 있습니다. 가능하면 source 주소를 제한합니다. Source: any는 기존 LAN이나 상위 port forward를 통해 192.168.10.50에 도달할 수 있는 모든 곳에 서비스를 노출합니다.

워크로드 VM 연결

각 VM은 의도적으로 multi-homed로 구성하는 경우가 아니라면 필요한 VNet 하나에만 연결합니다.

vnet10 guest -> gateway 10.10.10.1
vnet20 guest -> gateway 10.10.20.1
vnet30 guest -> gateway 10.10.30.1

IP는 OPNsense DHCP로 받거나 정적으로 설정합니다. VNet은 각 노드에 공통 Linux bridge처럼 나타나므로 VM은 cluster 어느 노드에 있어도 됩니다.

static guest라면 guest가 여전히 1500을 기본값으로 사용할 때 interface MTU를 1370으로 설정합니다.

MTU 확인

이 구성에서 가장 흔한 문제는 MTU입니다.

WireGuard 경로를 먼저 확인합니다.

ping -c 3 -M do -s 1392 10.255.255.2

IPv4 ICMP에서 1392 + 28 = 1420입니다.

그 다음 서로 다른 노드의 같은 VNet에 있는 guest 사이에서 확인합니다.

ping -c 3 -M do -s 1342 10.10.10.12

1342 + 28 = 1370입니다.

HTTPS가 멈추거나 package manager가 중간에 멈추거나 큰 ping이 실패하면 VXLAN MTU를 더 낮추거나 guest interface MTU를 1370 이하로 명시합니다. 일부 경로에서만 실패한다면 physical LAN, WAN uplink, nested virtualization layer, 중간 firewall 중 더 낮은 MTU가 있는 구간을 확인합니다.

내부에서 front-door IP로 접근해야 하는 경우

tenant VM이 내부 주소 대신 192.168.10.50으로 published service에 접근해야 한다면 둘 중 하나를 사용합니다.

split DNS로 내부 클라이언트가 내부 주소를 직접 resolve하게 만들기
OPNsense reflection 또는 hairpin NAT 사용

가능하면 split DNS가 더 단순하고 source address도 더 명확하게 유지됩니다. 외부 주소로 꼭 접근해야 하는 클라이언트가 있을 때만 reflection 또는 hairpin NAT를 검토합니다. client와 server가 같은 L2 서브넷에 있다면 asymmetric return traffic을 피하기 위해 hairpin NAT에 destination NAT와 source NAT가 모두 필요합니다.

문제 해결 체크리스트

연결이 실패할 때는 다음 항목을 확인합니다.

# WireGuard 상태와 handshake 확인
sudo wg show

# VXLAN peer로 가는 route는 wg0를 사용해야 함
ip route get 10.255.255.2

# cross-node tenant traffic이 흐를 때 VXLAN packet이 wg0에 보여야 함
sudo tcpdump -ni wg0 udp port 4789

# 생성된 SDN bridge interface 확인
ip link show vnet10
bridge link show | grep vnet

# WireGuard와 tenant 경로에서 큰 packet 확인
ping -c 3 -M do -s 1392 10.255.255.2
ping -c 3 -M do -s 1342 10.10.10.12

OPNsense에서는 다음 위치를 확인합니다.

Firewall -> Log Files -> Live View에서 tenant 또는 WAN-forwarded traffic 차단 여부 확인
Firewall -> NAT -> Outbound에서 automatic outbound NAT 활성화 확인
Firewall -> NAT -> Destination NAT (Port Forward) 에서 DNAT rule 확인
Firewall -> Rules -> WAN에서 associated 또는 수동 pass rule 확인
Interfaces에서 LAN10, LAN20, LAN30 MTU 값 확인

구축 순서

모든 Proxmox 노드에서 SDN 지원과 firewall 사전 조건을 확인합니다.
세 Proxmox 노드 사이 WireGuard full mesh를 구성합니다.
10.255.255.1, 10.255.255.2, 10.255.255.3 간 ping을 확인합니다.
각 peer에 대한 ip route get 결과가 wg0를 사용하는지 확인합니다.
Proxmox SDN VXLAN Zone vxwg를 생성합니다.
vnet10, vnet20, vnet30을 생성합니다.
SDN 변경 사항을 Apply하고 VNet interface가 모든 노드에 있는지 확인합니다.
OPNsense VM에 WAN 하나와 LAN 세 개의 NIC를 연결합니다.
OPNsense WAN을 192.168.10.50/24로 설정합니다.
OPNsense LAN gateway를 10.10.10.1, 10.10.20.1, 10.10.30.1로 설정합니다.
OPNsense LAN10, LAN20, LAN30 interface MTU를 1370으로 설정합니다.
각 OPNsense tenant interface에서 DHCP를 켭니다.
subnet 간 block rule과 필요한 management-LAN block rule을 추가합니다.
VNet마다 test VM 한 대씩 배치합니다.
cross-node VNet connectivity와 MTU를 테스트합니다.
192.168.10.50:2222 -> 10.10.10.11:22 같은 test port forward를 검증합니다.
test path가 동작한 뒤 실제 workload를 이동합니다.

참고 자료

Acknowledgements

This post was created with assistance from AI.

마지막 수정 일자 2026년 5월 3일

Ubuntu에 Docker Engine(docker-ce) 설치하기