Cloud SQL privat IP over VPN: ruten, som ingen eksporterer

Mange teams tror, at Cloud SQL privat IP kun virker indefra VPC'en, og troen holder, fordi fejlen ligner et databaseproblem. Google dokumenterer adgang fra netværk, der er forbundet via Cloud VPN eller Cloud Interconnect. Det, disse netværk har brug for, er ikke en særlig databasefunktion, men to ruteudvekslinger, som det er let at efterlade halvt konfigureret. Tunnelen kommer op, compute-instanserne svarer, og databaseforbindelsen timeouter — præcis den kombination, der sender folk til den forkerte konsol.

Myte: privat IP betyder privat for VPC'en

Privat serviceadgang er en VPC-peering mellem dit netværk og et producentnetværk ejet af Google. Det tildelte område til tjenesten ligger på producentsiden, og instansadressen ligger inde i det. Denne peering er grunden til, at en database i dit projekt kan ligge på en adresse, som din VPC ruter til, uden at nogen af dine eksplicitte undernet indeholder den.

Fordi det er en peering, har den også peering-adfærd, inklusive den del hvor brugerdefinerede ruter ikke automatisk krydser.

Myte: en fungerende tunnel bærer databaseruten med sig

To områder skal overleve turen. Det første er klientpræfikset: dit lokale netværk skal være kendt af Cloud Router med bestemte præfikser, fordi en standardrute ikke kan levere den import, producentnetværket har brug for til returvejen. Det andet er det tildelte tjenesteområde, som den eksterne side skal lære, så dens pakker til databasen har et sted at gå hen. Det er forskellige ruter vedligeholdt ved forskellige grænser, og at rette den ene efterlader den anden brudt.

På Googles side betyder det at aktivere Export custom routes på de relevante peering-forbindelser og tilføje det tildelte tjenesteområde til Cloud Routers annoncerede ruter for tunnelen.

Behold de annoncer, der allerede er der. Tilføjelse af tjenesteområdet bør ikke fjerne de VPC-ruter, som samme BGP-session bærer for anden trafik, og et annoncesæt, der erstattes helt, er et andet udfald skjult bag det første. Kontroller også de effektive ruter på den eksterne enhed, fordi at kunne nå VPN-gatewayen eller et andet undernet kun beviser transport.

Myte: Cloud SQL Auth Proxy løser netværket

The Auth Proxy leverer understøttet godkendelse og krypteret transport mellem din applikation og instansen. Den opretter ikke en rute. En proxy startet på en vært uden vej til det private netværk vil fejle præcis som en direkte forbindelse ville, og dens logge vil være mindre hjælpsomme om hvorfor. At flytte proxyen til en vært, der har forbindelse, ændrer hvilket ben af ruten der skal virke, og det er en rigtig designbeslutning frem for en omvej.

Det, den ikke gør, er at lade en afbrudt bærbar computer nå en instans, der kun er privat.

Myte: Private Service Connect følger de samme regler

Private Service Connect bruger et endpoint i dit eget undernet og et DNS-arrangement, du styrer, så ruten dertil er en almindelig rute til en adresse, du ejer. Indstillinger for peering-eksport gælder ikke for det design, og at kopiere peering-ændringer ind i en PSC-udrulning tilføjer risiko uden at tilføje rækkevidde.

Begge giver dig en privat adresse; ligheden stopper der.

Test ruten i den rigtige rækkefølge

Fra den eksterne klient testes databasens TCP-endpoint først. Et fuldført TCP-håndtryk betyder, at routing, firewall og listener alle er på plads, og den næste test er en tilladt godkendt operation. En afvisning af godkendelse er faktisk godt nyt på det tidspunkt, fordi det beviser, at en databaselistener svarede. En ICMP-timeout siger næsten intet om databaseadgang, fordi mange ruter dropper den, mens de videresender TCP uden problemer.

Hvis dine klientområder ligger uden for RFC 1918, så gennemgå de ekstra krav til ruteeksport og netværksautorisation, før du konkluderer, at designet ikke understøttes.

Notér fire objekter sammen med forbindelsen: det eksterne præfiks, det tildelte tjenesteområde, de involverede peering-forbindelser og routeren, der annoncerer. De fire forklarer hele den private rute, og de erstatter folkloren om, at Cloud SQL enten altid kræver en proxy eller slet ikke kan nås over en VPN.