Forat negre d’MTU: per què les peticions petites funcionen però les pujades s’encallen

Es carrega una pàgina, torna una crida API petita i després una pujada de fitxer es penja fins que el client es rendeix. Res del registre del servidor ho explica, perquè els paquets es van deixar caure al mig del camí sense enviar cap resposta útil. Aquest patró és un forat negre d’MTU: un enllaç més estret del que suposa l’emissor, més un rebuig silenciós a dir-ho. La mida que falla és repetible, i això és el que la fa diagnosticable.

Què fa negre el forat

Cada enllaç té una unitat màxima de transmissió, i un paquet més gran que el límit del salt següent s’ha de fragmentar o bé rebutjar amb un missatge ICMP que ho digui. El descobriment de l’MTU del camí depèn que aquest missatge arribi i que es respecti. Filtrar-lo o ignorar-lo deixa l’emissor repetint un paquet que mai no hi cap.

L’encapsulament fa que això sigui habitual als VPN, perquè un túnel afegeix una capçalera exterior a un paquet que ja tenia la mida de l’enllaç físic. El paquet interior és legal a 1500 bytes i l’encapsulat no, així que mor a la frontera mentre els paquets petits passen. Un handshake completat i una pàgina d’inici que funciona només demostren que els paquets petits funcionen. El paquet més gran que l’aplicació intenta enviar és el que importa.

Troba la mida on es trenca

Cerca binàriament la mida de la càrrega amb una prova de no fragmentació, des d’un equip d’un costat del túnel fins a un equip de l’altre. La càrrega més gran que té èxit és el vostre MTU de camí utilitzable menys la sobrecàrrega de la capçalera.

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

Una càrrega de 1472 bytes té èxit en un camí Ethernet net de 1500 bytes quan s’hi afegeixen els 28 bytes de les capçaleres IPv4 i ICMP. Quan la mateixa prova només té èxit amb una càrrega més petita un cop el túnel està aixecat, la diferència és la sobrecàrrega d’encapsulament, i la frontera del túnel és on s’hauria d’haver generat el missatge de rebuig. Anota els dos números, abans i després de connectar, perquè aquesta parella és la prova. Repeteix la prova per a IPv6 quan l’aplicació l’utilitzi, ja que la capçalera és més gran i el llindar de fallada es mou.

Llegeix les proves abans de culpar el túnel

Els errors d’aplicacions remotes, la congestió i la pèrdua ordinària també encallen les pujades, així que una transferència fallida no identifica un forat negre. El que els separa és la relació de mides: un èxit repetible a 1200 bytes i un encallament repetible a 1400 bytes, en la mateixa direcció, pel mateix punt final.

Una captura als dos extrems mostra els paquets grans sortint i no arribant mai, sense cap rebuig entremig. Aquest és el moment de mirar el dispositiu de frontera en lloc del servidor, que respon cada petició que rep de veritat. La congestió també encalla, però encalla mides diferents en moments diferents, i això és una signatura diferent.

Comprova la reparació als dos transports

La reparació suportada és deixar que la frontera informi del límit real, o fixar-hi la mida màxima de segment de TCP perquè no s’intenti cap segment massa gran. Baixar cada MTU de la xarxa, o desactivar el tallafoc, amaga el símptoma i deixa una configuració que ningú no podrà raonar més endavant.

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

Verifica-ho amb la mateixa prova de mida, després amb l’aplicació que va fallar, i comprova un segon protocol, perquè les aplicacions UDP no reben mai la correcció de mida de segment de TCP. Guarda els valors originals al tiquet, perquè una reparació que no es pot revertir és un segon problema esperant passar. Si la prova de mida passa i la pujada encara s’encalla, el forat negre no era la causa, i la investigació ha de seguir endavant en lloc d’ampliar el canvi.