GCP Classic VPN i Terraform: gør tunnelen rutebaseret

Planen anvendes rent, tunnelen kommer op, og konsollen kalder den policybaseret. Trafikken går stadig ikke igennem, og søgningen efter en rutebaseret kontakt i Terraform-ressourcen fører ingen vegne, fordi feltet ikke findes. I Classic VPN er rutebaseret adfærd ikke en tilstand, du vælger. Det er det, du får, når den lokale trafikselector er 0.0.0.0/0, fjernselectorerne lister de netværk, du faktisk vil have, og en rute peger på tunnelen. Tre ting, og etiketten følger med.

Myten: et felt til tunnelens tilstand

Konsollettiketten afspejler, hvad API'et ser i selectorerne. Intet i ressourcen siger rutebaseret, så der er intet at sætte til sand.

At lede efter det felt bruger den første time af problemet, mens læsning af selectorværdierne tager de sidste fem minutter.

Hvad rutebaseret betyder her

Google dokumenterer Classic VPN's rutebaserede tunneler som policybaserede tunneler, hvis lokale selector er 0.0.0.0/0. Kun fjernområderne navngives, og den lokale side behandles som en vilkårlig adresse. Derfor er markøren i din konfiguration en værdi og ikke en tilstand. Skriv begge selectorer eksplicit, og læs dem i planens output:

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

Peer-præfikset i det uddrag er illustrativt; formen er det, der betyder noget.

Ruten er et separat objekt

Et tunnelobjekt installerer ikke en rute. Pakker kan matche tunnelens politik og stadig ikke have nogen steder at gå hen, fordi VPC-rutetabellen bestemmer næste hop. Ruten skal have destinationsområdet, netværket, tunnelen som næste hop og en prioritet, der vinder over alt bredere. Glemmer du det, får du en tunnel, der rapporterer etableret, og en ping, der aldrig forlader 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
}

Opret ruten i samme modul som tunnelen, så de to ikke kan drive fra hinanden under gennemgangen.

Spejl selectorerne på peer'en

Fjernenheden skal konfigureres med spejlbilledet: dens lokale område er din fjernselector, og dens fjerne område skal dække de GCP-undernet, du forventer at bruge. Hvis en af siderne indsnævrer, fejler fase 2, selv om fase 1 lykkes. Det er den mest almindelige form for en konfiguration, der ser rigtig ud i konsollen og ikke bærer trafik.

Udskriv begge siders selectorer ved siden af hinanden under ændringsgennemgangen.

Del den statiske adresse op i to kørsler

At oprette den reserverede adresse og tunnelen, der refererer til den, i én kørsel er en kendt kilde til uro, fordi adressen skal findes, før videresendelsesreglen kan bruge den. Anvend først kun adresseressourcen, tilføj derefter gateway, videresendelsesregler og tunnel, og anvend igen. Terraform læser den eksisterende adresse fra state ved anden kørsel og genbruger den. Springer du det over, kan tunnelen få en ny offentlig adresse ved hver kørsel, hvilket ødelægger peer-konfigurationen hver gang.

To kørsler nu er billigere end en peer-ændring ved hver udgivelse.

Verificér forhandlingen, ikke etiketten

Efter anvendelsen skal du kontrollere tre separate fakta: tunnelen rapporterer etableret, ruten findes med det tilsigtede næste hop, og peer'en rapporterer både fase 1 og fase 2 oppe.

En tunnel, der er oppe med fase 2 nede, betyder, at de to sider er uenige om selectorerne:

• Den ene side lister et undernet, den anden ikke gør.
• Den ene side bruger et aggregate, som den anden har indsnævret.
• Ruten findes, men peger på en anden tunnel.

Classic VPN er en enkelt tunnel med lavere SLA end HA VPN, og HA VPN bruger to interfaces, to tunneler og BGP med andre ressourcetyper. At kopiere et klassisk eksempel til en HA-konfiguration og forvente, at selector-felterne opfører sig ens, er en separat fejl, der er værd at undgå. Selve tunnel-felterne er dokumenteret i referencen for google_compute_vpn_tunnel.