Rute Terraform Client VPN cu mai multe CIDR decât subrețele

Un laptop se conectează la punctul final Client VPN, iar terraform apply eșuează în continuare pe o resursă de rută. Configurația are de obicei mai multe CIDR-uri de destinație decât subrețele asociate, iar blocul de rută alege o țintă cu un index. Asta presupune că cele două colecții sunt paralele. Nu sunt, iar eșecul apare la aplicare, nu la revizuire.

Numiți obiectul care eșuează

Sunt implicate trei resurse și fiecare răspunde la o întrebare diferită. Asocierea plasează interfața de rețea a punctului final într-o subrețea. Ruta spune ce prefix de destinație este livrat unei subrețele țintă. Regula de autorizare spune ce utilizatori pot ajunge la ce prefix. O rută care indică o subrețea ce nu a fost niciodată asociată eșuează chiar dacă ambele obiecte există, pentru că ținta trebuie să aparțină acestui punct final.

Listați mai întâi asocierile: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

Amintiți-vă de ruta locală a VPC-ului

Prima asociere adaugă o rută locală pentru întregul VPC, așa că fiecare subrețea din acel VPC este deja accesibilă fără o resursă de rută. Există rute suplimentare pentru VPC-uri conectate, atașamente Transit Gateway și prefixe on-premises pe care VPC-ul nu le deține. De aceea un punct final cu trei asocieri poate transporta legitim șapte intrări de destinație.

Numărați destinațiile din afara VPC-ului înainte de a adăuga rute. Dacă acel număr este mai mic decât lista CIDR, lista descrie subrețele care nu au nevoie deloc de rută.

Înlocuiți indexul cu o hartă

Înfășurarea indexului într-un operator modulo înăbușă eroarea și păstrează greșeala de modelare. O destinație care nu poate fi atinsă prin ținta aleasă tot nu transportă trafic, oricât de curat s-ar aplica planul. Stocați în schimb relația și lăsați Terraform să o verifice înainte de a crea ceva. Blocul de mai jos este ilustrativ și folosește argumentele de rută ale punctului final de la furnizor.

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

Când harta stă lângă lista de asocieri, adăugarea unei destinații impune o decizie despre ce subrețea o transportă. Aceasta este conversația pe care indexul o ascundea.

O altă defecțiune produce valori fără sens în loc de o eroare de index. Trecerea unei construcții de nivel jos acolo unde se așteaptă o interfață de nivel înalt lasă câmpurile citite de API necompletate, iar CIDR-ul rezultat este inutilizabil. Terraform arată aceeași formă când un șir ajunge acolo unde se așteaptă un obiect. Verificați schema furnizorului pentru tipul argumentului.

Dovediți-o dintr-un client

Rulați terraform validate și un plan împotriva stării reale înainte de aplicare. Apoi comparați lista de rețele țintă a punctului final cu harta în loc să vă bazați pe un apply reușit.

Testul de acceptare este un client conectat care ajunge la fiecare prefix dorit.

Regula de autorizare este locul unde multe configurații se opresc devreme. Este limitată la un CIDR de destinație și la un grup, iar o rută fără autorizarea corespunzătoare produce un client conectat care nu poate ajunge la prefix. Verificați ambele obiecte pentru fiecare prefix, pentru că un apply care creează ruta și uită regula pare complet. Testați cu un utilizator în grup și unul în afara lui.

Când un prefix eșuează, comparați intrarea sa de rută cu regula de autorizare. O autorizare lipsă și o rută lipsă arată similar în jurnalul clientului și se corectează în resurse diferite.