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 कालबाह्य आहे, म्हणून आधार नसलेल्या जुन्या क्लायंटवर उभारलेली नवी तैनाती अल्पकालीन उपाय आहे। गेटवेच्या मालकाकडे आधारित स्थलांतर मार्ग मागा, तिथे दुसरा घटक कसा हाताळला जाईल यासह।
घटक बंद न करता निदान
लॉगमधील टप्पे वेगळे करा: सहकाऱ्यांची वाटाघाटी, वापरकर्ता देवघेव, दुसऱ्या घटकाचा निकाल, नंतर पत्ता आणि मार्ग नेमणूक। प्रत्येक फील्डमध्ये कोड वापरून पाहण्याऐवजी घटक आणि टप्पा नोंदवा। चाचणी उत्तीर्ण व्हावी म्हणून घटक बंद केल्यास तैनातीबद्दल काहीही सिद्ध न करणारा बोगदा तयार होतो।
नोंदणीच्या गुप्तता आणि सामायिक किल्ली संस्थेच्या प्रक्रियेनुसार संरक्षित साठवणीत ठेवा। कायमस्वरूपी फाइलमधील एकवेळचा कोड हा घटक राहिलेला नसलेला घटक आहे।