Por que um servidor VPN atrás de CGNAT nunca aceita conexões

Um endereço 100.64, um nome DNS dinâmico que resolve noutro lugar e nenhum aperto de mão de entrada são um só problema: NAT da operadora. Confirme e depois encaminhe o tráfego de saída.

O router relata um endereço WAN que começa por 100.72, o nome DNS dinâmico resolve para outro endereço público e o servidor VPN nesse router nunca conclui um aperto de mão a partir de fora. O encaminhamento de portas está configurado, o serviço está a correr e um teste a partir da LAN continua a funcionar. Nada no registo do router parece um erro. Essa combinação é NAT de nível de operadora, e nenhuma regra de firewall consegue abrir uma porta num endereço que a ISP detém.

Confirmar o endereço partilhado leva dois minutos e evita uma semana de alterações de configuração.

Os sinais que apontam para o NAT da operadora

Compare o endereço WAN na página de estado do router com o endereço que uma consulta externa relata. Um endereço WAN dentro de 100.64.0.0/10 é o sinal habitual, e os intervalos privados 10/8, 172.16/12 e 192.168/16 significam o mesmo. Se o traceroute mostrar o mesmo salto público repetido, ou um salto inicial responder com um endereço privado, há outro tradutor entre o router e a internet. Algumas ISP listam o endereço atribuído apenas no portal de clientes, por isso exporte esse valor juntamente com o traceroute.

Mudar de protocolo ou de porta não ajuda, porque o problema é a alcançabilidade de entrada e não uma porta fechada.

Por que o encaminhamento e o DNS dinâmico não o conseguem corrigir

Uma regra de encaminhamento de porta mapeia uma porta na interface WAN do router, mas o tráfego de entrada nunca chega a essa interface: a ISP traduz primeiro e só encaminha o que a sua própria tabela permite. Publicar o endereço partilhado no DNS dinâmico aponta os clientes para um gateway da ISP usado por muitos assinantes, e é por isso que o nome resolve e o aperto de mão continua a falhar. Os testes de hairpin funcionam porque o router responde à sua própria regra por dentro, e o UPnP tem exatamente o mesmo ponto cego.

Reconfigurar o cliente também não ajudará, porque a falha ocorre antes de qualquer definição do cliente ser lida.

Encaminhar através de um VPS com rotas explícitas

Coloque um endereço público à frente alugando o VPS mais pequeno capaz de transportar o tráfego, e depois faça o router de casa ligar-se para lá. O UDP de saída da rede doméstica atravessa o NAT da operadora, por isso o túnel estabelece-se por dentro e o VPS torna-se o ponto final alcançável. O lado doméstico passa a ser um cliente com um endereço de túnel fixo, não um servidor.

No VPS, acrescente uma entrada de diretório específica do cliente para que o servidor saiba qual par possui a sub-rede doméstica, e acrescente uma rota de kernel correspondente.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

A linha iroute diz ao OpenVPN qual cliente recebe o tráfego da sub-rede doméstica; a linha route coloca essa sub-rede na tabela do kernel do VPS para que os pacotes entrem no túnel. Para um serviço publicado, acrescente uma regra NAT de destino que encaminhe a porta pública para 10.8.0.10 e ative net.ipv4.ip_forward.

Teste o caminho a partir de fora

Verifique cada salto do lado público, porque um túnel bem-sucedido não prova que o serviço é alcançável. O estado de escuta e a captura de pacotes no VPS separam «nada chegou» de «chegou e foi descartado».

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

Se a captura mostrar pacotes do telemóvel mas nenhuma resposta, a configuração do servidor ou a firewall são a próxima paragem. Se a captura não mostrar nada, o cliente ainda está a resolver ou a enviar para o endereço errado.

Alternativas que vale a pena orçamentar primeiro

Um endereço IPv4 dedicado da ISP é a solução mais curta e costuma ser uma pequena mensalidade. O IPv6 nativo elimina a tradução nas duas pontas quando a VPN, a rede do cliente e os registos DNS o suportam. Uma sobreposição mesh com um router de sub-rede dentro da rede doméstica consegue o mesmo encaminhamento sem VPS, ao custo de depender de um serviço de coordenação.

Escolha o encaminhamento quando o requisito é acesso de entrada estável e cada regra deve ficar sob o seu controlo. Escolha o endereço da ISP quando o orçamento o permitir e o objetivo for simplesmente deixar de pensar nisso.

Artigos relacionados