App Engine poate ajunge la baza dvs. de date VPN: ce trebuie să coincidă

Afirmația că App Engine Standard nu poate ajunge la o bază de date privată prin Cloud VPN este o rămășiță dintr-o generație anterioară a platformei. Instanțele Standard nu primesc o adresă nativă VPC precum unele alte medii de execuție, dar pot trimite egress printr-un conector Serverless VPC Access care se află în rețeaua dvs. Odată ce acea cale există, Cloud VPN și firewallul de la distanță văd traficul conectorului ca orice altă sursă. Ceea ce eșuează este rareori capacitatea în sine. Este una dintre cele trei setări care nu au fost niciodată aliniate.

De unde a venit răspunsul vechi

Înainte să existe conectori, răspunsul practic era într-adevăr că Standard putea vorbi doar cu puncte finale publice, iar echipele treceau la un VM proxy sau la alt mediu de execuție pentru a ocoli asta. Platforma s-a schimbat, folclorul nu. Multe sfaturi online reflectă încă epoca în care nu exista deloc opțiune de egress.

Corectarea este mai îngustă decât sună. Standard poate ajunge la rețeaua privată, dar numai printr-o integrare de egress acceptată, și numai pentru destinațiile pe care acea integrare le captează efectiv.

Alegeți mai întâi calea de egress

Un conector atașat serviciului este cel care îi pune traficul în VPC. Documentația conectorului enumeră cerința regională și setările de egress; conectorul trebuie să existe în regiunea serviciului și să poată fi folosit de identitatea care implementează.

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

private-ranges-only trimite destinațiile private în VPC și lasă tot restul pe calea normală a internetului, ceea ce de obicei este ce are nevoie o conexiune la bază de date. all-traffic împinge traficul de ieșire prin VPC în mod larg, așa că apelurile obișnuite la internet moștenesc și ele poziția NAT și firewall a VPC.

Editarea fișierului local nu schimbă nimic până când implementați. O versiune care rulează păstrează configurația cu care a fost creată.

Adresa sursă este conectorul, nu laptopul dvs.

Aici se duce cea mai mare parte a timpului de depanare. Gateway-ul VPN de la distanță și firewallul bazei de date trebuie să admită intervalul alocat conectorului în interiorul VPC, nu adresa biroului dvs. și nu adresa de egress publică a serviciului. Căutați acel interval în consolă înainte de a scrie măcar o regulă.

Încă două locuri trebuie să fie de acord. Tabelul de rute al VPC are nevoie de o rută către rețeaua de la distanță a bazei de date, iar partea de la distanță are nevoie de o rută de întoarcere pentru intervalul conectorului. Dacă tunelul folosește selectori de trafic, confirmați că intervalul conectorului se află în domeniul negociat. O rută care există doar în direcția de la distanță spre local este o scăpare frecventă și lasă ping-urile să treacă fără a finaliza vreodată un handshake TCP.

Un tunel care admite doar o subrețea de VM va arunca pachetele conectorului fără un mesaj de eroare util, motiv pentru care expirarea bazei de date arată ca o problemă de acreditări.

DNS-ul călătorește pe o altă cale

Un nume de gazdă al unei baze de date private trebuie rezolvat în rețeaua la care ajunge conectorul, prin peering Cloud DNS sau o zonă de redirecționare pe care VPC o poate folosi. Rezolvarea lui pe stația dvs. de lucru nu dovedește nimic despre serviciul implementat, deoarece laptopul dvs. nu folosește acel resolver.

Dacă numele se rezolvă într-o adresă publică din interiorul VPC, sunteți pe punctul de a depana firewallul greșit.

URL Fetch nu folosește conectorul

Setarea de egress acoperă socketurile de ieșire normale ale mediului de execuție, iar serviciul legacy URL Fetch nu face parte din acea cale. O cerere emisă prin urlfetch ignoră conectorul, indiferent ce spune configurația. Când apelul care eșuează se află într-o bibliotecă mai veche care încă folosește URL Fetch, soluția este să mutați acel apel pe clientul HTTP standard.

Pentru un driver de bază de date acesta este rareori problema, dar este motivul clasic pentru care un punct final funcționează, iar altul nu, din același serviciu.

Verificați cu o singură interogare îngustă

Implementați, apoi executați o singură operațiune permisă pe baza de date din versiunea implementată, urmărind partea de la distanță. Adresa sursă înregistrată de bază de date sau de gateway-ul VPN ar trebui să fie a conectorului. Dacă nu este, cererea nu a intrat niciodată în VPC și nicio configurație de tunel nu o va repara. Comparați-o cu intervalul pe care l-ați căutat în consolă; o nepotrivire înseamnă de obicei că un al doilea conector deservește versiunea.

O interogare reușită dintr-un VM din interiorul VPC stabilește că ruta există. Nu stabilește că serviciul a ales-o.