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 रहदारीत बदलत नाही, आणि खाजगी गंतव्यांना सहसा स्पष्ट वगळणी आवश्यक असते। यशस्वी स्थानिक चाचणी फक्त तो लूपबॅक मार्ग सिद्ध करते जो कधीही समस्या नव्हता।