Tor-এর SOCKS পোর্টে UDP: কী পাঠানো যায় না

কোনো অ্যাপকে SOCKS পোর্টে নির্দেশ করা ব্রাউজারের জন্য কাজ করে আর গেমের জন্য ব্যর্থ হয়, এবং কারণটি কনফিগারেশন নয়। SOCKS5 কয়েকটি কমান্ড সংজ্ঞায়িত করে, আর একটি বাস্তবায়ন চাইলে তাদের কেবল কয়েকটিই সমর্থন করতে পারে; Tor-এর ইন্টারফেস স্ট্রিম সংযোগ ও নাম রেজলিউশন গ্রহণ করে, ইচ্ছাকৃত ডেটাগ্রাম ফরওয়ার্ডিং নয়। যে ক্লায়েন্ট UDP পাঠায় এবং প্রত্যাশা করে প্রক্সি তা রিলে করবে, সে এমন কমান্ড চায় যা সার্ভার বাস্তবায়ন করে না। নিচের রানবুকটি কয়েক মিনিটে সেটি যাচাই করে এবং তারপর এমন ট্রান্সপোর্ট বেছে নেয় যা সত্যিই কাজ করতে পারে।

অ্যাপটি আসলে কী পাঠায় তা যাচাই করুন

প্রোটোকলের নাম নয়, ট্রান্সপোর্ট শনাক্ত করে শুরু করুন। একটি ভয়েস ক্লায়েন্ট HTTPS-এ সাইন ইন করে তারপর UDP-তে মিডিয়া বহন করতে পারে; একটি গেম TCP-তে প্রমাণীকরণ করে UDP-তে খেলতে পারে; একটি ফাইল ট্রান্সফার নিয়ন্ত্রণের জন্য TCP আর আবিষ্কারের জন্য UDP ব্যবহার করতে পারে। প্রথম দুটি আচরণ লগইন সফল হওয়ার পরেও কল ব্যর্থ থাকা পর্যন্ত একই রকম দেখায়, তাই “সংযুক্ত হয়েছে” পুরো অ্যাপটি কাজ করছে এর প্রমাণ নয়। কিছু ক্লায়েন্ট নিজে থেকেই UDP থেকে TCP-তে ফিরে যায়, যা আংশিকভাবে কাজ করা সেশনকে বাধাপ্রাপ্ত ট্রান্সপোর্টের বদলে অস্থির নেটওয়ার্কের মতো দেখায়।

যে অংশটি ব্যর্থ হয় তার জন্য গন্তব্য পোর্ট ও ট্রান্সপোর্ট লিখে রাখুন। ওই এক লাইনই ঠিক করে প্রক্সি আদৌ সাহায্য করতে পারে কি না।

Tor-এর SOCKS ইন্টারফেস কী গ্রহণ করবে

Tor স্ট্রিম সংযোগের জন্য SOCKS5 CONNECT কমান্ড আর নাম সমাধানের জন্য এক্সটেনশন কমান্ড বাস্তবায়ন করে, তাই একটি ব্রাউজার কোনো পরিবর্তন ছাড়াই এর মধ্য দিয়ে কাজ করে। UDP ASSOCIATE, যে কমান্ডটি ক্লায়েন্টকে প্রক্সির কাছে ডেটাগ্রাম ফরওয়ার্ডিংয়ের জন্য দিতে দিত, Tor যা দেয় তার অংশ নয়। এক্সটেনশনগুলোর নথি প্রকল্পের SOCKS এক্সটেনশন স্পেসিফিকেশন-এ আছে, আর তা সংক্ষিপ্ত। ডেটাগ্রাম কমান্ডের অনুপস্থিতি ইচ্ছাকৃত: ইচ্ছাকৃত UDP রিলে করলে নেটওয়ার্ক এমন একটি ফরওয়ার্ডিং ভূমিকা পেত যার জন্য এটি কখনোই ডিজাইন করা হয়নি।

এটিই WireGuard-এর জন্যও উত্তর, যা ডিজাইন অনুযায়ী UDP এবং এর কোনো TCP ফলব্যাক নেই। এমন কোনো সমর্থিত পথ নেই যা WireGuard-কে SOCKS পোর্টে নির্দেশ দেয়, আর অন্যথা দাবি করে যা কিছু, তা দুই টুলের কোনোটির বৈশিষ্ট্য নয় বরং নিজস্ব বিশ্বাস ও রক্ষণাবেক্ষণের গল্পসহ একটি মোড়ক।

OpenVPN আংশিক ব্যতিক্রম, কারণ এটি TCP-এর উপর টানেল করতে কনফিগার করা যায় এবং এটি SOCKS প্রক্সি অপশন বোঝে। তবুও এর জন্য TCP-এর জন্য কনফিগার করা সার্ভার এবং পারফরম্যান্স ও ফিঙ্গারপ্রিন্টের পরিণতি নিয়ে সচেতন সিদ্ধান্ত দরকার, তাই এটি সমর্থনযোগ্যতার সমাধান নয়, একটি নকশা সিদ্ধান্ত।

ক্রম অনুযায়ী যাচাই চালান

প্রথমে নিশ্চিত করুন প্রক্সি স্ট্রিমের জন্য কাজ করে, যাতে পরের ব্যর্থতা অগম্য পোর্টের উপর চাপানো না যায়। তারপর অ্যাপের নিজের ট্রাফিক নিশ্চিত করুন এবং দেখুন এটি আসলে কোন সকেট খোলে।

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

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

ফিরিয়ে নিন এবং সঠিক টুল বাছুন

যে প্রক্সি এনভায়রনমেন্ট ভেরিয়েবল বা প্রতি-অ্যাপ্লিকেশন প্রক্সি সেটিং UDP ক্লায়েন্টকে SOCKS পোর্টে নির্দেশ দিয়েছিল, সেগুলো সরান; এগুলো রেখে দিলে পরের পরীক্ষাগুলো অস্পষ্ট হয়ে যায়। কপি থেকে আগের কনফিগারেশন পুনরুদ্ধার করুন, অ্যাপটি পুনরায় চালু করুন এবং নিশ্চিত করুন মূল আচরণ ফিরে এসেছে যাতে তুলনাটি পরিষ্কার হয়। যাচাই না করা রোলব্যাক কেবল এই আশা যে অবস্থা বদলেছে।

যে ট্রান্সপোর্টকে UDP থাকতেই হবে, তার জন্য VPN সাধারণত বেশি মানানসই: এটি অ্যাপকে প্রক্সি প্রোটোকল বলতে না দিয়েই অ্যাপের প্যাকেট বহন করে, তবে সম্পূর্ণ ভিন্ন বেনামিত্বের বৈশিষ্ট্য-এর বিনিময়ে। প্রতিটি টুল তার নথিভুক্ত কাজের জন্য ব্যবহার করুন, আর তাদের মধ্যে যেকোনো সেতুকে আলাদা সিস্টেম হিসেবে দেখুন যার নিজস্ব পর্যালোচনা দরকার। চূড়ান্ত প্রতিবেদনে লিখুন কোন স্তর কোন ট্রান্সপোর্ট বহন করে, যাতে পরের ব্যক্তি অন্য অ্যাপের সঙ্গে একই সীমা আবার আবিষ্কার না করে।