ESP სწორად გაშიფრავს და შიდა პაკეტი მაინც არსად მიდის

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

რას ხედავთ, როცა ეტიკეტი ტყუის

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

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

ტიპი ტრეილერში ცხოვრობს

ჩვეულებრივ IPsec გვირაბის რეჟიმში, ESP-ით დაცული დატვირთვა შეიცავს სრულ შიდა IP პაკეტს. ტრეილერის შემდეგი სათაურის ველი განსაზღვრავს, რა არის ეს დატვირთვა, და ეს არ არის TCP პორტი, არ არის პროტოკოლის ნომერი გარე სათაურში და არ არის საწყისი SPI და მიმდევრობის ნომრის ველის ნაწილი. RFC 4303 განყოფილება 2.6 განსაზღვრავს მას დატვირთვის ტიპის ველად, რაც ზუსტი სახელია ზუსტი საქმისთვის.

მნიშვნელობები, რომლებსაც შეხვდებით, მცირეა და დამახსოვრებად ღირს: IPv4 არის 4 (0x04), ხოლო IPv6 არის 41 (0x29).

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

როგორ განვასხვაოთ ის ჩვეულებრივი ეჭვმიტანილებისგან

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

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

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

რა არ არის შეკეთება

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

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

შეამოწმეთ ნაკადი, და არა მრიცხველი

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

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