OpenVPN avisa sobre uso inconsistente do MTU: o que o aviso compara

Esse aviso informa de uma comparação entre as opções dos pares, não de uma medição do caminho entre eles. As pessoas leem-no como «o MTU está errado» e mudam o número até a linha desaparecer. Isso trata uma comparação de configuração como medição de rede, e muitas vezes piora o túnel enquanto deixa o registo mais silencioso. O primeiro passo útil é decidir qual desses dois problemas tem realmente.

Três condições decidem a resposta: o que os pares comparam, se o valor é legado e que sintoma existe além do aviso.

O aviso compara opções, não pacotes

Os pares de OpenVPN trocam as suas cadeias de opções durante o aperto de mão e comparam-nas como parte da verificação de consistência de opções. Quando um lado comunica link-mtu ou tun-mtu de forma diferente do outro, a discrepância é registada com ambos os valores. Essa troca nunca envia um pacote grande para ver o que acontece, por isso o aviso descreve configuração e não capacidade. Um túnel pode transportar tráfego de tamanho completo e ainda imprimir o aviso, ou falhar em pacotes grandes e não imprimir nada.

Guarde o aviso completo com os valores local e remoto. O par é a prova; o número isolado de que se lembra não é.

Por que link-mtu está obsoleto

O OpenVPN 2.6 declara link-mtu obsoleto porque cabeçalhos variáveis e cifras negociadas tornam um valor de ligação fixo pouco fiável. A opção pressupunha uma disposição de pacote que o protocolo já não garante, pelo que um perfil antigo com um link-mtu literal descreve uma intenção que o código atual não consegue cumprir. Copiar esse número para um perfil novo propaga uma suposição obsoleta. Leia-o como parte da história do perfil antigo, não como recomendação.

A verificação de consistência também tem um valor OCC opcional ligado a tun-mtu, que muda o que é comparado sem mudar o que a rede transporta. Defini-lo não faz caber pacotes maiores.

Corrija o perfil antes de testar o caminho

Corrija uma discrepância não intencional através de quem detém os perfis, e lembre-se de que uma alteração no servidor afeta todos os clientes. Edite o perfil que a instância realmente carrega, não uma exportação numa pasta de transferências. Depois reconecte um cliente de teste e anote qual aviso sobrevive. Se a mensagem mudar de forma em vez de desaparecer, está a comparar opções diferentes das que pensa.

Um servidor partilhado precisa de ver o inventário de clientes verificado antes de mover um valor global, porque o valor que serve um site pode quebrar outro.

Depois teste o sintoma que tem realmente

Se as transferências grandes encravam enquanto os pedidos pequenos funcionam, meça o tamanho do pacote contra um destino controlado. Uma sonda que define o bit «não fragmentar» e aumenta o tamanho da carga encontra o MTU utilizável do caminho muito mais fiavelmente do que um ping que simplesmente acerta. Inclua a aplicação que falha no teste: um tempo limite ICMP pode refletir filtragem, e um ping pequeno bem-sucedido nada diz sobre um pacote de aplicação de tamanho completo.

mssfix limita o MSS anunciado para as sessões TCP dentro do túnel, o que ajuda o TCP e não faz nada por uma carga UDP interna. A fragmentação e o offload têm as suas próprias condições de compatibilidade. Escolha um mecanismo para o problema demonstrado em vez de mudar vários ao mesmo tempo para silenciar uma linha de registo.

Guarde os valores efetivos com o resultado

Registe os valores efetivos originais e corrigidos junto ao resultado de uma transferência real. É esse par que separa uma opção de perfil obsoleta de um problema de MTU no caminho que existe de forma independente. Sem ele, o leitor seguinte vê um aviso que desapareceu e assume que a rede mudou.

Silenciar a verificação de consistência não reconcilia nada. Remove a observação e deixa ambas as configurações como estavam.