टर्मिनल बन्द गर्दा 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 होइन। अधिकांशका लागि सबैभन्दा कम हस्तक्षेपकारी समाधान भनेको दिनभर खुला रहने सत्रबाट क्लाइन्ट सुरु गर्ने र त्यो विन्डोलाई छुनु नहुने हो।

टिकट बन्द गर्नुअघि, टनेल उठ्दा क्लाइन्टले कुन सत्र हेरिरहेको थियो अभिलेख गर्नुहोस्। त्यो एउटै लाइनले रहस्यमय विच्छेदलाई मेसिनमा बस्ने अर्को व्यक्तिका लागि पुनरुत्पादनयोग्य अवस्थामा बदल्छ।