चरण-दर-चरण RADIUS प्रमाणीकरण का परीक्षण कैसे करें
Published
आप एक लैपटॉप, एक एक्सेस पॉइंट और एक RADIUS सर्वर के साथ एक साइट पर हैं जो "पहले से ही ठीक होना चाहिए।" किसी ने इसे पिंग किया था। UDP 1812 खुला है। एक डैशबोर्ड प्रोब भी हरा वापस आया। इनमें से कोई भी आपको यह नहीं बताता है कि क्या किसी कर्मचारी का डिवाइस कर्मचारी VLAN पर आता है, या क्या रद्द किए गए प्रमाणपत्र को अभी भी एक सत्र मिलता है।
RADIUS प्रमाणीकरण का परीक्षण कैसे करें, यह प्रमाणों की एक श्रृंखला है, न कि केवल एक लॉगिन। प्रत्येक Access-Accept को एक परिकल्पना (hypothesis) के रूप में लें। आपको अभी भी विधि, एट्रिब्यूट्स, स्रोत पता, और सर्वर, डायरेक्ट्री या प्रमाणपत्र के गलत होने पर नेटवर्क क्या करता है, इसकी जांच करनी होगी।
एक नियंत्रित अनुरोध से शुरुआत करें। फिर मामलों का दायरा तब तक बढ़ाएं जब तक कि गलत पास (false pass) के लिए छिपने की कोई जगह न बचे।
विषय सूची
- radtest के साथ अपना पहला परीक्षण भेजें
- Access-Accept नेटवर्क एक्सेस साबित क्यों नहीं करता है
- प्रत्येक RADIUS परिनियोजन के लिए आवश्यक टेस्ट केसेस
- radclient के साथ लोड और लेटेंसी को मापें
- विफलता पाथ, फेलओवर और सुरक्षा जांच
- प्रत्येक परीक्षण परिणाम की पुष्टि के लिए लॉग पढ़ें
- तय करें कि RADIUS रोलआउट के लिए कब तैयार है
radtest के साथ अपना पहला परीक्षण भेजें
वह कमांड जिसे आप अगले पांच मिनट में चला सकते हैं, वह है radtest testing password 127.0.0.1 0 testing123। FreeRADIUS radtest मैनुअल इसे पांच इनपुट के साथ नियंत्रित Access-Request के रूप में परिभाषित करता है: उपयोगकर्ता नाम, पासवर्ड, सर्वर पता, NAS-Port और साझा रहस्य। PAP डिफ़ॉल्ट है। यही उपयोगिता CHAP, MS-CHAP, या EAP-MD5 भी भेज सकती है।
किसी भी अन्य चीज़ को बदलने से पहले बेसलाइन चलाएं
- एक टेस्ट अकाउंट परिभाषित करें। जहां सर्वर को मिले वहां एक ज्ञात यूज़रनेम और पासवर्ड रखें। आप ऐसा क्रेडेंशियल चाहते हैं जिसे आप बिना डायरेक्टरी में खोजे टाइप कर सकें।
- क्लाइंट की सूची बनाएं। जिस होस्ट या NAS से आप भेजते हैं, वह
clients.confमें उस सीक्रेट के साथ होना चाहिए जिसे आप टाइप करेंगे। एक अज्ञात स्रोत, एक खराब पासवर्ड से अलग विफलता है। - सर्वर को डिबग मोड में शुरू करें। हर पैकेट और अस्वीकृति का कारण टर्मिनल पर प्रिंट होना चाहिए। एक मूक विफलता रन को बेकार कर देती है।
- पाँच इनपुट भेजें। यूज़रनेम, पासवर्ड, सर्वर, NAS-Port, सीक्रेट।
0का एक NAS-Port इस पहले प्रमाण के लिए पर्याप्त है। - कोड पढ़ें, फिर कारण। Access-Accept का अर्थ है कि सर्वर ने उन क्रेडेंशियल्स को स्वीकृत कर दिया है। Access-Reject का अर्थ है कि इसने उन्हें अस्वीकार कर दिया है। डिबग आउटपुट एक गलत शेयर किए गए सीक्रेट, एक अज्ञात क्लाइंट, अमान्य क्रेडेंशियल और एक पॉलिसी विफलता को अलग करता है।
- NAS से दोहराएं। केवल localhost से ही नहीं, बल्कि एक्सेस पॉइंट या स्विच एड्रेस से भी उसी अनुरोध को प्राप्त करें। क्लाइंट आमतौर पर स्रोत एड्रेस और शेयर किए गए सीक्रेट द्वारा एक साथ अधिकृत होते हैं।
पहुंच क्षमता (Reachability) अंतिम परिणाम नहीं है। पैकेट पहुंचना चाहिए, और प्राधिकरण का निर्णय वही होना चाहिए जिसकी आपने उम्मीद की थी। स्वीकृति मिलने पर, लौटाए गए एट्रिब्यूट्स का निरीक्षण करें जैसे कि VLAN, सेवा प्रकार, या फ़्रेम्ड पता। गलत VLAN का नाम बताने वाली स्वीकृति को सफलता नहीं माना जाता है, भले ही कोड साफ़ दिखाई दे।
उस मूल स्वीकार के बाद, वही मैनुअल आठ तरीकों की सूची देता है जो उदाहरण खाते के लिए काम कर सकते हैं: PAP, CHAP, MS-CHAPv1, MS-CHAPv2, PEAP, EAP-TTLS, EAP-GTC, और EAP-MD5। आज ही आठों के पीछे न भागें।
व्यवहारिक नियम: वास्तविक NAS पते से एक Access-Accept और एक गलत पासवर्ड से एक Access-Reject सहेजें। वे दो नोट्स वह आधार रेखा हैं जिसके आधार पर बाद के हर मामले का न्याय किया जाता है।
Access-Accept नेटवर्क एक्सेस को साबित क्यों नहीं करता है
हरा इन्फ्रास्ट्रक्चर टेस्ट एक गलत पास (false pass) है, जिसे मैं साइन ऑफ नहीं करूंगा। यह अक्सर केवल यही दिखाता है कि किसी अनुरोध को कोई उत्तर मिला है।
Meraki RADIUS ट्रबलशूटिंग गाइड में कहा गया है कि इसका डैशबोर्ड परीक्षण PEAP के साथ MS-CHAPv2 का उपयोग करता है। वह परीक्षण EAP-TLS के लिए विफल हो जाता है, या कोई सार्थक सत्यापन नहीं देता है, क्योंकि एक्सेस पॉइंट के पास कोई क्लाइंट प्रमाण पत्र नहीं है। प्रमाणपत्र वायरलेस का परीक्षण एक वास्तविक सप्लिकेंट के साथ किया जाना है जिसमें सही प्रमाणपत्र और विश्वास श्रृंखला है।
चार परतें, चार अलग-अलग प्रश्न
ट्रांसपोर्ट पूछता है कि क्या किसी ने उत्तर दिया। टाइमआउट का अर्थ रिजेक्ट होना नहीं है।
ऑथेंटिकेशन यह पूछता है कि क्या पासवर्ड या सर्टिफिकेट उस पहचान के लिए मान्य था।
ऑथराइजेशन यह पूछता है कि क्या उत्तर में वही VLAN, रोल, या ACL शामिल था जिसे आप भेजना चाहते थे।
पहुंच क्षमता (Reachability) पूछती है कि क्या एंडपॉइंट को अपेक्षित पता, DNS नीति, और उन संसाधनों तक पहुंच मिली जो उस सेगमेंट को अनुमति देनी चाहिए।
एक स्तर पर सफलता का मतलब अन्य तीन स्तरों के बारे में कुछ भी साबित होना नहीं है। FreeRADIUS EAP व्यवहार के साथ पढ़े जाने वाले समान Meraki दिशानिर्देश, एक सफल EAP-TLS परीक्षण को मल्टी-पैकेट Access-Request और Access-Challenge एक्सचेंज, और फिर वास्तविक क्लाइंट नेटवर्क एक्सेस के रूप में वर्णित करते हैं। एक सिंगल कनेक्टिविटी प्रोब वह परीक्षण नहीं है।
सप्लिकेंट जिस सर्वर नाम पर भरोसा करता है, CA चेन, सर्टिफिकेट की समाप्ति और डिवाइस क्लॉक की जांच करें। क्लॉक का अंतर एक अच्छे सर्टिफिकेट को भी विफल कर देता है। मान लीजिए कि स्टाफ का एक लैपटॉप ऑथेंटिकेट होता है और फिर स्टाफ सेगमेंट के बजाय डिफ़ॉल्ट VLAN पर रहता है। Accept वास्तविक था। नेटवर्क प्लेसमेंट गलत था। यह वह चूक है जिसे अधिकांश चेकलिस्ट कभी रिकॉर्ड नहीं करती हैं।
पासवर्ड उपयोगकर्ताओं, EAP-TLS डिवाइसों, xPSK पहचानों, और डायरेक्टरी-संचालित नीति के लिए अलग पंक्तियाँ रखें। PAP स्वीकार को प्रमाणपत्र जॉइन के विकल्प के रूप में इस्तेमाल नहीं किया जाना चाहिए।
किसी स्पेयर डिवाइस पर EAP-TLSProve करें
- उसी CA से एक टेस्ट क्लाइंट सर्टिफिकेट जारी करें जिस पर सर्वर भरोसा करता है।
- एक स्पेयर लैपटॉप या फोन पर सर्टिफिकेट और CA चेन इंस्टॉल करें।
- पुष्टि करें कि सप्लिकेंट आपके द्वारा कॉन्फ़िगर किए गए सर्वर नाम को सत्यापित करता है।
- कनेक्ट करें और चैलेंज एक्सचेंज को कैप्चर करें, न कि केवल एक-पैकेट प्रोब को।
- पुष्टि करें कि सेशन वास्तविक नेटवर्क एक्सेस के साथ अपेक्षित VLAN पर समाप्त होता है।
उस एक्सचेंज का एक छोटा दृश्य कैप्चर को पहचानना आसान बनाता है जब आपका खुद का ट्रेस शोर से भरा (noisy) हो।
प्रत्येक RADIUS डिप्लॉयमेंट के लिए आवश्यक टेस्ट केसेस
उपयोगकर्ता के गलत नेटवर्क पर आने के बाद भी एक वैध क्रेडेंशियल Access-Accept जनरेट कर सकता है। प्रत्येक लेयर का अलग से परीक्षण करें: रिक्वेस्ट हैंडलिंग, प्रमाणीकरण, प्राधिकरण एट्रिब्यूट और एंडपॉइंट की वास्तविक पहुंच। FreeRADIUS परफॉरमेंस टेस्टिंग गाइड में लोड के साथ-साथ सटीकता भी शामिल है। इसमें नकारात्मक मामलों को भी शामिल करें: अमान्य क्रेडेंशियल को Access-Reject वापस करना चाहिए, जबकि विकृत अनुरोध, एक अज्ञात NAS और एक गलत साझा रहस्य से एक सफल लॉगिन जनरेट नहीं होना चाहिए।
radtest वर्कफ़्लो लंबे समय से स्थापित है और अभी भी उन्हीं पांच इनपुट का उपयोग करता है। टनेल्ड विधियों के लिए, इनर ऑथेंटिकेशन सर्वर का UDP पोर्ट 18120 पर अलग से परीक्षण करें। जब PEAP आउटर विधि हो, तो MS-CHAP इनर टेस्ट का उपयोग करें। इससे यह अलग करने में मदद मिलती है कि विफलता आउटर EAP एक्सचेंज में है, सर्टिफिकेट या TLS सेटअप में है, या इनर क्रेडेंशियल चेक में है।
एक Access-Accept सत्यापित करने की एक परिकल्पना है, न कि सही नेटवर्क एक्सेस का प्रमाण। FreeRADIUS कार्यान्वयन गाइड वर्णन करता है कि एक NAS कैसे असमर्थित VLAN विशेषता को हटा सकता है या किसी लापता विशेषता को डिफ़ॉल्ट VLAN में मैप कर सकता है। लौटाई गई विशेषताओं की जांच करें, फिर एंडपॉइंट के पते, VLAN, ACL, DNS नीति और पहुंच क्षमता की पुष्टि करें। EAP-MD5 वह की (key) सामग्री प्रदान नहीं करता है जिसकी वायरलेस को आवश्यकता होती है, इसलिए EAP-MD5 स्वीकृति वायरलेस तत्परता का प्रमाण नहीं है। इसका उपयोग केवल सीमित वायर्ड परीक्षण के लिए करें।
ऑथराइजेशन परीक्षण चलाने से पहले इच्छित सेगमेंट तय करें; WiFi एक्सेस कंट्रोल बताता है कि उस नीति को कैसे संरचित किया जाए।
नौ पंक्तियाँ जिन्हें न्यूनतम माना जाता है
| टेस्ट केस | इसे कैसे चलाएं | अपेक्षित परिणाम |
|---|---|---|
| बेसलाइन स्वीकार करें | NAS IP से मान्य टेस्ट अकाउंट के साथ radtest चलाएं |
अपेक्षित VLAN एट्रिब्यूट के साथ Access-Accept; पुष्टि करें कि एंडपॉइंट उसी VLAN पर पहुंचता है |
| गलत पासवर्ड | गलत पासवर्ड के साथ radtest चलाएं |
दर्ज किए गए कारण के साथ Access-Reject |
| गलत शेयर किया गया सीक्रेट | बेमेल सीक्रेट के साथ कॉन्फ़िगर किए गए क्लाइंट से भेजें | कोई Access-Accept नहीं; डिबग आउटपुट में सीक्रेट त्रुटि दिखाई दे रही है |
| अज्ञात NAS | क्लाइंट के रूप में परिभाषित न किए गए IP एड्रेस से भेजें | ड्रॉप या रिजेक्ट किया गया और लॉग किया गया |
| मान्य EAP-TLS डिवाइस | मान्य सर्टिफिकेट और विश्वसनीय चेन के साथ एक वास्तविक सप्लीकेंट कनेक्ट करें | Access-Accept और इसके समूह के लिए सही VLAN; डिवाइस से नेटवर्क एक्सेस की पुष्टि करें |
| समाप्त या रद्द किया गया सर्टिफिकेट | समाप्त या रद्द किए गए सर्टिफिकेट वाले डिवाइस को कनेक्ट करें | Access-Reject, डिफ़ॉल्ट नेटवर्क पर कोई फॉलबैक नहीं के साथ |
| डायरेक्टरी समूह में बदलाव | टेस्ट यूज़र को दूसरे ग्रुप में ले जाएं, फिर से प्रमाणित करें | नया ग्रुप से मेल खाने के लिए VLAN या भूमिका बदल जाती है, या एक्सेस से इनकार कर दिया जाता है |
| प्राथमिक सर्वर उपलब्ध नहीं है | प्राइमरी के लिए UDP 1812 ब्लॉक करें या इसे रोकें | समान पॉलिसी लागू होने के साथ, टाइमआउट के भीतर सेकेंडरी पर फेलओवर |
| अकाउंटिंग शुरू और बंद करें | एक सेशन शुरू करें, फिर उसे समाप्त करें | स्टार्ट और स्टॉप रिकॉर्ड सेशन से मेल खाते हैं |
प्रत्येक पंक्ति के लिए, अनुरोध आगमन, प्रतिक्रिया कोड, राउंड-ट्रिप लेटेंसी, चयनित नीति, लौटाए गए गुण, और एकाउंटिंग स्टार्ट एवं स्टॉप को रिकॉर्ड करें। रुक-रुक कर होने वाले UDP नुकसान को पकड़ने के लिए प्रत्येक परीक्षण को दोहराएं। एक एकल क्लीन रन से गलत VLAN या असंगत नीति निर्णय छूट सकता है।
एक स्वीकृति जो क्लाइंट को गलत नेटवर्क पर रखती है, वह एक विफल परीक्षण है।
radclient के साथ लोड और लेटेंसी मापें
एक शांत स्वीकृति (quiet accept) कतारबद्धता (queueing) को छिपाती है। वॉल्यूम टेस्टिंग के लिए एक ऐसे टूल की आवश्यकता होती है जो बैच के लिए बनाया गया हो, न कि किसी अन्य सिंगल लॉगिन के लिए।
- रैंडम यूज़रनेम और पासवर्ड की एक प्रमाणीकरण फ़ाइल बनाएं। मान्य और अमान्य प्रविष्टियों को मिलाएं ताकि अस्वीकृतियों की गिनती की जा सके, उन्हें शोर न माना जाए।
- फ़ाइल भेजें और बैच का समय मापें Unix
timeकमांड के साथ, जबकिradclientसर्वर चलाता है। - रॉ काउंट रिकॉर्ड करें। कुल अनुरोध, स्वीकृतियां, अस्वीकृतियां, टाइमआउट, त्रुटि प्रतिक्रियाएं और बीता हुआ समय।
- दरों की गणना करें। स्वीकृति दर फ़ाइल के मान्य हिस्से से मेल खानी चाहिए। अस्वीकृति दर अमान्य हिस्से से मेल खानी चाहिए। साथ ही औसत और पर्सेंटाइल लेटेंसी भी लें।
- व्यस्त समय पर दोहराएं। सुबह का चेक-इन या स्कूल की शुरुआत क्यूइंग दिखाएगी जो दोपहर के भोजन के समय का लैब रन कभी नहीं दिखाएगा।
| मैट्रिक | इसकी गणना कैसे करें | लक्ष्य |
|---|---|---|
| कुल अनुरोध | प्रामाणिक फ़ाइल से भेजी गई पंक्तियों की संख्या | फ़ाइल की लंबाई के बराबर |
| स्वीकृति दर | कुल अनुरोधों से विभाजित स्वीकृतियां | फ़ाइल के मान्य हिस्से से मेल खाता है |
| अस्वीकृति दर | कुल अनुरोधों से विभाजित अस्वीकृतियां | फ़ाइल के अमान्य हिस्से से मेल खाता है |
| टाइमआउट और त्रुटियां | रन में बिना उत्तर और त्रुटि वाली प्रतिक्रियाओं की संख्या | क्लीन पाथ पर शून्य |
| औसत लेटेंसी | सभी अनुरोधों में औसत प्रतिक्रिया समय | पीक के समय आपके लेटेंसी लक्ष्य के भीतर |
| बीता हुआ समय | पूरे बैच के लिए Unix समय आउटपुट | दोहराए जाने वाले रन में स्थिर |
टनल को अकाउंट स्टोर से अलग करें
यदि स्वीकृति दर मान्य शेयर से कम है, तो जब तक आपको यह पता न चल जाए कि कौन सा आधा हिस्सा विफल हुआ है, तब तक "लोड" को दोष न दें। PEAP के लिए, इनर सर्वर के विरुद्ध MS-CHAP अनुरोध के साथ इनर मेथड का अलग से परीक्षण करें। टूटे हुए आउटर जॉइन के साथ एक इनर एक्सेप्ट, सर्टिफिकेट या TLS सेटिंग्स की ओर इशारा करता है। इनर चेक पर समाप्त होने वाला एक आउटर हैंडशेक अकाउंट स्टोर, पासवर्ड हैश, या उस समूह की ओर इशारा करता है जिसकी पॉलिसी अपेक्षा करती है।
इन समयों को कार्यात्मक परिणामों वाले समान लॉग में रखें। बाद के फ़र्मवेयर या निर्देशिका परिवर्तन की तुलना उस आधार रेखा से की जानी चाहिए, न कि इस भावना से कि "यह धीमा लगा था।"
यदि टाइमआउट केवल पीक समय पर बढ़ता है, तो साइट जोड़ने से पहले क्षमता या पाथ को ठीक करें। जो सर्वर सही है और धीमा है, वह फिर भी उन क्लाइंट्स को विफल कर देगा जो पहले हार मान लेते हैं।
विफलता के रास्ते, फेलओवर और सुरक्षा जांच
एक काम करता हुआ एक्सचेंज भी असुरक्षित हो सकता है। ट्रबलशूटिंग जो केवल यह पूछती है कि UDP 1812 को कोई उत्तर मिला या नहीं, बहुत जल्दी रुक जाती है।
Juniper का 2025 सुरक्षा बुलेटिन RFC 2865 रिस्पॉन्स ऑथेंटिकेटर में Blast-RADIUS एक्सपोजर का वर्णन करता है। एक स्थानीय हमलावर जो ट्रैफ़िक को संशोधित कर सकता है, वह संभावित रूप से एक MD5 चुने हुए-उपसर्ग टकराव के माध्यम से एक वैध प्रतिक्रिया को दूसरी प्रतिक्रिया में बदल सकता है। "प्रमाणीकरण सफल रहा" इस बात का प्रमाण नहीं है कि परिनियोजन सुरक्षित है।
जांच जो फेलओवर के समान रन में शामिल हैं
जहां प्लेटफॉर्म इसकी अनुमति देता है वहां पाथ को सुरक्षित रखें। पुष्टि करें कि ऑन-पाथ हेरफेर अवरुद्ध है, और यह कि जिन पैकेटों को आवश्यकता है उन पर Message-Authenticator सत्यापन लागू किया गया है।
कमजोर तरीकों को बंद करें। अप्रचलित EAP प्रकारों को अक्षम कर दिया जाना चाहिए, न कि "बस मामले के लिए" छोड़ दिया जाना चाहिए। यदि आप अभी भी प्रमाणपत्र और पासवर्ड के बाहरी तरीकों के बीच चयन कर रहे हैं, तो दोनों को सक्षम छोड़ने से पहले EAP-TLS बनाम PEAP में उनकी तुलना करें।
जानबूझकर सर्वर को विफल करें। नीचे दिए गए प्रत्येक परिदृश्य में इच्छित फेल-क्लोज्ड या नियंत्रित फ़ॉलबैक, साथ ही एक लॉग लाइन, एक अलर्ट, और एक उपयोगकर्ता अनुभव दिखना चाहिए जिसे आप साइट मैनेजर को समझा सकें।
| विफलता का परिदृश्य | इसे ट्रिगर कैसे करें | पास स्थिति |
|---|---|---|
| टाइमआउट | सर्वर के लिए UDP 1812 ब्लॉक करें | फेल क्लोज्ड या नियंत्रित फॉलबैक, लॉग और अलर्ट किया गया |
| Access-Reject | गलत पासवर्ड का उपयोग करें | बिना किसी फॉलबैक नेटवर्क के पहुंच अस्वीकृत |
| समाप्त प्रमाणपत्र (Expired certificate) | समाप्त प्रमाणपत्र वाला डिवाइस | बिना किसी डिफ़ॉल्ट VLAN के Access-Reject |
| रद्द प्रमाणपत्र (Revoked certificate) | रद्द प्रमाणपत्र वाला डिवाइस | बिना किसी डिफ़ॉल्ट VLAN के Access-Reject |
| अज्ञात NAS स्रोत IP | अपरिभाषित पते से भेजें | ड्रॉप या अस्वीकार और लॉग किया गया |
| गलत शेयर किया गया सीक्रेट | क्लाइंट पर बेमेल सीक्रेट | डिबग आउटपुट में कोई Access-Accept नहीं और सीक्रेट त्रुटि |
| अनुपलब्ध निर्देशिका (Unreachable directory) | निर्देशिका कनेक्टिविटी रोकें | नीति के अनुसार अस्वीकृत या नियंत्रित फॉलबैक |
| विलंबित प्राधिकरण प्रतिक्रिया | प्राधिकरण उत्तर में विलंब जोड़ें | ओपन एक्सेस के बिना संभाला गया टाइमआउट |
क्षेत्रीय फेलओवर को क्या सुरक्षित रखना है
किसी अन्य सर्वर का उत्तर देना नीति की निरंतरता नहीं है। जब आप प्राथमिक सर्वर को रोकते हैं, तो बैकअप से VLAN, बैंडविड्थ सीमाएं, रद्दीकरण स्थिति, और ऑडिट एट्रिब्यूट्स की प्राथमिक सर्वर से तुलना करें। यदि कोई मेहमान फ़ेलओवर होकर कर्मचारी वर्ग में आ जाता है, तो यह एक विफल परीक्षण है, भले ही जुड़ाव तेज़ था।
ओपन एक्सेस पर फ़ॉलबैक होने वाले किसी भी परिदृश्य को विफल के रूप में चिह्नित करें, चाहे उपयोगकर्ता ऑनलाइन हो या न हो। प्रत्येक परिणाम को कार्यात्मक आधार रेखा के समान परीक्षण लॉग में लिखें ताकि बाद का फेलओवर परिवर्तन स्पष्ट हो।
प्रत्येक परीक्षण परिणाम की पुष्टि करने के लिए लॉग पढ़ें
प्रत्येक परीक्षण में एक निशान छोड़ना चाहिए जिसे आप परीक्षण ID या किसी ज्ञात खाते से मिला सकें। एक व्यस्त संपत्ति पर, वही लेबल आपको बाकी सभी की सुबह को स्क्रॉल किए बिना अपना रन खोजने में मदद करता है।
प्रत्येक ऑथेंटिकेशन के लिए, इन फ़ील्ड्स को पंक्तिबद्ध करें:
- पहचान और डिवाइस: किसने या किस डिवाइस ने जॉइन किया है, केवल वह MAC एड्रेस नहीं जिसे आप अपना मान रहे हैं।
- विधि: EAP-TLS, PEAP, या कोई व्यक्तिगत PSK। ऐसी विधि जिसे आपने तैनात नहीं किया है, वह एक फाइंडिंग है।
- स्थान: एक्सेस पॉइंट, SSID, और साइट।
- निर्णय: VLAN और लौटाई गई भूमिका, या अस्वीकृति का कारण।
- समय: वह टाइमस्टैम्प जो आपके द्वारा टेस्ट की गई विंडो के भीतर स्थित है।
हमारा प्रमाणीकरण लॉग उसी मिलान के लिए बनाया गया है। संपूर्ण एस्टेट से जुड़ी एक ही क्वेरी पहचान, डिवाइस, नामांकन स्थिति, विधि, एक्सेस पॉइंट, SSID, साइट, VLAN, भूमिका, कारण और टाइमस्टैम्प के साथ प्रत्येक स्वीकृति और अस्वीकृति को दर्शाती है। इसका उपयोग तब करें जब किसी साइट पर कई एक्सेस पॉइंट हों और आपको यह देखने की आवश्यकता हो कि क्या वही विफलता हर जगह है या केवल एक कंट्रोलर पर है।
तीन पैटर्न जिनका अर्थ है कि नोट्स गलत हैं
कारण परीक्षण से मेल नहीं खाता है। आपने एक गलत पासवर्ड भेजा और लॉग कहता है अज्ञात क्लाइंट। आपने गलत चीज़ का परीक्षण किया, या दो त्रुटियां एक साथ आ गईं।
स्वीकृति डिफॉल्ट VLAN का नाम बताती है। क्रेडेंशियल्स ने काम किया। प्लेसमेंट ने काम नहीं किया। केस बंद न करें।
लेखांकन शुरू हुआ और कभी रुका नहीं। सत्र रिकॉर्ड अधूरा है, इसलिए आप यह साबित नहीं कर सकते कि क्लाइंट ने आपके सोचने पर ही नेटवर्क छोड़ दिया। आपके द्वारा चलाए गए सत्र से प्रारंभ और समाप्ति की तुलना करें, न कि पास के किसी उपयोगकर्ता के सत्र से।
परीक्षण विंडो के दौरान रिजेक्ट स्पाइक्स के लिए एक अलर्ट सेट करें ताकि एक खराब साझा सीक्रेट ऐसा न लगे कि "उपयोगकर्ताओं ने गलत टाइप किया है।" परीक्षण नोट्स के साथ लॉग एक्सट्रैक्ट रखें। जब कोई हफ्तों बाद पूछे कि आपने क्या साबित किया था, तो वह एक्सट्रैक्ट ही ऑडिट साक्ष्य होता है।
तय करें कि RADIUS रोलआउट के लिए कब तैयार है
लाइव केवल तभी जाएं जब प्रमाण पांच शर्तों को पूरा करते हों। एक आश्वस्त इंजीनियर उनमें से एक नहीं है।
- प्रत्येक मैट्रिक्स पंक्ति आपके द्वारा तैनात प्रत्येक NAS प्रकार पर पास होती है, जिसमें प्रत्येक SSID या एक्सेस नीति शामिल है जिसे आप बनाए रखना चाहते हैं।
- फेलओवर प्राथमिक सर्वर के समान VLAN, नीति और निरसन व्यवहार बनाए रखता है। एक दूसरा सर्वर जो भिन्न भूमिका के साथ उत्तर देता है, वह इस गेट में विफल हो जाता है।
- कोई भी विफलता परिदृश्य खुला नहीं रहता है। गलत पासवर्ड, निष्क्रिय निर्देशिका, समाप्त हो चुका प्रमाणपत्र और विलंबित प्रतिक्रिया के कारण यूज़र को अप्रतिबंधित नेटवर्क पर नहीं जाना चाहिए।
- लोड पीक पर आपके लेटेंसी लक्ष्य के भीतर रहता है, जिसमें स्वीकृति दर परीक्षण फ़ाइल के मान्य हिस्से से मेल खाती है।
- लॉग हर उस रन के लिए अपेक्षित कारण और VLAN दिखाते हैं जिसे आप पास का दावा करते हैं।
व्यापक रोलआउट को तब तक रोकें जब तक कि वे पांचों किसी वास्तविक साइट पर सही साबित न हो जाएं, केवल लैब VLAN में ही नहीं।
हम आपको सबसे पहले एक साइट पर इसे साबित करने की अनुमति देते हैं। नए ओपन, सुरक्षित और xPSK नेटवर्क को उन एक्सेस पॉइंट्स पर रखें जिन्हें वह साइट पहले से चला रही है, उस नेटवर्क के बगल में जिसका वह आज उपयोग करती है, और किसी भी अन्य साइट के परिवर्तनों से पहले टिकटों और ऑडिट साक्ष्यों पर परिणाम का न्याय करें। उस पायलट के दौरान, लॉग को बिना किसी बैठक के दो प्रश्नों के उत्तर देने चाहिए। किन डिवाइसों ने किस VLAN पर जॉइन किया, और कौन सा एक्सेप्ट या रिजेक्ट कारण सबसे अधिक बार दिखाई दिया।
केवल तभी विस्तार करें जब टिक्ट और ऑडिट एक्स्ट्रेक्ट में कोई अप्रत्याशित अस्वीकृति और गलत सेगमेंट पर कोई डिवाइस न दिखाई दे। मैट्रिक्स को एक स्थायी रिग्रेशन सूट के रूप में रखें। उपयोगकर्ताओं द्वारा बदलाव देखने से पहले, एक ही बेसलाइन के विरुद्ध प्रत्येक प्रमाण पत्र नवीनीकरण, फर्मवेयर अपडेट या निर्देशिका परिवर्तन के बाद इसे फिर से चलाएं। उस पायलट साइट को कैसे तैयार किया जाना चाहिए, इसके लिए WiFi नेटवर्क डिज़ाइन से शुरू करें और उस डिज़ाइन का परीक्षण करें जिसे आप रखना चाहते हैं, न कि उस अस्थायी SSID का जिसे आप अगले सप्ताह हटा देंगे।
Purple Access आपको क्लाउड RADIUS प्रदान करता है जो प्रत्येक डिवाइस को पहचान के आधार पर ओपन, सुरक्षित या xPSK नेटवर्क पर रखता है, जिसमें प्रमाणिकरण लॉग में VLAN और अस्वीकृति का कारण दिखाई देता है। यदि आप उस टेस्ट प्लान को अपने मौजूदा एक्सेस पॉइंट्स पर चलाना चाहते हैं, तो एक साइट से शुरुआत करें और आगे बढ़ने से पहले परिणाम देखें। Purple Access पर जाएं और पहली साइट को एक ऐसे बेसलाइन पर रखें जिसका आप बचाव कर सकें।
