Roteiro para descobrir por que a VPN WireGuard não conecta ou não acessa as VMs: handshake, rotas, firewall, MTU e DNS.

Para que serve

Quando a VPN WireGuard não conecta ou conecta e não acessa nada, o problema quase sempre está em uma de cinco camadas: o túnel não fecha (handshake), o túnel fecha mas os pacotes não têm rota, o firewall bloqueia, o MTU quebra conexões maiores ou o DNS não resolve os nomes internos. Este roteiro testa uma camada por vez, na ordem, para você achar a causa sem adivinhar. Os exemplos usam WireGuard; no fim há os equivalentes para IPsec.

Pré-requisitos

  • Acesso root à VM de VPN e ao host Proxmox (pela VPN, pelo console noVNC do Proxmox ou, se o painel estiver bloqueado, pelo console IPMI/iLO, que continua acessível mesmo sem VPN).
  • Acesso ao cliente com problema (notebook, celular ou roteador do escritório).
  • Pacote tcpdump no servidor: apt install tcpdump.
  • Exemplos (fictícios): VM de VPN com ID 110, IP público 203.0.113.5, placa interna ens19 em 10.10.10.2; host em 10.10.10.1; VPN 10.8.0.0/24; VMs 10.10.10.0/24.

Passo a passo para diagnosticar a VPN WireGuard

  1. Camada 0: a VM de VPN está ligada?

    No host (pelo iLO, se necessário): qm status 110. Se estiver parada, qm start 110 e confira se ela tem início automático (qm config 110 | grep -E 'onboot|startup').

  2. Camada 1: o handshake acontece?

    Na VM de VPN:

    wg show wg0

    Para cada peer, observe latest handshake. Com tráfego, o WireGuard renova o handshake a cada dois minutos; se a última for de muitos minutos atrás ou a linha não existir, o túnel não está fechando. Se o handshake está recente, pule para a camada 3.

  3. Camada 2: os pacotes do cliente chegam ao servidor?

    Na VM de VPN, deixe a captura rodando e ative o túnel no cliente:

    tcpdump -ni any udp port 51820
    • Nenhum pacote chega: o problema está antes do servidor. Confira o Endpoint (IP e porta) no cliente, se a rede do cliente bloqueia UDP (redes corporativas e Wi-Fi de hotel costumam bloquear) e teste pelo 4G do celular.
    • Pacotes chegam, mas o servidor não responde: o WireGuard descarta em silêncio pacotes com chave errada. Compare a chave pública configurada no servidor com a chave derivada da privada do cliente (no app, ela aparece no topo do túnel). Se nada chega na VM, confira o firewall dela no host: cat /etc/pve/firewall/110.fw deve ter IN ACCEPT -i net0 -p udp -dport 51820, e o firewall precisa estar ativo no Datacenter.
    • Interface não existe: systemctl status wg-quick@wg0 e journalctl -u wg-quick@wg0 mostram o erro de sintaxe ou de chave.
    Relógio: o WireGuard usa um carimbo de tempo no handshake para evitar replay. Se o relógio de um peer voltou no tempo (comum em roteadores sem bateria de relógio após reiniciar), o outro lado recusa o handshake até reiniciar a interface ou o relógio ser corrigido. Confira a data e hora nos dois lados (timedatectl no Linux).

  4. Camada 3: as rotas estão certas?

    Com handshake ok, mas sem acesso às VMs, confira os três pontos do caminho:

    # VM de VPN: o encaminhamento e o NAT estão ativos?
sysctl net.ipv4.ip_forward
nft list table ip wgnat

# VM de VPN: existe rota para clientes e escritório?
ip route get 10.8.0.2
ip route get 192.168.10.5

    No Windows do cliente, veja se a rede das VMs aponta para a interface do túnel:

    route print 10.10.10.*
Find-NetRoute -RemoteIPAddress 10.10.10.20
    • A rede das VMs não aparece na tabela do cliente: falta ela no AllowedIPs do cliente. O AllowedIPs funciona como tabela de roteamento: só vai pelo túnel o que está ali.
    • A VM de VPN recebe o pacote, mas o host ou a VM de destino não responde: na VM de VPN, rode tcpdump -ni wg0 icmp e, em paralelo, tcpdump -ni ens19 icmp. Se o ping sai pela ens19 com origem 10.8.0.x, o NAT não está ativo; sem NAT, o destino precisa da rota 10.8.0.0/24 via 10.10.10.2, senão responde pela internet.
    • Pacotes do escritório somem no servidor: a origem precisa estar nas Allowed IPs do peer do escritório. Pacote de origem não listada é descartado sem aviso.
    • Rede local do usuário igual à rede das VMs: conflito de rotas. Troque uma das faixas.

  5. Camada 4: o firewall está bloqueando?

    Teste a porta do serviço, não só o ping:

    # Windows
Test-NetConnection 10.10.10.20 -Port 3389

# Linux/macOS
nc -vz -w 3 10.10.10.20 3389
    • No Proxmox, o firewall da VM só filtra se estiver ativo em Datacenter, na VM e na placa de rede. Confira se existe regra liberando a origem 10.10.10.2 (com NAT na VM de VPN) ou 10.8.0.0/24 (com rota estática). No host, essa origem precisa estar no IPSet management para acessar 8006 e SSH.
    • No Windows da VM, a regra de RDP pode estar limitada a outra faixa: Get-NetFirewallRule -DisplayGroup *Remot* | Get-NetFirewallAddressFilter.
    • Se a VM de VPN usa UFW, o tráfego roteado tem política própria: ufw status verbose deve mostrar a regra route allow in on wg0 out on ens19.

  6. Camada 5: o MTU está quebrando conexões?

    Sintoma clássico: ping funciona, SSH conecta, mas o RDP trava na tela preta, páginas carregam pela metade ou cópias de arquivo param. O WireGuard acrescenta 60 bytes (IPv4) ou 80 bytes (IPv6) a cada pacote e usa MTU 1420 por padrão. Em links PPPoE, comuns em fibra no Brasil, o MTU da internet já é 1492, então sobra menos.

    Descubra o maior pacote que passa sem fragmentar:

    # Linux: 1392 de dados + 28 de cabeçalho = 1420
ping -M do -s 1392 10.10.10.20

# Windows
ping -f -l 1392 10.10.10.20

    Diminua o valor até o ping passar. Some 28 ao maior valor que funcionou e use esse resultado como MTU = na seção [Interface] do cliente (por exemplo, MTU = 1380). Em túneis site-to-site, aplique também o ajuste de MSS na VM de VPN:

    nft add table inet mss
nft add chain inet mss fwd '{ type filter hook forward priority mangle; }'
nft add rule inet mss fwd oifname "wg0" tcp flags syn tcp option maxseg size set rt mtu
nft add rule inet mss fwd iifname "wg0" tcp flags syn tcp option maxseg size set rt mtu

    Para tornar permanente, coloque essas linhas no PostUp do wg0.conf e nft delete table inet mss no PostDown.

  7. Camada 6: o DNS resolve os nomes internos?

    Se acessa por IP mas não por nome (ex.: erp.empresa.local):

    • Defina o servidor DNS interno no cliente: DNS = 10.10.10.10 na seção [Interface]. Com split tunnel, o IP do DNS precisa estar dentro do AllowedIPs.
    • Em Linux, a linha DNS = exige o comando resolvconf. Se aparecer "resolvconf: command not found", instale o systemd-resolved (Debian/Ubuntu) ou remova a linha.
    • Teste a resolução diretamente no DNS interno: nslookup erp.empresa.local 10.10.10.10 (Windows) ou dig @10.10.10.10 erp.empresa.local (Linux).

Equivalentes para IPsec (strongSwan)

  • Estado dos túneis: swanctl --list-sas. Conexões configuradas: swanctl --list-conns.
  • Log em tempo real: journalctl -u strongswan -f.
  • Captura: tcpdump -ni any udp port 500 or udp port 4500.
  • Erros frequentes: NO_PROPOSAL_CHOSEN (criptografia diferente nos dois lados), TS_UNACCEPTABLE (redes local/remota não batem), AUTHENTICATION_FAILED (PSK ou ID errado).

Como saber se funcionou

  • wg show com handshake recente e contadores de transfer subindo nos dois sentidos.
  • Test-NetConnection com TcpTestSucceeded : True na porta do serviço.
  • Uma cópia de arquivo grande ou uma sessão RDP longa sem travar (valida o MTU).

Problemas comuns

  • Funciona por alguns minutos e para: falta PersistentKeepalive = 25 no lado que está atrás de NAT.
  • Funcionava e parou após reiniciar o servidor: a VM de VPN não tem início automático (qm set 110 --onboot 1 --startup order=1), o serviço não está habilitado no boot da VM (systemctl enable wg-quick@wg0) ou o forwarding não foi gravado em /etc/sysctl.d/.
  • Mexeu no firewall e perdeu tudo: entre pelo IPMI/iLO no console do host e rode pve-firewall stop (libera temporariamente a 8006 pelo IP público). Corrija e volte com pve-firewall start.

Perguntas frequentes

Por que o WireGuard não mostra erro quando a chave está errada?

Por projeto: ele não responde a quem não se autentica. Por isso o diagnóstico é pelo handshake e pela captura de pacotes.

Qual MTU usar na VPN em internet PPPoE?

Comece com 1412 (1492 menos 80) e reduza até o teste de ping sem fragmentar passar.

A VPN funciona no 4G e não no Wi-Fi da empresa. Por quê?

A rede da empresa provavelmente bloqueia UDP de saída. Peça a liberação da porta ou use OpenVPN em TCP 443.

Precisa de ajuda?

Se mesmo seguindo o roteiro a VPN não funcionar, abra um ticket informando em qual camada o teste falhou e anexe as saídas de wg show, ip route e da captura do tcpdump (nunca envie chaves privadas).

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também