Porque é que uma VPN bloqueia em transferências grandes e não nas pequenas

Uma página carrega, um ping responde e uma cópia de ficheiro bloqueia sempre no mesmo ponto. Esse padrão aponta para o tamanho do pacote, não para a largura de banda ou as credenciais. A encapsulação acrescenta bytes a cada pacote, por isso uma carga útil que cabia no caminho original pode exceder o limite depois de passar por um túnel. Nestas conversas três números diferentes são chamados MTU, e confundi-los leva a um ajuste que corrige uma aplicação e quebra outra.

Três números que as pessoas chamam MTU

A MTU da interface é o limite configurado para um pacote nessa ligação. A MTU do caminho é o limite mais pequeno ao longo da rota, e descobre-se em vez de se configurar. A MSS do TCP é o tamanho da carga útil que um par anuncia poder receber, e deriva dos outros dois em vez de ser um limite físico à parte.

Um túnel tem uma vista interior e uma vista exterior. O pacote exterior transporta o encapsulado mais os cabeçalhos de que o protocolo precisa, por isso o tamanho interior utilizável é menor do que o caminho exterior permite. O caminho até ao servidor VPN também é diferente do caminho do servidor até ao destino.

A descoberta da MTU de caminho permite ao emissor conhecer o tamanho que funciona, mas depende de o feedback chegar. Quando um dispositivo intermédio filtra as mensagens ICMP relevantes, o emissor continua a enviar pacotes que nunca se completam, e esse é o buraco negro clássico. O sintoma é inconfundível quando se conhece: o handshake tem sucesso, a primeira carga útil de tamanho completo desaparece e a ligação acaba por ser reiniciada ou bloqueada. Nada no registo da aplicação se parece com um problema de rede.

Sonde o caminho com uma carga útil que controle

Um teste é uma prova sobre uma rota e um tamanho, não um ajuste recomendado. Use um anfitrião que responda e varie apenas o tamanho da carga útil.

ping -M do -s 1372 -c 2 203.0.113.20
ping -4 -f -l 1372 vpn.example

O primeiro comando envia uma sonda Linux com a fragmentação desativada e uma carga útil de 1372 bytes, e o segundo faz o mesmo no Windows, onde a carga útil se define com -l. Uma resposta significa que esse tamanho sobreviveu ao caminho. Uma mensagem de fragmentação necessária é informativa, enquanto um tempo de espera é ambíguo porque o anfitrião ou um dispositivo intermédio podem simplesmente descartar o ICMP.

Desça o tamanho em poucos passos em vez de fazer uma pesquisa binária até ao byte. Está a tentar estabelecer se existe um teto de tamanho, não a publicar um número para cada rede. O número que encontrar aplica-se a este caminho, a este protocolo e a esta família de endereços.

IPv4 e IPv6 fragmentam de forma diferente, por isso o resultado de uma família não diz nada sobre a outra. Teste a família que a aplicação usa de facto.

O ajuste de MSS só ajuda o TCP

No TCP, a carga útil efetiva é negociada durante o handshake, e um router do caminho pode reescrever esse valor para baixo para que ambas as extremidades enviem segmentos menores. É isso que o ajuste de MSS faz, e funciona sem tocar no cliente de todo.

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
ip link show tun0

A primeira regra ajusta a MSS anunciada à MTU do caminho para os handshakes TCP reencaminhados, e a segunda mostra a MTU própria da interface do túnel para que a compare com o que o caminho permite. O ajuste é a reparação menos invasiva para uma aplicação TCP que bloqueia após o handshake.

Para UDP não faz nada. Um cliente de voz ou de jogos que envie datagramas grandes ignorará por completo um ajuste de MSS, porque não há handshake para reescrever. Se a aplicação que falha for UDP, veja antes as opções de tamanho de pacote do próprio cliente. Os dois protocolos falham de forma diferente e são reparados com ferramentas diferentes, por isso o protocolo pertence à primeira frase do ticket.

OpenVPN expõe opções como tun-mtu, mssfix e definições ligadas à fragmentação, e o comportamento delas depende da versão e de o canal de dados ser AEAD. Leia o manual da versão em uso e mude uma opção de cada vez.

Mude um único ajuste suportado e repita as duas execuções

Mantenha o perfil original, mude um único valor suportado e repita tanto o pedido pequeno que funcionava como a transferência grande que falhava. Se só a grande mudar, andava atrás do tamanho. Se ambas mudarem, algo mais se moveu com ela.

Um valor mais baixo pode reduzir o sintoma ao mesmo tempo que acrescenta sobrecarga, por isso o número mais pequeno possível não é o objetivo. O objetivo é um tamanho que o caminho transporte de forma fiável com o mínimo desperdício. Anote o valor, o caminho e a versão do cliente no ticket, porque aplicar o mesmo número noutro sítio é um palpite.

Se o mesmo perfil funcionar a partir de outra rede de confiança, mantenha essa diferença no diagnóstico em vez de declarar o cliente reparado. A variável que mudou é o caminho, e o caminho é o que a sonda mediu.