VPN de oficina + VoIP: Cómo reducir jitter y latencia en túneles

El modelo mental: qué le hace un túnel VPN a la voz

VoIP es alérgico a la variabilidad. No solo al retardo—al retardo variable. Los humanos toleran mucho mejor 80 ms constantes que picos de 30–200 ms. Los túneles VPN tienden a aumentar la variabilidad por tres motivos aburridos:

• Encabezados extra y trabajo criptográfico: más bytes por paquete, más CPU por paquete y, a veces, comportamiento distinto de offload de la NIC.
• Flujos ocultos: una vez que el tráfico está cifrado, los dispositivos intermedios no pueden ver “esto es RTP” a menos que lo marques antes del cifrado y conserves las marcas.
• El encolamiento se mueve: puedes pensar que tu firewall es el cuello de botella; en realidad puede ser el CPE del ISP o un moldeador aguas arriba donde los paquetes se quedan y se estropean.

La voz (señalización SIP + media RTP) usa típicamente paquetes pequeños a un ritmo constante. Los túneles también prefieren lo constante—hasta que el enlace de la oficina se satura. Cuando ocurre la saturación, flujos grandes (discos en la nube, actualizaciones, copias de seguridad) crean colas. Esas colas inyectan jitter en RTP. Entonces el jitter buffer intenta compensar, añade retardo y, cuando no puede, obtienes audio cortado.

Hay una ley dura en redes de oficina: no “arreglas el jitter” dentro del túnel; previenes las colas antes del cuello de botella y priorizas la voz hacia dentro del túnel. Eso significa hacer shaping en la salida del enlace realmente restringido y elegir una disciplina de encolamiento que no castigue flujos pequeños en tiempo real.

Un chiste operativo seco, como prometí: los túneles VPN son como paraguas—la gente solo se acuerda de ellos cuando ya está lloviendo y ya están empapados.

Qué asume este artículo (y qué no)

Supuestos:

• Controlas un router/firewall de oficina (Linux, pfSense/OPNsense, un firewall de proveedor o un router-en-una-VM).
• Los endpoints VoIP son teléfonos de escritorio, softphones o un SBC de PBX en la nube, y la oficina está haciendo túnel hacia algo (CPD, nube, gateway de seguridad).
• Puedes ejecutar capturas de paquetes y herramientas CLI básicas.

No objetivos:

• No planteamos “comprar un nuevo circuito WAN” como solución principal, aunque a veces es la respuesta adulta.
• No vamos a hablar vagamente de “QoS” sin probar dónde está el cuello de botella.

Datos interesantes y contexto (porque la historia se repite en los paquetes)

1. VoIP sobre IP se popularizó mucho antes de que existiera “internet buena”. Los despliegues tempranos dependían mucho de jitter buffers porque los enlaces de acceso eran ruidosos y congestionados.
2. RTP es intencionalmente simple: asume que la red a veces será terrible y los endpoints lo mascararán con buffering y ocultación de pérdidas.
3. DiffServ (DSCP) data de finales de los 90 como reemplazo del antiguo modelo IP Precedence. Sigue siendo el lenguaje principal de QoS, aunque muchas redes lo ignoren.
4. IPsec ESP fue diseñado para confidencialidad, no para ingeniería de tráfico. El hecho de que ahora esperemos que preserve marcas QoS es una adaptación operativa, no la intención original.
5. Bufferbloat se nombró en 2009, pero el comportamiento existió desde que el hardware de consumo venía con buffers profundos no gestionados.
6. FQ-CoDel y CAKE nacieron del dolor en tiempo real: jugadores y usuarios de voz impulsaron mejoras prácticas en la gestión de colas, no la perfección académica.
7. SRTP (RTP seguro) cifra la media de extremo a extremo. Cuando añades una VPN encima, haces doble cifrado. Eso puede estar bien—salvo si tu CPU de borde es una vela en el viento.
8. Los problemas de MTU empeoraron con VPNs sobre banda ancha porque PPPoE, etiquetas VLAN y overhead de túnel se apilan como contenedores de envío.

Cómo es “buena voz”: latencia, jitter, pérdida y MOS

Para arreglar VoIP sobre VPN necesitas objetivos. Aquí están los prácticos usados en entornos de producción:

• Latencia unidireccional: < 150 ms es generalmente “bueno”. 150–250 ms es tolerable pero notable. Por encima de 250 ms, la gente comienza a pisarse.
• Jitter: mantenlo < 20–30 ms para una experiencia cómoda. Puedes sobrevivir a más, pero el jitter buffer añadirá demora.
• Pérdida de paquetes: mantenla < 1% para audio decente. Muchos códecs pueden ocultar un poco de pérdida; no les gusta.
• Reordenamiento: pequeñas cantidades están bien. Algunas optimizaciones VPN/acceleration pueden aumentarlo, y RTP odia sorpresas.

El jitter buffer no cura; es un préstamo

Los endpoints compensan el jitter con buffering. Ese buffer aumenta la latencia. Si “arreglas” el jitter aumentando el tamaño del buffer, acabas moviendo el dolor de audio robótico a conversación retrasada. A veces es un trade-off correcto—los centros de llamadas a menudo prefieren algo más de retardo a cortes—pero no es gratis.

MOS no es mágico

MOS (Mean Opinion Score) es un modelo. Es útil cuando las tendencias son claras y no lo engañas. Si puedes, mide jitter/pérdida directamente; trata MOS como un proxy de la percepción del cliente, no como una física inviolable.

Una cita de confiabilidad (idea parafraseada), porque operaciones tiene profetas: La idea parafraseada de Werner Vogels: todo falla, todo el tiempo—diseña y opera como si la falla fuera normal.

Guion de diagnóstico rápido (primero/segundo/tercero)

Primero: prueba dónde está el cuello de botella

Antes de tocar perillas de QoS, averigua qué se está saturando:

1. Revisa la utilización del enlace ascendente y los drops en el egress WAN real (el dispositivo que envía paquetes al ISP). Si estás haciendo shaping en una interfaz interna, probablemente estás actuando en el lugar equivocado.
2. Busca bufferbloat: la latencia bajo carga es la verdad. Si los tiempos de ping se multiplican por 10 durante una subida, encontraste tu fábrica de jitter.
3. Revisa la CPU en el endpoint VPN: el procesamiento de paquetes cifrados a menudo está limitado por un único núcleo. Un túnel puede estar “arriba” mientras la caja se derrite en silencio.

Segundo: valida MTU y fragmentación extremo a extremo

Si tienes fragmentación, PMTUD en silencio o problemas de MSS, la voz fallará de formas que parecen “jitter aleatorio”. No es aleatorio; son paquetes retrasados, fragmentados o descartados.

Tercero: asegura que la voz se clasifique correctamente antes del cifrado

La voz debe identificarse y priorizarse antes de desaparecer en un túnel. Luego necesitas o bien:

• Preservar DSCP en la cabecera exterior del túnel, o
• Clasificar dentro del endpoint del túnel y aplicar shaping/queueing allí.

Cuarto: arregla el encolamiento con disciplinas modernas (FQ-CoDel/CAKE)

Las colas de prioridad clásicas pueden ayudar, pero también pueden dejar todo lo demás sin servicio y crear extraña ráfaga. Para enlaces de oficina, CAKE o FQ-CoDel con shaping sensato suele ser la respuesta “funciona el lunes por la mañana”.

Quinto: solo entonces ajusta endpoints y PBX

La selección de códec, el packetization time (ptime), el jitter buffer y los timers SIP importan—pero no pueden arreglar un enlace ascendente saturado con colas terribles.

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

Estas tareas están escritas para un gateway VPN basado en Linux. Si estás en un appliance, los mismos conceptos aplican; los comandos solo serán específicos del proveedor.

Tarea 1: Identificar la interfaz WAN real y su tipo de enlace

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
ens18            UP             52:54:00:aa:bb:cc <BROADCAST,MULTICAST,UP,LOWER_UP>
ppp0             UNKNOWN        00:11:22:33:44:55 <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>
wg0              UNKNOWN        9a:bc:de:f0:12:34 <POINTOPOINT,NOARP,UP,LOWER_UP>

Qué significa: Puede que estés en PPPoE (ppp0) y no te des cuenta de que estás aplicando shaping en la interfaz equivocada (ens18). PPP añade overhead y tiene comportamiento de MTU distinto.

Decisión: Aplica shaping/QoS en el egress WAN verdadero (a menudo ppp0). Si haces shaping en ens18 pero el cuello de botella real es ppp0 o el módem del ISP, solo estás haciendo danza interpretativa.

Tarea 2: Revisar estadísticas de la interfaz VPN por errores y descartes

cr0x@server:~$ ip -s link show dev wg0
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
      987654321  123456      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
      876543210  120000      0       0       0       0

Qué significa: Paquetes RX descartados pueden indicar desbordamiento de cola en el lado receptor, contención de CPU o presión a nivel de kernel. En WireGuard, los descartes suelen ser congestión aguas abajo o policing en otro lugar.

Decisión: Si los descartes suben durante llamadas, no toques primero el PBX. Arregla congestión/encolamiento y revisa CPU y shaping.

Tarea 3: Medir latencia bajo carga (test de bufferbloat que puedes ejecutar ahora)

cr0x@server:~$ ping -i 0.2 -c 30 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=56 time=12.3 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=56 time=13.1 ms
...
--- 1.1.1.1 ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 6008ms
rtt min/avg/max/mdev = 11.9/12.8/14.6/0.6 ms

Qué significa: La línea base parece estable. Repite mientras saturas la subida (por ejemplo, una prueba de velocidad desde un cliente o un iperf controlado). Si el máximo salta a 200–800 ms, tienes bufferbloat.

Decisión: Si la latencia bajo carga se dispara, tu primer arreglo es shaping + AQM moderno (CAKE/FQ-CoDel), no “cambia códecs”.

Tarea 4: Confirmar qdisc actual en el egress WAN

cr0x@server:~$ tc qdisc show dev ppp0
qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Qué significa: pfifo_fast es anticuado y suele ser terrible con tráfico mixto. No gestiona activamente la latencia.

Decisión: Cámbialo por CAKE o FQ-CoDel + shaping. Si no puedes, lucharás contra los síntomas para siempre.

Tarea 5: Instalar shaping CAKE (ejemplo) y verificar que está activo

cr0x@server:~$ sudo tc qdisc replace dev ppp0 root cake bandwidth 80Mbit diffserv4 nat nowash ack-filter
cr0x@server:~$ tc -s qdisc show dev ppp0
qdisc cake 8001: root refcnt 2 bandwidth 80Mbit diffserv4 nat nowash ack-filter
 Sent 123456789 bytes 234567 pkt (dropped 123, overlimits 456 requeues 0)
 backlog 0b 0p requeues 0

Qué significa: CAKE está limitando a 80 Mbit y aplicando niveles DiffServ. Algunos descartes son normales; deberían ocurrir en tu moldeador, no corriente arriba en un buffer gigante del ISP.

Decisión: Fija el ancho de banda ligeramente por debajo del rendimiento real (a menudo 85–95%). Repite la prueba de calidad de llamada bajo carga. Si mejora drásticamente, encontraste el culpable principal.

Tarea 6: Observar DSCP en RTP entrante antes de que entre al túnel

cr0x@server:~$ sudo tcpdump -ni ens18 -vv 'udp and (port 5060 or portrange 10000-20000)' -c 5
tcpdump: listening on ens18, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP (tos 0xb8, ttl 64, id 12345, offset 0, flags [DF], proto UDP (17), length 214)
    10.10.20.50.40012 > 198.51.100.10.16432: UDP, length 172
IP (tos 0x00, ttl 64, id 12346, offset 0, flags [DF], proto UDP (17), length 498)
    10.10.20.50.5060 > 198.51.100.10.5060: SIP, length 456

Qué significa: RTP marcado con DSCP EF (0xb8) es ideal. SIP suele permanecer best-effort (0x00), lo cual está bien; lo que importa es la media.

Decisión: Si RTP no está marcado, decide si marcarlo en el teléfono, en el switch/AP de acceso o en el gateway (tabla mangle). Marcar en el borde es más limpio.

Tarea 7: Comprobar si DSCP sobrevive dentro del túnel (cabecera exterior)

cr0x@server:~$ sudo tcpdump -ni ppp0 -vv 'udp and host 203.0.113.20' -c 3
tcpdump: listening on ppp0, link-type LINUX_SLL2, snapshot length 262144 bytes
IP (tos 0x00, ttl 64, id 54321, offset 0, flags [DF], proto UDP (17), length 148)
    192.0.2.10.51820 > 203.0.113.20.51820: UDP, length 96

Qué significa: Los paquetes exteriores del túnel son best-effort (tos 0x00). Es común: la encapsulación no copió el DSCP interno al exterior.

Decisión: Si tu QoS WAN depende de DSCP, puede que necesites copiar DSCP (si está soportado) o clasificar tráfico en el endpoint del túnel y aplicar shaping allí. Si no, tu ISP verá un flujo insípido y tratará la voz como videos de gatos.

Tarea 8: Verificar MTU en el túnel y detectar riesgo de fragmentación

cr0x@server:~$ ip link show dev wg0
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000

Qué significa: 1420 es un MTU común en WireGuard. Si tu LAN es 1500 y no ajustas MSS para TCP, verás fragmentación en paquetes grandes. RTP es pequeño, pero SIP/TLS y “otro tráfico durante una llamada” aún pueden desencadenar encolamiento y retransmisiones.

Decisión: Si sospechas problemas de MTU, ajusta MSS para TCP y valida PMTUD. No adivines.

Tarea 9: Prueba PMTU con ping “no fragmentar”

cr0x@server:~$ ping -M do -s 1372 -c 3 203.0.113.20
PING 203.0.113.20 (203.0.113.20) 1372(1400) bytes of data.
1400 bytes from 203.0.113.20: icmp_seq=1 ttl=57 time=23.1 ms
1400 bytes from 203.0.113.20: icmp_seq=2 ttl=57 time=23.4 ms
1400 bytes from 203.0.113.20: icmp_seq=3 ttl=57 time=23.0 ms

--- 203.0.113.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 23.0/23.1/23.4/0.2 ms

Qué significa: Paquetes de 1400 bytes con DF funcionan. Incrementa tamaño hasta que falle para encontrar el verdadero margen PMTU.

Decisión: Si incluso pings DF modestos fallan, probablemente tienes un agujero negro PMTUD. Arregla MTU/MSS y asegúrate de que ICMP “frag needed” no esté bloqueado.

Tarea 10: Clamp MSS para TCP y evitar fragmentación a través del túnel

cr0x@server:~$ sudo iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
cr0x@server:~$ sudo iptables -t mangle -S FORWARD | grep TCPMSS
-A FORWARD -o wg0 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Qué significa: Esto evita que sesiones TCP intenten enviar segmentos demasiado grandes para el túnel, reduciendo fragmentación y retransmisiones que pueden empeorar indirectamente el jitter bajo carga.

Decisión: Mantén esto a menos que tengas una razón específica para no hacerlo. Es una de esas guardas “aburridas y correctas”.

Tarea 11: Revisar saturación de CPU en el endpoint VPN durante llamadas

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0 (server)  12/28/2025  _x86_64_  (4 CPU)

12:10:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:10:02 AM  all   22.0  0.0  11.0    0.0  0.0  20.0    0.0  47.0
12:10:02 AM    0   18.0  0.0   9.0    0.0  0.0  42.0    0.0  31.0
12:10:02 AM    1   25.0  0.0  12.0    0.0  0.0  18.0    0.0  45.0
12:10:02 AM    2   23.0  0.0  11.0    0.0  0.0  15.0    0.0  51.0
12:10:02 AM    3   22.0  0.0  12.0    0.0  0.0   5.0    0.0  61.0

Qué significa: Un %soft alto en un núcleo puede indicar un cuello de botella en el procesamiento de paquetes (softirq). El cifrado y encapsulación VPN pueden fijarse a un núcleo según el driver/queueing.

Decisión: Si un núcleo está constantemente al máximo en horas pico, necesitas optimizar la ruta de CPU (NIC RSS, afinidad de IRQ, cifrado más rápido, hardware o menos paquetes mediante ptime mayor cuando sea aceptable).

Tarea 12: Observar presión de softirq (procesamiento de red) y descartes de paquetes

cr0x@server:~$ cat /proc/softirqs | egrep 'NET_RX|NET_TX'
NET_TX:     1020304   993322   880011   770022
NET_RX:     9090909  8888888  7777777  6666666

Qué significa: Un NET_RX grande y que crece rápido en una CPU puede correlacionarse con jitter cuando el sistema está sobrecargado y los paquetes esperan su turno.

Decisión: Si se correlaciona con llamadas malas, reduce la tasa de paquetes (packetización del códec), escala CPU o ajusta IRQ/RPS/RFS para repartir la carga.

Tarea 13: Verificar pérdida y jitter de RTP con una captura en el gateway

cr0x@server:~$ sudo tshark -ni ens18 -f "udp portrange 10000-20000" -c 50 -q -z rtp,streams
Running as user "root" and group "root". This could be dangerous.
========================= RTP Streams =========================
Start time  End time  Src IP       Src port  Dst IP       Dst port  SSRC        Payload  Packets  Lost  Max Jitter
0.000000    9.842000  10.10.20.50  40012     198.51.100.10 16432   0x1a2b3c4d  111      400      3     14.7 ms
===============================================================

Qué significa: Estás viendo pérdida y jitter reales de RTP (tal como lo ve el punto de captura). Unos pocos paquetes perdidos pueden ser tolerables; pérdida sostenida se correlaciona con artefactos audibles.

Decisión: Si la pérdida ocurre antes de la encapsulación del túnel, arregla LAN/Wi‑Fi. Si la pérdida ocurre después de la encapsulación (captura en el lado WAN), arregla shaping/WAN/endpoint del túnel/ISP.

Tarea 14: Revisar presión de conntrack (sobrecarga de la tabla NAT puede parecer “jitter”)

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 24789
net.netfilter.nf_conntrack_max = 262144

Qué significa: Espacio amplio. Si el count está cerca del max, los flujos nuevos se descartan/expulsan, lo que puede romper SIP/RTP de formas extrañas.

Decisión: Si está cerca del máximo en horario laboral, aumenta conntrack_max y/o reduce el churn NAT innecesario (flujos de corta duración, timeouts mal configurados, dispositivos muy chatos).

Tarea 15: Confirmar que los timeouts RTP/SIP no son eliminados por valores por defecto del firewall

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_udp_timeout net.netfilter.nf_conntrack_udp_timeout_stream
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180

Qué significa: Si estos son demasiado cortos para tu entorno, los flujos RTP pueden ser eliminados a mitad de llamada cuando hay un breve silencio o un baile de re-INVITE.

Decisión: Si ves audio unidireccional a mitad de llamada tras ~30 segundos de silencio, aumenta los timeouts UDP o asegura que los keepalives estén configurados.

Guía específica por túnel: IPsec, WireGuard, OpenVPN

IPsec (IKEv2/ESP): robusto, común y fácil de mal-QoS

IPsec es un caballo de batalla. También le encanta hacer invisible tu QoS si no la preservas deliberadamente.

• La encapsulación ESP oculta puertos, así que “priorizar UDP 10000–20000” no ayuda en el lado WAN; todo se vuelve ESP.
• Copiar DSCP no es automático en todas partes. Algunas pilas pueden copiar el DSCP interno al externo; otras no; algunas lo hacen hasta que activas NAT-T.
• NAT-T (encapsulación UDP) añade otra cabecera y puede cambiar la MTU y la dinámica de fragmentación.

Qué hacer: Prioriza el tráfico antes del cifrado, luego asegúrate de que el endpoint VPN use eso para programar paquetes dentro del túnel. Si haces QoS a downstream (gestionado por el ISP), necesitarás preservación de DSCP en el exterior y verificarlo con capturas.

WireGuard: liviano, rápido, pero no mágico

La simplicidad de WireGuard es operativamente hermosa. Pero no resuelve automáticamente el jitter; solo consume menos ciclos de CPU que algunos diseños antiguos.

• Las elecciones de MTU por defecto importan. 1420 es común; tu entorno puede necesitar ~1380 si apilas PPPoE/VLAN.
• Problema del flujo UDP único: desde la perspectiva del ISP, es un solo flujo a menos que hagas shaping inteligentemente. Debes aplicar fair queueing en tu lado.
• Marcado: el DSCP en paquetes internos no se convierte automáticamente en DSCP en los paquetes UDP externos 51820.

OpenVPN: flexible, a veces más pesado de lo que crees

OpenVPN puede ser perfectamente válido para VoIP. También puede convertirse en generador de jitter si lo ejecutas en espacio de usuario en una CPU pequeña y empujas muchos paquetes pequeños.

• El modo UDP suele ser la elección correcta para VoIP. El modo TCP puede amplificar la latencia debido a retransmisiones (“TCP meltdown”).
• El overhead en espacio de usuario puede ser visible como jitter durante ráfagas de tráfico.
• La compresión es una trampa en configuraciones modernas: suele ser un riesgo de seguridad y puede aumentar el jitter por CPU.

QoS y shaping que realmente funciona sobre túneles

Empieza por shaping, no por “prioridad”

Si no haces otra cosa: haz shaping en el egress ligeramente por debajo de la tasa WAN real y usa CAKE. Esto fuerza a que la cola ocurra en tu caja (donde la controlas) en lugar de dentro del misterioso buffer del ISP (donde no lo haces).

Por qué esto ayuda a VoIP sobre VPN:

• Los paquetes RTP siguen siendo pequeños y frecuentes; el fair queueing les da turnos frecuentes.
• Las cargas grandes se dispersan en lugar de construir una cola gigante.
• La latencia bajo carga se vuelve predecible, que es exactamente lo que desean los jitter buffers.

Clasificación: marca antes del cifrado y luego programa en el túnel

Hay dos modelos viables:

1. Clasificación interna + shaping consciente del túnel: clasifica RTP/SIP en la interfaz LAN y luego haz shaping en WAN basado en marcas del firewall. Esto evita necesitar DSCP en la cabecera exterior.
2. DSCP extremo a extremo: marca RTP EF y asegúrate de que el túnel copie DSCP a la cabecera exterior para que los dispositivos downstream lo respeten. Es más limpio cuando funciona. Suele no hacerlo, salvo que lo configures explícitamente.

No abuses de la prioridad

Muchas guías de “QoS” recomiendan una cola de prioridad estricta para voz. Está bien si el volumen de voz es modesto y la clasificación es correcta. En una oficina real, la mala clasificación ocurre y la prioridad estricta puede dejar sin servicio DNS, ACKs y tráfico de control—provocando un tipo extraño de fallo autoinfligido donde la voz suena cristalina y todo lo demás colapsa.

Segundo chiste corto (y esa es la cuota): la QoS de prioridad estricta es como darle a un compañero la única llave de la sala de reuniones; la reunión es eficiente hasta que todos los demás empiezan a forzar la cerradura.

Mídelo: latencia bajo carga como KPI

Tu mejor “antes/después” no es el MOS de un teléfono. Es la latencia de ping bajo carga más la pérdida/jitter de RTP de capturas en puntos clave. Si el shaping funciona, el ping bajo carga mejora drásticamente y el jitter de RTP se estabiliza.

MTU, MSS, fragmentación: el silencioso asesino de la voz

Por qué los problemas de MTU aparecen como “jitter”

La fragmentación no siempre descarta paquetes, pero aumenta la variabilidad. Los fragmentos pueden tomar diferentes rutas, ser encolados de manera distinta o descartarse selectivamente. Si tienes mala suerte, PMTUD falla y los paquetes grandes se pierden en un agujero negro; entonces las retransmisiones TCP inundan el enlace y la transmisión de voz sufre daño colateral.

Pilas de MTU comunes en oficinas

• Ethernet: 1500
• PPPoE: típicamente 1492
• Overhead de etiqueta VLAN: reduce efectivamente la carga útil a menos que uses jumbo frames extremo a extremo
• WireGuard: a menudo ~1420
• IPsec ESP/NAT-T: varía; puede reducir sustancialmente el MTU efectivo

Reglas prácticas

• Clampea MSS para TCP hacia el túnel para prevenir tormentas de fragmentación.
• Permite ICMP esencial (frag-needed, time-exceeded). Bloquearlo es como quitar señales de tráfico y culpar a los conductores por llegar tarde.
• Define el MTU del túnel deliberadamente. El auto puede estar bien, pero “estar bien” no es una estrategia cuando el CEO oye robots.

Wi‑Fi y problemas de última milla que sigues culpando a “la VPN”

Wi‑Fi introduce jitter por diseño

Wi‑Fi es basado en contención. Los clientes se turnan, retransmiten y adaptan la tasa. Es asombroso que VoIP funcione en ello, y la razón es que la voz requiere poco ancho de banda. Pero poco ancho no significa baja sensibilidad.

Si tus teléfonos de oficina están en Wi‑Fi:

• Prefiere 5 GHz (o 6 GHz si está disponible) para menor interferencia.
• Activa WMM (Wi‑Fi Multimedia) y asigna correctamente DSCP a categorías WMM.
• Vigila “clientes pegados” a APs distantes que causan reintentos y abuso de airtime.

Asimetría de última milla y policing

Muchos enlaces de banda ancha son asimétricos en subida. VoIP es bidireccional; la subida suele importar más porque es donde la oficina envía RTP al proveedor y donde las copias en la nube y sincronizaciones pueden saturar.

Además: los ISP a veces policía el tráfico de forma que causas microburst y descartar. Tu moldeador debería suavizar los picos antes de que golpeen el módem. Si no haces shaping, el ISP lo hará por ti, mal.

Tres mini-historias corporativas (dolor, arrepentimiento y éxito aburrido)

1) El incidente causado por una suposición incorrecta

Migraron teléfonos a un PBX en la nube y mantuvieron el VPN site-to-site porque “la seguridad requiere todo el tráfico por HQ”. El plan asumió que la voz era “solo otro flujo UDP” y, como los gráficos de ancho de banda parecían bien, nadie se preocupó.

La primera semana en producción, los ejecutivos empezaron a reportar que las llamadas eran perfectas temprano en la mañana e inservibles a las 10:30. Ese patrón gritaba “congestión”, pero el NOC miró la utilización media y no vio nada alarmante—porque las medias son la mentira que te cuentan tus gráficos para mantenerte tranquilo.

Una captura en LAN mostró RTP marcado EF. Una captura en WAN mostró los paquetes del túnel todos best-effort. El firewall de HQ tenía una política QoS preciosa para puertos de voz, pero cuando los paquetes entraron en IPsec se convirtieron en ESP. La política nunca hizo match. La voz estaba encolada detrás de una avalancha de sincronización de almacenamiento en la nube y un ciclo semanal de actualizaciones de endpoints.

La solución no fue exótica: moldear el uplink de HQ con CAKE, clasificar la voz antes del cifrado y programarla en una capa superior. Una vez que la cola del cuello de botella se trasladó del ISP a su moldeador controlado, el jitter se aplanó y las llamadas se estabilizaron. La suposición equivocada fue creer que “ya tenemos QoS” porque la configuración existía. La red no se preocupaba por la configuración; se preocupaba por dónde realmente se encolaban los paquetes.

2) La optimización que se salió de madre

Otra compañía tenía una sucursal pequeña con un firewall modesto. VoIP sobre VPN estaba al límite en momentos de actividad, así que alguien “optimizó” activando coalescing agresivo de paquetes y offloads, además de un perfil de rendimiento que subía la moderación de interrupciones para reducir uso de CPU.

Los gráficos de CPU del firewall mejoraron inmediatamente. El equipo celebró. Entonces el helpdesk recibió una nueva clase de quejas: “La gente suena como si estuviera bajo el agua” y “Cada pocos segundos el audio hace un ‘hiccup’”. No se correlacionaba con el ancho de banda; se correlacionaba con ráfagas de tráfico.

Qué pasó: la moderación de interrupciones y el coalescing aumentaron la varianza de latencia. Los paquetes no se procesaban de forma regular; llegaban en racimos. RTP prefiere un metrónomo. Recibió jazz. Además, algunos ajustes de offload interactuaban mal con tráfico encapsulado, aumentando retransmisiones en otros flujos, lo que creó más ráfagas. Un bucle perfecto—como un eco, pero por malas decisiones.

Revirtieron los ajustes de “rendimiento” y luego usaron shaping para limitar el WAN ligeramente por debajo de la línea. La CPU subió, pero la calidad de las llamadas se estabilizó. La lección: optimizar para CPU promedio puede empeorar la latencia en la cola. VoIP vive en las colas altas.

3) La práctica aburrida pero correcta que salvó el día

Una compañía con docenas de pequeñas oficinas ejecutaba VoIP sobre WireGuard hacia un hub regional. Nada sofisticado. Pero tenían la costumbre poco glamorosa: cada nuevo sitio recibía una “prueba de aceptación de voz” estandarizada desde el día uno.

La prueba incluía un ping bajo carga, un barrido MTU con DF-ping y un breve flujo RTP sintético medido en el hub. Guardaban resultados por sitio y los comparaban con la línea base. Era tan rutinario que técnicos junior podían ejecutarlo sin improvisar.

Una oficina empezó a tener problemas intermitentes tras un cambio de hardware del ISP. El ISP insistía en que la línea estaba bien. El equipo volvió a correr la prueba de aceptación y vio inmediatamente que la latencia bajo carga pasó de “estable” a “montaña rusa”. El barrido MTU también mostró una PMTU reducida. No habían cambiado nada internamente.

Porque tenían datos de referencia, no discutieron sobre sensaciones. Presentaron evidencia medida, ajustaron su moldeador y el MTU del túnel temporalmente, y presionaron al ISP para corregir la provisión. Las llamadas mejoraron el mismo día. La práctica no era glamorosa. Era correcta. Les ahorró tiempo y la reunión interminable donde alguien dice “pero funcionó el año pasado”.

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

1) Síntoma: las llamadas están bien hasta que alguien sube un archivo grande

Causa raíz: bufferbloat en el uplink; la cola ocurre en el módem/ISP, no bajo tu control.

Solución: haz shaping en el egress de la WAN real (CAKE/FQ-CoDel). Valida con ping bajo carga.

2) Síntoma: audio unidireccional, especialmente después de un minuto de silencio

Causa raíz: timeouts UDP de NAT/conntrack demasiado bajos; mapeos SIP/RTP expiran.

Solución: aumenta los timeouts UDP apropiadamente, habilita keepalives SIP/RTP si están soportados y asegura enrutamiento simétrico.

3) Síntoma: audio robótico con tartamudeos periódicos, incluso con bajo ancho de banda

Causa raíz: cuello de botella de CPU/softirq en el gateway VPN, a menudo saturación de un solo núcleo, o moderación de interrupciones agresiva que causa procesamiento a ráfagas.

Solución: revisa CPU por núcleo y softirq. Ajusta IRQ/RSS, reduce la tasa de paquetes (ptime del códec) o mejora el hardware. Reviértete de offloads que hostilizan la latencia.

4) Síntoma: caídas aleatorias al habilitar la VPN, especialmente para ciertas aplicaciones

Causa raíz: problemas MTU/PMTUD; ICMP frag-needed bloqueado; fragmentación o agujero negro.

Solución: valida PMTU con pings DF; clampea MSS; permite ICMP; fija el MTU del túnel deliberadamente.

5) Síntoma: QoS configurado, pero la voz sigue sonando mal sobre VPN

Causa raíz: estás haciendo match en puertos internos que quedan ocultos después del cifrado; o DSCP no se copia a la cabecera exterior.

Solución: clasifica antes del cifrado usando marcas, haz shaping en WAN usando esas marcas; o configura copia de DSCP y verifica con capturas.

6) Síntoma: jitter solo en usuarios Wi‑Fi, los teléfonos cableados están bien

Causa raíz: reintentos Wi‑Fi, interferencia, contención de airtime, mapeo WMM/DSCP faltante.

Solución: fuerza uso 5/6 GHz, ajusta APs, activa WMM, reduce reintentos y considera SSID/VLAN dedicado para voz.

7) Síntoma: la VPN “funciona”, pero el establecimiento de llamada es lento o falla intermitentemente

Causa raíz: SIP ALG o funciones “útiles” del firewall reescribiendo SIP; o enrutamiento asimétrico entre múltiples WANs.

Solución: desactiva SIP ALG salvo que realmente lo necesites; asegura un camino consistente para señalización y media; usa un SBC si la arquitectura lo requiere.

Listas de verificación / plan paso a paso

Paso a paso: estabilizar la voz sobre una VPN en una oficina

1. Mapea la ruta del tráfico: dónde está el endpoint VPN, dónde se hace NAT, dónde está el cuello de botella real (egress WAN). Escríbelo.
2. Mide la línea base: ping a un destino externo estable; captura estadísticas RTP en el gateway; anota síntomas de llamadas y patrón horario.
3. Ejecuta test de latencia bajo carga: satura la subida brevemente; observa ping máximo y jitter. Si se dispara, deja de culpar al “PBX”.
4. Instala shaping en egress WAN: empieza con CAKE al 85–95% del ancho de banda real. Reprueba bajo carga.
5. Clasifica la voz: marca RTP EF (o equivalente) en el borde; asegúrate de que el moldeador lo respete. Si no puedes preservar DSCP en el túnel, usa marcas del firewall.
6. Arregla MTU/MSS: barrido DF-ping, clamp MSS, permite ICMP necesarios, ajusta MTU del túnel si hace falta.
7. Verifica holgura de CPU: mira CPU por núcleo y softirq durante llamadas concurridas + carga. Si estás limitado por CPU, ninguna política QoS te salvará.
8. Valida Wi‑Fi por separado: si solo falla Wi‑Fi, trátalo como problema Wi‑Fi. Las pruebas cableadas son tu grupo de control.
9. Fija el monitoreo: registra latencia bajo carga, descartes de túnel, descartes de qdisc y jitter/pérdida de RTP. Haz tendencias. Hazlo aburrido.

Lista operativa: antes de cambiar algo en medio de un incidente

• Captura 30 segundos de tráfico en LAN y en WAN (o interfaz del túnel) durante una llamada mala.
• Revisa estadísticas de qdisc y descartes de interfaz.
• Revisa CPU por núcleo y softirq.
• Confirma si el uplink se está saturando (no promedio; picos actuales).
• Confirma si DSCP está presente en RTP y si sobrevive la encapsulación.
• Ejecuta pings DF con varios tamaños para detectar regresiones PMTU.

Preguntas frecuentes

1) ¿Una VPN hace inherentemente malo al VoIP?

No. Una VPN añade overhead y puede ocultar tráfico para QoS, pero el asesino habitual es el encolamiento por congestión y la mala gestión de colas. Arregla eso y VoIP puede ser excelente sobre un túnel.

2) ¿Debería ejecutar VoIP fuera de la VPN para “arreglarlo”?

A veces es una opción arquitectónica válida, especialmente con PBX en la nube y SRTP/TLS ya en uso. Pero no lo uses como parche para un bufferbloat que seguirás teniendo para todo lo demás.

3) ¿Qué importa más: latencia o jitter?

Para la calidad de voz, el jitter suele ser lo que los usuarios perciben como “entrecortado”. Para la comodidad conversacional, la latencia importa más. En la práctica están ligados: los jitter buffers intercambian jitter por latencia.

4) ¿Vale la pena DSCP en internet público?

En internet abierto, DSCP es inconsistente. Dentro de tu oficina y en tu borde controlado, definitivamente vale la pena porque informa a tu propio moldeador y al mapeo WMM de Wi‑Fi. Trata que el ISP lo respete como un bonus, no como dependencia.

5) ¿Cuál es el cambio único más efectivo para VoIP de oficina sobre VPN?

Hacer shaping en el egress WAN con CAKE (o FQ-CoDel) a un límite realista de ancho de banda, y verificar que la latencia bajo carga mejore. No es glamoroso. Es efectivo.

6) ¿Por qué mis gráficos muestran baja utilización pero las llamadas se cortan?

Porque las medias ocultan microburst y encolamiento. La voz falla en variabilidad de escala de milisegundos. Mira la latencia máxima bajo carga, descartes de interfaz y backlog de qdisc—no solo promedios de 5 minutos.

7) ¿Debería cambiar códecs para arreglar jitter?

La elección de códec puede ayudar (algunos toleran mejor la pérdida) y el ptime afecta la tasa de paquetes. Pero si tus colas upstream son el problema, cambiar códecs es un parche. Arregla la red primero, luego optimiza códecs si hace falta.

8) ¿Es buena idea una VPN basada en TCP (o SIP sobre TCP)?

Para la media (RTP), no—usa UDP. Para señalización SIP, TCP/TLS está bien. Pero túneles basados en TCP para todo pueden amplificar la latencia bajo pérdida por retransmisiones y head-of-line blocking.

9) ¿Y si el endpoint VPN está en la nube, no en la oficina?

Entonces aún necesitas shaping en el egress WAN de la oficina. El shaping en la nube no arregla la cola del uplink de la oficina. También puedes añadir shaping/queueing en la nube para proteger downstream, pero el primer cuello de botella suele ser el uplink de la sucursal.

10) ¿Cómo saber si el problema es el ISP o mi equipo?

Si el shaping en tu gateway mejora drásticamente la latencia bajo carga, el camino del ISP puede estar bien; la cola previa estaba en el lugar equivocado. Si aún ves pérdida/jitter después del shaping y la CPU está sana, recoge capturas y presiona al ISP con evidencia (cambios PMTU, patrones de pérdida, correlación horaria).

Conclusión: siguientes pasos que puedes hacer esta semana

Si tu oficina ejecuta VoIP a través de un túnel VPN y la calidad es inconsistente, deja de debatir y empieza a medir. La solución suele ser una pequeña pila de controles aburridos:

1. Ejecuta pruebas de latencia bajo carga y prueba bufferbloat (o descártalo).
2. Haz shaping en el egress WAN real con CAKE o FQ-CoDel, ligeramente por debajo de la tasa real.
3. Clasifica la voz antes del cifrado; no asumas que las reglas QoS coinciden una vez que el tráfico es “solo un túnel”.
4. Valida MTU/PMTU y clampea MSS para no crear caos por fragmentación.
5. Revisa CPU/softirq del endpoint VPN y deshaz “optimizaciones” que aumenten la latencia en las colas.

Haz eso y VoIP sobre VPN se volverá aburrido—que es el mayor cumplido que un SRE puede dar a un sistema en producción.