Bakit tumigil ang OpenVPN sa pagkonekta pagkatapos ng upgrade ng Ubuntu?

Ang mga profile ng VPN na gumagana noong nakaraang linggo ay nasisira pagkatapos ng upgrade ng release ng Ubuntu, at bihirang banggitin ng log ang upgrade. Ang binabanggit nito ay ang layer na nabigo: ang TLS handshake, ang cipher na naayos para sa data channel, ang paketeng na-install, o ang kopya ng OpenSSL na ikinakarga ng binary sa pagsisimula. Bawat layer ay may sariling hugis ng error at sariling pagkukumpuni, kaya ang pag-uuri ang unang trabaho at ang pag-edit ang pangalawa. Ituring na inosente ang profile hanggang pangalanan ito ng log.

Aling layer ang nabigo: handshake, cipher, pakete o library

Basahin ang log ng client bago hawakan ang profile. Ang pinakaunang error sa output ang tumutukoy sa layer; lahat ng nakalimbag pagkatapos nito ay karaniwang bunga ng unang pagkabigong iyon. Kapag hindi talaga nagsisimula ang client, ang VPN log ang maling file na bubuksan.

Ang mga reklamo tungkol sa sertipiko at lagda, o mensahe tungkol sa haba ng key, ay galing sa control channel at sa patakaran ng library na nagrereglamento nito. Ang babala namang nagsisimula sa DEPRECATED OPTION ay kabilang sa negosasyon ng data channel.

Ang linyang gaya ng Unrecognized option ay ikatlong kategorya: hindi na tinatanggap ng bagong binary ang direktiba na tiniis ng luma, kaya kailangang isulat muli ang profile at hindi luwagan ang library. Iba na naman ang hitsura ng mga pagkabigo ng pakete dahil nangyayari ang mga ito bago tumakbo ang anumang tunnel code. Nawawalang binary, plugin na hindi naglo-load, o repositoryong tumuturo sa maling codename — lahat ay nagbibigay ng ganitong hugis. Apat na sintomas, apat na lugar na titingnan, at halos walang pagtatagpo sa pagitan ng mga pagkukumpuni.

Kapag nabigo ang handshake, tinatanggihan ng patakaran ng TLS ang sertipiko

Inilipat ng Ubuntu 22.04 ang sistema sa OpenSSL 3, at ang default na antas ng seguridad sa sangay na iyon ay mas mahigpit sa mga lagda ng sertipiko at laki ng key kaysa 20.04. Ang sertipikong CA na pinirmahan ng mas lumang digest, o key na mas mababa sa kasalukuyang hangganan, ay nabibigo ngayon sa handshake. Dahil wala pang napatunayan, ang error ay parang maling password o patay na server.

Ang makitid na pagkukumpuni ay naglalakip ng cipher string sa koneksiyong ito lamang. Sa desktop editor, buksan ang profile, pumunta sa advanced settings at ilagay ang DEFAULT:@SECLEVEL=0 sa field ng TLS cipher. Kinukuha ng NetworkManager keyfile ang parehong halaga sa ilalim ng [vpn]:

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

I-restart ang NetworkManager at kumonekta muli, dahil nagca-cache ang daemon ng mga na-parse na profile at kung hindi ay gagamitin pa rin ang kopyang hawak na nito. Alamin ang ginagawa ng linya bago ito itago: ang setting na iyon ay hangganan sa ilang parameter ng sertipiko at key, hindi pangalan ng cipher, kaya ang pagbaba nito ay nagpapalawak ng tinatanggap ng nag-iisang profile. Itala kung aling server ang humiling nito at bitawan ang setting kapag naglabas muli ang operator ng kasalukuyang materyal. Ang pagbabago ng /etc/ssl/openssl.cnf ay umaabot sa parehong hangganan para sa bawat programang nagbabasa ng file na iyon, na malayo pa sa VPN.

Inaatasan ng OpenVPN 2.6 na nakalista ang cipher para sa negosasyon

Dinala ng Ubuntu 22.10 ang OpenVPN 2.6, at sa release na iyon ay --cipher tumitigil sa pagpili ng data channel nang mag-isa. Dapat ding naroroon ang cipher sa naayos na data-ciphers listahan, kung hindi ay maglilimbag ang client ng babala sa pagka-luma at pagkatapos ay hindi maiangat ang tunnel.

Ang plugin ng NetworkManager mula sa parehong panahon ay sumusulat pa rin ng lumang direktiba lamang. Hinahati ng detalyeng ito ang diagnosis, dahil ang profile na kinumpuni sa kamay ay makakakonekta mula sa shell at babagsak pa rin mula sa desktop applet. Idagdag ang listahan sa connection file sa ilalim ng [vpn]:

data-ciphers=AES-256-CBC

Gamitin ang halagang inaanunsiyo ng server, hindi ang natatandaan mo; ang server na nag-aalok ng AES-256-GCM ay hindi makikipagnegosasyon sa listahan ng client na CBC lamang ang binabanggit. I-restart ang manager at kumonekta muli, pagkatapos ay ulitin ang pagtatangka mula sa shell na tahasang ibinigay ang cipher para sa negosasyon at fallback:

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

Kung maiangat ng utos na iyon ang tunnel, maayos ang server, mga sertipiko at kredensyal, at ang tanging natitirang depekto ay ang naka-save na opsiyon ng manager. Ang babala tungkol sa direktibang keysize ay kabilang sa parehong paglilinis: i-comment ito at itago ang orihinal na file sa tabi ng profile.

Ang mga depekto ng pakete at plugin ay mukhang depekto ng VPN

Hindi lahat ng pagkabigo pagkatapos ng upgrade ay kriptograpiko. Ang repositoryo ng OpenVPN na idinagdag sa ilalim ng codename na hindi ginagamit ng release ay gumagawa ng paketeng hindi kailanman nai-install, kaya ihambing ang iniuulat ng lsb_release -a sa listahang file na idinagdag mo. Ang nawawalang universe component o bulsa ng seguridad ay gumagawa ng paketeng hindi talaga mahanap. Kapwa iniiwan ng dalawang kaso ang profile na hindi nagalaw at ang tunnel na imposible.

Basahin ang error ng package manager bago ang VPN log. Kung kailanman ay hindi na-install ang client, walang dami ng pag-edit ng profile ang magbubunga ng handshake.

Ang mga two-factor na profile na tumitigil sa pagtatanong ay ang bersiyon ng plugin ng parehong kuwento. Galing sa authentication plugin ang hamon, at ang upgrade na nag-alis o pumalit dito ay iniiwan ang profile na buo habang naglalaho ang prompt. I-install muli ang sinusuportahang plugin sa halip na burahin ang ikalawang factor upang gumana ang koneksiyon.

Maaaring magtago ang library ng vendor sa likod ng error ng patakaran

Isang pattern ang dapat makilala dahil natatalo nito ang bawat pagkukumpuni ng patakaran. Ang configuration tool ng vendor ng hardware ay maaaring mag-install ng sariling mga library ng OpenSSL at ilagay ang mga ito sa unahan ng mga kopya ng sistema sa search path ng loader. Pagkatapos ay nagsisimula ang client laban sa library na walang nag-upgrade, at ang pagkabigo sa pagsisimula ay kamukhang-kamukha ng tinanggihang sertipiko.

Ang muling pag-install ng VPN package ay hindi nagbabago kung aling library ang unang mahahanap, at ang pagbaba ng antas ng TLS ay hindi umaabot sa library na hindi kailanman galing sa sistema. Itanong sa loader kung aling mga crypto object ang tunay na nireresolba ng binary:

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

Alisin o i-redirect ang kopya ng vendor, pagkatapos ay patakbuhin muli ang parehong pagsusuri. Ang inaasahang bersiyon ay dapat ang ginagamit bago ka bumalik sa profile.

Ang pag-pin ng lumang client ay bumibili ng oras, hindi solusyon

Ang pagpapanatili ng nakaraang bersiyon ng client ay nagbabalik ng tunnel hangga't tumatagal ang paghawak. Pinipigil din nito ang mga update sa seguridad para sa paketeng iyon at nagpaplano ng parehong pagkasira sa susunod na upgrade, kaya ituring itong may petsang pansamantalang hakbang, hindi solusyon.

Kung ipipin mo pa rin ito, hawakan ang pakete nang tahasan upang hindi ito maalis ng upgrade na walang nagmamasid, isulat ang dahilan at petsa ng muling pagsusuri, at magtakda ng paalala para sa susunod na paglabas ng profile ng provider. Ang kondisyong dapat bantayan ay profile ng server na nakikipagnegosasyon sa kasalukuyang cipher; kapag umiiral na iyon, wala nang katwiran ang pag-pin. Sa kabilang banda, ang pin na hindi naitala ay nagiging pagkagambala na walang makapagpapaliwanag makalipas ang anim na buwan, dahil umalis na ang taong naglapat nito at wala namang naitala ang file.

Sa susunod na mamatay ang VPN pagkatapos ng upgrade ng release, magtanong ng limang katanungan sa sunod-sunod: aling layer ang gumawa ng unang error, tinanggihan ba ng patakaran ng TLS ang sertipiko, negotiable ba ang cipher sa dalawang direksiyon, talaga bang na-install ang pakete at ang plugin nito, at aling library ang ikinakarga ng proseso. Kapag ang lima ay malinis na bumalik, saka lamang may saysay ang downgrade.