Terraform Client VPN-rutter med fler CIDR än subnät

En bärbar dator ansluter till Client VPN-slutpunkten, och terraform apply misslyckas fortfarande på en ruttresurs. Konfigurationen har vanligtvis fler destinations-CIDR än associerade subnät, och ruttblocket väljer ett mål med ett index. Det förutsätter att de två samlingarna är parallella. Det är de inte, och felet visar sig vid tillämpning i stället för vid granskning.

Namnge objektet som misslyckas

Tre resurser är inblandade och var och en svarar på en annan fråga. Associationen placerar slutpunktens nätverksgränssnitt i ett subnät. Rutten anger vilket destinationsprefix som levereras till ett målsubnät. Auktoriseringsregeln anger vilka användare som kan nå vilket prefix. En rutt som pekar på ett subnät som aldrig associerades misslyckas även om båda objekten finns, eftersom målet måste tillhöra denna slutpunkt.

Lista associationerna först: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

Kom ihåg VPC:ns lokala rutt

Den första associationen lägger till en lokal rutt för hela VPC:n, så varje subnät i den VPC:n är redan nåbart utan en ruttresurs. Extra rutter finns för peer-anslutna VPC:er, Transit Gateway-kopplingar och on-premises-prefix som VPC:n inte äger. Därför kan en slutpunkt med tre associationer legitimt bära sju destinationsposter.

Räkna destinationerna utanför VPC:n innan du lägger till rutter. Om antalet är mindre än CIDR-listan beskriver listan subnät som inte behöver någon rutt alls.

Ersätt indexet med en karta

Att linda in indexet i en modulo-operator tystar felet och behåller modelleringsfelet. En destination som inte kan nås via det valda målet bär fortfarande ingen trafik, hur rent planen än tillämpas. Spara i stället relationen och låt Terraform kontrollera den innan något skapas. Blocket nedan är illustrativt och använder leverantörens slutpunktsruttargument.

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

När kartan står bredvid associationslistan tvingar tillägget av en destination fram ett beslut om vilket subnät som bär den. Det är samtalet som indexet dolde.

Ett annat fel ger meningslösa värden i stället för ett indexfel. Att skicka en konstruktion på låg nivå där ett gränssnitt på högre nivå förväntas lämnar fälten som API:t läser ofyllda, och det resulterande CIDR:et är oanvändbart. Terraform visar samma form när en sträng anländer där ett objekt förväntas. Kontrollera leverantörens schema för argumenttypen.

Bevisa det från en klient

Kör terraform validate och en plan mot verkligt tillstånd innan du tillämpar. Jämför sedan slutpunktens målnätverkslista med kartan i stället för att lita på en lyckad apply.

Acceptanstestet är en ansluten klient som når varje avsett prefix.

Auktoriseringsregeln är där många uppsättningar stannar tidigt. Den är begränsad till ett destinations-CIDR och en grupp, och en rutt utan matchande auktorisering ger en ansluten klient som inte kan nå prefixet. Kontrollera båda objekten för varje prefix, eftersom en apply som skapar rutten och glömmer regeln ser komplett ut. Testa med en användare inom gruppen och en utanför.

När ett prefix misslyckas, jämför dess ruttpost med auktoriseringsregeln. En saknad auktorisering och en saknad rutt ser liknande ut i klientloggen och åtgärdas i olika resurser.