GCP Classic VPN a Terraform: feu que el túnel sigui basat en rutes

A Classic VPN l’etiqueta no decideix el comportament. Basat en rutes és un selector local 0.0.0.0/0, selectors remots coincidents i una ruta explícita.

El pla s’aplica net, el túnel s’aixeca i la consola el qualifica de basat en polítiques. El trànsit encara no passa, i la cerca d’un commutador basat en rutes al recurs de Terraform no porta enlloc perquè aquest camp no existeix. A Classic VPN, el comportament basat en rutes no és un mode que trieu. És el que obteniu quan el selector de trànsit local és 0.0.0.0/0, els selectors remots llisten les xarxes que realment voleu i una ruta apunta al túnel. Tres coses, i l’etiqueta segueix.

El mite: un camp de mode del túnel

L’etiqueta de la consola reflecteix el que l’API veu als selectors. Res del recurs diu basat en rutes, així que no hi ha res a posar a cert.

Buscar aquest camp consumeix la primera hora del problema, mentre que llegir els valors dels selectors ocupa els últims cinc minuts.

Què vol dir basat en rutes aquí

Google documenta els túnels basats en rutes de Classic VPN com a túnels basats en polítiques el selector local dels quals és 0.0.0.0/0. Només s’anomenen els rangs remots, i el costat local es tracta com qualsevol adreça. Per això el marcador de la vostra configuració és un valor i no un mode. Escriviu tots dos selectors explícitament i llegiu-los a la sortida del pla:

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

El prefix del parell en aquest fragment és il·lustratiu; la forma és la part que importa.

La ruta és un objecte a part

Un objecte túnel no instal·la cap ruta. Els paquets poden coincidir amb la política del túnel i tot i així no tenir on anar, perquè la taula d’encaminament de la VPC decideix el salt següent. La ruta necessita el rang de destinació, la xarxa, el túnel com a salt següent i una prioritat que guanyi contra qualsevol cosa més àmplia. Si ho oblideu, obteniu un túnel que informa d’establert i un ping que mai no surt de la 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
}

Creeu la ruta al mateix mòdul que el túnel, perquè els dos no es puguin separar durant la revisió.

Reflectiu els selectors al parell

El dispositiu remot s’ha de configurar amb la imatge mirall: el seu rang local és el vostre selector remot, i el seu rang remot ha de cobrir les subxarxes de GCP que espereu utilitzar. Si qualsevol dels dos costats s’estreny, la fase 2 falla encara que la fase 1 funcioni. Aquesta és la forma més habitual d’una configuració que sembla correcta a la consola i no transporta cap trànsit.

Imprimiu els selectors dels dos costats l’un al costat de l’altre durant la revisió del canvi.

Dividiu l’adreça estàtica en dues aplicacions

Crear l’adreça reservada i el túnel que hi fa referència en una sola aplicació és una font coneguda d’inestabilitat, perquè l’adreça ha d’existir abans que la regla d’enviament la pugui utilitzar. Apliqueu primer només el recurs de l’adreça, després afegiu la passarel·la, les regles d’enviament i el túnel i torneu a aplicar. Terraform llegeix l’adreça existent de l’estat a la segona execució i la reutilitza. Si us ho salteu, el túnel pot rebre una adreça pública nova a cada aplicació, cosa que trenca la configuració del parell cada vegada.

Dues aplicacions ara surten més barates que un canvi de parell a cada versió.

Verifiqueu la negociació, no l’etiqueta

Després d’aplicar, comproveu tres fets separats: el túnel informa d’establert, la ruta existeix amb el salt següent previst i el parell informa que la fase 1 i la fase 2 estan actives.

Un túnel actiu amb la fase 2 caiguda vol dir que els dos costats no es posen d’acord sobre els selectors:

  • Un costat llista una subxarxa que l’altre no llista.
  • Un costat fa servir un agregat que l’altre ha estret.
  • La ruta existeix però apunta a un túnel diferent.

Classic VPN és un sol túnel amb un SLA més baix que HA VPN, i HA VPN fa servir dues interfícies, dos túnels i BGP amb tipus de recursos diferents. Copiar un exemple clàssic en una configuració HA i esperar que els camps de selector es comportin igual és un error a part que val la pena evitar. Els camps del túnel mateixos es documenten a la referència de google_compute_vpn_tunnel.

Articles relacionats