LAN 주소가 있는 VPN 클라이언트는 LAN에 있지 않다

클라이언트는 연결되어 10.50.0.200을 받지만, 두 번호가 같은 /24에 있음에도 10.50.0.20의 서버에 도달하지 못한다. 이 구성 뒤에 있는 믿음은 LAN 프리픽스의 주소가 클라이언트를 LAN의 일부로 만든다는 것이다. 그렇지 않다. 클라이언트는 점대점 링크에 있고, 서버는 목적지를 로컬로 간주하며, 빠진 조각은 아무도 보내지 않는 이웃 응답이다.

신화: 같은 프리픽스는 같은 세그먼트를 뜻한다

주소 프리픽스는 호스트가 어떤 목적지에 직접 도달할 수 있고 어떤 목적지에 라우터가 필요한지 알려 준다. 목적지가 물리적으로 어떻게 연결되어 있는지는 알려 주지 않으며, 목적지가 링크 계층 요청에 응답할 수 있다고 보장하지도 않는다. 이는 서로 다른 질문이고, 호스트의 서로 다른 표가 답한다. 마스크는 첫 번째에, 이웃 표는 두 번째에 답하며, VPN 쪽에서 통제할 수 있는 것은 첫 번째뿐이다.

서버가 10.50.0.200으로 보낼 때, 목적지를 자기 마스크와 비교해 주소가 on-link라고 판단하고, 그 주소를 소유한 하드웨어 주소를 로컬 세그먼트에 묻는다. 그 요청은 Ethernet 인터페이스로 나가지만, VPN 클라이언트는 그것을 들을 곳에 없다.

클라이언트의 구성으로는 자기 쪽에서 이것을 고칠 수 없다. 응답 경로는 LAN에 있는 장치가 클라이언트를 대신해 응답하는지, 또는 클라이언트가 서버가 로컬로 보지 않는 주소를 갖는지에 달려 있다.

로컬 호스트가 주소로 실제로 하는 일

동작은 관찰하기 쉬우며 무엇이든 바꾸기 전에 관찰할 가치가 있다. LAN 호스트가 클라이언트에 도달하려 한 뒤 이웃 표를 보라. 불완전하거나 실패한 항목이 한 줄로 된 진단 전체다. 그 줄은 결함이 세그먼트에 국한된 것이지 터널 어딘가가 아니라는 것도 알려 준다.

ip neigh show 10.50.0.200
ip route get 10.50.0.200
arping -I eth0 -c 3 10.50.0.200

경로 조회는 Ethernet 인터페이스를 통해 목적지를 on-link로 보고할 것이며, 바로 그것이 문제다. VPN 세션이 살아 있는 동안 이웃 항목이 불완전하게 남는다면, 빠진 조각이 라우팅이나 방화벽 정책이 아니라 링크 계층 해석임을 확인한 것이다.

다른 서브넷의 호스트에서 같은 점검을 하고 비교하라. 라우터를 통해 클라이언트에 도달하는 호스트는 이웃 항목이 전혀 필요 없으며, 그 차이가 축소판 설계 결정이다.

proxy ARP가 다음 홉을 제공하는 방법

proxy ARP는 게이트웨이가 다른 인터페이스로 도달할 수 있는 목적지를 대신해 링크 계층 요청에 응답하게 한다. LAN 호스트는 하드웨어 주소를 받고, 프레임을 게이트웨이로 보내며, 게이트웨이는 패킷을 VPN 세션으로 전달한다. 호스트 관점에서는 클라이언트가 그저 게이트웨이 뒤에 있는 것처럼 보인다. 클라이언트 구성은 아무것도 바뀌지 않는다.

MikroTik의 RouterOS ARP 문서는 연결된 LAN의 주소 공간을 빌리는 다이얼인 클라이언트에 대한 이런 사용을 설명한다. 이 메커니즘은 이웃 해석의 수리이며, 게이트웨이가 정말로 두 경로 모두에 있기 때문에 작동한다.

이것은 클라이언트를 LAN으로 브리지하는 것과 같지 않다. 게이트웨이는 여전히 패킷을 올바른 활성 세션으로 전달해야 하고, 라우팅과 방화벽 정책은 여전히 서비스를 허용해야 한다. proxy ARP는 이웃 요청에 누가 응답하는지를 바꿀 뿐, 누가 말할 수 있는지는 바꾸지 않는다.

플랫폼의 모드 이름을 주의 깊게 읽어라. RouterOS는 proxy-arp와 local-proxy-arp를 구분하며, 두 번째는 같은 인터페이스로 들어오고 나가는 트래픽을 처리한다. 둘은 서로 바꿔 쓸 수 있는 철자가 아니며, 둘 다 무분별하게 켜는 것은 지름길이 아니다.

proxy ARP가 주지 않는 것

broadcast나 multicast 검색을 제공하지 않는다. broadcast로 서비스를 찾아야 하는 클라이언트는 여전히 실패한다. 게이트웨이가 unicast를 세션으로 전달하고 클라이언트를 LAN의 broadcast 도메인 구성원으로 만들지 않기 때문이다. broadcast에 의존하는 검색 프로토콜은 빌린 주소 설계에서 한 가지에는 되고 다른 것에는 안 된다는 보고의 흔한 원인이다.

주소를 예약하지 않는다. 빌린 번호가 DHCP 풀이나 정적 할당에도 있으면 두 장치가 같은 주소가 될 수 있고, 그 결과 동작은 타이밍에 달려 있다. 성공한 로그인은 예약이 아니다.

그리고 LAN 소유자와 조정할 필요를 없애지 않는다. 주소 계획 소유자를 놀라게 하는 proxy ARP 항목은 조용한 주를 기다리는 지원 사건이다.

별도로 라우팅된 풀과의 비교

대안은 VPN 클라이언트에 자체 프리픽스를 주고 LAN 호스트가 그쪽으로 라우팅하게 하는 것이다. 그러면 서버는 게이트웨이로 off-link 응답을 보내고, 게이트웨이는 프리픽스를 VPN 엔드포인트로 라우팅하며, LAN 세그먼트에서는 이웃 해석이 전혀 필요 없다. 빌린 주소에 proxy 응답을 더한 것보다 움직이는 부품이 적다.

그 설계는 추론하기도 감사하기도 쉽다. 클라이언트 범위가 LAN 범위와 눈에 띄게 분리되어 있기 때문이다. 비용은 경로 하나, 반환 경로, 접근 규칙이며, proxy ARP 설계가 덜 분명한 곳에서 필요로 하는 것과 같은 항목이다.

모델 사이에서 우연이 아니라 의도적으로 선택하라. proxy ARP는 특정 관계 하나를 고치고, 라우팅된 풀은 그 수리가 필요 없게 한다. 어느 것을 골랐고 왜인지 적어 두면, 다음 사람이 실패한 이웃 항목에서 그것을 다시 발견할 필요가 없다.