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

कॅप्टिव्ह पोर्टल रिडायरेक्ट्सचे ट्रबलशूटिंग: गेस्ट WiFi कनेक्शनच्या समस्यांचे निवारण करणे

अ‍ॉड्रेसिंग, DNS, प्रोब रिडायरेक्ट, वॉल्ड गार्डन आणि RADIUS या स्टॅकवर काम करून गेस्ट WiFi कनेक्टेड दाखवूनही इंटरनेट का चालत नाही याचे निदान तुम्ही करू शकाल. त्यानंतर तुम्ही लक्षणांची त्यांच्या कारणांशी सांगड घालू शकता, तुमच्याकडे आधीपासून असलेल्या हार्डवेअरवरील कॉन्फिगरेशनमध्ये ती दुरुस्त करू शकता आणि त्रुटी पुन्हा उद्भवण्यापासून रोखणारे चेंज कंट्रोल्स तयार करू शकता.

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

Video overview

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

पॉडकास्ट ट्रान्सक्रिप्ट पहा
होस्ट (UK इंग्लिश, आत्मविश्वासी सल्लागाराचा सूर): Purple टेक्निकल ब्रीफिंगमध्ये आपले स्वागत आहे. आज आपण एंटरप्राइझ नेटवर्किंगमधील सर्वात कायमस्वरूपी डोकेदुखी असलेल्या एका समस्येवर उपाय शोधत आहोत: ती म्हणजे captive portal रीडायरेक्ट फेल्युअर. जेव्हा तुमचे गेस्ट WiFi कनेक्टेड असल्याचे दिसते परंतु तिथे इंटरनेट ॲक्सेस नसतो, तेव्हा तुमचे अभ्यागत त्रस्त होतात, तुमच्या हेल्पडेस्कवर तक्रारींचा पूर येतो आणि तुमची डेटा कॅप्चर धोरणे ठप्प होतात. या ब्रीफिंगमध्ये, आपण captive portals च्या तांत्रिक आर्किटेक्चरचे विश्लेषण करू, आधुनिक ऑपरेटिंग सिस्टीम्स आणि ब्राउझर अनेकदा त्यांना का ब्लॉक करतात हे शोधू आणि या समस्या कायमच्या सोडवण्यासाठी तुम्हाला ठोस अंमलबजावणी धोरणे देऊ. [विराम] चला परिस्थिती समजून घेऊया. तुम्ही शंभर रिटेल लोकेशन्सवर Cisco Meraki किंवा HPE Aruba ॲक्सेस पॉइंट्स तैनात केले आहेत. हार्डवेअर मजबूत आहे. परंतु गेस्ट तक्रार करतात की ते इंटरनेट ॲक्सेस करू शकत नाहीत. ते SSID निवडतात, त्यांच्या डिव्हाइसवर WiFi आयकॉन दिसतो, परंतु स्प्लॅश पेज कधीच लोड होत नाही. किंवा त्याहूनही वाईट म्हणजे, त्यांना एक भीतीदायक SSL सर्टिफिकेट एरर दिसते. असे का होते? हे ऑपरेटिंग सिस्टीम्स इंटरनेट कनेक्टिव्हिटी कशी शोधतात यावर अवलंबून असते. जेव्हा एखादे डिव्हाइस नेटवर्कशी कनेक्ट होते, तेव्हा ते एका ओळखीच्या URL वर HTTP प्रोब पाठवते. iOS साठी, ती captive.apple.com आहे. Android साठी, ती connectivitycheck.gstatic.com आहे. Windows msftconnecttest.com वापरते. डिव्हाइसला मानक HTTP 200 OK प्रतिसाद मिळाल्यास, ते थेट इंटरनेट ॲक्सेस असल्याचे गृहीत धरते. जर नेटवर्क गेटवेने त्या विनंतीमध्ये हस्तक्षेप केला आणि वेगळ्या URL वर HTTP 302 रीडायरेक्टसह उत्तर दिले, तर ऑपरेटिंग सिस्टीमला समजते की ते एका captive portal च्या मागे आहे. त्यानंतर ते स्प्लॅश पेज लोड करण्यासाठी एक स्यूडो-ब्राउझर उघडते. अपयश सहसा या हस्तक्षेपाच्या ठिकाणी (interception point) घडते. [विराम] अपयशाचा पहिला मुख्य मुद्दा म्हणजे नेटवर्क कनेक्टिव्हिटी स्टेटस इंडिकेटर प्रोब, किंवा NCSI. जर तुमच्या फायरवॉलने किंवा गेटवेने या अनइन्क्रिप्टेड HTTP विनंत्यांना ब्लॉक केले, तर ऑपरेटिंग सिस्टीमला 302 रीडायरेक्ट कधीच मिळत नाही. ते फक्त असे गृहीत धरते की नेटवर्क खराब आहे. हे दुरुस्त करण्यासाठी, तुम्ही हे सुनिश्चित केले पाहिजे की तुमच्या प्री-ऑथेंटिकेशन ॲक्सेस कंट्रोल लिस्ट्स त्या विशिष्ट OS डिटेक्शन URLs कडे जाणाऱ्या HTTP ट्रॅफिकला परवानगी देतात. दुसरी, आणि वाढती सामान्य समस्या म्हणजे HTTP स्ट्रिक्ट ट्रान्सपोर्ट सिक्युरिटी, किंवा HSTS. आधुनिक ब्राउझर प्रमुख डोमेन्ससाठी HTTPS ची सक्ती करतात. जर एखाद्या वापरकर्त्याने तुमच्या WiFi शी कनेक्ट केले आणि त्वरित google.com उघडण्याचा प्रयत्न केला, तर त्यांचा ब्राउझर एनक्रिप्टेड कनेक्शनचा आग्रह धरतो. जेव्हा तुमचा गेटवे त्या HTTPS विनंतीमध्ये हस्तक्षेप करतो आणि तिला captive portal वर रीडायरेक्ट करण्याचा प्रयत्न करतो, तेव्हा ब्राउझरला मॅन-इन-द-मिडल (man-in-the-middle) हल्ला झाल्याचे आढळते. तुमच्या गेटवेने सादर केलेले सर्टिफिकेट google.com शी जुळत नाही. याचा परिणाम थेट ब्लॉकिंगमध्ये होतो. वापरकर्त्याला सुरक्षेची चेतावणी दिसते आणि ते लॉगइन पेजवर पुढे जाऊ शकत नाहीत. यावर दोन प्रकारे उपाय आहे. पहिले म्हणजे, आपण आत्ताच चर्चा केलेल्या OS-स्तरीय डिटेक्शन मेकॅनिझम्सवर अवलंबून राहा. हे सर्टिफिकेट विसंगती टाळण्यासाठी विशेषतः अनइन्क्रिप्टेड HTTP वापरतात. दुसरे म्हणजे, तुमचे वॉल्ड गार्डन (walled garden) कॉन्फिगरेशन त्रुटीविरहित असल्याची खात्री करा. वॉल्ड गार्डन (walled garden) म्हणजे काय? ही अशा डोमेन्स आणि IP ॲड्रेसची सूची आहे ज्यांवर अतिथी प्रमाणीकरण (authenticate) करण्यापूर्वी प्रवेश करू शकतात. तुम्ही Microsoft Entra ID किंवा Google Workspace द्वारे सोशल लॉगिन वापरत असल्यास, किंवा Stripe द्वारे पेमेंट प्रक्रियेत असल्यास, ते डोमेन्स तुमच्या वॉल्ड गार्डनमध्ये असणे आवश्यक आहे. ते नसल्यास, स्प्लॅश पेज लोड होऊ शकते, परंतु प्रमाणीकरण प्रक्रिया कोणत्याही सूचनेशिवाय अपयशी ठरेल. [PAUSE] चला एका वास्तविक परिस्थितीवर नजर टाकूया. McDonald's हजारो ठिकाणांवर लाखो ग्राहकांना सेवा देते. ते त्यांचे अतिथी WiFi व्यवस्थापित करण्यासाठी Purple वापरतात. जर त्यांचा सेशन टाइमआउट खूप लहान सेट केला असेल, तर दुपारच्या जेवणादरम्यान बराच वेळ आपला फोन चेक करणाऱ्या ग्राहकाला वारंवार पुन्हा प्रमाणीकरण करावे लागू शकते. यामुळे अनुभव खराब होतो. आम्ही हॉस्पिटॅलिटी आणि रिटेल वातावरणासाठी सेशनचा कालावधी २४ तास सेट करण्याची शिफारस करतो, ज्यामुळे परत येणाऱ्या उपकरणांना अखंडपणे ओळखण्यासाठी MAC ॲड्रेस कॅशिंगचा वापर केला जाऊ शकतो. [PAUSE] आता अंमलबजावणीच्या शिफारसींबद्दल. कॅप्टिव्ह पोर्टल (captive portal) तैनात करताना, तुम्ही DNS आणि HTTP ट्रॅफिक अचूकपणे इंटरसेप्ट करण्यासाठी तुमचे गेटवे कॉन्फिगर केले पाहिजे. तुम्ही Purple सारखे क्लाउड ओव्हरले वापरत असल्यास, तुमचे स्थानिक हार्डवेअर, मग ते Juniper Mist असो वा Ubiquiti UniFi, Purple RADIUS सर्व्हरपर्यंत पोहोचण्यास सक्षम असले पाहिजे. येथे एक गंभीर चूक टाळावी लागेल: DNS रिझोल्यूशन. जर एखादे अतिथी उपकरण तुमच्या कॅप्टिव्ह पोर्टलच्या होस्टनेमचे निराकरण (resolve) करू शकत नसेल, तर रिडायरेक्ट अयशस्वी होते. तुमचा DHCP सर्व्हर विश्वासार्ह DNS ॲड्रेस देतो याची खात्री करा आणि तुमचे गेटवे वॉल्ड गार्डनमधून DNS क्वेरी पास होऊ देते की नाही हे तपासा. याव्यतिरिक्त, भौतिक वातावरणाचा विचार करा. स्टेडियम किंवा ट्रॅव्हल हब जसे की Manchester Airports Group सारख्या उच्च घनतेच्या ठिकाणी एकाच वेळी हजारो कनेक्शनचे प्रयत्न केले जातात. जर तुमचा स्थानिक DHCP पूल संपला, तर नवीन उपकरणे ॲक्सेस पॉइंटशी कनेक्ट होतील परंतु त्यांना IP ॲड्रेस मिळणार नाही. ते कधीही कॅप्टिव्ह पोर्टल टप्प्यापर्यंत पोहोचणार नाहीत. पीक क्षमतेसाठी तुमचे सबनेट नेहमी योग्य आकाराचे ठेवा आणि तात्पुरत्या अभ्यागत नेटवर्कसाठी लहान DHCP लीज वेळा वापरा. [PAUSE] आता सामान्य हेल्पडेस्क तिकिटांवर आधारित एक जलद प्रश्न आणि उत्तर सत्र घेऊया. प्रश्न १: पोर्टल आयफोनवर चालते पण Android उपकरणांवर का अयशस्वी होते? उत्तर: ही नक्कीच वॉल्ड गार्डनची समस्या आहे. तुम्ही बहुधा captive.apple.com ला व्हाईटलिस्ट केले आहे परंतु connectivitycheck.gstatic.com विसरला आहात. तुमची प्री-ऑथेंटिकेशन ॲक्सेस कंट्रोल लिस्ट अपडेट करा. प्रश्न २: अतिथी यशस्वीरित्या प्रमाणीकरण करतात, तरीही त्यांना इंटरनेट मिळत नाही. असे का? उत्तर: तुमचे RADIUS कॉन्फिगरेशन तपासा. गेटवेला बहुधा RADIUS सर्व्हरकडून Access-Accept मेसेज मिळत नाही, किंवा प्रमाणीकरणानंतरचे फायरवॉल नियम ट्रॅफिक ब्लॉक करत आहेत. सामायिक केलेले गुपिते (shared secret) सत्यापित करा आणि पोर्ट १८१२ आणि १८१३ उघडे असल्याचे सुनिश्चित करा. प्रश्न ३: सुरक्षिततेच्या चेतावणी टाळण्यासाठी आम्ही सुरुवातीच्या रिडायरेक्टसाठी HTTPS वापरू शकतो का? उत्तर: नाही. प्रत्येक अतिथी उपकरणावर रूट प्रमाणपत्र स्थापित केल्याशिवाय तुम्ही प्रमाणपत्र त्रुटी (certificate error) न आणता HTTPS विनंती इंटरसेप्ट करू शकत नाही, जे सार्वजनिक WiFi साठी अशक्य आहे. पोर्टल ट्रिगर करण्यासाठी तुम्हाला अनइन्क्रिप्टेड HTTP OS प्रोब्सवरच अवलंबून राहावे लागेल. [PAUSE] थोडक्यात सांगायचे तर: Captive Portal मधील त्रुटी या क्वचितच हार्डवेअरच्या बिघाडामुळे असतात. त्या बहुतांश वेळा रिडायरेक्ट फ्लो, वॉल्ड गार्डन (walled garden) किंवा DNS सेटिंग्जमधील विसंगत कॉन्फिगरेशनमुळे असतात. पॉइंट एक: प्रमाणीकरणापूर्वी (authentication) OS डिटेक्शन URLs ॲक्सेस करण्यायोग्य असल्याची खात्री करा. पॉइंट दोन: सर्व आवश्यक आयडेंटिटी प्रोव्हाइडर्स आणि कंटेंट डिलिव्हरी नेटवर्क्सचा समावेश करण्यासाठी तुमचे वॉल्ड गार्डन (walled garden) कॉन्फिगर करा. पॉइंट तीन: तुमचे गेटवे आणि तुमचे प्रमाणीकरण प्लॅटफॉर्म यामधील RADIUS संप्रेषण सत्यापित करा. पॉइंट चार: पीक डेन्सिटी लक्षात घेऊन तुमचे DHCP स्कोप्स निश्चित करा. या घटकांवर प्रभुत्व मिळवून, तुम्ही कनेक्शनमधील अडथळे दूर करता. तुम्ही तुमच्या पाहुण्यांना निराश करणे थांबवता आणि लॉयल्टी तसेच महसूल वाढवण्यासाठी आवश्यक असलेला फर्स्ट-पार्टी डेटा गोळा करण्यास सुरुवात करता. Purple चे आयडेंटिटी-बेस्ड नेटवर्क ही प्रक्रिया सोपी करतात, एक हार्डवेअर-अग्नॉस्टिक क्लाउड ओव्हरले प्रदान करतात जे जगभरातील ८०,००० पेक्षा जास्त लाइव्ह वेन्यूजवर 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 देखील रीझॉल्व्ह करते. त्यामुळे, HTTP कार्यरत असले तरीही, प्री-ऑथेंटिकेशन DNS खराब असल्यास Windows लॅपटॉप 'इंटरनेट नाही' असा रिपोर्ट देऊ शकतो.

कॅप्टिव्ह पोर्टल रिडायरेक्ट सहसा का अयशस्वी होते?

बहुतांश प्रकरणांसाठी सात कारणे जबाबदार असतात. ती ॲड्रेसिंगपासून ऑथेंटिकेशनपर्यंतच्या वेगवेगळ्या स्तरांवर असतात.

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

गेटवेची प्री-ऑथेंटिकेशन ॲक्सेस कंट्रोल लिस्ट (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 च्या इंटिग्रेशन मार्गदर्शकामध्ये सूचीबद्ध केलेले Purple चे कॅप्टिव्ह पोर्टल आणि RADIUS एंडपॉइंट्स.

ऑथेंटिकेशनपूर्वी DNS अयशस्वी होते

पेज लोड करण्यापूर्वी डिव्हाइसने पोर्टल होस्टनेम रिझॉल्व्ह करणे आवश्यक आहे. दोन प्रकरणांमध्ये रीडायरेक्ट कुठेही होत नाही:

  • गेटवे प्री-ऑथेंटिकेशन स्थितीत DNS ब्लॉक करतो.
  • DHCP असे DNS सर्व्हर प्रदान करतो जिथपर्यंत डिव्हाइस पोहोचू शकत नाही.

Android यामध्ये एक वेगळी अडचण निर्माण करतो. व्हिजिटरने विशिष्ट प्रायव्हेट DNS होस्टनेम सेट केले असल्यास, Android पोर्ट 853 वर TLS द्वारे DNS ची अपेक्षा करतो. ऑटोमॅटिक मोडमध्ये तो सामान्य DNS वर परत येतो.

DHCP पूल समाप्त झाला आहे

ॲड्रेस पूल संपल्यावर, नवीन डिव्हाइस ॲक्सेस पॉइंटशी कनेक्ट होते परंतु त्याला IP ॲड्रेस मिळत नाही. Windows नंतर स्वतःला 169.254.x.x लिंक-लोकल ॲड्रेस असाइन करते, आणि इतर सिस्टीम तत्सम सेल्फ-असाइन स्थिती दाखवतात.

वैध ॲड्रेस नसल्यामुळे, डिव्हाइस प्रोब पाठवू शकत नाही. ते कनेक्ट केलेले दिसते परंतु तेथे इंटरनेट नसते. स्टेडियम, कॉन्फरन्स सेंटर्स आणि ट्रान्सपोर्ट हबमध्ये पीक-टाइमदरम्यान होणारा हा क्लासिक बिघाड आहे.

RADIUS कडून ॲक्सेस-ॲसेप्ट डिलिव्हर होत नाही

RADIUS (रिमोट ऑथेंटिकेशन डायल-इन युझर सर्व्हिस) ऑथेंटिकेशन सर्व्हरकडून तुमच्या गेटवेकडे लॉगिनचा निर्णय घेऊन जातो. सर्व्हर RFC 2865 मध्ये परिभाषित केल्यानुसार ॲक्सेस-ॲसेप्ट किंवा ॲक्सेस-रिजेक्ट असा प्रतिसाद देतो. त्यानंतर गेटवे ॲक्सेस सुरू करतो किंवा तो बंद ठेवतो.एखादा भेट देणारा फॉर्म पूर्ण करतो परंतु ऑफलाइनच राहतो, याचा अर्थ सहसा गेटवेने Access-Accept मिस केले आहे. याची तीन सामान्य कारणे पुढीलप्रमाणे आहेत:

  • अनमिल्ता (mismatched) सामायिक गुप्त कोड (shared secret).
  • UDP 1812 (ऑथेंटिकेशन) किंवा UDP 1813 (अकाउंटिंग) ला अवरोधित करणारा फायरवॉल. RFC 2865 आणि RFC 2866 हे पोर्ट परिभाषित करतात.
  • कंट्रोलरवरील चुकीचा सर्व्हर पत्ता.

पोर्टलचे स्वतःचे प्रमाणपत्र कालबाह्य झाले आहे

तुमचे लॉगिन पृष्ठ HTTPS द्वारे प्रदान केले जाते. जर त्याचे TLS प्रमाणपत्र कालबाह्य झाले, तर प्रत्येक आधुनिक ब्राउझर सुरक्षा इशारा देऊन ते पृष्ठ अवरोधित करतो. रिडायरेक्ट पूर्णपणे कार्य करते, तरीही भेट देणारा साइन इन करू शकत नाही.

तुमचे कोणते कारण आहे हे तुम्ही कसे शोधाल?

क्रमाने स्टॅकवर काम करा. प्रत्येक तपासणी एक स्तर वगळते, त्यामुळे पहिल्या अपयशावरच थांबा.

  1. डिव्हाइसकडे वैध IP पत्ता आहे का? Windows वर ipconfig /all चालवा, किंवा फोनवर नेटवर्क तपशील तपासा. 169.254.x.x पत्ता, किंवा कोणताही पत्ता नसणे, हे DHCP कडे निर्देश करते. DHCP सर्व्हरवर पूल वापर (pool utilisation) तपासा. 90% च्या वर असल्यास, तुम्ही ते संपण्याच्या जवळ आहात.
  2. DNS रिझॉल्व्ह होते का? गेस्ट व्हर्च्युअल LAN (VLAN) वरील, तार्किकदृष्ट्या स्वतंत्र नेटवर्क विभागातील डिव्हाइसवरून, पोर्टल होस्टनेम शोधा. शोध अयशस्वी झाल्यास, प्री-ऑथेंटिकेशन DNS अवरोधित केले आहे किंवा DHCP-नियुक्त सर्व्हर चुकीचा आहे.
  3. प्रोबला 302 मिळतो का? गेस्ट VLAN वर पॅकेट कॅप्चर करा, किंवा HTTP प्रोब URL पैकी एकावर ब्राउझ करा. तुम्हाला प्रोब दिसला पाहिजे, आणि त्यानंतर पोर्टलकडे निर्देश करणारा HTTP 302 दिसला पाहिजे. उत्तर न मिळणारा प्रोब म्हणजे ACL तो ड्रॉप करत आहे. कोणताही प्रोब न दिसणे म्हणजे डिव्हाइसला ते आधीपासूनच ऑनलाइन आहे असे वाटते, जे सहसा कॅश केलेल्या स्थितीमुळे होते. नेटवर्क विसरून जा (Forget the network) आणि पुन्हा कनेक्ट व्हा.
  4. लॉगिन पृष्ठ पूर्णपणे लोड होते का? ब्राउझर डेव्हलपर टूल्स (F12) उघडा आणि नेटवर्क टॅबचे निरीक्षण करा. थर्ड-पार्टी डोमेनसाठी अवरोधित केलेल्या विनंत्या वॉल्ड गार्डन गॅप्सकडे (walled garden gaps) निर्देश करतात.
  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 पाहुण्यांकडून फ्रंट डेस्कवर तक्रारी प्राप्त झाल्या. त्यापैकी बहुतेकांनी Google साइन-इन पर्याय निवडला. पोर्टल दिसले, परंतु बटणाने काहीही केले नाही.

काय करण्यात आले. IT व्यवस्थापकाने एका iPhone, एका Android फोन आणि एका Windows लॅपटॉपवर प्रवाहाची चाचणी केली. लॅपटॉपवरील डेव्हलपर टूल्सने फॉन्ट डिलिव्हरी नेटवर्क आणि Google च्या साइन-इन डोमेन्सना ब्लॉक केलेल्या विनंत्या दाखवल्या. रीडिझाइनमध्ये हे दोन्ही जोडले गेले होते. टीमने त्यांना वॉल्ड गार्डनमध्ये जोडले.

निकाल. पहिल्या रीटेस्टवर तिन्ही टेस्ट उपकरणांवर Google साइन-इन पूर्ण झाले. या उपायासाठी दोन वॉल्ड गार्डन नोंदी लागल्या आणि कोणताही हार्डवेअर बदल करावा लागला नाही.

यशस्वी परिस्थिती: फायरवॉल रिफ्रेश नंतर 40 दुकानांची रिटेल इस्टेट

परिस्थिती. एका रिटेल विक्रेत्याने वीकेंडला 40 दुकानांमधील फायरवॉल बदलल्या. सोमवारी, प्रत्येक रिफ्रेश केलेल्या दुकानातील ग्राहक लॉगिन फॉर्म पूर्ण करू शकत होते परंतु ऑफलाइनच राहिले. अद्याप रिफ्रेश न झालेली दुकाने सामान्यपणे कार्यरत होती.

काय करण्यात आले. पायरी 5 मध्ये रिफ्रेश केलेल्या दुकानांमधून कोणतेही अकाउंटिंग रेकॉर्ड आढळले नाहीत. नवीन फायरवॉल टेम्पलेटने डीफॉल्टनुसार आउटबाउंड UDP नाकारले, ज्यामुळे 1812 आणि 1813 ब्लॉक झाले. टीमने टेम्पलेटमध्ये स्पष्ट आउटबाउंड नियम जोडले आणि ते सर्व 40 दुकानांमध्ये पुश केले.

निकाल. पुश केल्यानंतर प्रत्येक दुकानातून अकाउंटिंग रेकॉर्ड पुन्हा दिसू लागले. केवळ रिफ्रेश केलेली दुकाने अपयशी ठरल्यामुळे, पॅटर्नने थेट टेम्पलेटकडे निर्देश केला आणि WiFi कडून लक्ष हटवले.

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

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

आपण प्रत्येक ऑपरेटिंग सिस्टम आणि कंट्रोलरवर हे कसे दुरुस्त करता?

कंट्रोलर फिक्स प्रत्येक प्लॅटफॉर्मवर एकाच पॅटर्नचे अनुसरण करतो. ऑपरेटिंग सिस्टम फिक्स मुख्यत्वे प्रत्येक सिस्टम कशी वर्तन करते हे जाणून घेण्याबद्दल असतात.

तुमच्या कंट्रोलरवर

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 वर

कॅप्टिव्ह नेटवर्क असिस्टंट उघडत नसल्यास, Settings मध्ये नेटवर्क फॉरगेट करा आणि पुन्हा जॉईन व्हा. यामुळे एक नवीन प्रोब फोर्स होतो.

अलीकडील iOS आणि macOS रिलीजेस कॅप्टिव्ह पोर्टल API ला देखील सपोर्ट करतात. हे RFC 8910 मध्ये परिभाषित केलेल्या DHCP पर्याय 114 द्वारे नेटवर्कला त्याचे पोर्टल जाहिरात करण्याची अनुमती देते, ज्यामुळे इंटरसेप्शनवरील अवलंबित्व कमी होते. असिस्टंट उघडल्यास परंतु ब्लँक राहिल्यास, ॲसेट डोमेन्ससाठी वॉल्ड गार्डन तपासा.

Android वर

Android जेव्हा पोर्टल डिटेक्ट करते तेव्हा "Sign in to network" सूचना दाखवते. सूचना कधीही न दिसल्यास, गेटवे connectivitycheck.gstatic.com ला ड्रॉप करण्याऐवजी रिडायरेक्ट करतो याची पुष्टी करा.

व्हिजिटरला "Private DNS server cannot be accessed" दिसल्यास, त्यांच्या फोनमध्ये एक स्ट्रिक्ट प्रायव्हेट DNS होस्टनेम सेट केलेले असते. तुमच्याकडे दोन पर्याय आहेत:

  • ऑथेंटिकेशनपूर्वी पोर्ट 853 वर DNS over TLS ला अनुमती द्या.
  • व्हिजिटरला प्रायव्हेट 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 मिनिटांचे लीझ चालतात.
  • भेटीनुसार सत्रे (sessions) सेट करा. हॉस्पिटॅलिटी आणि रिटेल ठिकाणे सामान्यतः 24-तासांची सत्रे सेट करतात, जेणेकरून भेट देणारी व्यक्ती प्रत्येक मुक्कामासाठी किंवा भेटीसाठी एकदाच साइन इन करेल.
  • दररोज लॉगिन प्रमाणावर लक्ष ठेवा. Purple चे WiFi Analytics ठिकाणानुसार (venue) लॉगिनची नोंद ठेवते. एका साइटवर अचानक आलेली घट तुम्हाला भेट देणाऱ्यांनी तक्रार करण्यापूर्वीच RADIUS किंवा वॉल्ड गार्डन त्रुटीची पूर्वसूचना देते.
  • प्रमाणपत्रे आणि सामायिक रहस्ये (shared secrets) बदल नियंत्रणाखाली ठेवा. पोर्टल प्रमाणपत्राच्या समाप्तीची तारीख नोंदवून ठेवा. RADIUS सामायिक रहस्य अशा ठिकाणी स्टोअर करा जिथे फायरवॉल आणि कंट्रोलर टीम्स दोन्ही तपासू शकतील.
  • गेस्ट ट्रॅफिक विभक्त (segment) करा. पाहुण्यांना (guests) त्यांच्या स्वतःच्या VLAN वर ठेवा. PCI DSS सेगमेंटेशनला तुमच्या कार्डधारक डेटा वातावरणाच्या कक्षेबाहेर गेस्ट नेटवर्क ठेवण्याचा मार्ग मानतो.
  • MAC रँडमायझेशनचे नियोजन करा. अलीकडील iOS आणि Android आवृत्त्या प्रत्येक नेटवर्कसाठी रँडम MAC ॲड्रेस वापरतात आणि काही मोड्स वेळेनुसार ते फिरवतात. MAC ॲड्रेसवर आधारित सत्र कॅशिंग नंतर परत येणाऱ्या भेट देणाऱ्यांना पुन्हा साइन इन करण्यास सांगेल.
  • योग्यरित्या संमती गोळा करा. मार्केटिंग डेटासाठी GDPR ला माहितीपूर्ण, होकारार्थी संमती आवश्यक आहे. Purple चे कॉन्शस-चॉइस ऑप्ट-इन्स प्रत्येक उद्देशासाठी स्वतंत्र पर्याय सादर करतात.

परत येणाऱ्या भेट देणाऱ्यांना कॅप्टिव्ह पोर्टलवरून काढून टाका

सर्वात टिकाऊ उपाय म्हणजे पुन्हा भेट देणाऱ्यांसाठीचे रीडायरेक्ट पूर्णपणे काढून टाकणे.

  • Passpoint हे हॉटस्पॉट 2.0 तपशीलावर तयार केलेले उद्योग प्रमाणपत्र आहे. हे डिव्हाइसला स्टोअर केलेल्या प्रोफाइलचा वापर करून आपोआप नेटवर्कमध्ये सामील होऊ देते.
  • OpenRoaming, वायरलेस ब्रॉडबँड अलायन्सद्वारे संचलित, ओळख पुरवठादारांना (identity providers) एकत्र करते. भेट देणाऱ्याची विद्यमान क्रेडेन्शियल्स नंतर सहभागी ठिकाणांवर कार्य करतात.

दोन्ही IEEE 802.1X वापरतात, जो पोर्ट-आधारित नेटवर्क ॲक्सेस कंट्रोलसाठीचा मानक आहे, त्यामुळे खंडित होण्यासाठी कोणतेही पोर्टल नसते.

ॲक्सेस पद्धत पहिली भेट परत येणारी भेट ओव्हर-द-एयर एन्क्रिप्शन मुख्य त्रुटी बिंदू योग्य
कॅप्टिव्ह पोर्टलसह ओपन SSID भेट देणारी व्यक्ती लॉगिन पृष्ठ पूर्ण करते सत्र किंवा MAC कॅश संपल्यावर पुन्हा साइन इन करते काहीही नाही, जर SSID एन्हॅन्स्ड ओपन (OWE) वापरत नसेल प्रोब्स, वॉल्ड गार्डन, DNS, RADIUS प्रत्येक भेटीत फर्स्ट-पार्टी डेटा कॅप्चर करणारी ठिकाणे
सामायिक प्री-शेअर्ड की (PSK) भेट देणारी व्यक्ती पासवर्ड टाइप करते स्वयंचलित WPA2 किंवा WPA3-Personal पासवर्ड शेअरिंग, कोणतीही भेट देणाऱ्याची ओळख नाही डेटाची उद्दिष्टे नसलेली छोटी कॅफे
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 हे हार्डवेअर-स्वतंत्र (hardware-agnostic) आहे आणि Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet वर क्लाउड ओव्हरले म्हणून चालते. तुम्ही तुमचे विद्यमान ॲक्सेस पॉइंट्स आणि कंट्रोलर्स वापरणे सुरू ठेवू शकता. तुम्ही तुमचे गेस्ट SSID हे Purple च्या कॅप्टिव्ह पोर्टलवर निर्देशित करता, Purple च्या इंटिग्रेशन मार्गदर्शक तत्त्वांमधून वॉल्ड गार्डन एंट्रीज आणि RADIUS तपशील जोडता आणि नंतर चाचणी करता. यात जुने सिस्टीम काढून नवीन बसवण्याची (rip and replace) गरज नसते.

गेस्ट 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-Personal द्वारे ट्रॅफिक एनक्रिप्ट करते. तथापि, त्यावरून कोण कनेक्ट झाले आहे याबद्दल काहीही माहिती मिळत नाही आणि पासवर्ड पसरत जातो. कॅप्टिव्ह पोर्टल संमती असलेला फर्स्ट-पार्टी डेटा गोळा करते, आणि Passpoint किंवा OpenRoaming वारंवार देणाऱ्या भेटींसाठी स्वयंचलित, एनक्रिप्टेड ॲक्सेस जोडते.

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

कॅप्टिव्ह पोर्टल

इंटरनेट अ‍ॅक्सेस देण्यापूर्वी गेटवे (कंट्रोलर, फायरवॉल किंवा अ‍ॅक्सेस पॉइंट) दाखवत असलेले एक वेब पेज. ऑपरेटिंग सिस्टीम प्लेन HTTP प्रोब पाठवून आणि HTTP 302 रिडायरेक्टला पोर्टल उपस्थित असल्याचे चिन्ह मानून ते ओळखतात.

गेस्ट WiFi कनेक्टेड पण नो इंटरनेट दाखवते तेव्हा हा लेयर अपयशी ठरतो. तुम्ही एक्सटर्नल पोर्टल URL कडे निर्देश करण्यासाठी आणि ऑथेंटिकेट न केलेल्या HTTP ट्रॅफिकला त्यावर रिडायरेक्ट करण्यासाठी गेस्ट SSID कॉन्फिगर करता.

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

प्रत्येक प्लॅटफॉर्म नेटवर्कमध्ये सामील होताना पाठवणारी एक प्लेन 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 डोमेन्सची प्रीलोड सूची पाठवतात आणि त्यावरील विनंत्या डिव्हाइस सोडण्यापूर्वी अपग्रेड करतात.

गेटवेकडे प्रमाणपत्र असल्याशिवाय तो HSTS डोमेनवरील HTTPS विनंती रिडायरेक्ट करू शकत नाही, त्यामुळे व्हिजिटरला गंभीर सुरक्षा चेतावणी दिसते. फक्त HTTP प्रोब्स रिडायरेक्ट करा आणि कर्मचाऱ्यांना व्हिजिटर्सना google.com वर न पाठवण्याच्या स्पष्ट सूचना द्या.

वॉल्ड गार्डन

गेटवेच्या प्री-ऑथेंटिकेशन ॲक्सेस कंट्रोल लिस्टद्वारे लागू केलेली, डिव्हाइस प्री-ऑथेंटिकेशन स्थितीत असताना ज्या डोमेन्स आणि IP ॲड्रेसेसपर्यंत पोहोचू शकते त्यांची ॲलो लिस्ट (allow list).

Microsoft Entra ID, Okta किंवा Google Workspace यांसारख्या आयडेंटिटी प्रदात्यांच्या, कंटेंट डिलिव्हरी नेटवर्क्सच्या किंवा Purple एंडपॉइंट्सच्या नोंदी नसल्यास पेज अंशतः लोड होते आणि सोशल लॉगिनच्या प्रक्रियेत कोणतीही सूचना न मिळता अपयश येते.

RADIUS

रिमोट ऑथेंटिकेशन डायल-इन युझर सर्व्हिस, जी ऑथेंटिकेशनसाठी UDP 1812 वर RFC 2865 मध्ये आणि अकाउंटिंगसाठी UDP 1813 वर RFC 2866 मध्ये परिभाषित केली आहे. सर्व्हर प्रत्येक ॲक्सेस-रिक्वेस्टला ॲक्सेस-ॲक्सेप्ट किंवा ॲक्सेस-रिजेक्टद्वारे उत्तर देतो.

RADIUS लॉगिनचा निर्णय तुमच्या गेटवेकडे पाठवतो. विसंगत शेअर केलेले गुपित (shared secret), UDP 1812 किंवा 1813 ला ब्लॉक करणारी फायरवॉल किंवा चुकीचा सर्व्हर ॲड्रेस असल्यास यशस्वी लॉगिननंतरही भेट देणारे ऑफलाइनच राहतात.

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

RFC 2866 मध्ये परिभाषित केलेला RADIUS अकाउंटिंग मेसेज, जो सेशन सुरू झाल्यावर UDP 1813 वर पाठवला जातो आणि यात 'स्टार्ट' प्रकारची स्थिती असते.

लॉगिननंतर कंट्रोलर लॉग्जमध्ये याची उपस्थिती गेटवेने ॲक्सेस-ॲक्सेप्ट लागू केल्याची पुष्टी करते. लॉगिननंतर अकाउंटिंग रेकॉर्ड नसल्यास याचा अर्थ RADIUS पाथ खंडित झाला आहे.

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

Windows ची कनेक्टिव्हिटी तपासणी जी www.msftconnecttest.com वर HTTP प्रोब पाठवते आणि Microsoft Connect Test या मजकुराची अपेक्षा ठेवून DNS तपासणी म्हणून dns.msftncsi.com देखील रिझॉल्व्ह करते.

प्री-ऑथेंटिकेशन DNS खराब असल्यास HTTP कार्य करत असले तरीही Windows लॅपटॉप 'इंटरनेट नाही' असा अहवाल देऊ शकतो, आणि लॉगिननंतर सतत 'इंटरनेट नाही' दाखवण्याचा अर्थ सहसा असा होतो की गेटवे अजूनही प्रोब रिडायरेक्ट करत आहे.

कॅप्टिव्ह पोर्टल API (DHCP पर्याय 114)

RFC 8910 मध्ये परिभाषित केलेला, DHCP पर्याय 114 नेटवर्कला त्याचा कॅप्टिव्ह पोर्टल URI थेट डिव्हाइसला ॲडव्हर्टाइज करण्याची अनुमती देतो, जेणेकरून डिव्हाइस प्रोब इंटरसेप्ट करण्यावर अवलंबून राहत नाही.

नुकत्याच आलेल्या iOS आणि macOS रिलीजमध्ये याचे समर्थन उपलब्ध आहे, ज्यामुळे रिडायरेक्शनवरील आणि त्यासोबत येणाऱ्या त्रुटीच्या मुद्द्यांवरील अवलंबित्व कमी होते.

प्रायव्हेट DNS (DNS ओव्हर TLS)

एक Android सेटिंग जी, एखादे विशिष्ट होस्टनेम सेट केलेले असताना, सामान्य DNS ऐवजी पोर्ट 853 वर TLS द्वारे एनक्रिप्ट केलेले DNS क्वेरीज पाठवते. ऑटोमॅटिक मोडमध्ये ते सामान्य DNS वर परत येते.

सक्तीचा प्रायव्हेट DNS होस्टनेम असलेल्या भेट देणाऱ्यांना 'प्रायव्हेट DNS सर्व्हरवर ॲक्सेस करता येत नाही' असे दिसते. तुम्ही एकतर ऑथेंटिकेशनपूर्वी पोर्ट 853 ला अनुमती द्या किंवा भेट देणाऱ्याला ते ऑटोमॅटिकवर स्विच करण्यास सांगा.

Passpoint आणि OpenRoaming

Passpoint हे स्टोअर केलेल्या प्रोफाईलसह स्वयंचलित नेटवर्क जॉइनिंगसाठी हॉटस्पॉट 2.0 तपशीलावर तयार केलेले उद्योग प्रमाणपत्र आहे. वायरलेस ब्रॉडबँड अलायन्सद्वारे संचलित 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 मिनिटांपर्यंत कमी करणे (बाहेर पडलेल्या डिव्हाइसेसकडून जलद रीतीने ॲड्रेसेस पुन्हा मिळवणे) आणि शक्य असल्यास, दुसरे सबनेट जोडून पूलचा विस्तार करणे. दीर्घकालीन उपाय म्हणजे पुढील कार्यक्रमात सरासरीऐवजी कमाल समवर्ती (concurrent) डिव्हाइस संख्येनुसार DHCP पूलचा आकार ठरवणे.

Q2. तुम्ही एका रिटेल साखळीवरील Ubiquiti UniFi ॲक्सेस पॉईंट्सवर Purple तैनात केले आहे. स्प्लॅश पेज सर्व डिव्हाइसेसवर व्यवस्थित लोड होते. पाहुणे ईमेल कॅप्चर फॉर्म भरतात आणि त्यांना यशस्वी झाल्याचा संदेश दिसतो. परंतु जेव्हा ते ब्राउझ करण्याचा प्रयत्न करतात, तेव्हा त्यांना इंटरनेट ॲक्सेस मिळत नाही. Purple डॅशबोर्ड लॉगिन यशस्वी झाल्याचे दाखवतो. तुम्ही सर्वात आधी काय तपासाल?

टीप: क्लाउड प्लॅटफॉर्मने ऑथेंटिकेशनची नोंद केली आहे. त्रुटी ही स्थानिक अंमलबजावणीच्या टप्प्यात आहे.

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

Purple चा डॅशबोर्ड यशस्वी लॉगिन दाखवत असल्यामुळे, क्लाउड ऑथेंटिकेशन टप्पा योग्यरित्या पूर्ण झाला आहे. त्रुटी ही RADIUS ऑथोरायझेशनच्या टप्प्यात आहे - UniFi कंट्रोलरला Purple च्या RADIUS सर्व्हर्सकडून ॲक्सेस-ॲसेप्ट (Access-Accept) मेसेज मिळत नाहीये किंवा त्यावर कारवाई होत नाहीये. या क्रमाने तपासा: (1) UniFi कंट्रोलरवरील RADIUS शेअर केलेले सिक्रेट (shared secret) हे Purple च्या डॅशबोर्डमधील सिक्रेटशी तंतोतंत जुळते; (2) कंट्रोलरकडून Purple च्या RADIUS सर्व्हर IP ॲड्रेसेसवर पोर्ट 1812 आणि 1813 वरील आऊटबाउंड UDP ला अनुमती आहे; (3) UniFi कंट्रोलरवर कॉन्फिगर केलेले RADIUS सर्व्हर IP ॲड्रेसेस अद्ययावत आहेत (Purple ने ते अपडेट केले असण्याची शक्यता आहे). कंट्रोलरवर पॅकेट कॅप्चर केल्याने ॲक्सेस-ॲसेप्ट मेसेज येत आहे की नाही याची पुष्टी होईल.

Q3. एका हॉटेलच्या IT व्यवस्थापकाने नोंदवले आहे की त्यांच्या डिव्हाइसेसवर VPN वापरणारे पाहुणे कॅप्टिव्ह पोर्टलमध्ये अजिबात प्रवेश करू शकत नाहीत. VPN नसलेले पाहुणे सामान्यपणे कनेक्ट होतात. हॉटेल Cisco Meraki MX उपकरणांचा वापर करते. IT टीमने VPN वापरकर्त्यांना सामावून घेण्यासाठी कॅप्टिव्ह पोर्टल कॉन्फिगरेशन बदलले पाहिजे का?

टीप: कॅप्टिव्ह पोर्टल डिव्हाइसच्या नेटवर्क ट्रॅफिकला इंटरसेप्ट करण्यापूर्वी VPN त्या ट्रॅफिकचे काय करते, याचा विचार करा.

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

नाही - कॅप्टिव्ह पोर्टल कॉन्फिगरेशन बदलण्याची आवश्यकता नाही. VPN क्लायंट डिव्हाइस सोडण्यापूर्वी त्यावरील सर्व ट्रॅफिक एनक्रिप्ट करतो, ज्यामध्ये HTTP कनेक्टिव्हिटी प्रोबचा देखील समावेश असतो. गेटवे एनक्रिप्ट केलेले VPN ट्रॅफिक इंटरसेप्ट करू शकत नाही, त्यामुळे तो कधीही 302 रिडायरेक्ट जारी करत नाही. पाहुण्याने त्यांचा VPN डिसेबल करणे, कॅप्टिव्ह पोर्टल ऑथेंटिकेशन पूर्ण करणे आणि नंतर VPN पुन्हा सक्षम करणे आवश्यक आहे. ही कॅप्टिव्ह पोर्टल्स आणि VPN ची मूलभूत आर्किटेक्चरल मर्यादा आहे, कॉन्फिगरेशनची चूक नाही. IT टीमने VPN वापरकर्त्यांना कनेक्ट करण्यापूर्वी त्यांचे VPN डिसेबल करण्याचा सल्ला देणारी एक टीप पाहुण्यांच्या WiFi सूचनांमध्ये जोडली पाहिजे.

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

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 redirect, hotspot आणि walled garden चेकलिस्ट

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

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

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

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

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

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

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

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

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

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