GCP Classic VPN i Terraform: gjør tunnelen rutebasert

Planen brukes rent, tunnelen kommer opp, og konsollen kaller den policybasert. Trafikken går fortsatt ikke gjennom, og letingen etter en rutebasert bryter i Terraform-ressursen fører ingen vei fordi feltet ikke finnes. I Classic VPN er rutebasert atferd ikke en modus du velger. Det er det du får når den lokale trafikkselektoren er 0.0.0.0/0, de eksterne selektorene lister nettverkene du faktisk vil ha, og en rute peker på tunnelen. Tre ting, og etiketten følger.

Myten: et felt for tunnelmodus

Konsolletiketten gjenspeiler det API-et ser i selektorene. Ingenting i ressursen sier rutebasert, så det er ingenting å sette til sant.

Å lete etter det feltet bruker den første timen av problemet, mens lesing av selektorverdiene tar de siste fem minuttene.

Hva rutebasert betyr her

Google dokumenterer Classic VPNs rutebaserte tunneler som policybaserte tunneler der den lokale selektoren er 0.0.0.0/0. Bare de eksterne områdene navngis, og den lokale siden behandles som en hvilken som helst adresse. Derfor er markøren i konfigurasjonen din en verdi og ikke en modus. Skriv begge selektorene eksplisitt og les dem i planutdataene:

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

Peer-prefikset i det utdraget er illustrativt; formen er det som betyr noe.

Ruten er et eget objekt

Et tunnelobjekt installerer ikke en rute. Pakker kan matche tunnelens policy og likevel ikke ha noe sted å gå, fordi VPC-rutertabellen bestemmer neste hopp. Ruten trenger målområdet, nettverket, tunnelen som neste hopp og en prioritet som vinner over alt bredere. Glemmer du det, får du en tunnel som rapporterer etablert og en ping som aldri forlater VPC-en.

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
}

Opprett ruten i samme modul som tunnelen, slik at de to ikke kan gli fra hverandre i gjennomgangen.

Speil selektorene på peer-en

Fjernenheten må konfigureres med speilbildet: dens lokale område er din eksterne selektor, og dens eksterne område må dekke GCP-subnettene du forventer å bruke. Hvis en av sidene snevres inn, feiler fase 2 selv om fase 1 lykkes. Det er den vanligste formen for en konfigurasjon som ser riktig ut i konsollen og ikke bærer trafikk.

Skriv ut selektorene til begge sider ved siden av hverandre under endringsgjennomgangen.

Del den statiske adressen i to kjøringer

Å opprette den reserverte adressen og tunnelen som refererer til den i én kjøring er en kjent kilde til uro, fordi adressen må finnes før videresendingsregelen kan bruke den. Bruk først bare adresseressursen, legg deretter til gatewayen, videresendingsreglene og tunnelen og bruk på nytt. Terraform leser den eksisterende adressen fra state ved andre kjøring og gjenbruker den. Hopper du over det, kan tunnelen få en ny offentlig adresse ved hver kjøring, noe som bryter peer-konfigurasjonen hver gang.

To kjøringer nå er billigere enn en peer-endring ved hver utgivelse.

Verifiser forhandlingen, ikke etiketten

Etter bruk, sjekk tre separate fakta: tunnelen rapporterer etablert, ruten finnes med det tiltenkte neste hoppet, og peer-en rapporterer at både fase 1 og fase 2 er oppe.

En tunnel som er oppe med fase 2 nede betyr at de to sidene er uenige om selektorene:

• Den ene siden lister et subnett den andre ikke lister.
• Den ene siden bruker et aggregat den andre har snevret inn.
• Ruten finnes, men peker på en annen tunnel.

Classic VPN er én enkelt tunnel med lavere SLA enn HA VPN, og HA VPN bruker to grensesnitt, to tunneler og BGP med andre ressurstyper. Å kopiere et klassisk eksempel inn i en HA-konfigurasjon og forvente at selektorfeltene oppfører seg likt er en egen feil som det er verdt å unngå. Selve tunnelfeltene er dokumentert i referansen for google_compute_vpn_tunnel.