Las páginas cargan pero las subidas se atascan en la VPN: qué causa gana
Un atasco que depende del tamaño encaja con un fallo de MTU de la ruta, y también con DNS, un límite de la aplicación o un túnel inestable. Cuatro observaciones deciden cuál.
Las páginas cargan, la VPN dice estar conectada y una subida de archivo se congela siempre en el mismo punto. Cuatro explicaciones encajan con esa descripción: un problema de tamaño de paquete, un problema de resolución de nombres, un límite de la aplicación y un túnel que se reinicia continuamente. Cada una puede confirmarse o descartarse con una observación distinta, así que la decisión consiste en elegir la prueba correcta en lugar de adivinar la causa.
Cuatro candidatos y una forma
Empieza por la forma del fallo, porque elimina la mayor parte de la lista antes de abrir cualquier herramienta. Un atasco que ocurre con un tamaño constante es un problema de tamaño hasta que se demuestre lo contrario. Un atasco en puntos aleatorios es un problema de pérdida o de estabilidad. Un fallo antes de que se abra la conexión es un problema de nombres.
El cuarto candidato es la aplicación. Los límites de subida, los tiempos de espera de las solicitudes y los topes de tamaño del cuerpo del proxy producen fallos que, desde el navegador, parecen fallos de red, y suelen llegar como un rechazo en lugar de un cuelgue.
Anota la forma observada antes de probar nada. «Se detiene aproximadamente en el mismo número de bytes, cada vez, con el túnel levantado» es un punto de partida mucho más sólido que «las subidas no funcionan».
Luego mantén la ruta fija mientras pruebas. Cambiar la salida, el protocolo y el servidor al mismo tiempo produce un resultado que no puedes atribuir a ninguno de ellos. Una variable por ejecución, y anótala.
Divide el tamaño antes de tocar la política
El discriminador más barato es una sonda que varía un solo número. Envía pings sin fragmentación de tamaño creciente al destino, sube un archivo que controles al mismo servicio y compara dónde se detiene cada uno.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadEl primer comando informa si un paquete de tamaño completo sobrevive a la ruta. Con una MTU de 1500 bytes, la mayor carga ICMP que no se fragmenta es de 1472 bytes, y un túnel saca aún más de ese presupuesto antes de que empiece el paquete interior. El segundo te da un tamaño y una duración para una transferencia a nivel de aplicación, que es el número que de verdad importa.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
Lee el par en conjunto. Sondas que fallan por encima de un umbral y una subida que se detiene cerca del mismo umbral es una historia coherente. Sondas que tienen éxito todas mientras la subida se atasca en un número de bytes que la ruta claramente transporta apuntan a la aplicación o al servidor, y ningún trabajo de MTU lo cambiará. Ese resultado negativo vale tanto como uno positivo. Elimina la rama más cara de la investigación.
Después comprueba la estabilidad durante la transferencia, porque un túnel que renueva la clave en mitad de una subida grande produce un fallo que parece depender del tamaño sin serlo. La lectura del tiempo de actividad es la forma más barata de confirmarlo.
Decide entre una reparación y un apaño
Si las pruebas apuntan al tamaño, hay dos respuestas honestas y una deshonesta. Las honestas son restaurar el descubrimiento de MTU de la ruta permitiendo la retroalimentación ICMP necesaria, o fijar el tamaño de segmento anunciado para que los pares envíen segmentos más pequeños. La deshonesta es bajar la MTU de una interfaz a un valor copiado de un foro y no verificar nunca qué cambió.
La elección depende de lo que controles. En una red que operas, permitir los mensajes ICMP es la solución más limpia porque mantiene el mecanismo funcionando para cada protocolo. En una ruta que no controlas, fijar el tamaño es la opción práctica, y debe aplicarse de forma estrecha y no a todo el servidor.
Si las pruebas apuntan a la aplicación, repara la aplicación o su configuración de proxy. Una respuesta 413 y una conexión colgada son fallos distintos, y el segundo suele ser un tiempo de espera en algún punto de una cadena que incluye un proxy con sus propios límites.
En cualquier caso, conserva los valores originales y vuelve a probar después de revertir. Un cambio que coincide con una transferencia correcta no es prueba de que la haya causado, y la capacidad de deshacerlo es lo que separa un diagnóstico de una coincidencia.
Registra la decisión para que sobreviva al próximo incidente
Cuatro hechos bastan: la forma observada del fallo, los resultados de las sondas, el cambio que hiciste y el resultado de la repetición de la prueba. Con ellos, la siguiente persona puede decir si el problema es el mismo o uno nuevo con el mismo síntoma.
Anota también el contexto de la ruta, porque un hallazgo de MTU es específico de un enlace. Un portátil que funciona en casa y falla en un hotel tiene dos rutas, y una corrección aplicada a una de ellas no dice nada sobre la otra.
Por último, resiste el resumen de que «la VPN rompió las subidas». El túnel estaba presente tanto en el caso que funcionaba como en el que fallaba; lo que cambió fue el tamaño del paquete que la ruta debía transportar, o dónde se detuvo la transferencia. Nombrar el mecanismo real es lo que hace útil la nota.