AWS Client VPN conectado pero sen acceso a internet: comprobación de rutas

AWS Client VPN conectado sen acceso a internet? Comprobe as rutas do cliente, a autorización do endpoint, a saída da subrede e o DNS nesa orde.

Está conectado ao endpoint de AWS Client VPN, a subrede privada responde e, aínda así, cada páxina pública esgota o tempo de espera. Esa combinación reduce o problema a un de tres obxectos do lado xestionado: a ruta que instala o cliente, a ruta do endpoint xunto coa súa regra de autorización, ou o seguinte salto da subrede asociada. Compróboas nesa orde porque cada fallo vese distinto desde o cliente. Esta guía cobre o endpoint xestionado asociado á VPC, non un servidor OpenVPN nunha instancia EC2 nin unha conexión de Cloud WAN ou Transit Gateway.

Comece polo que o cliente encamiña realmente

Un estado conectado demostra a sesión TLS e a asignación de CIDR ao cliente, nada máis. Pregunte ao sistema operativo cara a onde iría un enderezo público mentres o túnel está activo. En Linux, ip route get 1.1.1.1 debería nomear a interface do túnel; en macOS, netstat -rn -f inet | head -5 mostra a entrada predeterminada; en Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 imprime a interface escollida e o seguinte salto.

Despois lea o indicador de túnel dividido, porque decide se as rutas publicadas do endpoint son os únicos destinos que o cliente envía ao túnel:

aws ec2 describe-client-vpn-endpoints \
  --client-vpn-endpoint-ids cvpn-endpoint-0123456789abcdef0 \
  --query 'ClientVpnEndpoints[0].SplitTunnel'

Con SplitTunnel en true, un destino público usa o túnel só cando o endpoint publica unha ruta que o cobre, así que unha 0.0.0.0/0 ausente deixa ese tráfico na interface local. Co valor en false, o cliente captura o tráfico, pero o endpoint aínda debe encaminalo e autorizalo; se non, os paquetes entran no túnel e detéñense alí. Volva conectar o cliente tras cambiar calquera dos dous axustes, porque as rutas e os servidores DNS entréganse no momento da conexión e un cliente en marcha pode conservar o conxunto anterior.

Lea a ruta do endpoint e a regra de autorización por separado

Son dous obxectos, e crear un non crea o outro. Enumere as rutas do endpoint e busque unha predeterminada cuxo destino sexa unha subrede asociada:

aws ec2 describe-client-vpn-routes \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Cada ruta ten exactamente unha subrede de destino, así que tres asociacións necesitan unha ruta predeterminada correspondente cada unha. AWS documenta este requisito de cobertura, e o síntoma práctico dun oco é un usuario que traballa desde unha subrede e se atasca desde outra, o que se le como un fallo intermitente en lugar dunha ruta ausente. A documentación oficial do escenario de Client VPN describe a disposición de subrede pública á que pertencen estas rutas.

A autorización é o segundo obxecto. Cando ningunha regra cobre o destino público, o túnel transporta o paquete e o servizo descártao, así que os recursos privados seguen funcionando mentres internet non o fai:

aws ec2 describe-client-vpn-authorization-rules \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0

Unha regra para o CIDR da VPC non di nada sobre 0.0.0.0/0. Engadir as pezas que faltan para un túnel completo significa unha ruta por subrede asociada máis unha regra de autorización que poida auditar despois:

aws ec2 create-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 create-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all \
  --description "internet egress for full tunnel"

--access-all concede o destino a todos os clientes do endpoint, así que mantéñao só mentres o túnel deba ser completo; unha regra ligada a un grupo de directorio é preferible cando ten grupos aos que ligala.

Siga o paquete fóra da subrede asociada

A ruta do endpoint decide que AWS entrega o paquete a esa subrede. Non decide o seguinte salto máis alá, que vive na táboa de rutas VPC propia da subrede:

aws ec2 describe-route-tables \
  --filters Name=association.subnet-id,Values=subnet-0a1b2c3d4e5f67890 \
  --query 'RouteTables[].Routes[?DestinationCidrBlock==`0.0.0.0/0`]'

Unha ruta predeterminada utilizábel apunta a unha internet gateway para unha subrede pública, ou a unha NAT gateway para unha privada, e un estado blackhole significa que o destino se eliminou e o camiño agora morre en silencio. Son táboas distintas da lista de rutas do endpoint, e reparar unha non repara a outra.

Neste salto hai dous filtros. O grupo de seguridade aplicado á asociación de rede de destino debe permitir o tráfico de saída cara ao destino público, e calquera ACL de rede aplicábel debe permitir a solicitude e o tráfico de retorno en portos efémeros. Un grupo de seguridade de asociación restritivo é unha causa habitual de que o acceso privado funcione e o público non.

Escolla a primeira capa a partir do síntoma en lugar de cambiar as tres á vez:

What you observeLayer to check first
No tunnel interface for a public IPClient route or split-tunnel flag
Tunnel interface chosen, request times outEndpoint route and authorization rule
Endpoint route present, still times outSubnet route table, association security group
Named host fails, numeric address worksDNS servers and their own authorization

Separe o fallo de DNS dunha ruta morta

A resolución de nomes falla de xeito distinto ao reenvío, e o túnel completo fai que a diferenza importe porque agora se chega ao resolutor empurrado a través do túnel. Se o endpoint especifica servidores DNS da VPC, os seus enderezos necesitan cobertura de ruta e autorización como calquera outro destino. Consulte o resolutor directamente para ver que fallo ten: dig +short example.com @10.0.0.2, ou nslookup example.com 10.0.0.2 en Windows.

Cando un URL numérico responde e un con nome non, deixe de editar a ruta predeterminada e traballe no DNS. Unha solicitude a un enderezo IP non demostra nada sobre un host virtual con nome e o seu certificado, así que manteña unha proba con nome na comprobación final.

O tempo axuda. Unha conexión TCP que non recibe resposta en poucos segundos apunta ao encamiñamento ou a un filtro, mentres que unha solicitude que se colga dentro da busca de nome apunta ao resolutor. Cambiar a ruta predeterminada mentres o resolutor é inalcanzábel adoita converter un fallo en dous.

Desfaga con limpeza e logo verifique o camiño de saída

Ambos os obxectos eran aditivos, así que desfacer é borrar e non reparar:

aws ec2 delete-client-vpn-route \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --target-vpc-subnet-id subnet-0a1b2c3d4e5f67890
aws ec2 delete-client-vpn-authorization-rule \
  --client-vpn-endpoint-id cvpn-endpoint-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --access-all

Volva conectar e confirme por que camiño sae o tráfico. Compare o enderezo público observado co enderezo IP elástico da NAT gateway, ou coa internet gateway que pretendía usar, e comprobe que un recurso privado segue respondendo na mesma sesión.

Termine cunha lista curta e trate o último elemento como parte do cambio e non como documentación:

  • Unha 0.0.0.0/0 ruta de endpoint para cada subrede asociada.
  • Unha regra de autorización que cubra 0.0.0.0/0 para os clientes aos que quere servir.
  • Unha ruta predeterminada de VPC que non estea en estado blackhole en cada subrede asociada.
  • Saída do grupo de seguridade da asociación, máis o tráfico de retorno da ACL.
  • Enderezos do resolutor encamiñados e autorizados, verificados cunha solicitude con nome.
  • Unha reversión rexistrada para a ruta e a regra.

Unha nota de alcance: este é un camiño IPv4. Un cliente de dobre pila conserva a conectividade IPv6 que xa teña, así que unha ruta predeterminada IPv6 é unha decisión aparte coa súa propia autorización e non un efecto secundario desta.

Artigos relacionados