Portabilidad del perfil OpenVPN: claves portables frente a opciones de plataforma

El mismo archivo .ovpn abre un túnel en un cliente y no arranca en otro, y el certificado suele ser el primer sospechoso. Lo más habitual es que el archivo contenga una directiva que solo implementa un motor. Un perfil es un contrato con un cliente concreto, no un script portable.

Separe lo que viaja con la identidad de lo que pertenece a una plataforma. Entonces el fallo suele nombrarse solo.

Un archivo, dos contratos

Un perfil agrupa tres tipos de contenido: material de identidad como los certificados de CA y de cliente y la clave privada, datos de transporte como el extremo remoto y el protocolo, y directivas de comportamiento como el manejo de DNS o las opciones de dispositivo. Los dos primeros son ampliamente portables entre motores que admiten el mismo protocolo. El tercero es donde las implementaciones divergen. Tratar todo el archivo como una unidad portable es lo que produce los fallos confusos.

Un archivo que funciona en una GUI en una plataforma no es automáticamente válido para el cliente de línea de comandos en otra. Incluso cuando ambos son OpenVPN, los analizadores y los conjuntos de opciones difieren. Por eso una importación correcta no es prueba de un perfil portable.

Material portable frente a directivas de plataforma

Las secciones de identidad y transporte son la parte que hay que conservar. ca, cert, key y remote describen quién se conecta y adónde, y significan lo mismo para cualquier cliente conforme.

Las directivas de comportamiento son la parte que hay que comparar. block-outside-dns, por ejemplo, existe para cambiar el comportamiento de DNS en Windows. Puede que un cliente Unix no la reconozca en absoluto.

Lea la lista de opciones del cliente receptor en lugar de la del emisor. El manual de referencia de OpenVPN 2.6 documenta las opciones del motor, y el diálogo de importación de una GUI no es esa lista.

Lea el error del analizador antes que el certificado

Un error que nombra una opción no reconocida es un fallo del analizador, no un fallo de autenticación. La conexión nunca llegó a TLS, así que cambiar los certificados no puede ayudar. Lea el primer error del cliente y la versión reales y luego elimine o sustituya solo la directiva que ese cliente no puede implementar. Borrar secciones de certificado o de rutas para que el archivo cargue es la forma en que un perfil que funciona se vuelve inseguro.

Si el error menciona el handshake, un certificado o un cifrado, el perfil se analizó y el problema está en otro sitio.

Guarde el archivo original junto al adaptado. Cuando el archivo adaptado falle más adelante, el original es el control que indica si se movió el cambio o el entorno.

Los privilegios son una segunda frontera

Los privilegios son la otra frontera: crear un dispositivo de túnel, instalar rutas y leer una clave privada dependen todos de permisos locales. Un archivo de clave legible solo por root es un despliegue normal, no un defecto del perfil. La corrección pertenece a la propiedad o a las capacidades, no al archivo.

Ejecutar el cliente con sudo puede resolver una denegación de permisos local, y no puede añadir una directiva que el binario no implementa. También cambia qué llavero, rutas de configuración y contexto del gestor de red se aplican, así que el resultado no es la misma prueba.

Adapte con criterio

Cuando un proveedor publica perfiles separados, tome el destinado al cliente receptor. Adaptar el archivo de otra plataforma es el último recurso. Requiere un registro de cada opción cambiada y una copia del original.

Pruebe identidad, enrutamiento y DNS como tres resultados separados. Un perfil que se autentica y enruta pero rompe la resolución de nombres es un perfil parcialmente adaptado, no uno que funciona.