3편까지 VLAN·DHCP·방화벽 룰을 구성해, OPNsense는 내부적으로 완성된 상태가 됐습니다. 하지만 아직 인터넷은 기존 방화벽(SonicWall)을 통해 들어옵니다. 이번 편은 외부 공개 서비스를 위한 NAT/포트포워딩을 구성하고, 서비스 중단을 최소화하며 회선을 OPNsense로 넘기는(절체) 과정을 다룹니다. 시리즈에서 가장 긴장되는 순간입니다.
절체란 무엇이고 왜 위험한가
절체(切替, switchover/cutover)는 “끊고 바꾼다”는 뜻으로, 여기서는 인터넷이 들어오는 메인 장비를 SonicWall에서 OPNsense로 바꾸는 작업입니다.
이 작업이 인프라 전체에서 가장 위험한 순간인 이유는 분명합니다. 작업 중 사무실 전체 인터넷이 끊길 수 있고, VoIP 전화·그룹웨어·메일이 동시에 멈출 수 있으며, SonicWall에서 되던 게 OPNsense에서 안 될 수도 있습니다. 그래서 무중단에 가깝게 진행하는 전략과 즉시 롤백할 수 있는 안전장치가 핵심입니다.
이번 편의 큰 흐름은 이렇습니다.
- NAT·포트포워딩 이해와 SonicWall 룰 복제
- 무중단 전략: 2단계 절체(보조 회선 검증 → 최종 절체)
- Phase A — 보조 회선으로 OPNsense 사전 검증
- 절체 전 체크리스트와 롤백 플랜
- Phase B — 최종 WAN 절체
- 절체 직후 확인과 임시 LAN 제거
1. NAT·포트포워딩과 SonicWall 룰 복제
Outbound NAT (내부 → 외부)
내부 사설 IP(10.0.x.x, 192.168.x.x)가 인터넷으로 나갈 때 공인 IP로 바뀌는 게 Outbound NAT입니다. OPNsense는 기본적으로 이걸 자동(Automatic outbound NAT)으로 처리하므로, 일반적인 인터넷 사용은 WAN만 살아 있으면 별도 설정 없이 됩니다.
Firewall → NAT → Outbound대부분의 환경은 Automatic으로 충분합니다. 특정 대역만 다르게 NAT하거나, VPN 대역을 특정 인터페이스로 내보내야 하는 경우에만 Hybrid로 바꿔 수동 룰을 추가합니다.
Port Forwarding (외부 → 내부)
외부에서 우리 서버(웹·메일·VPN 등)로 들어오는 트래픽을 내부 서버로 넘기는 게 포트포워딩입니다.
Firewall → NAT → Port Forward여기서 중요한 작업이 하나 있습니다. 기존 SonicWall에 걸려 있던 포트포워딩 룰을 빠짐없이 OPNsense로 옮겨야 합니다. 이걸 누락하면 절체 직후 “외부에서 홈페이지가 안 열린다”, “메일이 안 들어온다” 같은 사고가 납니다.
절체 준비 단계에서 이렇게 했습니다.
- SonicWall의 NAT/Port Forwarding 규칙을 전부 캡처/Export — 어떤 외부 포트가 어떤 내부 서버:포트로 가는지 목록화.
- OPNsense Port Forward에 같은 룰을 미리 입력하되, Disabled 상태로 둠. 보조 회선 검증 때 하나씩 켜서 시험.
- 각 룰에 대응하는 방화벽 허용도 함께 준비(포트포워딩은 NAT만으로 끝나지 않고, WAN 인바운드 허용 룰이 짝으로 필요).
포트포워딩을 추가하면 OPNsense가 연결된 방화벽 룰을 자동 생성하도록 옵션을 줄 수 있는데, 룰 순서·로그 관리를 위해 NAT와 방화벽 룰을 명시적으로 분리해 관리하는 편이 추적에 유리합니다.
2. 무중단 전략: 2단계 절체
핵심 아이디어는 “운영 중인 회선은 건드리지 않고, 별도 회선으로 먼저 충분히 검증한 뒤 케이블만 옮긴다”입니다. 이걸 위해 ISP 회선을 두 개 활용했습니다.
[Phase A — 검증기]
주 회선 ──→ SonicWall ──→ 사무실 (운영 중, 무중단)
보조 회선 ──→ OPNsense WAN ──→ 관리자만 테스트
[Phase B — 절체기]
주 회선 ──→ OPNsense WAN ──→ 사무실 (새 메인)
SonicWall ──→ 은퇴이 방식의 장점은 명확합니다. Phase A 동안 직원들은 SonicWall 경유로 평소처럼 일하고, OPNsense는 보조 회선에서 혼자 NAT·포트포워딩·VPN을 실제 인터넷으로 테스트합니다. 문제가 나도 OPNsense만 끄면 되니 운영에 영향이 없습니다.
보조 회선이 없다면? 짧은 점검 시간을 잡아 한 번에 옮기는 방법밖에 없습니다. 이 경우 롤백 플랜(아래)이 더더욱 중요합니다. 가능하면 임시 회선이라도 확보해 Phase A를 거치는 걸 강력히 권합니다.
임시 LAN이라는 또 하나의 안전망
2편에서 남겨둔 임시 관리 LAN(트렁크의 Untagged 채널, 예: 192.168.200.1)이 여기서 또 활약합니다. WAN을 아직 SonicWall이 쥐고 있는 동안, 관리 PC를 이 임시 LAN에 직접 꽂아 OPNsense GUI에 접속해 모든 사전 작업을 합니다. WAN 유무와 무관하게 장비를 만질 수 있는 작업 채널입니다.
3. Phase A — 보조 회선으로 사전 검증
WAN 인터페이스에 공인 IP 먼저 설정
ISP가 고정 IP(Static)를 준다면, 케이블을 꽂기 전에 WAN 인터페이스에 IP를 먼저 입력해야 합니다. 설정 없이 꽂으면 기본값(DHCP)이라 IP를 못 받고 Down 상태가 됩니다.
Interfaces → WAN (예: igb5)
IPv4 Configuration Type: Static IPv4
IPv4 address: (보조 회선 공인 IP) / (서브넷, 예 /29)
IPv4 Upstream Gateway: (ISP 게이트웨이) — 새 Gateway 추가DNS는 OPNsense가 자체 Unbound로 재귀 질의를 하므로 ISP DNS는 필수가 아닙니다. 참고용으로 기록만 해둡니다.
연결과 검증
- 보조 회선 랜선을 WAN 포트에 연결.
- OPNsense에서 외부 ping 확인:
ping 8.8.8.8→ 성공하면 회선·게이트웨이 정상. - 포트포워딩 룰을 하나씩 Enabled로 켜며 외부(모바일 데이터 등)에서 접속 테스트.
- VPN(OpenVPN/WireGuard) 클라이언트 설정의 엔드포인트를 보조 회선 공인 IP로 두고 외부에서 접속 테스트.
ISP에 따라 연결 장비의 MAC 주소 등록이 필요할 수 있습니다(특정 ISP는 등록된 MAC만 통신 허용). OPNsense WAN NIC의 MAC을 미리 확인해두고, 회선이 MAC 인증을 쓰면 ISP에 등록을 요청합니다. 절체 당일 “케이블은 꽂았는데 인터넷이 안 된다”의 흔한 원인입니다.
이 단계를 통과하면 OPNsense는 “공인 IP만 바꿔 꽂으면 바로 메인이 될 수 있는” 상태가 됩니다.
4. 절체 전 체크리스트와 롤백 플랜
Phase B는 실제 운영 회선을 옮기는 작업이라, 반드시 아래를 먼저 확정합니다.
절체 직전 체크리스트
- OPNsense config 백업 + SonicWall config 백업 (둘 다, 절체 직전 “골든 백업”)
- 관리 PC가 MGHQ(관리망)로 접속 가능한지 확인 — 절체 후에도 관리할 경로 확보
- WAN 인터페이스에 주 회선 공인 IP/게이트웨이를 적용할 준비 (값 미리 메모)
- 포트포워딩 룰 전부 Enabled 예정 상태로 검토 완료
- 모든 인터페이스 룰에 로그 옵션 ON (절체 직후 트래픽 관찰용)
- 내부 DHCP가 나눠주는 게이트웨이를 OPNsense로 바꿀 준비 (직원 PC가 새 메인을 바라보게)
- 롤백 플랜 — 케이블을 SonicWall에 다시 꽂으면 즉시 복구되는 상태 유지
- 작업 시간 공지 — 평일 업무시간 회피, 저녁/주말, 전 직원 사전 공지
롤백 플랜이 핵심
절체가 잘못됐을 때 “케이블을 SonicWall로 되돌리면 원상복구”되는 상태를 끝까지 유지하는 게 가장 중요한 안전장치입니다. SonicWall 설정을 절체 직전까지 그대로 보존하고, 전원을 내리지 않습니다. 무엇이 안 되든 일단 회선을 되돌려 서비스를 살리고, 원인은 그 다음에 분석합니다.
5. Phase B — 최종 WAN 절체
업무 종료 후, 공지된 시간에 진행합니다.
- 골든 백업 — OPNsense·SonicWall 양쪽 설정을 절체 직전 한 번 더 백업.
- WAN 케이블 이동 — 주 회선 랜선을 SonicWall에서 뽑아 OPNsense WAN 포트에 꽂음.
- WAN IP 변경 — OPNsense WAN 인터페이스의 IP/게이트웨이를 주 회선 공인 IP로 변경(보조 회선 값 → 주 회선 값).
- (필요 시) MAC 등록 — 주 회선이 MAC 인증을 쓰면 ISP에 OPNsense WAN MAC 등록 요청. (이게 막히면 인터넷이 안 되니 사전에 확인)
- 포트포워딩 전부 Enabled — 준비해둔 룰을 모두 활성화.
- 내부 게이트웨이 전환 — DHCP가 나눠주는 게이트웨이를 OPNsense IP로 변경, 고정 IP 장비도 게이트웨이를 OPNsense로. 직원 PC는 DHCP 갱신(또는 재부팅).
여기까지 하면 인터넷 트래픽이 OPNsense를 통해 흐르기 시작합니다.
회선 진단 팁: 같은 ISP의 서브넷을 본사와 다른 사이트가 공유하는 환경에서는, 게이트웨이의 VRRP(가상 라우터) 구성이나 MAC 인증 때문에 “물리적으로는 연결됐는데 통신이 안 되는” 상황이 생길 수 있습니다. 이럴 땐 ① 게이트웨이로 ping이 가는지, ② ARP로 게이트웨이 MAC이 보이는지, ③ ISP가 MAC 필터를 거는지 순서로 좁혀 갑니다.
6. 절체 직후 확인과 임시 LAN 제거
즉시 확인
- 외부 통신: 내부 서버(예: PRHQ)에서 외부로
ping/curl성공 확인. - 각 VLAN 인터넷: USR/DEV/TEL 등 각 망에서 인터넷이 되는지 확인.
- 포트포워딩: 외부에서 공개 서비스(웹/메일/VPN) 접속 확인.
- VPN: 외부에서 원격 접속 성공 확인.
- 로그 관찰: 켜둔 방화벽 로그로 예상치 못한 차단이 없는지 모니터링.
이상이 있으면 주저 없이 롤백(케이블을 SonicWall로)하고 원인을 분석합니다. 이상이 없으면 24~48시간 로그를 관찰하며 안정화를 확인합니다.
임시 LAN 제거와 관리 경로 단일화
안정화가 확인되면, 이제 그동안 작업 채널이자 백도어였던 임시 관리 LAN(192.168.200.1 등)을 정리합니다.
- 관리 경로가 MGHQ(관리망)로 단일화됐는지 먼저 확인(MGHQ로 GUI 접속·SSH가 되는지).
- 3편에서 Anti-Lockout을 LAN → MGHQ로 옮겨뒀는지 재확인. (안 옮겼다면 LAN 제거 시 잠길 수 있음)
- 확인되면 임시 LAN 인터페이스를 비활성화하거나 제거.
이로써 “트렁크 Untagged에 임시 관리 IP가 떠 있는” 과도기 구조가 사라지고, 관리망(또는 VPN)을 통한 깔끔한 단일 관리 경로만 남습니다.
SonicWall 은퇴
며칠간 문제가 없으면 SonicWall의 전원을 내리고 백업용으로 보관합니다. 설정 백업은 별도로 보존해 두면, 만에 하나의 비교·참조에 유용합니다.
이번 편 체크포인트
- 외부 공개 서비스용 포트포워딩이 SonicWall에서 OPNsense로 빠짐없이 이전됨
- 보조 회선으로 NAT·포트포워딩·VPN을 사전 검증(Phase A) 완료
- 골든 백업과 롤백 플랜을 갖춘 상태에서 주 회선을 OPNsense로 절체(Phase B)
- 내부 게이트웨이가 OPNsense로 전환되어 모든 망이 OPNsense를 통해 인터넷 사용
- 임시 LAN 제거로 관리 경로가 MGHQ(또는 VPN)로 단일화
- SonicWall 은퇴 — OPNsense가 명실상부한 메인 방화벽
이제 OPNsense가 실제 운영에 들어갔습니다. 지금까지의 모든 설정(VLAN·DHCP·방화벽·NAT)은 이 절체를 위한 준비였고, 절체가 성공해야 비로소 OPNsense가 진짜 일을 시작합니다.
다음 편 예고
절체가 끝나 OPNsense가 외부에 노출되기 시작하면, 이제 보안·운영 플러그인 트랙으로 넘어갑니다. NTP, GeoIP 차단, ACME(Let’s Encrypt) 인증서, Caddy(리버스 프록시), Suricata(IDS/IPS), 관리자 2FA(TOTP), 그리고 사이트 간 IPsec과 원격 VPN까지. 절체 직후 어떤 순서로 방어선을 세웠는지, 그리고 각 플러그인을 어떻게 설정했는지를 이어서 다룹니다.
