নীতি রাউটিং বনাম SOCKS: কোন স্তরটি আসলে ট্রাফিক প্রক্সি করে

আপনি একটি নীতি রুট যোগ করেছেন যা একটি VPN ক্লায়েন্টের ট্রাফিক পোর্ট 1080-এ SOCKS লিসেনার চালানো একটি হোস্টে পাঠায়। প্যাকেটগুলো পৌঁছায়, লিসেনার কিছুই লগ করে না, এবং সংযোগটি ঝুলে থাকে। রুটে কোনো সমস্যা নেই: পরবর্তী হপ নির্ধারণ করে একটি প্যাকেট কোথায় যায়, আর SOCKS হলো এমন একটি কথোপকথন যা ক্লায়েন্টকেই শুরু করতে হয়। মানুষ সাধারণত প্রক্সির মাধ্যমে ট্রাফিক পাঠাতে যে তিনটি আর্কিটেকচার বোঝায় সেগুলো তুলনা করুন, তাহলে স্পষ্ট হবে আপনার সেটআপে কোন অংশটি অনুপস্থিত।

রাউটিং, DNAT এবং SOCKS ভিন্ন ভিন্ন জিনিস বদলায়

একটি নীতি রুট লেয়ার-3 সিদ্ধান্ত পুনর্লিখন করে। একটি ক্লায়েন্টের ট্রাফিক বেছে নেওয়া পরবর্তী হপে পাঠাতে দুটি লাইনই যথেষ্ট:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

এর পরে কার্নেল প্যাকেটটি 10.50.0.2-এ হস্তান্তর করে, আর মূল গন্তব্যটি তখনও IP হেডারে থাকে। যদি 10.50.0.2 একটি রাউটার হয়, তবে এটি প্যাকেটটি ফরওয়ার্ড করে। যদি এটি 1080-এ SOCKS ডেমন চালানো একটি হোস্ট হয়, তবে প্যাকেটটি এমন কিছুর ঠিকানায় নেই যা এটি গ্রহণ করতে পারে, এবং পোর্ট 1080-এ DNAT-ও সাহায্য করে না, কারণ রূপান্তরিত প্যাকেটটি SOCKS অভিবাদনের বদলে মূল অ্যাপ্লিকেশন পেলোডই বহন করে।

SOCKS5 একটি ভার্সন বাইট, একটি মেথড তালিকা, একটি প্রমাণীকরণ বিনিময় এবং গন্তব্য নামকরণকারী একটি অনুরোধ দিয়ে শুরু হয়। ওটা অ্যাপ্লিকেশন ডেটা। কোনো রাউটিং এন্ট্রি বা netfilter টার্গেট এটি তৈরি করে না, আর এক লাইনে তুলনাটি এই: রাউটিং একটি পথ বেছে নেয়, SOCKS একটি সার্ভারকে দ্বিতীয় সংযোগ করতে বলে।

প্রথম ক্ষেত্র: অ্যাপ্লিকেশনটি নিজেই SOCKS বলতে পারে

যখন প্রোগ্রামের একটি প্রক্সি সেটিং থাকে, এটাই সবচেয়ে ছোট পথ এবং এতে কার্নেল পরিবর্তনের দরকার নেই। এটি লিসেনারের দিকে নির্দেশ করুন, সার্ভার চাইলে শংসাপত্র দিন, এবং নামগুলো স্থানীয়ভাবে রিজলভ হবে না প্রক্সিতে পাঠানো হবে তা ঠিক করুন। curl-এ এগুলো ভিন্ন ফ্ল্যাগ, এবং গন্তব্যটি কেবল প্রক্সির দিক থেকেই রিজলভ হলে পার্থক্যটি গুরুত্বপূর্ণ:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

যে অ্যাপ্লিকেশনগুলো প্রক্সি এনভায়রনমেন্ট ভেরিয়েবল উপেক্ষা করে, বা কাঁচা সকেট খোলে, তাদের এভাবে সাহায্য করা যায় না। ব্রাউজার আর বেশিরভাগ HTTP টুলিং ঠিক আছে; একটি গেম ক্লায়েন্ট, একটি মেইল ডেমন বা যেকোনো ভেন্ডর বাইনারি সাধারণত নয়। সীমাটি প্রতি অ্যাপ্লিকেশন ও প্রতি প্রোটোকলে, তাই এই বিকল্পটি পরীক্ষার জন্য চমৎকার আর পুরো VPN-এর উত্তর হিসেবে দুর্বল।

দ্বিতীয় ক্ষেত্র: একটি অ্যাডাপ্টার যা IP প্রবাহকে প্রক্সি সেশনে রূপান্তর করে

যে প্রোগ্রামগুলো SOCKS বলতে পারে না, তাদের জন্য রূপান্তরটি এমন কিছুতে ঘটতে হবে যা IP ট্রাফিক সমাপ্ত করে এবং তাদের পক্ষে প্রক্সি সেশন খোলে। সেই উপাদানটি একটি টানেল ইন্টারফেসের মালিক, নীতি রাউটিং যে প্রবাহগুলো বেছে নিয়েছে তা গ্রহণ করে, প্রতিটির জন্য SOCKS হ্যান্ডশেক সম্পন্ন করে এবং উত্তরগুলো পুনর্গঠন করে। রুটটি ট্রাফিককে সেখানে নির্দেশ করে; অ্যাডাপ্টারই সেশনটি তৈরি করে।

একটি সম্পূর্ণ সাবনেটের দায়িত্ব দিয়ে দেওয়ার আগে এর ডকুমেন্টেশন পড়ুন। অনেক অ্যাডাপ্টার TCP ভালোভাবে বহন করে এবং UDP সামলায় কেবল SOCKS5 UDP অ্যাসোসিয়েশনের মাধ্যমে, আর তাদের কেউই ICMP-কে প্রক্সি ট্রাফিকে রূপান্তর করে না, তাই সফল ping প্রক্সি পথ সম্পর্কে কিছুই বলে না। DNS হলো অন্য ফাঁদ: অ্যাডাপ্টার যদি নাম স্থানীয়ভাবে রিজলভ করে, তবে শুধু-অভ্যন্তরীণ রেকর্ডগুলো ভুল উত্তর বা একেবারে কিছুই না-তে রিজলভ হয়।

লুপ প্রতিরোধ হলো সেই পরিচালনাগত খুঁটিনাটি যা কামড় দেয়। SOCKS সার্ভারের সাথে অ্যাডাপ্টারের নিজের সংযোগগুলো আবার অ্যাডাপ্টারে রাউট করা যাবে না, তাই এর ট্রাফিকের জন্য নিয়মে একটি ব্যতিক্রম বা একটি নির্দিষ্ট সোর্স ঠিকানা দরকার। এখানে ভুল করলে প্রক্সি সেশনটি নিজেকেই প্রক্সি করতে চেষ্টা করবে।

তৃতীয় ক্ষেত্র: হোস্টটি আসলে একটি রাউটেড গেটওয়ে

কখনও কখনও কাজ করা সেটআপে কোনো SOCKS-ই থাকে না। দূরবর্তী হোস্টটি প্যাকেট ফরওয়ার্ড করে বা সেগুলোতে NAT করে, আর সোর্স-ভিত্তিক নিয়মটি কেবল এটিকে প্রস্থান হিসেবে বেছে নেয়। সেই নকশাটি বৈধ, এবং এটিই ব্যাখ্যা করে কেন একটি কপি করা কনফিগারেশন এক নেটওয়ার্কে কাজ করে আর অন্যটিতে ব্যর্থ হয়: নিয়মটি অভিন্ন, অনুপস্থিত অংশটি হলো ওপাশে একটি ফরওয়ার্ডিং সেবা।

তিনটি ক্ষেত্র দ্রুত আলাদা হয়। আসলে কী লিসেন করছে তা দেখুন, তারপর হোস্টে পৌঁছানো প্রথম বাইটগুলো দেখুন:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

একটি সত্যিকারের SOCKS ক্লায়েন্টের প্রথম পেলোড বাইট 0x05, অর্থাৎ অভিবাদনের ভার্সন। যদি ক্যাপচার তার বদলে মূল অ্যাপ্লিকেশন ডেটা দেখায়, তবে কোনো SOCKS ডেমন উত্তর দেবে না, কারণ দরকষাকষি কখনও শুরু হয়নি। যদি 1080-এ কিছুই লিসেন না করে, তবে হোস্টটি একটি গেটওয়ে, এবং প্রশ্নটি হয় এটি ফরওয়ার্ড করে কি না এবং ফেরার পথ আছে কি না।

চারটি প্রশ্নে স্তরটি বেছে নিন

প্রোগ্রামটির কি প্রক্সি সেটিং আছে? সেটি ব্যবহার করুন এবং সেখানেই থামুন। ট্রাফিকে কি UDP বা ICMP আছে যা টিকে থাকতে হবে? কেবল একটি রাউটেড বা NAT গেটওয়ে ICMP বহন করে, আর UDP-এর জন্য দরকার এমন একটি SOCKS5 অ্যাসোসিয়েশন যা দুই পক্ষই সমর্থন করে। মেশিনের প্রতিটি প্রসেস কি কভার করতে হবে, যেগুলো আপনি কনফিগার করতে পারেন না সেগুলোসহ? তাহলে দরকার একটি অ্যাডাপ্টার যা ইন্টারফেসের মালিক এবং প্রবাহ সমাপ্ত করে। আপনি কি এর রাউটিং, DNS এবং লুপ-প্রতিরোধ ব্যতিক্রমগুলোরও দায়িত্ব নিতে পারবেন? না পারলে, সাধারণ গেটওয়ের পরিচালনা খরচ কম হবে।

একটি পার্থক্য সোজা রাখা দরকার। একটি VPN ক্লায়েন্টের নিজস্ব socks-proxy অপশন বর্ণনা করে বাইরের টানেল সংযোগটি কীভাবে তার সার্ভারে পৌঁছায়, এবং ভেতরের ক্লায়েন্ট প্রবাহ রূপান্তরের বিষয়ে কিছুই বলে না। দুটোকে একই টিকিটে বারবার গুলিয়ে ফেলা হয়। কোনো রুটে হাত দেওয়ার আগে ঠিক করুন আপনার কোন সম্পর্কটি দরকার।