क्यों कैप्टिव पोर्टल आपके VPN को रोकता है, और फिर से साइन इन कैसे करें
सार्वजनिक Wi-Fi आपके डिवाइस को मंज़ूरी देता है, इससे पहले कि उससे कोई पैकेट निकले। पोर्टल क्या गिराता है, आपका VPN इसे गलत क्यों बताता है, और कौन-सा क्रम आपको फिर से जोड़ता है।
खुले नेटवर्क पर आपका एक्सेस पॉइंट पैकेटों को यूँ ही इंटरनेट को नहीं सौंपता। ऊपर की ओर एक पॉलिसी पॉइंट जाँचता है कि आपके डिवाइस को मंज़ूरी मिली है या नहीं, और जब तक नहीं मिलती, लगभग सब कुछ गिरा दिया जाता है। आपका VPN क्लाइंट उस खामोशी को मृत सर्वर के रूप में पढ़ता है। वह यह शायद ही कहता है: WireGuard खालीपन में हैंडशेक दोहराता है, OpenVPN कनेक्शन टाइमआउट की सूचना देता है, और IKEv2 उस दूर के सर्वर के बारे में त्रुटि 809 के साथ लौटता है जो जवाब नहीं दे रहा।
पोर्टल वास्तव में क्या नियंत्रित करता है
कैप्टिव पोर्टल दो चीज़ें हैं जो एक साथ जुड़ी हैं: एक पॉलिसी निर्णय बिंदु और एक रीडायरेक्टर। जब आपका डिवाइस जुड़ता है और DHCP लीज़ लेता है, तो नेटवर्क आपको मंज़ूरी से पहले की स्थिति में रखता है।
वह स्थिति फ़ायरवॉल नियमों का एक समूह है। यह आमतौर पर DNS की अनुमति देता है और पोर्टल होस्ट की एक छोटी सूची तक HTTP या HTTPS की अनुमति देता है, और बाकी सब कुछ गिरा देता है। अनुमत सूची वह दीवारों वाला बगीचा है, और इसमें लगभग कभी VPN एंडपॉइंट शामिल नहीं होता।
इनमें से कोई भी गिराना विनम्र नहीं है। VPN सर्वर की ओर भेजे गए पैकेट अस्वीकार होने के बजाय गिरा दिए जाते हैं, इसलिए क्लाइंट को न ICMP unreachable मिलता है और न TCP reset, सिर्फ़ जवाब का अभाव। विक्रेता के अनुसार, रीडायरेक्टर पोर्ट 80 पर साइन-इन पेज की ओर रीडायरेक्ट के साथ जवाब दे सकता है जबकि पोर्ट 443 गिराया या रोका जाता है। रीडायरेक्ट पहचानना आसान है क्योंकि वे सादा HTTP जवाब ले जाते हैं; 443 पर रोकने के लिए ऐसा प्रमाणपत्र चाहिए जिस पर आपका ब्राउज़र भरोसा करने से मना कर देगा।
मंज़ूरी खुद आमतौर पर डिवाइस के MAC पते से जुड़ी होती है, कभी-कभी लीज़ किए गए IP से, और वह टाइमर वाली सत्र तालिका में रहती है। साइन इन करने से एक प्रविष्टि बनती है। जो फ़ायरवॉल नियम आपके ट्रैफ़िक को जाने देता है वह सिर्फ़ तब तक मौजूद रहता है जब तक वह प्रविष्टि है, और इसलिए आपकी ओर कुछ बदले बिना पूरी समस्या बाद में लौट आती है।
VPN हैंडशेक शुरू होने से पहले क्यों मर जाता है
हर प्रोटोकॉल का अपना ट्रांसपोर्ट है, और मंज़ूरी से पहले का फ़ायरवॉल हर एक को अलग तरह से तोड़ता है। Windows और iOS पर IKEv2 UDP 500 और UDP 4500 पर चलता है; उन पोर्ट पर गिराया जाना 809 के रूप में, या उन क्लाइंट पर नाम-हल जैसी विफलता के रूप में दिखता है जो चरण अलग-अलग बताते हैं। UDP 1194 पर OpenVPN अपना समय खत्म होने तक कनेक्टिंग स्थिति में रहता है। TCP 443 पर OpenVPN दिलचस्प मामला है, क्योंकि पोर्टल TCP हैंडशेक पूरा करके फिर अपने रीडायरेक्ट पेज से जवाब दे सकता है, इसलिए आपको टाइमआउट के बजाय TLS त्रुटि दिखती है।
WireGuard इस तंत्र को सबसे साफ़ दिखाता है। यह डिज़ाइन से केवल UDP है, कोई TCP विकल्प नहीं, इसलिए अज्ञात UDP गिराने वाला फ़ायरवॉल ट्रांसपोर्ट को पूरी तरह हटा देता है। क्लाइंट बढ़ते अंतराल के साथ हैंडशेक शुरुआतें भेजता रहता है और ऐसे हैंडशेक की सूचना देता है जो कभी पूरा नहीं होता। उस संदेश में कहीं Wi-Fi का ज़िक्र नहीं है, और उसमें कुछ भी यह नहीं सुझाता कि आपको ब्राउज़र खोलना चाहिए।
प्लेटफ़ॉर्म आपके VPN से पहले स्थिति को भाँपने की कोशिश करते हैं। Windows साइन-इन सूचना दिखानी है या नहीं यह तय करने के लिए एक ज्ञात URL लाता है, Android ऐसा एंडपॉइंट माँगता है जिसे 204 No Content का जवाब देना चाहिए, और Apple डिवाइस एक छोटी कैप्टिव-नेटवर्क विंडो खोलते हैं। वे प्रोब काम करते हैं क्योंकि पोर्टल अपेक्षित बॉडी के बजाय रीडायरेक्ट से जवाब देता है। यही व्यवहार समझाता है कि पोर्टल पूरी तरह स्वस्थ कैसे दिख सकता है जबकि आपका टनल मृत है: प्रोब और टनल को अलग नियमों से परखा जाता है।
सत्र समाप्ति वास्तव में क्या रीसेट करती है
स्थल आपके VPN खाते से असंबंधित कारणों से सत्र समाप्त करते हैं: निष्क्रियता का समय, सत्र की अधिकतम अवधि, नई DHCP लीज़, या किसी दूसरे एक्सेस पॉइंट पर फिर से जुड़ना। जब टाइमर बजता है, सत्र तालिका की प्रविष्टि गायब हो जाती है और मंज़ूरी से पहले का नियम समूह ठीक वैसा ही लौट आता है जैसा चेक-इन के समय था।
स्थापित टनल अक्सर स्वस्थ दिखने के लिए पर्याप्त समय तक टिकता है। कीपअलाइव संदेश बाहर जाते रहते हैं, और क्लाइंट इसे नोटिस करता है या नहीं यह इस पर निर्भर करता है कि वह बिना जवाब वाले ट्रैफ़िक को कैसे संभालता है, इसलिए रास्ता जाने के बाद भी स्थिति बत्ती कुछ देर हरी रह सकती है। फिर टनल गिर जाता है और फिर से जुड़ने की हर कोशिश उन्हीं अवरुद्ध पोर्ट पर विफल होती है।
उस समय क्लाइंट की त्रुटि आपको बताती है कि आप किस चरण पर हैं, अगर आप उसे ध्यान से पढ़ें:
| Symptom | What it means | Next check |
|---|---|---|
| Handshake times out with no reply | Pre-authorization drop on UDP | Load any HTTP page and see whether the portal appears |
| Immediate TLS error on 443 | The portal answered your TCP connection | Authorize, then retry the same profile |
| Authentication rejected | Your credentials reached the server | The network is fine, so treat this as an account problem |
| Connects, then drops repeatedly | Session or lease churn | Watch the portal timer and the lease time |
एक ब्यौरा लोगों को भ्रमित करता है: जब सत्र MAC पते से बंधा हो, तो साइन-इन पेज फिर से लोड करने से शायद मदद न मिले। आपको जुड़ाव छोड़कर फिर से जुड़ना होगा ताकि पोर्टल समाप्त प्रयास के बजाय नया मंज़ूरी प्रयास देखे।
पहले साइन इन करें, फिर टनल उठाएँ
जो क्रम काम करता है वह है: डिवाइस को मंज़ूरी दें, रास्ता साबित करें, VPN शुरू करें, टनल साबित करें, और फिर अपना सामान्य अवरोध बहाल करें। वह आखिरी कदम मायने रखता है क्योंकि पोर्टल तक पहुँचने के लिए जो अस्थायी स्थिति चाहिए, वह ठीक वही स्थिति है जिसे रोकने के लिए किल स्विच मौजूद है।
टनल के बाहर अवरोध का विकल्प रखने वाले डेस्कटॉप क्लाइंट को पोर्टल पेज लोड होने के लिए रोकना पड़ता है, और उस बाहर वाली खिड़की के दौरान संवेदनशील ऐप्स बंद रखनी चाहिए; यही एकमात्र अंतराल है जब स्थानीय ट्रैफ़िक बिना सुरक्षा के बाहर जाता है। प्रबंधित हमेशा-चालू डिवाइस को उसकी मालिक द्वारा प्रकाशित प्रक्रिया का उपयोग करना चाहिए, आपके द्वारा नीति हटाने के बजाय। अगर पोर्टल प्रमाणपत्र चेतावनी दिखाए, तो रुकें: उसे स्वीकार करने से आपका सत्र स्थल के अवरोध प्रॉक्सी से होकर जाता है, और वह प्रॉक्सी आपके द्वारा भेजा गया सब कुछ पढ़ सकती है। Android पर हमेशा-चालू VPN के अधीन लॉकडाउन टनल उठने से पहले ट्रैफ़िक रोक देता है, और कुछ बिल्ड पोर्टल प्रवाह को छूट नहीं दे सकते; अगर आपका नहीं दे सकता, तो लॉकडाउन बंद छोड़ने के बजाय स्थल का वैकल्पिक एक्सेस या दूसरा डिवाइस इस्तेमाल करें। Apple के ऑन-डिमांड नियम ऐसे लिखे जा सकते हैं कि प्रोब सफल होने तक टनल से इनकार करें, और होटल नेटवर्क पर आप यही व्यवहार चाहते हैं।
जो उपकरण आपके पास पहले से हैं उनसे क्रम में जाँचें। टनल से पहले प्रोब को हेडर और बॉडी दोनों दिखते हुए चलाएँ, और देखें कि आपके VPN ट्रांसपोर्ट को कोई जवाब मिलता है या नहीं:
curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'मंज़ूरी से पहले सामान्य पोर्टल दो में से एक जवाब देता है: 302 जिसका Location साइन-इन पेज की ओर इशारा करता है, या 200 जिसकी HTML बॉडी पोर्टल पेज है। लिख लें कि आपको कौन-सा मिला। साइन इन से पहले रीडायरेक्ट विफलता नहीं है; पोर्टल आपको बता रहा है कि कहाँ जाना है। पोर्टल सफलता की सूचना देने के बाद कमांड दोहराएँ और 200 की अपेक्षा करें जिसकी बॉडी शब्दशः Success शब्द है। वही स्ट्रिंग प्रोब को अर्थपूर्ण बनाती है। अगर होस्ट सामान्य रूप से जवाब देता है इससे पहले कि आपने कभी साइन इन किया हो, तो इस नेटवर्क पर कोई अवरोध पोर्टल नहीं है। कैप्चर में मंज़ूरी से पहले गिराया जाना बाहर जाते पैकेट हैं जिनसे कुछ भी वापस नहीं आता, जबकि काम करने वाला रास्ता उसी प्रवाह पर लगभग एक सेकंड में जवाब दिखाता है। कनेक्ट करें, फिर कैप्चर दोहराएँ।
अगर पोर्टल हाँ कहने के बाद भी टनल विफल रहे
साइन इन की सफलता अनुमत ट्रांसपोर्ट के बराबर नहीं है। कई स्थल पोर्टल और सामान्य ब्राउज़िंग की अनुमति देते हैं जबकि UDP को पूरी तरह अवरुद्ध करते हैं, जिससे WireGuard और UDP OpenVPN टूटे रह जाते हैं और TCP 443 काम करता रहता है। अगर TCP 443 निकल जाता है और UDP नहीं, तो यह स्थल की नीति है, आपका गलत कॉन्फ़िगर किया क्लाइंट नहीं, इसलिए ट्रांसपोर्ट बदलें या सीमा स्वीकार करके आगे बढ़ें। अगर उसके बाद भी फिर से जुड़ना विफल रहे, तो सटीक त्रुटि रख लें; वह बताती है कि आप किस चरण पर अटके हैं।
दूसरी विफलताएँ डिवाइस में रहती हैं। पुराने MAC से अब भी बंधा सत्र, अपनी लीज़ वाला दूसरा Wi-Fi अडैप्टर, या वह क्लाइंट जिसने पोर्टल की प्रमाणपत्र छूट कैश कर ली है — इनमें से हर एक स्वच्छ पुनर्मंज़ूरी के बाद भी विफल होता रह सकता है। जुड़ाव छोड़ें, फिर से मंज़ूरी दें, और क्लाइंट सेटिंग्स छूने से पहले एक बार फिर कोशिश करें। अगर आप उन घटकों के पीछे की संरचना चाहते हैं जिन्हें आप देख रहे हैं, तो RFC 8952 पढ़ने लायक है।
अगर पोर्टल खुद मंज़ूरी देने से इनकार कर दे, तो समस्या खाते या डिवाइस आवंटन में है और कोई भी VPN सेटिंग उसे ठीक नहीं करेगी। VPN का निकास देश बदलने से स्थल की स्थानीय एक्सेस स्थिति रीसेट नहीं होती; वह तालिका आपके डिवाइस से जुड़ी है, आपके चुने सर्वर से नहीं। स्थल के ऑपरेटर से पूछें और उसे समय दें, क्योंकि वह सत्र तालिका ही देखेगा।
अपनी अगली यात्रा से पहले तीन चीज़ें लिख लें: शून्य कदम के रूप में पोर्टल पेज, आपके साथ जाने वाले हर डिवाइस के लिए अवरोध थामने का कदम, और एक वैकल्पिक ट्रांसपोर्ट जिसे आपने सचमुच परखा हो। जब दस मिनट पहले काम करने वाला टनल फिर रुक जाए, तो उसे समाप्त मंज़ूरी मानें और VPN प्रोफ़ाइल छूने से पहले पोर्टल फिर से जाँचें।