Daudzas komandas uzskata, ka Cloud SQL privātā IP darbojas tikai VPC iekšpusē, un šis uzskats saglabājas, jo kļūme izskatās pēc datubāzes problēmas. Google dokumentē piekļuvi no tīkliem, kas savienoti ar Cloud VPN vai Cloud Interconnect. Šiem tīkliem vajag nevis īpašu datubāzes funkciju, bet divas maršruta apmaiņas, ko viegli atstāt pusceļā konfigurētas. Tunelis paceļas, skaitļošanas instances atbild, un datubāzes savienojums beidzas ar taimautu — tieši tā kombinācija, kas cilvēkus aizsūta uz nepareizo konsoli.

Mīts: privātā IP nozīmē privātu attiecībā pret VPC

Piekļuve privātajiem pakalpojumiem ir VPC peering starp jūsu tīklu un Google piederošu ražotāja tīklu. Pakalpojumam piešķirtais diapazons atrodas ražotāja pusē, un instances adrese ir tā iekšpusē. Šī peering dēļ datubāze jūsu projektā var atrasties adresē, uz kuru jūsu VPC maršrutē, lai gan neviena jūsu skaidrā apakštīkla to nesatur.

Tā kā tas ir peering, tam ir arī peering uzvedība, tostarp tā daļa, kur pielāgotie maršruti automātiski nešķērso.

Mīts: strādājošs tunelis nes datubāzes maršrutu līdzi

Divi diapazoni iztur šo ceļu. Pirmais ir klienta prefikss: jūsu vietējam tīklam jābūt zināmam Cloud Router ar konkrētiem prefiksiem, jo noklusējuma maršruts nevar nodrošināt importu, kas ražotāja tīklam vajadzīgs atpakaļceļam. Otrais ir piešķirtais pakalpojuma diapazons, kas ārējai pusei jāiemācās, lai tās paketiem uz datubāzi būtu kur iet. Tie ir dažādi maršruti, kas uzturēti dažādās robežās, un viena salabošana otru atstāj salauztu.

Google pusē tas nozīmē Export custom routes iespējošanu attiecīgajos peering savienojumos un piešķirtā pakalpojuma diapazona pievienošanu Cloud Router izsludinātajiem tuneļa maršrutiem.

Saglabājiet jau esošos izsludinājumus. Pakalpojuma diapazona pievienošana nedrīkst noņemt VPC maršrutus, ko tā pati BGP sesija nes citam trafikam, un pilnībā aizstāts izsludinājumu kopums ir otra kļūme, kas paslēpta aiz pirmās. Pārbaudiet arī efektīvos maršrutus ārējā ierīcē, jo VPN vārtejas vai citas apakštīkla sasniegšana pierāda tikai transportu.

Mīts: Cloud SQL Auth Proxy atrisina tīklu

The Auth Proxy nodrošina atbalstītu autentifikāciju un šifrētu transportu starp jūsu lietojumprogrammu un instanci. Tas neveido maršrutu. Starpniekserveris, kas palaists resursdatorā bez ceļa uz privāto tīklu, neizdosies tieši tāpat kā tiešs savienojums, un tā žurnāli būs mazāk noderīgi par iemeslu. Starpniekservera pārvietošana uz resursdatoru, kuram ir savienojamība, maina to, kura ceļa daļa ir jādarbojas, un tas ir īsts dizaina lēmums, nevis apietais risinājums.

Ko tas nedara — neļauj atvienotam portatīvajam datoram sasniegt tikai privātu instanci.

Mīts: Private Service Connect ievēro tos pašus noteikumus

Private Service Connect izmanto endpoint jūsu pašu apakštīklā un DNS kārtību, ko kontrolējat jūs, tāpēc maršruts uz to ir parasts maršruts uz adresi, kas pieder jums. Peering eksporta iestatījumi šim dizainam neattiecas, un peering izmaiņu kopēšana PSC izvietojumā pievieno risku, nepievienojot sasniedzamību.

Abi dod jums privātu adresi; līdzība tur beidzas.

Pārbaudiet ceļu pareizajā secībā

No ārējā klienta vispirms pārbaudiet datubāzes TCP endpointu. Pabeigta TCP rokas spiediena rezultātā maršrutēšana, ugunsmūris un klausītājs ir savās vietās, un nākamais tests ir atļauta autentificēta darbība. Autentifikācijas atteikums tajā brīdī faktiski ir laba ziņa, jo pierāda, ka datubāzes klausītājs ir atbildējis. ICMP taimauts par piekļuvi datubāzei gandrīz neko nepasaka, jo daudzi ceļi to izmet, vienlaikus bez problēmām pārsūtot TCP.

Ja jūsu klienta diapazoni ir ārpus RFC 1918, pārskatiet papildu maršrutu eksporta un tīkla autorizācijas prasības, pirms secināt, ka dizains netiek atbalstīts.

Pierakstiet četrus objektus kopā ar savienojumu: ārējo prefiksu, piešķirto pakalpojuma diapazonu, iesaistītos peering savienojumus un maršrutētāju, kas izsludina. Šie četri izskaidro visu privāto ceļu, un tie aizstāj teiku, ka Cloud SQL vai nu vienmēr vajag starpniekserveri, vai arī to vispār nevar sasniegt pār VPN.

Saistītie raksti