Tor দিয়ে VPN: আগে ট্রান্সপোর্ট যাচাই

Tor-প্রথম মানে VPN ক্লায়েন্ট একটি SOCKS প্রক্সির পিছনে বসে, তাই টানেলটি Tor দিয়ে তৈরি হয় এবং অ্যাপ্লিকেশন ট্রাফিক VPN এন্ডপয়েন্ট থেকে বের হয়। এটি একটি নির্দিষ্ট ক্রম, আর বেশিরভাগ মানুষ যা তৈরি করেন তা এটি নয়। সাধারণ VPN ক্লায়েন্টের পাশে Tor Browser খোলা দুটি প্রোগ্রামের কোনোটিকেই অন্যটির পথ ব্যবহার করতে বাধ্য করে না।

যাচাইগুলো ক্রমানুসারে করুন। প্রতিটি ঠিক করে পরেরটি শুরু করা মূল্যবান কি না।

আপনি আসলে কোন ক্রম তৈরি করছেন

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

কিছু কনফিগার করার আগে লিখে রাখুন কাজটির কোন ক্রম দরকার, কারণ দুটির আলাদা সফটওয়্যার সেটিংস লাগে এবং আলাদা জায়গায় ব্যর্থ হয়। ভুল নাম দেওয়া ক্রম আপনাকে এক ঘণ্টা ভুল স্তরে সমস্যা খুঁজতে পাঠায়। নিচের সবকিছু Tor প্রথম ধরে নেয়।

অন্য কিছুর আগে ট্রান্সপোর্ট যাচাই করুন

Tor-এর SOCKS ইন্টারফেস TCP স্ট্রিম বহন করে এবং সাধারণ UDP অ্যাসোসিয়েশন দেয় না। যার ট্রান্সপোর্ট UDP এমন VPN সেই প্রক্সিকে সাধারণ নেটওয়ার্ক ইন্টারফেস হিসেবে ধরতে পারে না, আর কোনো ক্লায়েন্ট সেটিং প্রক্সি কী ফরওয়ার্ড করতে রাজি তা বদলায় না। স্বাভাবিক রূপে WireGuard স্পষ্টতই ক্ষতিগ্রস্ত। TCP মোডে OpenVPN প্রোফাইল সাধারণ সমাধান, এবং এটিকেও স্পষ্টভাবে প্রক্সি ব্যবহার করতে বলতে হয়।

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

এর মধ্য দিয়ে টানেল ডিবাগ করার আগে নিশ্চিত করুন প্রক্সি শুনছে এবং একটি সাধারণ HTTPS অনুরোধ বহন করতে পারে। সাধারণ অনুরোধ ব্যর্থ হলে VPN ক্লায়েন্ট কখনো সফল হবে না এবং তার লগ আপনাকে কারণ বলবে না।

পর্যবেক্ষকের মানচিত্র পুনর্লিখন করুন

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

এটি প্রতিটি গন্তব্যে বিতরণকৃত পথও পুনরায় তৈরি করে না। Tor Browser প্রতি সাইটে নতুন সার্কিট তৈরি করে; Tor দিয়ে বহন করা VPN একটি টানেল তৈরি করে এবং তার পিছনের প্রতিটি সাইট ওই এন্ডপয়েন্ট ভাগ করে। পার্থক্যটিকে দূর করার সীমাবদ্ধতা নয়, নকশার তথ্য হিসেবে ধরুন।

ভেঙে গেলে ব্যর্থতার স্তরগুলো গুনুন

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

প্রথম যে স্তরটি ব্যর্থ হয় তা লগ করুন এবং সেখানেই থামুন। প্রক্সি প্রত্যাখ্যান আর প্রত্যাখ্যাত কী একই ঘটনার রূপ নয়।

হুমকির মডেলের Tor Browser-এর প্রতিরক্ষা দরকার হলে থামুন

Tor দিয়ে বহন করা VPN-এর মধ্য দিয়ে যেকোনো অ্যাপ্লিকেশন রাউট করলে সেই অ্যাপগুলো Tor Browser-এর ফিঙ্গারপ্রিন্ট ও বিচ্ছিন্নকরণ বৈশিষ্ট্য পায় না। তাদের অ্যাকাউন্ট, শনাক্তকারী ও নিজস্ব নেটওয়ার্ক আচরণ প্রাসঙ্গিক থাকে, আর টানেল তার কিছুই স্বাভাবিক করে না। লক্ষ্য যদি অন্য ব্যবহারকারীদের সঙ্গে মিশে যাওয়া ব্রাউজার হয়, এই ক্রম তা দেয় না।

Tor Project নিজেই এমন সমন্বয়ের বিরুদ্ধে সতর্ক করে যা ব্যবহারকারীরা সঠিকভাবে কনফিগার করতে পারেন না, আর এটি বেশিরভাগ মানুষের ক্ষেত্রে প্রযোজ্য। এটি সংকীর্ণ হুমকি মডেলের জন্য ইচ্ছাকৃত নকশা, পুরো ডিভাইসের বেনামি ট্রাফিকের শর্টকাট নয়।