OPNsense 마이그레이션으로 홈 네트워크 업그레이드하는 법

OPNsense 마이그레이션을 고민하게 되는 순간은 단순히 인터넷 속도가 아쉬울 때가 아니었습니다. NAS 붙이고, 홈서버 돌리고, 외부 접속 열고, IoT를 분리하고 싶어지면 속도보다 구조가 먼저 병목이 되더라고요. 저도 처음엔 소비자 공유기 설정 화면에서 포트포워딩 몇 개만 더 열면 끝날 줄 알았는데, 어느 순간부터는 규칙보다 예외가 더 많아졌습니다. 그때부터 장비 교체가 아니라 네트워크 역할을 다시 나누는 쪽으로 생각이 바뀌었습니다.

막상 해보면 핵심은 의외로 분명합니다. 라우팅, DHCP, DNS, 방화벽 책임을 어디에 둘지 다시 설계하는 일입니다. 만족도는 높지만 접근 순서가 틀리면 가족 와이파이부터 바로 영향을 받습니다. 그래서 이 글은 설치 후기가 아니라, 언제 넘어가야 하고 어디서 망가지며 어떻게 다운타임을 줄일지에 집중해 정리했습니다.

특히 아래 조건에 가깝다면 비싼 소비자 공유기 업그레이드보다 OPNsense 마이그레이션이 더 잘 맞습니다.

• 내부망을 메인 PC, 서버, IoT, 게스트로 나누고 싶다
• 포트포워딩과 VPN을 함께 운영해야 한다
• 문제가 생겼을 때 로그와 상태로 원인을 추적하고 싶다
• 기존 공유기를 버리기보다 AP로 재활용하고 싶다

기존 공유기 단일 구조와 OPNsense 중심 분리 구조를 한눈에 보여주는 개요 이미지입니다.

왜 OPNsense 마이그레이션이 필요한가

소비자 공유기는 기본값이 강합니다. 인터넷 연결, NAT, DHCP, 무선, 간단한 방화벽이 한 장비 안에서 돌아가고, 대부분은 그게 장점이죠. 반대로 OPNsense는 기본값보다 의도가 중요합니다. 어떤 세그먼트가 어떤 DNS를 쓰는지, 어떤 VLAN이 어디까지 접근 가능한지, 어떤 포트포워딩이 상위 NAT와 충돌하는지까지 사용자가 구조를 정해야 합니다.

제가 판단 기준으로 삼는 차이는 기능 수가 아니라 정책의 수입니다. 네트워크를 지나는 트래픽에 예외가 계속 늘어난다면, 고급형 소비자 공유기로 버티는 것보다 OPNsense 쪽이 장기적으로 덜 피곤합니다. 반대로 인터넷, 스트리밍, 무선만 안정적이면 되는 집이라면 마이그레이션이 오히려 관리 부담이 될 수 있습니다.

• OPNsense가 유리한 경우: VLAN 분리, 내부 DNS 이름해결, VPN, 포트포워딩, 트래픽 추적, 정책 기반 제어가 필요한 경우
• 기존 공유기가 나은 경우: 무선 커버리지가 핵심이고, 외부 공개 서비스가 없고, 네트워크를 손댈 일이 거의 없는 경우
• 애매한 경우: 라우팅만 OPNsense로 넘기고 무선은 기존 장비를 AP 모드로 유지하는 하이브리드 구성이 현실적입니다

중요한 건, OPNsense는 단순히 더 강한 공유기가 아니라 장애 원인을 분해해서 볼 수 있게 해주는 플랫폼이라는 점입니다. 이 차이를 알고 들어가면 꽤 편합니다. 모르고 들어가면 초반 피로도가 확 올라갑니다.

OPNsense 마이그레이션 전에 먼저 정리할 것들

1. 현재 네트워크를 도식화하지 않으면 장애 시간이 길어집니다

OPNsense로 넘어갈 때 흔한 실수는 새 기능에 신나서 기존 상태를 정확히 안 남기는 겁니다. 이 단계에서 필요한 건 멋진 설계도가 아니라 현재 인터넷이 왜 되는지 설명 가능한 상태입니다. 아래 항목은 최소한 적어두는 편이 좋습니다.

• 회선 연결 방식: DHCP, PPPoE, 고정 IP
• 현재 LAN 대역과 게이트웨이 주소
• 고정 IP 장비: NAS, 프린터, 홈서버, NVR, 카메라
• 외부 공개 포트와 실제 목적지 장비
• DNS를 누가 맡고 있는지: 공유기, Pi-hole, NAS, 외부 DNS
• 무선 AP가 라우팅까지 하는지, 순수 AP인지
• 상위 장비가 모뎀인지, 모뎀 겸 공유기인지

이걸 안 적어두면 나중에 “인터넷은 되는데 NAS 이름이 안 풀린다” 같은 문제에서 시간을 크게 잃습니다. 그 증상이 DNS 문제인지, DHCP 정적 매핑 누락인지, AP 뒤에 남아 있는 옛 서브넷 때문인지 바로 구분이 안 되거든요.

2. 전부 교체하지 말고 역할만 먼저 분리하세요

마이그레이션에서 가장 생산적인 판단은 “무엇을 새로 살까”보다 “누가 어떤 역할을 맡을까”입니다. 특히 홈 네트워크는 무선 품질 때문에 기존 공유기를 완전히 버리는 게 꼭 답은 아닙니다. 저는 보통 아래처럼 나눠서 봅니다.

핵심은 간단합니다. 무선은 유지해도 되고, 라우팅은 분리하는 게 맞습니다. 이 경계만 잘 그어도 전환 난이도가 확 내려갑니다.

OPNsense 마이그레이션 전략: 한 번에 갈아엎지 마세요

집 네트워크는 사무실보다 장애 허용도가 낮습니다. 서버가 잠깐 죽는 건 참아도 TV와 휴대폰 와이파이가 안 되면 바로 티가 납니다. 그래서 저는 병행 전환만 권합니다. 기존 공유기를 빼고 새 장비를 바로 올리는 방식은, 장애가 생겼을 때 비교 기준 자체가 사라집니다.

1. OPNsense 장비 준비: 최소 2개 NIC가 있는 x86 장비를 준비합니다.
2. 분리된 테스트 환경에서 먼저 부팅: WAN에는 회선 또는 상위 장비, LAN에는 테스트 PC 1대만 붙입니다.
3. 기본 인터넷과 관리 UI 확인: WAN 주소, 기본 게이트웨이, LAN DHCP, 웹 UI 접근부터 검증합니다.
4. 기존 공유기는 AP 모드로 전환: DHCP와 NAT는 끄고 무선만 맡깁니다.
5. 고정 IP와 포트포워딩 이전: NAS, 홈서버처럼 영향 큰 장비부터 옮깁니다.
6. VLAN과 세부 정책은 마지막: 기본 LAN이 멀쩡하다는 게 확인된 뒤에 분리 정책을 얹습니다.

여기서 순서를 뒤집으면 대부분 꼬입니다. 특히 초반부터 VLAN, DNS 오버라이드, VPN, IDS/IPS까지 한 번에 켜는 건 추천하지 않습니다. 문제는 기능이 많아서가 아니라, 증상이 서로 비슷하게 보이기 때문입니다. DNS ACL 문제, VLAN 태깅 오류, AP의 잔존 DHCP는 전부 “어떤 기기만 인터넷이 안 됨”으로 보일 수 있습니다.

실전 구현: 최소 다운타임으로 옮기는 순서

1. 기존 공유기 설정 백업과 현재 상태 점검

백업 파일만 믿지 말고, 클라이언트 기준 상태도 남겨두세요. 전환 후 비교할 때 훨씬 빠릅니다. 코드 블록은 설정을 바꾸는 용도가 아니라, 현재 상태를 기록하고 전환 전후를 비교하는 용도입니다.

# Linux 클라이언트 기준: 전환 전 상태 저장
ip addr
ip route
cat /etc/resolv.conf
arp -an

# 전환 후 비교용
ping -c 4 1.1.1.1
ping -c 4 google.com
traceroute 1.1.1.1

해석 포인트는 단순합니다. 숫자 IP는 되는데 도메인이 안 되면 DNS를 먼저 봅니다. 첫 홉이 새 OPNsense LAN 주소가 아니면 클라이언트가 아직 예전 게이트웨이를 보고 있는 겁니다. 이 단계에서 이미 문제를 절반은 줄일 수 있습니다.

2. 전환 후 검증용 테스트 세트는 서비스별로 준비하세요

제가 실제로 쓰는 검증 기준은 단순 인터넷 연결이 아닙니다. 외부 IP, 외부 DNS, 내부 DNS, 내부 서비스, 외부 진입을 구분해서 봅니다. 그래야 어디가 깨졌는지 바로 분류됩니다.

# 외부 IP / 외부 DNS / 내부 이름해결을 한 번에 점검
for host in 1.1.1.1 google.com nas.home.arpa; do
  echo "== $host =="
  ping -c 2 "$host"
done

# TCP 서비스 확인 예시
nc -vz nas.home.arpa 445
nc -vz opnsense.lan 443

여기서는 내부 로컬 이름을 일부러 넣는 편이 좋습니다. OPNsense로 옮긴 뒤 가장 늦게 발견되는 문제가 바로 내부 DNS 등록 누락이기 때문입니다. 인터넷은 되는데 NAS 이름만 안 풀리면 사용자 입장에선 거의 망가진 것처럼 느껴집니다.

3. OPNsense 초기 설정은 기본값을 존중하되 자동 마법에 기대진 마세요

설치 직후엔 욕심내서 꾸미지 말고 아래 순서만 확인합니다.

1. WAN 인터페이스에 회선 연결
2. LAN 인터페이스에 테스트 PC 연결
3. LAN 대역 지정
4. DHCP 서버 활성화
5. 웹 UI 접근 확인
6. 외부 IP와 도메인 해석 확인

이 시점에서 특히 중요한 건 DNS입니다. OPNsense는 기본 설치에서 Unbound DNS가 기본 리졸버로 활성화되는 구성이 일반적입니다. 내부 이름해결까지 생각하면 Services > Unbound DNS에서 아래 항목을 먼저 확인해 두는 편이 좋습니다.

• Register ISC DHCP4 Leases: ISC DHCP를 쓰는 경우, DHCP 호스트명을 Unbound에 반영
• Register DHCP Static Mappings: 정적 매핑 이름을 내부 DNS에 반영
• Access Lists: 클라이언트 네트워크가 리졸버에 질의할 수 있는지 확인
• Network Interfaces / Outgoing Interfaces: 특별한 이유가 없으면 수동 지정보다 기본값을 유지

다만 여기에는 중요한 예외가 있습니다. Kea DHCP를 쓰는 경우에는 ISC DHCP처럼 동적 임대 호스트명이 바로 Unbound에 자동 등록되지 않습니다. 그래서 초반에는 정적 매핑과 내부 도메인 정책부터 먼저 맞추는 쪽이 더 안전합니다. 실제로 OPNsense 초반 장애는 방화벽보다 DNS에서 많이 나더라고요.

인터넷 회선, OPNsense, 스위치, AP, 서버, IoT 네트워크가 어떻게 분리되는지 보여주는 구성 이미지입니다.

4. AP 모드 전환은 체크박스가 아니라 이중 라우팅 제거 작업입니다

기존 소비자 공유기를 AP로 재활용할 때는 아래 네 가지를 꼭 확인합니다.

• DHCP 비활성화: 주소를 두 군데서 주면 클라이언트가 서브넷을 섞어 받습니다.
• NAT 비활성화: 이중 NAT가 남으면 외부 진입과 VPN이 꼬입니다.
• LAN 포트 uplink: 상위 연결은 보통 WAN이 아니라 LAN 포트로 넣습니다.
• 관리 IP 고정: AP 관리 주소를 새 대역 안의 고정 IP로 잡아둡니다.

여기서 자주 나오는 사고 시나리오가 있습니다. AP라고 해놨는데 라우터 기능이 일부 남아 있어서 휴대폰은 새 대역을 받고 TV는 옛 대역을 받는 식입니다. 겉으로 보면 무선 문제 같지만, 근본 원인은 DHCP 서버가 둘인 경우가 많습니다.

5. VLAN은 기능이 아니라 운영 규칙입니다

VLAN을 넣는 순간 네트워크는 깔끔해지지만 동시에 추적 포인트도 늘어납니다. 그래서 저는 기본 LAN이 완전히 안정된 다음에만 넣습니다. 그리고 VLAN ID보다 먼저 접근 정책 문장을 적어둡니다. 예를 들면 이런 식입니다.

• 메인 LAN은 서버 VLAN과 관리 IP에 접근 가능
• IoT VLAN은 인터넷만 가능, 메인 LAN과 서버 VLAN은 차단
• 게스트 VLAN은 내부망 전체 차단, 인터넷만 허용
• 관리용 네트워크는 OPNsense UI와 스위치/AP 관리 IP 접근 허용

이 문장이 먼저 없으면 VLAN은 분리가 아니라 혼란이 됩니다. 태깅이 맞아도 방화벽 규칙이 애매하면 결국 운영자가 더 헷갈립니다. 홈랩에서 가장 위험한 상태는 “분리했다고 믿지만 실제로는 접근이 열려 있는 상태”입니다.

OPNsense 마이그레이션 중 설정과 검증에 바로 쓰는 명령어

웹 UI만으로도 운영은 되지만, 마이그레이션 시점에는 셸에서 현재 상태를 보는 편이 빠릅니다. 아래 명령은 설정을 바꾸는 게 아니라 관찰용이라 부담이 적고, 어디서 막히는지 가닥을 잡는 데 꽤 유용합니다.

# OPNsense 셸에서 현재 상태 빠르게 확인
ifconfig
netstat -rn
sockstat -4 -6 -l | egrep ':(53|67|80|443)\b'
pfctl -sr
pfctl -s nat
pfctl -ss

제가 보는 포인트는 이렇습니다.

• <code>netstat -rn: 기본 경로가 WAN 쪽으로 제대로 잡혔는지
• sockstat: DNS(53), DHCP(67), 웹 UI(80/443) 같은 핵심 서비스가 실제로 리슨 중인지
• pfctl -sr: 필터 규칙이 생각한 순서대로 로드됐는지
• pfctl -s nat: 포트포워딩과 아웃바운드 NAT가 실제로 반영됐는지
• pfctl -ss: 연결 상태가 생기고 있는지 확인할 수 있는지

포트포워딩이나 NAT reflection 관련해서는 pfctl -s nat가 특히 유용합니다. GUI에 규칙이 있어 보여도 적용 버튼을 놓친 경우, 셸에서 활성 NAT 규칙을 보면 바로 티가 납니다.

# 외부 진입 문제를 볼 때 최소 확인 세트
pfctl -s nat
pfctl -ss | egrep '(:80|:443|:51820|:22)'
tcpdump -ni <wan_if> host <public_or_remote_ip>
tcpdump -ni <lan_if> host <internal_server_ip>

이 블록은 트래픽 흐름을 좁혀보는 용도입니다. 패킷이 WAN에는 들어오는데 LAN으로 안 넘겨지면 NAT나 필터 규칙 문제를 먼저 의심합니다. WAN과 LAN 양쪽에 SYN이 보이는데 서버에서 SYN/ACK가 안 나오면, 그땐 서버 방화벽이나 서버 기본 게이트웨이를 먼저 보는 쪽이 맞습니다.

트러블슈팅: OPNsense 마이그레이션에서 자주 막히는 지점들

관리 UI는 열리는데 인터넷이 안 될 때

이건 단순히 인터넷 불가라고 뭉뚱그리면 안 됩니다. OPNsense UI가 열리면 최소한 LAN, DHCP, 웹 UI는 살아 있다는 뜻입니다. 따라서 문제는 대개 WAN, 기본 경로, DNS 중 하나로 좁혀집니다.

제가 실제로 자주 본 케이스는 인터넷은 되는데 nas.home.arpa 같은 내부 이름만 안 풀리는 경우입니다. 이건 사용자 입장에선 반쯤 망가진 상태에 가깝습니다. 그런데 운영자가 이걸 가볍게 넘기면 이후 백업, 미디어 서버, 프린터 검색이 줄줄이 꼬입니다.

포트포워딩이 안 먹을 때

이쪽은 놀랄 만큼 자주 상위 NAT가 원인입니다. OPNsense WAN에 공인 IP가 아니라 사설 IP가 붙어 있다면, 그 위에 이미 모뎀 겸 공유기나 ISP 장비가 라우팅을 하고 있을 가능성이 큽니다. 이 상태에서 OPNsense에만 포워딩을 만들면 외부에서 안 들어옵니다.

• 우선 확인: OPNsense WAN IP가 사설 대역인지 공인 IP인지
• 다음 확인: 상위 장비가 브리지 모드인지, 아니면 별도 포워딩이 필요한지
• 셸 확인: pfctl -s nat로 실제 로드된 NAT 규칙 확인
• 로그 확인: 라이브 로그에서 생성한 규칙 라벨이 매치되는지 확인

여기서 또 하나 많이 헷갈리는 게 헤어핀 NAT입니다. 집 안에서 공인 도메인으로 자기 서버에 접속하려는 경우죠. 외부에서는 되는데 내부에서는 안 되면, 서버가 죽은 게 아니라 NAT reflection이나 split DNS 설계 문제일 수 있습니다. 저는 reflection을 무조건 기본값처럼 기대하기보다, 내부에서는 내부 이름으로 접근하게 DNS를 정리하는 쪽이 더 편하더라고요.

특정 기기만 이상하게 느릴 때

이 부분은 네트워크 글에서 제일 뭉뚱그려 설명되지만 실제 원인은 몇 갈래로 나뉩니다.

• 예전 DHCP 임대 정보: 새 게이트웨이 반영이 늦는 기기가 있습니다
• MTU/MSS 문제: PPPoE나 특정 상위 장비 환경에서 일부 서비스만 유독 느릴 수 있습니다
• DNS 재바인딩 보호나 로컬 DNS 충돌: 특정 내부 웹 UI 접속이 꼬일 수 있습니다
• Wi-Fi 자체 문제: 라우팅이 아니라 무선 로밍이나 채널 혼잡일 수 있습니다

여기서 중요한 건, 모든 느림을 OPNsense 탓으로 돌리면 안 된다는 점입니다. 실제로는 OPNsense로 옮긴 뒤 네트워크가 더 잘 보이기 때문에 원래 있던 무선 문제를 이제서야 발견하는 경우도 많습니다. 특정 기기만 느리면 저는 먼저 그 기기의 IP, 게이트웨이, DNS를 보고 그다음에 무선 연결 위치와 AP를 확인합니다.

관리 화면에서 규칙과 상태 정보를 확인하며 문제를 좁혀가는 과정의 이미지입니다.

검증: OPNsense 마이그레이션이 끝났는지 판단하는 기준

저는 웹 한 번 열렸다고 완료 판정하지 않습니다. 아래 체크리스트를 전부 통과해야 실제 전환 완료로 봅니다.

1. 유선 클라이언트가 의도한 DHCP 범위에서 새 IP를 받는다
2. 기본 게이트웨이가 OPNsense LAN 주소로 잡힌다
3. 외부 IP 통신과 외부 DNS 조회가 모두 정상이다
4. 내부 서비스(NAS, 프린터, 홈서버)가 IP와 이름 둘 다로 접근된다
5. 포트포워딩 또는 VPN 진입이 의도한 서비스에만 열린다
6. IoT와 게스트망이 메인 LAN이나 서버망에 임의 접근하지 못한다
7. AP 관리 IP, 스위치 관리 IP 같은 운영 경로가 끊기지 않는다

이 단계에서 저는 일부러 실패 테스트도 합니다. 예를 들어 IoT VLAN에서 NAS 관리 포트 접속을 시도해 보고, 막혀야 정상인지 확인하는 식입니다. 허용 테스트만 하면 분리 정책은 검증되지 않습니다.

# 클라이언트 검증 예시
ip route
ping -c 2 1.1.1.1
ping -c 2 google.com
ping -c 2 nas.home.arpa
nc -vz nas.home.arpa 445
nc -vz opnsense.lan 443

그리고 OPNsense 쪽에서는 규칙이 실제로 상태를 만들고 있는지 봅니다. 규칙 설명을 사람이 읽을 수 있게 써두면 라이브 로그와 상태 추적에서 시간이 꽤 절약됩니다. 이거 진짜 편하더라고요.

게이트웨이 정상, DHCP 분배 정상, 세그먼트 분리가 완료된 상태를 시각적으로 보여주는 결과 이미지입니다.

운영 팁: OPNsense 마이그레이션 직후 바로 해두면 편한 것

• 구성 백업: 포트포워딩, VLAN, DHCP 정적 매핑을 바꿀 때마다 설정 백업을 남기세요.
• 관리 문서 분리: VLAN ID, 서브넷, 게이트웨이, DHCP 범위, 고정 IP, AP 관리 주소를 표로 남기세요.
• 규칙 이름 정리: “allow any” 같은 이름보다 목적이 드러나는 설명을 쓰세요.
• 변경 단위 축소: DHCP를 바꾼 날에는 DNS까지 같이 손대지 않는 편이 좋습니다.
• 내부 DNS 우선: 포트포워딩보다 먼저 내부 이름해결을 안정화하세요.

추가로 홈랩에서는 성능보다도 되돌리기 쉬운 구조가 중요합니다. VLAN을 멋지게 쪼개는 것보다, 문제가 생겼을 때 10분 안에 원인을 좁힐 수 있는 구성이 더 낫습니다. 저는 그래서 초기에 자동 생성 규칙에 과하게 기대기보다, 나중에 봐도 이해되는 명시적 규칙을 선호합니다.

이전 글에서 스위치 포트 태깅과 AP SSID 분리까지 정리해두셨다면 그 글도 함께 보세요. OPNsense만 제대로 세팅해도 네트워크가 자동으로 정리되진 않거든요. 병목은 늘 경계면에서 생깁니다. 방화벽과 AP 사이, DHCP와 DNS 사이, 상위 모뎀과 WAN 사이에서요.

FAQ와 최종 권고

소비자 공유기를 완전히 버려야 하나요?

그럴 필요 없습니다. 무선 품질이 괜찮다면 AP로 계속 쓰는 게 가장 현실적입니다. 다만 라우팅, NAT, DHCP는 한 곳으로 모아야 합니다. 저는 보통 그 역할을 OPNsense에 몰아주는 쪽을 권합니다.

작은 집 네트워크에도 필요할까요?

기기 수가 적고 외부 공개 서비스도 없고 분리할 네트워크도 없다면 굳이 필요 없습니다. OPNsense는 만능 업그레이드라기보다 정책이 늘어난 환경을 위한 도구에 가깝습니다.

어떤 경우에 특히 추천하나요?

NAS, 홈서버, 원격 접속, IoT 분리, 포트포워딩 운영이 동시에 들어간다면 추천합니다. 반대로 와이파이만 안정적이면 된다면 기존 공유기를 유지하거나 좋은 AP를 추가하는 쪽이 더 낫습니다.

제가 실제 운영 기준으로 내리는 결론은 명확합니다. 외부 공개 서비스가 있거나, 내부망을 둘 이상으로 나눠야 하거나, 장애 원인을 직접 추적해야 한다면 OPNsense로 가는 편이 맞습니다. 이 경우 소비자 공유기 업그레이드는 대개 임시 연장선에 그칩니다. 반대로 네트워크를 설계할 생각이 없고 관리 포인트를 늘리고 싶지 않다면 기존 공유기를 유지하세요. 그 편이 운영 품질이 더 높습니다.

즉, 선택 기준은 장비 성능이 아니라 내가 감당해야 할 정책의 복잡도입니다. 그 복잡도가 이미 공유기 UI를 넘었다면, OPNsense 마이그레이션은 꽤 만족도 높은 홈 네트워크 업그레이드가 됩니다. 아직 그 단계가 아니라면 AP 재배치나 무선 분리만으로도 충분할 수 있습니다.

어떤 환경에서 기존 공유기를 유지하고, 어떤 경우 OPNsense로 넘어가면 좋은지 정리한 요약 이미지입니다.