¿Por qué mi VPN va tan lenta? Pruebe estos cuatro tramos
Decida qué tipo de lentitud tiene y luego pruebe el enlace de acceso, la salida, el transporte y el dispositivo en ese orden, cambiando un tramo cada vez.
Una llamada que se entrecorta, una descarga que se arrastra y una subida que se congela a mitad de camino son tres quejas distintas bajo una misma etiqueta. Decidir cuál persigue antes de medir nada ahorra el resto de la investigación. Después cambie un tramo del camino cada vez y repita la misma tarea.
El orden siguiente se aleja de la tarea, porque el túnel no puede aportar ancho de banda que falta por debajo.
Decida qué significa lento antes de medir
Una velocidad baja y constante, una latencia alta con picos bruscos y una transferencia que se detiene en seco a un tamaño fijo no son variaciones de una sola avería. Cada una apunta a un tramo distinto: el rendimiento, el propio camino o un límite de tamaño de paquete. Elija la tarea que de verdad le molesta y úsela como referencia, porque una prueba de velocidad mide una transferencia masiva que puede comportarse de forma muy distinta a una videollamada. Anote el extremo, el protocolo, la hora del día y el número que le importa.
Sin ese registro, cada comparación posterior se convierte en una discusión sobre impresiones.
Compruebe primero la red de acceso
Pause sus propias transferencias grandes y luego mida el enlace local antes de que intervenga el túnel. Compare con una tarea inofensiva y siga el procedimiento de kill switch del cliente en lugar de desactivar varias protecciones a la vez, y mantenga el mismo destino en ambas ejecuciones. Un proveedor de pruebas de velocidad puede asignarle otro servidor de medición en cuanto cambie su ubicación visible, lo que convierte la comparación en una prueba de dos servidores distintos.
ping -c 20 192.168.50.1
ping -c 20 198.51.100.7
curl -o /dev/null -w "%{time_starttransfer} %{speed_download}\n" https://speed.example.net/10mb.bin
Si la línea base ya es mala, el trabajo pertenece al Wi-Fi, a la demanda del router o al servicio de acceso. Una prueba por cable o una posición fija cerca del punto de acceso separa un enlace de radio débil de un enlace de subida congestionado. Nada de lo que hace el túnel añadirá capacidad que la línea de acceso no entrega.
Cambie la salida y luego el transporte
Mantenga fijos el dispositivo, la red y el protocolo y pruebe un segundo extremo. Elija una ciudad verosímil de la lista de ubicaciones, pero no suponga que la etiqueta más cercana significa la mejor ruta. Si una salida va lenta y las demás bien, su host o camino merece la investigación; si todas las salidas van lentas en un dispositivo mientras otro dispositivo va bien, el cliente es el mejor sospechoso.
Donde el servicio ofrece ambos perfiles, compare OpenVPN por UDP con OpenVPN por TCP. UDP es el punto de partida habitual para el trabajo interactivo, mientras que TCP puede ayudar en una red de acceso que no deja pasar en absoluto el tráfico UDP. Un túnel TCP recupera las pérdidas retransmitiendo dentro del flujo, y por eso puede sentirse más lento en un enlace que descarta paquetes, y las notas de solución de problemas de rendimiento de OpenVPN cubren el mismo compromiso antes de que ajuste nada más. Editar la palabra "udp" a "tcp" en un perfil no puede crear un receptor que el servidor nunca abrió.
Guarde el perfil que ayuda antes de probar el siguiente cambio. De lo contrario, una regresión posterior le deja adivinando qué edición produjo la mejora.
Lea el dispositivo y el síntoma juntos
Observe la carga del procesador durante la transferencia y no después, porque el costo del cifrado crece con el tráfico y un router pequeño que sirve a un hogar es una máquina distinta de un portátil que ejecuta su propio cliente. Otra VPN, una máquina virtual o un filtro de red pueden estar en el mismo camino y llevarse una parte del tráfico. Mantenga el software actualizado sin quitar comprobaciones de autenticación ni un kill switch para que una prueba comparativa se vea mejor. Si las peticiones pequeñas tienen éxito y las subidas grandes se atascan a un tamaño consistente, la comprobación de la MTU es la siguiente parada.
ping -M do -s 1400 -c 3 198.51.100.7
ip link show dev tun0 | grep -o "mtu [0-9]*"
Cuando el túnel se reinicia repetidamente, arregle las desconexiones antes de interpretar cualquier número de rendimiento, porque un túnel que se reconecta mide el saludo y no el camino. Repita la tarea original después de cada cambio y guarde el resultado. Una prueba de velocidad más rápida que sigue rompiendo la llamada no ha resuelto la queja con la que empezó.