EAP თუ კლიენტის სერტიფიკატები? IKEv2 ავთენტიფიკაციის გადაწყვეტა

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

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

ორი სერტიფიკატი, ორი მტკიცება

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

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

EAP კონტეინერია და არა მეთოდი

EAP ჩარჩოა: კარიბჭე და კლიენტი მეთოდზე მოლაპარაკებას აწარმოებენ, და მეთოდი წყვეტს, მონაწილეობს პაროლი, ტოკენი, გვირაბირებული შიდა გაცვლა თუ სერტიფიკატი, როგორც ამას strongSwan-ის IKEv2 დოკუმენტაცია განმარტავს. ამიტომ EAP-TLS კლიენტის მხრიდან საერთოდ არ ჰგავს EAP-MSCHAPv2-ს, თუმცა ორივე მენიუში EAP-ად ჩანს. პროფილი, რომელიც მხოლოდ EAP-ს ასახელებს, არ გითხრათ, რას ჰკითხავენ მომხმარებელს.

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

შერეული განლაგება ნორმალურია

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

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

გადაწყვეტა ჩავარდნის ეტაპიდან

დაალაგეთ დაკვირვებები. ნდობის შეცდომა ნებისმიერ მომხმარებლის მოთხოვნამდე სერვერის სერტიფიკატის პრობლემაა და ვერც ერთი პაროლი ვერ გამოასწორებს. მოთხოვნას, რომელსაც უარი მოჰყვება, მომხმარებლის ავთენტიფიკაციის პრობლემაა, EAP მეთოდი და backend ეჭვმიტანილები არიან. წარმატებულ ავთენტიფიკაციას, რომელსაც child-SA-ის ჩავარდნა მოჰყვება, არც ერთია და არც მეორე.

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

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

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

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

მას შემდეგ, რაც იდენტობა მიღებულია

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

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