GCP Classic VPN i Terraform: gjer tunnelen rutebasert

Planen blir brukt reint, tunnelen kjem opp, og konsollen kallar han policybasert. Trafikken går framleis ikkje gjennom, og leitinga etter ein rutebasert brytar i Terraform-ressursen fører ingen veg fordi feltet ikkje finst. I Classic VPN er rutebasert åtferd ikkje ein modus du vel. Det er det du får når den lokale trafikkselektoren er 0.0.0.0/0, dei eksterne selektorane listar netverka du faktisk vil ha, og ei rute peikar på tunnelen. Tre ting, og etiketten følgjer.

Myten: eit felt for tunnelmodus

Konsolletiketten speglar det API-et ser i selektorane. Ingenting i ressursen seier rutebasert, så det er ingenting å setje til sant.

Å leite etter det feltet brukar den første timen av problemet, medan lesing av selektorverdiane tek dei siste fem minutta.

Kva rutebasert tyder her

Google dokumenterer dei rutebaserte tunnelane til Classic VPN som policybaserte tunnelar der den lokale selektoren er 0.0.0.0/0. Berre dei eksterne områda blir namngjevne, og den lokale sida blir handsama som ei kvar som helst adresse. Derfor er markøren i konfigurasjonen din ein verdi og ikkje ein modus. Skriv begge selektorane eksplisitt og les dei i planutdataa:

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

Peer-prefikset i det utdraget er illustrativt; forma er det som har noko å seie.

Ruta er eit eige objekt

Eit tunnelobjekt installerer ikkje ei rute. Pakkar kan matche policyen til tunnelen og likevel ikkje ha nokon stad å gå, fordi VPC-rutetabellen avgjer neste hopp. Ruta treng målområdet, netverket, tunnelen som neste hopp og ein prioritet som vinn over alt breiare. Gløymer du det, får du ein tunnel som rapporterer etablert og ein ping som aldri forlèt 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 ruta i same modul som tunnelen, slik at dei to ikkje kan gli frå kvarandre i gjennomgangen.

Spegle selektorane på peer-en

Fjerneininga må konfigurerast med spegelbiletet: det lokale området hennar er din eksterne selektor, og det eksterne området hennar må dekkje GCP-subnetta du ventar å bruke. Viss ei av sidene blir snøgd inn, feilar fase 2 sjølv om fase 1 lukkast. Det er den vanlegaste forma for ein konfigurasjon som ser rett ut i konsollen og ikkje ber trafikk.

Skriv ut selektorane til begge sider ved sida av kvarandre under endringsgjennomgangen.

Del den statiske adressa i to køyringar

Å opprette den reserverte adressa og tunnelen som viser til henne i éi køyring er ei kjend kjelde til uro, fordi adressa må finnast før videresendingsregelen kan bruke henne. Bruk først berre adresseressursen, legg så til gatewayen, videresendingsreglane og tunnelen og bruk på nytt. Terraform les den eksisterande adressa frå state ved andre køyring og brukar henne om att. Hoppar du over det, kan tunnelen få ei ny offentleg adresse ved kvar køyring, noko som bryt peer-konfigurasjonen kvar gong.

To køyringar no er billegare enn ei peer-endring ved kvar utgiving.

Verifiser forhandlinga, ikkje etiketten

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

Ein tunnel som er oppe med fase 2 nede tyder at dei to sidene er usamde om selektorane:

• Den eine sida listar eit subnett den andre ikkje listar.
• Den eine sida brukar eit aggregat den andre har snøgt inn.
• Ruta finst, men peikar på ein annan tunnel.

Classic VPN er éin einaste tunnel med lågare SLA enn HA VPN, og HA VPN brukar to grensesnitt, to tunnelar og BGP med andre ressurstypar. Å kopiere eit klassisk døme inn i ein HA-konfigurasjon og vente at selektorfelta oppfører seg likt er ein eigen feil det er verdt å unngå. Sjølve tunnelfelta er dokumenterte i referansen for google_compute_vpn_tunnel.