원격 VPN 클라이언트가 접속하고, LAN 서버가 응답하며, 그 응답은 평범한 인터넷 라우터를 지나 밖으로 나가 그곳에서 죽습니다. 서버 하나라면 정적 경로로 고칠 수 있지만, 서버 서브넷 전체라면 이미 네트워크 구성을 받는 곳에서 다루는 편이 낫습니다. DHCPv4 옵션 121은 바로 그런 목적지 경로를 배포하며, 기본 경로를 잊는 순간 사람들이 흔히 틀리는 부분이 이것입니다. 증상은 단방향 트래픽입니다. 요청은 도착하는데 응답은 사라집니다.

먼저 세 주소의 이름을 붙이십시오

구체적인 LAN을 하나 잡아 봅시다. 192.168.50.0/24 이 있고, 평범한 기본 라우터가 192.168.50.1, 별도의 VPN 게이트웨이가 192.168.50.2 입니다. 인증된 원격 클라이언트는 10.90.0.0/24 을 차지합니다.

참여하는 모든 호스트에 필요한 경로는 10.90.0.0/24 via 192.168.50.2 입니다. 목적지는 클라이언트 풀이고, 다음 홉은 게이트웨이의 터널 주소가 아니라 LAN 주소입니다.

클래스 없는 정적 경로로 인코딩하십시오

옵션 121은 프리픽스와 다음 홉의 쌍을 실어 나르며, RFC 3442 가 인코딩과 그에 따르는 클라이언트 동작을 모두 정의합니다. 이 예시 LAN만 서비스하는 기존 dnsmasq 인스턴스라면 설정의 형태는 다음과 같습니다.

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

이것은 조각이지 새로운 DHCP 서비스가 아닙니다. 여러 세그먼트를 다루는 서버에서는 이미 쓰고 있는 태그나 네트워크 정책으로 옵션의 범위를 좁히십시오. 되돌리는 일은 재부팅이 아니라 임대 갱신을 한 번 더 하는 것이므로, 이전 설정을 손에 두십시오.

기본 경로를 잃지 마십시오

여기가 함정입니다. 옵션 121을 받은 클라이언트는 일반 Router 옵션을 무시해야 하므로, VPN 풀 경로만 알리면 그 호스트가 기본 경로를 아예 갖지 못할 수 있습니다. 기계는 여전히 설정된 것처럼 보이면서 조용히 인터넷을 잃습니다. 사용자들은 모든 인터페이스가 살아 있는데 네트워크가 죽었다고 표현합니다.

위 조각이 그러하듯 의도한 기본 경로를 같은 목록에 넣으십시오. 클래스 없는 경로를 구현하지 않는 클라이언트를 위해 일반 Router 옵션도 그대로 두십시오. 누구에게 무엇을 보낼지는 서버 자체의 옵션 처리가 결정합니다.

클라이언트가 무엇을 받아들일지 확인하십시오

주소를 수동으로 설정한 호스트는 임대를 요청하지 않으므로 이것을 절대 받아들이지 않습니다. 클라이언트 지원도 제각각이므로 모든 장치가 옵션 121을 지킨다고 가정하지 말고 실제로 쓰는 운영체제에서 시험하십시오. 그 서버의 주인에게 어느 것이 정적 주소인지 확인하십시오. 그런 호스트는 자체 경로 항목이 필요하며, 없으면 그냥 참여하지 않습니다.

관리형 DHCP 서비스도 한계입니다. 일부 클라우드 네트워크는 관리자가 임의의 옵션을 게시하지 못하게 하며, 같은 세그먼트에 경쟁 DHCP 서버가 있는 것은 옵션이 전혀 없는 것보다 나쁩니다.

임대를 확인하고, 그다음 조회를 확인하십시오

DHCP 담당자에게 변경을 적용하게 한 뒤 클라이언트에서 임대를 갱신하십시오. 기존 임대는 갱신될 때까지 옛 설정을 유지하므로 즉시 결과가 나온다고 보장할 수 없습니다.

Linux 클라이언트에서 실제 경로를 읽고 두 항목을 모두 확인하십시오.

ip -4 route
ip -4 route get 10.90.0.23

문맥 조회는 풀 경로를 192.168.50.2 을 통해, 기본 경로를 192.168.50.1 을 통해 보여 주어야 합니다. 기본 경로가 없다면 위의 함정을 재현한 것입니다.

그다음 실제 교환을 시험하십시오

경로 배포가 경로의 전부는 아닙니다. 별도 게이트웨이에는 여전히 포워딩, 원격 피어 소유권, 서버를 허용하는 접근 정책이 필요하고, DHCP는 아무도 인증하지 않습니다.

마지막으로 철거 계획을 두십시오. 학습된 정적 경로는 VPN이 끊겨도 스스로 철회되지 않으므로, 낡은 다음 홉은 터널이 사라진 한참 뒤에도 그 프리픽스를 블랙홀로 만들 수 있습니다.

관련 글