Niveles de script-security de OpenVPN del 0 al 3, y qué desbloquea cada uno

Importa un perfil en un cliente de escritorio y el primer fallo suele ser una línea que el cliente se niega a cumplir: un hook de script que no ejecutará, o un valor de script-security que considera demasiado permisivo. Subir el número hace desaparecer el diálogo. También amplía qué puede ejecutar ese perfil en tu máquina, que es algo extraño de conceder solo para cerrar un aviso. Sigue la importación hasta la directiva y la decisión se vuelve concreta.

Del diálogo de importación a la directiva

El perfil es un archivo de texto con directivas, y el cliente las lee antes de que exista ningún túnel. Una directiva como up, down o tls-verify nombra un programa externo que OpenVPN debe ejecutar en un momento definido. Si OpenVPN está dispuesto a ejecutarlo es un ajuste aparte llamado script-security, y el perfil normalmente también lo fija.

Así que el aviso no trata de criptografía ni de certificados. Trata de un archivo de configuración que pide al cliente ejecutar algo en el host, y del cliente comprobando si su nivel de permisos actual permite esa petición.

Dos fallos distintos parecen iguales en esta etapa. Un perfil que pide un nivel que el cliente no concederá produce un rechazo. Un perfil que pide un nivel que el cliente concede pero falta el script produce un fallo en tiempo de ejecución, y los dos se confunden en los hilos de soporte. Uno es una cuestión de permisos y el otro una cuestión de empaquetado.

Qué abre realmente cada nivel

El nivel 0 prohíbe por completo las llamadas a programas externos, lo que es coherente para un cliente que configura su propia interfaz sin ayuda e incoherente para uno que recurre al sistema operativo. El nivel 1, el predeterminado, permite los ejecutables integrados que necesitan la configuración de interfaz y de rutas. Ninguno de los dos ejecuta nada que haya aportado el usuario.

El nivel 2 es la frontera interesante, porque admite scripts definidos por el usuario. A partir de ese punto los privilegios del cliente se aplican a código que quizá nunca hayas leído, invocado en momentos que no elegiste, con un entorno que incluye detalles de la conexión. El nivel 3 va más allá y permite pasar contraseñas mediante variables de entorno, por eso el manual lo describe como potencialmente inseguro.

Ninguno de estos números es un ajuste de fuerza. Un perfil en el nivel 3 no tiene mejor cifrado que uno en el nivel 1; simplemente tiene una superficie de ejecución mayor, y el túnel es idéntico.

Decide qué merece el perfil

Pregunta para qué sirve el script antes de preguntar qué nivel necesita. Un hook que empuja la configuración de DNS o repara una ruta tras conectar es un motivo legítimo para ejecutar algo. Un hook que llama a un binario desconocido en un directorio temporal es un motivo para parar.

La ruta del script importa tanto como el script. Una ruta relativa se resuelve contra el directorio que use el cliente, y un directorio escribible convierte una importación puntual en un punto de ejecución permanente. Las rutas absolutas en un directorio que el usuario no puede modificar son la forma que conviene preferir.

Los scripts también heredan el entorno del cliente, donde viven las credenciales y los metadatos de conexión. Esa herencia es justo lo que hace peligroso el nivel 3 combinado con un script que registra su entorno, y es la razón por la que un volcado de diagnóstico de un cliente con scripts merece un segundo vistazo antes de pegarlo en un tiquete. Limpia el entorno antes de compartirlo.

grep -nE 'script-security|^up |^down |tls-verify' client.ovpn

Cambia una cosa y luego observa también el desmontaje

Si el perfil necesita de verdad un script, cambia solo el nivel y solo para ese perfil. Ejecuta el cliente en primer plano con salida detallada para que los errores del propio script sean visibles en lugar de quedar tragados por un gestor de servicios.

openvpn --config client.ovpn --script-security 2 --verb 3
ip route show default

Prueba todo el ciclo de vida, no solo la conexión. Un hook de bajada que falla deja rutas apuntando a un túnel muerto, lo que produce una máquina que parece conectada y no llega a nada. Reconecta una vez y desconecta una vez antes de dar el cambio por terminado, y revisa la tabla de enrutamiento después de cada uno.

Guarda una copia del perfil original. Si un cliente de plataforma no implementa el mismo modelo de scripts, borrar directivas hasta que la importación funcione puede eliminar la integración de DNS o de rutas que el túnel necesitaba, y la conexión resultante se autenticará perfectamente mientras no resuelve nada.

La decisión que hay que registrar es estrecha: qué script, en qué ruta, concedido a qué nivel, para qué perfil. Todo lo demás del perfil queda igual, y eso es una frase que un revisor puede verificar.