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

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

შემოწმება 1: წაიკითხეთ ეტაპი და არა შეტყობინება

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

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

შემოწმება 2: რომელი იდენტობა შემოწმდა

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

strongSwan-ის ტერმინებით ეს არის rightid კლიენტზე და კარიბჭის საკუთარი იდენტობა მეორე მხარეს, და შეუსაბამობა ვერ ხერხდება მანამ, სანამ EAP განიხილება.

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

შემოწმება 3: თუ EAP მონაწილეობს

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

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

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

შემოწმება 4: რა ხდება წარმატებული შესვლის შემდეგ

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

ახლად მომუშავე შესვლა ხშირად ავლენს სელექტორის ან მარშრუტის პრობლემას, რომელიც ადრე ავთენტიფიკაციის მარცხის მიღმა იყო დამალული. თუ გვირაბი ადის და აპლიკაცია მაინც ვერ აღწევს დანიშნულებას, შეხედეთ შეთანხმებულ სელექტორებს და მარშრუტებს და არა ისევ იდენტობას. იდენტობის პარამეტრების შეცვლა ამ მომენტში არასწორ ეტაპს მიმართავს და ჩვეულებრივ ამტვრევს მომუშავე შესვლას. დაადასტურეთ swanctl --list-sas-ით, რომელიც შვილებს და მათ სელექტორებს IKE SA-სგან ცალკე აჩვენებს.

შემოწმება 5: რა მივცეთ მხარდაჭერას

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

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