¿Hook de cliente o hook de servidor? Dónde se ejecuta un script de OpenVPN

La tarea está clara: cuando un portátil se conecta, algo en el portátil debería cambiar. La configuración que se edita pertenece al servidor, y ahí es donde se rompe la suposición. Una ruta en un archivo del servidor nombra un archivo en ese servidor, y ninguna cantidad de push cambia qué proceso lo ejecuta. Elegir entre los dos hooks es sobre todo decidir qué máquina es dueña del trabajo y aceptar los límites que se derivan.

Dos máquinas, dos preguntas que responder primero

Pregunte dónde debe ocurrir el cambio de estado y luego qué evento le corresponde. Si el cambio es una autorización por usuario o una decisión de configuración por cliente, pertenece a donde se conoce el directorio de usuarios: el servidor. Si el cambio es una ruta, un ajuste del resolutor o un ayudante local en un extremo, pertenece al extremo, y solo el extremo puede hacerlo.

Responder esas dos preguntas en el orden inverso es como la gente acaba intentando empujar un archivo por lotes a un portátil con Windows. El servidor sabe quién se conectó; el portátil sabe cómo es su propia pila de red. Ninguno tiene la información del otro, y el intento suele fallar en silencio en lugar de con un error claro.

Antes de ambas vale la pena una tercera pregunta: ¿la plataforma siquiera ofrece el hook que quiere? Un dispositivo que genera su propia configuración puede no ofrecer los mismos nombres de eventos, y un cliente de escritorio que importa un archivo .ovpn no es necesariamente el mismo cliente para el que se escribió el archivo. Confirmar la plataforma primero le ahorra diseñar alrededor de un hook que no existe allí. También le dice qué documentación se aplica realmente a la máquina que tiene delante.

La opción del lado del servidor: un evento por conexión

Un script client-connect se ejecuta en el contexto del proceso del servidor cuando se conecta un cliente autenticado, y recibe detalles de conexión documentados como el common name y la dirección asignada. Es el lugar correcto para escribir un fragmento de configuración por cliente, aplicar una decisión de política o registrar estado que el servidor posee.

La distinción que la gente pasa por alto es la diferencia entre ese hook y un hook up del servidor. El hook up se dispara cuando el servidor abre su dispositivo de túnel, lo que en un servidor con varios clientes ocurre una vez al arrancar el demonio. No es un evento por inicio de sesión, y el código colocado allí se ejecuta cuando arranca el servicio, no cuando se conectan los usuarios.

En un dispositivo con interfaz web, use el mecanismo de extensión admitido en lugar de editar archivos del demonio generados. Los archivos generados se reescriben en el siguiente guardado, y la reescritura elimina su cambio en silencio en el peor momento posible. Guarde una copia del texto de la extensión fuera del dispositivo para que una actualización de firmware no pierda también la intención.

La opción del lado del cliente: trabajo que debe ejecutarse localmente

Un cliente de la comunidad puede ejecutar un script local cuando aparece el dispositivo de túnel y de nuevo cuando se instalan las rutas. Son dos momentos distintos, y elegir el equivocado produce la clásica carrera en la que un ayudante arranca antes de que exista la ruta de la que depende.

El ayudante debe existir en ese cliente, ser legible y ejecutable por la cuenta que ejecuta el cliente, y estar permitido por un ajuste explícito de script-security. Un script que funciona cuando se lanza el cliente como administrador no dice nada sobre un servicio previo al inicio de sesión ni sobre la sesión de otro usuario.

Los nombres también importan. El hook up corresponde a la creación del dispositivo y route-up a la instalación de rutas, pero una tarea que necesita que una red privada sea alcanzable debe verificar la alcanzabilidad en lugar de suponer que la creación del dispositivo implica que cada ruta, entrada de resolutor y aplicación están listas.

Por qué empujar código ejecutable no está en el menú

Las opciones empujadas con push están restringidas a propósito, y las opciones que ejecutan scripts están entre las categorías que el servidor no puede entregar. Esa restricción existe porque la alternativa permitiría que un servidor comprometido o mal configurado ejecutara comandos arbitrarios en cada cliente que se conecte alguna vez.

Habilitar la ejecución de scripts localmente no cambia eso. Su ajuste de script-security permite scripts locales que usted eligió; no autoriza al servidor a suministrar nuevos.

Si el objetivo es simplemente instalar rutas VPN, use la configuración de rutas admitida en lugar de inventar un esquema de ejecución remota. Si el objetivo realmente requiere código local, distribúyalo mediante las herramientas de gestión de extremos de la organización y revíselo como cualquier otro software que se ejecuta con los privilegios del usuario.

Qué verificar antes de confiar en cualquiera de los dos hooks

Anote cuatro cosas por cada hook: la máquina, el nombre del evento, la cuenta con la que se ejecuta y el cambio de estado que debe producir. Después pruebe la conexión, una reconexión y la ruta de limpieza, porque un hook que filtra estado al reconectar es peor que uno que nunca se ejecutó.

Pruebe con la cuenta que realmente lo ejecutará, en el momento en que realmente se ejecute. El manual openvpn(8) documenta ambas familias de hooks y las restricciones del push; la plataforma en la que despliegue documenta si las expone o no. Un script que tiene éxito en una terminal de administrador interactiva es una hipótesis, no una verificación.