Qual è esattamente il problema MTU / MRU, da cosa è causato e come risolverlo?

In caso di impiccagione, congelamento,, connessioni internet non risponde lente la causa è di solito irragionevolmente identificato come "questione MTU / MRU" con diversi frettolosamente proposte "cure magici" (di solito non valide o inapplicabili per la situazione) come comandi che coinvolgono iptableso ifconfig, e altri " bloccare gli incantesimi da MTU a TSS ".

Quello che voglio sapere è esattamente quale sia il problema MTU / MRU, perché influenza la velocità e la latenza della connessione e come viene risolto (metodi noti e moderni), dal momento che mi piacerebbe avvicinarmi con cognizione di causa alla risoluzione del problema, non magicamente.

Questa è una domanda un po 'complicata, quindi inizierò con le basi. Perdonami se sai già tutto questo.

MTU è l'unità di trasmissione massima, il più grande pacchetto di dati che verrà inviata da un'interfaccia per computer. Per Ethernet il valore predefinito è 1500 byte. In genere, i frame Ethernet possono avere una lunghezza massima di 1522-1542 (dipende da ciò che conti) e lo spazio extra è "riservato" per le informazioni di intestazione.

Varie connessioni possono avere capacità diverse. È abbastanza comune imbattersi in un collegamento su Internet che ha un MTU leggermente più piccolo di 1500. Questo di solito è dovuto al collegamento che utilizza informazioni di intestazione aggiuntive o utilizza un mezzo diverso da Ethernet "standard" (la maggior parte di Internet funziona su Connessioni ATM / SoNet). Normalmente il traffico che incontra un tale collegamento viene semplicemente suddiviso in più parti e inviato insieme.

Poiché questo è comune ed era al momento dell'invenzione dell'IP, parte della responsabilità del protocollo ICMP era di comunicare eventuali problemi con gli MTU. Se un pacchetto per qualsiasi motivo non può essere rotto e inoltrato, ICMP viene utilizzato per comunicare il problema al computer di invio. Il computer di invio esegue le azioni appropriate, suddividendo le informazioni in blocchi più piccoli e tutti sono felici. L'intero processo è gestito dietro le quinte. In una rete correttamente funzionante non è mai necessario confondere con le impostazioni MTU .

Il qualificatore di quest'ultima frase è il kicker. Esistono tre motivi comuni per cui il processo automatizzato si interrompe:

1. Implementazione interrotta - Il software ad un certo punto semplicemente non funziona come dovrebbe. Non ci sono leggi che dicono che le persone devono seguire gli standard pertinenti di Internet e ci sono aziende che infrangono gli standard, di solito per essere economici.
2. Implementazione disabilitata a livello amministrativo - Succede che le persone con buone intenzioni rompano il software perché non sanno davvero cosa stanno facendo. Ho visto personalmente le persone bloccare ICMP perché pensano che sia usato solo per i pacchetti ICMP.0.0 (eco, la maggior parte delle persone lo sa pingdall'utilità).
3. Altre ragioni completamente al di fuori di questo processo "normale". Per lo più comunemente questo significa che la connessione è così perdita che solo i pacchetti più corti riescono a farlo in modo affidabile attraverso la connessione (o senza un numero enorme di tentativi). Alcuni dei primi DSL e CableModem avevano problemi come questo. E prima, il dial-up aveva comunemente problemi come questo quando si utilizzavano linee telefoniche di qualità molto scadente e codici di linea aggressivi.

Quindi, perché è comune: tecnici / aziende pigri. È quasi universalmente "più semplice" ostacolare la connessione con un piccolo MTU piuttosto che risolvere uno dei problemi descritti sopra. Come detto sopra, nessuno dovrebbe avere problemi con MTU in questi giorni (l'unica eccezione che posso pensare di abilitare i frame Jumbo, ma non è proprio quello di cui stiamo discutendo qui). La cura corretta in ogni caso è capire il problema di fondo e risolverlo; caso classico di cura della malattia non del sintomo.

In che modo MTU influisce su una connessione? Tagliare i dati in piccoli pezzi significa che ogni pezzo avrà maggiori possibilità di arrivare a destinazione, specialmente attraverso connessioni altamente inaffidabili. Essendo pezzi più piccoli, tuttavia, vi è un sovraccarico maggiore per i dati trasmessi. Ciò significa che la velocità di connessione effettiva viene ridotta; sostanzialmente se l'MTU è davvero piccola. La latenza può essere influenzata, anche se mi aspetto che sia minore, a causa dell'elaborazione e del sovraccarico extra dell'intestazione e del processo di frammentazione / riassemblaggio.

Aggiornamento: - Per quanto riguarda --clamp-mss-to-pmtu
Personalmente non ho mai avuto problemi con MTU; Ammetto di essere un po 'un perfezionista e quando si presentano con brutti hack come questo trovo sempre la radice del problema e sono stato in grado di correggerlo. A tal fine, l' iptablesopzione --clamp-mss-to-pmtunon mi è familiare. Apparentemente è estremamente comune, e probabilmente molto ingiustificato nella maggior parte delle situazioni, usare questo hack. È ancora un trucco per compensare uno dei problemi di cui sopra. Cito dalla manpage di Linux per iptables (8):

Questo obiettivo viene utilizzato per superare ISP o server criminali che bloccano i pacchetti "ICMP Fragmentation Needed" o "ICMPv6 Packet Too Big".

Il linguaggio relativamente aspro della manpage dovrebbe essere un'indicazione di quanto disprezzo sia raccolto dagli ISP e dalle reti che non seguono le RFC (e non fanno alcuno sforzo per cercare di compensare).

Parlando dell'uso di UDP nelle VPN, questo era più comune per ridurre al minimo il sovraccarico della VPN e consentire agli endpoint esistenti di gestire le informazioni sulla sessione. Non c'è modo per la VPN di sapere come gestire la sessione, quindi quell'attività è davvero meglio lasciare alle applicazioni che lo sanno.

Molti protocolli di tunneling VPN moderni sono basati su livelli inferiori (con un sovraccarico ancora minore), come GRE e L2TP; o tunneling a livelli più alti (di solito per compatibilità con firewall restrittivi o altri motivi), come SSTP o SSH. Questi sostituiranno gradualmente UDP come meccanismo di trasporto.

Aggiornamento 2: - Diagnosi dei problemi MTU / ICMP
Quindi pensi di avere un problema MTU / ICMP e vuoi esserne sicuro. Ci sono due passaggi fondamentali per questo processo. Le indicazioni sono per un box Linux o BSD, ma possono essere adattate a qualsiasi sistema operativo.

1. Scegli un obiettivo Ping ICMP (ad es. Google.com, Yahoo.com, Facebook.com, ecc.). Provare a pingare con il seguente comando: ping -c 2 -s 1472 -D google.com.
   • Questo dovrebbe avere successo. Se non riesce, dovrebbe restituire "il pacchetto deve essere frammentato". Se uno di questi è vero, fermati, la tua connessione funziona bene.
   • Se ciò non restituisce nulla o restituisce un messaggio di "timeout", si verifica un problema.
2. Solo per connessioni interrotte: eseguire traceroute -F google.com 1472. Questo ti dirà quale hop è rotto. Nota: è abbastanza comune che CPE non risponda alle richieste traceroute, quindi non allarmarti se il primo hop non risponde.
   • Qualunque sia l'ultimo hop per rispondere è l'ultimo che funziona correttamente per te.
   • Se nessuno di loro risponde è la tua linea CPE o DSL (capire quale può essere un po 'complicato, ma non è quasi mai CPE se è moderno). Nota: se la connessione funziona correttamente, traceroute verrà completato correttamente.

Nota a margine: quale ISP utilizza PPTP in questi giorni ?! È un tuffo nel passato antiquato e inutile. Dovrebbero almeno usare PPPoE; ma autorizzare semplicemente il modem tramite MAC e segmento sarebbe molto più semplice (più facile sia per l'ISP che per il cliente).