टर्मिनल बंद होने पर 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 पर काम करता है, इसलिए बिना टर्मिनल के स्क्रिप्ट या cron कार्य से चलाने पर इसे मिलाने के लिए कुछ नहीं बचता। और /run/utmp सामान्य उपयोगकर्ताओं के लिए लिखने योग्य नहीं है, इसलिए root के बिना चलाना चुपचाप विफल होता है जब तक आप निकास स्थिति जाँच न लें।

बंद होने के बाद टनल बची रहती है या नहीं, यह सत्यापित करें

मान लेने के बजाय तंत्र का परीक्षण करें। जिस सत्र को आप रखना चाहते हैं उससे कनेक्ट करें, दूसरा टर्मिनल खोलें, दूसरा बंद करें, फिर vpn state और इंटरफ़ेस सूची पर एक नज़र से पुष्टि करें कि टनल अभी भी चालू है। यदि टनल बची रहती है, तो ट्रिगर हर सत्र नहीं बल्कि कोई विशेष सत्र प्रकार था, और आपने वह सत्र ढूंढ लिया है जो खुला रहना चाहिए।

यदि वह फिर भी गिरती है, तो निगरानी किया गया सत्र कहीं और था, अक्सर वही ग्राफ़िकल लॉगिन जिसने आपका टर्मिनल बनाया, और एक TTY प्रविष्टि हटाने से मदद नहीं मिलेगी। अधिक सर्जरी जोड़ने के बजाय पहले कदम की पूरी सूची के साथ अवलोकन दोहराएँ।

कब utmp को फिर से लिखना गलत उत्तर है

utmp साझा लेखा है, निजी तालिका नहीं। अभी जीवित सत्र की प्रविष्टि फिर से लिखने से who, w और कुछ ऑडिट उपकरण उसे कम बताते हैं, और बाद में उसी प्रविष्टि को बंद करने वाला प्रोग्राम पूरी तरह विफल हो सकता है। उपकरण को अपने ही सत्र तक सीमित रखें, मूल फ़ाइल की प्रति रखें, और इसे हर रिकॉर्ड हटाने वाली बूट सेवा न बनाएँ।

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

टिकट बंद करने से पहले दर्ज करें कि टनल उठते समय क्लाइंट किस सत्र पर नज़र रख रहा था। वही एक पंक्ति रहस्यमय डिस्कनेक्ट को मशीन पर अगले व्यक्ति के लिए पुनरुत्पाद्य स्थिति में बदल देती है।