NetworkManager में OpenConnect का TOTP अनुरोध गायब है: चार जाँचें

गेटवे पासवर्ड स्वीकार करता है, कोड माँगता है, और संवाद उसके लिए कोई फ़ील्ड नहीं देता। कुछ गलत टाइप नहीं हुआ: NetworkManager प्लगइन ने छह अंकों का मान माँगे बिना सीक्रेट की अदला-बदली पूरी कर ली। नीचे दी गई चारों जाँचें क्रम से करें, क्योंकि इनमें से सिर्फ़ एक ही क्लाइंट बदलती है। बाकी सूची गेटवे, खाते और प्लगइन के बिल्ड को बाहर करती है।

पहली जाँच: पढ़ें कि प्रमाणीकरण कहाँ रुका

गलत पासवर्ड तुरंत विफल होता है। गायब दूसरा कारक क्रेडेंशियल चरण के बाद विफल होता है, आम तौर पर दोहराए गए अनुरोध या गेटवे की ओर समय-सीमा खत्म होने से। समय और गेटवे लॉग बताते हैं कि कौन-सा दौर बिना उत्तर रह गया।

प्रोफ़ाइल छूने से पहले कनेक्शन लॉग पढ़ें। अगर गेटवे अधूरा प्रमाणीकरण या समय-बाह्य चुनौती बताता है, तो क्लाइंट ने कोड कभी नहीं भेजा। अगर वह अमान्य क्रेडेंशियल बताता है, तो समस्या पासवर्ड में है और कोई भी TOTP सेटिंग उसे ठीक नहीं करेगी।

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

दूसरी जाँच: उसी क्लाइंट का उपयोग करें जिसके पास चुनौती है

OpenConnect स्वयं चुनौती दौर सहित पूरी बातचीत लागू करता है। इसे सीधे चलाना यह पुष्टि करने का सबसे अनुमानित तरीका है कि खाता और गेटवे काम करते हैं:

sudo openconnect --protocol=anyconnect --useragent=AnyConnect vpn.example.net

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

अगर कमांड लाइन सही ढंग से पूछती है, तो खाता, गेटवे और दूसरा कारक ठीक हैं। बची हुई समस्या प्लगइन का संवाद है, प्रमाणीकरण सेवा नहीं। यह सर्वर को छुए बिना खराब घटक को अलग करता है। कमांड का आउटपुट घटना रिकॉर्ड के साथ रखें।

अगर कमांड लाइन भी अनुरोध छोड़ देती है, तो रुकें और गेटवे कॉन्फ़िगरेशन उसके मालिक के साथ जाँचें। कोई भी डेस्कटॉप क्लाइंट ऐसी चुनौती का उत्तर नहीं दे सकता जो सर्वर कभी नहीं भेजता।

तीसरी जाँच: देखें कि आपका प्लगइन TOTP मोड देता है या नहीं

कुछ NetworkManager OpenConnect बिल्ड कनेक्शन के Identity टैब में टोकन मोड और उपयोगकर्ता एजेंट फ़ील्ड देते हैं। उपयोगकर्ता एजेंट को गेटवे के अपेक्षित मान पर सेट करें, मैन्युअल TOTP प्रविष्टि चुनें और कनेक्शन सहेजें।

ये फ़ील्ड हैं या नहीं, यह प्लगइन संस्करण और इस पर निर्भर करता है कि डेस्कटॉप कौन-सा कनेक्शन संपादक इस्तेमाल करता है। अलग संपादक GNOME पैनल द्वारा छिपाए गए विकल्प दिखा सकता है, या इसका उलटा। छिपी सेटिंग ढूँढने से पहले स्थापित पैकेज का संस्करण जाँचें।

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

चौथी जाँच: उत्पन्न कोड को एक समझौता मानें

एक स्क्रिप्ट वर्तमान कोड के लिए oathtool कॉल कर सकती है और उपयोगकर्ता नाम, पासवर्ड और कोड को nmcli connection up --ask में भेज सकती है। क्रम काम करता है, लेकिन साझा सीक्रेट अंततः ऐसी जगह संग्रहीत होता है जिसे स्क्रिप्ट खोल सकने वाला कोई भी पढ़ सकता है, और वह पाठक हमेशा के लिए कोड बना सकता है। यह क्रेडेंशियल सतह का स्थायी विस्तार है, क्लाइंट का सुधार नहीं।

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

स्क्रिप्ट को गेटवे के अनुरोध-क्रम का भी पालन करना होगा। अगर सर्वर पासवर्ड से पहले कोड माँगता है, तो निश्चित इनपुट क्रम गलत मान गलत अनुरोध को भेजता है और वही अधूरा प्रमाणीकरण पैदा करता है। लॉगिन कार्य से जोड़ने से पहले परीक्षण खाते के साथ इसका अभ्यास करें।

वही गेटवे और खाता सुनिश्चित करें

हर वैकल्पिक उपाय को उसी गेटवे, उसी खाते और उसी टनल समूह के सामने जाँचें। जो गेटवे डिवाइस प्रमाणपत्र भी माँगता है कमांड-लाइन क्लाइंट को TOTP से असंबंधित कारण से अस्वीकार कर सकता है, और अनुरोध-क्रम आपके अभ्यास किए क्रम से अलग हो सकता है।

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

पूरे लॉगआउट के बाद एक बार फिर से कनेक्ट करके समाप्त करें। कैश किया गया सीक्रेट टूटे प्रवाह को अगले सत्र तक ठीक दिखा सकता है, और दूसरे कनेक्शन में ही गायब अनुरोध आम तौर पर लौटता है।