Pruebas de calidad del VPN de oficina: medir latencia, jitter y pérdida para demostrar problemas del ISP

Cómo luce realmente una “buena calidad de VPN”

La mayoría de los equipos solo notan la calidad del VPN cuando es mala. Eso es un error. Define qué significa “bueno”, o pasarás
la vida debatiendo sensaciones.

Para un VPN oficina→datacenter (o oficina→cloud) que transporta tráfico interactivo (VoIP, RDP, VDI, SSH), estos son
los objetivos prácticos que uso:

• Latency (RTT): Estable es mejor que bajo. Menos de 50 ms RTT es excelente para la misma región; menos de 100 ms es usable; las ráfagas son el enemigo.
• Jitter: Menos de 5–10 ms suele ser suficiente; por encima de 20–30 ms la voz empieza a sonar como un robot con dolor de garganta.
• Packet loss: Menos de 0.1% suele ser invisible; 0.5% empieza a causar impacto real en aplicaciones; 1% es un impuesto a la productividad; 2% es una crisis.
• Reordering: Normalmente cercano a cero; cuando aparece, TCP puede parecer “lento” incluso cuando hay ancho de banda disponible.
• MTU sanity: Un MTU correcto extremo a extremo evita fragmentación/blackholes; un MTU incorrecto puede imitar “lentitud aleatoria”.
• Throughput: Para flujos masivos, importa el throughput sostenido bajo carga, no los picos de “speed test”.

Los VPN complican la medición porque el túnel añade overhead, cambia los tamaños de paquete y a menudo desplaza el tráfico a
una ruta distinta a la del tráfico de Internet plano. El resultado: tu argumento de “el ISP está bien” muere en cuanto te das cuenta de que
solo probaste hacia un CDN público, no a través del VPN hacia lo que realmente usan los usuarios.

Datos interesantes y breve historia (porque explica el desastre actual)

• Hecho 1: La clásica herramienta ping data de principios de los 80 y se inspiró en el sonar; fue diseñada para comprobar alcanzabilidad, no para analizar rendimiento.
• Hecho 2: “Jitter” se volvió una métrica cotidiana en gran medida porque la voz/video en tiempo real pasó de circuitos conmutados a redes conmutadas por paquetes.
• Hecho 3: IPsec (una tecnología común de site-to-site VPN) se estandarizó en los 90, cuando los enlaces típicos de Internet eran mucho más lentos y NAT no estaba en todas partes.
• Hecho 4: WireGuard es relativamente reciente (mediados/finales de los 2010) y es intencionalmente pequeño; menos opciones, menos trampas y en general mejor rendimiento base.
• Hecho 5: El throughput de TCP está limitado por RTT y pérdida; por eso un enlace de alta capacidad puede todavía “sentirse lento” sobre una ruta con pérdida o jitter.
• Hecho 6: Muchos enlaces de banda ancha de consumo e incluso “corporativos” confían en oversubscription; la congestión depende a menudo de la hora del día y no aparece en una sola prueba.
• Hecho 7: Bufferbloat (almacenamiento excesivo en buffers de dispositivos de red) se discutió ampliamente a finales de los 2000 y puede causar enormes picos de latencia bajo subida/descarga.
• Hecho 8: ECMP (equal-cost multipath) en redes de proveedores puede causar reordenamiento de paquetes; la encapsulación VPN a veces cambia cómo se hace el hashing de los flujos entre rutas.
• Hecho 9: Algunas redes todavía tratan a ICMP de forma distinta (rate-limit, deprioritize); por eso debes corroborar ping con otros métodos antes de declarar victoria.

Broma 1: Lo bueno del “pérdida de paquetes intermitente” es que enseña atención plena. No puedes aferrarte a expectativas cuando tus paquetes no se aferran a la existencia.

Las métricas que importan (y las que mienten)

Latency: mide distribuciones, no un solo número

La latencia media oculta el dolor. Los usuarios sienten las ráfagas. Captura min/avg/max y percentiles si tu herramienta lo permite.
Cuando alguien dice “el VPN está lento”, suele describir variabilidad, no un promedio estable.

Jitter: la métrica de “calidad” para tráfico en tiempo real

El jitter es la variación en el retardo. VoIP y videoconferencias pueden hacer un pequeño buffering; una vez que el jitter supera el buffer,
el audio se corta y el video se congela. Los túneles VPN pueden amplificar el jitter cuando los appliances de cifrado están saturados de CPU o cuando
las colas del ISP se llenan bajo carga.

Loss: el asesino silencioso del throughput

TCP interpreta la pérdida como congestión y reduce la ventana. Una pequeña cantidad de pérdida aleatoria puede hundir el throughput en rutas con RTT largo.
Para VPNs de oficina, la pérdida también es el principal impulsor de “RDP se siente pegajoso”, “Teams se congela” y “la copia de archivos se queda colgada”.

Throughput: prueba ambas direcciones e incluye flujos concurrentes

Un flujo no es la realidad. Muchos gateways VPN funcionan bien con un stream de iperf y se desmoronan con diez. También prueba la subida:
las oficinas a menudo saturan el upstream durante backups, escaneos o “alguien envió un archivo de 2 GB a toda la empresa”.

MTU/fragmentación: la clásica trampa de los VPN

La encapsulación VPN añade overhead. Si tu MTU efectivo de ruta baja y PMTUD está bloqueado o roto, los paquetes grandes quedan en blackhole.
Los síntomas parecen “algunos sitios funcionan, otros no” o “SSH está bien pero la transferencia de archivos se cuelga”.
Los problemas de MTU son aburridos, comunes y absolutamente vale la pena probarlos temprano.

Lo que miente: pruebas de velocidad, pings aislados y “está verde en el dashboard”

Las pruebas de velocidad públicas a menudo alcanzan nodos CDN cercanos por rutas bien peeradas que tu tráfico VPN nunca usa. Un ping aislado a las 9:03 AM no prueba casi nada. Y los dashboards muestran verde cuando miden alcanzabilidad, no experiencia.

Una cita (idea parafraseada): John Allspaw ha argumentado que la fiabilidad viene de entender los sistemas en condiciones reales, no de culpar a individuos.

Guía rápida de diagnóstico

Cuando el VPN de oficina “se siente mal”, no tienes tiempo para un proyecto de investigación de una semana. Empieza con los discriminadores más rápidos: ¿el cuello de botella está en la LAN/Wi‑Fi local, la última milla del ISP, el gateway VPN o la red aguas arriba?

Primero: confirma el alcance y elige dos endpoints

• Elige un cliente: una máquina cableada en la LAN de la oficina (no Wi‑Fi a menos que la queja sea Wi‑Fi).
• Elige dos objetivos: (1) la IP pública del gateway VPN de la oficina, (2) un host interno del lado VPN (un jump box o servidor).
• Decide el marco temporal: “ahora mismo” más “repetir durante las horas pico”.

Segundo: divide la ruta en segmentos

• Cliente → router de oficina: prueba problemas de LAN/Wi‑Fi.
• Cliente → IP pública del gateway VPN: prueba la ruta del ISP hasta el gateway.
• Cliente → host interno a través del VPN: prueba el túnel + lado remoto.
• Gateway VPN → host interno: prueba la red remota si puedes ejecutar tests allí.

Tercero: ejecuta tres pruebas rápidas

1. Ping con timestamps e intervalos (baseline de latencia/jitter/pérdida).
2. MTR (pérdida/latencia por salto; bueno para escalar, no para dogma).
3. Una corrida corta de iperf3 en ambas direcciones (throughput + pérdida bajo carga).

Cuarto: provoca el problema (con cuidado)

Si la calidad colapsa solo cuando el enlace está ocupado, necesitas una prueba de carga controlada. Satura el upstream brevemente,
mide la latencia bajo carga y expondrás bufferbloat, bugs de shaping o un appliance VPN que entra en pánico cuando tiene que hacer trabajo real.

Quinto: decide dónde enfocarte

• Mal hacia el gateway público: ISP/circuito local, peering o congestión de última milla.
• Bien hacia el gateway pero mal a través del túnel: CPU del gateway VPN, MTU, ajustes de cifrado o lado remoto.
• Bien desde cableado pero mal desde Wi‑Fi: deja de culpar al ISP; arregla RF, roaming o drivers del cliente.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas tareas asumen clientes/servidores Linux. Si estás en macOS o Windows, aún puedes aplicar la lógica; cambian los nombres de comandos, la física no.

Task 1: Identificar la interfaz activa y la gateway (evita probar la ruta equivocada)

cr0x@server:~$ ip route show
default via 192.0.2.1 dev eno1 proto dhcp src 192.0.2.50 metric 100
192.0.2.0/24 dev eno1 proto kernel scope link src 192.0.2.50

Qué significa: Tu cliente sale por eno1 hacia 192.0.2.1.
Si alguien ejecuta pruebas sobre Wi‑Fi mientras los usuarios están en cable (o al revés), estarás depurando fan fiction.

Decisión: Si la ruta es incorrecta, arréglala antes de probar. Si no, procede.

Task 2: Baseline de la LAN: hacer ping al gateway por defecto

cr0x@server:~$ ping -c 20 -i 0.2 192.0.2.1
PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.
64 bytes from 192.0.2.1: icmp_seq=1 ttl=64 time=0.362 ms
64 bytes from 192.0.2.1: icmp_seq=2 ttl=64 time=0.401 ms
...
20 packets transmitted, 20 received, 0% packet loss, time 3804ms
rtt min/avg/max/mdev = 0.331/0.389/0.471/0.038 ms

Qué significa: Este es tu piso. Si ves pérdida o jitter de varios milisegundos aquí en una red cableada,
el ISP no es tu primer problema.

Decisión: Si el ping de la LAN es inestable, revisa puertos de switch, duplex, errores de NIC, Wi‑Fi o congestión local.

Task 3: Revisar contadores de NIC por drops y errores

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    987654321  123456      0       2       0       123
    TX:  bytes packets errors dropped carrier collsns
    876543210  112233      0       0       0       0

Qué significa: Unos pocos drops pueden estar bien; errores/drops crecientes durante las quejas es un indicio fuerte.

Decisión: Si los errores suben, reemplaza el cable, corrige mismatch de duplex, actualiza drivers/firmware o cambia de puerto.

Task 4: Confirmar selección de ruta del VPN (sorpresas de split tunnel son comunes)

cr0x@server:~$ ip route get 10.10.20.15
10.10.20.15 dev wg0 src 10.200.0.2 uid 1000
    cache

Qué significa: El tráfico hacia 10.10.20.15 va por wg0 (el VPN).
Si va por la ruta por defecto en su lugar, no estás probando el túnel en absoluto.

Decisión: Arregla routing/policy routing antes de diagnosticar “rendimiento del VPN”.

Task 5: Medir RTT, proxy de jitter (mdev) y pérdida a la IP pública del gateway VPN

cr0x@server:~$ ping -c 50 -i 0.2 203.0.113.10
PING 203.0.113.10 (203.0.113.10) 56(84) bytes of data.
64 bytes from 203.0.113.10: icmp_seq=1 ttl=52 time=18.9 ms
64 bytes from 203.0.113.10: icmp_seq=2 ttl=52 time=19.2 ms
...
50 packets transmitted, 50 received, 0% packet loss, time 10052ms
rtt min/avg/max/mdev = 18.5/19.4/28.7/1.8 ms

Qué significa: mdev no es jitter perfecto, pero es un buen indicador rápido.
El pico máximo (28.7 ms) es notable; si esto sube a 200+ ms durante las quejas, probablemente estés viendo congestión.

Decisión: Si aparece pérdida aquí, enfócate en la ruta del ISP antes de culpar a los ajustes de cripto del VPN.

Task 6: MTR a la IP pública del gateway VPN (evidencia, no teología)

cr0x@server:~$ mtr -rwzc 200 203.0.113.10
Start: 2025-12-28T09:15:02+0000
HOST: office-client                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.0.2.1                        0.0%   200    0.5   0.6   0.4   1.2   0.1
  2.|-- 198.51.100.1                     0.0%   200    7.8   8.1   6.9  20.3   1.5
  3.|-- 198.51.100.34                    1.5%   200   12.1  12.8  10.2  45.7   4.2
  4.|-- 203.0.113.10                     0.5%   200   19.6  21.4  18.4  80.2   6.9

Qué significa: La pérdida en saltos intermedios puede ser rate-limiting de ICMP. La clave es si la pérdida
persiste hasta el hop final. Aquí, 0.5% de pérdida hacia el destino es lo suficientemente real como para perjudicar la experiencia VPN.

Decisión: Si la pérdida del destino coincide con las ventanas de queja, empieza a armar un paquete de escalamiento al ISP.

Task 7: Comparar con un objetivo “control” fuera del VPN (prueba que sea específico de la ruta)

cr0x@server:~$ ping -c 50 -i 0.2 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=9.7 ms
...
50 packets transmitted, 50 received, 0% packet loss, time 10043ms
rtt min/avg/max/mdev = 9.4/9.9/12.5/0.4 ms

Qué significa: Internet en general puede verse bien mientras la ruta hacia tu gateway VPN está enferma.
Esto es exactamente por qué pruebas el endpoint real del VPN.

Decisión: Si el control está limpio pero el gateway no, presiona al ISP sobre routing/peering hacia ese destino.

Task 8: Verificar MTU hacia un host interno (encuentra blackholes temprano)

cr0x@server:~$ ping -M do -s 1372 -c 3 10.10.20.15
PING 10.10.20.15 (10.10.20.15) 1372(1400) bytes of data.
1380 bytes from 10.10.20.15: icmp_seq=1 ttl=63 time=24.3 ms
1380 bytes from 10.10.20.15: icmp_seq=2 ttl=63 time=24.8 ms
1380 bytes from 10.10.20.15: icmp_seq=3 ttl=63 time=25.1 ms

--- 10.10.20.15 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

Qué significa: -M do prohíbe la fragmentación. Si esto falla, tu MTU efectivo es más pequeño de lo que crees, y PMTUD podría no estar funcionando.

Decisión: Si falla, reduce el MTU del túnel (o aplica MSS clamp) y vuelve a probar hasta que pase consistentemente.

Task 9: Detectar ruptura de PMTUD (clásico “funciona para pequeño, falla para grande”)

cr0x@server:~$ tracepath 10.10.20.15
 1?: [LOCALHOST]                      pmtu 1500
 1:  10.200.0.1                        4.123ms
 2:  10.10.20.15                      24.910ms reached
     Resume: pmtu 1420 hops 2 back 2

Qué significa: MTU de ruta descubierto como 1420. Eso es plausible para algunos escenarios de overhead VPN.
Si tus interfaces están en 1500 y confías en PMTUD pero ICMP está bloqueado en algún punto, puedes tener blackholes.

Decisión: Ajusta el MTU del VPN al PMTU descubierto (con margen), o aplica TCP MSS clamping en el edge.

Task 10: Ejecutar iperf3 a través del VPN (flujo único)

cr0x@server:~$ iperf3 -c 10.10.20.15 -t 15
Connecting to host 10.10.20.15, port 5201
[  5] local 10.200.0.2 port 45322 connected to 10.10.20.15 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  6.25 MBytes  52.4 Mbits/sec    0   1.12 MBytes
[  5]   1.00-2.00   sec  6.12 MBytes  51.3 Mbits/sec    2   0.96 MBytes
...
[  5]  14.00-15.00  sec  3.10 MBytes  26.0 Mbits/sec   18   0.42 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-15.00  sec  67.2 MBytes  37.6 Mbits/sec  61             sender
[  5]   0.00-15.00  sec  66.5 MBytes  37.2 Mbits/sec                  receiver

Qué significa: Retransmisiones (Retr) y bitrate decreciente apuntan a pérdida, congestión o
una ruta limitada por CPU. Un camino VPN sano no debería mostrar retransmisiones escalando rápidamente en una prueba corta y limpia.

Decisión: Si las retransmisiones suben, correlaciona con pérdida en ping e investiga ISP o MTU/queueing del túnel.

Task 11: Ejecutar iperf3 en dirección inversa (descarga puede estar bien mientras la subida es un desastre)

cr0x@server:~$ iperf3 -c 10.10.20.15 -R -t 15
Connecting to host 10.10.20.15, port 5201
Reverse mode, remote host 10.10.20.15 is sending
[  5] local 10.200.0.2 port 45330 connected to 10.10.20.15 port 5201
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-15.00  sec  120 MBytes  67.1 Mbits/sec   3             sender
[  5]   0.00-15.00  sec  119 MBytes  66.5 Mbits/sec                 receiver

Qué significa: El reverse está limpio; el forward no lo estaba. Eso es una pista fuerte de que el upstream de la oficina está
congestionado o mal configurado, o que la cola de egress está inflada.

Decisión: Enfócate en la capacidad upstream, QoS/SQM o en un posible daño del ISP en subida.

Task 12: Medir latencia bajo carga (chequeo de bufferbloat)

cr0x@server:~$ (ping -i 0.2 -c 50 203.0.113.10 | tail -n 3) & iperf3 -c 10.10.20.15 -t 15 > /dev/null; wait
50 packets transmitted, 50 received, 0% packet loss, time 10041ms
rtt min/avg/max/mdev = 19.0/85.4/312.7/58.1 ms

Qué significa: El RTT medio se cuadruplicó y el máximo llegó a 312 ms mientras se empujaba tráfico. Eso es clásico
bufferbloat o saturación de colas. Los usuarios experimentan esto como “el VPN está bien hasta que hacemos algo”.

Decisión: Implementa smart queue management (SQM) en el edge, configura shaping ligeramente por debajo de la tasa del ISP, o consigue más ancho de banda upstream.

Task 13: Revisar MTU y estadísticas de la interfaz VPN (drops a nivel túnel)

cr0x@server:~$ ip -s link show dev wg0
5: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
    RX:  bytes packets errors dropped  missed   mcast
    12345678   54321      0      45       0       0
    TX:  bytes packets errors dropped carrier collsns
    23456789   65432      0      12       0       0

Qué significa: Drops en la interfaz de túnel pueden indicar queueing local, policing o ráfagas que exceden lo que la ruta puede manejar.

Decisión: Si los drops suben durante picos, configura shaping, revisa QoS y comprueba saturación de CPU en el endpoint VPN.

Task 14: Observar estadísticas de WireGuard en runtime (freshness de handshake y transfer)

cr0x@server:~$ sudo wg show
interface: wg0
  public key: zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz=
  private key: (hidden)
  listening port: 51820

peer: yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy=
  endpoint: 203.0.113.10:51820
  allowed ips: 10.10.0.0/16
  latest handshake: 28 seconds ago
  transfer: 1.23 GiB received, 2.10 GiB sent
  persistent keepalive: every 25 seconds

Qué significa: Los handshakes están ocurriendo; el túnel está vivo. Si el latest handshake se vuelve stale
o flapea, podrías estar golpeando timeouts de NAT o filtrado upstream.

Decisión: Si los handshakes caen durante inactividad, habilita keepalive o arregla timeouts de NAT/firewall.

Task 15: Confirmar salud de SA de IPsec (si usas IPsec)

cr0x@server:~$ sudo ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.8, Linux 6.5.0, x86_64):
  uptime: 2 hours, since Dec 28 07:12:03 2025
Connections:
office-to-dc:  192.0.2.0/24 === 10.10.0.0/16
Security Associations (1 up, 0 connecting):
office-to-dc[1]: ESTABLISHED 12 minutes ago, 198.51.100.10[CN=office]...203.0.113.10[CN=dc]
office-to-dc{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c1a2b3c4_i c4b3a2c1_o
office-to-dc{1}:   192.0.2.0/24 === 10.10.0.0/16

Qué significa: SA está establecida. Esto no prueba calidad, pero descarta churn de negociación
que puede causar congelamientos intermitentes.

Decisión: Si las SA se rekeyean con demasiada frecuencia o flapean, ajusta lifetimes, manejo de NAT-T o pinholes de firewall.

Task 16: Capturar un breve trazado de paquetes para probar fragmentación o retransmisiones

cr0x@server:~$ sudo tcpdump -ni wg0 -c 20 -vv 'host 10.10.20.15 and (tcp or icmp)'
tcpdump: listening on wg0, link-type RAW (Raw IP), snapshot length 262144 bytes
09:18:41.120001 IP (tos 0x0, ttl 64, id 12345, offset 0, flags [DF], proto ICMP (1), length 1420)
    10.200.0.2 > 10.10.20.15: ICMP echo request, id 3011, seq 1, length 1400
09:18:41.144210 IP (tos 0x0, ttl 63, id 54321, offset 0, flags [DF], proto ICMP (1), length 1420)
    10.10.20.15 > 10.200.0.2: ICMP echo reply, id 3011, seq 1, length 1400
...

Qué significa: Ves DF set y replies exitosos a tamaño 1400—bueno para MTU. Para TCP buscarías retransmisiones y reducción de ventana.

Decisión: Usa trazas con moderación: lo suficiente para probar una hipótesis, no tanto como para ahogarte en paquetes.

Tres micro-historias corporativas (todas dolorosamente plausibles)

Incidente causado por una suposición errónea: “Ping está limpio, así que el ISP es inocente”

Una empresa mediana tenía un site-to-site VPN desde la sede a una VPC en la nube. Helpdesk reportó que sesiones RDP
se congelaban y luego se ponían al día en ráfagas. El equipo de red ejecutó ping al gateway VPN. 0% de pérdida, ~12 ms.
Declararon el ISP como correcto y siguieron culpando a las actualizaciones de Windows.

El congelamiento continuó. Alguien finalmente corrió una prueba que realmente coincidía con la carga de trabajo: subida sostenida a través
del VPN mientras medían latencia al gateway. RTT saltó de ~12 ms a ~280 ms y se mantuvo. El VPN no estaba “caído.” Simplemente estaba atrapado detrás de un océano de buffering en la cola upstream del router de la oficina.

La suposición errónea fue sutil: “Si ping está bien ahora, el enlace está bien.” En realidad, el ping en reposo mide el camino feliz. El negocio sufría bajo carga. Una sola subida de cámara, un backup de la nube o incluso una gran pantalla compartida en Teams bastó para llenar la cola e introducir segundos de retardo.

Arreglarlo no fue glamoroso. Implementaron smart queue management en el edge y limitaron la subida ligeramente por debajo de la tasa real del ISP. RDP volvió a ser aburrido. El ISP no cambió nada; la oficina sí.

Optimización que salió mal: “Habilitamos offload por hardware y lo empeoramos”

Otra empresa desplegó nuevos appliances de borde y activó todas las funciones de aceleración disponibles: checksum offload, GRO/LRO y algún “VPN fast path” específico del proveedor. Los benchmarks de throughput lucían bien en laboratorio.
En producción, las llamadas VoIP sobre el VPN empezaron a perder palabras. El túnel se mantenía arriba y las transferencias masivas eran rápidas,
así que el problema se desestimó como “Teams siendo Teams”.

La pista vino del jitter. Bajo carga moderada, la latencia no era alta en promedio, pero era muy variable—microráfagas y batching de paquetes.
Los offloads estaban coalesciendo paquetes y entregándolos en bloques. Los flujos interactivos odian los bloques.
Los usuarios lo percibían como tartamudeo y conversaciones con solapamientos incómodos.

La “optimización” mejoró la métrica que a alguien le importaba (throughput pico) y degradó la métrica que importaba a los usuarios (latencia consistente). Desactivar algunos offloads en las interfaces WAN/VPN redujo ligeramente el throughput pero estabilizó el jitter. VoIP se estabilizó de inmediato.

A nadie le gusta la conclusión: a veces compras un coche más rápido y luego te das cuenta de que solo conduces en tráfico. Optimiza para estabilidad de latencia primero. El ancho de banda rara vez es el factor limitante para el dolor humano en VPN.

Práctica aburrida pero correcta que salvó el día: “Mediciones en series temporales con un registro de cambios”

Un equipo global tenía una queja recurrente: “Cada martes por la tarde el VPN es terrible.” La gente tenía teorías:
mantenimiento del ISP, problemas del proveedor cloud, erupciones solares y una sugerencia memorable sobre un switch encantado.

El SRE de turno hizo lo menos emocionante posible. Configuró pruebas programadas cada cinco minutos desde un host cableado en la oficina: ping y MTR al gateway VPN, además de una corrida corta de iperf3 a un servidor de prueba interno. Guardaron las salidas crudas con timestamps y las alinearon con un simple change log: cambios de circuito WAN, cambios de políticas de firewall, upgrades de endpoints y eventos de la oficina.

Tras dos semanas, el patrón fue claro. Pérdida y jitter subían al mismo tiempo cada semana, pero solo en la dirección upstream. Se correlacionó con un job recurrente de backup offsite que saturaba la subida. El job no era nuevo; el dataset creció y finalmente cruzó el umbral donde las colas colapsaron.

Movieron la ventana del backup, limitaron la tasa y pusieron SQM básico. Los martes por la tarde se calmaron. Lo mejor: no necesitaron heroísmos, solo recibos. La evidencia también previno una escalada inútil al ISP que habría terminado con “no se reproduce el problema.”

Broma 2: La estrategia de red más fiable es “mide primero.” La segunda más fiable es “deja de programar backups a las 2 PM.”

Listas de verificación / plan paso a paso

Paso a paso: establecer una prueba de calidad de VPN repetible

1. Elige un cliente de prueba estable. Cableado, no en una docking station con una NIC USB inestable.
   Si debes probar Wi‑Fi, hazlo intencionalmente y documenta que es Wi‑Fi.
2. Elige objetivos estables.
   Un objetivo público: la IP pública del gateway VPN. Un objetivo privado: un host interno accesible solo vía VPN.
3. Define tres ventanas de prueba.
   Mañana tranquila, horas pico y la “hora de la queja” que todos mencionan.
4. Ejecuta pruebas base.
   Ping al gateway (LAN), ping al endpoint público del VPN, ping al host interno vía VPN, MTR al endpoint VPN, comprobaciones de MTU.
5. Ejecuta pruebas de carga en ráfagas cortas.
   iperf3 forward y reverse por 15–30 segundos. No fundas enlaces de producción por minutos.
6. Repite y guarda salidas crudas.
   Capturas de pantalla no son datos. Conserva salidas de texto con timestamps.
7. Correlaciona con métricas de dispositivos.
   CPU del gateway VPN, drops en interfaces, utilización del WAN y contadores de shaping/policing.
8. Toma una decisión.
   Si el deterioro aparece antes del túnel (hacia IP pública), escala al ISP. Si aparece solo a través del túnel,
   arregla tu configuración VPN o el lado remoto.

Checklist: antes de llamar al ISP

• Confirma que el problema ocurre desde un cliente cableado (a menos que Wi‑Fi sea la causa sospechada).
• Muestra pérdida/jitter hacia la IP pública del gateway VPN a lo largo del tiempo, no una sola prueba.
• Adjunta MTR al mismo endpoint durante periodos buenos y malos.
• Incluye evidencia de latencia bajo carga si sospechas congestión/bufferbloat.
• Confirma que MTU funciona (o documenta que la ajustaste) para que el ISP no culpe al overhead de tu túnel.
• Documenta quién, dónde, cuándo: ID de circuito, ubicación de la oficina, timestamps con zona horaria y si las pruebas fueron por VPN.

Checklist: cambios que suelen mejorar la calidad del VPN

• Habilitar o arreglar SQM en el edge de la oficina (o shapear ligeramente por debajo de la tasa del ISP).
• Corregir MTU/MSS para la ruta VPN.
• Preferir cableado para usuarios críticos del VPN; arreglar roaming de Wi‑Fi para el resto.
• Vigilar CPU y presión de interrupciones del gateway VPN durante picos; escalar o offload según corresponda.
• Separar tráfico masivo (backups, sincronizaciones grandes) del interactivo con QoS.

Errores comunes: síntoma → causa raíz → solución

• Síntoma: “El VPN está lento, pero las pruebas de velocidad son geniales.”
  Causa raíz: Las pruebas de velocidad alcanzan un CDN cercano; el tráfico VPN toma una ruta distinta, congestionada o sufre pérdida/jitter.
  Solución: Prueba hacia la IP pública del gateway VPN y hacia un host interno a través del túnel; ejecuta pruebas durante horas pico y bajo carga.
• Síntoma: “SSH funciona, pero transferencias de archivos se cuelgan; algunas apps hacen timeout.”
  Causa raíz: MTU/PMTUD en blackhole dentro de la ruta VPN.
  Solución: Usa ping -M do con payloads grandes, usa tracepath, luego baja el MTU del túnel o aplica MSS clamp en el edge.
• Síntoma: “Teams/VoIP está entrecortado solo cuando hay subidas.”
  Causa raíz: Bufferbloat o saturación upstream en el enlace de oficina.
  Solución: Aplica SQM/shaping para upstream; mueve jobs masivos fuera de horario; aplica límites de tasa para backups.
• Síntoma: “MTR muestra pérdida en el hop 3; el ISP dice que está bien.”
  Causa raíz: Rate-limiting de ICMP en routers intermedios; no es necesariamente pérdida en data-plane.
  Solución: Enfócate en pérdida/latencia al destino final; corrobora con retransmisiones de iperf3 y síntomas de aplicaciones.
• Síntoma: “Throughput del VPN es horrible en un sitio; bien en otros.”
  Causa raíz: Enrutamiento asimétrico, diferencias de peering o un problema local en la última milla.
  Solución: Compara MTR y ping desde múltiples sitios al mismo endpoint VPN; presenta la delta al ISP.
• Síntoma: “El rendimiento empeoró tras actualizar el firewall.”
  Causa raíz: Límite de throughput por cripto, CPU pequeña, MTU mal dimensionado o offloads que causan jitter.
  Solución: Mide CPU y drops en interfaces bajo carga; ejecuta pruebas iperf3 multi-stream; desactiva offloads problemáticos; escala el appliance.
• Síntoma: “El VPN se desconecta cada pocos minutos, especialmente en idle.”
  Causa raíz: Timeouts de NAT, limpieza agresiva de estado o UDP mal manejado.
  Solución: Habilita keepalive para el túnel; ajusta timeouts UDP en firewall/NAT; confirma que el ISP no filtra UDP.
• Síntoma: “RDP va con lag, pero la copia de archivos masiva está bien.”
  Causa raíz: Jitter y microráfagas; batching/coalescing; delays de queueing que no destruyen throughput.
  Solución: Mide latencia bajo carga; ajusta SQM; reduce offloads que agrupan paquetes; prioriza tráfico interactivo.
• Síntoma: “Todo está mal solo en Wi‑Fi.”
  Causa raíz: Interferencias RF, roaming, power save o mala colocación de APs.
  Solución: Reproduce en cableado; si en cable todo está limpio, arregla Wi‑Fi—plan de canales, RSSI mínimo, band steering y actualizaciones de drivers.
• Síntoma: “Vemos pérdida, pero solo pings pequeños tienen éxito consistentemente.”
  Causa raíz: Fragmentación/MTU o policing que descarta paquetes grandes bajo carga.
  Solución: Realiza pings DF con tamaños crecientes; ajusta MTU/MSS; verifica que no haya policing mal configurado en interfaces WAN/VPN.

Cómo construir un paquete de evidencia a prueba de ISP

Los ISP no responden a “el VPN está lento.” Responden a “aquí hay pérdida y latencia hasta su handoff, aquí hay pérdida al destino, aquí hay timestamps, y aquí una comparación con una ruta de control.” Tu objetivo no es ganar una discusión.
Tu objetivo es conseguir un ticket que llegue a alguien que pueda cambiar algo.

Qué recopilar (recibos mínimos viables)

• Dos semanas de ping periódico a la IP pública del gateway VPN (o al menos varios días incluyendo ventanas “malas”).
• Corridas de MTR durante periodos buenos y malos hacia la IP pública del gateway VPN.
• Prueba de latencia bajo carga demostrando bufferbloat (ping mientras iperf3 corre) si sospechas congestión.
• Resultados de iperf3 forward y reverse a través del VPN para mostrar direccionalidad.
• Pruebas de MTU demostrando que tu túnel está configurado sensatamente (para que no te culpen por blackholes de fragmentación).
• Métricas del edge de oficina: utilización del WAN, drops en interfaces, CPU en el dispositivo VPN, timestamps alineados con quejas de usuarios.

Cómo presentarlo para que se actúe

Manténlo corto. Hazlo fácil de ojear. Los ISP están atendidos por humanos con colas. Proporciona:
identificador de circuito, IP pública, tu IP del gateway VPN, IP del cliente de prueba, timestamps con zona horaria y una frase de un párrafo
sobre el impacto (“tráfico interactivo VPN inusable 10:00–12:00 diario; pérdida hasta 1% y RTT con picos de 300 ms”).

Luego adjunta salidas crudas. Las salidas crudas importan porque son difíciles de discutir y fáciles de reenviar internamente.
También: incluye muestras “buenas” y “malas”. Si solo muestras fallos, te quedarán en el bucle de “no podemos reproducirlo”.

Actitud práctica sobre la culpa

No empieces culpando. Empieza por segmentar. “Hay pérdida desde la oficina hasta la IP pública del gateway VPN; la LAN está limpia;
tests en reverse muestran impedimento en upstream.” Así es como consigues que el ISP deje de pedirte que reinicies el modem.

Preguntas frecuentes

1) ¿Cuál es la diferencia entre latencia y jitter, en términos sencillos?

La latencia es cuánto tarda un paquete en completar un viaje de ida y vuelta. El jitter es cuánto varía ese tiempo. A los humanos les molesta más el jitter que una latencia moderada y constante.

2) ¿Cuánta pérdida de paquetes es “aceptable” para un VPN?

Para trabajo interactivo, apunta a prácticamente cero. En la práctica, menos de 0.1% suele ser aceptable; 0.5% sostenido se nota;
1%+ causará dolor recurrente y tickets de soporte.

3) ¿Puede ser engañoso ICMP ping?

Sí. Algunas redes limitan ICMP o lo tratan de forma distinta. Por eso lo corroboras con pruebas end-to-end como retransmisiones de iperf3,
latencia bajo carga y comportamiento de aplicaciones. Aun así, ping es útil si se usa con cuidado.

4) ¿Por qué el VPN empeora durante videollamadas o backups?

Porque estás llenando colas. En muchos enlaces de oficina, el upstream es limitado y los buffers son profundos. Una vez que la cola upstream se llena, la latencia se dispara. El túnel se mantiene arriba; la experiencia colapsa.

5) ¿Qué MTU debo poner para WireGuard o IPsec?

No hay un número mágico. Empieza con el valor común de WireGuard alrededor de 1420, luego valida con pings DF y tracepath. Para IPsec el overhead varía (NAT-T, algoritmos). Mide, no adivines.

6) ¿Debería correr iperf3 sobre enlaces de producción durante horario laboral?

Sí, pero en ráfagas cortas, controladas y avisando. Una prueba de 15 segundos suele ser suficiente para revelar direccionalidad,
retransmisiones y jitter bajo carga. No hagas una prueba de saturación de cinco minutos y luego te sorprendas porque la gente se queja.

7) ¿Cómo pruebo que el dispositivo VPN es el cuello de botella y no el ISP?

Muestra rendimiento limpio hacia la IP pública del gateway VPN pero degradación solo a través del túnel. Luego correlaciona con CPU del dispositivo VPN, drops en interfaces o contadores de offload/cripto durante la misma ventana.

8) Nuestro ISP dice “no se encontró problema”. ¿Qué hago ahora?

Proporciona evidencia en series temporales y segmenta la ruta. Incluye MTR/ping buenos vs malos, direccionalidad (iperf3 forward vs reverse) y resultados de latencia bajo carga. Si aún se niegan, pide escalamiento a backbone/peering o solicita un cambio de circuito—con cortesía y con recibos.

9) ¿Por qué veo pérdida en MTR en un hop intermedio pero no en el destino?

Ese hop puede estar limitando respuestas ICMP. Puede parecer “pérdida” en el reporte mientras el forwarding real está bien.
Confía más en resultados extremo a extremo que en comportamiento de ICMP por salto.

10) ¿El Wi‑Fi es realmente tan importante para la calidad del VPN?

Sí. Los VPN amplifican problemas de Wi‑Fi: retransmisiones, interrupciones por roaming y latencia variable. Siempre reproduce en cableado antes de escalar a un ISP—a menos que la queja sea explícitamente “Wi‑Fi + VPN”.

Conclusión: siguientes pasos que realmente mueven la aguja

La calidad del VPN no es misteriosa. Es medible. El truco es medir las cosas correctas, en el segmento correcto de la ruta, de una manera que sobreviva al ritual corporativo de “pruébalo”.

1. Define objetivos para latencia, jitter y pérdida, y escríbelos.
2. Instrumenta la ruta: ping/MTR programados al endpoint público del VPN y a un objetivo interno privado.
3. Prueba MTU temprano; arréglalo una vez y deja de redescubrir el mismo problema cada trimestre.
4. Mide bajo carga para exponer bufferbloat y problemas de direccionalidad.
5. Construye un paquete de evidencia con timestamps y salidas crudas; escala con segmentación, no con sensaciones.
6. Arregla lo aburrido: SQM, shaping, jobs masivos fuera de horario y dimensionado sensato del gateway VPN.

Haz esto y la próxima vez que alguien diga “el VPN está lento”, no discutirás. Señalarás un gráfico, adjuntarás un log
y elegirás la palanca correcta—ticket al ISP, shaping en el edge, cambio de MTU o aumentar capacidad VPN—con propósito.