NAT simétrico e VPN: meça o mapeamento, não o rótulo

Uma thread de suporte termina com o veredicto «NAT simétrico, a VPN não vai funcionar aqui», e depois o cliente é reinstalado três vezes sem motivo. O rótulo faz estragos porque responde a uma pergunta que ninguém fez. Um cliente que se liga para fora a um servidor fixo cria um mapeamento no momento em que envia o primeiro pacote, e a resposta é autorizada a voltar segundo regras que quase todas as redes implementam. O que o mapeamento dependente da extremidade realmente complica é dois pares a tentar chegar um ao outro ao mesmo tempo, e isso é outro teste.

Duas perguntas escondem-se atrás de um rótulo

A primeira pergunta é se um host atrás desta rede consegue abrir uma sessão para um endereço público e uma porta conhecidos. Para um cliente de túnel esse é o caso normal, e a resposta é quase sempre sim. O router registra a origem interna, atribui uma porta externa e deixa passar a resposta porque pertence a uma sessão que começou por dentro.

A segunda pergunta é se dois hosts atrás de redes diferentes conseguem descobrir um caminho comum e enviar um ao outro sem um servidor no meio. Isso depende de como cada rede atribui essas portas externas, e é o único lugar onde o comportamento do mapeamento importa.

Confundir as duas produz o diagnóstico errado clássico: uma funcionalidade entre pares falha, alguém corre um teste de tipo de NAT, vê a pior categoria e conclui que o túnel comum também não pode funcionar. O túnel nunca foi o que falhou.

Mapeamento e filtragem são propriedades separadas

A terminologia do RFC é mais precisa do que os nomes usados pelos fabricantes, e vale a pena levá-la para o ticket porque resolve discussões. O mapeamento é como a porta externa é atribuída. A filtragem é que pacotes de entrada são deixados passar. Uma rede pode ser rígida numa e liberal na outra, e é essa combinação que um protocolo entre pares tem de sobreviver.

A terceira linha é o que a maioria dos routers domésticos e operadores móveis entende por simétrico. Note que o rótulo descreve apenas a atribuição. Uma rede com esse mapeamento e filtragem liberal ainda pode aceitar pacotes de entrada na porta que acabou de atribuir, e é por isso que a perfuração de buracos funciona em algumas e falha noutras.

A filtragem tem os seus três casos e o seu nome para cada um. Escrever «NAT simétrico» num ticket quando se quer dizer «filtragem dependente de endereço e porta» manda a pessoa seguinte para o capítulo errado do manual. As duas comportam-se de forma diferente em teste, portanto o erro não é académico.

Meça o mapeamento em vez de lhe dar nome

Pode observar a porta atribuída diretamente do lado do servidor de qualquer serviço UDP que controle. Inicie uma captura no host público, envie a partir do cliente e leia a porta de origem com que o pacote chegou:

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

A linha da extremidade é a mais útil das três, porque o WireGuard registra o último endereço e a última porta que recebeu de cada par. Compare essa porta com a que o cliente pensa estar a usar. Serão diferentes sempre que ocorra qualquer tradução, e a pergunta importante é se o valor se mantém estável.

Repita a observação contra uma segunda porta de destino ou um segundo servidor e compare outra vez. Se a porta externa muda por destino, o mapeamento depende do endereço e da porta. Se ficar igual, a rede dá-lhe um único mapeamento e a descoberta tem uma oportunidade.

As ferramentas baseadas em STUN relatam a mesma classificação num só passo, e podem usar-se quando a rede permite UDP de saída para um servidor STUN público. Quando não permite, o método de captura acima continua a funcionar e não exige nada além de um host que já controla.

Escolha uma correção que corresponda à falha

Se a funcionalidade que falha for entre pares, as respostas suportadas são um relay, um serviço de encontro que ambos os pares alcancem, ou uma topologia diferente. O TURN existe exatamente para isto, e um produto que inclui o seu próprio relay está a dizer-lhe que espera que algumas redes sejam hostis.

Se a funcionalidade que falha for um túnel comum, o comportamento do mapeamento não é o seu problema e nada do acima se aplica. Verifique que o cliente envia mesmo, que o servidor vê o pacote e que a resposta regressa. Essa sequência são três observações e não exige saber nada sobre a categoria NAT do router.

O que não funciona é espalhar alterações de porta local até algo se ligar. Mudar a porta de origem do cliente não muda a forma como a rede atribui mapeamentos. Um sucesso casual à quinta tentativa é um falso positivo, e será citado como correção durante meses.

Registe a arquitetura, não o veredicto

Uma nota útil diz qual protocolo, em que direção começa a sessão, se há um relay no caminho e o que foi observado no cabo. «NAT simétrico, não funciona» é inutilizável, porque é ao mesmo tempo errado sobre o túnel e omisso sobre o caminho entre pares.

Inclua a estabilidade da porta medida e o comportamento da filtragem se os testou. Esses dois factos permitem a outra pessoa prever se uma nova funcionalidade vai funcionar naquela rede sem repetir toda a investigação. Também envelhecem melhor do que uma categoria de fabricante que significa algo ligeiramente diferente em cada página de ajuda.

Por fim, tenha à mão a terminologia do RFC 4787 quando o escrever. Usar os termos precisos custa uma frase e evita que o leitor seguinte repita o mesmo diagnóstico errado, e é todo o sentido de escrever a nota.