सुरक्षित Guest WiFi नेटवर्क्स: सर्वोत्तम पद्धती आणि अंमलबजावणी

पाहुण्यांच्या WiFi नेटवर्क्स सुरक्षित करणे: सर्वोत्तम पद्धती आणि अंमलबजावणी. Purple WiFi इंटेलिजन्स ब्रीफिंग. प्रस्तावना आणि संदर्भ. स्वागत आहे. आपण जर हे ऐकत असाल, तर आपण बहुधा आयटी व्यवस्थापक, नेटवर्क आर्किटेक्ट किंवा CTO असाल ज्यांच्यावर आपल्या पाहुण्यांच्या WiFi ला वापरण्यायोग्य आणि सुरक्षित अशा दोन्ही प्रकारे तयार करण्याचे काम सोपवले गेले आहे — आणि आपल्याला काम करण्यासाठी स्पष्ट, अंमलबजावणीयोग्य आराखड्याची आवश्यकता आहे. आज आपण नेमक्या याच गोष्टींवर चर्चा करणार आहोत. पाहुण्यांचे WiFi आता केवळ एक अतिरिक्त सोय राहिलेली नाही. ही इन्फ्रास्ट्रक्चरचा एक अत्यंत महत्त्वाचा भाग आहे जो ग्राहक अनुभव, डेटा अनुपालन आणि नेटवर्क सुरक्षा यांच्या केंद्रस्थानी आहे. आणि यातील जोखीम बहुतांश संस्थांच्या कल्पनेपेक्षा बरीच जास्त आहे. अयोग्यरित्या विभागलेले पाहुण्यांचे नेटवर्क हल्लेखोराला आपल्या कॉर्पोरेट सिस्टम्समध्ये प्रवेश मिळवून देऊ शकते. चुकीच्या पद्धतीने कॉन्फिगर केलेले Captive Portal आपल्याला GDPR च्या दायित्वाखाली आणू शकते. आणि बँडविड्थ मॅनेजमेंट नसलेले नेटवर्क पीक अवर्समध्ये आपल्या कामकाजाला पूर्णपणे ठप्प करू शकते. पुढील दहा मिनिटांत, आपण आर्किटेक्चर, ऑथेंटिकेशन पर्याय, अनुपालन आवश्यकता आणि सुरक्षित, उत्तम रीतीने चालवल्या जाणाऱ्या गेस्ट नेटवर्कला एका मोठ्या धोक्यापासून वेगळे करणाऱ्या ऑपरेशनल पद्धतींचा सविस्तर आढावा घेणार आहोत. तांत्रिक सखोल विश्लेषण. चला, पायापासून सुरुवात करूया: नेटवर्कचे विभाजन (नेटवर्क सेगमेंटेशन). पाहुण्यांचे WiFi तैनात करताना आपण करू शकत असलेली सर्वात महत्त्वाची गोष्ट म्हणजे आपल्या गेस्ट नेटवर्क आणि कॉर्पोरेट इन्फ्रास्ट्रक्चर यांच्यात पूर्ण विलगीकरण (आयसोलेशन) सुनिश्चित करणे. ही केवळ एक चांगली पद्धत नाही — तर आपण त्याच फिजिकल इन्फ्रास्ट्रक्चरवर कुठेही कार्ड पेमेंटवर प्रक्रिया करत असल्यास, PCI-DSS सारख्या फ्रेमवर्क्स अंतर्गत ही एक मूलभूत आवश्यकता आहे. यासाठीचा मानक दृष्टिकोन म्हणजे VLAN वर आधारित विभाजन. आपण आपले गेस्ट ट्रॅफिक एका समर्पित VLAN ला नियुक्त करता — साधारणपणे VLAN 30 सारखे — आणि आपले कॉर्पोरेट ट्रॅफिक एका वेगळ्या VLAN ला. हे VLAN नंतर मॅनेज्ड स्विच लेयरवर लागू केले जातात, ज्यामध्ये इंटर-VLAN राउटिंग एकतर पूर्णपणे अक्षम केले जाते किंवा फायरवॉल ACLs द्वारे काटेकोरपणे नियंत्रित केले जाते. गेस्ट VLAN कडे फक्त इंटरनेटचा मार्ग असला पाहिजे, इतर काहीही नाही. फाईल शेअर्समध्ये प्रवेश नाही, प्रिंटरमध्ये प्रवेश नाही आणि अंतर्गत टोपोलॉजी माहिती उघड करू शकणाऱ्या अंतर्गत DNS रिझॉल्व्हर्समध्ये प्रवेश नाही. मल्टिपल साइट्स चालवणाऱ्या संस्थांसाठी — उदाहरणार्थ, २०० स्टोअर्स असलेली रिटेल साखळी किंवा संपूर्ण युरोपमध्ये मालमत्ता असलेले हॉटेल ग्रुप — हे विभाजन प्रत्येक ॲक्सेस पॉइंट आणि इस्टेटमधील प्रत्येक स्विचवर सातत्याने लागू केले जाणे आवश्यक आहे. येथेच केंद्रीकृत व्यवस्थापन प्लॅटफॉर्म्स (सेंट्रलाइज्ड मॅनेजमेंट प्लॅटफॉर्म्स) आवश्यक बनतात. आपण शेकडो साइट्सवर मॅन्युअली VLAN कॉन्फिगरेशनचे ऑडिट करू शकत नाही. आपल्याला एका केंद्रीय कंट्रोलरवरून लागू केल्या जाणाऱ्या पॉलिसी अंमलबजावणीची आवश्यकता असते. आता, VLAN विभागणी व्यतिरिक्त, तुम्ही अतिथी VLAN मध्येच क्लायंट आयसोलेशन देखील तैनात केले पाहिजे. हे अतिथी डिव्हाइसेसना एकमेकांशी संवाद साधण्यापासून रोखते - जे विशेषतः हॉटेल आणि कॉन्फरन्स सेंटर्स सारख्या वातावरणात महत्वाचे आहे जिथे एकाच SSID शी कनेक्ट होणारे वैयक्तिक आणि कॉर्पोरेट डिव्हाइसेसचे मिश्रण असते. क्लायंट आयसोलेशन हे सहसा तुमच्या वायरलेस कंट्रोलरमधील एकच टिक बॉक्स असते, परंतु याकडे अनेकदा दुर्लक्ष केले जाते. आता captive portal कॉन्फिगरेशनकडे वळूया. अतिथी प्रवेशासाठी captive portal हा तुमचा मुख्य नियंत्रण बिंदू आहे. येथेच तुम्ही वापरकर्त्यांचे प्रमाणीकरण करता, संमती मिळवता आणि ते तुमच्या नेटवर्कमध्ये प्रवेश करत असलेल्या अटी स्थापित करता. चांगल्या प्रकारे केल्यास, हा काही सेकंदांचा अखंड अनुभव ठरतो. चुकीच्या पद्धतीने केल्यास, हा सपोर्ट कॉल्स, नियमांचे पालन न होण्याचा धोका आणि निराश अतिथींचे कारण बनतो. सुरक्षेच्या दृष्टिकोनातून, तुमचे captive portal HTTPS वरून दिले जाणे आवश्यक आहे. हे स्पष्ट वाटते, परंतु आश्चर्यकारकपणे अनेक उपयोजने अद्याप वापरकर्त्यांना प्रारंभिक प्रमाणीकरण चरणासाठी HTTP पृष्ठावर रिडायरेक्ट करतात. साध्या HTTP वरून दिलेले कोणतेही पोर्टल क्रेडेंशियल इंटरसेप्शन आणि कंटेंट इंजेक्शनसाठी असुरक्षित असते. वैध TLS प्रमाणपत्र वापरा - आदर्शपणे नामांकित प्रमाणपत्र प्राधिकरणाकडून - आणि तुमचे पोर्टल पोर्ट 443 वर प्रवेश करण्यायोग्य असल्याची खात्री करा. पोर्टल स्वतः DMZ मध्ये होस्ट केले जावे - एक डिमिलिटराइज्ड झोन जो तुमच्या अतिथी VLAN आणि इंटरनेट दरम्यान असतो. याचा अर्थ पोर्टल सर्व्हर अतिथी डिव्हाइसेसद्वारे प्रमाणीकृत होण्यापूर्वी पोहोचण्यायोग्य असतो, परंतु तो तुमच्या कॉर्पोरेट नेटवर्कवर नसतो. जर पोर्टल सर्व्हरशी तडजोड झाली, तर होणारा परिणाम मर्यादित राहतो. प्रमाणीकरण पद्धतींच्या बाबतीत, तुमच्याकडे अनेक पर्याय आहेत आणि योग्य पर्याय तुमच्या वापराच्या परिस्थितीवर अवलंबून असतो. सोशल लॉगिन - Google, Facebook किंवा Apple सारख्या प्रदात्यांद्वारे OAuth 2.0 वापरणे - हे रिटेल आणि हॉस्पिटॅलिटी सारख्या ग्राहकाभिमुख वातावरणासाठी सर्वात कमी त्रासाचा पर्याय आहे. वापरकर्ता विद्यमान खात्यासह प्रमाणीकरण करतो, तुम्हाला सत्यापित ओळख टोकन मिळते आणि तुम्ही प्रवाहाचा भाग म्हणून ईमेल पत्ता आणि नाव यासारखा प्रथम पक्ष डेटा गोळा करू शकता. येथील मुख्य तांत्रिक विचार असा आहे की तुम्ही तृतीय पक्ष ओळख प्रदात्यावर अवलंबून आहात, त्यामुळे तुम्हाला टोकनची मुदत संपणे आणि रद्द करणे व्यवस्थितपणे हाताळणे आवश्यक आहे. SMS पडताळणी - मोबाईल नंबरवर वन-टाइम पासकोड पाठवणे - हे एक मजबूत ओळख सिग्नल आहे कारण ते प्रवेशास भौतिक सिम कार्डशी जोडते. हे विशेषतः स्टेडियम, ट्रान्सपोर्ट हब किंवा सार्वजनिक क्षेत्रातील ठिकाणे यासारख्या वातावरणासाठी योग्य आहे जेथे तुम्हाला सत्यापित करण्यायोग्य ऑडिट ट्रेलची आवश्यकता असते. यामध्ये येणारा खर्च - मोठ्या प्रमाणावर SMS गेटवेचे शुल्क वाढते - आणि मोबाईल नंबरची आवश्यकता असल्यामुळे येणारा अडथळा हा याचा नकारात्मक पैलू आहे. ईमेल नोंदणी हा कॉन्फरन्स सेंटर्स आणि व्यावसायिक ठिकाणांसाठी सर्वात सामान्य दृष्टीकोन आहे. हा कमी खर्चाचा आहे, उपयुक्त विपणन माहिती गोळा करतो आणि GDPR संमती प्रवाहाशी नैसर्गिकरित्या समाकलित होतो. याची कमतरता अशी आहे की ईमेल पत्ते खोटे तयार करणे सोपे आहे, त्यामुळे ते SMS किंवा सोशल लॉगिनपेक्षा कमकुवत ओळख हमी प्रदान करते. वेळ-आधारित ॲक्सेस - म्हणजेच व्हाउचर कोड किंवा वेळ-मर्यादित टोकन्स जारी करणे - अशा ठिकाणी योग्य ठरते जिथे तुम्हाला वैयक्तिक डेटा गोळा करायचा नसतो. ग्रंथालये, NHS प्रतीक्षा कक्ष आणि काही सार्वजनिक क्षेत्रातील वातावरणे या श्रेणीत येतात. ॲक्सेस टोकन तयार केले जाते, वापरले जाते आणि कालबाह्य होते, ज्याच्याशी कोणतीही वैयक्तिकरित्या ओळखण्यायोग्य माहिती जोडलेली नसते. आपण तरीही कनेक्शन इव्हेंट्सचा ऑडिट लॉग ठेवता, परंतु तो कोणत्याही व्यक्तीशी जोडला जात नाही. आता आपण WPA3 बद्दल बोलूया. जर आपण नवीन ॲक्सेस पॉईंट्स तैनात करत असाल किंवा आपली वायरलेस इन्फ्रास्ट्रक्चर रिफ्रेश करत असाल, तर WPA3 हा आपला बेसलाईन एन्क्रिप्शन मानक असावा. WPA3-Personal हे Simultaneous Authentication of Equals - SAE - सादर करते जे WPA2 मध्ये वापरल्या जाणाऱ्या Pre-Shared Key हँडशेकची जागा घेते आणि ऑफलाइन डिक्शनरी हल्ल्यांच्या असुरक्षिततेला दूर करते. अतिथी नेटवर्कसाठी, WPA3-Enhanced Open - ज्याला OWE किंवा Opportunistic Wireless Encryption म्हणून देखील ओळखले जाते - हे विशेषतः संबंधित आहे. हे पासवर्डची आवश्यकता नसताना ओपन नेटवर्क्ससाठी एन्क्रिप्शन प्रदान करते, ज्याचा अर्थ असा की कोणत्याही ऑथेंटिकेशनचा अडथळा नसलेले नेटवर्क देखील डिव्हाइस आणि ॲक्सेस पॉईंट दरम्यानच्या ट्रॅफिकला एन्क्रिप्ट करते. जुन्या ओपन WiFi च्या तुलनेत ही एक महत्त्वपूर्ण सुधारणा आहे, जिथे सर्व ट्रॅफिक प्लेनटेक्स्टमध्ये प्रसारित केले जात होते. एंटरप्राइझ तैनातीसाठी जिथे आपण 802.1X ऑथेंटिकेशन वापरत आहात - विशेषतः हायब्रिड वातावरणात जिथे कर्मचारी आणि अतिथी फिजिकल इन्फ्रास्ट्रक्चर शेअर करतात - तिथे WPA3-Enterprise सह 192-bit मोड सर्वात मजबूत उपलब्ध सुरक्षा स्थिती प्रदान करतो. बँडविड्थ व्यवस्थापन हा एक ऑपरेशनल स्तर आहे ज्याकडे अनेकदा सुरक्षा चर्चांमध्ये दुर्लक्ष केले जाते, परंतु तो थेट उपलब्धतेशी संबंधित आहे - जी स्वतः एक सुरक्षा मालमत्ता आहे. अनमॅनेज्ड अतिथी नेटवर्क हे हाय-डेफिनिशन व्हिडिओ स्ट्रीमिंग करणाऱ्या एका युझरमुळे, चुकीच्या पद्धतीने कॉन्फिगर केलेल्या डिव्हाइसमुळे निर्माण होणाऱ्या ब्रॉडकास्ट स्टॉर्म्समुळे किंवा जाणीवपूर्वक केलेल्या डिनायल-ऑफ-सर्व्हिसच्या प्रयत्नांमुळे बँडविड्थ संपण्याच्या बाबतीत असुरक्षित असते. वायरलेस कंट्रोलर पातळीवर प्रति-युझर आणि प्रति-SSID बँडविड्थ मर्यादा लागू करा. आपल्या वापराच्या आवश्यकतेनुसार योग्य अपलोड आणि डाउनलोड मर्यादा सेट करा - सामान्य अतिथी ॲक्सेससाठी सामान्यत: प्रति युझर 5 ते 20 मेगाबिट्स प्रति सेकंद. QoS पॉलिसी सुरू करा ज्या मोठ्या प्रमाणात ट्रान्सफर करण्याऐवजी DNS आणि HTTPS ट्रॅफिकला प्राधान्य देतात. आणि कोणत्याही एका अतिथी डिव्हाइसला आपल्या अपलिंक क्षमतेचा असमान वाटा वापरण्यापासून रोखण्यासाठी फायरवॉलवर रेट लिमिटिंग कॉन्फिगर करा. अंमलबजावणीच्या शिफारसी आणि सामान्य चुका. मी तुम्हाला अंमलबजावणीचा तो क्रम सांगतो जो प्रत्यक्षात प्रभावीपणे काम करतो. आपल्या नेटवर्क डायग्रामपासून सुरुवात करा. आपण कोणत्याही उपकरणाला स्पर्श करण्यापूर्वी, आपल्या सध्याच्या टोपोलॉजीचे दस्तऐवजीकरण करा आणि अतिथी VLAN कुठे संपेल, फायरवॉल नियम कुठे लागू केले जातील आणि Captive Portal कुठे होस्ट केले जाईल हे अचूकपणे ओळखा. हे अगदी मूलभूत वाटते, परंतु अतिथी नेटवर्क तैनातीमधील बहुतेक सुरक्षा घटनांची मुळे अशा टोपोलॉजीमध्ये असतात ज्याचे कधीही योग्य दस्तऐवजीकरण केले गेले नव्हते. दुसरे, केवळ वायरलेस कंट्रोलरवरच नव्हे, तर स्विच लेयरवर VLAN सेगमेंटेशन लागू करा. कंट्रोलर्स बायपास किंवा चुकीच्या पद्धतीने कॉन्फिगर केले जाऊ शकतात. जर तुमचे मॅनेज्ड स्विचेस पोर्ट लेव्हलवर VLAN मेंबरशिप लागू करत असतील, तर तुम्हाला सखोल संरक्षण (defence in depth) मिळते. तिसरे, HTTPS, वैध सर्टिफिकेट आणि GDPR कलम १३ च्या आवश्यकता पूर्ण करणाऱ्या स्पष्ट गोपनीयता सूचनेसह तुमचे Captive Portal कॉन्फिगर करा. गो-लाइव्ह होण्यापूर्वी तुमच्या कायदेशीर टीमकडून संमतीच्या मजकुराला मंजुरी मिळणे आवश्यक आहे. चौथे, लॉगिंग लागू करा. प्रत्येक कनेक्शन इव्हेंट - डिव्हाइसचा MAC ॲड्रेस, टाइमस्टॅम्प, ऑथेंटिकेशन पद्धत, सेशनचा कालावधी - एका सेंट्रलाइज्ड लॉगमध्ये नोंदवला गेला पाहिजे. युकेच्या इन्व्हेस्टिगेटरी पॉवर्स ॲक्ट आणि इतर अधिकार क्षेत्रांमधील समतुल्य कायद्यांतर्गत, तुम्हाला हा डेटा १२ महिन्यांपर्यंत राखून ठेवण्याची आवश्यकता असू शकते. तुमची रिटेंशन पॉलिसी दस्तऐवजीकरण केलेली असल्याची आणि त्यानुसार तुमच्या स्टोरेजचा आकार योग्य असल्याची खात्री करा. पाचवे, तुमच्या सेगमेंटेशनची चाचणी घ्या. गेस्ट VLAN वरील डिव्हाइस वापरा आणि अंतर्गत संसाधने - तुमचे फाइल सर्व्हर, तुमचे अंतर्गत वेब ॲप्लिकेशन्स, तुमचे कॉर्पोरेट DNS - यांच्यापर्यंत पोहोचण्याचा प्रयत्न करा. तुम्ही कशापर्यंतही पोहोचू शकत असाल, तर तुमचे सेगमेंटेशन सदोष आहे. ही चाचणी तुमच्या गो-लाइव्ह चेकलिस्टचा आणि तुमच्या वार्षिक सुरक्षा पुनरावलोकनाचा भाग असावी. आता, धोके पाहूया. मला दिसणारा सर्वात सामान्य धोका म्हणजे संस्था गेस्ट WiFi चा विचार सर्वात शेवटी करतात - ते योग्य VLAN सेगमेंटेशनशिवाय त्यांच्या अस्तित्वात असलेल्या इन्फ्रास्ट्रक्चरमध्ये गेस्ट SSID जोडतात, आणि यामुळे गेस्ट नेटवर्क कॉर्पोरेट नेटवर्कच्या समान लेयर २ ब्रॉडकास्ट डोमेनवर संपते. हे सुरक्षा मॉडेलचे पूर्णपणे अपयश आहे. दुसरा धोका म्हणजे HTTP वर रिडायरेक्ट होणारे captive portals. हे त्वरित दुरुस्त करा. तिसरा म्हणजे क्लायंट आयसोलेशन नसणे. ३०० खोल्या असलेल्या हॉटेलमध्ये, जर क्लायंट आयसोलेशन निष्क्रिय असेल तर तुमच्याकडे ३०० संभाव्य अटॅक वेक्टर्स असतात. आणि चौथा धोका म्हणजे लॉगिंग नसणे. तुमच्याकडे सुरक्षेची घटना घडल्यास आणि लॉग्स उपलब्ध नसल्यास, तुमच्याकडे कोणतीही फॉरेन्सिक क्षमता नसते आणि संभाव्यतः कायदेशीर/नियमन विषयक समस्या निर्माण होऊ शकते. झटपट प्रश्न आणि उत्तरे. मी आधीच captive portal वापरत असल्यास मला WPA3 ची गरज आहे का? होय. Captive portal ऑथेंटिकेशन आणि संमती हाताळते. WPA3 रेडिओ लिंकच्या एन्क्रिप्शनचे काम करते. ते वेगवेगळ्या थ्रेट वेक्टर्सवर मात करतात आणि तुम्हाला दोन्हीची आवश्यकता आहे. मी गेस्ट आणि कॉर्पोरेट ट्रॅफिकसाठी समान फिजिकल ॲक्सेस पॉइंट्स वापरू शकतो का? होय, वेगवेगळ्या VLANs वर मॅप केलेले स्वतंत्र SSIDs वापरून. परंतु तुमचे ॲक्सेस पॉइंट्स दोन्ही नेटवर्कच्या थ्रूपुट आवश्यकतांना एकाच वेळी सपोर्ट करत असल्याची आणि तुमचा वायरलेस कंट्रोलर VLAN टॅगिंग अचूकपणे लागू करत असल्याची खात्री करा. मी माझ्या गेस्ट नेटवर्कचे क्रेडेंशियल्स किंवा SSID किती वेळा बदलले पाहिजेत? PSK-आधारित गेस्ट नेटवर्कसाठी, पासफ्रेज किमान त्रैमासिक बदला किंवा संशयास्पद तडजोड झाल्यानंतर लगेच बदला. प्रति-युझर ऑथेंटिकेशनसह captive portal नेटवर्कसाठी, वैयक्तिक सेशन टोकन्स आपोआप एक्सपायर होतात - SSID स्वतः बदलण्याची आवश्यकता नसते. किमान लॉग रिटेंशनचा कालावधी काय आहे? युके आणि ईयू दूरसंचार नियमांचे पालन करण्यासाठी बारा महिने ही प्रमाणित शिफारस आहे. तुमच्या विशिष्ट अधिकार क्षेत्राच्या आणि क्षेत्राच्या आवश्यकता तपासा. सारांश आणि पुढील पायऱ्या. थोडक्यात सांगायचे तर: सुरक्षित अतिथी WiFi उपयोजन चार स्तंभांवर अवलंबून असते. नेटवर्क विभाजन - अतिथी आणि कॉर्पोरेट ट्रॅफिक दरम्यान संपूर्ण VLAN विलगीकरण. Captive Portal सुरक्षा - HTTPS, वैध प्रमाणपत्रे, GDPR - सुसंगत संमती प्रवाह. प्रमाणीकरण - सोशल लॉगिन, SMS, ईमेल किंवा वेळ - आधारित टोकन यापैकी तुमच्या वापराच्या परिस्थितीशी जुळणारे. आणि कार्यात्मक नियंत्रणे - बँडविड्थ व्यवस्थापन, क्लायंट विलगीकरण, केंद्रीकृत लॉगिंग आणि नियमित सुरक्षा चाचणी. ज्या संस्था हे योग्यरित्या व्यवस्थापित करतात त्या अतिथी WiFi कडे नंतरचा विचार न करता एक प्रथम श्रेणीची पायाभूत सुविधा म्हणून पाहतात. त्या त्यांच्या टोपोलॉजीचे दस्तऐवजीकरण करतात, त्यांच्या धोरणांची स्विच स्तरावर अंमलबजावणी करतात आणि त्यांच्या कॉन्फिगरेशनचे नियमितपणे ऑडिट करतात. तुम्ही नवीन उपयोजन सुरू करत असल्यास किंवा सध्याच्या उपयोजनाचे पुनरावलोकन करत असल्यास, पहिली गोष्ट म्हणजे ती विभाजन चाचणी चालवणे. तुमच्या अतिथी नेटवर्कवर एखादे डिव्हाइस ठेवा आणि अंतर्गत कशावर तरी पोहोचण्याचा प्रयत्न करा. तुम्हाला जे आढळेल ते तुम्हाला कुठून सुरुवात करायची आहे याबद्दल आवश्यक असलेली सर्व माहिती देईल. WPA3 अंमलबजावणीबद्दल अधिक माहितीसाठी, Purple चे WPA3-Enterprise अंमलबजावणीचे मार्गदर्शक हा एक उत्तम तांत्रिक संदर्भ आहे. आणि जर तुम्ही विशिष्ट अनुपालन आवश्यकता असलेल्या क्षेत्रात असाल - आरोग्य सेवा, वाहतूक, किरकोळ विक्री - तर तुमच्या वातावरणाला लागू होणाऱ्या बारकाव्यांसाठी Purple च्या उद्योग - विशिष्ट संसाधनांचे पुनरावलोकन करणे योग्य ठरेल. ऐकल्याबद्दल धन्यवाद. हे उपयुक्त वाटल्यास, तुमच्या नेटवर्क टीमसोबत शेअर करा. आणि तुम्ही अतिथी WiFi प्लॅटफॉर्मचे मूल्यांकन करत असल्यास, Purple चे WiFi इंटेलिजन्स प्लॅटफॉर्म एकाच उपयोजनामध्ये captive portal, विश्लेषण आणि अनुपालन स्तर हाताळते. माहिती समाप्त.