VPN गेटवेमार्फत EAP: पद्धत कोण संपवतो

हेल्पडेस्क तिकिटे अपयशी VPN लॉगिन आणि अधिक मजबूत पद्धत मागणाऱ्या RADIUS धोरणाचे एकच समस्या असे वर्णन करतात, पण तसे नाही. गेटवे एकतर क्रेडेन्शियल्स स्वीकारून पुढे पाठवतो, किंवा क्लायंट आणि प्रमाणीकरण सर्व्हरमध्ये EAP संभाषण नेतो. यापैकी काय घडते यावर सर्व्हर बाजूचा बदल काही दुरुस्त करू शकतो का ते ठरते. सर्व्हर गट संपादित करण्यापूर्वी देवघेव वाचा.

लॉगमध्ये सारखे दिसणारे दोन प्रमाणीकरण मार्ग

पहिल्या मार्गात VPN गेटवे वापरकर्तानाव आणि पासवर्ड गोळा करतो आणि पासवर्ड गुणधर्मासह RADIUS Access-Request पाठवतो. प्रमाणीकरण सर्व्हर ते आपल्या साठ्याशी तुलना करतो आणि स्वीकार किंवा नकार असे उत्तर देतो. क्लायंट कधीही EAP पद्धत चालवत नाही, कारण कोणीही ती मागितली नाही.

दुसऱ्या मार्गात क्लायंट आणि प्रमाणीकरण सर्व्हर EAP पद्धत सुरुवातीपासून शेवटपर्यंत चालवतात, आणि गेटवे त्यांच्यामध्ये EAP-Message गुणधर्म पाठवतो. गेटवे अजूनही बाहेरील RADIUS संभाषण संपवतो, पण पद्धतीचे तर्क दोन्ही टोकांवर असते.

दोन्ही मार्ग लॉगमध्ये प्रमाणीकरण अपयशी झाले अशी ओळ निर्माण करतात. फक्त दुसऱ्यावर सर्व्हर कोणती EAP पद्धत पसंत करतो याचा परिणाम होऊ शकतो, आणि फक्त पहिल्यावर गेटवे पासवर्ड कसा वाचतो याचा. त्यांना अदलाबदल करण्यायोग्य मानणे म्हणजे PEAP न बोलणाऱ्या क्लायंटसाठी संघ दिवसभर सर्व्हर गट बदलण्यात घालवतात याचे कारण.

पद्धत प्रत्यक्षात कुठे चालते

RFC 3579 पास-थ्रू व्यवस्था ठरवते: NAS RADIUS गुणधर्मांमध्ये EAP पॅकेट नेतो आणि प्रत्येक EAP प्रकारासाठी पद्धत-विशिष्ट कोडची गरज नसते. म्हणून गेटवे PEAP आणि EAP-TLS यांना कोणतेही अंमलात न आणता समर्थन देऊ शकतो.

पासवर्ड सबमिट करणारा गेटवे PEAP नेत नाही, जरी बॅकएंड दुसऱ्या क्लायंटकडून PEAP स्वीकारले तरी. सर्व्हर धोरणात PEAP सक्षम केल्याने कधीही न देऊ केलेल्या क्लायंटला पद्धत जोडली जात नाही.

PPP प्रमाणीकरण सेटिंग्ज PPP सेवेच्या आहेत. त्या समान AAA सर्व्हर वापरणाऱ्या प्रत्येक IPsec किंवा जुन्या XAuth मार्गाची शांतपणे पुनर्रचना करत नाहीत, म्हणून एका प्रवेश प्रकारासाठी काम करणारा बदल दुसऱ्याला अस्पर्श ठेवू शकतो.

NAS ने काय समर्थन द्यायला हवे

पास-थ्रू आवश्यकता पद्धत कोडमधून वाहक समर्थनाकडे सरकवते. गेटवेने आपल्या VPN प्रोटोकॉलवर EAP नेले पाहिजे, आणि त्यावरील RADIUS क्लायंटने संबंधित आकाराचे EAP-Message गुणधर्म पाठवले व स्वीकारले पाहिजेत.

IKEv2 साठी EAP हा ठरलेल्या प्रमाणीकरण प्रवाहाचा भाग आहे, आणि सर्व्हरची ओळख व विश्वास तपासणी त्या प्रवाहातून येते. 802.1X अंमलबजावणीतून घेतलेला PEAP लेबल आपोआप हस्तांतरित होत नाही, कारण त्याच्याभोवतीची वाटाघाटी वेगळी असते.

क्लायंट बाजूलाही आवश्यकता आहेत. तो पद्धतीसाठी संरचित असला पाहिजे, पद्धत सादर करणाऱ्या सर्व्हर प्रमाणपत्रावर विश्वास ठेवला पाहिजे आणि पद्धत वापरू शकेल असे क्रेडेन्शियल्स असले पाहिजेत. क्लायंट प्रमाणपत्राशिवाय प्रमाणपत्र-आधारित पद्धत RADIUS काही पाहण्यापूर्वीच अपयशी ठरते, ही सर्व्हर धोरणाची नाही तर पुरवठ्याची समस्या आहे.

धोरण बदलण्यापूर्वी एक प्रयत्न वाचा

गेटवे आणि प्रमाणीकरण सर्व्हरवर एक मंजूर प्रयत्न कॅप्चर करा. RADIUS विनंतीत EAP-Message गुणधर्म शोधा. त्यांची उपस्थिती पास-थ्रू मार्ग वापरात असल्याचे सांगते; अनुपस्थिती क्रेडेन्शियल्सच्या देवघेवीकडे निर्देश करते.

Linux गेटवेवर RADIUS पोर्टवरील कॅप्चर तारेवर कोणते गुणधर्म आहेत ते दाखवते:

sudo tcpdump -ni any -X 'udp port 1812' -c 20

नंतर नकार बिंदूची तुलना करा. कोणत्याही RADIUS पॅकेटपूर्वी गेटवेवर अपयश म्हणजे क्लायंट आणि गेटवे पद्धतीवर सहमत नव्हते. EAP गुणधर्म असलेला RADIUS नकार म्हणजे दोन्ही टोकांनी पद्धत चालवली आणि त्यापैकी एकाने निकाल नाकारला.

स्थलांतर एकच सुरुवातीपासून-शेवटपर्यंतचा बदल म्हणून नियोजित करा

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

जे संयोजन काम करते ते नोंदवा: VPN प्रोटोकॉल, EAP वाहक, सहकारी पद्धत, सर्व्हर पद्धत, क्रेडेन्शियल्स प्रकार आणि सर्व्हर ओळख तपासणी.

प्रशासकीय लॉगिन AAA VPN प्रमाणीकरणापासून वेगळे ठेवा, जोपर्यंत कार्य स्पष्टपणे दोन्ही समाविष्ट करत नाही. दूरस्थ प्रवेशासाठीचा बदल तुम्हाला ते संपवणाऱ्या उपकरणाचे व्यवस्थापन करण्याची क्षमता घेऊ नये.