O NAT decide qual endereço de origem o seu servidor VPN realmente vê

Você imagina o servidor VPN a ler o endereço do seu portátil do pacote e a escrevê-lo num registo. O que ele lê é o que o último salto NAT colocou no cabeçalho externo, e num telemóvel usado como hotspot é frequentemente um endereço partilhado com centenas de outros assinantes. O endereço da sua própria máquina 192.168.x.x nunca atravessa a internet nesse cabeçalho, e o endereço do túnel é atribuído pelo servidor depois de a ligação já estar estabelecida. Por isso, quando o registo do servidor e ip addr no portátil não coincidem, nenhum dos dois está errado; descrevem camadas diferentes de uma mesma sessão.

Três endereços, e apenas um está no registo

A confusão vem de reduzir três endereços a um. Cada um tem um proprietário diferente, vive num cabeçalho diferente e chega ao servidor por um caminho diferente.

Só a linha do meio é desconhecida no momento da ligação. O servidor escreve-a na sua tabela de pares, no ficheiro de estado ou no registo de fluxos conforme o daemon: o WireGuard chama-lhe ponto final, um ficheiro de estado do OpenVPN rotula-a como Real Address e o strongSwan reporta-a como anfitrião remoto do IKE_SA. Esse valor é renovado sempre que chega um pacote de outra origem, pelo que muda sem que ninguém reinicie nada.

A linha de baixo é o que as pessoas leem erradamente como uma alegação de identidade. Marca uma posição na configuração do servidor, não uma pessoa, porque o servidor escolheu-a do seu próprio conjunto. Dois utilizadores podem receber o mesmo endereço de túnel em dias diferentes, e um pode ter dois deles a partir de dois dispositivos.

Porque o tuplo registado muda enquanto o túnel continua ativo

A tradução de endereços é uma tabela com temporizador, não uma ligação permanente. Um router doméstico mantém o mapeamento UDP durante algum tempo após o último pacote, um gateway de operadora recicla portas segundo o seu próprio calendário, e um telemóvel que passa de Wi-Fi para LTE regressa com uma origem completamente diferente. Os valores predefinidos do conntrack no Linux são uma referência útil aqui: nf_conntrack_udp_timeout é de 30 segundos e a variante de streaming é de 120, pelo que um túnel silencioso pode perder o mapeamento muito antes de o utilizador notar.

O túnel sobrevive porque o protocolo autentica o par, não o endereço. O WireGuard fica sem estado após o handshake, por isso qualquer pacote autenticado atualiza o ponto final guardado e a religação corrige-se no pacote seguinte; é por isso que existe persistent-keepalive = 25, para manter o mapeamento quente durante a inatividade. O --float do OpenVPN faz o mesmo e permite que um cliente autenticado continue a partir de um novo endereço e porta. Nas compilações 2.4 e 2.5 em que o float está desativado por predefinição, uma religação reinicia a sessão e o cliente volta a ligar-se.

O IPsec chega lá com mais peças móveis. O IKEv2 deteta a tradução comparando os hashes de origem e destino nas cargas de deteção de NAT, passa para encapsulamento UDP 4500 e segue os keepalives até ao novo tuplo. Quando os keepalives são bloqueados, a SA mantém-se ativa no papel enquanto o tráfego num sentido para em silêncio.

O que o servidor pode atribuir, e o que não pode

O mito que vale a pena matar é que a tradução o esconde do operador. Muda o rótulo, não a observação. Um gateway atrás do NAT da operadora vê o espaço 100.64.0.0/10 ou um endereço público partilhado por muitos assinantes, e ainda assim consegue ligar o fluxo a um sujeito de certificado, uma chave pública do WireGuard, um endereço de túnel atribuído, contadores de bytes e uma janela temporal. Nada disso precisa do seu endereço LAN.

Os limites também funcionam no sentido inverso. Um endereço partilhado num registo aponta para um gateway, não para um agregado familiar; duas sessões a partir do mesmo endereço traduzido em portas diferentes são dispositivos diferentes; o mesmo endereço em dois dias diferentes pode ser dois assinantes sem relação se a porta foi reciclada. Um servidor que só registe chaves de pares não consegue associar uma a um cliente sem a base de dados de contas, e um servidor que só registe endereços não distingue um portátil de um telemóvel atrás do mesmo router.

Compare as duas pontas em vez de adivinhar

Para esclarecer o que aconteceu, capture a mesma ligação nas duas pontas no mesmo momento e compare o tuplo, não o endereço. No cliente, antes de qualquer tradução:

ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpoints

Depois leia a entrada de tradução no router ou no gateway CGNAT, e o que chega finalmente ao servidor:

conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820

Três padrões explicam a maioria das divergências. A porta de origem no servidor difere da porta local enquanto o destino coincide: tradução de portas normal. O endereço de origem no servidor pertence a um bloco de ISP que não é o seu: pelo menos uma camada NAT adicional. Os pacotes param após um período de inatividade e retomam com uma porta nova: o mapeamento expirou, não é uma falha de encaminhamento. Se os carimbos de tempo estão a mais de um ou dois segundos, está a comparar duas tentativas diferentes.

Onde a diferença quebra as coisas

As interrupções que parecem falhas do servidor começam normalmente aqui. Uma regra de acesso fixada ao seu endereço de casa falha depois de o lease do ISP mudar. Uma regra do fail2ban que corresponde a um endereço traduzido bloqueia todos os assinantes atrás desse gateway de uma vez. Um par site-to-site com um endereço remoto fixo deixa de renovar chaves depois de um link móvel mudar. O protocolo do túnel estava bem; a suposição sobre o tuplo externo não.

A mesma confusão aparece do lado do servidor. Se a própria caixa VPN estiver atrás de NAT, precisa de encaminhamento de porta e de um caminho de reencaminhamento funcional; o guia de reencaminhamento do strongSwan cobre esse caso para IPsec. Um servidor acessível apenas num endereço privado nunca vê o tuplo traduzido que os seus clientes apresentam, e isso é um problema diferente de os clientes serem traduzidos.

Percorra estas quatro verificações por ordem e pare na primeira que falhar:

• Capture nas duas pontas ao mesmo tempo; confirme que a porta de origem, a porta de destino e os carimbos de tempo coincidem.
• Leia a lista de pares do servidor para o endereço que ele tem agora, não o que esperava.
• Verifique a tabela conntrack ou NAT para a entrada e o seu tempo de vida restante.
• Confirme que o endereço da interface do túnel no cliente corresponde ao atribuído pelo servidor, não ao endereço LAN.

Se ambas as capturas concordam no tuplo e o túnel continua a falhar, a tradução não é o seu problema; passe ao handshake e à tabela de encaminhamento dentro do túnel.