निष्क्रियतामा VPN काटिने समस्या सुधार्ने: Wi-Fi पावर सेभका लागि जाँचसूची

ल्यापटप केही बेर नछोइकन बसेपछि तपाईंको टनेल मर्छ, र तपाईंले ट्र्याकप्याड छुने क्षणमै फर्केर आउँछ। यो ढाँचाले 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 सेटिङ बदल्न रोक्नुहोस् र यसलाई स्थानीय लिंक खराबी मान्नुहोस्।

तपाईंले एउटा मात्र काम गर्नुभयो भने दोस्रो जाँच गर्नुहोस्। यो सूचीको बाँकी तपाईंलाई लागू हुन्छ कि हुँदैन भन्ने निर्णय त्यसैले गर्छ, र उत्तर पावर सेभ हो भनी पहिले नै ठानिसकेपछि मानिसहरूले छोड्ने चरण पनि त्यही हो।