Cómo probar la velocidad de una VPN para que las cifras signifiquen algo

Una prueba de velocidad nunca mide la VPN. Mide una ruta, y encender el túnel sustituye parte de esa ruta antes de que se mueva el primer byte. Por eso un portátil muestra una cifra sana contra un sitio y una mala contra otro sin que haya cambiado nada en ninguno de los dos lados. Lea el resultado como evidencia sobre una ruta, no como una puntuación de un producto.

Tres cosas deciden si la comparación vale algo: si ambas ejecuciones dieron con el mismo objetivo, si la red de acceso se quedó quieta y si registró el retardo junto al volumen.

Qué reescribe el túnel antes del primer byte

El cliente envuelve cada paquete en otra cabecera, así que la carga útil por paquete se reduce. El coste es por paquete y no por transferencia, lo que significa que un archivo grande necesita más paquetes que el mismo archivo enviado sin túnel. Ese sobrecoste se ve como número de paquetes, no como un ajuste visible.

Se derivan dos consecuencias. Una prueba hecha de bloques grandes nota el coste por paquete, mientras que una prueba de muchas peticiones pequeñas nota en cambio los viajes de ida y vuelta. Y si el descubrimiento de la MTU de la ruta está bloqueado en algún punto, el túnel se queda en un tamaño de paquete menor y el caudal cae por un motivo que no tiene nada que ver con los cifrados.

Puede observar el techo directamente. En Linux, pida la carga útil más grande que sobrevive sin fragmentación y repita después con el túnel encendido:

ping -M do -s 1472 -c 3 203.0.113.10

Si eso falla, baje a 1,400 y vuelva a intentarlo. Un túnel que solo transporta 1,380 bytes le está diciendo que algo aprieta más abajo en la ruta, y ningún ajuste en el cliente lo levantará.

Por qué se mueve el servidor de prueba cuando se enciende el túnel

La mayoría de las herramientas eligen un servidor cercano a partir de la dirección pública que ven. Con el túnel encendido, esa dirección pertenece al nodo de salida, así que la herramienta puede elegir un host en otra ciudad u otro país. Entonces compara dos destinos, y la diferencia entre ellos incluye la distancia desde la salida hasta el host de prueba.

Fije el servidor por nombre o ID antes de la primera ejecución y manténgalo en cada ejecución posterior. Si la herramienta no lo retiene, elija un objetivo que controle y condúzcalo usted mismo: iperf3 -c test.example.net -R -t 20 mantiene fijo el destino y le da un número que puede comparar con el de ayer.

Cambie una variable, y la capa inferior no es una sola

Lo inalámbrico es el cambio oculto habitual. La potencia de la señal se desplaza cuando se mueve el portátil y la ocupación del canal se desplaza cuando un vecino empieza una llamada, así que dos ejecuciones con diez minutos de diferencia por Wi-Fi no son repeticiones de la misma prueba. Cable, o una posición fija con el nivel de señal anotado, elimina la mayor parte de ese ruido. Anotar el nivel de señal al principio y al final de cada ejecución suele bastar para mostrar si dos ejecuciones van juntas.

La carga del dispositivo va en la misma cesta. Un cliente que cifra en un solo núcleo llega a su propio techo mucho antes que el enlace, y una sincronización en segundo plano llega antes. Vigile la CPU durante la ejecución y anote qué más estaba abierto. Los ajustes de energía también pueden morder aquí, porque un portátil con batería puede limitar el procesador mucho antes de que el enlace esté siquiera cerca de estar ocupado.

Mantenga quieta la capa inferior en lugar de promediarla. Tres ejecuciones que coinciden dicen más que diez tomadas en habitaciones distintas.

Retardo, pérdida e ICMP responden a preguntas distintas

Ping envía una sonda pequeña a una dirección fija, y muchas redes responden al ICMP con baja prioridad o lo ignoran por completo. Las respuestas ausentes describen la sonda, no los paquetes de la aplicación. Un tiempo de ida y vuelta que sube bajo carga suele significar que se está llenando una cola, no que la ruta se haya alargado.

Para saber si el túnel añade retardo, compare un objetivo con y sin él, o compare dos salidas alcanzables desde la misma red de acceso. Ejecute la sonda repetidamente y mire la dispersión, porque la media esconde justo la variación que hace inservible una llamada.

Vuelva a la tarea que se sintió lenta

Una medida que mejora mientras la llamada sigue entrecortándose ha respondido a otra cosa. Vuelva a ejecutar la tarea que inició la investigación, fuera una reunión, un recurso compartido o una sesión de escritorio remoto. Si la cifra mejoró y la tarea no, el cuello de botella estaba en algún sitio al que la prueba nunca llegó, como el servidor detrás del túnel o el enlace de subida de su lado.

Registre cada ejecución con dispositivo, red de acceso, extremo, protocolo, objetivo y hora. Una ejecución que nunca se conectó es un resultado de alcanzabilidad y no un caudal de cero, así que archívela bajo esa etiqueta en lugar de borrarla.

Una lista corta antes de la próxima comparación

Fije el objetivo y escriba por qué lo eligió. Registre el tamaño de paquete que permite la ruta, para que una caída posterior tenga explicación. Mantenga la red de acceso idéntica, anote la carga de CPU y haga tres ejecuciones antes de creer una diferencia.

Luego cambie exactamente una cosa y repita. La comparación que puede explicar vale más que la que tiene el número más grande.