O perfil OpenVPN de Windows falla en Ubuntu: tres capas

Inicie o mesmo perfil desde o terminal e a mensaxe que case todos copian é un aviso, non a razón pola que o cliente se detivo. Aquí fallan tres capas independentes: unha directiva enviada que a compilación de Linux non implementa, os dereitos necesarios para crear un dispositivo tun e o axudante de resolución que converte unha conexión nun DNS funcional. Recórreas en orde, porque cada unha pode ocultar a seguinte.

Conserve a descarga tal como chegou e edite unha copia, para que unha descarga nova non reverta os seus cambios en silencio.

Lea o aviso antes de culparlo

block-outside-dns bloquea o DNS en Windows mediante a Plataforma de filtrado de Windows, e o cliente de Linux non ten con que asociarlo. Cando o servidor o envía, o cliente imprime unha liña de opción non recoñecida para esa entrada enviada e continúa, porque unha opción enviada non se trata como fatal. A liña idéntica no seu propio ficheiro é outra cousa: alí o analizador detense. Decida cal das dúas ten antes de tocar nada, porque só unha delas remata a execución.

Para quitar o ruído, fíltreo antes de analizar: unha entrada pull-filter ignore para ese nome, ou --ignore-unknown-option cando a liña está no ficheiro local. Ambas silencian unha liña que xa leu; ningunha repara unha falla que non diagnosticou.

Os privilexios fallan antes ca calquera outra cousa

Un dispositivo tun e as rutas que o acompañan son obxectos privilexiados, e unha conta normal non pode crealos. A opción --user explica esa división: o daemon cede os seus privilexios só despois de que o traballo privilexiado está feito. Inícieo como root, ou mediante unha unit que o inicie así, e despois busque un erro de permisos antes de mirar os certificados. Relaxar os permisos do ficheiro do perfil non lle dá ao proceso os dereitos que lle faltan.

Un erro de TLS significa que o cliente superou esta capa. Unha queixa sobre o dispositivo ou a ruta significa que nunca chegou á capa de arriba.

O que fai a GUI e o terminal non

Conectarse con éxito mentres todas as consultas seguen fallando é a terceira capa. NetworkManager fai o seu propio traballo de resolución, e por iso unha importación de escritorio pode repartir DNS mesmo cando o script up do perfil nunca se executou con éxito. A orde openvpn --config executa o que nomee --up, e se ese axudante non está, a interface aparece mentres as consultas seguen indo aos servidores anteriores. Compare os scripts dos dous camiños antes de instalar nada.

Use o axudante empaquetado para a súa distribución; un script copiado dunha entrada de blog adoita apuntar a outro resolutor. A integración que se distribúe para systemd-resolved non é o script xenérico ao estilo vpnc, e cada unha espera os seus propios argumentos e variables do cliente. Os scripts up definidos polo usuario tamén requiren script-security 2 antes de que o cliente os execute.

Separe as capas na próxima execución

Execute unha vez con --verb 4 e lea o rexistro na orde en que ocorreu: creación do dispositivo, rutas, aperto de mans TLS e despois a saída do script up. O primeiro fallo desa secuencia é o que paga a pena corrixir; todo o que vén despois adoita ser unha consecuencia. Un túnel que se establece mentres o resolutor non o fai sitúao na terceira capa, onde o certificado é irrelevante. Deixe intacto o perfil descargado mentres compara.

Cando cada axuste do operador produce outra liña rexeitada, o ficheiro apunta a outra plataforma. Pida unha exportación para Linux en lugar de construír unha lista de filtros permanente.

Anote que capa fallou e que a cambiou, porque a seguinte persoa que reciba o mesmo ficheiro, se non, tamén se deterá no aviso.