IKEv2-ის ფრაგმენტაციის გარჩევა სერტიფიკატების ჯაჭვის პრობლემისგან
როცა ხელის ჩამორთმევა პირველი გაცვლისთანავე ჩერდება, გაარკვიეთ, შეტყობინება საერთოდ არ მივიდა თუ უარყვეს, სანამ სერტიფიკატებს შეეხებით.
გვირაბი ოფისის ქსელში მუშაობდა და სახლში ჩერდება, ხოლო ჟურნალი აჩვენებს, რომ პირველი გაცვლა სრულდება მანამ, სანამ სხვა რამ მოხდება. ეს ნიმუში ავთენტიფიკაციის გაცვლაზე მიუთითებს და არა სერტიფიკატებზე: სერტიფიკატების ჯაჭვი ამ შეტყობინებას წინაზე გაცილებით დიდს ხდის, და ბილიკი, რომელსაც დიდი დეტაგრამები არ უყვარს, ჩუმად გადააგდებს მას. ჩართულია ორი განსხვავებული ფრაგმენტაციის მექანიზმი, და იმის ცოდნა, რომელს უყურებთ, გადაწყვეტს შესწორებას.
ორი ფრაგმენტაციის მექანიზმი, ერთი სიმპტომი
IKEv2-ს აქვს საკუთარი ფრაგმენტაციის გაფართოება, რომელიც განსაზღვრულია RFC 7383-ში და დაცულ IKE შეტყობინებებს ყოფს უფრო პატარა IKE შეტყობინებებად. მხარეები ამ შესაძლებლობაზე მოლაპარაკებას აწარმოებენ, და შეტყობინებას IKE-ის იმპლემენტაცია აწყობს ხელახლა და არა IP შრე.
ჩვეულებრივი IP ფრაგმენტაცია სხვა მექანიზმია სხვა მარცხის რეჟიმით. მხარეებს შორის მარშრუტიზატორი ყოფს დიდ დეტაგრამას, ან გადააგდებს მას და აბრუნებს ICMP შეტყობინებას, რომელიც შესაძლოა გამგზავნამდე ვერასოდეს მივიდეს. ზოგი ქსელი ჩუმად აგდებს ფრაგმენტებს, ზოგი შუამავალი მოწყობილობა კი ამუშავებს პირველ ფრაგმენტს, მაგრამ არა დანარჩენებს. აპლიკაციის თვალსაზრისით სამივე შემთხვევა ერთნაირად გამოიყურება.
NAT-ის გავლა მესამე ცვლადს ამატებს, რადგან მაშინ ESP UDP-ში იხვევა და გარე პაკეტი დიდდება, თანაც 4500 პორტზე ჩვეულებრივ UDP ტრაფიკს ჰგავს. ბილიკი, რომელიც UDP-ს კარგად გაატარებს, მაინც შეიძლება ჩავარდეს დეტაგრამაზე, რომელიც აღარ ეტევა.
წაიკითხეთ ჩავარდნილი გაცვლა
მოძებნეთ გადასვლა და არა შეცდომა. ჟურნალი, რომელიც აჩვენებს პირველი გაცვლის გაგზავნას და პასუხს, შემდეგ კი არაფერს, გეუბნებათ, რომ შემდეგი შეტყობინება ვერასოდეს დასრულდა. დროებით აამაღლეთ ჟურნალის დონე და შეადარეთ მოხსენებული ზომები ორივე მხარეს.
რისი დადგენაც გსურთ, არის ის, დაინახა თუ არა პასუხისმგებელმა მოთხოვნა საერთოდ. თუ ინიციატორმა რაღაც გაგზავნა და პასუხისმგებელს ამის არავითარი ჩანაწერი არ აქვს, პრობლემა მიწოდებაშია. თუ პასუხისმგებელმა მოთხოვნა გააანალიზა და უარყო, პრობლემა თავად სერტიფიკატია, და ფრაგმენტაცია ყურადღების გადატანაა. ეს განსხვავება უფრო ღირებულია, ვიდრე დროის ამოწურვის შეტყობინებების ერთი გვერდი.
შეცვალეთ ბილიკი და არა სერტიფიკატი
სცადეთ იგივე კლიენტი, იგივე სერტიფიკატი და იგივე კონფიგურაცია სხვა ქსელიდან. მობილური ჰოტსპოტი ჩვეულებრივ ყველაზე იაფი მეორე ბილიკია, და ის ოფისის კავშირისგან ნამდვილად განსხვავდება, და არა მხოლოდ სახელით.
თუ ხელის ჩამორთმევა მეორე ბილიკზე სრულდება, სერტიფიკატების ჯაჭვი რიგზეა და ცვლადი პირველი ბილიკია. თუ ორივეზე ერთნაირად ჩავარდა, შეწყვიტეთ ქსელების გამოცდა და შეხედეთ თავად შეტყობინებებს. ეს ერთი შედარება შესაძლო ახსნათა დაახლოებით ნახევარს აშორებს.
გაზომეთ გაცვლა, სანამ რამეს შეცვლით
მიიღეთ ჯაჭვის ზომა და ბილიკის ზომა. ორივე რიცხვი ზღუდავს, რისი გაგზავნაც ხელის ჩამორთმევას შეუძლია, და ორივეს გაზომვა იაფია:
openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject ls -l chain.pem ping -M do -s 1400 198.51.100.7 ip -s link show eth0 | sed -n '1,6p'
პირველი ორი იძლევა სერტიფიკატების რაოდენობას და ფაილის ზომას, რაც გონივრული მაჩვენებელია იმისა, რამდენად დიდი იქნება ავთენტიფიკაციის შეტყობინება. ping-ის შემოწმება იტყობინება, გადარჩება თუ არა ასეთი ზომის დეტაგრამა ბილიკზე, და ინტერფეისის მრიცხველები აჩვენებენ, გადააგდეს თუ არა ფრაგმენტები თქვენთან. Windows-ზე ეკვივალენტური შემოწმება არის ping do-not-fragment დროშით და მკაფიო ტვირთის ზომით.
გაიმეორეთ შემოწმება ქვევით, სანამ არ წარმატდება. ყველაზე დიდი ზომა, რომელიც გადის, არის სამუშაო ბიუჯეტი ამ ბილიკისთვის, და ის უფრო სასარგებლოა, ვიდრე ნებისმიერი გამოქვეყნებული ნაგულისხმევი მნიშვნელობა.
შეაკეთეთ შრე, რომელიც ნამდვილად გატეხილია
თუ ბილიკი დიდ დეტაგრამებს აგდებს, ჩართეთ IKE ფრაგმენტაცია ორივე მხარეს და დაადასტურეთ, რომ გაფართოებაზე მოლაპარაკება შედგა და არა მხოლოდ შეთავაზება. თუ ბილიკი IP დონეზე ცუდად ეპყრობა ფრაგმენტებს, შესწორება იქ ან გარე ინტერფეისის MTU-შია, და არა სერტიფიკატების საცავში.
თუ ჯაჭვი ზედმეტად გრძელია, შეამოკლეთ იმ შუალედურ სერტიფიკატებამდე, რომლებიც მხარეს ნამდვილად სჭირდება. ფესვის წაშლა, რომელსაც კლიენტი უკვე ენდობა, გონივრული მოვლაა; შუალედურის წაშლა ასე არ არის, და შეტყობინების შემცირებისთვის შემოწმების გამორთვა მიწოდების პრობლემას ცვლის უსაფრთხოების პრობლემით.
ჩაწერეთ, რომელი მექანიზმი შეცვალეთ და როგორ გამოიყურებოდა ხელის ჩამორთმევა ამის შემდეგ. შემდეგი შემთხვევა ჩვეულებრივ სხვა ქსელშია იმავე სიმპტომით, და სწორედ ჩანაწერი აქცევს ორ საათს ათ წუთად.