क्याप्टिभ पोर्टलले तपाईंको 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'अधिकृति अघि सामान्य पोर्टलले दुईमध्ये एउटा उत्तर दिन्छ: Location साइन-इन पृष्ठतर्फ देखाउने 302, वा पोर्टल पृष्ठ भएको HTML मुख्य भाग भएको 200। तपाईंले कुन पाउनुभयो लेख्नुहोस्। साइन इन अघिको पुनर्निर्देशन असफलता होइन; पोर्टलले तपाईंलाई कहाँ जाने भनेर भन्दै छ। पोर्टलले सफलताको रिपोर्ट गरेपछि आदेश दोहोर्याउनुहोस् र मुख्य भाग शब्दशः Success शब्द भएको 200 को अपेक्षा गर्नुहोस्। त्यही स्ट्रिङले प्रोबलाई अर्थपूर्ण बनाउँछ। तपाईंले कहिल्यै साइन इन गर्नुअघि होस्टले सामान्य रूपमा उत्तर दिन्छ भने यो नेटवर्कमा रोक्ने पोर्टल छैन। क्याप्चरमा अधिकृति अघिको फ्याँकिनु भनेको केही पनि फर्कन नआउने बाहिर जाने प्याकेटहरू हुन्, जबकि काम गर्ने मार्गले त्यही प्रवाहमा करिब एक सेकेन्डभित्र उत्तर देखाउँछ। जोडिनुहोस्, त्यसपछि क्याप्चर दोहोर्याउनुहोस्।
पोर्टलले हो भनेपछि पनि टनेल असफल भयो भने
साइन इनको सफलता अनुमति दिइएको यातायात जस्तै होइन। धेरै स्थलहरूले पोर्टल र सामान्य ब्राउजिङलाई अनुमति दिन्छन् तर UDP पूर्ण रूपमा अवरुद्ध गर्छन्, जसले WireGuard र UDP OpenVPN लाई तोडिएको र TCP 443 लाई काम गरिरहेको छोड्छ। TCP 443 जान्छ तर UDP जाँदैन भने त्यो तपाईंले गलत कन्फिगर गरेको क्लाइन्ट होइन, स्थलको नीति हो, त्यसैले यातायात बदल्नुहोस् वा सीमा स्वीकारेर अगाडि बढ्नुहोस्। त्यसपछि पनि पुनः जोडिन असफल भयो भने सही त्रुटि राख्नुहोस्; तपाईं कहाँ अड्किनुभयो त्यो भन्छ।
अरू असफलताहरू यन्त्रमै बस्छन्। पुरानो MAC सँग अझै बाँधिएको सत्र, आफ्नै भाडा भएको दोस्रो Wi-Fi एडाप्टर, वा पोर्टलको प्रमाणपत्र छुट क्यास गरेको क्लाइन्ट — यीमध्ये हरेक सफा पुनःअधिकृतिपछि पनि असफल हुँदै रहन सक्छ। जडान छोड्नुहोस्, फेरि अधिकृत गर्नुहोस्, र क्लाइन्टका सेटिङ छुनुअघि एक पटक प्रयास गर्नुहोस्। तपाईंले निरीक्षण गरिरहनुभएका घटकहरूको पछाडिको संरचना चाहनुहुन्छ भने RFC 8952 पढ्न लायक छ।
पोर्टल आफैंले अधिकृत गर्न अस्वीकार गर्यो भने समस्या खाता वा यन्त्र बाँडफाँटमा छ र कुनै VPN सेटिङले त्यो सुधार्ने छैन। VPN को निर्गमन देश बदल्नाले स्थलको स्थानीय पहुँच अवस्था रिसेट हुँदैन; त्यो तालिका तपाईंको यन्त्रसँग जोडिएको छ, तपाईंले छान्नुभएको सर्भरसँग होइन। स्थलको अपरेटरलाई सोध्नुहोस् र समय दिनुहोस्, किनभने उसले सत्र तालिका हेर्नेछ।
अर्को यात्राअघि तीन कुरा लेख्नुहोस्: शून्य चरणको रूपमा पोर्टल पृष्ठ, तपाईंले साथमा लैजाने हरेक यन्त्रका लागि अवरोध रोक्ने चरण, र तपाईंले साँच्चै परीक्षण गर्नुभएको एउटा वैकल्पिक यातायात। दस मिनेटअघि काम गरेको टनेल फेरि रोकियो भने त्यसलाई समाप्त भइसकेको अधिकृति मान्नुहोस् र VPN प्रोफाइल छुनुअघि पोर्टल फेरि जाँच्नुहोस्।