MTU თითოეული მარშრუტისთვის Linux-ზე: ზომის სამი კონტროლი, ერთი მარშრუტი
ინტერფეისის MTU, მარშრუტის MTU და MSS-ის ზღვარი სხვადასხვა დონეზე მოქმედებს. მიაბით ბიუჯეტი იმ მარშრუტს, რომელიც ძებნაში იმარჯვებს, და შეინარჩუნეთ ცვლილება შექცევადი.
Linux-ის კლიენტზე სამი პარამეტრი ერთნაირად ჟღერს — «პაკეტები უფრო პატარა გახადე» — და ისინი სხვადასხვა დონეზე მოქმედებს. ინტერფეისის MTU ზღუდავს ყოველ პაკეტს, რომელსაც მოწყობილობა აგზავნის. მარშრუტის MTU ზღუდავს პაკეტებს, რომლებიც ამ მარშრუტს იყენებენ, და ეს ხშირად სწორედ ის არის, რაც ერთი VPN მიმართულებისთვის ნამდვილად გჭირდებათ. TCP MSS-ის ზღვარი ცვლის იმას, რაზეც ორი მხარე თანხმდება, და UDP-ისთვის არაფერს აკეთებს.
სამი კონტროლი, რომლებიც ერთი ღილაკივით გამოიყურება
სანამ აირჩევთ, გვერდიგვერდ დადეთ, რადგან არასწორი სტრიქონის არჩევა ხსნის უმეტეს იმ რჩევას, რომელიც არ მუშაობს:
| Control | Scope | What it cannot fix |
|---|---|---|
| Interface MTU | Every packet the device sends | Nothing, but it over-constrains unrelated traffic |
| Route MTU | Packets using that route | A send that the lookup never routes there |
| MSS clamp | TCP handshake on that path | UDP payload sizes and ICMP |
მთელი მანქანისთვის Ethernet MTU-ის დაწევა ამ გამოსწორების უხეში ვერსიაა. ის მუშაობს და ასევე სჯის ჰოსტზე ყველა სხვა აპლიკაციას, მათაც, რომელთა ბილიკები რიგზე იყო. თითო მარშრუტის მნიშვნელობა იმავე განზრახვას გამოხატავს გვერდითი ხარჯის გარეშე.
შედარება მოქმედებს მხოლოდ იმ ტრაფიკზე, რომელსაც თავად ჰოსტი ქმნის. სხვა კლიენტისთვის პაკეტის გადაცემა მოიცავს მის საკუთარ ბილიკს და გვირაბის გარე ბიუჯეტს, და ამ ჰოსტზე მარშრუტის მეტრიკა ამ საზღვარს არ სცილდება.
მიაბით ბიუჯეტი იმ მარშრუტს, რომელიც ძებნაში იმარჯვებს
საილუსტრაციო IPv4 მარშრუტის ჩანაწერი ასე გამოიყურება:
ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380ჩანაწერი წაიკითხეთ როგორც განზრახვის აღწერა, და არა ჩასასმელი მნიშვნელობა. პრეფიქსი, მოწყობილობა და სასურველი წყარო უნდა შეესაბამებოდეს რეალურ კონფიგურაციას, და რიცხვი უნდა მოვიდეს ინკაფსულირებული ბილიკის შესახებ მტკიცებულებიდან, და არა ბლოგის პოსტიდან. მარშრუტის MTU ზღუდავს შიდა IP პაკეტს, რაც არ არის იგივე, რაც 1380 ბაიტიანი TCP დატვირთვა ან 1380 ბაიტიანი დაშიფრული გარე პაკეტი.
სანამ რამეს დაამატებთ, ნახეთ, სად იხსნება ძებნა სინამდვილეში. პოლიტიკის წესების მქონე ჰოსტს შეუძლია მოცემული დანიშნულება გაატაროს main-ისგან განსხვავებული ცხრილით, და მეტრიკა, რომელიც მხოლოდ main ცხრილში არსებობს, უხილავია ამ მოთხოვნისთვის. შეადარეთ ip -4 route show table all და ip route get-ის პასუხი, წესების გამოყენებისას ნიშნის ან სახელთა სივრცის კონტექსტის ჩათვლით. თუ ეს ორი არ ემთხვევა, პასუხის გამცემი ცხრილია ის, რომელსაც მეტრიკა სჭირდება, და არა უფრო მოწესრიგებულად რომ გამოიყურება.
mtu არ არის mtu lock
ნაგულისხმევად ბირთვს ჯერ კიდევ შეუძლია ბილიკის MTU-ის განახლება ICMP-ის უკუკავშირიდან, ბილიკის MTU-ის აღმოჩენა სწორედ ამისთვისაა. lock დამატება ამას აჩერებს. ეს სხვა გადაწყვეტილებაა, არა იმავე რიცხვის შენახვის უფრო ძლიერი გზა, და IPv4-ისთვის ცვლის «არ დაყავი» ბიტის დოკუმენტირებულ დამუშავებას.
ჩაკეტვა გონივრულია, როცა ბილიკი გაზომილი გაქვთ და გსურთ მნიშვნელობა უცვლელი დარჩეს, რაც არ უნდა მოვიდეს. ეს ცუდი ნაგულისხმევია, როცა ქსელი ზომის ლეგიტიმურ უკუკავშირს აგზავნის, რადგან ბირთვს აღარ შეუძლია ადაპტაცია და ხარვეზი სხვა სიმპტომზე გადადის.
თუ ICMP სადმე ბილიკზე იფილტრება, არც ერთი მარშრუტის პარამეტრი ამას არ ასწორებს. გამოსწორება ფილტრს ეკუთვნის, და პატარა MTU არის შემოვლითი გზა, რომელიც ნამდვილ ხარვეზს მალავს შემდეგ ბილიკის ცვლილებამდე.
გვირაბის პროგრამა თავის ზომის საკონტროლოებს ამატებს
OpenVPN- mssfix არეგულირებს TCP სეგმენტის ზომას თავისი დოკუმენტირებული UDP გვირაბის შემთხვევისთვის. ის TCP საუბარზე მოქმედებს, ამიტომ ოპერაციული სისტემის მარშრუტის MTU-ის სხვა მართლწერა არ არის, და ვერ დაეხმარება UDP სერვისს, რომელიც მოლაპარაკებას უგულებელყოფს.
ნუ დააწყობთ მარშრუტის MTU-ს, ინტერფეისის MTU-ის ცვლილებას და MSS-ის ზღვარს ერთ ცვლილების ფანჯარაში. თუ პრობლემა გაქრა, ვერ გაიგებთ, რომელი იყო მთავარი, და რაც დატოვეთ, წლების განმავლობაში შეზღუდავს ტრაფიკს ისე, რომ მიზეზი არავის ახსოვს.
გახადეთ ის შექცევადი, შემდეგ დაამტკიცეთ
მარშრუტის ნამდვილი მფლობელი წყვეტს, გადარჩება თუ არა ცვლილება ხელახალი დაკავშირების შემდეგ. VPN კლიენტი, რომელიც მარშრუტს დინამიკურად აყენებს, ჩვეულებრივ ხელახლა ააშენებს მას თქვენი მეტრიკის გარეშე, და ხელით შესრულებული ip route add შემდეგ ჰგავს გამოსწორებას, რომელიც დღეში ჩავარდა. მნიშვნელობა ჩაწერეთ მენეჯერის კონფიგურაციაში, და თუ დროებითი ექსპერიმენტი გჭირდებათ, ჯერ საწყისი მარშრუტი ჩაიწერეთ.
შეამოწმეთ ახალი კავშირით, რომელიც ასრულებს გაჭედილ ოპერაციას, შემდეგ დაადასტურეთ, რომ განზრახული კერძო მარშრუტი კვლავ იმარჯვებს და უკავშირო დანიშნულებები არ შეცვლილა. ხელახლა დაუკავშირდით გვირაბს და ისევ წაიკითხეთ მარშრუტი, რადგან ხელახალი დაკავშირებისას გამქრალი მნიშვნელობა გამოსწორება არ არის.
თუ მტკიცებულება ცვლილებას არ უჭერს მხარს, მოხსენით გადაფარვა მისი მენეჯერის მეშვეობით და აღადგინეთ მარშრუტის საწყისი ატრიბუტები, ნაცვლად მარშრუტის წაშლისა. შემდეგ ჩაწერეთ, რა გაზომეთ და რომელ ბილიკზე, რომ შემდეგმა ადამიანმა გაარჩიოს ნამდვილი გაუმჯობესება მუშაობაში დატოვებული ექსპერიმენტისგან.