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

फायरवॉल बदलू शकतो की TCP जोडणी कुठे पोहोचते. पण केवळ त्या बदलाने तो मूळ अनुप्रयोगाला SOCKS बोलायला शिकवू शकत नाही.

सामान्य SOCKS सर्व्हर विनंती केलेल्या गंतव्याचे वर्णन करणाऱ्या बोलणीची अपेक्षा करतो. प्रॉक्सीची माहिती नसलेला अनुप्रयोग त्याऐवजी लगेच स्वतःचे प्रोटोकॉल बाइट पाठवतो. ते बाइट थेट SOCKS श्रोत्याकडे वळवा आणि दोन्ही बाजू पहिल्या संदेशाबाबत एकमत होणार नाहीत.

गहाळ घटक म्हणजे अनुवादक

पारदर्शक TCP-ते-प्रॉक्सी घटक त्या इंटरफेसच्या मध्ये असतो. तो अनुप्रयोगाने मूळतः मागितलेले गंतव्य शोधतो, योग्य SOCKS किंवा HTTP CONNECT सत्र स्थापित करतो आणि नंतर तयार झालेल्या प्रवाहावर अनुप्रयोग डेटा पुढे पाठवतो.

त्याच्या Linux iptables मार्गावर, redsocks स्रोत जतन केलेले गंतव्य SO_ORIGINAL_DST वापरून मिळवतो. इतर ऑपरेटिंग सिस्टम आणि पुनर्निर्देशन पद्धती वेगळे यंत्रणा वापरतात. हा पुनर्निर्देशक आणि नेटवर्क सेटअपचा गुणधर्म आहे, सामान्य SOCKS क्लायंटचे वैशिष्ट्य नाही.

मूळ-गंतव्याची माहिती हे देखील स्पष्ट करते की पुनर्निर्देशन नियम प्रॉक्सी होस्टवरून असंबंधित गेटवेवर हलवणे नेहमी समतुल्य का नसते. प्राप्त करणाऱ्या प्रक्रियेला तिच्या अडवण्याच्या पद्धतीला आवश्यक असलेला मेटाडेटा हवा असतो. अन्यत्र पुन्हा लिहिलेला पत्ता ती माहिती अपेक्षित स्वरूपात आता देणार नाही.

अनुवादकाची व्याप्ती स्पष्ट ठेवा. कार्यरत पुनर्निर्देशित TCP जोडणी कोणत्याही UDP, ICMP किंवा प्रत्येक रिझॉल्व्हर मार्गासाठी आधार सिद्ध करत नाही. अपस्ट्रीम प्रॉक्सी प्रोटोकॉल आणि अनुवादकाची अंमलबजावणी अजूनही समर्थित क्रिया ठरवतात.

जोडणीनंतर लगेच सेटअप अयशस्वी झाल्यास, प्रवेश नियम रुंदावण्यापूर्वी प्रोटोकॉल सीमा तपासा. पूर्णपणे पोहोचण्याजोगा SOCKS श्रोता अशा बाइट नाकारू शकतो जे कधीही SOCKS विनंती नव्हते.