Planas taikomas švariai, tunelis pakyla, o konsolė jį vadina taisyklėmis pagrįstu. Srautas vis tiek neina, o maršrutais pagrįsto jungiklio paieška Terraform ištekliuje niekur neveda, nes tokio lauko nėra. Classic VPN maršrutais pagrįsta elgsena nėra režimas, kurį pasirenkate. Tai gaunate, kai vietinis srauto selektorius yra 0.0.0.0/0, nuotoliniai selektoriai išvardija tinklus, kurių tikrai norite, o maršrutas rodo į tunelį. Trys dalykai, ir etiketė seka.

Mitas: tunelio režimo laukas

Konsolės etiketė atspindi tai, ką API mato selektoriuose. Nieko ištekliuje nesako maršrutais pagrįstas, tad nėra ko nustatyti į tiesa.

To lauko paieška suvalgo pirmą problemos valandą, o selektorių reikšmių skaitymas užima paskutines penkias minutes.

Ką čia reiškia maršrutais pagrįstas

Google Classic VPN maršrutais pagrįstus tunelius dokumentuoja kaip taisyklėmis pagrįstus tunelius, kurių vietinis selektorius yra 0.0.0.0/0. Įvardijami tik nuotoliniai diapazonai, o vietinė pusė traktuojama kaip bet kuris adresas. Todėl žymeklis jūsų konfigūracijoje yra reikšmė, o ne režimas. Parašykite abu selektorius aiškiai ir perskaitykite juos plano išvestyje:

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

Partnerio prefiksas tame fragmente yra iliustracinis; forma yra tai, kas svarbu.

Maršrutas yra atskiras objektas

Tunelio objektas neįdiegia maršruto. Paketai gali atitikti tunelio taisyklę ir vis tiek neturėti kur eiti, nes kitą šuolį nusprendžia VPC maršrutizavimo lentelė. Maršrutui reikia paskirties diapazono, tinklo, tunelio kaip kito šuolio ir prioriteto, kuris įveikia bet ką platesnio. Jei to pamiršite, gausite tunelį, kuris praneša apie užmegztą ryšį, ir patikrą, kuri niekada neišeina iš 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
}

Kurkite maršrutą tame pačiame modulyje kaip tunelis, kad peržiūros metu abu neišsiskirtų.

Atspindėkite selektorius partnerio pusėje

Nuotolinis įrenginys turi būti sukonfigūruotas veidrodiniu atspindžiu: jo vietinis diapazonas yra jūsų nuotolinis selektorius, o jo nuotolinis diapazonas turi apimti GCP potinklius, kuriuos ketinate naudoti. Jei kuri nors pusė susiaurėja, 2 fazė nepavyksta, nors 1 fazė pavyksta. Tai dažniausia konfigūracijos forma, kuri konsolėje atrodo teisingai ir neperduoda srauto.

Pokyčio peržiūros metu atspausdinkite abiejų pusių selektorius vieną šalia kito.

Padalinkite statinį adresą į du taikymus

Rezervuoto adreso ir į jį nukreipiančio tunelio kūrimas vienu taikymu yra žinomas nestabilumo šaltinis, nes adresas turi egzistuoti prieš tai, kai persiuntimo taisyklė galės jį naudoti. Pirmiausia taikykite tik adreso išteklių, tada pridėkite tinklų sietuvą, persiuntimo taisykles ir tunelį bei taikykite dar kartą. Antro paleidimo metu Terraform perskaito esamą adresą iš būsenos ir jį naudoja iš naujo. Jei to nepadarysite, tunelis kiekvieno taikymo metu gali gauti naują viešą adresą, o tai kaskart sugriauna partnerio konfigūraciją.

Du taikymai dabar pigesni nei partnerio keitimas kiekviename leidime.

Tikrinkite derybas, o ne etiketę

Po taikymo patikrinkite tris atskirus faktus: tunelis praneša apie užmegztą ryšį, maršrutas egzistuoja su numatytu kitu šuoliu, o partneris praneša, kad veikia ir 1, ir 2 fazės.

Tunelis veikia, bet 2 fazė neveikia, o tai reiškia, kad dvi pusės nesutaria dėl selektorių:

  • Viena pusė išvardija potinklį, kurio kita neišvardija.
  • Viena pusė naudoja agregatą, kurį kita susiaurino.
  • Maršrutas egzistuoja, bet rodo į kitą tunelį.

Classic VPN yra vienas tunelis su žemesniu SLA nei HA VPN, o HA VPN naudoja dvi sąsajas, du tunelius ir BGP su kitais išteklių tipais. Klasikinio pavyzdžio kopijavimas į HA konfigūraciją ir tikėjimasis, kad selektorių laukai elgsis taip pat, yra atskira klaida, kurios verta vengti. Patys tunelio laukai dokumentuoti google_compute_vpn_tunnel žinyne.

Susiję straipsniai