Warum die IPv6-Nachbarerkennung über ein geroutetes VPN scheitert

Die IPv6-Nachbarerkennung gehört zu einem Link, und ein gerouteter Tunnel ist eine Grenze zwischen zwei Links. Dieser eine Satz erklärt fast jeden Bericht über einen entfernten Host, der auf seine Adresse antwortet und sonst nicht gefunden werden kann. Prüfe den Geltungsbereich der Adresse, die du testest, bevor du den Tunnel prüfst. Eine linklokale Adresse ist nur auf ihrem eigenen Link sinnvoll, und eine Multicast-Gruppe für den angefragten Knoten ist genauso begrenzt. Keine von beiden überschreitet einen Router, weshalb ein Ping an eine globale Adresse gelingen kann, während die Erkennung für denselben Host scheitert.

Der Geltungsbereich kommt vor der Konfiguration

Nachbarschaftsanfrage und Nachbarankündigung tragen ein Hop-Limit von 255 und werden konstruktionsbedingt nicht weitergeleitet. Der Router zwischen deinem Tunnel und dem entfernten LAN leitet IPv6-Pakete weiter und übermittelt keine Nachbarschaftsnachrichten in seinem Namen. So enthält der Nachbar-Cache an der Tunnelschnittstelle den Peer und wenig mehr, was korrektes Verhalten und kein zu behebender Defekt ist.

Eine linklokale Adresse wie ein fe80::-Eintrag ist ebenfalls zonenbezogen, und derselbe Text kann auf einem anderen Link einen anderen Host bezeichnen. Eine solche Adresse von der anderen Seite des Tunnels zu testen beweist nichts außer der Mehrdeutigkeit der Adresse.

Die Falle ist die On-Link-Annahme

Ein Host, der glaubt, ein Präfix sei on-link, sendet eine Nachbarschaftsanfrage, statt das Paket an seinen Router zu geben, und das schließt ein /64 ein, das an einen entfernten Standort geroutet wird. Kommt ein solches Präfix als on-link an, fragt der Host den lokalen Link nach einem Host, der woanders lebt, und nichts antwortet. Route etwas Kleineres zum entfernten Host, oder beende das Präfix an dem Router, der dafür antworten wird.

Ein /128 für einen einzelnen Dienst ist die am wenigsten überraschende Lösung, und sie beseitigt die Mehrdeutigkeit vollständig. Die Spezifikation der Nachbarerkennung beschreibt den Nachrichtensatz und das On-Link-Flag, das darüber entscheidet.

Bridging ändert die Regeln absichtlich

Wenn der Tunnel Ethernet-Frames trägt, werden das entfernte und das lokale Segment zu einem Link, Multicast erreicht beide Seiten, und die Nachbarerkennung verhält sich wie auf einem Switch. Die Folgen kommen mit: Broadcast- und Multicast-Flooding, Duplikatadresserkennung über die Brücke und Router-Ankündigungen, die in ein Segment lecken, das sie nicht sehen sollte. Die Fehlerdomäne umfasst nun auch zwei Standorte. Nichts davon spricht gegen Bridging, und jeder Punkt ist ein Grund, eine Brücke bewusst und nicht nebenbei zu bauen.

Ein Profil von TUN auf TAP umzustellen, damit Erkennung erscheint, ist die falsche Reihenfolge. Server, Client und Adressplan müssen übereinstimmen, und mobile Clients bieten überhaupt keine TAP-Schnittstelle an, sodass ein solches Design auf einem Laptop funktioniert und auf einem Telefon scheitert. Nachbar-Proxys und -Relays sind eigene Mechanismen mit eigenen Anforderungen und gehören zur dokumentierten Regelung des Netzwerkadministrators, nicht zu den Einstellungen einer App.

Teste mit der Adresse, die die Anwendung nutzt

Bestätige die Route mit ip -6 route get, prüfe den Nachbareintrag mit ip -6 neigh und bestätige dann den Dienst über den gerouteten Pfad. DNS und der Rückweg sind getrennte Prüfungen, und ein gesunder Nachbareintrag beweist keine von beiden.

Besteht die Anwendung auf einem linklokalen oder erkennungsbasierten Ziel, ist das ein Designgespräch und keine Tuning-Übung, denn keine Client-Einstellung macht einen linkgebundenen Mechanismus über einen Router hinweg funktionsfähig.

Schreib auf, welches Design du hast

Halte vor dem Vorfall fest, ob geroutet oder gebrückt, denn die beiden Bereitstellungen beantworten diese Fragen unterschiedlich, und ein Bereitschaftsingenieur sollte es nicht aus einem Profil ableiten müssen.

Den Nachrichtensatz einmal zu lesen nimmt die Versuchung, eine Link-Scope-Eigenschaft als VPN-Fehler zu erklären, und das ist die teuerste Fehldiagnose in diesem Bereich.