GCP Classic VPN i Terraform: gör tunneln ruttbaserad

Planen tillämpas rent, tunneln kommer upp och konsolen kallar den principbaserad. Trafiken går fortfarande inte igenom, och sökandet efter en ruttbaserad växel i Terraform-resursen leder ingenstans eftersom fältet inte finns. I Classic VPN är ruttbaserat beteende inte ett läge som du väljer. Det är vad du får när den lokala trafikselectorn är 0.0.0.0/0, fjärrselectorerna listar de nätverk du faktiskt vill ha och en rutt pekar på tunneln. Tre saker, och etiketten följer med.

Myten: ett fält för tunnelläge

Konsolens etikett speglar vad API:t ser i selectorerna. Inget i resursen säger ruttbaserad, så det finns inget att sätta till sant.

Att leta efter fältet tar problemets första timme, medan läsning av selectorvärdena tar de sista fem minuterna.

Vad ruttbaserad betyder här

Google dokumenterar Classic VPN:s ruttbaserade tunnlar som principbaserade tunnlar vars lokala selector är 0.0.0.0/0. Bara fjärrområdena namnges, och den lokala sidan behandlas som vilken adress som helst. Därför är markören i din konfiguration ett värde och inte ett läge. Skriv båda selectorerna explicit och läs dem i planutskriften:

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

Peer-prefixet i det utdraget är illustrativt; formen är det som spelar roll.

Rutten är ett eget objekt

Ett tunnelobjekt installerar ingen rutt. Paket kan matcha tunnelns princip och ändå inte ha någonstans att ta vägen, eftersom VPC:s routingtabell avgör nästa hopp. Rutten behöver destinationsområdet, nätverket, tunneln som nästa hopp och en prioritet som vinner över allt bredare. Glömmer man det får man en tunnel som rapporterar etablerad och en ping som aldrig lämnar VPC:n.

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

Skapa rutten i samma modul som tunneln, så att de två inte kan glida isär i granskningen.

Spegla selectorerna hos peeren

Fjärrenheten måste konfigureras med spegelbilden: dess lokala område är din fjärrselector, och dess fjärrområde måste täcka de GCP-subnät du förväntar dig att använda. Om någon av sidorna snävas in misslyckas fas 2 även om fas 1 lyckas. Det är den vanligaste formen av en konfiguration som ser rätt ut i konsolen och inte bär trafik.

Skriv ut båda sidornas selectorer bredvid varandra under ändringsgranskningen.

Dela upp den statiska adressen i två körningar

Att skapa den reserverade adressen och tunneln som refererar till den i en enda körning är en känd källa till oro, eftersom adressen måste finnas innan vidarebefordringsregeln kan använda den. Använd först bara adressresursen, lägg sedan till gatewayen, vidarebefordringsreglerna och tunneln och använd igen. Terraform läser den befintliga adressen från state vid andra körningen och återanvänder den. Om du hoppar över det kan tunneln få en ny offentlig adress vid varje körning, vilket bryter peer-konfigurationen varje gång.

Två körningar nu är billigare än en peer-ändring vid varje release.

Verifiera förhandlingen, inte etiketten

Efter användning, kontrollera tre separata fakta: tunneln rapporterar etablerad, rutten finns med nästa hopp som avsetts, och peeren rapporterar att både fas 1 och fas 2 är uppe.

En tunnel som är uppe med fas 2 nere betyder att de två sidorna inte är överens om selectorerna:

• Den ena sidan listar ett subnät som den andra inte listar.
• Den ena sidan använder ett aggregat som den andra har snävat in.
• Rutten finns men pekar på en annan tunnel.

Classic VPN är en enda tunnel med lägre SLA än HA VPN, och HA VPN använder två gränssnitt, två tunnlar och BGP med andra resurstyper. Att kopiera ett klassiskt exempel till en HA-konfiguration och förvänta sig att selectorfälten beter sig likadant är ett separat misstag som det är värt att undvika. Själva tunnelfälten är dokumenterade i referensen för google_compute_vpn_tunnel.