mathbong
EN
인프라 OPNsense

[OPNsense 시리즈 4편] WireGuard VPN과 안전한 원격 관리 흐름 정리

#opnsense#wireguard#vpn#remote-admin#homelab
English version

이제 Proxmox와 OPNsense 구조가 잡혔다면, 관리자 자신이 외부에서 안전하게 들어올 길을 닦아야 합니다. WireGuard는 "관리자 노트북 ↔ OPNsense" 사이에 하나의 암호화 터널을 뚫어 주는 열쇠와 비슷합니다. 이 터널을 어떤 사람이 쓸 수 있고, 들어온 뒤 어디까지 이동할 수 있는지를 정교하게 정해야 진짜 안전해집니다. 단순히 터널만 열면 충분하지 않습니다. 어떤 서브넷을 VPN으로 연결하고, 어떤 서비스는 외부에 계속 열어둘지, Proxmox/OPNsense UI는 어디에 배치할지까지 함께 정리해야 합니다.

이 글은 OPNsense 자체의 버튼 위치 설명보다, 원격 관리 흐름을 설계하고 검증하는 관점에 집중합니다. 도입부에서 왜 WireGuard를 택했는지 배경을 먼저 잡고, 그다음 설계·검증 순서로 전개합니다. 무엇보다 VPN을 잠가 버리기 전에 IPMI/iKVM, Proxmox 로컬 계정, 물리 콘솔 같은 out-of-band 경로를 확보해야 비상 시 스스로를 가두지 않습니다.

이 글의 흐름

  1. 왜 WireGuard를 선택하고 OPNsense에서 운영하는가
  2. 관리자 전용 서브넷과 주소 계획을 어떻게 잡는가
  3. 원격 접근 흐름과 UI 배치를 어떻게 나누는가
  4. OPNsense WireGuard 설정 체크리스트
  5. 흔한 실수와 복구 시 주의점

이 글에서 새로 강조하는 개념

  1. 관리자 서브넷 (Admin subnet): 일반 서비스와 분리된, 관리 트래픽만 허용하는 사설 대역입니다.
  2. WireGuard Peer 그룹: WireGuard 인터페이스 하나에 여러 관리자를 묶어 두고, 키·AllowedIPs를 관리하는 단위입니다.
  3. 관리 UI 분리: Proxmox, OPNsense, 백업 UI를 VPN 뒤 또는 별도 VLAN으로 격리하는 전략입니다.

용어 미리 정리하기

  • AllowedIPs: WireGuard 피어가 송수신할 수 있도록 허용된 CIDR 목록입니다. 순서는 의미가 없고 10.10.30.0/27,10.10.20.0/24처럼 쉼표로 구분합니다. 서버 측에서는 해당 범위의 패킷만 피어에서 오는 것으로 인정하고, 클라이언트 측에서는 그 범위로 향하는 트래픽만 터널로 보냅니다.
  • Split tunneling: 클라이언트가 AllowedIPs를 제한해 특정 대역만 VPN을 거치도록 만드는 방식입니다. 예를 들어 10.10.30.0/27까지만 VPN으로 보내고 나머지 인터넷 트래픽은 기존 게이트웨이를 유지합니다.
  • Out-of-band 경로: VPN이나 일반 네트워크와 무관하게 장비에 접근할 수 있는 별도 수단입니다. 물리 콘솔, IPMI/iKVM, 별도 관리망 등 "WireGuard가 고장 나도 열리는 문"을 뜻합니다.

읽기 카드

  • 예상 소요: 18분
  • 사전 준비: OPNsense 인터페이스 설정, 기본 DHCP/NAT 개념, WireGuard 기본 키 교환 방식
  • 읽고 나면: 어느 주소 대역을 관리자용으로 남겨두고, 어떤 서비스만 외부에 노출할지 근거를 세울 수 있습니다.

왜 WireGuard를 선택하고 OPNsense에서 운영하는가

WireGuard는 단일 UDP 포트만 열면 되고, 키 교환이 단순하며, 모바일·데스크톱 클라이언트도 모두 지원합니다. OPNsense에 직접 WireGuard 플러그인을 올리면 다음을 한 곳에서 다룰 수 있습니다.

  1. VPN 터널이 끝나는 지점과 방화벽 정책이 같은 장비에 있으므로, 관리자용 서브넷을 바로 방화벽 규칙으로 제어할 수 있습니다.
  2. Proxmox, NAS, 백업 서버 같은 내부 장비는 OPNsense DHCP/DNS로 관리하고, 원격 관리자는 WireGuard 피어 설정의 DNS 항목을 통해 같은 내부 DNS를 사용하도록 강제할 수 있습니다.
  3. 장애 시에도 콘솔에서 WireGuard 인터페이스 상태를 확인하고, 필요하면 일시적으로 비활성화할 수 있습니다.

즉, WireGuard를 별도 VM이나 LXC에 두기보다 OPNsense에 두면 "VPN → 방화벽" 라우팅을 자연스럽게 강제할 수 있습니다.

관리자 서브넷 계획하기

관리자 서브넷이 명확하지 않으면 VPN을 열어도 결국 Proxmox UI나 백업 대시보드를 어디에 둘지 갈팡질팡하게 됩니다. 작은 홈랩이라도 "서비스용", "관리용" 대역을 구분하면 정책이 훨씬 단순해집니다.

이제 여기서 결정할 것은 단순한 IP 숫자가 아니라, "누가 어느 대역으로 들어와 어떤 관리 화면에 닿는가"를 한 장의 그림으로 고정하는 일입니다.

예시는 다음과 같습니다.

WAN / ISPOPNsenseService Subnet10.10.20.0/24Admin Subnet10.10.30.0/27WireGuard VPN10.10.50.0/28Mgmt Hosts(Proxmox, PBS, Switch, iLO)App / Proxy / DB
  • 10.10.20.0/24: 서비스(Reverse proxy, 앱 서버, DB)만 붙습니다.
  • 10.10.30.0/27: 관리 대상 장비(Proxmox, PBS, 스위치 관리 IP, iLO/IPMI)를 둡니다. 이 대역은 기본적으로 WireGuard에서만 접근합니다.
  • 10.10.50.0/28: WireGuard 클라이언트 주소입니다. 관리자 노트북, 태블릿, 점프박스 등을 여기에 할당합니다.

OPNsense DHCP 서버나 정적 매핑을 활용해 관리 장비가 항상 10.10.30.x를 받게 만들고, 방화벽 규칙도 "10.10.50.0/28에서 10.10.30.0/27으로만 허용"처럼 구체화합니다.

왜 이 대역인가

서브넷 선택 이유 주소 수(usable)
10.10.20.0/24 역방향 프록시, 앱 서버, DB처럼 늘어나는 워크로드 254
10.10.30.0/27 Proxmox(5), PBS(1), 스위치(1), IPMI(5) + 여유 30
10.10.50.0/28 관리자 5명 + 임시 장치 몇 개 14

장비 수가 더 많다면 /26이나 /25로 넓히면 되고, 이미 쓰는 대역과 겹친다면 다른 사설 범위를 고르면 됩니다. 핵심은 "관리 대상"과 "서비스 대상"을 별도 대역으로 나누고 이름까지 붙이는 것입니다.

대역 선택 빠른 가이드

환경 예상 WireGuard 피어 수 추천 서브넷
1~2명 개인 홈랩 2~4 /29
소규모 팀 5~8 /28
외부 감사·점검 포함 9~16 /27
2곳 이상 또는 20명 이상 16+ /26 이상

이 표는 피어 수만 본 값이 아니라, 서버 인터페이스 주소 1개와 임시 장치, 교체 장비, 테스트 단말까지 남겨 둘 여유분을 함께 고려한 권장치입니다.

서버 인터페이스가 주소를 1개 차지하므로 항상 여유분을 남겨 두고, 필요 시 /25 이상의 별도 대역을 확보하세요.

주소 계획 시 체크리스트

  1. 승격 불가 대역 예약: WireGuard용 대역은 다른 용도로 재사용하지 않습니다.
  2. 관리 대상 태깅: Proxmox UI, PBS, NAS, 스위치 관리 포트를 모두 관리자 서브넷으로 재배치합니다.
  3. DNS 이름 부여: mgmt-proxmox.lan, mgmt-opnsense.lan 같은 이름을 내부 DNS에 등록하면, 클라이언트가 IP 대신 이름으로 접근할 수 있습니다.

원격 접근 흐름과 UI 배치

관리자가 어떤 경로로 들어와 무엇을 만지는지 시각화하면 정책 점검이 쉬워집니다.

주소 계획을 정했다면, 이제 그 주소를 따라 실제 접근 흐름을 그려 봅니다. 이 단계를 거치면 "무엇을 VPN 뒤로 넣고 무엇을 외부에 남길지"가 훨씬 선명해집니다.

WireGuard Client노트북 / 휴대폰InternetOPNsenseWireGuard (UDP 51820)OPNsense FW RulesAdmin Subnet10.10.30.0/27Service Subnet10.10.20.0/24Mgmt UIProxmox / OPNsense / PBSPublic Proxy443 only

원칙은 다음처럼 요약됩니다.

  1. 외부 공개 포트는 리버스 프록시가 있는 서비스 서브넷에만 존재합니다.
  2. 관리자 UI는 관리자 서브넷에만 존재하며, WireGuard 피어에서만 접근할 수 있습니다.
  3. WireGuard 포트(예: UDP 51820) 하나만 WAN에 열고, 나머지 관리 포트는 전혀 공개하지 않습니다.
  4. 필요하면 WireGuard 피어별 AllowedIPs를 달리하여, 일부 피어는 10.10.20.0/24까지 보게 하고, 대부분은 10.10.30.0/27만 보게 만듭니다.

피어 권한 설계 예시

피어 AllowedIPs 예시 권한 범위
주 관리자 10.10.50.2/32,10.10.30.0/27,10.10.20.0/24 관리/서비스 모두 접근
백업 담당 10.10.50.3/32,10.10.30.5/32 PBS 한 대만 접근
외주 점검 10.10.50.4/32,10.10.30.0/27 관리자 서브넷만 접근

AllowedIPs를 구체적으로 좁힐수록 계정 탈취 시 영향 범위도 작아집니다.

예를 들어 집 밖의 노트북에서 Proxmox(10.10.30.5)와 NAS 관리 UI(10.10.30.10)만 열고 싶다면, 클라이언트 쪽 AllowedIPs를 10.10.30.5/32,10.10.30.10/32처럼 더 좁게 둘 수 있습니다. 이때도 서버 쪽 피어 설정에는 해당 클라이언트의 터널 주소(10.10.50.2/32)가 정확히 연결돼 있어야 합니다.

AllowedIPs는 라우팅만 통제할 뿐, 애플리케이션 권한까지 대신하지 않습니다. 즉, 네트워크 경로를 좁히는 도구이지 Proxmox 로그인 권한을 나눠 주는 ACL은 아닙니다. Proxmox RBAC, PBS 읽기 전용 권한, 별도 방화벽 룰과 함께 써야 역할별 접근이 실제로 구분됩니다.

또한 WireGuard 인터페이스에는 양방향 방화벽 규칙을 명확히 둬야 합니다. WireGuard 탭에서 "피어 → 관리자 서브넷" 허용 규칙을 만들고, 내부 관리자 서브넷에도 "관리자 서브넷 → WireGuard" 응답 규칙(또는 stateful 허용)을 둬야 ping, SSH, HTTPS 등이 정상적으로 돌아옵니다.

AllowedIPs 함정: 클라이언트 AllowedIPs에 10.10.30.0/27을 빼먹으면 관리자가 공용 인터넷을 통해 Proxmox에 접근하는 셈이 되고, 반대로 0.0.0.0/0을 넣으면 회사 VPN과 충돌하거나 전 트래픽이 WireGuard로 빨려 들어갈 수 있습니다. 필요한 범위만 명시하세요.

피어에서 Proxmox까지 실제로 어떻게 가는가

WireGuard 피어10.10.50.2OPNsense wg010.10.50.1OPNsense LAN10.10.30.1Proxmox10.10.30.5OPNsense 라우팅 테이블이10.10.50.0/28 ↔ 10.10.30.0/27 경로를연결합니다 UDP 51820암호화된 터널내부 라우팅LAN 평문

이 경로를 염두에 두고, wg show나 Routes 메뉴에서 라우팅 항목이 올바른지 확인합니다.

OPNsense에서 WireGuard 설정 체크리스트

버튼 순서를 장황하게 적기보다는, 설정 후에 점검할 항목과 성공 기준을 함께 두면 재현성이 높습니다.

  1. 플러그인
    • os-wireguard 설치 여부 확인 → VPN > WireGuard 메뉴가 생겼다면 통과
    • 실패 시 System > Firmware > Plugins에서 설치 후 재부팅
  2. 로컬 인스턴스
    • Local 탭에서 Interface Keys 생성, Listen Port 51820 고정
    • Tunnel Address에 10.10.50.1/28 입력 → 저장 후 wg show에서 Interface가 보이면 성공
  3. 피어
    • 관리자별 공개키·사설키를 클라이언트에서 생성 후 OPNsense에 등록
    • AllowedIPs 형식을 10.10.50.2/32,10.10.30.0/27처럼 쉼표로 구분
    • wg-quick 기반 클라이언트에는 DNS = 10.10.30.1(내부 DNS), MTU = 1420, PersistentKeepalive = 25를 함께 적어 DNS 누수·단편화·NAT 타임아웃을 줄입니다. ping -M do -s 1400 10.10.30.1로 MTU를 검증하세요.
    • wg show → latest handshake 시간이 찍히면 연결 성공(오랫동안 유휴인 피어는 타임스탬프가 오래돼도 정상)
  4. 방화벽
    • WAN 탭에 UDP 51820 허용 규칙 추가, 로그 활성화로 추후 감사 대비
    • 가능하면 이 규칙에 rate limit, GeoIP/ASN 필터 같은 보조 제어를 함께 검토해 무차별 스캔 노출을 줄입니다.
    • Interfaces > Assignments에서 WireGuard 인터페이스를 추가하고, 해당 탭에서 10.10.30.0/27만 허용하는 룰 작성
  5. 라우팅 및 DNS
    • System > Routes > Status에서 기존 경로와 겹치지 않는지 확인하고, 관리자 서브넷이 다른 인터페이스에 있다면 System > Routes > Configuration에 정적 경로를 추가합니다.
    • 내부 DNS 서버를 OPNsense로 두고 mgmt-* 이름을 WireGuard 클라이언트가 해석할 수 있게 추가합니다.
  6. 감사 로깅
    • VPN > WireGuard > Log에서 접속/해제 기록 확인
    • 필요하면 System > Settings > Logging / targets에서 외부 syslog로 내보내 추적성을 확보
  7. 키 로테이션
    • 분기마다 또는 멤버가 바뀔 때 Generate new key로 로컬 인터페이스/피어 키를 갱신하고, 클라이언트 설정도 함께 업데이트합니다.
    • 구 키를 삭제하고 새 키가 배포됐는지 wg show의 public key 값을 대조합니다.

샘플 wg-quick 클라이언트 설정

[Interface]
PrivateKey = <client-private-key>
Address = 10.10.50.2/28
DNS = 10.10.30.1
MTU = 1420

[Peer]
PublicKey = <opnsense-public-key>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.10.30.0/27,10.10.20.0/24
PersistentKeepalive = 25

설정 후 검증 5분 체크리스트

설정을 저장했다면 바로 아래 순서로 검증합니다. 이 단계가 빠지면 "설정은 맞는데 라우팅이나 방화벽이 어긋난 상태"를 한참 뒤에 발견하게 됩니다.

  1. OPNsense 측 인터페이스 상태: SSH나 콘솔에서 wg show를 실행해 interface: wg0, listening port: 51820이 보이는지 확인합니다. Web UI를 쓰는 경우에도 최근 핸드셰이크 시각과 송수신 바이트가 증가하는지를 같은 기준으로 봅니다.
  2. 클라이언트 연결: wg-quick up home-opnsense 실행 후 ip addr show로 10.10.50.x/28이 부여됐는지 확인하고, ping 10.10.50.2(자신)와 ping 10.10.50.1(서버)을 순서대로 확인합니다.
  3. 기본 통신 테스트: WireGuard 클라이언트에서 ping 10.10.30.1, ping 10.10.30.5(Proxmox) 순으로 확인합니다.
  4. DNS 확인: nslookup mgmt-proxmox.lan 10.10.50.1처럼 관리자용 도메인이 올바른 IP를 반환하는지 확인합니다.
  5. 실패 시 진단: OPNsense 로그(VPN > WireGuard > Log), 클라이언트 로그(journalctl -u wg-quick@home-opnsense)를 대조해 키 불일치인지 방화벽 문제인지 구분합니다.

백업과 키 관리 가이드

여기서는 개인 홈랩에서 바로 적용할 최소선과, 여러 사람이 함께 쓰는 환경에서 추가해야 할 운영 절차를 나눠 봅니다.

  • 개인 홈랩 최소 권장: WireGuard 키가 포함된 OPNsense 설정 백업은 암호화해 별도 보관하고, 최소 한 번은 복원 절차를 문서 없이도 다시 따라 할 수 있는지 점검합니다.
  • 개인 홈랩 최소 권장: 노트북이나 휴대폰을 분실했다면 해당 피어를 즉시 비활성화하거나 삭제하고, 새 키를 발급한 뒤 wg show로 새 공개키가 반영됐는지 확인합니다.
  • 소규모 팀 이상 권장: WireGuard 키 목록을 OPNsense 백업과 별도로 기록해 복구 후 대조할 수 있게 둡니다.
  • 소규모 팀 이상 권장: 복원 직후 wg show의 공개키를 인벤토리와 비교한 뒤 인터페이스를 재가동하고, 유출된 피어 키는 즉시 삭제한 뒤 새 키 배포와 방화벽 로그 확인까지 한 묶음으로 처리합니다.

무엇을 외부에 노출하고 무엇을 숨길 것인가

WireGuard가 있다 해도 모든 것을 VPN 뒤로 숨기면 이용자 경험이 나빠집니다. 현실적인 기준은 다음과 같습니다.

  • 외부 공개 유지: HTTPS 리버스 프록시(443), Let's Encrypt HTTP-01 인증용 80, 필요 시 특정 서비스 API 포트. 이때도 OPNsense에서 GeoIP, Rate limit, WAF 같은 보조 정책을 검토합니다.
  • VPN 뒤: Proxmox UI, OPNsense UI, 백업 서버, 모니터링, 내부 Git, Ansible/Puppet, IPMI/iLO. 이들은 단 한 번의 취약점으로 전체 호스트 제어권이 넘어갈 수 있으므로 반드시 WireGuard 뒤에 둡니다.
  • 조건부 공개: SSH. 꼭 필요하면 Jump VM 하나만 외부에 노출하고, 나머지는 WireGuard 뒤 점프박스를 통해 접근합니다. Jump VM은 키 기반 인증·rate limit을 적용하고, 침해되면 즉시 폐기할 수 있어야 합니다.

다만 IPMI/iLO처럼 전원 제어와 콘솔 복구까지 가능한 인터페이스는 일반 관리 UI와도 한 단계 더 분리된 별도 관리망이 가장 안전합니다. WireGuard 뒤 배치는 최소선이고, 장비가 허용한다면 별도 VLAN이나 물리적으로 분리된 관리 네트워크를 우선 검토하세요.

흔한 실수와 복구 시 주의점

  1. AllowedIPs를 0.0.0.0/0으로 열어 둔 경우
    • 증상: 회사/공용 네트워크에서 전체 트래픽이 VPN으로 빨려 들어가 인터넷이 막힌 듯 보입니다.
    • 원인 구분: 서버 측 AllowedIPs가 넓어도 문제는 적지만, 클라이언트 측 AllowedIPs가 0.0.0.0/0이면 전 트래픽을 강제로 터널로 보냅니다.
    • 해결: 피어 설정을 10.10.50.2/32,10.10.30.0/27처럼 필요한 범위만 넣고, 나머지 트래픽은 로컬 게이트웨이로 남겨 split tunneling을 유지합니다.
  2. 관리자 서브넷을 DHCP 기본 대역으로 재사용
    • 증상: 일반 클라이언트가 관리 서브넷 IP를 받아 관리자 UI에 직접 접근하거나, WireGuard 정적 IP와 충돌해 접속이 끊깁니다.
    • 해결: DHCP 범위를 10.10.20.0/24로 제한하고, 10.10.30.0/27은 정적 매핑만 허용하거나 별도 VLAN으로 빼냅니다. 내부 DNS에서도 mgmt-* 이름이 다른 대역과 섞이지 않도록 주의합니다.
  3. OPNsense UI를 여전히 WAN에서 열어 둔 경우
    • 증상: 휴대폰 LTE에서 OPNsense 로그인 페이지가 뜹니다.
    • 확인 및 조치: https://공인IP:포트로 접속해 화면이 보이면 즉시 System > Administration > Listen Interfaces를 LAN, WireGuard, localhost 등 내부 인터페이스만 선택하도록 수정합니다. 가능하면 관리자 계정을 분리하고 2FA도 함께 활성화해 UI 노출 실수의 피해 범위를 줄입니다.
  4. 백업 복구 시 WireGuard 키 초기화 미비
    • 증상: 설정은 살아났는데 WireGuard 접속이 모두 실패하거나, 유출된 구 키가 그대로 남습니다.
    • 해결: 복원 직후 wg show로 로컬·피어 공개키를 인벤토리와 비교하고, 새 키를 배포한 뒤 인터페이스를 다시 올립니다.
  5. 비상 콘솔 부재
    • 증상: WireGuard 설정을 잘못 적용해 VPN이 끊겼는데, 원격으로 접근할 방법이 없습니다.
    • 해결: Proxmox Console, IPMI, iKVM 같은 out-of-band 수단을 평소에 확보하고, 접속 방법·자격 증명을 별도로 문서화해 둡니다.
  6. WireGuard만이 유일한 관리 경로인 상태
    • 증상: Proxmox UI, OPNsense UI, 백업 시스템을 모두 WireGuard 뒤에만 두었는데, WireGuard가 고장 나면 복구 자체가 불가능합니다.
    • 해결: 최소 한 개의 로컬 계정/콘솔 경로를 Proxmox나 OPNsense에 남겨 두고, IPMI/iKVM은 가능한 한 별도 네트워크로 분리해 순환 의존성을 끊습니다.

로깅 현실: WireGuard 자체 로그는 핸드셰이크·오류 정도만 기록합니다. 세부 트래픽 감사가 필요하면 OPNsense 방화벽 룰 로그나 LAN 인터페이스 NetFlow/IPFIX를 활용해야 합니다.

마무리

OPNsense 위의 WireGuard는 "VPN 플러그인" 이상의 역할을 합니다. 관리자 서브넷을 설계하고, Proxmox와 주요 관리 UI를 그 안에 넣고, 외부 노출을 HTTPS 프록시 같은 최소 포트로 제한하면, 홈랩이든 작은 사내 인프라든 원격 관리가 훨씬 안전해집니다. 이번 글의 핵심은 세 가지입니다.

  1. VPN만 열지 말고, 관리 서브넷·주소·DNS를 함께 설계해 일관된 정책을 만든다.
  2. WireGuard 인터페이스를 OPNsense 방화벽 규칙과 접목해, 관리자 트래픽이 반드시 정책을 통과하도록 강제한다.
  3. 복구 경로(콘솔, 스냅샷)를 항상 마련해 두고, AllowedIPs·UI 노출·키 교체를 정기적으로 점검한다.

다음 편에서는 이 설계를 실제 배포 파이프라인과 묶어, OPNsense 백업·GitOps·자동 검증을 어떻게 구성할지 살펴보겠습니다.

💬 댓글

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

☰OPNsense 시리즈