Google API VPN-i kaudu: suuna VIP-i, mitte ainult alamvõrku
Marsruut VPC alamvõrku ei vali API VIP-aadresse. Lahenda õiged nimed, kuuluta VIP-prefiks, hoia VPC-s tagasitee ja seejärel testi HTTPS-i.
Logi SSH-ga kohalikku serverisse sisse, tõsta tunnel üles ja privaatne VM vastab; seejärel ebaõnnestub esimene Google API kutse ilma marsruudita. VM-i alamvõrk ja API VIP-aadressid on erinevad sihtkohad, seega ühe marsruut ei vali teist. Kolm tingimust peavad kehtima, enne kui privaatne API-kutse saab töötada. API nimi peab lahenema VIP-iks, VIP-prefiks peab olema tunneli kaudu kuulutatud ja VPC peab teadma, kuidas vastus tagasi saata. Ping ei ütle sulle sellest midagi, ja töötav SSH-sessioon alamvõrgus olevasse masinasse samuti mitte.
API VIP-aadressid on eraldi sihtkohad
Google avaldab kohalikust võrgust API-le juurdepääsuks eraldi VIP-aadressid ja just need aadressid peab sinu DNS API-nimede jaoks tagastama. Mõlemad on väikesed prefiksid ja kumbki ei ole RFC 1918 ruum:
| 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 |
Avalikuna näivad aadressid ei tähenda, et marsruut peaks tunnelist lahkuma tavalise interneti jaoks. Prefiksid on olemas selleks, et kohalik klient jõuaks Google’i esipindadeni toetatud teed pidi, mitte suvalise väljundpunkti kaudu. Käsitle neid tunnelile kuuluvate sihtkohtadena, mitte hostidena, mida uurida. Interneti väljundi jaoks kirjutatud tulemüürireegel tavaliselt viskab need kõrvale ja see on tavaline põhjus, miks kutse ebaõnnestub enne, kui see algab.
DNS otsustab, millise lõpp-punktini jõuad
Suuna kohalik resolver valitud lõpp-punkti jaoks dokumenteeritud kirjetele, et rakenduse vajalikud nimed vastaksid selle VIP-iga. Ainuüksi googleapis.com ei ole inventuur: paketiregistritel, konteineriregistritel ja migratsioonikonnektoritel on oma dokumenteeritud nimed. Ka piiratud VIP ei kanna iga teenust, seega lahenev nimi võib siiski olla toetuseta. Kirjuta üles domeenid, mida rakendus tegelikult külastab, enne kui resolverit puutud.
VPC VM-aadressi oletamine teenuse nime asendajana ei ole parandus ja tavaliselt varjab DNS-i lünka seni, kuni ebaõnnestub mõni teine klient.
Kuuluta VIP-prefiks, hoia ülejäänu
BGP-l põhineva ühenduse korral peab Cloud Router kuulutama valitud VIP-prefiksi, et kohalik ruuter saaks selle vahemiku kavandatud sessiooni kaudu õppida. Ainult VPC alamvõrkude kuulutamine ei lisa seda vahemikku ja kohalik ruuter jätkab nende aadresside jaoks oma vaiketeega. Marsruutimistabelis olev prefiks on ainus tõestus, et kuulutus läbis sessiooni.
Hoia olemasolevad kuulutused, kui uut lisad, sest ruuteritasandi ja peer-tasandi valikute ulatus erineb ning komplekti vahetamine võib tagasi võtta võrke, mis juba töötasid. Seejärel kontrolli tegelikku kuulutust igas sessioonis, mitte ruuteril tervikuna. Puuduv prefiks ja tagasi võetud prefiks näevad kohalikult poolt ühesugused välja, seega just sessiooni vaade eristab väljajätmist regressioonist.
VPC poolel on vaja oma marsruuti ja tagasiteed
VPC sees peab VIP-i tee kasutama järgmise hüppena vaikimisi internetilüüsi ja vaatamata nimele jääb see liiklus Google’i võrku. VPC-l on vaja ka marsruuti tagasi kohaliku allika juurde VPN-i kaudu, mis on kuulutatud prefiksist eraldi objekt. Arvesta dokumenteeritud piirkondlike marsruutimisnõuetega, kui tunnel ja klient ei ole samas piirkonnas.
Kontrolli tagasiteed iseseisvalt, sest töötav päringusuund võib varjata katkise vastusesuuna. Kaks suunda, kaks marsruuti ja kumbki ebaõnnestub oma sümptomiga.
Testi päringut, seejärel loe keeldumist
ICMP-kaja ei saa nendelt VIP-idelt vastust, seega ebaõnnestunud ping ei tõesta midagi ja õnnestunud tõestab väga vähe. Tegelikust kliendist uuri nime vastust ja valitud marsruuti, seejärel tee volitatud HTTPS-päring teenusele, mis sind huvitab. Kui päring jõuab teenuseni ja see lükatakse tagasi, vaata mandaate, IAM-i ja kõiki kehtivaid teenuse perimeetri poliitikaid.
Privaatne marsruutimine ei anna API volitust ega muuda seda, mida identiteedil on lubatud teha. Transpordi õnnestumine ja volitatud vastus on eraldi tulemused ning sul on vaja mõlemat. Hoia ka IPv6 tee selgesõnaline, sest IPv4 prefiksite seadistamine ei ütle midagi kliendi kohta, kes eelistab IPv6-te.
Google’i juhend Private Google Access kohta kohalikust võrgust katab DNS-kirjed ja marsruutimisnõuded koos, seega võrdle oma resolveri ja kuulutuse seadeid sellega, mitte foorumipostitusega. Seejärel korda sama päringut ja märgi vastus ning marsruut samasse tiketti.