Terraform Client VPN-ruter med flere CIDR'er end undernet

En bærbar computer opretter forbindelse til Client VPN-endpointet, og terraform apply fejler stadig på en ruteressource. Konfigurationen har normalt flere destinations-CIDR'er end tilknyttede undernet, og ruteblokken vælger et mål med et indeks. Det antager, at de to samlinger er parallelle. Det er de ikke, og fejlen viser sig ved apply-tidspunktet i stedet for ved gennemgang.

Navngiv objektet, der fejler

Tre ressourcer er involveret, og hver besvarer et forskelligt spørgsmål. Tilknytningen placerer endpointets netværksgrænseflade i et undernet. Ruten angiver, hvilket destinationspræfiks der leveres til et målundernet. Autorisationsreglen angiver, hvilke brugere der kan nå hvilket præfiks. En rute, der peger på et undernet, som aldrig blev tilknyttet, fejler, selv om begge objekter findes, fordi målet skal tilhøre dette endpoint.

List tilknytningerne først: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

Husk VPC'ens lokale rute

Den første tilknytning tilføjer en lokal rute for hele VPC'en, så hvert undernet i den VPC er allerede tilgængeligt uden en ruteressource. Ekstra ruter findes til peered VPC'er, Transit Gateway-tilkoblinger og on-premises-præfikser, som VPC'en ikke ejer. Derfor kan et endpoint med tre tilknytninger legitimt bære syv destinationsposter.

Tæl destinationerne uden for VPC'en, før du tilføjer ruter. Hvis det antal er mindre end CIDR-listen, beskriver listen undernet, der slet ikke har brug for en rute.

Erstat indekset med et map

At pakke indekset ind i en modulo-operator dæmper fejlen og bevarer modelleringsfejlen. En destination, der ikke kan nås gennem det valgte mål, bærer stadig ingen trafik, uanset hvor rent planen anvendes. Gem i stedet relationen, og lad Terraform kontrollere den, før noget oprettes. Blokken nedenfor er illustrativ og bruger udbyderens endpoint-ruteargumenter.

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 mappet står ved siden af tilknytningslisten, tvinger tilføjelsen af en destination en beslutning om, hvilket undernet der bærer den. Det er den samtale, indekset skjulte.

En anden fejl giver nonsensværdier i stedet for en indeksfejl. At sende en lavniveau-konstruktion, hvor der forventes en grænseflade på højere niveau, efterlader felterne, som API'en læser, uudfyldte, og det resulterende CIDR er ubrugeligt. Terraform viser samme form, når en streng ankommer, hvor der forventes et objekt. Kontroller udbyderens skema for argumenttypen.

Bevis det fra en klient

Kør terraform validate og en plan mod rigtig tilstand, før du anvender. Sammenlign derefter endpointets målnetværksliste med mappet i stedet for at stole på et vellykket apply.

Accepttesten er en tilsluttet klient, der når hvert tilsigtet præfiks.

Autorisationsreglen er der, hvor mange opsætninger stopper tidligt. Den er afgrænset til et destinations-CIDR og en gruppe, og en rute uden en matchende autorisation giver en tilsluttet klient, der ikke kan nå præfikset. Kontroller begge objekter for hvert præfiks, fordi et apply, der opretter ruten og glemmer reglen, ser færdigt ud. Test med én bruger i gruppen og én uden for den.

Når et præfiks fejler, sammenlign da dets rutepost med autorisationsreglen. En manglende autorisation og en manglende rute ser ens ud i klientloggen og rettes i forskellige ressourcer.