Google API over VPN: rut VIP’en, ikke kun undernettet

Log ind på den lokale server via SSH, bring tunnelen op, og den private VM svarer; derefter fejler det første kald til en Google API uden rute. VM’ets undernet og API’ets VIP-adresser er forskellige destinationer, så en rute til den ene vælger ikke den anden. Tre betingelser skal være opfyldt, før et privat API-kald kan virke. API-navnet skal slås op til en VIP, VIP-præfikset skal annonceres gennem tunnelen, og VPC’en skal vide, hvordan svaret sendes tilbage. En ping fortæller dig intet af det, og en fungerende SSH-session til en maskine i undernettet gør heller ikke.

API’ets VIP-adresser er separate destinationer

Google udgiver dedikerede VIP-adresser til API-adgang fra det lokale netværk, og det er de adresser, din DNS skal returnere for API-navnene. Begge er små præfikser, og ingen af dem er RFC 1918-adresserum:

Adresser, der ser offentlige ud, betyder ikke, at ruten skal forlade tunnelen for det almindelige internet. Præfikserne findes, så en lokal klient kan nå Googles frontender ad en understøttet vej i stedet for et vilkårligt udgangspunkt. Behandl dem som destinationer, der hører til tunnelen, ikke som værter, der skal undersøges. En firewallregel skrevet til internetudgang vil normalt droppe dem, og det er en almindelig grund til, at et kald fejler, før det begynder.

DNS afgør, hvilket endepunkt du når

Peg den lokale resolver mod de poster, som Google dokumenterer for det valgte endepunkt, så de navne, applikationen har brug for, svarer med den VIP. Bare googleapis.com er ikke en fortegnelse: pakkeregistre, containerregistre og migreringsforbindelser har deres egne dokumenterede navne. Den begrænsede VIP dækker heller ikke enhver tjeneste, så et navn, der slås op, kan stadig være uden support. Skriv de domæner ned, som applikationen faktisk kontakter, før du rører resolveren.

At gætte en VM-adresse i VPC’en som erstatning for et tjenestenavn er ikke en rettelse, og det skjuler normalt DNS-hullet, indtil en anden klient fejler.

Annoncer VIP-præfikset, behold resten

Med en BGP-baseret forbindelse skal Cloud Router annoncere det valgte VIP-præfiks, så den lokale router kan lære det interval gennem den tilsigtede session. Annoncering af VPC-undernettene alene tilføjer ikke intervallet, og den lokale router bliver ved med at bruge sin standardvej til de adresser. Præfikset i routingtabellen er det eneste bevis for, at annonceringen krydsede sessionen.

Behold de eksisterende annonceringer, mens du tilføjer den nye, fordi indstillinger på router- og peer-niveau har forskellig rækkevidde, og et bytte af sættet kan trække netværk tilbage, som allerede virkede. Kontrollér derefter den effektive annoncering på hver session i stedet for på routeren som helhed. Et manglende præfiks og et tilbagetrukket præfiks ser ens ud fra den lokale side, så det er sessionsvisningen, der skiller en udeladelse fra en regression.

VPC-siden har brug for sin egen rute og returvej

Inde i VPC’en skal VIP-stien bruge standard-internetgatewayen som næste hop, og trods navnet bliver den trafik inden for Googles netværk. VPC’en har også brug for en rute tilbage til den lokale kilde gennem VPN’en, og det er et separat objekt fra det annoncerede præfiks. Tag højde for de dokumenterede regionale routingkrav, når tunnelen og klienten ikke er i samme region.

Kontrollér returvejen uafhængigt, fordi en fungerende anmodningsretning kan skjule en brudt svarretning. To retninger, to ruter, og hver af dem fejler med sit eget symptom.

Test anmodningen, og læs så afvisningen

ICMP-ekko får intet svar fra disse VIP-adresser, så en mislykket ping beviser intet, og en vellykket beviser meget lidt. Fra den faktiske klient kan du undersøge navnets svar og den valgte rute og derefter sende en autoriseret HTTPS-anmodning til den tjeneste, du interesserer dig for. Hvis anmodningen når tjenesten og afvises, så se på legitimation, IAM og enhver tjenesteperimeterpolitik, der gælder.

Privat routing giver ikke API-autorisation og ændrer ikke, hvad identiteten må gøre. Transporterfolg og et autoriseret svar er separate resultater, og du har brug for begge. Hold også IPv6-stien eksplicit, fordi konfiguration af IPv4-præfikserne intet siger om en klient, der foretrækker IPv6.

Googles guide til Private Google Access fra det lokale netværk dækker DNS-posterne og routingkravene samlet, så sammenlign dine resolver- og annonceringsindstillinger med den i stedet for med et forumindlæg. Kør derefter den samme anmodning igen, og notér svaret og ruten i den samme ticket.