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

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

वाहतूक आणि स्वीकारणारी प्रॉक्सी टिकाऊ जागी नोंदवा। तीच प्रोफाइल दुसऱ्या नेटवर्कवर अयशस्वी झाल्यास, ती नोंद काही सेकंदात प्रॉक्सी वगळते किंवा पुष्टी करते।