Iniciar una VPN de Mac guardada desde el terminal con scutil --nc

Tiene un servicio VPN guardado en Ajustes del sistema y quiere que el terminal lo levante. En macOS la ruta compatible es scutil --nc, pero solo para servicios que posee el propio gestor de conexiones de red del sistema. La barra de menús no es la API: los clientes de terceros suelen tener su propia automatización, y un perfil enviado por un servicio de gestión puede rechazar un inicio local. Esta es la lista de comprobación que sigo: encuentre el servicio exacto, lea su estado, inícielo, espere a que el estado cambie y luego demuestre que el tráfico usa realmente el túnel. Deténgase en el primer paso que no cuadre, porque cada comando posterior supone que el anterior ha funcionado.

Encuentre el servicio antes de intentar iniciarlo

Empiece por el inventario en lugar del nombre de perfil que recuerda:

scutil --nc help
scutil --nc list

Cada línea empareja un estado con un identificador de servicio, un tipo y un nombre para mostrar. El identificador es el valor contra el que se escriben scripts, porque los nombres para mostrar se repiten y se pueden editar. El manual de scutil de Apple documenta el modo de conexión de red, mientras que el --nc help instalado es la lista autorizada de subcomandos en ese Mac; no suponga que una opción de una guía antigua sigue existiendo en su versión de macOS.

Una lista vacía es un resultado, no un error. Un servicio creado por un cliente de proveedor o por un perfil de gestión puede estar activo mientras es invisible aquí, o visible con un tipo que el controlador nativo no puede manejar. En ese caso, use la herramienta del proveedor o la documentación del perfil. Crear un perfil nativo paralelo solo para tener algo que iniciar es un mal negocio.

Lea el estado actual y confirme el selector

Consulte el servicio antes de iniciarlo, para saber qué debería cambiar un inicio correcto:

scutil --nc status "Office VPN"

Si dos servicios comparten un nombre para mostrar, el nombre es ambiguo. Pase el identificador en su lugar; el comando acepta cualquiera de los dos, pero solo el identificador garantiza seleccionar un único servicio. Compruebe que la palabra de estado sea una que reconozca — normalmente Connected, Disconnected, Connecting o Disconnecting — antes de analizarla en un script. Compruebe también si el perfil está gestionado, porque una configuración bloqueada puede aceptar el comando y aun así ignorarlo o pedir confirmación.

Esta consulta de estado es barata, así que úsela como guarda en la automatización: inicie solo cuando el estado sea Disconnected y no trate Connecting como un fallo. Si el servicio ya está Connected, omita el inicio en lugar de interrumpir un túnel que funciona.

Inicie la conexión y espere a que el estado se asiente

La solicitud de inicio es asíncrona. El comando regresa cuando se ha aceptado la solicitud, no cuando termina la autenticación o se instalan las rutas. Ejecútelo y luego sondee el estado con una espera acotada, y salga si el servicio vuelve a Disconnected:

scutil --nc start "Office VPN"
n=0
while [ "$n" -lt 30 ]; do
  state=$(scutil --nc status "Office VPN" | head -n 1)
  [ "$state" = "Connected" ] && break
  [ "$state" = "Disconnected" ] && { echo "start failed"; exit 1; }
  sleep 2
  n=$((n + 1))
done

Un estado Connecting que nunca se resuelve suele apuntar a credenciales, MFA o al servidor, no a scutil. El comando no puede proporcionar un inicio de sesión interactivo, así que un perfil que espera un token o una clave de hardware se quedará en Connecting y acabará retrocediendo. Lea la palabra de estado antes de añadir reintentos; un bucle contra un aviso de autenticación no puede tener éxito.

No trate el estado de salida del shell como disponibilidad. La señal útil es la cadena de estado, seguida de la evidencia de que el túnel transporta tráfico. Un comando de inicio que vuelve en silencio todavía puede dejarlo con una conexión que nunca se autentica.

Demuestre que el túnel transporta tráfico, no solo que dice Connected

Connected describe la conexión, no la decisión de enrutamiento. Los servicios nativos PPP e IKEv2 crean una interfaz ppp o utun e instalan rutas, mientras que un túnel dividido deja deliberadamente intacta la ruta predeterminada. Inspeccione las interfaces y ambas familias de direcciones:

ifconfig -l
netstat -rn -f inet
netstat -rn -f inet6
scutil --dns

Encuentre la interfaz que creó el servicio en lugar de adivinar un número, y luego pregunte a la tabla de enrutamiento qué interfaz usa un destino concreto: route -n get 10.0.0.10, sustituyéndolo por un host interno. Si informa de la interfaz física, el túnel está activo pero no transporta ese flujo. Compruebe las rutas del túnel dividido, el orden de los resolutores y cualquier regla de cortafuegos local que permita la interfaz del túnel pero no el proceso.

La resolución de nombres es el falso negativo habitual. Los nombres internos pueden resolverse por el resolutor equivocado mientras el túnel está perfectamente sano, lo que parece un fallo de VPN y no lo es. scutil --dns muestra el orden que usará macOS; tras un cambio de resolutor, vacíe la caché con dscacheutil -flushcache y sudo killall -HUP mDNSResponder.

Mantenga las credenciales y los privilegios fuera de la línea de comandos

Nunca ponga una contraseña, una clave precompartida o un token en los argumentos. Los argumentos son visibles en las listas de procesos y acaban en el historial del shell, y una transcripción de soporte copiada puede filtrarlos. La propia gestión de credenciales del perfil — ya sea un elemento del Keychain, un aviso del sistema o el flujo de autenticación del cliente — es el lugar para los secretos.

Ejecutar el comando con sudo no hace que un inicio de sesión interactivo sea desatendido. Cambia el usuario efectivo, no la disponibilidad de un aviso GUI, de un token de hardware o del Keychain de inicio de sesión. Un LaunchAgent puede iniciar un servicio después de que el usuario inicie sesión y el Keychain esté desbloqueado; un LaunchDaemon normalmente no puede alcanzar esas piezas de la sesión del usuario. Si una organización gestiona el servicio, sus reglas de ciclo de vida prevalecen sobre cualquier script local.

Detenga el servicio y verifique que siguió detenido

Detenga con el mismo selector que usó para iniciar y luego vuelva a leer el estado en lugar de suponer que el túnel ha desaparecido:

scutil --nc stop "Office VPN"
scutil --nc status "Office VPN"

Una detención que vuelve a Disconnected todavía deja una cosa que comprobar: si el perfil está configurado para conectar bajo demanda, lo que puede devolverlo sin su script. Si otro cliente posee rutas en el mismo Mac, esas rutas pueden sobrevivir a una detención nativa. Vuelva a comprobar la ruta antes de concluir que la máquina está fuera de la VPN.

Para un envoltorio que ejecute a mano, mantenga el orden fijo: lista, estado, inicio, sondeo, prueba de ruta, detención, verificación. No analice el nombre amigable a partir de una salida de formato libre cuando el identificador esté disponible, y no trate la salida del comando de inicio como disponibilidad. El gestor de conexiones informa del estado; su prueba es el estado más una ruta que apunta al túnel.