Routes Terraform Client VPN avec plus de CIDR que de sous-réseaux

L’association, la route et l’autorisation sont des objets distincts. Associez chaque CIDR de destination à un sous-réseau associé au lieu d’indexer une liste de sous-réseaux plus courte.

Un ordinateur portable se connecte au point de terminaison Client VPN, et terraform apply échoue toujours sur une ressource de route. La configuration comporte généralement plus de CIDR de destination que de sous-réseaux associés, et le bloc de route choisit une cible avec un index. Cela suppose que les deux collections sont parallèles. Elles ne le sont pas, et l’échec apparaît au moment de l’application plutôt qu’à la relecture.

Nommez l’objet qui échoue

Trois ressources sont en jeu et chacune répond à une question différente. L’association place l’interface réseau du point de terminaison dans un sous-réseau. La route indique quel préfixe de destination est livré à un sous-réseau cible. La règle d’autorisation indique quels utilisateurs peuvent atteindre quel préfixe. Une route pointant vers un sous-réseau qui n’a jamais été associé échoue même si les deux objets existent, car la cible doit appartenir à ce point de terminaison.

Listez d’abord les associations : aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

Rappelez-vous la route locale du VPC

La première association ajoute une route locale pour tout le VPC, donc chaque sous-réseau de ce VPC est déjà joignable sans ressource de route. Des routes supplémentaires existent pour les VPC appairés, les attachements Transit Gateway et les préfixes on-premises que le VPC ne possède pas. C’est pourquoi un point de terminaison avec trois associations peut légitimement porter sept entrées de destination.

Comptez les destinations situées hors du VPC avant d’ajouter des routes. Si ce nombre est inférieur à la liste de CIDR, la liste décrit des sous-réseaux qui n’ont besoin d’aucune route.

Remplacez l’index par une carte

Enfermer l’index dans un opérateur modulo fait taire l’erreur et conserve l’erreur de modélisation. Une destination inaccessible via la cible choisie ne transporte toujours aucun trafic, aussi proprement que le plan s’applique. Stockez plutôt la relation, et laissez Terraform la vérifier avant de créer quoi que ce soit. Le bloc ci-dessous est illustratif et utilise les arguments de route du point de terminaison du fournisseur.

variable "client_vpn_destinations" {
  description = "Destination CIDR mapped to an associated subnet key"
  type        = map(string)
}

resource "aws_ec2_client_vpn_route" "this" {
  for_each               = var.client_vpn_destinations
  client_vpn_endpoint_id = aws_ec2_client_vpn_endpoint.this.id
  destination_cidr_block = each.key
  target_vpc_subnet_id   = aws_subnet.private[each.value].id

  lifecycle {
    precondition {
      condition     = contains(keys(aws_subnet.private), each.value)
      error_message = "Route target must be a subnet key in the associated map."
    }
  }
}

Avec la carte à côté de la liste d’associations, ajouter une destination impose de décider quel sous-réseau la porte. C’est la conversation que l’index masquait.

Une autre défaillance produit des valeurs absurdes au lieu d’une erreur d’index. Passer une construction de bas niveau là où une interface de plus haut niveau est attendue laisse vides les champs que l’API lit, et le CIDR résultant est inutilisable. Terraform montre la même forme lorsqu’une chaîne arrive là où un objet est attendu. Vérifiez le schéma du fournisseur pour le type d’argument.

Prouvez-le depuis un client

Exécutez terraform validate et un plan sur l’état réel avant d’appliquer. Ensuite, comparez la liste des réseaux cibles du point de terminaison à la carte au lieu de vous fier à un apply réussi.

Le test d’acceptation est un client connecté qui atteint chaque préfixe prévu.

La règle d’autorisation est l’endroit où beaucoup de configurations s’arrêtent tôt. Elle est limitée à un CIDR de destination et à un groupe, et une route sans autorisation correspondante produit un client connecté qui ne peut pas atteindre le préfixe. Vérifiez les deux objets pour chaque préfixe, car un apply qui crée la route et oublie la règle semble complet. Testez avec un utilisateur dans le groupe et un autre en dehors.

Quand un préfixe échoue, comparez son entrée de route à la règle d’autorisation. Une autorisation manquante et une route manquante se ressemblent dans le journal du client et se corrigent dans des ressources différentes.

Articles similaires