AWS Client VPN conectado mas sem acesso à internet: verificação de rotas

AWS Client VPN conectado sem acesso à internet? Verifique as rotas do cliente, a autorização do endpoint, a saída da sub-rede e o DNS nessa ordem.

Você está conectado ao endpoint do AWS Client VPN, a sub-rede privada responde e, mesmo assim, toda página pública termina em tempo esgotado. Essa combinação reduz o problema a um de três objetos do lado gerenciado: a rota que o cliente instala, a rota do endpoint junto com a regra de autorização, ou o próximo salto da sub-rede associada. Verifico-os nessa ordem porque cada falha parece diferente do lado do cliente. Este guia cobre o endpoint gerenciado associado à VPC, não um servidor OpenVPN numa instância EC2 nem uma conexão do Cloud WAN ou Transit Gateway.

Comece pelo que o cliente realmente roteia

Um estado conectado prova a sessão TLS e a atribuição de CIDR ao cliente, nada além disso. Pergunte ao sistema operacional para onde iria um endereço público enquanto o túnel está ativo. No Linux, ip route get 1.1.1.1 deve nomear a interface do túnel; no macOS, netstat -rn -f inet | head -5 mostra a entrada padrão; no Windows, Find-NetRoute -RemoteIPAddress 1.1.1.1 imprime a interface escolhida e o próximo salto.

Depois leia o sinalizador de túnel dividido, porque ele decide se as rotas publicadas pelo endpoint são os únicos destinos que o cliente envia ao túnel:

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

Com SplitTunnel em true, um destino público usa o túnel somente quando o endpoint publica uma rota que o cobre, então uma 0.0.0.0/0 ausente deixa esse tráfego na interface local. Com o valor em false, o cliente captura o tráfego, mas o endpoint ainda precisa roteá-lo e autorizá-lo; caso contrário, os pacotes entram no túnel e param ali. Reconecte o cliente após alterar qualquer um dos dois ajustes, porque rotas e servidores DNS são entregues no momento da conexão e um cliente em execução pode manter o conjunto antigo.

Leia a rota do endpoint e a regra de autorização separadamente

São dois objetos, e criar um não cria o outro. Liste as rotas do endpoint e procure uma rota padrão cujo destino seja uma sub-rede associada:

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

Cada rota tem exatamente uma sub-rede de destino, então três associações precisam de uma rota padrão correspondente para cada. A AWS documenta esse requisito de cobertura, e o sintoma prático de uma lacuna é um usuário que trabalha de uma sub-rede e se atola de outra, o que se lê como falha intermitente em vez de rota ausente. A documentação oficial do cenário do Client VPN descreve a disposição de sub-rede pública à qual essas rotas pertencem.

A autorização é o segundo objeto. Quando nenhuma regra cobre o destino público, o túnel transporta o pacote e o serviço o descarta, então os recursos privados continuam funcionando enquanto a internet não:

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

Uma regra para o CIDR da VPC não diz nada sobre 0.0.0.0/0. Adicionar as peças que faltam para um túnel completo significa uma rota por sub-rede associada mais uma regra de autorização que você possa auditar depois:

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, então mantenha-a apenas enquanto o túnel deve ser completo; uma regra vinculada a um grupo de diretório é preferível quando há grupos para vincular.

Siga o pacote para fora da sub-rede associada

A rota do endpoint decide que a AWS entrega o pacote a essa sub-rede. Ela não decide o próximo salto além, que fica na tabela de rotas VPC da própria sub-rede:

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

Uma rota padrão utilizável aponta para um internet gateway numa sub-rede pública, ou para um NAT gateway numa privada, e um estado blackhole significa que o destino foi excluído e o caminho agora morre em silêncio. São tabelas diferentes da lista de rotas do endpoint, e reparar uma não repara a outra.

Há dois filtros neste salto. O grupo de segurança aplicado à associação de rede de destino precisa permitir o tráfego de saída para o destino público, e qualquer ACL de rede aplicável precisa permitir a solicitação e o tráfego de retorno em portas efêmeras. Um grupo de segurança de associação restritivo é uma causa comum de o acesso privado funcionar e o público não.

Escolha a primeira camada a partir do sintoma em vez de mudar as três de uma 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 a falha de DNS de uma rota morta

A resolução de nomes falha de forma diferente do encaminhamento, e o túnel completo torna a diferença importante porque agora se chega ao resolver forçado através do túnel. Se o endpoint especifica servidores DNS da VPC, os endereços deles precisam de cobertura de rota e autorização como qualquer outro destino. Consulte o resolver diretamente para ver qual falha você tem: dig +short example.com @10.0.0.2, ou nslookup example.com 10.0.0.2 no Windows.

Quando um URL numérico responde e um com nome não, pare de editar a rota padrão e trabalhe no DNS. Uma solicitação a um endereço IP não prova nada sobre um host virtual nomeado e o certificado dele, então mantenha um teste com nome na verificação final.

O tempo ajuda. Uma conexão TCP que não recebe resposta em poucos segundos aponta para roteamento ou um filtro, enquanto uma solicitação que trava dentro da busca de nome aponta para o resolver. Mudar a rota padrão enquanto o resolver está inalcançável costuma transformar uma falha em duas.

Reverta com limpeza e depois verifique o caminho de saída

Os dois objetos eram aditivos, então reverter é excluir e não 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

Reconecte e confirme por qual caminho o tráfego sai. Compare o endereço público observado com o endereço IP elástico do NAT gateway, ou com o internet gateway que você pretendia usar, e verifique se um recurso privado ainda responde na mesma sessão.

Termine com uma lista curta e trate o último item como parte da mudança e não como documentação:

  • Uma 0.0.0.0/0 rota de endpoint para cada sub-rede associada.
  • Uma regra de autorização que cubra 0.0.0.0/0 para os clientes que você quer atender.
  • Uma rota padrão de VPC que não esteja em estado blackhole em cada sub-rede associada.
  • Saída do grupo de segurança da associação, mais o tráfego de retorno da ACL.
  • Endereços do resolver roteados e autorizados, verificados com uma solicitação com nome.
  • Uma reversão registrada para a rota e a regra.

Uma nota de escopo: este é um caminho IPv4. Um cliente de pilha dupla mantém a conectividade IPv6 que já tem, então uma rota padrão IPv6 é uma decisão separada com a própria autorização e não um efeito colateral desta.

Artigos relacionados