OpenVPN mssfix: por que um cliente trava em transferências grandes

Um único portátil trava nos envios através do túnel enquanto todos os outros dispositivos no mesmo servidor continuam a funcionar. Esse padrão aponta para um caminho, não para a configuração do servidor, e é a entrada habitual para a questão do mssfix. A opção pode ajudar, mas apenas para as ligações TCP que realmente reescreve. Conhecer o seu alcance evita que altere um servidor que funciona para salvar um único cliente.

O que a opção reescreve

mssfix edita o tamanho máximo de segmento anunciado nos handshakes TCP que atravessam o túnel, para que o lado emissor escolha segmentos que cabem no orçamento encapsulado. Atua sobre o handshake, o que significa que uma ligação aberta antes da alteração mantém o valor negociado.

Não reduz os datagramas UDP e não define a MTU do túnel. Dois problemas diferentes produzem o mesmo sintoma: um emissor TCP que ignora o limite do caminho e um caminho que descarta silenciosamente pacotes grandes de qualquer tamanho. mssfix trata do primeiro e não faz nada pelo segundo.

Essa distinção explica as experiências dececionantes. Definir um valor menor num caminho com buraco negro altera o tamanho do segmento, mas não o descarte que se segue, pelo que a transferência falha noutro ponto.

O alcance é TCP dentro do túnel

Apenas o tráfego TCP é reescrito. Uma sessão QUIC, um jogo ou uma aplicação que envia datagramas UDP grandes mantém os seus próprios tamanhos de pacote, e se são essas as transferências que travam, a correção pertence antes à MTU do túnel ou do caminho. Leia que protocolo usa a transferência que falha antes de recorrer a uma opção TCP, porque a camada errada tem a sua própria correção.

A direção também importa. Uma definição do cliente afeta o tráfego que esse cliente envia para o túnel, enquanto o servidor cobre os fluxos que reencaminha para os clientes. Se apenas as transferências de entrada travam, o valor do lado do cliente não é a história toda.

O número e a palavra-chave não são portáveis

A versão comunitária do OpenVPN 2.6 aceita uma palavra-chave opcional depois do valor. Com mtu, o número descreve o tamanho do pacote exterior, incluindo os cabeçalhos IP e UDP; sem ela, o argumento segue outra convenção de cálculo. Por isso, uma linha copiada entre versões não descreve o mesmo orçamento de pacotes. Consulte a página do manual que acompanha a compilação que realmente executa, em vez de um tutorial para outra versão.

A sintaxe é assim:

mssfix 1400 mtu

Trate 1400 como um marcador de posição, não como uma recomendação para o seu caminho. Deduza o valor a partir do caminho medido e do encapsulamento realmente utilizado, e lembre-se de que os clientes em versões antigas ou noutras implementações podem rejeitar ou reinterpretar a palavra-chave.

Confirme primeiro no único cliente

Meça o caminho a partir da máquina que falha antes de alterar alguma coisa. Uma carga útil que o caminho possa transportar sem fragmentação é o número que procura:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

A primeira sonda cabe num pacote de 1500 bytes depois de acrescentados os 28 bytes de cabeçalhos. Se falhar com um erro de fragmentação e a mais pequena tiver êxito, o tamanho utilizável está nalgum ponto entre as duas, e a sobrecarga do túnel é retirada de cima.

Depois repita a transferência que travou, numa ligação nova, e compare. Se o cliente único melhorar enquanto os outros ficam intactos, encontrou o alcance do problema. Se todos os clientes travarem, o valor do lado do servidor é o que deve ser revisto. Nenhum dos dois resultados justifica uma alteração em hardware que nunca esteve no caminho que falha.