Ping zum IPv6-Tunnelpeer schlägt fehl? Prüfen Sie die ::-Adresse

Ein Ende Ihres IPv6-Tunnels pingt das andere, und nur eine Richtung antwortet überhaupt. Das Interface ist oben, die Route sieht richtig aus, und nichts im Protokoll erklärt es. Die Adresse, die Sie vergeben haben, ist die Subnet-Router-Anycast-Adresse, die gar keine Hostadresse ist, und auf einer Verbindung mit zwei Endpunkten hat sie genau ein Zustellziel: den Absender. Kein Timeout-Wert repariert das, weil die Adresse nicht tut, was Sie glauben.

Das Symptom, das auf die Adresse zeigt

Jeder Host auf der Verbindung antwortet außer dem, dessen Interface-Identifikator lauter Nullen ist. Ein Paket an diese Form wird per Definition an einen Router im Subnetz zugestellt, also kommt es auf einem Punkt-zu-Punkt-Tunnel zu der Maschine zurück, die es gesendet hat. Vom fernen Ende liest sich das als unerreichbarer Peer; vom nahen Ende als Stille. Tauschen Sie einen anderen Identifikator aus demselben Präfix ein, und das Symptom verschwindet ohne jede andere Änderung, und das ist die Bestätigung, die Sie vor dem Anfassen von Routen einholen sollten.

Der Identifikator aus lauter Nullen ist als Anycast reserviert

RFC 4291 behält den Interface-Identifikator aus lauter Nullen als Subnet-Router-Anycast-Adresse, daher enthält ein /64 wie 2001:db8:4a::/64 keinen nutzbaren Host unter 2001:db8:4a::. Die Reservierung verdient ihren Platz: Routerankündigungen und Nachbarschaftserkennung adressieren diese Form, und ein Router antwortet für das Präfix, das er bedient. Diesen Wert einem Tunnelendpunkt zuzuweisen gibt einem Blatt eine Routerrolle, und deshalb kommt nichts zurück. Jeder andere Identifikator im Präfix funktioniert als Host, die Reparatur ist also meistens eine Ziffer.

Behandeln Sie die Reservierung als eine Rolle, die Sie von einem Tunnelendpunkt aus nicht besetzen dürfen, nicht als eine Eigenheit, die man umroutet.

Vergeben Sie Hostadressen und routen Sie das Präfix

Wählen Sie ::1 und ::2 für die beiden Enden, fügen Sie eine mit ip -6 addr add 2001:db8:4a::2/64 dev tun0 hinzu, und routen Sie dann das entfernte Präfix, statt zu versuchen, es zu adressieren. Eine Route für 2001:db8:4a::/64 durch den Tunnel macht die ferne Seite erreichbar; die Adresse allein macht nur das lokale Interface konfiguriert.

Für einen vollen Tunnel gibt es einen dritten Schritt, eine Standardroute für globales Unicast durch das Gerät, was das IPv6-Äquivalent dazu ist, alles in den Tunnel zu schicken. Lassen Sie ihn weg, und IPv6 nutzt weiter die physische Verbindung, während IPv4 im Tunnel reist, sodass der Host genau den Verkehr leakt, von dem Sie glaubten, er sei abgedeckt. Bestätigen Sie mit ip -6 route get 2001:4860:4860::8888 und lesen Sie, welches Gerät genannt wird, statt die Antwort anzunehmen.

Multicast wird vor dem Routing abgelehnt

Android validiert Adressen und Routen für VpnService.Builder über LinkAddress, und dieser Konstruktor lehnt Multicast rundheraus ab. Geben Sie ihm ein Multicast-Präfix als Route, und das Ergebnis ist ein Fehler wegen schlechter LinkAddress-Parameter statt einer Route, was eine Validierungsantwort und keine Netzwerkantwort ist. Die Ablehnung passt zum Medium: ein Punkt-zu-Punkt-tun-Gerät hat kein Multicast auf der Sicherungsschicht, also hat eine Gruppenroute darauf kein Zustellmodell zu installieren. Gruppenadressen werden vom Stack selbst erzeugt und verbraucht, statt von Hand konfiguriert zu werden.

IPv6-all-nodes- und solicited-node-Adressen fallen unter dieselbe Regel. Das Interface trägt sie, weil der Stack sie dort hingelegt hat, nicht weil eine Richtlinie sie beabsichtigte.

Was ein Tunnel stattdessen tragen kann

Multicast-Erkennung über einen Tunnel zu bewegen braucht eine Schicht, die Gruppenmitgliedschaft versteht: eine TAP-Brücke, die ein Ethernet-Segment bereitstellt, ein Relay auf Anwendungsebene oder ein Routingprotokoll, dem ausdrücklich gesagt wird, an welche Peers repliziert werden soll. Nichts davon existiert im VpnService-Modell, wo die Anwendung Pakete liest und schreibt und keinen Aufruf hat, der für den Tunnel einer Gruppe beitritt. Entweder fügen Sie die Komponente hinzu, die Gruppen versteht, oder streichen Sie die Anforderung aus dem Design.

Unicast dagegen braucht nichts zusätzlich zu den Adressen und Routen oben, weshalb von Tunneln normalerweise erwartet wird, dass sie es tragen, und sie dann beschuldigt werden, wenn ein Erkennungsprotokoll versagt.

Drei Prüfungen, bevor Sie irgendetwas vergeben

Bestätigen Sie, dass die Adresse nicht die Anycast-Form ist, bestätigen Sie, dass sie kein Multicast ist, und bestätigen Sie, dass das Präfix geroutet und nicht nur dem Gerät zugewiesen ist. Senden Sie dann Ihren Test an ein Ziel, das ein echter Host ist, denn ein Ping auf die Anycast-Adresse misst den Absender und sagt nichts über den Pfad. Halten Sie diese drei Prüfungen im Änderungsdatensatz fest, damit die nächste Bereitstellung sie nicht neu entdeckt.

Eine Route, die die Plattform nie installiert hat, lässt sich nicht durch längeres Warten debuggen, und eine Adresse, die nie ein Host war, lässt sich nicht durch einen besseren Ping reparieren.