Google API cez VPN: smerujte VIP, nie len podsieti
Trasa do podsiete vo VPC nevyberá VIP adresy API. Preložte správne názvy, inzerujte prefix VIP, zachovajte spiatočnú cestu vo VPC a potom otestujte HTTPS.
Prihláste sa cez SSH na lokálny server, zdvihnite tunel a privátna VM odpovedá; potom prvé volanie Google API zlyhá bez trasy. Podsieť VM a VIP adresy API sú rôzne cieľové miesta, takže trasa k jednému nevyberá druhé. Tri podmienky musia platiť, aby privátne volanie API mohlo fungovať. Názov API sa musí preložiť na VIP, prefix VIP sa musí inzerovať tunelom a VPC musí vedieť, ako poslať odpoveď späť. Ping vám nič z toho nepovie a funkčná SSH relácia k stroju v podsieti tiež nie.
VIP adresy API sú samostatné cieľové miesta
Google publikuje vyhradené VIP adresy pre prístup k API z lokálnej siete a práve tieto adresy musí váš DNS vracať pre názvy API. Obe sú malé prefixy a ani jedna nie je priestor 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 |
Adresy, ktoré vyzerajú verejne, neznamenajú, že trasa má opustiť tunel pre bežný internet. Prefixy existujú preto, aby lokálny klient dosiahol frontendy Google podporovanou cestou namiesto ľubovoľného výstupného bodu. Berte ich ako cieľové miesta, ktoré patria tunelu, nie ako hostiteľov na testovanie. Pravidlo firewallu napísané pre internetový výstup ich zvyčajne zahodí, a to je častý dôvod, prečo volanie zlyhá skôr, než začne.
DNS rozhoduje, na ktorý koncový bod sa dostanete
Nasmerujte lokálny resolver na záznamy, ktoré Google dokumentuje pre zvolený koncový bod, aby názvy, ktoré aplikácia potrebuje, odpovedali touto VIP. Samotné googleapis.com nie je inventár: registre balíkov, registre kontajnerov a migračné konektory majú svoje vlastné dokumentované názvy. Obmedzená VIP tiež nenesie každú službu, takže názov, ktorý sa preloží, môže byť stále nepodporovaný. Predtým, než sa dotknete resolvera, zapíšte domény, s ktorými aplikácia skutočne komunikuje.
Hádanie adresy VM vo VPC namiesto názvu služby nie je oprava a zvyčajne skrýva medzeru v DNS, kým nezlyhá iný klient.
Inzerujte prefix VIP, zvyšok zachovajte
Pri pripojení založenom na BGP musí Cloud Router inzerovať zvolený prefix VIP, aby sa lokálny router naučil tento rozsah cez zamýšľanú reláciu. Inzerovanie samotných podsietí VPC tento rozsah nepridá a lokálny router pre tieto adresy ďalej používa svoju predvolenú cestu. Prefix v smerovacej tabuľke je jediným dôkazom, že inzercia prešla reláciou.
Zachovajte existujúce inzercie, kým pridávate novú, pretože možnosti na úrovni routera a na úrovni partnera majú iný dosah a výmena množiny môže stiahnuť siete, ktoré už fungovali. Potom skontrolujte efektívnu inzerciu na každej relácii, nie na routeri ako celku. Chýbajúci prefix a stiahnutý prefix vyzerajú z lokálnej strany rovnako, takže práve pohľad relácie oddeľuje opomenutie od regresie.
Strana VPC potrebuje vlastnú trasu a spiatočnú cestu
Vo vnútri VPC musí cesta k VIP použiť predvolenú internetovú bránu ako ďalší skok a napriek názvu tento prenos zostáva v sieti Google. VPC tiež potrebuje trasu späť k lokálnemu zdroju cez VPN, a to je samostatný objekt od inzerovaného prefixu. Zohľadnite dokumentované regionálne požiadavky na smerovanie, keď tunel a klient nie sú v tom istom regióne.
Spiatočnú cestu kontrolujte nezávisle, pretože fungujúci smer požiadavky môže skryť pokazený smer odpovede. Dva smery, dve trasy a každá zlyháva s vlastným príznakom.
Otestujte požiadavku a potom si prečítajte odmietnutie
ICMP echo od týchto VIP adries nedostane odpoveď, takže neúspešný ping nič nedokazuje a úspešný veľmi málo. Z reálneho klienta skontrolujte odpoveď názvu a zvolenú trasu, potom odošlite autorizovanú HTTPS požiadavku na službu, ktorá vás zaujíma. Ak požiadavka dorazí do služby a je odmietnutá, pozrite sa na prihlasovacie údaje, IAM a akúkoľvek uplatniteľnú politiku perimetra služby.
Privátne smerovanie neudeľuje autorizáciu API a nemení, čo identita smie robiť. Úspech transportu a autorizovaná odpoveď sú oddelené výsledky a potrebujete oba. Držte explicitnú aj cestu IPv6, pretože konfigurácia prefixov IPv4 nič nehovorí o klientovi, ktorý uprednostňuje IPv6.
Príručka Google pre Private Google Access z lokálnej siete pokrýva záznamy DNS a požiadavky na smerovanie spolu, takže porovnajte nastavenia resolvera a inzercie s ňou, a nie s príspevkom na fóre. Potom zopakujte tú istú požiadavku a poznačte odpoveď aj trasu do toho istého tiketu.