라우팅된 VPN에서 IPv6 이웃 탐색이 실패하는 이유

IPv6 이웃 탐색은 하나의 링크에 속하고, 라우팅된 터널은 두 링크 사이의 경계입니다. 그 한 문장이 주소로는 응답하지만 다른 어떤 방법으로도 찾을 수 없는 원격 호스트에 대한 거의 모든 보고를 설명합니다. 터널을 확인하기 전에 테스트하는 주소의 범위를 확인하세요. 링크 로컬 주소는 자기 링크에서만 의미가 있고, 요청된 노드의 멀티캐스트 그룹도 같은 방식으로 한정됩니다. 둘 다 라우터를 넘지 않으므로 전역 주소로의 ping은 성공해도 같은 호스트에 대한 탐색은 실패합니다.

범위가 구성보다 먼저다

이웃 요청과 이웃 알림은 홉 제한 255를 가지며 설계상 전달되지 않습니다. 터널과 원격 LAN 사이의 라우터는 IPv6 패킷을 전달하지만 그 대신 이웃 메시지를 중계하지는 않습니다. 따라서 터널 인터페이스의 이웃 캐시에는 상대와 약간의 정보만 들어 있으며, 이는 수정해야 할 결함이 아니라 올바른 동작입니다.

fe80:: 같은 링크 로컬 주소도 영역으로 한정되며, 같은 표기가 다른 링크에서는 다른 호스트를 가리킬 수 있습니다. 터널 반대편에서 시험해 봐도 주소가 모호하다는 것 외에는 아무것도 증명하지 못합니다.

함정은 접두사가 링크에 있다는 가정

접두사가 링크에 있다고 믿는 호스트는 패킷을 라우터에 넘기지 않고 이웃 요청을 보내며, 원격 사이트로 라우팅된 /64도 여기에 해당합니다. 그런 접두사가 링크에 있는 것으로 도착하면 호스트는 로컬 링크에 다른 곳에 사는 호스트를 물어보고, 아무도 응답하지 않습니다. 원격 호스트에는 더 작은 범위를 라우팅하거나, 그 대신 응답할 라우터에서 접두사를 종료하세요.

단일 서비스에 /128을 쓰는 것이 가장 놀랍지 않은 구성이며 모호성을 완전히 없앱니다. 이웃 탐색 명세는 메시지 집합과 이를 결정하는 링크상 플래그를 설명합니다.

브리지는 의도적으로 규칙을 바꾼다

터널이 Ethernet 프레임을 실으면 원격과 로컬 세그먼트가 하나의 링크가 되고, 멀티캐스트가 양쪽에 도달하며, 이웃 탐색은 스위치에서처럼 동작합니다. 그에 따라 브로드캐스트와 멀티캐스트 플러딩, 브리지를 넘는 중복 주소 검출, 보아서는 안 되는 세그먼트로 새는 라우터 알림이라는 결과가 따릅니다. 장애 도메인도 이제 두 사이트에 걸칩니다. 어느 것도 브리지에 반대하는 논거가 아니며, 각 항목은 우연이 아니라 의도적으로 브리지해야 하는 이유입니다.

탐색을 나타나게 하려고 프로필을 TUN에서 TAP으로 바꾸는 것은 잘못된 작업 순서입니다. 서버, 클라이언트, 주소 계획이 모두 합의해야 하고, 모바일 클라이언트는 TAP 인터페이스를 아예 제공하지 않으므로 그런 설계는 노트북에서는 동작하고 휴대폰에서는 실패합니다. 이웃 프록시와 릴레이는 자체 요구 사항이 있는 별개의 메커니즘이며, 앱 설정이 아니라 네트워크 관리자의 문서화된 구성에 속합니다.

애플리케이션이 쓰는 주소로 시험하라

ip -6 route get으로 경로를 확인하고 ip -6 neigh로 이웃 항목을 살펴본 다음 라우팅된 경로로 서비스를 확인하세요. DNS와 반환 경로는 별개의 확인이며, 건전한 이웃 항목은 둘 중 어느 것도 증명하지 않습니다.

애플리케이션이 링크 로컬 또는 탐색 기반 목적지를 고집한다면 그것은 튜닝 연습이 아니라 설계 대화이므로 어떤 클라이언트 설정도 링크로 한정된 메커니즘을 라우터 너머에서 동작하게 만들지 못합니다.

어떤 설계인지 적어 두라

두 배포가 이 질문에 다르게 답하고 당직 엔지니어가 프로필에서 추론하게 해서는 안 되므로, 사고 전에 라우팅인지 브리지인지 기록해 두세요.

메시지 집합을 한 번 읽으면 링크 범위 속성을 VPN 버그로 설명하려는 유혹이 사라지며, 이는 이 분야에서 가장 값비싼 오진입니다.