Google API över VPN: routa VIP:en, inte bara subnätet

Logga in på den lokala servern med SSH, få upp tunneln och den privata VM:en svarar; sedan misslyckas det första anropet till ett Google API utan rutt. VM:ens subnät och API:ets VIP-adresser är olika destinationer, så en rutt för den ena väljer inte den andra. Tre villkor måste gälla innan ett privat API-anrop kan fungera. API-namnet måste lösas till en VIP, VIP-prefixet måste annonseras genom tunneln, och VPC:n måste veta hur svaret ska skickas tillbaka. En ping säger inget om det, och en fungerande SSH-session till en maskin i subnätet gör det inte heller.

API:ets VIP-adresser är egna destinationer

Google publicerar egna VIP:er för API-åtkomst från det lokala nätet, och det är de adresserna som din DNS måste returnera för API-namnen. Båda är små prefix och ingen av dem är RFC 1918-rymd:

Adresser som ser offentliga ut betyder inte att rutten ska lämna tunneln för det vanliga internet. Prefixen finns för att en lokal klient ska nå Googles frontends via en stödd väg i stället för en godtycklig utgångspunkt. Behandla dem som destinationer som hör till tunneln, inte som värdar att undersöka. En brandväggsregel skriven för internetutgång slänger dem vanligen, och det är en vanlig orsak till att ett anrop misslyckas innan det börjar.

DNS avgör vilken ändpunkt du når

Peka den lokala resolvern mot de poster som Google dokumenterar för den valda ändpunkten, så att namnen applikationen behöver svarar med den VIP:en. Bara googleapis.com är ingen inventering: paketregister, containerregister och migreringskopplingar har egna dokumenterade namn. Den begränsade VIP:en bär inte heller varje tjänst, så ett namn som löses kan fortfarande vara ostött. Skriv ned de domäner som applikationen faktiskt kontaktar innan du rör resolvern.

Att gissa en VM-adress i VPC:n som ersättning för ett tjänstenamn är ingen åtgärd, och det döljer vanligen DNS-luckan tills en annan klient misslyckas.

Annonsera VIP-prefixet, behåll resten

Med en BGP-baserad anslutning måste Cloud Router annonsera det valda VIP-prefixet så att den lokala routern kan lära sig intervallet genom den avsedda sessionen. Att bara annonsera VPC-subnäten lägger inte till intervallet, och den lokala routern fortsätter att använda sin standardväg för de adresserna. Prefixet i routingtabellen är det enda beviset på att annonsen korsade sessionen.

Behåll de befintliga annonserna medan du lägger till den nya, eftersom alternativ på routernivå och peer-nivå har olika räckvidd, och att byta uppsättningen kan dra tillbaka nät som redan fungerade. Kontrollera sedan den effektiva annonsen per session i stället för på routern som helhet. Ett saknat prefix och ett återtaget prefix ser likadana ut från den lokala sidan, så det är sessionsvyn som skiljer en utelämning från en regression.

VPC-sidan behöver sin egen rutt och returväg

Inne i VPC:n måste VIP-vägen använda standardinternet-gatewayen som nästa hopp, och trots namnet stannar den trafiken inom Googles nät. VPC:n behöver också en rutt tillbaka till den lokala källan via VPN:en, och det är ett eget objekt från det annonserade prefixet. Ta hänsyn till de dokumenterade regionala routingkraven när tunneln och klienten inte är i samma region.

Kontrollera returvägen oberoende, eftersom en fungerande förfrågningsriktning kan dölja en trasig svarsriktning. Två riktningar, två rutter, och var och en misslyckas med sitt eget symptom.

Testa förfrågan och läs sedan avvisningen

ICMP-eko får inget svar från dessa VIP:er, så en misslyckad ping bevisar ingenting och en lyckad mycket lite. Från den faktiska klienten, granska namnets svar och den valda rutten, och skicka sedan en auktoriserad HTTPS-förfrågan till tjänsten du bryr dig om. Om förfrågan når tjänsten och avvisas, titta på autentiseringsuppgifter, IAM och eventuell gällande tjänstperimeterpolicy.

Privat routing ger ingen API-auktorisering och ändrar inte vad identiteten får göra. Transportframgång och ett auktoriserat svar är separata resultat, och du behöver båda. Håll också IPv6-vägen explicit, eftersom att konfigurera IPv4-prefixen inte säger något om en klient som föredrar IPv6.

Googles guide för Private Google Access från det lokala nätet täcker DNS-posterna och routingkraven tillsammans, så jämför dina resolver- och annonsinställningar med den i stället för med ett foruminlägg. Kör sedan samma förfrågan igen och notera svaret och rutten i samma ärende.