Por que OpenVPN deixou de conectar tras actualizar Ubuntu?

Os perfís VPN que funcionaban a semana pasada rompen tras unha actualización de versión de Ubuntu, e o rexistro raramente menciona a actualización. O que si nomea é a capa que fallou: o aperto de mans TLS, o cifrado negociado para a canle de datos, o paquete instalado ou a copia de OpenSSL que o binario carga ao arrincar. Cada capa ten a súa forma de erro e a súa reparación, polo que clasificar é o primeiro traballo e editar o segundo. Trate o perfil como inocente ata que o rexistro o nomee.

Que capa fallou: aperto de mans, cifrado, paquete ou biblioteca

Lea o rexistro do cliente antes de tocar o perfil. O primeiro erro da saída é o que identifica a capa; todo o impreso despois adoita ser consecuencia dese primeiro fallo. Cando o cliente non arrinca en absoluto, o rexistro de VPN é o ficheiro equivocado para abrir.

As queixas sobre certificados e sinaturas, ou unha mensaxe sobre a lonxitude da clave, veñen da canle de control e da política de biblioteca que o rexe. Un aviso que comeza con DEPRECATED OPTION pertence, en cambio, á negociación da canle de datos.

Unha liña do tipo Unrecognized option é unha terceira categoría: o binario novo xa non acepta unha directiva que o vello toleraba, así que hai que reescribir o perfil e non relaxar a biblioteca. Os fallos de empaquetado vense outra vez distintos porque ocorren antes de que se execute calquera código de túnel. Un binario ausente, un complemento que non carga ou un repositorio que apunta a un nome en clave equivocado producen todos esa forma. Catro síntomas, catro lugares onde mirar e case ningún solapamento entre as reparacións.

Cando falla o aperto de mans, a política TLS rexeita o certificado

Ubuntu 22.04 pasou o sistema a OpenSSL 3, e o nivel de seguridade predeterminado desa rama é máis estrito coas sinaturas de certificados e os tamaños de clave do que era 20.04. Un certificado de CA asinado cun resumo máis antigo, ou unha clave por baixo do limiar actual, agora fallan durante o aperto de mans. Como aínda non se autenticou nada, o erro lese como un contrasinal incorrecto ou un servidor morto.

A reparación estreita engade unha cadea de cifrado só a esta conexión. No editor de escritorio, abra o perfil, vaia á configuración avanzada e poña DEFAULT:@SECLEVEL=0 no campo de cifrado TLS. O ficheiro de claves de NetworkManager toma o mesmo valor baixo [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Reinicie NetworkManager e volva conectar, porque o daemon garda na caché os perfís analizados e doutro xeito seguirá usando a copia que xa ten. Saiba que fai a liña antes de conservala: ese axuste é un limiar sobre varios parámetros de certificados e claves, non un nome de cifrado, así que baixalo amplía o que acepta o perfil individual. Anote que servidor o esixiu e retire o axuste cando o operador reemita material actual. Cambiar /etc/ssl/openssl.cnf alcanza o mesmo limiar para cada programa que lea ese ficheiro, o que vai moito máis alá da VPN.

OpenVPN 2.6 necesita o cifrado listado para negociar

Ubuntu 22.10 incluíu OpenVPN 2.6, e nesa versión --cipher deixa de escoller a canle de datos por si só. O cifrado tamén debe estar presente na lista data-ciphers negociada, ou o cliente imprime un aviso de obsolescencia e despois non logra levantar o túnel.

O complemento de NetworkManager da mesma época seguía escribindo só a directiva antiga. Ese detalle divide o diagnóstico, porque un perfil corrixido a man pode conectar desde unha consola e seguir fallando desde o applet de escritorio. Engada a lista ao ficheiro de conexión baixo [vpn]:

data-ciphers=AES-256-CBC

Use o valor que anuncia o servidor e non o que recorda; un servidor que ofrece AES-256-GCM non negociará cunha lista de cliente que só nomee CBC. Reinicie o xestor e volva conectar, logo repita o intento desde unha consola co cifrado pasado explicitamente tanto para a negociación como para o retroceso:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

Se ese comando levanta o túnel, o servidor, os certificados e as credenciais están todos sans, e o único fallo restante é a opción gardada do xestor. Un aviso sobre a directiva keysize pertence á mesma limpeza: coménteo e conserve o ficheiro orixinal xunto ao perfil.

Os fallos de paquetes e complementos parecen fallos de VPN

Non todo fallo posterior á actualización é criptográfico. Un repositorio de OpenVPN engadido baixo un nome en clave que a versión non usa produce un paquete que nunca se instala, así que compare o que lsb_release -a informa co ficheiro de lista que engadiu. Un compoñente universe ausente ou un peto de seguridade producen un paquete que non se pode atopar en absoluto. Ambos os casos deixan o perfil intacto e o túnel imposible.

Lea o erro do xestor de paquetes antes do rexistro de VPN. Se o cliente nunca se instalou, ningunha cantidade de edición do perfil producirá un aperto de mans.

Os perfís de dous factores que deixan de pedir son a versión de complemento da mesma historia. O desafío vén dun complemento de autenticación, e unha actualización que o eliminou ou substituíu deixa o perfil intacto mentres a petición desaparece. Reinstale o complemento compatible en lugar de borrar o segundo factor para que a conexión funcione.

Unha biblioteca de provedor pode agocharse tras un erro de política

Un patrón merece recoñecemento porque derrota toda reparación de política. Unha ferramenta de configuración dun provedor de hardware pode instalar as súas propias bibliotecas OpenSSL e colocalas diante das copias do sistema na ruta de busca do cargador. O cliente arrinca entón contra unha biblioteca que ninguén actualizou, e o fallo de arrinque parece exactamente un certificado rexeitado.

Reinstalar o paquete de VPN non cambia que biblioteca se atopa primeiro, e baixar o nivel de TLS non pode alcanzar unha biblioteca que nunca veu do sistema. Pregunte ao cargador que obxectos criptográficos resolve realmente o binario:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

Elimine ou redirixa a copia do provedor, e despois execute a mesma comprobación outra vez. A versión esperada debe ser a que está en uso antes de volver ao perfil.

Fixar un cliente antigo compra tempo, non unha solución

Manter a versión anterior do cliente restaura o túnel mentres dure a retención. Tamén conxela as actualizacións de seguridade dese paquete e programa a mesma rotura para a próxima actualización, así que tráteo como unha solución temporal datada e non como unha resolución.

Se aínda así o fixa, reteña o paquete explicitamente para que unha actualización desatendida non poida desfacer a fixación, anote o motivo e a data para revisalo, e pon un recordatorio para a próxima versión de perfil do provedor. A condición que paga a pena vixiar é un perfil de servidor que negocie un cifrado actual; en canto exista, a fixación xa non ten xustificación. Unha fixación non rexistrada, en cambio, convértese nunha interrupción que ninguén pode explicar seis meses despois, porque a persoa que a aplicou xa marchou e o ficheiro non rexistra nada.

A próxima vez que unha VPN morra tras unha actualización de versión, faga cinco preguntas en orde: que capa produciu o primeiro erro, se a política TLS rexeitou o certificado, se o cifrado é negociable en ambos os sentidos, se o paquete e o seu complemento se instalaron de verdade, e que biblioteca carga o proceso. Só cando as cinco volven limpas ten sentido unha degradación.