GCP Classic VPN dans Terraform : rendez le tunnel basé sur les routes

Dans Classic VPN, l’étiquette ne décide pas du comportement. Basé sur les routes, c’est un sélecteur local 0.0.0.0/0, des sélecteurs distants concordants et une route explicite.

Le plan s’applique proprement, le tunnel monte et la console le qualifie de basé sur des règles. Le trafic ne passe toujours pas, et la recherche d’un commutateur basé sur les routes dans la ressource Terraform ne mène nulle part, car ce champ n’existe pas. Dans Classic VPN, le comportement basé sur les routes n’est pas un mode que l’on choisit. C’est ce que l’on obtient quand le sélecteur de trafic local est 0.0.0.0/0, que les sélecteurs distants listent les réseaux réellement voulus et qu’une route pointe vers le tunnel. Trois choses, et l’étiquette suit.

Le mythe : un champ de mode du tunnel

L’étiquette de la console reflète ce que l’API voit dans les sélecteurs. Rien dans la ressource ne dit basé sur les routes, il n’y a donc rien à mettre à vrai.

Chercher ce champ consomme la première heure du problème, tandis que lire les valeurs des sélecteurs prend les cinq dernières minutes.

Ce que basé sur les routes veut dire ici

Google documente les tunnels basés sur les routes de Classic VPN comme des tunnels basés sur des règles dont le sélecteur local est 0.0.0.0/0. Seules les plages distantes sont nommées, et le côté local est traité comme n’importe quelle adresse. C’est pourquoi le marqueur de votre configuration est une valeur et non un mode. Écrivez les deux sélecteurs explicitement et lisez-les dans la sortie du plan :

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

Le préfixe du pair dans cet extrait est illustratif ; la forme est ce qui compte.

La route est un objet distinct

Un objet tunnel n’installe pas de route. Les paquets peuvent correspondre à la règle du tunnel et n’avoir malgré tout nulle part où aller, car la table de routage du VPC décide du saut suivant. La route a besoin de la plage de destination, du réseau, du tunnel comme saut suivant et d’une priorité qui l’emporte sur tout ce qui est plus large. Si on l’oublie, on obtient un tunnel qui signale établi et un ping qui ne quitte jamais le 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
}

Créez la route dans le même module que le tunnel, afin que les deux ne puissent pas diverger lors de la revue.

Reproduisez les sélecteurs chez le pair

L’appareil distant doit être configuré en miroir : sa plage locale est votre sélecteur distant, et sa plage distante doit couvrir les sous-réseaux GCP que vous comptez utiliser. Si l’un des deux côtés se resserre, la phase 2 échoue même si la phase 1 réussit. C’est la forme la plus courante d’une configuration qui semble correcte dans la console et ne transporte aucun trafic.

Imprimez les sélecteurs des deux côtés côte à côte pendant la revue du changement.

Séparez l’adresse statique en deux applications

Créer l’adresse réservée et le tunnel qui la référence en une seule application est une source connue d’instabilité, car l’adresse doit exister avant que la règle de transfert puisse l’utiliser. Appliquez d’abord la ressource d’adresse seule, puis ajoutez la passerelle, les règles de transfert et le tunnel et appliquez de nouveau. Terraform lit l’adresse existante depuis l’état lors de la seconde exécution et la réutilise. Si on l’omet, le tunnel peut recevoir une nouvelle adresse publique à chaque application, ce qui casse la configuration du pair à chaque fois.

Deux applications maintenant coûtent moins cher qu’un changement de pair à chaque version.

Vérifiez la négociation, pas l’étiquette

Après l’application, vérifiez trois faits distincts : le tunnel signale établi, la route existe avec le saut suivant prévu et le pair signale que la phase 1 et la phase 2 sont actives.

Un tunnel actif avec la phase 2 en panne signifie que les deux côtés ne sont pas d’accord sur les sélecteurs :

  • Un côté liste un sous-réseau que l’autre ne liste pas.
  • Un côté utilise un agrégat que l’autre a resserré.
  • La route existe mais pointe vers un autre tunnel.

Classic VPN est un tunnel unique avec un SLA inférieur à HA VPN, et HA VPN utilise deux interfaces, deux tunnels et BGP avec des types de ressources différents. Copier un exemple classique dans une configuration HA et attendre des champs de sélecteur qu’ils se comportent de la même façon est une erreur distincte qu’il vaut la peine d’éviter. Les champs du tunnel eux-mêmes sont documentés dans la référence google_compute_vpn_tunnel.

Articles similaires