Por que AWS Client VPN descarta o tráfico sen unha ruta coincidente

O punto final só reenvía un paquete cando a súa táboa de rutas cobre o destino. Le as rutas, declara os prefixos con for_each, verifica o camiño de volta.

Client VPN entrega un enderezo ao cliente, o handshake complétase e a conexión segue sen ir a ningures. Antes de tocar certificados ou versións do cliente, mira a propia táboa de rutas do punto final. Un punto final de AWS Client VPN só reenvía un paquete cando unha das súas rutas cobre o prefixo de destino; se nada coincide, o paquete descártase no punto final e o host de destino nunca ve un SYN.

Esa é unha decisión de reenvío, non de autenticación. Ocorre despois de que o túnel estea levantado e de que se avalíen as regras de autorización, por iso un certificado válido e un grupo válido aínda poden producir unha conexión morta.

O punto final só reenvía o que cobre a súa táboa de rutas

Cada ruta é un CIDR de destino máis a subrede que debe recibir o tráfico. O punto final compara o destino do cliente con esa lista, escolle a entrada coincidente e envía o paquete á subrede asociada. Sen entrada non hai seguinte salto.

Fíxate no que a ruta non é. Non é unha entrada da táboa de rutas da VPC e non autoriza nada. As regras de autorización deciden se un grupo pode alcanzar un destino; as rutas deciden se o punto final ten onde enviar o paquete. Ambas deben coincidir, e fallan con síntomas distintos, así que adiviñar cal está rota desgasta unha tarde.

O desaxuste clásico é unha VPC con peering. Alguén engade unha ruta para 10.20.0.0/24 mentres o host vive en 10.20.4.0/24, así que o enderezo queda fóra de todas as entradas. Unha captura no lado do cliente mostra SYN repetidos sen resposta, e os rexistros do destino non mostran absolutamente nada.

Le a lista de rutas antes do certificado

As rutas do punto final son un obxecto propio, así que consúltalas directamente en lugar de ler a táboa da VPC:

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

Toma o enderezo exacto e a lonxitude de prefixo do cliente que falla, e despois comproba a cobertura carácter por carácter. Aplícase a coincidencia do prefixo máis longo, así que unha ruta máis ampla non te salva cando unha máis estreita apunta a outro sitio.

Un recurso por destino con for_each

Os bloques de rutas escritos a man desvíanse no momento en que alguén engade un prefixo na consola. Mantén os destinos nun mapa e crea un recurso por clave, para que cada adición ou eliminación quede illada.

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 a dependencia da asociación de rede. Unha ruta necesita unha subrede asociada, así que un apply que cree as dúas cousas debe ordenar primeiro a asociación, e sen esa referencia Terraform é libre de tentar a ruta primeiro. Despois le o plan: o número de adicións de rutas debe coincidir cos prefixos que engadiches. Se o plan tamén substitúe o punto final, o recurso do punto final está mal escrito, e aplicalo desconecta todos os clientes conectados.

Adoptar un punto final que non creaches

A maioría dos equipos herdan un punto final construído na consola, e por iso non existe código de rutas. Non levantes un segundo punto final só para meter rutas en Terraform.

Importa no seu lugar, ou pasa os ids como variables e deixa os obxectos herdados sen xestionar. A importación necesita o formato de identificador que o provedor documenta para cada tipo de recurso, que codifica o punto final, o prefixo de destino e a subrede obxectivo. Copia esa cadea da documentación do recurso en lugar de compoñela de memoria, executa un plan e espera que non haxa cambios antes de engadir algo novo.

Segue o paquete na orde en que viaxa

Cando a ruta existe e a conexión segue fallando, percorre o camiño en orde en lugar de adiviñar na capa superior.

  1. Ruta: un prefixo cobre o destino e apunta a unha subrede asociada ao punto final.
  2. Autorización: unha regra de autorización permite ese destino para o grupo do usuario. Unha ruta soa nunca concede acceso.
  3. Camiño de volta: a táboa de rutas da subrede de destino envía as respostas de volta cara ao punto final, e o grupo de seguridade permite o porto desde o pool de enderezos do cliente.
  4. Aplicación: abre unha conexión TCP real desde o cliente, e despois confirma que os rexistros do destino mostran o enderezo de orixe esperado do pool.

Cambia un prefixo por apply, volve ler a lista de rutas despois e anota xuntos o destino, a regra que autoriza e o camiño de volta. A próxima persoa que depure unha conexión rexeitada debería comezar por ese inventario, non por unha teoría sobre certificados.

Artigos relacionados