App Engine lahko doseže vašo podatkovno bazo VPN: kaj se mora ujemati
Standardni App Engine doseže podatkovno bazo prek Cloud VPN, vendar le, ko se ujemajo egress, obseg vira in pot zahteve. Tukaj je, kaj poravnati.
Trditev, da App Engine Standard ne more doseči zasebne podatkovne baze prek Cloud VPN, je ostanek prejšnje generacije platforme. Primerki Standard ne dobijo naslova, ki bi bil domač v VPC, kot nekatera druga izvajalna okolja, lahko pa pošiljajo egress prek konektorja Serverless VPC Access, ki živi v vašem omrežju. Ko ta pot obstaja, Cloud VPN in oddaljeni požarni zid vidita promet konektorja kot vsak drug vir. Kar spodleti, je redko sama zmožnost. To je ena od treh nastavitev, ki nikoli niso bile poravnane.
Od kod stari odgovor
Preden so konektorji obstajali, je bil praktični odgovor res, da lahko Standard govori le z javnimi končnimi točkami, ekipe pa so se preselile na posredniški VM ali drugo izvajalno okolje, da bi se temu izognile. Platforma se je spremenila, folklora ne. Veliko nasvetov na spletu še vedno odraža obdobje, ko možnosti egress sploh ni bilo.
Popravek je ožji, kot se sliši. Standard lahko doseže zasebno omrežje, vendar le prek podprte integracije egress in le za cilje, ki jih ta integracija resnično zajame.
Najprej izberite pot egress
Konektor, pripet na storitev, je tisto, kar njen promet postavi v VPC. Dokumentacija konektorja navaja regionalni pogoj in nastavitve egress; konektor mora obstajati v regiji storitve in biti uporaben identiteti, ki uvaja.
vpc_access_connector:
name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
egress_setting: private-ranges-only
private-ranges-only pošilja zasebne cilje v VPC in vse ostalo pusti na običajni internetni poti, kar običajno potrebuje povezava s podatkovno bazo. all-traffic široko potiska odhodni promet skozi VPC, zato tudi običajni internetni klici podedujejo NAT in požarnozidni položaj VPC.
Urejanje datoteke lokalno ne spremeni ničesar, dokler ne uvedete. Delujoča različica obdrži konfiguracijo, s katero je bila ustvarjena.
Naslov vira je konektor, ne vaš prenosnik
Tu gre večina časa za odpravljanje napak. Oddaljena VPN prehod in požarni zid podatkovne baze morata dovoliti obseg, dodeljen konektorju znotraj VPC, ne naslova vaše pisarne in ne javnega naslova egress storitve. Poiščite ta obseg v konzoli, preden napišete eno samo pravilo.
Še dve mesti se morata ujemati. Usmerjevalna tabela VPC potrebuje pot do oddaljenega omrežja podatkovne baze, oddaljena stran pa pot nazaj za obseg konektorja. Če tunel uporablja izbirnike prometa, potrdite, da je obseg konektorja znotraj dogovorjenega obsega. Pot, ki obstaja le v smeri od oddaljene proti lokalni strani, je pogosta spregledanost in prepušča ping, nikoli pa ne dokonča rokovanja TCP.
Tunel, ki dovoli le podmrežo VM, bo zavrgel pakete konektorja brez koristnega sporočila o napaki, zato se časovna omejitev podatkovne baze zdi kot težava s poverilnicami.
DNS potuje po drugi poti
Ime gostitelja zasebne podatkovne baze se mora razrešiti v omrežju, ki ga konektor doseže, prek partnerskega povezovanja Cloud DNS ali posredovalne cone, ki jo VPC lahko uporabi. Razreševanje na vaši delovni postaji ne dokaže ničesar o uvedeni storitvi, ker vaš prenosnik ne uporablja tega razreševalnika.
Če se ime znotraj VPC razreši v javni naslov, boste pravkar odpravljali napake na napačnem požarnem zidu.
URL Fetch ne uporablja konektorja
Nastavitev egress pokriva običajne odhodne vtičnice izvajalnega okolja, starejša storitev URL Fetch pa ni del te poti. Zahteva, izdana prek urlfetch, prezre konektor, ne glede na to, kaj pravi konfiguracija. Ko neuspešni klic sedi v starejši knjižnici, ki še vedno uporablja URL Fetch, je popravek premakniti ta klic na standardni odjemalec HTTP.
Za gonilnik podatkovne baze je to redko težava, je pa klasičen razlog, da ena končna točka deluje, druga pa ne iz iste storitve.
Preverite z eno ozko poizvedbo
Uvedite in nato izvedite eno dovoljeno operacijo s podatkovno bazo iz uvedene različice, medtem ko opazujete oddaljeno stran. Naslov vira, ki ga zabeleži podatkovna baza ali prehod VPN, bi moral biti naslov konektorja. Če ni, zahteva ni nikoli vstopila v VPC in nobena konfiguracija tunela tega ne odpravi. Primerjajte ga z obsegom, ki ste ga poiskali v konzoli; neujemanje običajno pomeni, da različico streže drugi konektor.
Uspešna poizvedba z VM znotraj VPC dokazuje, da pot obstaja. Ne dokazuje, da jo je storitev izbrala.