Google-APIs über VPN: die VIP routen, nicht nur das Subnetz

Melden Sie sich per SSH am lokalen Server an, bringen Sie den Tunnel hoch, und die private VM antwortet; dann scheitert der erste Aufruf einer Google-API ohne Route. Das VM-Subnetz und die VIPs der API sind verschiedene Ziele, also wählt eine Route für das eine nicht das andere. Drei Bedingungen müssen erfüllt sein, bevor ein privater API-Aufruf funktionieren kann. Der API-Name muss sich zu einer VIP auflösen, das VIP-Präfix muss über den Tunnel annonciert werden, und das VPC muss wissen, wie die Antwort zurückgeht. Ein Ping sagt Ihnen davon nichts, und eine funktionierende SSH-Sitzung zu einer Maschine im Subnetz ebenso wenig.

Die VIPs der API sind eigene Ziele

Google veröffentlicht eigene VIPs für den API-Zugriff aus dem lokalen Netz, und das sind die Adressen, die Ihr DNS für die API-Namen zurückgeben muss. Beide sind kleine Präfixe, und keines ist RFC-1918-Raum:

Öffentlich wirkende Adressen bedeuten nicht, dass die Route den Tunnel verlassen soll für das gewöhnliche Internet. Die Präfixe existieren, damit ein lokaler Client die Google-Frontends über einen unterstützten Pfad erreicht statt über einen beliebigen Ausstiegspunkt. Behandeln Sie sie als Ziele, die zum Tunnel gehören, nicht als Hosts zum Prüfen. Eine Firewall-Regel für Internet-Ausgang verwirft sie meist, und das ist ein häufiger Grund, warum ein Aufruf scheitert, bevor er beginnt.

DNS entscheidet, welchen Endpunkt Sie erreichen

Richten Sie den lokalen Resolver auf die Datensätze, die Google für den gewählten Endpunkt dokumentiert, damit die Namen, die die Anwendung braucht, mit dieser VIP antworten. Allein googleapis.com abzubilden ist kein Inventar: Paketregistries, Containerregistries und Migrationskonnektoren haben eigene dokumentierte Namen. Auch die eingeschränkte VIP trägt nicht jeden Dienst, also kann ein Name, der sich auflöst, trotzdem nicht unterstützt sein. Notieren Sie die Domains, die die Anwendung tatsächlich kontaktiert, bevor Sie den Resolver anfassen.

Eine VM-Adresse im VPC als Ersatz für einen Dienstnamen zu raten ist keine Behebung, und es verdeckt die DNS-Lücke meist, bis ein anderer Client scheitert.

Annoncieren Sie das VIP-Präfix, behalten Sie den Rest

Bei einer BGP-basierten Verbindung muss der Cloud Router das gewählte VIP-Präfix annoncieren, damit der lokale Router diesen Bereich über die vorgesehene Sitzung lernt. Nur die VPC-Subnetze zu annoncieren fügt diesen Bereich nicht hinzu, und der lokale Router nutzt für diese Adressen weiter seinen Standardpfad. Das Präfix in der Routing-Tabelle ist der einzige Beleg dafür, dass die Annonce die Sitzung überquert hat.

Behalten Sie die bestehenden Annoncen, während Sie die neue hinzufügen, denn Optionen auf Router- und auf Peer-Ebene haben unterschiedliche Reichweite, und ein Tausch des Satzes kann Netze zurückziehen, die bereits funktionierten. Prüfen Sie dann die effektive Annonce je Sitzung statt am Router als Ganzem. Ein fehlendes Präfix und ein zurückgezogenes Präfix sehen von der lokalen Seite gleich aus, deshalb trennt die Sitzungsansicht ein Versäumnis von einer Regression.

Die VPC-Seite braucht ihre eigene Route und ihren Rückweg

Innerhalb des VPC muss der VIP-Pfad das Standard-Internet-Gateway als nächsten Hop nutzen, und trotz des Namens bleibt dieser Verkehr im Netz von Google. Das VPC braucht außerdem eine Route zurück zur lokalen Quelle über das VPN, und das ist ein eigenes Objekt gegenüber dem annoncierten Präfix. Berücksichtigen Sie die dokumentierten regionalen Routing-Anforderungen, wenn Tunnel und Client nicht in derselben Region liegen.

Prüfen Sie den Rückweg unabhängig, denn eine funktionierende Anfragerechtung kann eine defekte Antwortrichtung verdecken. Zwei Richtungen, zwei Routen, und jede scheitert mit ihrem eigenen Symptom.

Testen Sie die Anfrage, dann lesen Sie die Ablehnung

ICMP-Echo erhält von diesen VIPs keine Antwort, ein fehlgeschlagener Ping beweist also nichts und ein erfolgreicher sehr wenig. Prüfen Sie vom tatsächlichen Client aus die Antwort des Namens und die gewählte Route, und stellen Sie dann eine autorisierte HTTPS-Anfrage an den Dienst, der Sie interessiert. Wenn die Anfrage den Dienst erreicht und abgelehnt wird, sehen Sie sich Anmeldedaten, IAM und jede geltende Dienstperimeter-Richtlinie an.

Privates Routing erteilt keine API-Autorisierung und ändert nicht, was die Identität tun darf. Transporterfolg und eine autorisierte Antwort sind getrennte Ergebnisse, und Sie brauchen beide. Halten Sie auch den IPv6-Pfad explizit, denn die IPv4-Präfixe zu konfigurieren sagt nichts über einen Client, der IPv6 bevorzugt.

Googles Leitfaden zu Private Google Access aus dem lokalen Netz deckt die DNS-Datensätze und die Routing-Anforderungen zusammen ab, vergleichen Sie also Ihre Resolver- und Annonce-Einstellungen damit und nicht mit einem Forenbeitrag. Führen Sie dann dieselbe Anfrage erneut aus und notieren Sie Antwort und Route im selben Ticket.