Fernzugriff für Entwickler auf ein Google Cloud VPC: den richtigen Weg wählen

Ein Entwickler braucht eine SSH-Sitzung, einen Datenbankport oder breiten Zugang zu einem Dutzend privater Dienste, und jede dieser Anfragen sieht wie dieselbe Frage aus. Ist sie nicht. Die Ziele, die Protokolle und die beteiligten Identitäten entscheiden, welcher Zugangsweg in Google Cloud passt, und die breiteste Option standardmäßig zu wählen, erzeugt Arbeit, die Sie nicht hätten übernehmen müssen.

Ziele und Protokolle aufschreiben

Listen Sie die privaten Adressen, Ports und Protokolle auf, die die Arbeit tatsächlich braucht, und markieren Sie dann, welche Identitäten getrennt authentifiziert werden müssen. Ein Datenbankport und eine private DNS-Zone sind unterschiedliche Anforderungen, und ein UDP-Dienst schließt eine der folgenden Optionen vollständig aus. Eine schriftliche Liste zeigt auch, was Sie nicht gewähren. Das ist der Teil, nach dem Prüfer fragen.

Tun Sie das, bevor Sie einen Listener öffnen. Die Liste wird später zum Abnahmetest, und sie ist der einzige verlässliche Weg, einen schmalen Tunnel von einem breiten zu unterscheiden, der zufällig funktioniert.

IAP für einige wenige TCP-Dienste

TCP-Weiterleitung in Identity-Aware Proxy liefert einen authentifizierten Tunnel zu geeigneten VM-Ressourcen, ohne den Dienst ins Internet zu stellen. Die alltägliche Form ist gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, und ein einzelner Port lässt sich lokal mit gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a weiterleiten.

Drei Dinge müssen zusammenpassen: der Aufrufer braucht die IAP-Tunnelzugriffsrolle, die Firewall muss den IAP-Quellbereich zulassen, und das Ziel muss auf der Instanz erreichbar sein. Die Berechtigung, den Tunnel zu erstellen, ist kein Datenbank-Anmeldedatum, kein SSH-Login und keine RDP-Sitzung, also lassen Sie die Anwendungsauthentifizierung, wo sie hingehört.

TCP-Weiterleitung in IAP ist kein VPN der dritten Schicht. Sie trägt TCP zu einem ausgewählten Ziel, nicht beliebigen IP-Verkehr oder UDP, und sie passt schlecht, wenn eine Anwendung privates DNS über viele Dienste hinweg braucht.

Ein Fernzugriffs-VPN für breitere Erreichbarkeit

Wenn mehrere Ziele, Protokolle oder private DNS-Zonen nötig sind, ist ein ausdrücklich verwaltetes Fernzugriffs-VPN auf einer VM oder einem unterstützten Gerät die bessere Form. Diese Bereitstellung ist getrennt vom von Google verwalteten Cloud VPN: Sie besitzen die Registrierung der Client-Identität, die Software-Aktualisierungen, die Client-Routen und die Rückwege im VPC.

Planen Sie die ganze Liste, nicht nur den öffentlichen Listener. Beziehen Sie den Tunnel-Pool, die VPC-Route zurück dorthin, Weiterleitungs-Kontrollen, DNS-Auflösung und die Zugriffsrichtlinie je Dienst ein. Ein VPN, das sich verbindet, aber interne Namen nicht auflösen kann, lässt den Entwickler-Workflow genauso vollständig scheitern wie eines, das sich nie verbindet.

Cloud VPN ist ein Standort-Gateway, kein Laptop-Profil

Google Cloud VPN verbindet Peer-Gateways über IPsec, und die häufig gestellten Fragen dazu trennen diese Standort-zu-Standort-Rolle vom Client-zu-Gateway-Zugriff. Einen Tunnel zu erstellen erzeugt kein Profil, das ein Mitarbeiter auf einem Laptop importiert. Der Unterschied zählt, wenn jemand ein Cloud VPN-Profil anfragt. Die Antwort ist ein anderes Produkt.

Was ein Gateway gut kann, ist den Rechnern hinter einem Büronetzwerk eine Route in das VPC zu geben. Es authentifiziert nicht jeden Mitarbeiter und erteilt keine Anwendungsberechtigungen, deshalb bleiben diese Richtlinien auf der Netzwerk- und Anwendungsschicht, wo sie pro Identität durchgesetzt werden können.

Prüfen und festhalten

Testen Sie zuerst das engste Ziel, dann das, welches DNS benötigt, und dann ein Ziel, das verweigert bleiben muss. Führen Sie jeden Test von demselben Client aus, der den Weg in der Produktion nutzt, denn ein funktionierender Test von einem Administrator-Arbeitsplatz beweist wenig über einen Entwickler-Laptop mit einem anderen Netzwerk.

Halten Sie das gewählte Modell fest, die Ziele, die es abdeckt, die Identitäten, die es authentifiziert, und das Fehlerverhalten, wenn der Weg nicht verfügbar ist. Dieser Eintrag ist es, der verhindert, dass die nächste Anfrage den Tunnel still erweitert, statt ein Ziel einem dokumentierten Entwurf hinzuzufügen.