GCP Classic VPN u Terraformu: učinite tunel rutiranim

Plan se čisto primjenjuje, tunel se diže, a konzola ga naziva pravilima utemeljenim. Promet i dalje ne prolazi, a traženje preklopnika za rutirani način rada u Terraform resursu ne vodi nikamo jer takvo polje ne postoji. U Classic VPN rutirano se ponašanje ne bira kao način rada. To je ono što dobijete kada je lokalni selektor prometa 0.0.0.0/0, udaljeni selektori navode mreže koje doista želite, a ruta pokazuje na tunel. Tri stvari, i oznaka slijedi.

Mit: polje načina rada tunela

Oznaka u konzoli odražava ono što API vidi u selektorima. Ništa u resursu ne kaže rutirano, pa nema što postaviti na istinito.

Traženje tog polja pojede prvi sat problema, a čitanje vrijednosti selektora zadnjih pet minuta.

Što ovdje znači rutirano

Google dokumentira rutirane tunele Classic VPN-a kao tunele utemeljene na pravilima čiji je lokalni selektor 0.0.0.0/0. Imenuju se samo udaljeni rasponi, a lokalna strana tretira se kao bilo koja adresa. Zato je oznaka u vašoj konfiguraciji vrijednost, a ne način rada. Zapišite oba selektora eksplicitno i pročitajte ih u izlazu plana:

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

Prefiks partnera u tom isječku je ilustrativan; oblik je ono što je važno.

Ruta je zaseban objekt

Objekt tunela ne instalira rutu. Paketi mogu odgovarati pravilima tunela i još uvijek nemati kamo otići, jer sljedeći skok određuje VPC tablica usmjeravanja. Ruti trebaju odredišni raspon, mreža, tunel kao sljedeći skok i prioritet koji pobjeđuje sve šire. Ako to zaboravite, dobivate tunel koji prijavljuje uspostavljenu vezu i provjeru koja nikada ne napušta VPC.

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
}

Stvorite rutu u istom modulu kao tunel, kako se njih dvoje ne bi razišli tijekom pregleda.

Zrcalite selektore na partneru

Udaljeni uređaj mora biti konfiguriran zrcalno: njegov lokalni raspon je vaš udaljeni selektor, a njegov udaljeni raspon mora pokrivati GCP podmreže koje namjeravate koristiti. Ako bilo koja strana suzi, faza 2 ne uspijeva iako faza 1 uspije. To je najčešći oblik konfiguracije koja u konzoli izgleda ispravno i ne prenosi promet.

Ispišite selektore obiju strana jedan uz drugi tijekom pregleda promjene.

Podijelite statičnu adresu u dvije primjene

Stvaranje rezervirane adrese i tunela koji se na nju poziva u jednoj primjeni poznat je izvor nestabilnosti, jer adresa mora postojati prije nego što je pravilo prosljeđivanja može koristiti. Prvo primijenite samo resurs adrese, zatim dodajte gateway, pravila prosljeđivanja i tunel pa primijenite ponovno. Terraform čita postojeću adresu iz stanja pri drugom pokretanju i ponovno je koristi. Preskočite li to, tunel može dobiti novu javnu adresu pri svakoj primjeni, što svaki put slomi konfiguraciju partnera.

Dvije primjene sada su jeftinije od promjene partnera pri svakom izdanju.

Provjerite pregovaranje, ne oznaku

Nakon primjene provjerite tri odvojene činjenice: tunel prijavljuje uspostavljenu vezu, ruta postoji s predviđenim sljedećim skokom, a partner prijavljuje da su faza 1 i faza 2 podignute.

Tunel koji je gore, a faza 2 je dolje, znači da se dvije strane ne slažu oko selektora:

• Jedna strana navodi podmrežu koju druga ne navodi.
• Jedna strana koristi agregat koji je druga suzila.
• Ruta postoji, ali pokazuje na drugi tunel.

Classic VPN jedan je tunel s nižim SLA-om od HA VPN-a, a HA VPN koristi dva sučelja, dva tunela i BGP s različitim vrstama resursa. Kopiranje klasičnog primjera u HA konfiguraciju i očekivanje da će se polja selektora ponašati jednako zasebna je pogreška koju vrijedi izbjeći. Sama polja tunela dokumentirana su u referenci google_compute_vpn_tunnel.