Privátní IP Cloud SQL přes VPN: trasa, kterou nikdo neexportuje

Mnoho týmů věří, že privátní IP Cloud SQL funguje jen zevnitř VPC, a toto přesvědčení přetrvává, protože selhání vypadá jako problém databáze. Google dokumentuje přístup ze sítí připojených přes Cloud VPN nebo Cloud Interconnect. Tyto sítě nepotřebují zvláštní funkci databáze, ale dvě výměny tras, které je snadné nechat napůl nakonfigurované. Tunel se zvedne, výpočetní instance odpovídají a spojení s databází vyprší — přesně ta kombinace, která lidi posílá do špatné konzole.

Mýtus: privátní IP znamená privátní pro VPC

Přístup k privátním službám je VPC peering mezi vaší sítí a producentskou sítí vlastněnou Googlem. Přidělený rozsah pro službu žije na straně producenta a adresa instance je uvnitř něj. Kvůli tomuto peeringu může databáze ve vašem projektu sedět na adrese, na kterou vaše VPC směruje, aniž by ji obsahovala nějaká vaše explicitní podsíť.

Protože jde o peering, má i peeringové chování, včetně té části, kde vlastní trasy automaticky nepřecházejí.

Mýtus: funkční tunel nese trasu databáze s sebou

Dva rozsahy musí cestu přežít. První je klientský prefix: vaše lokální síť musí být Cloud Routeru známa s konkrétními prefixy, protože výchozí trasa nemůže dodat import, který producentská síť potřebuje pro zpáteční cestu. Druhý je přidělený rozsah služby, který se vnější strana musí naučit, aby její pakety k databázi měly kam jít. To jsou různé trasy udržované na různých hranicích a oprava jedné nechá druhou rozbitou.

Na straně Google to znamená zapnout Export custom routes na příslušných peeringových spojeních a přidat přidělený rozsah služby do inzerovaných tras Cloud Routeru pro tunel.

Zachovejte inzeráty, které už existují. Přidání rozsahu služby nesmí odebrat trasy VPC, které stejná BGP session nese pro jiný provoz, a sada inzerátů nahrazená celá je druhý výpadek skrytý za prvním. Zkontrolujte také efektivní trasy na vnějším zařízení, protože dosažení VPN brány nebo jiné podsítě dokazuje jen transport.

Mýtus: Cloud SQL Auth Proxy řeší síť

The Auth Proxy poskytuje podporovanou autentizaci a šifrovaný transport mezi vaší aplikací a instancí. Nevytváří trasu. Proxy spuštěná na hostiteli bez cesty do privátní sítě selže stejně jako přímé spojení a její logy budou o důvodu méně užitečné. Přesun proxy na hostitele, který konektivitu má, mění, která část cesty musí fungovat, a to je skutečné designové rozhodnutí, ne workaround.

Co nedělá: neumožní odpojenému notebooku dosáhnout instance dostupné jen privátně.

Mýtus: Private Service Connect se řídí stejnými pravidly

Private Service Connect používá endpoint ve vaší vlastní podsíti a uspořádání DNS, které ovládáte, takže trasa k němu je běžná trasa k adrese, kterou vlastníte. Nastavení exportu peeringu se na tento design nevztahují a kopírování peeringových změn do nasazení PSC přidává riziko, aniž by přidávalo dostupnost.

Obě vám dají privátní adresu; podoba tam končí.

Otestujte cestu ve správném pořadí

Z vnějšího klienta otestujte nejprve TCP endpoint databáze. Dokončený TCP handshake znamená, že směrování, firewall i listener jsou na místě, a dalším testem je povolená autentizovaná operace. Odmítnutí autentizace je v tu chvíli vlastně dobrá zpráva, protože dokazuje, že listener databáze odpověděl. Vypršení ICMP o přístupu k databázi neříká téměř nic, protože mnoho cest ho zahazuje, zatímco TCP předává bez problémů.

Pokud jsou vaše klientské rozsahy mimo RFC 1918, projděte dodatečné požadavky na export tras a autorizaci sítě, než usoudíte, že design není podporován.

Zaznamenejte čtyři objekty spolu se spojením: vnější prefix, přidělený rozsah služby, zapojená peeringová spojení a router, který inzeruje. Tyto čtyři vysvětlují celou privátní cestu a nahrazují pověru, že Cloud SQL buď vždy potřebuje proxy, nebo přes VPN vůbec není dosažitelný.