Rutas de Terraform Client VPN con más CIDR que subredes

Un portátil se conecta al punto de enlace de Client VPN, y terraform apply sigue fallando en un recurso de ruta. La configuración suele tener más CIDR de destino que subredes asociadas, y el bloque de ruta elige un destino con un índice. Eso supone que las dos colecciones son paralelas. No lo son, y el fallo aparece al aplicar en lugar de al revisar.

Nombre el objeto que falla

Intervienen tres recursos y cada uno responde a una pregunta distinta. La asociación coloca la interfaz de red del punto de enlace en una subred. La ruta indica qué prefijo de destino se entrega a una subred de destino. La regla de autorización indica qué usuarios pueden alcanzar qué prefijo. Una ruta que apunta a una subred que nunca se asoció falla aunque ambos objetos existan, porque el destino debe pertenecer a este punto de enlace.

Enumere primero las asociaciones: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

Recuerde la ruta local de la VPC

La primera asociación añade una ruta local para toda la VPC, así que cada subred de esa VPC ya es accesible sin un recurso de ruta. Existen rutas adicionales para VPC emparejadas, conexiones de Transit Gateway y prefijos on-premises que la VPC no posee. Por eso un punto de enlace con tres asociaciones puede llevar legítimamente siete entradas de destino.

Cuente los destinos que quedan fuera de la VPC antes de añadir rutas. Si esa cuenta es menor que la lista de CIDR, la lista describe subredes que no necesitan ninguna ruta.

Sustituya el índice por un mapa

Envolver el índice en un operador de módulo silencia el error y conserva el error de modelado. Un destino al que no se puede llegar por el destino elegido sigue sin transportar tráfico, por limpio que se aplique el plan. Guarde la relación en su lugar y deje que Terraform la compruebe antes de crear nada. El bloque siguiente es ilustrativo y usa los argumentos de ruta del punto de enlace del proveedor.

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."
    }
  }
}

Con el mapa junto a la lista de asociaciones, añadir un destino obliga a decidir qué subred lo transporta. Esa es la conversación que el índice ocultaba.

Otro fallo produce valores sin sentido en lugar de un error de índice. Pasar una construcción de bajo nivel donde se espera una interfaz de nivel superior deja vacíos los campos que lee la API, y el CIDR resultante es inservible. Terraform muestra la misma forma cuando llega una cadena donde se espera un objeto. Compruebe el esquema del proveedor para el tipo de argumento.

Demuéstrelo desde un cliente

Ejecute terraform validate y un plan contra el estado real antes de aplicar. Después, compare la lista de redes de destino del punto de enlace con el mapa en lugar de confiar en un apply correcto.

La prueba de aceptación es un cliente conectado que alcanza cada prefijo previsto.

La regla de autorización es donde muchas configuraciones se detienen pronto. Está limitada a un CIDR de destino y un grupo, y una ruta sin la autorización correspondiente produce un cliente conectado que no puede alcanzar el prefijo. Compruebe ambos objetos para cada prefijo, porque un apply que crea la ruta y olvida la regla parece completo. Pruebe con un usuario dentro del grupo y otro fuera.

Cuando falla un prefijo, compare su entrada de ruta con la regla de autorización. Una autorización ausente y una ruta ausente se parecen en el registro del cliente y se corrigen en recursos distintos.