სწორი VPN პაროლი ვერ ჩაანაცვლებს დაკარგულ სერტიფიკატს

მონაცემები სწორია, პროფილი სუფთად იმპორტირდება და კავშირი მაინც ფუჭდება ავთენტიფიკაციის დასრულებამდე. Windows-ში შეტყობინება შეიძლება იყოს შეცდომა 798, EAP მეთოდისთვის ვერ ნაპოვნი სერტიფიკატის შესახებ. OpenVPN-ზე კლიენტის ჟურნალი აჩვენებს TLS ხელის ჩამორთმევას, რომელიც სერვერს არასოდეს აკმაყოფილებს. ორივე ერთსა და იმავე დაკარგულ ობიექტს აღწერს: კლიენტის სერტიფიკატს, რომელიც კლიენტს უნდა წარედგინა.

პაროლი საიდუმლოს ცოდნას ამტკიცებს; სერტიფიკატი გასაღების ფლობას ამტკიცებს და ერთი მეორეს არ ანაცვლებს.

პაროლი არასოდეს ყოფილა პრობლემა

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

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

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

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

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

ორი პროდუქტი, იგივე დაკარგული მონაცემი

OpenVPN სერვერები ნაგულისხმევად კლიენტის სერტიფიკატს მოითხოვენ. კლიენტზე auth-user-pass-ის დამატება აგზავნის მომხმარებლის სახელსა და პაროლს, ხოლო TLS ხელის ჩამორთმევა კვლავ სერტიფიკატს ითხოვს, ამიტომ მხოლოდ პაროლი ვერ დაასრულებს კავშირს verify-client-cert require-ის პირობებში. სერვერი შეიძლება ისე დაყენდეს, რომ არაფერი მოითხოვოს, რაც პაროლს კლიენტის ერთადერთ მონაცემად აქცევს და ძალაში რეალური შემცირებაა. auth-user-pass-verify-ის უკან მდგომ shell სკრიპტს შეუძლია მონაცემების ვალიდაცია და მოითხოვს სკრიპტების გაშვების ჩართულობას, რაც მას უფრო სარისკო დიზაინად აქცევს, ვიდრე სათანადო ავთენტიფიკაციის backend.

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

ნუ გაასწორებთ დაკარგულ სერტიფიკატს შემოწმებების გამორთვით

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

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

პაროლი რიგზე იყო. მონაცემი, რომელიც მეთოდს ნამდვილად სჭირდებოდა, სხვაგან იყო.