Google API caur VPN: maršrutē VIP, ne tikai apakštīklu
Maršruts uz VPC apakštīklu neizvēlas API VIP adreses. Atrisini pareizos nosaukumus, izsludini VIP prefiksu, saglabā VPC atgriešanās ceļu un pēc tam pārbaudi HTTPS.
Piesakies vietējā serverī ar SSH, pacel tuneli, un privātā VM atbild; tad pirmais Google API izsaukums neizdodas bez maršruta. VM apakštīkls un API VIP adreses ir dažādi galamērķi, tāpēc maršruts uz vienu neizvēlas otru. Trīs nosacījumiem jābūt izpildītiem, lai privāts API izsaukums strādātu. API nosaukumam jāatrisinās uz VIP, VIP prefiksam jābūt izsludinātam caur tuneli, un VPC jāzina, kā atbildi nosūtīt atpakaļ. Ping par to neko nepasaka, un strādājoša SSH sesija uz mašīnu apakštīklā arī ne.
API VIP adreses ir atsevišķi galamērķi
Google publicē atsevišķas VIP adreses API piekļuvei no vietējā tīkla, un tieši šīs adreses tavam DNS jāatgriež API nosaukumiem. Abi ir mazi prefiksi, un neviens nav RFC 1918 telpa:
| 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 |
Adreses, kas izskatās publiskas, nenozīmē, ka maršrutam jāatstāj tunelis parastajam internetam. Prefiksi pastāv tāpēc, lai vietējais klients sasniegtu Google priekšdaļas atbalstītā ceļā, nevis patvaļīgā izejas punktā. Uztver tos kā galamērķus, kas pieder tunelim, nevis kā pārbaudāmus resursdatorus. Ugunsmūra noteikums, kas rakstīts interneta izejai, tos parasti izmet, un tas ir biežs iemesls, kāpēc izsaukums neizdodas pirms sākuma.
DNS izlemj, kuru galapunktu sasniegsi
Novirzi vietējo atrisinātāju uz ierakstiem, ko Google dokumentē izvēlētajam galapunktam, lai lietotnei vajadzīgie nosaukumi atbildētu ar šo VIP. Tikai googleapis.com nav inventārs: pakotņu reģistriem, konteineru reģistriem un migrācijas savienotājiem ir savi dokumentēti nosaukumi. Arī ierobežotā VIP nenes katru pakalpojumu, tāpēc atrisināts nosaukums joprojām var būt neatbalstīts. Pieraksti domēnus, ar kuriem lietotne faktiski sazinās, pirms aiztiec atrisinātāju.
Uzminēt VPC VM adresi pakalpojuma nosaukuma vietā nav labojums, un tas parasti slēpj DNS robu, līdz neizdodas citam klientam.
Izsludini VIP prefiksu, pārējo saglabā
Ar BGP balstītu savienojumu Cloud Router jāizsludina izvēlētais VIP prefikss, lai vietējais maršrutētājs apgūtu šo diapazonu paredzētajā sesijā. Tikai VPC apakštīklu izsludināšana šo diapazonu nepievieno, un vietējais maršrutētājs šīm adresēm turpina izmantot savu noklusējuma ceļu. Prefikss maršrutēšanas tabulā ir vienīgais pierādījums, ka sludinājums šķērsoja sesiju.
Saglabā esošos sludinājumus, kamēr pievieno jauno, jo maršrutētāja līmeņa un vienaudža līmeņa opcijām ir atšķirīgs tvērums, un kopas maiņa var atsaukt tīklus, kas jau strādāja. Pēc tam pārbaudi efektīvo sludinājumu katrā sesijā, nevis visā maršrutētājā. Trūkstošs prefikss un atsaukts prefikss no vietējās puses izskatās vienādi, tāpēc tieši sesijas skats atdala izlaidumu no regresijas.
VPC pusei vajag savu maršrutu un atgriešanās ceļu
VPC iekšienē VIP ceļam jāizmanto noklusējuma interneta vārteja kā nākamais lēciens, un, neraugoties uz nosaukumu, šis trafiks paliek Google tīklā. VPC vajag arī maršrutu atpakaļ uz vietējo avotu caur VPN, un tas ir atsevišķs objekts no izsludinātā prefiksa. Ņem vērā dokumentētās reģionālās maršrutēšanas prasības, kad tunelis un klients nav vienā reģionā.
Pārbaudi atgriešanās ceļu neatkarīgi, jo strādājošs pieprasījuma virziens var paslēpt salauztu atbildes virzienu. Divi virzieni, divi maršruti, un katrs neizdodas ar savu simptomu.
Izmēģini pieprasījumu, pēc tam izlasi atteikumu
ICMP atbalss no šīm VIP nesaņem atbildi, tāpēc neizdevies ping neko nepierāda, bet veiksmīgais ļoti maz. No īstā klienta pārbaudi nosaukuma atbildi un izvēlēto maršrutu, pēc tam nosūti atļautu HTTPS pieprasījumu pakalpojumam, kas tev svarīgs. Ja pieprasījums sasniedz pakalpojumu un tiek atteikts, apskati akreditācijas datus, IAM un jebkuru piemērojamo pakalpojuma perimetra politiku.
Privātā maršrutēšana nepiešķir API atļauju un nemaina to, ko identitāte drīkst darīt. Pārvades veiksme un atļauta atbilde ir atsevišķi rezultāti, un vajag abus. Saglabā arī IPv6 ceļu skaidru, jo IPv4 prefiksu konfigurēšana neko nepasaka par klientu, kas dod priekšroku IPv6.
Google rokasgrāmata par Private Google Access no vietējā tīkla aptver DNS ierakstus un maršrutēšanas prasības kopā, tāpēc salīdzini atrisinātāja un sludinājuma iestatījumus ar to, nevis ar foruma ierakstu. Pēc tam atkārto to pašu pieprasījumu un pieraksti atbildi un maršrutu tajā pašā biļetē.