Per què OpenVPN va deixar de connectar després d'una actualització d'Ubuntu?

Els perfils VPN que funcionaven la setmana passada es trenquen després d'una actualització de versió d'Ubuntu, i el registre poques vegades esmenta l'actualització. El que sí que anomena és la capa que ha fallat: l'encaixada de mans TLS, el xifratge negociat per al canal de dades, el paquet que s'ha instal·lat o la còpia d'OpenSSL que el binari carrega en arrencar. Cada capa té la seva forma d'error i la seva reparació, cosa que fa de la classificació la primera feina i de l'edició la segona. Tracta el perfil com a innocent fins que el registre el nomeni.

Quina capa ha fallat: encaixada de mans, xifratge, paquet o biblioteca

Llegeix el registre del client abans de tocar el perfil. l'error més primerenc de la sortida és el que identifica la capa; tot el que s'imprimeix després sol ser la conseqüència d'aquella primera fallada. Quan el client no arrenca gens, el registre de VPN és el fitxer equivocat per obrir.

Les queixes de certificats i signatures, o un missatge sobre la longitud de la clau, vénen del canal de control i de la política de biblioteca que el governa. Un avís que comença amb DEPRECATED OPTION pertany, en canvi, a la negociació del canal de dades.

Una línia com Unrecognized option és una tercera categoria: el binari nou ja no accepta una directiva que el vell tolerava, així que cal reescriure el perfil en lloc de relaxar la biblioteca. Les fallades d'empaquetatge tornen a semblar diferents perquè passen abans que s'executi cap codi de túnel. Un binari absent, un connector que no es carrega o un repositori que apunta a un nom clau equivocat produeixen tots aquesta forma. Quatre símptomes, quatre llocs on mirar i gairebé cap solapament entre les reparacions.

Quan falla l'encaixada de mans, la política TLS rebutja el certificat

Ubuntu 22.04 va portar el sistema a OpenSSL 3, i el nivell de seguretat per defecte d'aquesta branca és més estricte amb les signatures de certificats i les mides de clau que el 20.04. Un certificat de CA signat amb un resum més antic, o una clau per sota del llindar actual, ara fallen durant l'encaixada de mans. Com que encara no s'ha autenticat res, l'error es llegeix com una contrasenya incorrecta o un servidor mort.

La reparació estreta adjunta una cadena de xifratge només a aquesta connexió. A l'editor d'escriptori, obre el perfil, ves a la configuració avançada i posa DEFAULT:@SECLEVEL=0 al camp de xifratge TLS. El fitxer de claus de NetworkManager pren el mateix valor sota [vpn]:

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

Reinicia NetworkManager i torna a connectar, perquè el dimoni fa memòria cau dels perfils analitzats i, si no, continuarà fent servir la còpia que ja té. Sapigueu què fa la línia abans de conservar-la: aquest paràmetre és un llindar sobre diversos paràmetres de certificats i claus, no un nom de xifratge, així que baixar-lo amplia el que accepta el perfil únic. Anota quin servidor ho va requerir i treu el paràmetre quan l'operador reemeti material actual. Canviar /etc/ssl/openssl.cnf arriba al mateix llindar per a cada programa que llegeixi aquell fitxer, cosa que va molt més enllà de la VPN.

OpenVPN 2.6 necessita el xifratge llistat per negociar

Ubuntu 22.10 va incloure OpenVPN 2.6, i en aquesta versió --cipher deixa d'escollir el canal de dades tot sol. El xifratge també ha de ser present a la llista data-ciphers negociada, o el client imprimeix un avís d'obsoletesa i després no aconsegueix aixecar el túnel.

El connector de NetworkManager de la mateixa època encara escrivia només la directiva antiga. Aquest detall divideix el diagnòstic, perquè un perfil corregit a mà pot connectar des d'un intèrpret i encaixar encara una fallada des de l'applet d'escriptori. Afegeix la llista al fitxer de connexió sota [vpn]:

data-ciphers=AES-256-CBC

Feu servir el valor que anuncia el servidor i no el que recordeu; un servidor que envia AES-256-GCM no negociarà amb una llista de client que només esmenti CBC. Reinicia el gestor i torna a connectar, i després repeteix l'intent des d'un intèrpret amb el xifratge passat explícitament tant per a la negociació com per al retrocés:

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

Si aquesta ordre aixeca el túnel, el servidor, els certificats i les credencials són tots bons, i l'única fallada que queda és l'opció desada del gestor. Un avís sobre la directiva keysize pertany a la mateixa neteja: comenta-la i conserva el fitxer original al costat del perfil.

Les fallades de paquets i connectors semblen fallades de VPN

No tota fallada posterior a l'actualització és criptogràfica. Un repositori d'OpenVPN afegit sota un nom clau que la versió no fa servir produeix un paquet que no s'instal·la mai, així que compara què lsb_release -a informa amb el fitxer de llista que heu afegit. Un component universe absent o un butxaca de seguretat produeixen un paquet que no es pot trobar de cap manera. Tots dos casos deixen el perfil intacte i el túnel impossible.

Llegeix l'error del gestor de paquets abans del registre de VPN. Si el client no s'ha instal·lat mai, cap quantitat d'edició del perfil produirà una encaixada de mans.

Els perfils de dos factors que deixen de demanar són la versió del connector de la mateixa història. El repte ve d'un connector d'autenticació, i una actualització que l'ha eliminat o substituït deixa el perfil intacte mentre la petició desapareix. Reinstal·la el connector compatible en lloc de suprimir el segon factor per fer funcionar la connexió.

Una biblioteca de proveïdor es pot amagar darrere d'un error de política

Un patró mereix reconeixement perquè derrota tota reparació de política. Una eina de configuració d'un proveïdor de maquinari pot instal·lar les seves pròpies biblioteques OpenSSL i col·locar-les davant de les còpies del sistema al camí de cerca del carregador. Llavors el client arrenca contra una biblioteca que ningú no ha actualitzat, i la fallada d'arrencada sembla exactament un certificat rebutjat.

Reinstal·lar el paquet de VPN no canvia quina biblioteca es troba primer, i baixar el nivell TLS no pot arribar a una biblioteca que mai no ha vingut del sistema. Pregunta al carregador quins objectes de xifratge resol realment el binari:

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

Elimina o redirigeix la còpia del proveïdor, i després torna a executar la mateixa comprovació. La versió esperada ha de ser la que està en ús abans de tornar al perfil.

Fixar un client antic compra temps, no una solució

Mantenir la versió anterior del client restaura el túnel mentre duri la retenció. També congela les actualitzacions de seguretat d'aquell paquet i programa la mateixa trencadissa per a la propera actualització, així que tracta-ho com una solució temporal datada i no com una resolució.

Si el fixes, retén el paquet explícitament perquè una actualització desatesa no pugui desfer la fixació, anota el motiu i la data per revisar-ho i posa un recordatori per a la propera versió de perfil del proveïdor. La condició que val la pena vigilar és un perfil de servidor que negociï un xifratge actual; un cop existeixi, la fixació no té cap justificació. Una fixació no registrada, en canvi, es converteix en una interrupció que ningú no pot explicar sis mesos després, perquè la persona que la va aplicar ja ha marxat i el fitxer no enregistra res.

La propera vegada que una VPN mori després d'una actualització de versió, fes cinc preguntes en seqüència: quina capa va produir el primer error, la política TLS va rebutjar el certificat, el xifratge és negociable en tots dos sentits, el paquet i el seu connector es van instal·lar de debò, i quina biblioteca carrega el procés. Només quan les cinc tornen netes té sentit una baixada de versió.