NAT duplo e sua VPN: o cliente funciona, o servidor não

Seu roteador fica atrás de outro roteador, o endereço WAN é privado, e o cliente VPN se conecta mesmo assim. Essa combinação surpreende quem espera que o NAT duplo quebre os túneis, mas são justamente as conexões de saída que a tradução trata melhor. Hospedar um servidor VPN atrás das mesmas duas camadas é o caso que costuma falhar. Desenhe a direção da conexão antes de mudar qualquer coisa.

Desenhe primeiro a direção da conexão

Abra a página de status do roteador interno e anote o endereço WAN dele, depois compare com o endereço que um serviço público informa para você. Se os dois forem diferentes, há pelo menos um tradutor entre o seu roteador e a internet. Se o endereço WAN estiver dentro de 100.64.0.0/10, o tradutor externo provavelmente é do seu provedor, e você não o controla. Esses dois fatos decidem qual dos passos seguintes pode funcionar.

curl -s https://ifconfig.me
ip -brief address
traceroute -n 1.1.1.1

NAT duplo não é VPN dupla. A tradução reescreve endereços e portas; ela não acrescenta um segundo túnel criptografado e não criptografa nada. Manter as duas ideias separadas importa porque as soluções são completamente diferentes, e uma delas exige uma conversa com o provedor em vez de uma página de configurações.

Saída: o cliente pergunta, os tradutores mapeiam

Um túnel de saída começa com um pacote da sua máquina, então cada tradutor pode criar um mapeamento e deixar a resposta entrar de volta. O protocolo, a porta e os temporizadores de inatividade decidem se esse mapeamento sobrevive o suficiente para ser útil. A maioria dos roteadores domésticos resolve isso sem nenhuma configuração.

As falhas que realmente aparecem costumam envolver tempos limite e suporte a protocolos, não o número de roteadores. Um túnel que cai após alguns minutos de silêncio é um mapeamento expirando, e um keepalive é a resposta padrão. O IPsec tem extensões NAT-traversal padrão, então afirmar que ele não consegue atravessar uma tradução é simplesmente errado. Se o túnel não se estabelece de forma alguma, olhe o endpoint e as credenciais antes de culpar a topologia.

wg show
ping -c3 10.8.0.1

Pare se o túnel de saída funciona a partir de uma rede e não de outra. Essa comparação é sobre as redes, não sobre o número de roteadores.

Entrada: o encaminhamento cobre apenas o equipamento que você possui

Hospedar um servidor é a direção inversa: uma nova conexão chega da internet e precisa alcançar a sua máquina atravessando cada camada. Uma regra de encaminhamento de porta no roteador interno só ajuda se o tradutor externo também entregar esse tráfego a você. Repetir a regra local não dá controle sobre o equipamento do provedor.

nc -vz 203.0.113.10 51820
ss -lunp 'sport = :51820'

Compare o endereço WAN do roteador interno com o endereço público que você observou e anote de onde veio cada valor. Se o endereço WAN for privado ou estiver na faixa compartilhada, a camada externa faz uma tradução que você não pode configurar. Pergunte ao provedor qual acessibilidade de entrada ele suporta antes de passar uma noite inteira com regras que não podem entrar em vigor. Remover um roteador ou desativar um firewall de forma ampla não é diagnóstico, e é uma troca ruim por uma única porta aberta.

Pare se a camada externa for do provedor e não encaminhar. Então as respostas suportadas são outro método de acesso ou um relé, não mais uma regra do seu lado.

Teste uma variável por vez

Mude uma coisa por teste e anote o resultado, porque um caminho com NAT duplo tem mais variáveis do que um com um único roteador. Mantenha o perfil e o dispositivo fixos e depois compare outra rede de acesso. Observe se a negociação falha, se a sessão cai após inatividade ou se apenas os destinos privados falham. Essas três observações apontam para três camadas diferentes.

journalctl -u wg-quick@wg0 -n 30 --no-pager
ip route get 10.20.30.40

Sub-redes privadas sobrepostas são uma armadilha à parte que nenhuma quantidade de tradução corrige. Se a sua rede doméstica e a rede remota usam a mesma faixa, surge um conflito de rotas independentemente de quantos tradutores estejam no meio. Renumerar um lado é a única resposta duradoura.

O gateway remoto merece a mesma atenção, porque suas regras de encaminhamento e rotas de retorno podem ser a peça que falta. Um túnel que se autentica ainda pode não ter nenhum caminho de aplicação utilizável, e essa falha parece idêntica do lado do cliente. O percurso termina quando você consegue dizer qual direção falha e qual camada é responsável.