होटल Wi-Fi: VPN सर्वर तक पहुँचने से पहले ही विफल हो जाता है
टनल विफल हो जाता है क्योंकि कैप्टिव पोर्टल ने अभी आपको अधिकृत नहीं किया। होटल नेटवर्क में साइन इन करें, सामान्य HTTPS काम करता है यह जाँचें, फिर VPN जोड़ें।
VPN क्लाइंट घूमता रहता है, फिर बताता है कि सर्वर तक नहीं पहुँच सकता, और सब मान लेते हैं कि होटल VPN ब्लॉक करता है। आम तौर पर ऐसा नाटकीय कुछ नहीं हुआ: नेटवर्क ने आपको अभी बाहर जाने नहीं दिया। कैप्टिव पोर्टल हर कनेक्शन को तब तक रोकता है जब तक आप साइन इन नहीं करते, और जब लॉगिन पेज उसके पैकेट पकड़ रहा हो तब टनल पूरा नहीं हो सकता। टनल को दोष देने से पहले साइन इन पूरा करें।
भ्रम: होटल VPN ब्लॉक करता है
अधिकांश होटल नेटवर्क टनल को खास तौर पर फ़िल्टर नहीं करते। वे वेब ट्रैफ़िक तब तक पकड़ते हैं जब तक मेहमान प्रमाणित न हो, और डिवाइस सीमित कर सकते हैं, सत्र समाप्त कर सकते हैं या गति घटा सकते हैं। इनमें से हर चीज़ ऐसी विफलता बनाती है जो VPN क्लाइंट के भीतर से ब्लॉक जैसी दिखती है।
यहाँ टनल खराब निदान उपकरण है, क्योंकि पोर्टल अधिकृत न होने तक विफल होने वाला यह अकेला ऐप है। सामान्य वेब पहुँच बेहतर संकेतक है, क्योंकि वह आपको लॉगिन पेज ही दिखा सकती है।
यह क्रम एक और कारण से मायने रखता है: किल स्विच या हमेशा-चालू मोड वाला क्लाइंट पोर्टल लोड करने से मना कर देगा, और उपयोगकर्ता मानेगा कि नेटवर्क खराब है, सेटिंग नहीं। दोनों तथ्य एक साथ सच हैं, और होटल में केवल एक बदला जा सकता है। क्लाइंट के अपने नियंत्रण से सुरक्षा बंद करें, साइन इन करें और फिर चालू करें। बाकी सब ऐसा रास्ता है जो असली क्रम छिपाता है।
पहले पोर्टल पूरा करें, फिर सामान्य HTTPS जाँचें
स्टाफ़ से आधिकारिक नेटवर्क नाम और साइन इन तरीका पूछें। विश्वसनीय दिखने वाला SSID मालिकाना साबित नहीं करता, और मिलते-जुलते नाम का दूसरा नेटवर्क सार्वजनिक जगहों पर आम चाल है। जहाँ उपलब्ध हो ऑपरेटिंग सिस्टम का अपना साइन इन संकेत इस्तेमाल करें, या होटल का प्रलेखित पेज।
curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/पहला अनुरोध सादे HTTP पर एक जाना-माना कैप्टिव-पोर्टल पहचान एंडपॉइंट पूछता है; रीडायरेक्ट या अप्रत्याशित सामग्री का मतलब है कि आप अब भी पोर्टल के पीछे हैं। दूसरा सामान्य HTTPS साइट जाँचता है। अगर पहला अवरोधन दिखाए और दूसरा विफल हो, तो साइन इन अधूरा है और VPN का इससे कोई लेना-देना नहीं।
निजी डिवाइस पर पोर्टल लोड हो सके इसके लिए किल स्विच या हमेशा-चालू VPN को क्लाइंट के समर्थित नियंत्रण से बंद करना पड़ सकता है। उस दौरान संवेदनशील ऐप बंद रखें और तुरंत बाद सुरक्षा फिर चालू करें। प्रबंधित डिवाइस पर स्वयं नीति हटाने के बजाय प्रशासक द्वारा स्वीकृत प्रक्रिया अपनाएँ।
ऑनलाइन आने के लिए कभी प्रमाणपत्र चेतावनी को नज़रअंदाज़ न करें और न ही अज्ञात प्रमाणपत्र या सहायक ऐप इंस्टॉल करें। अगर पोर्टल कुछ अप्रत्याशित माँगे, तो स्टाफ़ से पुष्टि करें, और अगर डिवाइस नियोक्ता का है तो प्रशासक से।
मूल प्रोफ़ाइल और उसकी त्रुटि रखें
सामान्य पहुँच काम करने पर मूल प्रोफ़ाइल जोड़ें और सटीक त्रुटि दर्ज करें। प्रमाणीकरण अस्वीकृति खाते की समस्या है, बातचीत के दौरान समय-समाप्ति पथ की समस्या है, और बनने पर भी कुछ न ले जाने वाला टनल रूटिंग या नीति की समस्या है।
इन तीनों को अलग अगले कदम चाहिए, और त्रुटि का स्क्रीनशॉट विवरण से अधिक मूल्यवान है। समय भी लिखें, क्योंकि होटल सत्र सीमा एक घंटे में समाप्त हो सकती है और ऐसी विफलता दे सकती है जो यादृच्छिक लगे। अगर क्लाइंट लॉग देता है, तो पूरी फ़ाइल के बजाय पहली विफलता के आसपास का हिस्सा रखें। वह अंश आम तौर पर प्रोफ़ाइल के मालिक को चरण पहचानने के लिए पर्याप्त होता है।
अगर सामान्य पहुँच काम करती है और बातचीत अब भी समय-समाप्त होती है, तो होटल से पूछें कि क्या वह इस ट्रैफ़िक का समर्थन करता है, और डिवाइस व प्रोफ़ाइल स्थिर रखते हुए किसी विश्वसनीय हॉटस्पॉट से तुलना करें। हॉटस्पॉट पर काम करने से ध्यान प्रोफ़ाइल के बारे में कुछ साबित किए बिना होटल के पथ पर सिमट जाता है।
केवल वही विकल्प इस्तेमाल करें जो ऑपरेटर देता है
मिलता-जुलता TCP प्रोफ़ाइल वहाँ सफल हो सकता है जहाँ दिया गया UDP पथ काम नहीं करता, पर केवल तब जब सर्वर वास्तव में उस ट्रांसपोर्ट और पोर्ट पर सुनता हो। TCP पोर्ट 443 को अपने आप सामान्य HTTPS नहीं माना जाता, और यह प्रतिबंधक नेटवर्क से गुज़रने की गारंटी नहीं है।
sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4
दिए गए प्रोफ़ाइल को अधिक विस्तार से चलाने पर पहली उपयोगी त्रुटि दिखती रहती है, सामान्य विफलता संवाद में दबने के बजाय। जो फ़ाइल ऑपरेटर ने दी है उसी का उपयोग करें, पोर्ट या प्रोटोकॉल स्वयं न बदलें, क्योंकि स्थानीय बदलाव दूसरी ओर मेल खाता श्रोता नहीं बना सकता।
अगर टनल बार-बार रीसेट हो, तो देखें कि पोर्टल फिर दिखता है या स्थानीय सिग्नल गिरता है, और एक साथ कई प्रोटोकॉल बदलने के बजाय स्थिरता जाँचें अपनाएँ। फिर वह ऐप जाँचें जिसकी आपको वास्तव में ज़रूरत है और सामान्य गोपनीयता नियंत्रण बहाल करें। जो कनेक्शन एक साइट ले जाता है पर दूसरी नहीं, वह पोर्टल नहीं, रूटिंग या नीति का सवाल है।
अंत में, लैपटॉप के सोने के बाद वसूली जाँचें। पोर्टल प्राधिकरण टनल से स्वतंत्र रूप से समाप्त हो सकता है, इसलिए अपने आप फिर जुड़ने वाला डिवाइस ऐसे नेटवर्क पर लौट सकता है जो उसे भुला चुका है। पोर्टल पेज फिर खोलना सामान्य कदम है, VPN के खराब होने का संकेत नहीं।