मुख्य मजकुराकडे जा

Captive Portal रिडायरेक्टच्या त्रुटींचे निवारण: अतिथी WiFi कनेक्शन अयशस्वी होणे सोडवणे

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

Tom Hackett द्वारेप्रकाशित अद्ययावत केले
📖 9 मिनिट वाचन2,119 शब्द2 सोडवलेली उदाहरणे3 सराव प्रश्न9 महत्वाच्या व्याख्या

Video overview

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

पॉडकास्ट ट्रान्सक्रिप्ट पहा
होस्ट (UK इंग्लिश, आत्मविश्वासी सल्लागाराचा सूर): Purple टेक्निकल ब्रीफिंगमध्ये आपले स्वागत आहे. आज आपण एंटरप्राइझ नेटवर्किंगमधील सर्वात कायमस्वरूपी डोकेदुखी असलेल्या एका समस्येवर उपाय शोधत आहोत: ती म्हणजे captive portal रीडायरेक्ट फेल्युअर. जेव्हा तुमचे गेस्ट 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 च्या मागे आहे. त्यानंतर ते स्प्लॅश पेज लोड करण्यासाठी एक स्यूडो-ब्राउझर उघडते. अपयश सहसा या हस्तक्षेपाच्या ठिकाणी (interception point) घडते. [विराम] अपयशाचा पहिला मुख्य मुद्दा म्हणजे नेटवर्क कनेक्टिव्हिटी स्टेटस इंडिकेटर प्रोब, किंवा NCSI. जर तुमच्या फायरवॉलने किंवा गेटवेने या अनइन्क्रिप्टेड HTTP विनंत्यांना ब्लॉक केले, तर ऑपरेटिंग सिस्टीमला 302 रीडायरेक्ट कधीच मिळत नाही. ते फक्त असे गृहीत धरते की नेटवर्क खराब आहे. हे दुरुस्त करण्यासाठी, तुम्ही हे सुनिश्चित केले पाहिजे की तुमच्या प्री-ऑथेंटिकेशन ॲक्सेस कंट्रोल लिस्ट्स त्या विशिष्ट OS डिटेक्शन URLs कडे जाणाऱ्या HTTP ट्रॅफिकला परवानगी देतात. दुसरी, आणि वाढती सामान्य समस्या म्हणजे HTTP स्ट्रिक्ट ट्रान्सपोर्ट सिक्युरिटी, किंवा HSTS. आधुनिक ब्राउझर प्रमुख डोमेन्ससाठी HTTPS ची सक्ती करतात. जर एखाद्या वापरकर्त्याने तुमच्या WiFi शी कनेक्ट केले आणि त्वरित google.com उघडण्याचा प्रयत्न केला, तर त्यांचा ब्राउझर एनक्रिप्टेड कनेक्शनचा आग्रह धरतो. जेव्हा तुमचा गेटवे त्या HTTPS विनंतीमध्ये हस्तक्षेप करतो आणि तिला captive portal वर रीडायरेक्ट करण्याचा प्रयत्न करतो, तेव्हा ब्राउझरला मॅन-इन-द-मिडल (man-in-the-middle) हल्ला झाल्याचे आढळते. तुमच्या गेटवेने सादर केलेले सर्टिफिकेट google.com शी जुळत नाही. याचा परिणाम थेट ब्लॉकिंगमध्ये होतो. वापरकर्त्याला सुरक्षेची चेतावणी दिसते आणि ते लॉगइन पेजवर पुढे जाऊ शकत नाहीत. यावर दोन प्रकारे उपाय आहे. पहिले म्हणजे, आपण आत्ताच चर्चा केलेल्या OS-स्तरीय डिटेक्शन मेकॅनिझम्सवर अवलंबून राहा. हे सर्टिफिकेट विसंगती टाळण्यासाठी विशेषतः अनइन्क्रिप्टेड HTTP वापरतात. दुसरे म्हणजे, तुमचे वॉल्ड गार्डन (walled garden) कॉन्फिगरेशन त्रुटीविरहित असल्याची खात्री करा. वॉल्ड गार्डन (walled garden) म्हणजे काय? ही अशा डोमेन्स आणि IP ॲड्रेसची सूची आहे ज्यांवर अतिथी प्रमाणीकरण (authenticate) करण्यापूर्वी प्रवेश करू शकतात. तुम्ही Microsoft Entra ID किंवा Google Workspace द्वारे सोशल लॉगिन वापरत असल्यास, किंवा Stripe द्वारे पेमेंट प्रक्रियेत असल्यास, ते डोमेन्स तुमच्या वॉल्ड गार्डनमध्ये असणे आवश्यक आहे. ते नसल्यास, स्प्लॅश पेज लोड होऊ शकते, परंतु प्रमाणीकरण प्रक्रिया कोणत्याही सूचनेशिवाय अपयशी ठरेल. [PAUSE] चला एका वास्तविक परिस्थितीवर नजर टाकूया. McDonald's हजारो ठिकाणांवर लाखो ग्राहकांना सेवा देते. ते त्यांचे अतिथी WiFi व्यवस्थापित करण्यासाठी Purple वापरतात. जर त्यांचा सेशन टाइमआउट खूप लहान सेट केला असेल, तर दुपारच्या जेवणादरम्यान बराच वेळ आपला फोन चेक करणाऱ्या ग्राहकाला वारंवार पुन्हा प्रमाणीकरण करावे लागू शकते. यामुळे अनुभव खराब होतो. आम्ही हॉस्पिटॅलिटी आणि रिटेल वातावरणासाठी सेशनचा कालावधी २४ तास सेट करण्याची शिफारस करतो, ज्यामुळे परत येणाऱ्या उपकरणांना अखंडपणे ओळखण्यासाठी MAC ॲड्रेस कॅशिंगचा वापर केला जाऊ शकतो. [PAUSE] आता अंमलबजावणीच्या शिफारसींबद्दल. कॅप्टिव्ह पोर्टल (captive portal) तैनात करताना, तुम्ही DNS आणि HTTP ट्रॅफिक अचूकपणे इंटरसेप्ट करण्यासाठी तुमचे गेटवे कॉन्फिगर केले पाहिजे. तुम्ही Purple सारखे क्लाउड ओव्हरले वापरत असल्यास, तुमचे स्थानिक हार्डवेअर, मग ते Juniper Mist असो वा Ubiquiti UniFi, Purple RADIUS सर्व्हरपर्यंत पोहोचण्यास सक्षम असले पाहिजे. येथे एक गंभीर चूक टाळावी लागेल: DNS रिझोल्यूशन. जर एखादे अतिथी उपकरण तुमच्या कॅप्टिव्ह पोर्टलच्या होस्टनेमचे निराकरण (resolve) करू शकत नसेल, तर रिडायरेक्ट अयशस्वी होते. तुमचा DHCP सर्व्हर विश्वासार्ह DNS ॲड्रेस देतो याची खात्री करा आणि तुमचे गेटवे वॉल्ड गार्डनमधून DNS क्वेरी पास होऊ देते की नाही हे तपासा. याव्यतिरिक्त, भौतिक वातावरणाचा विचार करा. स्टेडियम किंवा ट्रॅव्हल हब जसे की Manchester Airports Group सारख्या उच्च घनतेच्या ठिकाणी एकाच वेळी हजारो कनेक्शनचे प्रयत्न केले जातात. जर तुमचा स्थानिक DHCP पूल संपला, तर नवीन उपकरणे ॲक्सेस पॉइंटशी कनेक्ट होतील परंतु त्यांना IP ॲड्रेस मिळणार नाही. ते कधीही कॅप्टिव्ह पोर्टल टप्प्यापर्यंत पोहोचणार नाहीत. पीक क्षमतेसाठी तुमचे सबनेट नेहमी योग्य आकाराचे ठेवा आणि तात्पुरत्या अभ्यागत नेटवर्कसाठी लहान DHCP लीज वेळा वापरा. [PAUSE] आता सामान्य हेल्पडेस्क तिकिटांवर आधारित एक जलद प्रश्न आणि उत्तर सत्र घेऊया. प्रश्न १: पोर्टल आयफोनवर चालते पण Android उपकरणांवर का अयशस्वी होते? उत्तर: ही नक्कीच वॉल्ड गार्डनची समस्या आहे. तुम्ही बहुधा captive.apple.com ला व्हाईटलिस्ट केले आहे परंतु connectivitycheck.gstatic.com विसरला आहात. तुमची प्री-ऑथेंटिकेशन ॲक्सेस कंट्रोल लिस्ट अपडेट करा. प्रश्न २: अतिथी यशस्वीरित्या प्रमाणीकरण करतात, तरीही त्यांना इंटरनेट मिळत नाही. असे का? उत्तर: तुमचे RADIUS कॉन्फिगरेशन तपासा. गेटवेला बहुधा RADIUS सर्व्हरकडून Access-Accept मेसेज मिळत नाही, किंवा प्रमाणीकरणानंतरचे फायरवॉल नियम ट्रॅफिक ब्लॉक करत आहेत. सामायिक केलेले गुपिते (shared secret) सत्यापित करा आणि पोर्ट १८१२ आणि १८१३ उघडे असल्याचे सुनिश्चित करा. प्रश्न ३: सुरक्षिततेच्या चेतावणी टाळण्यासाठी आम्ही सुरुवातीच्या रिडायरेक्टसाठी HTTPS वापरू शकतो का? उत्तर: नाही. प्रत्येक अतिथी उपकरणावर रूट प्रमाणपत्र स्थापित केल्याशिवाय तुम्ही प्रमाणपत्र त्रुटी (certificate error) न आणता HTTPS विनंती इंटरसेप्ट करू शकत नाही, जे सार्वजनिक WiFi साठी अशक्य आहे. पोर्टल ट्रिगर करण्यासाठी तुम्हाला अनइन्क्रिप्टेड HTTP OS प्रोब्सवरच अवलंबून राहावे लागेल. [PAUSE] थोडक्यात सांगायचे तर: Captive Portal मधील त्रुटी या क्वचितच हार्डवेअरच्या बिघाडामुळे असतात. त्या बहुतांश वेळा रिडायरेक्ट फ्लो, वॉल्ड गार्डन (walled garden) किंवा DNS सेटिंग्जमधील विसंगत कॉन्फिगरेशनमुळे असतात. पॉइंट एक: प्रमाणीकरणापूर्वी (authentication) OS डिटेक्शन URLs ॲक्सेस करण्यायोग्य असल्याची खात्री करा. पॉइंट दोन: सर्व आवश्यक आयडेंटिटी प्रोव्हाइडर्स आणि कंटेंट डिलिव्हरी नेटवर्क्सचा समावेश करण्यासाठी तुमचे वॉल्ड गार्डन (walled garden) कॉन्फिगर करा. पॉइंट तीन: तुमचे गेटवे आणि तुमचे प्रमाणीकरण प्लॅटफॉर्म यामधील RADIUS संप्रेषण सत्यापित करा. पॉइंट चार: पीक डेन्सिटी लक्षात घेऊन तुमचे DHCP स्कोप्स निश्चित करा. या घटकांवर प्रभुत्व मिळवून, तुम्ही कनेक्शनमधील अडथळे दूर करता. तुम्ही तुमच्या पाहुण्यांना निराश करणे थांबवता आणि लॉयल्टी तसेच महसूल वाढवण्यासाठी आवश्यक असलेला फर्स्ट-पार्टी डेटा गोळा करण्यास सुरुवात करता. Purple चे आयडेंटिटी-बेस्ड नेटवर्क ही प्रक्रिया सोपी करतात, एक हार्डवेअर-अग्नॉस्टिक क्लाउड ओव्हरले प्रदान करतात जे जगभरातील ८०,००० पेक्षा जास्त लाइव्ह वेन्यूजवर RADIUS, Captive Portals आणि ॲनालिटिक्सची गुंतागुंत अखंडपणे हाताळतात. या Purple टेक्निकल ब्रीफिंगमध्ये सहभागी झाल्याबद्दल धन्यवाद. अधिक तपशीलवार कॉन्फिगरेशन मार्गदर्शक आणि आर्किटेक्चर डायग्राम्ससाठी, purple.ai ला भेट द्या.

आमच्या मुख्य मालिकेचा भाग: Captive Portal मार्गदर्शक

Captive Portal रिडायरेक्टच्या त्रुटींचे निवारण: अतिथी WiFi कनेक्शन अयशस्वी होणे सोडवणे

मुख्य सारांश

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


तांत्रिक सखोल माहिती

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 ला ओळखते की ते पोर्टलच्या मागे आहे आणि स्प्लॅश पेज प्रदर्शित करण्यासाठी स्यूडो-ब्राउझर (एक हलका वेबव्ह्यू) उघडते. जर प्रोब पूर्णपणे ब्लॉक केला असेल, तर OS 'नो इंटरनेट कनेक्शन' चा अहवाल देते आणि कधीही पोर्टल उघडण्याचा प्रयत्न करत नाही. 'गेस्ट WiFi कनेक्ट झाले आहे पण इंटरनेट नाही' या लक्षणाचे हे सर्वात सामान्य कारण आहे.

Captive Portal रिडायरेक्टच्या त्रुटींचे निवारण: अतिथी WiFi कनेक्शन अयशस्वी होणे सोडवणे - redirect flow diagram

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 URLs साठी साधे HTTP वापरतात जेणेकरून गेटवे प्रमाणपत्र संघर्षाशिवाय त्यांना अडवू शकतील आणि पुनर्निर्देशित करू शकतील. तुमच्या गेटवेने हे HTTP प्रोब्स अडवले पाहिजेत आणि 302 पुनर्निर्देशन जारी केले पाहिजे. Captive Portal च्या उद्देशांसाठी HTTPS ट्रॅफिक अडवण्याचा प्रयत्न करू नका.

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

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

  • आयडेंटिटी प्रोव्हाइडर डोमेन्स: जर तुम्ही सोशल किंवा SSO लॉगिनसाठी Microsoft Entra ID, Okta किंवा Google Workspace वापरत असाल, तर त्यांचे ऑथेंटिकेशन एंडपॉइंट्स वॉल्ड गार्डनमध्ये असणे आवश्यक आहे.
  • CDN आणि असेट डोमेन्स: तुमचे स्प्लॅश पृष्ठ कंटेंट डिलिव्हरी नेटवर्कवरून CSS, JavaScript किंवा फॉन्ट्स लोड करू शकते. जर ते CDN डोमेन्स ब्लॉक केले असतील, तर पृष्ठ तुटलेले दिसते.
  • पेमेंट प्रोसेसर डोमेन्स: जर तुम्ही Stripe किंवा इतर प्रोसेसरद्वारे प्रवेशासाठी शुल्क आकारत असाल, तर त्यांचे JavaScript SDK डोमेन्स पूर्व-ऑथेंटिकेट केलेले असणे आवश्यक आहे.
  • 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 संपणे हे कनेक्शन अयशस्वी होण्याचे एक वारंवार घडणारे कारण आहे जे अगदी captive portal च्या समस्येसारखेच दिसते. जर DHCP पूल पूर्ण असेल, तर नवीन डिव्हाइस ऍक्सेस पॉईंटशी जोडले जाते परंतु त्याला कधीही IP ऍड्रेस मिळत नाही. IP ऍड्रेसशिवाय, डिव्हाइस HTTP प्रोब पाठवू शकत नाही आणि कधीही captive portal पर्यंत पोहोचू शकत नाही. डिव्हाइस SSID शी कनेक्ट केलेले असल्याचे दिसते परंतु इंटरनेट चालत नाही.

मँचेस्टर एअरपोर्ट्स ग्रुप (MAG) सारख्या ठिकाणांसाठी, जेथे प्रवाशांची संख्या अचानक खूप वाढते, सबनेटचा आकार सरासरी ऐवजी जास्तीत जास्त एकाच वेळी कनेक्ट होणाऱ्या डिव्हाइसच्या संख्येनुसार निश्चित केला पाहिजे. कमी DHCP लीज वेळ (क्षणिक अभ्यागतांच्या नेटवर्कसाठी १५ - ३० मिनिटे) निघून गेलेल्या डिव्हाइसेसकडून ऍड्रेस लवकर परत मिळवते.


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

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

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

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

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

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

पायरी ५: तुमच्या DHCP कक्षेचा आकार निश्चित करा. तुमच्या ठिकाणी गर्दीच्या वेळी जास्तीत जास्त एकाच वेळी असणाऱ्या डिव्हाइसच्या संख्येची गणना करा. ५०० आसनांच्या रेस्टॉरंटमध्ये व्यस्त सेवेदरम्यान ८०० डिव्हाइसेस दिसू शकतात. ३० मिनिटांच्या लीज वेळेसह DHCP पूलचा आकार १,००० ऍड्रेसवर सेट करा.

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


तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?

आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.

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

Captive Portal रिडायरेक्टच्या त्रुटींचे निवारण: अतिथी WiFi कनेक्शन अयशस्वी होणे सोडवणे - troubleshooting checklist

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

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

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

सजग-पसंतीचे ऑप्ट-इन्स (conscious-choice opt-ins) लागू करा. 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 रेझोल्यूशन तपासा. अतिथी VLAN वरील डिव्हाइसवरून, Captive Portal होस्टनेम रिझॉल्व्ह करण्याचा प्रयत्न करा. जर DNS रेझोल्यूशन अयशस्वी झाले, तर रिडायरेक्ट योग्यरित्या जारी केले असले तरीही डिव्हाइस स्प्लॅश पेजपर्यंत पोहोचू शकत नाही. तुमचे DHCP सर्व्हर विश्वासार्ह DNS पत्ते वितरीत करत असल्याची आणि गेटवे प्री-ऑथेंटिकेशन स्थितीत DNS क्वेरींना परवानगी देत असल्याची खात्री करा.

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

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

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

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

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

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

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

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

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

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


संदर्भ

[1] Troubleshooting Tip: General captive portal explanation, flow and troubleshooting. Fortinet Community, नोव्हेंबर २०२४. 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, फेब्रुवारी २०२५. 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, फेब्रुवारी २०२६. 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 8910 मध्ये परिभाषित.

Walled garden

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

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

NCSI (Network Connectivity Status Indicator)

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

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

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)

UDP पोर्ट्स 1812 (ऑथेंटिकेशन) आणि 1813 (अकाउंटिंग) वर चालणारे, केंद्रीकृत ऑथेंटिकेशन, ऑथरायझेशन आणि अकाउंटिंग (AAA) व्यवस्थापन प्रदान करणारे एक नेटवर्किंग प्रोटोकॉल.

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

MAC address caching

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

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

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 ॲक्सेस पॉइंट्स वापरणारे 200 खोल्यांचे हॉटेल नोंदवते की Android डिव्हाइसवरील अतिथी Captive Portal मध्ये प्रवेश करू शकत नाहीत, तर iOS वापरकर्ते कोणत्याही समस्येशिवाय कनेक्ट होतात. IT टीमने पुष्टी केली आहे की व्यवस्थापन VLAN मधून पोर्टल URL पोहोचण्यायोग्य आहे.

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

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

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

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

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

सराव प्रश्न

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

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

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

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

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

टीप: क्लाउड प्लॅटफॉर्मने प्रमाणीकरण (authentication) रेकॉर्ड केले आहे. बिघाड स्थानिक अंमलबजावणीच्या पायरीवर आहे.

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

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

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

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

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

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

वारंवार विचारले जाणारे प्रश्न

Why does the captive portal redirect fail to open automatically on mobile devices?

Mobile operating systems (iOS, Android, Windows) rely on unauthenticated HTTP probes to vendor endpoints (such as captive.apple.com or connectivitycheck.gstatic.com/generate_204). If the network gateway does not intercept port 80 traffic with a clean HTTP 302 redirect, or if DNS queries for those probe domains are dropped before authentication, the Captive Network Assistant (CNA) will not launch.

Why does the 'captive portal login keeps stopping' error occur on Android devices?

The 'captive portal login keeps stopping' error on Android occurs when the system WebView crashes during redirection or when the gateway drops the generate_204 HTTP probe midway through authentication. Clearing the cache of the Android System WebView or Chrome app, disabling randomized MAC addresses for the venue SSID, and navigating manually to an unencrypted HTTP probe address resolves the crash loop.

How do unencrypted HTTP sites like neverssl.com force a captive portal login screen to load?

Because modern browsers enforce HTTP Strict Transport Security (HSTS) on encrypted domains like google.com, wireless gateways cannot intercept HTTPS traffic without triggering browser certificate warnings. Navigating to an unencrypted HTTP destination such as http://neverssl.com or http://1.1.1.1 sends a plaintext request that the gateway can safely intercept with an HTTP 302 redirect to the login splash page.

Why do Android devices show 'Sign into network' errors or fail the generate_204 probe?

Android devices query clients3.google.com/generate_204 and connectivitycheck.gstatic.com. If the wireless controller or walled garden blocks access to Google IP addresses without intercepting the HTTP request with a 302 redirect, Android detects a connection error or assumes an isolated intranet, suppressing the portal prompt. Whitelisting the required probe domains or ensuring transparent HTTP redirection resolves this.

How do you prevent HTTPS certificate warnings when intercepting captive portal traffic?

When a guest browser navigates to an HTTPS domain prior to login, intercepting the TLS handshake triggers severe browser security warnings (such as NET::ERR_CERT_COMMON_NAME_INVALID) due to HSTS and certificate mismatch. Enterprise networks prevent this by leaving HTTPS traffic undisturbed and relying exclusively on plaintext HTTP probe interception to trigger the operating system's native captive portal browser.

What causes RADIUS authentication timeouts during captive portal guest login?

RADIUS timeouts occur when the wireless access point or controller fails to receive a RADIUS Access-Accept packet from the authentication server within the timeout window (typically 5 seconds). Common causes include outbound UDP ports 1812 and 1813 being filtered by perimeter firewalls, mismatched RADIUS shared secrets, or asymmetric routing between the access point and the cloud RADIUS service.

How does RFC 8910 (Captive Portal API) resolve modern captive portal connection issues?

RFC 8910 standardizes captive portal discovery via DHCP Option 114 and IPv6 Router Advertisements. Rather than intercepting DNS queries or HTTP packets, the network directly advertises the captive portal API endpoint URL to connecting client devices. Modern operating systems query this API directly, eliminating HSTS certificate collisions, DNS hijacking latency, and CNA browser rendering bugs.

How does MAC address randomisation affect captive portal reconnection?

iOS 14+ and Android 10+ rotate private MAC addresses periodically or when re-associating with SSIDs. If a guest network tracks sessions solely by physical MAC address, returning visitors are forced to authenticate repeatedly. Enterprise platforms like Purple solve this by tying session authorisation to user identity tokens and Passpoint (Hotspot 2.0) profiles rather than transient hardware MACs.

How does Purple resolve captive portal redirect failures across multi-vendor networks?

Purple operates as a hardware-agnostic cloud overlay across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Fortinet, and UniFi hardware. By automating walled garden configurations, managing trusted SSL redirect domains, and providing high-availability cloud RADIUS clusters with sub-second failover, Purple eliminates captive portal redirect drops and delivers reliable guest onboarding.

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

Ubiquiti UniFi guest portal redirection होत नाही: कारणे आणि उपाय

ही मार्गदर्शिका guest state, redirect, pre-authorisation route आणि controller authorisation यांचा अनुक्रमे मागोवा घेऊन UniFi guest portal redirect बिघाड वेगळा करते. हे वेन्यू IT टीम्सना guest-network विरुद्ध Hotspot गोंधळ, बाह्य portal हँड-ऑफ, सद्य UniFi OS खाते आवश्यकता आणि DNS आयसोलेशन चाचणीचे निराकरण करण्यासाठी एक विश्वसनीय पद्धत प्रदान करते.

मार्गदर्शिका वाचा →

Cisco Meraki splash page काम करत नाही: एक ट्रबलशूटिंग फ्लोचार्ट

हा व्यावहारिक मार्गदर्शक Cisco Meraki splash फ्लो नेमका कुठे अयशस्वी झाला आहे ते शोधून काढतो: client authorisation, HTTP redirect initiation, walled-garden reachability किंवा RADIUS sign-on. हा व्हेन्यू IT टीम्सना एक नियंत्रित पुरावा मार्ग देतो, जेणेकरून ते थेट कार्यरत असलेल्या नेटवर्क मालमत्तेत मोठे बदल न करता Guest WiFi पूर्ववत करू शकतील.

मार्गदर्शिका वाचा →

Enterprise Guest WiFi सेटअप मार्गदर्शक: VLAN विभागणी, सुरक्षा आणि Captive Portals

हे तांत्रिक मार्गदर्शक IT टीम्सना VLAN विभागणी, फायरवॉल पॉलिसी आणि captive portal चा वापर करून Guest WiFi एक नियंत्रित इंटरनेट - ऍक्सेस सेवा म्हणून कसे सेट करावे हे दर्शवते. हे मार्गदर्शक कर्मचारी, पेमेंट आणि ऑपरेशनल सिस्टम्सच्या सुरक्षिततेची सीमा कमकुवत न करता Purple चे नोंदणी फॉर्म्स आणि ऑनबोर्डिंग नियंत्रणे पाहुण्यांना एक सुयोग्य अनुभव कसा देतात हे देखील स्पष्ट करते.

मार्गदर्शिका वाचा →

तुमच्या विशिष्ट सेटअपबद्दल काही प्रश्न आहेत का?

आमची टीम ८०,००० हून अधिक वेन्यूजमधील वेन्यू ऑपरेटर्स, IT मॅनेजर्स आणि नेटवर्क इंजिनिअर्ससोबत काम करते. २० मिनिटांचा कॉल बुक करा आणि तुमच्यासारख्या इतरांनी ही समस्या कशी सोडवली हे आम्ही तुम्हाला दाखवू.