Cloud SQL-ren IP pribatua VPN bidez: inork esportatzen ez duen bidea
Cloud SQL-ren IP pribatuak VPN bidez konektatutako sare batetik funtzionatzen du, baina soilik bezeroaren aurrizkiak eta zerbitzu-barrutiak bi bideratze-muga irauten dutenean.
Talde askok uste dute Cloud SQL-ren IP pribatuak VPC barruan soilik funtzionatzen duela, eta usteak irauten du hutsegiteak datu-basearen arazo bat dirudielako. Googleren dokumentazioak Cloud VPN edo Cloud Interconnect bidez konektatutako sareetatik sartzea jasotzen du. Sare horiei ez zaie datu-basearen funtzio berezirik behar, osorik konfiguratu gabe uztea erraza den bi bide-truke baizik. Tunela altxatzen da, konputazio-instantziek erantzuten dute, eta datu-basearen konexioak denbora-muga gainditzen du — jendea kontsola okerrekoa bidaltzen duen konbinazio zehatza.
Mitoa: IP pribatuak VPCrako pribatua esan nahi du
Zerbitzu pribatuetarako sarbidea VPC peerink bat da zure sarea eta Googlek duen ekoizle-sare baten artean. Zerbitzuarentzat esleitutako barrutia ekoizlearen aldean dago, eta instantziaren helbidea haren barruan. Peerink horri esker, zure proiektuko datu-base batek zure VPCak bideratzen duen helbide batean egon daiteke, zure azpisare esplizitu bakar batek ere hura eduki gabe.
Peerink bat denez, peerink-portaera ere badu, bide pertsonalizatuek automatikoki zeharkatzen ez duten zatia barne.
Mitoa: tunel lanean ari denak datu-basearen bidea berekin dakar
Bi barrutik bidaiari eutsi behar diote. Lehena bezeroaren aurrizkia da: zure sare lokalak Cloud Routerrek aurrizki zehatzekin ezagutu behar du, bide lehenetsi batek ekoizle-sareak itzulerako biderako behar duen inportazioa eman ezin duelako. Bigarrena esleitutako zerbitzu-barrutia da, kanpoko aldeak ikasi behar duena datu-baserako bere paketeek norabidea izan dezaten. Muga desberdinetan mantentzen diren bide desberdinak dira, eta bat konpontzeak bestea hautsita uzten du.
Googleren aldean horrek esan nahi du dagozkion peerink-konexioetan Export custom routes gaitzea eta esleitutako zerbitzu-barrutia tunelerako Cloud Routerrek iragarritako bideetara gehitzea.
Mantendu dagoeneko dauden iragarkiak. Zerbitzu-barrutia gehitzeak ez luke kendu behar BGP saio berak beste trafiko batzuetarako daramatzan VPC bideak, eta osorik ordezkatutako iragarki-multzo bat lehenaren atzean ezkutatutako bigarren etenaldia da. Egiaztatu kanpoko gailuan indarrean dauden bideak ere, VPN atebidera edo beste azpisare batera iristeak garraioa baino ez baitu frogatzen.
Mitoa: Cloud SQL Auth Proxy-k sarea konpontzen du
The Auth Proxy zure aplikazioaren eta instantziaren artean onartutako autentifikazioa eta garraio zifratua eskaintzen ditu. Ez du biderik sortzen. Sare pribaturako biderik ez duen ostalari batean abiatutako proxy bat huts egingo luke konexio zuzen batek egingo lukeen bezalaxe, eta haren erregistroak ez dira hain lagungarriak zergatiaz. Proxy-a konektibitatea duen ostalari batera mugitzeak bidearen zein atalek lan egin behar duen aldatzen du, eta hori benetako diseinu-erabakia da, ez ingurubidea.
Egiten ez duena da deskonektatutako eramangarri batek instantzia pribatu soil batera iristea ahalbidetzea.
Mitoa: Private Service Connectek arau berberak jarraitzen ditu
Private Service Connectek zure azpisare propioan endpoint bat eta zuk kontrolatzen duzun DNS antolaketa erabiltzen ditu, beraz hara doan bidea zurea den helbide baterako bide arrunta da. Peerink-esportazio ezarpenak ez zaizkio diseinu horri aplikatzen, eta peerink-aldaketak PSC inplementazio batera kopiatzeak arriskua gehitzen du irisgarritasuna gehitu gabe.
Biek helbide pribatua ematen dizute; antzekotasuna hor amaitzen da.
Probatu bidea ordena egokian
Kanpoko bezerotik, probatu lehenik datu-basearen TCP endpointa. TCP eskuko txikizioa osatzeak bideratzea, suebakia eta entzulea denak lekuan daudela esan nahi du, eta hurrengo proba baimendutako eragiketa autentifikatu bat da. Autentifikazioaren ukapena albiste ona da une horretan, datu-basearen entzule batek erantzun zuela frogatzen duelako. ICMP denbora-mugak ia ezer ez du esaten datu-basearen sarbideaz, bide askok hura baztertzen dutelako TCP arazorik gabe aurrera eramaten duten bitartean.
Zure bezero-barrutiak RFC 1918-tik kanpo badaude, berrikusi bide-esportazio eta sare-autorizaziorako baldintza gehigarriak diseinua onartua ez dela ondorioztatu aurretik.
Erregistratu lau objektu konexioarekin: kanpoko aurrizkia, esleitutako zerbitzu-barrutia, tartean dauden peerink-konexioak eta iragarkia egiten duen bideratzailea. Lau horiek bide pribatu osoa azaltzen dute eta Cloud SQLek beti proxy bat behar duela edo VPN bidez inola ere iristen ez dela dioen kondaira ordezkatzen dute.