Cloud Run către VPN local: configurarea ieșirii directe VPC

Un tunel Cloud VPN nu pune Cloud Run în rețea. Conectați serviciul la subrețeaua corectă, rutați intervalul său sursă, apoi testați acea revizie.

Tunelul este activ, o VM ajunge la serverul local, iar serviciul Cloud Run expiră pe același host. Acesta este punctul de plecare normal pentru această sarcină, iar tunelul este rareori ceea ce nu merge. O revizie Cloud Run nu se află în VPC-ul dumneavoastră implicit, iar când se află, folosește propriile adrese sursă în locul subrețelei VM pe care ați rutat-o deja. Runbook-ul de mai jos conectează serviciul, rutează intervalul său sursă real și apoi demonstrează calea din revizia care a servit cererea. Executați-l în această ordine, deoarece omiterea primului pas este motivul pentru care atât de multe dintre aceste cazuri se termină cu o modificare de VPN care nu repară nimic.

Conectați revizia înainte de a depana tunelul

Cloud Run acceptă ieșirea directă VPC, care pune traficul serviciului pe o subrețea din VPC-ul dumneavoastră fără un conector Serverless VPC Access. Pentru un serviciu existent, actualizarea arată astfel:

gcloud run services update SERVICE \
  --region=REGION --network=NETWORK --subnet=SUBNET \
  --vpc-egress=private-ranges-only

Înlocuiți substituenții, examinați ce face implementarea cu traficul live și alegeți o subrețea în regiunea serviciului cu suficientă capacitate de adrese și permisiunile de rețea corecte.

Alegeți modul de ieșire potrivit destinației

private-ranges-only trimite destinațiile pe care le clasifică drept private prin VPC. Aceasta nu înseamnă „tot ce este accesibil prin VPN”, iar acel gol apare când serviciul local se află într-un interval pe care setarea nu îl clasifică astfel. Dacă destinația nu este acoperită, all-traffic este celălalt mod documentat și trimite totul prin VPC, inclusiv dependențele publice ale serviciului. Alegeți deliberat și scrieți consecința în registrul de modificări.

Un serviciu care folosește deja un conector necesită o migrare, nu un comutator, așa că planificați-o în loc să configurați ambele.

Rutați sursa Cloud Run, nu o sursă VM

Ieșirea directă VPC alocă adrese efemere din subrețeaua selectată, iar partea locală trebuie să returneze traficul către acel interval. O rută de retur sau o permisiune de firewall scrisă pentru altă subrețea VM va părea corectă în diagramă și va eșua în practică. Luați CIDR-ul subrețelei din VPC și nu din memorie, apoi confirmați că ACL-ul criptografic sau tabela de rutare a dispozitivului îndepărtat îl include.

Cu rutare dinamică, verificați ce anunță efectiv Cloud Router și ce importă VPC-ul, inclusiv orice politică de anunț personalizată. O rută care există în consolă dar nu este selectată pentru această destinație este la fel ca nicio rută.

Trei condiții care trebuie să fie toate îndeplinite

O cale funcțională necesită toate cele de mai jos, iar fiecare eșuează în felul său:

  • O rută în VPC către prefixul local prin conexiunea Cloud VPN prevăzută.
  • O rută inversă la sediul local pentru subrețeaua Cloud Run.
  • Un domeniu de protecție firewall și IPsec care permite sursa, destinația și portul.

O rută lipsă arată de obicei ca un timeout fără dovezi pe partea îndepărtată. O problemă de rută inversă arată ca o cerere care ajunge și un răspuns care dispare. O problemă de firewall sau de selector poate arăta ca un refuz sau ca o renunțare silențioasă, în funcție de dispozitiv. Stabilirea careia dintre cele trei o aveți restrânge mult următoarea comandă.

Nu puneți o singură adresă Cloud Run temporară pe lista de permisiuni. Folosiți intervalul subrețelei și un design de autorizare potrivit aplicației.

Testați revizia care a servit cererea

Inspectați setările de rețea implementate și repartizarea traficului înainte de testare, deoarece o actualizare poate crea o revizie nouă în timp ce cererile ajung încă la una mai veche. Apoi executați aceeași operație pe care o execută cererea utilizatorului, din acea revizie. Dacă destinația este un nume de gazdă privat, verificați rezolvarea acestuia în acel mediu și adresa produsă, deoarece răspunsul DNS corporativ de pe laptopul dumneavoastră nu demonstrează nimic despre spațiul de nume al serviciului. Păstrați verificarea numelui de gazdă TLS și autentificarea proprie a aplicației îndepărtate.

Așteptați-vă la întârzierile documentate de conectare la pornirea Direct VPC și oferiți clientului o strategie de disponibilitate sau reîncercare în loc să diagnosticați fiecare pornire la rece ca un tunel stricat.

Revenirea și ce nu face aceasta

Pentru a reveni, readuceți setările de rețea și de ieșire ale serviciului la valorile anterioare și confirmați că revizia anterioară servește încă trafic. Păstrați comanda gcloud în registrul de modificări, deoarece inversul unei modificări parțiale nu este evident după șase săptămâni. Eliminarea atașării VPC readuce serviciul pe calea sa de ieșire anterioară, ceea ce poate fi exact ceea ce doriți în timpul unui incident.

Acest design acoperă conexiunile pe care Cloud Run le inițiază și răspunsurile lor. Nu oferă rețelei locale un socket adresabil în interiorul serviciului, deoarece expunerea spre interior este o decizie de ingress.

Articole similare