Túnel completo do Access Server no EC2: por que uma caixa de seleção não basta

Desativar a verificação de origem e destino numa instância EC2 é a resposta mais repetida às perguntas sobre a saída para a internet do Access Server, e por si só não faz nada pelos seus clientes. A verificação é uma restrição de encaminhamento da AWS: faz a instância aceitar pacotes cuja origem ou destino não é o seu próprio endereço. Não diz ao cliente do Access Server para enviar o tráfego de internet pelo túnel, não cria uma rota a montante e não adiciona NAT. O mito é que a caixa de seleção é a funcionalidade.

O que a verificação realmente controla

Cada interface de rede do EC2 descarta o tráfego que não lhe é endereçado, a menos que a instância atue como router, dispositivo NAT ou gateway VPN e você desative essa verificação. Desativá-la concede permissão para encaminhar. Permissão não é configuração: a instância continua a precisar de uma rota para um gateway de internet ou dispositivo NAT, a tabela de rotas da VPC continua a precisar da entrada correspondente, os grupos de segurança têm de permitir o fluxo, e o servidor tem de traduzir ou encaminhar o tráfego de retorno.

Verifique o valor atual com aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck antes de mudar qualquer coisa. Se o alterar na consola, altere-o porque a instância encaminha por outros, não porque um cliente não chega à internet.

A política de encaminhamento do cliente pertence ao Access Server

No Access Server 3, abra Access Controls e encontre a secção Internet Access and DNS. O seletor Internet Gateway oferece túnel completo ou túnel dividido; o túnel completo diz ao cliente para encaminhar o tráfego predefinido para dentro da VPN, o túnel dividido deixa o tráfego de internet no caminho local do cliente. Guarde e aplique através do fluxo de trabalho do produto e depois reconecte um cliente de teste, porque a política é entregue no momento da ligação.

Versões antigas usam menus diferentes e algumas compilações Community de OpenVPN não têm controlo equivalente. Verifique a versão principal instalada antes de procurar um ecrã que não existe. Depois confirme o que o cliente recebeu: um perfil de túnel completo deve instalar uma rota predefinida através do túnel, e um perfil de túnel dividido não deve fazê-lo.

Siga o pacote depois do túnel

Assim que o cliente envia tráfego de internet para o túnel, o servidor tem de o encaminhar e normalmente traduzi-lo. O Access Server gere as suas próprias regras de NAT e de encaminhamento, por isso leia a configuração efetiva em vez de acrescentar regras Community OpenVPN aos ficheiros gerados; as regras não geridas são substituídas ou entram em conflito na atualização seguinte do produto. sudo iptables -t nat -L -n -v ou o equivalente em nftables mostra o que está realmente a ser traduzido.

O lado da AWS é um caminho separado. Uma instância numa sub-rede pública chega a um gateway de internet diretamente e mantém o seu endereço público ou IP elástico. Uma instância numa sub-rede privada precisa de uma rota para um gateway NAT ou instância NAT, e o dispositivo NAT precisa da sua própria rota para o gateway de internet. Anexar um gateway de internet à VPC não dá por si só um endereço público de retorno a nenhuma origem privada, e é por isso que a mesma configuração do Access Server funciona numa sub-rede e falha em silêncio noutra.

Verifique a tabela de rotas associada à sub-rede da instância, não apenas a tabela principal da VPC. As associações de sub-rede prevalecem sobre a tabela principal, e uma associação obsoleta é uma causa comum de uma configuração que funcionava parar após uma reconstrução.

Mantenha a saída IP e o DNS separados

Teste primeiro um literal de endereço e depois um nome, a partir da mesma aplicação cliente. Se curl -4 https://checkip.amazonaws.com devolver um endereço público mas os nomes de anfitrião falharem, o túnel e o caminho NAT funcionam e o problema é o DNS: o resolver enviado, o estado do resolver do cliente ou um grupo de segurança que bloqueia o resolver. As definições de DNS do Access Server estão na mesma área Internet Access, mas percorrem um caminho de código diferente.

Compare o endereço devolvido com a saída que pretendia. Se for o endereço público da instância, o tráfego é traduzido pela instância; se for um endereço de gateway NAT, está a ser usado o caminho da sub-rede privada. Ambos podem estar corretos. O que não pode concluir é que um navegador no servidor prova o encaminhamento para o cliente.

Não deixe uma caixa fechar a investigação

IPv6 é uma decisão separada. Uma política de túnel completo para IPv4 não diz nada sobre se o IPv6 é transportado, bloqueado ou fuga, e um cliente de pilha dupla pode continuar a usar o seu caminho IPv6 local enquanto o IPv4 vai pelo túnel. Teste a família de endereços que realmente lhe importa e decida explicitamente se a outra deve ser desativada.

Por fim, teste o estado desligado. A seleção de túnel completo descreve a política de encaminhamento enquanto está ligado, não o que acontece quando o túnel cai. Se o requisito é que nenhum tráfego escape fora da VPN, isso é uma questão de kill-switch e firewall, e precisa do seu próprio teste em vez de uma dedução a partir da tabela de rotas.