ძველი .ovpn პროფილი Ubuntu 24.04-ზე ვერ მუშაობს: რომელი სტრიქონები უნდა წაიშალოს

Ubuntu 24.04 OpenVPN 2.6-ს მოაქვს, ხოლო 2.4-ისთვის ექსპორტირებული პროფილი წაშლილ პარამეტრებზე ჩერდება. წაშალეთ keysize და ncp-disable, შემდეგ გაასწორეთ ns-cert-type.

პროფილი ჩამოიტვირთება, იმპორტირდება და შემდეგ ჩერდება ფაილის 12-ე სტრიქონზე Unrecognized option შეტყობინებით, რომელშიც keysize არის მოხსენიებული. ანგარიშზე არაფერი შეცვლილა და სერვერი კვლავ იღებს სხვა კლიენტებს. შეიცვალა თავად კლიენტი: Ubuntu 24.04 აყენებს OpenVPN 2.6-ს, მაშინ როცა ექსპორტი 2.4-ისთვის დაიწერა. გასწორება წაშლების მოკლე მიმდევრობაა და თანმიმდევრობას მნიშვნელობა აქვს, რადგან ყოველი მოძველებული პარამეტრი ანალიზს წყვეტს მანამ, სანამ შემდეგი წაიკითხება.

წაიკითხეთ შეცდომის სტრიქონი ფაილზე ხელის დაჭერამდე

OpenVPN ასახელებს ფაილს და სტრიქონს, სადაც ანალიზი შეჩერდა, ამიტომ ერთ გაშვებაზე მხოლოდ ერთი პრობლემის გასწორება შეგიძლიათ. გაუშვით პროფილი ტერმინალიდან და არა სამუშაო მაგიდის აპლეტიდან, რადგან აპლეტი ჩვეულებრივ ყლაპავს stderr-ს და სტრიქონის ნომერი ერთადერთი სანდო მინიშნებაა, რომელსაც მიიღებთ: sudo openvpn --config /etc/openvpn/client/provider.ovpn. გაასწორეთ ის სტრიქონი, გაუშვით ხელახლა და დაელოდეთ, რომ შემდეგი წარუმატებლობა სხვა პარამეტრს დაასახელებს.

ანალიზის შეცდომა ყოველთვის ჩნდება ნებისმიერ TLS ხელის ჩამორთმევამდე, ამიტომ სერტიფიკატის ხსენება ნიშნავს, რომ შეტყობინებამ სინტაქსის ეტაპი უკვე გაიარა. ეს განსხვავება გიშლით ხელს შეასწოროთ ფაილი, რომელიც მხოლოდ ავთენტიფიკაციაზე ვარდება. წაიკითხეთ შეტყობინების პირველი სიტყვა და არა მისი შუა.

წარუმატებლობის სამი კლასი, სამი განსხვავებული გასწორება

ძველი ექსპორტები სამი განსხვავებული გზით ვარდება და სწორედ მათი ერთ პრობლემად გაერთიანება აიძულებს ადამიანებს ხელახლა დააყენონ პაკეტები, რომლებიც არასდროს გატეხილა. შეტყობინების ფორმულირება გეუბნებათ, რომელ კლასში ხართ, სანამ ფაილს გახსნით.

  • ანალიზის შეცდომები ასახელებენ ფაილს და სტრიქონს და ჩერდებიან ნებისმიერი ტრაფიკის გაჩენამდე.
  • მოლაპარაკების შეცდომები უერთდებიან და შემდეგ აცხადებენ, რომ ორი მხარე საერთო დაშიფვრასა თუ მისაღებ მონაცემთა არხზე ვერ შეთანხმდა.
  • ავთენტიფიკაციის შეცდომები ყველაზე შორს მიდიან და ასახელებენ სერტიფიკატს, მომხმარებელს ან უარყოფილ მონაცემს.

პროფილის რედაქტირება მხოლოდ პირველ კლასს ასწორებს. მოლაპარაკებას გადაწყვეტილება სჭირდება გვირაბის ორივე ბოლოში, ხოლო უარყოფილი მონაცემები სინტაქსის პრობლემა სულაც არ არის. თუ თქვენი შეტყობინება საერთო დაშიფვრას ან მონაცემთა არხს ხსნის, ქვემოთ მოცემული წაშლები ვერაფერს შეცვლის.

წაშალეთ 2.6-ის მიერ მოხსნილი პარამეტრები ამ თანმიმდევრობით

თითოეული ეს სტრიქონი დამოუკიდებლად აჩერებს ანალიზს, ამიტომ კლიენტი მათ სათითაოდ აცხადებს. ჩამოდით სიაში და ყოველი წაშლის შემდეგ ხელახლა გაუშვით.

ჯერ წაშალეთ keysize, რადგან მას თანამედროვე შესატყვისი არ აქვს და მისი არსებობა ჩვეულებრივ ნიშნავს დაშიფვრას, რომელსაც მიმდინარე კლიენტი მაინც უარყოფს. შემდეგ წაშალეთ ncp-disable, რომელიც დაშიფვრის მოლაპარაკებას აკონტროლებდა, 2.5-ში მოძველდა და 2.6-ში აღარ არის. შეცვალეთ ns-cert-type server remote-cert-tls server-ით, რომელიც იმავე განზრახვას მხარდაჭერილი შემოწმებით გამოხატავს. 2.6-ის ცვლილებების ისტორია დარჩენილ მოხსნებს მათ შემცვლელებთან ერთად ჩამოთვლის, ამიტომ ყველაფერს, რასაც ანალიზატორი ჯერ კიდევ უარყოფს, დოკუმენტირებული პასუხი აქვს.

პირველ რედაქტირებამდე შეინახეთ ორიგინალი პროფილის ასლი. პროვაიდერები ექსპორტს ხელახლა ქმნიან და გაუხები ფაილთან diff თქვენი ცვლილებების მათგან გასამიჯნავად ყველაზე სწრაფი გზაა. თუ წაშლის შემდეგ კლიენტი ირთვება, მაგრამ გვირაბი კვლავ ვარდება, თქვენ მოლაპარაკების კლასში გადახვედით და დარჩენილი სტრიქონები მიზეზი არ არის. ჩაწერეთ კლიენტის ვერსია ფაილის სახელში, რომ შემდეგმა ადამიანმა იცოდეს, რომელ გამოშვებაზეა მიმართული რედაქტირება.

BF-CBC მხოლოდ შეზღუდულ სარეზერვო ვარიანტად ამუშავეთ

ზოგი პროვაიდერი კვლავ BF-CBC-ზე ამთავრებს კავშირს, რაზეც OpenVPN 2.6 დახმარების გარეშე არ იმოლაპარაკებს, რადგან დაშიფვრის ბლოკი 64 ბიტია. ვიწრო გასწორება სარეზერვო სია და OpenSSL-ის ძველი პროვაიდერია და არა მთელი კლიენტის დაქვეითება.

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

პირველი სტრიქონი ძველ პროვაიდერს ტვირთავს, რომ OpenSSL-მა ჯერ კიდევ შეძლოს ამ დაშიფვრის შექმნა, მეორე ინარჩუნებს თანამედროვე მოლაპარაკებას მხარდამჭერი პარტნიორებისთვის, ხოლო მესამე მხოლოდ მაშინ მოქმედებს, როცა სერვერი უკეთესს არ სთავაზობს. ეს გვირაბის განზრახ შესუსტებაა, ამიტომ ფაილის გვერდით ჩაწერეთ, რატომ არსებობს. ამავდროულად სთხოვეთ პროვაიდერს ხელახლა შექმნილი ექსპორტი, რადგან სარეზერვო ვარიანტი ხიდია და არა დანიშნულება.

ნუ მიმართავთ --compat-mode-ს როგორც საყოველთაო პასუხს. ის ერთდროულად რამდენიმე ქცევას ცვლის, მათ შორის მოლაპარაკებისა და ხელახალი მოლაპარაკების ნაგულისხმევებს, ამიტომ ვერასდროს გაიგებთ, რომელი ცვლილება იყო მნიშვნელოვანი. ამჯობინეთ ზემოთ მოცემული სამი ცხადი სტრიქონი, რადგან თითოეული თავის ეფექტს აცხადებს.

შეამოწმეთ იმ პროფილით, რომელსაც კლიენტი რეალურად ტვირთავს

იმპორტირებული კავშირები ხშირად სისტემურ საქაღალდეში კოპირდება, ამიტომ ჩამოტვირთვების საქაღალდეში ფაილის რედაქტირებამ შეიძლება საერთოდ არაფერი შეცვალოს. იპოვეთ ის ასლი, რომელიც მუშაობს: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. შემდეგ გაუშვით გვირაბი და წაიკითხეთ ჟურნალის ის სტრიქონი, რომელიც აცხადებს, თუ რომელი მონაცემთა არხის დაშიფვრა აირჩა რეალურად. კავშირი, რომელიც ხელის ჩამორთმევას სარეზერვო ვარიანტზე ამთავრებს, გეუბნებათ, რომ სერვერს არასდროს შემოუთავაზებია თანამედროვე რამ.

სცადეთ იმ ქსელიდან, რომელიც პროვაიდერის მოსალოდნელი ქსელი არ არის, რათა დატყვევებული პორტალი ან გაფილტრული სასტუმრო ქსელი პროფილის ხარვეზად არ მოგვეჩვენოს. ჩაწერეთ კლიენტის ვერსია ნებისმიერ მხარდაჭერის მოთხოვნასთან ერთად.

როცა გვირაბი აწეულია, გაგზავნეთ ერთი მოთხოვნა, რომელიც მასში უნდა გაიაროს, და ერთი, რომელიც არ უნდა, შემდეგ კი დაადასტურეთ, რომ გადამწყვეტის პასუხი თქვენი მოლოდინისამებრ შეიცვალა. თუ პროფილი ახლა ანალიზდება, მაგრამ კავშირი კვლავ ვარდება, თქვენ სინტაქსის პრობლემა უკან დატოვეთ და შეცდომის ტექსტი ახალ კლასს დაასახელებს. შეინახეთ რედაქტირებული ფაილი ვერსიების კონტროლში, გვერდით ჩანაწერით, რომელიც მიზნობრივ OpenVPN გამოშვებას ასახელებს.

დაკავშირებული სტატიები