VPN-ის MTU მითები: რატომ იკუმშება თქვენი პაკეტები და სად მიდის ადგილი

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

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

პირველი მითი: გვირაბის MTU არის გზის MTU

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

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

მეორე მითი: ინკაპსულაცია ერთი სათაური ღირს

გულახდილად დაითვალეთ გარე შრეები. გარე IP სათაური 20 ბაიტია IPv4-ში ან 40 IPv6-ში. NAT-ის გავლისთვის UDP ინკაპსულაცია ამატებს 8-ს. გვირაბის პროტოკოლი ამატებს საკუთარ სათაურს, ინიციალიზაციის ვექტორს ან nonce-ს, შევსებას შიფრის ბლოკის ან გასწორების ზღვრამდე, დამამთავრებელ ნაწილს და მთლიანობის შემოწმების მნიშვნელობას. პროტოკოლისა და შიფრის მიხედვით, ჯამი მშვიდად ათეულ ბაიტებშია, სანამ შიდა პაკეტი საერთოდ დაიწყება.

შემდეგ კვლავ გამოაკელით თავად შიდა პაკეტის სათაურები. გვირაბის შიგნით TCP სეგმენტი ატარებს საკუთარ 20-ბაიტიან IP სათაურს და 20-ბაიტიან TCP სათაურს, და TCP-ის MSS გამომდინარეობს MTU-დან და არა გვირაბის ნომინალური დატვირთვიდან. ამიტომ ping უფრო მცირე დატვირთვით შეიძლება წარმატებული იყოს, მაშინ როცა ფაილის გადაცემა ჩერდება: ხელსაწყოები სხვადასხვა რამეს ამოწმებენ და მათგან მხოლოდ ერთი იყენებს სრული ზომის TCP სეგმენტს.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

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

მესამე მითი: PPPoE კვლავ გაძლევთ სუფთა 1500-ს

ჩვეულებრივი PPPoE წვდომის რგოლი არ გადაიტანს 1500-ბაიტიან IP პაკეტს. PPPoE სათაური და PPP პროტოკოლის ველი Ethernet კადრში 8 ბაიტს იკავებს, რაც IP პაკეტს 1492-ს უტოვებს. ეს არის RFC 2516-ში აღწერილი ტრადიციული ზღვარი. თუ VPN-ს ასეთ რგოლზე ამუშავებთ, გვირაბის დანახარჯი სწორედ იმ 1492-დან მოდის და არა 1500-დან.

RFC 4638 განსაზღვრავს უფრო დიდ PPP დატვირთვაზე მოლაპარაკების გზას, როცა წვდომის კონცენტრატორიც და კლიენტის აღჭურვილობაც მას ეხმარება, ამიტომ "ეს კავშირი იყენებს PPPoE-ს" მარტო არ ამტკიცებს კონკრეტულ რიცხვს. ლოკალური პარამეტრი ვერ აიძულებს შუალედურ მოწყობილობას მიიღოს პაკეტი, რომლისთვისაც ის არასდროს კონფიგურირებულა, ამიტომ სასარგებლო კითხვაა, რაზე შეთანხმდა რგოლი სინამდვილეში და არა რას ამბობს ეტიკეტი.

რატომ ჩანს ჩავარდნა შერჩევითი

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

მეორე, დაკავშირებული შეცდომა სამი რიცხვის არევაა: ინტერფეისის MTU, TCP-ის MSS და თავად პროტოკოლის ფრაგმენტაციის ან შევსების პარამეტრი. MSS-ის დაჭიმვა მარშრუტიზატორზე გადაწერს გამოცხადებულ MSS-ს, რათა გამომგზავნმა პატარა სეგმენტები ააწყოს; ის არ ცვლის გვირაბის MTU-ს და არ ეხმარება UDP ტრაფიკს. სამივესთვის ერთი და იმავე რიცხვის მიცემა იმიტომ, რომ დაკავშირებულად გამოიყურებიან, ის გზაა, რომლითაც კეთილგანწყობილი ცვლილება მუშა კონფიგურაციას ამტვრევს.

რა შევცვალოთ და რა თანმიმდევრობით

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

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