GCP Classic VPN în Terraform: faceți tunelul bazat pe rute

În Classic VPN eticheta nu decide comportamentul. Bazat pe rute înseamnă un selector local 0.0.0.0/0, selectori la distanță potriviți și o rută explicită.

Planul se aplică curat, tunelul urcă, iar consola îl numește bazat pe politici. Traficul tot nu trece, iar căutarea unui comutator bazat pe rute în resursa Terraform nu duce nicăieri pentru că acel câmp nu există. În Classic VPN, comportamentul bazat pe rute nu este un mod pe care îl alegi. Este ceea ce obții când selectorul local de trafic este 0.0.0.0/0, selectorii la distanță listează rețelele pe care le vrei cu adevărat, iar o rută indică tunelul. Trei lucruri, iar eticheta urmează.

Mitul: un câmp pentru modul tunelului

Eticheta din consolă reflectă ceea ce vede API-ul în selectori. Nimic din resursă nu spune bazat pe rute, așa că nu este nimic de setat pe adevărat.

Căutarea acelui câmp consumă prima oră a problemei, în timp ce citirea valorilor selectorilor ia ultimele cinci minute.

Ce înseamnă aici bazat pe rute

Google documentează tunelurile bazate pe rute din Classic VPN ca tuneluri bazate pe politici al căror selector local este 0.0.0.0/0. Sunt numite doar intervalele la distanță, iar partea locală este tratată ca orice adresă. De aceea marcajul din configurația ta este o valoare, nu un mod. Scrie ambii selectori explicit și citește-i în rezultatul planului:

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

Prefixul partenerului din acel fragment este ilustrativ; forma este partea care contează.

Ruta este un obiect separat

Un obiect tunel nu instalează o rută. Pachetele pot corespunde politicii tunelului și tot nu au unde să meargă, pentru că tabela de rutare a VPC decide următorul salt. Ruta are nevoie de intervalul de destinație, rețea, tunelul ca următor salt și o prioritate care învinge orice e mai larg. Dacă uiți asta, obții un tunel care raportează stabilit și un ping care nu părăsește niciodată VPC-ul.

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
}

Creează ruta în același modul cu tunelul, ca cele două să nu se despartă la revizuire.

Oglindește selectorii la partener

Dispozitivul la distanță trebuie configurat în oglindă: intervalul lui local este selectorul tău la distanță, iar intervalul lui la distanță trebuie să acopere subrețelele GCP pe care intenționezi să le folosești. Dacă oricare parte se îngustează, faza 2 eșuează chiar dacă faza 1 reușește. Este cea mai frecventă formă a unei configurații care arată corect în consolă și nu transportă trafic.

Tipărește selectorii ambelor părți unul lângă altul în timpul revizuirii modificării.

Împarte adresa statică în două aplicări

Crearea adresei rezervate și a tunelului care o referențiază într-o singură aplicare este o sursă cunoscută de instabilitate, pentru că adresa trebuie să existe înainte ca regula de redirecționare să o poată folosi. Aplică mai întâi doar resursa adresei, apoi adaugă gateway-ul, regulile de redirecționare și tunelul și aplică din nou. Terraform citește adresa existentă din stare la a doua rulare și o refolosește. Dacă sari peste asta, tunelul poate primi o adresă publică nouă la fiecare aplicare, ceea ce strică configurația partenerului de fiecare dată.

Două aplicări acum sunt mai ieftine decât o schimbare de partener la fiecare lansare.

Verifică negocierea, nu eticheta

După aplicare, verifică trei fapte separate: tunelul raportează stabilit, ruta există cu următorul salt dorit, iar partenerul raportează că faza 1 și faza 2 sunt active.

Un tunel activ cu faza 2 căzută înseamnă că cele două părți nu sunt de acord asupra selectorilor:

  • O parte listează o subrețea pe care cealaltă nu o listează.
  • O parte folosește un agregat pe care cealaltă l-a îngustat.
  • Ruta există, dar indică alt tunel.

Classic VPN este un singur tunel cu un SLA mai mic decât HA VPN, iar HA VPN folosește două interfețe, două tuneluri și BGP cu tipuri de resurse diferite. Copierea unui exemplu clasic într-o configurație HA și așteptarea ca câmpurile de selector să se comporte la fel este o greșeală separată care merită evitată. Câmpurile tunelului în sine sunt documentate în referința google_compute_vpn_tunnel.

Articole similare