WireGuard იჩეხება: MTU-ს ზღვარი თუ დაკარგული გადაცემის წესი?
სერვერის მიღმა არაფერი მუშაობს — ეს გადაცემის ან დაბრუნების მარშრუტის პრობლემაა. პატარა მოთხოვნები გადის, დიდი კი ჩერდება — ეს პაკეტის ზომის ნიშანია.
ჩვევა ასეთია: როგორც კი WireGuard ცუდად იქცევა, MTU-ს ამცირებენ, და ეს ჩვევა სხვა ხარვეზს მალავს. კარიბჭე, რომელიც არ გადასცემს, და გზა, რომელიც დიდ პაკეტებს არ ატარებს, განსხვავებულ ნიმუშებს იძლევიან: ერთი ორივე მიმართულებით და ყველა ზომაზე ფარდება, მეორე პატარა მოთხოვნებს გადაურჩება და დიდებზე იღუპება. დაადგინეთ, რომელი ფორმა გაქვთ, სანამ რომელიმე რიცხვს შეცვლით. ტესტი იაფია და შესაძლო მიზეზების ნახევარს აშორებს.
ორი ხარვეზი, ორი სხვადასხვა ფორმა
გადაცემის პრობლემა სერვერის შემდეგ მაშინვე ჩნდება. ხელის ჩამორთმევა წარმატებულია, გვირაბის მისამართი პასუხობს, და კარიბჭის მიღმა არაფერი მისაწვდომია პატარა მოთხოვნითაც კი. პაკეტი სერვერამდე მივიდა და არ გადაცემულა, ან პასუხს უკან დაბრუნების გზა არ ჰქონდა.
ზომის პრობლემა მხოლოდ ზღურბლს ზემოთ ჩნდება. DNS, TCP ხელის ჩამორთმევა და პატარა API გამოძახება მუშაობს, მაშინ როცა ფაილის ჩამოტვირთვა ან დიდი პასუხი იკიდება. პაკეტები, რომლებიც ჩაეტია, თავიდან ბოლომდე გაიარა, ხოლო რომლებიც არ ჩაეტია, სადღაც გადააგდეს სასარგებლო ანგარიშის გარეშე.
ეს აღწერილობები სხვადასხვა ადამიანსა და სხვადასხვა კონფიგურაციის ფაილზე მიუთითებს, ამიტომ ფორმის გაზომვა ვარაუდზე მეტად ღირებულია. კარიბჭეზე ერთი ping ვერ გამოყოფს მათ.
გამორიცხეთ გადაცემა, სანამ რამეს შეამცირებთ
გამოსცადეთ დანიშნულება კარიბჭის მიღმა და არა თავად კარიბჭე. სერვერის გვირაბის მისამართზე ping მხოლოდ იმას ამტკიცებს, რომ ინტერფეისი ჩართულია და რომ აღწევთ მანქანას, რომელიც გვირაბს ამთავრებს. უფრო ფართო ქსელის ტრაფიკი დამოკიდებულია იმაზე, ჩართულია თუ არა IP გადაცემა ამ მანქანაზე, და firewall-ზე, რომელიც ნებას რთავს გადაცემულ ნაკადს. ორივე უნდა იყოს ჭეშმარიტი, და თუ ერთი მცდარია, იგივე სიჩუმე დგება.
დაბრუნების მარშრუტიზაციას არანაკლები მნიშვნელობა აქვს. თუ დანიშნულების ქსელმა არ იცის, როგორ მიაღწიოს კლიენტის გვირაბის მისამართს, მოთხოვნა მოდის და პასუხი ქრება, კლიენტი კი იუწყება დროის ამოწურვაზე, რომელიც გადაგდებული გადაცემის იდენტურია.
სადაც დიზაინი იყენებს მისამართების თარგმნას, თარგმნის წესი ამ დაბრუნების გზის ნაწილია. მისი მოცილება MTU-ს პრობლემის დევნისას მუშა დიზაინს გატეხილად აქცევს, ამიტომ წაიკითხეთ არსებული წესები, სანამ შეცვლით.
გაზომეთ, საიდან იწყება წყვეტა
ჯერ წაიკითხეთ გადაცემის მდგომარეობა და ფილტრაციის წესები. ეს მხოლოდ კითხვის შემოწმებებია და პასუხობს იაფ კითხვას:
sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
ip route get 10.30.0.9შემდეგ გამოსცადეთ ზომები don’t-fragment ბიტით, კლიენტიდან, კარიბჭის მიღმა მდებარე ჰოსტისკენ:
ping -M do -s 1200 10.30.0.9
ping -M do -s 1400 10.30.0.9თუ პირველი შემოწმება მუშაობს და მეორე ფრაგმენტაციის შეცდომით ფარდება, გზა გეუბნებათ თავის გამოსადეგ ზომას. თუ არც ერთი არ მუშაობს, უყურებთ გადაცემას ან მარშრუტიზაციას და MTU არ არის შესაცვლელი ცვლადი.
| Observation | Points toward | Where to look |
|---|---|---|
| Nothing beyond the gateway works | Forwarding or return route | Forwarding flag, filter rules, routing table |
| Small works, large stalls | Packet size on the path | Tunnel MTU and the link underneath |
| Only names fail | DNS resolution | The resolver configured for the tunnel |
| Works sometimes | Multiple paths or state expiry | Flow selection and NAT state |
შეაკეთეთ ის ფენა, რომელიც დაამტკიცეთ
როცა გადაცემა არის ხარვეზი, შესწორებაა გადაცემის წესი ან მარშრუტი, გამოხატული იმდენად ვიწროდ, რამდენადაც დიზაინი იძლევა. როცა ზომა არის ხარვეზი, შესწორებაა MTU, რომელიც ითვალისწინებს კაფსულაციას სწორედ ამ გზაზე, გამოყენებული იმ ინტერფეისზე, რომელსაც სჭირდება, და არა ფლოტის ყველა ადაპტერზე.
როგორც არ უნდა იყოს, შემდეგ გაიმეორეთ იგივე ამოცანა იმავე დანიშნულების მიმართ. თუ თავდაპირველი დიდი გადაცემა ახლა სრულდება, ცვლილებამ მოაგვარა ის ფენა, რომელიც ფარდებოდა. თუ მხოლოდ პატარა შემოწმება გაუმჯობესდა, სიმპტომი მკურნალე ხართ და ნამდვილი ზღვარი ჯერ კიდევ ადგილზეა.
ჩაწერეთ, რომელი ფორმა დააკვირდით ცვლილებამდე. ის ერთი ხაზი, შესწორების გვერდით ჩაწერილი, არის ის, რაც ხელს უშლის შემდეგ ადამიანს შეამციროს MTU, რომელიც არასდროს ყოფილა პრობლემა.