Montar un recurso compartido desde Tunnelblick sin ejecutarse como root

El cliente VPN necesita ayuda privilegiada para reconfigurar la red, y ese hecho se aplica con demasiada amplitud a todo lo que lo rodea. Un script que monta un recurso compartido de archivos no necesita root, porque el recurso pertenece a la sesión del usuario conectado y a las credenciales de ese usuario. Sacar el montaje del camino privilegiado elimina la necesidad de reglas sudo, hooks de root y ediciones de aplicaciones incluidas. Lo que queda es un pequeño applet que permanece abierto, vigila un perfil y hace un solo intento.

Por qué esto pertenece a la sesión del usuario

Un volumen montado es una propiedad de la sesión que lo montó. La sesión de otro usuario no lo ve, y un montaje propiedad de root se comporta de forma distinta al que creó el Finder. Mantener el montaje en la sesión del usuario preserva esa semántica.

Los ayudantes privilegiados existen para las partes que realmente los necesitan: crear una interfaz de túnel, cambiar rutas, actualizar el resolutor. Montar un recurso SMB no es una de esas partes. Tratarlo como si lo fuera obliga a elegir entre sudo sin contraseña y un script de root que se ejecuta cuando no hay nadie. Ambos son riesgos mayores de lo que justifica el problema, y el enfoque de sesión de usuario evita la elección por completo.

Los hooks de conexión propios de Tunnelblick no son un sustituto aquí, ya que se ejecutan fuera de la sesión de escritorio y su orden respecto a los scripts del cliente no está definido. Consultar el estado desde un applet de usuario es un mecanismo más pequeño con menos suposiciones.

Demostrar primero a mano que el recurso funciona

La automatización no puede proporcionar una ruta, un permiso ni una cuenta que no exista. Conecta la VPN manualmente y abre el recurso en el Finder antes de escribir cualquier script. Si eso falla, el script fallará de una forma más confusa.

Anota los tres valores que usará el script: el nombre del perfil exactamente como lo lista Tunnelblick, la URL del recurso y el nombre del volumen que el Finder muestra tras montarlo. El nombre del volumen importa porque la comprobación de un montaje existente lo usa, y una comprobación solo por el nombre es una guarda de comodidad, no una prueba de la identidad del servidor. Usa un nombre único en la máquina. Después confirma que el servidor responde siquiera.

smbutil view //files.corp.example
osascript -e 'tell application "Tunnelblick" to get state of first configuration whose name is "Office"'
mount | grep -i smbfs

El primer comando demuestra que el servidor responde, el segundo que el nombre del perfil se resuelve, y el tercero muestra cómo es un montaje correcto. Registra los tres antes de automatizar nada.

Leer el estado del perfil desde Tunnelblick

Tunnelblick expone sus configuraciones y sus estados mediante AppleScript, y ese es el único hook que este diseño necesita. El estado que importa es la cadena que se informa para ese perfil concreto, no la presencia de la aplicación.

La consulta tiene consecuencias que vale la pena mencionar. Una reconexión más corta que el intervalo puede pasar inadvertida, y el applet no ve la transición en absoluto. Eso es aceptable para una guarda de montaje e inaceptable para cualquier cosa que deba reaccionar a cada evento. Si necesitas fidelidad de eventos, este es el mecanismo equivocado y no un mecanismo que necesite un temporizador más corto. Elige el intervalo con ese compromiso en mente.

property attempted : false

on idle
    set profileName to "Office"
    set shareURL to "smb://files.corp.example/OfficeTeam"
    set volName to "OfficeTeam"
    tell application "Tunnelblick" to set vpnState to state of first configuration whose name is profileName
    if vpnState is not "CONNECTED" then
        set attempted to false
        return 20
    end if
    tell application "Finder" to set mounted to (exists disk volName)
    if (not mounted) and (not attempted) then
        set attempted to true
        try
            mount volume shareURL
        end try
    end if
    return 20
end idle

Expórtalo como aplicación con la opción de permanecer abierta y luego lánzalo en la sesión conectada en lugar de mediante sudo.

Montar una vez y luego dejar de intentarlo

El indicador de intento es lo que impide que esto se convierta en un bucle que adivina credenciales. Una vez que el applet ha intentado, espera a que cambie el estado de conexión antes de volver a intentarlo.

Ese comportamiento es deliberado. Un recurso que rechaza el montaje suele rechazarlo por una razón que un reintento no puede corregir, y los intentos repetidos convierten una solicitud en un torrente de ellas. El indicador se reinicia cuando el perfil abandona el estado conectado, así que una reconexión real produce exactamente un intento nuevo. Salir y volver a iniciar el applet también lo reinicia, y esa es la anulación manual. Ninguno de los dos caminos oculta un fallo; ambos lo dejan visible en el Finder.

El script no lleva ninguna contraseña, y debería seguir así. Deja que la operación de montaje pregunte y deja que el llavero haga lo que la organización admita. Incrustar una credencial en una URL convierte un script de comodidad en un secreto que hay que rotar.

Qué no puede hacer el ayudante

Tres límites merecen escribirse junto al applet. No puede expulsar un volumen ocupado tras un fallo de red, no puede garantizar que el DNS y el servidor estén listos cuando el estado dice conectado, y no reacciona a cada reconexión.

El primer límite es el que más importa en la práctica. Un recurso cuyo servidor desaparece deja un volumen que parece montado y bloquea al acceder, y la corrección educada es terminar las operaciones de archivos y expulsar antes de una desconexión planificada. El segundo explica la mayoría de los primeros intentos fallidos: el túnel está levantado mientras el resolutor aún no ha llegado, así que espera y luego monta una vez a mano para confirmarlo. El tercero es el compromiso de consulta ya mencionado, no un error que haya que corregir.

Para una máquina sin supervisión o una flota gestionada, este diseño tiene la forma equivocada. Usa una política de montaje propiedad del administrador en lugar de extender un applet de escritorio a servicio privilegiado.