MTU შავი ხვრელი: რატომ მუშაობს პატარა მოთხოვნები, მაგრამ ატვირთვები ჩერდება

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

რა ხდის ხვრელს შავს

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

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

იპოვეთ ზომა, სადაც ის ტყდება

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

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

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

წაიკითხეთ მტკიცებულებები, სანამ გვირაბს დაადანაშაულებთ

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

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

შეამოწმეთ შეკეთება ორივე ტრანსპორტში

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

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

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