GCP VPN-rute virker kun i en region: kontroller dynamisk routing

Arbejdsbelastningen i USA når kontorpræfikset over HA VPN uden problemer, mens den europæiske arbejdsbelastning i samme VPC slet ikke får noget. Dens routingtabel indeholder ingen post for præfikset, ingen tunnel er nede, og ingen firewallregel er ændret. Tunnelen og dens BGP-session er sunde i begge retninger. En VPC, der spænder over regioner, er ikke det samme som dens lærte ruter, der spænder over regioner, og netop det gab forklarer hele symptomet.

Her forveksles to egenskaber: hvor undernettene bor, og hvor et lært næste hop må bruges.

Hvor det regionale omfang kommer fra

Cloud Router installerer lærte ruter med et omfang, der følger VPC'ens dynamiske routingtilstand. I regional tilstand kan en rute, der er lært i én region, kun bruges af den regions ressourcer, og derfor er den europæiske tabel tom i stedet for at vise et brudt næste hop. I global tilstand bliver kvalificerede lærte ruter tilgængelige for ressourcer i alle VPC'ens regioner. Læs den aktuelle værdi, før du ændrer noget, fordi regional er standarden. Indstillingen ligger på netværket, ikke på tunnelen eller på routeren.

Inventarkommandoen er skrivebeskyttet og svarer på det på én linje:

gcloud compute networks describe VPC_NAME --format='value(routingConfig.routingMode)'

Kør den i værtsprojektet, når VPC'en er delt. Netværket tilhører det projekt, og en fremviserrrolle i arbejdsbelastningsprojektet viser måske slet ikke routingkonfigurationen. Et hurtigt svar fra det forkerte projekt er værre end intet svar.

Ændringen er én kommando og én retning

Skiftet er en redigering af kontrolplanet for hele VPC'en, ikke en omvej pr. VM: gcloud compute networks update VPC_NAME --routing-mode=GLOBAL. Det er også envejs, fordi et netværk, der er sat til global, ikke kan føres tilbage til regional. Kontrollér projekt- og netværksnavnet én gang mere, før du kører det, da kommandoen ikke beder om bekræftelse. Ændringen fortjener en vedligeholdelsesnote og netværksejerens godkendelse frem for et hurtigt eksperiment på en delt VPC.

Hver Cloud Router-, VPN- og Interconnect-tilknytning i det netværk arver det nye omfang med det samme. Det omfatter de tilknytninger, som ingen nævnte i ændringsanmodningen. Regioner, der aldrig før har haft ruten, begynder at modtage den, så snart ændringen træder i kraft, og derfor er der ingen trinvis udrulning for dette skift.

Globalt er et omfang, ikke en garanti

Kvalifikation og præference er adskilt fra omfang. En rute, der er i konflikt med et mere specifikt præfiks, taber valget af bedste vej eller filtreres af politik, opfører sig præcis som før. Global tilstand udvider, hvor en rute må bruges, men afgør ikke, hvilken rute der vinder. En lært rute kan være inden for omfanget og alligevel tabe til en statisk eller mere specifik vej på samme VPC.

Den forskel betyder noget, fordi tilstandsændringen er let at bebrejde senere. Hvis det europæiske undernet stadig ikke har nogen rute efter skiftet, er spørgsmålet, om ruten findes og er kvalificeret, ikke om omfanget trådte i kraft. Præfiks konflikter og næste hops sundhed er de næste to ting at læse.

Fjernsiden annoncerer også anderledes

Annonceringsadfærd følger den samme indstilling. Med standardadfærd annoncerer en router i regional tilstand undernettene i sin egen region, mens global tilstand annoncerer VPC'ens undernet bredere. Derfor ændrer tilstanden ikke kun, hvad dine egne regioner må bruge, men også hvad fjernsiden installerer.

En brugerdefineret annonceringsliste udvides ikke, når tilstanden ændres. Hvis den lokale router har en håndskrevet liste over intervaller, forbliver det europæiske præfiks fraværende i den. Returvejen forbliver brudt i det tilfælde, selv om den udgående rute nu findes. Kontrollér, hvad fjernsiden installerede, i stedet for hvad du eksporterede.

Hvad tilstanden aldrig vil reparere

Global routing giver ikke adgang til offentligt internet, transit mellem ubeslægtede VPC'er eller manglende statiske ruter. Den ændrer ikke firewallregler eller IAM, så en forbindelse, der afvises af politik, forbliver afvist.

Disse fejl ser ens ud indefra en arbejdsbelastning og har intet at gøre med ruteomfang.

Test fra den fjerne region til den rigtige tjeneste, og bekræft derefter, at svaret kommer tilbage gennem den tilsigtede tunnel. Notér tilstanden, annonceringskonfigurationen og den destination, du testede. Hvis testen stadig fejler, så sammenlign fjernrouterens BGP-tabel med VPC'ens rutteliste, før du rører ved tilstanden igen. Så starter den næste rapport på tværs af regioner med fakta i stedet for med en tilstandsændring.