Privátna IP Cloud SQL cez VPN: trasa, ktorú nikto neexportuje

Mnohé tímy veria, že privátna IP Cloud SQL funguje iba zvnútra VPC, a toto presvedčenie pretrváva, pretože zlyhanie vyzerá ako problém databázy. Google dokumentuje prístup zo sietí pripojených cez Cloud VPN alebo Cloud Interconnect. Tieto siete nepotrebujú špeciálnu funkciu databázy, ale dve výmeny trás, ktoré je ľahké nechať napoly nakonfigurované. Tunel sa zdvihne, výpočtové inštancie odpovedajú a spojenie s databázou vyprší — presne tá kombinácia, ktorá posiela ľudí do nesprávnej konzoly.

Mýtus: privátna IP znamená privátna pre VPC

Prístup k privátnym službám je VPC peering medzi vašou sieťou a producentskou sieťou vlastnenou Google. Pridelený rozsah pre službu žije na strane producenta a adresa inštancie je v ňom. Pre tento peering môže databáza vo vašom projekte sedieť na adrese, na ktorú vaša VPC smeruje, hoci ju neobsahuje žiadna vaša explicitná podsiete.

Keďže je to peering, má aj peeringové správanie, vrátane tej časti, kde vlastné trasy automaticky neprechádzajú.

Mýtus: funkčný tunel nesie trasu databázy so sebou

Dva rozsahy musia cestu prežiť. Prvý je klientsky prefix: vaša lokálna sieť musí byť Cloud Routeru známa s konkrétnymi prefixami, pretože predvolená trasa nemôže dodať import, ktorý producentská sieť potrebuje pre spiatočnú cestu. Druhý je pridelený rozsah služby, ktorý sa vonkajšia strana musí naučiť, aby jej pakety k databáze mali kam ísť. Sú to rôzne trasy udržiavané na rôznych hraniciach a oprava jednej nechá druhú pokazenú.

Na strane Google to znamená zapnúť Export custom routes na príslušných peeringových spojeniach a pridať pridelený rozsah služby do inzerovaných trás Cloud Routera pre tunel.

Zachovajte inzeráty, ktoré už existujú. Pridanie rozsahu služby nesmie odstrániť trasy VPC, ktoré tá istá BGP relácia nesie pre inú prevádzku, a sada inzerátov nahradená celá je druhý výpadok skrytý za prvým. Skontrolujte aj efektívne trasy na vonkajšom zariadení, pretože dosiahnutie VPN brány alebo inej podsiete dokazuje iba transport.

Mýtus: Cloud SQL Auth Proxy rieši sieť

The Auth Proxy poskytuje podporovanú autentifikáciu a šifrovaný transport medzi vašou aplikáciou a inštanciou. Nevytvára trasu. Proxy spustené na hostiteľovi bez cesty do privátnej siete zlyhá rovnako ako priame spojenie a jeho záznamy budú o dôvode menej užitočné. Presun proxy na hostiteľa, ktorý má konektivitu, mení, ktorá časť cesty musí fungovať, a to je skutočné dizajnové rozhodnutie, nie obchádzka.

Čo nerobí: neumožní odpojenému notebooku dosiahnuť inštanciu dostupnú iba privátne.

Mýtus: Private Service Connect sa riadi rovnakými pravidlami

Private Service Connect používa endpoint vo vašej vlastnej podsieti a usporiadanie DNS, ktoré ovládate, takže trasa k nemu je bežná trasa k adrese, ktorú vlastníte. Nastavenia exportu peeringu sa na tento dizajn nevzťahujú a kopírovanie peeringových zmien do nasadenia PSC pridáva riziko bez pridania dostupnosti.

Obe vám dajú privátnu adresu; podobnosť sa tam končí.

Otestujte cestu v správnom poradí

Z vonkajšieho klienta otestujte najprv TCP endpoint databázy. Dokončený TCP handshake znamená, že smerovanie, firewall aj listener sú na mieste, a ďalším testom je povolená autentizovaná operácia. Odmietnutie autentifikácie je v tom momente vlastne dobrá správa, pretože dokazuje, že listener databázy odpovedal. Vypršanie ICMP o prístupe k databáze nehovorí takmer nič, pretože mnohé cesty ho zahadzujú, zatiaľ čo TCP prenášajú bez problémov.

Ak sú vaše klientske rozsahy mimo RFC 1918, prejdite dodatočné požiadavky na export trás a autorizáciu siete, skôr než usúdite, že dizajn nie je podporovaný.

Zaznamenajte štyri objekty spolu so spojením: vonkajší prefix, pridelený rozsah služby, zapojené peeringové spojenia a router, ktorý inzeruje. Tieto štyri vysvetľujú celú privátnu cestu a nahrádzajú povesť, že Cloud SQL buď vždy potrebuje proxy, alebo cez VPN vôbec nie je dosiahnuteľný.