Google API’s over VPN: route de VIP, niet alleen het subnet

Log met SSH in op de lokale server, breng de tunnel omhoog, en de private VM antwoordt; daarna mislukt de eerste aanroep naar een Google API zonder route. Het subnet van de VM en de VIP’s van de API zijn verschillende bestemmingen, dus een route voor het ene selecteert het andere niet. Er moeten drie voorwaarden gelden voordat een private API-aanroep kan werken. De API-naam moet naar een VIP resolven, het VIP-prefix moet over de tunnel worden geadverteerd, en de VPC moet weten hoe het antwoord teruggaat. Een ping vertelt je daar niets van, en een werkende SSH-sessie naar een machine in het subnet ook niet.

De VIP’s van de API zijn aparte bestemmingen

Google publiceert speciale VIP’s voor API-toegang vanaf het lokale netwerk, en dat zijn de adressen die je DNS voor de API-namen moet teruggeven. Beide zijn kleine prefixen en geen van beide is RFC 1918-ruimte:

Adressen die publiek lijken betekenen niet dat de route de tunnel moet verlaten voor het gewone internet. De prefixen bestaan zodat een lokale client de frontends van Google bereikt via een ondersteund pad in plaats van een willekeurig uitgangspunt. Behandel ze als bestemmingen die bij de tunnel horen, niet als hosts om te onderzoeken. Een firewallregel geschreven voor internetuitgang gooit ze meestal weg, en dat is een veelvoorkomende reden dat een aanroep mislukt voordat hij begint.

DNS bepaalt welk eindpunt je bereikt

Wijs de lokale resolver naar de records die Google documenteert voor het gekozen eindpunt, zodat de namen die de toepassing nodig heeft met die VIP antwoorden. Alleen googleapis.com is geen inventaris: pakketregisters, containerregisters en migratieconnectors hebben hun eigen gedocumenteerde namen. Ook de beperkte VIP draagt niet elke dienst, dus een naam die resolvet kan nog steeds niet ondersteund zijn. Noteer de domeinen die de toepassing echt contacteert voordat je de resolver aanraakt.

Een VM-adres in de VPC raden als vervanging voor een dienstnaam is geen oplossing, en het verbergt meestal het DNS-gat tot een andere client faalt.

Adverteer het VIP-prefix, houd de rest

Bij een op BGP gebaseerde verbinding moet de Cloud Router het gekozen VIP-prefix adverteren zodat de lokale router dat bereik via de bedoelde sessie leert. Alleen de VPC-subnetten adverteren voegt dat bereik niet toe, en de lokale router blijft zijn standaardpad voor die adressen gebruiken. Het prefix in de routetabel is het enige bewijs dat de advertentie de sessie is gepasseerd.

Houd de bestaande advertenties vast terwijl je de nieuwe toevoegt, want opties op routerniveau en op peerniveau hebben een verschillend bereik, en het wisselen van de set kan netwerken intrekken die al werkten. Controleer daarna de effectieve advertentie per sessie in plaats van op de router als geheel. Een ontbrekend prefix en een ingetrokken prefix zien er vanaf de lokale kant hetzelfde uit, dus de sessieweergave is wat een weglating van een regressie scheidt.

De VPC-kant heeft zijn eigen route en retourpad nodig

Binnen de VPC moet het VIP-pad de standaard internetgateway als volgende hop gebruiken, en ondanks de naam blijft dat verkeer binnen het netwerk van Google. De VPC heeft ook een route terug naar de lokale bron via de VPN nodig, en dat is een apart object van het geadverteerde prefix. Houd rekening met de gedocumenteerde regionale routingeisen wanneer de tunnel en de client niet in dezelfde regio liggen.

Controleer het retourpad onafhankelijk, want een werkende aanvraagrichting kan een kapotte antwoordrichting verbergen. Twee richtingen, twee routes, en elk faalt met zijn eigen symptoom.

Test de aanvraag en lees dan de afwijzing

ICMP-echo krijgt geen antwoord van deze VIP’s, dus een mislukte ping bewijst niets en een geslaagde heel weinig. Bekijk vanaf de echte client het antwoord van de naam en de gekozen route, en doe dan een geautoriseerde HTTPS-aanvraag naar de dienst die je belangrijk vindt. Als de aanvraag de dienst bereikt en wordt afgewezen, kijk dan naar inloggegevens, IAM en elk geldend dienstperimeterbeleid.

Private routing geeft geen API-autorisatie en verandert niet wat de identiteit mag doen. Transportsucces en een geautoriseerd antwoord zijn aparte resultaten, en je hebt beide nodig. Houd ook het IPv6-pad expliciet, want het configureren van de IPv4-prefixen zegt niets over een client die IPv6 verkiest.

De gids van Google over Private Google Access vanaf het lokale netwerk behandelt de DNS-records en de routingeisen samen, dus vergelijk je resolver- en advertentie-instellingen daarmee en niet met een forumbericht. Voer daarna dezelfde aanvraag opnieuw uit en noteer het antwoord en de route in hetzelfde ticket.