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

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

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

Tom Hackett द्वाराप्रकाशित अपडेट किया गया
📖 6 मिनट का पाठ1,703 शब्द2 हल किए गए उदाहरण3 अभ्यास प्रश्न8 मुख्य परिभाषाएं

Video overview

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

पॉडकास्ट ट्रांसक्रिप्ट देखें
Purple के इस तकनीकी ब्रीफिंग में आपका स्वागत है। आज हम एंटरप्राइज़ वायरलेस नेटवर्किंग में सबसे लगातार और सबसे गलत समझी जाने वाली समस्याओं में से एक का समाधान कर रहे हैं: guest WiFi captive portal जो लोड होने से साफ मना कर देता है। आप इस स्थिति से गुजरे होंगे। एक मेहमान आपके होटल, आपके रिटेल स्टोर, आपके स्टेडियम, या आपके कॉन्फ्रेंस सेंटर में आता है। वे WiFi नेटवर्क से जुड़ते हैं। कुछ नहीं होता। कोई लॉगिन पेज नहीं। कोई इंटरनेट नहीं। बस एक घूमता हुआ आइकॉन और बढ़ती हुई हताशा। वेन्यू ऑपरेशन्स डायरेक्टर्स और IT मैनेजर्स के लिए, वह क्षण केवल एक छोटी सी असुविधा नहीं है। यह आपके गेस्ट एक्सपीरियंस की सीधी विफलता, फ्रंट-ऑफ-हाउस सपोर्ट कॉल्स में बढ़ोतरी, और उस फर्स्ट-पार्टी डेटा को कैप्चर करने के छूटे हुए अवसर को दर्शाता है जो आपके वायरलेस इंफ्रास्ट्रक्चर इन्वेस्टमेंट को सही ठहराता है। इस ब्रीफिंग में, हम इसके तकनीकी पहलुओं को गहराई से समझेंगे। हम बताएंगे कि ऑपरेटिंग सिस्टम के स्तर पर captive portal डिटेक्शन वास्तव में कैसे काम करता है, उन छह बुनियादी कारणों की पहचान करेंगे जो कनेक्शन विफलताओं के बड़े हिस्से के लिए जिम्मेदार हैं, और आपको एक व्यावहारिक, लागू करने योग्य ट्रबलशूटिंग फ्रेमवर्क देंगे जिसे आप आज ही अपनी IT टीम को सौंप सकते हैं। आइए इसके काम करने के तरीके से शुरुआत करें। ज्यादातर लोग captive portal को केवल एक लॉगिन पेज समझते हैं। यह वास्तव में एक नेटवर्क-लेवल ट्रैफिक इंटरसेप्शन मैकेनिज्म है, और चीजें खराब होने पर यह अंतर बहुत मायने रखता है। इसकी प्रक्रिया इस प्रकार है। एक गेस्ट का डिवाइस आपके गेस्ट SSID से जुड़ता है और DHCP के माध्यम से एक IP एड्रेस प्राप्त करता है। उस समय, ऑपरेटिंग सिस्टम यूजर द्वारा ब्राउज़र खोलने का इंतजार नहीं करता है। बैकग्राउंड में, एक सिस्टम सर्विस तुरंत वेंडर-नियंत्रित प्रोब URL पर एक अनएन्क्रिप्टेड HTTP GET रिक्वेस्ट भेजती है। iOS डिवाइसेस captive.apple.com पर क्वेरी करते हैं। Android डिवाइसेस connectivitycheck.gstatic.com पर क्वेरी करते हैं। Windows डिवाइसेस msftconnecttest.com पर क्वेरी करते हैं। Firefox का detectportal.firefox.com पर अपना खुद का प्रोब है। यदि नेटवर्क के पास ओपन इंटरनेट एक्सेस है, तो ये प्रोब अपनी अपेक्षित प्रतिक्रियाएं वापस देते हैं, और ऑपरेटिंग सिस्टम यह निष्कर्ष निकालता है कि सब कुछ ठीक है। लेकिन एक गेस्ट नेटवर्क पर, आपका वायरलेस गेटवे या कंट्रोलर इंटरनेट तक पहुँचने से पहले उस HTTP प्रोब को इंटरसेप्ट कर लेता है। अपेक्षित प्रतिक्रिया के बजाय, गेटवे एक HTTP 307 रीडायरेक्ट वापस करता है जो आपके captive portal स्प्लैश पेज की ओर इशारा करता है। ऑपरेटिंग सिस्टम अनपेक्षित रीडायरेक्ट का पता लगाता है, यह महसूस करता है कि यह एक captive portal के पीछे है, और लॉगिन पेज प्रदर्शित करने के लिए एक सैंडबॉक्स्ड ब्राउज़र विंडो खोलता है - जिसे अक्सर Captive Network Assistant कहा जाता है। यह इसकी सामान्य प्रक्रिया है। अब आइए उन छह तरीकों के बारे में बात करते हैं जिनसे यह काम करना बंद कर देता है।पहला मूल कारण: DHCP पूल की समाप्ति। यह उच्च-घनत्व वाले आयोजनों में सबसे बड़ा मूक खतरा है। यदि आप एक मानक स्लैश-24 सबनेट पर दो हजार उपस्थित लोगों के साथ एक कॉन्फ्रेंस चला रहे हैं, तो आपके पास केवल 254 उपयोगी IP एड्रेस होते हैं। यदि आपका DHCP लीज़ समय डिफ़ॉल्ट 24 घंटे पर सेट है, तो दरवाजे खुलने के कुछ ही मिनटों के भीतर आपका वह पूल समाप्त हो जाएगा। इसके बाद का प्रत्येक कनेक्शन प्रयास Captive Portal अनुक्रम शुरू होने से पहले ही विफल हो जाता है। इसका समाधान आसान है: उच्च-टर्नओवर वाले वातावरण के लिए गेस्ट DHCP लीज़ समय को 15 से 30 मिनट के बीच सेट करें, और अपने सबनेट को केवल कुल संख्या के लिए नहीं, बल्कि चरम समवर्ती उपयोगकर्ताओं के लिए उचित आकार दें। दूसरा मूल कारण: DNS इंटरसेप्शन की विफलता। Captive Portal रीडायरेक्ट गेटवे द्वारा HTTP प्रोब को इंटरसेप्ट करने पर निर्भर करता है। लेकिन प्रोब के लिए पहले एक DNS लुकअप की आवश्यकता होती है। यदि आपका DNS कॉन्फ़िगरेशन पूर्व-प्रमाणित (pre-authenticated) क्लाइंट्स को बाहरी डोमेन नामों को रिज़ॉल्यूशन करने की अनुमति नहीं देता है, तो प्रोब कभी सक्रिय नहीं होता है। सुनिश्चित करें कि आपकी फ़ायरवॉल पॉलिसी स्पष्ट रूप से अप्रमाणित क्लाइंट्स से DNS क्वेरी की अनुमति देती है, और एक टेस्ट डिवाइस के खिलाफ पैकेट कैप्चर चलाकर यह सत्यापित करें कि आपका DNS इंटरसेप्शन काम कर रहा है। तीसरा मूल कारण: अपूर्ण वॉलड गार्डन (walled garden)। वॉलड गार्डन - जिसे प्री-ऑथेंटिकेशन एक्सेस कंट्रोल लिस्ट भी कहा जाता है - यह परिभाषित करता है कि अप्रमाणित मेहमान किन बाहरी डोमेन तक पहुँच सकते हैं। यदि आपका पोर्टल स्प्लैश पेज किसी ऐसे CDN से एसेट लोड करता है जो वॉलड गार्डन में नहीं है, तो पेज एक खाली स्क्रीन के रूप में दिखाई देगा। यदि आप Google, Apple, या Facebook के माध्यम से सोशल लॉगिन की सुविधा देते हैं, तो उन प्रदाताओं द्वारा उपयोग किए जाने वाले प्रत्येक OAuth डोमेन को व्हाइटलिस्ट किया जाना चाहिए। और यहाँ सबसे महत्वपूर्ण बात है: सोशल आइडेंटिटी प्रदाता नियमित रूप से अपने CDN IP रेंज और ऑथेंटिकेशन डोमेन को अपडेट करते रहते हैं। छह महीने पहले पूरी तरह से काम करने वाला वॉलड गार्डन आज चुपचाप खराब हो सकता है। त्रैमासिक वॉलड गार्डन ऑडिट शेड्यूल करें और वाइल्डकार्ड डोमेन स्नूपिंग का उपयोग करें जहाँ आपका हार्डवेयर इसका समर्थन करता है। Cisco Meraki, HPE Aruba, Ruckus, और Juniper Mist पर, यह मूल रूप से (natively) उपलब्ध है। चौथा मूल कारण: रीडायरेक्ट को ब्लॉक करने वाला 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 और उससे ऊपर के संस्करण इसका मूल रूप से (natively) समर्थन करते हैं।मुख्य कारण नंबर पांच: अतिथि डिवाइस पर सक्रिय VPN। एक VPN डिवाइस से आने वाले सभी ट्रैफ़िक को एन्क्रिप्ट करता है और आपके गेटवे तक पहुँचने से पहले इसे एक बाहरी टनल के माध्यम से रूट करता है। आपका गेटवे कभी भी HTTP प्रोब को नहीं देखता है। Captive Portal डिटेक्शन सीक्वेंस कभी ट्रिगर नहीं होता है। अतिथि को कोई लॉगिन पेज और कोई इंटरनेट नहीं दिखता है। अतिथि के लिए इसका समाधान सरल है: VPN को डिसेबल करें, पोर्टल से कनेक्ट करें, फिर VPN को फिर से इनेबल करें। आपके फ्रंट-ऑफ़-हाउस स्टाफ के लिए, यह पहला प्रश्न होना चाहिए जो वे तब पूछते हैं जब कोई अतिथि कनेक्शन की समस्या की रिपोर्ट करता है। मुख्य कारण नंबर छह: MAC एड्रेस रैंडमाइजेशन के कारण सेशन की निरंतरता का टूटना। आधुनिक iOS और Android डिवाइस प्राइवेसी फीचर के रूप में डिफ़ॉल्ट रूप से रैंडमाइज्ड MAC एड्रेस का उपयोग करते हैं। हर बार जब कोई डिवाइस नेटवर्क से कनेक्ट होता है, तो वह एक अलग MAC एड्रेस प्रस्तुत कर सकता है। चूंकि captive portal सेशन की स्थिति को MAC एड्रेस द्वारा ट्रैक किया जाता है, इसलिए एक अतिथि जिसने एक घंटे पहले प्रमाणित किया था, उसे अपने डिवाइस के MAC रोटेट होने के बाद फिर से लॉगिन पेज दिखाया जा सकता है। अतिथि के लिए इसका समाधान नेटवर्क सेटिंग्स में आपके विशिष्ट SSID के लिए Private Address को डिसेबल करना है। ऑपरेटर की ओर से इसका समाधान प्रोफाइल-आधारित प्रमाणीकरण लागू करना है - जैसे कि Passpoint और 802.1X के माध्यम से OpenRoaming - जो MAC एड्रेस के बजाय क्रेडेंशियल्स का उपयोग करके लेयर 2 पर प्रमाणित करता है, जिससे रैंडमाइजेशन अप्रासंगिक हो जाता है। अब आइए कार्यान्वयन के बारे में बात करते हैं। व्यवहार में वास्तव में एक अच्छी तरह से कॉन्फ़िगर किया गया captive portal परिनियोजन कैसा दिखता है? अपनी DHCP आर्किटेक्चर से शुरुआत करें। 200 से अधिक समवर्ती उपकरणों की अपेक्षा करने वाले किसी भी स्थान के लिए, एकल स्लैश-24 सबनेट से दूर हटें। स्लैश-22 या बड़े सबनेट का उपयोग करें, और अपने स्थान के ड्वेल प्रोफाइल से मेल खाने के लिए लीज टाइम सेट करें। एक होटल लीज को 8 घंटे पर सेट करता है। एक स्टेडियम लीज को 3 घंटे पर सेट करता है। एक शॉपिंग सेंटर लीज को 90 मिनट पर सेट करता है। एक कॉन्फ्रेंस सेंटर लीज को 30 मिनट पर सेट करता है। इसके बाद, प्रत्येक बड़े इवेंट से पहले अपने वॉल्ड गार्डन को सत्यापित करें। न्यूनतम आवश्यक प्रविष्टियां हैं: आपके पोर्टल का पूरी तरह से योग्य डोमेन नाम और सभी संबद्ध CDN डोमेन, Apple, Google, Windows और Firefox के लिए captive portal डिटेक्शन URL, और आपके द्वारा समर्थित प्रत्येक सोशल लॉगिन प्रदाता के लिए OAuth डोमेन। Purple के प्लेटफ़ॉर्म पर, हम अपनी क्लाउड-प्रबंधित सेवा के हिस्से के रूप में इन वॉल्ड गार्डन प्रविष्टियों को स्वचालित रूप से बनाए रखते हैं और अपडेट करते हैं, जो आपकी टीम से मैन्युअल रखरखाव के बोझ को हटा देता है। अपने पोर्टल प्रमाणपत्र के लिए, एक मान्यता प्राप्त प्रमाणपत्र प्राधिकारी से सार्वजनिक रूप से विश्वसनीय TLS प्रमाणपत्र का उपयोग करें। स्व-हस्ताक्षरित प्रमाणपत्र प्रत्येक डिवाइस पर ब्राउज़र चेतावनियाँ ट्रिगर करेंगे। समाप्ति से पहले प्रमाणपत्रों को नवीनीकृत करें - एक समाप्त हो चुका प्रमाणपत्र अचानक, पूरे स्थान पर पोर्टल विफलताओं के सबसे सामान्य कारणों में से एक है। एक जाल जो कई IT टीमों को फंसाता है: ऐसे डिवाइस से पोर्टल का परीक्षण करना जो पहले प्रमाणित हो चुका है। आपके डिवाइस का सेशन अभी भी सक्रिय है, इसलिए आप पोर्टल को पूरी तरह से बायपास कर देते हैं और निष्कर्ष निकालते हैं कि सब कुछ काम कर रहा है। हमेशा एक नए, अप्रमाणित डिवाइस से परीक्षण करें - या तो एक नया डिवाइस, या ऐसा डिवाइस जहां आप नेटवर्क को भूल चुके हैं और WiFi प्रोफाइल को साफ़ कर दिया है। आइए मैं आपको दो वास्तविक दुनिया के परिदृश्य देता हूँ जो इन सिद्धांतों को स्पष्ट करते हैं। परिदृश्य एक: मध्य लंदन में एक 350 कमरों वाला होटल। संपत्ति ने अतिथि WiFi के लिए एक एकल स्लैश-24 सबनेट चलाया। एक बड़े सम्मेलन के दौरान, 400 प्रतिनिधि एक साथ पहुंचे। 20 मिनट के भीतर, DHCP पूल समाप्त हो गया। मेहमानों ने कनेक्ट होने की सूचना दी लेकिन वे Captive Portal या इंटरनेट तक पहुंचने में असमर्थ थे। इसका तत्काल समाधान सबनेट को स्लैश-22 तक बढ़ाना था, जिससे 1,022 प्रयोग करने योग्य पते मिले, और लीज समय को 24 घंटे से घटाकर 8 घंटे करना था। दीर्घकालिक समाधान Purple के क्लाउड-प्रबंधित Captive Portal को लागू करना था, जो वास्तविक समय में DHCP पूल के उपयोग की निगरानी करता है और समाप्ति होने से पहले नेटवर्क टीम को सचेत करता है। इस बदलाव के 48 घंटों के भीतर पोर्टल विफलता दर लगभग शून्य हो गई। परिदृश्य दो: 200 स्टोर वाली एक प्रमुख रिटेल श्रृंखला। इस श्रृंखला ने अपने अतिथि पोर्टल पर Google और Facebook के माध्यम से सोशल लॉगिन का उपयोग किया। Google द्वारा अपने OAuth बुनियादी ढांचे को अपडेट करने के बाद, नए प्रमाणीकरण डोमेन walled garden में नहीं थे। मेहमान पोर्टल पेज तक पहुंच सकते थे लेकिन सोशल लॉगिन बटन खाली स्क्रीन दिखा रहे थे। श्रृंखला की IT टीम ने walled garden के अंतर की पहचान करने से पहले समस्या का निदान करने में दो दिन बिताए। एक बार पहचान होने के बाद समाधान में 10 मिनट लगे। सबक: क्लाउड-आधारित OAuth प्रदाताओं के लिए अपने walled garden में कभी भी IP पते को हार्डकोड न करें। वाइल्डकार्ड डोमेन प्रविष्टियों का उपयोग करें और त्रैमासिक रूप से उनकी समीक्षा करें। अब कुछ त्वरित प्रश्न जो हम नियमित रूप से स्थल की IT टीमों से सुनते हैं। पोर्टल iPhones पर काम करता है लेकिन Android उपकरणों पर क्यों नहीं? Android अपनी जांच URL के रूप में connectivitycheck.gstatic.com का उपयोग करता है। यदि वह डोमेन आपके फ़ायरवॉल द्वारा अवरुद्ध है या आपके walled garden में नहीं है, तो Android उपकरण कभी भी पोर्टल को ट्रिगर नहीं करते हैं। इसे स्पष्ट रूप से जोड़ें। एक अतिथि का कहना है कि पोर्टल लोड हो गया है लेकिन लॉग इन करने के बाद वे ऑनलाइन नहीं हो पा रहे हैं। यह लगभग हमेशा एक RADIUS प्राधिकरण विफलता है। जांचें कि आपका RADIUS सर्वर वायरलेस कंट्रोलर से पहुंचने योग्य है या नहीं, सत्यापित करें कि साझा रहस्य दोनों पक्षों में मेल खाता है, और Access-Reject संदेशों के लिए RADIUS लॉग की समीक्षा करें। हम उन मेहमानों को कैसे संभालें जो कुछ मिनटों के बाद बार-बार लॉग आउट हो जाते हैं? अपनी निष्क्रिय टाइमआउट सेटिंग की जांच करें। कई कंट्रोलर डिफ़ॉल्ट रूप से 5-मिनट की निष्क्रिय टाइमआउट पर सेट होते हैं, जो उन मोबाइल उपकरणों के लिए बहुत आक्रामक है जो इंटरैक्शन के बीच स्लीप मोड में चले जाते हैं। हॉस्पिटैलिटी और रिटेल परिवेशों के लिए निष्क्रिय टाइमआउट को कम से कम 30 मिनट पर सेट करें। आज की ब्रीफिंग के मुख्य बिंदुओं को संक्षेप में प्रस्तुत करने के लिए। अतिथि WiFi Captive Portal की विफलताएं छह श्रेणियों में आती हैं: DHCP पूल की समाप्ति, DNS इंटरसेप्शन विफलता, अपूर्ण walled garden, HSTS रीडायरेक्ट ब्लॉकिंग, क्लाइंट डिवाइस पर सक्रिय VPN, और MAC एड्रेस रैंडमाइजेशन। प्रत्येक का एक विशिष्ट, परीक्षण योग्य समाधान है। आपकी IT टीम के लिए, तत्काल कार्रवाइयां हैं: अपने DHCP लीज समय और सबनेट आकार का ऑडिट करें, अपने सोशल लॉगिन प्रदाताओं के वर्तमान OAuth डोमेन के खिलाफ अपने walled garden को सत्यापित करें, और हर कॉन्फ़िगरेशन परिवर्तन के बाद एक नए अप्रमाणित डिवाइस से अपने पोर्टल का परीक्षण करें।अपने दीर्घकालिक रोडमैप के लिए, लौटने वाले आगंतुकों के लिए Captive Portal री-ऑथेंटिकेशन के उत्तराधिकारी के रूप में OpenRoaming का मूल्यांकन करें। यह तकनीक परिपक्व है, इसके मानक IEEE 802.1X और WPA3-Enterprise के तहत स्थापित हैं, और Purple इसे Connect प्लान के तहत बिना किसी अतिरिक्त सॉफ्टवेयर लागत के उपलब्ध कराता है। Purple 80,000 से अधिक स्थानों पर काम करता है और केवल 2024 में ही इसने 440 मिलियन लॉगइन्स को प्रोसेस किया है। हमने इस ब्रीफिंग में वर्णित हर प्रकार की विफलता को देखा है - और उन्हें रोकने के लिए टूलिंग का निर्माण किया है। यदि आप यह जानना चाहते हैं कि 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' और स्पैश पेज रीडायरेक्शन विफलताओं को ठीक करना

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

यह गाइड सटीक रूप से बताती है कि ऑपरेटिंग सिस्टम स्तर पर Captive Portal डिटेक्शन कैसे काम करता है और अधिकांश कनेक्शन विफलताओं के लिए जिम्मेदार छह प्रमुख कारणों की पहचान करती है। यह DHCP समाप्ति, DNS इंटरसेप्शन विफलताएं, अपूर्ण walled gardens, ब्लॉक किए गए HSTS रीडायरेक्ट, सक्रिय VPN संघर्ष और MAC एड्रेस रैंडमाइजेशन समस्याओं को हल करने के लिए एक व्यावहारिक, विक्रेता-तटस्थ समस्या निवारण (troubleshooting) ढांचा प्रदान करती है।

तकनीकी गहन विश्लेषण: Captive Portal डिटेक्शन वास्तव में कैसे काम करता है

एक 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 प्रोब को इंटरसेप्ट कर लेता है। अपेक्षित प्रतिक्रिया के बजाय, गेटवे captive portal के स्प्लैश पेज की ओर इशारा करते हुए एक HTTP 307 Temporary Redirect वापस करता है। ऑपरेटिंग सिस्टम इस अप्रत्याशित रीडायरेक्ट का पता लगाता है, समझता है कि यह एक captive portal के पीछे है, और लॉगिन पेज प्रदर्शित करने के लिए एक सैंडबॉक्सयुक्त ब्राउज़र विंडो (कैप्टिव नेटवर्क असिस्टेंट) खोलता है।

पब्लिक WiFi की समस्याओं को हल करना: 'Connected, No Internet' और स्पैश पेज रीडायरेक्शन विफलताओं को ठीक करना - portal architec…

अपने विशिष्ट सेटअप को लेकर कोई सवाल हैं?

हमारी टीम 80,000 से अधिक वेन्यू में वेन्यू ऑपरेटरों, IT मैनेजरों और नेटवर्क इंजीनियरों के साथ काम करती है। 20 मिनट का कॉल बुक करें और हम आपको दिखाएंगे कि आपके जैसे अन्य लोगों ने इसे कैसे हल किया।

समस्या निवारण और जोखिम न्यूनीकरण: विफलता के 6 प्रमुख कारण

जब एक captive portal लोड होने में विफल रहता है, तो समस्या लगभग हमेशा छह विशिष्ट विफलता मोडों में से एक के कारण होती है। पब्लिक WiFi की समस्याओं को हल करना: 'Connected, No Internet' और स्पैश पेज रीडायरेक्शन विफलताओं को ठीक करना - root causes inf…

1. DHCP पूल का समाप्त होना

यह उच्च-घनत्व वाले आयोजनों में एक मूक हत्यारा है। यदि आप 2,000 सहभागियों के साथ एक सम्मेलन आयोजित कर रहे हैं और एक मानक /24 सबनेट का उपयोग कर रहे हैं, तो आपके पास केवल 254 उपयोग करने योग्य IP पते होते हैं। यदि आपका DHCP लीज समय डिफ़ॉल्ट 24 घंटे पर सेट है, तो दरवाजे खुलने के कुछ ही मिनटों के भीतर आपका पूल समाप्त हो जाएगा। उसके बाद प्रत्येक कनेक्शन का प्रयास Captive Portal अनुक्रम शुरू होने से पहले ही विफल हो जाएगा।

समाधान: उच्च-टर्नओवर वाले वातावरण के लिए अतिथि DHCP लीज समय को 15 से 30 मिनट के बीच सेट करें। अपने सबनेट का आकार केवल औसत उपस्थिति के आधार पर नहीं, बल्कि पीक समवर्ती उपयोगकर्ताओं के अनुसार निर्धारित करें। एक /22 सबनेट 1,022 उपयोग करने योग्य पते प्रदान करता है, जो उद्यम स्थलों के लिए अनुशंसित न्यूनतम आकार है।

2. DNS इंटरसेप्शन विफलता

Captive Portal रीडायरेक्शन HTTP प्रोब को इंटरसेप्ट करने वाले गेटवे पर निर्भर करता है। हालांकि, उस प्रोब के लिए पहले एक DNS लुकअप की आवश्यकता होती है। यदि आपका DNS कॉन्फ़िगरेशन पूर्व-प्रमाणित क्लाइंट्स को बाहरी डोमेन नामों को हल करने की अनुमति नहीं देता है, तो प्रोब कभी भी सक्रिय नहीं होगा।

समाधान: सुनिश्चित करें कि आपकी फ़ायरवॉल नीतियां स्पष्ट रूप से अप्रमाणित क्लाइंट्स से DNS प्रश्नों (पोर्ट 53) की अनुमति देती हैं। यह सत्यापित करने के लिए कि आपका DNS इंटरसेप्शन काम कर रहा है, एक परीक्षण डिवाइस पर पैकेट कैप्चर चलाएं।

3. अधूरा वॉल्ड गार्डन (Walled Garden)

वॉल्ड गार्डन (पूर्व-प्रमाणन एक्सेस कंट्रोल लिस्ट) यह परिभाषित करता है कि अप्रमाणित अतिथि किन बाहरी डोमेन तक पहुंच सकते हैं। यदि आपका पोर्टल स्प्लैश पेज किसी ऐसे CDN से एसेट लोड करता है जो वॉल्ड गार्डन में शामिल नहीं है, तो पेज एक खाली स्क्रीन के रूप में रेंडर होगा। यदि आप Google, Apple, या Microsoft Entra ID के माध्यम से सोशल लॉगिन प्रदान करते हैं, तो उन प्रदाताओं द्वारा उपयोग किए जाने वाले प्रत्येक OAuth डोमेन को श्वेतसूची (whitelist) में डाला जाना चाहिए। सोशल आइडेंटिटी प्रदाता नियमित रूप से अपनी CDN IP श्रेणियों और प्रमाणीकरण डोमेन को अपडेट करते रहते हैं; छह महीने पहले पूरी तरह से काम करने वाला वॉल्ड गार्डन रातोंरात खराब हो सकता है।

समाधान: त्रैमासिक वॉल्ड गार्डन ऑडिट शेड्यूल करें। जहां आपका हार्डवेयर इसका समर्थन करता है, वहां वाइल्डकार्ड डोमेन स्नूपिंग का उपयोग करें, जो मूल रूप से Cisco Meraki, HPE Aruba, Ruckus, और Juniper Mist पर उपलब्ध है। Purple हमारी क्लाउड-प्रबंधित सेवा के हिस्से के रूप में इन वॉल्ड गार्डन प्रविष्टियों को स्वचालित रूप से बनाए रखता है और अपडेट करता है।

4. 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 और उससे ऊपर के संस्करण इसका नेटिव रूप से समर्थन करते हैं।

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

एक VPN डिवाइस से आने-जाने वाले सभी ट्रैफ़िक को एन्क्रिप्ट करता है और आपके गेटवे तक पहुँचने से पहले इसे एक बाहरी टनल के माध्यम से रूट करता है। आपका गेटवे कभी भी HTTP प्रोब को नहीं देख पाता है, इसलिए Captive Portal डिटेक्शन सीक्वेंस कभी सक्रिय नहीं होता है। मेहमानों को न तो लॉगिन पेज दिखाई देता है और न ही इंटरनेट।

समाधान: मेहमान को VPN को अक्षम करना होगा, पोर्टल से कनेक्ट करना होगा और फिर VPN को फिर से सक्षम करना होगा। फ्रंट-ऑफ-हाउस स्टाफ के लिए, मेहमान से यह पूछना कि क्या वे VPN का उपयोग कर रहे हैं, समस्या निवारण का पहला कदम होना चाहिए।

6. MAC Address रैंडमाइजेशन द्वारा बाधित सत्र निरंतरता (Session Persistence)

आधुनिक iOS और Android डिवाइस गोपनीयता सुविधा के रूप में डिफ़ॉल्ट रूप से रैंडमाइज्ड MAC एड्रेस का उपयोग करते हैं। हर बार जब कोई डिवाइस किसी नेटवर्क से कनेक्ट होता है, तो वह एक अलग MAC एड्रेस प्रस्तुत कर सकता है। चूंकि Captive Portal सत्र की स्थिति को MAC एड्रेस द्वारा ट्रैक किया जाता है, इसलिए एक घंटे पहले प्रमाणित अतिथि को उनके डिवाइस का MAC बदलने के बाद फिर से लॉगिन पेज दिखाया जा सकता है।

समाधान: मेहमानों के लिए समाधान यह है कि वे अपने नेटवर्क सेटिंग्स में आपके विशिष्ट SSID के लिए Private Address को अक्षम कर दें। ऑपरेटर-साइड समाधान प्रोफाइल-आधारित प्रमाणीकरण को लागू करना है, जैसे कि 802.1X के माध्यम से Passpoint और OpenRoaming, जो MAC एड्रेस के बजाय क्रेडेंशियल्स का उपयोग करके लेयर 2 पर प्रमाणित करता है, जिससे रैंडमाइजेशन अप्रासंगिक हो जाता है।

कार्यान्वयन गाइड: एक लचीला आर्किटेक्चर बनाना

एक अच्छी तरह से कॉन्फ़िगर किए गए Captive Portal को तैनात करने के लिए सक्रिय आर्किटेक्चरल निर्णयों की आवश्यकता होती है।

  1. प्रत्येक बड़े आयोजन से पहले अपने वॉल्ड गार्डन (walled garden) को सत्यापित करें। न्यूनतम आवश्यक प्रविष्टियाँ हैं: आपके पोर्टल का FQDN और सभी संबद्ध CDN डोमेन, Apple, Google, Windows और Firefox के लिए Captive Portal डिटेक्शन URL, और आपके द्वारा समर्थित प्रत्येक सोशल लॉगिन प्रदाता के लिए OAuth डोमेन।
  2. सार्वजनिक रूप से विश्वसनीय TLS प्रमाणपत्र का उपयोग करें। स्व-हस्ताक्षरित (Self-signed) प्रमाणपत्र हर डिवाइस पर ब्राउज़र चेतावनियों को ट्रिगर करेंगे। प्रमाणपत्रों के समाप्त होने से पहले उनका नवीनीकरण करें; एक समाप्त हो चुका प्रमाणपत्र अचानक, पूरे स्थल पर पोर्टल विफलताओं के सबसे आम कारणों में से एक है।
  3. एक नए, अप्रमाणित डिवाइस से परीक्षण करें। पहले से प्रमाणित डिवाइस से पोर्टल का परीक्षण करने से पोर्टल पूरी तरह से बायपास हो जाएगा क्योंकि सत्र अभी भी सक्रिय है। हमेशा एक नए डिवाइस से परीक्षण करें, या ऐसे डिवाइस से परीक्षण करें जहाँ आप नेटवर्क को भूल चुके हैं और WiFi प्रोफ़ाइल को हटा दिया है।
  4. आइडल टाइमआउट को समायोजित करें। कई नियंत्रक डिफ़ॉल्ट रूप से 5-मिनट के आइडल टाइमआउट पर सेट होते हैं, जो उन मोबाइल उपकरणों के लिए अत्यधिक आक्रामक है जो इंटरैक्शन के बीच स्लीप मोड में चले जाते हैं। हॉस्पिटैलिटी और रिटेल वातावरण के लिए आइडल टाइमआउट को कम से कम 30 मिनट पर सेट करें।

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

Captive Portals एक परिपक्व तकनीक हैं, लेकिन इनमें कुछ अंतर्निहित जटिलताएं होती हैं। रणनीतिक लक्ष्य निर्बाध और सुरक्षित प्रमाणीकरण की दिशा में आगे बढ़ना है।

OpenRoaming, जो Passpoint और 802.1X पर निर्मित है, वापस आने वाले मेहमानों को बिना कोई लॉगिन पेज देखे स्वचालित रूप से और सुरक्षित रूप से कनेक्ट होने में मदद करता है। हमारे Connect प्लान के तहत, Purple OpenRoaming के लिए एक मुफ्त पहचान प्रदाता के रूप में कार्य करता है। Premier Inn और Manchester Airports Group जैसी जगहें दोहराए जाने वाले आगंतुकों के लिए फिर से प्रमाणीकरण की परेशानी को समाप्त करने के लिए पहले से ही इसका उपयोग कर रही हैं, जबकि पूरी तरह से GDPR अनुपालन और प्रथम-पक्ष डेटा संग्रह बनाए रख रही हैं। कनेक्शन विफलताओं को कम करके, आप एकत्र किए गए प्रथम-पक्ष डेटा की मात्रा को सीधे बढ़ा सकते हैं, जिससे ग्राहक निष्ठा और व्यक्तिगत जुड़ाव को बढ़ावा मिलता है।

Technical Briefing Podcast

हमारे 10 मिनट के तकनीकी ब्रीफिंग में हमारे सीनियर सॉल्यूशंस आर्किटेक्ट से इन समस्या निवारण चरणों का विस्तृत विश्लेषण सुनें।

मुख्य परिभाषाएं

Captive Portal

एक नेटवर्क-स्तरीय ट्रैफ़िक इंटरसेप्शन तंत्र जो इंटरनेट एक्सेस को तब तक प्रतिबंधित करता है जब तक कि उपयोगकर्ता कोई आवश्यक कार्रवाई पूरी नहीं कर लेता, जैसे कि शर्तों को स्वीकार करना या स्पैश पेज पर क्रेडेंशियल प्रदान करना।

एंटरप्राइज स्थानों के लिए गेस्ट एक्सेस को सुरक्षित करने और प्रथम-पक्ष डेटा कैप्चर करने का प्राथमिक तरीका।

Walled Garden

एक प्री-प्रमाणीकरण एक्सेस कंट्रोल लिस्ट जो यह परिभाषित करती है कि एक अप्रमाणित गेस्ट डिवाइस को किन बाहरी IP पतों या डोमेन तक पहुँचने की अनुमति है।

उपयोगकर्ता के पूरी तरह से प्रमाणित होने से पहले पोर्टल संपत्तियों, CDNs और 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 portals पर सत्र दृढ़ता को तोड़ती है, जिससे मेहमानों को फिर से प्रमाणित करने के लिए मजबूर होना पड़ता है यदि उनका MAC पता बदलता है।

OpenRoaming

WiFi नेटवर्क का एक संघ जो उपयोगकर्ताओं को बिना क्रेडेंशियल दर्ज किए या captive portal से इंटरैक्ट किए बिना भाग लेने वाले नेटवर्क से स्वचालित और सुरक्षित रूप से कनेक्ट होने की अनुमति देता है।

लगातार आने वाले आगंतुकों के लिए captive portals का रणनीतिक उत्तराधिकारी, जिसे Purple द्वारा एक निःशुल्क पहचान प्रदाता के रूप में समर्थित किया गया है।

RFC 8910 (DHCP Option 114)

एक मानक जो एक DHCP सर्वर को IP एड्रेस आवंटन के दौरान सीधे क्लाइंट डिवाइस को captive portal का URL प्रदान करने की अनुमति देता है।

यह पूरी तरह से HTTP रीडायरेक्शन की आवश्यकता को समाप्त करता है, जिससे HSTS के कारण होने वाली समस्याओं का समाधान होता है और पोर्टल का पता लगाने की गति में सुधार होता है।

हल किए गए उदाहरण

मध्य लंदन में एक 350 कमरों वाला होटल गेस्ट WiFi के लिए एक एकल /24 सबनेट चलाता है। एक बड़े सम्मेलन के दौरान, 400 प्रतिनिधि एक साथ आते हैं। 20 मिनट के भीतर, मेहमानों ने कनेक्ट होने की लेकिन पोर्टल या इंटरनेट तक पहुंचने में असमर्थ होने की सूचना दी।

इसका तत्काल समाधान सबनेट को /22 तक बढ़ाना है, जिससे 1,022 उपयोग करने योग्य पते मिलते हैं, और DHCP लीज समय को 24 घंटे से घटाकर 8 घंटे करना है। दीर्घकालिक समाधान Purple के क्लाउड-प्रबंधित captive portal को लागू करना है, जो वास्तविक समय में DHCP पूल उपयोग की निगरानी करता है और समाप्त होने से पहले नेटवर्क टीम को सचेत करता है।

परीक्षक की टिप्पणी: यह परिदृश्य क्लासिक DHCP पूल समाप्ति को प्रदर्शित करता है। एक /24 सबनेट केवल 254 उपयोग करने योग्य IP पते प्रदान करता है। सबनेट का आकार बढ़ाकर और लीज समय को कम करके, नेटवर्क सम्मेलन सेटिंग में विशिष्ट उपकरणों के उच्च टर्नओवर को समायोजित कर सकता है।

200 स्टोर वाली एक प्रमुख रिटेल श्रृंखला अपने गेस्ट पोर्टल पर Google और Facebook के माध्यम से सोशल लॉगिन का उपयोग करती है। Google द्वारा अपने OAuth इन्फ्रास्ट्रक्चर को अपडेट करने के बाद, मेहमान पोर्टल पेज पर तो पहुंच सकते हैं, लेकिन सोशल लॉगिन बटन खाली स्क्रीन दिखाते हैं।

IT टीम को Google द्वारा उपयोग किए जाने वाले नए प्रमाणीकरण डोमेन की पहचान करनी होगी और उन्हें walled garden (प्री-प्रमाणीकरण एक्सेस कंट्रोल लिस्ट) में जोड़ना होगा। भविष्य में इसे रोकने के लिए, उन्हें विशिष्ट IP पतों को हार्डकोड करने के बजाय वाइल्डकार्ड डोमेन प्रविष्टियों (जैसे, *.google.com) का उपयोग करना चाहिए, और त्रैमासिक रूप से walled garden की समीक्षा करनी चाहिए।

परीक्षक की टिप्पणी: यह तीसरे पक्ष के OAuth प्रदाताओं पर भरोसा करते समय स्थिर walled gardens की कमजोरी को उजागर करता है। क्लाउड-आधारित पहचान प्रदाता अक्सर अपने IP रेंज और CDN डोमेन बदलते रहते हैं। Cisco Meraki और HPE Aruba जैसे एंटरप्राइज हार्डवेयर द्वारा मूल रूप से समर्थित वाइल्डकार्ड स्नूपिंग, सही आर्किटेक्चरल दृष्टिकोण है।

अभ्यास प्रश्न

Q1. एक स्टेडियम IT निदेशक रिपोर्ट करता है कि हाफ-टाइम के दौरान, हजारों प्रशंसक गेस्ट WiFi से कनेक्ट होने का प्रयास करते हैं। कुछ के लिए पोर्टल लोड होता है, लेकिन कई रिपोर्ट करते हैं कि पोर्टल दिखने से पहले ही उनके डिवाइस 'Obtaining IP address' पर अटक गए हैं या 'Connected, No Internet' प्रदर्शित कर रहे हैं। सबसे संभावित आर्किटेक्चरल विफलता क्या है?

संकेत: नेटवर्क सेगमेंट पर उपलब्ध संसाधनों बनाम समवर्ती कनेक्शनों (concurrent connections) की मात्रा पर विचार करें।

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

नेटवर्क DHCP पूल की कमी का सामना कर रहा है। चरम समवर्ती उपयोगकर्ता लोड के लिए सबनेट का आकार संभवतः बहुत छोटा है (जैसे, एक /24), और DHCP लीज समय संभवतः बहुत अधिक सेट किया गया है। अनुशंसित दृष्टिकोण सबनेट का आकार बढ़ाना है (जैसे, /22 या /21 तक) और अपेक्षित ठहराव समय (जैसे, स्टेडियम के लिए 3 घंटे) से मेल खाने के लिए DHCP लीज समय को कम करना है।

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

संकेत: विचार करें कि आधुनिक ब्राउज़र सुरक्षित कनेक्शनों पर जबरन रीडायरेक्ट को कैसे संभालते हैं।

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

HSTS (HTTP Strict Transport Security) रीडायरेक्ट को ब्लॉक कर रहा है। अतिथि ने HSTS-प्रीलोडेड डोमेन (HTTPS के माध्यम से) पर जाने का प्रयास किया, और वायरलेस गेटवे ने पोर्टल पर रीडायरेक्ट करने के लिए उस सुरक्षित कनेक्शन को इंटरसेप्ट करने का प्रयास किया। ब्राउज़र ने सर्टिफिकेट बेमेल का पता लगाया और कनेक्शन को ब्लॉक कर दिया। गेटवे को केवल अनएन्क्रिप्टेड HTTP प्रोब्स को इंटरसेप्ट करने के लिए कॉन्फ़िगर किया जाना चाहिए।

Q3. आपने हाल ही में अपने captive portal पर Google और Microsoft Entra ID सोशल लॉगिन विकल्प सक्षम किए हैं। मेहमान रिपोर्ट करते हैं कि पोर्टल पेज लोड होता है, लेकिन लॉगिन बटन पर क्लिक करने पर टाइमआउट हो जाता है। IT विभाग के अप्रतिबंधित स्टाफ नेटवर्क पर परीक्षण करने पर पोर्टल पूरी तरह से काम करता है। कौन सा कॉन्फ़िगरेशन गायब है?

संकेत: प्रमाणीकरण पूरा होने से पहले अतिथि डिवाइस की नेटवर्क स्थिति पर विचार करें।

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

walled garden (प्री-ऑथेंटिकेशन एक्सेस कंट्रोल लिस्ट) अधूरा है। Google और Microsoft Entra ID द्वारा उपयोग किए जाने वाले OAuth प्रमाणीकरण डोमेन और CDN को व्हाइटलिस्ट नहीं किया गया है। चूंकि अतिथि अप्रमाणित है, इसलिए गेटवे इन बाहरी डोमेन तक पहुंच को ब्लॉक कर देता है, जिससे सोशल लॉगिन प्रक्रिया का टाइमआउट हो जाता है। IT टीम को walled garden में इन पहचान प्रदाताओं के लिए वाइल्डकार्ड प्रविष्टियां जोड़नी होंगी।

अक्सर पूछे जाने वाले प्रश्न

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 रीडायरेक्ट, hotspot और walled garden चेकलिस्ट

आप मेहमानों द्वारा रिपोर्ट की जाने वाली समस्याओं के आधार पर एक विफल हो रहे Ruckus captive portal का निदान करने और फिर उसे एक निश्चित क्रम में ठीक करने में सक्षम होंगे। इस क्रम में hotspot (WISPr) लॉगऑन URL, walled garden, नॉर्थबाउंड पोर्टल इंटरफ़ेस पासवर्ड, RADIUS प्रमाणीकरण और अकाउंटिंग, और HTTPS रीडायरेक्ट प्रमाणपत्र शामिल हैं। ये जाँच 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 या क्लाइंट सेटिंग्स को ठीक करेंगे।

गाइड पढ़ें →

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

अपने HPE Aruba captive portal में आ रही समस्याओं का निदान करने के लिए इस चेकलिस्ट का उपयोग करें: रीडायरेक्ट न होना, सर्टिफिकेट की चेतावनी आना या गेस्ट का लॉग इन न हो पाना। इसके बाद आप DNS, DHCP, walled garden, रीडायरेक्ट URL, सर्टिफिकेट या RADIUS में से समस्या का पता लगा सकते हैं। अंत में, Instant APs, Aruba Central या mobility controller पर इसका समाधान लागू करें।

गाइड पढ़ें →

अपने विशिष्ट सेटअप को लेकर कोई सवाल हैं?

हमारी टीम 80,000 से अधिक वेन्यू में वेन्यू ऑपरेटरों, IT मैनेजरों और नेटवर्क इंजीनियरों के साथ काम करती है। 20 मिनट का कॉल बुक करें और हम आपको दिखाएंगे कि आपके जैसे अन्य लोगों ने इसे कैसे हल किया।