.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 समर्थनको परिभाषा होइन।

केही परिनियोजनहरूले प्रारम्भिक जाँचपछि प्रमाणीकरण टोकन जारी गर्छन् ताकि पुनः जडानले फेरि नसोधोस्। त्यो आफ्नै वैधता विन्डो र रद्दीकरण कथासहितको डिजाइन निर्णय हो, तपाईंले उत्तराधिकारमा पाउने पूर्वनिर्धारित मान होइन।

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