Un router con una etiqueta Wi-Fi de 3,000 Mbps todavía puede mover tráfico cifrado a una fracción de esa cifra, y ninguna de las dos cifras es deshonesta. La calificación de radio describe la mejor modulación posible del enlace inalámbrico que admite el chipset; la cifra de VPN describe con qué rapidez un solo dispositivo puede empujar paquetes cifrados a través de la CPU del router y fuera de tu circuito de acceso. Son capas distintas, tamaños de paquete distintos y métodos de medición distintos. Trata el número de la caja como un techo que nadie alcanza, no como una previsión de la velocidad de tu túnel.

Paso 1: Traza las cuatro capas que limitan la cifra

Casi todas las quejas de router lento con las que he trabajado caen en uno de cuatro niveles: el enlace inalámbrico, la velocidad de acceso WAN, la ruta de reenvío (NAT, cortafuegos, seguimiento de conexiones) o la ruta criptográfica de la VPN. Se apilan, y el nivel más lento fija el resultado. Una velocidad Wi-Fi anunciada solo habla del primer nivel, y habla de él con generosidad.

Esa cifra sale de los flujos multiplicados por el ancho de canal y por la modulación más alta que el chipset puede negociar. Una radio 2x2 a 5 GHz con 80 MHz y 1024-QAM se anuncia cerca de 1,200 Mbps, pero el Wi-Fi es un medio compartido y semidúplex: los clientes se turnan, las retransmisiones y el tráfico de gestión queman tiempo de aire, y TCP añade su propia sobrecarga. Un cliente que negocia la velocidad máxima en condiciones ideales suele medir muy por debajo de la mitad, y menos aún en cuanto aparecen redes vecinas.

SymptomTier to suspect first
Wired clients are slow tooWAN access or forwarding path
Only Wi-Fi clients are slowRadio, airtime, or channel width
One stream is slow, four parallel streams add upPer-connection CPU path, not the link
Every stream is slow and one core sits at 100%Crypto path
Fast to LAN hosts, slow to the internetWAN, not the tunnel

Si la tabla apunta a la radio, arregla primero el lado inalámbrico: banda, ancho de canal, distancia. Si apunta por debajo de la radio, importan los cuatro pasos siguientes, y ninguna compra de antenas lo cambiará.

Paso 2: Toma una línea base por cable antes de tocar la radio

Pon el portátil en Ethernet y mide primero la ruta sin el túnel, porque eso te da un denominador. Ejecuta la herramienta de caudal en el extremo opuesto, en el VPS o servidor doméstico que termina la VPN, y apunta el cliente a su dirección pública para que el tráfico cruce tu router y tu circuito de acceso.

# on the far host (VPN endpoint)
iperf3 -s

# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30

# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4

Dos cifras de ese bloque responden preguntas distintas. Un solo flujo muestra el techo por conexión, que incluye el comportamiento de la ventana TCP y cualquier modelado por flujo en la ruta. Cuatro flujos muestran si el enlace tiene capacidad que no aprovechas, porque los flujos paralelos pueden llenar una tubería que uno solo no llena.

Mantenlo honesto: mismo equipo, hora del día y duración, sin nada más transmitiendo en casa. Una transferencia masiva de treinta segundos es la unidad correcta aquí, y RFC 6349, el marco para probar el caudal TCP, se basa en ese razonamiento, porque las ráfagas cortas y las peticiones pequeñas halagan a un enlace. Anota la línea base antes de cambiar nada.

Paso 3: Ejecuta la misma prueba a través del túnel

Ahora repítelo contra la dirección del túnel del extremo remoto, con el mismo cliente, duración y número de flujos, con el túnel levantado y sin otro tráfico. La ratio entre los dos resultados te dice qué cuestan el cifrado y la encapsulación en ese hardware; la cifra absoluta te dice si basta para el trabajo.

Mira los contadores mientras corre la transferencia. En WireGuard, wg show informa de los bytes transferidos por par; en OpenVPN, un archivo de estado escrito a intervalos te da la misma vista.

watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status

Si la cifra del túnel se acerca a la línea base por cable, la VPN no es tu cuello de botella y puedes dejar de culparla. Si es una fracción de la base, la pérdida ocurrió dentro de la ruta de cifrado y reenvío del router, y el paso siguiente te dice qué parte.

Una advertencia: en cuanto cambia la IP de salida, algunos servicios de prueba de velocidad eligen en silencio otro servidor de medición, así que acabas comparando dos destinos. Fija tú mismo la dirección del servidor.

Paso 4: Lee la CPU como una ruta, no como un promedio

Un router que muestra un 30 por ciento de CPU total todavía puede estar saturado: el trabajo de un túnel suele caer en un núcleo, una cola de interrupciones o un hilo del núcleo, así que el promedio esconde el techo. Mira las cifras por núcleo y de softirq en lugar del medidor del panel.

mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfo

Tres cosas importan en esa salida. Un solo núcleo clavado cerca del 100 por ciento mientras los demás están inactivos apunta a un límite por conexión. Un %soft alto o un ksoftirqd ocupado en una CPU apunta a procesamiento de paquetes en el lado de recepción que no se reparte entre colas. Y que falte el indicador aes significa que la CPU no tiene instrucciones AES, así que el cifrado simétrico va en software y cuesta mucho más por paquete.

La implementación también importa. Una instancia tradicional de OpenVPN en espacio de usuario procesa los paquetes de un túnel en gran parte en un solo lugar, así que una caja rápida multinúcleo puede comportarse como una de un solo núcleo para ese túnel. WireGuard en el núcleo reparte el trabajo entre CPU, y la descarga del canal de datos de OpenVPN también mueve el manejo de paquetes al núcleo, pero solo en compilaciones y plataformas que lo admiten. Una afirmación de aceleración por hardware en la página de marketing no es prueba de que la ruta de código que ejecutas la use.

Paso 5: Decide qué cambiar, en ese orden

Baja por esta lista y detente en la primera línea que sea cierta, porque cambiar cualquier cosa por debajo no moverá la cifra.

1. El caudal directo por cable está por debajo de lo que pagas: habla con el proveedor, porque el túnel no puede crear capacidad que el circuito de acceso no entrega. 2. El directo por cable está bien pero un núcleo se clava durante la prueba del túnel: la ruta criptográfica del router es el límite. 3. La CPU está inactiva pero el túnel es lento: revisa la MTU y la fragmentación, y luego la capacidad del propio extremo remoto. 4. Solo son lentos los clientes Wi-Fi: cambia de banda o de ancho de canal, y acepta que la velocidad anunciada nunca fue una cifra de VPN.

Cuando el router es de verdad el límite, las opciones honestas son un aparato con instrucciones AES y una ruta de reenvío más rápida, un túnel en el lado del núcleo como WireGuard en lugar de uno en espacio de usuario, o mover el cliente al propio aparato para que el router deje de cifrar. Apagar el cifrado autenticado para ganar una prueba de rendimiento no es una de ellas; cambia una propiedad de seguridad por una cifra que aún no coincidirá con la caja.

Antes de comprar nada, vuelve a ejecutar los pasos 2 y 3 en el aparato nuevo con el mismo servidor y duración, y luego compara ratios en lugar de picos.

Artículos relacionados