স্বচ্ছ TCP-থেকে-SOCKS ফরওয়ার্ডিংয়ে মূল গন্তব্য

একটি ফায়ারওয়াল বদলাতে পারে TCP সংযোগ কোথায় পৌঁছাবে। কিন্তু কেবল সেই পরিবর্তন দিয়ে উৎস অ্যাপ্লিকেশনকে SOCKS বলতে শেখানো যায় না।

সাধারণ SOCKS সার্ভার অনুরোধকৃত গন্তব্য বর্ণনা করা একটি আলোচনার প্রত্যাশা করে। প্রক্সি সম্পর্কে অজ্ঞ অ্যাপ্লিকেশন বরং সঙ্গে সঙ্গে নিজের প্রোটোকল বাইট পাঠায়। সেই বাইটগুলি সোজা SOCKS শ্রোতার কাছে পাঠালে দুই পক্ষ প্রথম বার্তা নিয়ে একমত হবে না।

অনুপস্থিত উপাদানটি একটি অনুবাদক

একটি স্বচ্ছ TCP-থেকে-প্রক্সি উপাদান ওই ইন্টারফেসগুলির মাঝে থাকে। এটি অ্যাপ্লিকেশনটি প্রথমে যে গন্তব্য চেয়েছিল তা আবিষ্কার করে, উপযুক্ত SOCKS বা HTTP CONNECT সেশন স্থাপন করে, তারপর ফলিত স্ট্রিমে অ্যাপ্লিকেশন ডেটা রিলে করে।

এর Linux iptables পথে redsocks সোর্স সংরক্ষিত গন্তব্য SO_ORIGINAL_DST ব্যবহার করে উদ্ধার করে। অন্য অপারেটিং সিস্টেম ও রিডাইরেকশন পদ্ধতি ভিন্ন প্রক্রিয়া ব্যবহার করে। এটি রিডাইরেক্টর ও নেটওয়ার্ক সেটআপের বৈশিষ্ট্য, সাধারণ SOCKS ক্লায়েন্টের বৈশিষ্ট্য নয়।

মূল-গন্তব্যের তথ্য এটাও ব্যাখ্যা করে কেন প্রক্সি হোস্ট থেকে একটি রিডাইরেকশন নিয়ম অসম্পর্কিত গেটওয়েতে সরানো সবসময় সমতুল্য নয়। গ্রহণকারী প্রক্রিয়ার নিজের ইন্টারসেপশন মোডের প্রয়োজনীয় মেটাডেটা দরকার। অন্যত্র পুনর্লিখিত একটি ঠিকানা হয়তো সেই তথ্য প্রত্যাশিত আকারে আর দেয় না।

অনুবাদকের পরিধি স্পষ্ট রাখুন। কার্যকর রিডাইরেক্ট করা TCP সংযোগ যেকোনো UDP, ICMP বা প্রতিটি রিজলভার পথের সমর্থন প্রমাণ করে না। আপস্ট্রিম প্রক্সি প্রোটোকল ও অনুবাদকের বাস্তবায়নই সমর্থিত ক্রিয়াকলাপ নির্ধারণ করে।

সংযোগের ঠিক পরে কোনো সেটআপ ব্যর্থ হলে, অ্যাক্সেস নিয়ম প্রশস্ত করার আগে প্রোটোকল সীমানা পরীক্ষা করুন। পুরোপুরি পৌঁছানো যায় এমন SOCKS শ্রোতাও এমন বাইট প্রত্যাখ্যান করতে পারে যা কখনো SOCKS অনুরোধ ছিল না।