Route Terraform Client VPN con più CIDR che subnet

Associazione, rotta e autorizzazione sono oggetti separati. Mappare ogni CIDR di destinazione su una subnet associata invece di indicizzare un elenco di subnet più corto.

Un portatile si connette all'endpoint Client VPN, e terraform apply continua a fallire su una risorsa di rotta. La configurazione di solito ha più CIDR di destinazione che subnet associate, e il blocco della rotta sceglie una destinazione con un indice. Ciò presuppone che le due raccolte siano parallele. Non lo sono, e l'errore emerge al momento dell'applicazione invece che in fase di revisione.

Nominate l'oggetto che fallisce

Sono coinvolte tre risorse e ciascuna risponde a una domanda diversa. L'associazione colloca l'interfaccia di rete dell'endpoint in una subnet. La rotta indica quale prefisso di destinazione viene consegnato a una subnet di destinazione. La regola di autorizzazione indica quali utenti possono raggiungere quale prefisso. Una rotta che punta a una subnet mai associata fallisce anche se entrambi gli oggetti esistono, perché la destinazione deve appartenere a questo endpoint.

Elencate prima le associazioni: aws ec2 describe-client-vpn-target-networks --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0.

Ricordate la rotta locale della VPC

La prima associazione aggiunge una rotta locale per l'intera VPC, quindi ogni subnet di quella VPC è già raggiungibile senza una risorsa di rotta. Esistono rotte aggiuntive per VPC con peering, collegamenti Transit Gateway e prefissi on-premises che la VPC non possiede. Per questo un endpoint con tre associazioni può legittimamente portare sette voci di destinazione.

Contate le destinazioni che cadono fuori dalla VPC prima di aggiungere rotte. Se quel conteggio è inferiore all'elenco dei CIDR, l'elenco descrive subnet che non hanno affatto bisogno di una rotta.

Sostituite l'indice con una mappa

Avvolgere l'indice in un operatore modulo zittisce l'errore e conserva l'errore di modellazione. Una destinazione irraggiungibile tramite la destinazione scelta continua a non trasportare traffico, per quanto pulitamente il piano venga applicato. Memorizzate invece la relazione, e lasciate che Terraform la verifichi prima di creare qualsiasi cosa. Il blocco seguente è illustrativo e usa gli argomenti di rotta dell'endpoint del provider.

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

Con la mappa accanto all'elenco delle associazioni, aggiungere una destinazione impone di decidere quale subnet la trasporta. È la conversazione che l'indice nascondeva.

Un guasto diverso produce valori privi di senso invece di un errore di indice. Passare una costruzione di basso livello dove è attesa un'interfaccia di livello superiore lascia vuoti i campi che l'API legge, e il CIDR risultante è inutilizzabile. Terraform mostra la stessa forma quando arriva una stringa dove è atteso un oggetto. Controllate lo schema del provider per il tipo di argomento.

Dimostratelo da un client

Eseguite terraform validate e un piano sullo stato reale prima di applicare. Poi confrontate l'elenco delle reti di destinazione dell'endpoint con la mappa invece di fidarvi di un apply riuscito.

Il test di accettazione è un client connesso che raggiunge ogni prefisso previsto.

La regola di autorizzazione è il punto in cui molte configurazioni si fermano presto. È limitata a un CIDR di destinazione e a un gruppo, e una rotta senza l'autorizzazione corrispondente produce un client connesso che non può raggiungere il prefisso. Controllate entrambi gli oggetti per ogni prefisso, perché un apply che crea la rotta e dimentica la regola sembra completo. Provate con un utente dentro il gruppo e uno fuori.

Quando un prefisso fallisce, confrontate la sua voce di rotta con la regola di autorizzazione. Un'autorizzazione mancante e una rotta mancante sembrano simili nel log del client e si correggono in risorse diverse.

Articoli correlati