Eu tenho dois sistemas Debian GNU/Linux (bullseye/sid), ambos rodando wireguard na porta 23456, ambos atrás do NAT. Ambos executam uma versão do kernel > 5.6 (mainlined wireguard).
O sistema A é o servidor e atualiza dinamicamente um "registro A" dedicado no servidor de nomes autoritativo para seu domínio da Internet, com o endereço IP público correto com o qual o roteador A voltado para a Internet (firewall ZyWALL USG 100) está atribuído. Ele faz isso uma vez a cada minuto, mas o endereço IP público realmente muda apenas na reinicialização do roteador/firewall, o que basicamente nunca acontece.
O sistema B está atrás do roteador VDSL B e atua como cliente wireguard, apontando para o "registro A" atualizado dinamicamente e a porta 33456. O roteador B é um roteador VDSL de nível de consumidor e permite tudo na direção de saída, apenas responde de entrada.
O roteador/firewall A (ZyWALL USG 100) está configurado para permitir pacotes UDP na porta 23456 através dele e os encaminha para o servidor A. Aqui está a tela de configuração relevante:
Aqui está o arquivo de configuração do servidor A wireguard (as chaves neste trecho, apesar de válidas, não são as reais):
[Interface]
Address = 10.31.33.100/24, fc00:31:33::1/64
ListenPort = 23456
PrivateKey = iJE/5Qy4uO55uUQg8nnDKQ/dFT1MEq+tDfFXrGNj3GY=
# PreUp = iptables -t nat -A POSTROUTING -s 10.31.33.0/24 -o enp1s0 -j MASQUERADE; ip6tables -t nat -A POSTROUTING -s fc00:31:33::/64 -o enp1s0 -j MASQUERADE
# PostDown = iptables -t nat -D POSTROUTING -s 10.31.33.0/24 -o enp1s0 -j MASQUERADE; ip6tables -t nat -D POSTROUTING -s fc00:31:33::/64 -o enp1s0 -j MASQUERADE
# Simon
[Peer]
PublicKey = QnkTJ+Qd9G5EybA2lAx2rPNRkxiQl1W6hHeEFWgJ0zc=
AllowedIPs = 10.31.33.211/32, fc00:31:33::3/128
E aqui está a configuração do wireguard do cliente B (novamente, as chaves e o domínio não são os reais):
[Interface]
PrivateKey = YA9cRlF4DgfUojqz6pK89poB71UFoHPM6pdMQabWf1I=
Address = 10.31.33.211/32
[Peer]
PublicKey = p62kU3HoXLJACI4G+9jg0PyTeKAOFIIcY5eeNy31cVs=
AllowedIPs = 10.31.33.0/24, 172.31.33.0/24
Endpoint = wgsrv.example.com:33456
PersistentKeepalive = 25
Aqui está um diagrama sujo que descreve a situação:
Client B -> LAN B -> VDSL Router B (NAT) -> the internet -> ZyWALL (NAT) -> LAN A -> Server A
Iniciar o wireguard em ambos os sistemas não estabelece a conexão VPN. Ativando mensagens de depuração no cliente e adicionando uma regra de LOG no iptables, que registra OUTPUT
os pacotes, recebo muitos destes:
[414414.454367] IN= OUT=wlp4s0 SRC=10.150.44.32 DST=1.2.3.4 LEN=176 TOS=0x08 PREC=0x80 TTL=64 ID=2797 PROTO=UDP SPT=36883 DPT=33456 LEN=156
[414419.821744] wireguard: wg0-simon: Handshake for peer 3 (1.2.3.4:33456) did not complete after 5 seconds, retrying (try 2)
[414419.821786] wireguard: wg0-simon: Sending handshake initiation to peer 3 (1.2.3.4:33456)
Adicionei uma regra LOG iptables ao servidor, para diagnosticar problemas de configuração do roteador.
root@wgserver ~ # iptables -t nat -I INPUT 1 -p udp --dport 23456 -j LOG
Ele registra os pacotes wireguard recebidos do cliente (mas não posso dizer se eles são de alguma forma inválidos ou incompletos):
[ 1412.380826] IN=enp1s0 OUT= MAC=6c:62:6d:a6:5a:8e:d4:60:e3:e0:23:30:08:00 SRC=37.161.119.20 DST=10.150.44.188 LEN=176 TOS=0x08 PREC=0x00 TTL=48 ID=60479 PROTO=UDP SPT=8567 DPT=23456 LEN=156
[ 1417.509702] IN=enp1s0 OUT= MAC=6c:62:6d:a6:5a:8e:d4:60:e3:e0:23:30:08:00 SRC=37.161.119.20 DST=10.150.44.188 LEN=176 TOS=0x08 PREC=0x00 TTL=48 ID=61002 PROTO=UDP SPT=8567 DPT=23456 LEN=156
então estou inclinado a assumir que o roteador A (ZyWALL USG 100) foi configurado corretamente para permitir que os pacotes entrem na rede local do servidor. Para confirmar essa suposição, tentei até substituir o ZyWALL por outro roteador de nível de consumidor e mover o servidor por uma conexão de internet diferente, mas o problema ainda está lá, então tenho certeza que o problema não é o firewall, nem seu específico conexão de internet.
Aqui está a configuração da rede do servidor, caso seja importante:
auto lo
iface lo inet loopback
auto enp1s0
iface enp1s0 inet static
address 10.150.44.188/24
gateway 10.150.44.1
Além disso, outros túneis VPN wireguard funcionam corretamente usando o mesmo cliente, mesmo roteador VDSL (lado do cliente), mesma conexão com a Internet, configuração de servidor semelhante (chaves e domínios obviamente diferentes), configuração de firewall semelhante (lado do servidor, diferentes modelo de firewall).
Pode ser estúpido, mas você tentou criar novas chaves de servidor, chaves de cliente e tentou novamente? O Wireguard pode agir exatamente assim quando os perfis estão errados.
OK, você mencionou que o cliente está em VDSL, então suspeito que você tenha um problema de MTU.
O MTU normal de uma conexão de rede com fio (e atualmente sem fio) é de 1500 bytes, mas em *DSL a camada PPPoE ocupa 8 bytes, tornando o MTU utilizável na verdade 1492. (Também é possível que sua conexão de rede tenha sido configurada para um ainda menor MTU.)
A sobrecarga do pacote do Wireguard é de 80 bytes, o que significa que o MTU do túnel é 1420 por padrão. Tente diminuir isso pelos mesmos 8 bytes, para 1412. (Ou mais baixo se você já tiver um MTU menor que 1492.)
Você também precisa ter o cliente para dizer ao servidor para diminuir seu MTU em pacotes encapsulados. Isso pode ser feito com uma regra do iptables.
No lado do cliente wg0.conf você precisará de algo como: