VPN पर eapol_test: क्या RADIUS आदान-प्रदान को लेयर 2 चाहिए?
eapol_test पीयर और RADIUS क्लाइंट को एक ही प्रक्रिया में चलाता है, इसलिए रूट किया गया VPN UDP 1812 ले जाता है। संकलित विधि सूची जाँचें, फिर वास्तविक पहुँच अलग से परखें।
लैब स्विच पोर्ट माँगिए ताकि आप eapol_test चला सकें — और संभवतः आपने औज़ार को गलत समझा है। पीयर और RADIUS क्लाइंट दोनों उसी एक बाइनरी के भीतर रहते हैं, इसलिए मशीन से बाहर जाने वाली एकमात्र बातचीत स्वयं RADIUS आदान-प्रदान है। परीक्षण होस्ट और प्रमाणीकरण सर्वर के बीच रूट किया गया सुरंग ही पूरी नेटवर्क आवश्यकता है। भौतिक 802.1X पथ एक अलग चीज़ है जिसे आपको अभी भी परखना पड़ सकता है, और यह वह नहीं है।
नाम लोगों को स्विच पोर्ट ढूँढ़ने क्यों भेजता है
EAPOL वह फ़्रेम प्रारूप है जिसका उपयोग supplicant और स्विच LAN पर करते हैं, और औज़ार ने नाम उधार लिया है क्योंकि वह उसी दुनिया से निकला है। जो दिया जाता है वह एक परीक्षण कार्यक्रम है जो पीयर स्टेट मशीन और RADIUS क्लाइंट को एक ही प्रक्रिया में रखता है, इसलिए 802.1X बातचीत के दो आधे कभी तार पर नहीं मिलते। नाम इतिहास है, टोपोलॉजी की आवश्यकता नहीं।
लोग अब भी पोर्ट माँगते हैं क्योंकि कार्यक्रम प्रमाणक के व्यवहार पर टिका है, और वह हार्डवेयर जैसा लगता है। उसका गोंद प्रमाणक की स्टेट मशीन को दोहराता है, इसलिए कमरे में किसी भी प्रवेश बिंदु के बिना परीक्षण पूरा हो जाता है; संकलित बाइनरी wpa_supplicant के EAP पीयर को hostapd के RADIUS क्लाइंट से जोड़ती है। स्विच हटाने से EAPOL छलांग हटती है, प्रमाणीकरण तर्क नहीं। जो बचता है वह दो IP होस्टों के बीच क्लाइंट-सर्वर आदान-प्रदान है।
एक RADIUS आदान-प्रदान को छलांग दर छलांग देखें
एक प्रयास देखें और पथ छोटा है। eapol_test के भीतर का पीयर आपकी कॉन्फ़िगर की गई विधि के लिए EAP-Response बनाता है, और उसी प्रक्रिया का RADIUS क्लाइंट उसे Access-Request में डालता है, पेलोड को Message-Authenticator के साथ EAP-Message विशेषताओं में ले जाता है। वह डेटाग्राम UDP पोर्ट 1812 पर सर्वर को संबोधित है और किसी भी अन्य IP पैकेट की तरह होस्ट छोड़ता है, और वहीं सुरंग आती है। सर्वर उसे अपनी नीति और विधि मॉड्यूल के विरुद्ध आँकता है, फिर Access-Challenge, Access-Accept या Access-Reject से उत्तर देता है।
eapol_test -c peap-mschapv2.conf -a 198.51.100.20 -p 1812 \
-s REPLACE_WITH_RADIUS_SECRET -t 30बाइनरी सर्वर पता, पोर्ट और साझा रहस्य कमांड लाइन से लेती है, और विधि तथा क्रेडेंशियल wpa_supplicant-शैली के कॉन्फ़िगरेशन ब्लॉक से। उस कॉल में कुछ भी लेयर 2 की निकटता पर निर्भर नहीं है: -a रूटिंग से पहुँचा जाता है, और उसे रूट करने वाला VPN पर्याप्त है। यदि सुरंग डेटाग्राम गिरा देती है, तो परीक्षण ठीक वैसे ही विफल होता है जैसे सपाट LAN पर अगम्य सर्वर के सामने।
बाइनरी और सर्वर नीति अलग सूचियाँ हैं
दो स्वतंत्र सूचियाँ तय करती हैं कि कोई विधि पार हो सकती है या नहीं, और उन्हें मिलाने से एक दिन बर्बाद होता है। पहली सूची बाइनरी में संकलित है: बिल्ड कॉन्फ़िगरेशन चुनता है कि कौन-सी EAP विधियाँ मौजूद हैं, इसलिए बिना विधि वाला बिल्ड उस पर बातचीत नहीं कर सकता चाहे सर्वर जो भी अनुमति दे। दूसरी सूची सर्वर पर रहती है, जहाँ नीति कहती है कि समर्थित विधियों में से यह क्लाइंट वर्ग कौन-सी इस्तेमाल कर सकता है। पार होने के लिए प्रतिच्छेद चाहिए, और कोई सूची दूसरी का अंतराल नहीं भर सकती।
सर्वर को दोष देने से पहले वह पहली सूची जाँचें। स्थापित बाइनरी में विधि का नाम खोजें, या जिस बिल्ड कॉन्फ़िगरेशन से वह आई उसे पढ़ें। यदि विधि अनुपस्थित है, तो RADIUS नीति संपादित करने के बजाय फिर से बिल्ड करें; यदि वह मौजूद है और आदान-प्रदान फिर भी विफल होता है, तो समस्या क्रेडेंशियल, नीति या प्रमाणपत्र भरोसे पर जा चुकी है।
पार होना अभी भी क्या नहीं ढकता
सफल रन एक विधि सिद्ध करता है, एक क्रेडेंशियल समुच्चय के लिए, एक RADIUS नीति के विरुद्ध, एक नेटवर्क पथ पर। यह प्रवेश बिंदु के रेडियो, स्विच के EAPOL प्रबंधन, प्रमाणीकरण के बाद के VLAN आवंटन, या किसी VPN केंद्रीकरण के उसी सर्वर के साथ एकीकृत होने के तरीके का अभ्यास नहीं करता। वे घटक कभी परखे गए पथ पर नहीं थे। परिणाम को सीमित प्रमाण मानें, और रिपोर्ट करते समय बताएं कि वह कौन-सी सीमा ढकता है।
उपयोगी अभिलेख वह है जो सर्वर और प्रक्रिया ने अलग-अलग देखा: कौन-सी विधि पर बातचीत हुई, आदान-प्रदान कहाँ रुका, और सर्वर ने क्या लॉग किया। साझा रहस्य और निजी कुंजियाँ उस अभिलेख से बाहर रखें।
परिणाम उद्धृत करने से पहले जाँच सूची
इससे पहले कि कोई आउटपुट को स्वीकृति माने, चार बातें पुष्टि करें। बिल्ड में परखी जा रही विधि है, RADIUS अंतबिंदु और साझा रहस्य परखे जा रहे वातावरण के हैं, सर्वर नीति इस परीक्षण पहचान को स्वीकार करती है, और नेटवर्क पथ उसी वर्ग का है जो उत्पादन क्लाइंट उपयोग करते हैं। फिर नाम लें कि रन ने क्या नहीं छुआ: प्रवेश बिंदु, स्विच, VLAN और केंद्रीकरण एकीकरण को परीक्षण योजना में अपनी-अपनी पंक्ति चाहिए।
दो मालिकों वाले दो परीक्षण एक अस्पष्ट स्वीकृति से बेहतर हैं। eapol_test रन विधि-और-सर्वर प्रश्न का उत्तर देता है; पहुँच सेवा प्रवर्तन के प्रश्न का उत्तर देती है।