GCP Classic VPN v Terraformu: naredite tunel na podlagi poti

V Classic VPN oznaka ne odloča o vedenju. Na podlagi poti pomeni lokalni izbirnik 0.0.0.0/0, ustrezne oddaljene izbirnike in izrecno pot.

Načrt se uporabi čisto, tunel se dvigne in konzola ga imenuje na podlagi pravil. Promet še vedno ne gre skozi, iskanje stikala na podlagi poti v viru Terraform pa ne vodi nikamor, ker takega polja ni. V Classic VPN vedenje na podlagi poti ni način, ki ga izberete. To je tisto, kar dobite, ko je lokalni izbirnik prometa 0.0.0.0/0, oddaljeni izbirniki naštejejo omrežja, ki jih res želite, in pot kaže na tunel. Tri stvari, in oznaka sledi.

Mit: polje načina tunela

Oznaka v konzoli odraža, kar API vidi v izbirnikih. Nič v viru ne pravi na podlagi poti, zato ni česa nastaviti na resnično.

Iskanje tega polja poje prvo uro težave, branje vrednosti izbirnikov pa vzame zadnjih pet minut.

Kaj tu pomeni na podlagi poti

Google dokumentira tunele Classic VPN na podlagi poti kot tunele na podlagi pravil, katerih lokalni izbirnik je 0.0.0.0/0. Imenovani so le oddaljeni razponi, lokalna stran pa se obravnava kot kateri koli naslov. Zato je oznaka v vaši konfiguraciji vrednost in ne način. Zapišite oba izbirnika izrecno in ju preberite v izpisu načrta:

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

Predpona sopotnika v tem izseku je ponazoritvena; oblika je tisto, kar šteje.

Pot je ločen objekt

Objekt tunela ne namesti poti. Paketi se lahko ujemajo s pravili tunela in vseeno nimajo kam iti, ker naslednji skok določi usmerjevalna tabela VPC. Pot potrebuje ciljni razpon, omrežje, tunel kot naslednji skok in prioriteto, ki premaga vse širše. Če to pozabite, dobite tunel, ki poroča vzpostavljeno povezavo, in preverjanje, ki nikoli ne zapusti 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
}

Ustvarite pot v istem modulu kot tunel, da se oba pri pregledu ne razideta.

Zrcalite izbirnike na sopotniku

Oddaljena naprava mora biti konfigurirana zrcalno: njen lokalni razpon je vaš oddaljeni izbirnik, njen oddaljeni razpon pa mora pokrivati podomrežja GCP, ki jih nameravate uporabljati. Če se katera koli stran zoži, faza 2 ne uspe, čeprav faza 1 uspe. To je najpogostejša oblika konfiguracije, ki je v konzoli videti pravilna in ne prenaša prometa.

Med pregledom spremembe natisnite izbirnike obeh strani enega ob drugega.

Razdelite statični naslov na dve uporabi

Ustvarjanje rezerviranega naslova in tunela, ki se nanj sklicuje, v eni uporabi je znan vir nestabilnosti, ker mora naslov obstajati, preden ga pravilo posredovanja lahko uporabi. Najprej uporabite samo vir naslova, nato dodajte prehod, pravila posredovanja in tunel ter uporabite znova. Terraform prebere obstoječi naslov iz stanja pri drugem zagonu in ga ponovno uporabi. Če to preskočite, lahko tunel pri vsaki uporabi dobi nov javni naslov, kar vsakič pokvari konfiguracijo sopotnika.

Dve uporabi zdaj sta cenejši od spremembe sopotnika pri vsaki izdaji.

Preverite pogajanje, ne oznake

Po uporabi preverite tri ločena dejstva: tunel poroča vzpostavljeno povezavo, pot obstaja z načrtovanim naslednjim skokom in sopotnik poroča, da sta faza 1 in faza 2 vzpostavljeni.

Tunel je vzpostavljen, faza 2 pa ne, kar pomeni, da se strani ne strinjata glede izbirnikov:

  • Ena stran navaja podomrežje, ki ga druga ne navaja.
  • Ena stran uporablja agregat, ki ga je druga zožila.
  • Pot obstaja, vendar kaže na drug tunel.

Classic VPN je en tunel z nižjim SLA kot HA VPN, HA VPN pa uporablja dva vmesnika, dva tunela in BGP z drugimi vrstami virov. Kopiranje klasičnega primera v konfiguracijo HA in pričakovanje, da se bodo polja izbirnikov vedla enako, je ločena napaka, ki se ji je vredno izogniti. Sama polja tunela so dokumentirana v referenci google_compute_vpn_tunnel.

Sorodni članki