GCP Classic VPN en Terraform: faga que o túnel sexa baseado en rutas

O plan aplícase sen problemas, o túnel lévase e a consola chámao baseado en políticas. O tráfico segue sen pasar, e a busca dun interruptor baseado en rutas no recurso de Terraform non leva a ningures porque ese campo non existe. En Classic VPN, o comportamento baseado en rutas non é un modo que se escolla. É o que se obtén cando o selector de tráfico local é 0.0.0.0/0, os selectores remotos enumeran as redes que realmente se queren e unha ruta apunta ao túnel. Tres cousas, e a etiqueta segue.

O mito: un campo de modo do túnel

A etiqueta da consola reflicte o que a API ve nos selectores. Nada no recurso di baseado en rutas, así que non hai nada que poñer en verdadeiro.

Buscar ese campo consume a primeira hora do problema, mentres que ler os valores dos selectores ocupa os últimos cinco minutos.

Que significa aquí baseado en rutas

Google documenta os túneles baseados en rutas de Classic VPN como túneles baseados en políticas cuxo selector local é 0.0.0.0/0. Só se nomean os rangos remotos, e o lado local trátase como calquera enderezo. Por iso o marcador da súa configuración é un valor e non un modo. Escriba ambos os selectores de forma explícita e léaos na saída do plan:

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

O prefixo do par nese fragmento é ilustrativo; a forma é o que importa.

A ruta é un obxecto aparte

Un obxecto de túnel non instala unha ruta. Os paquetes poden coincidir coa política do túnel e aínda así non teren onde ir, porque a táboa de encamiñamento da VPC decide o seguinte salto. A ruta necesita o rango de destino, a rede, o túnel como seguinte salto e unha prioridade que gañe a calquera cousa máis ampla. Se se esquece, obtense un túnel que informa de establecido e un ping que nunca sae da 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
}

Cree a ruta no mesmo módulo que o túnel, para que os dous non se separen durante a revisión.

Reflicta os selectores no par

O dispositivo remoto debe configurarse coa imaxe espello: o seu rango local é o seu selector remoto, e o seu rango remoto debe cubrir as subredes de GCP que espera usar. Se calquera dos dous lados se estreita, a fase 2 falla aínda que a fase 1 teña éxito. É a forma máis común dunha configuración que parece correcta na consola e non transporta tráfico.

Imprima os selectores de ambos os lados un xunto ao outro durante a revisión do cambio.

Divida o enderezo estático en dúas aplicacións

Crear o enderezo reservado e o túnel que o referencia nunha soa aplicación é unha fonte coñecida de inestabilidade, porque o enderezo debe existir antes de que a regra de reenvío poida usalo. Aplique primeiro só o recurso do enderezo, despois engada a pasarela, as regras de reenvío e o túnel e volva aplicar. Terraform le o enderezo existente do estado na segunda execución e reutilízao. Se se salta iso, o túnel pode recibir un enderezo público novo en cada aplicación, o que rompe a configuración do par cada vez.

Dúas aplicacións agora son máis baratas que un cambio de par en cada versión.

Verifique a negociación, non a etiqueta

Despois de aplicar, comprobe tres feitos separados: o túnel informa de establecido, a ruta existe co seguinte salto previsto e o par informa de que a fase 1 e a fase 2 están activas.

Un túnel activo coa fase 2 caída significa que os dous lados non coinciden nos selectores:

• Un lado enumera unha subrede que o outro non enumera.
• Un lado usa un agregado que o outro estreitou.
• A ruta existe pero apunta a un túnel distinto.

Classic VPN é un só túnel cun SLA máis baixo que HA VPN, e HA VPN usa dúas interfaces, dous túneles e BGP con tipos de recursos distintos. Copiar un exemplo clásico nunha configuración HA e esperar que os campos de selector se comporten igual é un erro aparte que convén evitar. Os propios campos do túnel están documentados na referencia de google_compute_vpn_tunnel.