Cloud SQL Auth Proxy prieš tiesioginį VPN maršrutą į duomenų bazę
Auth Proxy ir tiesioginis VPN maršrutas sprendžia skirtingas tos pačios problemos puses. Pirmiausia palyginkite jungties autorizaciją, prievadus ir prisijungimą prie duomenų bazės.
Yra du protingi būdai pasiekti privačią Cloud SQL instanciją iš nešiojamojo kompiuterio, prijungto prie VPN. Vienas – tiesioginis ryšys su privačiu instancijos adresu per maršrutą, kurį jau turite. Kitas – Cloud SQL Auth Proxy, kuris klausosi loopback ir pats atidaro ryšį su Cloud SQL. Tai ne tiek konkuruojantys produktai, kiek du skirtingi atsakymai į klausimą, kas laiko prisijungimo duomenis, o kas – maršrutą. Blogas pasirinkimas paprastai pasireiškia kaip autorizacijos klaida, kuri skaitoma kaip tinklo klaida.
Štai palyginimas, kurį padėčiau prieš komandą, o po jo – patikros, kurios iš tikrųjų sprendžia.
Du keliai į tą pačią instanciją
Tiesioginis kelias naudoja private-services-access maršrutą iš jūsų tinklo į projekto VPC. Jūsų klientas kalba PostgreSQL su privačiu instancijos adresu, o ryšys gyvena arba miršta priklausomai nuo maršrutizavimo, firewall taisyklių ir duomenų bazės prisijungimo duomenų.
Kelias per proxy naudoja tą patį maršrutą, bet prideda vietinį procesą. Proxy autentifikuojasi Google API su programos default credentials, atidaro ryšį su instancija per jungtį ir pateikia loopback prievadą, kurį jūsų klientas traktuoja kaip PostgreSQL. Du šuoliai tampa trimis, o vidurinis neša IAM autorizaciją. VPN maršrutas vis dar jūsų prižiūrimas, ir proxy niekada nelaiko jo tos patikros pakaitalu.
Ką iš tikrųjų autorizuoja kiekvienas kelias
Svarbiausias skirtumas – ką kiekviena parinktis gali autorizuoti už jus:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
Proxy IAM patikra ir prisijungimas prie duomenų bazės yra dveji atskiri vartai, ir perėjus vienus kiti neatsidaro. Komanda, kuri įjungia proxy ir mano, kad programos paskyra dabar nebereikalinga, praleis popietę su slaptažodžių klaidomis, kurios neturi nieko bendra su tinklu.
Prievadai ir maršrutai greta
Proxy reikia išeinančio TCP 443 API ir TCP 3307 instancijos ryšiui, abu aprašyti Google Auth Proxy apžvalgoje. Jūsų VPN maršrutas apima antrąjį; pirmasis paprastai išeina įprastu keliu.
Tiesioginiam ryšiui reikia, kad instancijos PostgreSQL prievadas būtų pasiekiamas per privatų maršrutą, o tai jau visai kitas pokalbis apie firewall. Jei jūsų tinklo komanda leidžia tik išeinantį 443 iš klientų potinklių, proxy telpa be taisyklės pakeitimo, o tiesioginis kelias netelpa. Šis vienas faktas nulemia pasirinkimą dažniau nei bet koks architektūrinis prioritetas.
Nė vienas kelias nereikalauja, kad instancija turėtų viešą adresą, ir nė vienas nepateisina jo pridėjimo.
Kur proxy nepadeda
Proxy nepataiso trūkstamo maršruto. Jei private-services-access maršruto nėra arba VPN jo neperduoda, jungtis sugenda, o vietinis klausytojas vis dar sėdi ten ir klausosi, ir tai yra painioji dalis.
Jis taip pat neapsaugo atkarpos tarp jūsų programos ir proxy. Viename nešiojamajame kompiuteryje ta atkarpa yra loopback ir viskas gerai. Jei klausytoją pririšate prie wildcard adreso, kad kolega jį pasiektų, pastatėte neautentifikuotą duomenų bazės vartus ir pavadinote tai patogumu. Laikykite jį loopback ir leiskite kolegai gauti savo prisijungimo duomenis.
Ir jis nedaro Private Service Connect ir private services access pakeičiamų vienas kitu. PSC instancijai reikia savo DNS tvarkos ir --psc iškvietimo, o ne --private-ip formos.
Pasirinkti, o paskui bet kuriuo atveju patikrinti
Rinkitės proxy, kai norite IAM kelyje, trumpalaikių prisijungimo duomenų ir jokių įeinančio firewall pakeitimų.
Rinkitės tiesioginį maršrutą, kai palaikomas klientas jau turi tvirtus duomenų bazės prisijungimo duomenis ir tinklo komanda pasirengusi atidaryti prievadą. Bet kuriuo atveju tikrinkite tikra užklausa, o ne sėkmingu ryšiu: prisijunkite, atlikite vieną skaitymą žinomoje lentelėje ir pažiūrėkite, ką serveris mato apie jūsų sesiją.
Po VPN persijungimo traktuokite pasibaigusius prisijungimo duomenis, trūkstamą privatų maršrutą ir prisijungimo prie duomenų bazės atmetimą kaip tris skirtingus gedimus. Tik vienas iš jų yra tinklo problema, ir tik vienas kada nors turėtų paskatinti keisti firewall taisyklę.