Per què AWS Client VPN descarta el trànsit sense cap ruta coincident

El punt final només reenvia un paquet quan la seva taula de rutes cobreix la destinació. Llegeix les rutes, declara els prefixos amb for_each, verifica el camí de tornada.

Client VPN lliura una adreça al client, l'handshake es completa i la connexió segueix sense anar enlloc. Abans de tocar certificats o versions del client, mira la taula de rutes del propi punt final. Un punt final d'AWS Client VPN només reenvia un paquet quan una de les seves rutes cobreix el prefix de destinació; si no hi ha cap coincidència, el paquet es descarta al punt final i l'amfitrió de destinació no veu mai un SYN.

Aquesta és una decisió d'encaminament, no d'autenticació. Passa després que el túnel estigui aixecat i després que s'avaluïn les regles d'autorització, i per això un certificat vàlid i un grup vàlid encara poden produir una connexió morta.

El punt final només reenvia allò que cobreix la seva taula de rutes

Cada ruta és un CIDR de destinació més la subxarxa que ha de rebre el trànsit. El punt final comprova la destinació del client contra aquesta llista, tria l'entrada coincident i envia el paquet a la subxarxa associada. Cap entrada vol dir cap salt següent.

Fixa't en què no és una ruta. No és una entrada de la taula de rutes de la VPC i no autoritza res. Les regles d'autorització decideixen si un grup pot arribar a una destinació; les rutes decideixen si el punt final té on enviar el paquet. Totes dues han de coincidir, i fallen amb símptomes diferents, així que endevinar quina està trencada malbarata una tarda.

La desajustada clàssica és una VPC amb peering. Algú afegeix una ruta per a 10.20.0.0/24 mentre l'amfitrió viu a 10.20.4.0/24, de manera que l'adreça cau fora de totes les entrades. Una captura al costat del client mostra SYN repetits sense resposta, i els registres de la destinació no mostren absolutament res.

Llegeix la llista de rutes abans del certificat

Les rutes del punt final són un objecte a part, així que consulta-les directament en lloc de llegir la taula de la VPC:

aws ec2 describe-client-vpn-routes --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 --query 'Routes[].{Dest:DestinationCidr,Target:TargetSubnet,Origin:Origin}'

Agafa l'adreça exacta i la longitud de prefix del client que falla, i després comprova la cobertura caràcter a caràcter. S'aplica la coincidència de prefix més llarg, així que una ruta més àmplia no et salva quan una de més estreta apunta a un altre lloc.

Un recurs per destinació amb for_each

Els blocs de rutes escrits a mà es desvien en el moment que algú afegeix un prefix a la consola. Mantén les destinacions en un mapa i crea un recurs per clau, perquè cada addició o eliminació quedi aïllada.

variable "client_vpn_routes" {
  type = map(string)
  default = {
    "10.20.0.0/16"  = "subnet-0aa11bb22cc33dd44"
    "172.31.0.0/20" = "subnet-0aa11bb22cc33dd44"
  }
}

resource "aws_ec2_client_vpn_route" "this" {
  for_each               = var.client_vpn_routes
  client_vpn_endpoint_id = var.client_vpn_endpoint_id
  destination_cidr_block = each.key
  target_vpc_subnet_id   = each.value
  depends_on             = [aws_ec2_client_vpn_network_association.this]
}

Conserva la dependència de l'associació de xarxa. Una ruta necessita una subxarxa associada, així que un apply que creï les dues coses ha d'ordenar primer l'associació, i sense aquesta referència Terraform és lliure d'intentar la ruta primer. Després llegeix el pla: el nombre d'addicions de ruta ha de coincidir amb els prefixos que has afegit. Si el pla també reemplaça el punt final, el recurs del punt final està mal escrit, i aplicar-lo desconnecta tots els clients connectats.

Adoptar un punt final que no has creat

La majoria d'equips hereten un punt final construït a la consola, i per això no existeix cap codi de rutes. No aixequis un segon punt final només per portar rutes a Terraform.

Importa'l, o passa els ids com a variables i deixa els objectes heretats sense gestionar. La importació necessita el format d'identificador que el proveïdor documenta per a cada tipus de recurs, que codifica el punt final, el prefix de destinació i la subxarxa objectiu. Copia aquesta cadena de la documentació del recurs en lloc de compondre-la de memòria, executa un pla i espera que no hi hagi canvis abans d'afegir res nou.

Segueix el paquet en l'ordre en què viatja

Quan la ruta existeix i la connexió encara falla, recorre el camí en ordre en lloc d'endevinar a la capa superior.

  1. Ruta: un prefix cobreix la destinació i apunta a una subxarxa associada al punt final.
  2. Autorització: una regla d'autorització permet aquesta destinació per al grup de l'usuari. Una ruta sola no concedeix mai accés.
  3. Camí de tornada: la taula de rutes de la subxarxa objectiu envia les respostes cap al punt final, i el grup de seguretat permet el port des del pool d'adreces del client.
  4. Aplicació: obre una connexió TCP real des del client, i després confirma que els registres de la destinació mostren l'adreça d'origen esperada del pool.

Canvia un prefix per apply, torna a llegir la llista de rutes després i anota la destinació, la regla que autoritza i el camí de tornada alhora. La propera persona que depuri una connexió rebutjada hauria de començar per aquest inventari, no per una teoria sobre certificats.

Articles relacionats