IP-ja private e Cloud SQL përmes VPN: rruga që askush nuk e eksporton

Shumë ekipe besojnë se IP-ja private e Cloud SQL funksionon vetëm nga brenda VPC-së, dhe besimi vazhdon sepse dështimi duket si problem i bazës së të dhënave. Google dokumenton aksesin nga rrjetet e lidhura përmes Cloud VPN ose Cloud Interconnect. Këtyre rrjeteve nuk u duhet një funksion i veçantë i bazës së të dhënave, por dy shkëmbime rrugësh që lihen lehtësisht gjysmë të konfiguruara. Tuneli ngrihet, instancat e llogaritjes përgjigjen dhe lidhja me bazën e të dhënave skadon — pikërisht kombinimi që i dërgon njerëzit në konsolën e gabuar.

Miti: IP private do të thotë private për VPC-në

Aksesi në shërbimet private është një peering VPC midis rrjetit tuaj dhe një rrjeti prodhuesi në pronësi të Google. Diapazoni i akorduar për shërbimin ndodhet në anën e prodhuesit, dhe adresa e instancës është brenda tij. Për shkak të këtij peering, një bazë e të dhënave në projektin tuaj mund të qëndrojë në një adresë ku VPC-ja juaj rrugëton, edhe pse asnjë nënrrjet i juaj eksplicit nuk e përmban atë.

Meqenëse është peering, ka edhe sjellje peering, duke përfshirë pjesën ku rrugët e personalizuara nuk kalojnë automatikisht.

Miti: një tunel që funksionon e mbart rrugën e bazës së të dhënave me vete

Dy diapazone duhet t'i mbijetojnë udhëtimit. I pari është prefiksi i klientit: rrjeti juaj lokal duhet të njihet nga Cloud Router me prefikse konkrete, sepse një rrugë e parazgjedhur nuk mund të ofrojë importin që rrjeti i prodhuesit ka nevojë për rrugën e kthimit. I dyti është diapazoni i akorduar i shërbimit, të cilin ana e jashtme duhet ta mësojë që paketat e saj drejt bazës së të dhënave të kenë ku të shkojnë. Këto janë rrugë të ndryshme të mirëmbajtura në kufij të ndryshëm, dhe rregullimi i njërës e lë tjetrën të thyer.

Nga ana e Google, kjo do të thotë të aktivizoni Export custom routes në lidhjet përkatëse të peering dhe të shtoni diapazonin e akorduar të shërbimit te rrugët e shpallura të Cloud Router për tunelin.

Mbani reklamat që ekzistojnë tashmë. Shtimi i diapazonit të shërbimit nuk duhet të heqë rrugët e VPC-së që e njëjta sesion BGP mbart për trafik tjetër, dhe një grup reklamash i zëvendësuar në tërësi është një ndërprerje e dytë e fshehur pas së parës. Kontrolloni edhe rrugët efektive në pajisjen e jashtme, sepse arritja e portës VPN ose e një nënrrjeti tjetër vërteton vetëm transportin.

Miti: Cloud SQL Auth Proxy e zgjidh rrjetin

The Auth Proxy ofron vërtetim të mbështetur dhe transport të kriptuar midis aplikacionit tuaj dhe instancës. Nuk krijon një rrugë. Një proxy i nisur në një strehues pa rrugë drejt rrjetit privat do të dështojë saktësisht siç do të dështonte një lidhje e drejtpërdrejtë, dhe regjistrat e tij do të jenë më pak të dobishëm për arsyen. Kalimi i proxy-t në një strehues që ka lidhje ndryshon cila pjesë e rrugës duhet të funksionojë, dhe ky është një vendim real projektimi, jo një anashkalim.

Ajo që nuk bën është t'i lejojë një laptopi të shkëputur të arrijë një instancë vetëm private.

Miti: Private Service Connect ndjek të njëjtat rregulla

Private Service Connect përdor një endpoint në nënrrjetin tuaj dhe një rregullim DNS që ju kontrolloni, kështu që rruga drejt tij është një rrugë e zakonshme drejt një adrese që zotëroni. Cilësimet e eksportit të peering nuk zbatohen për atë dizajn, dhe kopjimi i ndryshimeve të peering në një vendosje PSC shton rrezik pa shtuar arritshmëri.

Të dyja ju japin një adresë private; ngjashmëria mbaron aty.

Testoni rrugën në rendin e duhur

Nga klienti i jashtëm, testoni së pari endpoint-in TCP të bazës së të dhënave. Një shtrëngim duarsh TCP i përfunduar do të thotë që rrugëtimi, muri i zjarrit dhe dëgjuesi janë të gjithë në vend, dhe testi i radhës është një operacion i vërtetuar i lejuar. Një refuzim i vërtetimit është në atë moment në fakt një lajm i mirë, sepse provon që një dëgjues i bazës së të dhënave u përgjigj. Një skadim ICMP nuk thotë pothuajse asgjë për aksesin në bazën e të dhënave, sepse shumë rrugë e hedhin atë ndërsa përçojnë TCP pa problem.

Nëse diapazonet e klientit tuaj janë jashtë RFC 1918, rishikoni kërkesat shtesë për eksportin e rrugëve dhe autorizimin e rrjetit përpara se të arrini në përfundimin se dizajni nuk mbështetet.

Regjistroni katër objekte me lidhjen: prefiksin e jashtëm, diapazonin e akorduar të shërbimit, lidhjet e peering të përfshira dhe ruterin që shpall. Ato katër shpjegojnë të gjithë rrugën private dhe zëvendësojnë legjendën se Cloud SQL ose ka gjithmonë nevojë për një proxy ose nuk arrihet fare përmes VPN.