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 प्रमाणीकरणबाट अलग राख्नुहोस्, जबसम्म कार्यले स्पष्ट रूपमा दुवै समावेश गर्दैन। दूरस्थ पहुँचका लागि लक्षित परिवर्तनले त्यसलाई अन्त्य गर्ने उपकरण व्यवस्थापन गर्ने क्षमता खोस्नु हुँदैन।