A VPN por UDP trava em inatividade: a firewall esqueceu o seu fluxo

A VPN liga-se, funciona durante um bocado e depois deixa de passar tráfego enquanto o cliente ainda mostra uma sessão. Reconectar resolve, o que faz parecer um bug do cliente. Normalmente é uma firewall ou um dispositivo NAT que descartou um mapeamento UDP inativo e não faz ideia de que o túnel ainda existe.

O sintoma é consistente o suficiente para ser diagnosticado: aparece após inatividade, não sob carga.

Como é um travamento por inatividade

Meça-o em vez de o descrever. Anote quanto tempo o túnel fica inativo antes de o tráfego parar, se um novo pacote de saída o reanima e se a interface do cliente ainda mantém o seu endereço. Se um pedido novo do cliente funcionar mas uma resposta a um fluxo existente não, o mapeamento é o suspeito. Se nada funcionar até reconectar, o estado de sessão do cliente também se perdeu.

Ambos estão ligados à inatividade e precisam de correções diferentes.

Anote os tempos antes de mudar o que quer que seja. Um relato de que para após cerca de dez minutos de inatividade é verificável, enquanto um relato de que cai ao acaso não é. Essa diferença decide se anda atrás de um temporizador ou de uma alteração de encaminhamento.

Encontre o dispositivo que esqueceu

Vários dispositivos podem guardar estado para o mesmo fluxo: o router local, um tradutor mais acima, uma fronteira de nuvem e a firewall do anfitrião. Cada um tem o seu temporizador, e o mais curto ganha. Uma interrupção de cinco minutos normalmente significa que um dispositivo está configurado muito abaixo dos outros.

Não assuma que o valor predefinido documentado é o tempo limite no seu caminho. É o valor predefinido de um só dispositivo.

• Router doméstico: muitas vezes minutos, por vezes muito menos.
• NAT na nuvem ou balanceador de carga: procure o tempo limite de inatividade documentado especificamente para UDP.
• Firewall do anfitrião: os temporizadores de rastreio do netfilter aplicam-se por fluxo.

Verifique os temporizadores no caminho real

No Linux, os temporizadores de rastreio do netfilter são visíveis e ajustáveis: sysctl net.netfilter.nf_conntrack_udp_timeout e net.netfilter.nf_conntrack_udp_timeout_stream. O segundo aplica-se assim que foi visto tráfego nos dois sentidos, e é por isso que um túnel estabelecido pode sobreviver a uma sonda simples.

RFC 4787 define o comportamento do UDP NAT e os mínimos recomendados. É a referência a citar quando o valor predefinido de um fornecedor parece invulgarmente curto.

Keepalive e reconexão são ferramentas diferentes

Um keepalive mantém um mapeamento vivo; uma reconexão reconstrói uma sessão morta. Resolvem falhas diferentes e não são definições de velocidade intermutáveis. A opção PersistentKeepalive do WireGuard envia um pacote a um intervalo fixo para manter a ligação NAT aberta. A opção keepalive do OpenVPN faz o mesmo trabalho à sua maneira. Nenhuma ajuda se o dispositivo no meio já esqueceu o fluxo e está a descartar as duas direções.

Sondas extremamente frequentes acrescentam trabalho sem corrigir a fronteira errada.

Verifique com um pedido novo, não com uma recarga de página

Depois de alterar um temporizador ou acrescentar um keepalive, repita o cenário de inatividade exatamente como antes. Em seguida faça um pedido realmente novo a partir da aplicação coberta. Um separador do navegador já carregado pode ser renderizado a partir da cache e não lhe diz nada.

Se o travamento persistir, avance um salto para fora e verifique a tabela de estados desse dispositivo.