먼저 VLAN 게이트웨이, 그다음 VPN 출구 결정
기본 게이트웨이를 가진 장치가 출구 정책을 적용할 수 있는 위치를 결정합니다. 두 VLAN을 하나의 트랜짓으로 통과시키고 출발지에 따라 출구를 선택하세요.
두 VLAN에는 서로 다른 VPN 출구가 필요하며, 첫 번째 질문은 어떤 정책을 쓸지가 아니라 어떤 장치가 기본 게이트웨이에 응답하는지입니다. 스위치가 VLAN 사이를 라우팅하면 방화벽 규칙은 패킷이 결코 지나지 않는 경로를 설명할 수 있습니다. 출구 정책을 건드리기 전에 토폴로지를 살펴보세요.
첫단계: 각 VLAN이 사용하는 게이트웨이 찾기
각 클라이언트에 게이트웨이를 묻고, 어떤 인터페이스가 VLAN을 소유하는지 스위치에 물으세요. 기본 게이트웨이는 서브넷을 떠나는 트래픽의 첫 라우팅 결정을 정하므로 어떤 장치가 정책을 적용할 수 있는지도 정합니다.
ip route show default
show ip interface brief
일관된 두 가지 구성이 흔합니다. 방화벽이 VLAN 인터페이스를 소유하고 그 사이를 라우팅하거나, 다층 스위치가 이를 소유하고 로컬에서 라우팅하며 외부 목적지만 방화벽으로 보냅니다. 둘 다 작동하며 정책을 다른 위치에 둡니다.
의도적으로 하나를 고르세요. 혼합 구성이야말로 규칙이 잘못된 장치에 남는 방식입니다.
둘단계: 로컬 정책이 어디에 사는지 결정하기
스위치가 직원과 랩 사이를 라우팅한다면 방화벽 규칙은 방화벽에 결코 도달하지 않는 교환을 검사할 수 없습니다. 로컬 정책은 스위치 자체의 접근 제어에 있어야 하거나, 트래픽을 의도적으로 검사 지점을 통해 보내야 합니다.
반대 선택에도 비용이 있습니다. 모든 VLAN의 게이트웨이를 방화벽으로 만들면 로컬에서 라우팅되는 트래픽이 해당 장치의 용량 및 가용성 계획에 들어가므로 방화벽 재부팅이 VLAN 간 중단이 됩니다. 스위치가 무상태이거나 방화벽이 느리다고 가정하지 말고 실제 하드웨어를 평가하세요. 재부팅하는 장치가 두 바쁜 서브넷 사이의 경로도 아니라면 용량 계획이 더 쉽습니다.
중요한 것은 선택한 정책이 패킷이 실제로 따르는 경로에 있는지 여부입니다.
셋단계: 두 장치에 하나의 트랜짓 주기
스위치가 라우팅할 때 단일 트랜짓 서브넷은 토폴로지를 읽기 쉽게 유지합니다. 두 장비를 경쟁 라우터로 각 클라이언트 VLAN에 매다는 대신입니다. 스위치가 클라이언트 서브넷을 소유하고 방화벽이 외부를 소유합니다.
# on the switch
ip route 0.0.0.0/0 10.255.0.2
# on the firewall
ip route add 10.20.10.0/24 via 10.255.0.1
ip route add 10.20.20.0/24 via 10.255.0.1
스위치는 외부 목적지를 방화벽의 트랜짓 주소로 보내고, 방화벽은 스위치를 통해 두 클라이언트 접두사로 돌아가는 경로를 가집니다. 마이그레이션 중 관리 접근, DHCP 게이트웨이 설정, VLAN 멤버십을 그대로 유지하세요. 이 세 가지가 깔끔한 전환을 콘솔 케이블을 든 오후로 바꾸기 때문입니다.
트랜짓 설계는 다음 방화벽 교체도 재배선 프로젝트가 아니라 라우팅 변경으로 만듭니다.
넷단계: 도착하는 출발지에서 출구 선택하기
일반 라우팅과 중간 출발지 변환이 없으면 방화벽은 트랜짓 인터페이스에서 원래 직원 또는 랩 주소를 받습니다. 두 VLAN이 하나의 링크로 도착하며 그 IP 정체성은 유지됩니다.
그 출발지 주소와 실제 인그레스 경로의 의도된 목적지를 사용해 VPN 선택을 표현하세요. OPNsense의 규칙 문서는 시스템 라우팅을 따르는 기본 게이트웨이 설정과 정책 기반 라우팅을 호출하는 명시적 게이트웨이를 구분합니다. 선택이 패킷이 어디서 왔는지에 달려 있을 때 명시적 형식을 사용하세요. 일반 기본 경로는 출발지를 볼 이유가 전혀 없습니다.
로컬 목적지를 지나치게 넓은 출구 규칙 밖에 두고, 실행하는 릴리스에 지원되는 게이트웨이 모델을 확인하세요.
다단계: 두 경로를 모두 증명하기
결과를 두 문장으로 쓰세요. 승인된 목적지로 가는 직원 트래픽은 출구 A로 나가고, 승인된 목적지로 가는 랩 트래픽은 출구 B로 나갑니다. 반환 경로, 변환 규칙, 출구가 다운되었을 때의 의도된 동작을 추가하세요.
traceroute -n 198.51.100.10
그다음 로컬 VLAN 간 서비스를 별도로 테스트하세요. 같은 설계에서 다른 결정을 연습시키기 때문입니다.
각 VLAN의 새 흐름, 작동하는 로컬 서비스, 문서화된 장애 경로가 함께 설계를 증명합니다. 성공한 ping 하나는 그 순간 하나의 경로가 있었다는 것만 증명합니다.