AWS Client VPN-Endpoint-DNS: Warum das Festnageln der aufgelösten IP scheitert

Letzte Woche lieferte dig +short Ihnen eine Adresse für den Endpoint-Namen in Ihrem AWS Client VPN-Profil, und der Tunnel verband sich. Diese Woche hängt dasselbe Profil auf Ihrem Laptop bei 'Connecting', während die unberührte Kopie eines Kollegen noch funktioniert. Nichts wurde blockiert, und das Zertifikat ist nicht abgelaufen. Jemand hat den Hostnamen des Endpoints durch diese aufgelöste Adresse ersetzt, und der Dienst antwortet dort nicht mehr. Der exportierte Name ist der Teil, der für diese Änderung gebaut wurde.

Der Name in Ihrem Profil ist möglicherweise nicht der abgefragte Name

Aus Client VPN exportierte Profile tragen häufig remote-random-hostname. Mit dieser Option baut der Client ein Wegwerf-Label, verbindet es mit einem Punkt mit dem Endpoint-Namen und löst den zusammengesetzten Namen auf. Ein Wildcard-Eintrag in der Zone des Endpoints beantwortet jedes Label, weshalb ein erfundener Präfix weiterhin auflöst und weshalb der Trick unsichtbar bleibt, wenn Sie die Abfrage von Hand nachstellen.

Wenn Sie also den Endpoint-Namen in ein Terminal einfügen und eine Antwort erhalten, haben Sie einen anderen Namen aufgelöst als den, den der Client beim Verbinden verwendet. Diese Abweichung ist kein Fehler, der im Profil korrigiert werden müsste. Das Label wird absichtlich neu erzeugt: Die Option hindert Caches daran, eine veraltete Antwort zu halten, und sie identifiziert niemals Ihren Rechner oder Ihre Sitzung.

Mir ist der Kompatibilitätsfall begegnet, in dem ein Client die Option schlicht ignoriert. AWS dokumentiert den Ausweg: Behalten Sie den echten Endpoint-Namen und stellen Sie eine Zufallszeichenfolge plus einen Punkt davor, und behandeln Sie das als Namensmuster statt als einzufügenden Wert. Das auf einen alten Client anzuwenden ist vernünftig; die präfixierte Zeichenfolge als Endpoint fest zu verdrahten ist es nicht.

Warum eine gespeicherte Antwort nicht korrekt bleiben kann

Client VPN-Endpoint-Adressen werden von AWS verwaltet und ändern sich im Laufe der Zeit, was die Best-Practice-Dokumentation klar sagt. Eine festgehaltene Antwort ist eine Momentaufnahme einer Auflösung. Ein Profil, das sie fest verdrahtet, wird zu einem Profil, das auf einen außer Betrieb genommenen Host zielt, sobald der Dienst umzieht, und der Fehler sieht selten nach DNS aus: Sie bekommen einen Verbindungs-Timeout oder einen hängenden Handshake, also jagen Leute Routing und Zertifikaten nach.

Dieselbe Antwort in /etc/hosts erbt dasselbe Ablaufdatum mit einem zusätzlichen Problem. Ein hosts-Eintrag überlebt Neustarts, erneute Exporte und 'Client neu installieren'-Reparaturen, also kehrt der Fehler jedes Mal zurück, wenn die Adresse umzieht. Ich habe erlebt, wie einer wochenlang harmlos lag und dann jeden Rechner lahmlegte, der ihn trug, während frische Installationen normal verbanden. Diese Spaltung, eine Gruppe scheitert und eine andere ist im selben Konto in Ordnung, ist der billigste Hinweis, den Sie bekommen.

Begrenzen Sie die Randomisierung richtig. Sie geschieht pro Verbindungsversuch. Ein bestehender Tunnel löst seinen Endpoint nicht neu auf, wechselt nicht mitten in der Sitzung den Server, und einzelne Anwendungsanfragen wählen nicht jeweils einen neuen VPN-Host. Nur der nächste Versuch löst erneut auf, weshalb eine Sitzung, die den ganzen Nachmittag läuft, nichts über morgen früh sagt.

Was der Dienst prüft, wenn der Tunnel hochkommt

Client VPN verlangt, dass die Adresse, mit der Sie verbunden sind, einer Adresse entspricht, die für den DNS-Namen des Endpoints aufgelöst wurde. Diese eine Anforderung erklärt mehrere Fehler, die unzusammenhängend wirken: ein eigener DNS-Eintrag, der woanders hinzeigt, ein eigenes Frontend, das an die echte Endpoint-Adresse weiterleitet, und ein Profil, das auf eine rohe Adresse umgeschrieben wurde. AWS dokumentiert die Kombination aus eigenem Eintrag und Weiterleitung als Fehler mit neueren AWS-Clients. Die Prüfung ist eng; sie ist kein Urteil, dass jeder Alias verboten ist.

Es ist auch keine allgemeine Regel über VPN-Protokolle. Ein numerisches remote ist in einer gewöhnlichen OpenVPN-Bereitstellung völlig gültig, und viele laufen so. Die Einschränkung kommt von der verwalteten Anordnung, nicht vom Protokoll darunter.

Was das Lockern der Zertifikatsprüfung zum falschen Reflex macht. Scheitert ein Profil nach einem Adresstausch, verschiebt das Abschalten der Serverprüfung den Fehler, statt die Auflösung oder die Adressübereinstimmung zu reparieren, und hinterlässt einen Client, der allem vertraut. Behalten Sie das exportierte CA, die Serverprüfung und die Einstellungen für gegenseitige Authentifizierung genau so, wie sie kamen.

Allowlists, Egress und privates DNS sind drei getrennte Probleme

Eine Firewall-Regel, die ein Ziel erlauben muss, bevor ein Laptop sich verbindet, betrifft den äußeren Listener. Geben Sie dem Netzwerkeigentümer den Endpoint-Namen, das Transportprotokoll und den konfigurierten Port, und fragen Sie dann, ob deren Kontrolle dem DNS-Verhalten des Dienstes folgen kann. Eine Regel, die eine festgehaltene Adresse hält, ist eine Momentaufnahme mit ungeschriebenem Ablaufdatum. Wenn die Kontrolle nur unveränderliche Ziele akzeptiert, klären Sie diese Lücke vor dem Rollout, statt still eine Antwort fest zu verdrahten.

Ein Partner, der eine feste Quelladresse für Anfragen nach dem Aufbau des Tunnels braucht, hat eine andere Anforderung: Egress. Was eine Website beobachtet, hängt von der Anwendungsroute und der Split-Tunnel-Richtlinie ab, nicht von der Adresse, mit der der Client verbunden war. Split-getunnelter Verkehr berührt AWS möglicherweise gar nicht.

Privates DNS innerhalb des Tunnels ist eine dritte Ebene. Der Resolver, den Clients erhalten, beantwortet interne Namen nach der Verbindung; er kann den öffentlichen Endpoint nicht auflösen, bevor der Tunnel existiert. Fehler bei der Endpoint-Auflösung und Fehler bei der internen Anwendungsauflösung passieren in verschiedenen Phasen, und ihre Vermischung schickt Sie ins falsche Log.

Die Adressfamilie gehört in dieselbe Liste. Eine IPv4-Antwort sagt nichts über den erlaubten Pfad eines IPv6- oder Dual-Stack-Endpoints, also ist eine in einer Familie aufgenommene Momentaufnahme kein Beleg für die andere.

Prüfen Sie eine Verbindung, ohne etwas festzunageln

Beginnen Sie mit dem Profil wie exportiert und lesen Sie, was es tatsächlich verlangt:

grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'

Vergleichen Sie dann drei Dinge: den Endpoint-Namen im Profil, die Adresse, die der Client für einen frischen Versuch meldet, und wohin der Name gerade jetzt auflöst. Ein Name, der auflöst, beweist nur, dass der Eintrag antwortet; Transport und Authentifizierung sind getrennt, und der Endpoint muss nicht auf einen Ping antworten. Das eigene Log des Clients ist die einzige Quelle für den mittleren Punkt, also erfassen Sie es während des Versuchs und nicht danach.

Eine Adresse, die heute antwortet, ist ein Beleg über heute; der Name ist das, was der Dienst gültig hält. Notieren Sie die Beobachtung, schicken Sie sie an den Eigentümer des Endpoints, und lassen Sie das Profil auf den Namen zeigen.

Zwei Gewohnheiten abzulegen: Zertifikatsprüfungen abschalten, um an einem hängenden Handshake vorbeizukommen, und Labels vor den Endpoint-Namen zu stapeln in der Hoffnung, dass eines hängen bleibt. Ein Label löst über den Wildcard-Eintrag auf, oder das Problem liegt woanders. Wenn ein korrekt konfiguriertes Profil weiterhin scheitert, senden Sie die exakte Abfrage und das Verbindungsereignis, keinen längeren Hostnamen.

Bevor Sie es abschließen: Das Profil trägt noch den exportierten Endpoint-Namen, keine hosts-Datei nagelt die Adresse fest, das remote im Client-Log entspricht einer aktuellen Auflösung, und die Firewall-Regel nennt den Endpoint statt einer Adresse. Das ist auch der Zustand, den Sie der nächsten Person übergeben.