Captive Portal रीडायरेक्ट की समस्याओं को हल करना: गेस्ट WiFi कनेक्शन की विफलताओं को ठीक करना
जब मेहमान आपके WiFi से जुड़ते हैं लेकिन इंटरनेट का उपयोग नहीं कर पाते हैं, तो इसका कारण लगभग हमेशा एक गलत तरीके से कॉन्फ़िगर किया गया Captive Portal रीडायरेक्ट होता है - न कि कोई हार्डवेयर खराबी। यह मार्गदर्शिका IT प्रबंधकों, नेटवर्क आर्किटेक्ट्स और CTOs के लिए विफलताओं की पूरी श्रृंखला का निदान और समाधान करने के लिए एक गहन तकनीकी संदर्भ प्रदान करती है: OS-स्तर के कनेक्टिविटी प्रोब और HSTS प्रमाणपत्र संघर्षों से लेकर RADIUS प्रमाणीकरण अंतराल और DHCP की कमी तक। यह प्रत्येक विफलता मोड को एक ठोस सुधार से जोड़ता है और दिखाता है कि कैसे Purple का हार्डवेयर-स्वतंत्र क्लाउड ओवरले Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet परिनियोजनों में इन समस्याओं को समाप्त करता है।
Video overview
इस गाइड को सुनें
पॉडकास्ट ट्रांसक्रिप्ट देखें
हमारी मुख्य श्रृंखला का हिस्सा: Captive Portal मार्गदर्शिका →
कार्यकारी सारांश (Executive summary)
'गैस्ट WiFi कनेक्टेड है लेकिन इंटरनेट नहीं चल रहा है' वाली क्वेरी एंटरप्राइज नेटवर्किंग में सबसे आम सपोर्ट टिकटों में से एक है। यह लक्षण हर विजिटर को दिखाई देता है; जबकि इसका कारण अधिकांश IT टीमों को तब तक अदृश्य रहता है जब तक वे रीडायरेक्ट चेन को नहीं समझ लेते। एक Captive Portal (जिसे स्प्लैश पेज या हॉटस्पॉट गेटवे भी कहा जाता है) डिवाइस के शुरुआती HTTP कनेक्टिविटी प्रोब को इंटरसेप्ट करता है और लॉगिन पेज पर HTTP 302 रीडायरेक्ट जारी करता है। यदि उस चेन का कोई भी चरण टूट जाता है - जैसे ब्लॉक किए गए प्रोब, HSTS संघर्ष, वॉल्ड गार्डन कमियां, RADIUS विफलताएं, या DHCP समाप्ति - तो गैस्ट को केवल एक कनेक्टेड WiFi आइकन दिखाई देता है और कोई इंटरनेट नहीं मिलता है। यह गाइड आपको हर विफलता मोड, अंतर्निहित प्रोटोकॉल मैकेनिक्स और उन्हें हल करने वाले कॉन्फ़िगरेशन परिवर्तनों के बारे में बताती है। Purple 80,000 से अधिक लाइव वेन्यू पर काम करता है और सालाना 440 मिलियन लॉगिन प्रोसेस करता है (Purple आंतरिक डेटा, 2024), और यहाँ वर्णित पैटर्न हॉस्पिटैलिटी, रिटेल, ट्रांसपोर्ट और पब्लिक-सेक्टर डिप्लॉयमेंट में देखे जाने वाले सबसे लगातार मूल कारणों का प्रतिनिधित्व करते हैं।
तकनीकी गहराई (Technical deep-dive)
Captive Portal डिटेक्शन वास्तव में कैसे काम करता है
प्रत्येक प्रमुख ऑपरेटिंग सिस्टम एक इन-बिल्ट मैकेनिज्म के साथ आता है जो यह पता लगाता है कि इंटरनेट एक्सेस देने से पहले नेटवर्क को प्रमाणीकरण (authentication) की आवश्यकता है या नहीं। इन मैकेनिज्म को समझना ही सभी Captive Portal समस्या निवारण (troubleshooting) की नींव है।
जब कोई डिवाइस किसी 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 नो कंटेंट |
| Windows (NCSI) | http://www.msftconnecttest.com/connecttest.txt |
'Microsoft Connect Test' बॉडी के साथ HTTP 200 |
| Chrome (सभी प्लेटफॉर्म) | http://www.gstatic.com/generate_204 |
HTTP 204 नो कंटेंट |
| Firefox | http://detectportal.firefox.com/success.txt |
HTTP 200 |
यदि गेटवे इनमें से किसी एक अनुरोध को इंटरसेप्ट करता है और Captive Portal URL की ओर इशारा करते हुए एक HTTP 302 रीडायरेक्ट लौटाता है, तो OS पहचान लेता है कि यह एक पोर्टल के पीछे है और स्प्लैश पेज को प्रदर्शित करने के लिए एक छद्म-ब्राउज़र (एक लाइटवेट WebView) खोलता है। यदि प्रोब पूरी तरह से ब्लॉक हो जाता है, तो OS 'कोई इंटरनेट कनेक्शन नहीं' रिपोर्ट करता है और कभी भी पोर्टल खोलने का प्रयास नहीं करता है। यह 'गैस्ट WiFi कनेक्टेड है लेकिन इंटरनेट नहीं चल रहा है' लक्षण का सबसे आम कारण है।
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 ट्रैफ़िक को बीच में रोकने का प्रयास न करें।
The 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 संदेश प्राप्त या संसाधित नहीं हुआ। सामान्य कारणों में एक बेमेल साझा रहस्य (shared secret), स्थानीय फ़ायरवॉल द्वारा ब्लॉक किए गए UDP पोर्ट 1812 और 1813, या गेटवे पर RADIUS सर्वर IP पता गलत तरीके से कॉन्फ़िगर किया जाना शामिल है।
उच्च-घनत्व वाले वातावरण में DHCP थकावट
स्टेडियमों, कॉन्फ्रेंस केंद्रों और परिवहन केंद्रों में, DHCP की कमी कनेक्शन विफलताओं का एक सामान्य कारण है जो बिल्कुल captive portal समस्या जैसी ही दिखती है। यदि DHCP पूल भरा हुआ है, तो एक नया डिवाइस एक्सेस पॉइंट से जुड़ तो जाता है लेकिन उसे कभी भी IP एड्रेस नहीं मिलता है। IP एड्रेस के बिना, डिवाइस HTTP प्रोब नहीं भेज सकता और कभी भी captive portal तक नहीं पहुंच पाता है। डिवाइस SSID से कनेक्टेड दिखाई देता है लेकिन उसमें इंटरनेट नहीं होता है।
मैनचेस्टर एयरपोर्ट्स ग्रुप (MAG) जैसे स्थानों के लिए, जहाँ यात्रियों की संख्या तेजी से चरम पर पहुँचती है, सबनेट का आकार औसत के बजाय अधिकतम समवर्ती डिवाइस संख्या के लिए निर्धारित किया जाना चाहिए। कम DHCP लीज समय (अस्थायी विज़िटर नेटवर्क के लिए 15 - 30 मिनट) चले गए डिवाइसों से जल्दी से एड्रेस वापस ले लेते हैं।
कार्यान्वयन गाइड
Purple के क्लाउड ओवरले के साथ एकीकृत होने पर निम्नलिखित चरण किसी भी हार्डवेयर प्लेटफॉर्म - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, या Fortinet पर लागू होते हैं।
चरण 1: बाहरी captive portal के लिए SSID को कॉन्फ़िगर करें। अपने हार्डवेयर कंट्रोलर में, गेस्ट SSID को अन-ऑथेंटिकेटेड क्लाइंट्स को Purple के बाहरी पोर्टल URL पर रीडायरेक्ट करने के लिए सेट करें। कंट्रोलर पर ही किसी भी स्थानीय स्पलैश पेज को अक्षम करें।
चरण 2: walled garden को परिभाषित करें। न्यूनतम रूप से निम्नलिखित डोमेन जोड़ें: Purple का पोर्टल और RADIUS एंडपॉइंट्स (अपने हार्डवेयर इंटीग्रेशन गाइड देखें), ऊपर सूचीबद्ध OS डिटेक्शन प्रोब URLs, आपके पहचान प्रदाता डोमेन (Microsoft Entra ID, Okta, या Google Workspace), और आपके स्पलैश पेज एसेट्स द्वारा उपयोग किए जाने वाले कोई भी CDN डोमेन।
चरण 3: RADIUS कॉन्फ़िगर करें। Purple के RADIUS सर्वर IP एड्रेस, अपने Purple डैशबोर्ड से शेयर्ड सीक्रेट दर्ज करें, और ऑथेंटिकेशन पोर्ट को 1812 और अकाउंटिंग पोर्ट को 1813 पर सेट करें। सत्यापित करें कि आपका स्थानीय फ़ायरवॉल इन पोर्ट्स पर आउटबाउंड UDP की अनुमति देता है।
चरण 4: सेशन पैरामीटर सेट करें। हॉस्पिटैलिटी और रिटेल के लिए, MAC address कैशिंग सक्षम के साथ सेशन की अवधि 24 घंटे सेट करें। यह मेहमानों को एक ही विज़िट के दौरान फिर से ऑथेंटिकेट करने के लिए मजबूर होने से बचाता है। उच्च-सुरक्षा वाले वातावरणों के लिए, पुनः ऑथेंटिकेशन के साथ छोटे सेशन उपयुक्त होते हैं।
चरण 5: अपने DHCP स्कोप का आकार निर्धारित करें। पीक क्षमता पर अपने स्थान के लिए अधिकतम समवर्ती डिवाइस संख्या की गणना करें। 500 सीटों वाले रेस्टोरेंट में व्यस्त सर्विस के दौरान 800 डिवाइस देखे जा सकते हैं। 30 मिनट के लीज समय के साथ DHCP पूल का आकार 1,000 एड्रेस तक सेट करें।
चरण 6: विभिन्न ऑपरेटिंग सिस्टम पर परीक्षण करें। कॉन्फ़िगरेशन के बाद, iOS, Android, और Windows डिवाइसों पर संपूर्ण फ्लो का परीक्षण करें। प्रत्येक एक अलग प्रोब URL और WebView कार्यान्वयन का उपयोग करता है। एक प्लेटफॉर्म पर विफलता जबकि अन्य काम कर रहे हैं, लगभग हमेशा एक walled garden गैप होता है।
अपने विशिष्ट सेटअप को लेकर कोई सवाल हैं?
हमारी टीम 80,000 से अधिक वेन्यू में वेन्यू ऑपरेटरों, IT मैनेजरों और नेटवर्क इंजीनियरों के साथ काम करती है। 20 मिनट का कॉल बुक करें और हम आपको दिखाएंगे कि आपके जैसे अन्य लोगों ने इसे कैसे हल किया।
सर्वोत्तम प्रथाएं
निम्नलिखित सिफारिशें Purple के 80,000 से अधिक स्थानों के डिप्लॉयमेंट के मानकों और पैटर्न्स को दर्शाती हैं।
मेहमान और कर्मचारियों के नेटवर्क को अलग करें। कम से कम तीन SSIDs चलाएं: Guest WiFi, Staff WiFi, और एक IoT नेटवर्क। मेहमानों के ट्रैफ़िक को आंतरिक सिस्टम से अलग किया जाना चाहिए। आर्किटेक्चर विवरण के लिए हमारा गाइड Three SSIDs to rule them all: guest, Passpoint, and IoT WiFi देखें।
एक समर्पित गेस्ट VLAN का उपयोग करें। लेटरल मूवमेंट को रोकने और फ़ायरवॉल पॉलिसी को सरल बनाने के लिए मेहमानों के ट्रैफ़िक को उसके अपने VLAN में विभाजित करें। यदि कोई भी पेमेंट कार्ड डेटा नेटवर्क से गुजरता है, तो यह एक PCI-DSS आवश्यकता है।
सचेत-विकल्प ऑप्ट-इन लागू करें। 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 अकाउंटिंग लॉग्स की जांच करें। एक सफल प्रमाणीकरण एक Accounting-Start रिकॉर्ड जनरेट करता है। यदि किसी अतिथि के लॉग इन करने के बाद आपको कोई अकाउंटिंग रिकॉर्ड नहीं दिखता है, तो RADIUS संचार बाधित है। शेयर्ड सीक्रेट, सर्वर IP, और फ़ायरवॉल नियमों की जांच करें।
DHCP लीज़ उपयोग की जांच करें। DHCP सर्वर पर, पूल आकार के मुकाबले वर्तमान लीज़ संख्या की समीक्षा करें। यदि उपयोग 90% से अधिक है, तो आप समाप्ति के करीब हैं। पूल का विस्तार करें या लीज़ का समय तुरंत कम करें।
निम्नलिखित तालिका सबसे आम लक्षणों को उनके मूल कारणों और प्रासंगिक समाधानों से जोड़ती है।
| लक्षण | सबसे संभावित मूल कारण | समाधान |
|---|---|---|
| पोर्टल किसी भी डिवाइस पर कभी दिखाई नहीं देता | गेटवे ACL द्वारा OS प्रोब ब्लॉक किया गया | प्री-ऑथ अनुमति सूची में प्रोब URL जोड़ें |
| पोर्टल iOS पर दिखाई देता है, Android पर नहीं | Android प्रोब URL वॉल्ड गार्डन से गायब है | वॉल्ड गार्डन में connectivitycheck.gstatic.com जोड़ें |
| पोर्टल लोड होने पर HTTPS प्रमाणपत्र त्रुटि | गेटवे HTTP के बजाय HTTPS को इंटरसेप्ट कर रहा है | केवल HTTP प्रोब इंटरसेप्शन पर भरोसा करें |
| पोर्टल लोड होता है, लॉगिन के बाद इंटरनेट नहीं | RADIUS Access-Accept गेटवे द्वारा प्राप्त नहीं हुआ | शेयर्ड सीक्रेट, पोर्ट 1812/1813, RADIUS सर्वर IP सत्यापित करें |
| सोशल लॉगिन बटन बिना किसी चेतावनी के विफल हो जाता है | पहचान प्रदाता डोमेन वॉल्ड गार्डन में नहीं है | Microsoft Entra ID / Google Workspace एंडपॉइंट्स जोड़ें |
| अतिथियों को हर विज़िट पर पुनः प्रमाणित करना पड़ता है | सत्र की अवधि बहुत कम है या MAC कैशिंग अक्षम है | सत्र को 24 घंटे पर सेट करें, MAC एड्रेस कैशिंग सक्षम करें |
| पीक ऑवर्स के दौरान रुक-रुक कर होने वाली विफलताएं | DHCP पूल की समाप्ति | सबनेट का विस्तार करें, लीज़ का समय कम करें |
-
ROI और व्यावसायिक प्रभाव
प्रत्येक captive portal विफलता एक छूटा हुआ डेटा कैप्चर अवसर है। Purple का Guest WiFi प्लेटफॉर्म प्रत्येक सफल प्रमाणीकरण को एक फर्स्ट-पार्टी डेटा रिकॉर्ड - नाम, ईमेल, जनसांख्यिकीय डेटा, और विज़िट फ्रीक्वेंसी में परिवर्तित करता है - जो सीधे मार्केटिंग ऑटोमेशन और लॉयल्टी प्रोग्राम्स में फ़ीड होता है।
Premier Inn या Whitbread जैसे hospitality ऑपरेटर के लिए, 700-प्रॉपर्टी एस्टेट में पोर्टल प्रमाणीकरण सफलता दरों में 10% का सुधार सीधे प्रति माह हजारों अतिरिक्त ऑप्ट-इन रिकॉर्ड में बदल जाता है। वे रिकॉर्ड खरीदी गई सूचियों की तुलना में काफी अधिक ओपन रेट वाले व्यक्तिगत ईमेल अभियानों को शक्ति प्रदान करते हैं।
retail ऑपरेटरों के लिए, captive portal खरीदार के ठहरने के समय, दोहराए जाने वाले विज़िट फ्रीक्वेंसी और क्रॉस-लोकेशन व्यवहार को समझने का प्रवेश बिंदु है। Purple ने अपने वेन्यू नेटवर्क पर 29 बिलियन डेटा पॉइंट्स (Purple आंतरिक डेटा) एकत्र किए हैं। वह डेटा केवल उसी प्रमाणीकरण दर जितना ही अच्छा है जो इसे जनरेट करता है।
Manchester Airports Group जैसे transport हब के लिए, विश्वसनीय guest WiFi एक यात्री संतुष्टि मीट्रिक है जिसे बोर्ड स्तर पर ट्रैक किया जाता है। एक पोर्टल जो पीक प्रस्थान अवधियों के दौरान रुक-रुक कर विफल होता है, वह शिकायतें पैदा करता है और वेन्यू के नेट प्रमोटर स्कोर को नुकसान पहुंचाता है। healthcare परिवेशों के लिए, विश्वसनीय विज़िटर WiFi नैदानिक कर्मचारियों पर दबाव को कम करता है, जो अन्यथा कनेक्टिविटी से जुड़ी शिकायतों को संभालते हैं, और यह मरीज़ों के अनुभव से जुड़े मेट्रिक्स को भी बेहतर बनाता है।
Purple का 99.999% अपटाइम SLA यह सुनिश्चित करता है कि क्लाउड ओवरले स्वयं विफलता का कारण नहीं है। जब पोर्टल की समस्याएं आती हैं, तो उसका कारण लगभग हमेशा स्थानीय कॉन्फ़िगरेशन होता है - जिसे बिना कोई सपोर्ट टिकट जनरेट किए हल करने के लिए यह गाइड आपको तैयार करती है।
References
[1] Troubleshooting Tip: General captive portal explanation, flow and troubleshooting. Fortinet Community, November 2024. https://community.fortinet.com/fortigate-3/troubleshooting-tip-general-captive-portal-explanation-flow-and-troubleshooting-188409
[2] RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements. IETF. https://www.rfc-editor.org/info/rfc8910
[3] Network Connectivity Status Indicator overview for Windows. Microsoft Learn, February 2025. https://learn.microsoft.com/en-us/windows-server/networking/ncsi/ncsi-overview
[4] 7 Captive Portal Problems That Break Guest WiFi (And Quick Fixes). Spotipo, February 2026. https://www.spotipo.com/post/troubleshooting-captive-portals-common-issues
[5] Solution for HSTS issues with captive portal. Ubiquiti Community. https://community.ui.com/questions/Solution-for-HSTS-issues-with-captive-portal/17b033e7-3dfe-4830-af8f-bf6ead23d8b0
मुख्य परिभाषाएं
Captive portal
नेटवर्क में शामिल होने वाले डिवाइस को पूर्ण इंटरनेट एक्सेस प्रदान किए जाने से पहले उसके सामने प्रदर्शित होने वाला एक वेब पेज। गेटवे डिवाइस के शुरुआती HTTP कनेक्टिविटी प्रोब को इंटरसेप्ट करता है और उसे पोर्टल URL पर रीडायरेक्ट करता है।
होटल की लॉबी से लेकर स्टेडियम के परिसरों तक, हर गेस्ट WiFi लॉगिन पेज के पीछे का तंत्र। RFC 8910 में परिभाषित।
Walled garden
डोमेन और IP एड्रेस का वह सेट जिस तक कोई डिवाइस Captive Portal प्रमाणीकरण पूरा करने से पहले पहुंच सकता है। walled garden गंतव्यों के लिए जाने वाले ट्रैफ़िक को प्रमाणीकरण की आवश्यकता से छूट मिलती है।
इसमें OS प्रोब URL, आइडेंटिटी प्रोवाइडर एंडपॉइंट्स, CDN डोमेन और पेमेंट प्रोसेसर डोमेन शामिल होने चाहिए। गलत तरीके से कॉन्फ़िगर किया गया walled garden, Captive Portal विफलताओं का दूसरा सबसे आम कारण है।
NCSI (Network Connectivity Status Indicator)
एक Windows सुविधा जो यह निर्धारित करने के लिए `msftconnecttest.com` की जांच करती है कि डिवाइस में इंटरनेट एक्सेस है या वह Captive Portal के पीछे है। Microsoft के नेटवर्किंग दस्तावेज़ों में परिभाषित।
यदि गेटवे इस प्रोब को ब्लॉक करता है, तो Windows 'इंटरनेट एक्सेस नहीं' की रिपोर्ट करता है और 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) प्रबंधन प्रदान करता है, जो पोर्ट 1812 (प्रमाणीकरण) और पोर्ट 1813 (लेखांकन) पर UDP के माध्यम से संचालित होता है।
Purple का क्लाउड प्लेटफ़ॉर्म RADIUS सर्वर के रूप में कार्य करता है। स्थानीय गेटवे (Meraki, Aruba आदि) Purple के RADIUS सर्वरों को प्रमाणीकरण अनुरोध भेजता है और Access-Accept या Access-Reject प्रतिक्रिया पर कार्य करता है।
MAC address caching
लौटने वाले उपकरणों को पहचानने और पुनः प्रमाणीकरण की आवश्यकता के बिना सत्र स्थिति बनाए रखने के लिए डिवाइस के विशिष्ट हार्डवेयर पहचानकर्ता को संग्रहीत करने की प्रक्रिया।
सत्र विंडो के भीतर संक्षिप्त डिस्कनेक्शन और बार-बार आने वाले विजिटर्स के बीच सत्र निरंतरता सक्षम करता है। हॉस्पिटैलिटी वातावरण के लिए आवश्यक जहां मेहमान एक क्षेत्र से दूसरे क्षेत्र में जाते हैं।
Identity-Based Networks
Purple का आर्किटेक्चर मॉडल जिसमें एक्सेस नीतियां, VLAN असाइनमेंट और एनालिटिक्स केवल डिवाइस के IP या MAC एड्रेस के बजाय उपयोगकर्ता की प्रमाणित पहचान के आधार पर लागू किए जाते हैं।
यह 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 का परीक्षण करते हैं, जो संभवतः पहले से ही अनुमति सूची (whitelist) में है। Android डिवाइस connectivitycheck.gstatic.com और clients3.google.com/generate_204 का परीक्षण करते हैं। ये Google डोमेन लगभग निश्चित रूप से वॉल्ड गार्डन से गायब हैं। इन्हें प्री-ऑथेंटिकेशन अनुमति सूची में जोड़ने से समस्या हल हो जाती है। टीम को द्वितीयक Android प्रोब URL के रूप में connectivitycheck.android.com को भी जोड़ना चाहिए। वॉल्ड गार्डन को अपडेट करने के बाद, प्रभावित SSIDs को रीस्टार्ट करें और सुधार की पुष्टि करने के लिए फ़ैक्टरी-रीसेट Android डिवाइस पर परीक्षण करें, क्योंकि पहले से कनेक्टेड डिवाइस पर कैश्ड नेटवर्क स्थिति परिणाम को छुपा सकती है।
150 Cisco Meraki MX उपकरणों वाली एक रिटेल श्रृंखला रिपोर्ट करती है कि मेहमान Purple स्प्लैश पेज पर प्रमाणित होते हैं - Purple डैशबोर्ड सफल लॉगिन दिखाता है - लेकिन फॉर्म पूरा करने के बाद भी मेहमानों के पास कोई इंटरनेट एक्सेस नहीं है। यह समस्या एक साथ सभी स्थानों को प्रभावित करती है।
चूंकि Purple क्लाउड प्लेटफ़ॉर्म सफल लॉगिन दिखाता है, इसलिए प्रमाणीकरण चरण स्वयं काम कर रहा है। विफलता प्राधिकरण (authorisation) चरण में है - Meraki उपकरण को Purple के RADIUS सर्वर से RADIUS Access-Accept संदेश प्राप्त नहीं हो रहा है या वह उस पर कार्रवाई नहीं कर रहा है। टीम को क्रम में तीन चीजों की जांच करनी चाहिए: पहला, सत्यापित करें कि Meraki डैशबोर्ड पर RADIUS साझा रहस्य (shared secret) Purple पोर्टल में मौजूद रहस्य से बिल्कुल मेल खाता है (एक भी अक्षर का अंतर मूक विफलता का कारण बनता है); दूसरा, पुष्टि करें कि Meraki उपकरण से Purple के RADIUS सर्वर IP पतों पर पोर्ट 1812 और 1813 पर आउटबाउंड UDP ट्रैफ़िक की अनुमति है; तीसरा, जांचें कि क्या हाल ही में किसी नेटवर्क परिवर्तन ने फ़ायरवॉल नियम या NAT नीति पेश की है जो इस ट्रैफ़िक को अवरुद्ध करती है। चूंकि समस्या एक साथ सभी 150 स्थानों को प्रभावित करती है, इसलिए इसका कारण संभवतः एक केंद्रीकृत फ़ायरवॉल नीति परिवर्तन या एक Purple RADIUS सर्वर IP पता परिवर्तन है जिसे Meraki कॉन्फ़िगरेशन में प्रसारित नहीं किया गया था।
अभ्यास प्रश्न
Q1. एक 5,000 सीटों वाले स्थल पर एक बड़े सम्मेलन के दौरान, IT टीम को रिपोर्ट मिलती है कि सैकड़ों प्रतिभागी गेस्ट WiFi पोर्टल तक नहीं पहुंच पा रहे हैं। एक्सेस पॉइंट सामान्य एसोसिएशन संख्या दिखाते हैं। यह समस्या इवेंट शुरू होने के 45 मिनट बाद शुरू हुई। सबसे संभावित कारण क्या है और इसका तत्काल समाधान क्या है?
संकेत: समस्या इवेंट शुरू होने के बाद शुरू हुई, लॉन्च के समय नहीं। विचार करें कि अधिक उपकरणों के जुड़ने पर कौन सा संसाधन सीमित हो जाता है।
मॉडल उत्तर देखें
सबसे संभावित कारण DHCP पूल का समाप्त होना है। जैसे ही उपस्थित लोग आए और SSID से जुड़े, DHCP पूल भर गया। नए डिवाइस एक्सेस पॉइंट से जुड़ तो जाते हैं लेकिन वे IP एड्रेस प्राप्त नहीं कर सकते, इसलिए वे कभी भी कैप्टिव पोर्टल को ट्रिगर करने के लिए आवश्यक HTTP प्रोब नहीं भेज पाते हैं। इसका त्वरित समाधान DHCP लीज समय को घटाकर 15 मिनट करना है (जिससे जाने वाले डिवाइसों से एड्रेस तेजी से वापस मिल सकें) और, यदि संभव हो, तो एक दूसरा सबनेट जोड़कर पूल का विस्तार करना है। दीर्घकालिक समाधान अगले इवेंट में औसत संख्या के बजाय अधिकतम समवर्ती डिवाइस संख्या के लिए 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 का उपयोग करने वाले गेस्ट कैप्टिव पोर्टल तक बिल्कुल भी नहीं पहुँच पा रहे हैं। बिना VPN वाले गेस्ट सामान्य रूप से कनेक्ट होते हैं। होटल Cisco Meraki MX एप्लायंसेज का उपयोग करता है। क्या IT टीम को VPN उपयोगकर्ताओं को समायोजित करने के लिए कैप्टिव पोर्टल कॉन्फ़िगरेशन को बदलना चाहिए?
संकेत: विचार करें कि कैप्टिव पोर्टल द्वारा इंटरसेप्ट किए जाने से पहले एक VPN डिवाइस के नेटवर्क ट्रैफ़िक के साथ क्या करता है।
मॉडल उत्तर देखें
नहीं - कैप्टिव पोर्टल कॉन्फ़िगरेशन को बदलने की आवश्यकता नहीं है। एक VPN क्लाइंट डिवाइस से ट्रैफ़िक बाहर निकलने से पहले ही HTTP कनेक्टिविटी प्रोब सहित सभी ट्रैफ़िक को एन्क्रिप्ट कर देता है। गेटवे एन्क्रिप्टेड VPN ट्रैफ़िक को इंटरसेप्ट नहीं कर सकता है, इसलिए यह कभी भी 302 रीडायरेक्ट जारी नहीं करता है। गेस्ट को अपना 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 not redirecting: causes and fixes - कारण और समाधान
यह गाइड अतिथि स्थिति, रीडायरेक्ट, प्री-ऑथराइजेशन रूट और कंट्रोलर ऑथराइजेशन का क्रमवार पालन करके UniFi guest portal रीडायरेक्ट विफलता का पता लगाती है। यह वेन्यू IT टीमों को guest-network बनाम Hotspot के भ्रम, बाहरी पोर्टल हैंड-ऑफ़, वर्तमान UniFi OS अकाउंट आवश्यकताओं और DNS आइसोलेशन परीक्षण को हल करने के लिए एक विश्वसनीय तरीका प्रदान करती है।
Cisco Meraki splash page नहीं चल रहा है: एक ट्रबलशूटिंग फ्लोचार्ट
यह व्यावहारिक डे-टू गाइड यह पहचानती है कि Cisco Meraki splash फ्लो कहाँ विफल हुआ है: क्लाइंट ऑथराइजेशन, HTTP रीडायरेक्ट की शुरुआत, walled-garden रीचैबिलिटी या RADIUS साइन-ऑन। यह वेन्यू IT टीमों को एक नियंत्रित साक्ष्य पथ प्रदान करता है, ताकि वे लाइव एस्टेट में व्यापक बदलाव किए बिना Guest WiFi को बहाल कर सकें।
एंटरप्राइज गेस्ट WiFi सेटअप गाइड: VLAN सेगमेंटेशन, सुरक्षा, और Captive Portals
यह तकनीकी गाइड IT टीमों को दिखाती है कि VLAN Segmentation, फ़ायरवॉल पॉलिसी और एक Captive Portal का उपयोग करके Guest WiFi को एक नियंत्रित इंटरनेट-एक्सेस सेवा के रूप में कैसे सेट किया जाए। यह यह भी बताती है कि कैसे Purple के रजिस्ट्रेशन फॉर्म और ऑनबोर्डिंग नियंत्रण स्टाफ, भुगतान और परिचालन प्रणालियों के चारों ओर की सीमा को कमजोर किए बिना एक आनुपातिक विज़िटर अनुभव का समर्थन करते हैं।
अपने विशिष्ट सेटअप को लेकर कोई सवाल हैं?
हमारी टीम 80,000 से अधिक वेन्यू में वेन्यू ऑपरेटरों, IT मैनेजरों और नेटवर्क इंजीनियरों के साथ काम करती है। 20 मिनट का कॉल बुक करें और हम आपको दिखाएंगे कि आपके जैसे अन्य लोगों ने इसे कैसे हल किया।