Llegan las respuestas de eco, el escritorio remoto funciona y el navegador se queda en una página en blanco hasta que se rinde. Dos explicaciones encajan con ese patrón, y no son variantes de un mismo problema: una política que nunca permitió el servicio, o paquetes que dejan de caber cuando crece la transferencia. La respuesta de eco no descarta ninguna de las dos.

Vaya de la pregunta más pequeña a la más grande y anote qué demostró realmente cada paso.

Una respuesta de eco contesta una pregunta mucho más pequeña

Una respuesta de eco dice que la pila IP del destino contestó una petición ICMP de su origen. No dice nada sobre si existe un oyente TCP en el puerto que necesita, si una política permite ese puerto o si el host de destino filtra el tráfico con independencia de la puerta de enlace. Una puerta de enlace que permite un servicio puede descartar otro mientras ambos objetivos responden al ping. Lea la respuesta como un solo hecho sobre un solo paquete y una sola dirección.

Confirme el destino y el puerto del servicio antes de interpretar cualquier otra cosa. La dirección que probó y la dirección que usa la aplicación a veces son registros distintos, y un nombre que se resuelve en dos direcciones hace que eso sea probable.

Averigüe si la conexión comenzó

Una conexión rechazada de inmediato es una respuesta del oyente o de la política: algo contestó y dijo que no. Una conexión que se abre y luego se atasca cuando los datos empiezan a moverse apunta al tamaño. Una conexión que nunca completa el apretón de manos suele deberse a la política o al enrutamiento, y parece un tiempo de espera más que un rechazo.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

Anote cuál de esos tres casos observó antes de tocar los ajustes de MTU. Cambiar el tamaño del túnel para arreglar una conexión rechazada desperdicia el cambio y oculta la causa real durante un tiempo.

Mida el tamaño con un número declarado

Cuando el atasco aparece bajo carga, pruebe un tamaño de paquete con el bit de no fragmentar activado y exponga la aritmética para que el resultado signifique algo. En Linux con iputils, una carga útil de 1392 bytes más la cabecera ICMP de 8 bytes y la cabecera IPv4 de 20 bytes produce un paquete interno de exactamente 1420 bytes. Exponga esa aritmética en el ticket, porque un ping desnudo que llega a la puerta de enlace no demuestra nada sobre una aplicación.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Ambas sondas son puntos de medición, no recomendaciones de tamaño del túnel. Si se filtra ICMP en algún punto del camino, un tiempo de espera no le dice nada sobre el tamaño, porque el filtrado y un paquete demasiado grande se ven iguales desde el cliente. Un éxito tampoco dice nada sobre la dirección inversa ni sobre otro destino.

Cuente el camino exterior

La encapsulación añade sus propias cabeceras, así que el paquete en el cable es mayor que el paquete que midió dentro del túnel. La diferencia entre ambos es lo que hace posible al mismo tiempo una petición pequeña que funciona y una grande que falla.

El descubrimiento de la MTU del camino en IPv4 depende de la realimentación sobre paquetes que no se pueden reenviar sin fragmentación, e IPv6 usa mensajes Packet Too Big. La especificación IPv4 describe ese mecanismo. Filtrar la realimentación rompe la capacidad del emisor de aprender y lo deja retransmitiendo paquetes que nunca cabrán. Por eso una petición pequeña que funciona y una grande que falla conviven tan cómodamente.

Cambie un número y vuelva a probar la aplicación

Baje la MTU del túnel o limite el tamaño máximo de segmento para TCP, y luego repita la prueba original de la aplicación en lugar de la sonda. Una sonda que tiene éxito tras el cambio y una aplicación que sigue colgada son un problema distinto con una forma parecida, y solo la prueba de la aplicación los distingue.

Mantenga la aritmética en el registro del cambio: el tamaño medido, la sobrecarga que supuso y el valor que fijó. Quien lo revise más adelante podrá comprobar la suposición en lugar de volver a deducirla de una captura de pantalla de un ping.

Si la aplicación funciona con todos los tamaños que probó, deje de ajustar números y mire la política que separa el servicio que funciona del que falla.

Artículos relacionados