Cloud SQL privat IP över VPN: rutten som ingen exporterar

Många team tror att Cloud SQL privat IP bara fungerar inifrån VPC:n, och tron håller i sig eftersom felet ser ut som ett databasproblem. Google dokumenterar åtkomst från nätverk som är anslutna via Cloud VPN eller Cloud Interconnect. Dessa nätverk behöver ingen särskild databasfunktion, utan två ruteutbyten som är lätta att lämna halvkonfigurerade. Tunneln kommer upp, beräkningsinstanserna svarar och databasanslutningen tar slut på tid — exakt den kombination som skickar folk till fel konsol.

Myt: privat IP betyder privat för VPC:n

Privat tjänståtkomst är en VPC-peering mellan ditt nätverk och ett producentnätverk som ägs av Google. Det tilldelade intervallet för tjänsten ligger på producentsidan, och instansadressen ligger inom det. Den här peeringen är anledningen till att en databas i ditt projekt kan ligga på en adress som din VPC routar till utan att något av dina explicita subnät innehåller den.

Eftersom det är en peering har den också peering-beteende, inklusive den del där anpassade rutter inte korsar automatiskt.

Myt: en fungerande tunnel bär databasrutten med sig

Två intervall måste överleva resan. Det första är klientprefixet: ditt lokala nätverk måste vara känt av Cloud Router med specifika prefix, eftersom en standardrutt inte kan leverera den import som producentnätverket behöver för returvägen. Det andra är det tilldelade tjänsteintervallet, som den externa sidan måste lära sig så att dess paket till databasen har någonstans att ta vägen. De är olika rutter som underhålls vid olika gränser, och att laga den ena lämnar den andra trasig.

På Googles sida innebär det att aktivera Export custom routes på de berörda peering-anslutningarna och lägga till det tilldelade tjänsteintervallet i Cloud Routers annonserade rutter för tunneln.

Behåll de annonser som redan finns. Att lägga till tjänsteintervallet bör inte ta bort de VPC-rutter som samma BGP-session bär för annan trafik, och en annonsuppsättning som ersätts helt är ett andra avbrott gömt bakom det första. Kontrollera också de effektiva rutterna på den externa enheten, eftersom att nå VPN-gatewayen eller ett annat subnät bara bevisar transport.

Myt: Cloud SQL Auth Proxy löser nätverket

The Auth Proxy tillhandahåller stödd autentisering och krypterad transport mellan din applikation och instansen. Den skapar ingen rutt. En proxy som startas på en värd utan väg till det privata nätverket kommer att misslyckas precis som en direkt anslutning skulle göra, och dess loggar blir mindre hjälpsamma om varför. Att flytta proxyn till en värd som har anslutning ändrar vilken del av vägen som måste fungera, och det är ett riktigt designbeslut snarare än en kringgång.

Det den inte gör är att låta en frånkopplad bärbar dator nå en instans som bara är privat.

Myt: Private Service Connect följer samma regler

Private Service Connect använder en endpoint i ditt eget subnät och ett DNS-arrangemang som du kontrollerar, så rutten dit är en vanlig rutt till en adress du äger. Peering-exportinställningar gäller inte för den designen, och att kopiera peering-ändringar till en PSC-distribution adderar risk utan att addera nåbarhet.

Båda ger dig en privat adress; likheten slutar där.

Testa vägen i rätt ordning

Från den externa klienten, testa databasens TCP-endpoint först. Ett slutfört TCP-handskakning betyder att routning, brandvägg och lyssnare alla är på plats, och nästa test är en tillåten autentiserad operation. Ett avvisat autentisering är faktiskt goda nyheter i det läget, eftersom det bevisar att en databaslyssnare svarade. En ICMP-timeout säger nästan ingenting om databasåtkomst, eftersom många vägar släpper den medan de vidarebefordrar TCP utan problem.

Om dina klientintervall ligger utanför RFC 1918, gå igenom de extra kraven för ruteexport och nätverksauktorisering innan du drar slutsatsen att designen inte stöds.

Notera fyra objekt med anslutningen: det externa prefixet, det tilldelade tjänsteintervallet, peering-anslutningarna som är inblandade och routern som annonserar. Dessa fyra förklarar hela den privata vägen, och de ersätter folksagan att Cloud SQL antingen alltid behöver en proxy eller inte alls kan nås över VPN.