Burato negro de MTU: por que as peticións pequenas funcionan pero as subidas atascan

Unha páxina carga, unha chamada API pequena volve e despois unha subida de ficheiro queda colgada ata que o cliente se rende. Nada no rexistro do servidor o explica, porque os paquetes descartáronse no medio do camiño sen enviar unha resposta útil. Ese patrón é un burato negro de MTU: unha ligazón máis estreita do que supón o emisor, máis unha negativa silenciosa a dicilo. O tamaño que falla é repetible, e iso é o que o fai diagnosticable.

Que fai negro o burato

Cada ligazón ten unha unidade máxima de transmisión, e un paquete maior que o límite do seguinte salto debe fragmentarse ou rexeitarse cunha mensaxe ICMP que o diga. O descubrimento da MTU do camiño depende de que esa mensaxe chegue e se respecte. Filtrarla ou ignoralo deixa o emisor repetindo un paquete que nunca cabe.

A encapsulación fai que isto sexa habitual nos VPN, porque un túnel engade unha cabeceira externa a un paquete que xa estaba dimensionado para a ligazón física. O paquete interno é legal a 1500 bytes e o encapsulado non, así que morre na fronteira mentres os paquetes pequenos pasan. Un handshake completado e unha páxina de inicio que funciona só demostran que os paquetes pequenos funcionan. O paquete máis grande que a aplicación tenta enviar é o que importa.

Atopa o tamaño onde se rompe

Busca por bisección o tamaño da carga cunha proba sen fragmentación, desde un equipo a un lado do túnel ata un equipo no outro. A carga maior que ten éxito é a túa MTU de camiño utilizábel menos a sobrecarga da cabeceira.

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

Unha carga de 1472 bytes ten éxito nun camiño Ethernet limpo de 1500 bytes unha vez engadidos os 28 bytes das cabeceiras IPv4 e ICMP. Cando a mesma proba só ten éxito cunha carga menor unha vez levantado o túnel, a diferenza é a sobrecarga de encapsulación, e a fronteira do túnel é onde debería terse xerado a mensaxe de rexeitamento. Anota os dous números, antes e despois de conectar, porque ese par é a proba. Repite a proba para IPv6 cando a aplicación o use, xa que a cabeceira é maior e o limiar de fallo desprázase.

Le as probas antes de culpar o túnel

Os erros de aplicacións remotas, a conxestión e a perda ordinaria tamén atascan as subidas, así que unha transferencia fallida non identifica un burato negro. O que os separa é a relación de tamaños: un éxito repetible a 1200 bytes e un atasco repetible a 1400 bytes, na mesma dirección, polo mesmo punto final.

Unha captura nos dous extremos mostra os paquetes grandes saíndo e sen chegar nunca, sen rexeitamento entre eles. Ese é o momento de mirar o dispositivo de fronteira en lugar do servidor, que responde a cada petición que recibe de verdade. A conxestión tamén atasca, pero atasca tamaños distintos en momentos distintos, e iso é unha sinatura diferente.

Comproba a reparación nos dous transportes

A reparación admitida é deixar que a fronteira informe do límite real, ou fixar alí o tamaño máximo de segmento de TCP para que non se tente ningún segmento demasiado grande. Baixar cada MTU da rede, ou desactivar a devasa, oculta o síntoma e deixa unha configuración sobre a que ninguén poderá razoar despois.

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

Verifícao coa mesma proba de tamaño, despois coa aplicación que fallou, e comproba un segundo protocolo, porque as aplicacións UDP nunca reciben a corrección de tamaño de segmento de TCP. Garda os valores orixinais no ticket, porque unha reparación que non se pode reverter é un segundo problema esperando a ocorrer. Se a proba de tamaño pasa e a subida segue atascada, o burato negro non era a causa, e a investigación debe seguir adiante en lugar de ampliar o cambio.