Buco nero MTU: perché le richieste piccole funzionano ma gli invii si bloccano

Una pagina si carica, una piccola chiamata API torna, e poi un invio di file resta appeso finché il client non si arrende. Nulla nel registro del server lo spiega, perché i pacchetti sono stati scartati a metà del percorso senza che venisse inviata una risposta utile. Questo schema è un buco nero MTU: un collegamento più stretto di quanto il mittente supponga, più un rifiuto silenzioso di dirlo. La dimensione che fallisce è ripetibile, ed è ciò che la rende diagnosticabile.

Che cosa rende nero il buco

Ogni collegamento ha un’unità massima di trasmissione, e un pacchetto più grande del limite del salto successivo deve essere frammentato oppure rifiutato con un messaggio ICMP che lo dice. La scoperta dell’MTU del percorso dipende dall’arrivo di quel messaggio e dal suo rispetto. Filtrarlo o ignorarlo lascia il mittente a ripetere un pacchetto che non può mai entrare.

L’incapsulamento rende questo comune intorno alle VPN, perché un tunnel aggiunge un’intestazione esterna a un pacchetto già dimensionato per il collegamento fisico. Il pacchetto interno è lecito a 1500 byte e quello incapsulato no, quindi muore al confine mentre i pacchetti piccoli passano. Un handshake completato e una pagina di accesso funzionante dimostrano solo che i pacchetti piccoli funzionano. Il pacchetto più grande che l’applicazione prova a inviare è quello che conta.

Trovate la dimensione in cui si rompe

Cercate per bisezione la dimensione del carico con un test senza frammentazione, da un host su un lato del tunnel a un host sull’altro. Il carico più grande che passa è il vostro MTU di percorso utilizzabile meno l’overhead dell’intestazione.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

Un carico di 1472 byte passa su un percorso Ethernet pulito di 1500 byte una volta aggiunti i 28 byte delle intestazioni IPv4 e ICMP. Quando lo stesso test passa solo con un carico più piccolo dopo che il tunnel è attivo, la differenza è l’overhead di incapsulamento, e il confine del tunnel è dove il messaggio di rifiuto avrebbe dovuto essere generato. Annotate entrambi i numeri, prima e dopo la connessione, perché quella coppia è la prova. Ripetete il test per IPv6 quando l’applicazione lo usa, dato che l’intestazione è più grande e la soglia di fallimento si sposta.

Leggete le prove prima di dare la colpa al tunnel

Gli errori delle applicazioni remote, la congestione e la perdita ordinaria bloccano anch’essi gli invii, quindi un trasferimento fallito non identifica un buco nero. Ciò che li separa è il rapporto tra le dimensioni: un successo ripetibile a 1200 byte e un blocco ripetibile a 1400 byte, nella stessa direzione, attraverso lo stesso endpoint.

Una cattura a entrambe le estremità mostra i pacchetti grandi partire e non arrivare mai, senza rifiuto in mezzo. È il momento di guardare il dispositivo di confine invece del server, che risponde a ogni richiesta che riceve davvero. Anche la congestione blocca, ma blocca dimensioni diverse in momenti diversi, e questa è una firma diversa.

Verificate la riparazione su entrambi i trasporti

La riparazione supportata è lasciare che il confine riporti il limite reale, oppure limitare lì la dimensione massima del segmento TCP perché nessun segmento troppo grande venga tentato. Abbassare ogni MTU della rete, o disattivare il firewall, nasconde il sintomo e lascia una configurazione su cui nessuno potrà ragionare in seguito.

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

Verificate con lo stesso test di dimensione, poi con l’applicazione che ha fallito, e controllate un secondo protocollo, perché le applicazioni UDP non ricevono mai la correzione della dimensione del segmento di TCP. Conservate i valori originali nel ticket, perché una riparazione che non si può annullare è un secondo problema in attesa di accadere. Se il test di dimensione passa e l’invio si blocca ancora, il buco nero non era la causa, e l’indagine deve proseguire invece di allargare la modifica.