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

कैप्टिव पोर्टल रीडायरेक्ट्स का समस्या निवारण: गेस्ट WiFi कनेक्शन विफलताओं का समाधान

आप स्टैक पर काम करके यह निदान करने में सक्षम होंगे कि गेस्ट WiFi कनेक्टेड लेकिन 'नो इंटरनेट' क्यों दिखाता है: एड्रेसिंग, DNS, प्रोब रीडायरेक्ट, वॉल्ड गार्डन और RADIUS। फिर आप लक्षण को उसके कारण से मिला सकते हैं, अपने पास पहले से मौजूद हार्डवेयर पर कॉन्फ़िगरेशन में इसे ठीक कर सकते हैं, और ऐसे चेंज कंट्रोल बना सकते हैं जो खराबी को दोबारा आने से रोकते हैं।

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

Video overview

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

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

हमारी मुख्य श्रृंखला का हिस्सा: कैप्टिव पोर्टल गाइड →

Useful? Link to this tool

जब गेस्ट WiFi कनेक्टेड दिखाई देता है लेकिन इंटरनेट नहीं होता है, तो डिवाइस नेटवर्क से जुड़ गया है लेकिन कैप्टिव पोर्टल रीडायरेक्ट टूट गया है। इसके सामान्य कारण अवरुद्ध ऑपरेटिंग सिस्टम प्रोब, गायब वॉल्ड गार्डन प्रविष्टियाँ या विफल DNS हैं। अन्य कारणों में समाप्त हो चुका DHCP पूल या एक RADIUS Access-Accept शामिल है जो कभी गेटवे तक नहीं पहुँचता है। कॉन्फ़िगरेशन में इनमें से प्रत्येक को ठीक किया जा सकता है।

"गेस्ट WiFi कनेक्टेड है लेकिन इंटरनेट नहीं है" कैसा दिखता है?

डिवाइस नेटवर्क नाम (SSID) से जुड़ता है और पूर्ण सिग्नल दिखाता है, फिर भी कुछ भी लोड नहीं होता है। प्रत्येक प्लेटफॉर्म इसे अलग तरह से रिपोर्ट करता है:

  • iOS नेटवर्क नाम के नीचे "No Internet Connection" सूचीबद्ध करता है।
  • Android "Connected, no internet" या "Sign in to network" प्रॉम्प्ट दिखाता है जो कहीं नहीं ले जाता है।
  • Windows नेटवर्क को "No internet" के रूप में चिह्नित करता है।

विज़िटर को एक काम करता हुआ WiFi आइकन और एक बंद ब्राउज़र दिखाई देता है, इसलिए वे वेन्यू को दोषी ठहराते हैं।

एक लक्षण कई अलग-अलग विफलताओं को छिपा सकता है। आप आमतौर पर इनमें से एक पैटर्न देखेंगे:

  • लॉगिन पेज किसी भी डिवाइस पर कभी दिखाई नहीं देता है।
  • लॉगिन पेज iPhones पर दिखाई देता है लेकिन Android फोन पर नहीं, या इसके विपरीत।
  • ब्राउज़र लॉगिन पेज के बजाय एक प्रमाणपत्र या गोपनीयता चेतावनी दिखाता है।
  • विज़िटर फ़ॉर्म पूरा करता है, एक सफलता का संदेश देखता है, और फिर भी कोई इंटरनेट नहीं होता है।
  • शांत समय में सब कुछ काम करता है और पीक समय में विफल हो जाता है।

प्रत्येक पैटर्न नेटवर्क की एक अलग परत की ओर इशारा करता है। एक्सेस पॉइंट्स को रीबूट करके नहीं, बल्कि पैटर्न को पढ़कर शुरुआत करें।

कैप्टिव पोर्टल डिटेक्शन कैसे काम करता है

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

प्रत्येक प्रमुख ऑपरेटिंग सिस्टम जैसे ही किसी नेटवर्क से जुड़ता है, कैप्टिव पोर्टल की जाँच करता है। यह एक ज्ञात पते पर एक प्लेन HTTP अनुरोध भेजता है और उत्तर की तुलना अपनी अपेक्षा से करता है। प्रत्येक परिणाम का एक अलग अर्थ होता है:

  • उत्तर मेल खाता है। डिवाइस मानता है कि उसके पास ओपन इंटरनेट है।
  • गेटवे एक HTTP 302 रीडायरेक्ट लौटाता है। डिवाइस जानता है कि वह एक पोर्टल के पीछे है। यह एक लाइटवेट ब्राउज़र विंडो खोलता है, जिसे अक्सर कैप्टिव नेटवर्क असिस्टेंट कहा जाता है, और आपका लॉगिन पेज लोड करता है।
  • अनुरोध का कोई उत्तर नहीं मिलता है। डिवाइस नो इंटरनेट की रिपोर्ट करता है और कुछ भी नहीं खोलता है।
प्लेटफॉर्म प्रोब URL ऑनलाइन होने पर अपेक्षित उत्तर
iOS और macOS http://captive.apple.com/hotspot-detect.html "Success" पेज के साथ HTTP 200
Android http://connectivitycheck.gstatic.com/generate_204 HTTP 204 No Content
Windows (NCSI) http://www.msftconnecttest.com/connecttest.txt "Microsoft Connect Test" टेक्स्ट के साथ HTTP 200
Firefox http://detectportal.firefox.com/success.txt "success" टेक्स्ट के साथ HTTP 200

Microsoft दस्तावेज़ित करता है कि उसका नेटवर्क कनेक्टिविटी स्टेटस इंडिकेटर (NCSI) DNS जाँच के रूप में dns.msftncsi.com को भी रिज़ॉल्व करता है। इसलिए प्री-ऑथेंटिकेशन DNS टूटने पर एक Windows लैपटॉप इंटरनेट न होने की रिपोर्ट कर सकता है, भले ही HTTP काम कर रहा हो।

कैप्टिव पोर्टल रीडायरेक्ट विफल होने के सामान्य कारण क्या हैं?

इसके लिए मुख्य रूप से सात कारण ज़िम्मेदार होते हैं। ये एड्रेसिंग से लेकर ऑथेंटिकेशन तक, अलग-अलग लेयर्स पर स्थित होते हैं।

ऑपरेटिंग सिस्टम प्रोब ब्लॉक है

गेटवे की प्री-ऑथेंटिकेशन एक्सेस कंट्रोल लिस्ट (ACL) प्रोब को रीडायरेक्ट करने के बजाय ड्रॉप कर देती है। डिवाइस को कोई प्रतिक्रिया नहीं मिलती है और वह मान लेता है कि इंटरनेट नहीं है। यह कभी पोर्टल नहीं खोलता है।

DNS फ़िल्टरिंग सेवा जो प्रोब होस्टनेम को ब्लॉक करती है, उसका भी यही प्रभाव होता है। पोर्टल कभी न दिखने का यह सबसे आम कारण है।

HTTPS और HSTS इंटरसेप्शन को बाधित करते हैं

RFC 6797 में परिभाषित HTTP स्ट्रिक्ट ट्रांसपोर्ब सिक्योरिटी (HSTS), ब्राउज़र को केवल HTTPS के ज़रिए किसी डोमेन तक पहुँचने का निर्देश देता है। ब्राउज़र HSTS डोमेन की प्रीलोड सूची के साथ आते हैं, जिसमें Google और अधिकांश बैंकों की सूची शामिल होती है। जब कोई विज़िटर google.com टाइप करता है, तो रिक्वेस्ट डिवाइस से निकलने से पहले ही ब्राउज़र उसे HTTPS में अपग्रेड कर देता है।

गेटवे google.com के लिए प्रमाण पत्र प्रस्तुत किए बिना उस रिक्वेस्ट को रीडायरेक्ट नहीं कर सकता है, जो उसके पास नहीं होता है। ब्राउज़र आगे बढ़ने के किसी विकल्प के बिना एक गंभीर सुरक्षा चेतावनी दिखाता है।

इसका समाधान केवल ऊपर दी गई तालिका में दिए गए प्लेन HTTP प्रोब को ही रीडायरेक्ट करना है, जो बिल्कुल इसी उद्देश्य के लिए मौजूद हैं। पोर्टल रीडायरेक्शन के लिए कभी भी HTTPS को इंटरसेप्ट न करें।

वॉल्ड गार्डन बहुत सीमित है

वॉल्ड गार्डन उन डोमेन और IP एड्रेस की सूची है जहाँ तक कोई डिवाइस ऑथेंटिकेट होने से पहले पहुँच सकता है। यदि कोई एंट्री गायब है, तो लॉगिन पेज आंशिक रूप से लोड होता है या साइन-इन चरण विफल हो जाता है। सामान्यतः निम्नलिखित जानकारी छूट जाती है:

  • सोशल या सिंगल साइन-ऑन लॉगिन के लिए आइडेंटिटी प्रोवाइडर एंडपॉइंट्स, जैसे कि Microsoft Entra ID, Okta या Google Workspace।
  • कंटेंट डिलीवरी नेटवर्क डोमेन जो आपके लॉगिन पेज के फ़ॉन्ट, स्क्रिप्ट और स्टाइलशीट को सर्व करते हैं।
  • पेमेंट प्रोसेसर डोमेन, यदि आप एक्सेस के लिए शुल्क लेते हैं।
  • Purple का कैप्टिव पोर्टल और RADIUS एंडपॉइंट्स, जो आपके हार्डवेयर के लिए Purple की इंटीग्रेशन गाइड में सूचीबद्ध हैं।

ऑथेंटिकेशन से पहले DNS विफल हो जाता है

पेज लोड करने से पहले डिवाइस को पोर्टल होस्टनेम को रिज़ॉल्व करना होगा। दो मामलों में रीडायरेक्ट कहीं नहीं पहुँचता है:

  • गेटवे प्री-ऑथेंटिकेशन स्थिति में DNS को ब्लॉक कर देता है।
  • DHCP ऐसा DNS सर्वर प्रदान करता है जिस तक डिवाइस नहीं पहुँच सकता।

Android में एक अतिरिक्त चुनौती आती है। यदि किसी विज़िटर ने एक विशिष्ट प्राइवेट DNS होस्टनेम सेट किया है, तो Android पोर्ट 853 पर DNS ओवर TLS की अपेक्षा करता है। ऑटोमैटिक मोड में यह सामान्य DNS पर वापस आ जाता है।

DHCP पूल समाप्त हो गया है

जब एड्रेस पूल समाप्त हो जाता है, तो एक नया डिवाइस एक्सेस पॉइंट से जुड़ तो जाता है लेकिन उसे कोई IP एड्रेस नहीं मिलता है। इसके बाद Windows खुद को 169.254.x.x लिंक-लोकल एड्रेस असाइन कर लेता है, और अन्य सिस्टम भी इसी तरह की स्वयं-असाइन की गई स्थिति दिखाते हैं।

वैध एड्रेस के बिना, डिवाइस प्रोब नहीं भेज सकता। यह कनेक्टेड दिखता है लेकिन इसमें कोई इंटरनेट नहीं होता है। यह स्टेडियमों, सम्मेलन केंद्रों और परिवहन केंद्रों में पीक-टाइम की क्लासिक विफलता है।

RADIUS कभी भी Access-Accept डिलीवर नहीं करता है

RADIUS (रिमोट ऑथेंटिकेशन डायल-इन यूजर सर्विस) ऑथेंटिकेशन सर्वर से आपके गेटवे तक लॉगिन निर्णय ले जाता है। सर्वर Access-Accept या Access-Reject का उत्तर देता है, जैसा कि RFC 2865 में परिभाषित किया गया है। इसके बाद गेटवे एक्सेस खोलता है या उसे बंद रखता है।जो विज़िटर फ़ॉर्म पूरा करता है लेकिन ऑफ़लाइन रहता है, इसका मतलब लगभग हमेशा यह होता है कि गेटवे से Access-Accept मिस हो गया है। इसके तीन सामान्य कारण हैं:

  • एक बेमेल shared secret।
  • एक फ़ायरवॉल जो UDP 1812 (ऑथेंटिकेशन) या UDP 1813 (अकाउंटिंग) को ब्लॉक कर रहा है। RFC 2865 और RFC 2866 इन पोर्ट्स को परिभाषित करते हैं।
  • कंट्रोलर पर गलत सर्वर पता।

पोर्टल का अपना सर्टिफ़िकेट समाप्त हो गया है

आपका लॉगिन पेज HTTPS के ज़रिए सर्व किया जाता है। यदि इसका TLS सर्टिफ़िकेट समाप्त हो जाता है, तो हर आधुनिक ब्राउज़र सुरक्षा चेतावनी के साथ पेज को ब्लॉक कर देता है। रीडायरेक्ट पूरी तरह से काम करता है, फिर भी विज़िटर साइन इन नहीं कर पाता है।

आप कैसे पता लगाते हैं कि आपका कारण कौन सा है?

क्रम में स्टैक पर काम करें। प्रत्येक जांच एक लेयर को खारिज करती है, इसलिए पहली विफलता पर रुकें।

  1. क्या डिवाइस में एक मान्य IP पता है? Windows पर ipconfig /all चलाएं, या फोन पर नेटवर्क विवरण देखें। 169.254.x.x पता, या बिल्कुल भी पता न होना, DHCP की ओर इशारा करता है। DHCP सर्वर पर पूल उपयोग की जांच करें। 90% से ऊपर, आप इसे पूरी तरह समाप्त करने के करीब हैं।
  2. क्या DNS रिज़ॉल्व होता है? गेस्ट वर्चुअल LAN (VLAN), जो एक तार्किक रूप से अलग नेटवर्क सेगमेंट है, पर मौजूद डिवाइस से पोर्टल होस्टनेम खोजें। यदि लुकअप विफल हो जाता है, तो प्री-ऑथेंटिकेशन DNS ब्लॉक हो जाता है या DHCP-असाइन किया गया DNS सर्वर गलत होता है।
  3. क्या प्रोब को 302 मिलता है? गेस्ट VLAN पर एक पैकेट कैप्चर लें, या HTTP प्रोब URL में से किसी एक पर ब्राउज़ करें। आपको प्रोब देखना चाहिए, फिर पोर्टल की ओर इशारा करने वाला एक HTTP 302 देखना चाहिए। बिना किसी उत्तर वाले प्रोब का अर्थ है कि ACL इसे ड्रॉप कर देता है। बिल्कुल भी प्रोब न होने का अर्थ है कि डिवाइस सोचता है कि वह पहले से ही ऑनलाइन है, अक्सर कैश्ड स्थिति से। नेटवर्क को भूल जाएं और फिर से जुड़ें।
  4. क्या लॉगिन पेज पूरी तरह से लोड होता है? ब्राउज़र डेवलपर टूल (F12) खोलें और नेटवर्क टैब देखें। थर्ड-पार्टी डोमेन के लिए ब्लॉक किए गए अनुरोध वाल्ड गार्डन गैप्स की ओर इशारा करते हैं।
  5. क्या गेटवे को Access-Accept प्राप्त होता है? कंट्रोलर के RADIUS लॉग की जांच करें। एक सफल लॉगिन के बाद Start स्थिति वाला एक Accounting-Request आता है। यदि लॉगिन के बाद कोई अकाउंटिंग रिकॉर्ड दिखाई नहीं देता है, तो RADIUS पाथ टूट गया है।

फिर जो आप देखते हैं उसका इस तालिका से मिलान करें।

लक्षण सबसे संभावित कारण समाधान
किसी भी डिवाइस पर पोर्टल कभी दिखाई नहीं देता गेटवे ACL या DNS फ़िल्टर द्वारा अवरुद्ध प्रोब ऑथेंटिकेशन से पहले प्रोब होस्टनेम की अनुमति दें और उन्हें रीडायरेक्ट करें
पोर्टल iOS पर दिखाई देता है, Android पर नहीं रीडायरेक्ट नियमों से Android प्रोब होस्ट गायब है connectivitycheck.gstatic.com को रीडायरेक्ट करें और पुनः परीक्षण करें
पोर्टल के स्थान पर सर्टिफ़िकेट की चेतावनी HTTPS इंटरसेप्शन, या समाप्त हो चुका पोर्टल सर्टिफ़िकेट केवल HTTP प्रोब्स को रीडायरेक्ट करें, और सर्टिफ़िकेट को रीन्यू करें
पोर्टल गायब छवियों या बटनों के साथ लोड होता है कंटेंट डिलीवरी नेटवर्क डोमेन ब्लॉक किए गए हैं वाल्ड गार्डन में लॉगिन पेज के एसेट डोमेन जोड़ें
सोशल लॉगिन बिना किसी संदेश के विफल हो जाता है आइडेंटिटी प्रोवाइडर एंडपॉइंट गायब हैं Microsoft Entra ID, Okta या Google Workspace एंडपॉइंट जोड़ें
लॉगिन सफल, कोई इंटरनेट नहीं Access-Accept गेटवे तक नहीं पहुँच रहा है shared secret, UDP 1812 और 1813, तथा सर्वर पते की जांच करें
आगंतुक हर बार आने पर साइन इन करने के लिए कहते हैं छोटा सत्र, या यादृच्छिक MAC पता सत्र लंबा करें और MAC यादृच्छिकीकरण की योजना बनाएं
केवल व्यस्त समय में विफलताएं DHCP पूल समाप्त सबनेट को बड़ा करें और लीज समय को छोटा करें

व्यावहारिक परिदृश्य: व्यस्त समय में 1,500 सीटों वाला सम्मेलन केंद्र

स्थिति. एक सम्मेलन केंद्र ने आठ घंटे की DHCP लीज के साथ एक ही /24 सबनेट पर अपना सहभागी नेटवर्क चलाया। सुबह के मुख्य भाषण सुचारू रूप से चले। दोपहर के भोजन के बाद, दोपहर के सत्रों के लिए आने वाले सहभागियों ने "कनेक्टेड, कोई इंटरनेट नहीं" देखा। हेल्प डेस्क ने इसे पोर्टल की खराबी माना और कंट्रोलर को दो बार पुनरारंभ किया।

क्या किया गया था. निदान के चरण 1 में 169.254.x.x पते वाले नए उपकरण मिले। एक /24 254 उपयोगी पते प्रदान करता है, और आठ घंटे की लीज ने हर सुबह का पता सुरक्षित रखा। टीम ने सहभागी VLAN को /21 पर स्थानांतरित कर दिया और लीज को 30 मिनट तक कम कर दिया।

परिणाम. उपयोगी पते 254 से बढ़कर 2,046 हो गए, जो पिछली क्षमता से लगभग आठ गुना अधिक है। जाने वाले सहभागी द्वारा छोड़ा गया पता अब आठ घंटे के बजाय 30 मिनट के भीतर पूल में वापस आ जाता है। सुधार में एक परिवर्तन विंडो लगी और कोई नया हार्डवेयर नहीं लगा।

व्यावहारिक परिदृश्य: 200 कमरों वाला होटल जहां Android अतिथि साइन इन नहीं कर सके

स्थिति. लॉगिन पृष्ठ के नए डिज़ाइन के बाद, 200 कमरों वाले होटल को Android अतिथियों से फ्रंट डेस्क की शिकायतें प्राप्त हुईं। उनमें से अधिकांश ने गूगल साइन-इन विकल्प चुना। पोर्टल दिखाई दिया, लेकिन बटन ने कुछ नहीं किया।

क्या किया गया था. IT प्रबंधक ने एक iPhone, एक Android फोन और एक Windows लैपटॉप पर फ़्लो का परीक्षण किया। लैपटॉप पर डेवलपर टूल ने फ़ॉन्ट डिलीवरी नेटवर्क और गूगल के साइन-इन डोमेन के ब्लॉक किए गए अनुरोधों को दिखाया। नए डिज़ाइन ने दोनों को जोड़ दिया था। टीम ने उन्हें वॉल्ड गार्डन में जोड़ दिया।

परिणाम. पहले पुनपरीक्षण पर तीनों परीक्षण उपकरणों पर गूगल साइन-इन पूरा हो गया। सुधार के लिए दो वॉल्ड गार्डन प्रविष्टियों की आवश्यकता थी और कोई हार्डवेयर परिवर्तन नहीं हुआ।

व्यावहारिक परिदृश्य: फ़ायरवॉल रिफ़्रेश के बाद 40-स्टोर की रिटेल संपत्ति

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

क्या किया गया था. चरण 5 में रिफ़्रेश किए गए स्टोरों से कोई अकाउंटिंग रिकॉर्ड नहीं मिला। नए फ़ायरवॉल टेम्पलेट ने डिफ़ॉल्ट रूप से आउटबाउंड UDP को अस्वीकार कर दिया, जिससे 1812 और 1813 ब्लॉक हो गए। टीम ने टेम्पलेट में स्पष्ट आउटबाउंड नियम जोड़े और इसे सभी 40 स्टोरों में पुश कर दिया।

परिणाम. पुश के बाद हर स्टोर से अकाउंटिंग रिकॉर्ड फिर से दिखाई दिए। चूंकि केवल रिफ़्रेश किए गए स्टोर विफल रहे, पैटर्न सीधे टेम्पलेट की ओर इशारा करता था और WiFi से दूर था।

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

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

आप इसे प्रत्येक ऑपरेटिंग सिस्टम और कंट्रोलर पर कैसे ठीक करते हैं?

कंट्रोलर सुधार हर प्लेटफ़ॉर्म पर एक ही पैटर्न का पालन करता है। ऑपरेटिंग सिस्टम सुधार ज्यादातर यह जानने के बारे में हैं कि प्रत्येक कैसे व्यवहार करता है।

आपके कंट्रोलर पर

Purple, Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet पर क्लाउड ओवरले के रूप में चलता है। सुधार पैटर्न आठों पर समान है:

  1. अपने Purple इंटीग्रेशन गाइड में दिए गए बाहरी कैप्टिव पोर्टल URL पर गेस्ट SSID को पॉइंट करें, और किसी भी लोकल स्प्लैश पेज को अक्षम करें।
  2. प्रोब सहित सभी अन-ऑथेंटिकेटेड HTTP ट्रैफिक को उस URL पर रीडायरेक्ट करें। HTTPS को वैसा ही रहने दें।
  3. ऑथेंटिकेशन से पहले DNS और DHCP की अनुमति दें।
  4. वॉल्ड गार्डन एंट्रियां जोड़ें: Purple एंडपॉइंट्स, आइडेंटिटी प्रदाता एंडपॉइंट्स और लॉगिन पेज एसेट डोमेन।
  5. अपने Purple डैशबोर्ड से RADIUS सर्वर पते और साझा सीक्रेट दर्ज करें। फिर पुष्टि करें कि फायरवॉल आउटबाउंड UDP 1812 और 1813 की अनुमति देता है।

विक्रेता और फर्मवेयर संस्करण के अनुसार मेनू नाम भिन्न होते हैं, इसलिए अपने प्लेटफॉर्म के लिए Purple के इंटीग्रेशन गाइड का पालन करें। रीडायरेक्ट अनुक्रम के लिए FortiGate कैप्टिव पोर्टल फ्लो पर Fortinet का कम्युनिटी डॉक्यूमेंटेशन एक उपयोगी विक्रेता-पक्ष संदर्भ है।

iOS और macOS पर

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

हाल के iOS और macOS रिलीज़ भी कैप्टिव पोर्टल API का समर्थन करते हैं। यह नेटवर्क को DHCP विकल्प 114 (RFC 8910 में परिभाषित) के माध्यम से अपने पोर्टल का विज्ञापन करने देता है, जो इंटरसेप्शन पर निर्भरता को कम करता है। यदि असिस्टेंट खुलता है लेकिन खाली रहता है, तो एसेट डोमेन के लिए वॉल्ड गार्डन की जांच करें।

Android पर

पोर्टल का पता चलने पर Android "Sign in to network" नोटिफिकेशन दिखाता है। यदि नोटिफिकेशन कभी दिखाई नहीं देता है, तो पुष्टि करें कि गेटवे connectivitycheck.gstatic.com को ड्रॉप करने के बजाय रीडायरेक्ट करता है।

यदि किसी विज़िटर को "Private DNS server cannot be accessed" दिखाई देता है, तो उनके फोन में एक सख्त प्राइवेट DNS होस्टनेम सेट है। आपके पास दो विकल्प हैं:

  • ऑथेंटिकेशन से पहले पोर्ट 853 पर TLS पर DNS की अनुमति दें।
  • विज़िटर से प्राइवेट DNS को स्वचालित पर स्विच करने के लिए कहें।

Windows पर

Windows NCSI HTTP प्रोब और इसकी DNS जांच पर निर्भर करता है। यदि पोर्टल स्वचालित रूप से नहीं खुलता है, तो रीडायरेक्ट को मैन्युअल रूप से ट्रिगर करने के लिए किसी भी साधारण HTTP साइट पर ब्राउज़ करें। लॉगिन के बाद लगातार "No internet" दिखने का आमतौर पर मतलब है कि गेटवे अभी भी प्रोब को रीडायरेक्ट कर रहा है। उस स्थिति में, गेटवे ने Access-Accept लागू नहीं किया है।

ब्राउज़र में

फ्रंट-लाइन स्टाफ को विज़िटर्स को HTTP पते पर भेजने के लिए निर्देश दें, न कि google.com जैसे HSTS डोमेन पर। Firefox detectportal.firefox.com के विरुद्ध अपना स्वयं का प्रोब चलाता है, इसलिए अपने रीडायरेक्ट परीक्षणों में उस होस्ट को शामिल करें।

आप गेस्ट WiFi रीडायरेक्ट विफलताओं को दोबारा होने से कैसे रोकते हैं?

अधिकांश बार-बार होने वाली घटनाएं मूल निर्माण से नहीं, बल्कि बदलावों के कारण होती हैं। एक फर्मवेयर अपडेट, एक नया फायरवॉल टेम्पलेट, एक लॉगिन पेज रीडिजाइन या एक समाप्त हो रहा प्रमाणपत्र परीक्षण से छूट जाता है। अपने परिवर्तन प्रक्रिया में इन नियंत्रणों को शामिल करें:

  • हर बदलाव के बाद तीन प्लेटफॉर्म पर परीक्षण करें। एक iPhone, एक Android फोन और एक Windows लैपटॉप का उपयोग करें। यदि अन्य पास हो जाते हैं और एक प्लेटफॉर्म विफल हो जाता है, तो सबसे पहले वॉल्ड गार्डन में अंतर देखें।
  • औसत नहीं, बल्कि पीक के आधार पर आकार तय करें। समवर्ती डिवाइसों की अधिकतम संख्या की गणना करें और अतिरिक्त क्षमता जोड़ें। अस्थायी विज़िटर नेटवर्क आमतौर पर 15 से 30 मिनट के लीज़ चलाते हैं।
  • विज़िट के अनुसार सत्र सेट करें। हॉस्पिटैलिटी और रिटेल स्थल आमतौर पर 24 घंटे के सत्र निर्धारित करते हैं, ताकि अतिथि प्रत्येक प्रवास या विज़िट में केवल एक बार साइन इन करे।
  • दैनिक लॉगिन वॉल्यूम पर नज़र रखें। Purple का WiFi Analytics स्थल के अनुसार लॉगिन रिपोर्ट करता है। किसी एक साइट पर अचानक गिरावट आपको आगंतुकों की शिकायत से पहले ही RADIUS या वॉल-गार्डन की खराबी के बारे में चेतावनी दे देती है।
  • प्रमाणपत्रों और साझा रहस्यों को परिवर्तन नियंत्रण के तहत रखें। पोर्टल प्रमाणपत्र की समाप्ति तिथि का कैलेंडर बनाएं। RADIUS साझा रहस्य को वहां संग्रहीत करें जहां फ़ायरवॉल और कंट्रोलर दोनों टीमें इसकी जांच कर सकें।
  • अतिथि ट्रैफ़िक को अलग करें। अतिथियों को उनके अपने VLAN पर रखें। PCI DSS पृथक्करण को आपके कार्डधारक डेटा वातावरण के दायरे से बाहर अतिथि नेटवर्क रखने के तरीके के रूप में देखता है।
  • MAC रैंडमाइजेशन के लिए योजना बनाएं। हालिया iOS और Android रिलीज़ प्रत्येक नेटवर्क के लिए एक रैंडम MAC पते का उपयोग करते हैं, और कुछ मोड इसे समय के साथ बदलते हैं। MAC पते पर आधारित सत्र कैशिंग फिर वापस आने वाले आगंतुकों को फिर से साइन इन करने के लिए कहेगी।
  • सहमति को ठीक से एकत्र करें। GDPR को मार्केटिंग डेटा के लिए सूचित, सकारात्मक सहमति की आवश्यकता होती है। Purple का सचेत-पसंद ऑप्ट-इन प्रत्येक उद्देश्य के लिए एक अलग विकल्प प्रस्तुत करता है।

वापस आने वाले आगंतुकों को कैप्टिव पोर्टल से हटाएं

सबसे स्थायी समाधान बार-बार आने वाले आगंतुकों के लिए रिडायरेक्ट को पूरी तरह से हटा देता है।

  • Passpoint हॉटस्पॉट 2.0 विनिर्देशों पर निर्मित उद्योग प्रमाणन है। यह किसी डिवाइस को सहेजे गए प्रोफ़ाइल का उपयोग करके नेटवर्क में स्वचालित रूप से शामिल होने की अनुमति देता है।
  • OpenRoaming, जिसे वायरलेस ब्रॉडबैंड अलायंस द्वारा संचालित किया जाता है, पहचान प्रदाताओं को एकीकृत करता है। विज़िटर के मौजूदा क्रेडेंशियल फिर भाग लेने वाले स्थलों में काम करते हैं।

दोनों IEEE 802.1X का उपयोग करते हैं, जो पोर्ट-आधारित नेटवर्क एक्सेस नियंत्रण का मानक है, इसलिए इसमें खराब होने वाला कोई पोर्टल नहीं होता है।

पहुंच विधि पहली विज़िट वापस आने पर विज़िट ओवर-द-एयर एन्क्रिप्शन मुख्य विफलता बिंदु उपयुक्त किसके लिए
कैप्टिव पोर्टल के साथ ओपन SSID विज़िटर लॉगिन पेज पूरा करता है सत्र या MAC कैश समाप्त होने पर फिर से साइन इन करता है कोई नहीं, जब तक कि SSID एन्हांस्ड ओपन (OWE) का उपयोग न करे प्रोब्स, वॉल्ड गार्डन, DNS, RADIUS प्रत्येक विज़िट पर प्रथम-पक्ष डेटा कैप्चर करने वाले स्थल
साझा प्री-शेयर्ड की (PSK) विज़िटर पासवर्ड टाइप करता है स्वचालित WPA2 या WPA3-पर्सनल पासवर्ड शेयरिंग, विज़िटर की कोई पहचान नहीं बिना डेटा लक्ष्यों वाले छोटे कैफ़े
Passpoint या OpenRoaming विज़िटर प्रोफ़ाइल इंस्टॉल करता है या फ़ेडरेटेड पहचान का उपयोग करता है स्वचालित, कोई पोर्टल नहीं WPA2 या WPA3-Enterprise प्रोफ़ाइल प्रोविज़निंग, प्रमाणपत्र बार-बार आने वाले आगंतुकों वाले होटल, हवाई अड्डे, रेल और परिसर

Purple कहां उपयुक्त है

Purple Guest WiFi एक हार्डवेयर-अज्ञेयवादी क्लाउड ओवरले के रूप में चलता है, इसलिए आप नए हार्डवेयर के बिना, कॉन्फ़िगरेशन में रिडायरेक्ट त्रुटियों को ठीक कर सकते हैं। Purple 90 से अधिक देशों में 80,000+ से अधिक लाइव स्थलों को सेवाएं प्रदान करता है और प्रति वर्ष 500 मिलियन उपयोगकर्ताओं और लॉगिन का समर्थन करता है। प्लेटफ़ॉर्म 99.999% अपटाइम पर चलता है और ISO 27001, Cyber Essentials और B Corp प्रमाणित है। यह GDPR और CCPA के अनुरूप भी है।

जब कोई पोर्टल विफल होता है, तो उसका कारण लगभग हमेशा स्थानीय होता है: एक प्रोब नियम, एक वॉल्ड गार्डन प्रविष्टि, एक DHCP पूल या एक फ़ायरवॉल नियम।

विभिन्न उद्योगों में ये पैटर्न दोहराए जाते हैं:

  • होटल चेक-इन पिक के समय रीडायरेक्ट फ़ॉल्ट का अनुभव करते हैं।
  • रिटेल प्रॉपर्टीज़ पूरे परिसर में फ़ायरवॉल परिवर्तनों के बाद इन्हें महसूस करती हैं।
  • ट्रेन और स्टेशनों को DHCP दबाव का सामना करना पड़ता है क्योंकि यात्री लहरों में सवार होते हैं।
  • स्वास्थ्य सेवा साइटों को मरीज और आगंतुक WiFi की आवश्यकता होती है जो नैदानिक कर्मचारियों को सपोर्ट कॉल में खींचे बिना काम करे।

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

क्या Purple हमारे पास पहले से मौजूद एक्सेस पॉइंट्स के साथ काम करता है?

हाँ। Purple हार्डवेयर-अग्नोस्टिक है और Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet पर क्लाउड ओवरले के रूप में चलता है। आप अपने मौजूदा एक्सेस पॉइंट्स और कंट्रोलर रखते हैं। आप अपने गेस्ट SSID को Purple के कैप्टिव पोर्टल पर इंगित करते हैं, Purple की एकीकरण गाइड से वॉल्ड गार्डन प्रविष्टियाँ और RADIUS विवरण जोड़ते हैं, और फिर परीक्षण करते हैं। इसमें कुछ भी उखाड़ने और बदलने की आवश्यकता नहीं है।

क्या गेस्ट WiFi कनेक्टेड लेकिन नो इंटरनेट की समस्या को ठीक करने के लिए हमें नए हार्डवेयर की आवश्यकता है?

नहीं। लगभग हर मामले में खराबी कॉन्फ़िगरेशन की होती है: एक अवरुद्ध प्रोब, एक वॉल्ड गार्डन गैप, प्री-ऑथेंटिकेशन DNS, एक समाप्त हो चुका DHCP पूल या एक RADIUS फ़ायरवॉल नियम। आप पहले से चलाए जा रहे कंट्रोलर, फ़ायरवॉल या DHCP सर्वर पर इनमें से प्रत्येक को ठीक करते हैं। हार्डवेयर केवल तब समस्या बनता है जब एक्सेस पॉइंट डेंसिटी आपकी पिक डिवाइस संख्या को सेवा प्रदान नहीं कर सकती, जो एक साइट सर्वे दिखाएगा।

हमारे गेस्ट WiFi को Purple पर ले जाने के लिए क्या करना पड़ता है?

Purple पर जाना एक कॉन्फ़िगरेशन प्रोजेक्ट है, न कि कोई इंस्टालेशन प्रोजेक्ट। प्रत्येक कंट्रोलर पर, आप गेस्ट SSID को Purple के बाहरी पोर्टल पर सेट करते हैं और वॉल्ड गार्डन तथा RADIUS सेटिंग्स जोड़ते हैं। इसके बाद आप UDP 1812 और 1813 के लिए फ़ायरवॉल नियमों की पुष्टि करते हैं। इसके बाद, आप Purple में अपना लॉगिन पृष्ठ और सहमति विकल्प बनाते हैं और iOS, Android और Windows पर परीक्षण करते हैं। मल्टी-साइट प्रॉपर्टीज़ कंट्रोलर सेटिंग्स को टेम्पलेट कर सकती हैं।

क्या कैप्टिव पोर्टल GDPR के अनुकूल है?

हाँ, बशर्ते सहमति सूचित, विशिष्ट और स्वतंत्र रूप से दी गई हो। GDPR के लिए प्रत्येक उद्देश्य के लिए एक अलग सकारात्मक विकल्प की आवश्यकता होती है, जैसे कि मार्केटिंग ईमेल, और यह पहले से टिक किए गए बॉक्सों को खारिज करता है। Purple के सचेत-विकल्प ऑप्ट-इन प्रत्येक विकल्प को अलग से प्रस्तुत करते हैं। Purple ISO 27001 प्रमाणित है, Cyber Essentials रखता है और GDPR तथा CCPA के अनुकूल है। इससे आपके डेटा सुरक्षा अधिकारी को वे मानक मिलते हैं जिनके बारे में वे पूछेंगे।

क्या दोबारा आने वाले आगंतुक लॉगिन पृष्ठ को छोड़ सकते हैं?

हाँ। Passpoint और OpenRoaming किसी डिवाइस को संग्रहीत प्रोफ़ाइल या फ़ेडरेटेड पहचान का उपयोग करके स्वचालित रूप से जुड़ने की अनुमति देते हैं। दोनों WPA2 या WPA3-Enterprise एन्क्रिप्शन के साथ IEEE 802.1X ऑथेंटिकेशन का उपयोग करते हैं, इसलिए बार-बार आने पर विफल होने वाला कोई कैप्टिव पोर्टल रीडायरेक्ट नहीं होता है। कई स्थान दोनों चलाते हैं: पहली बार आने वाले आगंतुकों और डेटा कैप्चर के लिए एक कैप्टिव पोर्टल, और दोबारा आने वाले मेहमानों, यात्रियों और छात्रों के लिए OpenRoaming।

हमें कैसे पता चलेगा कि लॉगिन कब विफल होने लगे हैं?

स्थान के आधार पर लॉगिन वॉल्यूम देखें। Purple की WiFi एनालिटिक्स प्रत्येक साइट के लिए लॉगिन रिपोर्ट करती है, इसलिए किसी एक स्थान पर अचानक आई गिरावट उसके सामान्य पैटर्न और आपके अन्य स्थानों की तुलना में अलग दिखाई देती है। वह गिरावट आमतौर पर हाल ही में किए गए बदलाव के कारण हुई RADIUS, वॉल्ड गार्डन या DHCP खराबी का संकेत देती है। डैशबोर्ड में इसे पहचानना फ्रंट डेस्क की शिकायतों के IT तक पहुँचने का इंतज़ार करने से तेज़ है।

क्या हमें कैप्टिव पोर्टल का उपयोग करना चाहिए या साझा WiFi पासवर्ड का?

यदि आप फ़र्स्ट-पार्टी डेटा और सहमति चाहते हैं तो कैप्टिव पोर्टल का उपयोग करें, और साझा पासवर्ड का उपयोग केवल तभी करें जब आपको इनमें से किसी की भी आवश्यकता न हो। एक साझा प्री-शेयर की WPA2 या WPA3-पर्सनल के साथ ट्रैफ़िक को एन्क्रिप्ट करती है। हालाँकि, यह आपको इस बारे में कुछ नहीं बताती कि कौन कनेक्ट हुआ है, और पासवर्ड फैल जाता है। एक कैप्टिव पोर्टल सहमति प्राप्त फ़र्स्ट-पार्टी डेटा कैप्चर करता है, और Passpoint या OpenRoaming बार-बार आने वाले विज़िटर्स के लिए स्वचालित, एन्क्रिप्टेड एक्सेस जोड़ता है।

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

कैप्टिव पोर्टल

एक वेब पेज जिसे इंटरनेट एक्सेस देने से पहले एक गेटवे (कंट्रोलर, फ़ायरवॉल या एक्सेस पॉइंट) प्रदान करता है। ऑपरेटिंग सिस्टम एक प्लेन HTTP प्रोब भेजकर और HTTP 302 रीडायरेक्ट को पोर्टल की उपस्थिति के संकेत के रूप में मानकर इसका पता लगाते हैं।

यह वह लेयर है जो तब विफल होती है जब गेस्ट WiFi कनेक्टेड लेकिन नो इंटरनेट दिखाता है। आप गेस्ट SSID को बाहरी पोर्टल URL की ओर बिंदु करने और अनऑथेंटिकेटेड HTTP ट्रैफ़िक को उस पर रीडायरेक्ट करने के लिए कॉन्फ़िगर करते हैं।

ऑपरेटिंग सिस्टम प्रोब

एक प्लेन HTTP अनुरोध जो प्रत्येक प्लेटफॉर्म नेटवर्क से जुड़ने पर भेजता है: iOS और macOS के लिए captive.apple.com, Android के लिए connectivitycheck.gstatic.com/generate_204, Windows के लिए www.msftconnecttest.com/connecttest.txt और Firefox के लिए detectportal.firefox.com, जिनमें से प्रत्येक ऑनलाइन होने पर एक निश्चित उत्तर की उम्मीद करता है।

यदि प्री-ऑथेंटिकेशन ACL या DNS फ़िल्टर प्रोब को ड्रॉप कर देता है, तो डिवाइस यह तय करता है कि कोई इंटरनेट नहीं है और पोर्टल को कभी नहीं खोलता है। पोर्टल कभी न दिखाई देने का यह सबसे आम कारण है।

HSTS (HTTP स्ट्रिक्ट ट्रांसपोर्ट सिक्योरिटी)

RFC 6797 में परिभाषित, HSTS ब्राउज़र को केवल HTTPS के माध्यम से किसी डोमेन तक पहुँचने का निर्देश देता है। ब्राउज़र HSTS डोमेन की एक प्रीलोड सूची भेजते हैं और डिवाइस छोड़ने से पहले उनसे संबंधित अनुरोधों को अपग्रेड करते हैं।

एक गेटवे ऐसे सर्टिफिकेट के बिना किसी HTTPS अनुरोध को HSTS डोमेन पर रीडायरेक्ट नहीं कर सकता जो उसके पास नहीं है, इसलिए आगंतुक को एक कठिन सुरक्षा चेतावनी दिखाई देती है। केवल HTTP प्रोब्स को रीडायरेक्ट करें और कर्मचारियों को आगंतुकों को कभी भी google.com पर न भेजने के निर्देश दें।

वॉल्ड गार्डन

डोमेन और IP पतों की अनुमति सूची (allow list) जिस तक कोई डिवाइस पूर्व-प्रमाणीकरण (pre-authentication) स्थिति में पहुंच सकता है, जिसे गेटवे के पूर्व-प्रमाणीकरण एक्सेस कंट्रोल लिस्ट द्वारा लागू किया जाता है।

Microsoft Entra ID, Okta या Google Workspace जैसे पहचान प्रदाताओं, कंटेंट डिलीवरी नेटवर्क या Purple एंडपॉइंट के लिए छूटी हुई प्रविष्टियां आंशिक पेज लोड और अदृश्य सोशल लॉगिन विफलताओं का कारण बनती हैं।

RADIUS

रिमोट ऑथेंटिकेशन डायल-इन यूज़र सर्विस, जो UDP 1812 पर प्रमाणीकरण के लिए RFC 2865 में और UDP 1813 पर अकाउंटिंग के लिए RFC 2866 में परिभाषित है। सर्वर प्रत्येक Access-Request का उत्तर Access-Accept या Access-Reject के साथ देता है।

RADIUS आपके गेटवे तक लॉगिन निर्णय पहुंचाता है। एक बेमेल शेयर्ड सीक्रेट, UDP 1812 या 1813 को ब्लॉक करने वाला फ़ायरवॉल, या गलत सर्वर पता सफल लॉगिन के बाद भी आगंतुकों को ऑफ़लाइन रखता है।

अकाउंटिंग-रिक्वेस्ट (प्रारंभ)

RFC 2866 में परिभाषित एक RADIUS अकाउंटिंग संदेश, जो सत्र शुरू होने पर UDP 1813 पर भेजा जाता है, जिसमें Start की स्थिति प्रकार होती है।

लॉगिन के बाद नियंत्रक लॉग में इसकी उपस्थिति पुष्टि करती है कि गेटवे ने Access-Accept लागू किया है। लॉगिन के बाद कोई अकाउंटिंग रिकॉर्ड न होने का मतलब है कि RADIUS पाथ टूट गया है।

NCSI (नेटवर्क कनेक्टिविटी स्टेटस इंडिकेटर)

Windows कनेक्टिविटी जांच जो www.msftconnecttest.com पर एक HTTP जांच भेजती है और DNS जांच के रूप में dns.msftncsi.com को भी रिज़ॉल्व करती है, जिसमें Microsoft Connect Test टेक्स्ट की अपेक्षा की जाती है।

एक Windows लैपटॉप पूर्व-प्रमाणीकरण DNS खराब होने पर नो इंटरनेट की रिपोर्ट कर सकता है, भले ही HTTP काम कर रहा हो, और लॉगिन के बाद लगातार नो इंटरनेट दिखने का आमतौर पर मतलब है कि गेटवे अभी भी जांच (probe) को रीडायरेक्ट कर रहा है।

कैप्टिव पोर्टल API (DHCP विकल्प 114)

RFC 8910 में परिभाषित, DHCP विकल्प 114 नेटवर्क को सीधे डिवाइस पर अपने कैप्टिव पोर्टल URI का विज्ञापन करने की अनुमति देता है, ताकि डिवाइस किसी जांच को इंटरसेप्ट करने पर निर्भर न रहे।

हाल के iOS और macOS रिलीज़ इसका समर्थन करते हैं, जो रीडायरेक्शन पर निर्भरता और इसके साथ आने वाले विफलता के बिंदुओं को कम करता है।

प्राइवेट DNS (TLS पर DNS)

एक Android सेटिंग, जो किसी विशिष्ट होस्टनाम के सेट होने पर, साधारण DNS के बजाय पोर्ट 853 पर TLS पर एन्क्रिप्टेड DNS प्रश्न भेजती है। स्वचालित मोड में यह साधारण DNS पर वापस आ जाती है।

कड़े प्राइवेट DNS होस्टनाम वाले आगंतुकों को प्राइवेट DNS सर्वर तक नहीं पहुंचा जा सकता संदेश दिखाई देता है। आप या तो प्रमाणीकरण से पहले पोर्ट 853 की अनुमति देते हैं या आगंतुक से स्वचालित पर स्विच करने के लिए कहते हैं।

Passpoint और OpenRoaming

Passpoint सहेजे गए प्रोफ़ाइल के साथ स्वचालित नेटवर्क जुड़ाव के लिए Hotspot 2.0 विनिर्देश पर निर्मित उद्योग प्रमाणन है। Wireless Broadband Alliance द्वारा संचालित OpenRoaming, पहचान प्रदाताओं को एकीकृत करता है। दोनों IEEE 802.1X पोर्ट-आधारित नेटवर्क एक्सेस कंट्रोल और WPA2 या WPA3-Enterprise एन्क्रिप्शन के साथ प्रमाणित करते हैं।

वे बार-बार आने वाले आगंतुकों को पूरी तरह से कैप्टिव पोर्टल से हटा देते हैं, ताकि बार-बार आने पर कोई रीडायरेक्ट विफलता न हो, जबकि पोर्टल अभी भी पहली बार आने वालों और डेटा कैप्चर को संभालता है।

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

1,500 सीटों वाले एक सम्मेलन केंद्र ने आठ घंटे के DHCP लीज के साथ सिंगल /24 सबनेट पर उपस्थित लोगों का WiFi चलाया। सुबह के सत्र काम कर रहे थे, लेकिन दोपहर के भोजन के बाद नए आगंतुकों को कनेक्टेड, नो इंटरनेट दिखाई दिया और हेल्प डेस्क ने कंट्रोलर को दो बार रीस्टार्ट किया।

निदान के चरण 1 में पाया गया कि नए डिवाइसों में 169.254.x.x लिंक-लोकल पते थे, जो DHCP की ओर इशारा करता है, पोर्टल की ओर नहीं। एक /24 254 उपयोग योग्य पते प्रदान करता है, और आठ घंटे के लीज ने सुबह के हर पते को आरक्षित रखा, जिससे पूल खाली हो गया। टीम ने उपस्थित लोगों के VLAN को /21 पर स्थानांतरित कर दिया और लीज को घटाकर 30 मिनट कर दिया। उपयोग योग्य पते 254 से बढ़कर 2,046 हो गए, जो पिछली क्षमता से लगभग आठ गुना है, और जाने वाले उपस्थित लोगों के पते अब 30 मिनट के भीतर पूल में वापस आ जाते हैं। सुधार में एक चेंज विंडो लगी और कोई नया हार्डवेयर नहीं लगा।

एक लॉगिन पेज के रिडिजाइन के बाद, 200 कमरों वाले होटल में Android मेहमानों ने फ्रंट डेस्क पर शिकायत की। पोर्टल तो दिखाई दिया, लेकिन Google साइन-इन बटन ने कुछ नहीं किया।

IT मैनेजर ने एक iPhone, एक Android फोन और एक Windows लैपटॉप पर प्रवाह का परीक्षण किया। लैपटॉप पर ब्राउज़र डेवलपर टूल ने फ़ॉन्ट डिलीवरी नेटवर्क और Google के साइन-इन डोमेन के लिए अवरुद्ध अनुरोध दिखाए, जो दोनों रिडिजाइन द्वारा जोड़े गए थे। चूंकि पोर्टल स्वयं लोड हुआ था, इसलिए खराबी वॉल्ड गार्डन में थी, प्रोब रीडायरेक्ट में नहीं। टीम ने वॉल्ड गार्डन में दो डोमेन जोड़े। दो वॉल्ड गार्डन प्रविष्टियों के साथ और बिना किसी हार्डवेयर बदलाव के, पहले ही पुन: परीक्षण पर तीनों परीक्षण उपकरणों पर Google साइन-इन पूरा हो गया।

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

निदान के चरण 5 में कंट्रोलर RADIUS लॉग की जाँच की गई और रिफ्रेश किए गए स्टोरों से कोई अकाउंटिंग रिकॉर्ड नहीं मिला, जिसका अर्थ है कि गेटवे को कभी भी Access-Accept प्राप्त नहीं हुआ। नए फ़ायरवॉल टेम्पलेट ने डिफ़ॉल्ट रूप से आउटबाउंड UDP को अस्वीकार कर दिया, जिससे पोर्ट 1812 और 1813 अवरुद्ध हो गए। टीम ने टेम्पलेट में स्पष्ट आउटबाउंड नियम जोड़े और इसे सभी 40 स्टोरों में पुश कर दिया, और हर स्टोर से अकाउंटिंग रिकॉर्ड फिर से दिखाई देने लगे। चूंकि केवल रिफ्रेश किए गए स्टोर ही विफल रहे थे, इसलिए पैटर्न सीधे फ़ायरवॉल टेम्पलेट की ओर इशारा कर रहा था न कि WiFi की ओर।

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

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.

स्रोत

  1. RFC 6797: HTTP Strict Transport Security (HSTS)
  2. RFC 2865: Remote Authentication Dial In User Service (RADIUS)
  3. RFC 2866: RADIUS Accounting
  4. RFC 8910: Captive-Portal Identification in DHCP and Router Advertisements
  5. Wireless Broadband Alliance: OpenRoaming
  6. Regulation (EU) 2016/679 (GDPR)
  7. PCI Security Standards Council: PCI DSS

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

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 मिनट का कॉल बुक करें और हम आपको दिखाएंगे कि आपके जैसे अन्य लोगों ने इसे कैसे हल किया।