Cloud SQL privé-IP over VPN: de route die niemand exporteert

Veel teams denken dat Cloud SQL privé-IP alleen van binnen de VPC werkt, en die overtuiging blijft standhouden omdat de fout op een databaseprobleem lijkt. Google documenteert toegang vanaf netwerken die via Cloud VPN of Cloud Interconnect zijn verbonden. Die netwerken hebben geen speciale databasefunctie nodig, maar twee route-uitwisselingen die je gemakkelijk half geconfigureerd achterlaat. De tunnel komt op, de compute-instanties antwoorden en de databaseverbinding loopt in een time-out — precies de combinatie die mensen naar de verkeerde console stuurt.

Mythe: privé-IP betekent privé voor de VPC

Toegang tot privédiensten is een VPC-peering tussen jouw netwerk en een producentnetwerk dat eigendom is van Google. Het toegewezen bereik voor de dienst ligt aan de producentkant, en het instantieadres ligt daarbinnen. Door die peering kan een database in je project op een adres staan waar je VPC naartoe routeert zonder dat een expliciet subnet van jou die bevat.

Omdat het een peering is, heeft het ook peering-gedrag, inclusief het deel waarin aangepaste routes niet automatisch oversteken.

Mythe: een werkende tunnel draagt de databaseroute mee

Twee bereiken moeten de reis overleven. Het eerste is het clientprefix: je on-premises netwerk moet bij de Cloud Router bekend zijn met specifieke prefixen, want een standaardroute kan de import niet leveren die het producentnetwerk voor de terugweg nodig heeft. Het tweede is het toegewezen servicebereik, dat de externe kant moet leren zodat zijn pakketten naar de database ergens heen kunnen. Het zijn verschillende routes die bij verschillende grenzen worden onderhouden, en het ene repareren laat het andere kapot.

Aan de Google-kant betekent dat Export custom routes aanzetten op de betreffende peering-verbindingen en het toegewezen servicebereik toevoegen aan de aangekondigde routes van de Cloud Router voor de tunnel.

Behoud de aankondigingen die er al zijn. Het toevoegen van het servicebereik mag de VPC-routes niet verwijderen die dezelfde BGP-sessie voor ander verkeer draagt, en een aankondigingenset die in zijn geheel wordt vervangen is een tweede storing die zich achter de eerste verstopt. Controleer ook de effectieve routes op het externe apparaat, want de VPN-gateway of een ander subnet kunnen bereiken bewijst alleen transport.

Mythe: de Cloud SQL Auth Proxy lost het netwerk op

The Auth Proxy biedt ondersteunde authenticatie en versleuteld transport tussen je applicatie en de instantie. Het maakt geen route. Een proxy die start op een host zonder pad naar het privénetwerk zal precies zo falen als een directe verbinding zou doen, en de logs zullen minder behulpzaam zijn over waarom. De proxy naar een host verplaatsen die wel connectiviteit heeft, verandert welk been van het pad moet werken, en dat is een echte ontwerpbeslissing in plaats van een omweg.

Wat het niet doet, is een niet-verbonden laptop een alleen-privé-instantie laten bereiken.

Mythe: Private Service Connect volgt dezelfde regels

Private Service Connect gebruikt een endpoint in je eigen subnet en een DNS-regeling die je beheert, dus de route ernaartoe is een gewone route naar een adres dat je bezit. Peering-exportinstellingen gelden niet voor dat ontwerp, en peering-wijzigingen kopiëren naar een PSC-implementatie voegt risico toe zonder bereikbaarheid toe te voegen.

Beide geven je een privéadres; de gelijkenis stopt daar.

Test het pad in de juiste volgorde

Test vanaf de externe client eerst het TCP-endpoint van de database. Een voltooide TCP-handshake betekent dat routing, firewall en listener allemaal aanwezig zijn, en de volgende test is een toegestane geauthenticeerde bewerking. Een authenticatieweigering is op dat moment juist goed nieuws, omdat het bewijst dat een databaselistener heeft geantwoord. Een ICMP-time-out zegt bijna niets over databasetoegang, omdat veel paden die laten vallen terwijl ze TCP probleemloos doorsturen.

Als je clientbereiken buiten RFC 1918 liggen, bekijk dan de aanvullende eisen voor route-export en netwerkautorisatie voordat je concludeert dat het ontwerp niet wordt ondersteund.

Noteer vier objecten bij de verbinding: het externe prefix, het toegewezen servicebereik, de betrokken peering-verbindingen en de router die aankondigt. Die vier verklaren het hele privépad, en ze vervangen het verhaal dat Cloud SQL ofwel altijd een proxy nodig heeft ofwel helemaal niet over een VPN bereikbaar is.