पारदर्शी TCP-से-SOCKS अग्रेषण में मूल गंतव्य

एक फ़ायरवॉल बदल सकता है कि TCP कनेक्शन कहाँ पहुँचता है। पर केवल उस बदलाव से वह मूल अनुप्रयोग को SOCKS बोलना नहीं सिखा सकता।

सामान्य SOCKS सर्वर अनुरोध किए गए गंतव्य का वर्णन करने वाली बातचीत की अपेक्षा करता है। प्रॉक्सी से अनजान अनुप्रयोग इसके बजाय तुरंत अपने प्रोटोकॉल बाइट भेज देता है। उन बाइट को सीधे SOCKS श्रोता की ओर भेजिए और दोनों पक्ष पहले संदेश पर असहमत हो जाएँगे।

अनुपस्थित घटक एक अनुवादक है

एक पारदर्शी TCP-से-प्रॉक्सी घटक उन इंटरफ़ेस के बीच बैठता है। यह वह गंतव्य खोजता है जिसका अनुरोध अनुप्रयोग ने मूल रूप से किया था, उपयुक्त SOCKS या HTTP CONNECT सत्र स्थापित करता है, और फिर परिणामी स्ट्रीम पर अनुप्रयोग डेटा रिले करता है।

अपने Linux iptables पथ पर, redsocks स्रोत संरक्षित गंतव्य को SO_ORIGINAL_DST के माध्यम से प्राप्त करता है। अन्य ऑपरेटिंग सिस्टम और पुनर्निर्देशन विधियाँ भिन्न तंत्र अपनाती हैं। यह पुनर्निर्देशक और नेटवर्क सेटअप का गुण है, सामान्य SOCKS क्लाइंट की विशेषता नहीं।

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

अनुवादक का दायरा स्पष्ट रखें। काम करने वाला पुनर्निर्देशित TCP कनेक्शन मनमाने UDP, ICMP या हर रिज़ॉल्वर पथ के लिए समर्थन सिद्ध नहीं करता। अपस्ट्रीम प्रॉक्सी प्रोटोकॉल और अनुवादक का कार्यान्वयन अब भी समर्थित क्रियाएँ तय करते हैं।

जब कनेक्शन के तुरंत बाद कोई सेटअप विफल हो, तो पहुँच नियम विस्तारित करने से पहले प्रोटोकॉल सीमा जाँचें। पूरी तरह पहुँचने योग्य SOCKS श्रोता ऐसे बाइट अस्वीकार कर सकता है जो कभी SOCKS अनुरोध नहीं थे।