IP privat Cloud SQL prin VPN: ruta pe care nimeni nu o exportă

Multe echipe cred că IP-ul privat Cloud SQL funcționează doar din interiorul VPC, iar convingerea rezistă pentru că defecțiunea arată ca o problemă de bază de date. Google documentează accesul din rețele conectate prin Cloud VPN sau Cloud Interconnect. Acestor rețele nu le trebuie o funcție specială de bază de date, ci două schimburi de rute ușor de lăsat pe jumătate configurate. Tunelul urcă, instanțele de calcul răspund, iar conexiunea la baza de date expiră — exact combinația care trimite oamenii la consola greșită.

Mit: IP privat înseamnă privat pentru VPC

Accesul la servicii private este un peering VPC între rețeaua dumneavoastră și o rețea de producător deținută de Google. Intervalul alocat serviciului se află de partea producătorului, iar adresa instanței este în interiorul lui. Din cauza acestui peering, o bază de date din proiectul dumneavoastră poate sta pe o adresă către care VPC-ul dumneavoastră rutează fără ca vreo subrețea explicită a dumneavoastră să o conțină.

Deoarece este un peering, are și comportament de peering, inclusiv partea în care rutele personalizate nu trec automat.

Mit: un tunel funcțional duce ruta bazei de date cu el

Două intervale trebuie să supraviețuiască călătoriei. Primul este prefixul clientului: rețeaua dumneavoastră locală trebuie să fie cunoscută de Cloud Router cu prefixe concrete, pentru că o rută implicită nu poate furniza importul de care rețeaua producătorului are nevoie pentru drumul de întoarcere. Al doilea este intervalul de serviciu alocat, pe care partea externă trebuie să îl învețe ca pachetele ei către baza de date să aibă unde merge. Sunt rute diferite întreținute la granițe diferite, iar repararea uneia o lasă pe cealaltă stricată.

De partea Google, asta înseamnă activarea Export custom routes pe conexiunile de peering relevante și adăugarea intervalului de serviciu alocat la rutele anunțate ale Cloud Router pentru tunel.

Păstrați anunțurile care există deja. Adăugarea intervalului de serviciu nu trebuie să elimine rutele VPC pe care aceeași sesiune BGP le transportă pentru alt trafic, iar un set de anunțuri înlocuit în întregime este o a doua cădere ascunsă în spatele primeia. Verificați și rutele efective de pe dispozitivul extern, pentru că a ajunge la gateway-ul VPN sau la altă subrețea dovedește doar transport.

Mit: Cloud SQL Auth Proxy rezolvă rețeaua

The Auth Proxy asigură autentificare acceptată și transport criptat între aplicația dumneavoastră și instanță. Nu creează o rută. Un proxy pornit pe un host fără cale către rețeaua privată va eșua exact cum ar eșua o conexiune directă, iar jurnalele sale vor fi mai puțin utile despre motiv. Mutarea proxy-ului pe un host care are conectivitate schimbă care parte a drumului trebuie să funcționeze, iar asta este o decizie de proiectare reală, nu o soluție de ocolire.

Ce nu face este să permită unui laptop deconectat să ajungă la o instanță doar privată.

Mit: Private Service Connect urmează aceleași reguli

Private Service Connect folosește un endpoint în propria subrețea și o aranjare DNS pe care o controlați, deci ruta către el este o rută obișnuită către o adresă pe care o dețineți. Setările de export ale peering-ului nu se aplică acelui design, iar copierea modificărilor de peering într-o implementare PSC adaugă risc fără a adăuga accesibilitate.

Ambele vă dau o adresă privată; asemănarea se oprește acolo.

Testați calea în ordinea corectă

De la clientul extern, testați mai întâi endpoint-ul TCP al bazei de date. Un handshake TCP finalizat înseamnă că rutarea, firewall-ul și ascultătorul sunt toate la locul lor, iar următorul test este o operație autentificată permisă. O respingere a autentificării este de fapt o veste bună în acel moment, pentru că dovedește că un ascultător al bazei de date a răspuns. O expirare ICMP nu spune aproape nimic despre accesul la bază, pentru că multe căi îl aruncă în timp ce transportă TCP fără probleme.

Dacă intervalele dumneavoastră de client sunt în afara RFC 1918, revedeți cerințele suplimentare de export al rutelor și de autorizare a rețelei înainte de a concluziona că designul nu este acceptat.

Notați patru obiecte împreună cu conexiunea: prefixul extern, intervalul de serviciu alocat, conexiunile de peering implicate și routerul care anunță. Aceste patru explică întreaga cale privată și înlocuiesc legenda că Cloud SQL fie are întotdeauna nevoie de un proxy, fie nu poate fi atins deloc prin VPN.