IKEv1 सँग XAuth र OTP: प्रत्येक प्रम्प्टले के माग्छ
समूह PSK, प्रयोगकर्ताको XAuth आदानप्रदान र OTP चुनौती तीन फरक इनपुट हुन्। अर्को क्लाइन्ट स्थापना गर्नुअघि प्रत्येक प्रम्प्टलाई यसको मालिकसँग जोड्नुहोस्।
PSK, XAuth र OTP सँग IKEv1 ले एउटा जटिल पासवर्ड माग्दैन। यसले सहकर्मीहरूबीचको साझा कुञ्जी, प्रयोगकर्ता आदानप्रदान र ब्याकएन्डले कसरी माग्ने भनी निर्धारण गर्ने दोस्रो कारक तहहरूमा राख्छ। प्रत्येक तहको आफ्नै मालिक र आफ्नै असफलता सन्देश हुन्छ। यिनलाई मिसाउँदा मानिसहरू समूहको गोप्यता राख्ने फिल्डमा एक-पटकको कोड फेरि टाइप गर्छन्।
अर्को क्लाइन्ट स्थापना गर्नु वा प्रमाणहरू रिसेट गर्नुअघि प्रत्येक प्रम्प्टलाई यो माग्ने तहसँग जोड्नुहोस्।
तीन गोप्यता, तीन मालिक
पूर्व-साझा कुञ्जी सहकर्मी सम्बन्धको हो र दुवै छेउ सम्हाल्नेले एक पटक कन्फिगर गर्छ। प्रयोगकर्ताको प्रमाण प्रमाणीकरण ब्याकएन्डको हो र हरेक लगइनमा जाँचिन्छ। दोस्रो कारक टोकन प्रणालीको हो जसको प्रतिक्रिया हरेक प्रयासमा बदलिन्छ। कुनैले अर्कोलाई प्रतिस्थापन गर्दैन, र तीनलाई एउटै पासवर्ड मान्ने तैनाती कसैले अभिलेख नगरेको तहमा असफल हुन्छ।
तीन स्तम्भ लेख्नुहोस्: मालिक, आयु र प्रत्येकले उत्पादन गर्ने असफलता सन्देश। त्यही तालिका निदानको साधन हो, क्लाइन्टका फिल्ड नाम होइनन्।
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: व्यक्तिको होइन, सहकर्मीको
यो पुरानो व्यवस्थामा पूर्व-साझा कुञ्जीले गेटवे जोडी प्रमाणीकरण गर्छ, त्यसैले प्रयोगकर्ताको लगइनले यसलाई कहिल्यै प्रतिस्थापन गर्दैन। प्रम्प्टको सट्टा सामान्य वार्तालाप त्रुटि उत्पादन गर्ने तरिकामा सबैभन्दा धेरै गल्ती हुने मान पनि यही हो। कुनै पनि प्रयोगकर्ता प्रम्प्ट देखिनुअघि टनेल असफल भएमा शङ्कास्पद कुञ्जी वा प्रस्तावहरू हुन्।
प्रयोगकर्ताको प्रमाणले पहिलो चरणको असफलता सुधार्न सक्दैन। यसलाई घुमाउँदा सुरक्षित रूपमा घुमाउन सकिने एकमात्र प्रमाण बर्बाद हुन्छ र गलत सिद्धान्त बलियो बन्छ।
XAuth: पुरानो प्रयोगकर्ता आदानप्रदान
XAuth ले IKEv1 सहकर्मी प्रमाणीकरणमाथि प्रयोगकर्ता प्रमाणीकरणको आदानप्रदान थप्छ र कुन ब्याकएन्डले यसलाई जाँच्ने भनी गेटवेले निर्धारण गर्छ। त्यो ब्याकएन्डअनुसार आदानप्रदानले डाइरेक्टरी पासवर्ड, RADIUS प्रमाण वा टोकन प्रतिक्रिया स्वीकार गर्न सक्छ। XAuth शब्दले आदानप्रदानको ढुवानीको नाम दिन्छ, प्रमाणको प्रकारको होइन।
गेटवे प्रोफाइलले कुन ब्याकएन्डतर्फ सङ्केत गर्छ जाँच्नुहोस्। त्यसले प्रयोगकर्तालाई के सोधिन्छ र पासवर्ड रिसेटले वास्तवमै के बदल्छ भन्ने बताउँछ, र दुवै क्लाइन्ट प्रोफाइलमा देखिँदैनन्।
OTP: ब्याकएन्डले जे माग्छ
केही तैनातीहरू पासवर्डपछि छुट्टै एक-पटकको कोड माग्छन्, अरूले अभिलेख गरिएको विभाजकसहित संयुक्त इनपुट ढाँचा परिभाषित गर्छन्। दुवै अवस्थित छन्, र तपाईंअगाडिको प्रोफाइलले कुन हो भन्ने निर्धारण गर्छ। अर्को ठाउँमा चलेको भन्दै जोड्ने तरिका बनाउनु दर्ता टोकन जलाउने सबैभन्दा सामान्य तरिका हो। यो गेटवेकै आफ्ना कागजातले मात्र टुङ्गो लगाउँछ।
गेटवेले दिने आदानप्रदान पूरा गर्न सक्ने क्लाइन्टसँग अभिलेख गरिएको ढाँचा प्रयोग गर्नुहोस्।
क्लाइन्टको सीमा कहाँ टोक्छ
FortiClient 7.4.4 र त्यसपछिका संस्करणहरूले IPsec VPN का लागि IKEv1 लाई अब समर्थन गर्दैनन् भनी Fortinet उल्लेख गर्छ, यो FortiClient अनुकूलता टिप्पणी ले अभिलेख गरेजस्तै सार्वभौमिक हटाइ नभई उत्पादन र संस्करणको सीमा हो। अरू क्लाइन्ट पनि आपसमा बदल्न मिल्दैनन्: OpenConnect र openfortivpn विशेष गेटवे प्रोटोकल बोल्छन्, जुनसुकै IKEv1 प्रोफाइल होइन। स्थापित क्लाइन्टको IKE संस्करण, PSK मोड, XAuth समर्थन र अन्तरक्रिया ढाँचा छुट्टाछुट्टै जाँच्नुहोस्। फरक विधिले जोडिने क्लाइन्टले मूल आवश्यकता प्रमाणित गरेको छैन।
IKEv1 अप्रचलित छ, त्यसैले समर्थन नभएको पुरानो क्लाइन्टमाथि बनाइएको नयाँ तैनाती छोटो अवधिको समाधान हो। गेटवेको मालिकसँग समर्थित स्थानान्तरण मार्ग माग्नुहोस्, त्यहाँ दोस्रो कारक कसरी सम्हालिनेछ भन्नेसमेत।
कारक बन्द नगरी निदान
लगमा चरणहरू अलग गर्नुहोस्: सहकर्मी वार्तालाप, प्रयोगकर्ता आदानप्रदान, दोस्रो कारकको नतिजा, त्यसपछि ठेगाना र मार्ग तोकाइ। हरेक फिल्डमा कोड प्रयास गर्नुको सट्टा कम्पोनेन्ट र चरण अभिलेख गर्नुहोस्। परीक्षण उत्तीर्ण होस् भनी कारक बन्द गर्दा तैनातीबारे केही पनि प्रमाणित नगर्ने टनेल बन्छ।
दर्ताका गोप्यता र साझा कुञ्जी संस्थाको प्रक्रियाअनुसार सुरक्षित भण्डारणमा राख्नुहोस्। स्थायी फाइलमा रहेको एक-पटकको कोड कारक रहन छाडेको कारक हो।