मल्टी-साइट RADIUS माइग्रेशन: साइट्स, एक्सेस पॉइंट्स और पॉलिसी का सीक्वेंसिंग

आप पुरानी और नई सर्वर को एक साथ चलाकर बिना किसी फ्लैग डे के चार चरणों में मल्टी-साइट एस्टेट को क्लाउड RADIUS पर ले जा सकते हैं। प्रत्येक SSID दोनों को सूचीबद्ध करता है, और प्रत्येक डिवाइस नए सर्वर प्रमाणपत्र पर भरोसा करता है। प्रत्येक साइट लिखित एग्जिट टेस्ट के साथ IEEE 802.1X के तहत कटओवर करती है। Purple पर, कटओवर खुद आमतौर पर सप्ताहांत का काम होता है।

मल्टी-साइट RADIUS माइग्रेशन में क्या बदलता है, और क्या वैसा ही रहता है?

अंतिम स्थिति हर साइट को सेवा देने वाली एक क्लाउड RADIUS नीति है, जिसमें पहचान VLAN सेट करती है। RADIUS, जिसे RFC 2865 में परिभाषित किया गया है, वह प्रोटोकॉल है जिसका उपयोग आपके एक्सेस पॉइंट सर्वर से यह पूछने के लिए करते हैं कि क्या कोई डिवाइस कनेक्ट हो सकता है। सर्वर डिवाइस को स्वीकार या अस्वीकार करता है। यह VLAN जैसे एट्रिब्यूट भी वापस लौटा सकता है, वह नेटवर्क सेगमेंट जिस पर डिवाइस लैंड करता है।

एक सुरक्षित नेटवर्क पर, वह एक्सचेंज IEEE 802.1X के अंदर चलता है, जो पोर्ट आधारित नेटवर्क एक्सेस कंट्रोल का मानक है। 802.1X डिवाइस, एक्सेस पॉइंट और सर्वर के बीच EAP (एक्सटेंसिबल ऑथेंटिकेशन प्रोटोकॉल) ले जाता है। EAP-TLS, जिसे RFC 5216 में परिभाषित किया गया है, प्रमाणपत्रों के साथ दोनों पक्षों को प्रमाणित करता है। PEAP एक TLS टनल के अंदर पासवर्ड एक्सचेंज को लपेटता है।

चार चीजें बदलती हैं:

• प्रत्येक एक्सेस पॉइंट या कंट्रोलर एक नए सर्वर एड्रेस और शेयर की गई गुप्त कुंजी (shared secret) की ओर इशारा करता है। RADIUS उस डिवाइस को NAS (नेटवर्क एक्सेस सर्वर) कहता है।
• EAP हैंडशेक के दौरान डिवाइस एक नया सर्वर प्रमाणपत्र देखते हैं।
• नीति स्थानीय निर्देशिका के बजाय Microsoft Entra ID, Okta या Google Workspace से समूहों को पढ़ती है।
• लॉग एक नए कंसोल पर चले जाते हैं।

जो चीजें समान रहती हैं वे अधिक महत्वपूर्ण हैं। आप अपने एक्सेस पॉइंट, SSID नाम, VLAN ID, स्विच ट्रंक और फ़ायरवॉल ज़ोन रखते हैं। कोई भी पासवर्ड नहीं बदलता है या नए नेटवर्क से नहीं जुड़ता है।

यही दृष्टिकोण Purple Access के तीनों नेटवर्क पर लागू होता है। खुले नेटवर्क पर, कई Captive Portal, RADIUS के माध्यम से डिवाइस को अधिकृत करते हैं। सुरक्षित नेटवर्क EAP-TLS या PEAP का उपयोग करते हैं। xPSK नेटवर्क पर, RADIUS प्रत्येक डिवाइस या निवासी को उसकी अपनी प्री-शेयर्ड कुंजी देता है। यह गाइड सुरक्षित नेटवर्क का पालन करती है, क्योंकि इसमें सबसे अधिक जोखिम होता है।

{"tone":"warning","title":"नुकसान पहुँचाने वाला जोखिम: सर्वर प्रमाणपत्र ट्रस्ट","text":"EAP-TLS या PEAP पर डिवाइस RADIUS सर्वर प्रमाणपत्र की जांच करते हैं, और कई केवल पुराने सर्वर के सर्टिफिकेट अथॉरिटी पर भरोसा करते हैं। पहली साइट के स्थानांतरित होने से पहले हर डिवाइस प्रोफ़ाइल में नया CA पुश करें, अन्यथा वे डिवाइस कनेक्ट होने में विफल हो जाएंगे और बार-बार प्रयास करते रहेंगे।"}

एक बार जब आप प्रमाणपत्र ट्रस्ट से निपट लेते हैं, तो बाकी माइग्रेशन कॉन्फ़िगरेशन कार्य और होल्डिंग अवधि का होता है।

चरण 1 से पहले क्या सत्य होना चाहिए?

कोई भी नीति बनाए जाने से पहले पांच शर्तें पूरी होनी चाहिए। यदि एक भी गायब है, तो यह बाद के चरण में समस्याएं पैदा करेगी।

एक पूर्ण NAS इन्वेंट्री

पुराने सर्वर को अनुरोध भेजने वाले प्रत्येक डिवाइस की सूची बनाएं। इसमें एक्सेस पॉइंट, वायरलेस कंट्रोलर, वायर्ड 802.1X करने वाले स्विच और VPN गेटवे शामिल हैं। यह सूची नेटवर्क आरेख से नहीं, बल्कि पुराने सर्वर की RADIUS क्लाइंट सूची से बनाएं। यदि इन्वेंट्री में कोई NAS गायब है, तो आप चरण 4 में पुराने सर्वर को बंद नहीं कर सकते हैं।

एक नीति मानचित्र (पॉलिसी मैप), पंक्ति दर पंक्ति

पुराना सर्वर लागू होने वाले प्रत्येक नियम को उसकी स्थिति, उसके परिणाम और उसके द्वारा लौटाए जाने वाले एट्रिब्यूट के साथ लिखें। विशिष्ट पंक्तियाँ इस प्रकार दिखती हैं: स्टाफ ग्रुप से स्टाफ VLAN, ठेकेदारों से प्रतिबंधित VLAN, सर्टिफिकेट द्वारा कॉर्पोरेट लैपटॉप से कॉर्पोरेट VLAN। ध्यान दें कि कौन से एट्रिब्यूट VLAN को ले जाते हैं। RFC 3580 मानक सेट को परिभाषित करता है: टनल-टाइप, टनल-मीडियम-टाइप और टनल-प्राइवेट-ग्रुप-ID। कुछ संपत्तियां इसके बजाय विक्रेता-विशिष्ट एट्रिब्यूट का उपयोग करती हैं, और आपको उन्हें सटीक रूप से मिरर करना होगा।

एक सर्टिफिकेट योजना

तय करें कि कौन सा सर्टिफिकेट अथॉरिटी (CA) नया सर्वर सर्टिफिकेट जारी करता है। प्रबंधित डिवाइसों पर, किसी भी साइट को स्थानांतरित करने से पहले Microsoft Intune, Jamf या अपने मोबाइल डिवाइस प्रबंधन (MDM) प्लेटफॉर्म के माध्यम से उस CA को पुश करें। EAP-TLS के लिए, नए सर्वर को उस CA पर भी भरोसा करना होगा जिसने आपके डिवाइस सर्टिफिकेट जारी किए हैं।

एक पहचान स्रोत जिसे नया सर्वर पढ़ सकता है

अपने पहचान प्रदाता को कनेक्ट करें और पुष्टि करें कि नीति मानचित्र में प्रत्येक समूह वहां मौजूद है। यदि कोई समूह केवल पुराने सर्वर पर मौजूद है, तो पहले इसे पहचान प्रदाता में फिर से बनाएं।

पहुंच क्षमता (Reachability), मालिक और बदलाव की समय-सीमा (change windows)

प्रत्येक साइट को Purple के ऑनबोर्डिंग दस्तावेज़ीकरण में दिए गए पतों और पोर्ट का उपयोग करके क्लाउड सर्वर के लिए एक नेटवर्क पथ की आवश्यकता होती है। प्रत्येक साइट के लिए एक मालिक का नाम तय करें और साइट प्रबंधकों के साथ बदलाव की समय-सीमा पर सहमति व्यक्त करें। किसी भी चीज़ को स्थानांतरित करने से पहले रोलबैक ट्रिगर लिखें।

{"title":"मल्टी-साइट RADIUS माइग्रेशन चेकलिस्ट","groups":[{"heading":"चरण 1 से पहले","items":[{"text":"पुराने सर्वर की RADIUS क्लाइंट सूची निर्यात करें और NAS इन्वेंट्री के साथ इसका मिलान करें","why":"एक भूला हुआ NAS डीकमीशनिंग को रोकता है"},{"text":"प्रत्येक नीति नियम को मैप करें: स्थिति, परिणाम और लौटाए गए गुण"},{"text":"पुष्टि करें कि प्रत्येक नीति समूह Microsoft Entra ID, Okta या Google Workspace में मौजूद है"},{"text":"अपने MDM के माध्यम से प्रबंधित उपकरणों पर नया सर्वर CA पुश करें"},{"text":"प्रत्येक साइट पर Purple के ऑनबोर्डिंग दस्तावेज़ों में दिए गए पथ खोलें"},{"text":"प्रति साइट एक मालिक और एक परिवर्तन विंडो का नाम दें, और लिखित रूप में रोलबैक ट्रिगर पर सहमति दें"}]},{"heading":"चरण 1: निर्माण","items":[{"text":"पुराने सर्वर पर नीति परिवर्तनों को फ़्रीज़ करें"},{"text":"नए सर्वर पर प्रत्येक नीति पंक्ति को फिर से बनाएं"},{"text":"दोनों सर्वरों के विरुद्ध प्रति पंक्ति एक पहचान का परीक्षण करें और उत्तरों का मिलान करें"}]},{"heading":"चरण 2 और 3: पायलट और तरंगें","items":[{"text":"कटओवर से पहले प्रति साइट एक बेसलाइन अस्वीकृति दर रिकॉर्ड करें"},{"text":"प्रत्येक SSID पर पुराने के साथ नया सर्वर जोड़ें"},{"text":"पुष्टि करें कि प्रत्येक उपकरण वर्ग नए सर्वर पर प्रमाणित होता है"},{"text":"अगली तरंग से पहले प्रत्येक तरंग को एक पूर्ण व्यावसायिक चक्र के लिए रोकें"}]},{"heading":"चरण 4: डीकमीशन","items":[{"text":"प्रत्येक SSID और NAS से पुराने सर्वर को हटाएं"},{"text":"सहमति योग्य शांत अवधि के लिए पुराने सर्वर पर शून्य अनुरोधों की पुष्टि करें"},{"text":"अपनी प्रतिधारण नीति के तहत पुराने सर्वर लॉग को निर्यात करें और बनाए रखें"},{"text":"पुराने सर्वर के साथ उपयोग किए गए साझा रहस्यों को सेवानिवृत्त करें"},{"text":"रनबुक को अपडेट करें और प्रत्येक साइट के एग्जिट-टेस्ट रिकॉर्ड को फाइल करें"}]}],"download":{"filename":"radius-migration-checklist.csv"}}

क्रम में 4 चरण क्या हैं?

योजना के चार चरण हैं। प्रत्येक एक एग्जिट टेस्ट के साथ समाप्त होता है जिसे आप पास या फेल कर सकते हैं। जब तक टेस्ट पास नहीं हो जाता, तब तक कुछ भी अगले चरण में नहीं जाता है, जिससे आप बिग-बैंग कटओवर से बचते हैं।

{"kind":"timeline","direction":"lr","caption":"एक उदाहरणात्मक 40-साइट एस्टेट: चार चरण, प्रत्येक एक निकास परीक्षण द्वारा समाप्त होता है","alt":"लगभग 12 हफ्तों में तैयारी, फिर चरण 1 निर्माण, चरण 2 पायलट, चरण 3 तरंगें और चरण 4 सेवामुक्त करने की समयरेखा दर्शाई गई है।","nodes":[{"id":"p0","label":"चरण 1 से पहले","sub":"इन्वेंट्री, नीति मानचित्र, CA पुश, पहचान स्रोत","tone":"neutral","when":"सप्ताह 1-2"},{"id":"p1","label":"चरण 1: निर्माण और मिरर","sub":"क्लाउड RADIUS पर नीति का पुनर्नर्माण, लैब उत्तर मेल खाते हैं","tone":"brand","when":"सप्ताह 3"},{"id":"p2","label":"चरण 2: पायलट साइट","sub":"एक साइट, पुराना सर्वर द्वितीयक के रूप में रखा गया","tone":"brand","when":"सप्ताह 4-5"},{"id":"p3","label":"चरण 3: तरंगें","sub":"पांच, फिर 10, फिर शेष 24 साइटें","tone":"brand","when":"सप्ताह 6-10"},{"id":"p4","label":"चरण 4: सेवामुक्त करना","sub":"पुराने सर्वर पर शून्य अनुरोध, फिर बंद करना","tone":"success","when":"सप्ताह 11-12"}],"edges":[{"from":"p0","to":"p1","label":"पूर्वापेक्षाएं पूरी हुईं"},{"from":"p1","to":"p2","label":"लैब उत्तर मेल खाते हैं"},{"from":"p2","to":"p3","label":"पायलट निकास परीक्षण"},{"from":"p3","to":"p4","label":"सभी साइटों को स्थानांतरित किया गया"}]}

{"caption":"मल्टी-साइट RADIUS माइग्रेशन के लिए चरण योजना","asOf":"2026-06-10","columns":[{"key":"phase","label":"चरण"},{"key":"scope","label":"दायरा"},{"key":"owner","label":"स्वामी"},{"key":"exit","label":"निकास परीक्षण"}],"rows":[["चरण 1 से पहले","NAS इन्वेंट्री, नीति मानचित्र, CA पुश, पहचान स्रोत, साइट पथ","पहचान और पहुंच लीड के साथ IT प्रबंधक","प्रत्येक NAS सूचीबद्ध, पहचान प्रदाता में प्रत्येक नीति समूह, प्रबंधित उपकरणों पर नया CA"],["चरण 1: निर्माण","क्लाउड RADIUS पर नीति का पुनर्नर्माण, कोई लाइव ट्रैफिक नहीं","पहचान और पहुंच लीड","प्रत्येक पंक्ति के लिए एक परीक्षण पहचान को पुराने और नए से समान उत्तर और VLAN मिलता है"],["चरण 2: पायलट","एक प्रतिनिधि साइट, नया सर्वर प्राथमिक, पुराना द्वितीयक","नेटवर्क आर्किटेक्ट","बिना किसी स्पष्टीकरण के खारिज किए गए अनुरोधों के बिना एक व्यावसायिक चक्र और नए सर्वर पर देखा गया प्रत्येक उपकरण वर्ग"],["चरण 3: तरंगें","बढ़ती तरंगों में शेष साइटें, कंसोल टेम्पलेट द्वारा समूहीकृत","साइट स्वामियों के साथ नेटवर्क आर्किटेक्ट","अगला शुरू होने से पहले प्रत्येक तरंग पायलट निकास परीक्षण पास करती है"],["चरण 4: सेवामुक्त करना","प्रत्येक SSID और NAS से पुराना सर्वर हटा दिया गया","IT प्रबंधक","शांत अवधि के लिए पुराने सर्वर पर शून्य अनुरोध, लॉग बनाए रखे गए, रहस्य सेवानिवृत्त किए गए"]],"footnote":"स्वामी भूमिकाएं हैं, नामित व्यक्ति नहीं। शांत अवधि को कम से कम एक पुनः प्रमाणीकरण चक्र और एक व्यावसायिक सप्ताह के लिए सेट करें।","download":{"filename":"radius-migration-phase-plan.csv"}}

प्रत्येक चरण के अंदर क्या होता है?

चरण 1: नीति का निर्माण और मिरर करें

किसी भी लाइव अनुरोध के पहुंचने से पहले नए सर्वर पर नीति मानचित्र का पुनर्नर्माण करें। पहचान प्रदाता को कनेक्ट करें, फिर उसकी स्थिति, परिणाम और लौटाए गए गुणों के साथ प्रत्येक पंक्ति को फिर से बनाएं। VLAN आईडी को समान रखें, ताकि स्विच और फ़ायरवॉल कॉन्फ़िगरेशन कभी न बदले।

लैब से हर पंक्ति (row) का परीक्षण करें। wpa_supplicant प्रोजेक्ट के एक टूल eapol_test का उपयोग करें। यह RADIUS सर्वर पर एक वास्तविक EAP एक्सचेंज भेजता है और उत्तर प्रिंट करता है। दोनों सर्वरों के विरुद्ध प्रति पंक्ति एक पहचान (identity) चलाएं और उत्तरों की तुलना करें। निकास परीक्षण (exit test) हर पंक्ति पर एक मिलान है, जिसमें समान स्वीकार या अस्वीकार और समान VLAN हो।

चरण 2: एक साइट का पायलट परीक्षण करें

ऐसी साइट चुनें जो पूरी संपत्ति का प्रतिनिधित्व करती हो, न कि सबसे आसान वाली। इसमें आपके द्वारा उपयोग की जाने वाली प्रत्येक डिवाइस श्रेणी शामिल होनी चाहिए, जिसमें कठिन डिवाइस भी शामिल हैं। हैंडहेल्ड स्कैनर, WiFi पर भुगतान टर्मिनल और पुराने लैपटॉप के बारे में सोचें। आपको साइट पर किसी ऐसे व्यक्ति की भी आवश्यकता है जो पूछे जाने पर किसी डिवाइस का परीक्षण कर सके।

पुराने सर्वर के साथ नया सर्वर जोड़ें, इसका परीक्षण करें, फिर नए सर्वर को प्राथमिक बनाएं। इसे एक पूरे व्यावसायिक चक्र के लिए छोड़ दें। किसी होटल के लिए, इसका मतलब है शिफ्ट पैटर्न का एक सप्ताह। एक कार्यालय के लिए, इसका मतलब है सोमवार-सुबह के लॉगिन का एक सप्ताह। पायलट परीक्षण तब सफल होता है जब दो बातें सच होती हैं। पहला, प्रत्येक डिवाइस श्रेणी ने नए सर्वर पर प्रमाणीकरण किया है। दूसरा, अस्वीकृति दर आपकी आधाररेखा से बदतर नहीं है।

चरण 3: संपत्ति को चरणों (waves) में स्थानांतरित करें

जैसे-जैसे पहले वाले चरण सफल होते जाएं, प्रत्येक अगले चरण को पिछले वाले से बड़ा बनाएं। 40-साइट वाली संपत्ति में पहले एक पायलट साइट, फिर पांच, फिर 10, और फिर शेष 24 स्थानांतरित हो सकती हैं। प्रत्येक चरण को कंसोल टेम्पलेट या समूह द्वारा समूहीकृत करें, ताकि एक बदलाव उसमें मौजूद हर साइट तक पहुंचे। Meraki कॉन्फ़िगरेशन टेम्पलेट, Juniper Mist WLAN टेम्पलेट और HPE Aruba Central समूह सभी इस दृष्टिकोण के अनुकूल हैं।

कटओवर तब करें जब साइट कर्मचारी मौजूद हों, तड़के 3 बजे नहीं। जिस बदलाव का सुबह तक कोई परीक्षण नहीं करता, वह ऐसा बदलाव है जिसका आपने परीक्षण नहीं किया है। एक ही समय सीमा में अन्य नेटवर्क परिवर्तनों को बंडल करने से बचें।

चरण 4: पुराने सर्वर को सेवामुक्त (decommission) करें

इन्वेंट्री में प्रत्येक SSID और प्रत्येक NAS से पुराना सर्वर हटाएं, फिर इसके लॉग देखें। अनुरोध शून्य पर आ जाने चाहिए। जो कुछ भी अभी भी आता है वह उस NAS से आता है जिसे आप भूल गए थे। शांत अवधि को कम से कम एक पुन: प्रमाणीकरण चक्र और एक व्यावसायिक सप्ताह के लिए जारी रखें। फिर अपनी प्रतिधारण नीति के तहत लॉग निर्यात करें, सर्वर को बंद करें और इसके साझा रहस्यों को सेवानिवृत्त करें।

व्यावहारिक परिदृश्य: Cisco Meraki पर 40-होटलों का समूह

Cisco Meraki पर स्टाफ WiFi चलाने वाले 40-होटल समूह का उदाहरण लें। यह मुख्य कार्यालय में एक ऑन-प्रीमिस RADIUS सर्वर के विरुद्ध PEAP का उपयोग करता है। प्रत्येक अनुरोध WAN को पार करके एक इमारत तक जाता है, इसलिए मुख्य कार्यालय में आउटेज से हर होटल में स्टाफ WiFi बंद हो जाता है।

समूह पहले सप्ताह में अपने MDM के माध्यम से नया CA पुश करता है। यह Microsoft Entra ID के विरुद्ध क्लाउड RADIUS पर पांच नीति पंक्तियों को फिर से बनाता है, फिर 120-कमरों वाले सिटी होटल में पायलट परीक्षण करता है। इसके बाद पांच, 10 और 24 होटलों के चरण आते हैं, जिनमें से प्रत्येक एक Meraki कॉन्फ़िगरेशन टेम्पलेट है। एक होटल दोपहर के लिए रोल बैक करता है क्योंकि हाउसकीपिंग टैबलेट केवल पुराने CA पर भरोसा करता है। यह एक सप्ताह बाद फिर से स्थानांतरित होता है।

परिणाम:

• सभी 40 होटल छह परिवर्तन समय-सीमाओं (change windows) में स्थानांतरित होते हैं।
• एक साइट एक बार रोल बैक करती है।
• मुख्य कार्यालय अब प्रमाणीकरण पथ में नहीं है।

पुराने और नए RADIUS सर्वर साथ-साथ कैसे चलते हैं?

समानांतर संचालन (Parallel running) इस बात पर निर्भर करता है कि एक्सेस पॉइंट कैसे फेलओवर होते हैं। एक NAS अपनी सूची के पहले सर्वर को प्रत्येक अनुरोध भेजता है। यह अगले सर्वर पर केवल तभी प्रयास करता है जब पहला सर्वर समय-सीमा (timeout) के भीतर उत्तर नहीं देता है।

Access-Reject को एक उत्तर माना जाता है, विफलता नहीं, इसलिए NAS अन्यत्र अनुरोध का पुनः प्रयास नहीं करेगा। इसके दो परिणाम हैं:

• दोनों सर्वरों को समान उत्तर देना होगा। यदि वे भिन्न हैं, तो किसी डिवाइस का अनुभव इस बात पर निर्भर करता है कि किस सर्वर ने उत्तर दिया है।
• समानांतर संचालन एक सुरक्षा जाल (safety net) है, कोई परीक्षण नहीं। चरण 1 और पायलट पर नीति का परीक्षण करें। फेलओवर क्या करता है यह देखने के लिए प्रतीक्षा करके इसका परीक्षण न करें।

पहली साइट के स्थानांतरित होने से पहले टाइमआउट की जांच करें। एक क्लाउड सर्वर आपके संचार कक्ष (comms room) के सर्वर की तुलना में अधिक दूर होता है। प्रत्येक साइट के NAS टाइमआउट और रीट्राई सेटिंग्स की तुलना उसके राउंड-ट्रिप समय से करें। यदि सेटिंग्स बहुत सख्त हैं, तो बिना किसी वास्तविक कारण के अनुरोध पुराने सर्वर पर फेलओवर हो जाएंगे, और इससे समस्याएं छिप जाती हैं। प्रमाणीकरण (authentication) के साथ ही RADIUS एकाउंटिंग को नए सर्वर पर स्थानांतरित करें, ताकि सत्र रिकॉर्ड एक ही स्थान पर रहें।

प्रत्येक साइट पर कटओवर केवल दो सर्वरों के क्रम को बदलना है। ये चरण चरण 2 के भीतर दिखाए गए विक्रेता अंतरों के साथ, प्रत्येक साइट पर लागू होते हैं।

{"title":"बिना किसी फ़्लैग डे के एक साइट को कट ओवर करें","steps":[{"title":"पुष्टि करें कि साइट तैयार है","body":"माइग्रेशन चेकलिस्ट के विरुद्ध साइट की जांच करें: NAS सूचीबद्ध है, प्रबंधित डिवाइसों पर नया CA है, Purple का पाथ खुला है, साइट पर ऑनर मौजूद है।","check":"साइट के लिए प्रत्येक पूर्व-आवश्यकता पर सही का निशान लगा है।"},{"title":"पुराने सर्वर के साथ नया सर्वर जोड़ें","body":"SSID की RADIUS सर्वर सूची में Purple क्लाउड RADIUS जोड़ें, इसके लिए उसी शेयर की गई सीक्रेट का उपयोग करें जो Purple साइट के लिए जारी करता है। अभी के लिए पुराने सर्वर को पहले स्थान पर रहने दें।","check":"कंसोल SSID के विरुद्ध दोनों सर्वर दिखाता है।","variants":[{"label":"Meraki","body":"Meraki Dashboard में, SSID की एक्सेस कंट्रोल सेटिंग्स में सर्वर जोड़ें, आदर्श रूप से कॉन्फ़िगरेशन टेम्पलेट में।"},{"label":"Aruba","body":"HPE Aruba Central में, सर्वर को उस ऑथेंटिकेशन सर्वर ग्रुप में जोड़ें जिसका उपयोग WLAN करता है।"},{"label":"Ruckus","body":"सर्वर को उस AAA सर्वर प्रोफ़ाइल में सेकेंडरी सर्वर के रूप में जोड़ें जिसका उपयोग WLAN करता है।"},{"label":"Mist","body":"Juniper Mist पोर्टल में, सर्वर को WLAN के RADIUS ऑथेंटिकेशन सर्वरों में जोड़ें, आदर्श रूप से WLAN टेम्पलेट में।"},{"label":"UniFi","body":"UniFi Network एप्लिकेशन में, सर्वर को WiFi नेटवर्क के लिए असाइन की गई RADIUS प्रोफ़ाइल में जोड़ें।"}]},{"title":"अदला-बदली करने से पहले परीक्षण करें","body":"RADIUS क्लाइंट के रूप में पंजीकृत एक टेस्ट होस्ट से, नए सर्वर पर प्रति पॉलिसी पंक्ति एक पहचान भेजें।","code":{"lang":"bash","text":"eapol_test -c eap-tls.conf -a <purple-radius-address> -p 1812 -s <shared-secret>"},"check":"प्रत्येक पहचान को उम्मीद के अनुसार VLAN के साथ, पॉलिसी मैप के अनुसार Access-Accept या Access-Reject प्राप्त होता है।"},{"title":"क्रम बदलें","body":"नए सर्वर को प्राइमरी बनाएं और पुराने सर्वर को सेकेंडरी के रूप में रखें। यही कटओवर है।","check":"नए सर्वर लॉग साइट के प्रत्येक एक्सेस पॉइंट से अनुरोध दिखाते हैं।"},{"title":"एक व्यावसायिक चक्र के लिए रोक कर रखें","body":"अस्वीकृति दर (reject rate) की तुलना अपने बेसलाइन से करें और पुष्टि करें कि प्रत्येक डिवाइस क्लास ऑथेंटिकेट हो गई है।","check":"कोई अप्रत्याशित अस्वीकृति नहीं है, और साइट अपना एग्जिट टेस्ट पास करती है।"}]}

आप किसी साइट या वेव को रोल बैक कैसे करते हैं?

रोल बैक करना कटओवर की उल्टी प्रक्रिया है: आप पुराने सर्वर को फिर से पहले स्थान पर रखते हैं। ऊपर उल्लिखित प्रत्येक कंसोल पर, यह केवल एक कॉन्फ़िगरेशन परिवर्तन है। यह केवल तभी काम करता है जब पुराना सर्वर अभी भी चल रहा हो, बिना किसी बदलाव के, और उसकी शेयर की गई सीक्रेट्स सुरक्षित हों। इसीलिए डीकमीशनिंग सबसे अंत में आती है। इसी वजह से आप चरण 1 की शुरुआत में पुराने सर्वर पर पॉलिसी को फ्रीज कर देते हैं।

शुरू करने से पहले ट्रिगर्स पर सहमति बनाएं। विशिष्ट ट्रिगर्स हैं:

• एक डिवाइस क्लास जो कनेक्ट नहीं हो सकती और जिसके लिए उसी दिन कोई सुधार उपलब्ध नहीं है।
• VLAN असाइनमेंट जो पॉलिसी मैप से भिन्न हैं।
• बेसलाइन से अधिक अस्वीकृति दर जिसे आप चेंज विंडो के भीतर स्पष्ट नहीं कर सकते।

{"title":"एक वेव को आगे बढ़ाएं, रोकें या रोल बैक करें","start":"q1","nodes":[{"id":"q1","question":"क्या कोई डिवाइस क्लास नए सर्वर पर विफल हो रही है जो पुराने पर पास हुई थी?","help":"कटओवर से पहले आपके द्वारा रिकॉर्ड किए गए बेसलाइन के साथ डिवाइस प्रकार द्वारा अस्वीकृतियों (rejects) की तुलना करें।","options":[{"label":"हाँ","to":"q2"},{"label":"नहीं","to":"q3"}]},{"id":"q2","question":"क्या विफलता केवल एक डिवाइस क्लास तक सीमित है जिसका समाधान ज्ञात है?","help":"एक प्रोफ़ाइल में गायब CA एक ज्ञात समाधान है। कई क्लास में अस्वीकृतियां ज्ञात नहीं हैं।","options":[{"label":"हाँ","to":"o2"},{"label":"नहीं","to":"o3"}]},{"id":"q3","question":"क्या प्रत्येक परीक्षण पहचान वेव के प्रत्येक साइट पर अपेक्षित VLAN पर पहुंचती है?","options":[{"label":"हाँ","to":"q4"},{"label":"नहीं","to":"o3"}]},{"id":"q4","question":"क्या वेव बिना किसी बिना स्पष्टीकरण वाली अस्वीकृति के एक पूर्ण व्यावसायिक चक्र चला चुकी है?","options":[{"label":"हाँ","to":"o1"},{"label":"नहीं","to":"o2"}]},{"id":"o1","outcome":"आगे बढ़ें: अगली वेव शुरू करें","detail":"प्रति साइट एग्जिट-टेस्ट परिणाम रिकॉर्ड करें और अगली वेव शेड्यूल करें।","link":"[One policy across every location](guide:cloud-radius-multi-site)"},{"id":"o2","outcome":"रोकें: ठीक करें, फिर से परीक्षण करें","detail":"पुराने सर्वर को केवल प्रभावित SSID पर पहले रखें, प्रोफ़ाइल या नियम को ठीक करें, और एग्जिट टेस्ट फिर से चलाएं।"},{"id":"o3","outcome":"वेव को रोल बैक करें","detail":"पुराने सर्वर को वेव के प्रत्येक SSID पर पहले रखें, दोनों सर्वरों से लॉग कैप्चर करें और फिर से प्रयास करने से पहले कारण का पता लगाएं।","link":"[When RADIUS is unreachable](guide:radius-server-down-wifi)"}]}

किसी भी रोलबैक के बाद, विफल विंडो के लिए दोनों सर्वरों से लॉग एक्सपोर्ट करें। कारण ढूंढें और इसे नई नीति में ठीक करें। फिर साइट के दोबारा आगे बढ़ने से पहले प्रभावित पंक्ति के लिए चरण 1 लैब परीक्षण फिर से चलाएं।

आपको कैसे पता चलेगा कि माइग्रेशन पूरा हो गया है?

माइग्रेशन तब पूरा होता है जब प्रमाण ऐसा कहते हैं, न कि तब जब अंतिम साइट स्थानांतरित होती है। पाँच परीक्षण इसे पूरा करते हैं:

1. पुराने सर्वर ने सहमति व्यक्त की गई शांत अवधि के लिए शून्य अनुरोध लॉग किए हैं।
2. इन्वेंट्री में प्रत्येक NAS नए सर्वर के लॉग में दिखाई देता है।
3. एक वास्तविक डिवाइस ने प्रत्येक नीति पंक्ति का अभ्यास किया है और अपेक्षित VLAN पर उतरा है।
4. अस्वीकृति दर (reject rate) चरण 2 से पहले आपके द्वारा रिकॉर्ड किए गए बेसलाइन पर या उससे नीचे है।
5. पुराना सर्वर बंद है, इसके लॉग बनाए रखे गए हैं, इसके सीक्रेट्स रिटायर कर दिए गए हैं और रनबुक को अपडेट कर दिया गया है।

प्रत्येक साइट के लिए एक-पेज का रिकॉर्ड रखें, जिसमें तारीख, एग्जिट-टेस्ट का परिणाम और कोई भी रोलबैक शामिल हो। नए प्रमाणीकरण लॉग के साथ, वे रिकॉर्ड ISO 27001 एक्सेस-नियंत्रण और PCI-DSS लॉगिंग नियंत्रणों के लिए आपका प्रमाण हैं। वे अगले ऑडिट चक्र के लिए परिवर्तन-नियंत्रण प्रमाण के रूप में भी कार्य करते हैं।

क्षेत्र में देखे गए विफलता मोड

वे डिवाइस जो केवल पुराने प्रमाण पत्र पर भरोसा करते हैं

यह सबसे आम विफलता है। अनसंबद्ध PEAP डिवाइस नए प्रमाणपत्र के लिए प्रॉम्प्ट कर सकते हैं या इसे पूरी तरह से अस्वीकार कर सकते हैं। कुछ प्रबंधित प्रोफ़ाइल CA के साथ-साथ सर्वर नाम को भी पिन करती हैं। पायलट से पहले दोनों की जांच करें।

एक ऐसा NAS जिसे किसी ने सूचीबद्ध नहीं किया था

भूल गए कंट्रोलर्स, वायर्ड 802.1X स्विचेस और VPN गेटवे WiFi के स्थानांतरित होने के लंबे समय बाद भी पुराने सर्वर को व्यस्त रखते हैं। चरण 4 में शांत अवधि (quiet period) वह समय है जब आप इन्हें पकड़ पाते हैं।

नीति जो पुराने सर्वर पर मौजूद थी

स्थानीय समूह, हार्ड-कोडेड MAC सूचियां और समय-आधारित नियम अक्सर केवल पुराने सर्वर पर ही मौजूद होते हैं। यदि वे नीति मानचित्र में नहीं हैं, तो वे कटओवर के समय गायब हो जाते हैं।

साझा सीक्रेट और विशेषता बेमेल (attribute mismatches)

गलत टाइप किया गया सीक्रेट कुछ कंसोल पर बिना किसी चेतावनी के विफल हो जाता है। आईडी के बजाय नाम से लौटाया गया VLAN डिवाइस को डिफ़ॉल्ट VLAN पर डाल सकता है। दोनों को चरण 1 के परीक्षण में दिखाई देना चाहिए, और आपको पायलट के दौरान फिर से जांच करनी चाहिए।

भवन में मौजूद सर्वर के लिए ट्यून किए गए टाइमआउट

NAS पर सख्त टाइमआउट पुराने सर्वर पर अवांछित फ़ेलओवर का कारण बनते हैं। पुराना सर्वर हटाए जाने तक सब कुछ काम करता हुआ प्रतीत होता है।

काम किया गया परिदृश्य: दो कंसोल पर 120-स्टोर रिटेलर

एक 120-स्टोर रिटेलर का उदाहरण लें, जिसके पुराने स्टोर HPE Aruba पर हैं और नए स्टोर Juniper Mist पर हैं। स्टोर के हैंडहेल्ड और लैपटॉप ऑन-प्रीमिस RADIUS सर्वर के जोड़े के खिलाफ EAP-TLS का उपयोग करते हैं। Aruba Central समूह और Mist WLAN टेम्पलेट द्वारा समूहीकृत होकर पायलट और तरंगें (waves) सुचारू रूप से चलती हैं।

चरण 4 में, प्रत्येक SSID के स्थानांतरित होने के बाद भी पुराने सर्वर तीन पतों से अनुरोध लॉग करना जारी रखते हैं। दो स्टोर एस्टेट के बाहर वितरण-केंद्र कंट्रोलर हैं। तीसरा प्रधान कार्यालय के लैपटॉप के लिए एक VPN गेटवे है। टीम तीनों को इन्वेंट्री में जोड़ती है, उन्हें एक अतिरिक्त विंडो में स्थानांतरित करती है और शांत अवधि को फिर से शुरू करती है। किसी भी स्टोर पर बिना किसी रुकावट के, डीकमीशनिंग दो हफ्ते देरी से पूरी होती है।

Purple कहाँ फिट बैठता है

Purple Access उन एक्सेस पॉइंट्स का उपयोग करके जिन्हें आप पहले से रखते हैं, एक ही प्लेटफॉर्म पर ओपन, सुरक्षित और xPSK नेटवर्क चलाता है। secure network इस माइग्रेशन को संभालता है। यह Microsoft Entra ID, Okta या Google Workspace से क्लाउड RADIUS, EAP-TLS और पहचान प्रदान करता है। यह Passpoint का भी समर्थन करता है, जिसे Hotspot 2.0 भी कहा जाता है, जो डिवाइस को क्रेडेंशियल के साथ स्वचालित रूप से एक सुरक्षित नेटवर्क से जुड़ने की अनुमति देता है। Purple हार्डवेयर-अज्ञेयवादी है, इसलिए एक ही नीति इन प्लेटफॉर्मों पर मौजूद साइटों के काम आती है:

• Cisco Meraki
• HPE Aruba
• Ruckus
• Juniper Mist
• Ubiquiti UniFi
• Cambium
• Extreme Networks
• Fortinet

इसका अर्थ है कि एक मिश्रित एस्टेट एक ही योजना पर माइग्रेट कर सकता है।

Purple दुनिया में सबसे बड़ा क्लाउड RADIUS चलाता है। यह 99.999% अपटाइम पर चलने वाले प्लेटफॉर्म पर 99.9% RADIUS अपटाइम SLA के साथ आता है। क्योंकि चरण 2 शुरू होने से पहले Purple पक्ष का निर्माण किया जाता है, इसलिए प्रत्येक साइट का कटओवर आमतौर पर सप्ताहांत का अभ्यास होता है। यह चरणबद्ध प्रक्रिया आपके एस्टेट में जोखिम को प्रबंधित करने के लिए है, हमारे प्लेटफॉर्म पर नहीं।

{"items":[{"value":"80,000+","label":"लाइव स्थल","note":"Purple का अपना डेटा"},{"value":"90","label":"देश"},{"value":"99.9%","label":"RADIUS अपटाइम SLA","note":"99.999% पर चलने वाले प्लेटफॉर्म पर"}]}

{"tone":"proof","title":"शाखा पैमाने पर स्टाफ WiFi","text":"JPMorgan 5,000 शाखाओं में Purple पर स्टाफ WiFi चलाता है।"}

उत्पाद विवरण के लिए Purple Access पर क्लाउड RADIUS देखें, और व्यापक नियंत्रण सेट के लिए एंटरप्राइज WiFi सुरक्षा गाइड देखें। गेस्ट मार्केटिंग Engage में है और DNS फ़िल्टरिंग Shield में है। RADIUS माइग्रेशन के दौरान दोनों में से कोई भी नहीं बदलता है।

अक्सर पूछे जाने वाले प्रश्न

मल्टी-साइट RADIUS माइग्रेशन में कितना समय लगता है?

पूरे एस्टेट के लिए हफ्तों और प्रति साइट एक सप्ताहांत (वीकेंड) की योजना बनाएं। Purple पर, प्रत्येक साइट का कटओवर आमतौर पर सप्ताहांत का काम होता है। एस्टेट में अधिक समय लगता है क्योंकि अगला चरण शुरू होने से पहले प्रत्येक लहर एक व्यावसायिक चक्र के लिए रुकती है। एक 40-साइट का उदाहरणात्मक एस्टेट इन्वेंट्री से लेकर डिकमीशन तक लगभग 12 सप्ताह लेता है। उस समय का अधिकांश हिस्सा तैयारी और होल्डिंग अवधि में जाता है, न कि परिवर्तन कार्य पर।

क्या मुझे क्लाउड RADIUS पर जाने के लिए नए एक्सेस पॉइंट्स की आवश्यकता है?

नहीं। क्लाउड RADIUS उस सर्वर को बदलता है जिससे आपके एक्सेस पॉइंट अनुरोध करते हैं, न कि स्वयं एक्सेस पॉइंट्स को। Purple Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet के साथ काम करता है। आप प्रत्येक SSID की RADIUS सर्वर सूची में उस कंसोल में नया सर्वर जोड़ते हैं जिसे आप पहले से उपयोग करते हैं। आपके SSID, VLAN ID और स्विच कॉन्फ़िगरेशन वैसे ही रहते हैं जैसे वे हैं।

मुझे कई साइटों पर क्लाउड RADIUS की लागत का मॉडल कैसे बनाना चाहिए?

इसे दो संख्याओं पर मॉडल करें: साइटें और पहचान (आइडेंटिटीज)। प्रमाणित करने वाली प्रत्येक साइट और शामिल होने वाली प्रत्येक पहचान को गिनें, जिसमें EAP-TLS पर मौजूद डिवाइस भी शामिल हैं। फिर पुराने सर्वर की पूरी लागत के साथ इसकी तुलना करें: हार्डवेयर, लाइसेंस, पैचिंग, उच्च उपलब्धता (हाई उपलब्धता) और प्रधान कार्यालय का WAN पाथ। प्रति साइट क्लाउड RADIUS लागत मॉडलिंग के लिए हमारा गाइड इस गणना के माध्यम से बताता है।

क्या मैं माइग्रेशन के बाद पुराने RADIUS सर्वर को फ़ॉलबैक के रूप में रख सकता हूँ?

समानांतर संचालन (पैरेलल रनिंग) के दौरान इसे रखें, फिर इसे बंद कर दें। जब तक यह सेकेंडरी के रूप में सूचीबद्ध है, यह अभी भी तरंगों (वेव्स) में मौजूद साइटों पर टाइमआउट को कवर करता है। चरण 4 के बाद, पुरानी नीति की फ़्रीज की गई प्रति रखने वाला सर्वर एक जोखिम बन जाता है, क्योंकि इसके द्वारा दिया गया कोई भी उत्तर पुराने नियमों का उपयोग करता है। तब से, लचीलापन (रेजिलिएंस) 99.9% RADIUS अपटाइम SLA और एक आउटेज रिकवरी प्लान से आता है।

क्या कर्मचारियों को अपने उपकरणों को फिर से नामांकित (री-एनरोल) करना होगा?

यदि कटओवर से पहले नए सर्वर प्रमाणपत्र पर भरोसा किया जाता है तो नहीं। निर्माण चरण के दौरान अपने MDM के माध्यम से प्रबंधित उपकरणों के लिए नया CA पुश करें। EAP-TLS उपकरण अपने मौजूदा क्लाइंट प्रमाणपत्रों को बनाए रखते हैं, बशर्ते नया सर्वर उन्हें जारी करने वाले CA पर भरोसा करता हो। गैर-प्रबंधित PEAP उपकरण इसका अपवाद हैं, क्योंकि कुछ उपकरण नए प्रमाणपत्र को स्वीकार करने के लिए एक बार संकेत देते हैं। उन कर्मचारियों को उनकी साइट स्थानांतरित होने से पहले एक छोटा नोटिस भेजें।

क्या माइग्रेशन हमारे ISO 27001 या PCI DSS साक्ष्य को प्रभावित करता है?

यह बदलता है कि आपका प्रमाण कहाँ से आता है, इसलिए शुरू से ही इसके लिए योजना बनाएं। प्रमाणीकरण लॉग, नीति परिभाषाएं और परिवर्तन रिकॉर्ड नए प्लेटफॉर्म पर स्थानांतरित हो जाते हैं। अपनी प्रतिधारण नीति के तहत पुराने सर्वर के लॉग बनाए रखें और प्रत्येक साइट के एग्जिट-टेस्ट रिकॉर्ड को फाइल करें। Purple के पास ISO 27001 प्रमाणन है, जो आपके ऑडिटरों को प्लेटफॉर्म पक्ष के लिए प्रमाण देता है। आपके अपने नियंत्रणों को अभी भी अपने स्वयं के प्रमाण की आवश्यकता है।

कई एस्टेट चलाने वाले MSP के लिए यह कैसे अलग है?

चरण समान हैं। जो भिन्न है वह एस्टेट के बीच अलगाव है। एक MSP प्रत्येक एस्टेट के लिए समान चार चरण चलाता है, लेकिन साझा प्लेटफॉर्म पर प्रत्येक को अपनी नीति, पहचान स्रोत और लॉग की आवश्यकता होती है। तरंगे आमतौर पर कंसोल टेम्पलेट्स के बजाय अनुबंध सीमाओं का पालन करती हैं। MSPs के लिए मल्टी-टेनेंट RADIUS की हमारी गाइड में शामिल है कि माइग्रेशन के दौरान और बाद में प्रत्येक एस्टेट को कैसे अलग रखा जाए।