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

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 Networks और Fortinet परिनियोजन में इन समस्याओं को समाप्त करता है।

📖 9 मिनट का पाठ📝 2,237 शब्द🔧 2 हल किए गए उदाहरण❓ 3 अभ्यास प्रश्न📚 9 मुख्य परिभाषाएं

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

पॉडकास्ट ट्रांसक्रिप्ट देखें
होस्ट (UK ENGLISH, CONFIDENT CONSULTANT TONE): Purple टेक्निकल ब्रीफिंग में आपका स्वागत है। आज हम एंटरप्राइज़ नेटवर्किंग में सबसे लगातार होने वाली सिरदर्दों में से एक का समाधान कर रहे हैं: Captive Portal रीडायरेक्ट विफलता। जब आपका गेस्ट WiFi कनेक्टेड के रूप में दिखाई देता है लेकिन कोई इंटरनेट एक्सेस नहीं होता है, तो आपके विज़िटर निराश हो जाते हैं, आपके हेल्पडेस्क पर लोड बढ़ जाता है, और आपकी डेटा कैप्चर रणनीति पूरी तरह से रुक जाती है। इस ब्रीफिंग में, हम Captive Portal के तकनीकी आर्किटेक्चर को समझेंगे, यह पता लगाएंगे कि आधुनिक ऑपरेटिंग सिस्टम और ब्राउज़र अक्सर उन्हें क्यों ब्लॉक करते हैं, और आपको इन समस्याओं को स्थायी रूप से हल करने के लिए ठोस कार्यान्वयन रणनीतियाँ देंगे। [PAUSE] आइए परिस्थिति को समझें। आपने सौ रिटेल स्थानों पर 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 के पीछे है। फिर यह स्प्लैश पेज लोड करने के लिए एक छद्म-ब्राउज़र (pseudo-browser) खोलता है। विफलता आमतौर पर इसी इंटरसेप्शन पॉइंट पर होती है। [PAUSE] विफलता का पहला बड़ा कारण नेटवर्क कनेक्टिविटी स्टेटस इंडिकेटर प्रोब, या NCSI है। यदि आपका फ़ायरवॉल या गेटवे इन अनएन्क्रिप्टेड HTTP अनुरोधों को ब्लॉक करता है, तो ऑपरेटिंग सिस्टम को कभी भी 302 रीडायरेक्ट प्राप्त नहीं होता है। यह बस मान लेता है कि नेटवर्क खराब है। इसे ठीक करने के लिए, आपको यह सुनिश्चित करना होगा कि आपकी प्री-ऑथेंटिकेशन एक्सेस कंट्रोल सूचियां उन विशिष्ट OS डिटेक्शन URLs पर HTTP ट्रैफ़िक की अनुमति देती हैं। दूसरा, और तेजी से आम होने वाला मुद्दा, HTTP Strict Transport Security, या 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 के माध्यम से भुगतान प्रोसेस करते हैं, तो वे डोमेन आपके walled garden में होने चाहिए। यदि वे नहीं हैं, तो स्प्लैश पेज लोड हो सकता है, लेकिन प्रमाणीकरण प्रक्रिया बिना किसी सूचना के विफल हो जाएगी। [PAUSE] आइए एक वास्तविक स्थिति को देखें। McDonald's हजारों स्थानों पर लाखों ग्राहकों को सेवा प्रदान करता है। वे अपने गेस्ट WiFi को प्रबंधित करने के लिए Purple का उपयोग करते हैं। यदि उनका सेशन टाइमआउट बहुत कम सेट किया गया है, तो लंबे लंच के दौरान अपना फोन चेक करने वाले ग्राहक को बार-बार प्रमाणित करने के लिए मजबूर होना पड़ सकता है। इससे अनुभव खराब होता है। हम हॉस्पिटैलिटी और रिटेल वातावरण के लिए सेशन की अवधि 24 घंटे सेट करने की सलाह देते हैं, और लौटने वाले उपकरणों को आसानी से पहचानने के लिए MAC एड्रेस कैशिंग का उपयोग करने की सलाह देते हैं। [PAUSE] अब कार्यान्वयन (implementation) संबंधी सिफारिशों के बारे में। जब आप Captive Portal तैनात करते हैं, तो आपको DNS और HTTP ट्रैफ़िक को सही ढंग से इंटरसेप्ट करने के लिए अपने गेटवे को कॉन्फ़िगर करना होगा। यदि आप Purple जैसे क्लाउड ओवरले का उपयोग करते हैं, तो आपका स्थानीय हार्डवेयर, चाहे वह Juniper Mist हो या Ubiquiti UniFi, Purple RADIUS सर्वर तक पहुँचने में सक्षम होना चाहिए। यहाँ एक महत्वपूर्ण समस्या है: DNS रिज़ॉल्यूशन। यदि कोई गेस्ट डिवाइस आपके Captive Portal के होस्टनेम को रिज़ॉल्व नहीं कर सकता है, तो रीडायरेक्ट विफल हो जाता है। सुनिश्चित करें कि आपका DHCP सर्वर विश्वसनीय DNS एड्रेस प्रदान करता है, और सत्यापित करें कि आपका गेटवे DNS क्वेरी को walled garden से गुजरने की अनुमति देता है। इसके अलावा, भौतिक वातावरण पर विचार करें। स्टेडियम या ट्रैवल हब जैसे उच्च-घनत्व वाले स्थान, जैसे कि Manchester Airports Group, एक साथ हजारों कनेक्शन प्रयासों को संभालते हैं। यदि आपका स्थानीय DHCP पूल समाप्त हो जाता है, तो नए डिवाइस एक्सेस पॉइंट से तो कनेक्ट हो जाएंगे लेकिन उन्हें IP एड्रेस प्राप्त नहीं होगा। वे कभी भी Captive Portal चरण तक नहीं पहुँच पाएंगे। हमेशा पीक क्षमता के लिए अपने सबनेट का आकार उचित रखें, और अस्थायी विज़िटर नेटवर्क के लिए कम DHCP लीज टाइम का उपयोग करें। [PAUSE] अब सामान्य हेल्पडेस्क टिकटों पर आधारित एक त्वरित प्रश्न और उत्तर सत्र। प्रश्न एक: पोर्टल iPhones पर तो काम करता है लेकिन Android डिवाइस पर विफल क्यों हो जाता है? उत्तर: यह निश्चित रूप से एक walled garden की समस्या है। आपने शायद captive.apple.com को व्हाइटलिस्ट कर दिया है लेकिन connectivitycheck.gstatic.com को छोड़ दिया है। अपनी प्री-ऑथेंटिकेशन एक्सेस कंट्रोल सूचियों को अपडेट करें। प्रश्न दो: गेस्ट सफलतापूर्वक प्रमाणित हो जाते हैं, लेकिन फिर भी इंटरनेट नहीं चलता। क्यों? उत्तर: अपने RADIUS कॉन्फ़िगरेशन की जाँच करें। गेटवे को संभवतः RADIUS सर्वर से Access-Accept संदेश प्राप्त नहीं हो रहा है, या पोस्ट-ऑथेंटिकेशन फ़ायरवॉल नियम ट्रैफ़िक को ब्लॉक कर रहे हैं। शेयर्ड सीक्रेट को सत्यापित करें और सुनिश्चित करें कि पोर्ट 1812 और 1813 खुले हैं। प्रश्न तीन: क्या हम सुरक्षा चेतावनियों से बचने के लिए शुरुआती रीडायरेक्ट के लिए HTTPS का उपयोग कर सकते हैं? उत्तर: नहीं। आप सर्टिफिकेट एरर पैदा किए बिना HTTPS अनुरोध को इंटरसेप्ट नहीं कर सकते, जब तक कि आप प्रत्येक गेस्ट डिवाइस पर रूट सर्टिफिकेट इंस्टॉल न करें, जो कि पब्लिक WiFi के लिए असंभव है। पोर्टल को ट्रिगर करने के लिए आपको अनएन्क्रिप्टेड HTTP OS प्रोब्स पर ही निर्भर रहना होगा। [PAUSE] संक्षेप में: Captive Portal की विफलताएं शायद ही कभी हार्डवेयर की खराबी होती हैं। वे लगभग हमेशा रीडायरेक्ट फ़्लो, walled garden, या DNS सेटिंग्स में कॉन्फ़िगरेशन के बेमेल होने के कारण होती हैं। पहला बिंदु: सुनिश्चित करें कि प्रमाणीकरण से पहले OS डिटेक्शन URL एक्सेस किए जा सकें। दूसरा बिंदु: अपने walled garden को सभी आवश्यक identity providers और content delivery networks को शामिल करने के लिए कॉन्फ़िगर करें। तीसरा बिंदु: अपने गेटवे और प्रमाणीकरण प्लेटफ़ॉर्म के बीच RADIUS संचार को सत्यापित करें। चौथा बिंदु: अधिकतम डेंसिटी के लिए अपने DHCP स्कोप का आकार निर्धारित करें। इन तत्वों पर महारत हासिल करके, आप कनेक्शन की बाधाओं को समाप्त करते हैं। आप अपने विज़िटर्स को निराश करना बंद करते हैं और उस फ़र्स्ट-पार्टी डेटा को कैप्चर करना शुरू करते हैं जिसकी आपको वफादारी और राजस्व बढ़ाने के लिए आवश्यकता होती है। Purple के Identity-Based Networks इस प्रक्रिया को सरल बनाते हैं, एक हार्डवेयर-अज्ञेयवादी क्लाउड ओवरले प्रदान करते हैं जो दुनिया भर के 80,000 लाइव स्थानों पर RADIUS, Captive Portals और एनालिटिक्स की जटिलता को सहजता से संभालता है। इस Purple Technical Briefing में शामिल होने के लिए धन्यवाद। अधिक विस्तृत कॉन्फ़िगरेशन गाइड और आर्किटेक्चर आरेखों के लिए, purple.ai पर जाएं।

header_image.png

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

एंटरप्राइज नेटवर्किंग में सबसे आम सपोर्ट टिकटों में से 'guest WiFi connected but no internet' (अतिथि WiFi कनेक्टेड है लेकिन इंटरनेट नहीं है) एक है। इसके लक्षण हर विजिटर को दिखाई देते हैं; लेकिन जब तक IT टीमें रीडायरेक्ट चेन को नहीं समझतीं, तब तक इसका कारण अधिकांश टीमों के लिए अदृश्य रहता है। एक 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 पर एक अनएन्क्रिप्टेड 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 No Content
Windows (NCSI) http://www.msftconnecttest.com/connecttest.txt बॉडी 'Microsoft Connect Test' के साथ HTTP 200
Chrome (सभी प्लेटफ़ॉर्म) http://www.gstatic.com/generate_204 HTTP 204 No Content
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' लक्षण का सबसे आम कारण है।

redirect_flow_diagram.png

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

walled garden डोमेन और IP एड्रेस का वह सेट है जहां कोई डिवाइस प्रमाणित होने से पहले पहुंच सकता है। यदि walled garden बहुत संकीर्ण है, तो स्प्लैश पेज लोड हो सकता है लेकिन प्रमाणीकरण विफल हो जाएगा। सामान्य कमियों में शामिल हैं:

  • पहचान प्रदाता डोमेन: यदि आप सोशल या SSO लॉगिन के लिए Microsoft Entra ID, Okta, या Google Workspace का उपयोग करते हैं, तो उनके प्रमाणीकरण एंडपॉइंट walled garden में होने चाहिए।
  • 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 से कनेक्टेड दिखाई देता है लेकिन उसमें इंटरनेट नहीं होता है।

Manchester Airports Group (MAG) जैसे स्थानों के लिए, जहां यात्रियों की संख्या तेजी से चरम पर पहुंचती है, सबनेट का आकार औसत नहीं, बल्कि अधिकतम समवर्ती डिवाइस संख्या के लिए निर्धारित किया जाना चाहिए। कम DHCP लीज समय (अस्थायी विज़िटर नेटवर्क के लिए 15 - 30 मिनट) चले गए डिवाइसों से एड्रेस जल्दी वापस ले लेता है।

Implementation guide

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

चरण 1: SSID को बाहरी captive portal के लिए कॉन्फ़िगर करें। अपने हार्डवेयर कंट्रोलर में, गेस्ट SSID को अन-ऑथेंटिकेटेड क्लाइंट्स को Purple के बाहरी पोर्टल URL पर रीडायरेक्ट करने के लिए सेट करें। कंट्रोलर पर ही किसी भी स्थानीय स्प्लैश पेज को अक्षम करें।

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

चरण 3: RADIUS को कॉन्फ़िगर करें। Purple के RADIUS सर्वर IP एड्रेस, अपने Purple डैशबोर्ड से साझा रहस्य (shared secret) दर्ज करें, और प्रमाणीकरण पोर्ट को 1812 और अकाउंटिंग पोर्ट को 1813 पर सेट करें। सत्यापित करें कि आपका स्थानीय फ़ायरवॉल इन पोर्टों पर आउटबाउंड UDP की अनुमति देता है।

चरण 4: सत्र पैरामीटर सेट करें। हॉस्पिटैलिटी और रिटेल के लिए, MAC एड्रेस कैशिंग सक्षम के साथ सत्र की अवधि 24 घंटे सेट करें। यह मेहमानों को एक ही विज़िट के दौरान दोबारा प्रमाणित करने के लिए मजबूर होने से बचाता है। उच्च-सुरक्षा वाले वातावरण के लिए, पुन: प्रमाणीकरण के साथ कम अवधि के सत्र उपयुक्त हैं।

चरण 5: अपने DHCP स्कोप का आकार निर्धारित करें। पीक क्षमता पर अपने स्थान के लिए अधिकतम समवर्ती डिवाइस संख्या की गणना करें। 500 सीटों वाले रेस्तरां में व्यस्त सेवा के दौरान 800 डिवाइस दिखाई दे सकते हैं। DHCP पूल का आकार 30 मिनट के लीज समय के साथ 1,000 एड्रेस तक निर्धारित करें।

चरण 6: विभिन्न ऑपरेटिंग सिस्टम पर परीक्षण करें। कॉन्फ़िगरेशन के बाद, iOS, Android, और Windows डिवाइस पर संपूर्ण प्रवाह का परीक्षण करें। प्रत्येक एक अलग प्रोब URL और WebView कार्यान्वयन का उपयोग करता है। एक प्लेटफ़ॉर्म पर विफलता जबकि अन्य काम कर रहे हों, लगभग हमेशा एक walled garden की कमी होती है।

Best practices

troubleshooting_checklist.png

निम्नलिखित सिफारिशें Purple के 80,000+ से अधिक स्थानों के परिनियोजन के मानकों और पैटर्नों को दर्शाती हैं।

अतिथि (guest) और कर्मचारी (staff) नेटवर्क को अलग करें। कम से कम तीन SSIDs चलाएं: Guest WiFi, Staff WiFi, और एक IoT नेटवर्क। Guest ट्रैफ़िक को आंतरिक सिस्टम से अलग किया जाना चाहिए। आर्किटेक्चर विवरण के लिए हमारा गाइड Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi देखें।

एक समर्पित गेस्ट VLAN का उपयोग करें। लेटरल मूवमेंट को रोकने और फ़ायरवॉल पॉलिसी को सरल बनाने के लिए गेस्ट ट्रैफ़िक को उसके अपने VLAN में विभाजित करें। यदि कोई भुगतान कार्ड डेटा नेटवर्क से होकर गुजरता है, तो यह एक PCI DSS आवश्यकता है।

सचेत-विकल्प ऑप्ट-इन्स लागू करें। GDPR की आवश्यकता है कि कैप्टिव पोर्टल पर डेटा संग्रह सूचित, सकारात्मक सहमति पर आधारित हो। Purple के सचेत-विकल्प ऑप्ट-इन्स डेटा संग्रह के विकल्पों को स्पष्ट रूप से प्रस्तुत करते हैं, जिसमें प्रत्येक उद्देश्य के लिए अलग-अलग टिक बॉक्स होते हैं। UK या EU में संचालित होने वाले स्थानों के लिए यह वैकल्पिक नहीं है।

प्रोएक्टिव रूप से पोर्टल की स्थिति की निगरानी करें। Purple का WiFi Analytics प्लेटफ़ॉर्म लॉगिन सफलता दरों, सेशन काउंट और प्रमाणीकरण विफलताओं की रीयल-टाइम दृश्यता प्रदान करता है। सफल लॉगिन में अचानक गिरावट मेहमानों की शिकायत शुरू होने से पहले RADIUS या वॉल्ड गार्डन समस्या की प्रारंभिक चेतावनी है।

संगत ब्रांडिंग लागू करें। स्प्लैश पेज वह पहला ब्रांडेड इंटरैक्शन है जो किसी अतिथि का आपके नेटवर्क के साथ होता है। एक अच्छी तरह से डिज़ाइन किया गया पोर्टल ऑप्ट-इन दरों को बढ़ाता है और WiFi अनुभव के लिए अपेक्षाएं सेट करता है। डिज़ाइन मार्गदर्शन के लिए How to make a great first impression with your guest WiFi देखें।

समस्या निवारण और जोखिम न्यूनीकरण

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

विफलता बिंदु को अलग करें। अतिथि से पूछें कि वे किस OS और ब्राउज़र का उपयोग कर रहे हैं। उसी OS पर स्वयं उसी प्रवाह का परीक्षण करें। यदि समस्या OS-विशिष्ट है, तो इसका कारण लगभग निश्चित रूप से उस OS के प्रोब URL के लिए एक गायब वॉल्ड गार्डन प्रविष्टि है।

DNS रिज़ॉल्यूशन की जाँच करें। गेस्ट VLAN पर मौजूद किसी डिवाइस से, कैप्टिव पोर्टल होस्टनाम को रिज़ॉल्व करने का प्रयास करें। यदि DNS रिज़ॉल्यूशन विफल हो जाता है, तो डिवाइस स्प्लैश पेज तक नहीं पहुंच सकता है, भले ही रीडायरेक्ट सही ढंग से जारी किया गया हो। सत्यापित करें कि आपका DHCP सर्वर विश्वसनीय DNS पते वितरित कर रहा है और गेटवे प्री-ऑथेंटिकेशन स्थिति में DNS प्रश्नों की अनुमति देता है।

रीडायरेक्ट को कैप्चर करें। HTTP एक्सचेंज को देखने के लिए ब्राउज़र डेवलपर टूल (F12) या पैकेट कैप्चर का उपयोग करें। आपको OS प्रोब अनुरोध और उसके बाद पोर्टल URL युक्त एक HTTP 302 प्रतिक्रिया देखनी चाहिए। यदि आप प्रोब अनुरोध देखते हैं लेकिन कोई 302 प्रतिक्रिया नहीं मिलती है, तो गेटवे सही ढंग से इंटरसेप्ट नहीं कर रहा है। यदि आपको कोई प्रोब अनुरोध बिल्कुल नहीं दिखता है, तो OS ने पहले ही निर्धारित कर लिया है कि उसके पास इंटरनेट एक्सेस है (संभवतः कैश्ड स्थिति से) और वह प्रोब नहीं भेज रहा है।

RADIUS संचार सत्यापित करें। गेटवे पर, RADIUS अकाउंटिंग लॉग्स की जांच करें। एक सफल प्रमाणीकरण एक Accounting-Start रिकॉर्ड बनाता है। यदि अतिथि लॉग इन करने के बाद आपको कोई अकाउंटिंग रिकॉर्ड नहीं दिखता है, तो RADIUS संचार टूटा हुआ है। साझा किए गए गुप्त (shared secret), सर्वर IP और फ़ायरवॉल नियमों की जांच करें।

DHCP लीज़ उपयोग की जाँच करें। DHCP सर्वर पर, पूल के आकार के मुकाबले वर्तमान लीज़ संख्या की समीक्षा करें। यदि उपयोग 90% से अधिक है, तो आप सीमा समाप्त होने के करीब हैं। पूल का विस्तार करें या तुरंत लीज़ का समय कम करें।

निम्नलिखित तालिका सबसे आम लक्षणों को उनके मूल कारणों और प्रासंगिक समाधान से जोड़ती है।

लक्षण सबसे संभावित मूल कारण समाधान
किसी भी डिवाइस पर पोर्टल कभी दिखाई नहीं देता गेटवे ACL द्वारा OS प्रोब ब्लॉक किया गया प्री-ऑथ अनुमति सूची (pre-auth allow list) में प्रोब URLs जोड़ें
पोर्टल iOS पर दिखाई देता है, Android पर नहीं वोल्ड गार्डन (walled garden) से Android प्रोब URL गायब है वोल्ड गार्डन में connectivitycheck.gstatic.com जोड़ें
पोर्टल लोड होने पर HTTPS प्रमाणपत्र त्रुटि गेटवे HTTP के बजाय HTTPS को इंटरसेप्ट कर रहा है केवल HTTP प्रोब इंटरसेप्शन पर निर्भर रहें
पोर्टल लोड होता है, लॉगिन के बाद इंटरनेट नहीं चलता गेटवे द्वारा RADIUS Access-Accept प्राप्त नहीं हुआ साझा किए गए गुप्त (shared secret), पोर्ट्स 1812/1813, RADIUS सर्वर IP सत्यापित करें
सोशल लॉगिन बटन बिना किसी चेतावनी के विफल हो जाता है पहचान प्रदाता (identity provider) डोमेन वोल्ड गार्डन में नहीं है Microsoft Entra ID / Google Workspace एंडपॉइंट जोड़ें
अतिथियों को हर विज़िट पर पुनः प्रमाणित करना पड़ता है सत्र की अवधि बहुत कम है या MAC कैशिंग अक्षम है सत्र को 24 घंटे पर सेट करें, MAC एड्रेस कैशिंग सक्षम करें
पीक ऑवर्स के दौरान रुक-रुक कर होने वाली विफलताएं DHCP पूल समाप्त होना सबनेट का विस्तार करें, लीज़ का समय कम करें

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

प्रत्येक कैप्टिव पोर्टल विफलता एक छूटा हुआ डेटा कैप्चर अवसर है। Purple का Guest WiFi प्लेटफॉर्म प्रत्येक सफल प्रमाणीकरण को एक फर्स्ट-पार्टी डेटा रिकॉर्ड - नाम, ईमेल, जनसांख्यिकीय डेटा, और विज़िट आवृत्ति - में परिवर्तित करता है जो सीधे मार्केटिंग ऑटोमेशन और लॉयल्टी कार्यक्रमों में फीड होता है।

Premier Inn या Whitbread जैसे hospitality ऑपरेटर के लिए, 700-संपत्ति वाले एस्टेट में पोर्टल प्रमाणीकरण सफलता दर में 10% का सुधार सीधे प्रति माह हजारों अतिरिक्त ऑप्ट-इन रिकॉर्ड में बदल जाता है। वे रिकॉर्ड खरीदे गए सूचियों की तुलना में काफी उच्च ओपन रेट वाले व्यक्तिगत ईमेल अभियानों को शक्ति प्रदान करते हैं।

retail ऑपरेटरों के लिए, कैप्टिव पोर्टल खरीदार के रुकने के समय (dwell time), बार-बार आने की आवृत्ति, और विभिन्न स्थानों के व्यवहार को समझने का प्रवेश द्वार है। Purple ने अपने वेन्यू नेटवर्क पर 29 बिलियन डेटा पॉइंट (Purple आंतरिक डेटा) एकत्र किए हैं। वह डेटा केवल उसी प्रमाणीकरण दर जितना अच्छा है जो इसे उत्पन्न करता है।

Manchester Airports Group जैसे transport हब के लिए, विश्वसनीय गेस्ट WiFi एक यात्री संतुष्टि मीट्रिक है जिसे बोर्ड स्तर पर ट्रैक किया जाता है। एक पोर्टल जो पीक प्रस्थान अवधियों के दौरान रुक-रुक कर विफल रहता है, वह शिकायतें उत्पन्न करता है और वेन्यू के नेट प्रमोटर स्कोर (Net Promoter Score) को नुकसान पहुंचाता है। 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 8910 में परिभाषित।

Walled garden

उन डोमेन और IP एड्रेस का सेट, जहां Captive Portal प्रमाणीकरण पूरा करने से पहले कोई डिवाइस पहुंच सकता है। walled garden गंतव्यों के लिए जाने वाला ट्रैफ़िक प्रमाणीकरण की आवश्यकता को बायपास करता है।

इसमें OS प्रोब URLs, पहचान प्रदाता एंडपॉइंट्स, CDN डोमेन और पेमेंट प्रोसेसर डोमेन शामिल होने चाहिए। गलत तरीके से कॉन्फ़िगर किया गया walled garden, Captive Portal विफलताओं का दूसरा सबसे आम कारण है।

NCSI (Network Connectivity Status Indicator)

एक Windows सुविधा जो यह निर्धारित करने के लिए `msftconnecttest.com` की जांच करती है कि डिवाइस में इंटरनेट एक्सेस है या वह 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)

एक नेटवर्किंग प्रोटोकॉल जो केंद्रीकृत प्रमाणीकरण, प्राधिकरण और लेखा (AAA) प्रबंधन प्रदान करता है, जो UDP पर पोर्ट 1812 (प्रमाणीकरण) और 1813 (लेखा) पर काम करता है।

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 एक्सेस पॉइंट्स का उपयोग करने वाला एक 200 कमरों वाला होटल रिपोर्ट करता है कि Android उपकरणों वाले अतिथि Captive Portal तक नहीं पहुँच सकते हैं, जबकि iOS उपयोगकर्ता बिना किसी समस्या के कनेक्ट हो जाते हैं। IT टीम ने पुष्टि की है कि पोर्टल URL प्रबंधन VLAN से सुलभ है।

IT टीम को HPE Aruba कंट्रोलर पर प्री-ऑथेंटिकेशन वॉल्ड गार्डन का निरीक्षण करना चाहिए। iOS डिवाइस captive.apple.com की जांच करते हैं, जो संभवतः पहले से ही श्वेतसूची (whitelisted) में है। Android डिवाइस connectivitycheck.gstatic.com और clients3.google.com/generate_204 की जांच करते हैं। ये Google डोमेन लगभग निश्चित रूप से वॉल्ड गार्डन से गायब हैं। इन्हें प्री-ऑथेंटिकेशन अनुमति सूची में जोड़ने से समस्या हल हो जाती है। टीम को एक माध्यमिक 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. एक 5,000 सीटों वाले स्थान पर एक बड़े सम्मेलन के दौरान, IT टीम को रिपोर्ट मिलती है कि सैकड़ों प्रतिभागी अतिथि WiFi पोर्टल तक नहीं पहुंच पा रहे हैं। एक्सेस पॉइंट सामान्य एसोसिएशन संख्या दिखाते हैं। समस्या कार्यक्रम शुरू होने के 45 मिनट बाद शुरू हुई। इसका सबसे संभावित कारण क्या है और इसका तत्काल समाधान क्या है?

संकेत: समस्या कार्यक्रम शुरू होने के बाद शुरू हुई, लॉन्च के समय नहीं। विचार करें कि अधिक उपकरणों के जुड़ने पर कौन सा संसाधन सीमित हो जाता है।

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

सबसे संभावित कारण DHCP पूल का समाप्त होना है। जैसे-जैसे प्रतिभागी आए और SSID से जुड़े, DHCP पूल भर गया। नए डिवाइस एक्सेस पॉइंट से जुड़ते हैं लेकिन IP पता प्राप्त नहीं कर पाते हैं, इसलिए वे कभी भी Captive Portal को ट्रिगर करने के लिए आवश्यक HTTP प्रोब नहीं भेजते हैं। तत्काल सुधार DHCP लीज समय को घटाकर 15 मिनट करना है (जिससे जाने वाले डिवाइस से IP पते तेजी से खाली हो सकें) और यदि संभव हो, तो दूसरा सबनेट जोड़कर पूल का विस्तार करना है। दीर्घकालिक सुधार अगले इवेंट में औसत के बजाय अधिकतम समवर्ती डिवाइस संख्या के लिए DHCP पूल का आकार निर्धारित करना है।

Q2. आपने एक रिटेल चेन में Ubiquiti UniFi एक्सेस पॉइंट्स पर Purple को तैनात किया है। स्प्लैश पेज सभी डिवाइस पर सही ढंग से लोड होता है। मेहमान ईमेल कैप्चर फॉर्म पूरा करते हैं और एक सफलता का संदेश देखते हैं। लेकिन जब वे ब्राउज़ करने का प्रयास करते हैं, तो उन्हें इंटरनेट एक्सेस नहीं मिलता है। Purple डैशबोर्ड लॉगइन को सफल दिखाता है। आप सबसे पहले क्या जांचेंगे?

संकेत: क्लाउड प्लेटफॉर्म ने ऑथेंटिकेशन को रिकॉर्ड कर लिया है। विफलता लोकल एन्फोर्समेंट चरण में है।

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

चूंकि Purple का डैशबोर्ड सफल लॉगइन दिखाता है, इसलिए क्लाउड ऑथेंटिकेशन चरण सही ढंग से पूरा हो गया था। विफलता RADIUS ऑथराइजेशन चरण में है - UniFi कंट्रोलर Purple के RADIUS सर्वर से Access-Accept संदेश प्राप्त नहीं कर रहा है या उस पर कार्रवाई नहीं कर रहा है। इस क्रम में जांचें: (1) UniFi कंट्रोलर पर RADIUS शेयर्ड सीक्रेट Purple के डैशबोर्ड में दिए गए सीक्रेट से बिल्कुल मेल खाता है; (2) कंट्रोलर से Purple के RADIUS सर्वर IP पते पर पोर्ट 1812 और 1813 पर आउटबाउंड UDP की अनुमति है; (3) UniFi कंट्रोलर पर कॉन्फ़िगर किए गए RADIUS सर्वर IP पते वर्तमान हैं (Purple ने उन्हें अपडेट किया हो सकता है)। कंट्रोलर पर पैकेट कैप्चर करने से यह पुष्टि हो जाएगी कि Access-Accept संदेश आ रहा है या नहीं।

Q3. एक होटल IT मैनेजर रिपोर्ट करता है कि अपने डिवाइस पर VPN का उपयोग करने वाले मेहमान Captive Portal को बिल्कुल भी एक्सेस नहीं कर पा रहे हैं। बिना VPN वाले मेहमान सामान्य रूप से कनेक्ट होते हैं। होटल Cisco Meraki MX एप्लायंसेज का उपयोग करता है। क्या IT टीम को VPN उपयोगकर्ताओं को समायोजित करने के लिए Captive Portal कॉन्फ़िगरेशन को बदलना चाहिए?

संकेत: विचार करें कि Captive Portal द्वारा इंटरसेप्ट किए जाने से पहले एक VPN डिवाइस के नेटवर्क ट्रैफिक पर क्या प्रभाव डालता है।

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

नहीं - Captive Portal कॉन्फ़िगरेशन को बदलने की आवश्यकता नहीं है। एक VPN क्लाइंट डिवाइस से बाहर निकलने से पहले उसके सभी ट्रैफिक को एन्क्रिप्ट कर देता है, जिसमें HTTP कनेक्टिविटी प्रोब भी शामिल है। गेटवे एन्क्रिप्टेड VPN ट्रैफिक को इंटरसेप्ट नहीं कर सकता है, इसलिए यह कभी भी 302 रीडायरेक्ट जारी नहीं करता है। मेहमान को अपना VPN अक्षम करना होगा, Captive Portal ऑथेंटिकेशन पूरा करना होगा, और फिर VPN को पुनः सक्षम करना होगा। यह Captive Portal और VPN की एक बुनियादी आर्किटेक्चरल सीमा है, न कि कोई कॉन्फ़िगरेशन त्रुटि। IT टीम को अतिथि WiFi निर्देशों में एक नोट जोड़ना चाहिए जिसमें VPN उपयोगकर्ताओं को कनेक्ट करने से पहले अपने VPN को अक्षम करने की सलाह दी गई हो।

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

पब्लिक WiFi का निवारण (Troubleshooting): 'Connected, No Internet' और स्पैश पेज रीडायरेक्शन विफलताओं को ठीक करना

यह आधिकारिक तकनीकी संदर्भ गाइड Captive Portal डिटेक्शन के अंतर्निहित तंत्र को स्पष्ट करती है और उन छह प्राथमिक विफलता मोडों का विवरण देती है जो गेस्ट WiFi को कनेक्ट होने से रोकते हैं। यह IT प्रबंधकों और नेटवर्क आर्किटेक्ट्स को HTTP रीडायरेक्ट मुद्दों, DNS संघर्षों और MAC रैंडमाइजेशन चुनौतियों को हल करने के लिए एक व्यावहारिक समस्या निवारण फ्रेमवर्क प्रदान करता है।

गाइड पढ़ें →

हाई-डेंसिटी वायरलेस नेटवर्क पर DHCP टाइमआउट के शीर्ष 10 कारण

यह आधिकारिक तकनीकी संदर्भ मार्गदर्शिका हाई-डेंसिटी वायरलेस नेटवर्क पर DHCP टाइमआउट के शीर्ष दस कारणों की पहचान करती है और व्यावहारिक, विक्रेता-तटस्थ समाधान रणनीतियाँ प्रदान करती है। वरिष्ठ IT नेताओं, नेटवर्क आर्किटेक्ट्स और वेन्यू ऑपरेशंस डायरेक्टर्स के लिए डिज़ाइन की गई, यह गहन इंजीनियरिंग सिद्धांतों, चरण-दर-चरण कार्यान्वयन वर्कफ़्लो और मापने योग्य व्यावसायिक परिणामों को कवर करती है। जानें कि कनेक्शन की बाधाओं को कैसे समाप्त किया जाए और मांग वाले एंटरप्राइज परिवेशों में निर्बाध कनेक्टिविटी प्रदान करने के लिए अपने वायरलेस इंफ्रास्ट्रक्चर को कैसे अनुकूलित किया जाए।

गाइड पढ़ें →

धीमे WiFi प्रदर्शन का निदान करने के लिए पैकेट कैप्चर (PCAP) का उपयोग करना

यह तकनीकी संदर्भ मार्गदर्शिका IT प्रबंधकों, नेटवर्क आर्किटेक्ट्स और वेन्यू ऑपरेशन्स डायरेक्टर्स को पैकेट कैप्चर (PCAP) विश्लेषण का उपयोग करके धीमे एंटरप्राइज WiFi प्रदर्शन का निदान और समाधान करने के लिए एक संरचित, पैकेट-स्तरीय कार्यप्रणाली प्रदान करती है। रीट्रांसमिशन दरों, एयरटाइम उपयोग और फिजिकल लेयर मेटाडेटा सहित कच्चे 802.11 फ्रेम का विश्लेषण करके, टीमें वायर्ड या एप्लिकेशन समस्याओं से RF-लेयर की बाधाओं को सटीकता से अलग कर सकती हैं। होटल, रिटेल चेन, स्टेडियम और कॉन्फ्रेंस सेंटरों सहित उच्च-घनत्व वाले स्थानों पर लागू, यह मार्गदर्शिका नेटवर्क क्षमता को पुनः प्राप्त करने और अतिथि अनुभव की रक्षा करने के लिए व्यावहारिक नैदानिक वर्कफ़्लो, वास्तविक दुनिया के केस स्टडीज और कॉन्फ़िगरेशन समाधान चरण प्रदान करती है।

गाइड पढ़ें →