Montar un recurso compartido desde Tunnelblick sen executarse como root

O cliente VPN necesita axuda privilexiada para reconfigurar a rede, e ese feito aplícase con demasiada amplitude a todo o que o rodea. Un script que monta un recurso compartido de ficheiros non necesita root, porque o recurso pertence á sesión do usuario conectado e ás credenciais dese usuario. Sacar a montaxe do camiño privilexiado elimina a necesidade de regras sudo, hooks de root e edicións de aplicacións incluídas. O que queda é un pequeno applet que permanece aberto, vixía un perfil e fai un só intento.

Por que isto pertence á sesión de usuario

Un volume montado é unha propiedade da sesión que o montou. A sesión doutro usuario non o ve, e unha montaxe propiedade de root compórtase de xeito distinto á que creou o Finder. Manter a montaxe na sesión de usuario preserva esa semántica.

Os axudantes privilexiados existen para as partes que realmente os necesitan: crear unha interface de túnel, cambiar rutas, actualizar o resolvedor. Montar un recurso SMB non é unha desas partes. Tratalo como se o fose obriga a elixir entre sudo sen contrasinal e un script de root que se executa cando non hai ninguén. Ambos son riscos maiores do que xustifica o problema, e o enfoque de sesión de usuario evita a elección por completo.

Os hooks de conexión propios de Tunnelblick non son un substituto aquí, xa que se executan fóra da sesión de escritorio e a súa orde respecto aos scripts do cliente non está definida. Consultar o estado desde un applet de usuario é un mecanismo máis pequeno con menos suposicións.

Demostrar primeiro a man que o recurso funciona

A automatización non pode proporcionar unha ruta, un permiso nin unha conta que non exista. Conecta a VPN manualmente e abre o recurso no Finder antes de escribir calquera script. Se iso falla, o script fallará dun xeito máis confuso.

Anota os tres valores que usará o script: o nome do perfil exactamente como o lista Tunnelblick, o URL do recurso e o nome do volume que o Finder mostra tras montalo. O nome do volume importa porque a comprobación dunha montaxe existente o usa, e unha comprobación só polo nome é unha garda de comodidade, non unha proba da identidade do servidor. Usa un nome único na máquina. Despois confirma que o servidor responde, cando menos.

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

O primeiro comando proba que o servidor responde, o segundo que o nome do perfil se resolve, e o terceiro mostra como é unha montaxe correcta. Rexistra os tres antes de automatizar nada.

Ler o estado do perfil desde Tunnelblick

Tunnelblick expón as súas configuracións e os seus estados mediante AppleScript, e ese é o único hook que este deseño necesita. O estado que importa é a cadea que se informa para ese perfil concreto, non a presenza da aplicación.

A consulta ten consecuencias que paga a pena mencionar. Unha reconexión máis curta que o intervalo pode pasar desapercibida, e o applet non ve a transición en absoluto. Iso é aceptable para unha garda de montaxe e inaceptable para calquera cousa que deba reaccionar a cada evento. Se necesitas fidelidade de eventos, este é o mecanismo equivocado e non un mecanismo que necesite un temporizador máis curto. Escolle o 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órtao como aplicación coa opción de permanecer aberta e despois lánzao na sesión conectada en lugar de mediante sudo.

Montar unha vez e despois deixar de tentar

O indicador de tentativa é o que impide que isto se converta nun bucle que adiviña credenciais. Unha vez que o applet tentou, espera a que cambie o estado de conexión antes de tentalo de novo.

Ese comportamento é deliberado. Un recurso que rexeita a montaxe adoita rexeitala por unha razón que un reintento non pode corrixir, e os intentos repetidos converten unha solicitude nun torrente delas. O indicador restablécese cando o perfil abandona o estado conectado, así que unha reconexión real produce exactamente unha tentativa nova. Saír e volver iniciar o applet tamén o restablece, e esa é a anulación manual. Ningún dos dous camiños agocha un fallo; ambos o deixan visible no Finder.

O script non leva ningún contrasinal, e debería seguir así. Deixa que a operación de montaxe pregunte e deixa que o chaveiro faga o que a organización admite. Incrustar unha credencial nun URL converte un script de comodidade nun segredo que hai que rotar.

Que non pode facer o axudante

Tres límites merecen escribirse xunto ao applet. Non pode expulsar un volume ocupado tras un fallo de rede, non pode garantir que o DNS e o servidor estean listos cando o estado di conectado, e non reacciona a cada reconexión.

O primeiro límite é o que máis importa na práctica. Un recurso cuxo servidor desaparece deixa un volume que parece montado e bloquea ao acceder, e a corrección educada é rematar as operacións de ficheiros e expulsar antes dunha desconexión planificada. O segundo explica a maioría dos primeiros intentos fallidos: o túnel está levantado mentres o resolvedor aínda non chegou, así que espera e despois monta unha vez a man para confirmar. O terceiro é o compromiso de consulta xa mencionado, non un erro que haxa que corrixir.

Para unha máquina sen supervisión ou unha frota xestionada, este deseño ten a forma equivocada. Usa unha política de montaxe propiedade do administrador en lugar de estender un applet de escritorio a servizo privilexiado.