IKEv2 ერთი ხელის ჩამორთმევა არ არის: IKE SA, ავთენტიფიკაცია, შემდეგ CHILD SA
კარიბჭის პასუხი ხელმისაწვდომობას ადასტურებს, არა იდენტობას. მიჰყევით IKE_SA_INIT-ს, IKE_AUTH-ს და პირველ CHILD SA-ს, შემდეგ შეამოწმეთ რა უნდა იყოს ჭეშმარიტი ტრაფიკის გატარებამდე.
შეიძლება გგონიათ, რომ IKEv2 კავშირი ერთი გაცვლაა, რომელიც თქვენი ტრაფიკის დაშიფვრით მთავრდება. სინამდვილეში სულ მცირე ორია და პირველი არავის ავთენტიფიცირებს. მხარეები იწყებენ საკონტროლო შეტყობინებებით, თანხმდებიან კრიპტოგრაფიულ პარამეტრებზე, ამტკიცებენ იდენტობას და მხოლოდ ამის შემდეგ აწარმოებენ მოლაპარაკებას იმ მდგომარეობაზე, რომელიც აპლიკაციის პაკეტებს გადააქვს. სწორედ ეს თანმიმდევრობა ხსნის იმ შეუსაბამობას, რომელზეც ხალხი მუდმივად წერს: კარიბჭე პასუხობს, კლიენტი ამბობს რომ დაკავშირებულია, და კერძო აპლიკაცია მაინც ვერ ელოდება პასუხს. აქ არის რა აკეთებს რეალურად თითოეული ეტაპი და რა უნდა იყოს ჭეშმარიტი მის შემდეგ.
მითი: თუ კარიბჭე პასუხობს, დაკავშირებული ხართ
პირველ შეტყობინებაზე პასუხი ადასტურებს, რომ ბოლო წერტილი ხელმისაწვდომია და საუბრისთვის მზადაა. ის არ ადასტურებს, რომ ანგარიში მიღებულია, სერტიფიკატების ჯაჭვი დადასტურდა, ან რომელიმე მონაცემთა პოლიტიკა დაყენდა.
ეს წარუმატებლობები უფრო გვიან ხდება და სხვადასხვა სიმპტომს იძლევა. სერტიფიკატის უარყოფა ან EAP-ის წარუმატებლობა მოდის მას შემდეგ, რაც პირველი გაცვლა უკვე წარმატებით დასრულდა, ამიტომ UDP 500-ზე ping და კლიენტის მწვანე ხატულა ძალიან ცოტას გეუბნებათ.
IKE_SA_INIT: შეთანხმდით პარამეტრებზე, არა იდენტობაზე
პირველი გაცვლა გადააქვს IKE უსაფრთხოების ასოციაციის წინადადებებს: დაშიფვრისა და მთლიანობის ალგორითმები, ფსევდო-შემთხვევითი ფუნქცია და Diffie-Hellman ჯგუფი. მხარეები ასევე ცვლიან nonce-ებს და თითოეული მხარე IKE SA-ს გასაღების მასალას იღებს იმ საერთო საიდუმლოდან, რომელსაც ეს მნიშვნელობები ქმნიან. ამ გაცვლაში არაფერი ადგენს, ვინ არის მეორე მხარე. ის ადგენს, რომ ორივე მხარეს შეუძლია ერთი და იგივე გასაღებების გამოთვლა და რომ ისინი ერთ წინადადებაზე თანხმდებიან. რესპონდენტი, რომელსაც არც ერთი წინადადება არ მოსწონს, აქ უარყოფს გაცვლას, ამიტომ ვერსიის ან ალგორითმის შეუსაბამობა ისე გამოიყურება, თითქოს სერვერი გამორთულია.
ამ ეტაპზე შექმნილი IKE SA იცავს ყველა შემდგომ საკონტროლო გაცვლას. ეს მისი საქმეა და ეს განსხვავებული საქმეა თქვენი პაკეტების დაცვისგან.
IKE_AUTH: დაამტკიცეთ იდენტობა და შემდეგ ააგეთ პირველი CHILD SA
მეორე გაცვლა იდენტობას გადააქვს. სერტიფიკატებით, თითოეული მხარე ხელს აწერს საკუთარი კერძო გასაღებით და წარადგენს ჯაჭვს, რომელიც მეორემ უნდა დაადასტუროს; EAP-ით, რესპონდენტი გამომწვევს უგზავნის არჩეული მეთოდით. აქ ბოლოს და ბოლოს ვლინდება არასწორი სერვერის სახელი, ვადაგასული სერტიფიკატი ან უარყოფილი პაროლი.
ჩვეულებრივ შემთხვევაში IKE_AUTH პირველ CHILD SA-ზეც აწარმოებს მოლაპარაკებას, ამიტომ მონაცემთა დაცვა იმავე ორმხრივ მოგზაურობაში თანხმდება. გამომწვევი სთავაზობს ტრაფიკის სელექტორებს, რესპონდენტი ავიწროებს ან უარყოფს მათ, და მონაცემთა გზის გასაღებები IKE SA-დან მიიღება. ეს ნიშნავს, რომ ერთი გაცვლა შეიძლება ორ სრულიად განსხვავებულ ადგილას ჩავარდეს: იდენტობაში ან პოლიტიკაში. წაიკითხეთ შეტყობინების დატვირთვა ან შეცდომა და არა ზოგადი ხელის ჩამორთმევის ჩავარდნა, რადგან ერთის გამოსწორება სერტიფიკატია, მეორის კი ქვექსელის შეუსაბამობა.
ორი SA, ორი საქმე
| ასოციაცია | იცავს | სიცოცხლის ხანგრძლივობის ქცევა |
|---|---|---|
| IKE SA | საკონტროლო გაცვლები: გასაღებების განახლება, წაშლა, კონფიგურაციის დატვირთვები | განახლდება საკუთარი გრაფიკით; მონაცემთა გზა შეიძლება გადაურჩეს ცვლილებას |
| CHILD SA | ტრაფიკის სელექტორებს შესაბამისი აპლიკაციის ტრაფიკი | განახლდება დამოუკიდებლად, ხშირად უფრო ხშირად |
მათი განცალკევება ხსნის ორ ქცევას, რომლებიც შეცდომებად გვეჩვენება. გვირაბი შეიძლება დადგენილად გამოჩნდეს, სანამ ფონზე გასაღებების განახლება ჩავარდება, და CHILD SA შეიძლება შეიცვალოს კლიენტის კავშირის დაკარგვის გარეშე.
strongSwan-ზე, IKEv2 კონფიგურაციის ცნობარი და swanctl --list-sas ორივე დონეს აჩვენებენ, ხოლო ip xfrm state -სთან ერთად ip xfrm policy აჩვენებენ, რა დააყენა რეალურად ბირთვმა. ამ ორი ხედის შედარება ყველაზე სწრაფი გზაა იმის დასანახად, დასრულდა მოლაპარაკება თუ მხოლოდ დასრულებული ჩანდა. თუ დემონი ჩამოთვლის CHILD SA-ს, რომლისთვისაც ბირთვს მდგომარეობა არ აქვს, დაყენება ჩუმად ჩავარდა. თუ ბირთვს აქვს მდგომარეობა, რომელიც დემონმა არ იცის, თქვენ უყურებთ წინა ცდის ნარჩენს.
რა უნდა დარჩეს ჭეშმარიტი გვირაბის აწევის შემდეგ
ტრაფიკის სელექტორები განსაზღვრავენ, რომელი მისამართებია დაფარული. თუ კლიენტი სთავაზობს ერთ ქვექსელს და სერვერი მეორეს ელის, CHILD SA დაყენდება, მაგრამ სასარგებლოს არაფერს გადააქვს, და შეცდომა ჩნდება როგორც მარშრუტიზაციის პრობლემა და არა მოლაპარაკების. შემდეგ ლოკალური სტეკი უნდა ითანამშრომლოს: გადაცემა ჩართული იქ, სადაც ჰოსტი მარშრუტიზაციას აკეთებს, მარშრუტები გვირაბისკენ, ფაირვოლის წესები, რომლებიც ნებას რთავს დეკაპსულირებულ პაკეტებს, და შიდა რეზოლვერი, თუ კერძო სახელებია ჩართული. თითოეული მათგანი ცალკე ცდება და არც ერთი არ სწორდება IKE დემონის გადატვირთვით.
დიაგნოსტიკის დროს ჟურნალი თვალსაჩინოდ გქონდეთ: საწყისი გაცვლა, შემდეგ იდენტობის დადასტურება, შემდეგ მომხმარებლის ავთენტიფიკაცია სადაც გამოიყენება, შემდეგ CHILD-ის დაყენება და ბოლოს აპლიკაციის ტრაფიკი. ეტაპი, რომელიც ჩერდება, არის გამოსასწორებელი, და გვიანდელი მარშრუტიზაციის ჩავარდნა არასოდეს არის მიზეზი უკვე გავლილი იდენტობის შემოწმებების შესუსტებისა.