Cloud SQL privat IP over VPN: ruta ingen eksporterer
Cloud SQL privat IP fungerer frå eit VPN-tilkopla nettverk, men berre når både klientprefikset og tenesteområdet overlever to rutegrenser.
Mange team trur at Cloud SQL privat IP berre fungerer innanfrå VPC-en, og trua held seg fordi feilen ser ut som eit databaseproblem. Google dokumenterer tilgang frå nettverk som er kopla til via Cloud VPN eller Cloud Interconnect. Det desse nettverka treng er ikkje ein spesiell databasefunksjon, men to ruteutvekslingar som er lette å la stå halvkonfigurerte. Tunnelen kjem opp, compute-instansane svarar, og databasekoplinga går ut på tid — nøyaktig kombinasjonen som sender folk til feil konsoll.
Myte: privat IP tyder privat for VPC-en
Privat tenestetilgang er ei VPC-peering mellom nettverket ditt og eit produsentnettverk eigd av Google. Det tildelte området for tenesta ligg på produsentsida, og instansadressa ligg inni det. Denne peeringa er grunnen til at ein database i prosjektet ditt kan liggje på ei adresse som VPC-en din ruter til, utan at noko av ditt eksplisitte subnett inneheld ho.
Fordi det er ei peering, har ho òg peering-åtferd, inkludert delen der eigendefinerte ruter ikkje kryssar automatisk.
Myte: ein fungerande tunnel ber databaseruta med seg
To område må overleve turen. Det første er klientprefikset: det lokale nettverket ditt må vere kjent for Cloud Router med bestemte prefiks, fordi ei standardrute ikkje kan levere importen produsentnettverket treng for returvegen. Det andre er det tildelte tenesteområdet, som den eksterne sida må lære slik at pakkane hennar til databasen har ein stad å gå. Dette er ulike ruter haldne ved like ved ulike grenser, og å reparere den eine lèt den andre vere øydelagd.
På Google-sida tyder det å slå på Export custom routes på dei relevante peering-koplingane og leggje det tildelte tenesteområdet til dei annonserte rutene til Cloud Router for tunnelen.
Hald på annonsane som allereie finst. Å leggje til tenesteområdet skal ikkje fjerne VPC-rutene som same BGP-økt ber for annan trafikk, og eit annonsesett som blir heilt erstatta er eit andre avbrot gøymt bak det første. Kontroller òg dei effektive rutene på den eksterne eininga, fordi å kunne nå VPN-gatewayen eller eit anna subnett beviser berre transport.
Myte: Cloud SQL Auth Proxy løyser nettverket
The Auth Proxy gir støtta autentisering og kryptert transport mellom applikasjonen din og instansen. Det opprettar ikkje ei rute. Ein proxy starta på ein vert utan veg til det private nettverket vil feile nøyaktig som ei direkte kopling ville gjere, og loggane vil vere mindre nyttige om kvifor. Å flytte proxyen til ein vert som har tilkopling endrar kva bein av ruta som må fungere, og det er ei reell designavgjerd framfor ein omveg.
Det han ikkje gjer, er å la ein fråkopla berbar datamaskin nå ein instans som berre er privat.
Myte: Private Service Connect følgjer dei same reglane
Private Service Connect brukar eit endepunkt i ditt eige subnett og eit DNS-oppsett du kontrollerer, så ruta dit er ei vanleg rute til ei adresse du eig. Peering-eksportinnstillingar gjeld ikkje for det designet, og å kopiere peering-endringar inn i ein PSC-utrulling legg til risiko utan å leggje til rekkevidd.
Begge gir deg ei privat adresse; likskapen stoppar der.
Test ruta i rett rekkjefølgje
Frå den eksterne klienten, test TCP-endepunktet til databasen først. Eit fullført TCP-handtrykk tyder at ruting, brannmur og lyttar alle er på plass, og neste test er ein tillaten autentisert operasjon. Ei avvist autentisering er faktisk gode nyhende på det tidspunktet, fordi det beviser at ein databaselyttar svara. Ein ICMP-timeout seier nesten ingenting om databasetilgang, fordi mange ruter droppar han medan dei videresender TCP utan problem.
Viss klientområda dine er utanfor RFC 1918, gå gjennom dei ekstra krava til ruteeksport og nettverksautorisasjon før du konkluderer med at designet ikkje er støtta.
Noter fire objekt saman med koplinga: det eksterne prefikset, det tildelte tenesteområdet, peering-koplingane som er involverte og rutaren som annonserer. Desse fire forklarer heile den private ruta, og dei erstattar folkloren om at Cloud SQL anten alltid treng ein proxy eller ikkje kan nånast over VPN i det heile.