पब्लिक WiFi चे ट्रबलशूटिंग: 'Connected, No Internet' आणि स्प्लॅश पेज रिडायरेक्शन अपयश सोडवणे

Purple कडून या तांत्रिक माहितीमध्ये आपले स्वागत आहे. आज आपण एंटरप्राइज वायरलेस नेटवर्किंगमधील सर्वात कायमस्वरूपी, सर्वात जास्त गैरसमज असलेल्या समस्यांपैकी एका समस्येचे निराकरण करत आहोत: guest WiFi captive portal जे लोड होण्यास स्पष्टपणे नकार देते. तुम्ही या परिस्थितीचा अनुभव घेतला असेल. एखादा पाहुणा तुमच्या हॉटेलमध्ये, तुमच्या रिटेल स्टोअरमध्ये, तुमच्या स्टेडियममध्ये किंवा तुमच्या कॉन्फरन्स सेंटरमध्ये येतो. ते WiFi नेटवर्कमध्ये सामील होतात. काहीही घडत नाही. कोणतेही लॉगिन पेज नाही. इंटरनेट नाही. फक्त फिरणारे आयकॉन आणि वाढती निराशा. वेन्यू ऑपरेशन्स डायरेक्टर्स आणि IT मॅनेजर्ससाठी, तो क्षण केवळ एक किरकोळ गैरसोय नसतो. तो तुमच्या पाहुण्यांच्या अनुभवाचे थेट अपयश, फ्रंट-ऑफ-हाउस सपोर्ट कॉल्समध्ये झालेली वाढ आणि तुमच्या वायरलेस इन्फ्रास्ट्रक्चर गुंतवणुकीचे समर्थन करणारा फर्स्ट-पार्टी डेटा कॅप्चर करण्याची गमावलेली संधी दर्शवतो. या माहितीमध्ये, आपण सखोल तांत्रिक बाजू पाहणार आहोत. ऑपरेटिंग सिस्टम लेव्हलवर captive portal डिटेक्शन नेमके कसे काम करते हे आम्ही स्पष्ट करू, बहुतांश कनेक्शन अपयशांसाठी कारणीभूत असलेली सहा मूळ कारणे शोधू आणि तुम्हाला एक व्यावहारिक, कृती करण्यायोग्य ट्रबलशूटिंग फ्रेमवर्क देऊ जे तुम्ही आजच तुमच्या IT टीमकडे सोपवू शकता. चला यंत्रणेपासून सुरुवात करूया. बहुतेक लोक captive portal कडे केवळ एक लॉगिन पेज म्हणून पाहतात. हे प्रत्यक्षात नेटवर्क-लेव्हल ट्रॅफिक इंटरसेप्शन मेकॅनिझम आहे आणि जेव्हा गोष्टी बिघडतात तेव्हा हा फरक अत्यंत महत्त्वाचा ठरतो. हा तो क्रम आहे. पाहुण्याचे डिव्हाइस तुमच्या guest SSID मध्ये सामील होते आणि DHCP द्वारे IP ॲड्रेस प्राप्त करते. त्या वेळी, ऑपरेटिंग सिस्टम युझरने ब्राउझर उघडण्याची वाट पाहत नाही. बॅकग्राउंडमध्ये, एक सिस्टम सर्व्हिस त्वरित एका वेंडर-नियंत्रित प्रोब URL कडे अनएनक्रिप्टेड HTTP GET रिक्वेस्ट पाठवते. Apple डिव्हाइसेस captive.apple.com वर क्वेरी करतात. Android डिव्हाइसेस connectivitycheck.gstatic.com वर क्वेरी करतात. Windows डिव्हाइसेस msftconnecttest.com वर क्वेरी करतात. Firefox कडे detectportal.firefox.com वर स्वतःचा प्रोब असतो. जर नेटवर्ककडे ओपन इंटरनेट ॲक्सेस असेल, तर हे प्रोब्स त्यांचे अपेक्षित प्रतिसाद परत करतात आणि ऑपरेटिंग सिस्टम निष्कर्ष काढते की सर्वकाही ठीक आहे. परंतु guest नेटवर्कवर, तुमचा वायरलेस गेटवे किंवा कंट्रोलर तो HTTP प्रोब इंटरनेटवर पोहोचण्यापूर्वीच इंटरसेप्ट करतो. अपेक्षित प्रतिसादाऐवजी, गेटवे तुमच्या captive portal स्प्लॅश पेजकडे निर्देशित करणारे HTTP 307 रीडायरेक्ट परत करतो. ऑपरेटिंग सिस्टम अनपेक्षित रीडायरेक्ट शोधते, तिला समजते की ती एका captive portal च्या मागे आहे आणि लॉगिन पेज प्रदर्शित करण्यासाठी सँडबॉक्स्ड ब्राउझर विंडो - ज्याला सहसा Captive Network Assistant म्हटले जाते - उघडते. हा सुरळीत चालणारा मार्ग आहे. आता आपण ते बिघडण्याच्या सहा मार्गांबद्दल बोलूया. मूळ कारण क्रमांक एक: DHCP पूल संपणे. हाय-डेन्सिटी इव्हेंट्समध्ये हा एक छुपा धोका आहे. जर तुम्ही मानक स्लॅश-24 सबनेटवर दोन हजार उपस्थितांसह परिषद चालवत असाल, तर तुमच्याकडे २५४ वापरण्यायोग्य IP पत्ते आहेत. जर तुमची DHCP लीझ वेळ डीफॉल्ट २४ तास सेट केली असेल, तर दारे उघडल्यापासून काही मिनिटांतच तो पूल संपून जाईल. त्यानंतरचा प्रत्येक कनेक्शनचा प्रयत्न Captive Portal प्रक्रिया सुरू होण्यापूर्वीच अयशस्वी होतो. याचे निराकरण सोपे आहे: हाय-टर्नओव्हर वातावरणासाठी पाहुण्यांची DHCP लीझ वेळ १५ ते ३० मिनिटांच्या दरम्यान सेट करा, आणि केवळ एकूण उपस्थित लोकांच्या संख्येसाठीच नाही, तर कमाल समवर्ती युजर्ससाठी तुमचे सबनेट योग्य आकाराचे करा. मूळ कारण क्रमांक दोन: DNS इंटरसेप्शन अयशस्वी होणे. Captive Portal रिडायरेक्ट हा गेटवेद्वारे HTTP प्रोब इंटरसेप्ट करण्यावर अवलंबून असतो. परंतु प्रोबसाठी प्रथम DNS लूकअप आवश्यक आहे. जर तुमचे DNS कॉन्फिगरेशन प्री-ऑथेंटिकेटेड क्लायंट्सना बाह्य डोमेन नावे शोधण्याची परवानगी देत नसेल, तर प्रोब कधीही सुरू होत नाही. तुमची फायरवॉल पॉलिसी अनऑथेंटिकेटेड क्लायंट्सकडून स्पष्टपणे DNS क्वेरींना परवानगी देत असल्याची खात्री करा, आणि चाचणी डिव्हाइसवर पॅकेट कॅप्चर चालवून तुमचे DNS इंटरसेप्शन काम करत असल्याचे तपासा. मूळ कारण क्रमांक तीन: अपूर्ण वॉल्ड गार्डन. वॉल्ड गार्डन - ज्याला प्री-ऑथेंटिकेशन ऍक्सेस कंट्रोल लिस्ट देखील म्हटले जाते - अनऑथेंटिकेटेड पाहुणे कोणत्या बाह्य डोमेनवर पोहोचू शकतात हे परिभाषित करते. जर तुमचे पोर्टल स्प्लॅश पेज अशा CDN मधील ॲसेट्स लोड करत असेल जे वॉल्ड गार्डनमध्ये नाही, तर ते पेज रिकाम्या स्क्रीनसारखे दिसते. जर तुम्ही Google, Apple, किंवा Facebook द्वारे सोशल लॉगिन ऑफर करत असाल, तर ते प्रदाते वापरत असलेले प्रत्येक OAuth डोमेन व्हाईटलिस्ट केलेले असणे आवश्यक आहे. आणि सर्वात महत्त्वाचा मुद्दा म्हणजे: सोशल आयडेंटिटी प्रदाते त्यांच्या CDN IP श्रेणी आणि ऑथेंटिकेशन डोमेन नियमितपणे अपडेट करतात. सहा महिन्यांपूर्वी उत्तम प्रकारे काम करणारे वॉल्ड गार्डन आज बंद पडलेले असू शकते. त्रैमासिक वॉल्ड गार्डन ऑडिट शेड्यूल करा आणि तुमचे हार्डवेअर सपोर्ट करत असेल तिथे वाईल्डकार्ड डोमेन स्नूपिंग वापरा. Cisco Meraki, HPE Aruba, Ruckus, आणि Juniper Mist वर हे नेटिव्हली उपलब्ध आहे. मूळ कारण क्रमांक चार: HSTS द्वारे रिडायरेक्ट ब्लॉक करणे. HTTP स्ट्रिक्ट ट्रान्सपोर्ट सिक्युरिटी, किंवा HSTS, ही ब्राउझर सुरक्षा पॉलिसी आहे जी केवळ HTTPS वर विशिष्ट डोमेनवर कनेक्शन सक्तीने लागू करते. जर एखाद्या पाहुण्याचे डिव्हाइस HSTS-प्रिलोड केलेल्या डोमेनशी - ज्यामध्ये अक्षरशः प्रत्येक मुख्य वेबसाइट समाविष्ट आहे - संपर्क साधण्याचा प्रयत्न करते आणि तुमचे गेटवे पोर्टलवर रिडायरेक्ट करण्यासाठी त्या HTTPS विनंतीला इंटरसेप्ट करण्याचा प्रयत्न करते, तेव्हा ब्राउझरला सर्टिफिकेट जुळत नसल्याचे आढळते. ते बायपास न करता येणारी सुरक्षा चेतावणी दर्शवते आणि रिडायरेक्ट पूर्णपणे ब्लॉक करते. याचे योग्य समाधान म्हणजे कधीही HTTPS इंटरसेप्शनचा प्रयत्न न करणे. तुमच्या गेटवेने केवळ अनएनक्रिप्टेड HTTP कॅनरी प्रोब्स रिडायरेक्ट केले पाहिजेत. दीर्घकालीन मानकांवर आधारित उपाय म्हणजे RFC 8910, जे DHCP पर्याय ११४ परिभाषित करते. हा पर्याय तुमच्या DHCP सर्व्हरला थेट क्लायंट डिव्हाइसवर Captive Portal URL ची जाहिरात करण्याची परवानगी देतो, ज्यामुळे HTTP रिडायरेक्शनची आवश्यकता पूर्णपणे बायपास होते. iOS 14 आणि Android 11 आणि त्यावरील व्हर्जन याला नेटिव्हली सपोर्ट करतात. पाचवे मूळ कारण: अतिथीच्या डिव्हाइसवर सक्रिय VPN असणे. VPN डिव्हाइसवरील सर्व ट्रॅफिक एन्क्रिप्ट करते आणि आपल्या गेटवेवर पोहोचण्यापूर्वी ते बाह्य बोगद्याद्वारे (external tunnel) पाठवते. आपल्या गेटवेला HTTP चाचणी (probe) कधीच दिसत नाही. Captive Portal ओळखण्याची प्रक्रिया कधीच सुरू होत नाही. अतिथीला कोणतेही लॉगिन पेज आणि इंटरनेट दिसत नाही. अतिथीसाठी यावरील उपाय सोपा आहे: VPN बंद करा, पोर्टलशी कनेक्ट व्हा आणि नंतर पुन्हा VPN सुरू करा. आपल्या फ्रंट-ऑफ-हाउस कर्मचाऱ्यांसाठी, जेव्हा एखादा अतिथी कनेक्शनच्या समस्येबद्दल सांगेल, तेव्हा त्यांनी विचारलेला हा पहिला प्रश्न असावा. सहावे मूळ कारण: MAC ॲड्रेस रँडमायझेशनमुळे सेशन सातत्य (session persistence) खंडित होणे. आधुनिक iOS आणि Android डिव्हाइसेस प्रायव्हसी फीचर म्हणून डीफॉल्टनुसार रँडमायझ्ड MAC ॲड्रेसेस वापरतात. जेव्हा एखादे डिव्हाइस नेटवर्कशी कनेक्ट होते, तेव्हा ते प्रत्येक वेळी भिन्न MAC ॲड्रेस सादर करू शकते. Captive Portal सेशनची स्थिती MAC ॲड्रेसद्वारे ट्रॅक केली जात असल्याने, ज्या अतिथीने एका तासापूर्वी ऑथेंटिकेशन केले होते, त्याच्या डिव्हाइसचा MAC बदलल्यानंतर त्याला पुन्हा लॉगिन पेज दिसू शकते. यावर अतिथीच्या बाजूने असलेला उपाय म्हणजे नेटवर्क सेटिंग्समध्ये आपल्या विशिष्ट SSID साठी Private Address बंद करणे. ऑपरेटरच्या बाजूने असलेला उपाय म्हणजे प्रोफाइल-आधारित ऑथेंटिकेशन लागू करणे - जसे की Passpoint आणि 802.1X द्वारे OpenRoaming - जे MAC ॲड्रेसेसऐवजी क्रेडेंशियल्सचा वापर करून लेयर २ वर ऑथेंटिकेशन करते, ज्यामुळे रँडमायझेशनचा कोणताही फरक पडत नाही. आता आपण अंमलबजावणीबद्दल बोलूया. प्रत्यक्ष व्यवहारात योग्यरित्या कॉन्फिगर केलेले captive portal डिप्लॉयमेंट नेमके कसे दिसते? आपल्या DHCP आर्किटेक्चरपासून सुरुवात करा. २०० पेक्षा जास्त एकाच वेळी वापरल्या जाणाऱ्या डिव्हाइसेसची अपेक्षा असलेल्या कोणत्याही ठिकाणासाठी (venue), सिंगल स्लॅश-२४ (slash-24) सबनेट वापरणे टाळा. स्लॅश-२२ (slash-22) किंवा त्याहून मोठे सबनेट वापरा, आणि आपल्या ठिकाणाच्या ड्वेल प्रोफाइलनुसार (dwell profile) लीजची वेळ सेट करा. हॉटेल लीजची वेळ ८ तास सेट करते. स्टेडियम लीजची वेळ ३ तास सेट करते. शॉपिंग सेंटर लीजची वेळ ९० मिनिटे सेट करते. कॉन्फरन्स सेंटर लीजची वेळ ३० मिनिटे सेट करते. यानंतर, प्रत्येक मोठ्या इव्हेंटपूर्वी आपल्या वॉल्ड गार्डनची (walled garden) पडताळणी करा. किमान आवश्यक नोंदी पुढीलप्रमाणे आहेत: आपल्या पोर्टलचे फुली क्वालिफाइड डोमेन नेम (fully qualified domain name) आणि त्याशी संबंधित सर्व CDN डोमेन्स, Apple, Google, Windows, आणि Firefox साठीचे captive portal डिटेक्शन URLs आणि आपण सपोर्ट करत असलेल्या प्रत्येक सोशल लॉगिन प्रोव्हाइडरचे OAuth डोमेन्स. Purple च्या प्लॅटफॉर्मवर, आम्ही आमच्या क्लाउड-मॅनेज्ड सेवेचा भाग म्हणून या वॉल्ड गार्डन नोंदी स्वयंचलितपणे देखरेख आणि अपडेट करतो, ज्यामुळे आपल्या टीमवरील मॅन्युअल देखभालीचा भार कमी होतो. आपल्या पोर्टल सर्टिफिकेटसाठी, मान्यताप्राप्त सर्टिफिकेट ऑथॉरिटीकडून सार्वजनिकरित्या विश्वसनीय असलेले TLS सर्टिफिकेट वापरा. सेल्फ-साइन केलेले सर्टिफिकेट्स प्रत्येक डिव्हाइसवर ब्राउझर वॉर्निंग ट्रिगर करतील. सर्टिफिकेट्स संपण्यापूर्वी त्यांचे नूतनीकरण करा - मुदत संपलेले सर्टिफिकेट हे अचानक, संपूर्ण ठिकाणभर पोर्टल बंद पडण्याचे सर्वात सामान्य कारणांपैकी एक आहे. एक चूक जी अनेक आयटी टीम्सच्या बाबतीत घडते: आधीच ऑथेंटिकेट झालेल्या डिव्हाइसवरून पोर्टलची चाचणी घेणे. आपल्या डिव्हाइसचे सेशन अजूनही सक्रिय असते, त्यामुळे आपण पोर्टल पूर्णपणे बायपास करता आणि सर्व काही व्यवस्थित काम करत असल्याचा निष्कर्ष काढता. नेहमी नवीन, अन-ऑथेंटिकेटेड स्थितीत असलेल्या डिव्हाइसवरून चाचणी घ्या - एकतर नवीन डिव्हाइस, किंवा असे डिव्हाइस ज्यामध्ये आपण नेटवर्क 'फॉर्गोट' केले आहे आणि WiFi प्रोफाइल साफ केले आहे.मी तुम्हाला हे नियम स्पष्ट करणारी दोन वास्तविक जगातील उदाहरणे देतो. पहिले उदाहरण: मध्य लंडन मधील एक ३५० खोल्यांचे हॉटेल. ही प्रॉपर्टी अतिथी WiFi साठी सिंगल स्लॅश-२४ सबनेट चालवत होती. एका मोठ्या परिषदेदरम्यान, ४०० प्रतिनिधी एकाच वेळी पोहोचले. २० मिनिटांत, DHCP पूल संपला. अतिथींनी कनेक्ट झाल्याचे सांगितले परंतु ते Captive Portal किंवा इंटरनेटपर्यंत पोहोचू शकत नव्हते. यावर तात्काळ उपाय म्हणजे सबनेटचा स्लॅश-२२ पर्यंत विस्तार करणे, ज्यामुळे १,०२२ वापरण्यायोग्य पत्ते मिळाले, आणि लीज वेळ २४ तासांवरून ८ तासांवर आणणे. दीर्घकालीन उपाय म्हणजे Purple चे क्लाउड-व्यवस्थापित Captive Portal लागू करणे, जे रिअल-टाइममध्ये DHCP पूलच्या वापराचे निरीक्षण करते आणि पूल संपण्यापूर्वी नेटवर्क टीमला अलर्ट करते. बदल केल्याच्या ४८ तासांच्या आत पोर्टल अपयशाचा दर जवळजवळ शून्यावर आला. दुसरे उदाहरण: २०० स्टोअर्स असलेली एक मोठी रिटेल साखळी. या साखळीने त्यांच्या अतिथी पोर्टलवर Google आणि Facebook द्वारे सोशल लॉगिनचा वापर केला. Google ने त्याचे OAuth इन्फ्रास्ट्रक्चर अपडेट केल्यानंतर, नवीन ऑथेंटिकेशन डोमेन वॉल्ड गार्डन (walled garden) मध्ये नव्हते. अतिथी पोर्टल पेजपर्यंत पोहोचू शकत होते परंतु सोशल लॉगिन बटणांवर क्लिक केल्यावर रिकामी स्क्रीन दिसत होती. साखळीच्या IT टीमने वॉल्ड गार्डन मधील ही त्रुटी शोधण्यापूर्वी समस्येचे निदान करण्यात दोन दिवस घालवले. एकदा त्रुटी समजल्यावर ती दुरुस्त करण्यासाठी केवळ १० मिनिटे लागली. यातून मिळालेला धडा: क्लाउड-आधारित OAuth प्रदात्यांसाठी तुमच्या वॉल्ड गार्डनमध्ये IP पत्ते कधीही हार्डकोड करू नका. वाइल्डकार्ड डोमेन एंट्री वापरा आणि त्रैमासिक आधारावर त्यांचे पुनरावलोकन करा. आता वेन्यू IT टीम्सकडून आम्हाला नियमितपणे विचारले जाणारे काही जलद प्रश्न पाहूया. पोर्टल iPhones वर काम करते पण Android डिव्हाइसेसवर का नाही? Android त्याचे प्रोब URL म्हणून connectivitycheck.gstatic.com वापरते. जर तो डोमेन तुमच्या फायरवॉलद्वारे ब्लॉक केला असेल किंवा तुमच्या वॉल्ड गार्डनमध्ये नसेल, तर Android डिव्हाइसेस कधीही पोर्टल ट्रिगर करत नाहीत. तो स्पष्टपणे जोडा. एक अतिथी सांगतो की पोर्टल लोड झाले परंतु लॉग इन केल्यानंतर ते ऑनलाइन जाऊ शकत नाहीत. हे सहसा RADIUS ऑथरायझेशन अपयशी ठरल्यामुळे होते. तुमचा RADIUS सर्व्हर वायरलेस कंट्रोलरवरून पोहोचण्यायोग्य आहे का ते तपासा, दोन्ही बाजूंनी शेअर केलेला सिक्रेट कोड मॅच होत असल्याची खात्री करा, आणि Access-Reject मेसेजेससाठी RADIUS लॉगचे पुनरावलोकन करा. काही मिनिटांनंतर वारंवार लॉग आउट होणाऱ्या अतिथींना आम्ही कसे हाताळू? तुमची आयडल टाइमआउट (idle timeout) सेटिंग तपासा. अनेक कंट्रोलर्स डिफॉल्टनुसार ५ मिनिटांचा आयडल टाइमआउट वापरतात, जो संवादांच्या दरम्यान स्लीप मोडमध्ये जाणाऱ्या मोबाईल डिव्हाइसेससाठी अत्यंत कमी आहे. हॉस्पिटॅलिटी आणि रिटेल वातावरणासाठी आयडल टाइमआउट किमान ३० मिनिटांवर सेट करा. आजच्या ब्रीफिंगमधील मुख्य मुद्द्यांचा सारांश सांगायचा तर. अतिथी WiFi Captive Portal चे अपयश सहा श्रेणींमध्ये येते: DHCP पूल संपणे, DNS इंटरसेप्शन अयशस्वी होणे, अपूर्ण वॉल्ड गार्डन, HSTS रिडायरेक्ट ब्लॉकिंग, क्लायंट डिव्हाइसवर सक्रिय VPN, आणि MAC address randomisation. प्रत्येकासाठी एक विशिष्ट, चाचणी करण्यायोग्य उपाय आहे. तुमच्या IT टीमसाठी, तात्काळ करायच्या कृती म्हणजे: तुमच्या DHCP लीज वेळा आणि सबनेट आकाराचे ऑडिट करा, तुमच्या सोशल लॉगिन प्रदात्यांच्या सध्याच्या OAuth डोमेनसह तुमच्या वॉल्ड गार्डनची पडताळणी करा, आणि प्रत्येक कॉन्फिगरेशन बदलानंतर नवीन अन-ऑथेंटिकेटेड डिव्हाइसवरून तुमच्या पोर्टलची चाचणी घ्या. तुमच्या दीर्घकालीन रोडमॅपसाठी, परत येणाऱ्या अभ्यागतांसाठी Captive Portal री-ऑथेंटिकेशनचा पर्याय म्हणून OpenRoaming चे मूल्यांकन करा. हे तंत्रज्ञान प्रगत आहे, IEEE 802.1X आणि WPA3-Enterprise अंतर्गत याचे निकष स्थापित केले गेले आहेत आणि Purple आपल्या Connect प्लॅनअंतर्गत कोणत्याही अतिरिक्त सॉफ्टवेअर खर्चाशिवाय हे उपलब्ध करून देते. Purple ८०,००० पेक्षा जास्त ठिकाणी कार्यरत आहे आणि केवळ २०२४ मध्येच आम्ही ४४० दशलक्ष लॉगिन हाताळले आहेत. या माहितीपत्रकात वर्णन केलेले प्रत्येक बिघाड मोड आम्ही पाहिले आहेत – आणि ते रोखण्यासाठी साधने तयार केली आहेत. Purple चे क्लाउड ओव्हरले तुमच्या विद्यमान Cisco Meraki, HPE Aruba, Ruckus किंवा Juniper Mist पायाभूत सुविधांसोबत कसे जोडले जाते हे तुम्हाला पाहायचे असल्यास, purple.ai ला भेट द्या किंवा तुमच्या अकाउंट व्यवस्थापकाशी संपर्क साधा. ऐकल्याबद्दल धन्यवाद.