OpenVPN के लिए SOCKS5 प्रॉक्सी: TCP सुरंग या ऐप्स को प्रॉक्सी करना?

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

एक बाधा डिज़ाइन तय करती है

SOCKS5 वाकई UDP एसोसिएशन मोड निर्दिष्ट करता है। फिर भी OpenVPN क्लाइंट का प्रॉक्सी समर्थन स्ट्रीम के इर्द-गिर्द बना है: socks-proxy TCP प्रोफ़ाइल के लिए प्रलेखित है, और HTTP CONNECT प्रॉक्सी के पास डेटाग्राम के लिए कोई रास्ता ही नहीं है। दस्तावेज़ की एक पंक्ति कॉन्फ़िगरेशन फ़ाइल छूने से पहले आर्किटेक्चर तय कर देती है।

इसलिए सवाल यह नहीं है कि कौन-सी प्रॉक्सी चुनें। सवाल यह है कि सुरंग स्ट्रीम बनती है, या डेटाग्राम रहती है और कुछ और प्रॉक्सीिंग अपने ऊपर ले लेता है।

विकल्प A: सुरंग को स्ट्रीम बनाएँ

इसके लिए TCP श्रोता वाला सर्वर और प्रॉक्सी का नाम बताने वाला क्लाइंट प्रोफ़ाइल चाहिए। दोनों हिस्से ज़रूरी हैं, और सर्वर पक्ष वही है जिसे लोग भूल जाते हैं:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

अंतिम पंक्ति को http-proxy proxy.internal 8080 से बदलें जब प्रॉक्सी HTTP बोलती है, और अगर मांगे तो क्रेडेंशियल फ़ाइल जोड़ें। प्रॉक्सी को आपके VPN पोर्ट पर CONNECT करने को तैयार होना चाहिए, और सर्वर को TCP पर उत्तर देना चाहिए; केवल UDP श्रोता उस प्रयास को अनदेखा करता है। 443 चुनना व्यावहारिक कदम है, क्योंकि कई प्रतिबंधक नेटवर्क उसे और बहुत कम अन्य चीज़ों को अनुमति देते हैं।

लागत है TCP पर TCP थोपना। एक खोया बाहरी खंड उस कनेक्शन को साझा करने वाली हर आंतरिक स्ट्रीम को रोक देता है, इसलिए जो रिकवरी आम तौर पर स्वतंत्र होती, वह साझा हो जाती है। सेटअप में भी अधिक समय लगता है, और अस्थिर बाहरी मार्ग धीमी सुरंग के बजाय अस्थिर सुरंग बन जाता है।

विकल्प B: सुरंग को अकेला छोड़ दें

जब सुरंग को UDP पर ही रहना हो, तो सुरंग वह जगह नहीं है जहाँ आप कुछ कॉन्फ़िगर करते हैं। इसके बजाय ऐप्स से जाता TCP स्थानीय SOCKS श्रोता की ओर रीडायरेक्ट होता है, और ऐप्स को कभी पता नहीं चलता कि प्रॉक्सी मौजूद है। Linux पर यह आम तौर पर redsocks और nat तालिका में NAT REDIRECT नियम होता है।

फिर से केवल TCP। privoxy जैसी केवल-HTTP प्रॉक्सी मनमाने प्रोटोकॉल रिले नहीं कर सकती, और यह डिज़ाइन ऐप्स के लिए कोई डेटाग्राम समर्थन भी नहीं जोड़ता।

जहाँ सॉफ़्टवेयर समर्थन देता है वहाँ हर ऐप को सीधे प्रॉक्सी के बारे में बताना आम तौर पर बेहतर है। इसका ऑडिट करना आसान है, और यह ऐसी जगह विफल होता है जिसे आप वास्तव में देख सकते हैं।

हर विकल्प कहाँ विफल होता है

विकल्प A विफल होता है जब सर्वर के पास TCP श्रोता नहीं है, जब प्रॉक्सी CONNECT लक्ष्य से इनकार करती है, या जब बाहरी स्ट्रीम सुरंग की ज़रूरत से नीचे थ्रॉटल हो जाती है। पहले दो प्रॉक्सी लॉग में एक प्रविष्टि छोड़ते हैं; तीसरा एक ऐसा कनेक्शन छोड़ता है जो बनता है और फिर गलत लगता है। प्रोफ़ाइल संपादित करने से पहले वह लॉग पढ़ें, क्योंकि यह अनुमति की समस्या को क्षमता की समस्या से अलग करता है। पूर्ण CONNECT जाँच को सुरंग के अंदर ले जाता है।

विकल्प B उन सबके लिए विफल होता है जिन्हें डेटाग्राम चाहिए, उन प्रोटोकॉल के लिए जिन्हें प्रॉक्सी नहीं समझती, और चुपचाप उन होस्टों पर विफल होता है जहाँ रीडायरेक्ट नियम मौजूद है पर राउटिंग ट्रैफ़िक को उसके बगल से भेज देती है।

कोई भी विकल्प डिवाइस की आवश्यकता नहीं बदलता। पैकेटों को कर्नेल के राउट करने से पहले अब भी TUN या TAP नोड चाहिए, इसलिए प्रक्रिया को अब भी /dev/net/tun पर अनुमति चाहिए। रैपर यह बदलता है कि उस नोड के खुलने के बाद क्या होता है, यह नहीं कि आपको इसकी ज़रूरत है या नहीं।

साबित करें कि आपने कौन-सा रास्ता बनाया

ट्रे आइकन के बजाय सॉकेट देखें। VPN प्रक्रिया को प्रॉक्सी पते तक स्थापित कनेक्शन रखना चाहिए, और प्रॉक्सी ने वह लक्ष्य लॉग किया होना चाहिए जिस तक पहुँचने को कहा गया था:

ss -tnp | grep openvpn

फिर ऐसे गंतव्य की ओर जाएँ जिसे केवल सुरंग ही सेवा दे सकती है, और ऐसे नाम की ओर जिसका उत्तर केवल सुरंग का रिज़ॉल्वर ही दे सकता है। मृत सुरंग के साथ पूर्ण प्रॉक्सी कनेक्शन आम तौर पर मतलब है कि दूर का सिरा आपकी प्रोफ़ाइल में नामित ट्रांसपोर्ट कभी नहीं दे पाया।

ट्रांसपोर्ट और स्वीकार करने वाली प्रॉक्सी को टिकाऊ जगह पर नोट करें। जब वही प्रोफ़ाइल किसी दूसरे नेटवर्क पर विफल हो, तो वह नोट सेकंडों में प्रॉक्सी को बाहर या अंदर कर देता है।