Cloud SQL private IP oor VPN: die roete wat niemand uitvoer nie

Baie spanne glo Cloud SQL private IP werk net binne die VPC, en die oortuiging bly staan omdat die fout soos 'n databasisprobleem lyk. Google dokumenteer toegang vanaf netwerke wat deur Cloud VPN of Cloud Interconnect gekoppel is. Wat daardie netwerke nodig het, is nie 'n spesiale databasisfunksie nie, maar twee roete-uitruilings wat maklik half opgestel gelaat word. Die tonnel kom op, die rekenaarisntansies antwoord, en die databasisverbinding hou op reageer — presies die kombinasie wat mense na die verkeerde konsole stuur.

Mite: private IP beteken privaat aan die VPC

Private services access is 'n VPC-peering tussen jou netwerk en 'n produsentnetwerk wat deur Google besit word. Die toegekende reeks vir die diens lê aan die produsentkant, en die instansie-adres is daarbinne. Daardie peering is die rede waarom 'n databasis in jou projek op 'n adres kan sit waarna jou VPC roeteer sonder dat enige eksplisiete subnet van jou dit bevat.

Omdat dit 'n peering is, het dit ook peering-gedrag, insluitend die deel waar pasgemaakte roetes nie outomaties oorgaan nie.

Mite: 'n werkende tonnel dra die databasisroete saam

Twee reekse moet die reis oorleef. Die eerste is die kliëntvoorvoegsel: jou plaaslike netwerk moet by die Cloud Router bekend wees met spesifieke voorvoegsels, want 'n verstekroete kan nie die invoer lewer wat die produsentnetwerk vir die terugpad nodig het nie. Die tweede is die toegekende diensreeks, wat die eksterne kant moet leer sodat sy pakkette vir die databasis êrens heen kan gaan. Dit is verskillende roetes wat by verskillende grense onderhou word, en om een reg te maak laat die ander stukkend.

Aan die Google-kant beteken dit dat jy Export custom routes op die betrokke peering-verbindings moet aktiveer en die toegekende diensreeks by die Cloud Router se geadverteerde roetes vir die tonnel moet voeg.

Behou die advertensies wat reeds daar is. Om die diensreeks by te voeg, moet nie die VPC-roetes verwyder wat dieselfde BGP-sessie vir ander verkeer dra nie, en 'n advertensiestel wat heeltemal vervang word, is 'n tweede onderbreking wat agter die eerste wegkruip. Kyk ook na die effektiewe roetes op die eksterne toestel, want om die VPN-gateway of 'n ander subnet te kan bereik bewys net vervoer.

Mite: die Cloud SQL Auth Proxy los die netwerk op

The Auth Proxy verskaf ondersteunde verifikasie en geënkripteerde vervoer tussen jou toepassing en die instansie. Dit skep nie 'n roete nie. 'n Proxy wat op 'n gasheer sonder 'n pad na die private netwerk begin word, sal presies so misluk soos 'n direkte verbinding sou, en sy logs sal minder nuttig wees oor hoekom. Om die proxy na 'n gasheer te skuif wat wel konnektiwiteit het, verander watter been van die pad moet werk, en dit is 'n werklike ontwerpbesluit eerder as 'n omweg.

Wat dit nie doen nie, is om 'n ontkoppelde skootrekenaar 'n instansie te laat bereik wat net privaat is.

Mite: Private Service Connect volg dieselfde reëls

Private Service Connect gebruik 'n eindpunt in jou eie subnet en 'n DNS-reëling wat jy beheer, so die roete daarheen is 'n gewone roete na 'n adres wat jy besit. Peering-uitvoerinstellings geld nie vir daardie ontwerp nie, en om peering-veranderinge in 'n PSC-ontplooiing te kopieer, voeg risiko by sonder om bereikbaarheid by te voeg.

Beide gee jou 'n private adres; die ooreenkoms stop daar.

Toets die pad in die regte volgorde

Vanaf die eksterne kliënt, toets eers die databasis se TCP-eindpunt. 'n Voltooide TCP-handdruk beteken roetering, firewall en luisteraar is alles in plek, en die volgende toets is 'n toegelate geauthentiseerde bewerking. 'n Verifikasieverwerping is op daardie punt eintlik goeie nuus, want dit bewys 'n databasisluisteraar het geantwoord. 'n ICMP-tydsverloop sê byna niks oor databasistoegang nie, want baie paaie laat dit val terwyl TCP gelukkig deurgestuur word.

As jou kliëntreekse buite RFC 1918 val, hersien die bykomende roete-uitvoer- en netwerk-outorisasievereistes voordat jy tot die gevolgtrekking kom dat die ontwerp nie ondersteun word nie.

Teken vier objekte saam met die verbinding aan: die eksterne voorvoegsel, die toegekende diensreeks, die peering-verbindings wat betrokke is, en die roeteerder wat adverteer. Daardie vier verduidelik die hele private pad, en hulle vervang die volksverhaal dat Cloud SQL óf altyd 'n proxy nodig het óf glad nie oor 'n VPN bereik kan word nie.