MTU por rota no Linux: três controles de tamanho, uma rota
A MTU da interface, a MTU da rota e o limite MSS atuam em camadas diferentes. Ataque um orçamento à rota que ganha a busca e mantenha a mudança reversível.
Três ajustes num cliente Linux soam todos como «deixe os pacotes menores», e atuam em camadas diferentes. A MTU da interface limita cada pacote que o dispositivo envia. A MTU de uma rota limita os pacotes que usam essa rota, que muitas vezes é o que você realmente quer para um destino VPN. O limite TCP MSS muda o que as duas pontas negociam, e não faz nada por UDP.
Três controles que parecem o mesmo botão
Coloque-os lado a lado antes de escolher, porque escolher a linha errada explica a maior parte do conselho que não funciona:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
Baixar a MTU do Ethernet para a máquina inteira é a versão grosseira deste ajuste. Funciona, e também penaliza qualquer outra aplicação no host, inclusive as que tinham seus caminhos em ordem. Um valor por rota expressa a mesma intenção sem o custo colateral.
A comparação só vale para o tráfego que o próprio host gera. Encaminhar um pacote para outro cliente envolve o caminho dele e o orçamento externo do túnel, e uma métrica de rota neste host não alcança além dessa fronteira.
Ataque o orçamento à rota que ganha a busca
Um registro de rota IPv4 ilustrativo se parece com isto:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380
Leia o registro como descrição de intenção, não como valor para colar. O prefixo, o dispositivo e a fonte preferida precisam corresponder à configuração real, e o número precisa vir de evidência sobre o caminho encapsulado, não de um post de blog. A MTU da rota limita o pacote IP interno, que não é o mesmo que uma carga TCP de 1380 bytes nem um pacote externo cifrado de 1380 bytes.
Veja onde a busca realmente se resolve antes de acrescentar qualquer coisa. Um host com regras de política pode encaminhar um destino por uma tabela diferente de main, e uma métrica que só existe em main é invisível para essa requisição. Compare ip -4 route show table all com a resposta de ip route get, incluindo o contexto de marca ou de namespace quando as regras os usam. Se os dois não concordam, a tabela que respondeu é a que precisa da métrica, não a que parece mais arrumada.
mtu não é mtu lock
Por padrão o kernel ainda pode atualizar a MTU do caminho a partir do feedback ICMP, que é para isso que serve a descoberta de MTU de caminho. Acrescentar lock interrompe isso. É uma decisão diferente, não uma forma mais forte de guardar o mesmo número, e no IPv4 muda o tratamento documentado do bit de não fragmentar.
Travar é razoável quando você mediu o caminho e quer o valor fixo, aconteça o que acontecer. É um padrão ruim quando a rede envia feedback legítimo de tamanho, porque o kernel não pode mais se ajustar e a falha se desloca para outro sintoma.
Se o ICMP for filtrado em algum ponto do caminho, nenhum ajuste de rota conserta isso. A correção pertence ao filtro, e uma MTU menor é um contorno que esconde a falha real até a próxima mudança de caminho.
O software de túnel acrescenta seus próprios botões de tamanho
OpenVPN- mssfix ajusta o tamanho do segmento TCP para o seu caso documentado de túnel UDP. Atua na conversa TCP, então não é outra grafia da MTU de rota do sistema operacional, e não pode ajudar um serviço UDP que ignora a negociação.
Não empilhe uma MTU de rota, uma mudança de MTU de interface e um limite MSS na mesma janela de mudança. Se o problema desaparecer, você não saberá qual importou, e os que mantiver limiterão o tráfego por anos sem um motivo que alguém lembre.
Torne reversível e depois prove
O dono real da rota decide se a mudança sobrevive a uma reconexão. Um cliente VPN que instala a rota dinamicamente normalmente a reconstrói sem a sua métrica, e um ip route add manual então parece uma correção que falhou um dia depois. Ponha o valor na configuração do gerente e, se precisar de um experimento temporário, anote primeiro a rota original.
Teste com uma conexão nova que faça a operação que travou, depois confirme que a rota privada pretendida continua ganhando e que os destinos não relacionados não mudaram. Reconecte o túnel e leia a rota de novo, porque um valor que desaparece na reconexão não é correção.
Se a evidência não sustenta a mudança, remova a substituição pelo gerente e restaure os atributos originais da rota em vez de apagá-la. Depois anote o que você mediu e em qual caminho, para que a próxima pessoa distinga uma melhoria real de um experimento que ficou rodando.