Troubleshooting: timeout de TLS no OpenVPN (roteamento assimétrico em Multi-WAN)¶

O cenário e o problema¶

Em firewalls com múltiplos links de internet (Multi-WAN), clientes externos do OpenVPN podem falhar na fase de negociação de chaves. O erro típico no log do cliente, após 60 segundos, é:

▎ TLS Error: TLS key negotiation failed to occur within 60 seconds

▎ TLS handshake failed

Este documento cobre o diagnóstico e a correção desse incidente, causado pelo roteamento assimétrico que o comportamento padrão do protocolo UDP gera nesse tipo de topologia.

Topologia de referência (IPs fictícios)¶

eth1 (link principal / rota default): IP 203.0.113.10
eth2 (link secundário / dedicado à VPN): IP 198.51.100.20
Cliente externo: IP 192.0.2.50
Porta OpenVPN: UDP 1194 (padrão) ou 50000 (customizada)

Processo de diagnóstico (CLI)¶

O primeiro passo é isolar se o pacote está sendo bloqueado pelo provedor de internet ou se o problema está na camada lógica do servidor. Substitua a porta 1194 nos comandos abaixo pela porta usada no seu ambiente.

1. Verificação do serviço (bind)¶

Confirme se o daemon do OpenVPN está ativo e escutando na porta correta.

ss -ulnp | grep 1194

Saída esperada (serviço escutando em todas as interfaces):

UNCONN 0 0 0.0.0.0:1194 0.0.0.0:* users:(("openvpn",pid=12345,fd=6))

2. Captura de pacotes na interface WAN¶

Inspecione a interface de rede dedicada à VPN (eth2) para confirmar que os pacotes do cliente chegam ao firewall.

tcpdump -i eth2 -n udp port 1194

Saída esperada:

17:36:22.140844 IP 192.0.2.50.1194 > 198.51

O tráfego chega na interface eth2 sem problemas, então não há bloqueio de operadora.

3. Simulação da rota de retorno¶

O problema acontece porque a requisição entra por um link, mas o servidor tenta responder pelo outro. Para confirmar, consulte a tabela de roteamento do kernel para o IP do cliente:

ip route get 192.0.2.50

Saída obtida:

192.0.2.50 via 203.0.113.1 dev eth1 src 203.0.113.10 uid 0

O kernel direciona a resposta do OpenVPN parcipal), diferente da interface de entrada(eth2).

4. Auditoria do Policy Based Routing (PBR)¶

Verifique se o firewall tem as regras de Multi-WAN configuradas.

ip rule show

Saída esperada (as regras existem):

85:    from 198.51.100.20 lookup eth2-wan-vivo
32766: from all lookup main

Causa raiz¶

A falha combina o comportamento do protocolo UDP com a topologia Multi-WAN:

Como o OpenVPN escuta em 0.0.0.0, ele recebe o pacote pela eth2, mas entrega a resposta ao kernel do Linux sem especificar o IP de origem 198.51.100.20.
Sem um IP de origem explícito, o Linux ignora a regra 85 do PBR e despacha o pacote pela tabela principal de rotas, que sai pela eth1.
O pacote sai com o IP trocado (de 198.51.100.20 para 203.0.113.10). O firewall do cliente detecta a quebra do estado de conexão e descarta o tráfego, o qu

Solução: simetria de rotas (multihome)¶

Para corrigir o roteamento assimétrico, force o OpenVPN a registrar a interface de entrada de cada requisição e a usar o mesmo endereço na resposta.

Aplicação¶

Edite o arquivo de configuração do servidor (server.conf) ou acesse a seção de configurações avançadas (Custom Options) do painel de gerência da VPN, e adicione:

multihome

Se a VPN não precisar operar em múltiplas interfaces, também é possível fixar o IP de escuta com a diretiva local 198.51.100.20.

Validação¶

Depois de reiniciar o serviço, o daemon passa a assinar os pacotes de resposta com o IP de origem correto. Isso aciona a regra de PBR do sistema operacional: o pacote volta pela eth2 e o handshake TLS se completa.