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

Cisco Meraki splash page काम करत नाही: एक ट्रबलशूटिंग फ्लोचार्ट

हा प्रॅक्टिकल मार्गदर्शक Cisco Meraki splash फ्लो नेमका कुठे अयशस्वी झाला आहे ते शोधून काढतो: client authorisation, HTTP redirect initiation, walled-garden reachability किंवा RADIUS sign-on. हा व्हेन्यू IT टीम्सना एक नियंत्रित पुरावा मार्ग प्रदान करतो, जेणेकरून ते थेट सुरू असलेल्या नेटवर्कवर मोठे बदल न करता Guest WiFi पूर्ववत करू शकतील.

Marketing Team द्वारेप्रकाशित अद्ययावत केले
📖 12 मिनिट वाचन2,663 शब्द2 सोडवलेली उदाहरणे10 महत्वाच्या व्याख्या

Video overview

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

पॉडकास्ट ट्रान्सक्रिप्ट पहा
परिचय आणि संदर्भ तुमचे Cisco Meraki स्प्लॅश पेज दिसणे बंद झाले असल्यास, पेज पुन्हा तयार करण्याचा मोह टाळा. एका कार्यरत उपयोजनामध्ये, पेज साखळीतील फक्त एक टप्पा असते. डिव्हाइसने इच्छित SSID मध्ये सामील झाले पाहिजे, वापरण्यायोग्य नेटवर्क ॲड्रेसिंग प्राप्त केले पाहिजे, अनधिकृत म्हणून मानले गेले पाहिजे, रिडायरेक्ट मार्ग सुरू केला पाहिजे, अनुमत पूर्व-प्रमाणीकरण (pre-authentication) सेवांपर्यंत पोहोचले पाहिजे आणि साइन-ऑन प्रवेशासाठी, RADIUS एक्सचेंज पूर्ण केले पाहिजे. हे ब्रीफिंग तुम्हाला स्थापित Cisco Meraki अतिथी WiFi सेवेचे निदान करण्यासाठी एक नियंत्रित मार्ग प्रदान करते. हे सेटअप मार्गदर्शक नाही. आपण अयशस्वी टप्पा, त्यावर मालकी असणारा पुढील संघ आणि आवश्यक असणारा बदल या पुराव्यांसह एक इन्सिडेंट नोंदवला पाहिजे. तांत्रिक सखोल विश्लेषण एका डिव्हाइसपासून सुरुवात करा. त्याचा MAC ॲड्रेस, SSID, ॲक्सेस पॉइंट किंवा MX गेटवे, स्थानिक वेळ, ब्राउझर आणि डिव्हाइसने यापूर्वी कधी हे नेटवर्क वापरले होते का, याची नोंद घ्या. तुम्ही एका विशिष्ट क्लायंटवर या समस्येची पुनरावृत्ती करू शकत नसल्यास, तुम्ही संपूर्ण इस्टेटमधील कॉन्फिगरेशन बदलाच्या परिणामावर विश्वास ठेवू शकत नाही. Cisco Meraki क्लायंट तपशील दृश्यामध्ये, त्याची स्प्लॅश स्थिती तपासा. अनधिकृत डिव्हाइस नवीन स्प्लॅश प्रवाहासाठी पात्र असते. अधिकृत डिव्हाइस कदाचित पात्र नसू शकते. जेव्हा लोक तक्रार करतात की स्प्लॅश वारंवारतेकडे दुर्लक्ष केले गेले आहे, तेव्हा हे महत्त्वाचे ठरते. मागील वारंवारतेनुसार अधिकृत केलेले डिव्हाइस सेटिंग बदलल्यानंतरही तो अधिकृतता कालावधी कायम ठेवू शकते. योग्य चाचणीसाठी, केवळ निवडलेल्या चाचणी डिव्हाइसवरील अधिकृतता रद्द करा, आणि नंतर प्रवाह पुन्हा चालवा. आता Meraki इव्हेंट लॉगचा वापर त्रुटींची सूची म्हणून न करता टाइमलाइन म्हणून करा. प्रथम क्लायंट MAC ॲड्रेसद्वारे फिल्टर करा, नंतर नोंदवलेल्या अपयशाच्या वेळेनुसार विंडो सेट करा. MR ॲक्सेस पॉइंट्ससाठी, 802.11, Auth, DHCP आणि RADIUS श्रेणींचे निरीक्षण करा. MX वर, आवश्यकतेनुसार Auth आणि RADIUS वापरा. हा अनुक्रम महत्त्वाचा आहे. 802.11 असोसिएशन हे सिद्ध करते की डिव्हाइस ॲक्सेस पॉइंटशी जोडले गेले आहे. हे सिद्ध करत नाही की डिव्हाइसला IP ॲड्रेस मिळाला, ते तुमच्या स्प्लॅश पेजवर पोहोचले किंवा त्याने इंटरनेटवर प्रवेश केला. जर असोसिएशन नसेल, किंवा वारंवार डिस्कनेक्ट झाल्यामुळे चाचणीत व्यत्यय येत असेल, तर कॅप्टिव्ह पोर्टलच्या समस्येपूर्वी तुम्हाला वायरलेस कनेक्शनची समस्या आहे. अद्याप पेज टीमला तपासण्यास सांगू नका. त्यानंतर, DHCP पुरावा शोधा. ज्या क्लायंटला वैध ॲड्रेसिंग मिळाले नाही तो स्प्लॅश प्रवाह विश्वसनीयपणे सुरू करू शकत नाही. जर DHCP त्रुटी एखाद्या विशिष्ट SSID किंवा AP वर केंद्रित असतील, तर क्लायंट ॲड्रेसिंग आणि VLAN मार्ग तपासा. Cisco Meraki हे SSID आणि अपस्ट्रीम स्विच VLAN टॅगिंगला सामान्य DHCP तपासणी क्षेत्र म्हणून ओळखते. तुम्ही स्प्लॅश वारंवारता किंवा RADIUS कॉन्फिगरेशन बदलण्यापूर्वी ते दुरुस्त करा. असोसिएशन आणि ॲड्रेसिंगची पुष्टी झाल्यावर, तुम्ही अधिकृत की अनधिकृत क्लायंटची चाचणी घेत आहात हे निश्चित करा. जर तो अधिकृत असेल, तर पेज न दिसणे अगदी योग्य असू शकते. नामांकित चाचणी क्लायंटची अधिकृतता रद्द करा आणि चाचणीची पुनरावृत्ती करा. पुढील भाग स्पष्टपणे दिसत असलेल्या रीडायरेक्ट त्रुटींचा मोठा हिस्सा शोधून काढतो. Cisco Meraki जेव्हा अनधिकृत डिव्हाइस HTTP GET पाठवते, तेव्हा splash रीडायरेक्ट सुरू करते. ॲक्सेस पॉइंट त्या विनंतीला अडवतो आणि ब्राउझरला splash URL कडे निर्देशित करतो. HTTPS च्या बाबतीत हे वेगळे आहे. विनंती एन्क्रिप्टेड असते, त्यामुळे ॲक्सेस पॉइंट त्याला splash रीडायरेक्टसह बदलू शकत नाही. splash पेज लोड होण्याऐवजी HTTPS-first ब्राउझर विनंतीचा टाईमआउट होऊ शकतो. त्यामुळे ट्रिगरची जाणीवपूर्वक चाचणी घ्या. ब्राउझर कुकीज स्वीकारत असल्याची खात्री करा. तुमच्या ऑपरेटिंग प्रक्रियेमध्ये बसत असेल तरच ब्राउझर कॅशे साफ करा. त्यानंतर अनधिकृत चाचणी डिव्हाइसवर HTTP डेस्टिनेशन उघडा. जर पेज दिसले, तर Captive Portal यंत्रणा कार्यरत आहे. क्लायंटच्या वर्तनाची नोंद करा. योग्य प्रतिसाद म्हणजे सुरक्षा कमकुवत करणे किंवा प्रत्येक HTTPS-first विनंती रीडायरेक्ट होईल असे वचन देणे हा नाही. जर पेज रिकामेच राहिले, तर कुकीज पुन्हा तपासा. Cisco Meraki रिकाम्या पेजचे कारण म्हणून डिसेबल केलेल्या कुकीज ओळखते. splash पेज ब्राउझर सेशन स्टेटवर अवलंबून असते. कुकीज नाकारण्यासाठी कॉन्फिगर केलेला ब्राउझर अशी लक्षणे दाखवू शकतो जी होस्टिंग त्रुटीसारखी वाटू शकतात. जर पेज लोड होण्यास सुरुवात झाली परंतु त्यामध्ये स्टाईलिंग, इमेज, फॉर्म घटक किंवा त्याची ओळख सेवा नसेल, तर walled garden कडे जा. ही ती डेस्टिनेशन्स आहेत जिथे अनधिकृत डिव्हाइस पोहोचू शकते. पेज होस्टचे पुनरावलोकन करा, त्यानंतर ऑथोरायझेशनपूर्वी आवश्यक असलेले केवळ ॲसेट, ऑथेंटिकेशन आणि सर्व्हिस एंडपॉइंट्स तपासा. Cisco Meraki होस्टनेम्स, IP ॲड्रेसेस, रेंज आणि वाईल्डकार्ड डोमेन्सना सपोर्ट करते, तर कस्टम splash URL ला परवानगी असणे आवश्यक आहे. Purple ऑफलाइन पेजसाठी, ही सीमा महत्त्वाची ठरते. व्हिजिटर walled garden मध्येच राहतो आणि बाह्य लिंक्स किंवा रिमोट रिसोर्सेस वापरू शकत नाही. प्रत्येक नवीन पेज डिपेंडन्सीची ऑथेंटिकेशनपूर्वीच्या पॉलिसीशी तुलना करा. splash टेम्पलेटमध्ये ॲसेट्स अपलोड करणे अधिक सोयीचे असू शकते. पेज यशस्वीरीत्या लोड झाल्यानंतरच तुम्ही RADIUS ची तपासणी करावी. साइन-ऑन splash पेज जे लोड तर होते परंतु क्रेडेंशियल्स नाकारते, फिरत राहते किंवा टाईमआउट दाखवते, अशा वेळी RADIUS संबंधित ठरते. जेव्हा कोणतेही पेज दिसत नाही, तेव्हा ते तुमचे पहिले संशयित कारण नसते. Cisco Meraki एक गोष्ट अगदी स्पष्ट करते. तुमच्या RADIUS सर्व्हरचा वापर करणाऱ्या साइन-ऑन splash पेजसाठी, RADIUS विनंती Dashboard क्लाउडमधून येते. ती स्थानिक AP किंवा MX कडून येत नाही. याचा संपूर्ण ट्रबलशूटिंगच्या मार्गावर परिणाम होतो. RADIUS सर्व्हरसाठीचा खाजगी LAN ॲड्रेस या प्रवाहाला मदत करणार नाही. सेवा डॉक्युमेंट केलेल्या Dashboard सोर्स रेंजमधून पोहोचण्यायोग्य असणे आवश्यक आहे, संबंधित सोर्स RADIUS क्लायंट म्हणून ओळखले गेले पाहिजेत आणि शेअर्ड सिक्रेट जुळले पाहिजे. ऑथेंटिकेशनची पद्धत देखील महत्त्वाची आहे. Cisco Meraki या साइन-ऑन splash प्रवाहासाठी PAP डॉक्युमेंट करते आणि नमूद करते की RADSec ला सपोर्ट नाही. त्या डॉक्युमेंट केलेल्या मोडनुसार तुमच्या RADIUS पॉलिसीची पडताळणी करा. वेगळ्या Enterprise WiFi डिप्लोयमेंटसाठी तयार केलेली पॉलिसी येथे जशीच्या तशी लागू होईल असे गृहीत धरू नका. Cisco डॉक्युमेंट केलेल्या वायरलेस कॉन्फिगरेशनसाठी Dashboard RADIUS चाचणी देखील प्रदान करते. ती उपलब्ध असेल तिथे वापरा, आणि नंतर विनंती पोहोचली, नाकारली गेली किंवा कोणताही प्रतिसाद मिळाला नाही हे ठरवण्यासाठी RADIUS सर्व्हरचे स्वतःचे लॉग तपासा. अमलबजावणीच्या शिफारसी आणि संभाव्य अडचणी हा डायग्नोस्टिक अनुक्रम तुमच्या ऑपरेटिंग रनबुकमध्ये तयार करा. यामध्ये नामांकित चाचणी डिव्हाइस, त्याचे प्रमाणीकरण रद्द करण्यासाठी मंजुरीची मर्यादा, अपेक्षित स्पॅश होस्ट, वॉल्ड-गार्डन डिपेंडन्सी लिस्ट, RADIUS सेवा मालक आणि एस्केलेशन संपर्क समाविष्ट करा. प्रत्येक वेन्यूला हे माहित असले पाहिजे की पेज कंटेंट, नेटवर्क कॉन्फिगरेशन आणि ऑथेंटिकेशन पॉलिसीची मालकी कोणाकडे आहे. हे रिसेप्शन टीम, MSP आणि आयडेंटिटी टीम यांना परस्पर नसलेले बदल करण्यापासून रोखते. चाचणी सक्तीची करण्यासाठी स्पॅश वारंवारता बदलू नका. एका चाचणी क्लायंटचे प्रमाणीकरण रद्द करा. आउटेजचा पुरावा म्हणून केवळ एका ब्राउझर निकालाचा वापर करू नका. एका क्लीन चाचणी डिव्हाइसची प्रभावित डिव्हाइसशी तुलना करा. कस्टम पेज खराब झाले म्हणून अनियंत्रित प्री-ऑथेंटिकेशन इंटरनेट ॲक्सेस जोडू नका. डिपेंडन्सी अचूकपणे ओळखा. व्हिजिटर पेजवर पोहोचला आहे याचा पुरावा म्हणून RADIUS इव्हेंट गृहीत धरू नका. या अनुक्रमाचे अनुसरण करा: असोसिएशन, ॲड्रेसिंग, अनऑथराइज्ड स्टेट, HTTP ट्रिगर, पेज रीचॅबिलिटी आणि साइन-ऑन ऑथेंटिकेशन. त्वरित विचारले जाणारे प्रश्न पेज वारंवार का दाखवले जाते? कुकीज, ब्राउझर कॅशे आणि गेटवे ॲक्सेस पॉईंट रीस्टार्ट झाले आहे का ते तपासा. हे घटक Cisco Meraki स्पॅश अनुभवाभोवती वापरत असलेल्या स्टेटवर परिणाम करतात. ते फार कमी वेळा का दाखवले जाते? डिव्हाइस अद्याप आधीच्या वारंवारतेनुसार ऑथराइज्ड असू शकते. नियंत्रित चाचणी क्लायंटचे ऑथरायझेशन रद्द करा आणि पुन्हा चाचणी घ्या. Guest WiFi रिडायरेक्ट का होत नाही? क्लायंट अनऑथराइज्ड आहे, त्याच्याकडे वैध ॲड्रेसिंग आहे आणि तो HTTP विनंतीची चाचणी घेत आहे याची खात्री करा. HTTPS-फर्स्ट विनंती समान रिडायरेक्ट ट्रिगर करू शकत नाही. साइन-ऑन टाईम आऊट का होते? डॅशबोर्ड ते RADIUS रीचॅबिलिटी, वर्तमान स्त्रोत श्रेणी, RADIUS क्लायंट एंट्रीज, शेअर केलेले सिक्रेट अलाइनमेंट, PAP सपोर्ट आणि सर्व्हर पॉलिसी प्रमाणित करा. Auth इव्हेंटचा अर्थ काय आहे? ते स्पॅश ऑथेंटिकेशन वर्गवारी चिन्हांकित करतात. त्यांना स्वतंत्रपणे न पाहता असोसिएशन, DHCP आणि RADIUS रेकॉर्डसह वाचा. एक व्यावहारिक वेन्यू सिनॅरियो हा मुद्दा स्पष्ट करतो. एका कॉन्फरन्स-सेंटर ऑपरेशन्स टीमने कळवले आहे की उपस्थितांचे फोन्स Guest WiFi ला जोडले जात आहेत परंतु साइन-ऑन पेज अपूर्ण दिसत आहे. नेटवर्क टीम एक हँडसेट निवडते, त्याचा MAC ॲड्रेस रेकॉर्ड करते आणि असोसिएशन, DHCP आणि अनऑथराइज्ड स्पॅश स्टेटची पुष्टी करते. एक HTTP चाचणी पेज उघडते, परंतु त्याचा बाह्य आयडेंटिटी घटक लोड होत नाही. यामुळे त्वरित त्रुटीच्या मार्गातून RADIUS बाजूला होतो. टीम प्री-ऑथेंटिकेशन डिपेंडन्सी लिस्टचे पुनरावलोकन करते आणि त्यांना आढळते की नवीन पेज घटक वॉल्ड-गार्डन पुनरावलोकनामध्ये समाविष्ट केलेला नाही. ते मंजूर केलेल्या डिपेंडन्सीमध्ये सुधारणा करतात, चाचणीची पुनरावृत्ती करतात आणि यशस्वी ऑथरायझेशन रेकॉर्ड कॅप्चर करतात. याचा धडा असा नाही की प्रत्येक तुटलेल्या स्पॅश पेजला दुसऱ्या वॉल्ड-गार्डन एंट्रीची आवश्यकता असते. धडा हा आहे की प्रथम टप्पा सिद्ध करणे आवश्यक आहे. एखाद्या भिन्न साईटवर व्हिजिटरचे हेच लक्षण दिसू शकते कारण HTTP ट्रिगर झाला नसेल, किंवा डॅशबोर्ड क्लाउड RADIUS सर्व्हरपर्यंत पोहोचू शकत नसेल. ही प्रक्रिया अशा अपयशांना द्रुतपणे वेगळे करते. सारांश आणि पुढील पायऱ्या Cisco Meraki splash page ची समस्या सहसा बिघडलेला टप्पा असतो, बिघडलेले पेज नाही. डिव्हाइस योग्य नेटवर्कमध्ये सामील झाल्याचे सिद्ध करा. त्याला वैध ॲड्रेसिंग मिळाले असल्याचे सिद्ध करा. ते खरोखरच अनधिकृत आहे की नाही याची खात्री करा. HTTP द्वारे फ्लो ट्रिगर करा. केवळ लॉगिन करण्यापूर्वी आवश्यक असलेल्या घटकांसाठी walled garden चे पुनरावलोकन करा. त्यानंतर, साइन-ऑन पेज स्वतः अयशस्वी झाल्यास Dashboard-to-RADIUS ऑथेंटिकेशनची तपासणी करा. हा दृष्टिकोन तुमच्या वेन्यू ऑपरेशनचे रक्षण करतो. हे घाईघाईने केलेले बदल टाळते ज्यामुळे इतर पाहुण्यांना त्रास होऊ शकतो, आणि नेटवर्क टीमला ते पुन्हा तयार करू शकतील असे पुरावे देते. फ्लोचार्ट सर्व्हिस रनबुकसह ठेवा, प्रत्येक नियोजित पेज किंवा ओळख बदलानंतर त्याची चाचणी घ्या, आणि प्रत्येक एस्केलेशनमध्ये क्लायंट MAC, वेळ, SSID, गेटवे आणि लॉग पुरावे समाविष्ट करा. अशा प्रकारे तुम्ही “splash page काम करत नाही आहे” चे एका सुलभ तांत्रिक समस्येमध्ये रूपांतर करू शकता.

आमच्या मुख्य मालिकेचा भाग: Captive Portal मार्गदर्शक →

Cisco Meraki Architecture DiagnosticSeverity: Critical

Cisco Meraki splash page troubleshooting advisor

Select the observed symptom below to identify the root cause, Meraki Event Log codes, step-by-step Dashboard remediation paths, and copyable network configuration rules.

Filter by target client platform:

Observed symptom profile

Mobile clients associate to the SSID and receive a DHCP address, but the native captive portal popup window (Apple Captive Network Assistant, Android CaptivePortalLogin) never launches. Manual browsing yields connection timeouts or HTTPS certificate warnings.

Primary technical root cause

The client browser or OS uses secure DNS (DoH/DoT) or private DNS that bypasses Meraki local DNS interception on UDP port 53. Alternatively, the client attempts an initial HTTP probe over HTTPS to an HSTS-preloaded domain before the AP can inject the 302 redirect.

Meraki Dashboard path:Wireless > Configure > Access control > Client IP and DHCP

Step-by-step resolution procedure

1Ensure the DHCP scope hands out accessible local or public DNS resolvers (e.g. 1.1.1.1, 8.8.8.8) so initial probe hostnames resolve instantly.
2Under Access control, ensure "Block LAN traffic" is not blocking the gateway IP or DNS server.
3Advise guests on persistent devices to visit an unencrypted HTTP destination such as captive.apple.com or neverssl.com to trigger interception.
4Confirm that the AP native firmware intercepts port 80 traffic before applying Layer 3 or Layer 7 firewall blocking rules.

Deploying guest WiFi across Cisco Meraki access points?

Purple provides native cloud-managed splash pages, pre-configured walled garden access, and certified RADIUS authentication for Cisco Meraki MR and MX infrastructure.

Cisco Meraki splash page काम करत नाही: एक ट्रबलशूटिंग फ्लोचार्ट

जेव्हा क्लायंट अजूनही अधिकृत (authorised) असतो, रिडायरेक्ट ट्रिगर करणारी HTTP विनंती पाठवू शकत नाही, स्वीकृत splash डिपेंडन्सीपर्यंत पोहोचू शकत नाही किंवा RADIUS प्रमाणीकरण पूर्ण करू शकत नाही, तेव्हा Cisco Meraki splash पेजेस दिसणे बंद होते. एका बाधित क्लायंटपासून सुरुवात करा, त्याच्या MAC पत्त्याद्वारे Auth, DHCP आणि RADIUS रेकॉर्ड्स फिल्टर करा, आणि नंतर खालील संबंधित ब्रँचची चाचणी घ्या. 1 2 3 5

Meraki splash पेज दिसण्यासाठी कोणती गोष्ट कार्यरत असणे आवश्यक आहे?

Captive Portal कडे एक सिंगल वेब पेज म्हणून न बघता, एक लहान साखळी म्हणून पहा. उपकरणाने योग्य SSID शी जोडले जाणे, वैध ॲड्रेसिंग मिळवणे, अनधिकृत म्हणून वर्गीकृत केले जाणे, splash फ्लो सुरू करू शकणारा ट्रॅफिक पाठवणे, आवश्यक होस्ट केलेल्या सेवेपर्यंत पोहोचणे आणि नंतर अधिकृतता प्राप्त करणे आवश्यक आहे. Cisco Meraki या ट्रिगरचे वर्णन अनधिकृत क्लायंटकडून येणारे HTTP GET म्हणून करते. AP त्या विनंतीला अडवतो (intercepts) आणि splash URL वर HTTP 307 रिडायरेक्ट पाठवतो. 1

यावरून एक सामान्य सपोर्ट कॉल स्पष्ट होतो: एखादा अतिथी तुमच्या Guest WiFi मध्ये सामील होऊ शकतो परंतु splash पेज लोड होत नाही असे सांगतो. ॲक्सेस पॉइंट कदाचित डिझाइननुसारच काम करत असेल. उपकरणाने आधी केवळ HTTPS-असलेले गंतव्यस्थान उघडल्यास, एन्क्रिप्ट केलेली विनंती रिडायरेक्ट केली जाऊ शकत नाही. Cisco Meraki विशेषतः याला ब्राउझर टाइमआउट परिस्थिती म्हणून ओळखते. SSID, पेज डिझाइन किंवा RADIUS सर्व्हर बदलण्यापूर्वी नियंत्रित HTTP ब्रँचची चाचणी घ्या. 2

हीच शिस्त दुसरी एक सामान्य चूक टाळते: प्रत्येक पुनरावृत्तीच्या प्रॉम्प्टला पेज अयशस्वी झाल्यासारखे समजणे. Splash वारंवारता हे अधिकृतता धोरण (authorisation policy) आहे. Cisco Meraki हे splash स्टेटस गेटवे ॲक्सेस पॉइंट आणि क्लाउड कंट्रोलरवर ठेवते, तर ब्राउझर सेशन कुकी राखून ठेवतो. वैध अधिकृतता कालावधी असलेल्या क्लायंटला तुम्ही कॉन्फिगर केलेली वारंवारता कमी केल्यानंतर कदाचित पेज पुन्हा दिसणार नाही. याउलट, कुकीज अक्षम किंवा साफ केलेल्या क्लायंटला वारंवार प्रॉम्प्ट केले जाऊ शकते. 2

क्लायंट काय रिपोर्ट करतो गोळा करायचा पहिला पुरावा सर्वात संभाव्य ब्रँच पहिली नियंत्रित तपासणी
“मी जॉइन झालो पण पेज उघडत नाहीये” क्लायंट MAC, SSID, AP आणि वेळ HTTP-ट्रिगर किंवा क्लायंट अधिकृतता Splash: Not authorized ची खात्री करा, नंतर HTTP चाचणी गंतव्यस्थानावर ब्राउझ करा. 1 2
“काल काम करत होते पण आज नाही” अधिकृतता स्टेटस आणि अलीकडील AP उपलब्धता Splash वारंवारता किंवा गेटवे स्टेटस क्लायंट स्टेटसह कालबाह्यता (expiry) तपासा. केवळ नियुक्त चाचणी क्लायंटसाठी अधिकृतता रद्द करा. 2 3
“पेज रिकामे दिसत आहे” ब्राउझर कुकी सेटिंग आणि उपकरणाचा प्रकार ब्राउझर सेशन स्टेटस कुकीज सक्षम करा आणि त्याच क्लायंटवर फ्लो पुन्हा करा. 2
“पेज उघडते पण साइन-इन फिरत राहते किंवा अयशस्वी होते” लॉगिन प्रयत्न, Auth इव्हेंट्स आणि RADIUS रेकॉर्ड्स क्लाउड-टू-RADIUS पोहोच किंवा धोरण Dashboard RADIUS चाचणी चालवा जेथे Cisco Meraki ती प्रदान करते, नंतर फायरवॉल, सोर्स श्रेणी आणि शेअर्ड-सिक्रेट अलाइनमेंटचे पुनरावलोकन करा. 4

काहीही बदलण्यापूर्वी तुम्ही काय कॅप्चर केले पाहिजे?

एका रिप्रोड्युसिबल रिपोर्टसह सुरुवात करा. क्लायंटचा MAC address, SSID, गेटवे ॲक्सेस पॉइंट किंवा MX, डिव्हाइस प्रकार, स्थानिक वेळ, ब्राउझर आणि डिव्हाइसने आधी स्प्लॅश ऑथेंटिकेशन पूर्ण केले होते की नाही हे रेकॉर्ड करा. तुम्ही तपासणी करत असताना रिपोर्टरला डिव्हाइस कनेक्टेड ठेवण्यास सांगा. यामुळे तुम्हाला एका विशिष्ट घटनेची मर्यादा मिळते आणि एखाद्या गजबजलेल्या हॉटेल, रिटेल साइट किंवा कार्यक्रमाच्या ठिकाणी ढोबळ तक्रारीवरून आंधळेपणाने कॉन्फिगरेशन बदल करावे लागत नाहीत.

क्लायंटचे तपशील उघडा आणि ते ऑथराइज्ड आहे की नाही ते तपासा. Cisco Meraki ऑथराइज्ड नसलेल्या क्लायंटला Splash: Not authorized म्हणून ओळखते; तर ऑथराइज्ड क्लायंट त्याचा उर्वरित ऑथरायझेशन वेळ दाखवतो. तुमच्या चाचणीसाठी सेव्ह केलेला ब्राउझर टॅब वापरू नका. यामुळे मागील सेशन आणि सध्याची रेडिओ व DHCP स्थिती एकत्र मिसळू शकते. 1

त्यानंतर क्लायंट MAC address आणि घटनेच्या वेळेनुसार डॅशबोर्ड इव्हेंट लॉग फिल्टर करा. MR ॲक्सेस पॉइंट्ससाठी, Auth इव्हेंट प्रकार स्प्लॅश-पेज ऑथेंटिकेशनचे प्रतिनिधित्व करतो. 802.11 असोसिएशन आणि डिसअसोसिएशन दर्शवते, DHCP लीझ-संबंधित इव्हेंट्स वाहून नेते, आणि RADIUS हे RADIUS किंवा MAC Authentication Bypass ॲक्टिव्हिटी ओळखते. MX स्प्लॅश ऑथेंटिकेशनसाठी देखील हेच Auth फिल्टर उपलब्ध आहे. Cisco Meraki नमूद करते की डिव्हाइसेस ऑनलाईन आल्यानंतर मूळ टाइमस्टॅम्प राखून ठेवून स्टोअर केलेले इव्हेंट्स अपलोड करतात, त्यामुळे नेमके आधी काय घडले हे ठरवण्यापूर्वी टाइम झोन जुळवून घ्या. 5

खालील क्रमाने दिलेल्या रेकॉर्डचा वापर करा. हे अंदाज न लावता फॉल्ट डोमेन कमी करते.

पुराव्यांचा चेकपॉइंट निरोगी संकेत जर ते अनुपस्थित किंवा चुकीचे असेल ते तुम्हाला काय सांगते
802.11 असोसिएशन क्लायंट अपेक्षेप्रमाणे AP आणि SSID मध्ये सामील झाला असोसिएशन नाही, वारंवार डिसअसोसिएशन किंवा अनपेक्षित AP Captive Portal च्या वर्तनापूर्वी रेडिओ असोसिएशनचे निदान करा. 6
ॲड्रेसिंग रिपोर्टच्या वेळेच्या दरम्यान वैध क्लायंट ॲड्रेस आणि कोणतीही DHCP त्रुटी नाही DHCP त्रुटी किंवा वापरण्यायोग्य क्लायंट कॉन्फिगरेशन नाही SSID/क्लायंट ॲड्रेसिंग आणि VLAN मार्ग तपासा. 2 6
स्प्लॅश स्थिती नवीन चाचणीसाठी क्लायंट ऑथराइज्ड नाही क्लायंट ऑथराइज्ड राहिला आहे केवळ नियुक्त चाचणी क्लायंटचे ऑथरायझेशन रद्द करा, नंतर पुन्हा चाचणी घ्या. 2 3
Auth स्प्लॅश-संबंधित इव्हेंट चाचणीशी जुळतो HTTP चाचणीनंतर कोणताही इव्हेंट नाही रिडायरेक्ट ट्रिगर किंवा क्लायंट चाचणी अपूर्ण आहे. 5
RADIUS पुरावा प्रयत्न आणि प्रतिसाद साइन-ऑन वेळेसह जुळतात टाईमआऊट, नकार किंवा कोणताही प्रतिसाद नाही डॅशबोर्ड-टू-RADIUS शाखेकडे जा. 4 5

तुम्ही ट्रबलशूटिंग फ्लोचार्ट कसा चालवाल?

Cisco Meraki splash page काम करत नाही: एक ट्रबलशूटिंग फ्लोचार्ट - splash troubleshooting flowchart

स्वच्छ चाचणी क्लायंटसाठी एकदा आणि आधीपासून प्रभावित असलेल्या क्लायंटसाठी एकदा फ्लोचार्ट वापरा. यामधील फरक उपयुक्त ठरतो. जर एखादा स्वच्छ क्लायंट स्प्लॅश स्क्रीनपर्यंत पोहोचत असेल आणि प्रभावित डिव्हाइस पोहोचत नसेल, तर हे संपूर्ण वेन्यूमधील आउटेजऐवजी ऑथोरायझेशन, ब्राउझरची स्थिती किंवा क्लायंट-विशिष्ट पॉलिसीचे पुरावे दर्शवते.

  1. असोसिएशन आणि ॲड्रेसिंगची खात्री करा. जर इव्हेंट लॉगमध्ये क्लायंट इच्छित SSID शी असोसिएट झाल्याचे दिसत नसेल, तर स्प्लॅशच्या त्रुटी शोधू नका. जर ते असोसिएट होत असेल परंतु DHCP रेकॉर्डमध्ये त्रुटी दिसत असेल, तर आधी ॲड्रेसिंग किंवा VLAN पाथ दुरुस्त करा. Cisco Meraki नुसार SSID किंवा अपस्ट्रीम स्विच पोर्टवरील VLAN टॅगिंग हे DHCP अयशस्वी होण्याचे सामान्य कारण आहे. 6

  2. क्लायंट अनऑथोराइज्ड असल्याची खात्री करा. आधी ऑथोराइज्ड केलेल्या डिव्हाइसला कदाचित पुन्हा स्प्लॅश पेजची आवश्यकता नसेल. Cisco Meraki नियंत्रित री-टेस्टिंगसाठी क्लायंट-ऑथोरायझेशन रिव्होक फंक्शन प्रदान करते. प्रत्येक वेन्यू वापरकर्त्यासाठी स्प्लॅश फ्रिक्वेन्सी बदलण्याऐवजी, नामनिर्देशित डिव्हाइसवर याचा वापर करा. 2 3

  3. HTTP सह ट्रिगरची चाचणी घ्या. आपल्या चाचणी प्रक्रियेनुसार योग्य असेल तेथेच ब्राउझर कॅशे क्लियर करा, कुकीज सुरू असल्याची खात्री करा, आणि नंतर एखादे HTTP डेस्टिनेशन उघडा. Cisco Meraki नुसार HTTPS-फर्स्ट विनंती रीडायरेक्ट केली जाऊ शकत नाही कारण ट्रॅफिक एन्क्रिप्टेड असते. जर HTTP चाचणी यशस्वी झाली, तर या वर्तनाचे कारण क्लायंट आहे असे नोंदवा. नेटवर्कने त्याचे स्प्लॅश रीडायरेक्ट गमावलेले नाही. 1 2

  4. पेजची पोहोच आणि वल्ड गार्डनची चाचणी घ्या. एक वल्ड गार्डन स्प्लॅश ऑथेंटिकेशनपूर्वी विशिष्ट IP ॲड्रेस, रेंजेस किंवा होस्टनेम्सना (वाइल्डकार्ड डोमेन्ससह) परवानगी देते. आपण कस्टम स्प्लॅश URL वापरत असल्यास, Cisco Meraki नुसार कस्टम पेजचा IP ॲड्रेस आणि/किंवा URL वल्ड गार्डनमध्ये असणे आवश्यक आहे. जेव्हा पेज स्वतंत्र ॲसेट, आयडेंटिटी किंवा सर्व्हिस एंडपॉइंट्सवर अवलंबून असते, तेव्हा सर्व्हिस ओनरसह प्रत्येक आवश्यक डेस्टिनेशनचे पुनरावलोकन करा. अंदाजाने IP ॲड्रेस टाकू नका किंवा शॉर्टकट म्हणून संपूर्ण इंटरनेट प्रवेश देऊ नका. 3

Purple पेजेस हा फरक स्पष्ट करतात. एक ऑफलाइन स्प्लॅश पेज लॉगिनपूर्वी दिसते आणि त्यामध्ये बाह्य लिंक्स किंवा रिसोर्सेस समाविष्ट केले जाऊ शकत नाहीत कारण भेट देणारा वल्ड गार्डनमध्ये असतो. एक ऑनलाइन पेज यशस्वी लॉगिननंतर दिसते आणि त्यावर बाह्य मीडिया किंवा लिंक्स असू शकतात. बदलांनंतर जर एखाद्या ऑफलाइन Purple HTML पेजमधील इमेज, स्टाईलशीट, स्क्रिप्ट किंवा थर्ड-पार्टी आयडेंटिटी एलिमेंट लोड होत नसेल, तर डिझाइन बदलण्यापूर्वी परवानगी असलेल्या प्री-ऑथेंटिकेशन एंट्रीजशी त्यांची तुलना करा. 7 8

  1. पेज लोड झाल्यानंतरच साइन-ऑन RADIUS ची चाचणी घ्या. सेंट्रलाइज्ड ऑथेंटिकेशन विनंत्यांसाठी वापरला जाणारा RADIUS हा प्रोटोकॉल, स्प्लॅश पेज न दिसण्यामागील पहिले कारण नसतो. जेव्हा साइन-ऑन फॉर्म लोड होतो परंतु ऑथेंटिकेशन अयशस्वी किंवा टाईम-आउट होते तेव्हा हा संबंधित ठरतो. या Cisco Meraki फ्लोसाठी, स्थानिक AP किंवा MX नव्हे तर Dashboard क्लाउड RADIUS ॲक्सेस विनंती पाठवते. सर्व्हरला अधिकृत Dashboard सोर्स रेंजेसवरून पब्लिक रीचेबिलिटी, मॅचिंग शेअर्ड सिक्रेट आणि PAP साठी सपोर्ट आवश्यक असतो. Cisco Meraki नुसार स्प्लॅश ऑथेंटिकेशनसाठी RADSec सपोर्टेड नाही. 4 ६. समर्थित RADIUS तपासणी चालवा आणि सर्व्हर रेकॉर्डचे परीक्षण करा. Cisco Meraki दस्तऐवजीकरण केलेल्या वायरलेस कॉन्फिगरेशनसाठी Dashboard RADIUS चाचणी प्रदान करते, जरी MX किंवा Z-मालिका नेटवर्कसाठी चाचणी बटण अस्तित्वात नाही. टाइमआउटचा अर्थ असा आहे की आपण वर्तमान Dashboard फायरवॉल माहिती, RADIUS क्लायंट नोंदी, सार्वजनिक होस्ट पोहोचक्षमता, सामायिक-गुपित संरेखन आणि पॉलिसी वर्तन तपासले पाहिजे. Cisco Meraki ची आरोग्य तपासणी नियतकालिक प्रवेश विनंत्या पाठवते आणि २० सेकंदांच्या अंतराने सहा अनुत्तरीत प्रयत्नांनंतर सर्व्हरला पोहोचण्यायोग्य नसलेले मानते. [४]

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

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

आपण सामान्य बिघाड बिंदू कशा प्रकारे वेगळे करता?

Cisco Meraki splash page काम करत नाही: एक ट्रबलशूटिंग फ्लोचार्ट - meraki splash evidence map

Splash वारंवारता चुकीची वाटते

जर splash पेज पॉलिसी सुचवल्यापेक्षा कमी वेळा दिसत असेल, तर वारंवारता बदलली तेव्हा क्लायंट आधीच अधिकृत होता का ते तपासा. Cisco Meraki चे म्हणणे आहे की विद्यमान अधिकृतता कालावधी लागू राहतो. निवडलेल्या क्लायंटची अधिकृतता रद्द केल्याने अद्ययावत केलेल्या सेटिंगची एक वैध चाचणी तयार होते. जर पेज अधिक वेळा दिसत असेल, तर ब्राउझर कुकी स्वीकारणे, कॅशे साफ करणे आणि गेटवे ॲक्सेस-पॉइंट सातत्य तपासा. जोपर्यंत ब्राउझर त्याची कुकी सादर करू शकत नाही, तोपर्यंत गेटवे रीस्टार्ट करण्यासाठी पुन्हा प्रमाणीकरणाची आवश्यकता असू शकते. [२]

हे हॉस्पिटॅलिटी क्षेत्रात महत्त्वाचे आहे. एका उदाहरणादाखल २०० खोल्यांच्या हॉटेलने बदलानंतर नियंत्रित हँडसेटसह चाचणी केली पाहिजे, नंतर तीन सोपे परिणाम म्हणून निकालाचे मोजमाप केले पाहिजे: क्लायंट अधिकृतमध्ये बदलतो, त्याला अपेक्षित समाप्ती मिळते आणि पुढील नवीन HTTP विनंती इच्छित वर्तन करते. तक्रारी थांबल्या आहेत की नाही हे रिसेप्शनला विचारण्यापेक्षा हा एक चांगला रिलीज गेट आहे.

अतिथी WiFi रिडायरेक्ट होत नाही आहे

HTTPS ने Captive Portal "बिघडवले" आहे असे सांगू नका. Cisco Meraki चे दस्तऐवजीकरण केलेले वर्तन मर्यादित आहे: रिडायरेक्ट यंत्रणा अनधिकृत HTTP GET वर कार्य करते, तर HTTPS-प्रथम विनंती रिडायरेक्ट केली जाऊ शकत नाही. आधुनिक डिव्हाइसेस असोसिएशनवर त्यांचे ऑपरेटिंग सिस्टिमचे Captive Portal शोध प्रवाह सुरू करू शकतात. तो प्रॉम्ट न दिसल्यास, नेटवर्क शाखा कार्य करते की नाही हे स्थापित करण्यासाठी HTTP चाचणी वापरा. [१] [२]

एका उदाहरणादाखल रिटेल रोलआउटसाठी, स्टोअरची आयटी टीम सेल्स-फ्लोअर SSID वरील स्टाफ चाचणी डिव्हाइससह तक्रार पुन्हा तयार करू शकते. मान्यतेचा पुरावा हा अस्पष्ट पेज-लोड दावा नाही. असोसिएशन रेकॉर्ड, वैध पत्ता, अनधिकृत स्थिती, HTTP चाचणीनंतरची Auth इव्हेंट आणि परिणामी अधिकृतता स्थिती कॅप्चर करा. अभ्यागतांचे क्रेडेंशियल उघड न करता या रेकॉर्डची विविध स्टोअरमध्ये तुलना केली जाऊ शकते.

Walled garden अपूर्ण आहे

एक walled garden हा मुद्दाम मर्यादित केलेला पूर्व-अधिकृतता प्रवेश असतो. ती बायपास सूची बनू नये. प्रथम splash होस्टचे पुनरावलोकन करा, त्यानंतर आपल्या पूर्व-प्रमाणीकरण पेजला खरोखर आवश्यक असलेल्या अवलंबनांचे पुनरावलोकन करा. Cisco Meraki वाईल्डकार्ड डोमेनसह आयपी पत्ते, आयपी श्रेणी आणि होस्टनावांना अनुमती देते. जेव्हा ते वैशिष्ट्य सक्षम असते तेव्हा Cisco ला walled garden मध्ये सानुकूल splash पेज URL किंवा आयपी पत्त्याची देखील आवश्यकता असते. [३]

Purple ऑफलाईन पेज हा सर्वात मर्यादित टप्पा आहे. Purple असे स्पष्ट करते की व्हिजिटर 'वॉल गार्डन' (मर्यादित नेटवर्क क्षेत्र) मध्ये असताना ते बाह्य लिंक्स किंवा संसाधने वापरू शकत नाही. HTML एडिटर तुमच्या टीमला पोर्टलमध्ये ॲसेट्स अपलोड करण्याची आणि सध्याच्या पेजचे पुनरावलोकन करण्याची परवानगी देतो, ज्यामुळे अनावश्यक रिमोट डिपेंडन्सीज कमी होऊ शकतात. संपादित केलेले टेम्पलेट प्रकाशित करण्यापूर्वी Purple ने प्रकाशित केलेल्या पायऱ्यांचे अनुसरण करा. 7 8

साइन-ऑन स्प्लॅश टाईम आऊट होतो किंवा क्रेडेंशियल नाकारतो

नकार देणे आणि टाईम आऊट होणे या दोन वेगवेगळ्या गोष्टी आहेत. नकार देणे हा ऑथेंटिकेशन किंवा पॉलिसीचा परिणाम असतो. टाईम आऊट किंवा "कनेक्ट करण्यात अडचण" असा संदेश मुख्यत्वे डॅशबोर्ड आणि कॉन्फिगर केलेल्या RADIUS सर्व्हरमधील पोहोचण्यायोग्यतेकडे निर्देश करतो. Cisco Meraki दस्तऐवज स्पष्ट करतात की साइन-ऑन स्प्लॅश विनंत्या डॅशबोर्ड क्लाउडमधून सुरू होतात आणि RADIUS सर्व्हरसाठी खाजगी LAN ॲड्रेस वापरू शकत नाहीत. 4

या स्प्लॅश मोडसाठी सर्व्हर PAP ची अपेक्षा करतो, दस्तऐवजीकरण केलेले डॅशबोर्ड सोर्स रेंजेस अनुमतीत आहेत, सर्व संबंधित सोर्स IPs RADIUS क्लायंट म्हणून कॉन्फिगर केले आहेत आणि सामायिक गुप्त संकेतशब्द (shared secret) दोन्ही बाजूंनी जुळत असल्याची खात्री करा. Cisco Meraki हे देखील सांगते की बाह्य स्प्लॅश इंटिग्रेशनने प्रदान केलेले login_url कोणत्याही बदलाशिवाय वापरले पाहिजे आणि फिल्टरिंगने एका निश्चित पॅटर्नऐवजी त्याच्या बदलणाऱ्या होस्टनेमला अनुमती दिली पाहिजे. 4

इव्हेंट लॉग मधील Meraki स्प्लॅश इव्हेंटचा अर्थ काय आहे?

हा रेकॉर्ड एका टाईमलाईनसारखा वाचा. 802.11 association म्हणजे क्लायंट AP मध्ये सामील झाला आहे. याचा अर्थ असा नाही की क्लायंटला ॲड्रेस मिळाला आहे, तो स्प्लॅश पेजपर्यंत पोहोचला आहे किंवा त्याला इंटरनेटचा ॲक्सेस मिळाला आहे. Auth इव्हेंट ही स्प्लॅश-पेज ऑथेंटिकेशनसाठीची इव्हेंट श्रेणी आहे. त्याच वेळेच्या आसपास आलेला DHCP इव्हेंट तपासणीला ॲड्रेसिंगकडे वळवू शकतो. RADIUS-बॅक्ड साइन-ऑन प्रवाहासाठी RADIUS इव्हेंट महत्त्वाचा आहे, परंतु ब्राउझर त्या पेजवर पोहोचल्याचा हा पुरावा नाही. 5 6

802.1X ला साइन-ऑन स्प्लॅश पेजसोबत गोंधळात टाकू नका. Cisco Meraki हे WPA2-Enterprise SSIDs साठी 802.1X आणि RADIUS संदेश ओळखते. त्याचे स्वतंत्र साइन-ऑन स्प्लॅश RADIUS दस्तऐवजीकरण डॅशबोर्ड क्लाउड आणि तुमच्या RADIUS सर्व्हरमधील PAP चे वर्णन करते. या मार्गदर्शकामध्ये, अयशस्वी झालेला टप्पा शोधण्यासाठी असोसिएशन, Auth, DHCP आणि RADIUS श्रेणींचा वापर करा. एका लॉग लाईनवरून थेट मूळ कारणाचा निष्कर्ष काढू नका. 4 6

इव्हेंट किंवा रेकॉर्ड या तपासणीतील अर्थ पुढील प्रश्न
802.11 association डिव्हाइस AP मध्ये सामील झाले त्याला वैध ॲड्रेसिंग मिळाले आणि ते कनेक्टेड राहिले का? 6
802.11 disassociation डिव्हाइस बाहेर पडले किंवा AP टेबलमधून काढून टाकले गेले RF हालचाल, स्लीप मोड किंवा डिस्कनेक्शनमुळे चाचणीमध्ये व्यत्यय येत आहे का? 6
Auth स्प्लॅश-पेज ऑथेंटिकेशन श्रेणी हे नियंत्रित HTTP ट्रिगरनंतर घडले का? 5
DHCP ॲड्रेस वाटप किंवा त्रुटी श्रेणी क्लायंट ॲड्रेसिंग किंवा VLAN कॅरेज पुढील पायरी ब्लॉक करत आहे का? 5 6
RADIUS RADIUS किंवा MAB संबंधित श्रेणी हा साइन-ऑन स्प्लॅशचा प्रयत्न आहे का, आणि क्लाउडला सर्व्हरकडून प्रतिसाद मिळाला का? 4 5
स्प्लॅश लॉगिन प्रयत्नाचा रेकॉर्ड लॉगिन वेळ, SSID, क्लायंट आणि गेटवे आयडेंटिफायर्स, अधिक ऑथोरायझेशन स्थिती नोंदवलेला निकाल प्रत्यक्ष ठिकाणच्या रिपोर्टशी जुळतो का? 9

Cisco Meraki त्याच्या दस्तऐवजीकरण केलेल्या Dashboard API द्वारे स्प्लॅश लॉगिन प्रयत्नांची माहिती देखील उघड करते. या रेकॉर्डमध्ये लॉगिनची वेळ, SSID, गेटवे-डिव्हाइस MAC, क्लायंट MAC आणि ऑथोरायझेशन स्थिती समाविष्ट असते. बहु-साइट IT टीम्ससाठी, यामुळे केवळ एका अनुभवावर विसंबून न राहता घटनात्मक पुरावा म्हणून ठिकाणच्या तिकिटाला ऑथेंटिकेशनच्या परिणामाशी जुळवणे शक्य होते. 9

तुम्ही निश्चित केलेले स्प्लॅश पेज पुन्हा निकामी होण्यापासून कसे वाचवाल?

तुमच्या Guest WiFi सेवा मालकासह एक लहान ऑपरेटिंग रनबुक तयार ठेवा. या रनबुकमध्ये चाचणी SSID, चाचणी डिव्हाइस, ऑथोरायझेशन रद्द करण्याची प्रक्रिया, अपेक्षित पेज होस्ट, प्री-ऑथेंटिकेशन अवलंबित्व, RADIUS मालकी आणि एस्केलेशन संपर्क यांची स्पष्ट माहिती असावी. तसेच यामध्ये क्लाउड कंट्रोलर अनुपलब्ध असतानाच्या डिप्लोयमेंटच्या कंट्रोलर-डिस्कनेक्शन वर्तनाचा देखील उल्लेख असावा. Cisco Meraki क्लाउड कंट्रोलर अनुपलब्ध असतानाचे ओपन, रिस्ट्रिक्टेड आणि डिफॉल्ट वर्तन दस्तऐवजीकरण करते. 3

संमती, ब्रँडिंग आणि प्रवेश धोरणासाठी Captive Portal वापरणाऱ्या मालमत्तांसाठी, ऑफलाइन पेजला नियंत्रित ॲप्लिकेशन घटक म्हणून समजा. Purple ऑफलाइन, ऑनलाइन आणि कामाच्या वेळेव्यतिरिक्तचे पेज प्रकार प्रदान करते. प्रवेश प्रवासातील बदलांसाठी प्रकाशित केलेल्या Splash Pages मार्गदर्शकाचा आणि अपलोड केलेल्या ॲसेट आणि पूर्वावलोकनासाठी HTML editor मार्गदर्शकाचा वापर करा. दुसऱ्या दिवसाचे निदान आणि नवीन कॉन्फिगरेशन या गोष्टी वेगवेगळ्या ठेवा. 7 8

जेव्हा ही एखाद्या विशिष्ट ठिकाणी वारंवार उद्भवणारी समस्या बनते, तेव्हा अंदाज लावण्याऐवजी पुराव्यांचे केंद्रीकरण करा. घटनेची वेळ, क्लायंट MAC, AP किंवा MX, SSID, ऑथोरायझेशन स्थिती, इव्हेंट-लॉग श्रेणी आणि RADIUS सर्व्हर प्रतिसाद यांचा परस्पर संबंध जोडा. हा दृष्टिकोन Hospitality, Retail आणि Transport साइट्ससाठी योग्य ठरतो, जिथे स्थानिक टीम्सना स्पष्ट एस्केलेशन मर्यादा हवी असते आणि नेटवर्क टीमला पुन्हा तपासता येण्याजोगा पुरावा हवा असतो. अधिक विस्तृत सेवा रचनेसाठी, Guest WiFi Management: Smart Authentication & Segmentation पहा.

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

Purple सध्याच्या Cisco Meraki ॲक्सेस पॉइंट्ससह काम करते का?

होय. Purple गेस्ट WiFi डिप्लॉयमेंटला सपोर्ट करते जे Cisco Meraki सह सध्याच्या इन्फ्रास्ट्रक्चरवर काम करू शकते. हे मार्गदर्शक Meraki स्प्लॅश अपयशाच्या दुसऱ्या दिवसाच्या निदानाची माहिती देते. हे नवीन captive portal साठी आवश्यक असलेल्या डिझाइन आणि ऑनबोर्डिंग कामाची जागा घेत नाही. सपोर्टेड पेज प्रकार आणि ॲक्सेस-प्रवासातील बदलांसाठी अधिकृत Purple Splash Pages मार्गदर्शनाचा वापर करा. 7

Meraki स्प्लॅश पेज Purple वर स्थलांतरित करण्यासाठी किती कामाची आवश्यकता असते?

हे काम सध्याचा ऑथेंटिकेशन फ्लो, प्री-ऑथेंटिकेशन डिपेंडन्सी आणि पेज डिझाइनवर अवलंबून असते. सध्याचा पेज होस्ट, वॉल-गार्डन (walled-garden) एंट्रीज, साइन-ऑन पद्धत आणि लॉगिन नंतरचे डेस्टिनेशन यांची पडताळणी करून सुरुवात करा. Purple हे अपलोड केलेले असेट्स आणि लाईव्ह प्रिव्ह्यूसह स्टँडर्ड आणि HTML स्प्लॅश-पेज टेम्पलेट्सना सपोर्ट करते. स्थलांतराचे नियोजन नियंत्रित बदल म्हणून करा, तात्पुरती समस्या निवारण म्हणून नाही. 7 8

Cisco Meraki स्प्लॅश पेज फक्त HTTPS-असलेल्या विनंतीला रिडायरेक्ट करू शकते का?

नाही. Cisco Meraki दस्तऐवज स्पष्ट करतात की त्याचे स्प्लॅश रिडायरेक्शन तेव्हा सुरू होते जेव्हा अनऑथराइज्ड क्लायंट HTTP GET पाठवतो. HTTPS-first ट्रॅफिक एन्क्रिप्टेड असते आणि त्याद्वारे रिडायरेक्ट केले जाऊ शकत नाही. HTTP डेस्टिनेशनसह चाचणी करा, नंतर नेटवर्क-व्यापी स्प्लॅश अपयशापासून क्लायंट ब्राउझरचे वर्तन वेगळे ओळखा. 1 2

कस्टमाइज्ड Meraki स्प्लॅश पेजसाठी कोणत्या वॉल-गार्डन (walled-garden) एंट्रीज आवश्यक आहेत?

वॉल गार्डन सक्रिय असताना त्याने कस्टमाइज्ड स्प्लॅश पेजचा IP ॲड्रेस आणि/किंवा URL ला परवानगी दिली पाहिजे. त्यानंतर पेजला खरोखर आवश्यक असणाऱ्या अतिरिक्त प्री-ऑथेंटिकेशन एंडपॉइंट्सनाच फक्त परवानगी द्या. Cisco Meraki हे IP ॲड्रेस, रेंजेस आणि वाईल्डकार्ड डोमेन्ससह होस्टनेम्सना सपोर्ट करते. त्या पडताळणीऐवजी थेट अनिर्बंध इंटरनेट प्रवेश देऊ नका. 3

Meraki साइन-ऑन स्प्लॅश पेज RADIUS सह टाईम आउट का होते?

टाईम आउटचा अर्थ सहसा असा होतो की Cisco Meraki Dashboard क्लाउडला कॉन्फिगर केलेल्या RADIUS सर्व्हरकडून प्रतिसाद मिळू शकत नाही. पब्लिक रीचेबिलिटी, सध्याच्या Dashboard सोर्स रेंजेस, मॅचिंग RADIUS क्लायंट शेअर केलेले सिक्रेट्स आणि PAP सपोर्ट तपासा. स्थानिक AP किंवा MX हा स्प्लॅश RADIUS विनंत्यांचा सोर्स नसतो. 4

आम्ही विविध ठिकाणी होणारे स्प्लॅश लॉगिन अपयश कसे मॉनिटर करू शकतो?

प्रभावित क्लायंट आणि वेळेची विंडो फिल्टर करण्यासाठी Meraki इव्हेंट लॉग वापरा, नंतर Auth, DHCP आणि RADIUS श्रेणींशी संबंध जोडा. Cisco ची splash-login-attempts API ही लॉगिनची वेळ, SSID, गेटवे डिव्हाइस, क्लायंट आयडेंटिफायर आणि ऑथरायझेशन स्टेटस परत करू शकते. हे मल्टि-साइट सपोर्ट डेस्कसाठी एक सुसंगत पुरावा रेकॉर्ड तयार करते. 5 9

संदर्भ

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

Captive portal

एक नियंत्रित प्री-ऑथेंटिकेशन नेटवर्क स्थिती जी कॉन्फिगर केलेले splash इंटरॲक्शन पूर्ण करेपर्यंत क्लायंटला प्रतिबंधित करते.

जेव्हा एखादे डिव्हाइस Guest WiFi ला जोडले जाते परंतु त्याला अद्याप सामान्य नेटवर्क ऍक्सेस मिळालेला नसतो, तेव्हा तुम्ही captive portal ट्रबलशूट करता.

Splash authorisation

Cisco Meraki स्थिती जी क्लायंटने splash आवश्यकता पूर्ण केली आहे की नाही आणि लागू असल्यास, ते ऑथरायझेशन किती काळ वैध राहील याची नोंद ठेवते.

पूर्वी कार्यरत असलेले डिव्हाइस पुन्हा splash पेज प्राप्त करत नसल्यास सर्वप्रथम हे तपासा.

Walled garden

splash ऑथेंटिकेशन पूर्ण करण्यापूर्वी अनऑथराइज्ड क्लायंट ज्या IP addresses, रेंजेस आणि होस्टनेम्सपर्यंत पोहोचू शकतो त्यांची प्रतिबंधित यादी.

जेव्हा एखाद्या कस्टम पेजमध्ये ऍसेट्स, फॉर्म बिहेवियर किंवा अन्य वैध प्री-ऑथेंटिकेशन डिपेंडन्सीची कमतरता असते तेव्हा याचे पुनरावलोकन करा.

Splash frequency

कॉन्फिगर केलेले इंटरव्हल जे क्लायंटला किती वेळा splash पेज दाखवले जावे हे नियंत्रित करते.

पॉलिसी बदलल्यानंतरही डिव्हाइस ऑथराइज्ड का राहते किंवा वारंवार प्रॉम्प्ट का केले जाते हे समजून घेण्यास हे मदत करते.

HTTP redirect trigger

अनऑथराइज्ड क्लायंटचे HTTP GET ज्याला Cisco Meraki splash रीडायरेक्ट प्रक्रिया सुरू करण्यासाठी इंटरसेप्ट करते.

रीडायरेक्ट इनिशिएशनला HTTPS-first ब्राउझर विनंतीपासून वेगळे करण्यासाठी नियंत्रित HTTP चाचणी वापरा.

HTTPS-first request

splash ऑथरायझेशनपूर्वी एन्क्रिप्टेड HTTPS डेस्टिनेशनपर्यंत पोहोचण्याचा क्लायंटचा प्रयत्न.

Cisco Meraki दस्तऐवज स्पष्ट करतात की हा ट्रॅफिक HTTP splash मेकॅनिझमद्वारे रीडायरेक्ट केला जाऊ शकत नाही, ज्यामुळे हे पेज टाईमआउट सारखे दिसू शकते.

RADIUS

Remote Authentication Dial-In User Service, हा प्रोटोकॉल येथे केंद्रीय व्यवस्थापित ऑथेंटिकेशन सर्व्हरद्वारे sign-on splash क्रेडेंशियल्सची पडताळणी करण्यासाठी वापरला जातो.

sign-on पेज लोड झाल्यानंतर परंतु ऑथेंटिकेशन नाकारले गेल्यावर किंवा टाईमआउट झाल्यावर याचा तपास करा.

PAP

Password Authentication Protocol, ग्राहक-होस्ट केलेल्या RADIUS सर्व्हरसह sign-on splash वापरासाठी Cisco Meraki दस्तऐवजीकरण केलेली ऑथेंटिकेशन पद्धत.

समस्येला सामान्य सर्व्हर आऊटेज मानण्यापूर्वी RADIUS पॉलिसी PAP ला परवानगी देते की नाही याची खात्री करा.

Auth event

Cisco Meraki डॅशबोर्डवरील event-log कॅटेगरी जी splash-page ऑथेंटिकेशन ऍक्टिव्हिटीसाठी वापरली जाते.

क्लायंट फ्लो कोणत्या टप्प्यावर थांबला हे शोधण्यासाठी असोसिएशन, DHCP आणि RADIUS रेकॉर्ड्ससह हे वाचा.

802.1X

एंटरप्राइझ WiFi प्रमाणीकरणासाठी वापरली जाणारी पोर्ट-आधारित नेटवर्क ऍक्सेस कंट्रोल फ्रेमवर्क, जी या मार्गदर्शकामध्ये वर्णन केलेल्या RADIUS-बॅक्ड साइन-ऑन स्प्लॅश फ्लोपेक्षा वेगळी आहे.

802.1X इव्हेंट रेकॉर्ड्सला ब्राउझर-आधारित sign-on splash पेज लोड झाल्याचा पुरावा म्हणून समजण्याची चूक करू नका.

सोडवलेली उदाहरणे

उदाहरणादाखल हॉस्पिटॅलिटीचे दृश्य: एका २०० खोल्यांच्या हॉटेलला चेक-इन केलेल्या पाहुण्यांना कोणताही त्रास न देता, अधूनमधून येणाऱ्या Guest WiFi splash रिपोर्टचे निदान करणे आवश्यक आहे.

एक चाचणी हँडसेट निवडा आणि त्याचा MAC address, SSID, सर्व्हिंग ऍक्सेस पॉईंट आणि स्थानिक वेळ नोंदवा. असोसिएशन आणि वैध ऍड्रेसिंगची खात्री करा, नंतर client splash स्थिती तपासा. जेव्हा नवीन चाचणीची आवश्यकता असेल तेव्हा केवळ त्याच हँडसेटसाठी ऑथरायझेशन रद्द करा. HTTP चाचणी चालवा आणि जुळणारे Auth, DHCP आणि RADIUS पुरावे तपासा. मोजता येण्याजोगा रिलीज रेकॉर्ड म्हणजे एक ऑथराइज्ड चाचणी क्लायंट, अपेक्षित ऑथरायझेशनची मुदत समाप्ती आणि प्रत्येक चेकपॉइंटसाठी दस्तऐवजीकरण केलेले निकाल.

उदाहरणादाखल रिटेलचे दृश्य: स्टोअरचे कस्टम प्री-ऑथेंटिकेशन पेज उघडते परंतु कंटेंट बदलल्यानंतर त्याचे sign-on घटक गमावून बसते.

लॉगिन करण्यापूर्वी संपूर्ण इंटरनेट उपलब्ध करू नका. अनऑथराइज्ड चाचणी डिव्हाइसवर पेज स्वतः लोड होत असल्याची खात्री करा, त्यानंतर त्याच्या आवश्यक प्री-ऑथेंटिकेशन एंडपॉइंट्सची यादी तयार करा. पेज होस्ट आणि प्रत्येक आवश्यक ऍसेट किंवा आयडेंटिटी डिपेंडन्सीची तुलना walled-garden पॉलिसीशी करा. तोच क्लायंट वापरून पुन्हा चाचणी घ्या आणि splash स्थिती, Auth टाइमलाइन आणि ऑथरायझेशन निकाल कॅप्चर करा. मोजता येणारा परिणाम म्हणजे प्री-ऑथेंटिकेशन ऍक्सेसचा कोणताही अवाजवी विस्तार न करता पूर्ण झालेला sign-on फ्लो.

स्रोत

  1. Cisco Meraki: Splash Page Traffic Flow and Troubleshooting
  2. Cisco Meraki: Troubleshooting Splash Page Appearance Frequency
  3. Cisco Meraki: Splash Page Overview
  4. Cisco Meraki: Configuring RADIUS Authentication with a Sign-On Splash Page
  5. Cisco Meraki: How to Use the Meraki Event Log
  6. Cisco Meraki: Common Wireless Event Log Messages and Issues
  7. Purple: Splash Pages
  8. Purple: Splash Page Editor - HTML
  9. Cisco Meraki Dashboard API: Get Network Splash Login Attempts

या मालिकेमध्ये पुढे वाचा

Ubiquiti UniFi guest portal redirection होत नाही: कारणे आणि उपाय

ही मार्गदर्शिका guest state, redirect, pre-authorisation route आणि controller authorisation यांचा अनुक्रमे मागोवा घेऊन UniFi guest portal redirect बिघाड वेगळा करते. हे वेन्यू IT टीम्सना guest-network विरुद्ध Hotspot गोंधळ, बाह्य portal हँड-ऑफ, सद्य UniFi OS खाते आवश्यकता आणि DNS आयसोलेशन चाचणीचे निराकरण करण्यासाठी एक विश्वसनीय पद्धत प्रदान करते.

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

Enterprise Guest WiFi सेटअप मार्गदर्शक: VLAN विभागणी, सुरक्षा आणि Captive Portals

हे तांत्रिक मार्गदर्शक IT टीम्सना VLAN विभागणी, फायरवॉल पॉलिसी आणि captive portal चा वापर करून Guest WiFi एक नियंत्रित इंटरनेट - ऍक्सेस सेवा म्हणून कसे सेट करावे हे दर्शवते. हे मार्गदर्शक कर्मचारी, पेमेंट आणि ऑपरेशनल सिस्टम्सच्या सुरक्षिततेची सीमा कमकुवत न करता Purple चे नोंदणी फॉर्म्स आणि ऑनबोर्डिंग नियंत्रणे पाहुण्यांना एक सुयोग्य अनुभव कसा देतात हे देखील स्पष्ट करते.

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

Starlink वर Captive Portal कसे सेट करावे: सागरी, वाहतूक आणि दुर्गम क्षेत्रांसाठी मार्गदर्शिका

ही तांत्रिक मार्गदर्शिका सुरक्षित, GDPR-सुसंगत guest WiFi साठी captive portal तैनात करण्यासाठी Starlink च्या मूळ CGNAT मर्यादा कशा बायपास करायच्या हे स्पष्ट करते. यामध्ये सागरी, वाहतूक आणि दुर्गम कॉर्पोरेट क्षेत्रांसाठी नेटवर्क आर्किटेक्चर, VLAN विभागणी आणि क्लाउड RADIUS एकत्रीकरण समाविष्ट आहे.

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

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

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