So testen Sie IPv6 über ein VPN mit Ihrer eigenen Ressource

Eine öffentliche IP-Prüfseite beantwortet eine Frage, und meist nicht die, die Sie gestellt haben. Sie nennt die Ausgangsadresse, die die Seite gesehen hat; sie sagt nicht, ob die IPv6-Route durch den Tunnel funktioniert, ob der Host IPv6 bevorzugt hat oder zurückgefallen ist, oder ob eine ausgeschlossene Anwendung einen anderen Pfad genommen hat. Eine autorisierte Ressource, die Sie kontrollieren, beantwortet die engere Frage ordentlich, weil Sie beide Enden sehen. Das Runbook unten handelt davon, zu einer belastbaren Schlussfolgerung zu kommen, nicht von einem grünen Ergebnis.

Schritt 1: Legen Sie fest, welchen IPv6-Pfad Sie testen

Sagen Sie es in einem Satz. Eine Anfrage an die eigene IPv6-Adresse des Tunnelservers testet den Tunnel; eine Anfrage an einen Host jenseits des Ausgangs testet den IPv6-Ausgang des Ausgangs; eine Anfrage an eine private IPv6-Adresse testet eine interne Route.

Das sind drei verschiedene Aussagen, und eine einzelne erfolgreiche Anfrage kann nicht alle stützen. Wählen Sie die, die für die anstehende Entscheidung zählt, und schreiben Sie sie auf, bevor Sie etwas ausführen. Geht es darum, ob IPv6 am Tunnel vorbei leckt, betrifft die Frage die Routenwahl des Hosts, nicht die Erreichbarkeit des Ausgangs. Geht es darum, ob die Gegenseite einen internen Dienst erreicht, ist der Ausgang unerheblich.

Schritt 2: Bestätigen Sie, dass der Host diese Route wählt

ip -6 route get 2001:db8:1::10 gibt die Route, die Quelladresse und die Schnittstelle aus, die der Kernel verwenden würde, und genau davon hängt der Rest des Tests ab.

Eine vorhandene Schnittstelle ist nicht dasselbe wie eine gewählte. Dual-Stack-Hosts haben eine Prioritätstabelle, und /etc/gai.conf unter Linux kann ändern, welche Familie für einen Namen gewinnt, der sich auf beide auflöst.

Schritt 3: Verwenden Sie ein legitimes Ziel und einen legitimen Namen

Wenn Sie HTTPS testen, nutzen Sie den Hostnamen, für den das Zertifikat ausgestellt wurde, und lassen Sie die Prüfung an; auf eine literale Adresse zu wechseln, damit der Test besteht, schaltet genau die Prüfung ab, die belegt, dass Sie den vorgesehenen Host erreicht haben. Ein Diagnosedienst, den Sie kontrollieren und der unter einem bekannten Namen mit gültigem Zertifikat antwortet, ist das sauberste Ziel. Er liefert Ihnen außerdem eine serverseitige Logzeile zum Abgleichen, die ein Prüfer von dritter Seite nie liefern wird.

Führen Sie die Anfrage in einer Form aus, die die verwendete Adresse zeigt: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/. Die Option -6 erzwingt die Familie, und so trennen Sie IPv6 funktioniert nicht von IPv6 wurde nicht bevorzugt.

Für eine reine Erreichbarkeitsprüfung, bei der ICMPv6 erlaubt ist, genügt ping -6 -c 3 2001:db8:1::10. Sie belegt den Pfad und nichts darüber hinaus.

Schritt 4: Gleichen Sie beide Enden ab

Wenn Sie Zugriff auf beide Enden haben, führen Sie tcpdump -ni any ip6 and host 2001:db8:1::10 auf dem Client und das Gegenstück auf der Ressource aus, mit Zeitstempeln, und bestätigen Sie, dass derselbe Fluss an beiden Stellen erscheint. Das macht aus einem plausiblen Ergebnis einen Beleg: die Sicht des Clients allein kann eine Antwort der Ressource nicht von einer Antwort von etwas dazwischen unterscheiden. Halten Sie die Aufzeichnung eng auf das eine Ziel begrenzt, damit die Ausgabe lesbar bleibt und keine fremde Sitzung in der Datei landet.

Wiederholen Sie den Test nach einem Wiederverbinden, wenn die Frage ist, ob die Richtlinie einen Neustart übersteht. Zur Verbindungszeit einmal angewandter Routen- und Firewallzustand kann sich von erneut angewandtem Zustand unterscheiden, und der Unterschied zeigt sich erst bei der zweiten Verbindung.

Testen Sie den Fehlerfall getrennt, wenn Sie ihn brauchen. Ein Tunnel, der IPv6 blockiert, wenn er wegfällt, und einer, der es lecken lässt, sind verschiedene Entwürfe, und nur einer von beiden lässt sich durch eine erfolgreiche Anfrage bestätigen.

Schritt 5: Notieren Sie, was der Test nicht belegt hat

Schritt fünf ist das Notieren dessen, was der Test nicht belegt hat, und dieser Teil wird gern weggelassen. Ein erfolgreicher Test gegen einen privaten Endpunkt belegt keinen öffentlichen IPv6-Ausgang, belegt kein DNS-Verhalten und deckt keine Anwendungen ab, die Sie vom Tunnel ausgeschlossen haben. Jedes davon braucht sein eigenes Ziel und seine eigene Beobachtung. Eine Notiz, dass IPv6 nach einer Anfrage an einen Host funktioniert, ist kein Befund; sie ist eine Vermutung mit Zeitstempel.

Der Datensatz, der sich zu behalten lohnt, ist kurz: das Ziel, der Name, die vom Host gewählte Quelladresse, die beobachtete Gegenstelle und die Uhrzeit. RFC 7359 erörtert, wie man prüft, dass ein relevanter IPv6-Pfad tatsächlich nutzbar ist, und das ist der Standard, dem sich dieses Runbook mit einfacheren Werkzeugen nähert. Wenn die Schlussfolgerung einen öffentlichen Prüfer braucht, um wahr zu sein, war der Test nicht spezifisch genug.