VPN in die VPC funktioniert, aber der Managed Service läuft in ein Timeout

Der Zugriff auf eine verwaltete Datenbank über ein VPN scheitert meist aus einem Grund, den niemand ins Runbook geschrieben hat: Der Tunnel endet an Ihrer Netzwerkkante, während der Dienst nie auf Ihrer Seite davon lag. Die Routentabelle sieht korrekt aus, der Tunnel meldet sich als aktiv, und die Verbindung läuft trotzdem in ein Timeout. Arbeiten Sie die vier Prüfungen unten der Reihe nach ab und halten Sie bei der ersten an, deren Erfolgsbedingung nicht erfüllt ist, denn jede folgende Prüfung setzt voraus, dass die vorherigen gegriffen haben.

Prüfung eins: Wo lebt der Endpunkt tatsächlich?

Ein VPN-Gateway verbindet zwei Netze, deren Adressierung Sie kontrollieren. Ein Managed Service wird hinter der eigenen Eingangstür des Anbieters betrieben, und diese Tür hat je nach Produkt eine von drei Formen. Wenn Sie nicht wissen, mit welcher Form Sie es zu tun haben, hilft keine noch so große Routingarbeit, weil der Fehler vielleicht gar kein Routingfehler ist.

Die meisten vergeudeten Nachmittage entstehen dadurch, dass diese Klassifizierung übersprungen und direkt zur Routentabelle gegangen wird. Ein beim Anbieter gehosteter Dienst mit öffentlichem Endpunkt liegt nicht hinter Ihrem Tunnel, was das Diagramm auch sagt, und ein VPC-angebundener wird nie in einer öffentlichen DNS-Antwort auftauchen.

Prüfung zwei: ein VPC-angebundener Dienst wie ElastiCache

Zwischenspeicher dieser Art werden innerhalb Ihrer eigenen VPC adressiert und haben überhaupt keinen internetzugewandten Listener. Ein Client-VPN, das in derselben VPC endet, kann sie erreichen, aber nur wenn drei Bedingungen zusammenkommen. Der Cache-Endpunkt muss Subnetzen zugeordnet sein, die Ihr Tunnel sieht, seine Sicherheitsgruppe muss die Adresse zulassen, von der Ihre Clients kommen, und auf der Clientseite braucht es eine Route, die die Cache-Subnetze abdeckt.

Der häufige Fehler ist anzunehmen, eine Verbindung irgendwo in der Nähe zähle. Das VPN an eine andere VPC anzubinden oder sich allein auf Peering zu verlassen, erweitert weder die Sicherheitsgruppe des Caches noch dessen Subnetz-Routentabelle auf Ihre Clients. Wenn der bestehende Tunnel anderswo endet, ist ein Jump Host oder ein VPN-Server innerhalb dieser VPC der übliche Rückfallweg. Dieser Rückfallweg ist ein Notbehelf und kein Entwurf, und er sollte im Runbook als solcher gekennzeichnet werden.

Prüfung drei: ein PaaS-Endpunkt mit öffentlichem Namen

Azure Database for PostgreSQL bietet einen öffentlichen Servernamen. Es liefert Ihnen keine private Adresse, die Sie in eine hosts-Datei eintragen und über ein Gateway routen können. Dienstendpunkte für virtuelle Netze beschränken, welche Subnetze eine Ressource erreichen dürfen; sie berechtigen keinen lokalen Client, der über ein VPN ankommt.

Privater Zugriff bedeutet, einen privaten Endpunkt oder ein Private-Link-Design einzuführen und dann eine private DNS-Zone hinzuzufügen, damit der öffentliche Name mit diesem Endpunkt statt mit dem Internet antwortet. Ein VPN in Kombination mit einer Dienstendpunkt-Regel ist eine andere Architektur, die nur im Diagramm gleich aussieht. App Service folgt derselben Logik aus der anderen Richtung: VNet-Integration lässt die App ausgehende Aufrufe in ein VNet machen, und sie erzeugt keinen eingehenden privaten Pfad aus Ihrem Tunnel. Eingehender privater Zugriff erfordert daher einen privaten Endpunkt, eine App Service Environment oder ein Gateway vor der App, und was davon nutzbar ist, hängt vom Tarif ab.

Prüfung vier: Produkte mit eigener Eingangstür

Firebase Hosting lässt sich nicht an ein Cloud VPN anbinden, weil die Hosting-Ebene ein globales Frontend ist und nicht etwas innerhalb einer Projekt-VPC. Die dokumentierte Alternative ist, den kontrollierten Einstiegspunkt selbst zu bauen, mit einer Proxy-Instanz oder einem Load Balancer, der von einem Bucket gestützt wird. So oder so hört die Seite auf, ein reines Hostingprodukt zu sein, und wird zu Infrastruktur, die Sie nun betreiben. Dieser Tausch verdient einen Namen, bevor jemand verspricht, der Tunnel werde ihn abdecken.

Private API Gateway steht näher an der VPC-Dienstseite: Ein Interface-VPC-Endpunkt veröffentlicht einen Hostnamen, dessen Antworten private Adressen sind, und Verkehr aus Ihrem Standort kommt über den Tunnel oder eine dedizierte Interconnect-Verbindung an. Der Endpunkt muss der API zugeordnet sein, und Zertifikat plus Hostname müssen zur benutzerdefinierten Domain passen, die Aufrufer verwenden.

Google Cloud VPN-Tunnel binden an Peer-IP-Adressen, nicht an Namen. Die DNS-Weiterleitung wird separat konfiguriert, weshalb ein Tunnel völlig gesund sein kann, während Abfragen in der entfernten privaten Zone weiterhin scheitern.

Dann lokalisieren Sie die Grenze

Führen Sie dieselbe Verbindung von einer VM innerhalb der VPC aus. Wenn sie dort gelingt und vom VPN-Client aus scheitert, liegt die Lücke zwischen dem Clientpfad und dem Dienstendpunkt: eine Route, eine Sicherheitsgruppe, eine Endpunktrichtlinie oder ein Name. Wenn beide Versuche scheitern, kann nichts in diesem Netz den Dienst erreichen, und das VPN war nie das Hindernis.

getent hosts db.internal.example
nc -vz db.internal.example 5432

Machen Sie die Namensauflösung und die Portprüfung getrennt, weil sie aus verschiedenen Gründen scheitern und das Paar Ihnen sagt, welche Hälfte des Pfades kaputt ist. Ein Name, der zu einer öffentlichen Adresse auflöst, sagt Ihnen, dass die private DNS-Zone nicht im Spiel ist.