Redsocks लूपबैक पर सुनता है पर VPN ट्रैफ़िक कभी नहीं पहुँचता

एक टनल ऊपर आता है, क्लाइंट गेटवे को पिंग कर सकता है, और प्रॉक्सी पथ से जाने वाला हर वेब अनुरोध मर जाता है। redsocks प्रक्रिया चल रही है और उसका पोर्ट सुन रहा है, इसलिए गेटवे से ही सेवा स्वस्थ दिखती है। जो विफल होता है वह डिलीवरी चरण है: टनल से रीडायरेक्ट किया गया पैकेट उस सॉकेट पर नहीं उतरता जिसे आपने शुरू किया था। बाइंड पता और रीडायरेक्ट लक्ष्य को मेल खाना चाहिए, और सामान्यतः इनमें से केवल एक की जाँच होती है।

रीडायरेक्ट किया गया पैकेट वास्तव में कहाँ उतरता है

गेटवे पर पारदर्शी प्रॉक्सी PREROUTING में nat तालिका के REDIRECT का उपयोग करके आने वाले कनेक्शन के गंतव्य को स्थानीय पोर्ट पर फिर से लिखती है। फिर से लिखा गया गंतव्य वह स्थानीय पता है जैसा पैकेट जिस इंटरफ़ेस पर आया उसे दिखता है, न कि कहीं और शुरू हुई प्रक्रिया का लूपबैक पता। केवल 127.0.0.1 पर बंधा श्रोता उन कनेक्शनों को स्वीकार करता है जो पहले से होस्ट पर स्थानीय थे, और टनल ट्रैफ़िक विफल होने पर काम करता रहने वाला मामला ठीक यही है। क्लाइंट का अपना लूपबैक तीसरा पता है और कभी गेटवे के नियम का लक्ष्य नहीं होता।

इसलिए अपस्ट्रीम क्रेडेंशियल छूने से पहले दो तथ्य स्थापित करें: नियम किस स्थानीय पते पर फिर से लिखता है, और प्रॉक्सी सॉकेट किस पते पर बंधा है।

श्रोता और रीडायरेक्ट नियम को साथ पढ़ें

सॉकेट तालिका और nat नियम एक ही पास में छापें, क्योंकि जिस पोर्ट का कोई मालिक नहीं उसकी ओर इशारा करने वाला नियम गलत पते की ओर इशारा करने वाले नियम जैसा ही दिखता है। sudo ss -ltnp | grep redsocks बाइंड पता और मालिक प्रक्रिया दिखाता है। sudo iptables -t nat -S PREROUTING REDIRECT लक्ष्य दिखाता है, और sudo iptables -t nat -L PREROUTING -v -n दिखाता है कि कुछ उससे मेल खाया या नहीं।

REDSOCKS नाम की उपयोगकर्ता श्रृंखला में कूदना तब तक कुछ नहीं करता जब तक वह श्रृंखला मौजूद न हो और इच्छित अपवर्जन तथा REDIRECT क्रिया न ले जाए। नाम ही काम करता है मानने के बजाय sudo iptables -t nat -S REDSOCKS से जिस श्रृंखला में यह कूदता है उसे पढ़ें।

फिर दोनों मानों की तुलना करें। यदि नियम पोर्ट 12345 पर गेटवे पते पर रीडायरेक्ट करता है और श्रोता 127.0.0.1:12345 बताता है, तो बेमेल किसी अतिरिक्त निदान के बिना विफलता समझा देता है।

संकीर्ण रूप से बाँधें, फिर सीमित करें कि क्या उस तक पहुँच सकता है

अपस्ट्रीम नमूना कॉन्फ़िगरेशन अच्छे कारण से श्रोता को लूपबैक पर रखता है: पारदर्शी प्रॉक्सी उस हर व्यक्ति की ओर से कनेक्शन स्वीकार करती है जो उस तक पहुँच सकता है। बाइंड को 0.0.0.0 करना डिलीवरी ठीक करता है और साथ ही हर इंटरफ़ेस पर पोर्ट खोल देता है, जो सुरक्षा परिवर्तन है, तटस्थ मरम्मत नहीं। रीडायरेक्ट जिस विशिष्ट स्थानीय पते को लक्ष्य करता है उसी पर बाँधना पसंद करें, और अविश्वसनीय इंटरफ़ेस पर पोर्ट बंद रखें। यदि व्यापक बाइंड अपरिहार्य हो, तो होस्ट फ़ायरवॉल नियम जोड़ें जो केवल टनल स्रोत श्रेणी और गेटवे के अपने स्थानीय ट्रैफ़िक को अनुमति दे।

सार्वजनिक इंटरफ़ेस पर पोर्ट खोलना रीडायरेक्ट किए गए VPN ट्रैफ़िक के लिए कभी आवश्यक नहीं है, क्योंकि फिर से लिखे जाने के बाद कनेक्शन स्थानीय रूप से समाप्त होता है। स्थानीय रीडायरेक्ट काम करे इसके लिए प्रॉक्सी को इंटरनेट पर उजागर न करें।

क्लाइंट से नए कनेक्शन के साथ इसे सिद्ध करें

गेटवे के शेल से नहीं, वास्तविक VPN क्लाइंट से नए TCP कनेक्शन के साथ परीक्षण करें। क्लाइंट पर curl -sS -o /dev/null -w '%{http_code}\n' http://example.com रीडायरेक्ट किए गए पथ को शुरू से अंत तक चलाता है।

फिर पुष्टि करें कि अविश्वसनीय नेटवर्क से श्रोता तक सीधा कनेक्शन अब भी अस्वीकार होता है, और प्रॉक्सी का अपना अपस्ट्रीम कनेक्शन उसी नियम से फिर नहीं पकड़ा जाता। पुनरावर्ती पकड़ ऐसी प्रॉक्सी के रूप में दिखती है जो स्वयं से जुड़ती है और कभी अनुरोध पूरा नहीं करती। प्रॉक्सी का गंतव्य अपवर्जन समुच्चय में जोड़ें, या उसके बहिर्गामी पैकेट चिह्नित करें ताकि श्रृंखला उन्हें छोड़ दे।

अंत में याद रखें कि यह पथ क्या कवर नहीं करता। सामान्य redsocks TCP रीडायरेक्ट UDP, QUIC या DNS को SOCKS ट्रैफ़िक नहीं बनाता, और निजी गंतव्यों को सामान्यतः स्पष्ट अपवर्जन चाहिए। सफल स्थानीय परीक्षण केवल उस लूपबैक पथ को सिद्ध करता है जो कभी समस्या नहीं था।