Google API oer VPN: rûte de VIP, net allinnich it subnet
In rûte nei in VPC-subnet selektearret de API-VIP’s net. Los de juste nammen op, advertearje it VIP-foarheaksel, hâld de VPC-weromwei, en test dan HTTPS.
Meld jo oan fia SSH op ’e pleatslike tsjinner, bring de tunnel omheech, en de privee VM antwurdet; dan mislearret de earste oprop nei in Google-API sûnder rûte. It VM-subnet en de API-VIP’s binne ferskate bestimmingen, dus in rûte foar ien selektearret de oare net. Trije betingsten moatte jilde foardat in privee API-oprop wurkje kin. De API-namme moat nei in VIP oplosse, it VIP-foarheaksel moat oer de tunnel advertearre wurde, en de VPC moat witte hoe’t it antwurd werom stjoerd wurdt. In ping fertelt jo dêr neat fan, en in wurkjende SSH-sesje nei in masine yn it subnet ek net.
De API-VIP’s binne aparte bestimmingen
Google publisearret tawijde VIP’s foar API-tagong fan it pleatslike netwurk, en dat binne de adressen dy’t jo DNS foar de API-nammen weromjaan moat. Beide binne lytse foarheaksels en gjinien is RFC 1918-romte:
| Record | Resolves to | What it does not give you |
|---|---|---|
| private.googleapis.com | 199.36.153.8/30, the general front door for Google APIs | not a bypass around a service perimeter |
| restricted.googleapis.com | 199.36.153.4/30, reachable only for services a perimeter allows | not the whole API surface, so some names stay out of reach |
Adressen dy’t publike lykje betsjutte net dat de rûte de tunnel ferlitte moat foar it gewoane ynternet. De foarheaksels besteane sadat in pleatslike klant de fronten fan Google berikke kin fia in stipe paad yn stee fan in willekeurich útgongspunt. Behannelje se as bestimmingen dy’t by de tunnel hearre, net as hosts om te ûndersykjen. In fjoerwâlregel skreaun foar ynternetútgong ferwaarf se meastentiids, en dat is in algemiene reden wêrom’t in oprop mislearret foardat er begjint.
DNS beslút hokker einpunt jo berikke
Rjochtsje de pleatslike resolver op de records dy’t Google dokumintearret foar it keazen einpunt, sadat de nammen dy’t de applikaasje nedich hat, mei dy VIP antwurdzje. Allinnich googleapis.com is gjin ynventaris: pakketregisters, containerregisters en migraasjekonnektoren hawwe har eigen dokumintearre nammen. De beheinde VIP draacht ek net elke tsjinst, dus in namme dy’t oplost kin noch hieltyd net stipe wurde. Skriuw de domeinen op dy’t de applikaasje eins kontaktet foardat jo de resolver oanreitsje.
In VM-adres yn ’e VPC riede as ferfanging foar in tsjinstnamme is gjin oplossing, en it ferberget meastentiids it DNS-gat oant in oare klant mislearret.
Advertearje it VIP-foarheaksel, hâld de rest
Mei in BGP-basearre ferbining moat de Cloud Router it keazen VIP-foarheaksel advertearje sadat de pleatslike router dat berik oer de bedoelde sesje leare kin. Allinnich de VPC-subnetten advertearje foeget dat berik net ta, en de pleatslike router bliuwt syn standertpaad foar dy adressen brûken. It foarheaksel yn ’e rûtetabel is it iennichste bewiis dat de advertinsje de sesje oerstutsen hat.
Hâld de besteande advertinsjes wylst jo it nije tafoegje, want opsjes op routernivo en op peernivo hawwe ferskillend berik, en it wikseljen fan ’e set kin netwurken weromlûke dy’t al wurken. Kontrolearje dan de effektive advertinsje op elke sesje yn stee fan op ’e router as gehiel. In ûntbrekkend foarheaksel en in weromlutsen foarheaksel lykje fan ’e pleatslike kant itselde, dus de sesje-oansjoch is wat in ferskowing fan in regression skiedt.
De VPC-kant hat syn eigen rûte en weromwei nedich
Binnen de VPC moat it VIP-paad de standert ynternetpoarte as folgjende hop brûke, en nettsjinsteande de namme bliuwt dat ferkear binnen it netwurk fan Google. De VPC hat ek in rûte werom nei de pleatslike boarne fia de VPN nedich, en dat is in apart objekt fan it advertearre foarheaksel. Hâld rekken mei de dokumintearre regionale rûte-easken as de tunnel en de klant net yn deselde regio binne.
Kontrolearje de weromwei ûnôfhinklik, want in wurkjende oanfraachrjochting kin in brutsen antwurdrjochting ferbergje. Twa rjochtingen, twa rûtes, en elk mislearret mei syn eigen symptoom.
Test de oanfraach, lês dan de ôfwizing
ICMP-echo krijt gjin antwurd fan dizze VIP’s, dus in mislearre ping bewiist neat en in slagge ien hiel lyts bytsje. Fan ’e echte klant, ûndersykje it antwurd fan ’e namme en de keazen rûte, en doch dan in autorisearre HTTPS-oanfraach nei de tsjinst dy’t jo oanbelanget. As de oanfraach de tsjinst berikt en wurdt ôfwiisd, sjoch dan nei de oanmeldgegevens, IAM en elk jildich tsjinstperimeterbelied.
Privee rûtering jout gjin API-autorisaasje en feroaret net wat de identiteit dwaan mei. Ferfierssukses en in autorisearre antwurd binne aparte resultaten, en jo hawwe beide nedich. Hâld ek it IPv6-paad eksplisyt, want it konfigurearjen fan ’e IPv4-foarheaksels seit neat oer in klant dy’t IPv6 foarkomt.
De hânlieding fan Google oer Private Google Access fan it pleatslike netwurk behannelet de DNS-records en de rûte-easken tegearre, dus fergelykje jo resolver- en advertinsje-ynstellings dêrmei en net mei in forumberjocht. Rin dan deselde oanfraach wer en notearje it antwurd en de rûte yn itselde ticket.