Zasebni IP naslov Cloud SQL prek VPN: pot, ki je nihče ne izvozi

Mnoge ekipe verjamejo, da zasebni IP Cloud SQL deluje le znotraj VPC, in to prepričanje vztraja, ker je napaka videti kot težava zbirke podatkov. Google dokumentira dostop iz omrežij, povezanih prek Cloud VPN ali Cloud Interconnect. Tem omrežjem ne manjka posebna funkcija zbirke podatkov, temveč dve izmenjavi poti, ki ju je lahko pustiti napol nastavljeni. Tunel se dvigne, računalniški primerki odgovorijo, povezava z zbirko podatkov pa poteče — natanko tista kombinacija, ki ljudi pošlje v napačno konzolo.

Mit: zasebni IP pomeni zaseben za VPC

Dostop do zasebnih storitev je VPC peering med vašim omrežjem in omrežjem ponudnika v lasti Googla. Dodeljeni obseg za storitev živi na strani ponudnika, naslov primerka pa je znotraj njega. Zaradi tega peeringa je lahko zbirka podatkov v vašem projektu na naslovu, v katerega usmerja vaš VPC, čeprav je ne vsebuje nobena vaša izrecna podomrežje.

Ker je peering, ima tudi vedenje peeringa, vključno z delom, kjer se poti po meri ne prenašajo samodejno.

Mit: delujoč tunel nosi pot zbirke podatkov s seboj

Dva obsega morata pot prestati. Prvi je predpona odjemalca: vaše lokalno omrežje mora biti usmerjevalniku Cloud Router znano s konkretnimi predponami, ker privzeta pot ne more zagotoviti uvoza, ki ga omrežje ponudnika potrebuje za povratno pot. Drugi je dodeljeni obseg storitve, ki se ga mora zunanja stran naučiti, da imajo njeni paketi do zbirke podatkov kam iti. To so različne poti, ki se vzdržujejo na različnih mejah, in popravilo ene pusti drugo zlomljeno.

Na strani Googla to pomeni omogočiti Export custom routes na ustreznih peering povezavah in dodati dodeljeni obseg storitve med oglaševane poti Cloud Routerja za tunel.

Obdržite oglase, ki že obstajajo. Dodajanje obsega storitve ne sme odstraniti poti VPC, ki jih ista seja BGP nosi za drug promet, nabor oglasov, zamenjan v celoti, pa je druga motnja, skrita za prvo. Preverite tudi dejanske poti na zunanji napravi, ker doseganje prehoda VPN ali druge podomrežja dokazuje samo transport.

Mit: Cloud SQL Auth Proxy reši omrežje

The Auth Proxy zagotavlja podprto preverjanje pristnosti in šifriran transport med vašo aplikacijo in primerkom. Ne ustvari poti. Posrednik, zagnan na gostitelju brez poti v zasebno omrežje, bo spodletel enako kot neposredna povezava, njegovi dnevniki pa bodo manj koristni glede vzroka. Premik posrednika na gostitelja s povezljivostjo spremeni, kateri del poti mora delovati, in to je resnična oblikovalska odločitev, ne obhod.

Česa ne naredi: ne omogoči odklopljenemu prenosniku, da doseže primerek, ki je samo zaseben.

Mit: Private Service Connect sledi istim pravilom

Private Service Connect uporablja končno točko v vašem lastnem podomrežju in ureditev DNS, ki jo nadzorujete, zato je pot do nje običajna pot do naslova, ki ga imate v lasti. Nastavitve izvoza peeringa za to zasnovo ne veljajo, kopiranje peering sprememb v uvedbo PSC pa doda tveganje brez dodane dosegljivosti.

Oba vam dasta zasebni naslov; podobnost se tam konča.

Preizkusite pot v pravilnem vrstnem redu

Z zunanjega odjemalca najprej preizkusite končno točko TCP zbirke podatkov. Zaključen rokovanje TCP pomeni, da so usmerjanje, požarni zid in poslušalec vsi na mestu, naslednji preizkus pa je dovoljena preverjena operacija. Zavrnitev preverjanja pristnosti je v tistem trenutku pravzaprav dobra novica, ker dokazuje, da je poslušalec zbirke podatkov odgovoril. Potek ICMP o dostopu do zbirke podatkov ne pove skoraj ničesar, ker ga številne poti zavržejo, medtem ko TCP posredujejo brez težav.

Če so vaši odjemalski obsegi zunaj RFC 1918, preglejte dodatne zahteve za izvoz poti in avtorizacijo omrežja, preden sklenete, da zasnova ni podprta.

Zapišite štiri objekte skupaj s povezavo: zunanjo predpono, dodeljeni obseg storitve, vključene peering povezave in usmerjevalnik, ki oglašuje. Ti štirje pojasnjujejo celotno zasebno pot in nadomeščajo vražo, da Cloud SQL bodisi vedno potrebuje posrednika bodisi prek VPN sploh ni dosegljiv.