¿La subida del VPN es más lenta que la bajada? Decida qué límite está alcanzando

La mayoría de las líneas de acceso son asimétricas, así que un túnel normalmente sube más despacio de lo que baja, y esa es la respuesta esperada y no un fallo. La pregunta interesante es si su subida está limitada por la línea, por otra cosa que ya la usa o por un flujo que se atasca en lugar de ir constante. Esos tres producen la misma queja y exigen un trabajo distinto.

Tres límites que desde la barra de progreso parecen idénticos

La capacidad es el primero, y es una propiedad del producto de acceso, no del túnel. Un enlace ascendente de unos pocos megabits es normal en fibra residencial y en muchos planes móviles, y el costo del cifrado es pequeño frente a esa diferencia. La encapsulación también añade bytes por paquete, lo que recorta el rendimiento útil en ambas direcciones y no solo en una, así que por sí sola no puede explicar una asimetría grande.

La contención es el segundo. La sincronización en la nube, las fototecas y los agentes de actualización suben mientras el equipo parece inactivo, y un segundo dispositivo en la misma línea hace lo mismo. La cola es el tercero: un enlace ascendente saturado empuja el tráfico interactivo detrás de los datos masivos, así que las llamadas se cortan mientras la propia transferencia informa de un progreso saludable.

Mida una dirección a la vez

Use el mismo dispositivo, el mismo perfil y el mismo destino, y nunca ejecute ambas direcciones a la vez salvo que la contención sea justo lo que quiere observar. Pause sus propias transferencias opcionales antes de la primera ejecución. Dos ejecuciones con una bandera entre ellas resuelven la mayor parte.

iperf3 envía desde el cliente por defecto, así que la ejecución simple mide su ruta de subida; -R invierte la dirección y mide la bajada. Ejecútelas con unos minutos de diferencia y anote ambos números en lugar de promediarlos:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

Si la cifra de subida es una fracción pequeña de la de bajada y se mantiene estable entre ejecuciones, la forma corresponde a una línea de acceso asimétrica y el túnel no es la historia. Si la subida oscila entre ejecuciones o se desploma a los diez segundos, siga leyendo.

Decida por dónde cambia la subida

Cambie una variable a la vez y observe qué dirección se mueve. Un segundo punto final de VPN que sube mejor apunta a ese punto final o a la ruta hacia él. La misma subida lenta desde un segundo dispositivo en la misma línea apunta a la línea. Un dispositivo distinto en una línea distinta que también es lento apunta a la política de entrada del destino, que no puede arreglar localmente.

Anote bytes por segundo y tiempo transcurrido para la misma carga, no una única puntuación de velocidad. Un cliente de copias de seguridad y una prueba de velocidad usan destinos y concurrencia distintos, así que comparar sus cifras no responde nada. Si las peticiones pequeñas van bien y solo se arrastran las transferencias grandes, el límite probablemente no sea el ancho de banda.

Para el uso diario, limitar una subida en segundo plano o programarla fuera de las horas de reuniones suele ayudar más que cualquier ajuste del túnel. Juzgue ese cambio por la carga combinada: una copia de seguridad que termina más tarde pero ya no arruina las llamadas suele ser el mejor intercambio.

Cuando el atasco vence a la lentitud

Una transferencia que se congela en un punto repetible y luego se reanuda se comporta como un problema de MTU de la ruta y no como un límite de velocidad. El túnel reduce la carga útil por paquete, y un dispositivo que descarta el mensaje ICMP resultante deja al emisor adivinando. Ese patrón merece su propia prueba, porque la reparación es distinta de ajustar una velocidad. Una cifra baja y estable apunta a la capacidad, mientras que un estallido seguido de silencio apunta a una carga que la ruta no puede llevar.

Pruebe la ruta con una carga que no deba fragmentarse y luego compare la MTU de la interfaz del túnel con el valor que pasa:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

Si la sonda grande desaparece mientras una pequeña tiene éxito, ajuste el TCP MSS en el túnel en lugar de bajar la MTU de la interfaz para cada protocolo. Los atascos persistentes después de ese punto pertenecen al almacenamiento o al ritmo de la aplicación receptora, no a la ruta de red.

Qué cambiar y qué dejar

Cambie las cosas que controla: los horarios de transferencia en segundo plano, la elección de punto final y la MSS para una ruta que se atasca. Mantenga cada cambio reversible y limitado a una carga. Deje en paz las cosas que la medición dice que están bien, incluida una velocidad de bajada que ya coincide con la línea.

Anote las cifras de antes y después junto con el perfil, el punto final y la hora del día, porque un problema de subida que se mueve con el punto final es una cuestión de enrutamiento y uno que se mueve con el dispositivo es local. Ese registro es lo que convierte una queja vaga en una decisión, y cuesta dos ejecuciones del mismo comando.