Pribadong IP ng Cloud SQL sa VPN: ang rutang walang nag-e-export

Maraming team ang naniniwala na ang pribadong IP ng Cloud SQL ay gumagana lamang mula sa loob ng VPC, at nagpapatuloy ang paniniwalang ito dahil mukhang problema sa database ang pagkabigo. Dinodokumento ng Google ang pag-access mula sa mga network na konektado sa Cloud VPN o Cloud Interconnect. Ang kailangan ng mga network na iyon ay hindi espesyal na feature ng database, kundi dalawang palitan ng ruta na madaling iwanang kalahating naka-configure. Bumangon ang tunnel, sumasagot ang mga compute instance, at nag-time out ang koneksyon sa database — eksaktong kombinasyon na nagpapadala ng mga tao sa maling console.

Mito: ang pribadong IP ay nangangahulugang pribado sa VPC

Ang pag-access sa mga pribadong serbisyo ay isang VPC peering sa pagitan ng iyong network at ng producer network na pag-aari ng Google. Ang inilaan na saklaw para sa serbisyo ay nasa panig ng producer, at ang address ng instance ay nasa loob nito. Dahil sa peering na iyon, ang isang database sa iyong proyekto ay maaaring nasa isang address na ruta ng iyong VPC nang walang anumang tahasang subnet mo na naglalaman nito.

Dahil peering ito, mayroon din itong pag-uugali ng peering, kasama ang bahagi kung saan hindi awtomatikong tumatawid ang mga custom na ruta.

Mito: ang gumaganang tunnel ay nagdadala ng ruta ng database

Dalawang saklaw ang dapat makalampas sa paglalakbay. Ang una ay ang prefix ng kliyente: dapat kilala ng Cloud Router ang iyong on-premises network na may tiyak na mga prefix, dahil ang default na ruta ay hindi makapagbibigay ng import na kailangan ng producer network para sa pabalik na landas. Ang pangalawa ay ang inilaan na saklaw ng serbisyo, na dapat matutunan ng panlabas na panig upang ang mga packet nito patungo sa database ay may mapupuntahan. Ito ay magkaibang ruta na pinapanatili sa magkaibang hangganan, at ang pag-aayos ng isa ay iniiwan ang isa na sira.

Sa panig ng Google, nangangahulugan ito ng pagpapagana ng Export custom routes sa mga kaugnay na koneksyon ng peering at pagdaragdag ng inilaan na saklaw ng serbisyo sa mga inihayag na ruta ng Cloud Router para sa tunnel.

Panatilihin ang mga anunsyo na naroon na. Ang pagdaragdag ng saklaw ng serbisyo ay hindi dapat mag-alis ng mga ruta ng VPC na dinadala ng parehong session ng BGP para sa ibang trapiko, at ang isang set ng anunsyo na ganap na pinalitan ay pangalawang pagkaantala na nakatago sa likod ng una. Suriin din ang mga epektibong ruta sa panlabas na aparato, dahil ang maabot ang gateway ng VPN o ibang subnet ay nagpapatunay lamang ng transport.

Mito: nilulutas ng Cloud SQL Auth Proxy ang network

The Auth Proxy ay nagbibigay ng sinusuportahang pagpapatunay at naka-encrypt na transport sa pagitan ng iyong aplikasyon at ng instance. Hindi ito gumagawa ng ruta. Ang isang proxy na sinimulan sa host na walang landas patungo sa pribadong network ay mabibigo nang eksakto tulad ng isang direktang koneksyon, at ang mga log nito ay hindi gaanong makakatulong tungkol sa dahilan. Ang paglipat ng proxy sa host na may koneksyon ay nagbabago kung aling bahagi ng landas ang dapat gumana, at iyon ay tunay na desisyon sa disenyo, hindi isang paraan ng pag-iwas.

Ang hindi nito ginagawa ay ang payagan ang isang nakadiskonektang laptop na maabot ang isang instance na pribado lamang.

Mito: sinusunod ng Private Service Connect ang parehong mga patakaran

Gumagamit ang Private Service Connect ng endpoint sa iyong sariling subnet at ng kaayusan ng DNS na kontrolado mo, kaya ang ruta patungo roon ay ordinaryong ruta patungo sa isang address na pag-aari mo. Ang mga setting ng export ng peering ay hindi nalalapat sa disenyong iyon, at ang pagkopya ng mga pagbabago sa peering sa isang deployment ng PSC ay nagdaragdag ng peligro nang walang idinagdag na maabot.

Parehong nagbibigay sa iyo ng pribadong address; doon nagtatapos ang pagkakatulad.

Subukan ang landas sa tamang pagkakasunod-sunod

Mula sa panlabas na kliyente, subukan muna ang TCP endpoint ng database. Ang natapos na TCP handshake ay nangangahulugang naroon ang routing, firewall at listener, at ang susunod na pagsubok ay isang pinahihintulutang na-authenticate na operasyon. Ang pagtanggi sa pagpapatunay sa puntong iyon ay talagang mabuting balita, dahil pinatutunayan nito na sumagot ang isang listener ng database. Ang pag-time out ng ICMP ay halos walang sinasabi tungkol sa pag-access sa database, dahil maraming landas ang nagtatapon nito habang maayos na nagpapasa ng TCP.

Kung ang iyong mga saklaw ng kliyente ay labas ng RFC 1918, suriin ang mga karagdagang pangangailangan sa pag-export ng ruta at awtorisasyon ng network bago magpasya na hindi sinusuportahan ang disenyo.

Itala ang apat na bagay kasama ng koneksyon: ang panlabas na prefix, ang inilaan na saklaw ng serbisyo, ang mga koneksyon ng peering na sangkot at ang router na nag-anunsyo. Ang apat na iyon ay nagpapaliwanag ng buong pribadong landas, at pinapalitan nila ang alamat na ang Cloud SQL ay palaging nangangailangan ng proxy o hindi maabot sa VPN.