API Google prek VPN: usmerite VIP, ne le podomrežja
Pot do podomrežja v VPC ne izbere VIP naslovov API. Razrešite prava imena, oglašujte predpono VIP, ohranite povratno pot v VPC in nato preizkusite HTTPS.
Prijavite se prek SSH v lokalni strežnik, dvignite tunel in zasebni VM odgovori; nato prvi klic na Google API ne uspe brez poti. Podomrežje VM in VIP naslovi API so različni cilji, zato pot do enega ne izbere drugega. Trije pogoji morajo veljati, preden lahko zasebni klic API deluje. Ime API se mora razrešiti v VIP, predpona VIP se mora oglaševati skozi tunel in VPC mora vedeti, kako poslati odgovor nazaj. Ping vam o tem ne pove ničesar, delujoča seja SSH do stroja v podomrežju pa tudi ne.
VIP naslovi API so ločeni cilji
Google objavlja namenske VIP naslove za dostop do API iz lokalnega omrežja in prav te naslove mora vaš DNS vračati za imena API. Oba sta majhni predponi in nobena ni prostor RFC 1918:
| 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 |
Naslovi, ki izgledajo javno, ne pomenijo, da mora pot zapustiti tunel za običajni internet. Predpone obstajajo zato, da lokalni odjemalec doseže sprednje dele Googla po podprti poti namesto skozi poljubno izhodno točko. Obravnavajte jih kot cilje, ki pripadajo tunelu, ne kot gostitelje za preiskovanje. Pravilo požarnega zidu, napisano za internetni izhod, jih običajno zavrže, in to je pogost razlog, da klic ne uspe, še preden se začne.
DNS odloči, do katere končne točke pridete
Usmerite lokalni razreševalnik na zapise, ki jih Google dokumentira za izbrano končno točko, da bodo imena, ki jih aplikacija potrebuje, odgovorila s to VIP. Samo googleapis.com ni popis: registri paketov, registri vsebnikov in migracijski konektorji imajo svoja dokumentirana imena. Tudi omejena VIP ne nosi vsake storitve, zato je ime, ki se razreši, lahko še vedno nepodprto. Preden se dotaknete razreševalnika, zapišite domene, s katerimi aplikacija v resnici komunicira.
Ugibanje naslova VM v VPC namesto imena storitve ni popravek in običajno skrije vrzel v DNS, dokler ne odpove drug odjemalec.
Oglašujte predpono VIP, obdržite ostalo
Pri povezavi na osnovi BGP mora Cloud Router oglaševati izbrano predpono VIP, da se lokalni usmerjevalnik nauči tega obsega skozi predvideno sejo. Oglaševanje samo podomrežij VPC tega obsega ne doda, lokalni usmerjevalnik pa za te naslove še naprej uporablja svojo privzeto pot. Predpona v usmerjevalni tabeli je edini dokaz, da je oglas prešel sejo.
Obstoječe oglase ohranite, medtem ko dodajate novega, ker imajo možnosti na ravni usmerjevalnika in na ravni partnerja različen doseg, zamenjava nabora pa lahko umakne omrežja, ki so že delovala. Nato preverite dejanski oglas v vsaki seji, ne na usmerjevalniku kot celoti. Manjkajoča predpona in umaknjena predpona sta z lokalne strani videti enako, zato prav pogled seje loči izpustitev od regresije.
Stran VPC potrebuje svojo pot in povratno pot
Znotraj VPC mora pot do VIP uporabiti privzeti internetni prehod kot naslednji skok, in kljub imenu ta promet ostane v omrežju Googla. VPC potrebuje tudi pot nazaj do lokalnega vira prek VPN, kar je ločen objekt od oglaševane predpone. Upoštevajte dokumentirane regionalne zahteve usmerjanja, ko tunel in odjemalec nista v isti regiji.
Povratno pot preverite neodvisno, ker delujoča smer zahteve lahko skrije pokvarjeno smer odgovora. Dve smeri, dve poti in vsaka ne uspe s svojim simptomom.
Preizkusite zahtevo in nato preberite zavrnitev
Odmev ICMP od teh VIP ne dobi odgovora, zato neuspešen ping ne dokaže ničesar, uspešen pa zelo malo. Pri dejanskem odjemalcu preglejte odgovor imena in izbrano pot, nato pošljite pooblaščeno zahtevo HTTPS storitvi, ki vas zanima. Če zahteva doseže storitev in je zavrnjena, poglejte poverilnice, IAM in morebitno veljavno politiko obsega storitve.
Zasebno usmerjanje ne podeli avtorizacije API in ne spremeni, kaj identiteta sme početi. Uspeh prenosa in pooblaščen odgovor sta ločena rezultata in potrebujete oba. Tudi pot IPv6 naj bo izrecna, ker konfiguracija predpon IPv4 ne pove ničesar o odjemalcu, ki daje prednost IPv6.
Googlov vodnik za Private Google Access iz lokalnega omrežja pokriva zapise DNS in zahteve usmerjanja skupaj, zato primerjajte svoje nastavitve razreševalnika in oglaševanja z njim in ne z objavo na forumu. Nato znova izvedite isto zahtevo in zabeležite odgovor in pot v isti zahtevek.