IPv4 გზაზე ფრაგმენტაციას აკეთებს; IPv6 სამაგიეროდ ძალიან დიდი პაკეტის შეტყობინებას აგზავნის
მხოლოდ IPv4 მარშრუტიზატორებს შეუძლიათ ზედმეტად დიდი პაკეტის ფრაგმენტაცია. IPv6 ელოდება, რომ გამგზავნი უპასუხებს ძალიან დიდი პაკეტის შეტყობინებას, რომლის გატეხვაც გვირაბს ან გაფილტრულ ICMP წესს შეუძლია.
IPv6-ის წარუმატებლობებს ბევრად უფრო ხშირად პროტოკოლს აბრალებენ, ვიდრე იმ პაკეტის ზომას, რომელმაც ისინი გამოიწვია. ორი ოჯახი მართლაც განსხვავებულად ეხება ზედმეტად დიდ პაკეტს და სწორედ გვირაბია ის, რაც ამ განსხვავებას მნიშვნელოვანს ხდის. IPv4 მარშრუტიზატორებს შეუძლიათ პაკეტის ფრაგმენტაცია, როცა წესები იძლევა საშუალებას, ხოლო IPv6 მარშრუტიზატორებმა გზაზე საერთოდ არ უნდა გააკეთონ ფრაგმენტაცია. IPv6 სამაგიეროდ ამას გამგზავნს ეუბნება და მოსალოდნელია, რომ გამგზავნი რეაგირებს. ყველაფერი, რაც შემდეგ ცუდად მიდის, დამოკიდებულია იმაზე, მივა თუ არა ეს შეტყობინება.
რას აკეთებს თითოეული ოჯახი
ცხრილი მექანიზმია ოთხ სტრიქონში და ერთი სტრიქონი ხსნის დაბნეულობის უდიდეს ნაწილს.
| Behaviour | IPv4 | IPv6 |
|---|---|---|
| Router fragments an oversized packet | Allowed while DF is clear | Never |
| Signal returned to the sender | ICMP Fragmentation Needed | ICMPv6 Packet Too Big |
| Size that must always work | 68 bytes | 1280 bytes |
| Fragmentation possible | Routers or source | Source only |
IPv6-ს არ აქვს გზაზე ფრაგმენტაცია და არც გასასუფთავებელი DF დროშა, ამიტომ არაფერია საით დაბრუნდეს, როცა პაკეტი ძალიან დიდია. გამგზავნს უნდა უთხრა და გამგზავნმა ეს უნდა დაიჯეროს.
გვირაბი ჩუმად ავიწროებს გზას
VPN ამატებს გარე სათაურებს, ხოლო დაშიფრულ შემთხვევაში მთლიანობის მონაცემებსაც, სანამ პაკეტი დატოვებს ჰოსტს. შიდა პაკეტი შეიძლება მოთავსდეს იმ ინტერფეისის MTU-ში, რომელსაც ხედავს, მაშინ როცა გარე პაკეტი აჭარბებს შემდეგი რგოლის ზღვარს და ამიტომაც ჩნდება ეს პირველად გვირაბში. განზრახ შეამცირეთ გვირაბის ინტერფეისის MTU ან გამკაცრდით TCP MSS გზაზე და ჩაწერეთ, რომელი რიცხვი აირჩიეთ და რატომ.
ESP-ის დანახარჯი დამოკიდებულია რეჟიმსა და ალგორითმებზე, ამიტომ გვირაბის სწორი MTU გამოთვლაა და არა ჩვეულება. რასაც აირჩევთ, უნდა დატოვოს ადგილი სრული 1280-ბაიტიანი შიდა IPv6 პაკეტისთვის, რადგან ყოველი IPv6 რგოლი ვალდებულია ამდენი ატაროს. გვირაბი, რომელსაც არ შეუძლია 1280 ბაიტი IPv6-ის ტარება, არ არის რეგულირების პრობლემა; ის გატეხილი გზაა ამ ოჯახისთვის. სწორედ ეს შეზღუდვა ქრება, როცა MTU მნიშვნელობა კოპირდება მხოლოდ IPv4-ზე დაფუძნებული განლაგებიდან.
რატომ ჩანს სიმპტომი გაჩერებად
მარცხი სუფთა შეცდომა არ არის და ამიტომ არასწორად დიაგნოსტირდება. TCP ხელის ჩამორთმევა სრულდება, მცირე პასუხები მოდის და კავშირი ჩერდება მაშინვე, როცა იწყება დიდი პასუხი ან დიდი ატვირთვა, რადგან სწორედ ისინი არიან პირველი პაკეტები, რომლებიც საკმარისად დიდია გადასაგდებად. SSH უკავშირდება და შემდეგ ჩერდება პირველ დიდ გამოსავალზე, ხოლო გვერდის სათაური იტვირთება, სანამ სხეული არასოდეს სრულდება.
თუ ICMPv6-ის ძალიან დიდი პაკეტის შეტყობინებები იფილტრება, გამგზავნი ვერასოდეს გაიგებს და განაგრძობს იმავე ზომის ცდას. ეს შავი ხვრელია და არა ნელი გზა, ხოლო მისი ნიშანი განმეორებადი ზომის საზღვარია და არა შემთხვევითი დანაკარგი. შესაბამისი მართვის ტრაფიკის დაშვება მუშა IPv6 განლაგების ნაწილია და არა თავაზიანობა.
ნუ გამორთავთ იმ შეტყობინებებს, რომლებზეც თქვენივე გზაა დამოკიდებული, და შემდეგ შედეგს IPv6-ის ხარვეზად ნუ აღწერთ. იგივე არგუმენტი ეხება IPv4-ის Fragmentation Needed შეტყობინებებს, რომლებიც თანაბრად არაპოპულარულია firewall-ის ავტორებს შორის და თანაბრად აუცილებელი.
გაზომეთ საზღვარი და შემდეგ შეასწორეთ ფენა
შეამოწმეთ და ნუ გამოიცნობთ: გამოიყენეთ don't-fragment დროშა IPv4-ზე და ფიქსირებული დატვირთვის ზომები IPv6-ზე, და ჩაწერეთ, სად ჩერდება პასუხები. ping -M do -s 1472 და ping -6 -s 1400 საკმარისია პრობლემის ფორმის დასადგენად, და tracepath აცნობებს გზაზე აღმოჩენილ მარშრუტის MTU-ს.
შემდეგ შეასწორეთ ის ფენა, რომელიც ფლობს რიცხვს: გვირაბის ინტერფეისის MTU, MSS-ის გამკაცრება TCP-სთვის, ან თავად გზა. RFC 8200 არის IPv6 წესის ცნობარი და უფრო მოკლე საკითხავია, ვიდრე ინციდენტი, რომელსაც თავიდან იცილებს.
შეამოწმეთ ის ოჯახი, რომელსაც აპლიკაცია რეალურად იყენებს, რადგან ორმაგი დასტის სახელი შეიძლება პასუხობდეს ერთ ოჯახზე და არა მეორეზე, და აპლიკაცია შეიძლება შეიცვალოს ქსელის ცვლილების შემდეგ. ჩაწერეთ მისამართი, რომელიც შეამოწმეთ, რადგან A ჩანაწერის წინააღმდეგ შედეგი არაფერს ამბობს AAAA ჩანაწერზე.
მოეპყარით ზომის საზღვარს როგორც მტკიცებულებას
განმეორებადი ზომის საზღვარი ერთ-ერთია იმ მცირერიცხოვან ქსელურ ხარვეზთაგან, რომელიც ზუსტად მეორდება, იმავე ბაიტების რაოდენობით, იმავე წყაროდან, ყოველ ჯერზე. ეს მას საჩუქრად აქცევს და არა საიდუმლოდ, და ასევე ნიშნავს, რომ შესწორება შეიძლება გადამოწმდეს და არა იმედი იქნას.
ბილეთში ჩაწერეთ აღმოჩენილი MTU, თქვენ მიერ კონფიგურირებული გვირაბის MTU და ტესტი, რომელმაც სხვაობა დაამტკიცა. შემდეგი ადამიანი იმავე არითმეტიკას შეხვდება სხვა რგოლზე.