पारदर्शी TCP-देखि-SOCKS अग्रेषणमा मूल गन्तव्यहरू

फायरवालले TCP जडान कहाँ पुग्छ भन्ने परिवर्तन गर्न सक्छ। तर त्यो परिवर्तनले मात्र मूल अनुप्रयोगलाई SOCKS बोल्न सिकाउन सक्दैन।

साधारण SOCKS सर्भरले अनुरोध गरिएको गन्तव्य वर्णन गर्ने वार्ताको अपेक्षा गर्छ। प्रोक्सीको जानकारी नभएको अनुप्रयोगले बरु तुरुन्तै आफ्नै प्रोटोकल बाइटहरू पठाउँछ। ती बाइटहरू सिधै SOCKS श्रोतातर्फ घुमाउनुहोस् र दुवै पक्ष पहिलो सन्देशमा सहमत हुनेछैनन्।

हराएको अवयव अनुवादक हो

पारदर्शी TCP-देखि-प्रोक्सी अवयव ती इन्टरफेसहरूबीच बस्छ। यसले अनुप्रयोगले सुरुमा अनुरोध गरेको गन्तव्य पत्ता लगाउँछ, उपयुक्त SOCKS वा HTTP CONNECT सत्र स्थापना गर्छ, र त्यसपछि बनेको प्रवाहमा अनुप्रयोग डेटा रिले गर्छ।

यसको Linux iptables मार्गमा, redsocks स्रोतले संरक्षित गन्तव्य SO_ORIGINAL_DST प्रयोग गरी प्राप्त गर्छ। अन्य अपरेटिङ सिस्टम र पुनर्निर्देशन विधिहरूले फरक संयन्त्र प्रयोग गर्छन्। यो पुनर्निर्देशक र नेटवर्क सेटअपको गुण हो, साधारण SOCKS क्लाइन्टको विशेषता होइन।

मूल-गन्तव्यको जानकारीले पुनर्निर्देशन नियम प्रोक्सी होस्टबाट असम्बन्धित गेटवेमा सार्नु सधैं समान किन नहुने भन्ने पनि व्याख्या गर्छ। प्राप्त गर्ने प्रक्रियालाई यसको अवरोध विधिले माग गर्ने मेटाडाटा चाहिन्छ। अन्यत्र पुनर्लेखन गरिएको ठेगानाले त्यो जानकारी अपेक्षित रूपमा अब नदिन सक्छ।

अनुवादकको दायरा स्पष्ट राख्नुहोस्। काम गर्ने पुनर्निर्देशित TCP जडानले कुनै पनि UDP, ICMP वा हरेक रिजोल्भर मार्गको समर्थन प्रमाणित गर्दैन। अपस्ट्रिम प्रोक्सी प्रोटोकल र अनुवादकको कार्यान्वयनले अझै समर्थित कार्यहरू निर्धारण गर्छ।

जडानको ठीक पछि सेटअप असफल भएमा, पहुँच नियम फराकिलो बनाउनुअघि प्रोटोकल सीमा जाँच्नुहोस्। पूर्ण रूपमा पुग्न सकिने SOCKS श्रोताले पनि कहिल्यै SOCKS अनुरोध नभएका बाइटहरू अस्वीकार गर्न सक्छ।