VPN 주소와 LAN DHCP 임대: 터널 IP는 누가 할당하는가

클라이언트를 연결하고 Wi-Fi 아이콘 대신 어댑터를 본다. 10.80.0.14 같은 주소가 터널에 있는데도 사무실 LAN의 어떤 DHCP 서버도 그 임대를 기록한 적이 없을 수 있다. 그 번호를 고른 프로세스가 문제 해결의 출발점을 정한다.

클라이언트에서는 모두 같아 보인다: IPv4 주소 하나, 마스크 하나, 때로 기본 게이트웨이까지. 차이는 그 주소에 누가 응답하고 누가 기록을 보관하는지 물을 때만 드러난다.

클라이언트 쪽에서 터널 주소 읽기

첫 줄이 아니라 블록 전체를 읽으면 Windows가 차이를 보여 준다. ipconfig /all 은 어댑터 설명, 물리 주소, DHCP 줄을 출력한다. PPP나 IKEv2 전화 접속 어댑터는 보통 DHCP를 사용 안 함으로 보고하는데, 이는 연결이 LAN 서버에서 임대하는 대신 전화 접속 중에 주소를 협상했기 때문이다. DHCP가 켜진 터널 어댑터는 드물며 따로 조사할 가치가 있다.

Linux는 같은 정보를 두 도구로 나눈다. ip -4 addr show dev tun0 는 주소와 프리픽스 길이를 준다. nmcli -f IP4 connection show work 는 값이 연결 프로필에서 왔는지, 링크상의 DHCP 교환에서 왔는지, 밀어 넣은 구성에서 왔는지를 드러낸다. 가장 분명한 경우는 WireGuard로, 인터페이스가 나타날 때 wg-quick 가 구성 파일의 Address 줄을 적용하며 연결 시점에 어떤 피어도 무언가를 할당하지 않는다.

프리픽스도 무언가를 말한다. /32 또는 255.255.255.255 마스크는 게이트웨이가 단일 호스트 주소로 라우팅하기를 기대한다는 뜻이고, 더 넓은 마스크는 터널 뒤 어딘가에 링크상 서브넷이 있음을 시사한다.

IKEv2 구성 페이로드가 나르는 것

IKEv2에는 이 작업을 위한 전용 메커니즘이 있다. RFC 7296 3.15.1절에 설명된 구성 페이로드는 INTERNAL_IP4_ADDRESS, INTERNAL_IP4_NETMASK, INTERNAL_IP4_DNS 같은 속성과 그 IPv6 대응물을 나른다. 클라이언트는 선호가 없을 때 길이가 영인 속성을 보내고, 응답자는 사용하기를 원하는 값을 돌려준다. 이 교환은 이미 암호화된 IKE_AUTH 안에서 이루어지므로 어떤 DHCP 브로드캐스트도 터널을 넘지 않는다.

두 가지 결과가 따른다. 첫째, 주소는 응답자나 응답자가 참조하는 인가 백엔드가 고르므로, 풀이 게이트웨이에, RADIUS 응답에, 또는 ID 공급자 매핑에 있을 수 있다. 둘째, DNS 속성은 주소 속성과 별개다. 10.80.0.14 을 받았다고 해서 어느 리졸버가 돌아왔는지, 아니면 아예 돌아왔는지는 알 수 없다.

넷마스크 속성은 실제로 선택 사항이다. 많은 배포가 주소만 돌려주고 클라이언트가 호스트 경로를 설치하게 하므로, 같은 풀이 한 클라이언트에서는 /32, 다른 클라이언트에서는 /24 처럼 보일 수 있다.

LAN DHCP 범위와 VPN 풀이 충돌하는 지점

두 할당자가 같은 범위를 가리킬 때 문제가 시작된다. 10.20.30.0/24 용 DHCP 서버는 10.20.30.128/25 용으로 구성된 VPN 풀을 전혀 모르므로, 게이트웨이가 같은 주소를 원격 클라이언트에 주는 동안 그 서버가 10.20.30.140 을 프린터에 임대하는 것을 막을 것이 없다. 충돌은 며칠 동안 조용히 있다가 간헐적 중복으로 드러난다.

라우팅된 사이트 간 설계는 구조적으로 충돌을 피한다. 지사의 호스트는 로컬 DHCP 서버가 준 주소를 유지한다. 두 게이트웨이의 터널 인터페이스는 각자의 링크 주소를 가지며, 패킷이 지나갈 길은 라우팅 테이블이 정한다. 원격 접속 클라이언트의 주소는 세 번째 범주이며 게이트웨이의 링크 주소와 섞어서는 안 된다.

터널을 LAN에 브리지하면 그 분리가 사라진다. 설계가 정말 하나의 브로드캐스트 도메인을 필요로 한다면 VPN 끝점은 스스로 주소를 내주는 대신 릴레이나 공유 권한 원천을 통해 DHCP 서버와 같은 할당 결정에 참여해야 한다.

주소를 소유한 프로세스 확인

범위를 바꾸기 전에 소유권을 증명한다. 클라이언트에서 주소와 프리픽스를 적는다. LAN에서는 임대 데이터베이스를 검색한다. 게이트웨이에서는 배포하도록 구성된 풀을 나열한다. 임대 파일에서 찾은 주소는 DHCP 서버의 것이므로 터널이 브리지되었거나 릴레이되었다는 뜻이며, 게이트웨이 풀에서만 찾은 주소는 터널 끝점의 것이다.

# client: address and prefix on the tunnel interface
ip -4 addr show dev tun0

# LAN DHCP server: is this address leased to anyone?
grep -c '10.80.0.14' /var/lib/dhcp/dhcpd.leases

# gateway: pools that remote-access clients draw from
sudo swanctl --list-pools

답이 분명해지면 네 가지를 기록한다: 어떤 구성 요소가 클라이언트 주소를 할당하는지, 그 주소에 어떤 범위가 예약되어 있는지, 반환 트래픽이 그 범위에 어떻게 도달하는지, 어떤 자원이 그 주소를 받아들이는지. 이 네 항목이 가상 어댑터 한 줄을 운영상의 사실로 바꾼다.

그 자리에서 DNS 속성 검사도 반복한다. 주소는 주지만 리졸버는 주지 않는 풀은 클라이언트를 로컬 DNS에 남기는데, 이는 LAN이 이미 쓰는 주소를 주는 풀과는 다른 고장이다.