GCP Classic VPN v Terraformu: udělejte tunel směrovaný

V Classic VPN popisek nerozhoduje o chování. Směrovaný znamená lokální selektor 0.0.0.0/0, odpovídající vzdálené selektory a explicitní trasu.

Plán se aplikuje čistě, tunel naskočí a konzole ho nazývá založený na zásadách. Provoz stále neprochází a hledání přepínače směrovaného režimu v prostředku Terraform nikam nevede, protože takové pole neexistuje. V Classic VPN není směrované chování režim, který si vyberete. Je to to, co dostanete, když je lokální selektor provozu 0.0.0.0/0, vzdálené selektory vypisují sítě, které skutečně chcete, a trasa ukazuje na tunel. Tři věci a popisek následuje.

Mýtus: pole režimu tunelu

Popisek v konzoli odráží to, co API vidí v selektorech. Nic v prostředku neříká směrovaný, takže není co nastavit na pravda.

Hledání toho pole spotřebuje první hodinu problému, zatímco čtení hodnot selektorů zabere posledních pět minut.

Co tu směrovaný znamená

Google dokumentuje směrované tunely Classic VPN jako tunely založené na zásadách, jejichž lokální selektor je 0.0.0.0/0. Uvádějí se jen vzdálené rozsahy a lokální strana se považuje za libovolnou adresu. Proto je značka ve vaší konfiguraci hodnota, a ne režim. Napište oba selektory explicitně a přečtěte je ve výstupu plánu:

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

Předpona protistrany v tomto úryvku je ilustrativní; důležitý je tvar.

Trasa je samostatný objekt

Objekt tunelu neinstaluje trasu. Pakety mohou odpovídat zásadě tunelu a přesto nemít kam jít, protože další skok určuje směrovací tabulka VPC. Trasa potřebuje cílový rozsah, síť, tunel jako další skok a prioritu, která převáží cokoli širšího. Když na to zapomenete, vznikne tunel, který hlásí navázané spojení, a ping, který nikdy neopustí 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
}

Vytvořte trasu ve stejném modulu jako tunel, aby se obě při revizi nerozešly.

Zrcadlete selektory na protistraně

Vzdálené zařízení musí být nakonfigurováno zrcadlově: jeho lokální rozsah je váš vzdálený selektor a jeho vzdálený rozsah musí pokrývat podsítě GCP, které hodláte používat. Když kterákoli strana zúží, fáze 2 selže, i když fáze 1 uspěje. To je nejčastější podoba konfigurace, která v konzoli vypadá správně a nepřenáší žádný provoz.

Vytiskněte selektory obou stran vedle sebe při revizi změny.

Rozdělte statickou adresu do dvou aplikací

Vytvoření rezervované adresy a tunelu, který na ni odkazuje, v jedné aplikaci je známým zdrojem nestability, protože adresa musí existovat dřív, než ji pravidlo přesměrování může použít. Nejprve aplikujte jen prostředek adresy, potom přidejte bránu, pravidla přesměrování a tunel a aplikujte znovu. Terraform přečte existující adresu ze stavu při druhém běhu a znovu ji použije. Když to přeskočíte, může tunel při každé aplikaci dostat novou veřejnou adresu, což pokaždé rozbije konfiguraci protistrany.

Dvě aplikace teď jsou levnější než změna protistrany při každém vydání.

Ověřujte vyjednávání, ne popisek

Po aplikaci zkontrolujte tři oddělená fakta: tunel hlásí navázané spojení, trasa existuje se zamýšleným dalším skokem a protistrana hlásí, že fáze 1 i fáze 2 jsou nahoře.

Tunel, který je nahoře, ale fáze 2 dole, znamená, že se obě strany neshodují na selektorech:

  • Jedna strana uvádí podsíť, kterou druhá neuvádí.
  • Jedna strana používá agregát, který druhá zúžila.
  • Trasa existuje, ale ukazuje na jiný tunel.

Classic VPN je jediný tunel s nižší SLA než HA VPN a HA VPN používá dvě rozhraní, dva tunely a BGP s jinými typy prostředků. Zkopírovat klasický příklad do konfigurace HA a čekat, že se pole selektorů budou chovat stejně, je samostatná chyba, které stojí za to se vyhnout. Samotná pole tunelu jsou zdokumentována v referenci google_compute_vpn_tunnel.

Související články