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

सार्वजनिक WiFi चे निवारण: 'Connected, No Internet' आणि Splash Page रीडायरेक्शन अपयश दुरुस्त करणे

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

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

Video overview

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

पॉडकास्ट ट्रान्सक्रिप्ट पहा
Purple कडून या तांत्रिक माहितीपत्रकात आपले स्वागत आहे. आज आपण एंटरप्राइझ वायरलेस नेटवर्किंगमधील सर्वात कायमस्वरूपी आणि चुकीच्या समजल्या जाणाऱ्या समस्यांपैकी एका समस्येचे निराकरण करत आहोत: गेस्ट WiFi captive portal जे लोड होण्यास नकार देते. तुम्हाला हा अनुभव आला असेल. एखादा पाहुणा तुमच्या हॉटेलमध्ये, रिटेल स्टोअरमध्ये, स्टेडियममध्ये किंवा कॉन्फरन्स सेंटरमध्ये येतो. ते WiFi नेटवर्कशी जोडले जातात. पण काहीच घडत नाही. लॉगिन पेज नाही. इंटरनेट नाही. फक्त फिरणारे आयकॉन आणि वाढणारी निराशा. वेन्यू ऑपरेशन्स डायरेक्टर्स आणि IT मॅनेजर्ससाठी, तो क्षण केवळ एक किरकोळ गैरसोय नसतो. तो तुमच्या गेस्ट अनुभवाचे थेट अपयश, फ्रंट-ऑफ-हाउस सपोर्ट कॉल्समध्ये झालेली वाढ आणि तुमच्या वायरलेस इन्फ्रास्ट्रक्चर गुंतवणुकीचे समर्थन करणारा फर्स्ट-पार्टी डेटा कॅप्चर करण्याची गमावलेली संधी दर्शवतो. या माहितीपत्रकात, आपण याच्या तांत्रिक बाजू समजून घेऊ. ऑपरेटिंग सिस्टम स्तरावर captive portal डिटेक्शन नेमके कसे काम करते हे आम्ही स्पष्ट करू, बहुतांश कनेक्शन अपयशासाठी कारणीभूत असलेल्या सहा मूळ कारणांची ओळख पटवून देऊ, आणि एक व्यावहारिक, कृतीयोग्य ट्रबलशूटिंग फ्रेमवर्क प्रदान करू जे तुम्ही आजच तुमच्या IT टीमकडे सोपवू शकता. चला याच्या मेकॅनिक्सपासून सुरुवात करूया. बहुतेक लोक captive portal ला फक्त एक लॉगिन पेज मानतात. परंतु प्रत्यक्षात ही नेटवर्क-स्तरीय ट्रॅफिक इंटरसेप्शन यंत्रणा आहे, आणि जेव्हा गोष्टी बिघडतात तेव्हा हा फरक अत्यंत महत्त्वाचा ठरतो. याची प्रक्रिया अशी आहे. पाहुण्याचे डिव्हाइस तुमच्या गेस्ट SSID मध्ये सामील होते आणि DHCP द्वारे IP ॲड्रेस प्राप्त करते. त्या वेळी, ऑपरेटिंग सिस्टम युझरने ब्राउझर उघडण्याची वाट पाहत नाही. बॅकग्राउंडमध्ये, एक सिस्टम सर्व्हिस त्वरित एका वेंडर-नियंत्रित प्रोब URL कडे अनइन्क्रिप्टेड HTTP GET रिक्वेस्ट पाठवते. Apple डिव्हाइसेस captive.apple.com वर क्वेरी करतात. Android डिव्हाइसेस connectivitycheck.gstatic.com वर क्वेरी करतात. Windows डिव्हाइसेस msftconnecttest.com वर क्वेरी करतात. Firefox चे detectportal.firefox.com वर स्वतःचे प्रोब असते. जर नेटवर्ककडे ओपन इंटरनेट ॲक्सेस असेल, तर या प्रोब्स त्यांच्या अपेक्षेनुसार प्रतिसाद देतात, आणि ऑपरेटिंग सिस्टम असा निष्कर्ष काढते की सर्वकाही ठीक आहे. परंतु गेस्ट नेटवर्कवर, तुमचे वायरलेस गेटवे किंवा कंट्रोलर तो HTTP प्रोब इंटरनेटवर पोहोचण्यापूर्वीच थांबवतो. अपेक्षित प्रतिसादाऐवजी, गेटवे तुमच्या captive portal स्प्लॅश पेजकडे निर्देशित करणारा HTTP 307 रीडायरेक्ट परत करतो. ऑपरेटिंग सिस्टमला हा अनपेक्षित रीडायरेक्ट आढळतो, तिला समजते की ती captive portal च्या मागे आहे, आणि लॉगिन पेज दाखवण्यासाठी ती एक सँडबॉक्स केलेले ब्राउझर विंडो - ज्याला सहसा Captive Network Assistant म्हटले जाते - उघडते. हा सुरळीत चालणारा मार्ग आहे. आता आपण त्या सहा मार्गांबद्दल बोलूया ज्यांमुळे ही प्रक्रिया खंडित होते. मूळ कारण क्रमांक एक: DHCP पूल संपणे. हाय-डेन्सिटी इव्हेंट्समध्ये हा एक छुपा अडथळा ठरतो. तुम्ही मानक स्लॅश-24 सबनेटवर दोन हजार उपस्थितांसह परिषद चालवत असल्यास, तुमच्याकडे 254 वापरण्यायोग्य IP पत्ते असतात. तुमचा DHCP लीज टाईम डीफॉल्ट 24 तासांवर सेट असल्यास, दरवाजे उघडल्यानंतर काही मिनिटांतच तो पूल संपून जाईल. यानंतरचा प्रत्येक कनेक्शनचा प्रयत्न Captive Portal प्रक्रिया सुरू होण्यापूर्वीच अयशस्वी होतो. याचे निवारण सोपे आहे: जास्त आवर्तन असलेल्या वातावरणासाठी गेस्ट DHCP लीज टाईम 15 ते 30 मिनिटांच्या दरम्यान सेट करा आणि केवळ एकूण उपस्थिती न पाहता पीक कन्सुरंट युजर्ससाठी तुमचे सबनेट योग्य आकाराचे ठेवा. मूळ कारण क्रमांक दोन: DNS इंटरसेप्शन अयशस्वी होणे. Captive Portal रिडायरेक्ट हा गेटवेवर HTTP प्रोब इंटरसेप्ट करण्यावर अवलंबून असतो. परंतु या प्रोबसाठी आधी DNS लुकअप आवश्यक असते. तुमचे DNS कॉन्फिगरेशन प्री-ऑथेंटिकेटेड क्लायंट्सना बाह्य डोमेन नावे रिझोल्व्ह करण्याची परवानगी देत नसेल, तर प्रोब कधीही फायर होत नाही. तुमची फायरवॉल पॉलिसी अनऑथेंटिकेटेड क्लायंट्सकडून DNS क्वेरींना स्पष्टपणे परवानगी देत असल्याची खात्री करा, आणि टेस्ट डिव्हाइसवर पॅकेट कॅप्चर चालवून तुमचे DNS इंटरसेप्शन कार्य करत असल्याचे सत्यापित करा. मूळ कारण क्रमांक तीन: अपूर्ण वॉल्ड गार्डन. वॉल्ड गार्डन - ज्याला प्री-ऑथेंटिकेशन ॲक्सेस कंट्रोल लिस्ट देखील म्हटले जाते - हे अनऑथेंटिकेटेड अतिथी कोणत्या बाह्य डोमेनपर्यंत पोहोचू शकतात हे परिभाषित करते. जर तुमचे पोर्टल स्प्लॅश पेज वॉल्ड गार्डनमध्ये नसलेल्या CDN कडून ॲसेट्स लोड करत असेल, तर पेज रिकाम्या स्क्रीनसारखे दिसेल. तुम्ही Google, Apple, किंवा Facebook द्वारे सोशल लॉगिन ऑफर करत असल्यास, ते प्रोव्हाइडर्स वापरत असलेले प्रत्येक OAuth डोमेन व्हाईटलिस्ट केलेले असणे आवश्यक आहे. आणि येथे एक महत्त्वाचा मुद्दा आहे: सोशल आयडेंटिटी प्रोव्हाइडर्स त्यांच्या CDN IP श्रेणी आणि ऑथेंटिकेशन डोमेन नियमितपणे अपडेट करतात. सहा महिन्यांपूर्वी उत्तम प्रकारे काम करणारे वॉल्ड गार्डन आज अचानक बंद पडू शकते. त्रैमासिक वॉल्ड गार्डन ऑडिटचे नियोजन करा आणि तुमचे हार्डवेअर सपोर्ट करत असेल तेथे वाईल्डकार्ड डोमेन स्नूपिंग वापरा. Cisco Meraki, HPE Aruba, Ruckus, आणि Juniper Mist वर हे नेटिव्हली उपलब्ध आहे. मूळ कारण क्रमांक चार: HSTS रिडायरेक्ट ब्लॉक करणे. HTTP Strict Transport Security, किंवा HSTS, ही ब्राउझरची एक सुरक्षा पॉलिसी आहे जी विशिष्ट डोमेनचे कनेक्शन केवळ HTTPS वरच सक्तीने चालवते. जर अतिथीचे डिव्हाइस HSTS-प्रीलोडेड डोमेनशी संपर्क साधण्याचा प्रयत्न करत असेल - ज्यामध्ये अक्षरशः प्रत्येक मोठ्या वेबसाइटचा समावेश होतो - आणि तुमचा गेटवे पोर्टलवर रिडायरेक्ट करण्यासाठी त्या HTTPS रिक्वेस्टला इंटरसेप्ट करण्याचा प्रयत्न करत असेल, तर ब्राउझरला सर्टिफिकेट मिसमॅच आढळते. ते बायपास न करता येणारी सुरक्षा चेतावणी दर्शवते आणि रिडायरेक्ट पूर्णपणे ब्लॉक करते. योग्य सोल्यूशन म्हणजे HTTPS इंटरसेप्शनचा कधीही प्रयत्न न करणे. तुमच्या गेटवेने केवळ अनइन्क्रिप्टेड HTTP कॅनरी प्रोब्स रिडायरेक्ट केले पाहिजेत. दीर्घकालीन मानकांवर आधारित उपाय म्हणजे RFC 8910 आहे, जे DHCP Option 114 परिभाषित करते. हा पर्याय तुमच्या DHCP सर्व्हरला क्लायंट डिव्हाइसवर थेट Captive Portal URL ॲडव्हर्टाइज करण्याची परवानगी देतो, ज्यामुळे HTTP रिडायरेक्शनची आवश्यकता पूर्णपणे नाहीशी होते. iOS 14 आणि Android 11 आणि त्यावरील व्हर्जन याला नेटिव्हली सपोर्ट करतात. मूळ कारण क्रमांक पाच: अतिथी डिव्हाइसवर सक्रिय असलेले VPN. VPN हे डिव्हाइसवरील सर्व ट्रॅफिक एन्क्रिप्ट करते आणि तुमच्या गेटवेपर्यंत पोहोचण्यापूर्वी त्याला बाह्य टनेलमधून मार्गस्थ करते. तुमच्या गेटवेला HTTP शोध कधीच दिसत नाही. Captive Portal शोधण्याची प्रक्रिया कधीच सुरू होत नाही. अतिथीला कोणतेही लॉगिन पेज आणि इंटरनेट दिसत नाही. अतिथीसाठी यावर सोपा उपाय आहे: VPN निष्क्रिय करा, पोर्टलशी कनेक्ट व्हा आणि नंतर VPN पुन्हा सक्रिय करा. अतिथीने कनेक्शनची समस्या नोंदवल्यास तुमच्या फ्रंट-ऑफ-हाउस कर्मचाऱ्यांनी त्यांना विचारलेला हा पहिला प्रश्न असावा. मूळ कारण क्रमांक सहा: MAC ॲड्रेस रँडमायझेशनमुळे सेशन सातत्य खंडित होणे. आधुनिक iOS आणि Android डिव्हाइसेस प्रायव्हसी वैशिष्ट्य म्हणून डीफॉल्टनुसार रँडमायझेशन केलेले MAC ॲड्रेसेस वापरतात. प्रत्येक वेळी जेव्हा एखादे डिव्हाइस नेटवर्कशी कनेक्ट होते, तेव्हा ते वेगळा MAC ॲड्रेस दर्शवू शकते. Captive Portal सेशनची स्थिती MAC ॲड्रेसद्वारे ट्रॅक केली जात असल्याने, ज्या अतिथीने एका तासापूर्वी ऑथेंटिकेशन केले होते त्याला त्याच्या डिव्हाइसचा MAC रोटेट झाल्यानंतर पुन्हा लॉगिन पेज दिसू शकते. अतिथीच्या बाजूने यावर उपाय म्हणजे नेटवर्क सेटिंग्जमध्ये तुमच्या विशिष्ट SSID साठी Private Address निष्क्रिय करणे. ऑपरेटरच्या बाजूने यावर उपाय म्हणजे प्रोफाइल-आधारित ऑथेंटिकेशन लागू करणे - जसे की Passpoint आणि 802.1X द्वारे OpenRoaming - जे MAC ॲड्रेसेसऐवजी क्रेडेंशियल्स वापरून लेयर २ वर ऑथेंटिकेशन करते, ज्यामुळे रँडमायझेशन निरर्थक ठरते. आता आपण अंमलबजावणीबद्दल बोलूया. चांगल्या प्रकारे कॉन्फिगर केलेले captive portal डिप्लॉयमेंट प्रत्यक्षात कसे दिसते? तुमच्या DHCP आर्किटेक्चरपासून सुरुवात करा. २०० पेक्षा जास्त एकाच वेळी वापरल्या जाणाऱ्या डिव्हाइसेसची अपेक्षा असलेल्या कोणत्याही ठिकाणासाठी, सिंगल स्लॅश-२४ सबनेट वापरणे थांबवा. स्लॅश-२२ किंवा त्याहून मोठे सबनेट वापरा आणि तुमच्या ठिकाणाच्या वास्तव्याच्या प्रोफाइलनुसार लीज टाईम सेट करा. हॉटेल ८ तासांसाठी लीज सेट करते. स्टेडियम ३ तासांसाठी लीज सेट करते. शॉपिंग सेंटर ९० मिनिटांसाठी लीज सेट करते. कॉन्फरन्स सेंटर ३० मिनिटांसाठी लीज सेट करते. यानंतर, प्रत्येक मोठ्या इव्हेंटपूर्वी तुमच्या वॉल्ड गार्डनची (walled garden) पडताळणी करा. यासाठी आवश्यक असलेल्या किमान नोंदी आहेत: तुमच्या पोर्टलचे पूर्णपणे पात्र डोमेन नाव (fully qualified domain name) आणि सर्व संबंधित CDN डोमेन्स, Apple, Google, Windows आणि Firefox साठी captive portal डिटेक्ट करणारे URLs, आणि तुम्ही सपोर्ट करत असलेल्या प्रत्येक सोशल लॉगिन प्रोव्हाइडरचे OAuth डोमेन्स. Purple च्या प्लॅटफॉर्मवर, आम्ही आमच्या क्लाउड-मॅनेज्ड सेवेचा भाग म्हणून या वॉल्ड गार्डन नोंदी स्वयंचलितपणे देखरेख आणि अपडेट करतो, ज्यामुळे तुमच्या टीमवरील मॅन्युअल देखभालीचा भार कमी होतो. तुमच्या पोर्टल प्रमाणपत्रासाठी, मान्यताप्राप्त सर्टिफिकेट ऑथॉरिटीकडून सार्वजनिकरित्या विश्वसनीय असलेले TLS प्रमाणपत्र वापरा. सेल्फ-साइन केलेले प्रमाणपत्र प्रत्येक डिव्हाइसवर ब्राउझर चेतावणी देईल. प्रमाणपत्रे कालबाह्य होण्यापूर्वी त्यांचे नूतनीकरण करा - अचानक, संपूर्ण ठिकाणी पोर्टल अयशस्वी होण्याच्या सर्वात सामान्य कारणांपैकी एक म्हणजे कालबाह्य झालेले प्रमाणपत्र होय. एक अडचण ज्यामध्ये अनेक IT टीम अडकतात: पूर्वी ऑथेंटिकेशन केलेल्या डिव्हाइसवरून पोर्टलची चाचणी घेणे. तुमच्या डिव्हाइसचे सेशन अद्याप सक्रिय असते, त्यामुळे तुम्ही पोर्टल पूर्णपणे बायपास करता आणि सर्व काही व्यवस्थित काम करत असल्याचा निष्कर्ष काढता. नेहमी नवीन, अन-ऑथेंटिकेट स्थितीत असलेल्या डिव्हाइसवरून चाचणी घ्या - एकतर नवीन डिव्हाइस, किंवा असे डिव्हाइस ज्यामध्ये तुम्ही नेटवर्क विसरलात (forget network) आणि WiFi प्रोफाइल साफ केले आहे.या तत्त्वांचे स्पष्टीकरण देणारी दोन वास्तविक परिस्थितीची उदाहरणे मी तुम्हाला देतो. पहिली परिस्थिती: मध्य लंडनमध्ये असलेले ३५० खोल्यांचे एक हॉटेल. ही मालमत्ता अतिथी WiFi साठी सिंगल स्लॅश-२४ सबनेट चालवत होती. एका मोठ्या परिषदेदरम्यान, एकाच वेळी ४०० प्रतिनिधी आले. २० मिनिटांच्या आत, DHCP पूल संपला. अतिथींनी नेटवर्कशी जोडले गेले असल्याचे पण Captive Portal किंवा इंटरनेटपर्यंत पोहोचू शकत नसल्याचे कळवले. यावर त्वरित उपाय म्हणून सबनेट स्लॅश-२२ पर्यंत वाढवण्यात आले, ज्यामुळे १,०२२ वापरण्यायोग्य पत्ते मिळाले, आणि लीज वेळ २४ तासांवरून ८ तास करण्यात आली. दीर्घकालीन उपाय म्हणजे Purple चे क्लाउड-व्यवस्थापित Captive Portal लागू करणे, जे रिअल-टाइममध्ये DHCP पूल वापराचे निरीक्षण करते आणि पूल संपण्यापूर्वी नेटवर्क टीमला सतर्क करते. हा बदल केल्यानंतर ४८ तासांच्या आत पोर्टल अपयशाचा दर जवळपास शून्यावर आला. दुसरी परिस्थिती: २०० स्टोअर्स असलेली एक मोठी रिटेल साखळी. या साखळीने त्यांच्या अतिथी पोर्टलवर Google आणि Facebook द्वारे सोशल लॉगिनचा वापर केला होता. Google ने त्याचे OAuth इन्फ्रास्ट्रक्चर अपडेट केल्यानंतर, नवीन ऑथेंटिकेशन डोमेन्स वॉल्ड गार्डन (walled garden) मध्ये नव्हते. अतिथी पोर्टल पेजपर्यंत पोहोचू शकत होते परंतु सोशल लॉगिन बटणांवर क्लिक केल्यावर रिकामी स्क्रीन दिसत होती. वॉल्ड गार्डन मधील ही त्रुटी ओळखण्यापूर्वी साखळीच्या IT टीमने समस्येचे निदान करण्यासाठी दोन दिवस घालवले. एकदा त्रुटी समजल्यावर ती दुरुस्त करण्यासाठी १० मिनिटे लागली. यातून मिळालेला धडा: क्लाउड-आधारित OAuth प्रदात्यांसाठी तुमच्या वॉल्ड गार्डनमध्ये कधीही IP पत्ते हार्डकोड करू नका. वाईल्डकार्ड डोमेन एंट्रीज वापरा आणि त्यांचे त्रैमासिक पुनरावलोकन करा. आता वेन्यू IT टीम्सकडून आम्हाला नियमितपणे ऐकायला मिळणारे काही जलद प्रश्न पाहूया. पोर्टल iPhones वर काम करते परंतु Android उपकरणांवर का करत नाही? Android त्याचे प्रोब URL म्हणून connectivitycheck.gstatic.com वापरते. जर तो डोमेन तुमच्या फायरवॉलद्वारे ब्लॉक केला असेल किंवा तुमच्या वॉल्ड गार्डनमध्ये नसेल, तर Android उपकरणे कधीही पोर्टल ट्रिगर करत नाहीत. तो स्पष्टपणे जोडा. एक अतिथी सांगतो की पोर्टल लोड झाले परंतु लॉग इन केल्यानंतर ते ऑनलाइन जाऊ शकत नाहीत. हे जवळजवळ नेहमीच RADIUS ऑथरायझेशन अपयश असते. तुमचा RADIUS सर्व्हर वायरलेस कंट्रोलरवरून पोहोचण्यायोग्य असल्याची खात्री करा, दोन्ही बाजूंनी सामायिक केलेले गुपिते (shared secret) जुळत असल्याचे तपासा, आणि Access-Reject संदेशांसाठी RADIUS लॉगचे पुनरावलोकन करा. काही मिनिटांनंतर वारंवार लॉग आउट होणाऱ्या अतिथींना आम्ही कसे हाताळावे? तुमचे आयडल टाइमआउट (idle timeout) सेटिंग तपासा. अनेक कंट्रोलर्स डीफॉल्टनुसार ५ मिनिटांच्या आयडल टाइमआउटवर सेट असतात, जे परस्परसंवादाच्या दरम्यान स्लीप मोडवर जाणाऱ्या मोबाइल उपकरणांसाठी खूपच कमी आहे. आदरातिथ्य (hospitality) आणि रिटेल वातावरणासाठी आयडल टाइमआउट किमान ३० मिनिटांवर सेट करा. आजच्या ब्रीफिंगमधील मुख्य मुद्द्यांचा सारांश. अतिथी WiFi Captive Portal चे अपयश सहा श्रेणींमध्ये विभागले जाते: DHCP पूल संपणे, DNS इंटरसेप्शन अपयश, अपूर्ण वॉल्ड गार्डन, HSTS रीडायरेक्ट ब्लॉकिंग, क्लायंट डिव्हाइसवर सक्रिय VPN, आणि MAC address यादृच्छिकीकरण (randomisation). प्रत्येकावर एक विशिष्ट, तपासण्यायोग्य उपाय आहे. तुमच्या IT टीमसाठी त्वरित कृती या आहेत: तुमच्या DHCP लीज वेळा आणि सबनेट आकाराचे ऑडिट करा, तुमच्या सोशल लॉगिन प्रदात्यांच्या सद्य OAuth डोमेन्सच्या विरूद्ध तुमच्या वॉल्ड गार्डनची पडताळणी करा, आणि प्रत्येक कॉन्फिगरेशन बदलानंतर नवीन अनऑथेंटिकेटेड डिव्हाइसवरून तुमच्या पोर्टलची चाचणी घ्या.तुमच्या दीर्घकालीन रोडमॅपसाठी, परत येणाऱ्या अभ्यागतांसाठी Captive Portal री-ऑथेंटिकेशनला पर्याय म्हणून OpenRoaming चे मूल्यांकन करा. हे तंत्रज्ञान प्रगत आहे, IEEE 802.1X आणि WPA3-Enterprise अंतर्गत त्याचे मानक स्थापित केले गेले आहेत, आणि Purple ते Connect प्लॅन अंतर्गत कोणत्याही अतिरिक्त सॉफ्टवेअर खर्चाशिवाय उपलब्ध करून देते. Purple ८०,००० पेक्षा जास्त ठिकाणी कार्यरत आहे आणि केवळ २०२४ मध्ये ४४० दशलक्ष लॉगइन्स प्रविष्ट केले आहेत. आम्ही या माहितीपत्रकात वर्णन केलेले प्रत्येक बिघाड मोड पाहिले आहे - आणि ते टाळण्यासाठी टूल्स तयार केली आहेत. Purple चे क्लाउड ओव्हरले तुमच्या सध्याच्या Cisco Meraki, HPE Aruba, Ruckus किंवा Juniper Mist इन्फ्रास्ट्रक्चरशी कसे समाकलित होते हे तुम्हाला पाहायचे असल्यास, purple.ai ला भेट द्या किंवा तुमच्या खाते व्यवस्थापकाशी संपर्क साधा. ऐकल्याबद्दल धन्यवाद.

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

Interactive Network Diagnostic Tool

Public WiFi & Captive Portal Redirection Diagnostic Tool

Diagnose the root cause of splash page redirection failures, probe timeouts, and 'Connected, No Internet' errors across client operating systems and enterprise wireless controllers.

Diagnosis for:Apple iOS (iPhone / iPad)+Cisco Meraki

Root Cause Mechanism

The wireless controller or gateway is failing to intercept cleartext HTTP port 80 requests, or DNS queries for probe domains are being dropped by upstream firewalls before authentication.

Client OS Captive Portal Probe Details
Probe URL:http://captive.apple.com/hotspot-detect.html
Expected Success Status:HTTP 200 with "Success" body string
Detection Daemon:Captive Network Assistant (CNA daemon)
OS behaviour: Fires instantly upon L2 association. If HTTP 302 is received, opens a restricted modal web sheet without full Safari features (e.g. strict cookie storage, no tabs).

Recommended Remediation Actions

  1. Verify that UDP port 53 (DNS) is completely open in pre-authentication firewall policies to allow probe domain resolution.
  2. Ensure the AP or gateway intercepts cleartext HTTP requests (TCP 80) and issues an immediate HTTP 302 Found redirect to the portal URL.
  3. Do not intercept HTTPS port 443 before authentication, as HSTS and TLS SNI mismatches will trigger security warnings.
  4. Instruct users to test manual fallback URLs such as http://neverssl.com or http://captive.apple.com to trigger redirection.
Cisco Meraki Walled Garden & Controller Path:

Configuration Location: Wireless > Configure > Access control > Splash page

# Meraki Dashboard Configuration
1. Set Association Requirements to "Open (no encryption)"
2. Set Splash page to "Sign-on splash page / External captive portal"
3. In "Walled garden", add: *.purple.ai, *.purpleserver.net
4. Enable "RADIUS CoA (RFC 5176)" on port 3799
Pre-auth walled garden FQDNs: *.purple.ai*.purpleserver.net
Do not add the OS probe hosts (captive.apple.com, connectivitycheck.gstatic.com, msftconnecttest.com): if they answer before login, the device decides it is online and never shows the portal.

Eliminate Public WiFi Redirection Failures Across Your Estate

Purple's hardware-agnostic cloud guest WiFi platform eliminates captive portal drops, delivers sub-second splash page loading, and manages pre-auth walled gardens across Cisco Meraki, Aruba, Ruckus, and UniFi.

Useful? Link to this tool

Executive Summary

सार्वजनिक WiFi चे निवारण: 'Connected, No Internet' आणि Splash Page रीडायरेक्शन अपयश दुरुस्त करणे

एक पाहुणा तुमच्या WiFi शी जोडला जातो, परंतु लॉगिन पेज लोड होण्यास अपयशी ठरते. त्यांना 'Connected, No Internet' अशी चेतावणी दिसते आणि ते प्रयत्न सोडून देतात. व्हेन्यू ऑपरेशन्स डायरेक्टर्स आणि IT मॅनेजर्ससाठी, हे अपयश थेट पाहुण्यांच्या अनुभवातील घसरण, सपोर्ट तिकिटांमधील वाढ आणि प्रथम-पक्ष डेटा गोळा करण्याची गमावलेली संधी दर्शवते, जी वायरलेस इन्फ्रास्ट्रक्चरमधील गुंतवणुकीचे समर्थन करते.

हे मार्गदर्शक ऑपरेटिंग सिस्टम स्तरावर Captive Portal डिटेक्शन नेमके कसे कार्य करते हे स्पष्ट करते आणि बहुतेक कनेक्शन अपयशांसाठी कारणीभूत असलेल्या सहा मूळ कारणांची ओळख पटवते. हे DHCP एक्झॉस्शन, DNS इंटरसेप्शन अपयश, अपूर्ण वॉल्ड गार्डन्स, ब्लॉक केलेले HSTS रीडायरेक्ट्स, सक्रिय VPN संघर्ष आणि MAC ॲड्रेस रँडमायझेशन समस्यांचे निराकरण करण्यासाठी एक व्यावहारिक, व्हेंडर-तटस्थ ट्रबलशूटिंग फ्रेमवर्क प्रदान करते.

Technical Deep-Dive: How Captive Portal Detection Actually Works

Captive Portal मधील समस्यांचे निवारण करण्यासाठी, तुम्हाला प्रथम हे समजून घेणे आवश्यक आहे की नेटवर्क स्तरावर Captive Portal नेमके काय करते. हे केवळ एक लॉगिन पेज नाही; हे नेटवर्क-स्तरीय ट्रॅफिक इंटरसेप्शन मेकॅनिझम आहे.

जेव्हा एखादे पाहुण्याचे डिव्हाइस पाहुण्यांच्या SSID मध्ये सामील होते, तेव्हा त्याला DHCP द्वारे एक IP ॲड्रेस प्राप्त होतो. ऑपरेटिंग सिस्टम वापरकर्त्याने ब्राउझर उघडण्याची वाट पाहत नाही. त्याऐवजी, बॅकग्राउंड सिस्टम सर्व्हिस त्वरित एका व्हेंडर-नियंत्रित प्रोब URL कडे एक अनइनक्रिप्टेड HTTP GET विनंती पाठवते. Apple डिव्हाइसेस captive.apple.com वर क्वेरी करतात. Android डिव्हाइसेस connectivitycheck.gstatic.com वर क्वेरी करतात. Windows डिव्हाइसेस msftconnecttest.com वर क्वेरी करतात. Firefox detectportal.firefox.com वर क्वेरी करते.

जर नेटवर्कला ओपन इंटरनेट ॲक्सेस असेल, तर या प्रोब त्यांचे अपेक्षित HTTP 200 OK प्रतिसाद परत करतात आणि ऑपरेटिंग सिस्टम कनेक्शन सक्रिय असल्याचे ठरवते. तथापि, पाहुण्यांच्या नेटवर्कवर, वायरलेस गेटवे किंवा कंट्रोलर हा HTTP प्रोब इंटरनेटवर पोहोचण्यापूर्वीच अडवतो. अपेक्षित प्रतिसादाऐवजी, गेटवे एक HTTP 307 Temporary Redirect परत करतो जो Captive Portal च्या स्लॅश पेजकडे निर्देशित करतो. ऑपरेटिंग सिस्टमला हा अनपेक्षित रीडायरेक्ट आढळतो, हे समजते की ते Captive Portal च्या मागे आहे आणि लॉगिन पेज प्रदर्शित करण्यासाठी सँडबॉक्स केलेले ब्राउझर विंडो (कॅप्टिव्ह नेटवर्क असिस्टंट) उघडते.

सार्वजनिक WiFi चे निवारण: 'Connected, No Internet' आणि Splash Page रीडायरेक्शन अपयश दुरुस्त करणे - portal architecture diagr…

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

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

Troubleshooting & Risk Mitigation: The 6 Root Causes of Failure

जेव्हा Captive Portal लोड होण्यात अपयशी ठरते, तेव्हा ही समस्या जवळजवळ नेहमीच सहा विशिष्ट अपयशाच्या पद्धतींपैकी एका पद्धतीमुळे उद्भवलेली असते.

सार्वजनिक WiFi चे निवारण: 'Connected, No Internet' आणि Splash Page रीडायरेक्शन अपयश दुरुस्त करणे - root causes infographic

१. DHCP Pool संपणे (Exhaustion)

उच्च गर्दीच्या कार्यक्रमांमध्ये ही एक छुपी समस्या आहे. जर तुम्ही २,००० उपस्थितांसह एक परिषद चालवत असाल आणि मानक /24 सबनेट वापरत असाल, तर तुमच्याकडे फक्त २५४ वापरण्यायोग्य IP पत्ते असतात. जर तुमची DHCP लीझ वेळ डीफॉल्ट २४ तासांवर सेट असेल, तर दरवाजे उघडल्यापासून काही मिनिटांतच तुमचा पूल संपून जाईल. त्यानंतरचा प्रत्येक कनेक्शनचा प्रयत्न Captive Portal प्रक्रिया सुरू होण्यापूर्वीच अयशस्वी होईल.

उपाय: जास्त आवक-जावक असलेल्या वातावरणासाठी अतिथी DHCP लीझ वेळ १५ ते ३० मिनिटांच्या दरम्यान सेट करा. केवळ सरासरी उपस्थितीनुसार नाही, तर पीक काळातील एकाच वेळी वापरणाऱ्या वापरकर्त्यांच्या संख्येनुसार तुमचे सबनेट आकाराचे ठेवा. एक /22 सबनेट १,०२२ वापरण्यायोग्य पत्ते प्रदान करते, जे एंटरप्राइझ ठिकाणांसाठी शिफारस केलेले किमान आकार आहे.

२. DNS Interception अयशस्वी होणे

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

उपाय: तुमच्या फायरवॉल पॉलिसी अनऑथेंटिकेटेड क्लायंटकडून DNS क्वेरींना (पोर्ट ५३) स्पष्टपणे परवानगी देतात याची खात्री करा. तुमच्या DNS इंटरसेप्शन कार्य करत आहे की नाही हे तपासण्यासाठी चाचणी डिव्हाइसवर पॅकेट कॅप्चर चालवा.

३. अपूर्ण Walled Garden

Walled garden (प्री-ऑथेंटिकेशन ॲक्सेस कंट्रोल लिस्ट) हे ठरवते की अनऑथेंटिकेटेड अतिथी कोणत्या बाह्य डोमेनवर पोहोचू शकतात. जर तुमचे पोर्टल स्प्लॅश पेज अशा CDN वरून मालमत्ता लोड करत असेल जे walled garden मध्ये समाविष्ट नाही, तर ते पेज रिकाम्या स्क्रीनसारखे दिसेल. जर तुम्ही Google, Apple, किंवा Microsoft Entra ID द्वारे सोशल लॉगिन ऑफर करत असाल, तर त्या प्रदात्यांद्वारे वापरले जाणारे प्रत्येक OAuth डोमेन व्हाइटलिस्ट केलेले असणे आवश्यक आहे. सोशल आयडेंटिटी प्रदाते नियमितपणे त्यांचे CDN IP श्रेणी आणि ऑथेंटिकेशन डोमेन अपडेट करतात; सहा महिन्यांपूर्वी उत्तम चालणारे walled garden एका रात्रीत बंद पडू शकते.

उपाय: त्रैमासिक walled garden ऑडिटचे वेळापत्रक आखा. जिथे तुमचे हार्डवेअर सपोर्ट करते, तिथे वाइल्डकार्ड डोमेन स्नूपिंग वापरा, जे Cisco Meraki, HPE Aruba, Ruckus आणि Juniper Mist वर मूळ स्वरूपात उपलब्ध आहे. Purple आमच्या क्लाउड-मॅनेज्ड सेवेचा भाग म्हणून या walled garden नोंदी आपोआप राखते आणि अपडेट करते.

४. HSTS रिडायरेक्ट ब्लॉक होणे

HTTP Strict Transport Security (HSTS) हे ब्राउझर सुरक्षा धोरण आहे जे विशिष्ट डोमेनशी केवळ HTTPS द्वारे कनेक्शन सक्तीचे करते. जर अतिथी डिव्हाइसने HSTS-प्रीलोडेड डोमेनशी संवाद साधण्याचा प्रयत्न केला आणि तुमच्या गेटवेने पोर्टलवर रिडायरेक्ट करण्यासाठी त्या HTTPS विनंतीला इंटरसेप्ट करण्याचा प्रयत्न केला, तर ब्राउझरला प्रमाणपत्र जुळत नसल्याचे (certificate mismatch) आढळते. हे टाळता न येणारी सुरक्षा चेतावणी दर्शवते आणि रिडायरेक्ट पूर्णपणे ब्लॉक करते. सोल्यूशन: सुरुवातीच्या रिडायरेक्टसाठी कधीही HTTPS इंटरसेप्शनचा प्रयत्न करू नका. तुमचे गेटवे केवळ अनएनक्रिप्टेड HTTP कॅनरी प्रोब्सलाच रिडायरेक्ट करेल याची खात्री करा. दीर्घकालीन मानकांवर आधारित सोल्यूशन म्हणजे RFC 8910 आहे, जे DHCP Option 114 परिभाषित करते. हा पर्याय तुमच्या DHCP सर्व्हरला Captive Portal URL थेट क्लायंट डिव्हाइसवर जाहिरात करण्याची परवानगी देतो, ज्यामुळे HTTP रिडायरेक्शनची आवश्यकता पूर्णपणे नाहीशी होते. iOS 14 आणि Android 11 आणि त्यावरील व्हर्जन याला नेटिव्हली सपोर्ट करतात.

5. क्लायंट डिव्हाइसवर ॲक्टिव्ह VPN

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

सोल्यूशन: पाहुण्याने VPN डिसेबल करणे, पोर्टलशी कनेक्ट करणे आणि नंतर पुन्हा VPN इनेबल करणे आवश्यक आहे. फ्रंट-ऑफ-हाउस कर्मचाऱ्यांसाठी, पाहुणा VPN वापरत आहे का हे विचारणे ही पहिली ट्रबलशूटिंग पायरी असावी.

6. MAC Address Randomisation मुळे सेशन सातत्य खंडित होणे

मॉडर्न iOS आणि Android डिव्हाइसेस प्रायव्हसी वैशिष्ट्य म्हणून डीफॉल्टनुसार रँडमाइज्ड MAC ॲड्रेस वापरतात. प्रत्येक वेळी जेव्हा एखादे डिव्हाइस नेटवर्कशी कनेक्ट होते, तेव्हा ते वेगळा MAC ॲड्रेस सादर करू शकते. Captive Portal सेशनची स्थिती MAC ॲड्रेसद्वारे ट्रॅक केली जात असल्याने, एका तासापूर्वी ऑथेंटिकेट झालेल्या पाहुण्याला त्यांच्या डिव्हाइसचा MAC बदलल्यानंतर पुन्हा लॉगिन पेज दाखवले जाऊ शकते.

सोल्यूशन: पाहुण्यांसाठी सोल्यूशन म्हणजे त्यांच्या नेटवर्क सेटिंग्जमध्ये तुमच्या विशिष्ट SSID साठी Private Address डिसेबल करणे. ऑपरेटर-साइड सोल्यूशन म्हणजे प्रोफाइल-आधारित ऑथेंटिकेशन लागू करणे, जसे की 802.1X द्वारे Passpoint आणि OpenRoaming, जे MAC ॲड्रेस ऐवजी क्रेडेंशियल वापरून लेयर 2 वर ऑथेंटिकेट करते, ज्यामुळे रँडमायझेशन निरर्थक ठरते.

अंमलबजावणी मार्गदर्शक: एक लवचिक आर्किटेक्चर तयार करणे

एक चांगल्या प्रकारे कॉन्फिगर केलेले Captive Portal तैनात करण्यासाठी सक्रिय आर्किटेक्चरल निर्णयांची आवश्यकता असते.

  1. प्रत्येक मोठ्या इव्हेंटपूर्वी तुमच्या वॉल्ड गार्डनची पडताळणी करा. किमान आवश्यक नोंदी आहेत: तुमच्या पोर्टलचे FQDN आणि सर्व संबंधित CDN डोमेन्स, Apple, Google, Windows आणि Firefox साठी Captive Portal डिटेक्शन URLs, आणि तुम्ही सपोर्ट करत असलेल्या प्रत्येक सोशल लॉगिन प्रोव्हाइडरसाठी OAuth डोमेन्स.
  2. सार्वजनिकरित्या विश्वसनीय TLS सर्टिफिकेट वापरा. सेल्फ-साइन केलेले सर्टिफिकेट्स प्रत्येक डिव्हाइसवर ब्राउझर चेतावणी ट्रिगर करतील. सर्टिफिकेट्स कालबाह्य होण्यापूर्वी त्यांचे नूतनीकरण करा; कालबाह्य झालेले सर्टिफिकेट हे अचानक, संपूर्ण वेन्यूवर पोर्टल अयशस्वी होण्याचे सर्वात सामान्य कारणांपैकी एक आहे.
  3. नवीन, अनऑथेंटिकेटेड स्थितीमधून चाचणी करा. पूर्वी ऑथेंटिकेट केलेल्या डिव्हाइसवरून पोर्टलची चाचणी घेतल्यास पोर्टल पूर्णपणे बायपास होईल कारण सेशन अजूनही ॲक्टिव्ह असते. नेहमी नवीन डिव्हाइसवरून चाचणी करा, किंवा अशा डिव्हाइसवरून करा जिथे तुम्ही नेटवर्क विसरला आहात आणि WiFi प्रोफाइल डिलीट केले आहे.
  4. आयडल टाइमआउट्स ॲडजस्ट करा. अनेक कंट्रोलर्स डीफॉल्टनुसार 5 मिनिटांच्या आयडल टाइमआउटवर सेट असतात, जे मोबाईल डिव्हाइसेससाठी अत्यंत आक्रमक आहे जे वापराच्या दरम्यान स्लीप मोडमध्ये जातात. हॉस्पिटॅलिटी आणि रिटेल वातावरणासाठी आयडल टाइमआउट किमान 30 मिनिटांवर सेट करा.

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

Captive Portals हे एक प्रगत तंत्रज्ञान आहे, परंतु त्यामध्ये काही अंगभूत गुंतागुंत आहेत. अखंड आणि सुरक्षित प्रमाणीकरणाकडे वाटचाल करणे हे धोरणात्मक ध्येय आहे.

Passpoint आणि 802.1X वर आधारित असलेले OpenRoaming, परत येणाऱ्या पाहुण्यांना कोणतेही लॉगिन पृष्ठ न दाखवता स्वयंचलितपणे आणि सुरक्षितपणे कनेक्ट होण्यास मदत करते. आमच्या Connect प्लॅन अंतर्गत, Purple हे OpenRoaming साठी विनामूल्य ओळख प्रदाता म्हणून काम करते. Premier Inn आणि Manchester Airports Group सारख्या जागा वारंवार येणाऱ्या अभ्यागतांसाठी पुन्हा प्रमाणीकरण करण्याचा त्रास दूर करण्यासाठी याचा वापर आधीपासूनच करत आहेत, तसेच संपूर्ण GDPR अनुपालन आणि प्रथम-पक्ष डेटा संकलन देखील राखत आहेत. कनेक्शनमधील त्रुटी कमी करून, तुम्ही गोळा केलेल्या प्रथम-पक्ष डेटाचे प्रमाण थेट वाढवू शकता, ज्यामुळे ग्राहकांची निष्ठा आणि वैयक्तिकृत प्रतिबद्धता वाढू शकते.

तांत्रिक माहिती पॉडकास्ट

आमच्या १० मिनिटांच्या तांत्रिक माहितीमध्ये आमच्या वरिष्ठ सोल्यूशन्स आर्किटेक्ट कडून या त्रुटी निवारण चरणांचे तपशीलवार विश्लेषण ऐका.

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

Captive Portal

एक नेटवर्क-स्तरीय ट्रॅफिक इंटरसेप्शन यंत्रणा जी वापरकर्त्याने आवश्यक कृती पूर्ण करेपर्यंत, जसे की अटी स्वीकारणे किंवा splash page वर क्रेडेंशियल प्रदान करेपर्यंत इंटरनेट प्रवेश प्रतिबंधित करते.

एंटरप्राइझ ठिकाणांसाठी अतिथी प्रवेश सुरक्षित करण्याचा आणि फर्स्ट-पार्टी डेटा कॅप्चर करण्याचा प्राथमिक मार्ग.

Walled Garden

एक प्रि-ऑथेंटिकेशन ॲक्सेस कंट्रोल लिस्ट जी व्याख्या करते की अनऑथेंटिकेट अतिथी उपकरणाला कोणत्या बाह्य IP पत्त्यांवर किंवा डोमेन्सवर पोहोचण्याची परवानगी आहे.

वापरकर्ता पूर्णपणे ऑथेंटिकेट होण्यापूर्वी पोर्टल मालमत्ता, CDN आणि OAuth ओळख प्रदात्यांना प्रवेश देण्यास अत्यंत महत्त्वाचे.

Captive Network Assistant (CNA)

जेव्हा ऑपरेटिंग सिस्टमला एखादे captive portal रीडायरेक्ट आढळते तेव्हा तिच्याद्वारे स्वयंचलितपणे उघडलेली सँडबॉक्स केलेली, मर्यादित-कार्यक्षमता असलेली ब्राउझर विंडो.

हा तो इंटरफेस आहे जिथे अतिथी प्रत्यक्षात तुमचे लॉगिन पेज पाहतो आणि त्यावर संवाद साधतो.

HSTS (HTTP Strict Transport Security)

एक वेब सुरक्षा पॉलिसी यंत्रणा जी ब्राउझरला केवळ सुरक्षित HTTPS कनेक्शनद्वारे संवाद साधण्यास भाग पाडून मॅन-इन-द-मिडल हल्ल्यांपासून वेबसाइटचे संरक्षण करण्यास मदत करते.

HSTS गेटवेला वापरकर्त्यांना captive portal वर रीडायरेक्ट करण्यासाठी HTTPS इंटरसेप्शन वापरण्यापासून प्रतिबंधित करते, ज्यामुळे चुकीच्या पद्धतीने कॉन्फिगर केले असल्यास कनेक्शन अपयशी ठरते.

DHCP Pool Exhaustion

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

स्टेडियम किंवा परिषदांसारख्या उच्च-घनतेच्या वातावरणात 'Connected, No Internet' त्रुटींचे एक सामान्य कारण.

MAC Address Randomisation

आधुनिक मोबाइल ऑपरेटिंग सिस्टममधील एक गोपनीयता वैशिष्ट्य जे प्रत्येक WiFi नेटवर्कसाठी यादृच्छिक MAC पत्ता तयार करते, ज्यामुळे वेगवेगळ्या ठिकाणी ट्रॅकिंग रोखले जाते.

हे वैशिष्ट्य captive portal वरील सेशन सातत्य खंडित करते, ज्यामुळे अतिथीचा MAC पत्ता रोटेट झाल्यास त्यांना पुन्हा ऑथेंटिकेट करावे लागते.

OpenRoaming

WiFi नेटवर्कचे एक फेडरेशन जे वापरकर्त्यांना क्रेडेंशियल न टाकता किंवा captive portal शी संवाद न साधता सहभागी नेटवर्कशी स्वयंचलितपणे आणि सुरक्षितपणे कनेक्ट होण्याची परवानगी देते.

वारंवार भेट देणाऱ्यांसाठी captive portals चा धोरणात्मक पर्याय, ज्याला Purple एक विनामूल्य ओळख प्रदाता म्हणून समर्थन देते.

RFC 8910 (DHCP Option 114)

एक मानक जे IP ॲड्रेस असाइनमेंट दरम्यान क्लायंट डिव्हाइसला captive portal ची URL थेट प्रदान करण्यास DHCP सर्व्हरला अनुमती देते.

हे HTTP रिडायरेक्शनची आवश्यकता पूर्णपणे बायपास करते, HSTS मुळे उद्भवणाऱ्या समस्यांचे निराकरण करते आणि पोर्टल शोधण्याचा वेग सुधारते.

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

सेंट्रल लंडनमधील एका ३५० खोल्यांच्या हॉटेलमध्ये अतिथी WiFi साठी एकच /24 सबनेट चालवले जाते. एका मोठ्या परिषदेदरम्यान, ४०० प्रतिनिधी एकाच वेळी येतात. २० मिनिटांच्या आत, अतिथी कनेक्टेड असल्याचे परंतु पोर्टल किंवा इंटरनेटपर्यंत पोहोचण्यास असमर्थ असल्याचे सांगतात.

त्वरित उपाय म्हणजे सबनेटचा /22 पर्यंत विस्तार करणे, ज्यामुळे १,०२२ वापरण्यायोग्य पत्ते मिळतात आणि DHCP लीज वेळ २४ तासांवरून ८ तासांवर कमी करणे. दीर्घकालीन उपाय म्हणजे Purple चे क्लाउड-व्यवस्थापित captive portal लागू करणे, जे रिअल टाइममध्ये DHCP पूल वापराचे निरीक्षण करते आणि ते संपण्यापूर्वी नेटवर्क टीमला अलर्ट करते.

परीक्षकाचे भाष्य: हे दृश्य क्लासिक DHCP पूल संपल्याचे दर्शवते. /24 सबनेट केवळ २५४ वापरण्यायोग्य IP पत्ते प्रदान करते. सबनेटचा आकार वाढवून आणि लीज वेळ कमी करून, नेटवर्क परिषदेच्या वातावरणात सामान्य असणाऱ्या उपकरणांच्या उच्च टर्नओव्हरला सामावून घेऊ शकते.

२०० स्टोअर्स असलेली एक प्रमुख रिटेल साखळी त्यांच्या अतिथी पोर्टलवर Google आणि Facebook द्वारे सोशल लॉगिन वापरते. Google ने त्याचे OAuth इन्फ्रास्ट्रक्चर अपडेट केल्यानंतर, अतिथी पोर्टल पेजवर पोहोचू शकतात, परंतु सोशल लॉगिन बटणांमुळे रिकाम्या स्क्रीन दिसतात.

आयटी टीमने Google द्वारे वापरले जाणारे नवीन ऑथेंटिकेशन डोमेन्स ओळखले पाहिजेत आणि त्यांना walled garden (प्रि-ऑथेंटिकेशन ॲक्सेस कंट्रोल लिस्ट) मध्ये जोडले पाहिजे. भविष्यात हे टाळण्यासाठी, त्यांनी विशिष्ट IP पत्ते हार्डकोड करण्याऐवजी वाईल्डकार्ड डोमेन नोंदी (उदा. *.google.com) वापराव्यात आणि त्रैमासिक आधारावर walled garden चे पुनरावलोकन करावे.

परीक्षकाचे भाष्य: तिसऱ्या पक्षाच्या OAuth प्रदात्यांवर अवलंबून असताना हे स्थिर walled garden चे नाजूकपणा अधोरेखित करते. क्लाउड-आधारित ओळख प्रदाते वारंवार त्यांच्या IP श्रेणी आणि CDN डोमेन्स बदलतात. Cisco Meraki आणि HPE Aruba सारख्या एंटरप्राइझ हार्डवेअरद्वारे नेटिव्हली सपोर्ट केलेले वाईल्डकार्ड स्नूपिंग हा योग्य आर्किटेक्चरल दृष्टिकोन आहे.

सराव प्रश्न

Q1. स्टेडियमचा IT संचालक सांगतो की हाफटाइम दरम्यान हजारो फॅन्स अतिथी WiFi शी कनेक्ट करण्याचा प्रयत्न करतात. काहींसाठी पोर्टल लोड होते, परंतु अनेकांचे डिव्हाइस 'Obtaining IP address' वर अडकल्याचे किंवा पोर्टल दिसण्यापूर्वीच 'Connected, No Internet' दर्शवत असल्याचे अहवाल देतात. सर्वात संभाव्य आर्किटेक्चरल त्रुटी कोणती आहे?

टीप: नेटवर्क सेगमेंटवरील उपलब्ध संसाधनांच्या तुलनेत एकाच वेळी होणाऱ्या कनेक्शनच्या संख्येचा विचार करा.

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

नेटवर्कमध्ये DHCP पूल संपण्याची (exhaustion) समस्या येत आहे. शिखर कॉनकरंट युझर लोडच्या मानाने सबनेटचा आकार खूप लहान (उदा. /24) असावा आणि DHCP लीझ वेळ कदाचित खूप जास्त सेट केली असावी. शिफारस केलेला उपाय म्हणजे सबनेटचा आकार वाढवणे (उदा. /22 किंवा /21 पर्यंत) आणि अपेक्षित थांबण्याच्या वेळेनुसार DHCP लीझ वेळ कमी करणे (उदा. स्टेडियमसाठी 3 तास).

Q2. एक अतिथी तुमच्या रिटेल WiFi नेटवर्कशी कनेक्ट होतो. एखादी लोकप्रिय वेबसाइट लोड करण्याचा प्रयत्न करताना त्यांच्या डिव्हाइसवर 'Your connection is not private' अशी सुरक्षा चेतावणी दिसते आणि captive portal कधीच उघडत नाही. हा ब्लॉक कोणत्या यंत्रणेमुळे होत आहे?

टीप: सुरक्षित कनेक्शनवर फोर्स केलेल्या रिडायरेक्ट्स आधुनिक ब्राउझर कसे हाताळतात याचा विचार करा.

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

HSTS (HTTP Strict Transport Security) रिडायरेक्ट ब्लॉक करत आहे. अतिथीने (HTTPS द्वारे) HSTS-प्रिलोड केलेल्या डोमेनवर जाण्याचा प्रयत्न केला आणि वायरलेस गेटवेने पोर्टलवर रिडायरेक्ट करण्यासाठी त्या सुरक्षित कनेक्शनमध्ये व्यत्यय आणण्याचा प्रयत्न केला. ब्राउझरने सर्टिफिकेटमधील विसंगती शोधली आणि कनेक्शन ब्लॉक केले. गेटवे फक्त कूटबद्ध नसलेल्या (unencrypted) HTTP प्रोब्समध्ये व्यत्यय आणण्यासाठी कॉन्फिगर केलेला असणे आवश्यक आहे.

Q3. तुम्ही अलीकडेच तुमच्या captive portal वर Google आणि Microsoft Entra ID सोशल लॉगिन पर्याय सुरू केले आहेत. अतिथी अहवाल देतात की पोर्टल पेज लोड होते, परंतु लॉगिन बटणावर क्लिक केल्यावर टाईमआउट होतो. IT विभागाच्या अनिर्बंध कर्मचारी नेटवर्कवर चाचणी केल्यावर पोर्टल उत्तम प्रकारे काम करते. कोणती कॉन्फिगरेशन गहाळ आहे?

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

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

वल्ड गार्डन (pre-authentication access control list) अपूर्ण आहे. Google आणि Microsoft Entra ID द्वारे वापरले जाणारे OAuth ऑथेंटिकेशन डोमेन आणि CDNs व्हाईटलिस्ट केलेले नाहीत. अतिथी अनऑथेंटिकेट असल्यामुळे, गेटवे या बाह्य डोमेनचा ॲक्सेस ब्लॉक करतो, ज्यामुळे सोशल लॉगिन प्रक्रियेचा टाईमआउट होतो. IT टीमने या ओळख प्रदात्यांसाठी वल्ड गार्डनमध्ये वाईल्डकार्ड एंट्री जोडणे आवश्यक आहे.

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

Why does public WiFi fail to redirect to the splash login page?

Public WiFi fails to redirect when the wireless controller or gateway cannot intercept cleartext HTTP requests (TCP port 80), when upstream firewalls drop DNS queries for captive portal probe URLs (such as captive.apple.com or connectivitycheck.gstatic.com), or when modern client browsers enforce HSTS on HTTPS requests before authentication. Allowing pre-authentication DNS and redirecting HTTP traffic resolves the issue.

How do client operating systems detect public WiFi captive portals?

Upon connecting to an open or public WiFi network, iOS fires HTTP requests via Captive Network Assistant (CNA) to captive.apple.com/hotspot-detect.html, Android queries connectivitycheck.gstatic.com/generate_204 via CaptivePortalLogin, and Windows probes msftconnecttest.com/connecttest.txt via NCSI. If the network returns an HTTP 302 redirect, the operating system launches the captive portal webview. If the probe domain fails to resolve or times out, the device marks the connection as having no internet.

Why do users see SSL certificate or HSTS warnings on public WiFi?

When an access point or gateway intercepts encrypted HTTPS requests (port 443) and presents its own self-signed or vendor certificate to force a splash page on public WiFi, modern web browsers detect a domain mismatch and block the connection with an HSTS or untrusted certificate error. Public WiFi networks should only intercept cleartext HTTP port 80 requests or implement RFC 8910 DHCP Option 114 to cleanly announce the portal URL.

What causes public WiFi captive portals to loop back to the login page?

Infinite login loops occur when the wireless access point or controller fails to receive or process the RADIUS Access-Accept packet or RFC 5176 Change of Authorization (CoA) disconnect/re-authenticate message on UDP port 3799. As a result, the controller maintains the client device in the pre-authentication walled garden role despite successful submission of guest credentials on the public WiFi network.

How does Purple eliminate public WiFi splash page redirection failures?

Purple operates as a cloud-delivered, hardware-agnostic guest WiFi management platform across Cisco Meraki, HPE Aruba, Ruckus, Ubiquiti UniFi, and Fortinet architectures. By optimizing captive portal redirection flows, automating walled garden rules, and integrating with high-speed Anycast DNS, Purple ensures detection probes succeed instantly, onboarding visitors in under 3 seconds without connection drops.

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

Ruckus captive portal त्रुटी निवारण: WISPr redirect, hotspot आणि walled garden चेकलिस्ट

तुम्ही अतिथींच्या तक्रारींवरून अपयशी ठरणाऱ्या Ruckus captive portal चे निदान करू शकाल, आणि नंतर एका विशिष्ट क्रमाने ते दुरुस्त करू शकाल. या क्रमामध्ये hotspot (WISPr) logon URL, walled garden, northbound portal interface पासवर्ड, RADIUS authentication आणि accounting, आणि HTTPS redirect प्रमाणपत्रे समाविष्ट आहेत. हे चेक्स SmartZone, Ruckus One आणि Unleashed वर लागू होतात.

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

Ubiquiti UniFi captive portal troubleshooting: external portal, hotspot आणि walled garden चेकलिस्ट

तुमचे Ubiquiti UniFi captive portal का काम करत नाही आहे हे शोधण्यासाठी आणि ते दुरुस्त करण्यासाठी या चेकलिस्टचा वापर करा. तुम्ही लक्षणांची सांगड सहा कारणांपैकी एकाशी घालू शकाल, दोन जलद चाचण्या रन करू शकाल आणि external portal server, pre-authorisation access, guest subnet restrictions, HTTPS redirects, controller reachability किंवा client settings दुरुस्त करू शकाल.

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

HPE Aruba captive portal त्रुटी निवारण: रिडायरेक्ट, प्रमाणपत्र आणि walled garden चेकलिस्ट

तुम्हाला दिसणाऱ्या लक्षणांवरून - जसे की redirect न होणे, certificate warning येणे किंवा गेस्ट कधीही कनेक्ट न होणे - बिघडलेल्या HPE Aruba captive portal चे निदान करण्यासाठी या चेकलिस्टचा वापर करा. त्यानंतर तुम्ही DNS, DHCP, walled garden, redirect URL, certificate किंवा RADIUS मधील त्रुटी शोधू शकता. शेवटी, Instant APs, Aruba Central किंवा mobility controller वर हे दुरुस्त करा.

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

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

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