निष्क्रिय VPN सत्र को काटने वाला टाइमर पैकेट गिनता है, कीबोर्ड के दबाव नहीं। यह टनल पर संचार की अनुपस्थिति देखता है, इसलिए पृष्ठभूमि में मेल, बैकअप एजेंट या चैट क्लाइंट वाला लैपटॉप इसे कभी निष्क्रिय नहीं दिखता। यही एक तथ्य आम शिकायत की दोनों दिशाएँ समझाता है: लंबे दोपहर के भोजन के बाद भी टिकने वाला सत्र, और सक्रिय काम के बीच मरने वाला सत्र। कोई सेटिंग खोजने से पहले तय करें कि आप किस घड़ी से लड़ रहे हैं।

टाइमर वास्तव में क्या देखता है

Cisco ASA पर नॉब vpn-idle-timeout है, यह समूह नीति या उपयोगकर्ता नीति के अंतर्गत सेट होता है, और यह संचार गतिविधि के बिना की अवधि मापता है। इकाई मिनट है, डिफ़ॉल्ट मान विरासत में मिलता है, और जाँच सत्र के ट्रैफ़िक काउंटरों पर चलती है, न कि उस चीज़ पर जो ऑपरेटिंग सिस्टम इनपुट उपकरणों के बारे में जानता है। गेटवे को पता नहीं कि कीबोर्ड पर कोई इंसान है या नहीं। उसे पता है कि उस क्लाइंट से आख़िरी पैकेट कब देखा था।

दूसरी घड़ी vpn-session-timeout है, और वह निरपेक्ष है। यह सत्र स्थापित होने पर शुरू होती है और टनल कितनी व्यस्त है, इसकी परवाह किए बिना समाप्त हो जाती है। भारी उपयोग के ठीक एक घंटे बाद समाप्त होने वाला सत्र वही टाइमर है, निष्क्रियता का टाइमर नहीं, और कोई भी टाइपिंग उसे नहीं बढ़ाएगी।

किसी एक को बदलने से पहले दोनों मान पढ़ें, क्योंकि वे उपयोगकर्ता की कुर्सी से एक जैसे दिखने वाले तरीकों से विफल होते हैं।

तीन अलग घड़ियाँ जिन्हें लोग निष्क्रियता कहते हैं

तीन असंबंधित नीतियों को निष्क्रियता टाइमर कहा जाता है, और उनमें से केवल एक नेटवर्क की चुप्पी के बारे में है।

MeasureWhat it observesHow it fails
Gateway idle timeoutNo packets from the client on the tunnelDrops after a quiet period, survives background traffic
Gateway session timeoutElapsed time since the session was establishedDrops at a fixed interval no matter how active the tunnel is
Screen lock and device policyHuman presence at the deviceSession stays up while the laptop sits unattended and unlocked

तीसरी पंक्ति वही है जो लोग वास्तव में चाहते हैं जब वे कहते हैं कि कोई हटे तो VPN लॉक होना चाहिए। VPN टाइमर उपस्थिति नहीं माप सकता। अगर आवश्यकता यह है कि बिना निगरानी वाला लैपटॉप पहुँच खो दे, तो वह स्क्रीन-लॉक और डिवाइस नीति में आता है, जहाँ पृष्ठभूमि ट्रैफ़िक की परवाह किए बिना इसे लागू किया जा सकता है।

तीनों को मिलाने से तीस मिनट बिना टाइपिंग के डिस्कनेक्ट करें जैसी मांगें बनती हैं, जिन्हें कोई भी VPN गेटवे ईमानदारी से लागू नहीं कर सकता।

वह नीति खोजें जिसके पास यह कनेक्शन है

सेटिंग खोजने से पहले क्लाइंट और प्रोटोकॉल की पहचान करें। macOS की अंतर्निहित Cisco IPsec प्रोफ़ाइल, मूल L2TP कनेक्शन और Cisco Secure Client एक जैसे नियंत्रण नहीं देते, और उनमें से किसी एक में निष्क्रिय होने पर डिस्कनेक्ट करें चेकबॉक्स का स्क्रीनशॉट बाकियों के बारे में प्रमाण नहीं है। मूल प्रोफ़ाइल सर्वर, खाते और साझा रहस्य से आगे बहुत कम देती हैं। टाइमर गेटवे पर रहता है।

ASA पर, सबके लिए डिफ़ॉल्ट नीति के बजाय उपयोगकर्ता या समूह की प्रभावी नीति पढ़ें:

show running-config group-policy NAME | include timeout
show vpn-sessiondb detail anyconnect filter name USER

सत्र विवरण आउटपुट वास्तव में लागू किए गए निष्क्रियता और सत्र समय-सीमाओं को शेष समय के साथ सूचीबद्ध करता है। यही प्रभावी नीति है, विरासत सहित, जो running-config का अंश आपको नहीं बता सकता। इसकी तुलना उस समूह से करें जिसमें आपको लगता है कि उपयोगकर्ता है, क्योंकि उपयोगकर्ता नीति समूह नीति को ओवरराइड करती है।

तीस मिनट बाद आपका Mac क्यों जुड़ा दिखता है

पृष्ठभूमि ट्रैफ़िक ही सामान्य उत्तर है, और यह कोई बग नहीं है। मेल, फ़ोटो सिंक, अपडेट जाँच, सॉकेट खुला रखने वाला चैट क्लाइंट, या वेबसॉकेट वाला ब्राउज़र टैब, हर एक ऐसे पैकेट बनाता है जिन्हें गेटवे गतिविधि गिनता है। टनल खुली रहती है क्योंकि उसका सचमुच उपयोग हो रहा है, बस आपके द्वारा नहीं। प्रमाण चाहिए तो स्क्रीन के बजाय काउंटर देखें।

उलटा चित्र वह सत्र है जो आपके टाइप करते समय गिरता है, और वह निष्क्रियता नहीं बल्कि सत्र समय-सीमा या प्रशासक का नीति परिवर्तन है।

जानने योग्य एक क्लाइंट-पक्ष प्रभाव भी है। कुछ क्लाइंट अपने स्वयं के कीपअलाइव या डेड-पीयर प्रोब भेजते हैं, और वे पैकेट गेटवे का निष्क्रियता काउंटर रीसेट कर देते हैं। इसीलिए समय-सीमा हराने के लिए जोड़ा गया कीपअलाइव काम करता है, और इसीलिए वह गलत उपकरण है: वह टाइमर जो प्रमाण देखता है उसे बदलता है, नीति के पीछे की प्राधिकरण आवश्यकता को नहीं।

उसका उद्देश्य तोड़े बिना सही नॉब बदलें

अगर लक्ष्य स्वीकृत नेटवर्क निष्क्रियता के बाद कनेक्शन के एक वर्ग को समाप्त करना है, तो नीति की भाषा में ठीक वही मांगें, और अधिकतम सत्र अवधि को अलग और जानबूझकर तय मान के रूप में रखें। फिर पृष्ठभूमि काम को ध्यान में रखते हुए प्रशासक की प्रक्रिया के तहत इसका परीक्षण करें।

अगर लक्ष्य यह है कि कोई व्यक्ति डेस्क छोड़े तो पहुँच रुके, तो इसे लागू करने के लिए VPN गलत परत है।

किसी सत्र को उसे समाप्त करने के लिए लिखी नीति से आगे जीवित रखने के लिए कभी भी ट्रैफ़िक पैदा करने वाला कीपअलाइव न जोड़ें। यह नियंत्रण को औपचारिकता बना देता है, और यह टिकट में नहीं बल्कि ऑडिट में पकड़ा जाता है। नीति बदलें, या आवश्यकता बदलें।

संबंधित लेख