O perfil .ovpn antigo falla en Ubuntu 24.04: que liñas hai que borrar
Ubuntu 24.04 incorpora OpenVPN 2.6 e un perfil exportado para a 2.4 morre en opcións eliminadas. Borre keysize e ncp-disable e despois corrixa ns-cert-type.
O perfil descárgase, impórtase e despois detense na liña 12 do ficheiro cunha mensaxe Unrecognized option que nomea keysize. Nada da conta cambiou e o servidor segue aceptando outros clientes. O que cambiou é o propio cliente: Ubuntu 24.04 instala OpenVPN 2.6, mentres que a exportación se escribiu para a 2.4. A reparación é unha serie curta de borrados, e a orde importa porque cada opción obsoleta aborta a análise antes de que a seguinte chegue a lerse.
Lea a liña do erro antes de tocar o ficheiro
OpenVPN nomea o ficheiro e a liña onde se detivo a análise, así que só pode arranxar un problema por execución. Arranque o perfil desde un terminal en lugar dun applet de escritorio, porque o applet adoita tragar stderr e o número de liña é a única pista fiable que recibe: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Corrixa esa liña, execute de novo e espere que o seguinte fallo nomee outra opción.
Un erro de análise aparece sempre antes de calquera handshake TLS, así que unha mensaxe que menciona un certificado xa superou a fase de sintaxe. Esa distinción evítalle editar un ficheiro que só falla na autenticación. Lea a primeira palabra da mensaxe en lugar da súa metade.
Tres clases de fallo, tres reparacións distintas
As exportacións antigas fallan de tres maneiras distinguibles, e xusto fundilas nun só problema é o que leva a xente a reinstalar paquetes que nunca estiveron rotos. A redacción da mensaxe dille en que clase está antes de abrir o ficheiro.
- Os erros de análise nomean un ficheiro e unha liña, e detéñense antes de que exista tráfico.
- Os erros de negociación conectan e despois informan de que os dous extremos non lograron acordar un cifrado compartido ou unha canle de datos aceptable.
- Os erros de autenticación chegan máis lonxe e nomean un certificado, un usuario ou unha credencial rexeitada.
Editar o perfil só arranxa a primeira clase. A negociación necesita unha decisión nos dous extremos do túnel, e unha credencial rexeitada non é en absoluto un problema de sintaxe. Se a súa mensaxe menciona un cifrado compartido ou unha canle de datos, os borrados de abaixo non cambiarán nada.
Borre as opcións que a 2.6 eliminou, nesta orde
Cada unha destas liñas detén a análise por si soa, así que o cliente as informa dunha en unha. Percorra a lista e volva executar tras cada borrado.
Borre primeiro keysize, porque non ten equivalente moderno e a súa presenza adoita marcar un cifrado que o cliente actual rexeita de todos os xeitos. Despois borre ncp-disable, que controlaba a negociación de cifrados, quedou obsoleto na 2.5 e xa non existe na 2.6. Substitúa ns-cert-type server por remote-cert-tls server, que expresa a mesma intención mediante unha comprobación admitida. O historial de cambios da 2.6 enumera as eliminacións restantes xunto coas súas substitucións, así que todo o que o analizador siga rexeitando ten unha resposta documentada.
Garde unha copia do perfil orixinal antes da primeira edición. Os provedores rexeneran as exportacións, e un diff contra o ficheiro intacto é a forma máis rápida de separar os seus cambios dos deles. Se un borrado permite que o cliente arranque pero o túnel segue fallando, xa pasou á clase de negociación e as liñas restantes non son a causa. Pon a versión do cliente no nome do ficheiro para que a seguinte persoa saiba a que versión apuntan as edicións.
Manteña BF-CBC só como alternativa acoutada
Algúns provedores seguen terminando en BF-CBC, co que OpenVPN 2.6 non negociará sen axuda porque o cifrado ten un bloque de 64 bits. A reparación estreita é unha lista de alternativas máis o provedor herdado de OpenSSL, non unha degradación de todo o cliente.
providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC
A primeira liña carga o provedor herdado para que OpenSSL aínda poida instanciar ese cifrado, a segunda conserva a negociación moderna para os pares que a admiten, e a terceira só se aplica cando o servidor non ofrece nada mellor. É un debilitamento deliberado do túnel, así que anote por que existe xunto ao ficheiro. Pida ao provedor unha exportación rexenerada ao mesmo tempo, porque a alternativa é unha ponte e non un destino.
Non recorra a --compat-mode como resposta universal. Cambia varios comportamentos á vez, incluídos os valores por defecto de negociación e renegociación, así que nunca saberá que cambio foi o importante. Prefira as tres liñas explícitas de arriba, porque cada unha declara o seu propio efecto.
Verifique co perfil que o cliente carga de verdade
As conexións importadas adoitan copiarse a un directorio do sistema, así que editar o ficheiro do seu cartafol de descargas pode non cambiar absolutamente nada. Atope a copia que se executa: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Despois arranque o túnel e lea a liña do rexistro que informa de que cifrado da canle de datos se escolleu realmente. Unha conexión que completa o handshake coa alternativa dille que o servidor nunca ofreceu nada moderno.
Probe desde unha rede que non sexa a que o provedor espera, para que un portal cativo ou unha rede de convidados filtrada non se disfracen de fallo do perfil. Anote a versión do cliente xunto a calquera solicitude de asistencia.
Unha vez que o túnel estea levantado, envía unha solicitude que deba cruzalo e outra que non deba, e logo confirme que a resposta do resolutor cambiou como esperaba. Se o perfil xa se analiza pero a conexión segue fallando, deixou atrás o problema de sintaxe e o texto do erro nomeará a nova clase. Manteña o ficheiro editado no control de versións xunto a unha nota que nomee a versión de OpenVPN á que apunta.