.ovpn फाइल संपादित केल्याने सर्व्हरवर MFA का सुरू होऊ शकत नाही

तुम्ही प्रोफाइलमध्ये auth-user-pass जोडता, पुन्हा कनेक्ट होता, आणि क्लायंट वापरकर्तानाव आणि पासवर्ड मागतो. MFA सुरू असल्यासारखे वाटते. मग तुम्ही चुकीच्या खात्याचा कोड, किंवा दहा मिनिटांपूर्वी कालबाह्य झालेला कोड टाकता, आणि बोगदा तरीही वर येतो. हेच लक्षण आहे: क्लायंट बदलला, सर्व्हर बदलला नाही. सर्व्हरवरील पडताळणीकर्ता तो कोड मागणाऱ्या ओळखीसाठी वैध आहे की नाही हे ठरवतो तेव्हाच एकवेळ पासवर्ड हा घटक ठरतो.

विनंती फक्त क्लायंटने विचारले हे सिद्ध करते, त्यापेक्षा जास्त नाही

.ovpn फाइल क्लायंटच्या बाजूचे दस्तऐवज आहे. ती क्लायंटला क्रेडेन्शियल्स मागण्यास, ती कॅशे करण्यास किंवा ते थांबवण्यास सांगू शकते. पण ती वापरकर्ता नोंदवू शकत नाही, PAM मॉड्यूल स्थापित करू शकत नाही, किंवा सर्व्हरला सध्या तपासत नसलेला दुसरा घटक मागण्यास भाग पाडू शकत नाही.

फोनवर ऑथेंटिकेटर अॅप स्थापित केल्यानेही ते नाते तयार होत नाही. Google Authenticator PAM प्रकल्प हा OTP पडताळणीचा घटक आहे जो OpenVPN च्या मागे बसू शकतो; आयात केलेल्या प्रोफाइलवर Google खाते लॉगिन चिकटवण्याचा तो मार्ग नाही.

नोंदणी हा तो भाग आहे जो प्रोफाइल करू शकत नाही

TOTP ला ऑथेंटिकेटर अॅप आणि त्याच्या पडताळणीकर्त्यामध्ये सामायिक नोंदणी साहित्य लागते. फोनवरील सहा अंक आउटपुट आहेत; त्यांच्यामागील बीज हे गुपित आहे, आणि ते एका ओळखीचे आहे.

म्हणून ऑपरेटरला योग्य बीज योग्य VPN ओळखीशी जोडणारी नोंदणी प्रक्रिया हवी, शिवाय हरवलेल्या फोनसाठी पडताळलेला बदली मार्ग हवा. वापरकर्त्यांना त्यांच्या नावाने फाइल अपलोड करू देणे नोंदणीला खाते ताब्यात घेण्याची संधी बनवते, आणि अपलोड एन्क्रिप्ट केल्याने ते बदलत नाही.

PAM आधारित रचनेला प्रत्येक VPN वापरकर्त्यासाठी वेगळे Unix खाते तयार करण्याची गरज नाही. मॉड्यूलचे दस्तऐवजीकरण पर्यायी गुप्त मार्ग आणि फाइल प्रवेशासाठी समर्पित खाते समर्थित करते, जी फाइलसिस्टम ओळख आहे, तपासली जाणारी लॉगिन ओळख नाही.

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

PAM स्टॅक वाचा आणि प्रत्यक्षात काय आवश्यक आहे ते पहा

account required pam_permit.so सारखी ओळ खाते पात्रता लागू करत नाही आणि घटक जोडत नाही. ती त्या PAM खाते-व्यवस्थापन टप्प्यास परवानगी देते, जे टप्प्याबद्दलचे विधान आहे, तुमच्या वापरकर्त्यांबद्दल नाही.

हेच उदार नोंदणी पर्यायांनाही लागू होते. नोंदणीकृत गुपित नसलेल्या वापरकर्त्यांना स्वीकारणे हा जाणीवपूर्वक रोलआउट निर्णय असू शकतो, पण तो MFA अनिवार्य असल्याचा पुरावा नाही, आणि तो समाप्ती तारखेसह तात्पुरता अपवाद म्हणून लिहून ठेवावा.

क्लायंटचा परस्परसंवाद सर्व्हरच्या रचनेशी जुळवा

auth-user-pass

हा निर्देश वापरकर्तानाव आणि पासवर्ड इनपुट मागतो. तो PAM कॉन्फिगर करत नाही, नोंदणी रेकॉर्ड तयार करत नाही, आणि पासवर्ड फील्डमध्ये TOTP मूल्य आहे हे सर्व्हरला सांगत नाही. सर्व्हर एकत्रीकरण आणि क्लायंटने त्या परस्परसंवादावर सहमत व्हावे ज्याला उपयोजन प्रत्यक्षात समर्थन देते: आव्हान, दस्तऐवजीकृत एकत्रित क्रेडेन्शियल स्वरूप, किंवा उत्पादन-विशिष्ट प्रवाह.

क्लायंट एक फील्ड दाखवतो म्हणून पासवर्डला कोड जोडू नका. तो फक्त तिथेच काम करतो जिथे सर्व्हरचा प्लगइन नेमके तेच स्वरूप अपेक्षित करतो, आणि बाकी सर्वत्र तो गोंधळात टाकणारा अयशस्वी होतो.

बीज आणि QR साहित्य सामायिक प्रोफाइल आणि नियमित निदान लॉगपासून दूर ठेवा. प्रमाणित लॉगिन चॅनेलवर सादर केलेला कोड नियंत्रित नोंदणीदरम्यान दिलेल्या बीजासारखाच वस्तू नाही, आणि सहाय्य तिकिटात दोन्ही मिसळणे हा गुपिते बाहेर पडण्याचा मार्ग आहे.

पुन्हा कनेक्शन, टोकन आणि प्रकरण निकाली काढणारी चाचणी

पहिल्या यशस्वी लॉगिननंतर काय होते याची योजना करा. पूर्वी स्वीकारलेला कोड पुढील प्रमाणीकरणात कालबाह्य झालेला किंवा पुनरावृत्ती म्हणून नाकारलेला असू शकतो. auth-nocache क्रेडेन्शियल्स टिकवण्यावर नियंत्रण ठेवतो आणि MFA स्थापित करत नाही, आणि reneg-sec 0 फोरम थ्रेडमध्ये कितीही वेळा दिसला तरी TOTP समर्थनाची व्याख्या नाही.

काही उपयोजने प्रारंभिक तपासणीनंतर प्रमाणीकरण टोकन देतात जेणेकरून पुन्हा कनेक्शन पुन्हा विचारणार नाही. तो स्वतःच्या वैधता कालावधी आणि रद्दीकरण कथेसह रचना निर्णय आहे, तुम्हाला वारसाहक्काने मिळणारे डीफॉल्ट नाही.

मग प्रवेश धोरण लोक प्रत्यक्षात वापरत असलेल्या क्लायंटसह तपासा. योग्य पासवर्ड, प्रमाणपत्र आणि सध्याचा कोड असलेल्या नोंदणीकृत वापरकर्त्याने कनेक्ट व्हावे. चुकीचा कोड, नोंदणी नसलेला वापरकर्ता आणि प्रतिबंधित खाते — प्रत्येकाने अयशस्वी व्हावे, आणि कारण सर्व्हर लॉगमध्ये दिसावे. त्या नकार पाहण्यापर्यंत तुमच्याकडे विनंती आहे, धोरण नाही.