Google-API over VPN: rut VIP-en, ikkje berre subnettet

Logg på den lokale serveren med SSH, ta tunnelen opp, og den private VM-en svarar; deretter feilar det første kallet til ein Google-API utan rute. Subnettet til VM-en og VIP-adressene til API-et er ulike mål, så ei rute for det eine vel ikkje det andre. Tre vilkår må vere oppfylte før eit privat API-kall kan verke. API-namnet må løysast til ein VIP, VIP-prefikset må annonserast gjennom tunnelen, og VPC-et må vite korleis svaret skal sendast tilbake. Ein ping fortel deg ingen ting om dette, og ein fungerande SSH-økt til ein maskin i subnettet gjer det heller ikkje.

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

Google publiserer eigne VIP-ar for API-tilgang frå det lokale nettet, og det er desse adressene DNS-en din må returnere for API-namna. Begge er små prefiks, og ingen av dei er RFC 1918-rom:

Adresser som ser offentlege ut tyder ikkje at ruta skal forlate tunnelen for det vanlege internettet. Prefiksa finst for at ein lokal klient skal nå frontenda til Google via ein støtta veg i staden for eit vilkårleg utgangspunkt. Handsame dei som mål som høyrer til tunnelen, ikkje som vertar som skal undersøkjast. Ein brannmurregel skriven for internett-utgang vil vanlegvis droppe dei, og det er ein vanleg grunn til at eit kall feilar før det byrjar.

DNS avgjer kva endepunkt du når

Pek den lokale resolvaren mot postane Google dokumenterer for det valde endepunktet, slik at namna applikasjonen treng svarar med den VIP-en. Berre googleapis.com er ikkje ei oversikt: pakkeregistre, containerregistre og migreringskoplingar har eigne dokumenterte namn. Den avgrensa VIP-en ber heller ikkje kvar teneste, så eit namn som løysast kan framleis vere ustøtta. Skriv ned domena applikasjonen faktisk kontaktar før du rører resolvaren.

Å gisse på ei VM-adresse i VPC-et som erstatning for eit tenestenamn er ikkje ei retting, og det skjuler vanlegvis DNS-hòlet til ein annan klient feilar.

Annonser VIP-prefikset, hald resten

Med ei BGP-basert sambinding må Cloud Router annonsere det valde VIP-prefikset slik at den lokale rutaren kan lære området gjennom den tiltenkte økta. Å annonsere berre VPC-subnetta legg ikkje til området, og den lokale rutaren held fram med å bruke standardvegen sin for desse adressene. Prefikset i rutetabellen er det einaste provet på at annonsen kryssa økta.

Hald dei eksisterande annonsane medan du legg til den nye, fordi alternativ på rutarnivå og peer-nivå har ulik rekkjevidd, og å byte settet kan trekkje tilbake nettverk som allereie verka. Kontroller deretter den effektive annonsen på kvar økt i staden for på rutaren som heilskap. Eit manglande prefiks og eit tilbaketrekt prefiks ser like ut frå den lokale sida, så det er øktvisinga som skil ei utelating frå ein regresjon.

VPC-sida treng si eiga rute og returveg

Inne i VPC-et må VIP-vegen bruke standard internett-gateway som neste hopp, og trass i namnet blir den trafikken innanfor nettverket til Google. VPC-et treng òg ei rute tilbake til den lokale kjelda gjennom VPN-en, og det er eit eige objekt frå det annonserte prefikset. Ta omsyn til dei dokumenterte regionale rutekrava når tunnelen og klienten ikkje er i same region.

Kontroller returvegen uavhengig, fordi ei fungerande førespurnadsretning kan skjule ei broten svarretning. To retningar, to ruter, og kvar av dei feilar med sitt eige symptom.

Test førespurnaden, og les deretter avvisinga

ICMP-ekko får ingen svar frå desse VIP-ane, så ein mislukka ping provar ingen ting og ein vellukka svært lite. Frå den faktiske klienten, undersøk svaret til namnet og den valde ruta, og send deretter ein autorisert HTTPS-førespurnad til tenesta du bryr deg om. Viss førespurnaden når tenesta og blir avvist, sjå på legitimasjon, IAM og kvar gjeldande tenesteperimeter-policy.

Privat ruting gir ikkje API-autorisasjon og endrar ikkje kva identiteten har lov til å gjere. Transportsuksess og eit autorisert svar er separate resultat, og du treng begge. Hald IPv6-vegen eksplisitt òg, fordi å konfigurere IPv4-prefiksa ikkje seier noko om ein klient som føretrekk IPv6.

Rettleiinga til Google om Private Google Access frå det lokale nettet dekkjer DNS-postane og rutekrava samla, så samanlikn resolver- og annonseinnstillingane dine med ho i staden for med eit foruminnlegg. Køyr deretter den same førespurnaden på nytt og noter svaret og ruta i same saka.