Google API preko VPN-a: rutirajte VIP, ne samo podmrežu
Ruta do podmreže u VPC-u ne odabire VIP adrese API-ja. Razriješite prava imena, oglašavajte VIP prefiks, zadržite povratnu putanju u VPC-u, pa testirajte HTTPS.
Uđite SSH-om na lokalni server, podignite tunel i privatna VM odgovara; zatim prvi poziv na Google API ne uspijeva bez rute. Podmreža VM-a i VIP adrese API-ja su različita odredišta, pa ruta za jedno ne odabire drugo. Tri uslova moraju biti ispunjena prije nego privatni poziv API-ja može raditi. Ime API-ja mora se razriješiti u VIP, VIP prefiks mora biti oglašen kroz tunel, a VPC mora znati kako poslati odgovor natrag. Ping vam ne kaže ništa od toga, a ni radna SSH sesija na mašinu u podmreži.
VIP adrese API-ja su odvojena odredišta
Google objavljuje namjenske VIP adrese za pristup API-ju iz lokalne mreže, i to su adrese koje vaš DNS mora vraćati za imena API-ja. Obje su mali prefiksi i nijedna nije 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 |
Adrese koje izgledaju javno ne znače da ruta treba napustiti tunel za obični internet. Prefiksi postoje da bi lokalni klijent mogao doći do Googleovih prednjih dijelova podržanim putem umjesto proizvoljne izlazne točke. Tretirajte ih kao odredišta koja pripadaju tunelu, a ne kao hostove za ispitivanje. Pravilo vatrozida napisano za internetski izlaz obično ih odbacuje, i to je čest razlog zašto poziv ne uspije prije nego što počne.
DNS odlučuje koju krajnju točku dosežete
Usmjerite lokalni resolver na zapise koje Google dokumentira za odabranu krajnju točku, tako da imena koja aplikacija treba odgovaraju tim VIP-om. Samo googleapis.com nije popis: registri paketa, registri kontejnera i migracijski konektori imaju svoja dokumentirana imena. Ograničeni VIP također ne nosi svaku uslugu, pa ime koje se razriješi može i dalje biti nepodržano. Zapišite domene koje aplikacija stvarno kontaktira prije nego što dirate resolver.
Pogađanje adrese VM-a u VPC-u kao zamjene za ime usluge nije popravka, i obično skriva prazninu u DNS-u dok ne padne neki drugi klijent.
Oglašavajte VIP prefiks, zadržite ostalo
Uz vezu zasnovanu na BGP-u, Cloud Router mora oglašavati odabrani VIP prefiks kako bi lokalni ruter mogao naučiti taj raspon kroz predviđenu sesiju. Oglašavanje samo VPC podmreža ne dodaje taj raspon, a lokalni ruter nastavlja koristiti svoju zadanu putanju za te adrese. Prefiks u tablici rutiranja jedini je dokaz da je oglas prešao sesiju.
Zadržite postojeće oglase dok dodajete novi, jer opcije na razini rutera i na razini peera imaju različit doseg, a zamjena skupa može povući mreže koje su već radile. Zatim provjerite efektivni oglas na svakoj sesiji, a ne na ruteru kao cjelini. Prefiks koji nedostaje i povučeni prefiks izgledaju isto s lokalne strane, pa upravo prikaz sesije razlikuje propust od regresije.
Strana VPC-a treba vlastitu rutu i povratnu putanju
Unutar VPC-a, putanja do VIP-a mora koristiti zadani internet gateway kao sljedeći skok, i uprkos imenu taj promet ostaje unutar Googleove mreže. VPC također treba rutu natrag do lokalnog izvora kroz VPN, što je odvojen objekt od oglašenog prefiksa. Uzmite u obzir dokumentirane regionalne zahtjeve rutiranja kada tunel i klijent nisu u istoj regiji.
Provjerite povratnu putanju neovisno, jer radni smjer zahtjeva može sakriti pokvaren smjer odgovora. Dva smjera, dvije rute, i svaki ne uspijeva sa svojim simptomom.
Testirajte zahtjev, pa pročitajte odbijanje
ICMP echo ne dobija odgovor od ovih VIP adresa, pa neuspjeli ping ništa ne dokazuje, a uspješni vrlo malo. Sa stvarnog klijenta pregledajte odgovor imena i odabranu rutu, zatim uputite ovlašteni HTTPS zahtjev usluzi koja vas zanima. Ako zahtjev stigne do usluge i bude odbijen, pogledajte vjerodajnice, IAM i svaku politiku perimetra usluge koja se primjenjuje.
Privatno rutiranje ne daje autorizaciju za API i ne mijenja šta identitet smije raditi. Uspjeh prijenosa i ovlašteni odgovor odvojeni su rezultati, i potrebno vam je oboje. Držite i IPv6 putanju eksplicitnom, jer konfigurisanje IPv4 prefiksa ne govori ništa o klijentu koji preferira IPv6.
Vodič kompanije Google za Private Google Access iz lokalne mreže pokriva DNS zapise i zahtjeve rutiranja zajedno, pa uporedite postavke resolvera i oglašavanja s njim, a ne s objavom na forumu. Zatim ponovite isti zahtjev i zabilježite odgovor i rutu u istom tiketu.