რატომ ვერ მუშაობს cryptoapicert OpenVPN 3-სა და Connect-ში Windows-ზე

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

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

რას ნიშნავს ეს პარამეტრი იქ, სადაც ის არსებობს

Windows-ზე Community OpenVPN 2 კლიენტში cryptoapicert ასახელებს სერტიფიკატს, რომელიც კლიენტმა უნდა მოძებნოს Windows-ის სერტიფიკატების საცავში და არა ფაილში. ეს Windows-სპეციფიკური მოხერხებულობაა და მუშაობს, რადგან ამ კლიენტმა იცის, როგორ ჩამოთვალოს საცავი და მიღებული გასაღები გადასცეს საკუთარ TLS-სტეკს. ამიტომ დირექტივა ამ კლიენტის კონფიგურაციის ენის ნაწილია და არა OpenVPN პროტოკოლის თვისება. გადაცემის ფორმატში ვერაფერი ატარებს მას.

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

რას სთავაზობს სამაგიეროდ ბირთვული ბიბლიოთეკა

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

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

რას აკეთებს სამაგიეროდ Windows-ის ფრონტენდი

OpenVPN Connect სხვა გზას ირჩევს: ოპერატორი PKCS#12 ფაილს იმპორტს უკეთებს, რომელიც შეიცავს სერტიფიკატს და მის პირად გასაღებს, ამ მიზნისთვის შექმნილ OpenVPN Certificate Store-ში, შემდეგ კი გარე სერტიფიკატს პროფილს ანიჭებს. ეს განზრახი იმპორტის ნაბიჯია და არა პირად საცავში შემთხვევით არსებულის ავტომატური აღმოჩენა. განსხვავებას მნიშვნელობა აქვს მაშინ, როცა ვიღაც ფიქრობს, რომ სხვა მიზნისთვის დაყენებული სერტიფიკატი უბრალოდ გამოჩნდება კლიენტის სიაში.

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

აირჩიეთ გზა, რომელიც ერგება გასაღების პოლიტიკას

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

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

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