Privates DNS funktioniert im VPC, aber nicht über das VPN
Ein privater Name, der in EC2 aufgelöst wird, über das VPN aber nicht, ist ein Problem des Resolver-Pfads. Prüfe die Fehlerform, bevor du den Zoneneintrag änderst.
Ein privater Name wird von einer EC2-Instanz aufgelöst, aber nicht von einem Laptop, der über das VPN verbunden ist, und die Zone sieht in der Konsole korrekt aus. Der Instinkt ist, den Eintrag zu bearbeiten, was fast nie das Problem ist. Der Eintrag antwortet jemandem; er antwortet nur nicht deinem Laptop. Was sich zwischen den beiden Aufrufern unterscheidet, ist, welchen Resolver sie fragen, und ob dieser Resolver einen unterstützten Pfad in die DNS-Sicht des VPC hat.
Ich beginne damit, zu beweisen, dass der Eintrag existiert, und verbringe die restliche Zeit mit dem Abfragepfad. Das sind getrennte Systeme, und sie scheitern auf unterschiedliche Weise.
Lies die Fehlerform, bevor du etwas änderst
Drei Ergebnisse bedeuten drei verschiedene Dinge, und eine einzige Abfrage unterscheidet sie: führe dig für den Namen gegen den Resolver aus, den der Client tatsächlich verwendet.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
Eine Zeitüberschreitung ist eine Aussage über das Netzwerk. NXDOMAIN ist eine Aussage über die DNS-Sicht. Eine öffentliche Antwort ist eine Aussage über die Richtlinie. Wer einen Zoneneintrag bearbeitet, während eine Zeitüberschreitung vorliegt, wirft den einzigen nützlichen Beweis des Falls weg.
Warum die Plus-zwei-Adresse des VPC kein entfernter Resolver ist
Die CIDR-plus-zwei-Adresse ist ein lokaler Dienst für Ressourcen innerhalb des VPC. AWS dokumentiert, dass das Weiterleiten von Abfragen aus lokalen Netzen oder von den DNS-Servern eines anderen VPC direkt an diese Adresse nicht unterstützt wird und instabile Ergebnisse liefern kann.
Das heißt nicht, dass ein Experiment nie zu funktionieren scheint. Es heißt, dass das Verhalten kein Vertrag ist, den man in ein Helpdesk-Skript schreiben kann. Die unterstützte Richtung ist ein eingehender Resolver-Endpunkt: ein Adresspaar in deinem VPC, erreichbar aus dem Netz, das du kontrollierst, das Abfragen von außerhalb von AWS annimmt.
Baue den Pfad in der Reihenfolge, in der er sauber scheitert
Drei Sprünge müssen existieren, und jeder hat seine eigene Art zu scheitern.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesDer Forwarder braucht eine Route zu den Endpunktadressen durch das VPN, und auch der Rückweg muss funktionieren. Für herkömmliches DNS auf Port 53 antwortet der Endpunkt über UDP und TCP, also müssen beide Protokolle erlaubt sein, und beide müssen eine zustandsbehaftete Prüfung in der Mitte überstehen.
Prüfe danach die DNS-Sicht separat. Eine private gehostete Zone ist nur für die VPCs sichtbar, mit denen sie verknüpft ist, oder über eine bewusste Freigaberegelung. Ein erreichbarer Endpunkt macht nicht von sich aus jede private Zone in seinem Auflösungskontext auflösbar.
Ein ausgehender Endpunkt dient der entgegengesetzten Richtung und beantwortet keine Abfrage, die von deinem Laptop hereinkommt.
Prüfe von beiden Enden aus
Frage vom Client gegen den Forwarder ab, dann vom Forwarder gegen den Endpunkt. Scheitert der Client, während der Forwarder Erfolg hat, liegt die Lücke zwischen diesen beiden.
Scheitern beide, schau dir die Sicherheitsrichtlinie am Endpunkt und die Quelladresse an, die er tatsächlich sieht. Ein Forwarder hinter NAT zeigt die NAT-Adresse statt der VPN-Adresse des Laptops, und dieser Unterschied allein reicht aus, um die Abfrage zu verwerfen. Haben beide Erfolg, scheitert die Anwendung aber weiterhin, verwendet die Anwendung möglicherweise einen anderen Resolver als den, den du getestet hast.
Halte die öffentlichen und die privaten Namespaces bewusst getrennt. Split DNS ist eine Richtlinie, die du konfigurierst, kein Nebeneffekt einer einzelnen Abfrage, die zufällig Daten zurückgibt.
Was ich nicht tun würde
Ich würde keine NAT-Regel hinzufügen, die eine einzelne Abfrage zum Laufen bringt, und das dann als Design bezeichnen.
Ich würde nicht jeden entfernten Client auf die Plus-zwei-Adresse zeigen lassen, nur weil ein Test einmal einen Eintrag zurückgegeben hat. Und ich würde die Sicherheitsrichtlinie des Endpunkts nicht auf den gesamten VPN-Pool ausweiten, wenn ein einziger Forwarder Zugriff braucht. Betreibt die Organisation bereits einen genehmigten Forwarder innerhalb des VPC, lies dieses Design zuerst, denn der zweite Endpunkt, den du hinzufügst, ist der, den niemand dokumentiert.