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

गस्ट WiFi पर कनेक्टेड लेकिन नो इंटरनेट एरर को हल करना

आप यह निदान करने में सक्षम होंगे कि मेहमानों को गेस्ट WiFi पर "कनेक्टेड, नो इंटरनेट" क्यों दिखाई देता है और नए हार्डवेयर के बिना, कॉन्फ़िगरेशन परिवर्तन के साथ कारण को ठीक कर सकेंगे। यह गाइड दिखाता है कि DHCP, वॉल्ड गार्डन और रेट-लिमिट त्रुटियों से DNS टाइमआउट को कैसे अलग किया जाए, फिर उन एक्सेस पॉइंट्स पर एक नजदीकी एंटरप्राइज DNS फ़िल्टर कैसे तैनात किया जाए जिन्हें आप पहले से चला रहे हैं।

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

Video overview

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

पॉडकास्ट ट्रांसक्रिप्ट देखें
गस्ट WiFi पर कनेक्टेड लेकिन नो इंटरनेट एरर को सुलझाना - एक Purple टेक्निकल ब्रीफिंग [परिचय और संदर्भ - लगभग 1 मिनट] Purple टेक्निकल ब्रीफिंग श्रृंखला में आपका स्वागत है। मैं आपका होस्ट हूँ, और आज हम एंटरप्राइज वेन्यू नेटवर्किंग में सबसे लगातार और निराशाजनक समस्याओं में से एक से निपट रहे हैं: गेस्ट WiFi पर "कनेक्टेड, नो इंटरनेट" एरर। यदि आप किसी होटल, रिटेल चेन, स्टेडियम या सम्मेलन केंद्र में WiFi इंफ्रास्ट्रक्चर का प्रबंधन करते हैं, तो आपने इसे ज़रूर देखा होगा। गेस्ट का डिवाइस पूरे सिग्नल बार दिखाता है, यह आपके एक्सेस प्वाइंट से जुड़ा हुआ है, इसे एक IP एड्रेस असाइन किया गया है - और फिर भी ब्राउज़र कुछ भी रिटर्न नहीं करता है। कैप्टिव पोर्टल कभी लोड ही नहीं होता है। गेस्ट फ्रंट डेस्क पर कॉल करता है। आपकी सपोर्ट टीम पिंग टेस्ट चलाती है, कागज़ पर सब कुछ ठीक दिखता है, और फिर भी समस्या बार-बार आती रहती है। बात यह है: एंटरप्राइज डिप्लॉयमेंट में मेरे सामने आने वाले अधिकांश मामलों में, यह कोई हार्डवेयर फॉल्ट नहीं है, कोई फ़ायरवॉल मिसकॉन्फ़िगरेशन नहीं है, और पारंपरिक अर्थों में बैंडविड्थ की समस्या नहीं है। यह एक DNS टाइमिंग इश्यू है - और यह लगभग हमेशा नेटवर्क कंजेशन के कारण होता है। आज मैं आपको समझाना चाहता हूँ कि ऐसा क्यों होता है, इसका सटीक निदान कैसे करें, और एंटरप्राइज DNS फ़िल्टर को डिप्लॉय करने से इस बाधा का स्थायी समाधान कैसे होता है। [टेक्निकल डीप-डाइव - लगभग 5 मिनट] आइए बुनियादी बातों से शुरू करते हैं। जब कोई गेस्ट डिवाइस आपके WiFi नेटवर्क से कनेक्ट होता है, तो सबसे पहली चीज़ जो इसे करने की आवश्यकता होती है - इससे पहले कि वह एक भी वेबपेज लोड कर सके, इससे पहले कि आपका कैप्टिव पोर्टल इसे रीडायरेक्ट कर सके, इससे पहले कि कोई ऑथेंटिकेशन हो सके - DNS के माध्यम से एक डोमेन नेम को IP एड्रेस में रिज़ॉल्व करना है। डोमेन नेम सिस्टम इंटरनेट की फोनबुक है। इसके बिना, आपके डिवाइस के पास यह जानने का कोई तरीका नहीं है कि ट्रैफ़िक कहाँ भेजना है। अब, यहाँ से समस्या शुरू होती है। अधिकांश उपभोक्ता उपकरणों - iPhones, Android हैंडसेट, Windows लैपटॉप - में कैप्टिव पोर्टल डिटेक्शन प्रोब नामक एक इन-बिल्ट मैकेनिज्म होता है। उदाहरण के लिए, iOS पर, डिवाइस एक ज्ञात Apple एंडपॉइंट, जैसे captive.apple.com पर एक HTTP रिक्वेस्ट भेजता है। Android पर, यह connectivitycheck.gstatic.com पर हिट करता है। Windows पर, यह msftconnecttest.com को प्रोब करता है। इन प्रोब्स को यह डिटेक्ट करने के लिए डिज़ाइन किया गया है कि इंटरनेट एक्सेस देने से पहले नेटवर्क को लॉगिन पेज की आवश्यकता है या नहीं। महत्वपूर्ण बिंदु यह है: ये प्रोब्स DNS-डिपेंडेंट हैं। HTTP रिक्वेस्ट भेजने से पहले डिवाइस को सबसे पहले प्रोब एंडपॉइंट के डोमेन नेम को रिज़ॉल्व करना होगा। और उस DNS क्वेरी का एक टाइमआउट होता है - ऑपरेटिंग सिस्टम के आधार पर आमतौर पर एक से पाँच सेकंड के बीच। यदि आपके नेटवर्क पर DNS रिज़ॉल्वर उस समय सीमा के भीतर प्रतिक्रिया नहीं देता है, तो डिवाइस यह निष्कर्ष निकालता है कि नेटवर्क में कोई इंटरनेट कनेक्टिविटी नहीं है, भले ही यह पूरी तरह से जुड़ा हुआ हो और एक वैध IP एड्रेस रखता हो। यही "कनेक्टेड, नो इंटरनेट" एरर है। यह कनेक्टिविटी की विफलता नहीं है - यह DNS प्रतिक्रिया की विफलता है। तो कंजस्टेड (अत्यधिक ट्रैफ़िक वाले) नेटवर्क पर DNS विफल क्यों होता है? यह वह हिस्सा है जो कई टीमों को असमंजस में डाल देता है। DNS क्वेरी डिफ़ॉल्ट रूप से पोर्ट 53 पर UDP के माध्यम से भेजी जाती हैं। UDP एक कनेक्शन-रहित प्रोटोकॉल है - इसमें ट्रांसपोर्ट लेयर पर कोई हैंडशेक, कोई एकनॉलेजमेंट और कोई रीट्रांसमिशन नहीं होता है। यदि नेटवर्क कंजेशन के कारण DNS पैकेट ड्रॉप हो जाता है, तो क्लाइंट बस टाइमआउट समाप्त होने तक प्रतीक्षा करता है और फिर या तो पुनः प्रयास करता है या हार मान लेता है। सैकड़ों या हज़ारों समवर्ती डिवाइस वाले गेस्ट WiFi नेटवर्क पर - जैसे कि मैच के दौरान स्टेडियम, पूरी तरह से भरा हुआ होटल, या कीनोट के दौरान एक कॉन्फ्रेंस सेंटर - अपस्ट्रीम लिंक और DNS रिज़ॉल्वर बहुत तेज़ी से संतृप्त (सैचुरेट) हो सकते हैं। यह समस्या इस तथ्य से और बढ़ जाती है कि गेस्ट नेटवर्क आम तौर पर एक ही अपस्ट्रीम DNS रिज़ॉल्वर साझा करते हैं, जो अक्सर ISP का डिफ़ॉल्ट रिज़ॉल्वर या 8.8.8.8 जैसा सार्वजनिक रिज़ॉल्वर होता है। जब नेटवर्क पर प्रत्येक डिवाइस एक साथ कैप्टिव पोर्टल डिटेक्शन के लिए जांच कर रहा होता है, बैकग्राउंड ऐप अपडेट चला रहा होता है, और सोशल मीडिया तथा स्ट्रीमिंग सेवाओं के लिए DNS क्वेरी कर रहा होता है, तो वह एकल रिज़ॉल्वर एक अड़चन (बॉटलनेक) बन जाता है। क्वेरी प्रतिक्रिया समय सामान्य 50-मिलीसेकंड से कम की सीमा से बढ़कर सैकड़ों या हज़ारों मिलीसेकंड तक पहुँच जाता है। टाइमआउट होने लगते हैं। "कनेक्टेड, कोई इंटरनेट नहीं" वाली त्रुटियाँ आनी शुरू हो जाती हैं। एक द्वितीयक तंत्र भी है जिसे समझना महत्वपूर्ण है: TTL समाप्ति। DNS प्रतिक्रियाओं में एक टाइम टू लिव मान शामिल होता है जो प्राप्तकर्ता डिवाइस को बताता है कि रिज़ॉल्व किए गए IP पते को कितने समय तक कैश करना है। एक कंजस्टेड नेटवर्क पर जहाँ डिवाइस लगातार एसोसिएट और डिसएसोसिएट हो रहे हैं - जो उच्च-घनत्व वाले स्थानों में आम है - कैश की गई प्रविष्टियाँ समाप्त हो जाती हैं और उन्हें बार-बार फिर से रिज़ॉल्व किया जाना चाहिए। इससे ठीक उसी समय रिज़ॉल्वर पर DNS क्वेरी लोड बढ़ जाता है जब नेटवर्क सबसे अधिक दबाव में होता है। अब, इस समस्या की पारंपरिक प्रतिक्रिया इस पर बैंडविड्थ बढ़ाना है - अपस्ट्रीम लिंक को अपग्रेड करना, अधिक एक्सेस पॉइंट जोड़ना, QoS नीतियों को लागू करना। ये सभी वैध उपाय हैं, लेकिन वे मूल कारण का समाधान नहीं करते हैं। मूल कारण यह है कि आपका DNS रिज़ॉल्यूशन पाथ उच्च-घनत्व वाले गेस्ट वातावरण के लिए अनुकूलित नहीं है। और यही एक एंटरप्राइज़ DNS फ़िल्टर हल करता है। एक एंटरप्राइज़ DNS फ़िल्टर - जैसे कि Purple के गेस्ट WiFi प्लेटफ़ॉर्म के भीतर DNS फ़िल्टरिंग क्षमता - एक स्थानीय, उच्च-प्रदर्शन वाले DNS रिज़ॉल्वर के रूप में कार्य करता है जो आपके गेस्ट डिवाइस और अपस्ट्रीम इंटरनेट के बीच स्थित होता है। प्रत्येक क्वेरी को किसी रिमोट सार्वजनिक रिज़ॉल्वर पर फ़ॉरवर्ड करने के बजाय, यह बार-बार रिज़ॉल्व किए गए डोमेन का एक स्थानीय कैश बनाए रखता है, कैप्टिव पोर्टल डिटेक्शन प्रोब को मूल रूप से संभालता है, और दुर्भावनापूर्ण या गैर-अनुपालन वाले डोमेन को अपस्ट्रीम रिज़ॉल्वर तक पहुँचने से पहले ही ब्लॉक करने के लिए नीति-आधारित फ़िल्टरिंग लागू करता है। इसका परिणाम नाटकीय रूप से कम हुई DNS क्वेरी लेटेंसी है - आमतौर पर दो-से-तीन-सेकंड के टाइमआउट से घटकर 200-मिलीसेकंड से कम की प्रतिक्रियाएं - जिसका अर्थ है कि कैप्टिव पोर्टल डिटेक्शन प्रोब पहले प्रयास में सफल हो जाते हैं, "कनेक्टेड, कोई इंटरनेट नहीं" त्रुटि गायब हो जाती है, और गेस्ट ऑनबोर्डिंग समय में काफी कमी आती है। मानकों के दृष्टिकोण से, यह आर्किटेक्चर उच्च-घनत्व वाले डिप्लॉयमेंट के लिए IEEE 802.11 की सिफारिशों के अनुरूप है और आपको DNS प्रश्नों को लॉग और ऑडिट करने की अनुमति देकर GDPR डेटा हैंडलिंग आवश्यकताओं के अनुपालन का समर्थन करता है - जो तब प्रासंगिक है जब आप सार्वजनिक क्षेत्र या हॉस्पिटैलिटी लाइसेंस के तहत काम कर रहे हों। यह यह भी सुनिश्चित करके कि गेस्ट DNS ट्रैफ़िक आपके कॉर्पोरेट रिज़ॉल्वर इन्फ्रास्ट्रक्चर से अलग रहे, PCI DSS नेटवर्क सेग्मेंटेशन आवश्यकताओं का समर्थन करता है। [कार्यान्वयन की सिफारिशें और कमियां - लगभग 2 मिनट] आइए मैं आपको व्यावहारिक डिप्लॉयमेंट मार्गदर्शन देता हूं। जब आप गेस्ट WiFi नेटवर्क पर एक एंटरप्राइज DNS फ़िल्टर रोल आउट कर रहे होते हैं, तो तीन कॉन्फ़िगरेशन निर्णय यह तय करेंगे कि आप सफल होते हैं या असफल। पहला, रिज़ॉल्वर का स्थान। आपका DNS फ़िल्टर गेस्ट नेटवर्क के जितना संभव हो सके उतना करीब डिप्लॉय किया जाना चाहिए - आदर्श रूप से उसी VLAN या सबनेट पर जिस पर आपके गेस्ट एक्सेस पॉइंट हैं। गेस्ट डिवाइस और रिज़ॉल्वर के बीच प्रत्येक हॉप लेटेंसी बढ़ाता है। यदि आपका DNS फ़िल्टर किसी रिमोट डेटा सेंटर में स्थित है और आपका गेस्ट नेटवर्क मैनचेस्टर के किसी होटल में है, तो आप राउंड-ट्रिप टाइम बढ़ा रहे हैं जो इसके उद्देश्य को विफल कर देता है। एक लोकल एप्लायंस या क्षेत्रीय पॉइंट ऑफ़ प्रेजेंस वाले क्लाउड-डिलीवर्ड DNS फ़िल्टर का उपयोग करें। दूसरा, कैप्टिव पोर्टल DNS पासथ्रू। यह सबसे आम गलत कॉन्फ़िगरेशन है जो मैं देखता हूं। जब आप एक DNS फ़िल्टर डिप्लॉय करते हैं, तो आपको यह सुनिश्चित करना होगा कि कैप्टिव पोर्टल का अपना डोमेन - वह URL जिस पर गेस्ट प्रमाणीकरण के लिए रीडायरेक्ट किए जाते हैं - फ़िल्टर में व्हाइटलिस्ट किया गया है। यदि फ़िल्टर आपके कैप्टिव पोर्टल डोमेन के रिज़ॉल्यूशन को रोकता है या उसमें देरी करता है, तो आप वही समस्या फिर से पैदा कर देंगे जिसे आप हल करने की कोशिश कर रहे थे। किसी भी DNS फ़िल्टरिंग नीति को डिप्लॉय करने के बाद हमेशा कैप्टिव पोर्टल रिज़ॉल्यूशन का स्पष्ट रूप से परीक्षण करें। तीसरा, TTL ट्यूनिंग। कैप्टिव पोर्टल डिटेक्शन प्रोब डोमेन - Apple, Google, Microsoft - के लिए छोटे TTL की सेवा के लिए अपने लोकल DNS रिज़ॉल्वर को कॉन्फ़िगर करें, ताकि डिवाइस अक्सर पुन: प्रश्न करें और कैश्ड प्रविष्टि की समय सीमा समाप्त होने की प्रतीक्षा करने और फिर भीड़भाड़ वाले अपस्ट्रीम रिज़ॉल्वर पर जाने के बजाय हमेशा एक तेज़ स्थानीय प्रतिक्रिया प्राप्त करें। इन विशिष्ट डोमेन के लिए 30 से 60 सेकंड का TTL एक उचित शुरुआती बिंदु है। जिस कमी से बचना है वह है अत्यधिक फ़िल्टरिंग। कुछ टीमें आक्रामक DNS ब्लॉकलिस्ट डिप्लॉय करती हैं जो अनजाने में वैध गेस्ट एप्लिकेशन द्वारा उपयोग किए जाने वाले डोमेन को ब्लॉक कर देती हैं - स्ट्रीमिंग सेवाएं, कॉर्पोरेट VPN एंडपॉइंट्स, क्लाउड स्टोरेज। यह सपोर्ट टिकट की एक अलग श्रेणी उत्पन्न करता है लेकिन गेस्ट अनुभव के लिए समान रूप से हानिकारक है। एक रूढ़िवादी नीति के साथ शुरुआत करें, ब्लॉक किए गए डोमेन के लिए DNS क्वेरी लॉग की निगरानी करें, और कॉन्फ़िगरेशन को लॉक करने से पहले दो सप्ताह की अवधि में परिष्कृत करें। [रैपिड-फायर प्रश्नोत्तर - लगभग 1 मिनट] आइए मैं इस विषय पर अक्सर पूछे जाने वाले प्रश्नों पर चर्चा करूं। "क्या मैं अपने गेस्ट DNS रिज़ॉल्वर के रूप में केवल 8.8.8.8 का उपयोग कर सकता हूं?" आप कर सकते हैं, लेकिन लोड के तहत इसका समय समाप्त हो जाएगा। एक लोकल या क्षेत्रीय रिज़ॉल्वर हमेशा भीड़भाड़ वाले नेटवर्क पर एक सार्वजनिक रिज़ॉल्वर से बेहतर प्रदर्शन करेगा। "क्या यह WPA3 परिनियोजन को प्रभावित करता है?" नहीं - WPA3 प्रमाणीकरण सुरक्षा में सुधार करता है लेकिन DNS रिज़ॉल्यूशन पाथ को नहीं बदलता है। उपयोग में आने वाले एन्क्रिप्शन मानक की परवाह किए बिना समान DNS टाइमआउट समस्या उत्पन्न होती है। "मुझे कैसे पता चलेगा कि मेरी 'कनेक्टेड, कोई इंटरनेट नहीं' त्रुटियों का वास्तविक कारण DNS ही है?" पीक लोड के दौरान गेस्ट VLAN पर एक पैकेट कैप्चर चलाएं। UDP पोर्ट 53 ट्रैफ़िक के लिए फ़िल्टर करें। यदि आप दो सेकंड के भीतर बिना किसी संबंधित प्रतिक्रिया के DNS प्रश्न देखते हैं, तो DNS टाइमआउट ही आपका मुख्य कारण है। "क्या एक एंटरप्राइज़ DNS फ़िल्टर अनुपालन में मदद करता है?" हाँ - DNS क्वेरी लॉगिंग एक ऑडिट ट्रेल प्रदान करती है जो GDPR जवाबदेही दायित्वों का समर्थन करती है और घटना प्रतिक्रिया में सहायता कर सकती है। Purple के प्लेटफ़ॉर्म में यह लॉगिंग मूल रूप से शामिल है। [सारांश और अगले कदम - लगभग 1 मिनट] संक्षेप में कहें तो: गेस्ट WiFi पर "कनेक्टेड, कोई इंटरनेट नहीं" त्रुटि अत्यधिक रूप से एक अनऑप्टिमाइज्ड हल करने वाले मार्ग को प्रभावित करने वाले नेटवर्क भीड़ के कारण होने वाली DNS टाइमिंग समस्या है। इसका समाधान अधिक बैंडविड्थ नहीं है - यह एक स्थानीय, उच्च प्रदर्शन वाला एंटरप्राइज़ DNS फ़िल्टर है जो कैप्टिव पोर्टल डिटेक्शन प्रोब को जल्दी हल करता है, एक स्थानीय कैश बनाए रखता है, और अपस्ट्रीम क्वेरी लोड को कम करने के लिए नीति आधारित फ़िल्टरिंग लागू करता है। इस सप्ताह करने के लिए तीन चीजें: निदान की पुष्टि करने के लिए पीक लोड के दौरान DNS पैकेट कैप्चर चलाएं; अपने वर्तमान DNS हल करने वाले प्लेसमेंट की समीक्षा करें और पहचानें कि यह स्थानीय है या रिमोट; और अपने गेस्ट VLAN पर एक एंटरप्राइज़ DNS फ़िल्टर परिनियोजन का मूल्यांकन करें। यदि आप इनमें से किसी पर भी गहराई से जाना चाहते हैं, तो Purple प्लेटफ़ॉर्म दस्तावेज़ में DNS फ़िल्टर कॉन्फ़िगरेशन को विस्तार से शामिल किया गया है, और purple.ai पर गेस्ट WiFi अनुकूलन गाइड इस ब्रीफ़िंग के साथ समीक्षा करने योग्य हैं। सुनने के लिए धन्यवाद - मैं आपसे अगले एपिसोड में मिलूंगा। [एपिसोड का अंत]

हमारी मुख्य श्रृंखला का हिस्सा: गेस्ट WiFi गाइड →

Interactive Diagnostic ToolUpdated for Enterprise WiFi & Captive Portal Architecture

Guest WiFi “Connected, No Internet” Root-Cause Diagnostic Tool

Select your venue deployment profile, active connection failure symptom, and wireless infrastructure vendor to calculate probe timeout risks, diagnose DNS/DHCP bottlenecks, and generate multi-vendor remediation steps.

Estimated Probe Latency
~325 ms
Target: <50ms for reliable Apple CNA
Timeout / Drop Probability
88%
Risk Level: Critical
Recommended DHCP Lease
480 mins
Subnet: /21
Active Probe Domain
captive.apple.com
Fallback: connectivitycheck.gstatic.com

Root-Cause Diagnostic Analysis: Captive portal login popup never appears on mobile devices

Severity: Critical
Root Cause:

OS captive portal detection probe DNS queries exceed the 2-5 second timeout window due to upstream resolver latency or dropped UDP packets.

Business Impact:

Devices display "Connected, No Internet" and automatically drop the connection or fail back to mobile cellular data.

Primary Engineering Remedy:

Deploy a local enterprise DNS caching filter, allowlist probe domains, and ensure UDP port 53 is allowed pre-authentication.

Vendor Implementation Guide: Cisco Meraki (Meraki Dashboard)

  1. DNS Configuration & Resolver Tuning:
    Under Wireless > Configure > Access control > Addressing and traffic, set Client IP assignment to "External DHCP server" or "Bridge mode" with reliable public Anycast DNS (1.1.1.1, 8.8.8.8).
  2. DHCP Scope & Lease Duration:
    In Security & SD-WAN > Configure > Addressing & VLANs, decrease DHCP lease time on the Guest VLAN to 30 minutes to prevent scope starvation.
  3. Walled Garden Pre-Authentication Rules:
    Under Wireless > Access control > Walled garden, enable Walled garden and add: *.purple.ai and the portal hosts only. Leave the OS probe hosts (captive.apple.com, connectivitycheck.gstatic.com, msftconnecttest.com) out, or devices will think they are online.
Configuration Snippet:
# Meraki Dashboard Configuration:
# 1. Wireless > Configure > Access Control > Splash Page: "Sign-on splash page"
# 2. Walled Garden ranges: *.purple.ai, fonts.googleapis.com (not the OS probe hosts)
# 3. Client IP assignment: Bridge Mode (NAT mode restricts Layer 2 client isolation)

Experiencing guest WiFi onboarding failures across your venue?

Purple works with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet, and manages the pre-auth walled garden and DNS allowances that most of these failures trace back to.

Useful? Link to this tool

गेस्ट WiFi पर "कनेक्टेड लेकिन इंटरनेट नहीं" की त्रुटि तब होती है जब Captive Portal लोड होने से पहले कनेक्टिविटी जाँच विफल हो जाती है। व्यस्त स्थानों में, भीड़ के दौरान UDP पोर्ट 53 DNS प्रश्न (RFC 1035) टाइम आउट हो जाते हैं। इसे हल करने के लिए गेस्ट DHCP स्कोप को कैशिंग DNS फ़िल्टर पर पॉइंट करना, Cisco Meraki जैसे कंट्रोलर में वॉल्ड गार्डन डोमेन को पूरा करना और ट्रैफिक शेपिंग नियमों की समीक्षा करना आवश्यक है।

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

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

प्रत्येक ऑपरेटिंग सिस्टम चेतावनी को अलग तरह से प्रदर्शित करता है। आपकी स्थान सहायता टीम को इन सभी की पहचान होनी चाहिए:

  • Windows नेटवर्क नाम के नीचे "No internet" दिखाता है।
  • Android "Connected without internet" या "Internet may not be available" दिखाता है।
  • iPhone और iPad नेटवर्क नाम के नीचे "No Internet Connection" दिखाते हैं।

तीनों एक ही तंत्र से आते हैं। जुड़ने के बाद, डिवाइस कनेक्शन का परीक्षण करने के लिए किसी ज्ञात वेब पते का अनुरोध करता है। यदि वह परीक्षण अपेक्षित पेज लौटाता है, तो डिवाइस कनेक्शन को कार्यशील मानता है। यदि यह एक लॉगिन पेज लौटाता है, तो डिवाइस Captive Portal खोलता है। यदि इसे कोई उत्तर नहीं मिलता है, तो डिवाइस "no internet" की रिपोर्ट करता है।

ऑपरेटिंग सिस्टम कनेक्टिविटी-जाँच होस्टनाम विफलता पर गेस्ट को क्या दिखता है
iOS, iPadOS, macOS captive.apple.com "No Internet Connection"
Android connectivitycheck.gstatic.com "Connected without internet"
Windows 10 और 11 www.msftconnecttest.com "No internet"

इससे पहले कि डिवाइस इनमें से किसी भी पेज का अनुरोध कर सके, उसे DNS के माध्यम से होस्टनाम खोजना होगा। वही लुकअप अधिकांश उच्च घनत्व वाली विफलताओं की शुरुआत का कारण बनता है।

गेस्ट WiFi पर आमतौर पर कनेक्टेड इंटरनेट नहीं त्रुटियों का क्या कारण है?

भीड़भाड़ वाले नेटवर्क पर DNS टाइमआउट

DNS (डोमेन नेम सिस्टम) किसी होस्टनाम को IP पते में बदलता है। अधिकांश DNS क्वेरी UDP पोर्ट 53 पर जाती हैं, जैसा कि RFC 1035 में परिभाषित किया गया है। UDP में कोई इन-बिल्ट रीट्रांसमिशन नहीं होता है, इसलिए कोई भी छूटी हुई क्वेरी बस डिवाइस के अपने पुनः प्रयास टाइमर की प्रतीक्षा करती है।

भीड़भाड़ अचानक आती है। किसी स्टेडियम में हाफ-टाइम, किसी होटल में नाश्ते का चेक-आउट, या स्टेशन पर आने वाली ट्रेन के बारे में सोचें। सेकंड के भीतर सैकड़ों डिवाइस जुड़ते हैं, और हर एक डिवाइस एक साथ लुकअप भेजता है। यदि हल करने वाला (रिफ्रेशर) व्यस्त WAN लिंक के पार कई हॉप दूर है, तो प्रश्नों में देरी होती है या वे छूट जाते हैं। डिवाइस प्रयास करना छोड़ देता है, पोर्टल कभी नहीं खुलता है, और गेस्ट को "no internet" दिखता है।

अन्य सामान्य कारण

व्यस्त स्थानों में DNS सबसे आम कारण है, लेकिन एकमात्र कारण नहीं है। इन्हें भी खारिज करें:

  • अपूर्ण वॉल्ड गार्डन प्रविष्टियाँ। वॉल्ड गार्डन उन डोमेन की सूची है जिन तक कोई डिवाइस लॉगिन से पहले पहुँच सकता है। यदि आपका पोर्टल या उसकी संपत्ति गायब है, तो पेज लोड नहीं हो सकता है।
  • DHCP पूल समाप्त होना। यदि एड्रेस पूल समाप्त हो जाता है, तो डिवाइस खुद को 169.254.x.x एड्रेस असाइन कर लेते हैं और किसी भी चीज़ तक पहुँचने में असमर्थ होते हैं।
  • UDP पोर्ट 53 की रेट लिमिट या QoS थ्रॉटलिंग। प्रति क्लाइंट या प्रति SSID सेट की गई बहुत सख्त सीमा भीड़ के समय DNS को बाधित कर सकती है।
  • एन्क्रिप्टेड DNS। DNS over HTTPS (DoH, RFC 8484) और DNS over TLS (DoT, RFC 7858) बाहरी रिज़ॉल्वर को लुकअप भेजते हैं। इन रिज़ॉल्वर को ब्लॉक करने वाला walled garden लॉगिन से पहले लुकअप को रोक देता है।
  • अपस्ट्रीम आउटेज। यदि WAN लिंक खुद डाउन है, तो हर डिवाइस विफल हो जाता है और हर वायर्ड पोर्ट भी विफल हो जाता है।

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

हार्डवेयर के बजाय पैटर्न से शुरुआत करें। कुछ भी बदलने से पहले कारण को सीमित करने के लिए इस मैट्रिक्स का उपयोग करें।

आप क्या देखते हैं सबसे संभावित कारण पहली कार्रवाई
अनुमानित पीक समय पर एरर बढ़ते हैं, शांत समय में ठीक रहते हैं भीड़भाड़ के तहत DNS टाइमआउट गेस्ट DHCP को पास के कैशिंग DNS फ़िल्टर पर पॉइंट करें
हर डिवाइस विफल रहता है, पूरे दिन अपस्ट्रीम WAN आउटेज या DHCP में गलत DNS सर्वर WAN लिंक और DHCP DNS सेटिंग का परीक्षण करें
डिवाइस 169.254.x.x एड्रेस दिखाता है DHCP पूल समाप्त हो गया है पूल को बढ़ाएं या लीज समय को छोटा करें
पोर्टल लोड होना शुरू होता है लेकिन रुक जाता है या खाली पेज दिखाता है Walled garden से पोर्टल डोमेन गायब हैं अपने Purple सेटअप लेख से डोमेन जोड़ें
केवल कुछ Android डिवाइस या लैपटॉप विफल होते हैं डिवाइस पर प्राइवेट DNS, DoT या DoH सेट है गेस्ट को प्राइवेट DNS को ऑटोमैटिक पर स्विच करने के लिए कहें
प्रति AP डिवाइसों की एक निश्चित संख्या के ऊपर ही विफल होता है UDP पोर्ट 53 पर रेट लिमिट या QoS गेस्ट SSID ट्रैफिक शेपिंग नियमों की समीक्षा करें

तीन जांच जो आपकी सपोर्ट टीम चला सकती है

  1. डिवाइस के IP एड्रेस की जांच करें। 169.254.x.x एड्रेस DHCP की ओर इशारा करता है, DNS की ओर नहीं। एक सामान्य गेस्ट रेंज एड्रेस का मतलब है कि डिवाइस ठीक से जुड़ गया है।
  2. एक टेस्ट डिवाइस से लुकअप का समय मापें। गेस्ट नेटवर्क पर लैपटॉप से nslookup captive.apple.com चलाएं। व्यस्त अवधि के दौरान एक धीमा या विफल उत्तर DNS बाधा की पुष्टि करता है।
  3. गेस्ट VLAN पर पैकेट कैप्चर करें। एक VLAN (वर्चुअल LAN) गेस्ट ट्रैफिक को आपके अन्य नेटवर्क से अलग करता है। udp port 53 पर कैप्चर को फ़िल्टर करें और बिना किसी मिलान उत्तर वाली क्वेरी की तलाश करें।

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

एक एंटरप्राइज DNS फ़िल्टर बाधा को कैसे ठीक करता है?

एक एंटरप्राइज DNS फ़िल्टर वह रिज़ॉल्वर है जिसे आप नियंत्रित करते हैं, जिसे गेस्ट नेटवर्क के करीब रखा जाता है। यह उस दूरस्थ ISP या सार्वजनिक रिज़ॉल्वर को बदल देता है जिसे DHCP आज सौंपता है। यह तीन काम करता है जो टाइमआउट को हटाते हैं।

यह कैश से उत्तर देता है। एक व्यस्त स्थान पर कनेक्टिविटी जांच वाले होस्टनामों का अनुरोध घंटे में हज़ारों बार किया जाता है। एक पास का फ़िल्टर अपने कैश से दोहराए जाने वाले लुकअप का उत्तर देता है, इसलिए वे कभी भी भीड़भाड़ वाले WAN लिंक को पार नहीं करते हैं।

यह अवांछित ट्रैफिक को जल्दी हटा देता है। दुर्भावनापूर्ण या अवरुद्ध श्रेणियों के प्रश्नों को फ़िल्टर पर अस्वीकार कर दिया जाता है। इससे महत्वपूर्ण लुकअप के लिए WAN क्षमता मुफ़्त हो जाती है।

यह हर प्रश्न (query) को लॉग करता है। आपको एक रिकॉर्ड मिलता है कि कौन से डोमेन विफल रहे, कब और कितनी बार। यह अगली बार जब कोई प्रबंधक किसी समस्या की रिपोर्ट करता है, तो अनुमान लगाने के बजाय साक्ष्य प्रदान करता है।

इसे कहाँ रखें

वितरित परिसंपत्तियों के लिए, जैसे सैकड़ों छोटे स्थलों वाली रिटेल श्रृंखला, पास के एज स्थानों वाला क्लाउड-डिलीवर फ़िल्टर आमतौर पर एक व्यावहारिक विकल्प होता है। एक एकल बड़े स्थल के लिए, जैसे कि स्टेडियम या सम्मेलन केंद्र, ऑन-साइट होस्ट किया गया रिज़ॉल्वर WAN से लुकअप को पूरी तरह से दूर रखता है। दोनों ही मामलों में, DHCP में दो रिज़ॉल्वर पते दें ताकि एक विफलता नेटवर्क को बंद न कर सके।

दो सेटिंग्स जो सफलता तय करती हैं

सबसे पहले, फ़िल्टर में अपने Captive Portal डोमेन की अनुमति दें। एक फ़िल्टर जो पोर्टल को ब्लॉक या विलंबित करता है, ठीक वही त्रुटि फिर से उत्पन्न करता है जिसे आप ठीक करने चले थे। दूसरा, अतिथि DNS को कॉर्पोरेट DNS से अलग रखें। PCI DSS अतिथि नेटवर्क को आपके कार्डधारक डेटा वातावरण के दायरे से बाहर रखने के लिए नेटवर्क विभाजन को सही तरीका मानता है।

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

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

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

आपके एक्सेस पॉइंट्स और कंट्रोलर पर

Purple हार्डवेयर-अज्ञेयवादी (hardware-agnostic) है और Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme और Fortinet पर एक क्लाउड ओवरले के रूप में चलता है। यह सुधार उनमें से प्रत्येक पर समान तीन चरणों का पालन करता है:

  1. अतिथि DHCP स्कोप में DNS सर्वर को अपने एंटरप्राइज़ DNS फ़िल्टर में अपडेट करें।
  2. walled garden को पूरा करें। Cisco Meraki, HPE Aruba और Ruckus सभी "walled garden" शब्द का उपयोग करते हैं। अपने विक्रेता के लिए Purple सेटअप लेख का पालन करें, जो अनुमति दिए जाने वाले सटीक डोमेन सूचीबद्ध करता है।
  3. अतिथि ट्रैफ़िक शेपिंग की जाँच करें ताकि प्रति-क्लाइंट सीमाएँ अचानक वृद्धि के दौरान UDP पोर्ट 53 को बाधित न करें।

विभिन्न विक्रेताओं के बीच सेटिंग्स की प्रतिलिपि न बनाएं। मेनू नाम और डिफ़ॉल्ट भिन्न होते हैं, इसलिए Purple सेटअप लेख के साथ विक्रेता के स्वयं के दस्तावेज़ों का उपयोग करें।

अतिथि के डिवाइस पर

जब कोई एकल अतिथि प्रभावित होता है और बाकी सब ठीक होते हैं, तो आपकी हेल्पडेस्क टीम इन चरणों का प्रयास कर सकती है:

  • नेटवर्क को भूल जाएं (Forget the network) और फिर से जुड़ें ताकि एक नया कनेक्टिविटी चेक ट्रिगर हो सके।
  • ब्राउज़र में एक सामान्य http:// पता खोलें ताकि पोर्टल को दिखाई देने के लिए बाध्य किया जा सके।
  • Android पर, Private DNS को Automatic पर सेट करें। एक निश्चित Private DNS प्रदाता लॉगिन से पहले लुकअप को ब्लॉक कर सकता है।
  • किसी भी VPN ऐप को तब तक रोकें (Pause) जब तक कि अतिथि साइन इन न कर ले।

व्यावहारिक परिदृश्य (Worked scenarios)

नीचे दिए गए आंकड़े उदाहरणात्मक हैं, किसी नामित परिनियोजन से नहीं लिए गए हैं। अपने स्वयं के स्थल पर क्या मापना है, इसके लिए एक मॉडल के रूप में इनका उपयोग करें।

नाश्ते के समय 200 कमरों वाला होटल

स्थिति। "इंटरनेट नहीं है" के बारे में फ़्रंट-डेस्क की शिकायतें सुबह 7 बजे से 9 बजे के बीच होती हैं, जब अतिथि चेकआउट से पहले ईमेल की जांच करते हैं। एक्सेस पॉइंट स्वस्थ सिग्नल और अतिरिक्त एयरटाइम दिखाते हैं। अतिथि DHCP एक व्यस्त लाइन पर कई हॉप्स दूर ISP के रिज़ॉल्वर को सौंपता है।

क्या किया गया। IT मैनेजर ने पीक समय के दौरान nslookup चलाया और देखा कि लुकअप पूरी तरह से विफल हो रहे थे। टीम ने अतिथि DHCP को क्लाउड DNS फ़िल्टर की ओर इंगित किया, walled garden में पोर्टल डोमेन जोड़े और अतिथि DNS को प्रॉपर्टी मैनेजमेंट नेटवर्क से अलग रखा।

परिणाम। WiFi Analytics और डेस्क लॉग में मापे जाने पर, पीक समय पर पोर्टल पूरा होने की दर 81% से बढ़कर 97% हो गई। डेस्क पर WiFi की शिकायतें प्रति सुबह लगभग 15 से घटकर दो रह गईं। होटल गेस्ट नेटवर्क के बारे में अधिक जानकारी के लिए, हमारे हॉस्पिटैलिटी पृष्ठ देखें।

हाफ-टाइम में 30,000 क्षमता वाला स्टेडियम

स्थिति। प्रशंसकों ने हर हाफ-टाइम में "इंटरनेट के बिना कनेक्टेड" की सूचना दी, जबकि प्रत्येक हाफ के पहले दस मिनट सुचारू रूप से चले। गेस्ट VLAN पर पैकेट कैप्चर ने वृद्धि के दौरान बिना किसी उत्तर के DNS प्रश्न दिखाए।

क्या किया गया। नेटवर्क आर्किटेक्ट ने क्लाउड फ़ॉलबैक के साथ एक ऑन-साइट रिज़ॉल्वर तैनात किया। टीम ने प्रति-क्लाइंट दर सीमा को हटा दिया जो UDP पोर्ट 53 को थ्रॉटल करती थी, और DHCP स्कोप को नए रिज़ॉल्वर पर स्थानांतरित कर दिया।

परिणाम। फॉलो-अप कैप्चर में हाफ-टाइम पर अनुत्तरित DNS प्रश्न 12% से घटकर 1% से भी कम हो गए। अंतराल के दौरान प्रशंसकों के लॉगिन पिछले मैच की तुलना में 40% बढ़ गए।

आप कनेक्टेड लेकिन कोई इंटरनेट नहीं त्रुटियों को फिर से होने से कैसे रोकते हैं?

  • कभी भी केवल एक दूरस्थ सार्वजनिक रिज़ॉल्वर पर भरोसा न करें। सार्वजनिक DNS सामान्य रूप से अच्छा प्रदर्शन करता है, लेकिन कई हॉप दूर एक रिज़ॉल्वर देरी जोड़ता है जिसे आप वृद्धि के दौरान नियंत्रित नहीं कर सकते।
  • अनुत्तरित DNS प्रश्नों पर अलर्ट सेट करें। गेस्ट नेटवर्क पर बढ़ते UDP पोर्ट 53 ड्रॉप्स को फ़्लैग करने के लिए अपने फ़ायरवॉल या कोर स्विच को कॉन्फ़िगर करें, जो मेहमानों के ध्यान देने से पहले टाइमआउट का संकेत देते हैं।
  • हर महीने DNS फ़िल्टर ब्लॉकलिस्ट की समीक्षा करें। अत्यधिक आक्रामक श्रेणियां वैध ऐप्स को तोड़ती हैं और नए सपोर्ट टिकट बनाती हैं।
  • लॉग प्रतिधारण अवधि सेट करें। DNS लॉग IP पतों को विज़िट किए गए डोमेन से जोड़ते हैं, इसलिए उन्हें GDPR के तहत व्यक्तिगत डेटा के रूप में समझें।
  • जहां आपका हार्डवेयर इसका समर्थन करता है वहां RFC 8910 अपनाएं। यह DHCP को डिवाइस को यह बताने देता है कि Captive Portal कहां है, जिससे डिवाइस कनेक्टिविटी-जांच लुकअप पर कम निर्भर करता है।
  • लौटने वाले आगंतुकों के लिए Passpoint पर विचार करें। Passpoint (जिसे Hotspot 2.0 भी कहा जाता है) और OpenRoaming उपकरणों को Captive Portal के बिना सुरक्षित रूप से जुड़ने की अनुमति देते हैं, जो उनके लिए इस विफलता मोड को पूरी तरह से हटा देता है।

Purple 90 से अधिक देशों में 80,000+ लाइव स्थानों पर 500 मिलियन उपयोगकर्ताओं और प्रति वर्ष लॉगिन के साथ Guest WiFi चलाता है। हेल्थकेयर प्रतीक्षा कक्षों से लेकर ट्रेन तक, पैटर्न बना रहता है: बैंडविड्थ खरीदने से पहले DNS को ठीक करें।

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

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

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

क्या Purple हमारे पास पहले से मौजूद हार्डवेयर के साथ काम करता है?

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

क्या एंटरप्राइज DNS फ़िल्टर हमारे गेस्ट WiFi को धीमा कर देगा?

नहीं, एक सही जगह पर लगाया गया DNS फ़िल्टर आमतौर पर लुकअप को तेज़ बनाता है। यह ISP या पब्लिक रिज़ॉल्वर की तुलना में गेस्ट नेटवर्क के अधिक करीब स्थित होता है और अपने कैश्ड डेटा से बार-बार होने वाले लुकअप का उत्तर देता है। जोखिम इसे स्थापित करने और कॉन्फ़िगर करने में है, फ़िल्टर करने में नहीं। रिडंडेंसी के लिए दो रिज़ॉल्वर एड्रेस दें, और अपने कैप्टिव पोर्टल डोमेन की अनुमति दें ताकि फ़िल्टर कभी भी लॉगिन पेज में देरी न करे।

गेस्ट्स को 8.8.8.8 जैसा पब्लिक रिज़ॉल्वर ही क्यों न दे दिया जाए?

आप दे सकते हैं, लेकिन यह कंजेशन टाइमआउट की समस्या को ठीक नहीं करता है। एक पब्लिक रिज़ॉल्वर अभी भी आपके WAN लिंक के पार होता है, इसलिए हर लुकअप उस ट्रैफ़िक वृद्धि से प्रतिस्पर्धा करता है जो विफलता का कारण बनती है। यह आपको ट्रबलशूटिंग के लिए कोई फ़िल्टरिंग और कोई क्वेरी लॉग भी नहीं देता है। पास का एंटरप्राइज फ़िल्टर कैश से उत्तर देता है, अवांछित श्रेणियों को अस्वीकार करता है और हर असफल लुकअप को रिकॉर्ड करता है, जो पब्लिक DNS आपके लिए नहीं कर सकता है।

हम GDPR के तहत DNS क्वेरी लॉग को कैसे संभालते हैं?

DNS लॉग को व्यक्तिगत डेटा के रूप में मानें, क्योंकि वे IP एड्रेस को उन डोमेन से जोड़ते हैं जिन पर किसी डिवाइस ने विज़िट किया है। एक निश्चित रिटेंशन अवधि निर्धारित करें, अपने नेटवर्क और सुरक्षा टीम तक पहुंच सीमित करें, और अपने गोपनीयता नोटिस में उद्देश्य को दर्ज करें। Purple ISO 27001 प्रमाणित और GDPR अनुपालन वाला है, और गेस्ट ट्रैफ़िक को इसके माध्यम से रूट करने से पहले आपके DNS फ़िल्टर आपूर्तिकर्ता को समकक्ष प्रमाणन दिखाना चाहिए।

डिप्लॉयमेंट में कितना प्रयास लगता है?

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

क्या Passpoint या OpenRoaming त्रुटि को हटा देंगे?

हाँ, उन डिवाइसों के लिए जो उनका उपयोग करते हैं। Passpoint और OpenRoaming डिवाइसों को कैप्टिव पोर्टल के बिना सुरक्षित रूप से कनेक्ट होने देते हैं, इसलिए विफल होने के लिए कोई पोर्टल नहीं होता है। पहली बार आने वाले विज़िटर्स और बिना Passpoint प्रोफाइल वाले डिवाइस अभी भी कैप्टिव पोर्टल का उपयोग करते हैं, इसलिए आपको अभी भी तेज़ DNS और एक पूर्ण वॉल्ड गार्डन की आवश्यकता है। दोनों को एक साथ चलाएं: लौटने वाले विज़िटर्स के लिए Passpoint, बाकी सभी के लिए एक ट्यून किया गया पोर्टल।

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

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

लॉगिन पेज जो एक गेस्ट नेटवर्क इंटरनेट एक्सेस देने से पहले सर्व करता है। RFC 8910 एक DHCP और IPv6 राउटर एडवर्टाइजमेंट विकल्प को परिभाषित करता है जो डिवाइस को पोर्टल का API एड्रेस बताता है, इसलिए इसे किसी विफल वेब अनुरोध से पोर्टल का अनुमान नहीं लगाना पड़ता है।

आपके मेहमान यहां शर्तें स्वीकार करते हैं या साइन इन करते हैं। यदि पोर्टल कभी नहीं खुलता है, तो वे ऑनलाइन नहीं हो सकते हैं और समस्या फ्रंट डेस्क या हेल्प पॉइंट पर आ जाती है।

कनेक्टिविटी चेक

एक HTTP अनुरोध जो प्रत्येक ऑपरेटिंग सिस्टम नेटवर्क में शामिल होने के बाद एक ज्ञात होस्टनेम को भेजता है: iOS, iPadOS और macOS पर captive.apple.com, Android पर connectivitycheck.gstatic.com, और Windows 10 और 11 पर www.msftconnecttest.com। अपेक्षित पेज का मतलब ऑनलाइन है, एक लॉगिन पेज पोर्टल को ट्रिगर करता है, और कोई उत्तर नहीं होने का मतलब "नो इंटरनेट" है।

यह जांच आपकी सहायता टीम द्वारा देखी जाने वाली चेतावनी के हर प्रकार को उत्पन्न करती है। यह पहले DNS लुकअप पर निर्भर करता है, जहां उच्च-घनत्व विफलताएं शुरू होती हैं।

DNS (डोमेन नेम सिस्टम)

वह प्रोटोकॉल जो RFC 1035 में निर्दिष्ट, होस्टनेम को IP एड्रेस में रीसॉल्व करता है। अधिकांश प्रश्न UDP पोर्ट 53 पर यात्रा करते हैं, जिसमें कोई अंतर्निहित रिट्रांसमिशन नहीं होता है, इसलिए एक छूटा हुआ प्रश्न डिवाइस के अपने रीट्राई टाइमर पर प्रतीक्षा करता है।

जब सैकड़ों डिवाइस एक साथ जुड़ते हैं और रीसॉल्वर एक व्यस्त WAN लिंक पर होता है, तो लुकअप का समय समाप्त हो जाता है और पोर्टल कभी नहीं खुलता है।

एंटरप्राइज DNS फ़िल्टर

आपके नियंत्रण में एक रीसॉल्वर, जो गेस्ट नेटवर्क के करीब स्थित है, जो कैश से बार-बार होने वाले लुकअप का उत्तर देता है, दुर्भावनापूर्ण या अवरुद्ध श्रेणियों के प्रश्नों को अस्वीकार करता है, और डोमेन, समय और आवृत्ति के अनुसार प्रत्येक प्रश्न को लॉग करता है।

यह आपके गेस्ट DHCP स्कोप में दूरस्थ ISP या सार्वजनिक रीसॉल्वर को बदल देता है। इसे वितरित संपत्तियों के लिए क्लाउड-डिलीवर्ड या किसी एकल बड़े स्थल के लिए ऑन-साइट तैनात करें।

वॉल्ड गार्डन

डोमेन की वह सूची जहाँ कोई डिवाइस कैप्टिव पोर्टल नेटवर्क पर प्रमाणन (authentication) से पहले पहुँच सकता है। Cisco Meraki, HPE Aruba और Ruckus सभी अपने कंट्रोलर कॉन्फ़िगरेशन में इस शब्द का उपयोग करते हैं।

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

DHCP पूल समाप्त होना

वह स्थिति जहाँ डायनामिक होस्ट कॉन्फ़िगरेशन प्रोटोकॉल (RFC 2131) सर्वर के स्कोप में कोई फ्री एड्रेस नहीं बचता है, इसलिए नए डिवाइस खुद को 169.254.x.x लिंक-लोकल एड्रेस असाइन कर लेते हैं और किसी भी चीज़ तक नहीं पहुँच पाते हैं।

गेस्ट डिवाइस पर 169.254.x.x एड्रेस DHCP की ओर इशारा करता है, DNS की ओर नहीं। पूल को बड़ा करें या लीज के समय को छोटा करें।

DNS over HTTPS (DoH) और DNS over TLS (DoT)

एन्क्रिप्टेड DNS ट्रांसपोर्ट: DoH RFC 8484 में निर्दिष्ट अनुसार HTTPS के अंदर प्रश्नों (queries) को ले जाता है, और DoT RFC 7858 में निर्दिष्ट अनुसार TLS सेशन के माध्यम से ले जाता है। दोनों आपके नेटवर्क के बाहर के रिज़ॉल्वर को लुकअप भेजते हैं।

एक वॉल्ड गार्डन (walled garden) जो उन बाहरी रिज़ॉल्वर को ब्लॉक करता है, लॉगिन से पहले लुकअप को रोक देता है। Android पर, गेस्ट से प्राइवेट DNS को ऑटोमैटिक पर सेट करने के लिए कहें।

VLAN (वर्चुअल LAN)

IEEE 802.1Q टैगिंग द्वारा परिभाषित एक लॉजिकल नेटवर्क सेग्मेंट, जो साझा किए गए स्विचिंग इंफ्रास्ट्रक्चर पर गेस्ट ट्रैफ़िक को अन्य नेटवर्क से अलग करता है।

अनुत्तरित प्रश्नों का पता लगाने के लिए udp पोर्ट 53 पर फ़िल्टर किए गए गेस्ट VLAN पर पैकेट कैप्चर करें। सेग्मेंटेशन गेस्ट ट्रैफ़िक को PCI DSS कार्डहोल्डर डेटा एनवायरनमेंट के स्कोप से बाहर भी रखता है।

Passpoint (Hotspot 2.0) और OpenRoaming

Passpoint, जिसे Hotspot 2.0 भी कहा जाता है, IEEE 802.11u नेटवर्क डिस्कवरी और IEEE 802.1X पोर्ट-आधारित प्रमाणन पर आधारित है ताकि प्रोफ़ाइल वाला डिवाइस बिना कैप्टिव पोर्टल के सुरक्षित रूप से जुड़ सके। OpenRoaming इसे भाग लेने वाले नेटवर्क पर विस्तारित करता है।

प्रोफ़ाइल वाले वापस आने वाले यूज़र्स कभी भी पोर्टल पर नहीं पहुँचते, इसलिए उनके लिए यह विफलता मोड गायब हो जाता है। पहली बार आने वाले यूज़र्स को अभी भी तेज़ DNS और एक पूर्ण वॉल्ड गार्डन (walled garden) की आवश्यकता होती है।

GDPR व्यक्तिगत डेटा (DNS लॉग)

UK GDPR और EU GDPR के तहत, किसी पहचानकर्ता जैसे IP एड्रेस को गतिविधि से जोड़ने वाली जानकारी को व्यक्तिगत डेटा माना जाता है, जिसके लिए एक परिभाषित उद्देश्य, सीमित रिटेंशन और प्रतिबंधित पहुँच की आवश्यकता होती है।

DNS फ़िल्टर लॉग IP एड्रेस को विज़िट किए गए डोमेन से जोड़ते हैं। एक रिटेंशन अवधि सेट करें, अपने नेटवर्क और सुरक्षा टीम तक पहुँच को सीमित करें, और अपने गोपनीयता नोटिस में उद्देश्य को रिकॉर्ड करें।

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

200 कमरों वाले एक होटल में सुबह 7 बजे से 9 बजे के बीच "इंटरनेट नहीं है" के बारे में फ्रंट-डेस्क पर शिकायतें आती हैं। एक्सेस पॉइंट्स स्वस्थ सिग्नल और अतिरिक्त एयरटाइम दिखाते हैं, और गेस्ट DHCP एक व्यस्त लाइन के पार कई हॉप दूर ISP के हलकर्ता (रीसॉल्वर) को सौंपता है। IT मैनेजर को क्या करना चाहिए? (आंकड़े उदाहरणात्मक हैं।)

IT मैनेजर ने पीक ऑवर्स के दौरान एक गेस्ट-नेटवर्क लैपटॉप से nslookup चलाया और देखा कि लुकअप पूरी तरह से विफल हो रहे थे, जिसने रेडियो फॉल्ट के बजाय DNS बॉटलनैक की पुष्टि की। टीम ने गेस्ट DHCP को क्लाउड DNS फ़िल्टर की ओर इंगित किया ताकि बार-बार होने वाले कनेक्टिविटी-चेक लुकअप का उत्तर कैश से दिया जा सके। उन्होंने पोर्टल डोमेन को वॉल्ड गार्डन में जोड़ा ताकि साइन-इन से पहले लॉगिन पेज लोड हो जाए। उन्होंने सेग्मेंटेशन बनाए रखने के लिए गेस्ट DNS को प्रॉपर्टी मैनेजमेंट नेटवर्क से अलग रखा। WiFi Analytics और डेस्क लॉग में मापे गए, पीक पर पोर्टल पूरा होने की दर 81% से बढ़कर 97% हो गई, और डेस्क शिकायतें प्रति सुबह लगभग 15 से घटकर दो रह गईं।

30,000 क्षमता वाले स्टेडियम में प्रशंसक हर हाफ-टाइम में "इंटरनेट के बिना कनेक्टेड" की रिपोर्ट करते हैं, जबकि प्रत्येक हाफ के पहले दस मिनट ठीक से चलते हैं। surge के दौरान गेस्ट VLAN पर पैकेट कैप्चर बिना किसी प्रतिक्रिया के DNS प्रश्न दिखाते हैं। नेटवर्क आर्किटेक्ट को कैसी प्रतिक्रिया देनी चाहिए? (आंकड़े उदाहरणात्मक हैं।)

पैटर्न ने कंजेशन की ओर इशारा किया, इसलिए आर्किटेक्ट ने क्लाउड फ़ॉलबैक के साथ एक ऑन-साइट रीसॉल्वर तैनात किया। लुकअप को ऑन-साइट रखने से surge के दौरान वे पूरी तरह से WAN से बाहर हो गए। टीम ने प्रति-क्लाइंट रेट लिमिट को भी ढूंढा और हटा दिया जो UDP पोर्ट 53 को थ्रॉटल कर रहा था, जिससे एक साथ हजारों डिवाइस जुड़ने पर DNS की कमी हो गई थी। उन्होंने गेस्ट DHCP स्कोप को नए रीसॉल्वर पर स्थानांतरित कर दिया। फॉलो-अप कैप्चर से पता चला कि हाफ-टाइम पर अनुत्तरित DNS प्रश्न 12% से घटकर 1% से भी कम हो गए। अंतराल के दौरान फैन लॉगिन पिछले मैच की तुलना में 40% बढ़ गए।

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

Q1. एक स्टेडियम के IT डायरेक्टर ध्यान देते हैं कि हाफ़-टाइम के दौरान, हज़ारों यूज़र्स WiFi से कनेक्ट होते हैं लेकिन कैप्टिव पोर्टल तक पहुँचने में विफल रहते हैं। कोर स्विच भारी UDP पैकेट ड्रॉप दिखाता है। क्या उन्हें WAN बैंडविड्थ को 2Gbps से बढ़ाकर 5Gbps कर देना चाहिए?

संकेत: विचार करें कि किस प्रोटोकॉल को ड्रॉप किया जा रहा है और क्या यह पेलोड बैंडविड्थ या कनेक्शन स्टेट सीमाओं से संबंधित है।

मॉडल उत्तर देखें

नहीं। WAN बैंडविड्थ बढ़ाने से समस्या हल नहीं होगी। UDP पैकेट ड्रॉप इंगित करते हैं कि फ़ायरवॉल या रिज़ॉल्वर समवर्ती DNS प्रश्नों (स्टेट टेबल की समाप्ति या CPU सीमा) की अत्यधिक मात्रा को संभालने में असमर्थ है। सही दृष्टिकोण यह है कि एज पर एक उच्च-प्रदर्शन स्थानीय DNS फ़िल्टर तैनात किया जाए ताकि WAN बॉटलनेक को पूरी तरह से दरकिनार करते हुए इन प्रश्नों का स्थानीय रूप से कैशिंग और उत्तर दिया जा सके।

Q2. आपने अभी एक होटल गेस्ट नेटवर्क पर एक एंटरप्राइज DNS फ़िल्टर तैनात किया है। गेस्ट अब सार्वजनिक वेबसाइटों को तेज़ी से रिज़ॉल्व कर सकते हैं, लेकिन जब वे पहली बार कनेक्ट होते हैं, तो उन्हें होटल के लॉगिन पेज पर रीडायरेक्ट नहीं किया जाता है। सबसे संभावित कॉन्फ़िगरेशन त्रुटि क्या है?

संकेत: खुद लॉगिन पेज के डोमेन नाम के बारे में सोचें।

मॉडल उत्तर देखें

सबसे संभावित त्रुटि यह है कि कैप्टिव पोर्टल के अपने डोमेन को DNS फ़िल्टर में स्पष्ट रूप से श्वेतसूची (पासथ्रू) में नहीं डाला गया है। फ़िल्टर या तो पोर्टल URL के रिज़ॉल्यूशन को ब्लॉक कर रहा है या उसमें देरी कर रहा है, जिससे रीडायरेक्शन पूरा होने से रुक रहा है।

Q3. एक सार्वजनिक क्षेत्र के संगठन को सुरक्षा नीतियों का अनुपालन करने के लिए 90 दिनों के लिए सभी गेस्ट WiFi ट्रैफ़िक को लॉग करने की आवश्यकता होती है। एक एंटरप्राइज DNS फ़िल्टर तैनात करने से इस आवश्यकता में कैसे मदद मिलती है?

संकेत: विचार करें कि मानक फ़ायरवॉल की तुलना में DNS फ़िल्टर किस डेटा को प्रोसेस करता है।

मॉडल उत्तर देखें

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

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

Why does guest WiFi say connected but no internet?

The 'Connected, No Internet' status occurs when a client device associates with an access point and receives an IP address, but its operating system detection probe fails to reach the internet. On guest WiFi networks, this is most commonly caused by DNS query timeouts on captive portal detection domains (such as captive.apple.com or connectivitycheck.gstatic.com), DHCP lease scope exhaustion, or firewalls blocking pre-authentication DNS traffic.

How do captive portal detection probes work on guest WiFi across iOS, Android, and Windows?

When connecting to an open or guest WiFi SSID, modern operating systems immediately transmit plaintext HTTP probe requests to vendor test URLs (iOS uses captive.apple.com/hotspot-detect.html, Android queries connectivitycheck.gstatic.com/generate_204, and Windows tests msftconnecttest.com/connecttest.txt). If the network returns an HTTP 200/204, the OS marks the connection as having internet. If it receives an HTTP 302 redirect, it launches the captive portal browser. If the initial DNS query for the probe domain times out, the OS reports 'Connected, No Internet' and drops the link.

How do DNS timeouts trigger guest WiFi connection drops?

In high-density environments, hundreds of devices query upstream DNS resolvers simultaneously over UDP port 53. If the local guest WiFi network forwards raw queries directly to rate-limited ISP resolvers without caching, response latency spikes above 2,000ms. Mobile devices enforce strict 2- to 5-second probe timeouts. Once that threshold is exceeded, the device assumes the network is broken and abandons the connection before the splash page can load.

What walled garden domains must be allowed before guest WiFi captive portal login?

Pre-authentication access control lists (walled gardens) on guest WiFi networks must permit outbound UDP and TCP port 53 to your designated DNS resolvers, DHCP transactions (UDP 67/68), and OS detection probes (captive.apple.com, connectivitycheck.gstatic.com, msftconnecttest.com). If using external captive portal hosting, CDN styling, or social login, you must also allow your portal domain (*.purple.ai), Google Fonts (fonts.googleapis.com), and OAuth endpoints.

How does DHCP pool exhaustion cause connected without internet errors on guest WiFi?

When venues configure long DHCP lease durations (such as 24 hours) on guest WiFi in environments with rapid visitor turnover, the pool of available IP addresses quickly runs out. New arrivals may associate with the access point via 802.11 beacons, but fail to receive a valid DHCPOFFER or default gateway, receiving a self-assigned 169.254.x.x APIPA address instead. Shortening lease times to 30 to 60 minutes and configuring dynamic VLAN pooling prevents scope starvation.

How does Purple prevent captive portal and DNS timeout failures on guest WiFi?

Purple acts as a resilient, hardware-agnostic guest WiFi management platform across Cisco Meraki, HPE Aruba, Ruckus, Ubiquiti UniFi, and Fortinet architectures. By optimizing captive portal redirection flows, automating walled garden rules, and integrating with high-speed Anycast DNS, Purple ensures detection probes succeed instantly, onboarding visitors in under 3 seconds without connection drops.

स्रोत

  1. RFC 1035: Domain names, implementation and specification
  2. RFC 8484: DNS queries over HTTPS (DoH)
  3. RFC 7858: DNS over Transport Layer Security (DoT)
  4. RFC 8910: Captive-portal identification in DHCP and Router Advertisements
  5. RFC 2131: Dynamic Host Configuration Protocol
  6. PCI Security Standards Council: PCI DSS
  7. Information Commissioner's Office: UK GDPR guidance

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

धीमी WiFi परफॉर्मेंस का निदान करने के लिए पैकेट कैप्चर (PCAP) का उपयोग करना

यह तकनीकी संदर्भ गाइड IT प्रबंधकों, नेटवर्क आर्किटेक्ट्स और वेन्यू ऑपरेशन्स निदेशकों को PCAP (पैकेट कैप्चर) विश्लेषण का उपयोग करके धीमी एंटरप्राइज WiFi परफॉर्मेंस का निदान और समाधान करने के लिए एक व्यवस्थित, पैकेट-स्तरीय कार्यप्रणाली प्रदान करती है। रीट्रांसमिशन दरों, एयरटाइम यूटिलाइजेशन और फिजिकल लेयर मेटाडेटा सहित रॉ 802.11 फ्रेम्स का विश्लेषण करके, टीमें वायर्ड या एप्लिकेशन समस्याओं से RF-लेयर की बाधाओं को सटीकता से अलग कर सकती हैं। होटल, रिटेल चेन, स्टेडियम और कॉन्फ्रेंस सेंटर्स सहित हाई-डेंसिटी वाले स्थानों पर लागू, यह गाइड नेटवर्क क्षमता को वापस पाने और गेस्ट एक्सपीरियंस को सुरक्षित रखने के लिए व्यावहारिक डायग्नोस्टिक वर्कफ़्लो, वास्तविक दुनिया के केस स्टडीज और कॉन्फ़िगरेशन सुधार के कदम प्रदान करती है।

गाइड पढ़ें →

आपके स्टेडियम का WiFi ठप क्यों हो जाता है (और इसे कैसे ठीक करें)

यह आधिकारिक तकनीकी गाइड स्टेडियम WiFi कंजेशन के मूल कारण — प्रोग्रैमेटिक विज्ञापनों और टेलीमेट्री को लोड करने वाले 50,000 डिवाइसों की एक साथ बैकग्राउंड चैटर — की जांच करती है, और प्राथमिक शमन रणनीति के रूप में Edge DNS फ़िल्टरिंग को तैनात करने के लिए एक विस्तृत आर्किटेक्चरल ब्लूप्रिंट प्रदान करती है। IT निदेशकों, CTO और नेटवर्क आर्किटेक्ट्स के लिए डिज़ाइन किया गया, यह वेन्यू ऑपरेटरों को बैंडविड्थ पुनः प्राप्त करने और बड़े पैमाने पर उच्च-प्रदर्शन कनेक्टिविटी प्रदान करने में मदद करने के लिए कार्रवाई योग्य कार्यान्वयन मार्गदर्शन, वास्तविक दुनिया के केस स्टडीज़ और मापने योग्य ROI फ्रेमवर्क प्रदान करता है।

गाइड पढ़ें →

हमारा गेस्ट WiFi इतना धीमा क्यों है? नेटवर्क कंजेशन का निदान

यह मार्गदर्शिका गेस्ट WiFi कंजेशन के छिपे हुए चालकों का निदान करती है - बैकग्राउंड टेलीमेट्री, प्रोग्रामेटिक विज्ञापन नेटवर्क और स्वचालित OS अपडेट - जो सामूहिक रूप से किसी गेस्ट द्वारा ब्राउज़र खोलने से पहले ही सार्वजनिक WiFi बैंडविड्थ का 40% तक उपभोग करते हैं। यह DNS फ़िल्टरिंग और QoS नीतियों के लिए एक चरणबद्ध, विक्रेता-तटस्थ कार्यान्वयन ढांचा प्रदान करता है जो उस बैंडविड्थ को पुनः प्राप्त करता है, गेस्ट अनुभव में सुधार करता है और मापने योग्य ROI प्रदान करता है। यह आतिथ्य (hospitality), खुदरा (retail), कार्यक्रमों और सार्वजनिक क्षेत्र के वातावरण में IT निदेशकों और संचालन प्रबंधकों के लिए लक्षित है।

गाइड पढ़ें →

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

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