Ինչու՞ OpenVPN-ը դադարեց միանալ Ubuntu-ի թարմացումից հետո

Անցյալ շաբաթ աշխատող VPN պրոֆիլները կոտրվում են Ubuntu-ի թողարկման թարմացումից հետո, և մատյանը հազվադեպ է նշում թարմացումը։ Այն, ինչ նա անվանում է, այն շերտն է, որը ձախողվել է՝ TLS ձեռքսեղմումը, տվյալների ալիքի համար բանակցված գաղտնագրումը, տեղադրված փաթեթը կամ OpenSSL-ի այն պատճենը, որը բինարը բեռնում է գործարկման պահին։ Յուրաքանչյուր շերտ ունի իր սխալի ձևը և իր վերանորոգումը, ինչը դասակարգումը դարձնում է առաջին աշխատանքը, իսկ խմբագրումը՝ երկրորդը։ Պրոֆիլը համարեք անմեղ, քանի դեռ մատյանը չի անվանել այն։

Ո՞ր շերտը ձախողվեց՝ ձեռքսեղմումը, գաղտնագրումը, փաթեթը, թե գրադարանը

Կարդացեք հաճախորդի մատյանը նախքան պրոֆիլին դիպչելը։ Ելքի ամենավաղ սխալը այն է, որը նույնացնում է շերտը. այն ամենը, ինչ տպվում է դրանից հետո, սովորաբար այդ առաջին ձախողման հետևանքն է։ Երբ հաճախորդն ընդհանրապես չի գործարկվում, VPN-ի մատյանը սխալ ֆայլ է բացելու համար։

Վկայագրերի և ստորագրությունների վերաբերյալ բողոքները կամ բանալու երկարության մասին հաղորդագրությունը գալիս են կառավարման ալիքից և այն կարգավորող գրադարանի քաղաքականությունից։ Իսկ DEPRECATED OPTION-ով սկսվող նախազգուշացումը պատկանում է տվյալների ալիքի բանակցությանը։

Նման տողը Unrecognized option երրորդ կարգն է. նոր բինարն այլևս չի ընդունում հրահանգ, որը հինը հանդուրժում էր, ուստի պրոֆիլը պետք է վերաշարադրվի, ոչ թե գրադարանը թուլացվի։ Փաթեթային ձախողումները նորից այլ տեսք ունեն, որովհետև դրանք տեղի են ունենում մինչև թունելի որևէ կոդի գործարկվելը։ Բացակայող բինար, չբեռնվող հավելում կամ սխալ կոդային անվանը հղվող պահոց՝ բոլորը տալիս են այդ ձևը։ Չորս ախտանիշ, դիտելու չորս տեղ, և վերանորոգումների միջև գրեթե ոչ մի համընկնում։

Երբ ձեռքսեղմումը ձախողվում է, TLS քաղաքականությունը մերժում է վկայագիրը

Ubuntu 22.04-ը համակարգը տեղափոխեց OpenSSL 3, և այդ ճյուղում լռելյայն անվտանգության մակարդակն ավելի խիստ է վկայագրերի ստորագրությունների և բանալիների չափերի նկատմամբ, քան 20.04-ում էր։ Ավելի հին մարսողությամբ ստորագրված CA վկայագիրը կամ ընթացիկ շեմից ցածր բանալին այժմ ձախողվում է ձեռքսեղմման ընթացքում։ Քանի որ դեռ ոչինչ չի նույնականացվել, սխալը կարդացվում է որպես սխալ գաղտնաբառ կամ մեռած սերվեր։

Նեղ վերանորոգումը գաղտնագրման տողը կցում է միայն այս միացմանը։ Սեղանադիր խմբագրիչում բացեք պրոֆիլը, անցեք լրացուցիչ կարգավորումներին և դրեք DEFAULT:@SECLEVEL=0 TLS գաղտնագրման դաշտում։ NetworkManager-ի բանալու ֆայլը վերցնում է նույն արժեքը [vpn] բաժնի տակ.

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

Վերագործարկեք NetworkManager-ը և նորից միացեք, որովհետև ծառայությունը պահում է վերլուծված պրոֆիլները քեշում և հակառակ դեպքում կշարունակի օգտագործել արդեն ունեցած պատճենը։ Իմացեք, թե ինչ է անում տողը նախքան այն պահելը. այդ կարգավորումը շեմ է մի քանի վկայագրի և բանալու պարամետրերի վրա, ոչ թե գաղտնագրման անուն, ուստի այն իջեցնելը լայնացնում է, ինչ ընդունում է առանձին պրոֆիլը։ Նշեք, թե որ սերվերն է դա պահանջել, և թողեք կարգավորումը, երբ օպերատորը վերաթողարկի ընթացիկ նյութը։ Իսկ /etc/ssl/openssl.cnf փոխելը հասնում է նույն շեմին այդ ֆայլը կարդացող յուրաքանչյուր ծրագրի համար, ինչը շատ ավելի հեռու է VPN-ից։

OpenVPN 2.6-ը պահանջում է գաղտնագրումը բանակցության ցանկում

Ubuntu 22.10-ը բերեց OpenVPN 2.6, և այդ թողարկումում --cipher դադարում է ինքնուրույն ընտրել տվյալների ալիքը։ Գաղտնագրումը պետք է նաև լինի բանակցված data-ciphers ցանկում, հակառակ դեպքում հաճախորդը տպում է հնացման նախազգուշացում և հետո չի կարողանում բարձրացնել թունելը։

Նույն ժամանակաշրջանի NetworkManager հավելումը դեռ գրում էր միայն հին հրահանգը։ Այդ մանրամասնությունը բաժանում է ախտորոշումը, որովհետև ձեռքով ուղղված պրոֆիլը կարող է միանալ shell-ից և այնուամենայնիվ ձախողվել սեղանադիր հավելվածից։ Ավելացրեք ցանկը միացման ֆայլում [vpn] բաժնի տակ.

data-ciphers=AES-256-CBC

Օգտագործեք այն արժեքը, որը հայտարարում է սերվերը, ոչ թե այն, ինչ հիշում եք. AES-256-GCM առաջարկող սերվերը չի բանակցի հաճախորդի ցանկի հետ, որը նշում է միայն CBC։ Վերագործարկեք կառավարիչը և նորից միացեք, ապա կրկնեք փորձը shell-ից՝ գաղտնագրումը բացահայտ փոխանցելով և՛ բանակցության, և՛ պահուստի համար.

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

Եթե այդ հրամանը բարձրացնում է թունելը, ապա սերվերը, վկայագրերը և հավատարմագրերն առողջ են, և միակ մնացած թերությունը կառավարչի պահված տարբերակն է։ keysize հրահանգի մասին նախազգուշացումը նույն մաքրմանն է պատկանում. մեկնաբանեք այն և բնօրինակ ֆայլը պահեք պրոֆիլի կողքին։

Փաթեթի և հավելումի թերությունները նման են VPN-ի թերություններին

Թարմացումից հետո ամեն ձախողում գաղտնագրային չէ։ Թողարկմանը չօգտագործվող կոդային անվան տակ ավելացված OpenVPN պահոցը տալիս է փաթեթ, որը երբեք չի տեղադրվում, ուստի համեմատեք, թե ինչ է հաղորդում lsb_release -a ձեր ավելացրած ցանկի ֆայլի հետ։ Բացակայող universe բաղադրիչը կամ անվտանգության գրպանը տալիս է փաթեթ, որը ընդհանրապես հնարավոր չէ գտնել։ Երկու դեպքում էլ պրոֆիլը մնում է անձեռնմխելի, իսկ թունելը՝ անհնար։

Կարդացեք փաթեթների կառավարչի սխալը VPN-ի մատյանից առաջ։ Եթե հաճախորդը երբեք չի տեղադրվել, պրոֆիլի խմբագրման ոչ մի քանակություն ձեռքսեղմում չի տա։

Երկու գործոնով պրոֆիլները, որոնք դադարում են հարցնել, նույն պատմության հավելումային տարբերակն են։ Մարտահրավերը գալիս է նույնականացման հավելումից, և այն հեռացրած կամ փոխարինած թարմացումը պրոֆիլը թողնում է անձեռնմխելի, մինչ հուշումն անհետանում է։ Վերատեղադրեք աջակցվող հավելումը՝ երկրորդ գործոնը ջնջելու փոխարեն, որպեսզի միացումն աշխատի։

Մատակարարի գրադարանը կարող է թաքնվել քաղաքականության սխալի հետևում

Մեկ օրինաչափություն արժանի է ճանաչման, որովհետև հաղթահարում է քաղաքականության ցանկացած վերանորոգում։ Սարքաշարի մատակարարի կարգավորման գործիքը կարող է տեղադրել իր սեփական OpenSSL գրադարանները և դրանք դնել համակարգի պատճեններից առաջ բեռնիչի որոնման ուղում։ Այնուհետև հաճախորդը գործարկվում է գրադարանի դեմ, որը ոչ ոք չի թարմացրել, և գործարկման ձախողումը ճիշտ մերժված վկայագրի տեսք ունի։

VPN փաթեթի վերատեղադրումը չի փոխում, թե որ գրադարանն է առաջինը գտնվում, և TLS մակարդակի իջեցումը չի հասնում համակարգից երբեք չեկած գրադարանի։ Հարցրեք բեռնիչին, թե որ գաղտնագրային օբյեկտներն է բինարը իրականում լուծում.

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

Հեռացրեք կամ վերահասցեավորեք մատակարարի պատճենը, ապա նորից գործարկեք նույն ստուգումը։ Սպասվող տարբերակը պետք է լինի օգտագործվողը, նախքան պրոֆիլին վերադառնալը։

Հին հաճախորդի ամրագրումը ժամանակ է գնում, ոչ լուծում

Նախորդ հաճախորդի տարբերակը պահելը վերականգնում է թունելը այնքան, որքան պահումը տևում է։ Այն նաև սառեցնում է այդ փաթեթի անվտանգության թարմացումները և նույն կոտրումը պլանավորում հաջորդ թարմացման համար, ուստի դա համարեք ամսաթվով ժամանակավոր լուծում, ոչ թե լուծում։

Եթե այնուամենայնիվ ամրագրեք, փաթեթը պահեք բացահայտ, որպեսզի չհսկվող թարմացումը չկարողանա չեղարկել ամրագրումը, գրեք պատճառը և վերանայման ամսաթիվը, և հիշեցում դրեք մատակարարի հաջորդ պրոֆիլի թողարկման համար։ Հետևելու արժանի պայմանը սերվերի պրոֆիլն է, որը բանակցում է ընթացիկ գաղտնագրում. հենց այն գոյություն ունենա, ամրագրումն այլևս արդարացում չունի։ Իսկ չգրանցված ամրագրումը վեց ամիս անց դառնում է ընդհատում, որը ոչ ոք չի կարող բացատրել, որովհետև այն կիրառողը հեռացել է, և ֆայլը ոչինչ չի գրանցում։

Հաջորդ անգամ, երբ VPN-ը մահանա թողարկման թարմացումից հետո, հինգ հարց տվեք հերթով. ո՞ր շերտն է տվել առաջին սխալը, արդյոք TLS քաղաքականությունը մերժե՞լ է վկայագիրը, արդյոք գաղտնագրումը բանակցելի է երկու ուղղությամբ, արդյոք փաթեթը և դրա հավելումը իրականում տեղադրվե՞լ են, և ո՞ր գրադարանն է բեռնում գործընթացը։ Միայն այն բանից հետո, երբ բոլոր հինգը մաքուր վերադառնան, իջեցումն իմաստ ունի։