मुख्य सामग्री पर जाएं
हिन्दी

RadSec: कैसे RADIUS over TLS, WiFi ऑथेंटिकेशन सुरक्षा को बेहतर बनाता है

यह आधिकारिक तकनीकी संदर्भ बताता है कि कैसे RadSec (RFC 6614) पारंपरिक RADIUS ट्रैफ़िक को TLS एन्क्रिप्शन में रैप करके एंटरप्राइज़ WiFi ऑथेंटिकेशन को सुरक्षित करता है। IT प्रबंधकों और नेटवर्क आर्किटेक्ट्स के लिए डिज़ाइन किया गया, यह कॉर्पोरेट और गेस्ट नेटवर्क पर अनएन्क्रिप्टेड UDP RADIUS ट्रैफ़िक के जोखिमों को कम करने के लिए आर्किटेक्चर, परिनियोजन रणनीतियों और व्यावहारिक कदमों को कवर करता है।

Iain Jewitt द्वाराप्रकाशित अपडेट किया गया
📖 4 मिनट का पाठ1,025 शब्द2 हल किए गए उदाहरण3 अभ्यास प्रश्न8 मुख्य परिभाषाएं

Video overview

इस गाइड को सुनें

पॉडकास्ट ट्रांसक्रिप्ट देखें
RadSec: कैसे RADIUS over TLS, WiFi ऑथेंटिकेशन सुरक्षा को बेहतर बनाता है Purple Enterprise WiFi इंटेलिजेंस ब्रीफिंग अनुमानित समय: 10 मिनट --- [परिचय और संदर्भ - लगभग 1 मिनट] Purple Enterprise WiFi इंटेलिजेंस सीरीज़ में आपका स्वागत है। मैं आपका होस्ट हूँ, और आज हम एक ऐसे विषय पर चर्चा कर रहे हैं जो नेटवर्क सुरक्षा और ऑपरेशनल रिस्क के बिल्कुल केंद्र में है: RadSec - जिसे औपचारिक रूप से RFC 6614 में परिभाषित किया गया है - और यह क्यों आपके इंफ्रास्ट्रक्चर रोडमैप पर होना चाहिए यदि यह पहले से वहां नहीं है। यदि आप एक आईटी मैनेजर, नेटवर्क आर्किटेक्ट, या CTO हैं जो किसी होटल ग्रुप, रिटेल एस्टेट, स्टेडियम, या पब्लिक सेक्टर कैंपस में एंटरप्राइज़ WiFi के लिए ज़िम्मेदार हैं, तो यह ब्रीफिंग आपके लिए है। हम इस पर चर्चा करेंगे कि RadSec वास्तव में क्या है, पारंपरिक RADIUS प्रोटोकॉल आपको कैसे असुरक्षित छोड़ देता है, वास्तविक दुनिया के वातावरण में RadSec को कैसे तैनात किया जाए, और वे कौन सी कमियां हैं जो टीमों को फंसाती हैं। कोई केवल थ्योरी के लिए थ्योरी नहीं - बस वही जानकारी जिसकी आपको इस तिमाही में निर्णय लेने के लिए आवश्यकता है। आइए इस पर विस्तार से बात करते हैं। --- [तकनीकी गहन विश्लेषण - लगभग 5 मिनट] तो, चलिए समस्या से शुरुआत करते हैं। RADIUS - रिमोट ऑथेंटिकेशन डायल-इन यूजर सर्विस - 1990 के दशक से एंटरप्राइज़ WiFi ऑथेंटिकेशन की रीढ़ रहा है। जब कोई यूजर या डिवाइस आपके कॉर्पोरेट या गेस्ट WiFi से कनेक्ट होता है, तो एक्सेस पॉइंट एक RADIUS क्लाइंट के रूप में काम करता है, जो ऑथेंटिकेशन अनुरोधों को RADIUS सर्वर पर फॉरवर्ड करता है, जो आपके डायरेक्टरी - Active Directory, LDAP, या क्लाउड आइडेंटिटी प्रोवाइडर के खिलाफ क्रेडेंशियल्स को सत्यापित करता है - और या तो एक्सेस देता है या मना करता है। यह 802.1X ऑथेंटिकेशन मॉडल है जो WPA2-Enterprise और WPA3-Enterprise नेटवर्क को आधार प्रदान करता है। समस्या यह है कि पारंपरिक RADIUS को एक अलग युग के लिए डिज़ाइन किया गया था। यह UDP - यूजर डेटाग्राम प्रोटोकॉल - पर पोर्ट 1812 और 1813 पर चलता है। UDP कनेक्शन रहित (connectionless) है, जिसका अर्थ है कि कोई हैंडशेक नहीं है, कोई सेशन स्टेट नहीं है, और महत्वपूर्ण रूप से, कोई नेटिव एन्क्रिप्शन नहीं है। आपके एक्सेस पॉइंट और आपके RADIUS सर्वर के बीच एकमात्र सुरक्षा एक शेयर्ड सीक्रेट है - अनिवार्य रूप से एक पासवर्ड - जिसका उपयोग MD5 हैशिंग का उपयोग करके ट्रांजिट में यूजर के पासवर्ड को अस्पष्ट करने के लिए किया जाता है। MD5, जैसा कि आप में से अधिकांश जानते होंगे, क्रिप्टोग्राफ़िक रूप से टूटा हुआ है। यह सालों से टूटा हुआ है। व्यवहार में इसका क्या अर्थ है? इसका अर्थ है कि किसी भी नेटवर्क सेगमेंट पर जहां कोई हमलावर RADIUS ट्रैफ़िक को रोक सकता है - और इसमें क्रेडेंशियल्स से समझौता किए गए स्विच, आपके मैनेजमेंट VLAN पर दुष्ट डिवाइस, या रिमोट एक्सेस पॉइंट और क्लाउड-होस्टेड RADIUS सर्वर के बीच का कोई भी पॉइंट शामिल है - वे संभावित रूप से ऑथेंटिकेशन एक्सचेंज को कैप्चर कर सकते हैं, शेयर्ड सीक्रेट के खिलाफ ऑफ़लाइन डिक्शनरी हमलों का प्रयास कर सकते हैं, और कुछ कॉन्फ़िगरेशन में, यूजर क्रेडेंशियल्स को पूरी तरह से उजागर कर सकते हैं। 200 संपत्तियों में गेस्ट WiFi चलाने वाले होटल ग्रुप के लिए, या प्रत्येक स्टोर में एक्सेस पॉइंट वाले रिटेल चेन के लिए जो पब्लिक इंटरनेट पर एक सेंट्रल RADIUS सर्वर पर बैकहॉल कर रहे हैं, यह कोई काल्पनिक जोखिम नहीं है। यह एक लाइव अटैक सरफेस है।यह बिल्कुल वही है जिसे RadSec हल करता है। RadSec - RFC 6614 में परिभाषित और RFC 7360 द्वारा अपडेट किया गया - RADIUS ट्रैफ़िक को TLS टनल के भीतर रैप करता है। UDP के बजाय, यह पोर्ट 2083 पर TCP का उपयोग करता है। एक शेयर्ड सीक्रेट और MD5 के बजाय, यह X.509 प्रमाणपत्रों के साथ म्यूचुअल TLS ऑथेंटिकेशन का उपयोग करता है। RADIUS क्लाइंट और RADIUS सर्वर दोनों प्रमाणपत्र प्रस्तुत करते हैं, एक-दूसरे की पहचान सत्यापित करते हैं, और कोई भी ऑथेंटिकेशन डेटा एक्सचेंज होने से पहले एक एन्क्रिप्टेड सेशन स्थापित करते हैं। TLS 1.3 वर्तमान अनुशंसित वर्शन है, जो फ़ॉरवर्ड सीक्रेसी प्रदान करता है और कई लीगेसी सिफर कमजोरियों को समाप्त करता है। इसका व्यावहारिक प्रभाव महत्वपूर्ण है। क्रेडेंशियल डेटा, यूजर एट्रिब्यूट्स और सेशन टोकन एक्सेस पॉइंट - या RadSec प्रॉक्सी - और RADIUS सर्वर के बीच एंड-टू-एंड एन्क्रिप्टेड होते हैं। वायर पर ट्रैफ़िक को इंटरसेप्ट करने वाले हमलावर को केवल एन्क्रिप्टेड TLS रिकॉर्ड दिखाई देते हैं। बैकवर्ड कम्पैटिबिलिटी के लिए शेयर्ड सीक्रेट अभी भी मौजूद है, लेकिन अब यह कोई महत्वपूर्ण सुरक्षा कार्य नहीं कर रहा है - TLS सारा भार उठा रहा है। यहाँ एक और आयाम है जो तेजी से प्रासंगिक हो रहा है: रोमिंग। Eduroam फेडरेशन, जिसका उपयोग पूरे यूरोप और उससे आगे के विश्वविद्यालयों और अनुसंधान संस्थानों द्वारा किया जाता है, अपने इंटर-इंस्टीट्यूशनल रोमिंग इंफ्रास्ट्रक्चर के हिस्से के रूप में वर्षों से RadSec चला रहा है। हाल ही में, Wi-Fi Alliance के OpenRoaming मानक ने - जो भाग लेने वाले स्थानों पर निर्बाध WiFi रोमिंग को सक्षम बनाता है - सभी फेडरेशन ट्रैफ़िक के लिए RadSec को अनिवार्य कर दिया है। यदि आप OpenRoaming-सक्षम इंफ्रास्ट्रक्चर तैनात कर रहे हैं, तो RadSec वैकल्पिक नहीं है; यह एक पूर्वापेक्षा है। Purple अपने Connect लाइसेंस के तहत OpenRoaming का समर्थन करता है, फेडरेशन के भीतर एक पहचान प्रदाता के रूप में कार्य करता है, और RadSec इस सुरक्षित रोमिंग फैब्रिक के काम करने के तरीके के लिए केंद्रीय है। अनुपालन के दृष्टिकोण से, RadSec तेजी से PCI-DSS 4.0 के लिए प्रासंगिक हो रहा है, जो पारगमन में ऑथेंटिकेशन डेटा की सुरक्षा के आसपास की आवश्यकताओं को कड़ा करता है। यदि आपका WiFi इंफ्रास्ट्रक्चर भुगतान कार्ड परिवेशों को छूता है - और रिटेल तथा हॉस्पिटैलिटी में, यह अक्सर ऐसा करता है - तो पारंपरिक RADIUS में एन्क्रिप्शन गैप एक ऐसी कमी है जो ऑडिट में पकड़ी जा सकती है। GDPR को भी व्यक्तिगत डेटा की सुरक्षा के लिए उपयुक्त तकनीकी उपायों की आवश्यकता होती है; आपके नेटवर्क पर अनएन्क्रिप्टेड प्रवाहित होने वाले यूजर क्रेडेंशियल और सेशन मेटाडेटा का डेटा सुरक्षा ऑडिट में बचाव करना कठिन है। अब आर्किटेक्चर की बात करते हैं। RadSec के लिए दो प्राथमिक परिनियोजन पैटर्न हैं। पहला आपके RADIUS सर्वर और एक्सेस पॉइंट्स पर नेटिव RadSec समर्थन है। FreeRADIUS 3.0 और उससे ऊपर का वर्शन नेटिव रूप से RadSec का समर्थन करता है। Microsoft NPS वर्तमान रिलीज़ के अनुसार नेटिव रूप से RadSec का समर्थन नहीं करता है, जो Windows-केंद्रित इंफ्रास्ट्रक्चर चलाने वाले संगठनों के लिए एक महत्वपूर्ण बाधा है। Cisco ISE RadSec का समर्थन करता है। Aruba ClearPass RadSec का समर्थन करता है। यदि आपका RADIUS सर्वर और आपका एक्सेस पॉइंट वेंडर दोनों नेटिव रूप से RadSec का समर्थन करते हैं, तो यह सबसे साफ रास्ता है - दोनों सिरों पर TLS प्रमाणपत्र कॉन्फ़िगर करें, अपने फ़ायरवॉल पर TCP 2083 खोलें, और आप RADIUS ट्रैफ़िक को एंड-टू-एंड एन्क्रिप्ट कर रहे हैं।दूसरा पैटर्न RadSec प्रॉक्सी है। व्यवहार में यह अधिक सामान्य परिनियोजन (deployment) है, विशेष रूप से उन संगठनों के लिए जिनके पास विरासत RADIUS इन्फ्रास्ट्रक्चर या मिश्रित-विक्रेता वातावरण हैं। एक RadSec प्रॉक्सी - radsecproxy सबसे व्यापक रूप से तैनात किया जाने वाला ओपन-सोर्स कार्यान्वयन है - जो आपके एक्सेस पॉइंट्स और आपके RADIUS सर्वर के बीच स्थित होता है। एक्सेस पॉइंट्स स्थानीय नेटवर्क पर प्रॉक्सी को UDP पर मानक RADIUS भेजते हैं। प्रॉक्सी उस कनेक्शन को समाप्त करता है, RADIUS ट्रैफ़िक को TLS टनल के भीतर फिर से एन्कैप्सुलेट करता है, और इसे TCP 2083 पर अपस्ट्रीम RADIUS सर्वर को फॉरवर्ड करता है। यह दृष्टिकोण आपको अपने RADIUS सर्वर को बदले बिना एक मौजूदा इन्फ्रास्ट्रक्चर में RadSec जोड़ने की अनुमति देता है, और यह विशेष रूप से तब उपयोगी होता है जब आपका RADIUS सर्वर क्लाउड में होस्ट किया गया हो या सार्वजनिक इंटरनेट पर एक्सेस किया जा रहा हो। सर्टिफिकेट प्रबंधन वह परिचालन जटिलता है जिसके लिए आपको योजना बनाने की आवश्यकता है। म्यूचुअल TLS के लिए उपयोग किए जाने वाले X.509 सर्टिफिकेट जारी करने और प्रबंधित करने के लिए आपको एक PKI - पब्लिक की इन्फ्रास्ट्रक्चर - की आवश्यकता होगी। इसका मतलब है एक सर्टिफिकेट अथॉरिटी, प्रत्येक RADIUS क्लाइंट और सर्वर के लिए सर्टिफिकेट जारी करना, और समाप्ति से पहले सर्टिफिकेट रोटेशन की एक प्रक्रिया। जिन सर्टिफिकेट की समय-सीमा बिना ध्यान दिए समाप्त हो जाती है, वे आपके नेटवर्क पर हर उपयोगकर्ता के लिए एक साथ प्रमाणीकरण को बाधित कर देंगे - और यह एक ऐसा परिदृश्य है जिससे आप बचना चाहते हैं। ACME या अपने CA के API का उपयोग करके सर्टिफिकेट रिन्यूअल को ऑटोमेट करें, और समाप्ति तिथियों से काफी पहले मॉनिटरिंग अलर्ट सेट करें। - - - [कार्यान्वयन सिफारिशें और कमियां - लगभग 2 मिनट] मैं आपको व्यावहारिक सिफारिशें देता हूँ। पहला: तैनात करने से पहले ऑडिट करें। अपने वातावरण में प्रत्येक RADIUS क्लाइंट - एक्सेस पॉइंट्स, VPN कॉन्सेंट्रेटर्स, 802.1X करने वाले स्विच - और प्रत्येक RADIUS सर्वर को मैप करें। समझें कि कौन से RadSec को मूल रूप से सपोर्ट करते हैं और किनके लिए प्रॉक्सी की आवश्यकता होगी। यह ऑडिट आमतौर पर उन पुराने उपकरणों को सतह पर लाता है जो बिल्कुल भी TLS का समर्थन नहीं करते हैं, और उन्हें आपके रिप्लेसमेंट रोडमैप पर होना चाहिए। दूसरा: उच्चतम जोखिम वाले ट्रैफ़िक से शुरू करें। यदि आपके पास सार्वजनिक इंटरनेट से गुजरने वाला RADIUS ट्रैफ़िक है - रिमोट साइट्स, क्लाउड-होस्टेड RADIUS, मल्टी-प्रॉपर्टी होटल समूह - तो यह आपकी पहली प्राथमिकता है। एक अच्छी तरह से खंडित (segmented) प्रबंधन VLAN पर स्थानीय RADIUS ट्रैफ़िक कम जोखिम वाला है, लेकिन इसे अभी भी रोडमैप पर होना चाहिए। तीसरा: गो-लाइव से पहले म्यूचुअल TLS का पूरी तरह से परीक्षण करें। RadSec परिनियोजन में सबसे आम विफलता मोड सर्टिफिकेट सत्यापन त्रुटियां हैं - जैसे बेमेल कॉमन नेम (Common Names), समाप्त हो चुके इंटरमीडिएट सर्टिफिकेट, या ऐसे क्लाइंट जो उस CA पर भरोसा नहीं करते हैं जिसने सर्वर सर्टिफिकेट पर हस्ताक्षर किए हैं। प्रोडक्शन ट्रैफ़िक को कट ओवर करने से पहले TLS हैंडशेक का परीक्षण करने के लिए openssl s_client का उपयोग करें। चौथा: मॉनिटरिंग की उपेक्षा न करें। RadSec एक TCP कनेक्शन लेयर जोड़ता है जो पारंपरिक RADIUS में नहीं होती है। TCP कनेक्शन विफलताएं, TLS हैंडशेक टाइमआउट, और सर्टिफिकेट त्रुटियां आपके उपयोगकर्ताओं के लिए प्रमाणीकरण विफलताओं के रूप में प्रकट होंगी। सुनिश्चित करें कि आपके RADIUS सर्वर लॉग और आपके प्रॉक्सी लॉग आपके SIEM या मॉनिटरिंग प्लेटफॉर्म में फीड हो रहे हैं ताकि आप एक RadSec कनेक्टिविटी समस्या और एक प्रमाणीकरण नीति समस्या के बीच अंतर कर सकें।जो सबसे आम गलती मैं देखता हूँ, वह यह है कि संगठन सर्वर साइड पर RadSec तो लागू कर देते हैं लेकिन अपने फ़ायरवॉल नियमों को अपडेट करना भूल जाते हैं। प्रत्येक RADIUS क्लाइंट और RADIUS सर्वर या प्रॉक्सी के बीच TCP 2083 खुला होना आवश्यक है। यदि आप UDP 1812 नियमों को प्रबंधित करने के आदी हैं, तो फ़ायरवॉल परिवर्तन प्रक्रिया में TCP 2083 छूट सकता है। - [त्वरित प्रश्नोत्तर - लगभग 1 मिनट] आइए मैं कुछ ऐसे सवालों पर नज़र डालूँ जो मुझे नियमित रूप से सुनने को मिलते हैं। "क्या RadSec, 802.1X को बदल देता है?" नहीं। RadSec एक्सेस पॉइंट और RADIUS सर्वर के बीच ट्रांसपोर्ट लेयर को सुरक्षित करता है। 802.1X क्लाइंट डिवाइस और एक्सेस पॉइंट के बीच प्रमाणीकरण ढांचा (authentication framework) है। ये अलग-अलग लेयर्स पर काम करते हैं और एक-दूसरे के पूरक हैं। "क्या सभी एक्सेस पॉइंट वेंडर्स पर RadSec समर्थित है?" सार्वभौमिक रूप से नहीं। Cisco, Aruba, Ruckus, और Meraki सभी के पास RadSec समर्थन के अलग-अलग स्तर हैं - अपने विशिष्ट फर्मवेयर संस्करण की जाँच करें। जहाँ मूल समर्थन अनुपस्थित है, वहाँ एक RadSec प्रॉक्सी आपका समाधान है। "DTLS - RADIUS over DTLS के बारे में क्या?" RFC 7360, RADIUS over DTLS को परिभाषित करता है, जो TCP के बजाय UDP का उपयोग करता है, जिससे एन्क्रिप्शन जोड़ते समय पारंपरिक RADIUS की कुछ कनेक्शन रहित विशेषताओं को सुरक्षित रखा जा सकता है। यह TLS पर RadSec की तुलना में कम व्यापक रूप से तैनात है, लेकिन यदि उच्च-थ्रूपुट वातावरण में लेटेंसी एक चिंता का विषय है तो यह मूल्यांकन करने योग्य है। "यह रोमिंग प्रदर्शन को कैसे प्रभावित करता है?" RadSec का TCP कनेक्शन लगातार बना रहता है, जो वास्तव में बाद के प्रमाणीकरण अनुरोधों के लिए कनेक्शन सेटअप ओवरहेड को कम करके फ़ेडरेटेड वातावरण में रोमिंग प्रदर्शन को बेहतर बना सकता है। - [सारांश और अगले कदम - लगभग 1 मिनट] समापन के लिए: RadSec पारंपरिक RADIUS में एक वास्तविक सुरक्षा अंतर का परिपक्व, मानकों-आधारित उत्तर है। यदि आप बड़े पैमाने पर एंटरप्राइज़ WiFi चला रहे हैं - कई साइटों पर, इंटरनेट पर, या PCI-DSS या GDPR के अधीन वातावरण में - तो सवाल यह नहीं है कि RadSec को लागू किया जाए या नहीं, बल्कि यह है कि कब और कैसे किया जाए। आपके अगले कदम: इस सप्ताह अपने RADIUS इन्फ्रास्ट्रक्चर का ऑडिट करें। अपने सबसे अधिक जोखिम वाले ट्रैफ़िक फ़्लो की पहचान करें। मूल RadSec समर्थन के लिए अपने RADIUS सर्वर और एक्सेस पॉइंट वेंडर के दस्तावेज़ों की जाँच करें। यदि आप FreeRADIUS चला रहे हैं, तो आप एक दिन में एक परीक्षण RadSec परिनियोजन चला सकते हैं। यदि आप Microsoft NPS पर हैं, तो एक प्रॉक्सी या RadSec-सक्षम सर्वर पर माइग्रेशन पथ का मूल्यांकन करना शुरू करें। Purple का प्लेटफ़ॉर्म एंटरप्राइज़ RADIUS इन्फ्रास्ट्रक्चर के साथ एकीकृत करने के लिए डिज़ाइन किया गया है, जो कॉर्पोरेट और गेस्ट WiFi दोनों वातावरणों के लिए सुरक्षित प्रमाणीकरण प्रवाह का समर्थन करता है। यदि आप समझना चाहते हैं कि आपके विशिष्ट परिनियोजन में RadSec कैसे फिट बैठता है, तो Purple की टीम इसके बारे में आपका मार्गदर्शन कर सकती है। सुनने के लिए धन्यवाद। अगली बार तक। - स्क्रिप्ट समाप्त

हमारी मुख्य श्रृंखला का हिस्सा: एंटरप्राइज़ WiFi सुरक्षा गाइड →

RFC 6614 Architecture ToolCloud RADIUS over TLS 1.3

RadSec Architecture Advisor: RADIUS over TLS Evaluator

Model TCP port 2083 TLS encapsulation overhead against legacy UDP RADIUS across WAN circuits. Calculate EAP-TLS handshake latencies, eliminate packet fragmentation black holes, and audit RFC 6614 trust.

Legacy UDP Latency (WAN)
302 ms
Includes 144 ms UDP timeout penalty
RadSec TLS Latency
160 ms
Fast TCP ACK recovery without timeout stalls
Handshake Latency Savings
47% faster
Saves 142 ms per EAP-TLS negotiation
At 0.5% packet loss, 4% of EAP-TLS exchanges lose at least one of their 9 packets. On UDP each loss waits out a 3,200 ms retransmit timer; on TCP a fast retransmit recovers it inside one or two round trips.
RFC 6614 PKI Posture
4 / 5 controls
One load-bearing control missing

Protocol Architecture: RadSec (RFC 6614) vs Legacy RADIUS (RFC 2865)

Security & Network VectorRadSec (RFC 6614 / TLS 1.3)Legacy RADIUS (RFC 2865 / UDP)
Transport & PortTCP Port 2083 (Stateful stream)UDP Ports 1812 / 1813 (Stateless datagrams)
Payload CryptographyTLS 1.3 Mutual Authentication (mTLS) with AEAD ciphersPre-Shared Key with MD5 hashing (RFC 2865 BlastRADIUS exposure)
MTU & Packet FragmentationTCP PMTU Discovery eliminates UDP fragmentation black holesLarge EAP-TLS certificate chains fragment over 1500 bytes and drop on WAN
Firewall Traversal & NATSingle outbound TCP connection; state table persists cleanlyRequires bi-directional UDP NAT pinholes prone to 30s timeout aging
Packet Loss RecoveryTCP fast retransmission within 1 to 2 RTTs (~70 ms)Controller retry timeout (typically 3,000 to 5,000 ms per drop)
Connection ModelLong-lived persistent TCP connection pool with keep-alivePer-packet datagrams with independent identifier tracking
Why BlastRADIUS (CVE-2024-3596) Mandates RadSec for WAN Authentications

The BlastRADIUS vulnerability exploits MD5 collisions in standard RFC 2865 Access-Request packets to forge an Access-Accept without the shared secret. RadSec protects the entire RADIUS protocol inside TLS 1.3 encryption, rendering man-in-the-middle packet injection impossible across untrusted internet WAN links.

Migrating Enterprise WiFi to Cloud RADIUS & RadSec?

Purple Cloud RADIUS delivers turnkey RFC 6614 RadSec termination, automated Intune and Jamf SCEP certificate enrolment, and zero on-prem server maintenance.

Security Guide →
Useful? Link to this tool

RadSec: कैसे RADIUS over TLS, WiFi ऑथेंटिकेशन सुरक्षा को बेहतर बनाता है

कार्यकारी सारांश (Executive Summary)

UDP (पोर्ट्स 1812/1813) पर चलने वाला पारंपरिक RADIUS आधुनिक एंटरप्राइज सुरक्षा खतरों से निपटने के लिए डिज़ाइन नहीं किया गया था। केवल एक शेयर्ड सीक्रेट और MD5 हैशिंग पर निर्भर रहने के कारण, यह क्रेडेंशियल्स और सेशन एट्रिब्यूट्स को इंटरसेप्ट होने के प्रति संवेदनशील छोड़ देता है, विशेष रूप से तब जब वे सार्वजनिक नेटवर्क या हॉस्पिटैलिटी और रिटेल चेन जैसे बड़े वितरित परिसरों से होकर गुजरते हैं। RadSec (RADIUS over TLS, RFC 6614) RADIUS ट्रैफ़िक को पोर्ट 2083 पर TCP-आधारित TLS 1.3 टनल के भीतर एनकैप्सुलेट करके इस बुनियादी सुरक्षा अंतर को हल करता है।

CTOs और नेटवर्क आर्किटेक्ट्स के लिए, RadSec को तैनात करना अब केवल एक सर्वोत्तम अभ्यास नहीं है - यह corporate wifi की सुरक्षा करने, PCI DSS 4.0 अनुपालन बनाए रखने, और OpenRoaming जैसे आधुनिक फेडरेटेड रोमिंग फ्रेमवर्क में भाग लेने के लिए एक अत्यंत आवश्यक आवश्यकता है। यह गाइड आपके ऑथेंटिकेशन इंफ्रास्ट्रक्चर को सुरक्षित करने के लिए आर्किटेक्चर, कार्यान्वयन पैटर्न और परिचालन आवश्यकताओं का विवरण देती है।

तकनीकी गहराई: RADIUS बनाम RadSec

पारंपरिक RADIUS में सुरक्षा भेद्यता

एक मानक 802.1X परिनियोजन में, एक्सेस पॉइंट (ऑथेंटिकेटर) क्लाइंट क्रेडेंशियल्स को RADIUS सर्वर (ऑथेंटिकेशन सर्वर) पर फॉरवर्ड करता है। पारंपरिक RADIUS में, यह पेलोड UDP पर भेजा जाता है। एकमात्र सुरक्षा एक प्री-शेयर्ड की (PSK) है जिसका उपयोग MD5 के माध्यम से पासवर्ड को अस्पष्ट करने के लिए किया जाता है।

यह आर्किटेक्चर तीन महत्वपूर्ण जोखिम प्रस्तुत करता है:

  1. ट्रांसपोर्ट एन्क्रिप्शन की कमी: यूजर एट्रिब्यूट्स, MAC एड्रेस और सेशन डेटा क्लियरटेक्स्ट में प्रसारित किए जाते हैं।
  2. क्रिप्टोग्राफिक कमजोरी: यदि कोई हमलावर ट्रैफ़िक को कैप्चर कर लेता है, तो MD5 ऑफ़लाइन डिक्शनरी हमलों के प्रति संवेदनशील होता है।
  3. म्युचुअल ऑथेंटिकेशन का न होना: एक्सेस पॉइंट क्रिप्टोग्राफिक रूप से यह सत्यापित नहीं कर सकता है कि वह वैध RADIUS सर्वर से बात कर रहा है, जिससे नकली सर्वर हमलों का मार्ग प्रशस्त होता है।

RadSec आर्किटेक्चर (RFC 6614)

RadSec ट्रांसपोर्ट लेयर को UDP से TCP में स्थानांतरित करके और पूरे पेलोड को TLS में रैप करके इन खामियों को दूर करता है।

RadSec: कैसे RADIUS over TLS, WiFi ऑथेंटिकेशन सुरक्षा को बेहतर बनाता है - architecture overview

  • ट्रांसपोर्ट: TCP पोर्ट 2083 विश्वसनीय डिलीवरी और स्टेटफुल कनेक्शन सुनिश्चित करता है, जिससे हाई-लेटेंसी वाले वातावरण में प्रदर्शन में सुधार होता है।
  • एन्क्रिप्शन: TLS 1.2 या 1.3 सभी RADIUS एट्रिब्यूट्स का मजबूत, एंड-टू-एंड एन्क्रिप्शन प्रदान करता है।
  • म्युचुअल ऑथेंटिकेशन: RADIUS क्लाइंट (या प्रॉक्सी) और सर्वर दोनों को एक विश्वसनीय सर्टिफिकेट अथॉरिटी (CA) द्वारा जारी किए गए वैध X.509 सर्टिफिकेट प्रस्तुत करने होंगे। शेयर्ड सीक्रेट को केवल बैकवर्ड कम्पैटिबिलिटी के लिए बनाए रखा जाता है; TLS वास्तविक सुरक्षा प्रदान करता है।यह आर्किटेक्चर डिस्ट्रीब्यूटेड एनवायरनमेंट के लिए आवश्यक है, जैसे कि Retail चेन या Hospitality स्थल, जहां एक्सेस पॉइंट्स पब्लिक इंटरनेट पर एक सेंट्रल या क्लाउड-होस्टेड RADIUS सर्वर को ऑथेंटिकेशन रिक्वेस्ट बैकहॉल करते हैं।

अपने विशिष्ट सेटअप को लेकर कोई सवाल हैं?

हमारी टीम 80,000 से अधिक वेन्यू में वेन्यू ऑपरेटरों, IT मैनेजरों और नेटवर्क इंजीनियरों के साथ काम करती है। 20 मिनट का कॉल बुक करें और हम आपको दिखाएंगे कि आपके जैसे अन्य लोगों ने इसे कैसे हल किया।

इम्प्लीमेंटेशन गाइड

RadSec को डिप्लॉय करना आमतौर पर दो पैटर्न में से एक का पालन करता है: Native Support या Proxy-based।

पैटर्न 1: Native RadSec

यदि आपका इन्फ्रास्ट्रक्चर इसका नेटिव रूप से समर्थन करता है (जैसे, FreeRADIUS 3.0+, Cisco ISE, Aruba ClearPass), तो आप सीधे RADIUS सर्वर और एक्सेस पॉइंट्स/कंट्रोलर्स पर TLS सर्टिफिकेट कॉन्फ़िगर करते हैं। यह एज से लेकर कोर तक सही एंड-टू-एंड एन्क्रिप्शन प्रदान करता है।

पैटर्न 2: RadSec Proxy

कई लीगेसी RADIUS सर्वर (विशेष रूप से Microsoft NPS) नेटिव रूप से RadSec का समर्थन नहीं करते हैं। इन एनवायरनमेंट में, एक प्रॉक्सी (जैसे कि radsecproxy) डिप्लॉय किया जाता है।

  1. लोकल लेग: AP लोकल प्रॉक्सी को स्टैंडर्ड UDP RADIUS भेजता है।
  2. WAN लेग: प्रॉक्सी ट्रैफ़िक को TLS में एनकैप्सुलेट करता है और इसे TCP 2083 पर अपस्ट्रीम सर्वर पर भेजता है।

यह पैटर्न आपको लीगेसी इन्फ्रास्ट्रक्चर को बदले बिना वाइड-एरिया ट्रैफ़िक को सुरक्षित करने की अनुमति देता है।

RadSec: कैसे RADIUS over TLS, WiFi ऑथेंटिकेशन सुरक्षा को बेहतर बनाता है - deployment checklist

Purple के साथ इंटीग्रेशन

Purple के Guest WiFi और WiFi Analytics प्लेटफ़ॉर्म एंटरप्राइज RADIUS इन्फ्रास्ट्रक्चर के साथ सहजता से इंटीग्रेट होते हैं। Connect लाइसेंस के तहत, Purple OpenRoaming के लिए एक मुफ्त आइडेंटिटी प्रोवाइडर के रूप में कार्य करता है, जहां स्थलों और सेंट्रल हब के बीच फेडरेशन ट्रैफ़िक को सुरक्षित करने के लिए RadSec एक अनिवार्य आवश्यकता है।

बेस्ट प्रैक्टिसेस

  1. सर्टिफिकेट लाइफसाइकिल मैनेजमेंट: म्यूचुअल TLS वैलिड सर्टिफिकेट पर निर्भर करता है। ऑटोमेटेड रिन्यूअल (जैसे, ACME के माध्यम से) और सख्त मॉनिटरिंग लागू करें। एक एक्सपायर्ड सर्टिफिकेट पूरे ऑथेंटिकेशन को ठप कर देगा।
  2. फ़ायरवॉल कॉन्फ़िगरेशन: सुनिश्चित करें कि TCP पोर्ट 2083 को स्थल से आउटबाउंड और RADIUS सर्वर पर इनबाउंड दोनों के लिए स्पष्ट रूप से अनुमति दी गई है। यह मानकर न चलें कि मौजूदा UDP 1812 नियम लागू होंगे।
  3. हाई-रिस्क ट्रैफ़िक को प्राथमिकता दें: लोकल मैनेजमेंट VLANs पर जाने से पहले उन लिंक्स पर डिप्लॉयमेंट शुरू करें जो पब्लिक इंटरनेट या अनट्रस्टेड WANs से गुजरते हैं।

एज को सुरक्षित करने के बारे में अधिक जानने के लिए, Access Point Security: Your 2026 Enterprise Guide पर हमारा गाइड पढ़ें।

ट्रबलशूटिंग और रिस्क मिटिगेशन

जब RadSec विफल होता है, तो यह शायद ही कभी ऑथेंटिकेशन की समस्या होती है - यह लगभग हमेशा एक TLS या TCP की समस्या होती है।

  • लक्षण: एक्सेस पॉइंट्स RADIUS सर्वर से डिस्कनेक्टेड दिखाई देते हैं।
    • चेक: TCP 2083 के लिए फ़ायरवॉल नियम। ट्रेडिशनल RADIUS, UDP का उपयोग करता है - नेटवर्क टीमें अक्सर TCP पोर्ट खोलना भूल जाती हैं।
  • लक्षण: TCP कनेक्शन स्थापित होता है, लेकिन ऑथेंटिकेशन तुरंत विफल हो जाता है।
    • जांचें: सर्टिफिकेट सत्यापन। सत्यापित करें कि Common Name (CN) या Subject Alternative Name (SAN) मेल खाता है, सर्टिफिकेट समाप्त नहीं हुआ है, और क्लाइंट साइनिंग CA पर भरोसा करता है। हैंडशेक को डीबग करने के लिए openssl s_client -connect <server>:2083 का उपयोग करें।

सुनिश्चित करें कि आपके नेटवर्क के बुनियादी सिद्धांत मजबूत हैं। Protect Your Network with Strong DNS and Security पर हमारी सलाह की समीक्षा करें।

ROI और व्यावसायिक प्रभाव

RadSec को लागू करना जोखिम को कम करने का एक निवेश है। ROI का मूल्यांकन डेटा लीक, अनुपालन उल्लंघन के जुर्माने (PCI-DSS, GDPR), और प्रतिष्ठा के नुकसान से बचने के आधार पर किया जाता है। इसके अलावा, यह OpenRoaming जैसे आधुनिक रोमिंग महासंघों में भागीदारी को सक्षम बनाता है, जो Healthcare और Transport परिवेशों में अतिथि अनुभव को काफी बेहतर बना सकता है।

ब्रीफिंग सुनें

RadSec को तैनात करने की परिचालन वास्तविकताओं के बारे में गहराई से जानने के लिए, हमारी 10 मिनट की तकनीकी ब्रीफिंग सुनें:

क्लाइंट डिवाइसों पर विशिष्ट कॉन्फ़िगरेशन चरणों के लिए, How to Set Up Enterprise WiFi on iOS and macOS with 802.1X देखें।

मुख्य परिभाषाएं

RadSec

RADIUS प्रोटोकॉल का एक विस्तार जो TCP पोर्ट 2083 पर TLS टनल के भीतर RADIUS ट्रैफ़िक को एनकैप्सुलेट करता है।

अविश्वसनीय नेटवर्क से गुजरते समय ऑथेंटिकेशन ट्रैफ़िक को सुरक्षित करने, क्रेडेंशियल इंटरसेप्शन को रोकने के लिए उपयोग किया जाता है।

म्युचुअल TLS (mTLS)

एक सुरक्षा प्रक्रिया जहां क्लाइंट और सर्वर दोनों एक एन्क्रिप्टेड कनेक्शन स्थापित करने से पहले एक-दूसरे की पहचान सत्यापित करने के लिए X.509 प्रमाणपत्र प्रस्तुत करते हैं।

RadSec का मुख्य ऑथेंटिकेशन तंत्र, जो स्थिर साझा रहस्यों (shared secrets) पर निर्भरता को प्रतिस्थापित करता है।

802.1X

पोर्ट-आधारित नेटवर्क एक्सेस कंट्रोल के लिए IEEE मानक, जिसका उपयोग LAN या WLAN से कनेक्ट करने का प्रयास करने वाले उपकरणों को ऑथेंटिकेट करने के लिए किया जाता है।

वह ढांचा जो निर्देशिका (directory) के खिलाफ उपयोगकर्ता क्रेडेंशियल को मान्य करने के लिए RADIUS (और विस्तार से, RadSec) पर निर्भर करता है।

radsecproxy

एक ओपन-सोर्स डेमन जो एक प्रॉक्सी के रूप में कार्य करता है, जो मानक UDP RADIUS ट्रैफ़िक को RadSec (TCP पर TLS) में और इसके विपरीत परिवर्तित करता है।

तब तैनात किया जाता है जब एक्सेस पॉइंट्स या विरासत RADIUS सर्वर जैसे Microsoft Entra ID (NPS) से नेटिव RadSec समर्थन गायब होता है।

OpenRoaming

WiFi Alliance द्वारा विकसित एक फेडरेशन मानक जो उपयोगकर्ताओं को वैश्विक स्तर पर भाग लेने वाले WiFi नेटवर्क से निर्बाध और सुरक्षित रूप से कनेक्ट होने की अनुमति देता है।

OpenRoaming स्थानों और पहचान प्रदाताओं के बीच ऑथेंटिकेशन ट्रैफ़िक को सुरक्षित करने के लिए RadSec के उपयोग को अनिवार्य करता है।

Shared Secret (साझा रहस्य)

पारंपरिक RADIUS में पासवर्ड को अस्पष्ट करने और अनुरोधों के स्रोत को सत्यापित करने के लिए उपयोग की जाने वाली एक स्थिर टेक्स्ट स्ट्रिंग।

बैकवर्ड कम्पेटिबिलिटी के लिए RadSec कॉन्फ़िगरेशन में तकनीकी रूप से अभी भी मौजूद होने के बावजूद, इसे TLS एन्क्रिप्शन द्वारा प्रतिस्थापित कर दिया गया है।

FreeRADIUS

एक व्यापक रूप से तैनात ओपन-सोर्स RADIUS सर्वर जो RadSec के लिए नेटिव समर्थन प्रदान करता है।

इसकी लचीलेपन और नेटिव TLS क्षमताओं के कारण अक्सर एंटरप्राइज़ वातावरण और रोमिंग फेडरेशन में उपयोग किया जाता है।

PKI (पब्लिक की इन्फ्रास्ट्रक्चर)

डिजिटल प्रमाणपत्रों को बनाने, प्रबंधित करने, वितरित करने और निरस्त करने के लिए आवश्यक भूमिकाओं, नीतियों और सॉफ़्टवेयर का ढांचा।

RadSec को तैनात करने के लिए एक पूर्वापेक्षा, क्योंकि आपको सभी RADIUS क्लाइंट और सर्वर के लिए प्रमाणपत्र जारी और प्रबंधित करने होंगे।

हल किए गए उदाहरण

एक 200-संपत्ति वाला होटल समूह स्टाफ ऑथेंटिकेशन के लिए केंद्रीय रूप से Microsoft Entra ID (NPS) का उपयोग करता है। प्रत्येक होटल के एक्सेस पॉइंट्स वर्तमान में UDP 1812 के माध्यम से सार्वजनिक इंटरनेट पर RADIUS अनुरोध भेजते हैं। CTO सभी ऑथेंटिकेशन ट्रैफ़िक के लिए एन्क्रिप्शन को अनिवार्य करता है, लेकिन इस वर्ष NPS को बदलना एक विकल्प नहीं है।

प्रत्येक होटल साइट पर एक RadSec प्रॉक्सी (जैसे, radsecproxy) और NPS सर्वर के सामने केंद्रीय डेटा सेंटर में एक संबंधित प्रॉक्सी तैनात करें। स्थानीय APs स्थानीय प्रॉक्सी को UDP RADIUS भेजते हैं। स्थानीय प्रॉक्सी इंटरनेट पर केंद्रीय प्रॉक्सी के लिए TCP 2083 पर एक म्युचुअल TLS टनल स्थापित करता है। केंद्रीय प्रॉक्सी TLS टनल को समाप्त करता है और मानक UDP RADIUS को NPS सर्वर पर फॉरवर्ड करता है।

परीक्षक की टिप्पणी: यह दृष्टिकोण मुख्य सुरक्षा लक्ष्य को प्राप्त करता है - अविश्वसनीय WAN पर ऑथेंटिकेशन डेटा को एन्क्रिप्ट करना - कोर Microsoft Entra ID (NPS) इन्फ्रास्ट्रक्चर के महंगे और विघटनकारी बदलाव की आवश्यकता के बिना। यह प्रॉक्सी के लिए प्रमाणपत्र प्रबंधन ओवरहेड का परिचय देता है, जिसे स्वचालित किया जाना चाहिए।

एक बड़ा विश्वविद्यालय अपने परिसर में OpenRoaming तैनात कर रहा है ताकि आने वाले शिक्षाविदों के लिए निर्बाध पहुंच की अनुमति दी जा सके। वे FreeRADIUS 3.0 चला रहे हैं।

FreeRADIUS के भीतर नेटिव RadSec सक्षम करें। OpenRoaming फेडरेशन द्वारा विश्वसनीय CA से X.509 प्रमाणपत्र जेनरेट करें। फेडरेशन हब के लिए इनबाउंड और आउटबाउंड TCP 2083 ट्रैफ़िक की अनुमति देने के लिए कैंपस फ़ायरवॉल को कॉन्फ़िगर करें। फेडरेशन-बाउंड सभी ऑथेंटिकेशन अनुरोधों के लिए RadSec का उपयोग करने के लिए वायरलेस LAN कंट्रोलर को कॉन्फ़िगर करें।

परीक्षक की टिप्पणी: चूंकि FreeRADIUS नेटिव रूप से RadSec का समर्थन करता है, इसलिए किसी प्रॉक्सी की आवश्यकता नहीं है। यह सबसे साफ आर्किटेक्चर है। यहाँ महत्वपूर्ण निर्भरता यह सुनिश्चित करना है कि प्रमाणपत्र OpenRoaming फेडरेशन की विशिष्ट PKI आवश्यकताओं के साथ संरेखित हों।

अभ्यास प्रश्न

Q1. आपकी टीम ने आपके रिमोट ब्रांच एक्सेस पॉइंट्स और आपके केंद्रीय FreeRADIUS सर्वर के बीच मूल RadSec तैनात किया है। APs सर्वर को पिंग कर सकते हैं, लेकिन प्रमाणीकरण अनुरोध पूरी तरह से टाइम आउट हो रहे हैं, और RADIUS लॉग में कोई ट्रैफ़िक नहीं आ रहा है।

संकेत: RadSec पारंपरिक RADIUS की तुलना में एक अलग ट्रांसपोर्ट प्रोटोकॉल और पोर्ट का उपयोग करता है।

मॉडल उत्तर देखें

फ़ायरवॉल संभवतः TCP पोर्ट 2083 को ब्लॉक कर रहा है। पारंपरिक RADIUS के आदी नेटवर्क टीमें अक्सर केवल UDP पोर्ट 1812/1813 की अनुमति देती हैं। आपको शाखा से आउटबाउंड और RADIUS सर्वर पर इनबाउंड के लिए स्पष्ट रूप से TCP 2083 की अनुमति देनी होगी।

Q2. आप एक रिटेल क्लाइंट के WiFi आर्किटेक्चर का ऑडिट कर रहे हैं। वे केंद्रीय रूप से Microsoft NPS का उपयोग करते हैं। उनके स्टोर APs एक IPsec VPN के माध्यम से इंटरनेट पर प्रमाणीकरण अनुरोध भेजते हैं। क्या यहाँ RadSec की आवश्यकता है?

संकेत: पहले से मौजूद एन्क्रिप्शन की परतों पर विचार करें।

मॉडल उत्तर देखें

हालांकि RadSec सर्वोत्तम अभ्यास है, IPsec VPN पहले से ही असुरक्षित इंटरनेट पर UDP RADIUS ट्रैफ़िक के लिए ट्रांसपोर्ट लेयर एन्क्रिप्शन प्रदान कर रहा है। यहाँ RadSec तैनात करना डिफेंस-इन-डेप्थ प्रदान करेगा लेकिन यह उससे कम जरूरी है जब ट्रैफ़िक मूल रूप से इंटरनेट से गुजर रहा हो।

Q3. एक सफल RadSec प्रॉक्सी तैनाती के एक सप्ताह बाद, पूरे उद्यम में सभी WiFi प्रमाणीकरण सोमवार को सुबह 09:00 बजे एक साथ विफल हो जाते हैं। नेटवर्क टीम पुष्टि करती है कि फ़ायरवॉल नियम अपरिवर्तित हैं।

संकेत: स्वयं TLS टनल के लिए प्राथमिक प्रमाणीकरण तंत्र क्या है?

मॉडल उत्तर देखें

पारस्परिक TLS प्रमाणीकरण के लिए उपयोग किए जाने वाले X.509 प्रमाणपत्र संभवतः समाप्त हो गए हैं। जब प्रमाणपत्र समाप्त हो जाते हैं, तो TLS हैंडशेक विफल हो जाता है, TCP कनेक्शन टूट जाता है, और RADIUS ट्रैफ़िक प्रवाहित नहीं हो पाता है। इसे रोकने के लिए स्वचालित प्रमाणपत्र निगरानी और रोटेशन लागू करें।

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

RadSec (RFC 6614) क्या है और यह विरासत RADIUS से कैसे भिन्न है?

RadSec TCP पोर्ट 2083 पर एक सुरक्षित TLS 1.3 टनल के अंदर मानक RADIUS प्रमाणीकरण, प्राधिकरण और लेखांकन (AAA) डेटाग्राम को एनकैप्सुलेट करता है। विरासत RADIUS (RFC 2865) MD5-हैशेड शेयर्ड सीक्रेट्स के साथ कनेक्शन रहित UDP पोर्ट 1812 और 1813 पर निर्भर करता है, जिससे पैकेट ईव्सड्रॉपिंग, पैकेट परिवर्तन और UDP विखंडन के संपर्क में आते हैं। RadSec वायरलेस कंट्रोलर और क्लाउड RADIUS सर्वर के बीच पारस्परिक TLS (mTLS) प्रमाणपत्र सत्यापन, कनेक्शन कीप-अलाइव्स और एन्क्रिप्टेड WAN ट्रांसपोर्ट पेश करता है।

RadSec BlastRADIUS भेद्यता के खिलाफ एंटरप्राइज WiFi को कैसे सुरक्षित रखता है?

BlastRADIUS (CVE-2024-3596) लेगेसी RFC 2865 Access-Request पैकेटों में MD5 क्रिप्टोग्राफिक कोलिजन का फायदा उठाता है, जिससे WAN पथ पर हमलावर बिना शेयर्ड सीक्रेट जाने वैध Access-Accept प्रतिक्रियाएं बना सकते हैं। चूंकि RadSec पूरी RADIUS सेशन को एक प्रमाणित, एन्क्रिप्टेड TLS 1.3 स्ट्रीम के अंदर रैप करता है, इसलिए हमलावर पैकेट पेलोड या एट्रिब्यूट की जांच या हेरफेर नहीं कर सकते, जिससे MD5 जालसाजी और मैन-इन-द-मिडल हमले निष्क्रिय हो जाते हैं।

RadSec WAN लिंक पर EAP-TLS पैकेट फ्रैगमेंटेशन समस्याओं को क्यों समाप्त करता है?

सर्टिफिकेट-आधारित 802.1X EAP-TLS ऑथेंटिकेशन में, क्लाइंट और इंटरमीडिएट सर्टिफिकेट चेन अक्सर मानक 1500-बाइट Ethernet MTU से अधिक हो जाते हैं। UDP पर, खंडित RADIUS पैकेटों को इंटरमीडिएट इंटरनेट सेवा प्रदाताओं, कॉर्पोरेट फ़ायरवॉल और कैरियर NAT गेटवे द्वारा नियमित रूप से ड्रॉप कर दिया जाता है। RadSec TCP Path MTU Discovery (PMTU) और TCP सेगमेंटेशन का उपयोग करता है, जिससे यह सुनिश्चित होता है कि बड़ी सर्टिफिकेट चेन बिना किसी पैकेट नुकसान या कंट्रोलर टाइमआउट के आसानी से ट्रांसफर हो जाएं।

RadSec में निरंतर TCP कनेक्शन पूलिंग ऑथेंटिकेशन लेटेंसी को कैसे कम करती है?

हर ऑथेंटिकेशन अनुरोध के लिए एक नया TCP थ्री-वे हैंडशेक और TLS की एक्सचेंज करने के बजाय, आधुनिक एंटरप्राइज कंट्रोलर और RadSec प्रॉक्सी लगातार कनेक्शन पूल स्थापित करते हैं। एक बार स्थापित होने के बाद, कई 802.1X ऑथेंटिकेशन खुले TLS सॉकेट का पुन: उपयोग करते हैं। यदि WAN पर कोई पैकेट ड्रॉप हो जाता है, तो TCP सेलेक्टिव एक्नॉलेजमेंट (SACK) खोए हुए सेगमेंट को 1 से 2 राउंड ट्रिप (~70ms) के भीतर पुनः प्रसारित करता है, जिससे UDP RADIUS में आम होने वाले मल्टी-सेकंड एप्लिकेशन टाइमआउट स्टॉल से बचा जा सकता है।

RadSec को डिप्लॉय करने के लिए किस म्यूचुअल सर्टिफिकेट ऑथेंटिकेशन (mTLS) की आवश्यकता होती है?

RFC 6614 द्विदिश X.509 सर्टिफिकेट सत्यापन को अनिवार्य बनाता है। वायरलेस एक्सेस कंट्रोलर एक विश्वसनीय एंटरप्राइज CA बंडल का उपयोग करके क्लाउड RADIUS FQDN (radius1.purplewifi.net) के विरुद्ध सर्वर सर्टिफिकेट सब्जेक्ट अल्टरनेटिव नेम (SAN) को सत्यापित करता है। इसके विपरीत, क्लाउड RADIUS सर्वर कंट्रोलर क्लाइंट सर्टिफिकेट और प्राइवेट की को सत्यापित करता है, जिससे यह सुनिश्चित होता है कि केवल अधिकृत नेटवर्क हार्डवेयर ही ऑथेंटिकेशन अनुरोध सबमिट कर सकें।

RadSec डिप्लॉयमेंट के लिए कौन से फ़ायरवॉल नियम और नेटवर्क पोर्ट आवश्यक हैं?

नेटवर्क एडमिनिस्ट्रेटर को वायरलेस LAN कंट्रोलर या एज एक्सेस पॉइंट से क्लाउड RADIUS एंडपॉइंट्स की ओर जाने वाले आउटबाउंड TCP पोर्ट 2083 ट्रैफ़िक की अनुमति देनी होगी। लेगेसी UDP RADIUS के विपरीत, जिसमें UDP 1812 और 1813 पर स्टेटफुल NAT पिनहोल्स की आवश्यकता होती है जो अक्सर 30 सेकंड की निष्क्रियता के बाद समाप्त हो जाते हैं, RadSec स्वचालित एप्लिकेशन-लेयर कीप-अलाइव प्रोब्स द्वारा बनाए रखे गए एक सिंगल आउटबाउंड TCP स्ट्रीम का उपयोग करता है।

इस श्रृंखला में आगे पढ़ें

CIPA अनुपालन: वेन्यू ऑपरेटरों के लिए अनुपालन चेकलिस्ट

आप यह तय कर सकेंगे कि CIPA आपके WiFi को बाध्य करता है या नहीं, फिर नेटवर्क को विभाजित करें, DNS को Purple Shield के माध्यम से रूट करें और बाईपास मार्गों को बंद करें। आपको यह भी पता चल जाएगा कि Form 486 या Form 479 प्रमाणन के लिए कौन से साक्ष्य रखने हैं। चेकलिस्ट प्रत्येक आवश्यकता के लिए एक मालिक सौंपती है, ताकि आपके अगले फंडिंग वर्ष के प्रमाणन में कुछ भी न छूटे।

गाइड पढ़ें →

WPA3 transition mode कनेक्शन विफलताएं: Cisco Meraki, HPE Aruba और Ruckus के लिए एक डिप्लॉयमेंट चेकलिस्ट

इस चेकलिस्ट का उपयोग यह पता लगाने के लिए करें कि डिवाइस WPA3 SAE transition mode SSID पर क्यों विफल हो रहे हैं और इसे Cisco Meraki, HPE Aruba या Ruckus पर ठीक करें। आप 802.11 स्टेटस कोड को कारणों से मिलाएंगे, PMF, 802.11r और 6GHz समस्याओं को अलग करेंगे, और यह तय करेंगे कि कब केवल-WPA3 SSID पर स्विच करना है।

गाइड पढ़ें →

बेस्ट DNS filtering: व्यवसायों के लिए एक व्यापक गाइड

यह तकनीकी संदर्भ गाइड बताती है कि कैसे एंटरप्राइज़ DNS filtering - कनेक्शन स्थापित होने से पहले - रिज़ॉल्यूशन लेयर पर दुर्भावनापूर्ण डोमेन को ब्लॉक करके सार्वजनिक नेटवर्क को सुरक्षित करता है। यह IT निदेशकों, नेटवर्क आर्किटेक्ट्स और वेन्यू ऑपरेशंस टीमों को वह डिप्लॉयमेंट आर्किटेक्चर, फ़ायरवॉल कॉन्फ़िगरेशन और अनुपालन संदर्भ प्रदान करता है जिसकी उन्हें हॉस्पिटैलिटी, रिटेल और सार्वजनिक क्षेत्र के वातावरण में Guest WiFi की सुरक्षा के लिए आवश्यकता होती है। Purple Shield 80,000+ से अधिक लाइव वेन्यू पर DNS स्तर पर मालवेयर, बॉटनेट्स और अनुपयुक्त सामग्री को ब्लॉक करता है।

गाइड पढ़ें →

अपने विशिष्ट सेटअप को लेकर कोई सवाल हैं?

हमारी टीम 80,000 से अधिक वेन्यू में वेन्यू ऑपरेटरों, IT मैनेजरों और नेटवर्क इंजीनियरों के साथ काम करती है। 20 मिनट का कॉल बुक करें और हम आपको दिखाएंगे कि आपके जैसे अन्य लोगों ने इसे कैसे हल किया।