OpenVPN अजूनही 443 वर अडवलेला? नेटवर्क काय तपासते ते पाहा

बोगदा घरच्या लाइनमधून जोडतो आणि हॉटेल किंवा ऑफिसच्या नेटवर्कवर थांबतो, आणि सर्व्हर पोर्ट 443 वर हलवल्याने काहीच बदलले नाही। हा निकाल इतका सामान्य आहे की त्याला एक आकार आहे: पोर्ट सोपा भाग होता, आणि उरलेला निर्णय क्लायंट आणि सर्व्हरमध्ये बसलेल्या सगळ्याचा आहे। दोन प्रश्न बहुतेक प्रकरणे सोडवतात, आणि त्यातील एकही सिफरबद्दल नाही। नेटवर्क त्या पत्त्यावर TLS हस्तांदोलन स्वीकारते का, आणि बोगदा वर असताना क्लायंट आपल्या आवरणापर्यंतचा मार्ग ठेवतो का?

हस्तांदोलन क्रमांकापेक्षा जास्त उघड करते

TCP 443 वरील मूळ VPN श्रोता पहिल्या पॅकेटपासून आपल्या प्रोटोकॉलमध्ये बोलतो। ClientHello मध्ये आवृत्ती क्षेत्र, यादृच्छिक मूल्य आणि विस्तारांची यादी असते, आणि काहीशे बाइट वाचणारे उपकरण काहीही डिक्रिप्ट न करता फरक ओळखू शकते। पोर्ट क्रमांक तृप्त करणे स्वस्त आहे, आणि फिल्टर प्रत्यक्षात प्रोटोकॉलचा आकारच तपासतो। नियम सहसा प्रोटोकॉलनुसारही लिहिले जातात, म्हणून TLS तपासणारे धोरण UDP बद्दल काहीच सांगत नाही।

वैध TLS सत्रावर आग्रह करणारा पारदर्शक प्रॉक्सी सेटअपच्या वेळीच कनेक्शन टाकतो, बहुतेकदा TCP हस्तांदोलन पूर्ण झाल्यानंतर। तो तपशील नंतर महत्त्वाचा आहे, कारण सॉकेट तयार झाल्यानंतर क्लायंट लॉग थांबतो असा त्याचा अर्थ आहे।

प्रवाह आवरणात गुंडाळल्याने दोन अपयशाचे बिंदू तयार होतात

stunnel सारखे TLS आवरण अपेक्षित आकार परत आणते: क्लायंट स्थानिक श्रोत्याशी जोडतो, आवरण सर्व्हरशी 443 वर खरे TLS सत्र उघडते, आणि सर्व्हरवरील दुसरे आवरण डिक्रिप्ट केलेले बाइट VPN डिमनकडे पाठवते। बाहेरील सत्र आता इतर कोणत्याही HTTPS कनेक्शनसारखे दिसते। सर्व्हरवरील VPN डिमनने फक्त loopback वर ऐकले पाहिजे, कारण आवरणाबाहेरील कोणालाही त्याच्यापर्यंत पोहोचण्याची गरज नाही।

त्या रचनेसाठी तीन वेगळ्या गोष्टी जुळल्या पाहिजेत। क्लायंट प्रोफाइल स्थानिक श्रोत्याकडे निर्देश करते, सर्व्हर प्रमाणपत्र क्लायंट तपासत असलेल्या नावाशी जुळते, आणि सर्व्हर बाजूचे अग्रेषण डिमन प्रत्यक्षात वापरत असलेल्या पोर्टला लक्ष्य करते। यापैकी एकही चुकल्यास VPN स्तर गाठण्यापूर्वीच कनेक्शन मरते। मग प्रमाणपत्राची विसंगती VPN त्रुटी म्हणून नाही, आवरणाची त्रुटी म्हणून दिसते, आणि म्हणूनच दोन्ही लॉग शेजारी शेजारी वाचणे योग्य आहे।

आवरणाकडे जाणारा मार्ग हाच सापळा

बोगदा वर आल्यावर डीफॉल्ट मार्ग त्याच्याकडे निर्देश करतो, आणि बाहेरील TLS सत्राला असा रस्ता हवा जो तो वाहत असलेल्या बोगद्यात जात नाही। सामान्य VPN क्लायंट आपण डायल करत असलेल्या पत्त्याचे रक्षण करतो; आवरण केलेला क्लायंट आपल्या loopback ला डायल करतो, त्यामुळे आवरणाचा गंतव्य पत्ता त्या संरक्षणाला अदृश्य असतो।

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

नेमके पत्ते तुम्हीच भरायचे आहेत, आणि मार्ग कनेक्शनच्या संपूर्ण आयुष्यभर असला पाहिजे, फक्त सुरुवातीला नाही। क्लायंटच्या आधी मार्ग जोडणारे आणि नंतर काढणारे छोटे आवरण स्क्रिप्ट लक्षात ठेवलेल्या आदेशापेक्षा विश्वासार्ह आहे।

Android वर त्या अपवादाची समानता प्रति-अॅप सेटिंग आहे: आवरण अॅप बोगद्यातून वगळा जेणेकरून त्याचा स्वतःचा रहदारी मोबाइल कनेक्शनने बाहेर जाईल। वगळले नाही तर आवरण जो बोगदा बनवू पाहत आहे त्यातच पाठवले जाते, आणि पुन्हा जोडण्याचे चक्र सर्व्हरची समस्या वाटते।

काहीही बदलण्यापूर्वी वेळ वाचा

प्रत्येक वेळी त्याच अंतरानंतर मरणारे सत्र क्रिप्टोग्राफिक अपयश नाही, धोरणाची सही आहे, आणि दीर्घकालीन प्रवाह मर्यादा नेमकी तीच पद्धत निर्माण करतात। हस्तांदोलनानंतर लगेच रीसेट होणारे कनेक्शन प्रमाणपत्र साखळी आवडली नसलेल्या प्रॉक्सीकडे निर्देश करते।

दोन्ही नेटवर्कमधून सामान्य HTTPS साइटच्या प्रमाणपत्राच्या जारीकर्त्याची तुलना करा। मर्यादित नेटवर्कवर जारीकर्ता वेगळा असेल तर मध्ये काहीतरी TLS संपवत आहे, आणि कोणतेही आवरण तो अडथळा बदलाशिवाय पार करणार नाही। तीच तुलना तुम्हाला सांगते की ब्लॉक तुमच्या सर्व्हरच्या नावाला लक्ष्य करतो की त्या पत्त्यावरील प्रत्येक TLS सत्राला।

दिसलेले वर्तन लिहा: सत्र किती काळ टिकले, सॉकेट उघडले का, आवरणाने हस्तांदोलन लॉग केले का। यातील प्रत्येक पुढील चाचणी अरुंद करते।

एका वेळी एक चल तपासा

आधी UDP तपासा, कारण काही नेटवर्क ते पूर्णपणे टाकतात, आणि UDP अपयश 443 बद्दल काहीच सांगत नाही। नंतर आवरणाशिवाय TCP 443 वापरून पाहा, नंतर 443 वर आवरण। प्रत्येक टप्प्यावर क्लायंट लॉग वाचा आणि वर्तन बदलताच थांबा।

प्रत्येक प्रयत्नात एक घटक बदला। नवा पोर्ट, नवे आवरण आणि नवे सिफर एकाच फेरीत ठेवल्यास तीनपैकी कोणते महत्त्वाचे होते हे तुम्ही सांगू शकणार नाही।