როგორ გადადის IKEv1-ის ჰიბრიდული აუთენტიფიკაცია IKEv2-ის მომხმარებლის აუთენტიფიკაციაში
ჰიბრიდული რეჟიმი გამშვების დამტკიცებას მომხმარებლის დამტკიცებისგან ჰყოფდა. IKEv2-ზე გადასვლა ინარჩუნებს ამ გაყოფას, მაგრამ ცვლის გაცვლას, EAP მეთოდს და სერტიფიკატის შემოწმებებს.
ყოველი ძველი VPN პროფილი, რომელიც ჯერ სერვერის სერტიფიკატს ითხოვს, შემდეგ კი მომხმარებლის სახელს, ერთ გაცვლაში ორ აუთენტიფიკაციის მოვლენას ატარებს და ეს ფორმა იმ პროტოკოლს გადაურჩა, რომელმაც ის შემოიღო. IKEv1-ის ჰიბრიდული რეჟიმი ზუსტად ამისთვის შეიქმნა: გამშვები თავს საჯარო გასაღებით ამტკიცებს, მომხმარებელი კი მოგვიანებით XAuth-ის მეშვეობით. IKEv2 იგივე ორსაფეხურიან იდეას სხვა მექანიზმით გამოხატავს და სწორედ ამ განსხვავებებში ვარდება მიგრაცია. ვერც ერთი ვერსიის ნომერი ვერ გადააქცევს ერთს მეორედ და ძველი პარამეტრების სახელების ახალ პროფილში კოპირება იძლევა კლიენტს, რომელიც მოლაპარაკებას აწარმოებს და შემდეგ არაფერს აუთენტიფიცირებს.
რას აკეთებდა ჰიბრიდული რეჟიმი IKEv1-ის შიგნით
ჰიბრიდულ პროფილში პასუხისმგებელი მხარე პირველი ფაზის გაცვლას თავისი სერტიფიკატით ხელს აწერს, ინიციატორი კი განზრახ არაფერს წარადგენს. ამიტომ პირადობის დამტკიცება ასიმეტრიულია და სწორედ ამან მისცა გამშვებს საშუალება შეენარჩუნებინა არსებული PKI, ხოლო მომხმარებლებს — კატალოგის პაროლები. როცა პირველი ფაზა სრულდება, XAuth სრულდება როგორც მოთხოვნა და პასუხი, რომლებიც მომხმარებლის სახელისა და პაროლის ატრიბუტებს უკვე დაშიფრული ISAKMP არხის შიგნით ატარებენ.
ყურადღება მიაქციეთ, სად ხვდება ნდობა. სერტიფიკატი პასუხობს, რომელ გამშვებამდე მივიდა კლიენტი; XAuth პასუხობს, რომელ მომხმარებელს სურს წვდომა. არც ერთი არ ცვლის მეორეს და კლიენტი, რომელიც ნებისმიერი სერვერის სერტიფიკატს იღებს, ჩუმად გადაყარა პირველი პასუხი. ჰიბრიდულის იარლიყი ასევე გამოიყენება აგრესიული რეჟიმისთვის წინასწარ გაზიარებული გასაღებით პლუს XAuth, სხვა განლაგება იგივე მომხმარებლის გამოცდილებით, ამიტომ წაიკითხეთ პროფილი და არა სახელი. ორივე ვარიანტი მოდის იმ პროექტებიდან, რომლებიც არასოდეს გახდნენ სტანდარტები და ამიტომ ორ მწარმოებელს შეუძლია ჰიბრიდული რეჟიმი დანერგოს და არც ერთთან არ ითანამშრომლოს.
როგორ აღწევს IKEv2 იმავე ორ დამტკიცებას
IKEv2 სამუშაოს IKE_SA_INIT-სა და IKE_AUTH-ს შორის ყოფს. პირველი გაცვლა შეთავაზებებსა და გასაღებებზე შეთანხმდება სრულიად პირადობების გარეშე; მეორე ატარებს IDi-ს, IDr-ს და AUTH დატვირთვებს. EAP-ის ქვეშ ინიციატორის პირველი AUTH დატვირთვა ცარიელი გადის, პასუხისმგებელი პირველი თავისი სერტიფიკატითა და ხელმოწერით აუთენტიფიცირდება, შემდეგ კი EAP საუბარი IKE_AUTH შეტყობინებების შიგნით მიდის.
მექანიზმი, რომელიც ამას უსაფრთხოს ხდის, გასაღების მასალაა. წარმატებული EAP მეთოდი სესიის გასაღებს ექსპორტს უკეთებს და ინიციატორის საბოლოო AUTH დატვირთვა სწორედ მისგან ითვლება, ასე რომ მომხმარებლის დამტკიცება და გვირაბის გასაღებები ერთმანეთთან არის მიბმული. XAuth-ს ეკვივალენტი არ აქვს: მისი ატრიბუტები პირველი ფაზის შემდეგ მოდის და გასაღებებს არაფერს ჰმატებს. სწორედ ეს ხარვეზი უნდა დაეხურა IKEv2-ის ჩარჩოს და ამიტომ მომუშავე IKEv2 შესვლა სერვერის სერტიფიკატს ამოწმებს, სანამ რამეს ითხოვს.
ეს თანმიმდევრობა ასევე სასარგებლო დიაგნოსტიკაა. როცა კლიენტი სერტიფიკატის ჩვენებამდე შესვლის მონაცემებზე ჩივის, ის საერთოდ არ ასრულებს IKEv2 EAP გაცვლას.
სამი პირადობა ცალკე შეინახეთ
მიგრაცია ცუდად მიდის, როცა სამი პირადობა ერთ ველში იშლება. არის გამშვების პირადობა, რომელსაც კლიენტი ამოწმებს, ჩვეულებრივ DNS სახელი სერტიფიკატის subject ან SAN-ში. არის EAP-ში წარდგენილი მომხმარებლის პირადობა, შესაძლოა დომენური შესვლა, მისამართი ან მკაფიო EAP პირადობის სტრიქონი. და არის ავტორიზაციის წყარო, რომელიც ამ მომხმარებელს ქსელებსა და მარშრუტებზე ასახავს.
strongSwan-ის swanctl სინტაქსი გაყოფას თვალსაჩინოს ხდის: კავშირი გამშვებისთვის remote { auth = pubkey }-ს და მომხმარებლისთვის local { auth = eap-mschapv2 }-ს აყენებს, EAP პირადობა კი ცალკე გადაადგილდება.
როცა ახალ პროფილში მომხმარებლის პირადობა ძველი XAuth ატრიბუტებისგან განსხვავდება, მაგალითად UPN მოკლე სახელის ნაცვლად, აუთენტიფიკაციის სერვერი უცნობ მომხმარებელს ხედავს და ხარვეზი არასწორ პაროლს ჰგავს. პირადობის სტრიქონი შეამოწმეთ სანამ შესვლის მონაცემებს შეამოწმებდეთ.
დაასახეთ პარამეტრები და შემდეგ მოელოდეთ ხაფანგებს
დასახვა მოკლეა და ყოველ სტრიქონს აქვს ხაფანგი, რომელიც მხოლოდ აუთენტიფიკაციის დროს ჩნდება.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
არც ერთი ეს სტრიქონი უბრალო გადარქმევა არ არის. კონფიგურაციის დატვირთვა მისამართებსა და რეზოლვერებს ტიპიზებული ატრიბუტების სიით აწვდის, ხოლო XAuth-ის ატრიბუტთა სივრცე საკუთარი გამოგონება იყო; მათი ურთიერთშემცვლელად მოპყრობა იმის გზაა, რომ პროფილი იმ პარამეტრს ითხოვს, რომელსაც გამშვები არასოდეს გაგზავნის.
ტრაფიკის სელექტორები საკუთარ გაფრთხილებას იმსახურებენ. IKEv1 საინტერესო ტრაფიკს quick mode გაცვლაზე მიბმული proxy ID-ებით გამოხატავდა, მაშინ როცა IKEv2 სელექტორებზე IKE_AUTH-ის დროს შეთანხმდება და პასუხისმგებელს შეუძლია შეავიწროოს ისინი. შეუსაბამობა ქმნის დამყარებულ IKE SA-ს child SA-ის გარეშე, რომელსაც ზოგი კლიენტი სიხარულით აჩვენებს როგორც დაკავშირებულს.
ძველ კავშირს საზღვრად მოეპყარით
RFC 9395 IKEv1-ს მოძველებულად აცხადებს, ამიტომ ძველი ჰიბრიდული კავშირი თარიღიანი თავსებადობის საზღვარია და არა საძირკველი. ცვლილების დროს ორივე პროფილი პარალელურად ამუშავეთ, რადგან მთავარი გამოცდა არ არის, ადის თუ არა ახალი პროფილი, არამედ, აღწევს თუ არა იგივე მომხმარებელი იმავე მოწყობილობაზე იმავე რესურსებს.
სერტიფიკატების შემოწმება მკაცრად შეინარჩუნეთ ბოლომდე. როგორც კი კლიენტი საკუთარ სერტიფიკატს აღარ წარადგენს, ჩნდება ცდუნება შეასუსტოთ სერვერის შემოწმება, სანამ handshake დასრულდება, და ეს ცვლის ერთადერთ დარჩენილ დამტკიცებას მწვანე ნიშნით.
სანამ ძველ პროფილს გააუქმებთ, ოთხი რამ ჩაწერეთ: EAP მეთოდი, პირადობის სტრიქონი, ავტორიზაციის წყარო და თარიღი, როცა მხარდაჭერა სრულდება.