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

त्यसपछि सुरुङले मात्र सेवा दिन सक्ने गन्तव्यतिर, र सुरुङको रिजोल्भरले मात्र जवाफ दिन सक्ने नामतिर जानुहोस्। मृत सुरुङसँग पूरा भएको प्रोक्सी जडानले सामान्यतया दूरको छेउले तपाईंको प्रोफाइलमा नाम दिइएको ट्रान्सपोर्ट कहिल्यै प्रस्ताव नगरेको बुझाउँछ।

ट्रान्सपोर्ट र स्वीकार गर्ने प्रोक्सी टिकाउ ठाउँमा टिपोट गर्नुहोस्। त्यही प्रोफाइल अर्को नेटवर्कमा असफल हुँदा, त्यो टिपोटले सेकेन्डभरमा प्रोक्सीलाई हटाउँछ वा पुष्टि गर्छ।