Cloud SQL privaatne IP VPN-i kaudu: marsruut, mida keegi ei ekspordi

Paljud meeskonnad usuvad, et Cloud SQL privaatne IP töötab ainult VPC sees, ja see usk püsib, sest tõrge näeb välja nagu andmebaasi probleem. Google dokumenteerib juurdepääsu võrkudest, mis on ühendatud Cloud VPN-i või Cloud Interconnecti kaudu. Need võrgud ei vaja erilist andmebaasifunktsiooni, vaid kahte marsruudivahetust, mille pooleli jätmine on lihtne. Tunnel tõuseb, arvutusinstantsid vastavad ja andmebaasiühendus aegub — täpselt see kombinatsioon, mis saadab inimesed valesse konsooli.

Müüt: privaatne IP tähendab VPC jaoks privaatset

Privaatsete teenuste juurdepääs on VPC-peering sinu võrgu ja Google'i omanduses oleva tootjavõrgu vahel. Teenuse jaoks eraldatud vahemik asub tootja poolel ja instantsi aadress on selle sees. Selle peeringu tõttu võib sinu projektis asuv andmebaas paikneda aadressil, kuhu sinu VPC marsruudib, ilma et ükski sinu selgesõnaline alamvõrk seda sisaldaks.

Kuna see on peering, on sellel ka peeringu käitumine, sealhulgas osa, kus kohandatud marsruudid ei lähe automaatselt üle.

Müüt: töötav tunnel kannab andmebaasi marsruudi endaga kaasa

Kaks vahemikku peavad teekonna üle elama. Esimene on kliendi prefiks: sinu kohalik võrk peab olema Cloud Routerile teada konkreetsete prefiksitega, sest vaikemarsruut ei saa anda importi, mida tootjavõrk tagasitee jaoks vajab. Teine on eraldatud teenusevahemik, mille väline pool peab õppima, et selle andmebaasi pakettidel oleks kuhu minna. Need on erinevad marsruudid, mida hoitakse erinevatel piiridel, ja ühe parandamine jätab teise katki.

Google'i poolel tähendab see Export custom routes lubamist asjakohastel peering-ühendustel ja eraldatud teenusevahemiku lisamist Cloud Routeri tunnelile kuulutatud marsruutide hulka.

Säilita kuulutused, mis juba olemas on. Teenusevahemiku lisamine ei tohiks eemaldada VPC marsruute, mida sama BGP sessioon kannab muu liikluse jaoks, ja täielikult asendatud kuulutuste kogum on teine katkestus, mis on esimese taga peidus. Kontrolli ka tõhusaid marsruute välisseadmes, sest VPN-lüüsile või teisele alamvõrgule ligipääs tõestab ainult transporti.

Müüt: Cloud SQL Auth Proxy lahendab võrgu

The Auth Proxy pakub toetatud autentimist ja krüpteeritud transporti sinu rakenduse ja instantsi vahel. See ei loo marsruuti. Hostil, millel pole teed privaatvõrku, käivitatud puhverserver ebaõnnestub täpselt nagu otsene ühendus ja selle logid on põhjuse kohta vähem kasulikud. Puhverserveri liigutamine hostile, millel ühenduvus on, muudab, milline tee lõik peab töötama, ja see on tõeline disainiotsus, mitte mööramine.

Mida see ei tee, on ühenduseta sülearvuti juurdepääsu lubamine ainult privaatsele instantsile.

Müüt: Private Service Connect järgib samu reegleid

Private Service Connect kasutab endpointi sinu enda alamvõrgus ja DNS-lahendust, mida sina kontrollid, seega on tee sinna tavaline marsruut aadressile, mis kuulub sulle. Peeringu ekspordi seaded sellele disainile ei kehti ja peeringu muudatuste kopeerimine PSC juurutusse lisab riski ilma juurdepääsetavust lisamata.

Mõlemad annavad privaatse aadressi; sarnasus lõpeb seal.

Testige teed õiges järjekorras

Väliskliendist testige esmalt andmebaasi TCP-lõpp-punkti. Lõpetatud TCP käepigistus tähendab, et marsruutimine, tulemüür ja kuulaja on kõik paigas, ja järgmine test on lubatud autenditud toiming. Autentimise tagasilükkamine on sel hetkel tegelikult hea uudis, sest see tõestab, et andmebaasi kuulaja vastas. ICMP aegumine ei ütle andmebaasi juurdepääsu kohta peaaegu midagi, sest paljud teed viskavad selle kõrvale, samal ajal kui TCP edastatakse muretult.

Kui sinu kliendivahemikud on väljaspool RFC 1918, vaadake üle täiendavad marsruudi ekspordi ja võrgu autoriseerimise nõuded, enne kui järeldate, et disain pole toetatud.

Kirjutage ühenduse juurde neli objekti: väline prefiks, eraldatud teenusevahemik, kaasatud peering-ühendused ja ruuter, mis kuulutab. Need neli selgitavad kogu privaatse tee ja asendavad rahvajutu, et Cloud SQL vajab kas alati puhverserverit või pole VPN-i kaudu üldse kättesaadav.