Redirecionamento de porta para um peer WireGuard atrás de NAT: DNAT mais SNAT

Um navegador solicita https://203.0.113.10:8443, o proxy aceita a conexão e o serviço no peer WireGuard nunca responde. A regra DNAT faz o seu trabalho; a resposta é a parte que falha. Siga o pacote pelas duas traduções e a regra em falta torna-se óbvia. A correção é mais uma instrução NAT no hook correto, não um túnel novo.

Siga um pedido do início ao fim

O pedido chega à interface pública do proxy com o endereço público do cliente como origem e o endereço do proxy como destino. Em nat PREROUTING a regra DNAT reescreve o destino para o endereço do túnel do peer, 10.90.0.2. A decisão de encaminhamento envia então o pacote por wg0 e o caminho de reencaminhamento fica completo.

No peer, o pacote transporta agora o endereço público de origem original, porque nada o reescreveu. O serviço aceita a conexão e envia a resposta para o seu próprio gateway predefinido, que é o router doméstico à frente do peer. Esse router não tem estado para um fluxo que nunca viu e ou descarta o pacote ou tradu-lo para o seu próprio endereço público, o que o cliente não aceitará.

A assimetria é todo o problema: o pedido passa pelo proxy e a resposta tenta ir diretamente. O rastreio de ligações do proxy só ajuda se a resposta voltar pelo proxy, e não pode voltar aí enquanto o endereço de origem ainda aponta para o cliente original.

Adicione a tradução de retorno

Reescreva a origem do fluxo reencaminhado para o endereço do túnel do proxy antes de partir para o peer. O serviço responde então a 10.90.0.1, o proxy recebe-o e o rastreio de ligações inverte as duas traduções antes de o pacote voltar ao cliente.

iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

A regra POSTROUTING é deliberadamente estreita: corresponde ao destino traduzido e à interface do túnel, por isso não reescreve tráfego não relacionado que por acaso sai por wg0. Uma regra masquerade ampla também esconderia o endereço do cliente, mas fá-lo-ia para cada fluxo e tornaria a tabela NAT mais difícil de auditar.

Coloque as regras onde existe o túnel

As regras que referem o endereço ou a interface do túnel devem correr depois de o wg-quick o ter configurado. A interface é criada antes do PreUp, mas os endereços, a MTU, o DNS e as rotas são aplicados depois, e o PostUp corre quando tudo isso está no lugar. Coloque as adições no PostUp e as remoções no PreDown.

PostUp = iptables -t nat -A PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PostUp = iptables -t nat -A POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1
PreDown = iptables -t nat -D PREROUTING -p tcp -m multiport --dports 8080,8443 -j DNAT --to-destination 10.90.0.2
PreDown = iptables -t nat -D POSTROUTING -d 10.90.0.2 -o wg0 -p tcp -m multiport --dports 8080,8443 -j SNAT --to-source 10.90.0.1

As remoções têm de corresponder às adições token a token, incluindo as correspondências multiport e de interface. Uma remoção que difere numa correspondência não remove nada, e a ligação seguinte acrescenta uma segunda cópia da regra. Após várias ligações a tabela contém duplicados difíceis de atribuir a uma linha de configuração.

Verifique o resultado com iptables -t nat -S após uma ligação. Se a mesma regra aparecer duas vezes, a linha PreDown não corresponde e a limpeza falha em silêncio.

Reencaminhamento, filtragem e o outro NAT

Ative o reencaminhamento IPv4 de forma permanente e depois permita o fluxo reencaminhado na tabela de filtro. O DNAT ocorre antes da cadeia FORWARD, por isso a regra de filtro corresponde ao destino traduzido e não ao endereço público. Se o UFW gere a firewall, expresse a permissão como regra de rota; uma regra de host simples não cobre tráfego reencaminhado.

Outras duas camadas de NAT ainda podem quebrar o caminho mesmo quando as regras do proxy estão corretas. Numa ligação doméstica o endereço público pertence ao router, e abrir a porta na firewall dele não é o mesmo que criar uma entrada de redirecionamento de porta que envie essa porta para o proxy. Uma porta que parece aberta de fora enquanto nada responde falta frequentemente exatamente esse mapeamento.

Num VPS com NAT o fornecedor mapeia uma porta pública para um endereço privado. O mapeamento tem de coincidir com a porta que anuncia, e uma discrepância parece idêntica a um túnel quebrado. Confirme o mapeamento do fornecedor antes de alterar a configuração do WireGuard.

Verifique o caminho de retorno e aceite o custo

Ligue-se a partir de uma rede que não seja a LAN do proxy e depois inspecione o par de traduções enquanto a ligação está aberta:

conntrack -L -p tcp --dport 8080
tcpdump -ni any tcp port 8080

A entrada de conntrack deve mostrar o tuple original, o tuple traduzido e a direção da resposta. Se a resposta faltar, o peer não envia pelo túnel, o que normalmente significa que a regra SNAT não foi aplicada ou que a firewall do próprio peer descartou o fluxo.

Reinicie uma vez para provar que o PostUp volta a aplicar as regras e depois pare o túnel e confirme que o PreDown as removeu. As regras mortas que sobrevivem a uma desconexão são a razão pela qual uma alteração posterior se comporta de forma imprevisível.

Por fim, aceite o que o SNAT custa. O serviço vê cada pedido como vindo do proxy, por isso os registos de acesso, os limites de taxa por cliente e as listas de endereços permitidos já não distinguem os utilizadores. O caso hairpin precisa da sua própria tradução de origem para clientes na LAN do proxy. Se o peer precisar de endereços reais dos clientes, a alternativa é uma rota de retorno para a rede do cliente, que dá mais trabalho mas preserva a informação.