VPN-ის გაწყვეტების გასწორება უმოქმედობისას: Wi-Fi ენერგოდაზოგვის სია

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

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

პირველი შემოწმება: მიჰყვება თუ არა გაწყვეტა უმოქმედობას?

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

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

მეორე შემოწმება: მხოლოდ VPN-ის ტრაფიკია?

სანამ გვირაბს დაადანაშაულებთ, გაარკვიეთ, კავშირი თავად ჯერ კიდევ გამოსადეგია თუ არა. სანამ გვირაბი მკვდარია, მაგრამ ეკრანი ჯერ კიდევ გამორთული, სცადეთ წვდომის წერტილის მისამართზე და საჯარო ჰოსტზე IP-ით მისვლა. თუ ჩვეულებრივი ping-იც ვერ შედგა, რადიომ ან წვდომის წერტილმა ჩამოგაგდათ და VPN-ის კლიენტი მხოლოდ დამკვირვებელია.

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

მესამე შემოწმება: წაიკითხეთ ენერგოდაზოგვის მდგომარეობა

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

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

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

Windows-ზე powercfg /q SCHEME_CURRENT ბეჭდავს აქტიურ სქემას და უსადენო ადაპტერის ქვეხე აჩვენებს, შეიძლება თუ არა ადაპტერს ენერგიის დაზოგვის ბრძანება; იგივე არჩევანი Device Manager-შიც არის ადაპტერის ენერგიის მართვის ჩანართზე. macOS-ზე თითოეული ინტერფეისის 802.11 ენერგოდაზოგვა თქვენთვის არ ჩანს, ამიტომ ნაცვლად შეხედეთ pmset -g ძილისა და ლოდინის ქცევას. იქ ხარვეზი ჩვეულებრივ ძილისა და გამოღვიძების გზაზე აღმოჩნდება და არა რადიოს უმოქმედობის ქცევაში.

მეოთხე შემოწმება: შეცვალეთ ერთი რამ, შემდეგ ხელახლა შეამოწმეთ

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

კავშირის ცოცხლად შენარჩუნება მეორე დამოუკიდებელი ცვლადია და მას გამუდმებით ენერგოდაზოგვას ურევენ. WireGuard-ის PersistentKeepalive = 25 NAT-ის რუკას თბილს ინახავს;OpenVPN ორივე ბოლოში keepalive და ping-restart იყენებს. ორივე ტრაფიკს ქმნის სხვაგვარად მდუმარე გვირაბში, ამიტომ ცოცხლად შენარჩუნება, რომელიც თითქოს ასწორებს გაწყვეტას, შეიძლება რადიოს პრობლემას მალავდეს და არა აგვარებდეს. გამოსცადეთ ისინი ცალ-ცალკე, სათითაოდ:

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

მეხუთე შემოწმება: როცა რადიო უდანაშაულოა

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

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

სანამ მას მუდმივს გახდით

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

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

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

დაკავშირებული სტატიები