Google-API over VPN: rut VIP-en, ikke bare subnettet

Logg på den lokale serveren med SSH, ta tunnelen opp, og den private VM-en svarer; deretter feiler det første kallet til en Google-API uten rute. Subnettet til VM-en og VIP-adressene til API-et er forskjellige mål, så en rute for det ene velger ikke det andre. Tre vilkår må være oppfylt før et privat API-kall kan virke. API-navnet må løses til en VIP, VIP-prefikset må annonseres gjennom tunnelen, og VPC-et må vite hvordan svaret skal sendes tilbake. En ping forteller deg ingenting av dette, og en fungerende SSH-økt til en maskin i subnettet gjør det heller ikke.

VIP-adressene til API-et er egne mål

Google publiserer egne VIP-er for API-tilgang fra det lokale nettet, og det er disse adressene DNS-en din må returnere for API-navnene. Begge er små prefikser, og ingen av dem er RFC 1918-rom:

Adresser som ser offentlige ut betyr ikke at ruten skal forlate tunnelen for det vanlige internettet. Prefiksene finnes for at en lokal klient skal nå Googles frontender via en støttet vei i stedet for et vilkårlig utgangspunkt. Behandle dem som mål som hører til tunnelen, ikke som verter som skal undersøkes. En brannmurregel skrevet for internett-utgang vil vanligvis droppe dem, og det er en vanlig grunn til at et kall feiler før det begynner.

DNS avgjør hvilket endepunkt du når

Pek den lokale resolveren mot postene Google dokumenterer for det valgte endepunktet, slik at navnene applikasjonen trenger svarer med den VIP-en. Bare googleapis.com er ikke en oversikt: pakkeregistre, containerregistre og migreringskoblinger har egne dokumenterte navn. Den begrensede VIP-en bærer heller ikke hver tjeneste, så et navn som løses kan fortsatt være ustøttet. Skriv ned domenene applikasjonen faktisk kontakter før du rører resolveren.

Å gjette en VM-adresse i VPC-et som erstatning for et tjenestenavn er ikke en rettelse, og det skjuler vanligvis DNS-hullet til en annen klient feiler.

Annonser VIP-prefikset, behold resten

Med en BGP-basert forbindelse må Cloud Router annonsere det valgte VIP-prefikset slik at den lokale ruteren kan lære området gjennom den tiltenkte økten. Å annonsere bare VPC-subnettene legger ikke til området, og den lokale ruteren fortsetter å bruke standardveien sin for disse adressene. Prefikset i rutetabellen er det eneste beviset på at annonsen krysset økten.

Behold de eksisterende annonsene mens du legger til den nye, fordi alternativer på ruternivå og peer-nivå har ulik rekkevidde, og å bytte settet kan trekke tilbake nettverk som allerede virket. Kontroller deretter den effektive annonsen på hver økt i stedet for på ruteren som helhet. Et manglende prefiks og et tilbaketrukket prefiks ser like ut fra den lokale siden, så det er øktvisningen som skiller en utelatelse fra en regresjon.

VPC-siden trenger sin egen rute og returvei

Inne i VPC-et må VIP-veien bruke standard internett-gateway som neste hopp, og til tross for navnet blir den trafikken innenfor Googles nettverk. VPC-et trenger også en rute tilbake til den lokale kilden gjennom VPN-en, og det er et eget objekt fra det annonserte prefikset. Ta hensyn til de dokumenterte regionale rutekravene når tunnelen og klienten ikke er i samme region.

Kontroller returveien uavhengig, fordi en fungerende forespørselsretning kan skjule en brutt svarretning. To retninger, to ruter, og hver av dem feiler med sitt eget symptom.

Test forespørselen, og les deretter avvisningen

ICMP-ekko får ingen svar fra disse VIP-ene, så en mislykket ping beviser ingenting og en vellykket svært lite. Fra den faktiske klienten, undersøk navnets svar og den valgte ruten, og send deretter en autorisert HTTPS-forespørsel til tjenesten du bryr deg om. Hvis forespørselen når tjenesten og blir avvist, se på legitimasjon, IAM og enhver gjeldende tjenesteperimeter-policy.

Privat ruting gir ikke API-autorisasjon og endrer ikke hva identiteten har lov til å gjøre. Transportsuksess og et autorisert svar er separate resultater, og du trenger begge. Hold IPv6-veien eksplisitt også, fordi å konfigurere IPv4-prefiksene ikke sier noe om en klient som foretrekker IPv6.

Googles veiledning for Private Google Access fra det lokale nettet dekker DNS-postene og rutekravene samlet, så sammenlign resolver- og annonseinnstillingene dine med den i stedet for med et foruminnlegg. Kjør deretter den samme forespørselen på nytt og noter svaret og ruten i samme sak.