Welche IPv6-Quelle eine VPN-Anfrage wählt und warum das wichtig ist
Ein Host mit mehreren IPv6-Adressen wählt eine Quelle, bevor die Route nachgeschlagen wird. Prüfen Sie die geordneten Regeln, eine eventuelle Anwendungsbindung und die Rückweg-Politik der Gegenseite.
Sie haben eine VPN-Adresse hinzugefügt und erwartet, dass die Anfrage sie nutzt, aber der Server protokollierte weiterhin das alte Präfix. Am Tunnel ist nichts gescheitert; der Host hat eine Quelladressenwahl getroffen, bevor er die Route überhaupt ansah, die Sie anstarrten. Die IPv6-Quellwahl ist ein eigener geordneter Wettbewerb unter den Kandidatenadressen des Hosts, und das längste passende Präfix ist nur eine Regel nahe dem Ende dieses Wettbewerbs. Das gewünschte Ergebnis zu bekommen heißt zu wissen, welche Regel bereits gewonnen hat. Die Regeln selbst sind langweilig und präzise, und genau deshalb liest man sie der Reihe nach.
Zwei Nachschlagevorgänge, nicht einer
Die Zielwahl bestimmt den nächsten Hop und die ausgehende Schnittstelle. Danach bestimmt die Quellwahl, welche der Host-Adressen im Header erscheint, und die beiden Fragen werden von unterschiedlichen Mechanismen beantwortet, obwohl beide Präfixe verwenden. Ein Host mit einer physischen Adresse, einer temporären Adresse und einer VPN-Adresse hat für jedes Ziel drei Kandidaten, und die Route zum VPN nominiert die dritte nicht automatisch.
Deshalb koexistieren eine korrekte Route und eine falsche Quelle so leicht, und deshalb kann sich dieselbe Anfrage im Browser und bei einer erzwungenen Bindung unterschiedlich verhalten. Behandeln Sie die beiden Nachschlagevorgänge getrennt, bis Sie Belege haben, die sie verbinden.
Lesen Sie die Regeln als geordneten Wettbewerb
RFC 6724 listet die Regeln der Reihe nach auf, und jede bricht nur einen Gleichstand, den die vorherigen hinterlassen haben. Die Präferenz der ausgehenden Schnittstelle und die Label-Übereinstimmung erscheinen lange vor dem Präfixvergleich, eine Adresse auf der Schnittstelle, die die Route nutzt, hat also bereits einen Vorteil gewonnen, den ein besserer Präfixtreffer nicht auslöschen kann. Auch Veraltung und Gültigkeitsbereich wirken mit, und deshalb wird eine veraltete Adresse manchmal nicht mehr gewählt, ohne dass jemand die Richtlinie ändert.
Die praktische Lesart ist, dass Sie über den Gewinner nicht allein aus dem Ziel schließen können. Listen Sie die Kandidaten auf, gehen Sie die Regeln der Reihe nach durch und sehen Sie, wo die Entscheidung tatsächlich gefallen ist.
Beachten Sie außerdem, dass dies die Quellhälfte des Problems ist. Zwei Präfixvergleiche zu vermischen erzeugt Erklärungen, die streng klingen und die falsche Adresse vorhersagen. Sagen Sie, welchen Vergleich Sie meinen, wann immer Sie das Wort Präfix in einem Ticket benutzen.
Eine Anwendungsbindung ändert die Frage
Eine Anwendung kann eine bestimmte Quelladresse verlangen, und eine gültige ausdrückliche Wahl verschiebt die Frage von “welche Adresse würde der Host bevorzugen” zu “kann diese Adresse das Ziel erreichen und zurückkommen”. Werkzeuge, die an eine Quelle binden oder Zusatzdaten zur gewählten Adresse anfordern, legen das direkt offen, und sie sind der schnellste Weg zu beweisen, welche Adresse eine Verbindung wirklich benutzt hat. Dieses Experiment ist besser als das dritte Lesen der Routentabelle, weil es berichtet, was der Kernel entschieden hat, statt was Sie konfiguriert haben. Wiederholen Sie es nach der Änderung und vergleichen Sie die beiden Antworten.
Das macht Quellbindung sowohl zu einem Diagnosewerkzeug als auch zu einem Behelf: Binden Sie die VPN-Adresse und beobachten Sie, ob die Anfrage erfolgreich ist. Wenn ja, ist der Pfad in Ordnung, und die Auswahl war das Problem. Wenn nicht, war der Rückweg oder die Richtlinie der Gegenseite von Anfang an das Problem.
Prüfen Sie, ob die Gegenseite diese Quelle akzeptiert
Was der Host auch wählt, es muss zum geschützten Bereich des VPN und zum Rückweg und den Zugriffsregeln der Gegenseite passen. Eine Quelle außerhalb der Selektoren kann in den Tunnel wandern und am fernen Ende verworfen werden, was wie ein einseitiger Fehler aussieht und dem Routing angelastet wird. Vergleichen Sie die gewählte innere Quelle mit dem Schutzbereich, bevor Sie die Verschlüsselungseinstellungen anfassen, denn ein Moduswechsel wählt nicht zwischen Kandidatenadressen.
Halten Sie auch die äußere Endpunktadresse in Ihren Überlegungen getrennt. Sie kennzeichnet den Transport zwischen den VPN-Teilnehmern und ist nicht die Quelle des Anwendungspakets innen.
Entscheiden Sie mit vier Beobachtungen
Notieren Sie das verwendete Ziel, die zulässigen lokalen Quellen, die tatsächlich gewählte Quelle und den wirksamen ausgehenden Pfad. Vier Zeilen genügen, um fast jeden Fall zu erklären, und sie lassen sich zwischen einem funktionierenden und einem fehlerhaften Host vergleichen, ohne die Theorie neu zu verhandeln. Verwenden Sie für den Auswahlschritt die eigene unterstützte Ansicht des Betriebssystems statt eines Namens aus der Norm, weil Implementierungen eigene lokale Vorlieben hinzufügen.
Wenn die Antwort Sie weiterhin überrascht, tut die Reihenfolge etwas, was Ihr Denkmodell nicht tut, und die Korrektur besteht darin, die Eingaben zu ändern, statt mit dem Algorithmus zu streiten. Schreiben Sie die vier Beobachtungen ins Ticket, und der nächste Leser kann Ihre Schlussfolgerung nachvollziehen.