Terraform Client VPN-Routen mit mehr CIDRs als Subnetzen

Zuordnung, Route und Autorisierung sind getrennte Objekte. Ordnen Sie jedes Ziel-CIDR einem zugeordneten Subnetz zu, statt eine kürzere Subnetzliste zu indizieren.

Ein Laptop verbindet sich mit dem Client VPN-Endpunkt, und terraform apply schlägt weiterhin an einer Routenressource fehl. Die Konfiguration enthält meist mehr Ziel-CIDRs als zugeordnete Subnetze, und der Routenblock wählt ein Ziel über einen Index. Das setzt voraus, dass die beiden Sammlungen parallel sind. Sind sie nicht, und der Fehler zeigt sich beim Anwenden statt bei der Prüfung.

Benennen Sie das Objekt, das fehlschlägt

Drei Ressourcen sind beteiligt, und jede beantwortet eine andere Frage. Die Zuordnung platziert die Netzwerkschnittstelle des Endpunkts in einem Subnetz. Die Route legt fest, welches Zielpräfix an ein Zielsubnetz geliefert wird. Die Autorisierungsregel legt fest, welche Benutzer welches Präfix erreichen dürfen. Eine Route, die auf ein Subnetz zeigt, das nie zugeordnet wurde, schlägt fehl, obwohl beide Objekte existieren, weil das Ziel zu diesem Endpunkt gehören muss.

Listen Sie zuerst die Zuordnungen auf: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

Denken Sie an die lokale VPC-Route

Die erste Zuordnung fügt eine lokale Route für die gesamte VPC hinzu, sodass jedes Subnetz in dieser VPC bereits ohne Routenressource erreichbar ist. Zusätzliche Routen gibt es für gepeerte VPCs, Transit Gateway-Anbindungen und On-Premises-Präfixe, die der VPC nicht gehören. Deshalb kann ein Endpunkt mit drei Zuordnungen legitim sieben Zieleinträge tragen.

Zählen Sie die Ziele außerhalb der VPC, bevor Sie Routen hinzufügen. Ist diese Anzahl kleiner als die CIDR-Liste, beschreibt die Liste Subnetze, die überhaupt keine Route benötigen.

Ersetzen Sie den Index durch eine Map

Das Einwickeln des Index in einen Modulo-Operator erstickt den Fehler und bewahrt den Modellierungsfehler. Ein Ziel, das über das gewählte Zielsubnetz nicht erreichbar ist, trägt weiterhin keinen Verkehr, egal wie sauber der Plan angewandt wird. Speichern Sie stattdessen die Beziehung, und lassen Sie Terraform sie prüfen, bevor irgendetwas erstellt wird. Der folgende Block ist illustrativ und verwendet die Endpunkt-Routenargumente des Providers.

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

Steht die Map neben der Zuordnungsliste, erzwingt das Hinzufügen eines Ziels eine Entscheidung darüber, welches Subnetz es trägt. Das ist das Gespräch, das der Index verborgen hat.

Ein anderer Fehler erzeugt Unsinnswerte statt eines Indexfehlers. Wird ein Konstrukt niedriger Ebene dort übergeben, wo eine Schnittstelle höherer Ebene erwartet wird, bleiben die vom API gelesenen Felder unausgefüllt, und das resultierende CIDR ist unbrauchbar. Terraform zeigt dieselbe Form, wenn eine Zeichenkette eintrifft, wo ein Objekt erwartet wird. Prüfen Sie das Providerschema auf den Argumenttyp.

Beweisen Sie es von einem Client aus

Führen Sie terraform validate und einen Plan gegen den echten Zustand aus, bevor Sie anwenden. Vergleichen Sie danach die Zielnetzwerkliste des Endpunkts mit der Map, statt einem erfolgreichen apply zu vertrauen.

Der Abnahmetest ist ein verbundener Client, der jedes vorgesehene Präfix erreicht.

Die Autorisierungsregel ist die Stelle, an der viele Setups früh aufhören. Sie ist auf ein Ziel-CIDR und eine Gruppe beschränkt, und eine Route ohne passende Autorisierung erzeugt einen verbundenen Client, der das Präfix nicht erreicht. Prüfen Sie beide Objekte für jedes Präfix, denn ein apply, das die Route erstellt und die Regel vergisst, wirkt vollständig. Testen Sie mit einem Benutzer innerhalb der Gruppe und einem außerhalb.

Wenn ein Präfix fehlschlägt, vergleichen Sie seinen Routeneintrag mit der Autorisierungsregel. Eine fehlende Autorisierung und eine fehlende Route sehen im Client-Log ähnlich aus und werden in verschiedenen Ressourcen behoben.

Ähnliche Artikel