Mac-ზე VPN-ში სერტიფიკატით შესვლა: ვინაობა, გასაღების გამოყენება თუ გეითვეის ნდობა?
სერტიფიკატით შესვლის უკან სამი გადაწყვეტილება დგას: რომელი ვინაობა აირჩევა, შეიძლება თუ არა VPN კომპონენტმა თავისი გასაღების გამოყენება და სანდოა თუ არა გეითვეი.
სერტიფიკატზე დაფუძნებული VPN შესვლები Mac-ს ითხოვს რაღაც უფრო ვიწროს, ვიდრე პაროლი: გამოიყენე ეს კონკრეტული კერძო გასაღები, ამ შესრულების კონტექსტში, რომ დაამტკიცო ვინაობა იმ გეითვეისთვის. როცა ის ვერ ხერხდება, შეტყობინება ჩვეულებრივ აღწერს მხოლოდ ბოლო რამეს, რაც არასწორად წავიდა, და ის იშვიათად არის მიზეზი. სამი გადაწყვეტილების იმ თანმიმდევრობით გავლა, რომლითაც სისტემა იღებს მათ, დიაგნოზს პატიოსნად ინახავს და ხელს უშლის ლოკალური ნებართვის პრობლემის ჯაჭვის ვალიდაციის მარცხად მიჩნევას.
გაიარე შესვლა იმ თანმიმდევრობით, რომლითაც Mac აკეთებს
ჯერ კლიენტი ირჩევს ვინაობას: გამოსადეგ კერძო გასაღებთან დაწყვილებული სერტიფიკატი, რომელიც ხელმისაწვდომია მხარდაჭერილი საცავის ან სერტიფიკატების მომწოდებლის მეშვეობით. შემდეგ VPN კომპონენტი ითხოვს კრიპტოგრაფიული ოპერაციის შესრულებას ამ გასაღებით, და ლოკალური ავტორიზაციის მოდელი პასუხობს. მხოლოდ ორივეს წარმატების შემდეგ ხდება დისტანციური ხელის ჩამორთმევა, სადაც Mac აფასებს გეითვეის, ხოლო გეითვეი აფასებს კლიენტის მტკიცებულებას.
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
წაიკითხე ცხრილი ზემოდან ქვემოთ და გაჩერდი პირველ წარუმატებელ სტრიქონზე. ყველაფერი მარცხის ქვემოთ დაუმტკიცებელია, ამიტომაცაა „სერტიფიკატი არასანდოა“ ასეთი გავრცელებული და ასეთი არასაიმედო დასკვნა.
რას ფარავს ლოკალური ნებართვა სინამდვილეში
macOS-ის გასაღებების საცავის მოდელში დაცული ელემენტები ატარებენ ოპერაციისთვის სპეციფიკურ წვდომის წესებს და სანდო აპლიკაციების სიას. კერძო გასაღებით ხელმოწერა ერთ-ერთი ასეთი ოპერაციაა, და წესები ვრცელდება იმ შესრულებად ფაილზე, რომელიც ამას აკეთებს, და არა სერტიფიკატზე როგორც დოკუმენტზე. Apple-ის წვდომის კონტროლის ცნობარი ხაზს ავლებს ამ მოდელსა და iCloud-ის გასაღებების საცავსა და წვდომის ჯგუფების მოწყობას შორისაც, ამიტომ ერთისთვის დაწერილი რჩევა მეორეზე არ გადადის.
ორი შედეგი მოჰყვება. სიაში ხილული საჯარო სერტიფიკატი არ ამტკიცებს, რომ VPN-ის ფონურ კომპონენტს საერთოდ შეუძლია ამ გასაღებამდე მისვლა. ხოლო ფრონტენდ აპლიკაციისთვის მიცემული ნებართვა არაფერს ამბობს ცალკე დამხმარესა თუ ქსელურ გაფართოებაზე, რადგან ისინი სხვა კოდია სხვა ვინაობებით.
დაადგინე რეალური იმპლემენტაცია და მისი მხარდაჭერილი სერტიფიკატების გაზიარების მექანიზმი, ნაცვლად იმისა, რომ ძველი კლიენტიდან შესრულებადი ფაილის ბილიკი გადააკოპირო. ჯერ დაადასტურე, რომელ ვინაობას შემოგთავაზებს სისტემა პირველ რიგში:
security find-identity -v -p ssl-clientროგორ წავიკითხოთ errSecInteractionNotAllowed
ეს სტატუსი იტყობინება Security Server-თან დაუშვებელი ურთიერთქმედების შესახებ და არაფერს ამბობს სერტიფიკატების ჯაჭვებზე. წაიკითხე ის იმ ოპერაციასთან ერთად, რომელმაც ის წარმოშვა: ხელმოწერის მოთხოვნა, გაგზავნილი კონტექსტიდან, რომელსაც მოთხოვნის ფანჯრის ჩვენება არ შეუძლია, ასე ჩავარდება მაშინაც, როცა გასაღებიც და სერტიფიკატიც სრულიად ნამდვილია. დასაწყისი არის ის ოპერაცია, რომელმაც ის ჩაწერა, და არა სერტიფიკატების საცავი. ნდობის საყრდენებთან დაკავშირებით ნებისმიერი ცვლილება შეცდომას ზუსტად იმავე ადგილას დატოვებს.
ამიტომ კოდს მივუდგეთ როგორც შესრულების კონტექსტისა და ავტორიზაციის შესამოწმებელ მიზეზს. მისი, როგორც იმის მტკიცებულების, მიჩნევა, რომ გეითვეის CA არასანდოა, პრობლემის არასწორ ნახევარში გიგზავნის, და იქ გაკეთებული ცვლილება შეცდომაზე საერთოდ არ იმოქმედებს.
შეაკეთე ვიწროდ, და არა ფართოდ
დაიწყე კავშირის მფლობელის რეგისტრაციის ან იმპორტის ინსტრუქციებით. ჩაწერე კლიენტის ვერსია, პროფილის ფარგლები, არჩეული ვინაობა და პირველი შესაბამისი ლოკალური შეცდომა, რადგან სწორედ ეს ოთხი ფაქტი სჭირდება მხარდაჭერაზე გადაცემას და მათზეა დამოკიდებული მოგვიანებითი შედარება. მართული პროფილი ან ტექნიკით მხარდაჭერილი ვინაობა შეიძლება მოითხოვდეს, რომ ადმინისტრატორმა ან მომწოდებელმა გადაცემა შეაკეთოს, და ლოკალური დაწკაპუნების არც ერთი რაოდენობა ამას არ ცვლის.
სადაც პროდუქტი მომხმარებლის დადასტურებას ელოდება, დაადასტურე, რომელი კომპონენტი ითხოვს და დაამტკიცე მხოლოდ ეს წვდომა მხარდაჭერილი ნაკადით. სადაც კომპონენტს არ აქვს მოთხოვნის ფანჯრის ატეხვის გზა იმ კონტექსტში, რომელშიც მუშაობს, მომზადებამ უნდა გაიაროს გამყიდველის მიერ დოკუმენტირებული მარშრუტი და არა სხვა ტერმინალის ფანჯრიდან გამოთრეული დიალოგი.
ძველ რჩევებში ორი ცვლილება ერთად შემოდის, და ორივე ზედმეტად ფართოა. ყველა აპლიკაციისთვის კერძო გასაღებზე წვდომის მიცემა ლოკალური გასაღების გამოყენებას მოთხოვნიდან ბევრად შორს აფართოებს, ხოლო სერტიფიკატის Always Trust-ზე დაყენება მანქანაზე ყველაფრისთვის ცვლის სერტიფიკატის შეფასებას. არც ერთი მათგანი არ გამოხატავს „ამ დამტკიცებულ VPN იმპლემენტაციას, ამ განზრახული ვინაობის გამოყენებით“.
ჯერ ლოკალურად შეამოწმე, მერე წაიკითხე გეითვეი
შეკეთების შემდეგ დაადასტურე, რომ ლოკალური ოპერაცია წარმატებით სრულდება სანამ მეორე მხრიდან რომელიმე პასუხს განმარტავ. თუ ხელმოწერა ახლა მუშაობს, შემდგომი სახელის, ჯაჭვის ან კლიენტის დაშვების უარი ახალი შედეგია და არა გამეორება, და ის სხვა გადაწყვეტილებას ეკუთვნის სხვა პასუხისმგებელით.
სასარგებლო გადაცემა ასახელებს, სამი გადაწყვეტილებიდან რომელი ჩავარდა, და იქ ჩერდება. ის არასოდეს მოიცავს კერძო გასაღებს და არასოდეს არესეტებს დაუკავშირებელ გასაღების საცავის ელემენტებს იმ იმედით, რომ სუფთა მდგომარეობა დაეხმარება. ეს ორი ჩვეულება ინციდენტამდე ჩამოაყალიბე და არა მის დროს, როცა ყველაფრის ერთდროულად ცდის ცდუნება ყველაზე ძლიერია. ბილეთი, რომელზეც წერია „საცავი ხელახლა ავაშენეთ“, მომდევნო მკითხველს თავდაპირველი ხარვეზის შესახებ თითქმის არაფერს ეუბნება.