Hvers vegna hætti OpenVPN að tengjast eftir Ubuntu-uppfærslu?
Ubuntu 22.04 og 22.10 breyttu OpenSSL-stefnunni, sjálfgefnu dulritunarsamningunum og sjálfgefnum pakkastillingum. Lestu það stig sem bregst áður en þú breytir sniðinu.
VPN-snið sem virkuðu í síðustu viku brotna eftir uppfærslu á Ubuntu-útgáfu, og annállinn nefnir uppfærsluna sjaldan. Það sem hann nefnir er lagið sem brást: TLS-handtakið, dulritunin sem samið var um fyrir gagnarásina, pakkinn sem var settur upp, eða afritið af OpenSSL sem keyrsluskráin hleður við ræsingu. Hvert lag hefur sína villumynd og sína viðgerð, sem gerir flokkun að fyrsta verkinu og breytingar að því öðru. Líttu á sniðið sem saklaust þar til annállinn nefnir það.
Hvaða lag brást: handtak, dulritun, pakki eða bókasafn
Lestu annál biðlarans áður en þú snertir sniðið. fyrsta villan í úttakinu er sú sem greinir lagið; allt sem prentast eftir henni er yfirleitt afleiðing þess fyrsta brests. Þegar biðlarinn ræsist alls ekki er VPN-annállinn rangi skráin til að opna.
Kvartanir um skírteini og undirskriftir, eða skilaboð um lyklalengd, koma frá stjórnrásinni og bókasafnsstefnunni sem stjórnar henni. Viðvörun sem hefst á DEPRECATED OPTION tilheyrir hins vegar samningum gagnarásarinnar.
Lína eins og Unrecognized option er þriðji flokkur: nýja keyrsluskráin samþykkir ekki lengur tilskipun sem hin gamla þoldi, svo breyta þarf sniðinu frekar en að slaka á bókasafninu. Pökkunarbilanir líta aftur öðruvísi út því þær gerast áður en nokkur göngukóði keyrir. Vantar keyrsluskrá, viðbót sem hleðst ekki eða geymsla sem vísar á ranga kóðaheiti gefa allar þessa mynd. Fjögur einkenni, fjórir staðir til að skoða og nánast engin skörun milli viðgerðanna.
Þegar handtakið bregst hafnar TLS-stefnan skírteininu
Ubuntu 22.04 færði kerfið yfir á OpenSSL 3, og sjálfgefið öryggisstig í þeirri grein er strangara um undirskriftir skírteina og lyklastærðir en 20.04 var. CA-skírteini undirritað með eldri þéttingu, eða lykill undir núverandi þröskuldi, bregst nú við handtakið. Þar sem ekkert hefur verið auðkennt enn þá lesst villan eins og rangt lykilorð eða dauður miðlari.
Þrönga viðgerðin festir dulritunartákn við þessa tengingu eina. Í skjáborðsritlinum skaltu opna sniðið, fara í ítarlegu stillingarnar og setja DEFAULT:@SECLEVEL=0 í TLS-dulritunarsviðið. Lykilskrá NetworkManager tekur sama gildi undir [vpn]:
[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0Endurræstu NetworkManager og tengstu aftur, því þjónustan skyggnir þáttuðum sniðum og myndi annars halda áfram að nota afritið sem hún hefur þegar. Vitaðu hvað línan gerir áður en þú heldur henni: stillingin er þröskuldur yfir nokkrar skírteina- og lyklabreytur, ekki dulritunarnafn, svo lækkun hennar víkkar það sem einstaka sniðið samþykkir. Skrifaðu niður hvaða miðlari krafðist hennar og slepptu stillingunni þegar rekstraraðilinn gefur út efnið að nýju. Að breyta /etc/ssl/openssl.cnf nær sama þröskuldi fyrir hvert forrit sem les þá skrá, sem er langt út fyrir VPN-ið.
OpenVPN 2.6 krefst þess að dulritunin sé skráð fyrir samningana
Ubuntu 22.10 kom með OpenVPN 2.6, og í þeirri útgáfu hættir --cipher að velja gagnarásina sjálft. Dulritunin verður einnig að vera á samningslistanum data-ciphers, annars prentar biðlarinn úreldingarviðvörun og nær svo ekki að reisa göngin.
NetworkManager-viðbótin frá sama tímabili skrifaði enn aðeins gömlu tilskipunina. Þessi smáatriði skipta greiningunni, því snið sem lagfært er í höndunum getur tengst úr skel og samt brugðist úr skjáborðsforritinu. Bættu listanum við tengiskrána undir [vpn]:
data-ciphers=AES-256-CBCNotaðu gildið sem miðlarinn auglýsir, ekki það sem þú manst; miðlari sem býður AES-256-GCM semur ekki við biðlaralista sem nefnir aðeins CBC. Endurræstu stjórnandann og tengstu aftur, endurtaktu svo tilraunina úr skel með dulritunina gefna skýrt bæði fyrir samninga og varaleið:
sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBCEf sú skipun reisir göngin eru miðlarinn, skírteinin og skilríkin öll heilbrigð, og eina eftirverandi gallinn er geymd stilling stjórnandans. Viðvörun um tilskipunina keysize tilheyrir sömu hreinsun: settu hana í athugasemd og geymdu upprunalegu skrána við sniðið.
Pakkningar- og viðbótargallar líta út eins og VPN-gallar
Ekki er sérhver bilun eftir uppfærslu dulritunarleg. OpenVPN-geymsla sem bætt er við undir kóðaheiti sem útgáfan notar ekki framleiðir pakka sem aldrei er settur upp, svo berðu saman það sem lsb_release -a greinir frá við listaskrána sem þú bættir við. Vantar universe hluta eða öryggisvasa og fæst pakki sem finnst alls ekki. Bæði tilvikin láta sniðið ósnert og göngin ómöguleg.
Lestu villu pakkastjórans áður en VPN-annállinn er skoðaður. Ef biðlarinn var aldrei settur upp mun engin sniðbreyting framleiða handtak.
Tveggja þátta snið sem hætta að spyrja eru viðbótarútgáfa sömu sögu. Áskorunin kemur frá auðkenningarviðbót, og uppfærsla sem sleppti henni eða skipti um hana lætur sniðið ósnert á meðan beiðnin hverfur. Settu upp studda viðbótina aftur í stað þess að eyða öðrum þættinum svo tengingin virki.
Bókasafn framleiðanda getur falið sig bak við stefnuvillu
Eitt mynstur á skilið að þekkjast því það sigrar hverja stefnuviðgerð. Stillingartól vélbúnaðarframleiðanda getur sett upp sín eigin OpenSSL-bókasöfn og raðað þeim framar kerfisafritunum í leitarslóð hleðslunnar. Biðlarinn ræsist þá gegn bókasafni sem enginn hefur uppfært, og ræsingarbilunin lítur nákvæmlega út eins og hafnað skírteini.
Enduruppsetning VPN-pakkans breytir ekki því hvaða bókasafn finnst fyrst, og lækkun TLS-stigs nær ekki bókasafni sem aldrei kom frá kerfinu. Spurðu hleðsluna hvaða dulritunarhluti keyrsluskráin leysir í raun:
ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'Fjarlægðu eða endurvísaðu afriti framleiðandans og keyrðu svo sömu athugun aftur. Vænta útgáfan verður að vera sú sem er í notkun áður en þú snýrð aftur að sniðinu.
Að festa eldri biðlara kaupir tíma, ekki lausn
Að halda fyrri biðlaraútgáfunni endurheimtir göngin svo lengi sem haldið varir. Það frystir einnig öryggisuppfærslur fyrir þann pakka og áætlar sömu brotnun fyrir næstu uppfærslu, svo líttu á það sem dagsetta bráðabirgðalausn, ekki lausn.
Ef þú festir hann engu að síður skaltu halda pakkanum skýrt svo óeftirlitð uppfærsla geti ekki afturkallað festinguna, skrifa niður ástæðuna og dagsetninguna til endurskoðunar og setja áminningu fyrir næstu sniðútgáfu þjónustuaðilans. Skilyrðið sem vert er að fylgjast með er miðlarasnið sem semur um núverandi dulritun; þegar það er til á festingin enga réttlætingu eftir. Óskráð festing verður hins vegar bilun sem enginn getur útskýrt hálfu ári síðar, því sá sem setti hana er farinn og skráin skráir ekkert.
Næst þegar VPN deyr eftir útgáfuuppfærslu skaltu spyrja fimm spurninga í röð: hvaða lag framleiddi fyrstu villuna, hafnaði TLS-stefnan skírteininu, er hægt að semja um dulritunina í báðar áttir, voru pakkinn og viðbótin hans raunverulega sett upp, og hvaða bókasafn hleður ferlið. Aðeins þegar allar fimm koma hreinar til baka er niðurfærsla skynsamleg.