Trasy Terraform Client VPN z większą liczbą CIDR niż podsieci

Laptop łączy się z punktem końcowym Client VPN, a terraform apply nadal kończy się niepowodzeniem na zasobie trasy. Konfiguracja zwykle ma więcej docelowych CIDR niż powiązanych podsieci, a blok trasy wybiera cel za pomocą indeksu. Zakłada to, że obie kolekcje są równoległe. Nie są, a błąd ujawnia się podczas stosowania, a nie podczas przeglądu.

Nazwij obiekt, który zawodzi

Uczestniczą trzy zasoby i każdy odpowiada na inne pytanie. Powiązanie umieszcza interfejs sieciowy punktu końcowego w podsieci. Trasa mówi, który prefiks docelowy jest dostarczany do podsieci docelowej. Reguła autoryzacji mówi, którzy użytkownicy mogą osiągnąć który prefiks. Trasa wskazująca podsieć, która nigdy nie została powiązana, zawodzi nawet gdy oba obiekty istnieją, ponieważ cel musi należeć do tego punktu końcowego.

Najpierw wylistuj powiązania: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

Pamiętaj o lokalnej trasie VPC

Pierwsze powiązanie dodaje lokalną trasę dla całego VPC, więc każda podsieć w tym VPC jest już osiągalna bez zasobu trasy. Dodatkowe trasy istnieją dla VPC połączonych peeringiem, połączeń Transit Gateway i prefiksów on-premises, których VPC nie posiada. Dlatego punkt końcowy z trzema powiązaniami może legalnie nieść siedem wpisów docelowych.

Policz cele znajdujące się poza VPC przed dodaniem tras. Jeśli ta liczba jest mniejsza niż lista CIDR, lista opisuje podsieci, które w ogóle nie potrzebują trasy.

Zastąp indeks mapą

Owinięcie indeksu w operator modulo wycisza błąd i zachowuje błąd modelowania. Cel, do którego nie można dotrzeć przez wybrany cel, nadal nie przenosi ruchu, niezależnie od tego, jak czysto plan zostanie zastosowany. Zamiast tego zapisz relację i pozwól Terraformowi ją sprawdzić, zanim cokolwiek zostanie utworzone. Poniższy blok jest ilustracyjny i używa argumentów trasy punktu końcowego dostawcy.

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

Gdy mapa stoi obok listy powiązań, dodanie celu wymusza decyzję, która podsieć go przenosi. To rozmowa, którą indeks ukrywał.

Inna awaria daje bezsensowne wartości zamiast błędu indeksu. Przekazanie konstrukcji niskiego poziomu tam, gdzie oczekiwany jest interfejs wyższego poziomu, pozostawia pola czytane przez API niewypełnione, a wynikowy CIDR jest bezużyteczny. Terraform pokazuje ten sam kształt, gdy ciąg trafia tam, gdzie oczekiwany jest obiekt. Sprawdź schemat dostawcy pod kątem typu argumentu.

Udowodnij to z klienta

Uruchom terraform validate i plan wobec rzeczywistego stanu przed zastosowaniem. Następnie porównaj listę sieci docelowych punktu końcowego z mapą, zamiast ufać udanemu apply.

Test akceptacyjny to połączony klient osiągający każdy zamierzony prefiks.

Reguła autoryzacji to miejsce, w którym wiele konfiguracji zatrzymuje się wcześnie. Jest ograniczona do docelowego CIDR i grupy, a trasa bez pasującej autoryzacji daje połączonego klienta, który nie może osiągnąć prefiksu. Sprawdź oba obiekty dla każdego prefiksu, ponieważ apply, który tworzy trasę i zapomina reguły, wygląda na kompletny. Przetestuj z jednym użytkownikiem w grupie i jednym poza nią.

Gdy jeden prefiks zawodzi, porównaj jego wpis trasy z regułą autoryzacji. Brakująca autoryzacja i brakująca trasa wyglądają podobnie w logu klienta i są naprawiane w różnych zasobach.