Wêrom hold OpenVPN op mei ferbinen nei in Ubuntu-upgrade?

VPN-profylen dy't ferline wike noch wurken, brekke nei in Ubuntu-útjefte-upgrade, en it loch neamt de upgrade amper. Wat it wol neamt, is de laach dy't mislearre: de TLS-hânskodding, de sifer dy't foar it datakanaal ôfpraat is, it pakket dat ynstallearre is, of de kopy fan OpenSSL dy't it programma by it starten ladt. Elke laach hat syn eigen flaterfoarm en syn eigen reparaasje, wat klassifikaasje it earste wurk makket en bewurkjen it twadde. Behannelje it profyl as ûnskuldich oant it loch it neamt.

Hokker laach mislearre: hânskodding, sifer, pakket of bibleteek

Lês it kliïntloch foardat jo it profyl oanreitsje. De ierste flaters in de útfier is dejinge dy't de laach oanwiist; alles wat dêrnei printe wurdt is meastentiids gefolch fan dy earste mislearring. As de kliïnt hielendal net start, is it VPN-loch it ferkearde bestân om te iepenjen.

Klachten oer sertifikaten en hantekens, of in berjocht oer kaaillingte, komme fan it kontrôlekanaal en it bibleteekbelied dat it regelet. In warskôging dy't begjint mei DEPRECATED OPTION heart lykwols by de ôfsprutsen fan it datakanaal.

In rigel Unrecognized option is in tredde kategory: it nije programma akseptearret gjin rjochtline mear dy't it âlde ferfoel, dus it profyl moat oerskreaun wurde ynstee fan de bibleteek te fersêftsjen. Pakketflaters sjogge der wer oars út, want se barre foardat der in tunnelkoade rint. In ûntbrekkend programma, in plugin dy't net ladt, of in bewarplak dat nei de ferkearde koadenamme wiist, jouwe allegear dy foarm. Fjouwer symptomen, fjouwer plakken om te sjen, en hast gjin oerlaap tusken de reparaasjes.

As de hânskodding mislearret, wiist it TLS-belied it sertifikaat ôf

Ubuntu 22.04 ferhuze it systeem nei OpenSSL 3, en it standert feiligensnivo yn dy tûke is stranger oer sertifikaathantekens en kaaimaten as 20.04 wie. In CA-sertifikaat dat mei in âlder digest ûndertekene is, of in kaai ûnder de hjoeddeiske drompel, mislearret no by de hânskodding. Om't noch neat autentisearre is, liedt de flater as in ferkeard wachtwurd of in deade tsjinner.

De smelle reparaasje hâldt in siferrigel allinne oan dizze ferbining. Iepenje yn de buroblêdredakteur it profyl, gean nei de avansearre ynstellingen en set DEFAULT:@SECLEVEL=0 yn it TLS-siferfjild. It NetworkManager-kaaibestân nimt deselde wearde ûnder [vpn]:

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

Start NetworkManager opnij en ferbin opnij, want de tsjinst bewarret ferwurke profylen en soe oars de kopy brûke dy't er al hat. Wês wat de rigel docht foardat jo him hâlde: dy ynstelling is in drompel oer ferskate sertifikaat- en kaai-parameters, gjin sifernamme, sadat ferleegjen útwreidet wat it iene profyl akseptearret. Skriuw op hokker tsjinner it easke en lit de ynstelling falle sadree't de operator aktueel materiaal opnij útjout. It feroarjen fan /etc/ssl/openssl.cnf berikt deselde drompel foar elk programma dat dat bestân lêst, wat folle fierder giet as de VPN.

OpenVPN 2.6 wol de sifer neamd foar de ôfsprutsen

Ubuntu 22.10 levere OpenVPN 2.6, en yn dy útjefte hâldt --cipher op mei sels it datakanaal te kiezen. De sifer moat ek yn 'e ôfsprutsen list data-ciphers stean, oars printet de kliïnt in ferâlderewarskôging en slagget it dêrnei net de tunnel op te bringen.

De NetworkManager-plugin út deselde tiid skreau noch altyd allinnich de âlde rjochtline. Dat detail spjaltet de diagnoaze, want in mei de hân korrigearre profyl kin fan in shell ferbine en dochs fan 'e buroblêdapp mislearje. Foegje de list ta oan it ferbiningsbestân ûnder [vpn]:

data-ciphers=AES-256-CBC

Brûk de wearde dy't de tsjinner oankundiget, net dy't jo ûnthâlde; in tsjinner dy't AES-256-GCM biedt, sil net ôfprate mei in kliïntlist dy't allinnich CBC neamt. Start de behearder opnij en ferbin opnij, werhelje dan de poging fan in shell mei de sifer eksplisyt trochjûn foar sawol ôfsprutsen as weromfal:

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

As dat kommando de tunnel opbringt, binne de tsjinner, de sertifikaten en de bewiisstikken allegear sûn, en is de iennige oerbleaune fout de bewarre opsje fan 'e behearder. In warskôging oer de rjochtline keysize heart by deselde opromming: set it yn kommentaar en hâld it orizjinele bestân njonken it profyl.

Pakket- en pluginfouten lykje op VPN-fouten

Net elke mislearring nei de upgrade is kryptografysk. In OpenVPN-bewarplak dat tafoege is ûnder in koadenamme dy't de útjefte net brûkt, jout in pakket dat nea ynstallearret, dus fergelykje wat lsb_release -a rapportearret mei it listbestân dat jo tafoege hawwe. In ûntbrekkende universe komponint of befeiligingsbûse jout in pakket dat hielendal net fûn wurde kin. Beide gefallen litte it profyl ûnoantaast en de tunnel ûnmooglik.

Lês de flater fan 'e pakketbehearder foar it VPN-loch. As de kliïnt nea ynstallearre is, sil gjin inkelde profylbewurking in hânskodding jouwe.

Profylen mei twa faktoaren dy't ophâlde te freegjen binne de plugin-ferzje fan itselde ferhaal. De útdaging komt fan in autentikaasjeplugin, en in upgrade dy't him weilitten of ferfongen hat, lit it profyl yntakt wylst de fraach ferdwynt. Ynstallearje de stipe plugin opnij ynstee fan de twadde faktor te wiskjen om de ferbining wurkje te litten.

In bibleteek fan in leveransier kin him efter in beliedsflater ferskûlje

Ien patroan fertsjinnet erkenning, want it ferslacht elke beliedsreparaasje. In konfiguraasje-ark fan in hardwareleveransier kin syn eigen OpenSSL-bibleteken ynstallearje en dy foar de systeemkopyen yn it sykpaad fan 'e lader pleatse. De kliïnt start dan tsjin in bibleteek dy't nimmen bywurke hat, en de startflater liket krekt op in ôfwiisd sertifikaat.

It VPN-pakket opnij ynstallearje feroaret net hokker bibleteek earst fûn wurdt, en it TLS-nivo ferleegje kin in bibleteek net berikke dy't nea fan it systeem kaam. Freegje de lader hokker kryptobjekten it programma wier oplost:

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

Ferwiderje of ferwizigje de kopy fan 'e leveransier en rin dan deselde kontrôle wer. De ferwachte ferzje moat de brûkte wêze foardat jo weromgeane nei it profyl.

In âldere kliïnt fêstsette keapet tiid, gjin oplossing

De foarige kliïntferzje oanhâlde herstelt de tunnel salang't it oanhâlden doart. It befriest ek de feiligensfernijings foar dat pakket en pland deselde brek foar de folgjende upgrade, dus behannelje it as in datearre needoplossing, net as in oplossing.

As jo it dochs fêstsette, hâld it pakket eksplisyt fêst sadat in net-bewekke upgrade it fêstsetten net ûngedien meitsje kin, skriuw de reden en de datum foar werynspeksje op, en set in herinnering foar de folgjende profylútjefte fan 'e oanbieder. De betingst dy't it besjen wurdich is, is in tsjinnerprofyl dat in aktuele sifer ôfpraten; sadree't dat bestiet, hat it fêstsetten gjin rjochtfeardiging mear. In net-opskreaun fêstsetten wurdt krekt in útfal dat nimmen seis moanne letter ferklearje kin, om't de persoan dy't it tapaste fierder gien is en it bestân neat fêstleit.

Nim de folgjende kear as in VPN nei in útjefte-upgrade stjert, fiif fragen op rige: hokker laach joech de earste flater, hat it TLS-belied it sertifikaat ôfwiisd, is de sifer yn beide rjochtingen ôfprekber, binne it pakket en syn plugin wier ynstallearre, en hokker bibleteek ladt it proses. Pas as alle fiif skjin weromkomme, hat in delgong sin.