Privatni IP Cloud SQL preko VPN-a: ruta koju nitko ne izvozi

Mnogi timovi vjeruju da privatni IP Cloud SQL radi samo iznutra VPC-a, a to uvjerenje traje jer kvar izgleda kao problem baze podataka. Google dokumentira pristup iz mreža povezanih preko Cloud VPN-a ili Cloud Interconnecta. Tim mrežama nije potrebna posebna funkcija baze podataka, već dvije razmjene ruta koje je lako ostaviti napola konfigurisane. Tunel se podigne, compute instance odgovore, a veza s bazom istekne — upravo kombinacija koja ljude šalje u pogrešnu konzolu.

Mit: privatni IP znači privatan za VPC

Pristup privatnim servisima je VPC peering između vaše mreže i producentove mreže koju posjeduje Google. Dodijeljeni raspon za servis živi na producentovoj strani, a adresa instance je unutar njega. Zbog tog peeringa baza podataka u vašem projektu može sjediti na adresi na koju vaš VPC rutira iako je nijedna vaša eksplicitna podmreža ne sadrži.

Budući da je peering, ima i peering ponašanje, uključujući dio u kojem prilagođene rute ne prelaze automatski.

Mit: ispravan tunel nosi rutu baze sa sobom

Dva raspona moraju preživjeti put. Prvi je klijentski prefiks: vaša lokalna mreža mora biti poznata Cloud Routeru s konkretnim prefiksima, jer zadana ruta ne može dati import koji producentova mreža treba za povratni put. Drugi je dodijeljeni servisni raspon, koji vanjska strana mora naučiti da bi njeni paketi za bazu imali kamo otići. To su različite rute koje se održavaju na različitim granicama, a popravka jedne ostavlja drugu slomljenom.

Na Googleovoj strani to znači uključiti Export custom routes na dotičnim peering vezama i dodati dodijeljeni servisni raspon u oglašene rute Cloud Routera za tunel.

Zadržite oglase koji već postoje. Dodavanje servisnog raspona ne smije ukloniti VPC rute koje ista BGP sesija nosi za drugi promet, a set oglasa zamijenjen u cjelini drugi je ispad skriven iza prvog. Provjerite i efektivne rute na vanjskom uređaju, jer mogućnost dosezanja VPN pristupnika ili druge podmreže dokazuje samo transport.

Mit: Cloud SQL Auth Proxy rješava mrežu

The Auth Proxy pruža podržanu autentikaciju i šifrirani transport između vaše aplikacije i instance. On ne stvara rutu. Proxy pokrenut na hostu bez puta do privatne mreže propast će jednako kao i izravna veza, a njegovi zapisi bit će manje korisni o razlogu. Premještanje proxyja na host koji ima povezanost mijenja koja dionica puta mora raditi, a to je stvarna projektna odluka, a ne zaobilazno rješenje.

Ono što ne čini jest da omogući nepovezanom prijenosniku dosezanje instance dostupne samo privatno.

Mit: Private Service Connect slijedi ista pravila

Private Service Connect koristi endpoint u vašoj vlastitoj podmreži i DNS raspored koji kontrolirate, pa je ruta do njega obična ruta do adrese koju posjedujete. Postavke izvoza peeringa ne vrijede za taj dizajn, a kopiranje peering promjena u PSC implementaciju dodaje rizik bez dodavanja dostupnosti.

Oba vam daju privatnu adresu; sličnost tu prestaje.

Testirajte put u ispravnom redoslijedu

S vanjskog klijenta prvo testirajte TCP endpoint baze. Završeno TCP rukovanje znači da su rutiranje, vatrozid i slušatelj na mjestu, a sljedeći test je dopuštena autentificirana operacija. Odbijanje autentikacije u tom je trenutku zapravo dobra vijest, jer dokazuje da je slušatelj baze odgovorio. ICMP istek ne govori gotovo ništa o pristupu bazi, jer mnogi putevi ga odbacuju dok TCP prosljeđuju bez problema.

Ako su vaši klijentski rasponi izvan RFC 1918, pregledajte dodatne zahtjeve za izvoz ruta i autorizaciju mreže prije nego zaključite da dizajn nije podržan.

Zabilježite četiri objekta uz vezu: vanjski prefiks, dodijeljeni servisni raspon, uključene peering veze i usmjerivač koji oglašava. Ta četiri objašnjavaju cijeli privatni put i zamjenjuju predaju da Cloud SQL ili uvijek treba proxy ili se uopće ne može dosegnuti preko VPN-a.