AWS Client VPN und DNS: den VPC-Resolver nutzen, nicht das Subnetz

Der Endpunkt liegt in 10.0.8.0/24, also muss der Resolver 10.0.8.2 sein. Diese Begründung höre ich am häufigsten, und sie ist zweimal falsch. Route 53 Resolver antwortet auf dem primären IPv4-Bereich der VPC plus zwei, was bei einer VPC 10.0.0.0/16 die 10.0.0.2 ist, egal welches Subnetz der Endpunkt nutzt. Der zweite Fehler ist leiser: die richtige Adresse im Endpunkt zu hinterlegen heißt nicht, dass das Betriebssystem des Clients sie jemals fragt. Beide Fehler erzeugen dasselbe Symptom: Namensauflösung funktioniert bei manchen Clients und scheitert bei anderen.

Der Mythos beginnt bei der Subnetz-Zuordnung

Die Zuordnung betrifft den Ort, an dem die elastischen Netzwerkschnittstellen für Clientverbindungen liegen, nicht die Frage, welche Resolver-Adresse existiert. Die Subnetze des Endpunkts geben den Clients eine Adresse innerhalb der VPC, und sie bringen nicht jeweils einen eigenen Resolver mit.

Sobald man diese beiden Ideen trennt, verliert die Arithmetik ihr Geheimnis, und die Fehlersuche wandert zum Client, wo die meisten dieser Fälle tatsächlich enden.

Die Adresse aus dem primären VPC-Bereich berechnen

Nimm den primären IPv4-CIDR der VPC und addiere zwei auf die Netzwerkadresse. 10.0.0.0/16 ergibt 10.0.0.2, 172.31.0.0/16 ergibt 172.31.0.2, und eine VPC mit einem sekundären Bereich behält den Resolver auf dem primären. Ein Subnetz 10.0.8.0/24 darin verschiebt ihn nicht. Notiere die Adresse neben der VPC-ID, bevor du den Endpunkt anfasst, denn die Zahl ist eine Eigenschaft der VPC und nicht der Verbindung.

Die VPC antwortet außerdem auf der link-lokalen Adresse 169.254.169.253. Diese Adresse ist aus dem Inneren der VPC erreichbar, aber kein allgemein geroutetes Ziel für einen Laptop am anderen Ende eines Tunnels.

Es gibt also zwei gültige Resolver-Adressen, und keine davon ist das Subnetz plus zwei.

Was die Endpunkt-Einstellung tut und was nicht

Der Client-VPN-Endpunkt hat DNS-Server-Felder, und wo die Konsole eine VPC-Resolver-Option anbietet, trägt sie dieselbe Idee ein. Sie zu setzen ändert, was der Dienst den Clients beim Verbindungsaufbau übergibt. Es ändert nicht, was ein nicht verwalteter OpenVPN-Client mit diesem Wert tut, denn der Client muss ihn noch immer im Betriebssystem anwenden. Aus dieser Lücke stammt „läuft auf meinem Mac, aber nicht auf der Linux-Kiste“.

Unter Linux gehört die Resolver-Integration dem Verbindungsmanager und nicht dem Benutzer. /etc/resolv.conf von Hand zu bearbeiten beweist, dass die Adresse für eine Sitzung funktioniert, und verschwindet beim Neuverbinden wieder — deshalb kommen so viele reparierte Fälle am nächsten Morgen zurück.

Prüfe nach dem Verbinden den aktiven Resolver am Client, nicht die Konfigurationsseite des Endpunkts.

Split-Tunneling kann einen korrekten Resolver aushebeln

Bei Split-Tunneling werden nur Routen genutzt, die in den Tunnel geschoben werden. Ist die Resolver-Adresse nicht von einer Route abgedeckt, verlässt die Anfrage die lokale Schnittstelle und wird vom Heimrouter beantwortet. Die Adresse im Endpunkt bleibt korrekt, und die Auflösung scheitert weiterhin. Ergänze die Route für den Resolver und teste erneut.

Überlappende lokale Bereiche liefern dasselbe Ergebnis auf unangenehmere Weise: die Anfrage wird beantwortet, nur vom falschen Server.

Keine Security Groups für die Amazon-DNS-Adresse öffnen

Der Instinkt bei Zeitüberschreitungen ist, eine Regel zu ergänzen, die UDP 53 zur Resolver-Adresse erlaubt. AWS dokumentiert, dass Security Groups und Netzwerk-ACLs den Amazon-DNS-Verkehr nicht so filtern, wie sie Verkehr zu einer eigenen DNS-Instanz filtern. Diese Regeln zu öffnen ändert nichts am VPC-Resolver und erweitert die Grenze ohne Grund. Ein selbst betriebener Resolver ist ein anderer Fall und braucht tatsächlich eigene Regeln.

Wenn beides in deinem Design vorkommt, prüfe, worauf der Client tatsächlich zeigt, bevor du eine Regel änderst.

Den Pfad prüfen, dann etwas anderes messen

Löse einen öffentlichen Namen auf, löse einen privaten Namen auf, der in einer mit der VPC verknüpften privaten gehosteten Zone registriert ist, und lies dazwischen den aktiven Resolver des Clients. Diese Reihenfolge trennt „die Resolver-Adresse ist falsch“ von „die Zone ist nicht verknüpft“ und von „der Client hat die Einstellung ignoriert“. Jedes hat eine andere Lösung, und keines ist ein Durchsatzproblem.

Ein erfolgreicher Lookup sagt nichts über dauerhafte Übertragungsgeschwindigkeit, also halte diese beiden Gespräche getrennt, wenn du berichtest.