당신의 VPN 풀은 LAN의 DHCP 범위가 아니다: 왜 깨지는가

유혹적인 지름길은 사무실 DHCP 서버가 쓰는 것과 같은 범위에서 VPN 클라이언트에게 주소를 주는 것이다. 어차피 다 하나의 네트워크라는 생각에서다. 아니다. 라우팅된 터널은 두 끝점 사이에서 유니캐스트 패킷을 나르고, LAN 풀은 물리 세그먼트에서 브로드캐스트 요청에 답하기 위해 존재한다. 같은 번호를 다시 쓰면 두 할당자가 하나의 주소 공간을 맡게 되고 반환 경로는 정의되지 않은 채 남는다.

두 할당자, 하나의 주소 공간

LAN의 DHCP 서버는 어떤 주소를 어느 MAC 주소에 임대했는지 알고 ARP로 그것을 지킨다. VPN 서버는 자기 풀이 있고 그 임대에 대해 아무것도 모른다. 둘 다 틀리지 않았다. 그저 서로 소개된 적이 없을 뿐이다.

VPN 서버가 LAN 풀에서 내주는 주소는 이미 프린터의 것일 수 있다. 이제 두 장치가 같은 프리픽스에서 한 주소를 주장하고, 스위치의 포워딩 테이블이 어느 쪽이 응답할지 정한다.

사람들이 가장 먼저 만나는 고장이 이것이다: 성공적으로 연결된 뒤 엉뚱한 기계에 도달하거나, 맞는 기계에 간헐적으로 도달하는 클라이언트다.

라우터가 VPN 주소를 나눠주지 않는 이유

DHCP 탐색은 브로드캐스트이고, 브로드캐스트는 라우팅 경계에서 멈춘다. 설계가 터널을 브리지하지 않거나 권한이 일치하는 DHCP 릴레이를 돌리지 않으면, 클라이언트의 요청은 LAN 서버에 결코 닿지 않는다.

그래서 VPN 서버가 주소를 직접 할당한다: 서버 구성 안의 풀, WireGuard 설정에서 피어마다 주는 주소, 또는 IKEv2 배포에서 인증 계층이 밀어 넣는 주소다. 이런 메커니즘은 LAN 임대 데이터베이스와 무관하며, 바로 그래서 자기만의 범위가 필요하다.

같은 논리로 DHCP 범위를 바꿔도 주소를 한 번도 받지 못하는 VPN 클라이언트는 고쳐지지 않는다. 클라이언트는 LAN 서버에 묻지 않고, 범위를 어떻게 편집해도 묻게 만들 수 없다.

겹침은 느린 네트워크가 아니라 충돌로 나타난다

지원되는 설계 없이 프리픽스를 공유하는 두 네트워크는 이중 소유와 다른 문제이며, 자주 혼동된다. VPN 풀이 별도 프리픽스라면 겹침은 경로가 트래픽을 잘못된 쪽으로 보낼 때만 문제가 된다. 풀이 LAN 프리픽스 안에 있으면 충돌은 즉각적이고 국지적이다.

실제로는 잘못된 장치에서 오는 ARP 응답, 중간에 재설정되는 연결, 자기 주소를 남이 주장하는 클라이언트를 본다. 어느 것도 라우팅 문제처럼 보이지 않아서 고침이 잘못된 계층에 적용된다. 중복 임대는 확인하기 쉽고 함께 살기 번거롭다. 재부팅도 견딘다. 두 할당자가 계속 같은 주소를 고집하기 때문이다.

반환 경로는 별개의 문제다

깨끗하고 별개의 풀이 있어도 LAN 호스트는 클라이언트에 어떻게 답할지 알아야 한다. 그들의 기본 게이트웨이는 라우터이고, 라우터에는 풀을 위한 VPN 서버를 가리키는 경로가 필요하다. 설계가 대신 클라이언트 트래픽을 변환하지 않는 한 그렇다.

무엇이든 바꾸기 전에 경로를 양방향으로 읽어라. 게이트웨이에서는 커널이 클라이언트 주소에 어느 인터페이스를 쓸지 묻고, 클라이언트에서는 LAN 주소에 어느 경로를 쓰는지 물어라.

이 명령들은 게이트웨이에서의 전달 결정과 중복을 드러내는 이웃 항목을 보여준다:

ip -4 route get 10.8.0.5
ip neigh show dev br-lan | grep 10.8
ip -4 route get 192.168.50.20

첫 명령이 터널 인터페이스로 답하면 반환 경로가 있다. LAN 인터페이스로 답하면 라우터는 클라이언트가 선로 위에 있다고 믿고 그를 위해 ARP를 시도할 것이다.

브리지 설계도 존재하지만 선택해야 한다

터널을 LAN으로 브리지하는 것은 실제 설계이며, 클라이언트가 브로드캐스트를 받아야 하거나 하나의 세그먼트를 가정하는 프로토콜이 그들을 발견해야 할 때 쓴다. 서버가 그 브리지 동작과 그에 따르는 주소 처리를 가져야 한다.

통하지 않는 것은 번호를 복사해 결과를 흉내 내는 것이다. 브리지 없는 공유 풀은 발견 없이 충돌만 준다. 두 배치 중 최악이다.

애플리케이션이 정말 세그먼트를 필요로 하지 않는 한 별도 풀로 세 번째 계층을 고르고, 풀을 문서화해 다음 관리자가 정돈을 이유로 DHCP 범위를 재사용하지 않게 하라.