IPv6 პაკეტი ძალიან დიდია: რატომ ჩერდება დიდი VPN გადაცემები

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

პატარა მოთხოვნები, დიდი გაჩერებები

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

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

Packet Too Big უკუკავშირია და არა ტრაფიკი

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

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

შეამოწმეთ ორივე მისამართების ოჯახი ცალ-ცალკე

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

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

ზონდი აგზავნის პაკეტს do-not-fragment ბიტით და აცნობებს იმ ზომას, რომელზეც ის ვარდება — ეს არის რიცხვი, რომელიც გვირაბმა უნდა დაიტიოს. მარშრუტის მოთხოვნა ასახელებს ინტერფეისს, რომელიც დანიშნულებას გადაიტანდა, ასე რომ იცით, რომელი რგოლის MTU მოქმედებს. ჩანაწერი ფილტრავს ICMPv6 ტიპ 2-ს, Packet Too Big შეტყობინებას, და აჩვენებს, აღწევს თუ არა ის საერთოდ ამ ჰოსტს. თუ შეტყობინება ჩანაწერში ჩანს და გადაცემა კვლავ ჩერდება, გამომგზავნი მას უგულებელყოფს, რაც გამოძიებას ქსელიდან სტეკში გადააქვს.

შეცვალეთ გვირაბის ზომა მხოლოდ მტკიცებულებების შემდეგ

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

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