რატომ აღდგება თქვენი VPN უფრო დიდხანს, ვიდრე გათიშვა

Wi-Fi ოცდაათი წამის წინ დაბრუნდა და VPN ჯერ კიდევ გამორთულია, ამიტომ კლიენტი გატეხილად გამოიყურება. ხშირად ის უბრალოდ საკუთარ ხელახალი მცდელობის გრაფიკს მიჰყვება და ამ გრაფიკმა არ იცის, რომ ქსელი ახლახან დაბრუნდა. სწორედ ეს სხვაობაა მთელი ამბავი: აღდგენის დრო არის გათიშვა პლუს ნებისმიერი ლოდინი, რომელზეც კლიენტი უკვე დათანხმდა. ყველა ტაიმერის შემცირება ერთი პასუხია, ხოლო იმის გაგება, რომელი ტაიმერია მნიშვნელოვანი, მეორე.

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

სამი ლოდინი, რომლებიც ერთს ჰგავს

საბოლოო წერტილის გარჩევა, IKE ან TLS მოლაპარაკება, პაკეტების ხელახალი გაგზავნა და ახალი მცდელობის დაწყება ცალკეული მოვლენებია ცალკეული ტაიმერებით. strongSwan ადოკუმენტებს ხელახალი გაგზავნის უკუსვლას IKE-სთვის, ხოლო OpenVPN -ს აქვს საკუთარი ხელახალი მცდელობის კონტროლი განსხვავებული სემანტიკით. რიცხვის ერთიდან მეორეში კოპირება ვარაუდობს, რომ მექანიზმები ერთმანეთს ემთხვევა, მაგრამ არ ემთხვევა. წაიკითხეთ ჟურნალის თანმიმდევრობა, სანამ გადაწყვეტთ, რომელ ინტერვალს უყურებთ.

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

რომელი ეტაპია სინამდვილეში ნელი?

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

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

როდის ეხმარება ტაიმერის შემცირება და როდის არა

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

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

შეამოწმეთ მზადყოფნა, სანამ კლიენტს დაადანაშაულებთ

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

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

რა ჩავწეროთ

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

ეს ჩანაწერი შემდეგ პროგრამულ განახლებას ექსპერიმენტის ნაცვლად შედარებად აქცევს.