Rotas do Terraform Client VPN com mais CIDR do que sub-redes

Um portátil conecta-se ao endpoint do Client VPN, e o terraform apply continua a falhar num recurso de rota. A configuração normalmente tem mais CIDR de destino do que sub-redes associadas, e o bloco de rota escolhe um alvo com um índice. Isso pressupõe que as duas coleções são paralelas. Não são, e a falha aparece no momento da aplicação em vez de na revisão.

Nomeie o objeto que falha

Três recursos estão envolvidos e cada um responde a uma pergunta diferente. A associação coloca a interface de rede do endpoint numa sub-rede. A rota indica qual prefixo de destino é entregue a uma sub-rede de destino. A regra de autorização indica quais utilizadores podem alcançar qual prefixo. Uma rota que aponta para uma sub-rede que nunca foi associada falha mesmo que ambos os objetos existam, porque o alvo tem de pertencer a este endpoint.

Liste primeiro as associações: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

Lembre-se da rota local da VPC

A primeira associação adiciona uma rota local para toda a VPC, pelo que cada sub-rede dessa VPC já é alcançável sem um recurso de rota. Existem rotas adicionais para VPC emparelhadas, ligações Transit Gateway e prefixos on-premises que a VPC não possui. Por isso um endpoint com três associações pode legitimamente transportar sete entradas de destino.

Conte os destinos que ficam fora da VPC antes de adicionar rotas. Se essa contagem for menor do que a lista de CIDR, a lista descreve sub-redes que não precisam de rota nenhuma.

Substitua o índice por um mapa

Envolver o índice num operador de módulo silencia o erro e mantém o erro de modelação. Um destino que não pode ser alcançado pelo alvo escolhido continua a não transportar tráfego, por mais limpo que o plano seja aplicado. Guarde antes a relação, e deixe o Terraform verificá-la antes de criar alguma coisa. O bloco abaixo é ilustrativo e usa os argumentos de rota do endpoint do fornecedor.

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

Com o mapa ao lado da lista de associações, adicionar um destino obriga a decidir qual sub-rede o transporta. Essa é a conversa que o índice escondia.

Outra falha produz valores sem sentido em vez de um erro de índice. Passar uma construção de baixo nível onde se espera uma interface de nível superior deixa os campos que a API lê por preencher, e o CIDR resultante é inutilizável. O Terraform mostra a mesma forma quando chega uma cadeia onde se espera um objeto. Verifique o esquema do fornecedor para o tipo de argumento.

Prove-o a partir de um cliente

Execute terraform validate e um plano contra o estado real antes de aplicar. Depois, compare a lista de redes de destino do endpoint com o mapa em vez de confiar num apply bem-sucedido.

O teste de aceitação é um cliente ligado que alcança cada prefixo pretendido.

A regra de autorização é onde muitas configurações param cedo. Está limitada a um CIDR de destino e a um grupo, e uma rota sem a autorização correspondente produz um cliente ligado que não consegue alcançar o prefixo. Verifique ambos os objetos para cada prefixo, porque um apply que cria a rota e esquece a regra parece completo. Teste com um utilizador dentro do grupo e outro fora.

Quando um prefixo falha, compare a sua entrada de rota com a regra de autorização. Uma autorização em falta e uma rota em falta parecem semelhantes no registo do cliente e são corrigidas em recursos diferentes.