स्क्रीन काळी झाल्यावर VPN बंद होते: लॉक, ब्लँक की सस्पेंड?
लॉक केलेले सत्र, काळी झालेली स्क्रीन आणि सस्पेंड झालेले मशीन या तीन वेगवेगळ्या घटना आहेत। VPN च्या कीपअलाइव्हला दोष देण्यापूर्वी त्या journalctl ने जोडून पाहा।
कोणी सांगतो की स्क्रीन काळी झाल्यावर VPN मेले, तेव्हा पहिला उपयुक्त प्रश्न असा आहे की तीनपैकी कोणती घटना खरोखर घडली: सत्र लॉक झाले, पॅनेल बंद झाले, की पूरे मशीनला झोप आली। हे वेगवेगळ्या टाइमरवरील वेगवेगळे यंत्रणा आहेत, आणि त्यांपैकी फक्त एकच प्रक्रियेचे शेड्यूलिंग पूर्णपणे थांबवू शकते। खालील तपासण्या क्रमाने करा। प्रश्नाचे उत्तर देणाऱ्या पहिल्या तपासणीवर थांबा, कारण त्यानंतरची प्रत्येक तपासणी दुसऱ्याच कशाचे उत्तर देते।
पहिली तपासणी: लॉक, ब्लँक आणि झोप वेगळे करा
लॉक कोणाला सत्र वापरण्याची परवानगी आहे हे बदलते; कंपोझिटर चित्र काढत राहतो, नेटवर्क स्टॅक चालू राहतो आणि VPN क्लायंटला काहीही जाणवत नाही। स्क्रीन ब्लँक झाल्यावर निष्क्रियतेनंतर पॅनेल बंद होते आणि मशीन पूर्ण जागे राहते। सस्पेंड प्रोसेसर थांबवते, म्हणजे वापरकर्ता-जागेतील कोणतीही प्रक्रिया शेड्यूल होत नाही, त्यामुळे मध्यांतर कितीही लहान ठेवा, कोणताही कीपअलाइव्ह चालू शकत नाही।
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
हेच सारणी कारण आहे की «स्क्रीन काळी झाली» हे निदान नाही। पाच मिनिटांनी ब्लँक आणि तीस मिनिटांनी सस्पेंड असे सेट केलेले डेस्कटॉप सहाव्या मिनिटाला पूर्णपणे निरोगी टनेलसह काळी स्क्रीन दाखवेल। तिसाव्या मिनिटाची बिघाड दुसरी घटना आणि दुसरा उपाय आहे, आणि खोलीच्या पलीकडून दोन्ही सारखीच दिसतात।
दुसरी तपासणी: वीज आणि नेटवर्कच्या घटना एका वेळरेषेवर ठेवा
संपूर्ण बूटऐवजी मर्यादित कालावधीचा जर्नल वाचा, आणि लॉगिन व्यवस्थापक तसेच कनेक्शनचा मालक दोन्ही समाविष्ट करा:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --listपहिला आदेश झोपेच्या विनंत्या, पुन्हा जागे होणे आणि त्यानंतरचे नेटवर्क संक्रमण दाखवतो। दुसरा आदेश सध्या कोणती गोष्ट अवरोधक कुलूप धरून आहे हे दाखवतो, ज्यामुळे काही गोष्ट जाणूनबुजून झोप रोखत आहे का आणि तो कोणता कार्यक्रम आहे हे कळते। तुमच्या कनेक्शनचा मालक NetworkManager नसल्यास युनिटची नावे बदला, आणि दुसऱ्या वापरकर्त्याचे युनिट किंवा सिस्टम जर्नल वाचणे स्थानिक धोरणावर अवलंबून आहे हे लक्षात ठेवा।
गहाळ ओळ नकारात्मक निकाल नाही। निवडलेल्या युनिटचा जर्नल तुमच्या खात्याला दिसत नसेल, तर सस्पेंड नोंदीची अनुपस्थिती काहीही सिद्ध करत नाही, आणि रिकाम्या फिल्टरमधून «ते कधीही झोपले नाही» असा निष्कर्ष काढणे हा तोच मार्ग आहे ज्यावर लोक आठवडाभर कीपअलाइव्ह जुळवत बसतात।
तिसरी तपासणी: ते झोपले असेल, तर ते हेतुपुरस्सर होते का ते ठरवा
वेळरेषेवर झोपेचे संक्रमण आल्यावर प्रश्न «VPN का तुटले» यावरून «मशीनला अजिबात झोपायला हवी होती का» याकडे बदलतो। लॅपटॉपवर उत्तर बहुतेक होय असते, आणि टनेलचा तुटणे हे अपेक्षित वर्तन आहे ज्यातून क्लायंटने जागे झाल्यावर सावरले पाहिजे। ज्या वर्कस्टेशनला पोहोचण्यायोग्य राहायचे आहे तिथे झोपेचे धोरण बदलायचे असते। या दोनपैकी कोणत्या मशीनकडे पाहत आहात हे ठरवायला एक प्रश्न लागतो, आणि तो असा प्रश्न नाही ज्याचे उत्तर जर्नल तुमच्या वतीने देऊ शकेल।
ते लॉग इन केलेल्या सत्राच्या नियंत्रणांद्वारे बदला, किंवा गरज संपूर्ण मशीनची असेल तर प्रशासक-समर्थित यंत्रणेद्वारे बदला। दुसऱ्या खात्याने लॉग इन असताना डिस्प्ले व्यवस्थापकाचे सेटिंग संपादित करणे ही तीच क्रिया नाही आणि पुढील सत्र सुरू होईपर्यंत ते काम केल्यासारखे दिसेल। वीज व्यवस्थापन पूर्णपणे बंद करणे ही बॅटरीचे आयुष्य खाणारी आणि खरा धोरणाचा प्रश्न लपवणारी व्यापक पहिली प्रतिक्रिया आहे।
चौथी तपासणी: ते जागे राहिले असेल, तर नेटवर्क आणि क्लायंट पाहा
टनेल गमावलेल्या जाग्या मशीनची तीनपैकी एक कहाणी असते: प्रवेश नेटवर्क पडले, VPN क्लायंट थांबले किंवा पुन्हा सुरू झाले, किंवा सर्व्हरच्या बाजूने सहयोग संपुष्टात आला पण क्लायंट अजूनही जोडलेले आहे असे मानत होता। मूलभूत लिंक घटनेच्या टाइमस्टॅम्पची टनेल घटनेशी तुलना करा, आणि कोणती आधी आली याबद्दल अचूक राहा।
मग मूळ सत्रापासून वेगळे पुनर्प्राप्तीचा मार्ग तपासा। पुनर्प्राप्त टनेलमधून नवीन विनंती यशस्वी होऊ शकते, पण तुटण्यापूर्वी उघडलेले दीर्घकालीन अनुप्रयोग सत्र तुटकच राहते, कारण अनुप्रयोग जुना सॉकेट किंवा कॅशे केलेला पत्ता धरून ठेवतो। ही अनुप्रयोगाची समस्या आहे, टनेल परत आले नाही याचा पुरावा नाही।
उपयुक्त अहवालात काय असते
क्रम टाइमस्टॅम्प आणि मालकांसह लिहा: सत्र कधी लॉक झाले, स्क्रीन कधी काळी झाली, झोपेची विनंती नोंदवली गेली का, लिंक कधी पडली आणि परत आली, टनेलने कधी स्थिती बदलली आणि अनुप्रयोगाने प्रत्यक्षात काय केले। प्रत्येक बाबीला मालक असतो, त्यामुळे प्रत्येक बाब Linux बद्दलच्या सर्वसाधारण तक्रारीत बदलण्याऐवजी योग्य व्यक्तीकडे दिली जाऊ शकते।
यापैकी कोणतीही ओळ गहाळ असेल, तर ती पुढे मोजायची गोष्ट आहे, पुढे बदलायची गोष्ट नाही। अंतर असलेली वेळरेषा अंदाजावर केलेल्या सेटिंग बदलापेक्षा अधिक माहिती देते।