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

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