Kial OpenVPN ĉesis konektiĝi post ĝisdatigo de Ubuntu?

VPN-profiloj, kiuj funkciis pasintsemajne, rompiĝas post ĝisdatigo de Ubuntu-eldono, kaj la protokolo malofte eĉ mencias la ĝisdatigon. Kion ĝi nomas estas la tavolo, kiu malsukcesis: la TLS-manpremo, la ĉifro negocita por la datkanalo, la pakaĵo instalita, aŭ la kopio de OpenSSL, kiun la binara dosiero ŝargas ĉe lanĉo. Ĉiu tavolo havas sian propran eraroformon kaj sian propran riparon, kio faras klasifikadon la unua tasko kaj redaktadon la dua. Konsideru la profilon senkulpa ĝis la protokolo nomos ĝin.

Kiu tavolo malsukcesis: manpremo, ĉifro, pakaĵo aŭ biblioteko

Legu la klientan protokolon antaŭ ol tuŝi la profilon. La plej frua eraro en la eligi estas tiu, kiu identigas la tavolon; ĉio presita poste estas kutime sekvo de tiu unua malsukceso. Kiam la kliento tute ne lanĉiĝas, la VPN-protokolo estas la malĝusta dosiero por malfermi.

Plendoj pri atestiloj kaj subskriboj, aŭ mesaĝo pri ŝlosila longo, venas de la regkanalo kaj de la biblioteka politiko, kiu regas ĝin. Averto, kiu komenciĝas per DEPRECATED OPTION apartenas anstataŭe al la negocado de la datkanalo.

Linio Unrecognized option estas tria kategorio: la nova binara dosiero jam ne akceptas direktivon, kiun la malnova toleris, do la profilo bezonas reverkon, ne la biblioteko malstreĉiĝon. Pakaĵaj fiaskoj aspektas denove alie, ĉar ili okazas antaŭ ol iu ajn tunela kodo ruliĝas. Mankanta binara dosiero, kromaĵo, kiu ne ŝargiĝas, aŭ deponejo montranta al malĝusta kodonomo ĉiuj produktas tiun formon. Kvar simptomoj, kvar lokoj por rigardi, kaj preskaŭ nenia interkovro inter la riparoj.

Kiam la manpremo malsukcesas, la TLS-politiko malakceptas la atestilon

Ubuntu 22.04 translokigis la sistemon al OpenSSL 3, kaj la defaŭlta sekurecnivelo en tiu branĉo estas pli severa pri atestilaj subskriboj kaj ŝlosilgrandoj ol estis 20.04. CA-atestilo subskribita per pli malnova resumo, aŭ ŝlosilo sub la nuna sojlo, nun malsukcesas dum la manpremo. Ĉar ankoraŭ nenio aŭtentikiĝis, la eraro legeblas kiel malĝusta pasvorto aŭ morta servilo.

La mallarĝa ripeto alligas ĉifroĉenon nur al ĉi tiu konekto. En la labortabla redaktilo malfermu la profilon, iru al la altnivelaj agordoj kaj metu DEFAULT:@SECLEVEL=0 en la kampon de TLS-ĉifro. La ŝlosildosiero de NetworkManager prenas la saman valoron sub [vpn]:

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

Restartigu NetworkManager kaj rekonektiĝu, ĉar la demono kaŝmemorigas analizitajn profilon kaj alie daŭre uzos la kopion, kiun ĝi jam tenas. Sciu, kion la linio faras antaŭ ol konservi ĝin: tiu agordo estas sojlo trans pluraj atestilaj kaj ŝlosilaj parametroj, ne ĉifra nomo, do malaltigi ĝin larĝigas tion, kion la unuopa profilo akceptas. Notu, kiu servilo postulis ĝin, kaj forlasu la agordon, kiam la funkciigisto reeldonos aktualan materialon. Ŝanĝi /etc/ssl/openssl.cnf atingas la saman sojlon por ĉiu programo, kiu legas tiun dosieron, kio multe superas la VPN.

OpenVPN 2.6 postulas la ĉifron listigita por negocado

Ubuntu 22.10 liveris OpenVPN 2.6, kaj en tiu eldono --cipher ĉesas mem elekti la datkanalon. La ĉifro devas ankaŭ ĉeesti en la negocita listo data-ciphers, alie la kliento presas averton pri malaktualiĝo kaj poste malsukcesas levi la tunelon.

La NetworkManager-kromaĵo el la sama periodo ankoraŭ skribis nur la malnovan direktivon. Tiu detalo dividas la diagnozon, ĉar profilo mane korektita povas konektiĝi el ŝelo kaj tamen malsukcesi el la labortabla aplikaĵeto. Aldonu la liston al la konekta dosiero sub [vpn]:

data-ciphers=AES-256-CBC

Uzu la valoron, kiun la servilo anoncas, ne tiun, kiun vi memoras; servilo proponanta AES-256-GCM ne negocos kun klienta listo nomanta nur CBC. Restartigu la administrilon kaj rekonektiĝu, poste ripetu la provon el ŝelo kun la ĉifro eksplicite pasigita kaj por negocado kaj por rezervo:

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

Se tiu komando levos la tunelon, la servilo, la atestiloj kaj la legitimiloj ĉiuj sanas, kaj la sola restanta difekto estas la konservita opcio de la administrilo. Averto pri la direktivo keysize apartenas al la sama purigado: komentuu ĝin kaj konservu la originalan dosieron apud la profilo.

Pakaĵaj kaj kromaĵaj difektoj aspektas kiel VPN-difektoj

Ne ĉiu malsukceso post ĝisdatigo estas kriptografia. OpenVPN-deponejo aldonita sub kodonomo, kiun la eldono ne uzas, produktas pakaĵon, kiu neniam instaliĝas, do komparu, kion lsb_release -a raportas, kun la listodosiero, kiun vi aldonis. Mankanta komponento universe aŭ sekureca poŝo produktas pakaĵon, kiu tute ne troveblas. Ambaŭ kazoj lasas la profilon netuŝita kaj la tunelon neebla.

Legu la eraron de la pakaĵadministrilo antaŭ la VPN-protokolo. Se la kliento neniam instaliĝis, neniu kvanto da profila redaktado produktos manpremon.

Dufaktoraj profilon, kiuj ĉesas demandi, estas la kromaĵa versio de la sama rakonto. La defio venas de aŭtentika kromaĵo, kaj ĝisdatigo, kiu forigis aŭ anstataŭigis ĝin, lasas la profilon sendifekta dum la invito malaperas. Reinstalu la subtenatan kromaĵon anstataŭ forigi la duan faktoron por igi la konekton funkcii.

Vendora biblioteko povas kaŝiĝi malantaŭ politika eraro

Unu ŝablono meritas rekonon, ĉar ĝi venkas ĉiun politikan riparon. Aparatvendora agordilo povas instali proprajn OpenSSL-bibliotekojn kaj meti ilin antaŭ la sistemajn kopiojn en la serĉvojo de la ŝargilo. La kliento tiam lanĉiĝas kontraŭ biblioteko, kiun neniu ĝisdatigis, kaj la lanĉa fiasko aspektas ekzakte kiel malakceptita atestilo.

Reinstalo de la VPN-pakaĵo ne ŝanĝas, kiu biblioteko troviĝas unue, kaj malaltigo de la TLS-nivelo ne atingas bibliotekon, kiu neniam venis de la sistemo. Demandu la ŝargilon, kiujn kriptobjektojn la binara dosiero efektive solvas:

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

Forigu aŭ readresu la vendoran kopion, poste rulu la saman kontrolon denove. La atendata versio devas esti tiu uzata antaŭ ol vi revenos al la profilo.

Fiksi pli malnovan klienton aĉetas tempon, ne solvon

Teni la antaŭan klientan version restarigas la tunelon dum la tenado daŭras. Ĝi ankaŭ frostigas sekurecajn ĝisdatigojn por tiu pakaĵo kaj planas la saman rompon por la sekva ĝisdatigo, do traktu ĝin kiel datitan provizoran solvon, ne kiel solvon.

Se vi tamen fiksas ĝin, tenu la pakaĵon eksplicite, por ke nesuperrigardata ĝisdatigo ne povu nuligi la fikson, notu la kialon kaj la daton por revizii, kaj starigu memorigilon por la sekva profila eldono de la provizanto. La kondiĉo inda je atento estas servila profilo, kiu negocas aktualan ĉifron; kiam ĝi ekzistas, la fikso ne plu havas iun justigon. Neregistrita fikso, kontraŭe, fariĝas interrompo, kiun neniu povas klarigi post duonjaro, ĉar la persono, kiu aplikis ĝin, jam foriris kaj la dosiero registras nenion.

La venontan fojon, kiam VPN mortas post eldona ĝisdatigo, demandu kvin demandojn sinsekve: kiu tavolo produktis la unuan eraron, ĉu la TLS-politiko malakceptis la atestilon, ĉu la ĉifro negocieblas en ambaŭ direktoj, ĉu la pakaĵo kaj ĝia kromaĵo efektive instaliĝis, kaj kiun bibliotekon la procezo ŝargas. Nur post kiam ĉiuj kvin revenas puraj, malaltigo de versio havas sencon.