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 ट्राफिकमा बदल्दैन, र निजी गन्तव्यहरूलाई सामान्यतया स्पष्ट बहिष्कार चाहिन्छ। सफल स्थानीय परीक्षणले कहिल्यै समस्या नभएको लूपब्याक मार्ग मात्र प्रमाणित गर्छ।