GCP Classic VPN in Terraform: rendi il tunnel basato sulle route

In Classic VPN l'etichetta non decide il comportamento. Basato sulle route significa selettore locale 0.0.0.0/0, selettori remoti corrispondenti e una route esplicita.

Il piano si applica senza errori, il tunnel sale e la console lo definisce basato su policy. Il traffico continua a non passare, e la ricerca di un interruttore basato sulle route nella risorsa Terraform non porta da nessuna parte perché quel campo non esiste. In Classic VPN, il comportamento basato sulle route non è una modalità che si sceglie. È ciò che si ottiene quando il selettore di traffico locale è 0.0.0.0/0, i selettori remoti elencano le reti che si vogliono davvero e una route punta al tunnel. Tre cose, e l'etichetta segue.

Il mito: un campo di modalità del tunnel

L'etichetta della console riflette ciò che l'API vede nei selettori. Nulla nella risorsa dice basato sulle route, quindi non c'è niente da impostare su vero.

Cercare quel campo consuma la prima ora del problema, mentre leggere i valori dei selettori occupa gli ultimi cinque minuti.

Che cosa significa qui basato sulle route

Google documenta i tunnel basati sulle route di Classic VPN come tunnel basati su policy il cui selettore locale è 0.0.0.0/0. Solo gli intervalli remoti vengono nominati, e il lato locale è trattato come qualsiasi indirizzo. Per questo l'indicatore nella configurazione è un valore e non una modalità. Scrivete entrambi i selettori in modo esplicito e leggeteli nell'output del piano:

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

Il prefisso del peer in quel frammento è illustrativo; la forma è la parte che conta.

La route è un oggetto separato

Un oggetto tunnel non installa una route. I pacchetti possono corrispondere alla policy del tunnel e comunque non avere dove andare, perché la tabella di routing della VPC decide il next hop. La route richiede l'intervallo di destinazione, la rete, il tunnel come next hop e una priorità che vince su qualsiasi cosa più ampia. Se lo si dimentica, si ottiene un tunnel che riporta stabilito e un ping che non lascia mai 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
}

Create la route nello stesso modulo del tunnel, così i due non possono divergere durante la revisione.

Rispecchiate i selettori sul peer

Il dispositivo remoto va configurato con l'immagine speculare: il suo intervallo locale è il vostro selettore remoto, e il suo intervallo remoto deve coprire le sottoreti GCP che intendete usare. Se uno dei due lati si restringe, la fase 2 fallisce anche se la fase 1 riesce. È la forma più comune di una configurazione che sembra corretta nella console e non trasporta traffico.

Stampate i selettori dei due lati affiancati durante la revisione della modifica.

Dividete l'indirizzo statico in due applicazioni

Creare l'indirizzo riservato e il tunnel che lo referenzia in un'unica applicazione è una fonte nota di instabilità, perché l'indirizzo deve esistere prima che la regola di inoltro possa usarlo. Applicate prima solo la risorsa dell'indirizzo, poi aggiungete il gateway, le regole di inoltro e il tunnel e applicate di nuovo. Terraform legge l'indirizzo esistente dallo stato alla seconda esecuzione e lo riutilizza. Se lo si salta, il tunnel può ricevere un nuovo indirizzo pubblico a ogni applicazione, il che rompe la configurazione del peer ogni volta.

Due applicazioni ora costano meno di un cambio di peer a ogni rilascio.

Verificate la negoziazione, non l'etichetta

Dopo l'applicazione, controllate tre fatti separati: il tunnel riporta stabilito, la route esiste con il next hop previsto e il peer riporta che la fase 1 e la fase 2 sono attive.

Un tunnel attivo con la fase 2 abbassata significa che i due lati non concordano sui selettori:

  • Un lato elenca una sottorete che l'altro non elenca.
  • Un lato usa un aggregato che l'altro ha ristretto.
  • La route esiste ma punta a un altro tunnel.

Classic VPN è un singolo tunnel con uno SLA inferiore a HA VPN, e HA VPN usa due interfacce, due tunnel e BGP con tipi di risorsa diversi. Copiare un esempio classico in una configurazione HA e aspettarsi che i campi dei selettori si comportino allo stesso modo è un errore separato che vale la pena evitare. I campi del tunnel stessi sono documentati nella referenza di google_compute_vpn_tunnel.

Articoli correlati