OpenVPN नंतर OTP सत्र का तोडते: पुनर्प्रमाणीकरणाला काय लागते

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

उपाय म्हणजे दुसऱ्या हस्तांदोलनाने काय सादर करावे हा निर्णय, अधिक लांब पुनःप्रयत्न टाइमर नाही।

क्लायंटच्या दृष्टिकोनातून देवघेव पाहा

लॉगिनच्या वेळी क्लायंट वापरकर्तानाव, पासवर्ड आणि टोकन उपकरणातील कोड पाठवतो, आणि सर्व्हर ते संयोजन स्वीकारतो। त्यानंतर सत्र पुन्हा बोलणीचा ट्रिगर सक्रिय होईपर्यंत चालते, जो विद्यमान बोगद्यात नवीन TLS हस्तांदोलन सुरू करतो। ते हस्तांदोलन पुन्हा प्रमाणीकरण मागते। जर सर्व्हरचा प्रमाणीकरण मार्ग पासवर्ड आणि सध्याचा एकवेळा कोड अपेक्षित असेल, तर वापरकर्ता तिथे उपस्थित राहून टाइप करत नसेल तर क्लायंटकडे देण्यासाठी नवीन कोड नाही।

बहुतेक क्लायंट सत्राच्या मध्यात प्रॉम्प्ट उघडत नाहीत, म्हणून हस्तांदोलनाची वेळ संपते आणि बोगदा तुटतो। वापरकर्त्याला प्रमाणीकरण प्रॉम्प्ट नाही तर पुन्हा जोडणी दिसते, म्हणूनच पहिला अहवाल सहसा नेटवर्कला दोष देतो।

auth-gen-token दुसऱ्या प्रश्नाला कोण उत्तर देते हे बदलते

पर्याय auth-gen-token सर्व्हरला यशस्वी लॉगिननंतर टोकन देण्यास अनुमती देतो, आणि नंतरच्या पुनर्बोलण्या पासवर्ड व कोड पुन्हा न देता तेच टोकन सादर करतात। या पुस्तिकेत त्याचे आयुष्यमान व नूतनीकरणाचे वर्तन नोंदवले आहे, आणि टोकन स्वतःच्या कालबाह्यतेसह ओळखपत्र म्हणून वागवावे लागते। डीफॉल्ट मार्गात सर्व्हर बाह्य पासवर्ड प्रमाणकाला पुन्हा न बोलावता टोकन स्वतः सत्यापित करतो।

बाह्य प्रमाणीकरणाच्या एकत्रीकरणासह ती विभागणी बदलते। प्लगइनला टोकनची स्थिती समजून स्वतःच्या तपासण्या लावाव्या लागतात, कारण सत्र पुढे चालेल की नाही हे ठरवणारा एकमेव घटक आता सर्व्हर नाही। टोकनला अजून एक संख्यात्मक एकवेळा कोड म्हणून वागवणे ही या सुविधेची अंमलबजावणी नाही।

खात्याच्या स्थितीचे काय होईल ते ठरवा

खात्याच्या प्रवेशापेक्षा जास्त जगणारे टोकन हे धोरणातील छिद्र आहे। अनुपलब्ध खाते, काढून टाकलेले गट-सदस्यत्व किंवा रद्द केलेले उपकरण टोकन अजून वैध असताना कसे परिणाम करते ते ठरवा। टोकनचे लहान आयुष्यमान खिडकी लहान करते; स्पष्ट रद्दीकरण मार्ग तिला हेतुपूर्वक बनवतो। पर्याय सुरू करण्यापूर्वी उत्तर लिहून ठेवा, कारण डीफॉल्ट मार्ग प्रत्येक पुनर्बोलणीला बाह्य प्रमाणकाला विचारत नाही।

अनेक सर्व्हरच्या तैनातीत टोकन स्वाक्षरीचे रहस्य सामायिक असावे लागते, अन्यथा क्लायंटला असे नोड पाठवले जाऊ शकते जे त्याचे टोकन सत्यापित करू शकत नाही।

फक्त लॉगिन नाही, कालबाह्यता आणि पुनर्जोडणी तपासा

चाचणी प्रोफाइलमध्ये पुनर्बोलणीचा मध्यांतर कमी करा जेणेकरून दुसरे हस्तांदोलन तुम्ही पाहत असतानाच होईल, नंतर दोन्ही लॉग पाहा। टोकन लॉगिनला दिले जाते, की-बदलाला सादर केले जाते आणि नियोजित आयुष्यमानानुसार नूतनीकृत किंवा पुन्हा दिले जाते याची खात्री करा। नंतर टोकनची कालबाह्यता आणि पूर्ण पुनर्जोडणी सक्तीने घडवा, कारण स्वच्छपणे पुन्हा जोडणारा क्लायंटही की-बदलाच्या मार्गावर अयशस्वी होऊ शकतो।

खाते काढण्याची चाचणी शेवटी करा। ती स्थिती तुम्ही लिहिलेले धोरण अंमलात येते की फक्त नोंदवले जाते हे सांगते।

नूतनीकरण बंद करून ते दुरुस्त करू नका

दोन्ही टोकांवर पुनर्बोलणीचा मध्यांतर शून्यावर आणल्यास लक्षण आणि त्यासोबत की-फिरणीही नाहीशी होते। ते कोणीही तपासले नाहीत अशा धोरण-बदलामागे ओळखपत्राच्या पुनरावृत्तीची समस्या लपवते। नूतनीकरण ठेवा आणि वापरकर्ता तिथे आहे की नाही यावरून सर्व्हरने दिलेले टोकन किंवा नवीन संवादात्मक आव्हान यातून निवडा।

लांब पुनःप्रयत्न टाइमर खर्च झालेला कोड पुन्हा वैध करत नाही। तो फक्त तुटणे लांबवतो आणि लॉग वाचणे कठीण करतो।