რატომ შეწყვიტა 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-ის დანამატი კვლავ მხოლოდ ძველ დირექტივას წერდა. ეს დეტალი დიაგნოზს ყოფს, რადგან ხელით გასწორებული პროფილი შელიდან დაუკავშირდება და მაინც ჩავარდება სამუშაო მაგიდის აპლეტიდან. დაამატეთ სია კავშირის ფაილში [vpn]-ის ქვეშ:

data-ciphers=AES-256-CBC

გამოიყენეთ ის მნიშვნელობა, რომელსაც სერვერი აცხადებს და არა ის, რაც გახსოვთ; AES-256-GCM-ის შემომთავაზებელი სერვერი არ იმოლაპარაკებს კლიენტის სიასთან, რომელიც მხოლოდ CBC-ს ასახელებს. გადატვირთეთ მენეჯერი და ხელახლა დაუკავშირდით, შემდეგ გაიმეორეთ მცდელობა შელიდან შიფრის ცალსახად გადაცემით როგორც მოლაპარაკებისთვის, ისე სარეზერვოდ:

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 პოლიტიკამ სერტიფიკატი, მოლაპარაკებადია თუ არა შიფრი ორივე მიმართულებით, ნამდვილად დაყენდა თუ არა პაკეტი და მისი დანამატი და რომელ ბიბლიოთეკას იტვირთავს პროცესი. მხოლოდ მას შემდეგ, რაც ხუთივე სუფთად დაბრუნდება, ვერსიის დაწევას აქვს აზრი.