Приватна IP адреса Cloud SQL преко VPN-а: рута коју нико не извози

Многи тимови верују да приватна IP адреса Cloud SQL ради само изнутра VPC-а, и то уверење опстаје зато што квар изгледа као проблем базе података. Google документује приступ из мрежа повезаних преко Cloud VPN-а или Cloud Interconnect-а. Тим мрежама не треба посебна функција базе података, већ две размене рута које је лако оставити полуконфигурисане. Тунел се подигне, рачунске инстанце одговоре, а веза са базом истекне — управо та комбинација која људе шаље у погрешну конзолу.

Мит: приватна IP значи приватна за VPC

Приступ приватним услугама је VPC peering између ваше мреже и мреже произвођача у власништву Google-а. Додељени опсег за услугу живи на страни произвођача, а адреса инстанце је унутар њега. Због тог peering-а база података у вашем пројекту може да седи на адреси ка којој ваша VPC рутира, иако је ниједна ваша експлицитна подмрежа не садржи.

Пошто је peering, има и понашање peering-а, укључујући део у ком прилагођене руте не прелазе аутоматски.

Мит: исправан тунел носи руту базе са собом

Два опсега морају да преживе пут. Први је клијентски префикс: ваша локална мрежа мора бити позната Cloud Router-у са конкретним префиксима, јер подразумевана рута не може да пружи увоз који мрежа произвођача захтева за повратни пут. Други је додељени опсег услуге, који спољна страна мора да научи како би њени пакети ка бази имали где да оду. То су различите руте које се одржавају на различитим границама, а поправка једне оставља другу покварену.

На страни Google-а то значи укључивање Export custom routes на одговарајућим peering везама и додавање додељеног опсега услуге у оглашене руте Cloud Router-а за тунел.

Задржите огласе који већ постоје. Додавање опсега услуге не сме да уклони VPC руте које иста BGP сесија носи за други саобраћај, а сет огласа замењен у целини је други прекид скривен иза првог. Проверите и ефективне руте на спољном уређају, јер достизање VPN пролаза или друге подмреже доказује само транспорт.

Мит: Cloud SQL Auth Proxy решава мрежу

The Auth Proxy пружа подржану аутентификацију и шифровани транспорт између ваше апликације и инстанце. Он не ствара руту. Прокси покренут на домаћину без пута до приватне мреже неће успети исто као директна веза, а његови записи ће бити мање корисни о разлогу. Премештање проксија на домаћина који има повезаност мења који део пута мора да ради, и то је стварна дизајнерска одлука, а не заобилажење.

Оно што не чини јесте да омогући искљученом лаптопу да достигне инстанцу доступну само приватно.

Мит: Private Service Connect следи иста правила

Private Service Connect користи endpoint у вашој сопственој подмрежи и DNS уређење које ви контролишете, па је рута до њега обична рута до адресе коју поседујете. Подешавања извоза peering-а не важе за тај дизајн, а копирање peering промена у PSC распоређивање додаје ризик без додавања доступности.

Оба вам дају приватну адресу; сличност се ту завршава.

Тестирајте пут у исправном редоследу

Са спољног клијента прво тестирајте TCP endpoint базе. Завршено TCP руковање значи да су рутирање, заштитни зид и слушалац сви на месту, а следећи тест је дозвољена аутентификована операција. Одбијање аутентификације је у том тренутку заправо добра вест, јер доказује да је слушалац базе одговорио. Истек ICMP-а не каже готово ништа о приступу бази, јер многи путеви га одбацују док TCP прослеђују без проблема.

Ако су ваши клијентски опсези изван RFC 1918, прегледајте додатне захтеве за извоз рута и ауторизацију мреже пре него што закључите да дизајн није подржан.

Забележите четири објекта уз везу: спољни префикс, додељени опсег услуге, укључене peering везе и рутер који оглашава. Та четири објашњавају цео приватни пут и замењују предање да Cloud SQL или увек захтева прокси или се уопште не може достићи преко VPN-а.