VPN 너머의 DHCP: 브로드캐스트를 브리지할까, 릴레이할까

터널 반대편의 새 노트북만 주소를 받지 못하는데, 같은 노트북이 본사에서는 잘 동작한다. 흔한 첫 추측은 터널이 DHCP를 막고 있다는 것이다. 그러나 실제로는 브로드캐스트에 경로가 없었던 경우가 더 많다. 설정되지 않은 클라이언트는 255.255.255.255로 보내고, 일반 IP 라우터는 그 패킷을 전달하지 않는다. 터널은 라우팅되는 터널이 하는 일을 그대로 하고 있을 뿐이다.

이를 바꿀 수 있는 설계는 두 가지이며, 서로 같지 않다. 하나는 브로드캐스트를 실어 나르고, 다른 하나는 요청을 중계한다.

브로드캐스트는 라우터를 건너지 않는다

주소가 없는 DHCPv4 클라이언트는 0.0.0.0에서 제한 브로드캐스트 주소로 UDP 67번과 68번 포트를 통해 보낸다. 이 패킷은 설계상 자신의 링크에 머문다. 이를 전달하는 라우터는 자신이 서비스하는 모든 세그먼트를 범람시키게 된다.

따라서 라우팅되는 사이트 간 터널은 릴레이를 서버에 연결한다. 클라이언트의 브로드캐스트 도메인을 넓히는 것이 아니며, 어떤 방화벽 규칙으로도 그렇게 만들 수 없다.

브리지한 터널이 실제로 넓히는 것

의도적으로 브리지한 VPN은 지원되는 토폴로지 안에서 이더넷 브로드캐스트를 실어 나를 수 있고, 그러면 DHCP가 로컬 트래픽으로 통과할 수 있다. 실제로 가능한 선택이지만 2계층 설계 결정이다. 브로드캐스트와 함께 장애 도메인과 접근 경계까지 넓히는 셈이다.

브리지는 브로드캐스트 폭풍, ARP 스윕, 악성 DHCP 서버가 닿을 수 있는 범위도 바꾼다. 원격 사무실을 같은 스위치에 꽂지 않을 것이라면, 주소를 나눠 주기 위해 터널을 브리지하지 마라. 활성화하기 전에 그 영향 반경을 시험해 보라.

주소를 공급하는 것보다 큰 결정이며, 의식적으로 내려야 한다.

대신 요청을 중계하라

일반적인 답은 클라이언트의 로컬 네트워크에 있는 릴레이다. 릴레이는 브로드캐스트를 받아 유니캐스트 요청으로 바꾸고, 자신의 주소를 게이트웨이 주소 필드에 넣는다. 서버는 그 릴레이 주소로 응답한다.

예시로 든 원격 사무실에서는 릴레이가 사무실 LAN에 있고 서버에는 사이트 VPN으로 도달한다. 그 사무실에 대한 범위, 릴레이와 서버의 신원, 완전한 반환 경로를 구성하라. 터널로 UDP 67을 허용한다고 해서 서버가 어떤 풀을 써야 하는지 알게 되지는 않는다.

전달은 하지만 응답을 받지 못하는 릴레이는 대개 반환 경로 문제다. 범위를 바꾸기 전에 릴레이 주소로 돌아가는 경로를 확인하라.

DHCP를 ARP와 터널 주소 지정에서 분리하라

DHCP는 UDP/IP 위에서 동작한다. 이더넷에서는 호스트가 ARP를 사용해 후보 주소가 이미 사용 중인지 확인할 수도 있다. 그 충돌 확인은 별개의 링크 로컬 동작이며, DHCP 메시지의 전송 수단이 아니다. DHCP가 본질적으로 ARP라고 말하는 것은 틀렸고, 둘이 전혀 관련 없다고 말하는 것은 너무 넓다.

VPN 클라이언트는 DHCP 브로드캐스트 대신 VPN 프로토콜이나 서버 자체의 풀에서 터널 주소를 받을 수도 있다. 이름에 DHCP가 들어간 옵션은 중계된 DHCP 패킷이 아니라 밀어 넣은 클라이언트 설정을 설명할 수 있다. DHCP가 관여한다고 가정하기 전에 서버의 풀을 확인하라.

받는 네트워크, 할당 소유자, 범위, 릴레이 존재 여부, 장애 시 예상 동작을 기록하라. 그런 다음 그 모델로 새 임대와 갱신을 시험하라. 두 사이트가 같은 관리되지 않는 풀을 서비스할 수 있다면, 첫 번째로 이동하는 노트북을 기다리는 충돌이 있는 것이다.