Kodėl OpenVPN nustojo jungtis po Ubuntu atnaujinimo?

Praėjusią savaitę veikę VPN profiliai sugenda po Ubuntu leidimo atnaujinimo, o žurnalas atnaujinimą retai tepamini. Jis įvardija sluoksnį, kuris nepavyko: TLS rankos paspaudimą, duomenų kanalui suderintą šifrą, įdiegtą paketą ar OpenSSL kopiją, kurią programa įkelia paleidžiant. Kiekvienas sluoksnis turi savo klaidos formą ir savo taisymą, todėl klasifikavimas yra pirmas darbas, o redagavimas antras. Laikykite profilį nekaltu, kol žurnalas jį įvardys.

Kuris sluoksnis nepavyko: rankos paspaudimas, šifras, paketas ar biblioteka

Prieš liesdami profilį perskaitykite kliento žurnalą. ankstyviausia išvesties klaida ir yra ta, kuri nurodo sluoksnį; visa, kas spausdinama po jos, paprastai yra tos pirmos klaidos pasekmė. Kai klientas visai nepasileidžia, VPN žurnalas yra ne tas failas, kurį reikia atidaryti.

Skundai dėl sertifikatų ir parašų arba pranešimas apie rakto ilgį ateina iš valdymo kanalo ir jį reglamentuojančios bibliotekos politikos. O įspėjimas, prasidedantis DEPRECATED OPTION, priklauso duomenų kanalo derinimui.

Tokia eilutė Unrecognized option yra trečia kategorija: nauja programa nebepriima direktyvos, kurią senoji toleravo, todėl profilį reikia perrašyti, o ne biblioteką sušvelninti. Paketo gedimai atrodo dar kitaip, nes įvyksta prieš paleidžiant bet kokį tunelio kodą. Trūkstama programa, neįkeliamas papildinys ar neteisingą kodo vardą nurodanti saugykla visi duoda tą pačią formą. Keturi simptomai, keturios vietos, kur žiūrėti, ir beveik jokio taisymų persidengimo.

Kai rankos paspaudimas nepavyksta, TLS politika atmeta sertifikatą

Ubuntu 22.04 perkėlė sistemą į OpenSSL 3, o tos šakos numatytasis saugumo lygis griežtesnis sertifikatų parašams ir raktų dydžiams nei buvo 20.04. CA sertifikatas, pasirašytas senesniu maišos algoritmu, arba raktas žemiau dabartinės ribos dabar nepavyksta rankos paspaudimo metu. Kadangi dar niekas neautentifikuota, klaida skaitoma kaip neteisingas slaptažodis arba miręs serveris.

Siauras taisymas šifrų eilutę prideda tik šiam ryšiui. Darbalaukio redaktoriuje atidarykite profilį, eikite į išplėstinius nustatymus ir įrašykite DEFAULT:@SECLEVEL=0 į TLS šifro lauką. NetworkManager raktų failas priima tą pačią reikšmę skiltyje [vpn]:

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

Paleiskite NetworkManager iš naujo ir prisijunkite iš naujo, nes tarnyba kaupia apdorotus profilius ir kitaip naudos jau turimą kopiją. Žinokite, ką eilutė daro, prieš ją palikdami: šis nustatymas yra kelių sertifikatų ir raktų parametrų riba, o ne šifro pavadinimas, todėl ją sumažinus išplečiama, ką priima vienas profilis. Užsirašykite, kuris serveris to pareikalavo, ir atsisakykite nustatymo, kai operatorius iš naujo išduos aktualią medžiagą. O /etc/ssl/openssl.cnf pakeitimas pasiekia tą pačią ribą kiekvienai programai, kuri skaito tą failą, ir tai daug toliau už VPN.

OpenVPN 2.6 reikalauja šifro sąraše derinimui

Ubuntu 22.10 atnešė OpenVPN 2.6, ir toje versijoje --cipher nustoja pats rinktis duomenų kanalą. Šifras taip pat turi būti suderintame data-ciphers sąraše, kitaip klientas atspausdina pasenimo įspėjimą ir tada nepakelia tunelio.

To paties laikotarpio NetworkManager papildinys vis dar rašė tik seną direktyvą. Ši detalė skiria diagnozę, nes rankomis pataisytas profilis gali prisijungti iš apvalkalo ir vis tiek nepavykti darbalaukio programėlėje. Pridėkite sąrašą prie ryšio failo skiltyje [vpn]:

data-ciphers=AES-256-CBC

Naudokite vertę, kurią skelbia serveris, o ne tą, kurią prisimenate; serveris, siūlantis AES-256-GCM, nesiderins su kliento sąrašu, kuriame nurodytas tik CBC. Paleiskite tvarkyklę iš naujo ir prisijunkite, tada pakartokite bandymą iš apvalkalo, aiškiai perduodami šifrą ir derinimui, ir atsarginei kopijai:

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

Jei ši komanda pakelia tunelį, serveris, sertifikatai ir prisijungimo duomenys yra sveiki, o vienintelis likęs defektas yra tvarkyklės išsaugotas nustatymas. Įspėjimas apie direktyvą keysize priklauso tam pačiam valymui: užkomentuokite ją ir laikykite originalų failą šalia profilio.

Paketo ir papildinio gedimai atrodo kaip VPN gedimai

Ne kiekvienas gedimas po atnaujinimo yra kriptografinis. OpenVPN saugykla, pridėta po kodo vardu, kurio leidimas nenaudoja, duoda paketą, kuris niekada neįdiegiamas, todėl palyginkite, ką lsb_release -a praneša, su pridėtu sąrašo failu. Trūkstamas universe komponentas ar saugumo kišenė duoda paketą, kurio visai nepavyksta rasti. Abiem atvejais profilis lieka neliestas, o tunelis neįmanomas.

Prieš VPN žurnalą perskaitykite paketų tvarkyklės klaidą. Jei klientas niekada nebuvo įdiegtas, joks profilio redagavimas neduos rankos paspaudimo.

Dviejų veiksnių profiliai, kurie nustoja klausti, yra ta pati istorija papildinio versijoje. Iššūkis ateina iš autentifikavimo papildinio, o jį pašalinęs ar pakeitęs atnaujinimas palieka profilį sveiką, kol užklausa išnyksta. Perįdiekite palaikomą papildinį, o ne trinkite antrą veiksnį, kad ryšys veiktų.

Tiekėjo biblioteka gali slėptis už politikos klaidos

Vienas modelis vertas atpažinimo, nes įveikia bet kokį politikos taisymą. Techninės įrangos tiekėjo konfigūravimo įrankis gali įdiegti savo OpenSSL bibliotekas ir pastatyti jas prieš sistemos kopijas įkėlėjo paieškos kelyje. Tada klientas paleidžiamas prieš biblioteką, kurios niekas neatnaujino, ir paleidimo gedimas atrodo lygiai kaip atmestas sertifikatas.

VPN paketo perįdiegimas nepakeičia, kuri biblioteka randama pirmoji, o TLS lygio sumažinimas nepasiekia bibliotekos, kuri niekada nebuvo atėjusi iš sistemos. Paklauskite įkėlėjo, kuriuos kriptografinius objektus programa iš tikrųjų išsprendžia:

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

Pašalinkite arba peradresuokite tiekėjo kopiją, tada dar kartą paleiskite tą pačią patikrą. Tikėtina versija turi būti naudojama, prieš grįžtant prie profilio.

Seno kliento priskyrimas perka laiką, o ne sprendimą

Ankstesnės kliento versijos laikymas atkuria tunelį tol, kol laikoma. Tai taip pat užšaldo to paketo saugumo atnaujinimus ir numato tą patį lūžį kitam atnaujinimui, todėl laikykite tai datuotu laikinu sprendimu, o ne išsprendimu.

Jei vis tiek jį priskiriate, laikykite paketą aiškiai, kad nepriežiūrimas atnaujinimas negalėtų atšaukti priskyrimo, užsirašykite priežastį ir peržiūros datą ir nustatykite priminimą dėl kito tiekėjo profilio leidimo. Sąlyga, kurią verta stebėti, yra serverio profilis, derinantis dabartinį šifrą; kai jis atsiras, priskyrimas nebeturi jokio pagrindo. O neužrašytas priskyrimas po pusmečio tampa sutrikimu, kurio niekas negali paaiškinti, nes jį pritaikęs žmogus jau pasitraukė, o failas nieko nefiksuoja.

Kitą kartą VPN mirus po leidimo atnaujinimo, užduokite penkis klausimus iš eilės: kuris sluoksnis davė pirmą klaidą, ar TLS politika atmetė sertifikatą, ar šifrą galima derinti abiem kryptimis, ar paketas ir jo papildinys tikrai įdiegti ir kurią biblioteką įkelia procesas. Tik kai visi penki grįžta švariai, versijos sumažinimas turi prasmę.