निष्क्रियता के दौरान 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 सेटिंग बदलना बंद करें और इसे स्थानीय लिंक खराबी मानें।

अगर आप केवल एक काम करें, तो दूसरी जाँच करें। यही तय करती है कि इस सूची का बाकी हिस्सा आप पर लागू होता है या नहीं, और लोग जवाब पावर सेव होने का पहले ही तय कर लेने के बाद इसी कदम को छोड़ते हैं।