VPN cai do nada? Como ajustar MTU e MSS Clamping

Por que sua VPN falha silenciosamente na rede

Quem nunca passou pela frustração de conectar em uma VPN corporativa e descobrir que páginas pesadas simplesmente travam no meio do carregamento? Na prática, isso significa que a conexão parece ativa, mas o tráfego real não passa. Muitas vezes, o culpado não é o provedor de internet e nem a criptografia, mas sim um detalhe invisível chamado MTU, ou Maximum Transmission Unit, que representa o tamanho máximo de um pacote de dados que pode trafegar sem ser picado em pedaços.

Quando adicionamos uma camada de VPN como WireGuard ou OpenVPN, o pacote original ganha um 'capacete' extra de dados de criptografia. Se o pacote resultante ultrapassar o limite que os roteadores no meio do caminho suportam, ele precisa ser fragmentado. Se os roteadores intermediários decidirem simplesmente descartar esses pacotes fragmentados por questões de segurança, ocorre a famigerada falha de handshake e a conexão congela completamente. Como detalhamos em nosso artigo sobre como mapear perda de pacotes e jitter em rotas, entender o comportamento do tráfego sob o capô é o primeiro passo para estabilizar qualquer túnel.

O que é MTU e por que o encapsulamento quebra tudo

Para entender o problema de forma simples, pense na MTU como a altura máxima permitida para um caminhão passar debaixo de uma ponte. A internet padrão possui uma MTU tradicional de 1500 bytes. Quando você cria um túnel VPN, o protocolo adiciona cabeçalhos extras para garantir a segurança dos dados. O WireGuard adiciona cerca de 60 bytes de overhead, enquanto o OpenVPN sobre UDP pode adicionar até 64 bytes ou mais dependendo da cifra utilizada.

Se a sua placa de rede envia um pacote de 1500 bytes e o túnel adiciona mais 60 bytes, o pacote total vai para 1560 bytes. Caso ele encontre pelo caminho um roteador de operadora que aceita no máximo 1500 bytes, o pacote precisará ser fragmentado. Se a rede ignorar a fragmentação ou se o bit DF (Don't Fragment) estiver ativado, o pacote morre no meio do caminho, resultando em lentidão extrema ou queda total da sessão VPN.

A solução definitiva: configurando MSS Clamping na prática

O MSS Clamping, ou aperto de mão do segmento máximo, é um mecanismo inteligente que avisa o computador de origem para reduzir o tamanho dos pedaços de dados antes mesmo que eles entrem no túnel. Em vez de deixar o pacote crescer e estourar o limite lá na frente, o roteador ou o próprio servidor VPN avisa: 'envie pacotes um pouco menores para caberem com folga no túnel'.

Isso resolve o problema dos sites que abrem parcialmente e travam, pois o protocolo TCP é forçado a negociar um segmento adequado desde o início. Para aplicar isso em roteadores Linux ou firewalls que lidam com tráfego encapsulado, você pode utilizar regras diretas no sistema de filtragem de pacotes. Veja um exemplo clássico de regra para ajustar o MSS automaticamente na interface do seu túnel:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Essa linha mágica instrui o sistema a olhar todo pacote TCP que está iniciando uma conexão e ajustar o seu MSS com base na MTU descoberta do caminho, garantindo que nenhum pacote exceda o limite seguro do seu túnel WireGuard ou OpenVPN.

Ajustando a MTU manualmente no WireGuard e OpenVPN

Além do MSS Clamping, definir o valor correto de MTU diretamente na configuração da interface da VPN é uma prática essencial de engenharia de redes. No WireGuard, por exemplo, o valor padrão costuma ser 1420 para acomodar o cabeçalho UDP e IP sobre uma rede com MTU de 1500. No entanto, se você estiver em uma conexão de fibra com PPPoE, que reduz a MTU base para 1492, o WireGuard precisará cair para 1412.

Para alterar isso no arquivo de configuração do seu cliente ou servidor WireGuard, basta adicionar a diretiva de MTU explicitamente na seção de interface. Veja como fica um bloco típico de configuração otimizada:

[Interface] Size = 10.0.0.2/32 PrivateKey = aaaa... MTU = 1380 [Peer] PublicKey = bbbb... Endpoint = 203.0.113.5:51820 AllowedIPs = 0.0.0.0/0

Ajustar esse valor para 1380 ou até 1360 cria uma margem de segurança contra redes corporativas restritivas, redes Wi-Fi públicas instáveis e conexões móveis 4G/5G que costumam fragmentar pacotes agressivamente. Garantir essa resiliência estrutural evita chamados de suporte e quedas abruptas durante reuniões importantes.

Diagnóstico e validação com testes de ping avançados

Adivinhar o valor ideal de MTU é um erro comum que gera perda de tempo. A melhor forma de descobrir o número exato que sua conexão suporta sem fragmentação é realizar testes manuais utilizando o utilitário ping com o parâmetro de tamanho de pacote restrito e o sinalizador para proibir fragmentação.

No sistema operacional Linux ou macOS, você pode executar o comando indicando o tamanho do pacote e forçando o bit DF. Vá reduzindo o número até que o pacote passe sem receber a mensagem de erro informando que ele precisa ser fragmentado. Veja um exemplo prático de comando para testar o limite em direção ao seu servidor VPN:

ping -M do -s 1400 10.0.0.1

Lembre-se de que o valor passado no parâmetro `-s` refere-se apenas aos dados úteis. Para saber a MTU total real, você deve somar 28 bytes referentes aos cabeçalhos IP e ICMP. Assim, se o teste com `-s 1420` passar sem erros, a sua MTU ideal será 1448. Fazer esse mapeamento evita falhas silenciosas e garante máxima performance.

Conclusão e boas práticas para túneis estáveis

Manter conexões VPN estáveis exige compreender que o tráfego de rede moderno lida com camadas complexas de encapsulamento e restrições invisíveis de infraestrutura. Ao combinar o ajuste fino do parâmetro MTU com o uso eficiente do MSS Clamping, eliminamos a raiz dos travamentos misteriosos e da lentidão intermitente em túneis WireGuard e OpenVPN.

Adotar uma postura proativa de testes com o comando ping e documentar os valores adequados para cada cenário de rede corporativa ou residencial garante uma operação sem surpresas desagradáveis. Investir alguns minutos configurando esses parâmetros libera você e sua equipe de falhas de handshake frustrantes, entregando uma experiência de rede verdadeiramente sólida e transparente.