El perfil OpenVPN de Windows falla en Ubuntu: tres capas

Inicie el mismo perfil desde la terminal y el mensaje que casi todos copian es un aviso, no la razón por la que el cliente se detuvo. Aquí fallan tres capas independientes: una directiva enviada que la compilación de Linux no implementa, los derechos necesarios para crear un dispositivo tun y el ayudante de resolución que convierte una conexión en un DNS funcional. Recórralas en orden, porque cada una puede ocultar la siguiente.

Conserve la descarga tal como llegó y edite una copia, para que una descarga nueva no revierta sus cambios en silencio.

Lea el aviso antes de culparlo

block-outside-dns bloquea el DNS en Windows mediante la Plataforma de filtrado de Windows, y el cliente de Linux no tiene con qué asociarlo. Cuando el servidor lo envía, el cliente imprime una línea de opción no reconocida para esa entrada enviada y continúa, porque una opción enviada no se trata como fatal. La línea idéntica en su propio archivo es otra cosa: allí el analizador se detiene. Decida cuál de las dos tiene antes de tocar nada, porque solo una de ellas termina la ejecución.

Para quitar el ruido, fíltrelo antes de analizar: una entrada pull-filter ignore para ese nombre, o --ignore-unknown-option cuando la línea está en el archivo local. Ambas silencian una línea que ya leyó; ninguna repara una falla que no haya diagnosticado.

Los privilegios fallan antes que cualquier otra cosa

Un dispositivo tun y las rutas que lo acompañan son objetos privilegiados, y una cuenta normal no puede crearlos. La opción --user explica esa división: el demonio cede sus privilegios solo después de que el trabajo privilegiado está hecho. Inícielo como root, o mediante una unit que lo inicie así, y luego busque un error de permisos antes de mirar los certificados. Relajar los permisos del archivo del perfil no da al proceso los derechos que le faltan.

Un error de TLS significa que el cliente superó esta capa. Una queja sobre el dispositivo o la ruta significa que nunca llegó a la capa de arriba.

Lo que hace la GUI y el terminal no

Conectarse con éxito mientras todas las consultas siguen fallando es la tercera capa. NetworkManager hace su propio trabajo de resolución, y por eso una importación de escritorio puede repartir DNS incluso cuando el script up del perfil nunca se ejecutó con éxito. La orden openvpn --config ejecuta lo que nombre --up, y si ese ayudante no está, la interfaz aparece mientras las consultas siguen yendo a los servidores anteriores. Compare los scripts de ambos caminos antes de instalar nada.

Use el ayudante empaquetado para su distribución; un script copiado de una entrada de blog suele apuntar a otro resolutor. La integración que se distribuye para systemd-resolved no es el script genérico al estilo vpnc, y cada una espera sus propios argumentos y variables del cliente. Los scripts up definidos por el usuario también requieren script-security 2 antes de que el cliente los ejecute.

Separe las capas en la próxima ejecución

Ejecute una vez con --verb 4 y lea el registro en el orden en que ocurrió: creación del dispositivo, rutas, apretón de manos TLS y luego la salida del script up. El primer fallo de esa secuencia es el que vale la pena corregir; todo lo que viene después suele ser una consecuencia. Un túnel que se establece mientras el resolutor no lo hace lo sitúa en la tercera capa, donde el certificado es irrelevante. Deje intacto el perfil descargado mientras compara.

Cuando cada ajuste del operador produce otra línea rechazada, el archivo apunta a otra plataforma. Pida una exportación para Linux en lugar de construir una lista de filtros permanente.

Anote qué capa falló y qué la cambió, porque la siguiente persona que reciba el mismo archivo, si no, también se detendrá en el aviso.