GCP Classic VPN sa Terraform: gawing ruta-based ang tunnel

Malinis na naiaaplay ang plano, bumabangon ang tunnel, at tinatawag itong policy-based ng console. Hindi pa rin dumadaan ang trapiko, at ang paghahanap ng ruta-based na switch sa Terraform resource ay walang patutunguhan dahil walang ganoong field. Sa Classic VPN, ang ruta-based na gawi ay hindi mode na pinipili mo. Ito ang nakukuha mo kapag ang lokal na trapiko selector ay 0.0.0.0/0, inililista ng remote selector ang mga network na talagang gusto mo, at may rutang tumuturo sa tunnel. Tatlong bagay, at sumusunod ang label.

Ang mito: field ng tunnel mode

Ang label sa console ay nagpapakita ng nakikita ng API sa mga selector. Walang sinasabi ang resource na ruta-based, kaya walang iseset sa totoo.

Ang paghahanap sa field na iyon ay kumakain ng unang oras ng problema, habang ang pagbasa ng mga halaga ng selector ay tumatagal ng huling limang minuto.

Ano ang ibig sabihin ng ruta-based dito

Idinodokumento ng Google ang ruta-based na tunnel ng Classic VPN bilang policy-based na tunnel na ang lokal na selector ay 0.0.0.0/0. Ang mga remote range lang ang pinangalanan, at ang lokal na panig ay itinuturing na kahit anong address. Kaya ang marker sa configuration mo ay isang halaga at hindi mode. Isulat nang tahasan ang dalawang selector at basahin sa output ng plano:

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

Ang peer prefix sa snippet na iyon ay ilustratibo; ang hugis ang mahalaga.

Ang ruta ay hiwalay na object

Ang tunnel object ay hindi nag-iinstall ng ruta. Maaaring tumugma ang mga packet sa patakaran ng tunnel at wala pa ring mapuntahan, dahil ang VPC routing table ang nagpapasya ng susunod na hop. Kailangan ng ruta ang destinasyong range, network, tunnel bilang susunod na hop at priority na nananalo sa anumang mas malawak. Kapag nakalimutan ito, makakakuha ka ng tunnel na nag-uulat ng established at ping na hindi lumalabas sa 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
}

Gawin ang ruta sa parehong module ng tunnel, para hindi maghiwalay ang dalawa sa review.

I-mirror ang mga selector sa peer

Ang remote device ay dapat i-configure na mirror image: ang lokal na range nito ay ang remote selector mo, at ang remote range nito ay dapat sumakop sa mga GCP subnet na inaasahan mong gamitin. Kapag lumiyit ang alinmang panig, nabibigo ang phase 2 kahit nagtagumpay ang phase 1. Ito ang pinakakaraniwang hugis ng configuration na mukhang tama sa console at walang dalang trapiko.

I-print ang mga selector ng dalawang panig nang magkatabi sa review ng pagbabago.

Hatiin ang static address sa dalawang apply

Ang paggawa ng reserved address at ng tunnel na nagrerefer dito sa isang apply ay kilalang pinagmumulan ng gulo, dahil kailangang umiral ang address bago ito magamit ng forwarding rule. I-apply muna ang address resource lang, pagkatapos idagdag ang gateway, forwarding rules at tunnel at i-apply muli. Binabasa ng Terraform ang umiiral na address mula sa state sa ikalawang run at ginagamit muli. Kapag nilaktawan ito, maaaring makakuha ang tunnel ng bagong public address sa bawat apply, na sumisira sa configuration ng peer tuwing ganoon.

Ang dalawang apply ngayon ay mas mura kaysa sa pagbabago ng peer tuwing release.

I-verify ang negosasyon, hindi ang label

Pagkatapos mag-apply, tingnan ang tatlong hiwalay na katotohanan: nag-uulat ang tunnel ng established, umiiral ang ruta kasama ang nilalayong susunod na hop, at nag-uulat ang peer na ang phase 1 at phase 2 ay parehong up.

Ang tunnel na up habang ang phase 2 ay down ay nangangahulugang hindi nagkakasundo ang dalawang panig sa mga selector:

• May inililista ang isang panig na subnet na hindi inililista ng isa.
• Gumagamit ang isang panig ng aggregate na pinaliit ng isa.
• Umiiral ang ruta pero tumuturo sa ibang tunnel.

Ang Classic VPN ay isang tunnel na may mas mababang SLA kaysa HA VPN, at gumagamit ang HA VPN ng dalawang interface, dalawang tunnel at BGP na may ibang uri ng resource. Ang pagkopya ng klasikong halimbawa sa HA configuration at pag-asang magkakapareho ang gawi ng selector field ay hiwalay na pagkakamaling dapat iwasan. Ang mga field ng tunnel mismo ay dokumentado sa reference ng google_compute_vpn_tunnel.