Terraform Client VPN-itineroj kun pli da CIDR-oj ol subretoj

Tekkomputilo konektiĝas al la Client VPN-finpunkto, kaj terraform apply ankoraŭ malsukcesas ĉe itinera resurso. La agordo kutime havas pli da celaj CIDR-oj ol asociitaj subretoj, kaj la itinera bloko elektas celon per indekso. Tio supozas, ke la du kolektoj estas paralelaj. Ili ne estas, kaj la malsukceso aperas ĉe aplika tempo anstataŭ ĉe revizio.

Nomu la objekton, kiu malsukcesas

Tri resursoj partoprenas kaj ĉiu respondas al malsama demando. La asocio metas la ret-interfacon de la finpunkto en subreton. La itinero diras, kiun celan prefikson oni liveras al cela subreto. La rajtiga regulo diras, kiuj uzantoj povas atingi kiun prefikson. Itinero indikanta subreton, kiu neniam estis asociita, malsukcesas eĉ kiam ambaŭ objektoj ekzistas, ĉar la celo devas aparteni al ĉi tiu finpunkto.

Unue listigu la asociojn: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

Memoru la lokan itineron de la VPC

La unua asocio aldonas lokan itineron por la tuta VPC, do ĉiu subreto en tiu VPC jam estas atingebla sen itinera resurso. Pliaj itineroj ekzistas por samnivelaj VPC-oj, Transit Gateway-alkroĉoj kaj surlokaj prefiksoj, kiujn la VPC ne posedas. Tial finpunkto kun tri asocioj povas laŭleĝe porti sep celajn erojn.

Kalkulu la celojn ekster la VPC antaŭ ol aldoni itinerojn. Se tiu nombro estas pli malgranda ol la CIDR-listo, la listo priskribas subretojn, kiuj tute ne bezonas itineron.

Anstataŭigu la indekson per mapo

Volvi la indekson en restan operatoron silentigas la eraron kaj konservas la modeligan eraron. Celo, kiun oni ne povas atingi per la elektita celo, daŭre portas neniun trafikon, kiel ajn pure la plano aplikiĝas. Anstataŭe konservu la rilaton, kaj lasu Terraform kontroli ĝin antaŭ ol krei ion ajn. La suba bloko estas ilustra kaj uzas la finpunktajn itinerajn argumentojn de la provizanto.

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

Kiam la mapo staras apud la asocia listo, aldoni celon devigas decidon pri tio, kiu subreto portas ĝin. Tio estas la konversacio, kiun la indekso kaŝis.

Alia malsukceso produktas sensencajn valorojn anstataŭ indeksan eraron. Transdoni malaltnivelan konstruaĵon tie, kie oni atendas pli altnivelan interfacon, lasas la kampojn, kiujn la API legas, neplenigitaj, kaj la rezulta CIDR estas neuzebla. Terraform montras la saman formon, kiam teksto alvenas tie, kie oni atendas objekton. Kontrolu la provizantan skemon por la argumenta tipo.

Pruvu ĝin de kliento

Rulu terraform validate kaj planon kontraŭ reala stato antaŭ ol apliki. Poste komparu la cellistan liston de la finpunkto kun la mapo anstataŭ fidi sukcesan apply.

La akcepta testo estas konektita kliento, kiu atingas ĉiun celitan prefikson.

La rajtiga regulo estas la loko, kie multaj agordoj frue haltas. Ĝi estas limigita al cela CIDR kaj grupo, kaj itinero sen kongrua rajtigo produktas konektitan klienton, kiu ne povas atingi la prefikson. Kontrolu ambaŭ objektojn por ĉiu prefikso, ĉar apply, kiu kreas la itineron kaj forgesas la regulon, aspektas kompleta. Testu kun unu uzanto ene de la grupo kaj unu ekster ĝi.

Kiam unu prefikso malsukcesas, komparu ĝian itineran eron kun la rajtiga regulo. Mankanta rajtigo kaj mankanta itinero aspektas similaj en la klienta protokolo kaj estas riparataj en malsamaj resursoj.