ორი იდენტობა ერთ IKEv2 შესვლაში: ჯერ მანქანა, შემდეგ მომხმარებელი

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

სიმპტომი: წარუმატებლობა წარმატებული პირველი მტკიცებულების შემდეგ

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

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

რას ამატებს გაფართოება და რას არა

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

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

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

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

იგივე ფაილი კარიბჭეზე სხვანაირად იკითხება

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

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

ეს რიგის წესი წარმოშობს დასამახსოვრებელ მარცხის ფორმას. მეორე remote ბლოკი არ არის კიდევ ერთი მისაღები ვარიანტი; ეს არის მეორე მოთხოვნა, ამიტომ „ან/ან“-ად წაკითხული პოლიტიკა იქცევა როგორც „და-შემდეგ“. კარიბჭის პოლიტიკამ შეიძლება მიიღოს რეგისტრირებული მანქანის სერტიფიკატი და შემდეგ მოითხოვოს იმ მომხმარებლის EAP გაცვლა, სწორედ ამ რიგში.

გაარჩიეთ რაუნდები დამოუკიდებელი ფაქტორებისგან

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

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

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

დაწერეთ დაწყვილების წესი და შეამოწმეთ უარყოფები

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

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

swanctl --list-conns
swanctl --list-sas

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