Início / computer / Perguntas / 1731924
Accepted
LivingSilver94
Asked: 2022-07-16 13:11:12 +0800 CST

Aproveite o firewall UDP com estado para servidores Wireguard em NATs

  • 772

Eu tenho uma configuração "cliente-servidor" composta por um computador servidor Wireguard e um cliente, ambos sob seus respectivos NAT. Eu quero que eles se comuniquem sem encaminhamento de porta no roteador do cliente. Obviamente, ainda preciso de encaminhamento de porta no roteador do servidor.

De acordo com este comentário , pode-se aproveitar o firewall UDP com estado se as respostas do servidor vierem da mesma porta que o cliente usou para alcançá-lo. Para fazer isso, configurei ListenPortpara 58120 em ambas as extremidades:

[Interface]
ListenPort = 51820
...snip...

Agora, com tcpdumpexecutado no roteador do cliente, posso provar que os pacotes estão saindo com a porta de origem 51820 e a porta de destino 51820. O mesmo com tcpdumpexecutado no roteador do servidor: pacotes de saída com origem e destino definidos para 51820.

No entanto, na direção de entrada, o roteador do cliente mostra que os pacotes vêm da porta 1025. Parece que o NAT do lado do servidor mudou a porta 51820 para 1025. Isso ocorre porque a porta 51820 já está ocupada pelo encaminhamento de porta? Como posso ter portas de origem e destino iguais para que o roteador do cliente detecte uma "conexão" UDP?

Detalhe da implementação: firewalls e NATs são controlados por iptables.

firewall iptables

1 respostas

  1. Best Answer

    De acordo com este comentário, pode-se aproveitar o firewall UDP com estado se as respostas do servidor vierem da mesma porta que o cliente usou para alcançá-lo.

    Não é isso que o comentário diz. As portas não precisam ser iguais; eles só precisam ser simétricos. Ou seja, se os pacotes saírem com a porta de origem 51820 e a porta de destino 28150, o NAT esperará que os pacotes de entrada sejam da porta 28150 a 51820.

    (Dê uma olhada em, por exemplo, solicitações de DNS – você não verá pacotes com 53→53, verá [random]→53 e o firewall apenas esperará respostas com 53→[random].)

    No entanto, na direção de entrada, o roteador do cliente mostra que os pacotes vêm da porta 1025. Parece que o NAT do lado do servidor mudou a porta 51820 para 1025. Isso ocorre porque a porta 51820 já está ocupada pelo encaminhamento de porta?

    O mais provável é que o NAT já esteja rastreando outra conversa UDP com esse destino que usa a mesma porta local (mas talvez vindo de um endereço IP interno diferente ou indo para uma porta remota diferente).

    O módulo SNAT / MASQUERADE padrão no iptables não analisa quais regras de encaminhamento de porta você tem - ele só tem informações sobre o estado do conntrack (os fluxos rastreados atualmente), mas tentará reescrever a porta local para garantir a exclusividade da entrada host:port (veja nf_nat_used_tuple).

    Verifique conntrack -L -p udpno gateway; você pode querer liberar estados antigos se estiver editando frequentemente as regras de NAT para experimentos.

    Algumas implementações de NAT em gateways usam um módulo NAT iptables personalizado e sempre alteram a porta de origem de todas as conexões de saída. Isso geralmente vem junto com o termo "Symmetric NAT" (em oposição ao "Cone NAT" mais brando que o iptables padrão implementa).

    Artigo relevante (de desenvolvedores de um aplicativo VPN baseado em WireGuard): https://tailscale.com/blog/how-nat-traversal-works/

    • 1

relate perguntas