टर्मिनल बंद केल्यावर AnyConnect तुटतो: सत्र तपासण्या

टनेल सुरू आहे, तुम्ही एक अतिरिक्त टर्मिनल बंद करता, आणि क्लायंटमध्ये एकही कळ न दाबता VPN खाली येतो. Linux AnyConnect क्लायंटमध्ये नोंदवलेले कारण राउटिंग नसून सत्र गणना आहे: टनेल सुरू झाला तेव्हा कोणती लॉगिन सत्रे होती हे क्लायंट नोंदवतो आणि त्यातील कोणतेही संपल्यास ते टनेल खाली आणण्याचे कारण मानतो. खालील तपासण्या क्रमाने चालतात, आणि पहिलीच अयशस्वी झाल्यास तुम्ही हे वर्तन पाहत आहात का हे कळते. क्लायंटच्या नेहमीच्या आउटपुटमध्ये टर्मिनलचा उल्लेख नसतो, म्हणून कॉन्सेंट्रेटरला दोष देण्याची पहिली प्रवृत्ती सहसा वाया जाणारे श्रम असते.

सिस्टम फाइल्स संपादित करून सुरुवात करू नका. प्रत्येक पायरी एकतर तुटणे समजावते किंवा एक संभाव्यता काढून टाकते, आणि स्वस्त पायऱ्या आधी येतात.

सत्र तुटणे आणि अंडरले तुटणे वेगळे करा

डिस्कनेक्ट झाल्यावर लगेच पुन्हा कनेक्ट करा. त्याच नेटवर्कवर, नवीन क्रेडेन्शियल्सशिवाय, काही सेकंदात परत येणारे टनेल मृत अपलिंक, Wi-Fi रोमिंग किंवा कॉन्सेंट्रेटरवरील निष्क्रिय टाइमआउट नसून बंद झालेल्या सत्रासारख्या स्थानिक कारणाकडे निर्देश करते. Connecting वर अडकलेले किंवा नेटवर्क बदलल्याशिवाय अयशस्वी होणारे टनेल हा वेगळा लेख आहे.

टनेल सुरू झाला तेव्हा काय उघडे होते ते लिहून ठेवा: तुम्ही क्लायंट चालवलेले टर्मिनल, काहीही दुसरे शेल, ग्राफिकल लॉगिन, आणि दुसऱ्या मशीनवरून आलेले कोणतेही SSH सत्र. ही यादी तुम्हाला थोड्या वेळात लागेल, आणि पुढील तुटण्यानंतर स्मरणातून ती पुन्हा तयार करणे विश्वासार्ह नाही.

कनेक्ट होताना क्लायंटने काय नोंदवले ते तपासा

क्लायंट प्रोसेसच्या पालकांची किंवा टर्मिनल मालकीची तपासणी करत नाही. तो कनेक्ट होताना असलेल्या लॉगिन सत्रांच्या संचाचा स्नॅपशॉट घेतो आणि नंतर त्याच संचाशी तुलना करतो; एखादा सदस्य नाहीसा झाल्यास तुलना अयशस्वी होते आणि टनेलही जाते. म्हणूनच ज्या खिडकीतून कनेक्ट केले ती बंद करणे निरुपद्रवी ठरू शकते, पण असंबंधित अतिरिक्त टर्मिनल बंद केल्यास कनेक्शन जाते: ते सत्र मूळ संचात होते का हे महत्त्वाचे. ही गणना नसून संच तुलना आहे, म्हणून सत्र बदलणेही एक गमावण्याइतकेच घातक ठरू शकते.

काहीही बदलण्यापूर्वी क्लायंटला काय दिसू शकत होते ते सूचीबद्ध करा:

who
w
last -n 10
sudo ls -l /run/utmp

who मधील प्रत्येक ओळ utmp मधील वापरकर्ता प्रक्रिया नोंद आहे. तुमचे सत्र दोनदा दिसल्यास, एकदा ग्राफिकल लॉगिनसाठी आणि एकदा टर्मिनलसाठी, दोन्ही नोंदी कनेक्ट होताना होत्या आणि दोन्ही उमेदवार आहेत.

utmp मधून फक्त तुमचीच नोंद काढा

प्रकाशित उपाय तुम्ही वापरणार असलेले सत्र क्लायंट सुरू होण्यापूर्वी utmp मध्ये अदृश्य करतो. एक छोटा C प्रोग्राम getutent() मधून फिरतो, ut_line प्रमाणित इनपुटच्या TTY शी समान असलेली नोंद शोधतो, आणि ती नोंद पुन्हा लिहितो. क्रम हेतुपुरस्सर आहे: setutent(), नोंद वाचा, तिचे ut_id कॉपी करा, ut_type DEAD_PROCESS वर सेट करा, वापरकर्ता व ओळीची फील्डे रिकामी करा, pututline() ने पुन्हा लिहा, नंतर endutent().

ते कंपाइल करा, नंतर क्लायंट सुरू करणाऱ्या शेलमधून root म्हणून चालवा:

sudo ./utmpremove && /opt/cisco/anyconnect/bin/vpn -s connect vpn.example.edu

साधन काहीही करत नाही अशा बहुतेक तक्रारींसाठी दोन अपयश पद्धती कारणीभूत आहेत. ते प्रमाणित इनपुटशी जोडलेल्या TTY वर कार्य करते, त्यामुळे टर्मिनल नसलेल्या स्क्रिप्ट किंवा क्रॉन जॉबमधून चालवल्यास जुळवण्यासाठी काहीही उरत नाही. आणि /run/utmp सामान्य वापरकर्त्यांना लिहिण्यायोग्य नाही, त्यामुळे root नसलेली धावणी एग्झिट स्थिती तपासल्याशिवाय शांतपणे अयशस्वी होते.

टनेल बंद होणे सहन करतो का ते तपासा

यंत्रणा गृहीत धरण्याऐवजी चाचणी करा. तुम्ही ठेवू इच्छित असलेल्या सत्रातून कनेक्ट करा, दुसरे टर्मिनल उघडा, दुसरे बंद करा, नंतर vpn state आणि इंटरफेस यादी पाहून टनेल अजूनही सुरू असल्याची खात्री करा. टनेल टिकल्यास, कारण प्रत्येक सत्र नसून विशिष्ट सत्र प्रकार होता, आणि उघडे ठेवावे लागणारे सत्र तुम्हाला सापडले.

तरीही तुटत असेल, तर पाहिले जात असलेले सत्र दुसरीकडे होते, बहुतेक वेळा तुमचे टर्मिनल तयार करणारे ग्राफिकल लॉगिन, आणि एक TTY नोंद काढून त्याचा उपयोग होणार नाही. अधिक शस्त्रक्रिया करण्याऐवजी पहिल्या पायरीच्या पूर्ण यादीसह निरीक्षणाची पुनरावृत्ती करा.

utmp पुनर्लेखन चुकीचे उत्तर कधी असते

utmp हे सामायिक गणना आहे, खाजगी तक्ता नाही. अजून जिवंत असलेल्या सत्राची नोंद पुन्हा लिहिल्यास who, w आणि काही ऑडिट साधने ते कमी नोंदवतात, आणि नंतर तीच नोंद बंद करणारा प्रोग्राम पूर्णपणे अयशस्वी होऊ शकतो. साधन तुमच्या स्वतःच्या सत्रापुरते मर्यादित ठेवा, मूळ फाइलची प्रत ठेवा, आणि प्रत्येक नोंद काढून टाकणारी बूट सेवा त्याची करू नका.

तुमची संस्था अनुपालनासाठी सत्र गणना गोळा करत असेल, तर हा उपाय त्या आवश्यकतेशी विसंगत आहे आणि समर्थित उत्तर क्लायंट आवृत्ती किंवा वेगळी प्रवेश पद्धत आहे, पॅच केलेला utmp नाही. बहुतेकांसाठी सर्वात कमी हस्तक्षेपाचा उपाय म्हणजे दिवसभर उघडे राहणाऱ्या सत्रातून क्लायंट सुरू करणे आणि ती खिडकी शांत ठेवणे.

तिकीट बंद करण्यापूर्वी, टनेल सुरू झाला तेव्हा क्लायंट कोणते सत्र पाहत होता ते नोंदवा. ती एकच ओळ रहस्यमय डिस्कनेक्टला मशीनवरील पुढील व्यक्तीसाठी पुनरुत्पादनीय स्थितीत बदलते.