हॉटेलच्या वाय-फायवर 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 डीफॉल्ट राहू द्या।

निवड प्रोफाइल नावात आणि सहाय्य टिपांमध्ये नोंदवा: कोणता पोर्ट, कोणता प्रोटोकॉल आणि कोणत्या नेटवर्कमुळे ती झाली। नंतर नेटवर्कच्या प्रशासकाला विचारा की पुढील उपकरण बदलीनंतरही तो पोर्ट उघडा राहील का, कारण गुपचूप गायब होणारा पर्यायी मार्ग कुठलाही पर्याय नसण्यापेक्षा वाईट आहे।