Kāpēc OpenVPN pārstāja pieslēgties pēc Ubuntu atjauninājuma?

VPN profili, kas pagājušajā nedēļā darbojās, pēc Ubuntu laidiena atjauninājuma salūzt, un žurnāls atjauninājumu piemin reti. Tas nosauc slāni, kas neizdevās: TLS rokasspiedienu, datu kanālam saskaņoto šifru, instalēto pakotni vai OpenSSL kopiju, ko programma ielādē startējot. Katram slānim ir sava kļūdas forma un savs labojums, tāpēc klasifikācija ir pirmais darbs, bet rediģēšana otrais. Uzskatiet profilu par nevainīgu, līdz žurnāls to nosauc.

Kurš slānis neizdevās: rokasspiediens, šifrs, pakotne vai bibliotēka

Pirms profila aizskaršanas izlasiet klienta žurnālu. agrākā izvades kļūda ir tā, kas nosaka slāni; viss pēc tam uzdrukātais parasti ir šīs pirmās kļūdas sekas. Ja klients vispār nestartē, VPN žurnāls ir nepareizais fails, ko atvērt.

Sūdzības par sertifikātiem un parakstiem vai ziņojums par atslēgas garumu nāk no vadības kanāla un to regulējošās bibliotēkas politikas. Savukārt brīdinājums, kas sākas ar DEPRECATED OPTION, pieder datu kanāla saskaņošanai.

Šāda rinda Unrecognized option ir trešā kategorija: jaunā programma vairs nepieņem direktīvu, ko vecā piecieta, tāpēc profils ir jāpārraksta, nevis bibliotēka jāatbrīvo. Pakotnes kļūmes izskatās vēl citādi, jo tās notiek pirms jebkura tuneļa koda palaišanas. Trūkstoša programma, neielādējams spraudnis vai uz nepareizu koda nosaukumu norādoša krātuve visas dod šo formu. Četri simptomi, četras vietas, kur skatīties, un gandrīz nekāda labojumu pārklāšanās.

Kad rokasspiediens neizdodas, TLS politika noraida sertifikātu

Ubuntu 22.04 pārcēla sistēmu uz OpenSSL 3, un šajā atzarā noklusējuma drošības līmenis ir stingrāks pret sertifikātu parakstiem un atslēgu izmēriem nekā 20.04. CA sertifikāts, kas parakstīts ar vecāku digestu, vai atslēga zem pašreizējā sliekšņa tagad neizdodas rokasspiediena laikā. Tā kā nekas vēl nav autentificēts, kļūda lasās kā nepareiza parole vai miris serveris.

Šaurais labojums šifrēšanas virkni pievieno tikai šim savienojumam. Darbvirsmas redaktorā atveriet profilu, ejiet uz paplašinātajiem iestatījumiem un ievietojiet DEFAULT:@SECLEVEL=0 TLS šifrēšanas laukā. NetworkManager atslēgas fails saņem to pašu vērtību sadaļā [vpn]:

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

Restartējiet NetworkManager un pieslēdzieties vēlreiz, jo dēmons kešo parsētos profilus un citādi turpinās izmantot jau esošo kopiju. Ziniet, ko rinda dara, pirms to paturat: šis iestatījums ir slieksnis pāri vairākiem sertifikātu un atslēgu parametriem, nevis šifra nosaukums, tāpēc tā pazemināšana paplašina to, ko pieņem viens profils. Pierakstiet, kurš serveris to pieprasīja, un atmetiet iestatījumu, kad operators atkārtoti izdos aktuālo materiālu. Savukārt /etc/ssl/openssl.cnf maiņa sasniedz to pašu slieksni katrai programmai, kas lasa šo failu, un tas ir daudz tālāk par VPN.

OpenVPN 2.6 pieprasa šifru saskaņošanas sarakstā

Ubuntu 22.10 atnesa OpenVPN 2.6, un šajā laidienā --cipher pārstāj pats izvēlēties datu kanālu. Šifram jābūt arī saskaņotajā data-ciphers sarakstā, citādi klients izdrukā novecošanas brīdinājumu un pēc tam nespēj pacelt tuneli.

Tā paša laika NetworkManager spraudnis joprojām rakstīja tikai veco direktīvu. Šī detaļa sadala diagnozi, jo ar rokām labots profils var pieslēgties no čaulas un tomēr neizdoties darbvirsmas lietotnē. Pievienojiet sarakstu savienojuma failam sadaļā [vpn]:

data-ciphers=AES-256-CBC

Izmantojiet vērtību, ko serveris izziņo, nevis to, ko atceraties; serveris, kas piedāvā AES-256-GCM, nesaskaņos ar klienta sarakstu, kurā nosaukts tikai CBC. Restartējiet pārvaldnieku un pieslēdzieties, pēc tam atkārtojiet mēģinājumu no čaulas, skaidri nododot šifru gan saskaņošanai, gan rezervei:

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

Ja šī komanda paceļ tuneli, serveris, sertifikāti un akreditācijas dati ir veseli, un vienīgais atlikušais defekts ir pārvaldnieka saglabātais iestatījums. Brīdinājums par direktīvu keysize pieder tam pašam uzkopšanas darbam: komentējiet to un glabājiet oriģinālo failu blakus profilam.

Pakotnes un spraudņa kļūmes izskatās kā VPN kļūmes

Ne katra kļūme pēc atjauninājuma ir kriptogrāfiska. OpenVPN krātuve, kas pievienota ar koda nosaukumu, ko laidiens neizmanto, dod pakotni, kas nekad netiek instalēta, tāpēc salīdziniet, ko lsb_release -a ziņo, ar pievienoto saraksta failu. Trūkstoša universe komponente vai drošības kabata dod pakotni, ko vispār nevar atrast. Abos gadījumos profils paliek neskarts, bet tunelis nav iespējams.

Pirms VPN žurnāla izlasiet pakotņu pārvaldnieka kļūdu. Ja klients nekad nav instalēts, nekāda profila rediģēšana nedos rokasspiedienu.

Divu faktoru profili, kas pārstāj jautāt, ir tā paša stāsta spraudņa versija. Izaicinājums nāk no autentifikācijas spraudņa, un atjauninājums, kas to izlaida vai aizstāja, atstāj profilu neskartu, kamēr uzvedne pazūd. Pārinstalējiet atbalstīto spraudni, nevis dzēsiet otro faktoru, lai savienojums darbotos.

Piegādātāja bibliotēka var slēpties aiz politikas kļūdas

Viens modelis ir vērts atpazīšanas, jo tas pārspēj jebkuru politikas labojumu. Aparatūras piegādātāja konfigurācijas rīks var instalēt savas OpenSSL bibliotēkas un novietot tās ielādētāja meklēšanas ceļā pirms sistēmas kopijām. Tad klients startē pret bibliotēku, ko neviens nav atjauninājis, un starta kļūme izskatās tieši kā noraidīts sertifikāts.

VPN pakotnes pārinstalēšana nemaina to, kura bibliotēka tiek atrasta pirmā, un TLS līmeņa pazemināšana neaizsniedz bibliotēku, kas nekad nav nākusi no sistēmas. Pajautājiet ielādētājam, kurus kripto objektus programma patiešām atrisina:

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

Noņemiet vai pārvirziet piegādātāja kopiju, pēc tam vēlreiz palaidiet to pašu pārbaudi. Sagaidītajai versijai jābūt lietotajai, pirms atgriežaties pie profila.

Vecāka klienta piespraušana pērk laiku, nevis risinājumu

Iepriekšējās klienta versijas turēšana atjauno tuneli, kamēr vien turēšana ilgst. Tā arī iesaldē šīs pakotnes drošības atjauninājumus un ieplāno tādu pašu lūzumu nākamajam atjauninājumam, tāpēc uzskatiet to par datētu pagaidu risinājumu, nevis atrisinājumu.

Ja tomēr to piespraudīsiet, turiet pakotni skaidri, lai neuzraudzīts atjauninājums nevarētu atcelt piespraušanu, pierakstiet iemeslu un pārskatīšanas datumu un iestatiet atgādinājumu par piegādātāja nākamo profila laidienu. Nosacījums, ko vērts uzraudzīt, ir servera profils, kas saskaņo pašreizējo šifru; tiklīdz tas pastāv, piespraušanai vairs nav pamata. Savukārt nereģistrēta piespraušana pēc pusgada kļūst par pārtraukumu, ko neviens nevar izskaidrot, jo to ieviesušais cilvēks jau aizgājis, un fails neko nefiksē.

Nākamreiz, kad VPN mirst pēc laidiena atjauninājuma, uzdodiet piecus jautājumus pēc kārtas: kurš slānis deva pirmo kļūdu, vai TLS politika noraidīja sertifikātu, vai šifru var saskaņot abos virzienos, vai pakotne un tās spraudnis tiešām tika instalēti, un kuru bibliotēku ielādē process. Tikai kad visi pieci atgriežas tīri, versijas pazemināšanai ir jēga.