Az App Engine eléri a VPN-adatbázisát: minek kell egyeznie

Az az állítás, hogy az App Engine Standard nem tud elérni egy privát adatbázist Cloud VPN-en keresztül, a platform egy korábbi generációjából maradt fenn. A Standard-példányok nem kapnak VPC-natív címet, mint néhány más futtatókörnyezet, de egresszt küldhetnek egy Serverless VPC Access-összekötőn keresztül, amely a hálózatában él. Ha ez az útvonal létezik, a Cloud VPN és a távoli tűzfal ugyanúgy látja az összekötő forgalmát, mint bármely más forrást. Ami ritkán hibázik, az maga a képesség. Ez egyike annak a három beállításnak, amelyeket soha nem hangoltak össze.

Honnan jött a régi válasz

Mielőtt az összekötők léteztek, a gyakorlati válasz valóban az volt, hogy a Standard csak nyilvános végpontokkal tud beszélni, és a csapatok proxy VM-re vagy más futtatókörnyezetre váltottak, hogy megkerüljék. A platform megváltozott, a folklór nem. Sok online tanács még mindig azt a korszakot tükrözi, amikor egyáltalán nem volt egress-lehetőség.

A javítás szűkebb, mint amilyennek hangzik. A Standard eléri a privát hálózatot, de csak támogatott egress-integráción keresztül, és csak azokra a célokra, amelyeket az az integráció valóban elkap.

Először az egress-útvonalat válassza ki

A szolgáltatáshoz csatolt összekötő az, ami a forgalmát a VPC-be viszi. Az összekötő dokumentációja felsorolja a regionális előfeltételt és az egress-beállításokat; az összekötőnek a szolgáltatás régiójában kell léteznie, és a telepítő identitásnak használhatónak kell lennie.

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

A private-ranges-only privát célokat küld a VPC-be, és minden mást a normál internetes útvonalon hagy, ami általában az, amire egy adatbázis-kapcsolatnak szüksége van. A all-traffic széles körben átnyomja a kimenő forgalmat a VPC-n, így a hétköznapi internetes hívások is öröklik a VPC NAT- és tűzfalbeállításait.

A fájl helyi szerkesztése semmit sem változtat a telepítésig. Egy futó verzió megtartja azt a konfigurációt, amellyel létrehozták.

A forráscím az összekötő, nem a laptopja

Ide megy a hibakeresési idő nagy része. A távoli VPN-átjárónak és az adatbázis tűzfalának engedélyeznie kell az összekötőhöz kiosztott tartományt a VPC-n belül, nem az irodája címét és nem a szolgáltatás nyilvános egress-címét. Egyetlen szabály megírása előtt keresse meg ezt a tartományt a konzolon.

Két másik helynek is egyet kell értenie. A VPC útválasztási táblájának útvonalra van szüksége a távoli adatbázishálózat felé, a távoli oldalnak pedig visszaútvonalra az összekötő tartományához. Ha az alagút forgalomválasztókat használ, erősítse meg, hogy az összekötő tartománya az egyeztetett hatókörön belül van. A csak távoli irányból helyi felé létező útvonal gyakori hiba, és átengedi a pingeket, miközben soha nem fejezi be a TCP-kézfogást.

Az olyan alagút, amely csak egy VM-alhálózatot enged be, hasznos hibaüzenet nélkül dobja el az összekötő csomagjait, ezért tűnik az adatbázis időtúllépése hitelesítő adatok problémájának.

A DNS más útvonalon jár

A privát adatbázis gazdagépnevét azon a hálózaton belül kell feloldani, amelyet az összekötő elér, Cloud DNS-társításon vagy olyan továbbítási zónán keresztül, amelyet a VPC használhat. A munkaállomásán történő feloldás semmit sem bizonyít a telepített szolgáltatásról, mert a laptopja nem azt a feloldót használja.

Ha a név a VPC-n belülről nyilvános címre oldódik fel, akkor éppen a rossz tűzfalat fogja hibakeresni.

Az URL Fetch nem használja az összekötőt

Az egress-beállítás a futtatókörnyezet normál kimenő socketjeit fedi le, és az örökölt URL Fetch szolgáltatás nem része ennek az útvonalnak. Az urlfetch-en keresztül kiadott kérés figyelmen kívül hagyja az összekötőt, bármit is mond a konfiguráció. Ha a hibázó hívás egy régebbi könyvtárban van, amely még mindig URL Fetch-et használ, a javítás az, hogy áthelyezi azt a hívást a szabványos HTTP-kliensre.

Egy adatbázis-illesztőprogram esetében ez ritkán a probléma, de ez a klasszikus oka annak, hogy ugyanabból a szolgáltatásból az egyik végpont működik, a másik nem.

Ellenőrizze egyetlen szűk lekérdezéssel

Telepítsen, majd futtasson egyetlen engedélyezett adatbázis-műveletet a telepített verzióból, miközben figyeli a távoli oldalt. Az adatbázis vagy a VPN-átjáró által naplózott forráscímnek az összekötőének kell lennie. Ha nem az, a kérés soha nem lépett be a VPC-be, és semmilyen alagútkonfiguráció nem javítja meg. Hasonlítsa össze azzal a tartománnyal, amelyet a konzolon megkeresett; az eltérés általában azt jelenti, hogy egy második összekötő szolgálja ki a verziót.

A VPC-n belüli VM-ből indított sikeres lekérdezés bizonyítja, hogy az útvonal létezik. Azt nem bizonyítja, hogy a szolgáltatás azt választotta.