Cloud SQL Auth Proxy vagy közvetlen VPN-útvonal az adatbázishoz
Az Auth Proxy és a közvetlen VPN-útvonal ugyanannak a problémának két különböző felét oldja meg. Először a connector engedélyezését, a portokat és az adatbázis-bejelentkezést hasonlítsa össze.
Két értelmes módja van annak, hogy egy VPN-en lévő laptopról elérjünk egy privát Cloud SQL-példányt. Az egyik a közvetlen kapcsolat a példány privát címére a már meglévő útvonalon. A másik a Cloud SQL Auth Proxy, amely loopbacken figyel, és maga nyitja meg a kapcsolatot a Cloud SQL felé. Ezek kevésbé versengő termékek, mint inkább két különböző válasz arra a kérdésre, hogy kinél van a hitelesítő adat és kinél az útvonal. A rossz választás általában engedélyezési hibaként jelenik meg, amelyet hálózati hibaként olvasnak.
Íme az összehasonlítás, amelyet egy csapat elé tennék, utána pedig azok az ellenőrzések, amelyek valóban eldöntik.
Két út ugyanahhoz a példányhoz
A közvetlen út a private-services-access útvonalat használja a hálózatából a projekt VPC-jébe. Az ügyfele PostgreSQL-t beszél a példány privát címével, és a kapcsolat az útvonalválasztáson, a firewall-szabályokon és az adatbázis hitelesítő adatain él vagy hal.
A proxy út ugyanazt az útvonalat használja, de hozzáad egy helyi folyamatot. A proxy az alkalmazás default credentials adataival hitelesít a Google API felé, kapcsolatot nyit a példányhoz a connectoron keresztül, és egy loopback portot tesz elérhetővé, amelyet az ügyfele PostgreSQL-ként kezel. Két ugrásból három lesz, és a középső hordozza az IAM-engedélyezést. A VPN-útvonal továbbra is az Ön karbantartása, és a proxy soha nem tekinti annak az ellenőrzésnek a helyettesítőjeként.
Mit engedélyez valójában az egyes utak
A legfontosabb különbség az, hogy melyik lehetőség mit engedélyezhet az Ön helyett:
| 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 |
A proxy IAM-ellenőrzése és az adatbázis-bejelentkezés külön kapuk, és az egyiken átjutva nem nyílik ki a másik. Az a csapat, amely bekapcsolja a proxyt, és azt feltételezi, hogy az alkalmazásfiók már felesleges, egy délutánt tölt olyan jelszóhibákkal, amelyeknek semmi közük a hálózathoz.
Portok és útvonalak egymás mellett
A proxynak kimenő TCP 443 kell az API-hoz és TCP 3307 a példánykapcsolathoz, mindkettőt a Google Auth Proxy áttekintése írja le. Az Ön VPN-útvonala a másodikat fedi le; az első általában a szokásos úton megy ki.
A közvetlen kapcsolathoz a példány PostgreSQL portjának elérhetőnek kell lennie a privát útvonalon, ami egészen más firewall-beszélgetés. Ha a hálózati csapata csak a kimenő 443-at engedi az ügyfél-alhálózatokból, a proxy szabálymódosítás nélkül illeszkedik, a közvetlen út pedig nem. Ez az egyetlen tény gyakrabban dönti el a választást, mint bármely architekturális preferencia.
Egyik út sem igényli, hogy a példánynak nyilvános címe legyen, és egyik sem indokolja meg egy hozzáadását.
Ahol a proxy nem segít
A proxy nem javítja a hiányzó útvonalat. Ha a private-services-access útvonal hiányzik, vagy a VPN nem szállítja, a connector meghiúsul, miközben a helyi figyelő még mindig ott ül és figyel, és ez a zavaró rész.
Arra a szakaszra sem nyújt védelmet, amely az alkalmazás és a proxy között van. Egy laptopon ez a szakasz loopback, és rendben van. Ha a figyelőt wildcard-címhez köti, hogy egy kolléga elérhesse, hitelesítés nélküli adatbázis-átjárót épített, és kényelemnek nevezte. Tartsa loopbacken, és hagyja, hogy a kolléga saját hitelesítő adatot szerezzen.
És nem teszi a Private Service Connectet és a private services accesst egymással felcserélhetővé. Egy PSC-példánynak saját DNS-elrendezésre és a --psc hívásra van szüksége a --private-ip forma helyett.
Választás, majd ellenőrzés mindkét esetben
Válassza a proxyt, ha IAM-et akar az útvonalon, rövid élettartamú hitelesítő adatokat és semmilyen változást a bejövő firewallon.
Válassza a közvetlen útvonalat, ha egy támogatott ügyfél már erős adatbázis-hitelesítő adatokkal rendelkezik, és a hálózati csapat hajlandó megnyitni a portot. Mindkét esetben valódi lekérdezéssel ellenőrizze, ne sikeres kapcsolattal: kapcsolódjon, futtasson egy olvasást egy ismert táblán, és nézze meg, mit lát a kiszolgáló a munkamenetéről.
A VPN újracsatlakozása után kezelje a lejárt hitelesítő adatot, a hiányzó privát útvonalat és az adatbázis-bejelentkezés elutasítását három különböző hibaként. Csak az egyik hálózati probléma, és csak az egyik vezethet valaha firewall-szabály módosításához.