Waarom het OpenVPN ná 'n Ubuntu-opgradering opgehou verbind?

VPN-profiele wat verlede week nog gewerk het, breek ná 'n Ubuntu-vrystellingopgradering, en die logboek noem die opgradering selde. Wat dit wel noem, is die laag wat misluk het: die TLS-handskud, die syfer wat vir die datakanaal onderhandel is, die pakket wat geïnstalleer is, of die kopie van OpenSSL wat die program by die opstart laai. Elke laag het sy eie foutvorm en sy eie herstel, wat klassifikasie die eerste taak maak en redigering die tweede. Behandel die profiel as onskuldig totdat die logboek dit noem.

Watter laag het misluk: handskud, syfer, pakket of biblioteek

Lees die kliënt se logboek voordat jy aan die profiel raak. Die vroegste fout in die uitset is die een wat die laag identifiseer; alles wat daarna gedruk word, is gewoonlik nasleep van daardie eerste mislukking. Wanneer die kliënt glad nie begin nie, is die VPN-logboek die verkeerde lêer om oop te maak.

Klagtes oor sertifikate en handtekeninge, of 'n boodskap oor sleutellengte, kom van die beheerkanaal en die biblioteekbeleid wat dit beheer. 'n Waarskuwing wat begin met DEPRECATED OPTION hoort eerder by datakanaal-onderhandeling.

’n Lyn met Unrecognized option is ’n derde kategorie: die nuwe program aanvaar nie meer ’n riglyn wat die oue verdra het nie, so die profiel moet herskryf word eerder as wat die biblioteek verslap moet word. Pakketfoute lyk weer anders, want hulle gebeur voordat enige tonnelkode loop. ’n Ontbrekende program, ’n invoegtoepassing wat nie laai nie, of ’n bewaarplek wat na die verkeerde kodenaam wys, lewer almal daardie vorm. Vier simptome, vier plekke om te kyk, en byna geen oorvleueling tussen die herstelle nie.

Wanneer die handskud misluk, verwerp die TLS-beleid die sertifikaat

Ubuntu 22.04 het die stelsel na OpenSSL 3 geskuif, en die verstek-sekerheidsvlak in daardie tak is strenger oor sertifikaathandtekeninge en sleutelgroottes as wat 20.04 was. ’n CA-sertifikaat wat met ’n ouer digest onderteken is, of ’n sleutel onder die huidige drempel, misluk nou tydens die handskud. Aangesien nog niks geauthentiseer is nie, lyk die fout soos ’n verkeerde wagwoord of ’n dooie bediener.

Die eng herstelling heg ’n syferstring net aan hierdie verbinding. Maak in die lessenaarredigeerder die profiel oop, skakel oor na die gevorderde instellings en sit DEFAULT:@SECLEVEL=0 in die TLS-syferveld. Die NetworkManager-sleutellêer neem dieselfde waarde onder [vpn]:

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

Herbegin NetworkManager en verbind weer, want die diens kas parsede profiele en sal anders die kopie bly gebruik wat hy al het. Weet wat die reël doen voordat jy dit hou: daardie instelling is ’n drempel oor verskeie sertifikaat- en sleutelparameters eerder as ’n syfernaam, so om dit te verlaag verbreed wat die enkele profiel aanvaar. Let op watter bediener dit vereis het en laat vaar die instelling sodra die operateur huidige materiaal heruitreik. Om /etc/ssl/openssl.cnf te verander bereik dieselfde drempel vir elke program wat daardie lêer lees, wat veel verder strek as die VPN.

OpenVPN 2.6 vereis dat die syfer vir onderhandeling gelys word

Ubuntu 22.10 het OpenVPN 2.6 vrygestel, en in daardie uitgawe hou --cipher op om die datakanaal alleen te kies. Die syfer moet ook in die onderhandelde data-ciphers-lys voorkom, anders druk die kliënt ’n verouderingswaarskuwing en slaag hy nie daarin om die tonnel op te bring nie.

Die NetworkManager-invoegtoepassing uit dieselfde tydperk het steeds net die ou riglyn geskryf. Daardie detail verdeel die diagnose, want ’n profiel wat met die hand reggemaak is, kan van ’n skulp verbind en steeds van die lessenaar-applet misluk. Voeg die lys by die verbindingslêer onder [vpn]:

data-ciphers=AES-256-CBC

Gebruik die waarde wat die bediener adverteer eerder as die een wat jy onthou; ’n bediener wat AES-256-GCM stuur, sal nie met ’n kliëntlys onderhandel wat net CBC noem nie. Herbegin die bestuurder en verbind weer, en herhaal dan die poging van ’n skulp met die syfer eksplisiet vir beide onderhandeling en terugval:

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

As daardie opdrag die tonnel opbring, is die bediener, die sertifikate en die geloofsbriewe almal gesond, en die bestuurder se gestoorde opsie is die enigste fout oor. ’n Waarskuwing oor ’n keysize riglyn hoort by dieselfde opruiming: kommenteer dit uit en hou die oorspronklike lêer langs die profiel.

Pakket- en invoegtoepassingfoute lyk soos VPN-foute

Nie elke mislukking ná die opgradering is kriptografies nie. ’n OpenVPN-bewaarplek wat onder ’n kodenaam bygevoeg is wat die uitgawe nie gebruik nie, lewer ’n pakket wat nooit installeer nie, so vergelyk wat lsb_release -a rapporteer met die lyslêer wat jy bygevoeg het. ’n Ontbrekende universe-komponent of sekuriteitsak lewer ’n pakket wat glad nie gevind kan word nie. Beide gevalle laat die profiel onaangeraak en die tonnel onmoontlik.

Lees die pakketbestuurder se fout voor die VPN-logboek. As die kliënt nooit geïnstalleer is nie, sal geen hoeveelheid profielredigering ’n handskud lewer nie.

Twee-faktorprofiele wat ophou vra, is die invoegtoepassing-weergawe van dieselfde verhaal. Die uitdaging kom van ’n verifikasiemodule, en ’n opgradering wat dit laat val of vervang het, laat die profiel ongeskonde terwyl die vraag verdwyn. Herinstalleer die ondersteunde module eerder as om die tweede faktor te skrap om die verbinding te laat werk.

’n Verskaffer-biblioteek kan agter ’n beleidsfout skuil

Een patroon verdien erkenning omdat dit elke beleidsherstel verydel. ’n Hardewareverskaffer se konfigurasienutsgoed kan sy eie OpenSSL-biblioteke installeer en dit voor die stelselkopieë in die laaier se soekpad plaas. Die kliënt begin dan teen ’n biblioteek wat niemand opgradeer het nie, en die opstartfout lyk presies soos ’n verwerpte sertifikaat.

Om die VPN-pakket te herinstalleer verander nie watter biblioteek eerste gevind word nie, en om die TLS-vlak te verlaag kan nie ’n biblioteek bereik wat nooit van die stelsel gekom het nie. Vra die laaier watter kripto-objekte die program werklik oplos:

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

Verwyder of herwys die verskafferkopie, en hardloop dan dieselfde kontrole weer. Die verwagte weergawe moet die een wees wat in gebruik is voordat jy na die profiel terugkeer.

Om ’n ouer kliënt vas te pen koop tyd, nie ’n oplossing nie

Om die vorige kliëntweergawe vas te hou, herstel die tonnel solank die vashouding duur. Dit bevries ook sekuriteitsopdaterings vir daardie pakket en beplan dieselfde breuk vir die volgende opgradering, so behandel dit as ’n gedateerde noodoplossing eerder as ’n oplossing.

As jy dit tog vaspen, hou die pakket eksplisiet vas sodat ’n onbewaakte opgradering die pen nie kan ontsoen nie, skryf die rede en die datum neer om dit te herbesoek, en stel ’n herinnering op vir die verskaffer se volgende profielvrystelling. Die toestand wat die moeite werd is om dop te hou, is ’n bedienerprofiel wat ’n huidige syfer onderhandel; sodra dit bestaan, het die pen geen regverdiging meer oor nie. ’n Ongenoteerde pen word daarenteen ’n onderbreking wat niemand ses maande later kan verduidelik nie, want die persoon wat dit toegepas het, het aangestap en die lêer teken niks aan nie.

Neem volgende keer wanneer ’n VPN ná ’n vrystellingopgradering sterf, vyf vrae in volgorde: watter laag het die eerste fout gelewer, het die TLS-beleid die sertifikaat verwerp, is die syfer in beide rigtings onderhandelbaar, het die pakket en sy invoegtoepassing werklik geïnstalleer, en watter biblioteek laai die proses. Eers nadat al vyf skoon terugkom, maak ’n afgradering sin.