Portabilidade do perfil OpenVPN: claves portables fronte a opcións de plataforma

O mesmo ficheiro .ovpn abre un túnel nun cliente e non arrinca noutro, e o certificado adoita ser o primeiro sospeitoso. Máis a miúdo o ficheiro contén unha directiva que só implementa un motor. Un perfil é un contrato cun cliente concreto, non un script portable.

Separe o que viaxa coa identidade do que pertence a unha plataforma. Entón o fallo adoita nomearse só.

Un ficheiro, dous contratos

Un perfil agrupa tres tipos de contido: material de identidade como os certificados CA e de cliente e a clave privada, datos de transporte como o extremo remoto e o protocolo, e directivas de comportamento como o manexo de DNS ou as opcións de dispositivo. Os dous primeiros son amplamente portables entre motores que admiten o mesmo protocolo. O terceiro é onde as implementacións diverxen. Tratar todo o ficheiro como unha unidade portable é o que produce os fallos confusos.

Un ficheiro que funciona nunha GUI nunha plataforma non é automaticamente válido para o cliente de liña de ordes noutra. Mesmo cando ambos son OpenVPN, os analizadores e os conxuntos de opcións difiren. Por iso unha importación correcta non é proba dun perfil portable.

Material portable fronte a directivas de plataforma

As seccións de identidade e transporte son a parte que hai que conservar. ca, cert, key e remote describen quen se conecta e a onde, e significan o mesmo para calquera cliente conforme.

As directivas de comportamento son a parte que hai que comparar. block-outside-dns, por exemplo, existe para cambiar o comportamento de DNS en Windows. Pode que un cliente Unix non a recoñeza en absoluto.

Lea a lista de opcións do cliente receptor en lugar da do emisor. O manual de referencia de OpenVPN 2.6 documenta as opcións do motor, e o diálogo de importación dunha GUI non é esa lista.

Lea o erro do analizador antes ca o certificado

Un erro que nomea unha opción non recoñecida é un fallo do analizador, non un fallo de autenticación. A conexión nunca chegou a TLS, así que cambiar os certificados non pode axudar. Lea o primeiro erro do cliente e da versión reais e despois elimine ou substitúa só a directiva que ese cliente non pode implementar. Borrar seccións de certificado ou de rutas para que o ficheiro cargue é a forma en que un perfil que funciona se volve inseguro.

Se o erro menciona o handshake, un certificado ou un cifrado, o perfil analizouse e o problema está noutro sitio.

Garde o ficheiro orixinal xunto ao adaptado. Cando o ficheiro adaptado falle máis adiante, o orixinal é o control que indica se se moveu o cambio ou a contorna.

Os privilexios son unha segunda fronteira

Os privilexios son a outra fronteira: crear un dispositivo de túnel, instalar rutas e ler unha clave privada dependen todos de permisos locais. Un ficheiro de clave lexible só por root é un despregamento normal, non un defecto do perfil. A corrección pertence á propiedade ou ás capacidades, non ao ficheiro.

Executar o cliente con sudo pode resolver unha denegación de permisos local, e non pode engadir unha directiva que o binario non implementa. Tamén cambia que chaveiro, rutas de configuración e contexto do xestor de rede se aplican, así que o resultado non é a mesma proba.

Adapte con criterio

Cando un provedor publica perfís separados, tome o destinado ao cliente receptor. Adaptar o ficheiro doutra plataforma é o último recurso. Require un rexistro de cada opción cambiada e unha copia do orixinal.

Probe identidade, encamiñamento e DNS como tres resultados separados. Un perfil que se autentica e encamiña pero rompe a resolución de nomes é un perfil parcialmente adaptado, non un que funciona.