Cómo monitorear el ancho de banda de la VPN en macOS

Te conectas a tu VPN, ejecutas una verificación web que reporta el país correcto y asumes que ahora todo está en el túnel. Dos días después notas que una de tus apps —digamos, un viejo cliente de chat o un agente de sincronización— ha estado hablando directamente con la internet pública todo el tiempo, ignorando el túnel por completo. La VPN estaba activa. La fuga estaba en un proceso que se ató a la interfaz física antes de que el túnel subiera y nunca la soltó.

Monitorizar el ancho de banda de la VPN en macOS es en parte confirmar que la VPN está haciendo su trabajo y en parte atrapar a las apps que silenciosamente la sortean. Este artículo cubre qué son realmente las interfaces utun, cómo leer el tráfico VPN con herramientas integradas, cómo detectar fugas y cómo medir la sobrecarga que añade el túnel. Si has estado buscando monitorizar el ancho de banda VPN en Mac porque el panel propio de la VPN no te dice lo suficiente, el kit de abajo responde a las preguntas más difíciles.

Qué son las interfaces utun

Cuando un cliente VPN se conecta en macOS, crea una interfaz virtual, normalmente nombrada utun0, utun1, utun2, etc. ("utun" significa "user tunnel".) El proceso VPN lee paquetes que el SO enruta a esa interfaz, los cifra y encapsula, y escribe los paquetes envueltos resultantes hacia tu interfaz física (en0 para Wi-Fi, típicamente).

Ejecuta esto en Terminal para ver qué hay activo ahora mismo:

ifconfig | grep -E "^(en|utun)" -A 3

Verás algo como:

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.42 netmask 0xffffff00 broadcast 192.168.1.255
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
        inet 10.8.0.6 --> 10.8.0.1 netmask 0xffffff00

en0 es tu red real. utun0 es la VPN. Algunos clientes VPN crean varias interfaces utun (una para el plano de datos, una para el de control); algunos crean utun9 o superiores para evitar colisiones con túneles del estilo Personal Hotspot de iOS.

Cómo monitorizar el tráfico VPN en Mac con nettop

nettop está integrado en macOS y es la manera más directa de ver qué interfaz está usando un proceso. La invocación relevante:

sudo nettop -P -m route

Esto muestra las conexiones de cada proceso agrupadas por ruta. Un proceso hablando por tu VPN mostrará su tráfico vía la interfaz utun; un proceso saltándose el túnel mostrará vía en0 (o en1 si es ethernet).

Mira nettop durante un minuto, luego pregunta: ¿qué apps están usando utun0 y cuáles están usando en0? Si pretendes que todo vaya por el túnel y ves Slack en en0, eso es una fuga.

La flag -P agrega por proceso; -m route muestra la columna de ruta. Añade -x para conteo de bytes. Añade -c y un retraso para refresco periódico, p. ej. nettop -P -c 2.

Qué muestra ova para el tráfico VPN

Un monitor por app como ova ve las mismas estadísticas del kernel que nettop y las acumula a lo largo del tiempo. El ancho de banda atribuido a "Slack" en ova incluye lo que sea que Slack envió: por en0 o utun0 no cambia el total por proceso. Así que ova responde "¿cuánto usó Slack?" limpiamente. Actualmente no desglosa el número por app por interfaz: si necesitas ese nivel de detalle, nettop es la herramienta.

Para la mayoría de los usuarios de VPN está bien. Las preguntas que normalmente quieres responder son:

• "¿Está mi cliente VPN usando el ancho de banda que espero?"
• "¿Hubo algún pico en la última hora?"
• "¿Qué app es actualmente la más pesada?"

ova te da las tres de un vistazo, con agrupación de procesos auxiliares para que un PID auxiliar de Slack no aparezca como una fila separada. El propio cliente VPN (Tailscale, Mullvad, ProtonVPN, NordVPN, etc.) aparece como su propia línea, y su número es el total envuelto/cifrado saliendo por tu enlace físico.

Detectar fugas

Una fuga de VPN es cuando el tráfico de una app sortea el túnel y va directo a internet. Las causas incluyen:

• La app cacheó una ruta antes de que la VPN subiera y aún la está usando.
• La VPN no enruta ciertos destinos (LAN, multicast, DNS a un servidor específico).
• El conmutador "excluir red local" de macOS está haciendo lo que dice.
• La VPN tiene túnel dividido y una app particular está en la lista de bypass.
• IPv6 está activado y la VPN solo enruta IPv4 (causa común).

El bucle de diagnóstico:

1. Con la VPN conectada, ejecuta nettop -P -m route y vigila cualquier proceso mostrando tráfico en0 que esperabas que estuviera tunelado.
2. Cruza con ova para el ancho de banda por proceso. Si un proceso muestra tráfico en ova pero no hay filas utun en nettop, está filtrando.
3. Confirma a nivel de red: visita ipleak.net o dnsleaktest.com desde un navegador. La IP reportada debe ser la salida de la VPN, no la de tu casa/oficina.
4. Para DNS específicamente: ejecuta scutil --dns | grep nameserver: los nameservers listados deben ser los de tu VPN, no los de tu ISP.

Para IPv6 específicamente, la configuración más segura es o una VPN que enrute IPv6 explícitamente o desactivar IPv6 en todo el sistema mientras estás conectado. Desactivar por red: Ajustes del Sistema > Red > tu red > Detalles > TCP/IP > Configurar IPv6 > Solo link-local.

Medir la sobrecarga de la VPN

Las VPNs añaden sobrecarga de dos maneras: rendimiento (obtienes menos de tu velocidad de línea real) y latencia (cada ida y vuelta pasa por un salto extra).

Sobrecarga de rendimiento

El impuesto del cifrado depende del protocolo:

• WireGuard: típicamente 5 a 10 por ciento de sobrecarga en un enlace rápido. Acelerado por hardware en Apple Silicon.
• OpenVPN: 15 a 30 por ciento de sobrecarga. Limitado por CPU, más lento que WireGuard a altas velocidades.
• IKEv2/IPsec: 10 a 20 por ciento de sobrecarga. Soporte nativo en macOS.
• Protocolos propietarios (Lightway, NordLynx basado en WireGuard, etc.): aproximadamente eficiencia nivel WireGuard.

Para medir: corre un test de velocidad con la VPN apagada, anota el resultado. Corre el mismo test con la VPN activa, a un servidor en la misma área metropolitana que el endpoint del test sin VPN. La proporción es la sobrecarga. Usa ova durante ambos tests: el tráfico por app mostrado para el cliente del test de velocidad debería ser el rendimiento de capa de aplicación; la tasa a nivel de sistema durante los tests con VPN es mayor por el framing del cifrado.

Sobrecarga de latencia

Ejecuta ping 8.8.8.8 con la VPN apagada, anota el RTT en estado estacionario. Conecta la VPN, ejecuta ping 8.8.8.8 de nuevo. La diferencia es el coste de ida y vuelta de cifrar, viajar al exit de la VPN y volver. Cifras típicas:

• Exit VPN en la misma ciudad: +5 a +15 ms.
• Exit VPN en otro país: +50 a +200 ms dependiendo de la geografía.
• Exit VPN en otro continente: +150 a +400 ms.

Esto es física inevitable en su mayor parte: no puedes tunelar a Tokio sin que te cueste la ida y vuelta.

Identificar el uso de ancho de banda propio de la VPN

El propio proceso del cliente VPN aparece en ova como su propia fila: "Mullvad VPN", "Tailscale", "ProtonVPN", etc. El número que ves ahí es el total cifrado y envuelto saliendo por tu enlace físico. Ese es el número correcto para "cuánto ancho de banda real de internet está consumiendo la VPN".

Una verificación de cordura útil: en cualquier momento, el ancho de banda reportado de la VPN debería ser aproximadamente igual a la suma de todas las demás apps que la usan, más un pequeño porcentaje por la sobrecarga del cifrado. Si son muy distintos, algo más está pasando: túnel dividido, fugas, o el cliente VPN haciendo trabajo de mantenimiento (rotación de claves, descubrimiento de pares).

Ve ova en acción

Un monitor de ancho de banda en la barra de menú visible de un vistazo: local, firmado, ~3 MB.

Descargar para macOS

VPN siempre activa: trampas

Varios clientes VPN ofrecen un modo "kill switch" o "siempre activa" que bloquea todo el tráfico si el túnel cae. Útil, pero con sorpresas:

• Los primeros segundos tras despertar pueden tener tráfico desbloqueado antes de que el túnel se restablezca. Algunos clientes lo retienen explícitamente; otros no.
• Los cambios de red Wi-Fi (de casa a la cafetería) disparan una breve desconexión. El kill switch debería retener pero la implementación varía.
• Algunas apps tienen lógica de reconexión agresiva: reintentan cada 100 ms cuando el túnel está caído. Eso es un pico de ancho de banda en el momento de la reconexión una vez que el túnel vuelve.

Mira ova el momento tras despertar con la VPN activa. El patrón normalmente es: el cliente VPN en sí muestra una pequeña subida mientras hace handshake de nuevo, luego en 5 a 30 segundos las apps individuales empiezan a subir mientras reconectan sus propios sockets. Si ves un pico de 200 MB al despertar, eso típicamente es Slack/Discord/iMessage poniéndose al día todos a la vez.

Enrutamiento por app y túneles divididos

Algunos clientes VPN soportan enrutar solo apps específicas por el túnel. El caso de uso es "envía mi cliente de torrent por Mullvad, pero deja a Slack ir directo para que las videollamadas no añadan latencia VPN".

Verificar las reglas de túnel dividido con nettop:

sudo nettop -P -m route

Las apps con túnel dividido solo deben mostrar tráfico en0; las tuneladas solo deben mostrar utun. Si ambos aparecen para el mismo proceso, las reglas no se están aplicando limpiamente, normalmente porque la app mantiene sockets de larga duración que predatan el cambio de regla. Reinicia la app para limpiarlos.

Monitorizar varias conexiones VPN

Los usuarios avanzados a veces corren dos VPNs a la vez, por ejemplo Tailscale para acceder a servicios internos de la empresa más una VPN comercial (Mullvad, Proton) para privacidad general en internet. macOS maneja esto vía tablas de enrutamiento: las rutas más específicas (100.64.0.0/10 de Tailscale) ganan sobre las más amplias (la ruta por defecto de la VPN comercial).

Verás varias interfaces utun en ifconfig. Usa netstat -rn | head -30 para leer la tabla de enrutamiento: la primera ruta que coincide gana. ova muestra el ancho de banda total por app sin distinguir qué túnel; para eso, la vista -m route de nettop es la referencia.

Qué hacer después

Una auditoría de 10 minutos para monitorizar el ancho de banda VPN en Mac de extremo a extremo:

1. Conecta la VPN.
2. Abre ova en la barra de menú, anota las apps actualmente activas.
3. Ejecuta sudo nettop -P -m route en Terminal.
4. Cruza: cada app mostrando ancho de banda significativo en ova debería tener sus conexiones apareciendo bajo utun0 (o cualquier utun que use tu VPN) en nettop. Cualquier tráfico en0 de esos procesos es candidato a fuga.
5. Visita ipleak.net para confirmar que la IP y el DNS salen por la VPN.
6. Desconecta, ejecuta un test de velocidad, reconecta, ejecuta otro. Calcula la sobrecarga.

Saldrás de esto sabiendo si tu VPN está realmente haciendo lo que crees, qué le cuesta realmente la sobrecarga y qué apps vigilar. Esa es una respuesta más fuerte que el indicador "Conectado" en la barra de menú de tu cliente VPN.