OpenVPN გასაღების მოთხოვნა OpenSSL 3-ის შემდეგ: შეამოწმეთ პროვაიდერი
პირადი გასაღების უეცარი მოთხოვნა ხშირად პროვაიდერის ცვლილებას მოჰყვება და არა ახალ პაროლს. შეამოწმეთ გასაღები, გამოსცადეთ პროვაიდერების ორივე ნაკრები და შეინახეთ პაროლფრაზა.
პროფილს არავის შეხებია, მაგრამ იგივე კლიენტი ახლა ყოველ გაშვებაზე პირადი გასაღებისთვის პაროლფრაზას ითხოვს. როცა ეს ცვლილება დისტრიბუტივის განახლებიდან რამდენიმე დღეში ჩნდება, სავარაუდო მიზეზი თავად განახლებაა: OpenSSL 3-მა ალგორითმების მხარდაჭერა გადააწყო, და გასაღები, რომელსაც ძველი ბიბლიოთეკა უპრობლემოდ კითხულობდა, შეიძლება წაუკითხავი გახდეს ერთი ბაიტის შეცვლის გარეშე. შეასრულეთ შემოწმებები თანმიმდევრობით, რადგან ორი მათგანი იდენტურად გამოიყურება, თუ მხოლოდ მოთხოვნას უყურებთ.
პირველი კითხვაა, დაშიფრულია თუ არა გასაღები, ხოლო მეორე — შეუძლია თუ არა ამ კონსტრუქციას მისი გაშიფვრა. კონფიგურაციის ცვლილებებს აზრი მხოლოდ მას შემდეგ აქვს, რაც ორივე პასუხი ცნობილია.
შეამოწმეთ, დაშიფრულია თუ არა გასაღები
წაიკითხეთ ფაილის პირველი ხაზი და შემდეგ მიეცით ბიბლიოთეკას მისი დამუშავების საშუალება, რადგან ფაილის სახელი არაფერს ამტკიცებს. PEM ბლოკი წარწერით ENCRYPTED PRIVATE KEY დაშიფრული PKCS#8-ია, ხოლო უფრო ძველი RSA PRIVATE KEY ბლოკი, რომელსაც აქვს Proc-Type: 4,ENCRYPTED ტრადიციული ფორმაა, და ორივე პაროლფრაზას მოელის. არადაშიფრული PRIVATE KEY ბლოკი საერთოდ არ უნდა ითხოვდეს მას. გაუშვით დამუშავება იმ ანგარიშით, რომელიც ფაილს ფლობს, რადგან ნებართვის პრობლემა სხვა და გაცილებით ნაკლებად საინტერესო შეცდომას იძლევა.
თუ გასაღები მართლაც არ არის დაშიფრული და კლიენტი მაინც ითხოვს, შეწყვიტეთ კრიპტოგრაფიაზე ყურება და შეამოწმეთ, ხომ არ ასახელებს პროფილი askpass ფაილს, რომელსაც სერვისი ჯერ კიდევ შეუძლია წაიკითხოს.
შეამოწმეთ, შეუძლია თუ არა ამ კონსტრუქციას მისი გაშიფვრა
OpenSSL 3-მა ალგორითმების მხარდაჭერა პროვაიდერებად დაყო, და ძველი შიფრების ნაკრები ახლა legacy პროვაიდერშია და არა ნაგულისხმევში. ამ შიფრებიდან ერთით დაშიფრული გასაღები ძალაში რჩება, მაგრამ legacy პროვაიდერის გარეშე ჩატვირთული ბიბლიოთეკა ვერ გაშიფრავს მას. ზოგ კლიენტზე ეს განმეორებადი მოთხოვნის სახით ჩანს, სხვებზე — პაროლფრაზისთანავე მკაცრი წარუმატებლობის სახით.
დაამუშავეთ იგივე გასაღები ორჯერ იმავე ბინარულით: ჯერ მხოლოდ ნაგულისხმევი პროვაიდერით, შემდეგ legacy და ნაგულისხმევი ერთად მოთხოვნილი ბრძანების სტრიქონზე. თუ მეორე ცდა წარმატებულია იქ, სადაც პირველი ჩავარდა, დიაგნოზი მტკიცებულებას ეყრდნობა და არა განახლების დროს. თუ ორივე იდენტურად ჩავარდა, პაროლფრაზა არასწორია ან ფაილი დაზიანებულია, და არც ერთ პროვაიდერის პარამეტრს არ შეუძლია რომელიმეს გამოსწორება.
შეამოწმეთ ყველაზე ვიწრო ხელმისაწვდომი შესწორება
უპირატესობა მიანიჭეთ კლიენტზე შემოფარგლულ ცვლილებას და არა სისტემურ ცვლილებას. ზოგი 2.6 კონსტრუქცია იღებს პროფილის პარამეტრს, რომელიც ორივე პროვაიდერს ტვირთავს იმ დემონის პროცესისთვის, ამიტომ სანამ მას დაეყრდნობით, დაადასტურეთ მითითება თქვენი ზუსტი ვერსიის სახელმძღვანელოში; სისტემური openssl.cnf ფაილის რედაქტირება სამაგიეროდ ჰოსტზე ყველა OpenSSL პროგრამაზე მოქმედებს. უფრო ვიწრო პარამეტრი გაცილებით ადვილი დასაბრუნებელია, რაც გასაღების ხელახლა კოდირების შემდეგ საჭირო ხდება.
არ წაშალოთ პაროლფრაზა, რომ მოთხოვნა გაქრეს. ეს დაცულ იდენტიფიკაციის მონაცემებს ღია ტექსტის ფაილად აქცევს და ჩუმად ცვლის ყოველი სარეზერვო ასლის, კოპიოსა და დახმარების პაკეტის რისკს, სადაც ის გვხვდება. მთავარი განსხვავება იმ გასაღებს შორისაა, რომელსაც თავისი პაროლფრაზა სჭირდება, და იმ გასაღებს შორის, რომელსაც ეს ბიბლიოთეკა ვერ გაშიფრავს.
შეამოწმეთ სერვისის კონტექსტი, შემდეგ ხელახლა დააკოდირეთ
როცა გასაღების გახსნა შესაძლებელი გახდება, ხელახლა დაშიფრეთ ის თანამედროვე ალგორითმით რათა დამოკიდებულება გაქრეს. ჩაწერეთ ახალი ფაილი თანამედროვე შიფრით, დაადასტურეთ, რომ ის მუშავდება, განაახლეთ პროფილი და შეინახეთ ძველი ასლი მხოლოდ მანამ, სანამ კავშირი წარმატებით დამყარდება. არასდროს მოათავსოთ პაროლფრაზა ბრძანების სტრიქონზე, სადაც ნებისმიერ ლოკალურ მომხმარებელს შეუძლია მისი წაკითხვა პროცესების სიიდან. წაშალეთ ძველი ფაილი მხოლოდ მას შემდეგ, რაც ახალი დაუკავშირდება სერვისის ანგარიშიდან და არა მხოლოდ თქვენი shell-იდან.
შემდეგ შეამოწმეთ ის ერთეული, რომელიც რეალურად უშვებს კლიენტს. თქვენს shell-ში წაკითხვადი გასაღები შეიძლება წაუკითხავი იყოს სხვა ანგარიშით ან გამკაცრებული სახლის დირექტორიის პარამეტრით მომუშავე სერვისისთვის.
ჩაწერეთ პროვაიდერის პარამეტრი პროფილის გვერდით და შეინახეთ ორბრძანებიანი ტესტი მასთან ერთად. როცა მოგვიანებით განახლება legacy პროვაიდერს მოხსნის, ხელახლა გაუშვით ეს ტესტი, რათა ნახოთ, სჭირდება თუ არა გასაღებს ის ჯერ კიდევ, თუ პროფილი შეიძლება ამ დროებითი ხსნიდან გამოვიყვანოთ.
მოთხოვნა სიმპტომია, რომელსაც სულ ცოტა სამი მიზეზი აქვს, და მათგან მხოლოდ ერთია დაკარგული პაროლფრაზა.