App Engine dosáhne na vaši databázi přes VPN: co musí souhlasit
Standardní App Engine skutečně dosáhne databáze přes Cloud VPN, ale jen když si sednou egress, rozsah zdroje a cesta požadavku. Tady je, co sladit.
Tvrzení, že App Engine Standard nedokáže dosáhnout na privátní databázi přes Cloud VPN, je pozůstatek starší generace platformy. Instance Standard nedostávají adresu nativní pro VPC jako některá jiná runtime prostředí, ale mohou posílat egress přes konektor Serverless VPC Access, který žije ve vaší síti. Jakmile tato cesta existuje, Cloud VPN a vzdálený firewall vidí provoz konektoru jako jakýkoli jiný zdroj. Co selhává, je málokdy samotná schopnost. Je to jedno ze tří nastavení, která se nikdy nesrovnala.
Odkud se vzala stará odpověď
Než konektory existovaly, praktická odpověď opravdu byla, že Standard umí mluvit jen s veřejnými koncovými body, a týmy přecházely na proxy VM nebo jiné runtime prostředí, aby to obešly. Platforma se změnila, folklór ne. Spousta rad na internetu stále odráží éru, kdy neexistovala žádná možnost egress.
Oprava je užší, než to zní. Standard se dostane do privátní sítě, ale jen přes podporovanou egress integraci a jen pro cíle, které tato integrace skutečně zachytí.
Nejprve vyberte egress cestu
Konektor připojený ke službě je to, co její provoz dostane do VPC. Dokumentace konektoru uvádí regionální předpoklad a nastavení egress; konektor musí existovat v regionu služby a být použitelný identitou, která nasazuje.
vpc_access_connector:
name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
egress_setting: private-ranges-only
private-ranges-only posílá privátní cíle do VPC a všechno ostatní nechává na běžné internetové cestě, což je obvykle to, co připojení k databázi potřebuje. all-traffic protlačuje odchozí provoz široce přes VPC, takže běžná internetová volání také dědí NAT a firewallový postoj VPC.
Úprava souboru lokálně nic nezmění, dokud nenasadíte. Běžící verze si zachovává konfiguraci, se kterou byla vytvořena.
Zdrojová adresa je konektor, ne váš laptop
Sem jde většina času na ladění. Vzdálená VPN brána a firewall databáze musí povolit přidělený rozsah konektoru uvnitř VPC, ne adresu vaší kanceláře a ne veřejnou egress adresu služby. Vyhledejte tento rozsah v konzoli, než napíšete jediné pravidlo.
Další dvě místa musí souhlasit. Směrovací tabulka VPC potřebuje trasu do vzdálené sítě databáze a vzdálená strana potřebuje zpětnou trasu pro rozsah konektoru. Pokud tunel používá selektory provozu, ověřte, že rozsah konektoru leží v dohodnutém rozsahu. Trasa, která existuje jen ve směru ze vzdálené do lokální strany, je časté opomenutí a propouští pingy, aniž by kdy dokončila TCP handshake.
Tunel, který povoluje jen podsíť VM, zahodí pakety konektoru bez užitečné chybové zprávy, a proto časový limit databáze vypadá jako problém s přihlašovacími údaji.
DNS jde jinou cestou
Název hostitele privátní databáze se musí přeložit uvnitř sítě, do které konektor dosáhne, přes Cloud DNS peering nebo předávací zónu, kterou VPC může použít. Přeložení na vaší pracovní stanici nic nedokazuje o nasazené službě, protože váš laptop tento resolver nepoužívá.
Pokud se název zevnitř VPC přeloží na veřejnou adresu, chystáte se ladit špatný firewall.
URL Fetch konektor nepoužívá
Nastavení egress pokrývá běžné odchozí sockety runtime prostředí a starší služba URL Fetch není součástí této cesty. Požadavek vydaný přes urlfetch konektor ignoruje, ať konfigurace říká cokoli. Když neúspěšné volání sedí ve starší knihovně, která stále používá URL Fetch, opravou je přesunout toto volání na standardní HTTP klient.
U ovladače databáze to málokdy bývá problém, ale je to klasický důvod, proč jeden koncový bod funguje a jiný ne ze stejné služby.
Ověřte jedním úzkým dotazem
Nasaďte a poté spusťte jednu povolenou databázovou operaci z nasazené verze a sledujte vzdálenou stranu. Zdrojová adresa zaznamenaná databází nebo VPN bránou by měla být adresa konektoru. Pokud není, požadavek nikdy nevstoupil do VPC a žádné množství konfigurace tunelu to nespraví. Porovnejte ji s rozsahem, který jste vyhledali v konzoli; neshoda obvykle znamená, že verzi obsluhuje druhý konektor.
Úspěšný dotaz z VM uvnitř VPC prokazuje, že trasa existuje. Neprokazuje, že ji služba zvolila.