MTU თუ MSS? რას ასწორებს სინამდვილეში VPN-ის ცვლილება

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

ორი რიცხვი, ორი ობიექტი

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

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

სად ჯდება გარე დამატებითი დატვირთვა

VPN შიდა პაკეტს სხვა პაკეტში დებს და გარე პაკეტი ფიზიკურ გზაში უნდა ჩაჯდეს. ინკაფსულაციის სათაურები, გარე IP სათაური, ტრანსპორტის სათაური და ნებისმიერი ავთენტიფიკაციის ტეგი ხარჯავს ბაიტებს, რომლებსაც შიდა პაკეტი ვერ გამოიყენებს. დატოვეთ გვირაბის ინტერფეისი 1500-ზე და გარე პაკეტი რეგულარულად აღემატება იმას, რასაც გზა უძლებს. 'არ დაყო' ბიტის ჩართვისას მარშრუტიზატორი მას ყრის და უნდა დააბრუნოს ICMP შეცდომა; თუ ეს შეცდომა იფილტრება, გამგზავნი ამას ვერასდროს შეიტყობს.

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

MSS-ის შეზღუდვა და სად მოქმედებს ის

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

ეფექტი მხოლოდ TCP-ზეა. UDP აპლიკაცია, QUIC სესია და ნებისმიერი პროტოკოლი, რომელიც საკუთარ დატაგრამებს აშენებს, უცვლელი რჩება.

დიაგნოსტიკა ფიქსირებული გზით

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

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

რას არ ასწორებს თითოეული ცვლილება

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

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