Qual é exatamente o problema de MTU / MRU, o que é causado e como corrigi-lo?

Em casos de interrupção, congelamento, conexão lenta e sem resposta da Internet, a causa geralmente é identificada como "problema de MTU / MRU" com várias "curas mágicas" propostas apressadamente (geralmente inválidas ou inaplicáveis ​​para a situação), como comandos envolvendo iptablesou ifconfig, e outros " braçadeira MTU para TSS ".

O que eu quero saber é qual é exatamente o problema do MTU / MRU, por que afeta a velocidade e a latência da conexão e como ele é curado (métodos conhecidos e modernos), pois eu gostaria de abordar a resolução do problema com conhecimento de causa, não magicamente.

Esta é uma pergunta um pouco complicada, então vou começar com o básico. Perdoe-me se você já sabe tudo isso.

MTU é a unidade máxima de transmissão, o maior pacote de dados que uma interface de computador enviará. Para Ethernet, o padrão é 1500 bytes. Geralmente, os quadros Ethernet podem ter até 1522-1542 (depende do que você conta) e o espaço extra é 'reservado' para as informações do cabeçalho.

Várias conexões podem ter recursos diferentes. É bastante comum encontrar um link na Internet que possui uma MTU um pouco menor que 1500. Isso geralmente ocorre porque o link emprega informações extras de cabeçalho ou usa um meio diferente da Ethernet 'padrão' (a maioria da Internet realmente roda em Conexões ATM / SoNet). Normalmente, o tráfego que encontra esse link é simplesmente dividido em várias partes e enviado.

Como isso é comum e, na época em que o IP foi inventado, parte da responsabilidade do protocolo ICMP era comunicar qualquer problema com as MTUs. Se, por algum motivo, um pacote não puder ser quebrado e encaminhado, o ICMP será usado para comunicar o problema ao computador remetente. O computador remetente toma as medidas apropriadas, dividindo as informações em partes menores e todos ficam felizes. Todo esse processo é tratado nos bastidores. Em uma rede funcionando corretamente , nunca é necessário mexer nas configurações da MTU .

O qualificador nessa última frase é o kicker. Há três razões comuns para o processo automatizado:

1. Implementação quebrada - O software em algum momento simplesmente não funciona como deveria. Não há leis dizendo que as pessoas precisam seguir o padrão relevante da Internet e há empresas que quebram os padrões, geralmente para serem baratas.
2. Implementação desabilitada administrativamente - acontece que pessoas com boas intenções interrompem o software porque na verdade não sabem o que estão fazendo. Eu pessoalmente vi pessoas bloquearem o ICMP porque acham que ele é usado apenas para pacotes ICMP.0.0 (eco, a maioria das pessoas sabe disso pelo pingutilitário).
3. Outras razões completamente fora deste processo "normal". Geralmente, isso significa que a conexão é tão perdida que apenas pacotes mais curtos passam pela conexão de maneira confiável (ou sem um grande número de tentativas). Alguns DSL e CableModems antigos tiveram problemas como este. Antes disso, a conexão discada geralmente apresentava problemas como esse ao usar linhas telefônicas de baixa qualidade e codificações de linha agressivas.

Então, por que é comum: técnicos / empresas preguiçosos. É quase universalmente 'mais fácil' prejudicar a conexão com uma pequena MTU do que corrigir um dos problemas descritos acima. Como mencionado acima, ninguém deveria ter que mexer com o MTU atualmente (a única exceção que posso pensar em ativar os quadros Jumbo, mas não é isso que estamos discutindo aqui). A cura correta, em qualquer caso, é descobrir o problema subjacente e corrigi-lo; caso clássico de tratar a doença e não o sintoma.

Como o MTU afeta uma conexão? Cortar os dados em pedaços minúsculos significa que cada pedaço terá uma melhor chance de chegar ao destino, especialmente em conexões altamente não confiáveis. Sendo pedaços menores, porém, há mais sobrecarga pelos dados transmitidos. Isso significa que a velocidade efetiva da conexão diminui; substancialmente se o MTU for realmente pequeno. A latência pode ser afetada, embora eu espere que seja menor, devido ao processamento extra e sobrecarga do cabeçalho e do processo de fragmentação / remontagem.

Atualização: - Em relação --clamp-mss-to-pmtu
pessoalmente, nunca me preocupei com o MTU; Admito que sou um pouco perfeccionista e, quando recebo hacks feios como esse, sempre encontro a raiz do problema e pude corrigi-lo. Para esse fim, a iptablesopção --clamp-mss-to-pmtunão me é familiar. Aparentemente, é extremamente comum e provavelmente muito injustificado na maioria das situações, usar esse hack. Ainda é um truque para compensar um dos problemas acima. Cito a página de manual do Linux para iptables (8):

Esse destino é usado para superar ISPs ou servidores de criminosos que bloqueiam os pacotes 'ICMP Fragmentation Needed' ou 'ICMPv6 Packet Too Big'.

A linguagem relativamente severa da página de manual deve ser uma indicação de quanto desprezo é conquistado pelos ISPs e redes que não seguem as RFCs (e não fazem nenhum esforço para tentar compensar).

Falando sobre o uso de UDP em VPNs, isso costumava ser mais comum para minimizar a sobrecarga da VPN e permitir que os terminais existentes gerenciassem as informações da sessão. Não há como a VPN saber como a sessão deve ser tratada; portanto, é melhor deixar essa tarefa para os aplicativos que a conhecem.

Muitos protocolos modernos de encapsulamento de VPN são criados em níveis mais baixos (com ainda menos sobrecarga), como GRE e L2TP; ou encapsulado em níveis mais altos (geralmente para compatibilidade com firewalls restritivos ou outros motivos), como SSTP ou SSH. Estes substituirão gradualmente o UDP como um mecanismo de transporte.

Atualização 2: - Diagnosticando problemas de MTU / ICMP
Então, você acha que tem um problema de MTU / ICMP e deseja ter certeza. Existem duas etapas básicas para esse processo. As instruções são para uma caixa Linux ou BSD, mas podem ser adaptadas a praticamente qualquer sistema operacional.

1. Escolha um alvo de ping ICMP (por exemplo, Google.com, Yahoo.com, Facebook.com, etc). Tente fazer um ping-los com o seguinte comando: ping -c 2 -s 1472 -D google.com.
   • Isso deve ter sucesso. Se não der certo, deve retornar "o pacote precisa ser fragmentado". Se uma dessas opções for verdadeira, pare, sua conexão funcionará perfeitamente.
   • Se isso não retornar nada ou der uma mensagem de "tempo limite", você terá um problema.
2. Somente para conexões interrompidas: execute traceroute -F google.com 1472. Isso informará qual salto está quebrado. Nota: é bastante comum o CPE não responder às solicitações de traceroute, portanto, não se assuste se o primeiro salto não responder.
   • Qualquer que seja o último salto a responder é o último que está funcionando corretamente para você.
   • Se nenhum deles responder, é a sua linha CPE ou DSL (descobrir qual pode ser um pouco complicado, mas quase nunca é CPE se for moderno). Nota: Se sua conexão funcionar bem, o traceroute será concluído com êxito.

Em uma nota lateral: Que ISP usa PPTP hoje em dia ?! Isso é uma explosão do passado antiquado e inútil. Eles deveriam pelo menos estar usando PPPoE; mas simplesmente autorizar o modem por MAC e Segment seria muito mais fácil (mais fácil para o ISP e o Cliente).