¿La interfaz utun de la VPN en Mac está activa pero el tráfico falla? Revisa ifconfig

Conectaste la VPN, ejecutaste ifconfig y encontraste una entrada utun4 con una dirección encima. El sitio que necesitabas sigue sin responder. Esa brecha es normal: el listado demuestra que existe una interfaz virtual, no que la posea tu cliente, que la ruta que te importa la seleccione o que los paquetes la crucen. Dejé de confiar en el nombre de la interfaz después de pasar una tarde culpando al túnel equivocado en un portátil que ya tenía tres entradas utun antes de instalar nada.

Qué contiene realmente una línea utun

Ejecuta ifconfig -a cuando quieras la imagen completa. Llamado sin argumentos, ifconfig solo imprime las interfaces que están activas en ese momento, y por eso un túnel que no arrancó puede faltar en la salida que la gente pega en los tickets. ifconfig -l devuelve solo los nombres, y esa es la forma más rápida de saber si apareció un utun nuevo después de conectarte.

Leer una sola interfaz es donde vive el detalle útil. Un túnel conectado suele verse así:

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

Tres campos llevan la respuesta. UP y RUNNING dicen que el núcleo está dispuesto a usar la interfaz. POINTOPOINT más la dirección del par --> es la firma de un túnel y no de un enlace físico. El valor mtu explica toda una clase de informes de «conecta y luego se atasca», porque las interfaces utun suelen levantarse con una MTU reducida, 1380 en varias compilaciones de macOS, y el cliente puede sobrescribirla. La lista de campos es lo bastante corta para hojearla una vez en el manual de ifconfig que distribuye Apple.

Encuentra el proceso detrás de la interfaz

ifconfig no tiene ningún concepto de aplicación propietaria. Dos clientes de VPN, un servicio del sistema y un túnel sobrante de la semana pasada producen entradas que a este nivel parecen idénticas. En mi propio Mac, utun0 hasta utun3 existían antes de que configurara nada; Continuity e iCloud Private Relay también usan túneles, y ninguno de ellos es la conexión que estás diagnosticando.

Para los túneles que registran una configuración en el sistema, scutil --nc list es la correlación más rápida. Imprime cada configuración con su estado y su ID de servicio, y la conectada se marca así:

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

Los clientes que ejecutan su propio proceso de túnel en lugar de registrar una configuración nunca aparecen ahí. Tunnelblick y una instancia de openvpn desde la línea de comandos caen en ese grupo, así que revisa también la tabla de procesos: ps -Ao pid,comm | grep -i openvpn. Una vez que un proceso posee el túnel, el número utun pertenece a ese proceso y a nadie más.

Prueba la dirección antes de probar la ruta

Una interfaz puede estar activa sin una dirección utilizable. Un perfil solo IPv6 muestra una entrada fe80:: local de enlace y nada en la línea inet, y un cliente que no logró aplicar una dirección empujada deja exactamente la misma forma. Si tu destino es IPv4 y el túnel no tiene dirección IPv4, la cuestión del enrutamiento ya está resuelta.

La MTU merece una comprobación aparte, porque el fallo no parece un problema de tamaño. Parece una conexión que se autentica y luego se queda en silencio en cuanto empieza una transferencia grande. Envía una sonda que no deba fragmentarse, dimensionada para que el paquete encaje con la MTU de la interfaz; para una MTU de 1400 la carga útil es de 1372 bytes:

ping -D -s 1372 10.8.0.5

Una respuesta significa que los paquetes de ese tamaño atraviesan el túnel. El silencio mientras los pings pequeños funcionan apunta a la MTU o a algo que descarta ICMP en el camino, no a la autenticación, que ya había terminado antes de que tuvieras una interfaz.

Demuestra que el destino elige el túnel

La pregunta importante no es si existe utun4, sino si el tráfico hacia una dirección concreta sale por él. route -n get lo responde para un solo destino e imprime la puerta de enlace y la interfaz que usaría:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Si el mismo comando informa de en0, tu configuración de túnel dividido hace lo que se le dijo y ninguna cantidad de inspección de interfaces lo cambiará. Usa netstat -rn -f inet cuando necesites la ruta predeterminada y toda la tabla en una sola vista.

Los contadores deciden si los paquetes se mueven de verdad. netstat -ib informa de los totales de paquetes y bytes por interfaz, incluidas las entradas utun; los números son acumulativos, así que léelos dos veces con una pausa y compara:

netstat -ib | grep utun4

Contadores congelados mientras la aplicación sigue reintentando significan que el núcleo nunca entregó un paquete a la interfaz. Contadores que suben en ambas direcciones mientras la aplicación sigue fallando trasladan la investigación al extremo opuesto del túnel.

Cuando no aparece ningún utun

Una lista de interfaces vacía tras un inicio de sesión que parecía correcto suele significar que el túnel nunca arrancó, no que ifconfig lo esconda. Revisa el estado del propio cliente y luego el del sistema: una extensión de red que nunca se aprobó, o que macOS desactivó tras una actualización, no deja ninguna interfaz atrás. La aprobación vive en Ajustes del Sistema, en Login Items & Extensions, y una entrada obsoleta allí merece volver a conmutarse antes de reinstalar nada.

La numeración utun no es estable entre reconexiones. Puedes obtener utun5 donde hace diez minutos existía utun4, porque la interfaz antigua se desmonta y el núcleo entrega el siguiente índice libre. Los scripts que fijan un nombre en duro se rompen en silencio en ese momento; mejor compara por la dirección o por la ruta.

Mantén el lado de lectura como solo lectura. sudo ifconfig utun4 down interrumpe el túnel, y en un perfil de túnel completo se lleva tu sesión remota con él, lo que es un mal intercambio cuando solo intentabas reunir pruebas. Nada de lo que necesitas aquí requiere root: leer indicadores, direcciones y contadores funciona como tu usuario normal.

Recorre las comprobaciones en orden la próxima vez que un túnel de Mac se porte mal: confirma que apareció un utun con ifconfig -l, lee sus indicadores, direcciones y MTU, atribúyelo a un proceso, pregunta a route -n get qué interfaz usa el destino y luego observa cómo se mueve netstat -ib. Cada paso descarta una capa distinta, y el primero que salga mal es donde va la solución.