გვერდები იტვირთება, მაგრამ VPN-ზე ატვირთვები ჩერდება: რომელი მიზეზი იმარჯვებს
ზომაზე დამოკიდებული შეჩერება შეესაბამება ბილიკის MTU ხარვეზს, ასევე DNS-ს, აპლიკაციის ლიმიტს ან არასტაბილურ გვირაბს. ოთხი დაკვირვება წყვეტს, რომელი.
გვერდები იტვირთება, VPN აცხადებს კავშირს, და ფაილის ატვირთვა ყოველ ჯერზე ერთსა და იმავე ადგილას იყინება. ამ აღწერას ოთხი ახსნა შეესაბამება: პაკეტის ზომის პრობლემა, სახელების გარჩევის პრობლემა, აპლიკაციის ლიმიტი და გვირაბი, რომელიც გამუდმებით გადაიტვირთება. თითოეული მათგანი სხვადასხვა დაკვირვებით შეიძლება დადასტურდეს ან გამოირიცხოს, ამიტომ გადაწყვეტილება სწორი გამოცდის არჩევაა და არა მიზეზის გამოცნობა.
ოთხი კანდიდატი და ერთი ფორმა
დაიწყეთ წარუმატებლობის ფორმით, რადგან ის სიის უმეტეს ნაწილს ხსნის ნებისმიერი ხელსაწყოს გახსნამდე. მუდმივ ზომაზე მომხდარი შეჩერება ზომის პრობლემაა, სანამ საპირისპირო დამტკიცდება. შემთხვევით წერტილებზე მომხდარი შეჩერება დანაკარგის ან სტაბილურობის პრობლემაა. კავშირის გახსნამდე მომხდარი ხარვეზი სახელის პრობლემაა.
მეოთხე კანდიდატი თავად აპლიკაციაა. ატვირთვის ლიმიტები, მოთხოვნების ვადები და პროქსის სხეულის ზომის ზედა ზღვრები ქმნიან ხარვეზებს, რომლებიც ბრაუზერიდან ქსელის ხარვეზად გამოიყურება, და ისინი ჩვეულებრივ ჩამოდიან როგორც უარი და არა როგორც შეჩერება.
ჩაწერეთ დაკვირვებული ფორმა სანამ რამეს გამოსცდით. „ჩერდება დაახლოებით იმავე ბაიტების რაოდენობაზე, ყოველ ჯერზე, გვირაბის აწეულ მდგომარეობაში“ გაცილებით ძლიერი საწყისი წერტილია, ვიდრე „ატვირთვები არ მუშაობს“.
შემდეგ გამოცდის დროს ბილიკი უცვლელად შეინახეთ. გასასვლელის, პროტოკოლისა და სერვერის ერთდროული შეცვლა იძლევა შედეგს, რომელსაც ვერც ერთ მათგანს მიაკუთვნებთ. ერთი ცვლადი ერთ გაშვებაზე, და ჩაწერეთ ის.
გაანახევრეთ ზომა, სანამ პოლიტიკას შეეხებით
ყველაზე იაფი გამმიჯნავი არის გამოცდა, რომელიც ერთ რიცხვს ცვლის. გაუგზავნეთ დანიშნულების ადგილს მზარდი ზომის, დაყოფის აკრძალვის მქონე ping-ები, ატვირთეთ თქვენს მიერ კონტროლირებადი ფაილი იმავე სერვისზე, შემდეგ შეადარეთ, სად ჩერდება თითოეული.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadპირველი ბრძანება აცხადებს, გადის თუ არა სრული ზომის პაკეტი ბილიკს საერთოდ. 1500 ბაიტიანი MTU-ის დროს, ყველაზე დიდი არადაყოფადი ICMP დატვირთვა 1472 ბაიტია, და გვირაბი ამ ბიუჯეტიდან მეტს იღებს შიდა პაკეტის დაწყებამდე. მეორე გაძლევთ ზომასა და ხანგრძლივობას აპლიკაციის დონის გადაცემისთვის, და სწორედ ეს რიცხვია მნიშვნელოვანი.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
წაიკითხეთ წყვილი ერთად. ზღურბლზე ზემოთ წარუმატებელი გამოცდები და იმავე ზღურბლთან მახლობლად შეჩერებული ატვირთვა თანმიმდევრული ამბავია. გამოცდები, რომლებიც ყველა წარმატებულია, მაშინ როცა ატვირთვა ჩერდება ბაიტების იმ რაოდენობაზე, რომელსაც ბილიკი აშკარად ატარებს, მიუთითებს აპლიკაციაზე ან სერვერზე, და MTU-ზე არც ერთი სამუშაო ამას არ შეცვლის. ეს უარყოფითი შედეგი დადებითის ტოლფასია. ის ხსნის გამოძიების ყველაზე ძვირადღირებულ ტოტს.
შემდეგ შეამოწმეთ სტაბილურობა გადაცემის დროს, რადგან გვირაბი, რომელიც დიდი ატვირთვის შუაში გასაღებს აახლებს, ქმნის ზომაზე დამოკიდებულად მოჩვენებულ ხარვეზს ისე, რომ ასეთი არ არის. მუშაობის დროის მაჩვენებელი ამის დასადასტურებლად ყველაზე იაფი გზაა.
აირჩიეთ შეკეთებასა და გვერდის ავლას შორის
თუ მტკიცებულებები ზომაზე მიუთითებს, არსებობს ორი პატიოსანი პასუხი და ერთი არაპატიოსანი. პატიოსნებია: აღადგინოთ ბილიკის MTU აღმოჩენა საჭირო ICMP უკუკავშირის დაშვებით, ან შეზღუდოთ გამოცხადებული სეგმენტის ზომა, რომ პარტნიორებმა უფრო პატარა სეგმენტები გაგზავნონ. არაპატიოსანია ინტერფეისის MTU ფორუმიდან კოპირებულ მნიშვნელობამდე დაწევა და იმის შეუმოწმებლობა, თუ რა შეცვალა ამან.
არჩევანი დამოკიდებულია იმაზე, თუ რას აკონტროლებთ. იმ ქსელში, რომელსაც თქვენ მართავთ, ICMP შეტყობინებების დაშვება უფრო სუფთა შეკეთებაა, რადგან მექანიზმს ყველა პროტოკოლისთვის მოქმედად ინახავს. იმ ბილიკზე, რომელსაც არ აკონტროლებთ, შეზღუდვა პრაქტიკული ვარიანტია, და ის უნდა გამოიყენოთ ვიწროდ და არა მთელ სერვერზე.
თუ მტკიცებულებები აპლიკაციაზე მიუთითებს, შეაკეთეთ აპლიკაცია ან მისი პროქსის კონფიგურაცია. 413 პასუხი და ჩამოკიდებული კავშირი სხვადასხვა ხარვეზია, და მეორე ჩვეულებრივ ვადის გასვლაა სადღაც ჯაჭვში, რომელიც მოიცავს საკუთარი ლიმიტების მქონე პროქსის.
ნებისმიერ შემთხვევაში, შეინახეთ საწყისი მნიშვნელობები და დაბრუნების შემდეგ ხელახლა გამოსცადეთ. სამუშაო გადაცემასთან დამთხვეული ცვლილება არ არის მტკიცებულება, რომ სწორედ მან გამოიწვია, და გაუქმების უნარია ის, რაც დიაგნოზს შემთხვევითობისგან გამოყოფს.
ჩაწერეთ გადაწყვეტილება, რომ ის გადაიტანოს შემდეგი ინციდენტი
ოთხი ფაქტი საკმარისია: დაკვირვებული ხარვეზის ფორმა, გამოცდების შედეგები, თქვენ მიერ გაკეთებული ცვლილება და ხელახალი გამოცდის შედეგი. მათთან ერთად შემდეგ ადამიანს შეუძლია თქვას, იგივე პრობლემაა თუ იგივე სიმპტომის მქონე ახალი.
აღნიშნეთ ბილიკის კონტექსტიც, რადგან MTU-ის დასკვნა კონკრეტულ რგოლს ეხება. ლეპტოპს, რომელიც სახლში მუშაობს და სასტუმროში ვერ ახერხებს, ორი ბილიკი აქვს, და ერთზე გამოყენებული შესწორება მეორეზე არაფერს ამბობს.
და ბოლოს, წინააღმდეგ გაუძელით შეჯამებას, რომ „VPN-მა ატვირთვები გატეხა“. გვირაბი ორივე შემთხვევაში იყო — როგორც მომუშავეში, ისე წარუმატებელში; შეიცვალა იმ პაკეტის ზომა, რომელიც ბილიკს უნდა ეტარებინა, ან ადგილი, სადაც გადაცემა შეწყდა. ნამდვილი მექანიზმის დასახელებაა ის, რაც ჩანაწერს სასარგებლოს ხდის.