OpenVPN em PPPoE: baixar link-mtu, tun-mtu ou mssfix?

Os pings respondem, o DNS resolve e toda página que precisa de um segmento de tamanho completo trava. Num uplink que acrescenta a sua própria encapsulação, o caminho perde silenciosamente algumas dezenas de bytes de orçamento, e um perfil escrito para Ethernet limpo continua a pedir pacotes que a linha não consegue transportar. A ligação não está lenta; está a descartar exatamente os pacotes que importam.

Três opções podem corrigir isto, e atuam em camadas diferentes. Escolher a errada ou não faz nada ou torna o túnel frágil de uma forma nova, por isso a escolha começa pelo que o caminho suporta realmente.

Três controlos, três camadas diferentes

link-mtu é o orçamento exterior: a carga cifrada mais o cabeçalho OpenVPN, o cabeçalho UDP e o cabeçalho IP exterior. Descreve o que sai da máquina, e é por isso que é o número que o caminho físico limita.

tun-mtu é o orçamento interior: a interface que o seu tráfego vê. É maior do que aquilo que o caminho consegue transportar exatamente na sobrecarga do túnel, e o OpenVPN normalmente deriva-o em vez de o obrigar a defini-lo.

mssfix é um mecanismo completamente diferente. Reescreve o tamanho máximo do segmento anunciado durante os handshakes TCP, para que os pares TCP escolham segmentos que caibam depois da encapsulação. Não altera a MTU da interface e não tem qualquer efeito sobre UDP.

Se definir link-mtu explicitamente, o OpenVPN subtrai a sua própria sobrecarga para derivar a MTU interior. Essa sobrecarga não é uma constante fixa; depende da cifra e da autenticação, e é por isso que um valor copiado de um fórum pode estar errado noutro perfil. Definir tanto link-mtu como tun-mtu dá ao cliente duas instruções contraditórias.

Meça o caminho antes de escolher qualquer número

Meça a partir da interface física, não de dentro do túnel, e lembre-se de que o ping reporta a carga útil, não o tamanho do pacote. Acrescente 28 bytes para os cabeçalhos IPv4 e ICMP antes de comparar a carga útil com uma trama de 1500 bytes, e tenha essa correção em mente quando um par reportar um número diferente.

Num cliente Linux, ping -M do -s 1472 proíbe a fragmentação e falha se o pacote for demasiado grande. Baixe a carga útil até passar, e depois acrescente 28 para obter a MTU do caminho. O PPPoE custa 8 bytes, por isso 1492 é normal em DSL. O DS-Lite e alguns caminhos móveis custam 40 ou mais, e a resposta é geralmente inferior ao que a velocidade nominal da ligação sugere.

Se todos os tamanhos de ping tiverem sucesso mas as transferências grandes continuarem a travar, suspeite de um buraco negro em vez de um limite de tamanho simples. Uma mensagem ICMP de fragmentação necessária está a ser filtrada algures no caminho, por isso o emissor nunca aprende a reduzir, e só os fluxos que precisam de um segmento grande o notam.

Limite o TCP primeiro, encolha o túnel depois

Os handshakes TCP são a única coisa que o mssfix toca, o que normalmente o torna o controlo menos invasivo a experimentar primeiro. Defina-o um pouco abaixo do orçamento real do caminho, envie o mesmo valor do servidor para que as duas pontas concordem, e volte a testar um download grande. Se o bloqueio desaparecer, o problema era o tamanho do segmento TCP, e nada mais precisa de mudar.

Baixe a MTU interior quando o tráfego afetado não for TCP. Um serviço UDP, um túnel dentro do túnel ou uma aplicação que envia datagramas de tamanho completo continuará a falhar depois de um limite MSS porque nada reescreve o tamanho dos seus pacotes. Reduza tun-mtu nesse caso, ou defina link-mtu e deixe o cliente derivar o valor interior, mas nunca ambos.

Não recorra à antiga opção de fragmentação. Dividia pacotes dentro do túnel, acrescentava sobrecarga e foi descontinuada por boas razões; o OpenVPN moderno espera que o caminho seja descrito com precisão.

Porque é que as sondas pequenas continuam a funcionar

As consultas DNS, os ecos ICMP e os handshakes TCP estão todos muito abaixo do tamanho que falha. O túnel parece portanto saudável em qualquer teste rápido, enquanto os handshakes TLS e as respostas HTTP falham silenciosamente. É precisamente essa combinação, um traceroute a funcionar e um navegador que trava na primeira resposta grande, o sinal a procurar. Recorra a uma sonda de tamanho completo antes de recorrer a um novo perfil.

Verifique com o tráfego que falhou. Carregue uma página grande, envie um datagrama UDP de tamanho completo se esse for o serviço afetado, e repita a partir de um segundo cliente noutro uplink. Anote a MTU de caminho medida e o valor que escolheu, porque a próxima pessoa a mexer no perfil tratará o número como arbitrário caso contrário.

Nunca baixe a MTU interior abaixo de 1280 quando o IPv6 passa sobre o túnel, porque esse é o mínimo que cada ligação IPv6 tem de transportar. Uma MTU menor é um facto sobre o caminho, não um ajuste de desempenho a calibrar por instinto.