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 सँग सम्बन्ध नभएको कारणले अस्वीकार गर्न सक्छ, र अनुरोध क्रम तपाईंले अभ्यास गरेको भन्दा फरक हुन सक्छ।

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

पूरा लगआउटपछि एकपटक पुनः जडान गरेर अन्त्य गर्नुहोस्। क्यास गरिएको गोप्य विवरणले बिग्रेको प्रवाह अर्को सत्रसम्म सुधारिएको देखाउन सक्छ, र दोस्रो जडानमै हराएको अनुरोध सामान्यतया फर्कन्छ।