Cloud SQL privát IP VPN-en át: az útvonal, amelyet senki nem exportál

Sok csapat hiszi, hogy a Cloud SQL privát IP-je csak a VPC-n belülről működik, és a hit megmarad, mert a hiba adatbázisproblémának látszik. A Google dokumentálja a hozzáférést a Cloud VPN-en vagy Cloud Interconnecten keresztül csatlakozó hálózatokból. Ezeknek a hálózatoknak nem különleges adatbázis-funkcióra van szükségük, hanem két útvonalcserére, amelyeket könnyű félkész állapotban hagyni. Az alagút feljön, a számítási példányok válaszolnak, és az adatbázis-kapcsolat időtúllépésbe fut — pontosan az a kombináció, amely rossz konzolra küldi az embereket.

Mítosz: a privát IP a VPC számára privátot jelent

A privát szolgáltatásokhoz való hozzáférés VPC-társítás az Ön hálózata és egy Google tulajdonában lévő előállítói hálózat között. A szolgáltatáshoz kiosztott tartomány az előállítói oldalon van, és a példány címe azon belül található. Ez a társítás az oka annak, hogy egy adatbázis a projektjében olyan címen lehet, ahová a VPC-je irányít, anélkül hogy bármelyik kifejezett alhálózata tartalmazná.

Mivel társítás, társítási viselkedése is van, beleértve azt a részt, ahol az egyéni útvonalak nem lépnek át automatikusan.

Mítosz: egy működő alagút magával viszi az adatbázis útvonalát

Két tartománynak kell túlélnie az utat. Az első az ügyfél-előtag: a helyi hálózatát konkrét előtagokkal kell ismernie a Cloud Routernek, mert egy alapértelmezett útvonal nem tudja biztosítani azt az importot, amelyre az előállítói hálózatnak a visszaúthoz szüksége van. A második a kiosztott szolgáltatási tartomány, amelyet a külső oldalnak meg kell tanulnia, hogy az adatbázis felé menő csomagjainak legyen hová menniük. Ezek különböző útvonalak, amelyeket különböző határokon tartanak karban, és az egyik javítása a másikat törve hagyja.

A Google oldalán ez azt jelenti, hogy engedélyezni kell az Export custom routes beállítást az érintett társítási kapcsolatokon, és hozzá kell adni a kiosztott szolgáltatási tartományt a Cloud Router alagúthoz hirdetett útvonalaihoz.

Tartsa meg a már meglévő hirdetéseket. A szolgáltatási tartomány hozzáadása nem távolíthatja el azokat a VPC-útvonalakat, amelyeket ugyanaz a BGP-munkamenet más forgalom számára hordoz, és a teljesen lecserélt hirdetéskészlet egy második kiesés, amely az első mögött rejtőzik. Ellenőrizze a külső eszközön érvényes útvonalakat is, mert a VPN-átjáró vagy egy másik alhálózat elérése csak a szállítást bizonyítja.

Mítosz: a Cloud SQL Auth Proxy megoldja a hálózatot

The Auth Proxy támogatott hitelesítést és titkosított szállítást biztosít az alkalmazás és a példány között. Nem hoz létre útvonalat. Egy olyan gazdagépen indított proxy, amelynek nincs útja a privát hálózat felé, pontosan úgy fog meghiúsulni, mint egy közvetlen kapcsolat, és a naplói kevésbé lesznek hasznosak az ok tekintetében. A proxy átvitele egy kapcsolattal rendelkező gazdagépre megváltoztatja, hogy az útvonal melyik szakaszának kell működnie, és ez valódi tervezési döntés, nem kerülőút.

Amit nem tesz: nem engedi, hogy egy leválasztott laptop csak privát példányt érjen el.

Mítosz: a Private Service Connect ugyanazokat a szabályokat követi

A Private Service Connect a saját alhálózatában lévő végpontot és az Ön által irányított DNS-elrendezést használ, így a hozzá vezető útvonal közönséges útvonal egy Ön tulajdonában lévő címhez. A társítási export beállításai nem vonatkoznak erre a tervre, és a társítási változások PSC-telepítésbe másolása kockázatot ad hozzá elérhetőség nélkül.

Mindkettő privát címet ad; a hasonlóság ott véget ér.

Tesztelje az utat a helyes sorrendben

A külső ügyféltől először az adatbázis TCP-végpontját tesztelje. A befejezett TCP-kézfogás azt jelenti, hogy az útválasztás, a tűzfal és a figyelő mind a helyén van, és a következő teszt egy engedélyezett hitelesített művelet. A hitelesítés elutasítása ezen a ponton valójában jó hír, mert bizonyítja, hogy egy adatbázis-figyelő válaszolt. Az ICMP-időtúllépés szinte semmit sem mond az adatbázis-hozzáférésről, mert sok útvonal eldobja, miközben a TCP-t gond nélkül továbbítja.

Ha az ügyféltartományai az RFC 1918 hatókörén kívül esnek, tekintse át az útvonal-export és a hálózati engedélyezés további követelményeit, mielőtt arra a következtetésre jutna, hogy a terv nem támogatott.

Jegyezzen fel négy objektumot a kapcsolathoz: a külső előtagot, a kiosztott szolgáltatási tartományt, az érintett társítási kapcsolatokat és a hirdető útválasztót. Ez a négy magyarázza a teljes privát utat, és helyettesíti azt a tévhitet, hogy a Cloud SQL vagy mindig proxyt igényel, vagy egyáltalán nem érhető el VPN-en.