Google API přes VPN: směrujte VIP, ne jen podsíť
Trasa do podsítě ve VPC nevybírá VIP adresy API. Přeložte správná jména, inzerujte prefix VIP, zachovejte zpáteční cestu ve VPC a potom otestujte HTTPS.
Připojte se přes SSH k místnímu serveru, zvedněte tunel a privátní VM odpovídá; pak první volání Google API selže bez trasy. Podsíť VM a VIP adresy API jsou různá cílová místa, takže trasa k jednomu nevybírá druhé. Než privátní volání API může fungovat, musí platit tři podmínky. Název API se musí přeložit na VIP, prefix VIP musí být inzerován tunelem a VPC musí vědět, jak poslat odpověď zpět. Ping vám nic z toho neřekne a funkční SSH relace ke stroji v podsíti také ne.
VIP adresy API jsou samostatná cílová místa
Google publikuje vyhrazené VIP adresy pro přístup k API z místní sítě a právě tyto adresy musí váš DNS vracet pro názvy API. Obě jsou malé prefixy a ani jedna není 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 |
Adresy, které vypadají veřejně, neznamenají, že trasa má opustit tunel pro běžný internet. Prefixy existují proto, aby místní klient dosáhl frontendů Google podporovanou cestou místo libovolného výstupního bodu. Berte je jako cílová místa, která patří tunelu, ne jako hostitele k testování. Pravidlo firewallu napsané pro internetový výstup je obvykle zahodí, a to je častý důvod, proč volání selže dřív, než začne.
DNS rozhoduje, na který koncový bod se dostanete
Nasměrujte místní resolver na záznamy, které Google dokumentuje pro zvolený koncový bod, aby názvy, které aplikace potřebuje, odpovídaly touto VIP. Pouhé googleapis.com není inventář: registr balíčků, registr kontejnerů i migrační konektory mají své vlastní dokumentované názvy. Omezená VIP také nenese každou službu, takže název, který se přeloží, může být stále nepodporovaný. Než sáhnete na resolver, zapište si domény, které aplikace skutečně kontaktuje.
Hádat adresu VM ve VPC jako náhradu za název služby není oprava a obvykle skryje mezeru v DNS, dokud neselže jiný klient.
Inzerujte prefix VIP, zbytek zachovejte
U připojení založeného na BGP musí Cloud Router inzerovat zvolený prefix VIP, aby se místní router mohl naučit tento rozsah přes zamýšlenou relaci. Inzerování samotných podsítí VPC tento rozsah nepřidá a místní router pro tyto adresy dál používá svou výchozí cestu. Prefix v routovací tabulce je jediným důkazem, že inzerce relaci prošla.
Zachovejte stávající inzerce, dokud novou přidáváte, protože volby na úrovni routeru a na úrovni peeru mají jiný dosah a výměna sady může stáhnout sítě, které už fungovaly. Potom zkontrolujte efektivní inzerci na každé relaci, ne na routeru jako celku. Chybějící prefix a stažený prefix vypadají z místní strany stejně, takže právě pohled relace odděluje opomenutí od regrese.
Strana VPC potřebuje vlastní trasu a zpáteční cestu
Uvnitř VPC musí cesta k VIP použít výchozí internetovou bránu jako další skok, a navzdory názvu tento provoz zůstává v síti Google. VPC také potřebuje trasu zpět k místnímu zdroji přes VPN, což je samostatný objekt od inzerovaného prefixu. Počítejte s dokumentovanými regionálními požadavky na směrování, když tunel a klient nejsou ve stejné oblasti.
Zpáteční cestu kontrolujte nezávisle, protože funkční směr požadavku může skrýt rozbitý směr odpovědi. Dva směry, dvě trasy a každá selhává s vlastním příznakem.
Otestujte požadavek a pak si přečtěte odmítnutí
ICMP echo od těchto VIP nedostane odpověď, takže neúspěšný ping nic nedokazuje a úspěšný velmi málo. Ze skutečného klienta zkontrolujte odpověď názvu a zvolenou trasu, potom odešlete autorizovaný HTTPS požadavek na službu, která vás zajímá. Pokud požadavek do služby dorazí a je odmítnut, podívejte se na přihlašovací údaje, IAM a případnou politiku perimetru služby.
Privátní směrování nedává autorizaci API a nemění, co identita smí dělat. Úspěch transportu a autorizovaná odpověď jsou oddělené výsledky a potřebujete oba. Držte explicitní i cestu IPv6, protože konfigurace prefixů IPv4 nic neříká o klientovi, který dává přednost IPv6.
Příručka Google pro Private Google Access z místní sítě pokrývá záznamy DNS a požadavky na směrování společně, takže porovnejte nastavení resolveru a inzerce s ní, a ne s příspěvkem na fóru. Potom zopakujte stejný požadavek a poznamenejte odpověď i trasu do stejného tiketu.