Google API per VPN: maršrutizuokite VIP, o ne vien potinklį
Maršrutas į VPC potinklį neparenka API VIP adresų. Išspręskite teisingus vardus, skelbkite VIP priešdėlį, išsaugokite VPC grįžtamąjį kelią ir tada patikrinkite HTTPS.
Prisijunkite prie vietinio serverio per SSH, pakelkite tunelį ir privati VM atsako; tada pirmas Google API kvietimas nepavyksta be maršruto. VM potinklis ir API VIP adresai yra skirtingos paskirties vietos, todėl vieno maršrutas neparenka kito. Trys sąlygos turi galioti, kad privatus API kvietimas veiktų. API vardas turi išsispręsti į VIP, VIP priešdėlis turi būti skelbiamas per tunelį, o VPC turi žinoti, kaip atsakymą grąžinti. Ping nieko apie tai nepasako, o veikianti SSH sesija į mašiną potinklyje taip pat ne.
API VIP adresai yra atskiros paskirties vietos
Google skelbia atskirus VIP adresus API prieigai iš vietinio tinklo, ir būtent šiuos adresus jūsų DNS turi grąžinti API vardams. Abu yra maži priešdėliai ir nė vienas nėra RFC 1918 erdvė:
| 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 |
Viešai atrodantys adresai nereiškia, kad maršrutas turi palikti tunelį įprastam internetui. Priešdėliai egzistuoja tam, kad vietinis klientas pasiektų Google frontendus palaikomu keliu, o ne savavališku išėjimo tašku. Traktuokite juos kaip paskirties vietas, priklausančias tuneliui, o ne kaip tikrinamus hostus. Interneto išėjimui parašyta ugniasienės taisyklė paprastai juos atmeta, ir tai dažna priežastis, kodėl kvietimas nepavyksta dar neprasidėjęs.
DNS nusprendžia, kurį galinį tašką pasiekiate
Nukreipkite vietinį resolverį į įrašus, kuriuos Google dokumentuoja pasirinktam galiniam taškui, kad aplikacijai reikalingi vardai atsakytų tuo VIP. Vien googleapis.com nėra inventorius: paketų registrai, konteinerių registrai ir migracijos jungtys turi savo dokumentuotus vardus. Apribotas VIP taip pat neperduoda kiekvienos paslaugos, todėl išspręstas vardas vis tiek gali būti nepalaikomas. Užrašykite domenus, su kuriais aplikacija iš tikrųjų susisiekia, prieš liesdami resolverį.
Spėlioti VPC VM adresą vietoj paslaugos vardo nėra taisymas, ir tai paprastai slepia DNS spragą, kol nepavyksta kitas klientas.
Skelbkite VIP priešdėlį, išsaugokite likusius
Su BGP pagrįstu ryšiu Cloud Router turi skelbti pasirinktą VIP priešdėlį, kad vietinis maršrutizatorius išmoktų tą diapazoną per numatytą sesiją. Skelbti vien VPC potinklius to diapazono neprideda, ir vietinis maršrutizatorius toliau naudoja savo numatytąjį kelią tiems adresams. Priešdėlis maršrutų lentelėje yra vienintelis įrodymas, kad skelbimas perėjo sesiją.
Išsaugokite esamus skelbimus, kol pridedate naują, nes maršrutizatoriaus lygio ir peer lygio parinktys turi skirtingą aprėptį, o rinkinio pakeitimas gali atšaukti tinklus, kurie jau veikė. Tada tikrinkite veiksmingą skelbimą kiekvienoje sesijoje, o ne visame maršrutizatoriuje. Trūkstamas priešdėlis ir atšauktas priešdėlis iš vietinės pusės atrodo vienodai, todėl būtent sesijos vaizdas atskiria praleidimą nuo regresijos.
VPC pusei reikia savo maršruto ir grįžtamojo kelio
VPC viduje VIP kelias turi naudoti numatytąjį interneto šliuzą kaip kitą šuolį, ir nepaisant pavadinimo šis srautas lieka Google tinkle. VPC taip pat reikia maršruto atgal į vietinį šaltinį per VPN, ir tai yra atskiras objektas nuo skelbiamo priešdėlio. Atsižvelkite į dokumentuotus regioninius maršrutizavimo reikalavimus, kai tunelis ir klientas yra ne tame pačiame regione.
Tikrinkite grįžtamąjį kelią atskirai, nes veikianti užklausos kryptis gali paslėpti sugedusią atsakymo kryptį. Dvi kryptys, du maršrutai, ir kiekvienas nepavyksta su savo simptomu.
Išbandykite užklausą, tada perskaitykite atmetimą
ICMP aidas negauna atsakymo iš šių VIP adresų, todėl nepavykęs ping nieko neįrodo, o sėkmingas labai mažai. Iš tikrojo kliento patikrinkite vardo atsakymą ir pasirinktą maršrutą, tada išsiųskite įgaliotą HTTPS užklausą paslaugai, kuri jums svarbi. Jei užklausa pasiekia paslaugą ir yra atmetama, pažiūrėkite prisijungimo duomenis, IAM ir bet kokią taikomą paslaugos perimetro politiką.
Privatus maršrutizavimas nesuteikia API leidimo ir nekeičia, ką tapatybė gali daryti. Transporto sėkmė ir įgaliotas atsakymas yra atskiri rezultatai, ir jums reikia abiejų. Išlaikykite ir IPv6 kelią aiškų, nes IPv4 priešdėlių konfigūravimas nieko nesako apie klientą, kuris teikia pirmenybę IPv6.
Google vadovas apie Private Google Access iš vietinio tinklo kartu apima DNS įrašus ir maršrutizavimo reikalavimus, todėl palyginkite resolverio ir skelbimo nustatymus su juo, o ne su forumo įrašu. Tada pakartokite tą pačią užklausą ir užsirašykite atsakymą bei maršrutą tame pačiame biliete.