होटल के वाई-फ़ाई पर OpenVPN कनेक्ट नहीं होता? TCP 443 आज़माएँ

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

पहले फ़ोन के हॉटस्पॉट से जाँचें। अगर वहाँ टनल बन जाती है, तो सर्वर, प्रमाणपत्र और खाता सब ठीक हैं, और बचा हुआ एकमात्र चर आपके सामने का नेटवर्क है।

क्लाइंट से शुरू करें: स्टेटस लाइन पढ़ें

स्टेटस लाइन बताती है कि कौन-सा चरण विफल हुआ। कनेक्टिंग पर अटका क्लाइंट अभी होस्ट हल कर रहा है या बाहरी सॉकेट खोल रहा है; सर्वर की प्रतीक्षा तक पहुँचने वाले क्लाइंट के पास रास्ता है पर जवाब नहीं; जो प्रमाणीकरण करके फिर गिर जाता है उसकी समस्या बिल्कुल अलग है। क्लाइंट लॉग और प्रोफ़ाइल के अपने remote और proto फ़ील्ड दिखाते हैं कि क्लाइंट क्या करने की कोशिश कर रहा है, और कमांड-लाइन क्लाइंट पर --verb 4 वही विवरण छापता है। उसकी तुलना सामने के नेटवर्क से करना ही 'वीपीएन ब्लॉक है' को एक ठोस दावे में बदलता है।

फिर जो औज़ार पहले से हैं उनसे नेटवर्क जाँचें। nc -vzu 203.0.113.10 1194 एक UDP डेटाग्राम भेजता है, curl -v telnet://203.0.113.10:443 बताता है कि TCP हैंडशेक पूरा होता है या नहीं, और HTTPS पेज लोड करने वाला ब्राउज़र केवल यह साबित करता है कि बाहर जाता 443 उस एक ही होस्ट तक पहुँचता है। छोटी जाँच वह जवाब देती है जो वीपीएन क्लाइंट नहीं दे सकता: इस नेटवर्क से कौन-सा पोर्ट और कौन-सा प्रोटोकॉल बाहर जाता ही है।

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

लिसनर और प्रोफ़ाइल साथ-साथ बदलें

सर्वर की ओर लिसनर को वही रखें जिसकी नेटवर्क अनुमति देता है: सर्वर कॉन्फ़िगरेशन में port 443 और proto tcp, फिर सेवा फिर शुरू करें और ss -lntp से सॉकेट की पुष्टि करें। क्लाइंट की ओर प्रोफ़ाइल को सहमत होना पड़ेगा, क्योंकि ट्रांसपोर्ट और पोर्ट टनल के बाहर हैं: .ovpn में proto tcp और port 443, या ऐप की सेटिंग स्क्रीन में वही फ़ील्ड। अभी भी UDP 1194 पर लक्षित प्रोफ़ाइल ठीक पहले जैसे ही विफल होता है, और मन करता है कि दोष उस फ़ायरवॉल पर डालें जो पहले ही ठीक हो चुका है। अगर वही होस्ट 443 पर HTTPS का जवाब भी देता है, तो दोनों लिसनर वह पता और प्रोटोकॉल साझा नहीं कर सकते; वीपीएन को दूसरा पता दें या आगे डीमल्टीप्लेक्सर लगाएँ।

दोनों सिरों पर tcpdump -ni any port 443 से पहला कनेक्शन देखें। क्लाइंट से निकलकर कभी न पहुँचने वाले पैकेट का मतलब है कि नेटवर्क आख़िर में फ़िल्टर कर रहा है, या प्रोफ़ाइल का पता वह नहीं है जो आप मान रहे हैं। बिना जवाब पहुँचने वाले पैकेट आपको सर्वर लॉग पर वापस भेजते हैं, जहाँ प्रोटोकॉल की असंगति तुरंत गिराए गए पैकेट के रूप में दिखती है।

जब नेटवर्क से सिर्फ़ प्रॉक्सी बाहर जाती है

कुछ अतिथि नेटवर्क HTTP प्रॉक्सी के अलावा कुछ भी नहीं देते, जो बंद पोर्ट से अलग बाधा है और OpenVPN से भी ज़्यादा को बाहर कर देती है। केवल PPTP, L2TP/IPsec या नंगे IPsec बोलने वाले क्लाइंट के लिए उसमें से निकलने का कोई रास्ता नहीं, क्योंकि वे डिज़ाइन मानते हैं कि उनका बाहरी प्रोटोकॉल सीधे सर्वर तक पहुँचेगा। OpenVPN कर सकता है, क्लाइंट प्रोफ़ाइल में http-proxy proxy.example.net 8080 के साथ, बशर्ते प्रॉक्सी आपके पोर्ट तक CONNECT विधि की अनुमति दे। SOCKS प्रॉक्सी और भी आसान है, क्योंकि वह अंदर क्या है इसकी परवाह किए बिना स्ट्रीम आगे भेजता है।

जहाँ क्लाइंट में प्रॉक्सी समर्थन नहीं है, वहाँ 443 पर SSH टनल ही आमतौर पर बचती है। यह एक दूसरी परत जोड़ती है, और नेटवर्क का संचालक इस पर राय रख सकता है, इसलिए इसे किसी एक यात्रा का पुल मानें, वास्तुकला नहीं।

रखने से पहले वैकल्पिक रास्ते की कीमत जानें

TCP के अंदर TCP की एक ज्ञात कीमत है। जब बाहरी कनेक्शन TCP हो और पेलोड भी TCP, तब खोया सेगमेंट दोनों परतों पर पुनःप्रेषण भड़काता है, और भीतरी कनेक्शन ऐसी हानि से पीछे हटता है जो उसे दिखती नहीं। ब्राउज़िंग यह झेल जाती है; इंटरैक्टिव सत्र और कॉल इसे महसूस करते हैं। TCP 443 लिसनर को उन नेटवर्क के लिए वैकल्पिक रास्ता रखें जो उसकी माँग करते हैं, और UDP को उन सबके लिए डिफ़ॉल्ट रहने दें जो अब भी उसे जाने देते हैं।

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