ბილიკის MTU-ის აღმოჩენა VPN-ის გავლით: ზომა და ICMP-ის ხარვეზი

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

რას ზომავს ბილიკის MTU სინამდვილეში

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

გვირაბისთვის მნიშვნელოვანი რიცხვია შიდა MTU, რაც არის გარე ბილიკის დასაშვები გამოკლებული ის, რასაც ინკაფსულაცია ხარჯავს. WireGuard ამატებს გარე IP სათაურს და UDP სათაურს; სხვა ტრანსპორტები ამატებენ თავიანთას. შიდა ზომა ძალიან მაღლა დააყენეთ და ყოველ სრული ზომის პაკეტს დასჭირდება ფრაგმენტაცია, რომელიც შეიძლება არასდროს მოხდეს.

რატომ ამცირებს გვირაბი გამოსაყენებელ პაკეტს

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

პრაქტიკული შედეგია ზომა, რომელიც ეტევა ხელის ჩამორთმევაში და არა დატვირთვაში. TLS ClientHello ან DNS მოთხოვნა საკმარისად პატარაა, რომ შემცირებული ბილიკი ხელუხლებლად გადაკვეთოს, მაშინ როცა მასობრივი გადაცემა ასე არ არის. ამიტომ სიმპტომები გროვდება კონკრეტული ოპერაციების გარშემო და არა კონკრეტული ჰოსტების.

აღმოჩენა მუშაობს მხოლოდ მაშინ, როცა უკუკავშირი მოდის

IPv4-ის აღმოჩენა ეყრდნობა don't-fragment ბიტს: როუტერი, რომელსაც პაკეტის გადაგზავნა არ შეუძლია, აბრუნებს ICMP fragmentation-needed-ს შემდეგი ჰოპის MTU-ით, და გამომგზავნი ამცირებს თავის შეფასებას. IPv6 სამაგიეროდ იყენებს Packet Too Big შეტყობინებებს, რადგან როუტერები ტრანზიტში არ აფრაგმენტებენ. ორივე მექანიზმი ვარაუდობს, რომ შეტყობინება იპოვის გზას უკან გამომგზავნთან, გვირაბის გავლით და დაბრუნების ბილიკზე ნებისმიერი ფაირვოლის მიღმა. როცა ეს ვარაუდი ვარდება, გამომგზავნი აგრძელებს ისეთი ზომის ხელახლა ცდას, რომელსაც ბილიკი ვერ ატარებს.

ფაირვოლი, რომელიც უშვებს echo request-ს და echo reply-ს, სულაც არ არის საჭირო, რომ ეს შეცდომების ტიპებიც უშვას. ICMP ოჯახია, და აქ მნიშვნელოვანი წევრები შეცდომებია და არა ექოს წყვილი. შეამოწმეთ კონტროლის ტრაფიკის პოლიტიკა გვირაბის ორივე ბოლოში და მათ შორის ბილიკზე, და მიჰყევით პლატფორმის მხარდაჭერილ მითითებებს, ნაცვლად იმისა, რომ ყველგან ყველა ICMP ტიპი დაუშვათ.

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

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

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

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

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

PLPMTUD, რომელიც აღწერილია RFC 4821-ში, ზემოთ სინჯავს და იყენებს ტრანსპორტის დადასტურებებს ნაცვლად იმისა, რომ მიწოდებულ შეცდომებს დაეყრდნოს. ის ეხმარება ICMP-ის ფილტრავ ბილიკებზე, მაგრამ მხარდაჭერა განსხვავდება სტეკის და აპლიკაციის მიხედვით. TCP ნაკადი შეიძლება თავისით გამოჯანმრთელდეს, მაშინ როცა ფიქსირებული დატაგრამის ზომის UDP აპლიკაცია აგრძელებს ვარდნას.

აირჩიეთ მნიშვნელობა და ჩაწერეთ დასაბუთება

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

IPv4 მექანიზმი აღწერილია RFC 1191-ში, ხოლო IPv6 პაკეტიზაციის მითითებები RFC 8201-ში; ორივეს დასახელება იცავს შემდეგ ინჟინერს ვარაუდის თავიდან გამოყვანისგან. თუ გადაცემა მაინც ჩერდება თქვენ მიერ არჩეულ ზომაზე, შეწყვიტეთ რიცხვის დაწევა და შეხედეთ შემდეგ დონეს. ბილიკი, რომელიც ყველა ზომაზე ვარდება, MTU-ის პრობლემა არ არის.