სავარაუდო VPN MTU პრობლემის შემოწმება მნიშვნელობების გამოცნობის გარეშე

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

დააფიქსირეთ გზა, სანამ რიცხვს შეცვლით

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

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

შეამოწმეთ თქვენ მიერ კონტროლირებადი ზომით

Linux-ში შემოწმება ასე გამოიყურება: ping -M do -s 1400 host, ხოლო Windows-ში ასე: ping -f -l 1400 host. ორივე შემთხვევაში თქვენ აყენებთ სასარგებლო დატვირთვას და არა პაკეტის ზომას, რადგან IP და ICMP სათაურები ზემოდან ემატება.

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

წარუმატებელი შემოწმება არ ამტკიცებს MTU ზღვარს

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

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

დაარეგულირეთ ერთი პარამეტრი, რომელსაც კლიენტი უკვე მხარს უჭერს

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

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

გაუქმება, შემოწმება და ჩაწერა

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

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