Geografisches DNS und Anycast: den VPN-Einstieg prüfen, den Sie erhalten

Eine nahe DNS-Antwort wirkt wie ein gelöstes Problem, bis die Verbindung woanders landet. Geografisches DNS und Anycast versuchen beide, den Weg zu verkürzen, und sie treffen diese Entscheidung aus unterschiedlichen Informationen. Keines von beiden garantiert, dass das Gateway, das Sie erreichen, erreichbar ist, dass es die Identität vorzeigt, die Ihr Client erwartet, oder dass Ihre Sitzung einen Knotenwechsel übersteht. Die folgenden Prüfungen trennen diese vier Fragen.

Prüfen Sie, wessen Standort der Resolver tatsächlich meldet

Ein autoritativer Server, der eine topologieabhängige Abfrage beantwortet, sieht normalerweise die Adresse des rekursiven Resolvers, der gefragt hat, nicht die Adresse der Person, die den Namen eingegeben hat. Ein zentraler Resolver kann weit von den Clients entfernt stehen, die er bedient, und die Antwort spiegelt den Resolver statt sie wider. Das ist kein Defekt; so verhält sich das Protokoll, solange keine zusätzlichen Informationen geliefert werden. Spezifikation für EDNS Client Subnet beschreibt sowohl die Einschränkung als auch die optionale Abhilfe.

EDNS Client Subnet kann Informationen über das Ursprungsnetz tragen, wenn jeder Teilnehmer es unterstützt und aktiviert. Es ist optional, es hat Folgen für Datenschutz und Caching, und es ist keine Erlaubnis anzunehmen, dass irgendein öffentlicher Resolver einen genauen Standort des Nutzers meldet. Fragen Sie die Resolver-Betreiber, bevor Sie darauf aufbauen.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Prüfen Sie, was das Anycast-Routing entschieden hat

Bei Anycast kündigen mehrere Standorte Erreichbarkeit für eine Dienstadresse an, und das Netzwerk liefert jeden Client an den Knoten, den sein Routing bevorzugt. Diese Wahl treffen BGP und die umgebende Politik, nicht die Entfernung auf einer Karte. Topologische Nähe bedeutet in der Regel auch nicht bessere Umlaufzeiten, weil der kurz wirkende Pfad überlastet oder asymmetrisch sein kann. Die Adresse, die Sie erhalten haben, sagt nichts darüber, welcher Knoten geantwortet hat.

Bestätigen Sie den Auslieferungsstandort von der Dienstseite oder aus einer Antwort, die ihn nennt, statt allein aus der DNS-Antwort. traceroute -n 198.51.100.20 zeigt den Pfad, den Sie genommen haben, und nennt den Host an dessen Ende trotzdem nicht, also lesen Sie es als Pfad und nicht als Antwort.

Prüfen Sie, dass die Sitzung einen Knotenwechsel übersteht

Eine DNS-Abfrage ist kurz und eine VPN-Sitzung lang, und beide haben völlig unterschiedliche Zustandsanforderungen. Das Routing kann sich mitten in der Sitzung verschieben, und wenn es das tut, können spätere Pakete an einem Knoten ankommen, der Ihren Tunnel nie gesehen hat. Ob das überlebbar ist, hängt von der Implementierung ab: gemeinsamer Zustand, ein bewusstes Wiederverbinden oder ein dokumentierter Fehler. Die Adresse allein liefert nichts davon.

Beobachten Sie die Verschiebung, statt sie anzunehmen. sudo tcpdump -ni any -c 20 esp zeigt die äußeren Pakete, während sich der Pfad ändert, und eine plötzliche Änderung der Peer-Adresse ist die Verschiebung. Definieren Sie das beabsichtigte Verhalten ausdrücklich für die Implementierung, die Sie betreiben, und testen Sie es dann, indem Sie einen Pfadwechsel erzwingen. Wenn das Design Sitzungsreplikation annimmt, benennen Sie den Mechanismus und benennen Sie den Fehler, den er nicht abdeckt.

Prüfen Sie, dass die Identität noch passt

Jeder Einstiegspunkt muss die Identität vorzeigen, die Ihr Clientprofil erwartet. Ein für den Dienstnamen ausgestelltes Zertifikat funktioniert über Knoten hinweg, während Zertifikate pro Knoten den Client zwingen, etwas Neues zu akzeptieren, und genau dort lernen Nutzer, Warnungen wegzuklicken. Halten Sie die erwartete Identität und das Profil mit dem Einstiegsmodell konsistent.

Prüfen Sie es von einem Client aus, der einen ungewöhnlichen Knoten erreicht hat, denn das ist der Fall, in dem ein Zertifikat pro Knoten sichtbar wird. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com gibt die Kette und die Namen aus, und genau das vergleicht der Client. Entscheiden Sie dann, ob das Profil verengt oder das Zertifikatsmodell geändert werden sollte.

Prüfen Sie die Aufzeichnung, nicht nur die erste Antwort

Bewerten Sie drei Szenarien und schreiben Sie für jedes vier Fakten auf: normaler Einstieg, ein nicht verfügbarer Standort und der vereinbarte Wiederherstellungsfall. Die vier Fakten sind der verwendete Resolver, die zurückgegebene Adresse, der Standort, der bedient hat, und ein frisches Anwendungsergebnis. Diese Aufzeichnung trennt ein DNS-Auswahlproblem von einem Gateway-Problem, einem Routingproblem oder einem Sitzungszustandsproblem. Ohne sie sehen alle vier aus Client-Sicht gleich aus.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Führen Sie die Szenarien aus repräsentativen Zugangsnetzen aus und nicht nur aus dem Büro, denn die ganze Frage dreht sich darum, welchen Einstiegspunkt verschiedene Clients tatsächlich erreichen. Ein Netzwerk ist eine Stichprobe von einem.