Captive Portal रीडायरेक्ट समस्यानिवारण: Guest WiFi कनेक्शन अपयश दूर करणे

जेव्हा अतिथी तुमच्या WiFi शी कनेक्ट होतात परंतु इंटरनेटवर प्रवेश करू शकत नाहीत, तेव्हा त्याचे कारण जवळजवळ नेहमीच चुकीचे कॉन्फिगर केलेले captive portal रिडायरेक्ट असते - कोणतीही हार्डवेअर त्रुटी नाही. हे मार्गदर्शक IT मॅनेजर्स, नेटवर्क आर्किटेक्ट्स आणि CTOs साठी OS-पातळीवरील कनेक्टिव्हिटी प्रोब्स आणि HSTS प्रमाणपत्र संघर्ष ते RADIUS ऑथोरायझेशन गॅप आणि DHCP संपण्यापर्यंतच्या संपूर्ण अपयशाच्या साखळीचे निदान आणि निराकरण करण्यासाठी सखोल तांत्रिक संदर्भ प्रदान करते. हे प्रत्येक अपयशाच्या पद्धतीला एका ठोस समाधानाशी मॅप करते आणि दाखवते की Purple चे हार्डवेअर-अज्ञेयवादी क्लाउड ओव्हरले Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet डिप्लॉयमेंट्स मधील या समस्या कशा दूर करते.

📖 9 मिनिट वाचन📝 2,237 शब्द🔧 2 सोडवलेली उदाहरणे❓ 3 सराव प्रश्न📚 9 महत्वाच्या व्याख्या

हे मार्गदर्शक ऐका

पॉडकास्ट ट्रान्सक्रिप्ट पहा

यजमान (युनायटेड किंगडम इंग्रजी, आत्मविश्वासी सल्लागार टोन):

Purple तांत्रिक ब्रीफिंगमध्ये आपले स्वागत आहे. आज आपण एंटरप्राइझ नेटवर्किंगमधील सर्वात सतत भेडसावणाऱ्या डोकेदुखींपैकी एका समस्येचे निराकरण करत आहोत: captive portal पुनर्निर्देशन (redirect) अयशस्वी होणे. जेव्हा आपले अतिथी WiFi कनेक्टेड असल्याचे दाखवते परंतु इंटरनेट प्रवेश नसतो, तेव्हा तुमचे अभ्यागत निराश होतात, तुमच्या हेल्पडेस्कवर तक्रारींचा पूर येतो आणि तुमची डेटा कॅप्चर धोरण ठप्प होते. या ब्रीफिंगमध्ये, आपण captive portals चे तांत्रिक आर्किटेक्चर समजून घेऊ, आधुनिक ऑपरेटिंग सिस्टम्स आणि ब्राउझर अनेकदा त्यांना का ब्लॉक करतात हे शोधू आणि या समस्यांचे कायमचे निराकरण करण्यासाठी तुम्हाला ठोस अंमलबजावणी धोरणे देऊ.

[विराम]

चला पार्श्वभूमी समजून घेऊया. तुम्ही शेकडो रिटेल लोकेशन्सवर Cisco Meraki किंवा HPE Aruba ऍक्सेस पॉइंट्स तैनात केले आहेत. हार्डवेअर मजबूत आहे. परंतु अतिथी तक्रार करतात की ते इंटरनेट ऍक्सेस करू शकत नाहीत. ते SSID निवडतात, त्यांच्या डिव्हाइसवर WiFi आयकॉन दिसतो, परंतु स्प्लॅश पेज कधीही दिसत नाही. किंवा त्याहून वाईट म्हणजे, त्यांना एक भयानक SSL प्रमाणपत्र त्रुटी दिसते.

असे का होते? हे ऑपरेटिंग सिस्टम्स इंटरनेट कनेक्टिव्हिटी कशी शोधतात यावर अवलंबून असते. जेव्हा एखादे डिव्हाइस नेटवर्कशी कनेक्ट होते, तेव्हा ते एका ज्ञात URL ला HTTP प्रोब पाठवते. iOS साठी, हे captive.apple.com आहे. Android साठी, हे connectivitycheck.gstatic.com आहे. Windows msftconnecttest.com वापरते. जर डिव्हाइसला मानक HTTP 200 OK प्रतिसाद मिळाला, तर ते गृहीत धरते की त्यास थेट इंटरनेट ऍक्सेस आहे. जर नेटवर्क गेटवेने त्या विनंतीला रोखले आणि दुसऱ्या URL वर HTTP 302 पुनर्निर्देशनासह प्रतिसाद दिला, तर ऑपरेटिंग सिस्टमला समजते की ते captive portal च्या मागे आहे. त्यानंतर ते स्प्लॅश पेज लोड करण्यासाठी स्यूडो-ब्राउझर उघडते.

अयशस्वी होण्याची प्रक्रिया सहसा या इंटरसेप्शन पॉइंटवर घडते.

[विराम]

अयशस्वी होण्याचा पहिला मुख्य मुद्दा म्हणजे नेटवर्क कनेक्टिव्हिटी स्टेटस इंडिकेटर प्रोब, किंवा NCSI. जर तुमचा फायरवॉल किंवा गेटवे या एन्क्रिप्ट न केलेल्या HTTP विनंत्यांना ब्लॉक करत असेल, तर ऑपरेटिंग सिस्टमला कधीही 302 पुनर्निर्देशन प्राप्त होत नाही. ते फक्त असे गृहीत धरते की नेटवर्क खराब आहे. हे दुरुस्त करण्यासाठी, आपण हे सुनिश्चित केले पाहिजे की आपल्या पूर्व-प्रमाणीकरण प्रवेश नियंत्रण सूची (ACLs) त्या विशिष्ट OS शोध URL ला HTTP ट्रॅफिकची अनुमती देतात.

दुसरी आणि वाढती सामान्य समस्या म्हणजे HTTP स्ट्रिक्ट ट्रान्सपोर्ट सिक्युरिटी, किंवा HSTS. आधुनिक ब्राउझर मुख्य डोमेनसाठी HTTPS लागू करतात. जर एखादा वापरकर्ता तुमच्या WiFi शी कनेक्ट झाला आणि ताबडतोब google.com उघडण्याचा प्रयत्न करत असेल, तर त्यांचा ब्राउझर एन्क्रिप्टेड कनेक्शनचा आग्रह धरतो. जेव्हा तुमचा गेटवे त्या HTTPS विनंतीला रोखतो आणि तिला captive portal वर पुनर्निर्देशित करण्याचा प्रयत्न करतो, तेव्हा ब्राउझरला मॅन-इन-द-मिडल (man-in-the-middle) हल्ला झाल्याचा संशय येतो. तुमच्या गेटवेने सादर केलेले प्रमाणपत्र google.com शी जुळत नाही. याचा परिणाम म्हणजे हार्ड ब्लॉक होतो. वापरकर्त्याला सुरक्षा चेतावणी दिसते आणि ते लॉगिन पृष्ठावर जाऊ शकत नाहीत.

यावर उपाय दुहेरी आहे. पहिले, आपण आत्ताच चर्चा केलेल्या OS-स्तरीय शोध यंत्रणेवर अवलंबून राहा. हे प्रमाणपत्र न जुळणे टाळण्यासाठी विशेषतः अनएन्क्रिप्टेड HTTP वापरतात. दुसरे, तुमचे वॉल्ड गार्डन (walled garden) कॉन्फिगरेशन निर्दोष असल्याची खात्री करा.

वॉल्ड गार्डन म्हणजे काय? ही अशा डोमेन्स आणि IP पत्त्यांची यादी आहे ज्यांवर पाहुणे प्रमाणित (authenticate) होण्यापूर्वी प्रवेश करू शकतात. तुम्ही Microsoft Entra ID किंवा Google Workspace द्वारे सोशल लॉगिन वापरत असल्यास, किंवा Stripe द्वारे पेमेंट प्रक्रियेत असल्यास, ते डोमेन्स तुमच्या वॉल्ड गार्डनमध्ये असणे आवश्यक आहे. ते नसल्यास, स्प्लॅश पेज लोड होऊ शकते, परंतु प्रमाणीकरण प्रक्रिया कोणत्याही सूचनेशिवाय अपयशी ठरेल.

[PAUSE]

आता आपण एका वास्तववादी परिस्थितीवर नजर टाकूया. McDonald's हजारो ठिकाणांवर लाखो ग्राहकांना सेवा देते. ते त्यांचे अतिथी WiFi व्यवस्थापित करण्यासाठी Purple वापरतात. जर त्यांचा सेशन टाइमआउट खूप लहान असेल, तर प्रदीर्घ दुपारच्या जेवणादरम्यान आपला फोन तपासणाऱ्या ग्राहकाला वारंवार पुन्हा प्रमाणित होण्यास भाग पाडले जाऊ शकते. यामुळे अनुभवाचा दर्जा खराब होतो. आम्ही आदरातिथ्य (hospitality) आणि किरकोळ विक्री (retail) वातावरणासाठी सेशनचा कालावधी 24 तास ठेवण्याची शिफारस करतो, ज्यामुळे परत येणाऱ्या उपकरणांना अखंडपणे ओळखण्यासाठी MAC address caching चा वापर करता येतो.

[PAUSE]

आता अंमलबजावणीच्या शिफारसींविषयी. Captive Portal तैनात करताना, तुम्ही DNS आणि HTTP ट्रॅफिक अचूकपणे अडवण्यासाठी तुमचे गेटवे कॉन्फिगर केले पाहिजे. तुम्ही Purple सारखे क्लाउड ओव्हरले वापरत असल्यास, तुमचे स्थानिक हार्डवेअर, मग ते Juniper Mist असो वा Ubiquiti UniFi, ते Purple RADIUS सर्व्हरपर्यंत पोहोचण्यास सक्षम असणे आवश्यक आहे.

येथे एक गंभीर त्रुटी उद्भवू शकते: DNS रिझोल्यूशन. अतिथीचे उपकरण तुमच्या captive portal च्या होस्टनेमचे निराकरण (resolve) करू शकत नसल्यास, रिडायरेक्ट अयशस्वी होते. तुमचा DHCP सर्व्हर विश्वासार्ह DNS पत्ते देतो याची खात्री करा आणि तुमचे गेटवे वॉल्ड गार्डनमधून DNS क्वेरी पाठवण्याची परवानगी देते की नाही हे तपासा.

शिवाय, भौतिक वातावरणाचा विचार करा. स्टेडियम किंवा मँचेस्टर एअरपोर्ट्स ग्रुप (Manchester Airports Group) सारखी ट्रॅव्हल हब यांसारख्या उच्च-घनतेच्या ठिकाणी एकाच वेळी हजारो कनेक्शनचे प्रयत्न हाताळले जातात. जर तुमचा स्थानिक DHCP पूल संपला, तर नवीन उपकरणे ऍक्सेस पॉइंटशी कनेक्ट होतील परंतु त्यांना IP पत्ता मिळणार नाही. ते कधीही captive portal टप्प्यापर्यंत पोहोचणार नाहीत. तुमच्या सबनेटचा आकार नेहमी पीक क्षमतेनुसार योग्य ठेवा आणि तात्पुरत्या अभ्यागत नेटवर्कसाठी लहान DHCP लीज वेळा वापरा.

[PAUSE]

आता सामान्य हेल्पडेस्क तिकिटांवर आधारित जलद प्रश्न आणि उत्तर सत्र.

प्रश्न एक: पोर्टल आयफोनवर चालते परंतु Android उपकरणांवर का अयशस्वी होते?

उत्तर: ही नक्कीच वॉल्ड गार्डनची समस्या आहे. तुम्ही कदाचित captive.apple.com ला व्हाईटलिस्ट केले असेल परंतु connectivitycheck.gstatic.com विसरला असाल. तुमच्या प्री-ऑथेंटिकेशन ऍक्सेस कंट्रोल लिस्ट अपडेट करा.

प्रश्न दोन: अतिथी यशस्वीरित्या प्रमाणित होतात, तरीही त्यांना इंटरनेट मिळत नाही. असे का?

उत्तर: तुमचे RADIUS कॉन्फिगरेशन तपासा. गेटवेला बहुधा RADIUS सर्व्हरकडून Access-Accept संदेश मिळत नाही, किंवा पोस्ट-ऑथेंटिकेशन फायरवॉल नियम ट्रॅफिक ब्लॉक करत आहेत. शेअर्ड सिक्रेट सत्यापित करा आणि पोर्ट 1812 आणि 1813 उघडे असल्याचे सुनिश्चित करा.

प्रश्न तीन: सुरक्षा चेतावणी टाळण्यासाठी आम्ही सुरुवातीच्या रिडायरेक्टसाठी HTTPS वापरू शकतो का?

उत्तर: नाही. प्रत्येक अतिथी उपकरणावर रूट प्रमाणपत्र स्थापित केल्याशिवाय तुम्ही प्रमाणपत्र त्रुटी न आणता HTTPS विनंती अडवू शकत नाही, जे सार्वजनिक WiFi साठी अशक्य आहे. पोर्टल ट्रिगर करण्यासाठी तुम्ही अनइनक्रिप्टेड HTTP OS प्रोब्सवरच अवलंबून राहिले पाहिजे.

[PAUSE]
संक्षिप्त सांगायचे तर: Captive portal मधील बिघाड क्वचितच हार्डवेअर त्रुटींमुळे होतात. ते सहसा redirect flow, walled garden किंवा DNS सेटिंग्जमधील कॉन्फिगरेशन विसंगतीमुळे असतात.

मुद्दा पहिला: प्रमाणीकरणापूर्वी OS detection URLs उपलब्ध असल्याची खात्री करा.

मुद्दा दुसरा: सर्व आवश्यक आयडेंटिटी प्रोव्हाइडर्स आणि कंटेंट डिलिव्हरी नेटवर्क्सचा समावेश करण्यासाठी तुमचा walled garden कॉन्फिगर करा.

मुद्दा तिसरा: तुमच्या गेटवे आणि ऑथेंटिकेशन प्लॅटफॉर्म दरम्यानच्या RADIUS कम्युनिकेशनची पडताळणी करा.

मुद्दा चौथा: पीक डेंसिटीसाठी तुमचे DHCP स्कोप्स योग्य आकाराचे ठेवा.

या घटकांवर प्रभुत्व मिळवून, तुम्ही कनेक्शनमधील अडथळे दूर करता. तुम्ही तुमच्या अभ्यागतांना निराश करणे थांबवता आणि ग्राहकांची निष्ठा आणि महसूल वाढवण्यासाठी आवश्यक असलेला फर्स्ट-पार्टी डेटा कॅप्चर करण्यास सुरुवात करता. Purple चे Identity-Based Networks ही प्रक्रिया सोपी करतात, एक हार्डवेअर-अज्ञेयवादी क्लाउड ओव्हरले प्रदान करतात जो जगभरातील ८०,००० हून अधिक थेट ठिकाणांवर RADIUS, captive portals आणि ॲनालिटिक्सची गुंतागुंत अखंडपणे हाताळतो.

या Purple टेक्निकल ब्रीफिंगमध्ये सामील झाल्याबद्दल धन्यवाद. अधिक तपशीलवार कॉन्फिगरेशन मार्गदर्शक आणि आर्किटेक्चर डायग्राम्ससाठी, purple.ai ला भेट द्या।

महत्वाचे मुद्दे

✓Captive Portal चे अपयश हे सहसा नेहमी कॉन्फिगरेशनच्या समस्यांमुळे असते - हार्डवेअरच्या त्रुटींमुळे नाही. रिडायरेक्ट साखळीत सहा टप्पे असतात आणि त्यातील कोणताही एक टप्पा खंडित होऊ शकतो.
✓प्रत्येक OS Captive Portals शोधण्यासाठी भिन्न HTTP प्रोब URL पाठवते. जर तुमच्या गेटवेने यापैकी कोणत्याही प्रोबला ब्लॉक केले, तर त्या OS ला स्प्लॅश पेज कधीही दिसत नाही.
✓Captive Portal रिडायरेक्शनसाठी HTTPS ट्रॅफिक इंटरसेप्ट करण्याचा कधीही प्रयत्न करू नका. HSTS मुळे गंभीर सर्टिफिकेट एरर्स येतात. OS च्या अन-एनक्रिप्टेड HTTP प्रोब्सवर अवलंबून रहा.
✓वॉल्ड गार्डन (walled garden) मध्ये ऑथेंटिकेशनपूर्वी OS प्रोब URL, आयडेंटिटी प्रोव्हायडर डोमेन्स (Microsoft Entra ID, Google Workspace), CDN ॲसेट्स आणि पेमेंट प्रोसेसर डोमेन्स समाविष्ट असणे आवश्यक आहे.
✓ऑथेंटिकेशन (लॉगिन फॉर्म पूर्ण करणे) आणि ऑथोरायझेशन (गेटवेने फायरवॉल नियम उघडणे) हे वेगवेगळे टप्पे आहेत. जर पोर्टल यश दर्शवत असेल परंतु इंटरनेट नसेल, तर गेटवे आणि Purple च्या सर्व्हरमधील RADIUS संवाद तुटलेला आहे.
✓अतिशय गर्दीच्या ठिकाणी, DHCP संपल्यामुळे Captive Portal बिघाडासारखीच लक्षणे उद्भवतात. पीक समवर्ती डिव्हाइस संख्येनुसार तुमच्या DHCP पूलचा आकार ठरवा आणि कमी लीझ वेळेचा वापर करा.
✓अंतिम मंजुरीपूर्वी प्रत्येक डिप्लॉयमेंटची iOS, Android, आणि Windows वर चाचणी घ्या. OS-विशिष्ट अपयश हे वॉल्ड गार्डनच्या त्रुटी दर्शवतात, मूलभूत चुकीचे कॉन्फिगरेशन नाही.

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

'guest WiFi connected but no internet' (गेस्ट WiFi कनेक्ट झाले आहे पण इंटरनेट नाही) ही क्वेरी एंटरप्राइझ नेटवर्किंगमधील सर्वात सामान्य सपोर्ट तिकिटांपैकी एक आहे. याचे लक्षण प्रत्येक पाहुण्याला दिसते; परंतु आयटी टीम्सना रीडायरेक्ट चेन समजल्याशिवाय याचे कारण सहसा समजत नाही. एक Captive Portal (ज्याला स्प्लॅश पेज किंवा हॉटस्पॉट गेटवे देखील म्हटले जाते) डिव्हाइसच्या सुरुवातीच्या HTTP कनेक्टिव्हिटी प्रोबला अडवते आणि लॉगिन पेजवर HTTP 302 रीडायरेक्ट जारी करते. जर या साखळीतील कोणतेही पाऊल खंडित झाले - जसे की ब्लॉक केलेले प्रोब्स, HSTS संघर्ष, वॉल्ड गार्डन त्रुटी, RADIUS अपयश किंवा DHCP संपुष्टात येणे - तर पाहुण्याला फक्त कनेक्ट केलेले WiFi आयकॉन दिसते आणि इंटरनेट चालत नाही. हे मार्गदर्शक तुम्हाला प्रत्येक बिघाड मोड, त्यामागील प्रोटोकॉल मेकॅनिक्स आणि ते सोडवणारे कॉन्फिगरेशन बदल समजून सांगेल. Purple 80,000+ पेक्षा जास्त लाइव्ह ठिकाणी कार्यरत आहे, दरवर्षी 440 दशलक्ष लॉगिन प्रक्रियेतून जात आहेत (Purple अंतर्गत डेटा, 2024), आणि येथे वर्णन केलेले पॅटर्न आम्ही हॉस्पिटॅलिटी, रिटेल, ट्रान्सपोर्ट आणि सार्वजनिक-क्षेत्रातील उपयोजनांमध्ये पाहत असलेली सर्वात वारंवार उद्भवणारी मूळ कारणे दर्शवतात.

तांत्रिक सखोल माहिती (Technical deep-dive)

Captive Portal डिटेक्शन प्रत्यक्षात कसे कार्य करते

इंटरनेट प्रवेश मंजूर करण्यापूर्वी नेटवर्कला ऑथेंटिकेशनची आवश्यकता आहे की नाही हे शोधण्यासाठी प्रत्येक प्रमुख ऑपरेटिंग सिस्टम अंगभूत यंत्रणेसह येते. या यंत्रणा समजून घेणे हा सर्व Captive Portal ट्रबलशूटिंगचा पाया आहे.

जेव्हा एखादे डिव्हाइस SSID शी जोडले जाते, तेव्हा OS पूर्व-निर्धारित URL वर एक न कूटबद्ध केलेली (unencrypted) HTTP GET विनंती पाठवते. खालील तक्त्यामध्ये प्लॅटफॉर्मनुसार प्रोब URL सूचीबद्ध केल्या आहेत.

ऑपरेटिंग सिस्टम	प्रोब URL	अपेक्षित प्रतिसाद
iOS / macOS	`http://captive.apple.com/hotspot-detect.html`	विशिष्ट बॉडीसह HTTP 200
Android (Google)	`http://connectivitycheck.gstatic.com/generate_204`	HTTP 204 नो कंटेंट
Windows (NCSI)	`http://www.msftconnecttest.com/connecttest.txt`	'Microsoft Connect Test' बॉडीसह HTTP 200
Chrome (सर्व प्लॅटफॉर्म)	`http://www.gstatic.com/generate_204`	HTTP 204 नो कंटेंट
Firefox	`http://detectportal.firefox.com/success.txt`	HTTP 200

जर गेटवेने या विनंत्यांपैकी एक अडवली आणि Captive Portal URL कडे निर्देशित करणारे HTTP 302 रीडायरेक्ट रिटर्न केले, तर OS ला समजते की ते एका पोर्टलच्या मागे आहे आणि स्प्लॅश पेज प्रदर्शित करण्यासाठी स्यूडो-ब्राउझर (एक हलका WebView) उघडते. जर प्रोब पूर्णपणे ब्लॉक केला असेल, तर OS 'No internet connection' चा अहवाल देते आणि पोर्टल उघडण्याचा कधीही प्रयत्न करत नाही. 'guest WiFi connected but no internet' या लक्षणाचे हे सर्वात सामान्य कारण आहे.

HSTS ची समस्या

HTTP Strict Transport Security (HSTS) हे RFC 6797 मध्ये परिभाषित केलेले वेब सुरक्षा धोरण आहे. ते ब्राउझरला डोमेनशी सर्व साधे HTTP कनेक्शन्स नाकारण्याचे आणि तंतोतंत जुळत नसलेले कोणतेही प्रमाणपत्र नाकारण्याचे निर्देश देते. google.com, facebook.com आणि बहुतेक बँकिंग साइट्ससह प्रमुख डोमेन Chrome, Firefox, Safari आणि Edge मध्ये अंगभूत असलेल्या HSTS प्रीलोड सूचीमध्ये समाविष्ट आहेत.

जेव्हा एखादा अतिथी ब्राउझर उघडतो आणि google.com टाईप करतो, तेव्हा ब्राउझर डिव्हाइस सोडण्यापूर्वी विनंती HTTPS वर अपग्रेड करतो. गेटवे HTTPS विनंतीला अडवू शकत नाही आणि ती यशस्वीरित्या पुनर्निर्देशित करू शकत नाही - त्याला google.com साठी एक प्रमाणपत्र सादर करावे लागेल, जे त्याच्याकडे उपलब्ध नसते. ब्राउझर प्रमाणपत्रातील तफावत ओळखतो आणि कडक सुरक्षा चेतावणी प्रदर्शित करतो. अतिथी पुढे लॉगिन पृष्ठावर जाऊ शकत नाही.

योग्य आर्किटेक्चर पूर्णपणे वर वर्णन केलेल्या OS-स्तरीय HTTP प्रोब्सवर अवलंबून असते. ते प्रोब्स विशेषतः नॉन-HSTS URL साठी साधे HTTP वापरतात जेणेकरून गेटवे प्रमाणपत्राच्या संघर्षांशिवाय त्यांना अडवू शकतील आणि पुनर्निर्देशित करू शकतील. तुमच्या गेटवेने हे HTTP प्रोब्स अडवले पाहिजेत आणि 302 रिडायरेक्ट जारी केले पाहिजे. Captive Portal च्या उद्देशांसाठी HTTPS ट्रॅफिक अडवण्याचा प्रयत्न करू नका.

द वॉल्ड गार्डन (The walled garden)

वॉल्ड गार्डन म्हणजे डोमेन आणि IP पत्त्यांचा असा संच ज्यावर एखादे डिव्हाइस प्रमाणीकरण करण्यापूर्वी प्रवेश करू शकते. वॉल्ड गार्डन खूप मर्यादित असल्यास, स्प्लॅश पृष्ठ लोड होऊ शकते परंतु प्रमाणीकरण अयशस्वी होईल. सामान्य त्रुटींमध्ये खालील गोष्टींचा समावेश होतो:

आयडेंटिटी प्रोव्हाइडर डोमेन: तुम्ही सोशल किंवा SSO लॉगिनसाठी Microsoft Entra ID, Okta किंवा Google Workspace वापरत असल्यास, त्यांचे प्रमाणीकरण एंडपॉइंट्स वॉल्ड गार्डनमध्ये असणे आवश्यक आहे.
CDN आणि ॲसेट डोमेन: तुमचे स्प्लॅश पृष्ठ कंटेंट डिलिव्हरी नेटवर्कवरून CSS, JavaScript किंवा फॉन्ट लोड करू शकते. हे CDN डोमेन ब्लॉक केलेले असल्यास, पृष्ठ योग्यरित्या लोड होत नाही.
पेमेंट प्रोसेसर डोमेन: तुम्ही Stripe किंवा इतर प्रोसेसरद्वारे प्रवेशासाठी शुल्क आकारत असल्यास, त्यांचे JavaScript SDK डोमेन आधीच प्रमाणीकृत (pre-authenticated) असणे आवश्यक आहे.
Purple प्लॅटफॉर्म डोमेन: Purple च्या क्लाउड ओव्हरलेला गेटवेने Purple च्या RADIUS सर्व्हर आणि पोर्टल एंडपॉइंट्सवर पोहोचणे आवश्यक असते. हे प्रत्येक समर्थित प्लॅटफॉर्मसाठी Purple च्या हार्डवेअर इंटिग्रेशन मार्गदर्शकांमध्ये दस्तऐवजीकरण केलेले आहेत.

RADIUS आणि ऑथोरायझेशन गॅप

RADIUS (Remote Authentication Dial-In User Service) हा प्रोटोकॉल आहे जो तुमच्या स्थानिक गेटवेला प्रमाणीकरण प्लॅटफॉर्मशी जोडतो. जेव्हा एखादा अतिथी लॉगिन फॉर्म पूर्ण करतो, तेव्हा Captive Portal RADIUS सर्व्हरला क्रेडेंशियल पाठवतो. RADIUS सर्व्हर Access-Accept किंवा Access-Reject संदेश पाठवतो. इंटरनेट प्रवेश देणारा फायरवॉल नियम उघडून किंवा बंद ठेवून गेटवे त्या संदेशावर कारवाई करतो.

ऑथोरायझेशन गॅप - जिथे अतिथी स्प्लॅश पृष्ठावर यशस्वीरित्या लॉगिन करतो परंतु तरीही इंटरनेट सुरू होत नाही - याचा अर्थ सहसा असा होतो की गेटवेला Access-Accept संदेश मिळाला नाही किंवा त्यावर प्रक्रिया झाली नाही. सामान्य कारणांमध्ये जुळत नसलेले शेअर्ड सिक्रेट, स्थानिक फायरवॉलद्वारे ब्लॉक केलेले UDP पोर्ट्स 1812 आणि 1813 किंवा गेटवेवर RADIUS सर्व्हरचा IP पत्ता चुकीचा कॉन्फिगर केलेला असणे यांचा समावेश होतो.

हाय-डेन्सिटी वातावरणात DHCP संपणे (DHCP exhaustion)

स्टेडियम, कॉन्फरन्स सेंटर्स आणि ट्रान्सपोर्ट हबमध्ये, DHCP संपणे हे कनेक्शन अयशस्वी होण्याचे एक वारंवार घडणारे कारण आहे, जे अगदी captive portal समस्येसारखेच दिसते. जर DHCP पूल पूर्ण असेल, तर नवीन डिव्हाइस ॲक्सेस पॉइंटशी जोडले जाते परंतु त्याला कधीही IP ॲड्रेस मिळत नाही. IP ॲड्रेसशिवाय, डिव्हाइस HTTP प्रोब पाठवू शकत नाही आणि captive portal पर्यंत कधीही पोहोचत नाही. डिव्हाइस SSID शी कनेक्ट केलेले दाखवते परंतु त्यावर इंटरनेट नसते.

Manchester Airports Group (MAG) सारख्या ठिकाणांसाठी, जिथे प्रवाशांची संख्या वेगाने उच्चांक गाठते, सबनेट्सचा आकार सरासरीऐवजी कमाल समवर्ती डिव्हाइस संख्येसाठी निश्चित केला पाहिजे. लहान DHCP लीझ वेळा (तात्पुरत्या अभ्यागतांच्या नेटवर्कसाठी 15 - 30 मिनिटे) गेलेल्या डिव्हाइसेसकडून ॲड्रेस त्वरित परत मिळवतात.

अंमलबजावणी मार्गदर्शक

जेव्हा Purple च्या क्लाउड ओव्हरलेशी समाकलित केले जाते, तेव्हा खालील पायऱ्या कोणत्याही हार्डवेअर प्लॅटफॉर्मला लागू होतात - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, किंवा Fortinet.

पायरी 1: बाह्य captive portal साठी SSID कॉन्फिगर करा. तुमच्या हार्डवेअर कंट्रोलरमध्ये, अनधिकृत क्लायंटना Purple च्या बाह्य पोर्टल URL वर रिडायरेक्ट करण्यासाठी गेस्ट SSID सेट करा. कंट्रोलरवरील कोणतेही स्थानिक स्प्लॅश पेज निष्क्रिय करा.

पायरी 2: walled garden परिभाषित करा. किमान खालील डोमेन जोडा: Purple चे पोर्टल आणि RADIUS एंडपॉइंट्स (तुमचे हार्डवेअर इंटिग्रेशन मार्गदर्शक पहा), वर सूचीबद्ध केलेल्या OS डिटेक्शन प्रोब URLs, तुमचे आयडेंटिटी प्रदाता डोमेन (Microsoft Entra ID, Okta, किंवा Google Workspace), आणि तुमच्या स्प्लॅश पेजची मालमत्ता वापरत असलेले कोणतेही CDN डोमेन.

पायरी 3: RADIUS कॉन्फिगर करा. Purple चे RADIUS सर्व्हर IP ॲड्रेस, तुमच्या Purple डॅशबोर्डमधील शेअर केलेले गुपित प्रविष्ट करा आणि ऑथेंटिकेशन पोर्ट 1812 आणि अकाउंटिंग पोर्ट 1813 वर सेट करा. तुमचे स्थानिक फायरवॉल या पोर्ट्सवर आउटबाउंड UDP ला अनुमती देते याची पडताळणी करा.

पायरी 4: सेशन पॅरामीटर्स सेट करा. हॉस्पिटॅलिटी आणि रिटेलसाठी, MAC ॲड्रेस कॅशिंग सक्षम करून सेशनचा कालावधी 24 तास सेट करा. हे पाहुण्यांना एकाच भेटीदरम्यान पुन्हा ऑथेंटिकेट करण्यास भाग पाडण्यापासून रोखते. उच्च सुरक्षा वातावरणासाठी, पुन्हा ऑथेंटिकेशनसह लहान सेशन्स योग्य आहेत.

पायरी 5: तुमच्या DHCP कक्षेचा आकार निश्चित करा. तुमच्या ठिकाणासाठी गर्दीच्या वेळी कमाल समवर्ती डिव्हाइस संख्येची गणना करा. 500 आसनी रेस्टॉरंटमध्ये व्यस्त वेळेत 800 डिव्हाइसेस दिसू शकतात. 30 मिनिटांच्या लीझ वेळेसह DHCP पूलचा आकार 1,000 ॲड्रेस इतका करा.

पायरी 6: सर्व ऑपरेटिंग सिस्टीमवर चाचणी करा. कॉन्फिगरेशननंतर, iOS, Android, आणि Windows डिव्हाइसेसवर संपूर्ण प्रवाहाची चाचणी घ्या. प्रत्येक यंत्रणा वेगळी प्रोब URL आणि WebView अंमलबजावणी वापरते. इतर कार्यरत असताना एखाद्या प्लॅटफॉर्मवर अपयश येणे हे सहसा walled garden मधील त्रुटीमुळे असते.

सर्वोत्तम पद्धती

खालील शिफारसी Purple च्या 80,000 हून अधिक ठिकाणांच्या उपयोजनांमधील मानके आणि पद्धती दर्शवतात.

guest आणि staff नेटवर्क्स वेगळे करा. किमान तीन SSIDs चालवा: Guest WiFi, Staff WiFi, आणि एक IoT नेटवर्क. Guest ट्रॅफिक अंतर्गत सिस्टम्सपासून वेगळे केले पाहिजे. आर्किटेक्चरच्या तपशिलांसाठी आमचे मार्गदर्शन Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi पहा.

एक समर्पित guest VLAN वापरा. लाटेरल मूव्हमेंट रोखण्यासाठी आणि फायरवॉल पॉलिसी सुलभ करण्यासाठी guest ट्रॅफिकला त्याच्या स्वतःच्या VLAN मध्ये विभागून घ्या. पेमेंट कार्ड डेटा नेटवर्कवरून जात असल्यास ही PCI-DSS आवश्यकता आहे.

सजग-निवड (conscious-choice) ऑप्ट-इन्स लागू करा. GDPR नुसार Captive Portal वरील डेटा गोळा करणे हे माहितीपूर्ण, होकारात्मक संमतीवर आधारित असणे आवश्यक आहे. Purple चे सजग-निवड ऑप्ट-इन्स डेटा गोळा करण्याचे पर्याय स्पष्टपणे सादर करतात, प्रत्येक उद्देशासाठी स्वतंत्र टिक बॉक्ससह. UK किंवा EU मध्ये कार्यरत असलेल्या ठिकाणांसाठी हे ऐच्छिक नाही.

पोर्टलच्या आरोग्याचे सक्रियपणे निरीक्षण करा. Purple चे WiFi Analytics प्लॅटफॉर्म लॉगइन यश दर, सेशन संख्या आणि ऑथेंटिकेशन अपयशांचे रिअल-टाइम व्हिज्युअलिटी प्रदान करते. यशस्वी लॉगइनमध्ये अचानक झालेली घट ही पाहुण्यांनी तक्रार करण्यास सुरुवात करण्यापूर्वीच RADIUS किंवा वॉल्ड गार्डन समस्येची पूर्व चेतावणी असते.

सुसंगत ब्रँडिंग लागू करा. स्प्लॅश पेज हा पाहुण्यांचा तुमच्या नेटवर्कसोबतचा पहिला ब्रँडेड संवाद असतो. उत्तम प्रकारे डिझाइन केलेले पोर्टल ऑप्ट-इन दर वाढवते आणि WiFi अनुभवासाठी अपेक्षा निश्चित करते. डिझाइन मार्गदर्शनासाठी How to make a great first impression with your guest WiFi पहा.

त्रुटी निवारण आणि जोखीम कमी करणे

जेव्हा Captive Portal समस्येची तक्रार केली जाते, तेव्हा कोणत्याही कॉन्फिगरेशन बदल करण्यापूर्वी या डायग्नोस्टिक अनुक्रमाचे अनुसरण करा.

बिघाड बिंदू वेगळा करा. पाहुण्यांना ते कोणते OS आणि ब्राउझर वापरत आहेत ते विचारा. त्याच OS वर स्वतः त्याच प्रवाहाची चाचणी घ्या. समस्या विशिष्ट OS पूरती असल्यास, त्याचे कारण नक्कीच त्या OS च्या प्रोब URL साठी गहाळ असलेली वॉल्ड गार्डन एन्ट्री असते.

DNS रिझोल्यूशन तपासा. guest VLAN वरील डिव्हाइसवरून, Captive Portal होस्टनेम रिझॉल्व्ह करण्याचा प्रयत्न करा. DNS रिझोल्यूशन अयशस्वी झाल्यास, रिडायरेक्ट योग्यरित्या जारी केले असले तरीही डिव्हाइस स्प्लॅश पेजपर्यंत पोहोचू शकत नाही. तुमचे DHCP सर्व्हर विश्वसनीय DNS पत्ते वितरित करत असल्याची आणि गेटवे प्री-ऑथेंटिकेशन स्थितीत DNS क्वेरींना परवानगी देत असल्याची खात्री करा.

रिडायरेक्ट कॅप्चर करा. HTTP एक्सचेंज पाहण्यासाठी ब्राउझर डेव्हलपर टूल्स (F12) किंवा पॅकेट कॅप्चर वापरा. तुम्हाला OS प्रोब विनंती आणि त्यानंतर पोर्टल URL असलेले HTTP 302 प्रतिसाद दिसले पाहिजेत. तुम्हाला प्रोब विनंती दिसत असल्यास परंतु 302 प्रतिसाद दिसत नसल्यास, गेटवे योग्यरित्या इंटरसेप्ट करत नाही. जर तुम्हाला कोणतीही प्रोब विनंती दिसत नसेल, तर OS ने आधीच ठरवले आहे की त्याच्याकडे इंटरनेट प्रवेश आहे (कदाचित कॅश केलेल्या स्थितीवरून) आणि ते प्रोब पाठवत नाही.RADIUS कम्युनिकेशन तपासा. गेटवेवर, RADIUS अकाउन्टिंग लॉग्स तपासा. यशस्वी प्रमाणीकरणामुळे (authentication) Accounting-Start रेकॉर्ड तयार होतो. पाहुण्याने (guest) लॉग इन केल्यानंतर तुम्हाला कोणतेही अकाउन्टिंग रेकॉर्ड दिसत नसल्यास, RADIUS कम्युनिकेशन खंडित झाले आहे. शेअर केलेले सिक्रेट, सर्व्हर IP आणि फायरवॉल नियम तपासा.

DHCP लीझ युटिलायझेशन तपासा. DHCP सर्व्हरवर, पूल साईझच्या तुलनेत सध्याची लीझ संख्या तपासा. जर वापर ९०% पेक्षा जास्त असेल, तर पूल संपत आला आहे. पूलचा विस्तार करा किंवा लीझ वेळ ताबडतोब कमी करा.

खालील तक्ता सर्वात सामान्य समस्या, त्यांची मूळ कारणे आणि संबंधित उपायांशी जुळवतो.

लक्षण	बहुधा मूळ कारण	उपाय
कोणत्याही डिव्हाइसवर पोर्टल कधीही दिसत नाही	OS प्रोब गेटवे ACL द्वारे ब्लॉक केला आहे	प्री-ऑथ परवानगी सूचीमध्ये प्रोब URLs जोडा
पोर्टल iOS वर दिसते, Android वर नाही	Android प्रोब URL वॉल्ड गार्डनमध्ये उपलब्ध नाही	वॉल्ड गार्डनमध्ये `connectivitycheck.gstatic.com` जोडा
पोर्टल लोड होताना HTTPS प्रमाणपत्र त्रुटी	गेटवे HTTP ऐवजी HTTPS इंटरसेप्ट करत आहे	केवळ HTTP प्रोब इंटरसेप्शनवर अवलंबून राहा
पोर्टल लोड होते, लॉग इन केल्यानंतर इंटरनेट चालत नाही	गेटवेद्वारे RADIUS Access-Accept प्राप्त झाले नाही	शेअर केलेले सिक्रेट, पोर्टस् १८१२/१८१३, RADIUS सर्व्हर IP सत्यापित करा
सोशल लॉगिन बटण कोणत्याही प्रतिसादाशिवाय अयशस्वी होते	आयडेंटिटी प्रोव्हायडर डोमेन वॉल्ड गार्डनमध्ये नाही	Microsoft Entra ID / Google Workspace एंडपॉइंट्स जोडा
पाहुण्यांना प्रत्येक भेटीदरम्यान पुन्हा-प्रमाणित करावे लागते	सेशन कालावधी खूप कमी आहे किंवा MAC कॅशिंग अक्षम आहे	सेशन २४ तासांसाठी सेट करा, MAC ॲड्रेस कॅशिंग सक्षम करा
गर्दीच्या वेळी मधूनमधून अपयश	DHCP पूल संपणे	सबनेटचा विस्तार करा, लीझ वेळ कमी करा

ROI आणि व्यावसायिक परिणाम

प्रत्येक कॅप्टिव्ह पोर्टल अपयश ही डेटा कॅप्चर करण्याची गमावलेली संधी असते. Purple चे Guest WiFi प्लॅटफॉर्म प्रत्येक यशस्वी प्रमाणीकरणाला फर्स्ट-पार्टी डेटा रेकॉर्डमध्ये रूपांतरित करते - ज्यामध्ये नाव, ईमेल, डेमोग्राफिक डेटा आणि भेट देण्याची वारंवारता समाविष्ट असते - जे थेट मार्केटिंग ऑटोमेशन आणि लॉयल्टी प्रोग्राम्समध्ये समाविष्ट होते.

Premier Inn किंवा Whitbread सारख्या हॉस्पिटॅलिटी ऑपरेटरसाठी, ७००-प्रॉपर्टीच्या इस्टेटमध्ये पोर्टल प्रमाणीकरण यश दरामध्ये १०% ची सुधारणा थेट दरमहा हजारो अतिरिक्त ऑप्ट-इन रेकॉर्ड्स मिळवून देते. ते रेकॉर्ड खरेदी केलेल्या यादीपेक्षा लक्षणीय उच्च ओपन रेटसह वैयक्तिकृत ईमेल मोहिमांना सक्षम करतात.

रिटेल ऑपरेटरसाठी, कॅप्टिव्ह पोर्टल हे खरेदीदारांचा थांबलेला वेळ, वारंवार भेटी आणि वेगवेगळ्या ठिकाणी त्यांच्या वर्तणुकीला समजून घेण्याचे प्रवेशद्वार आहे. Purple ने त्याच्या वेन्यू नेटवर्कवर २९ अब्ज डेटा पॉइंट्स (Purple चा अंतर्गत डेटा) गोळा केले आहेत. तो डेटा केवळ तो निर्माण करणाऱ्या प्रमाणीकरण दराइतकाच प्रभावी असतो.

मँचेस्टर एअरपोर्ट्स ग्रुप सारख्या ट्रान्सपोर्ट हबसाठी, विश्वसनीय गेस्ट WiFi हे बोर्ड पातळीवर ट्रॅक केले जाणारे प्रवासी समाधानाचे मॅट्रिक आहे. गर्दीच्या वेळेत मधूनमधून अयशस्वी होणारे पोर्टल तक्रारी निर्माण करते आणि वेन्यूच्या नेट प्रमोटर स्कोअरला नुकसान पोहोचवते. healthcare वातावरणासाठी, विश्वसनीय अभ्यागत WiFi क्लीनिकल कर्मचाऱ्यांवरील ताण कमी करते जे अन्यथा कनेक्टिव्हिटीच्या तक्रारी सोडवत असतात, आणि यामुळे रुग्णांच्या अनुभवाचे निकष देखील सुधारतात.

Purple ची 99.999% अपटाईम SLA हे सुनिश्चित करते की क्लाउड ओव्हरले स्वतः अपयशाचे कारण नाही. जेव्हा पोर्टलच्या समस्या उद्भवतात, तेव्हा त्याचे कारण जवळजवळ नेहमीच स्थानिक कॉन्फिगरेशन असते - जे हे मार्गदर्शक तुम्हाला सपोर्ट तिकीट न वाढवता सोडवण्यासाठी सक्षम करते.

References

[1] Troubleshooting Tip: General captive portal explanation, flow and troubleshooting. Fortinet Community, November 2024. https://community.fortinet.com/fortigate-3/troubleshooting-tip-general-captive-portal-explanation-flow-and-troubleshooting-188409

[2] RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements. IETF. https://www.rfc-editor.org/info/rfc8910

[3] Network Connectivity Status Indicator overview for Windows. Microsoft Learn, February 2025. https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-overview

[4] 7 Captive Portal Problems That Break Guest WiFi (And Quick Fixes). Spotipo, February 2026. https://www.spotipo.com/post/troubleshooting-captive-portals-common-issues

[5] Solution for HSTS issues with captive portal. Ubiquiti Community. https://community.ui.com/questions/Solution-for-HSTS-issues-with-captive-portal/17b033e7-3dfe-4830-af8f-bf6ead23d8b0

महत्वाच्या व्याख्या

Captive portal

पूर्ण इंटरनेट ॲक्सेस मिळण्यापूर्वी नेटवर्कमध्ये सामील होणाऱ्या डिव्हाइसला दाखवले जाणारे वेब पेज. गेटवे डिव्हाइसच्या सुरुवातीच्या HTTP कनेक्टिव्हिटी तपासणीला अडवतो आणि त्याला पोर्टल URL वर रिडायरेक्ट करतो.

हॉटेलच्या लॉबीपासून ते स्टेडियमच्या कॉनकोर्सपर्यंत प्रत्येक अतिथी WiFi लॉगिन पेजमागील यंत्रणा. RFC ८९१० मध्ये परिभाषित.

Walled garden

डोमेन्स आणि IP ॲड्रेसचा असा संच ज्यांच्यापर्यंत एखादे डिव्हाइस Captive Portal ऑथेंटिकेशन पूर्ण करण्यापूर्वी पोहोचू शकते. Walled garden च्या गंतव्यस्थानांकडे जाणाऱ्या ट्रॅफिकसाठी ऑथेंटिकेशनची आवश्यकता नसते.

यामध्ये OS प्रोब URL, आयडेंटिटी प्रोव्हायडर एंडपॉइंट्स, CDN डोमेन्स आणि पेमेंट प्रोसेसर डोमेन्स समाविष्ट असणे आवश्यक आहे. चुकीच्या पद्धतीने कॉन्फिगर केलेले walled garden हे Captive Portal बिघाडाचे दुसरे सर्वात सामान्य कारण आहे.

NCSI (Network Connectivity Status Indicator)

`msftconnecttest.com` ची तपासणी करणारे एक Windows वैशिष्ट्य, ज्याद्वारे डिव्हाइसकडे इंटरनेट ॲक्सेस आहे की ते Captive Portal च्या मागे आहे हे निर्धारित केले जाते. Microsoft च्या नेटवर्किंग दस्तऐवजीकरणामध्ये हे परिभाषित केले आहे.

जर गेटवेने या प्रोबला ब्लॉक केले, तर Windows 'No internet access' असा अहवाल देते आणि Captive Portal WebView कधीही ट्रिगर करत नाही. यावरील उपाय म्हणजे NCSI URL ला प्री-ऑथेंटिकेशन परवानगी सूचीमध्ये (allow list) जोडणे.

HSTS (HTTP Strict Transport Security)

RFC 6797 मध्ये परिभाषित केलेले एक वेब सुरक्षा धोरण जे ब्राउझरला साधे HTTP कनेक्शन्स नाकारण्याचे आणि डोमेनशी तंतोतंत न जुळणारे कोणतेही प्रमाणपत्र नाकारण्याचे निर्देश देते.

हे गेटवेला Captive Portal रिडायरेक्शनसाठी HTTPS विनंत्या अडवण्यापासून रोखते. google.com सह सर्व प्रमुख डोमेन्स सर्व प्रमुख ब्राउझरमधील HSTS प्रिलोड सूचीमध्ये समाविष्ट आहेत.

HTTP 302 redirect

एक मानक HTTP रिस्पॉन्स कोड जो सूचित करतो की विनंती केलेले संसाधन तात्पुरते वेगळ्या URI वर उपलब्ध आहे, जे Location हेडरमध्ये प्रदान केले जाते.

डिव्हाइसच्या कनेक्टिव्हिटी तपासणीला Captive Portal लॉगिन पेजकडे वळवण्यासाठी गेटवे या यंत्रणेचा वापर करतात. काही गेटवे त्याऐवजी HTTP 303 किंवा रिडायरेक्ट बॉडीसह HTTP 200 चा वापर करतात.

RADIUS (Remote Authentication Dial-In User Service)

सेंट्रलाइज्ड Authentication, Authorization, आणि Accounting (AAA) व्यवस्थापन प्रदान करणारा एक नेटवर्किंग प्रोटोकॉल, जो पोर्ट्स 1812 (ऑथेंटिकेशन) आणि 1813 (अकाउंटिंग) वर UDP द्वारे कार्यरत असतो.

Purple चे क्लाउड प्लॅटफॉर्म RADIUS सर्व्हर म्हणून काम करते. स्थानिक गेटवे (Meraki, Aruba, इ.) Purple च्या RADIUS सर्व्हरला ऑथेंटिकेशन विनंत्या पाठवतो आणि Access-Accept किंवा Access-Reject रिस्पॉन्सवर कारवाई करतो.

MAC address caching

परत येणाऱ्या डिव्हाइसेसना ओळखण्यासाठी आणि पुन्हा ऑथेंटिकेशन न मागता सेशनची स्थिती कायम ठेवण्यासाठी डिव्हाइसचा युनिक हार्डवेअर आयडेंटिफायर स्टोअर करण्याची प्रक्रिया.

हे सत्र कालावधी दरम्यान थोड्या वेळासाठी कनेक्शन तुटल्यास आणि पुन्हा भेट दिल्यास सेशन टिकवून ठेवण्यास सक्षम करते. हे आदरातिथ्य (hospitality) क्षेत्रासाठी अत्यंत आवश्यक आहे जेथे पाहुणे वेगवेगळ्या भागात फिरत असतात.

Identity-Based Networks

Purple चे आर्किटेक्चर मॉडेल ज्यामध्ये केवळ डिव्हाइसच्या IP किंवा MAC ॲड्रेसच्या ऐवजी युझरच्या ऑथेंटिकेट केलेल्या ओळखीच्या आधारावर ॲक्सेस पॉलिसी, VLAN असाइनमेंट आणि ॲनालिटिक्स लागू केले जातात.

Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, आणि Fortinet हार्डवेअरवर युझर्सच्या नेटवर्क वर्तनाचे अचूक वर्गीकरण, वैयक्तिकृत अनुभव आणि तपशीलवार ॲक्सेस नियंत्रण सक्षम करते.

DHCP exhaustion

अशी स्थिती ज्यामध्ये DHCP पूल मधील सर्व उपलब्ध IP ॲड्रेस नियुक्त केले गेले आहेत, ज्यामुळे नवीन डिव्हाइसेसना ॲड्रेस मिळवण्यापासून आणि पर्यायाने Captive Portal पर्यंत पोहोचण्यापासून रोखले जाते.

गर्दीच्या काळात जास्त लोकसंख्या असलेल्या ठिकाणी हे सामान्यपणे घडते. हे अगदी Captive Portal बिघाडासारखेच दिसते - डिव्हाइस SSID शी कनेक्ट केलेले दिसते परंतु इंटरनेट चालत नाही. सर्व्हरवरील DHCP लीज वापर तपासून याचे निदान केले जाते.

सोडवलेली उदाहरणे

HPE Aruba ॲक्सेस पॉइंट्स वापरणारे २०० खोल्यांचे हॉटेल असे नोंदवते की Android डिव्हाइसेसवरील अतिथी captive portal मध्ये प्रवेश करू शकत नाहीत, तर iOS वापरकर्ते कोणत्याही समस्येशिवाय कनेक्ट होतात. IT टीमने पुष्टी केली आहे की मॅनेजमेंट VLAN मधून पोर्टल URL वर पोहोचता येते.

IT टीमने HPE Aruba कंट्रोलरवर प्री-ऑथेंटिकेशन वॉल्ड गार्डनची तपासणी केली पाहिजे. iOS डिव्हाइसेस captive.apple.com प्रोब करतात, जे कदाचित आधीच व्हाइटलिस्ट केलेले आहे. Android डिव्हाइसेस connectivitycheck.gstatic.com आणि clients3.google.com/generate_204 प्रोब करतात. हे Google डोमेन्स वॉल्ड गार्डनमध्ये नक्कीच नसतील. त्यांना प्री-ऑथेंटिकेशन परवानगी सूचीमध्ये जोडल्याने समस्येचे निराकरण होते. टीमने दुय्यम Android प्रोब URL म्हणून connectivitycheck.android.com देखील जोडले पाहिजे. वॉल्ड गार्डन अपडेट केल्यानंतर, प्रभावित SSIDs रीस्टार्ट करा आणि निराकरणाची पुष्टी करण्यासाठी फॅक्टरी-रीसेट केलेल्या Android डिव्हाइसवर चाचणी करा, कारण पूर्वी कनेक्ट केलेल्या डिव्हाइसवरील कॅश केलेली नेटवर्क स्थिती परिणाम लपवू शकते.

परीक्षकाचे भाष्य: ही परिस्थिती captive portal शोधण्याचे OS-विशिष्ट स्वरूप स्पष्ट करते. प्रत्येक प्लॅटफॉर्म वेगवेगळे प्रोब URLs वापरतो, आणि केवळ एका OS साठी कॉन्फिगर केलेले वॉल्ड गार्डन असाच असममित अपयशाचा नमुना तयार करेल. मुख्य निदानाचे संकेत म्हणजे हे अपयश डिव्हाइस-प्रकार-विशिष्ट आहे, सर्व डिव्हाइसेसमध्ये अधूनमधून होणारे नाही. सर्व डिव्हाइसेसमधील अधूनमधून येणाऱ्या त्रुटी RADIUS किंवा DHCP समस्यांकडे निर्देश करतील.

१५० Cisco Meraki MX अप्लायन्सेस असलेली एक रिटेल चेन नोंदवते की अतिथी Purple स्प्लॅश पेजवर ऑथेंटिकेट करतात - Purple डॅशबोर्ड यशस्वी लॉगइन्स दाखवतो - परंतु फॉर्म पूर्ण केल्यानंतरही अतिथींना इंटरनेट प्रवेश मिळत नाही. या समस्येचा सर्व ठिकाणांवर एकाच वेळी परिणाम होत आहे.

कारण Purple क्लाउड प्लॅटफॉर्म यशस्वी लॉगइन्स दाखवतो, ऑथेंटिकेशनची पायरी स्वतः काम करत आहे. अपयश ऑथोरायझेशन पायरीमध्ये आहे - Meraki अप्लायन्सला Purple च्या RADIUS सर्व्हरकडून RADIUS Access-Accept संदेश मिळत नाही किंवा त्यावर कारवाई होत नाही. टीमने सलग तीन गोष्टी तपासल्या पाहिजेत: प्रथम, Meraki डॅशबोर्डवरील RADIUS सामायिक सिक्रेट Purple पोर्टलवरील सिक्रेटशी तंतोतंत जुळत असल्याची पडताळणी करा (एका अक्षराच्या फरकामुळे देखील त्रुटी न दाखवता अपयश येते); दुसरे, Meraki अप्लायन्सपासून Purple च्या RADIUS सर्व्हर IP पत्त्यांवर पोर्ट्स १८१२ आणि १८१३ वरील आउटबाउंड UDP ट्रॅफिकला परवानगी असल्याची पुष्टी करा; तिसरे, अलीकडील नेटवर्क बदलामुळे या ट्रॅफिकला ब्लॉक करणारा फायरवॉल नियम किंवा NAT पॉलिसी लागू झाली आहे का ते तपासा. समस्येचा सर्व १५० ठिकाणांवर एकाच वेळी परिणाम होत असल्याने, याचे कारण बहुधा केंद्रित फायरवॉल पॉलिसी बदल किंवा Purple RADIUS सर्व्हर IP पत्ता बदल असू शकतो जो Meraki कॉन्फिगरेशनमध्ये पाठवला गेला नव्हता.

परीक्षकाचे भाष्य: येथे गंभीर निदान अंतर्दृष्टी अशी आहे की यशस्वी लॉगइन्स दर्शवणारा Purple डॅशबोर्ड म्हणजे क्लाउड ऑथेंटिकेशन पायरी पूर्ण झाली आहे. त्यामुळे अपयश स्थानिक अंमलबजावणीच्या पायरीमध्ये आहे - क्लाउडवरून गेटवेवर जाणारा RADIUS संदेश. क्लाउड-साइड ऑथेंटिकेशन आणि लोकल-साइड ऑथोरायझेशनमधील हा फरक क्लाउड ओव्हरले आर्किटेक्चर वापरणाऱ्या कोणत्याही captive portal डिप्लॉयमेंटच्या ट्रबलशूटिंगसाठी मूलभूत आहे.

सराव प्रश्न

Q1. ५,००० आसनक्षमता असलेल्या ठिकाणी एका मोठ्या परिषदेदरम्यान, IT टीमला तक्रारी मिळतात की शेकडो उपस्थितांना गेस्ट WiFi पोर्टलवर प्रवेश करता येत नाही. ॲक्सेस पॉइंट्स सामान्य असोसिएशन संख्या दर्शवत आहेत. ही समस्या कार्यक्रम सुरू झाल्यानंतर ४५ मिनिटांनी सुरू झाली. याचे सर्वात संभाव्य कारण काय आहे आणि त्वरित उपाय काय आहे?

टीप: समस्या कार्यक्रम सुरू झाल्यावर झाली, सुरुवातीला नाही. अधिक डिव्हाइसेस सामील झाल्यावर कोणत्या संसाधनावर मर्यादा येते याचा विचार करा.

नमुना उत्तर पहा

सर्वात संभाव्य कारण म्हणजे DHCP पूल संपणे हे आहे. जसे जसे उपस्थित लोक आले आणि SSID शी जोडले गेले, तसा DHCP पूल भरला. नवीन डिव्हाइसेस ऍक्सेस पॉइंटशी जोडले जातात परंतु त्यांना IP ॲड्रेस मिळू शकत नाही, त्यामुळे ते Captive Portal ट्रिगर करण्यासाठी आवश्यक असलेली HTTP प्रोब कधीच पाठवत नाहीत. तात्काळ उपाय म्हणजे DHCP लीझ वेळ १५ मिनिटांपर्यंत कमी करणे (बाहेर पडलेल्या डिव्हाइसेसकडून जलद गतीने ॲड्रेसेस परत मिळवणे) आणि शक्य असल्यास, दुसरा सबनेट जोडून पूलचा विस्तार करणे. दीर्घकालीन उपाय म्हणजे पुढील इव्हेंटमध्ये सरासरीच्या ऐवजी कमाल समवर्ती (concurrent) डिव्हाइस संख्येसाठी DHCP पूलचा आकार निश्चित करणे.

Q2. तुम्ही एका रिटेल चेनमध्ये Ubiquiti UniFi ऍक्सेस पॉइंट्सवर Purple तैनात केले आहे. स्प्लॅश पेज सर्व डिव्हाइसेसवर योग्यरित्या लोड होते. अतिथी ईमेल कॅप्चर फॉर्म पूर्ण करतात आणि त्यांना यशाचा संदेश दिसतो. परंतु जेव्हा ते ब्राउझ करण्याचा प्रयत्न करतात, तेव्हा त्यांना इंटरनेट ऍक्सेस मिळत नाही. Purple डॅशबोर्ड लॉगिन यशस्वी झाल्याचे दर्शवतो. तुम्ही प्रथम काय तपासाल?

टीप: क्लाउड प्लॅटफॉर्मने ऑथेंटिकेशन नोंदवले आहे. अपयश स्थानिक अंमलबजावणीच्या (local enforcement) टप्प्यात आहे.

नमुना उत्तर पहा

Purple च्या डॅशबोर्डवर यशस्वी लॉगिन दिसत असल्याने, क्लाउड ऑथेंटिकेशन टप्पा योग्यरित्या पूर्ण झाला आहे. अपयश RADIUS ऑथोरायझेशन टप्प्यात आहे - UniFi कंट्रोलरला Purple च्या RADIUS सर्व्हरकडून Access-Accept संदेश मिळत नाही किंवा तो त्यावर कारवाई करत नाही. या क्रमाने तपासा: (1) UniFi कंट्रोलरवरील RADIUS शेअर्ड सिक्रेट Purple च्या डॅशबोर्डमधील सिक्रेटशी तंतोतंत जुळते आहे का; (2) कंट्रोलरकडून Purple च्या RADIUS सर्व्हर IP ॲड्रेसेसवर पोर्ट्स 1812 आणि 1813 वरील आउटबाउंड UDP ला परवानगी आहे का; (3) UniFi कंट्रोलरवर कॉन्फिगर केलेले RADIUS सर्व्हर IP ॲड्रेसेस अद्ययावत आहेत का (Purple ने ते अपडेट केले असावेत). कंट्रोलरवरील पॅकेट कॅप्चर (packet capture) द्वारे Access-Accept संदेश येत आहे की नाही याची खात्री होईल.

Q3. एका हॉटेलचे आयटी मॅनेजर सांगतात की त्यांच्या डिव्हाइसेसवर VPN वापरणारे अतिथी Captive Portal वर अजिबात प्रवेश करू शकत नाहीत. VPN नसलेले अतिथी नेहमीप्रमाणे कनेक्ट होतात. हॉटेल Cisco Meraki MX अप्लायन्सेस वापरते. आयटी टीमने VPN वापरकर्त्यांना सामावून घेण्यासाठी Captive Portal कॉन्फिगरेशन बदलले पाहिजे का?

टीप: Captive Portal ने इंटरसेप्ट करण्यापूर्वी VPN डिव्हाइसच्या नेटवर्क ट्रॅफिकवर काय परिणाम करतो याचा विचार करा.

नमुना उत्तर पहा

नाही - Captive Portal कॉन्फिगरेशन बदलण्याची आवश्यकता नाही. VPN क्लायंट डिव्हाइसमधून ट्रॅफिक बाहेर पडण्यापूर्वीच, HTTP कनेक्टिव्हिटी प्रोबसह डिव्हाइसमधील सर्व ट्रॅफिक एनक्रिप्ट करतो. गेटवे एनक्रिप्टेड VPN ट्रॅफिक इंटरसेप्ट करू शकत नाही, त्यामुळे तो कधीही 302 रिडायरेक्ट जारी करत नाही. अतिथीला त्यांचा VPN बंद करावा लागेल, Captive Portal ऑथेंटिकेशन पूर्ण करावे लागेल आणि नंतर VPN पुन्हा सुरू करावा लागेल. ही Captive Portals आणि VPN ची एक मूलभूत आर्किटेक्चरल मर्यादा आहे, कॉन्फिगरेशनची त्रुटी नाही. आयटी टीमने अतिथी WiFi सूचनांमध्ये एक टीप जोडली पाहिजे जी VPN वापरकर्त्यांना कनेक्ट करण्यापूर्वी त्यांचे VPN बंद करण्याचा सल्ला देते.

या मालिकेमध्ये पुढे वाचा

पब्लिक WiFi चे ट्रबलशूटिंग: 'Connected, No Internet' आणि स्प्लॅश पेज रीडायरेक्शनमधील त्रुटींचे निवारण करणे

हा अधिकृत तांत्रिक संदर्भ मार्गदर्शक कॅप्टिव्ह पोर्टल (captive portal) डिटेक्ट करण्याच्या अंतर्गत यंत्रणेचे स्पष्टीकरण देतो आणि अतिथी WiFi ला जोडण्यापासून रोखणाऱ्या सहा प्राथमिक त्रुटींच्या प्रकारांचे तपशील देतो. हे IT व्यवस्थापक आणि नेटवर्क डिझायनर्सना HTTP रीडायरेक्ट समस्या, DNS संघर्ष आणि MAC रँडमायझेशन आव्हाने सोडवण्यासाठी एक व्यावहारिक ट्रबलशूटिंग फ्रेमवर्क प्रदान करते.

हाय-डेन्सिटी वायरलेस नेटवर्कवर DHCP टाईमआउट होण्याची top १० कारणे

हा अधिकृत तांत्रिक संदर्भ मार्गदर्शक हाय-डेन्सिटी वायरलेस नेटवर्कवरील DHCP टाईमआउटच्या पहिल्या दहा कारणांचा शोध घेतो आणि त्यावर प्रत्यक्ष अमलात आणण्याजोगे, व्हेंडर-neutral उपाय प्रदान करतो. वरिष्ठ IT लीडर्स, नेटवर्क आर्किटेक्ट्स आणि व्हेन्यू ऑपरेशन्स डायरेक्टर्ससाठी डिझाइन केलेल्या या मार्गदर्शकामध्ये सखोल अभियांत्रिकी तत्त्वे, टप्प्याटप्प्याने अंमलबजावणीचे वर्कफ्लो आणि मोजण्यायोग्य व्यावसायिक परिणाम समाविष्ट आहेत. कठीण एंटरप्राइझ वातावरणात अखंड कनेक्टिव्हिटी प्रदान करण्यासाठी कनेक्शनमधील अडथळे कसे दूर करावेत आणि तुमची वायरलेस इन्फ्रास्ट्रक्चर कशी ऑप्टिमाइझ करावी हे जाणून घ्या.

मंद WiFi कामगिरीचे निदान करण्यासाठी पॅकेट कॅप्चर (PCAP) चा वापर करणे

हे तांत्रिक संदर्भ मार्गदर्शक IT व्यवस्थापक, नेटवर्क आर्किटेक्ट आणि वेन्यू ऑपरेशन्स डायरेक्टर्सना पॅकेट कॅप्चर (PCAP) विश्लेषणाचा वापर करून मंद कॉर्पोरेट WiFi कामगिरीचे निदान आणि निराकरण करण्यासाठी एक संरचित, पॅकेट-स्तरीय पद्धत प्रदान करते. रिट्रान्समिशन दर, एअरटाइम युटिलायझेशन आणि फिजिकल लेयर मेटाडेटा यासह कच्च्या 802.11 फ्रेम्सचे बारकाईने विश्लेषण करून, टीम्स अचूकतेने वायर्ड किंवा ॲप्लिकेशन समस्यांपासून RF-लेअरमधील अडथळे वेगळे करू शकतात. हॉटेल्स, रिटेल चेन्स, स्टेडियम्स आणि कॉन्फरन्स सेंटर्ससह उच्च-घनता असलेल्या ठिकाणांवर लागू होणारे, हे मार्गदर्शक नेटवर्क क्षमता पुनर्प्राप्त करण्यासाठी आणि पाहुण्यांच्या अनुभवाचे रक्षण करण्यासाठी कृतीयोग्य निदान वर्कफ्लो, वास्तविक-जगातील केस स्टडीज आणि कॉन्फिगरेशन सुधारणा पायऱ्या प्रदान करते.