Un portátil conéctase ao punto de conexión de Client VPN, e terraform apply segue fallando nun recurso de ruta. A configuración adoita ter máis CIDR de destino que subredes asociadas, e o bloque de ruta elixe un destino cun índice. Iso supón que as dúas coleccións son paralelas. Non o son, e o fallo aparece ao aplicar en lugar de ao revisar.

Nomee o obxecto que falla

Interveñen tres recursos e cada un responde a unha pregunta distinta. A asociación coloca a interface de rede do punto de conexión nunha subrede. A ruta indica que prefixo de destino se entrega a unha subrede de destino. A regra de autorización indica que usuarios poden alcanzar que prefixo. Unha ruta que apunta a unha subrede que nunca se asociou falla aínda que ambos os obxectos existan, porque o destino debe pertencer a este punto de conexión.

Enumere primeiro as asociacións: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

Lembre a ruta local da VPC

A primeira asociación engade unha ruta local para toda a VPC, así que cada subrede desa VPC xa é accesible sen un recurso de ruta. Existen rutas adicionais para VPC emparelladas, conexións de Transit Gateway e prefixos on-premises que a VPC non posúe. Por iso un punto de conexión con tres asociacións pode levar lexitimamente sete entradas de destino.

Conte os destinos que quedan fóra da VPC antes de engadir rutas. Se esa conta é menor que a lista de CIDR, a lista describe subredes que non necesitan ningunha ruta.

Substitúa o índice por un mapa

Envolver o índice nun operador de módulo cala o erro e conserva o erro de modelado. Un destino ao que non se pode chegar polo destino elixido segue sen transportar tráfico, por limpo que se aplique o plan. Garde a relación no seu lugar e deixe que Terraform a comprobe antes de crear nada. O bloque seguinte é ilustrativo e usa os argumentos de ruta do punto de conexión do provedor.

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

Co mapa xunto á lista de asociacións, engadir un destino obriga a decidir que subrede o transporta. Esa é a conversación que o índice ocultaba.

Outro fallo produce valores sen sentido en lugar dun erro de índice. Pasar unha construción de baixo nivel onde se espera unha interface de nivel superior deixa baleiros os campos que le a API, e o CIDR resultante é inservible. Terraform mostra a mesma forma cando chega unha cadea onde se espera un obxecto. Comprobe o esquema do provedor para o tipo de argumento.

Demóstrao desde un cliente

Execute terraform validate e un plan contra o estado real antes de aplicar. Despois, compare a lista de redes de destino do punto de conexión co mapa en lugar de confiar nun apply correcto.

A proba de aceptación é un cliente conectado que alcanza cada prefixo previsto.

A regra de autorización é onde moitas configuracións se deteñen cedo. Está limitada a un CIDR de destino e un grupo, e unha ruta sen a autorización correspondente produce un cliente conectado que non pode alcanzar o prefixo. Comprobe ambos os obxectos para cada prefixo, porque un apply que crea a ruta e esquece a regra parece completo. Probe cun usuario dentro do grupo e outro fóra.

Cando falla un prefixo, compare a súa entrada de ruta coa regra de autorización. Unha autorización ausente e unha ruta ausente parecen similares no rexistro do cliente e corríxense en recursos distintos.

Artigos relacionados