VPS-এ কীভাবে একটি Tor relay সেটআপ করবেন

VPS-এ একটি Tor relay যা করে

একটি Tor relay হলো এমন একটি মেশিনে থাকা Tor daemon, যার একটি public IP address আছে এবং এটি অন্যদের জন্য encrypted traffic forward করে। Directory authorities এটিকে প্রকাশ করে এবং Tor clients এর মাধ্যমে circuit তৈরি করে। একটি guard বা middle relay শুধুমাত্র অন্য একটি relay-এর কাছেই traffic পাঠায়, তাই এটি কখনোই কোনো অপরিচিত ব্যক্তির হয়ে কোনো ওয়েবসাইটের সাথে connection খোলে না। এই একটি কারণেই এটি কোনো abuse mail পায় না এবং সাধারণ VPS-এর জন্য এটিই সবচেয়ে উপযুক্ত অবদান। একটি relay অন্যদের traffic বহন করে এবং নিজের কোনো কিছু প্রকাশ করে না। তাই আপনি যদি নেটওয়ার্কে নিজের সাইট হোস্ট করতে চান, প্যাকেট আদান-প্রদান করার পরিবর্তে, তবে nginx-এর পেছনে v3 onion service চালানো একই Tor daemon-এর জন্য একটি ভিন্ন কাজ। একটি relay চালানো আপনার নিজের ব্রাউজিংয়ের গোপনীয়তার জন্য কোনো কাজ করে না, যা একটি আলাদা সমস্যা এবং এর কার্যকারিতা অধিকাংশ মানুষের প্রত্যাশার চেয়ে কম: SearXNG নিজে হোস্ট করলে আসলে কী গোপন থাকে তা একটি ভালো পরিমাপ যে, একটি সার্ভিস নিজের VPS-এ সরিয়ে নিলে আপনি কতটুকু সুরক্ষা পাবেন।

এর কাজ খুবই সামান্য: একটি package, পনেরো লাইনের config, একটি firewall rule এবং একটি restart। এই গাইডের বাকি অংশটি হলো সেই জায়গা যেখানে ভুল হওয়ার সম্ভাবনা থাকে। Metered plan-এ bandwidth-এর হিসাব এবং কেন একটি সম্পূর্ণ সুস্থ নতুন relay এক সপ্তাহ পর্যন্ত অকেজো মনে হয়, তার কারণ এখানে ব্যাখ্যা করা হয়েছে।

Guard, middle, bridge অথবা exit: ইনস্টল করার আগেই নির্বাচন করুন

একটি daemon-ই এই চারটি ভূমিকার যেকোনো একটি পালন করতে পারে। আপনার কনফিগারেশন এবং directory authorities নির্ধারণ করবে আপনি কোন ভূমিকা পালন করবেন।

• Middle relay: এটি একটি guard থেকে ট্রাফিক গ্রহণ করে এবং অন্য একটি relay-তে পাঠিয়ে দেয়। এটি সরাসরি কোনো গন্তব্য সাইটের সাথে যোগাযোগ করে না। প্রতিটি নতুন relay এখান থেকেই যাত্রা শুরু করে।
• Guard relay: একই কনফিগারেশন, তবে অতিরিক্ত একটি ফ্ল্যাগ যুক্ত থাকে। Directory authorities সেইসব relay-কে Guard ফ্ল্যাগ দেয় যারা দীর্ঘ সময় ধরে দ্রুত এবং স্থিতিশীল থাকে। আপনি এটি নিজে নির্বাচন করতে পারেন না। এটি অর্জন করতে হয় এবং নিচের কনফিগারেশনটিই তা অর্জনে সহায়তা করে।
• Bridge: এমন একটি relay যা ইচ্ছাকৃতভাবে পাবলিক ডিরেক্টরি থেকে দূরে রাখা হয় এবং যেসব স্থানে Tor ব্লক করা আছে, সেখানে ব্যবহারকারীদের ব্যক্তিগতভাবে দেওয়া হয়। এই চারটির মধ্যে এটি সবচেয়ে কম দায়বদ্ধতার কাজ: কম ব্যান্ডউইথ, কোনো পাবলিক লিস্টিং নেই এবং আপনার পরিকল্পনা যদি ছোট হয় তবে এটিই প্রথম সঠিক পদক্ষেপ। এর জন্য daemon-এর পাশাপাশি একটি obfs4 প্রক্সি চালানো প্রয়োজন এবং ভিন্ন কিছু torrc লাইন ব্যবহার করতে হয়, যা একটি সস্তা VPS-এ obfs4 bridge সেটআপ করা নির্দেশিকায় বিস্তারিত আলোচনা করা হয়েছে, যেখানে শেষে ব্যবহারকারীদের কীভাবে bridge লাইন দেওয়া হয় তাও দেখানো হয়েছে।
• Exit relay: এটি শেষ ধাপ, যা গন্তব্য সাইটের সাথে সংযোগ স্থাপন করে। ব্যবহারকারীর প্রতিটি অনুরোধ আপনার IP address থেকে যায়, তাই অপব্যবহারের রিপোর্ট এবং পুলিশের অনুসন্ধান সেই ঠিকানার মালিকের কাছেই পৌঁছায়।

Exit হলো একমাত্র ভূমিকা যা সাধারণ কোনো VPS-এর জন্য উপযুক্ত নয়। শুধুমাত্র এমন প্রোভাইডারের কাছেই exit চালান যারা আগে থেকেই এই ধরনের ট্রাফিক গ্রহণ করতে সম্মত হয়েছে, যার নিজস্ব IP address আছে এবং একটি প্রকাশিত abuse contact রয়েছে। বেশিরভাগ সাধারণ হোস্টিংয়ের শর্তাবলীতে এটি নিষিদ্ধ এবং এটি উপেক্ষা করার সাধারণ ফলাফল হলো সার্ভার সাসপেন্ড হওয়া এবং IP address হারিয়ে ফেলা। যদি আপনি তবুও এই কাজটিই করতে চান, তবে একটি exit relay চালানোর প্রকৃত প্রক্রিয়া নির্দেশিকায় exit-friendly হোস্ট খুঁজে বের করা, exit policy ও reverse DNS লেখা এবং মেইল আসার পর তার উত্তর দেওয়ার নিয়মগুলো কভার করা হয়েছে। একটি guard বা middle relay একই ব্যবহারকারীর ট্রাফিক বহন করে, কিন্তু এতে এই ধরনের কোনো ঝুঁকি থাকে না।

নিচের সবকিছু একটি guard/middle relay তৈরির জন্য। ExitRelay 0 হলো সেই লাইন যা এটিকে এই ভূমিকায় সীমাবদ্ধ রাখে।

শুরু করার আগে VPS-এর যা প্রয়োজন

The Tor Project relay-এর জন্য কঠোর প্রয়োজনীয়তা প্রকাশ করে। October 2026 অনুযায়ী সেগুলো হলো: relay-এর জন্য একটি public IPv4 address, উভয় দিকেই অন্তত 10 Mbit/s bandwidth, যেখানে 16 Mbit/s সুপারিশ করা হয়, প্রতি মাসে অন্তত 100 GB outbound traffic, এবং 40 Mbit/s-এর নিচে 512 MB RAM অথবা তার বেশি গতির জন্য 1 GB RAM। নির্দিষ্ট কোনো uptime rule নেই। তবে দিনে দুই ঘণ্টার কম চলা relay network-এর জন্য খুব কম উপযোগী।

10 Mbit/s মানটি line-এর ক্ষমতা বোঝায়, configuration-এর setting নয়। এই গতি দিতে পারে এমন একটি port আপনার প্রয়োজন। relay-কে সেই line-এর কতটা ব্যবহার করতে দেবেন, তা monthly transfer allowance-এর ভিত্তিতে আলাদাভাবে নির্ধারণ করতে হবে। configuration পরিবর্তনের আগে আপনার plan-এর শর্ত পড়ুন। আপনি যদি এখনও একটি box বেছে নিচ্ছেন, VPS-এর মাসিক প্রকৃত খরচ অংশে transfer allowance কীভাবে বিক্রি করা হয় তা ব্যাখ্যা করা হয়েছে, এবং VPS-এর প্রকৃত network throughput মাপা অংশে sales page-এর তথ্যের ওপর নির্ভর না করে iperf3 দিয়ে line-এর প্রকৃত ক্ষমতা কীভাবে যাচাই করবেন তা দেখানো হয়েছে।

প্রথমে machine-টি harden করুন। relay একটি public address-এ চলা public service, এবং address প্রকাশের কয়েক মিনিটের মধ্যেই scan করা হয়। SSH-কে key-এ সীমাবদ্ধ করা এবং sshd configuration harden করা কাজটি দশ মিনিটে করা যায়। এটি relay চালু করার আগেই করা উচিত, পরে নয়।

Tor Project repository থেকে tor ইনস্টল করুন

Distribution package-এর পরিবর্তে Tor Project-এর নিজস্ব apt repository ব্যবহার করুন। Relay code stable release-এর চেয়ে দ্রুত এগোয়। তাই fixes এই repository-তে আগে পৌঁছায়। Release-এর মধ্যবর্তী সময়ে distribution package পিছিয়ে থাকে।

sudo apt update
sudo apt install -y apt-transport-https gnupg wget

Signing key যোগ করুন, তারপর repository যোগ করুন। Codename মেশিন থেকেই পড়া হয়। তাই একই block Ubuntu 24.04 (noble) এবং Debian 13 (trixie)—উভয় ক্ষেত্রেই কাজ করে।

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
echo "$CODENAME"

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $CODENAME
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF

sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
tor --version

tor --version এইমাত্র ইনস্টল করা version দেখায়। apt update যদি এর পরিবর্তে NO_PUBKEY error দেখায়, তাহলে dearmored key Signed-By: line-এ উল্লেখ করা path-এ নেই। ফলে release file যাচাই করার জন্য apt-এর কোনো key থাকে না। পরে deb.torproject.org-keyring package গুরুত্বপূর্ণ হবে। এটি signing key-কে সাধারণ package হিসেবে সরবরাহ করে। তাই key rotate হলেও apt কাজ করতে থাকে।

Automatic upgrades চালু করুন। এরপর নতুন origin সম্পর্কে সেগুলোকে জানান।

sudo apt install -y unattended-upgrades apt-listchanges

Ubuntu-তে /etc/apt/apt.conf.d/50unattended-upgrades-এর Allowed-Origins block-এ Tor origin যোগ করুন:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "TorProject:${distro_codename}";
};

Debian-এ একই file Origins-Pattern ব্যবহার করে। সেখানে যোগ করার line হলো "origin=TorProject";। sudo unattended-upgrade --debug --dry-run দিয়ে ফলাফল পরীক্ষা করুন। এটি যে origin-গুলোর ওপর কাজ করবে সেগুলো দেখায় এবং কোনো output লেখে না।

যে torrc সেটিংগুলো গুরুত্বপূর্ণ

প্যাকেজটি অনেক মন্তব্যসহ একটি দীর্ঘ /etc/tor/torrc ইনস্টল করে। একটি relay-এর জন্য মাত্র কয়েকটি লাইন গুরুত্বপূর্ণ। সেগুলো ফাইলের শেষে যোগ করুন।

Nickname mynicerelay
ContactInfo relay-ops[at]example.com
ORPort 9001
ExitRelay 0
SocksPort 0

Nickname-এ 1 থেকে 19টি অক্ষর থাকতে পারে এবং এতে শুধু অক্ষর ও সংখ্যা ব্যবহার করা যায়। এটি network জুড়ে unique নয় এবং এটি আপনার পরিচয়ও নয়; আপনার পরিচয় হলো fingerprint। Search box-এ নিজের relay খুঁজতে এই নাম ব্যবহার করবেন। তাই এমন নাম বেছে নিন, যা ফোনে সহজে বানান করে বলা যায়।

ContactInfo relay descriptor-এর মধ্যে প্রকাশিত হয়। এটি একটি public document, যা যে কেউ download করতে পারে। তাই ঠিকানাটি বিভিন্ন জায়গা থেকে সংগ্রহ করা হবে। এমন ঠিকানা ব্যবহার করুন, যা দুই বছর পরও আপনি পড়বেন। চাইলে ঠিকানাটি obfuscate করতে পারেন। আপনার relay নিয়ে কোনো সমস্যা হলে Tor Project আপনাকে সতর্ক করার জন্য এটিই একমাত্র channel।

ORPort 9001 হলো সেই port, যেখানে অন্য relay এবং client সংযোগ করে। 9001 প্রচলিত port। আরেকটি সাধারণ পছন্দ হলো port 443, কারণ কিছু restrictive network শুধু outbound 443 অনুমোদন করে। তাই সেখানে listening করা relay আরও বেশি client-এর কাছে reachable হয়। Box-এ অন্য কোনো service-এর port 443 প্রয়োজন না হলেই শুধু 443 বেছে নিন।

SocksPort 0 local SOCKS proxy বন্ধ করে। Relay এটি ব্যবহার করে না। ফলে machine-এ একটি listening socket কমে যায়। ExitRelay 0 ফাইলে এই উদ্দেশ্যটি স্পষ্টভাবে লিখে রাখে: এই relay কখনো কোনো user-এর হয়ে destination-এ সংযোগ করবে না। পরে কেউ configuration পড়লে default দেখে এটি অনুমান করতে হবে না।

VPS-এ IPv6 address থাকলে tor সেটি ব্যবহার করার চেষ্টা করে। tor 0.4.5 থেকে address ছাড়া একটি ORPort line থাকলে IPv4 এবং IPv6—উভয় address-এই listening করা হয়। Relay যেভাবে IPv4 address খুঁজে পায়, একইভাবে নিজের IPv6 address-ও খুঁজে পায়। Discovery ভুল address বেছে নিলে তবেই address-টি square bracket-এর মধ্যে লিখে দ্বিতীয় ORPort line যোগ করুন। যে address reachable বলে নিশ্চিত, শুধু তার ক্ষেত্রেই এটি করুন। Reachability test-এ explicit IPv6 ORPort ব্যর্থ হলে relay তার descriptor publish করা বন্ধ করে।

ORPort 9001
ORPort [2001:db8::1]:9001

1 GB VPS-এ MaxMemInQueues 512 MB যোগ করুন। Machine-এ যত memory দেখতে পায়, Tor তার ভিত্তিতে queue limit নির্ধারণ করে। ছোট shared box-এ এই limit আপনার কাঙ্ক্ষিত ব্যবহারের চেয়ে বেশি হতে পারে। নিজে limit নির্ধারণ করলে চাপের সময় tor queued cell discard করে। এতে relay সচল থাকে। অন্যথায় queue বাড়তে বাড়তে kernel process-টি kill করতে পারে।

ফায়ারওয়ালে ORPort উন্মুক্ত করুন

ইনবাউন্ড ট্রাফিকের ক্ষেত্রে, ORPort অবশ্যই ইন্টারনেট থেকে যেকোনো স্থান থেকে অ্যাক্সেসযোগ্য হতে হবে। আউটবাউন্ড ট্রাফিকের ক্ষেত্রে, রিলেটিকে কোনো বিধিনিষেধের আওতায় রাখবেন না: এটি হাজার হাজার অন্যান্য রিলের সাথে বিভিন্ন পোর্টে সংযোগ স্থাপন করে, তাই আউটবাউন্ডের জন্য কোনো allowlist তৈরি করলে তা রিলেটির কার্যকারিতা নষ্ট করে দেবে।

sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verbose

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

আপনার প্ল্যান অনুযায়ী ব্যান্ডউইথ নির্ধারণ করুন

ম্যানুয়ালটিতে RelayBandwidthRate-কে একটি আলাদা টোকেন বাকেট হিসেবে বর্ণনা করা হয়েছে, যা "এই নোডে রিলে করা ট্রাফিকের গড় ইনকামিং ব্যান্ডউইথ ব্যবহারকে নির্দিষ্ট সংখ্যক বাইট প্রতি সেকেন্ডে সীমাবদ্ধ করে এবং আউটগোয়িং ব্যান্ডউইথ ব্যবহারকেও একই মানে সীমাবদ্ধ রাখে"। এটি দুবার পড়ুন। এই সীমা প্রতিটি দিকের জন্য আলাদাভাবে প্রযোজ্য। 1 Mbit/s-এ সেট করা একটি রিলে একই সময়ে 1 Mbit/s ইনকামিং এবং 1 Mbit/s আউটগোয়িং ট্রাফিক সরাতে পারে এবং যে প্রোভাইডার উভয় দিকই পরিমাপ করে, তারা এই দুটির যোগফল বিল করে।

[
  {
    "label": "1 Mbit/s",
    "torrc_rate": "125 KBytes",
    "gb_per_day": 21.6,
    "gb_per_month": "648"
  },
  {
    "label": "2 Mbit/s",
    "torrc_rate": "250 KBytes",
    "gb_per_day": 43.2,
    "gb_per_month": "1,296"
  },
  {
    "label": "5 Mbit/s",
    "torrc_rate": "625 KBytes",
    "gb_per_day": 108,
    "gb_per_month": "3,240"
  },
  {
    "label": "10 Mbit/s",
    "torrc_rate": "1250 KBytes",
    "gb_per_day": 216,
    "gb_per_month": "6,480"
  },
  {
    "label": "20 Mbit/s",
    "torrc_rate": "2500 KBytes",
    "gb_per_day": 432,
    "gb_per_month": "12,960"
  }
]

এই 5 সারিগুলো গাণিতিক হিসাব, পরিমাপ নয়: এগুলো দেখায় যে একটি রিলে যদি টানা 30 দিন উভয় দিকেই এই হার বজায় রাখে, তবে তার খরচ কত হবে। একটি বাস্তব রিলে বেশিরভাগ সময়ই তার সীমার নিচে থাকে, বিশেষ করে প্রথম কয়েক সপ্তাহে। টেবিলটি ব্যবহার করুন এমন সেটিংস বাদ দেওয়ার জন্য যা আপনার প্ল্যানের সাথে খাপ খায় না, গিগাবাইট হিসেবে ইনভয়েসের পূর্বাভাস দেওয়ার জন্য নয়।

প্রতি দিকে 1 Mbit/s হারে একটি রিলে প্রতিদিন প্রায় 21.6 GB ট্রাফিক সরায়, তাই 30 দিনের এক মাসে প্রায় 648 GB পরিমাপকৃত ট্রাফিক খরচ হয়। এটি 1 TB-এর সীমার মধ্যে থাকে এবং আপডেট ও ব্যাকআপের জন্য বাড়তি জায়গা থাকে। 2 Mbit/s-এ উন্নীত করলে মাসে 1,296 GB খরচ হয়, যা 1 TB প্ল্যানের সীমা অতিক্রম করে। শেষ সারিটি, 20 Mbit/s, মাসে 12,960 GB প্রয়োজন এবং এটি একটি আনমিটারড পোর্টে থাকা উচিত। যদি আপনার প্রোভাইডার শুধুমাত্র আউটবাউন্ড ট্রাফিকের জন্য বিল করে, তবে প্রতিটি সংখ্যা অর্ধেক করে নিন। রেট সেট করার আগে জেনে নিন আপনার প্রোভাইডার কীভাবে বিল করে, কারণ এই দুই উত্তরের মধ্যে দুই গুণের পার্থক্য থাকে।

এখন কনফিগারেশনের পালা। প্রথমে রেট লিমিট, তারপর কোটা।

RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00

RelayBandwidthBurst হলো টোকেন বাকেটের আকার, তাই এটি গড় হার ঠিক রেখে স্বল্প সময়ের জন্য রেটের চেয়ে বেশি স্পাইক বা ট্রাফিকের অনুমতি দেয়। রেটের প্রায় দ্বিগুণ মান একটি যুক্তিসঙ্গত পছন্দ।

AccountingRule হলো সেই লাইন যা বেশিরভাগ অপারেটর উপেক্ষা করেন। ডিফল্ট মান হলো max, যা কোটার বিপরীতে দুটি দিকের মধ্যে যেটি বড় সেটিকে পরিমাপ করে। ডিফল্ট সেটিংসে, AccountingMax 400 GBytes 400 GB ইনকামিং এবং 400 GB আউটগোয়িং-এর অনুমতি দেয়, যা উভয় দিক পরিমাপকারী মিটারে 800 GB হিসেবে গণ্য হয়। AccountingRule sum রিড এবং রাইট উভয়কেই একটি কোটার বিপরীতে গণনা করে, যা মূলত একটি ট্রান্সফার অ্যালাউন্স পরিমাপ করে।

AccountingStart-ও লিখুন, কখনোই শুধু AccountingMax লিখবেন না। কোটা হলো সংখ্যাটি, আর স্টার্ট লাইন হলো সেই সময়কাল যখন এটি রিসেট হয়। সময়কাল ছাড়া কোটা থাকলে রিলেটি হাইবারনেশনে চলে যাবে এবং পুনরায় চালু হওয়ার কোনো উপায় থাকবে না।

হাইবারনেশন একটি কঠোর ব্যবস্থা। যখন কোটা শেষ হয়ে যায়, tor এটি লগ করে এবং নতুন কাজ নেওয়া বন্ধ করে দেয়:

Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted

রিলেটি পরবর্তী সময়কালের ঠিক শুরুতে জেগে ওঠে না। Tor ট্র্যাক করে যে গত কোটা কত দ্রুত শেষ হয়েছে এবং নতুন ইন্টারভালের মধ্যে একটি র‍্যান্ডম পয়েন্ট বেছে নেয়, যাতে হাজার হাজার রিলে একই সেকেন্ডে নেটওয়ার্কে ফিরে না আসে। যে রিলে প্রতি মাসের শেষ সপ্তাহে অদৃশ্য হয়ে যায়, সেটি ডিরেক্টরি অথরিটিগুলোর পরিমাপ করা স্ট্যাবিলিটি স্কোর হারাতে থাকে। RelayBandwidthRate এমনভাবে নির্ধারণ করুন যাতে সীমা কখনোই পূর্ণ না হয় এবং AccountingMax-কে ব্যাকস্টপ হিসেবে রাখুন যা আপনার ইনভয়েসকে সুরক্ষিত রাখবে।

রিলে চালু করুন এবং নিশ্চিত করুন যে এটি অ্যাক্সেসযোগ্য

sudo systemctl restart tor@default
sudo systemctl status tor@default
sudo journalctl -u tor@default -n 50

কয়েক মিনিটের মধ্যে লগে এই লাইনটি দেখা উচিত:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

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

Your server has not managed to confirm reachability for its ORPort(s) at 203.0.113.10:9001. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

পর্যায়ক্রমে সমস্যাটি সমাধান করুন। ufw-তে ORPort খোলা আছে কি না তা দেখুন। এটি প্রোভাইডারের আলাদা নেটওয়ার্ক ফায়ারওয়ালেও খোলা আছে কি না তা যাচাই করুন। ওই বার্তায় থাকা ঠিকানাটি কি ইন্টারনেটে আপনার রাউটেবল ঠিকানা, নাকি NAT সেটআপ থেকে আসা কোনো প্রাইভেট ঠিকানা? nc -vz 203.0.113.10 9001 ব্যবহার করে অন্য একটি মেশিন থেকে পোর্টটি পরীক্ষা করুন। Tor নিজে থেকেই সেলফ-টেস্ট পুনরাবৃত্তি করে, তাই ফায়ারওয়াল ঠিক করলে তা স্বয়ংক্রিয়ভাবে শনাক্ত হয়, তবে রিস্টার্ট করলে তা তাৎক্ষণিকভাবে কার্যকর হয়।

আপনার রিলের স্থায়ী পরিচয় হলো এর ফিঙ্গারপ্রিন্ট:

sudo cat /var/lib/tor/fingerprint

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

একটি নতুন Tor relay-তে কেন প্রায় কোনো traffic থাকে না?

কারণ নেটওয়ার্ক এখনও এটিকে পরিমাপ করেনি, আর পরিমাপের এই প্রক্রিয়ায় কয়েক সপ্তাহ সময় লাগে। Tor Project এই ramp-up প্রক্রিয়াটিকে চারটি ধাপে বর্ণনা করেছে, কিন্তু যে অপারেটর এটি পড়েননি, তিনি মনে করেন relay-টি নষ্ট হয়ে গেছে এবং সেটিংস পরিবর্তন করতে শুরু করেন।

প্রথম তিন দিন relay-টি unmeasured বা পরিমাপহীন থাকে। এটি নিজের self-test ফলাফল রিপোর্ট করে, কিন্তু directory authorities এর প্রকাশিত weight 20 KB-তে সীমাবদ্ধ রাখে, তাই ক্লায়েন্টরা প্রায় কখনোই এটিকে নির্বাচন করে না। তৃতীয় দিন থেকে অষ্টম দিন পর্যন্ত bandwidth authorities এটিকে বাস্তবে পরিমাপ করে এবং এর weight বাড়তে থাকে, কিন্তু এটি শুধুমাত্র middle hop হিসেবে ব্যবহৃত হয়, কারণ কোনো ক্লায়েন্টই একটি নতুন relay-কে তাদের প্রথম hop হিসেবে ব্যবহার করতে চায় না।

অষ্টম দিনের দিকে relay-টি Guard flag পাওয়ার যোগ্য হয়ে ওঠে। এই flag পাওয়ার পর traffic কমে যায়, যা সবাইকে অবাক করে: ক্লায়েন্টরা middle hop নির্বাচনের সময় guard-দের এড়িয়ে চলে, এই ভেবে যে একটি guard ইতিমধ্যেই ব্যস্ত, তাই relay-টি guard traffic পাওয়ার আগেই middle traffic হারিয়ে ফেলে। ক্লায়েন্টরা তাদের guard সেট পরিবর্তন করার সাথে সাথে এটি আবার পূর্ণ হতে থাকে, যার জন্য কয়েক সপ্তাহ সময় লাগে। প্রায় 68 দিনের মাথায় এটি একটি স্থিতিশীল অবস্থায় পৌঁছায়, যেখানে ক্লায়েন্টদের বাদ দেওয়ার হার এবং যুক্ত হওয়ার হার সমান হয়ে যায়।

তাই বাস্তবসম্মত প্রত্যাশা হলো: তিন দিন কিছুই হবে না, এক সপ্তাহ পর কিছুটা traffic আসবে, এবং দুই মাস পর পূর্ণ লোড পাওয়া যাবে। একটি সেটিং পরিবর্তন করুন এবং সেটি কী প্রভাব ফেলল তা দেখার জন্য এক সপ্তাহ অপেক্ষা করুন। পোর্ট 9001-এর বিপরীতে TCP check সহ একটি self-hosted Uptime Kuma status page ব্যবহার করা আপনার অস্থিরতা কমানোর জন্য ভালো উপায়: এটি সেই প্রশ্নের উত্তর দেয় যা আপনি নিয়ন্ত্রণ করতে পারেন, অর্থাৎ পোর্টটি এখনও সাড়া দিচ্ছে কি না।

nyx দিয়ে relay পর্যবেক্ষণ করুন

nyx চালু থাকা relay-এর জন্য terminal monitor। এটি tor-এর control port-এর সঙ্গে যোগাযোগ করে। তাই প্রথমে torrc-এ এটি সক্রিয় করুন:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort শুধু 127.0.0.1-এ listen করে। Cookie authentication ব্যবহৃত হলে কোনো program command পাঠানোর আগে একটি secret file পড়তে হয়। Debian এবং Ubuntu-তে শেষের দুটি লাইন ইতিমধ্যেই package default হিসেবে থাকে: tor package-এর নিজস্ব /usr/share/tor/tor-service-defaults-torrc CookieAuthentication 1, CookieAuthFileGroupReadable 1 এবং CookieAuthFile /run/tor/control.authcookie সেট করে। তাই tor /run/tor/control.authcookie-এ debian-tor user হিসেবে cookie লেখে, এবং শুরু থেকেই debian-tor group-এর জন্য তা readable থাকে। torrc-এ এই দুটি লাইন লিখলে শুধু পরে configuration পড়া ব্যক্তির কাছে সেটি দৃশ্যমান হয়। ওই group-এর membership থাকলেই আপনার account sudo ছাড়া nyx চালাতে পারে।

sudo apt install -y nyx
sudo adduser "$USER" debian-tor
sudo systemctl restart tor@default

Log out করে আবার log in করুন। এরপর nyx চালান। নতুন group-টি login-এর সময় কার্যকর হয়। তাই একই shell session-এ nyx চালালে configuration সঠিক হলেও cookie file-এ permission error দেখা যাবে। nyx live bandwidth, uptime, log stream এবং connection list দেখায়। প্রথম কয়েক সপ্তাহে যে বিষয়টি পর্যবেক্ষণ করবেন, তা হলো bandwidth graph আপনার RelayBandwidthRate-এর নিচে থাকছে কি না।

একাধিক relay চালানো: MyFamily এবং family key

একটি relay থাকলে এই section এড়িয়ে যান। একই operator-এর পরিচালিত দুই বা তার বেশি relay-কে একে অপরকে ঘোষণা করতে হবে। এর ফলে client কখনও এমন circuit তৈরি করবে না, যা আপনার একটি machine দিয়ে প্রবেশ করে এবং আপনার অন্য machine দিয়ে বের হয়। তা হলে একজন operator circuit-এর দুই প্রান্তই দেখতে পারত।

দীর্ঘদিন ধরে প্রচলিত পদ্ধতিতে প্রতিটি relay-এর torrc-এ MyFamily ব্যবহার করা হয়। সেখানে অন্য সব relay-এর fingerprint তালিকাভুক্ত থাকে:

MyFamily AAAAAAAAAA,BBBBBBBB

প্রতিটি relay-এ অন্য প্রতিটি relay-এর তালিকা দিতে হয়। তাই চতুর্থ relay যোগ করতে চারটি file সম্পাদনা করতে হয়। Tor 0.4.9 এমন একটি family key যোগ করেছে, যা ওই তালিকার পাশাপাশি কাজ করে; এটি তালিকার বিকল্প নয়। Tor manual-এ এই key-কে family ঘোষণার ভবিষ্যৎ পছন্দনীয় পদ্ধতি বলা হয়েছে। তবে সেখানে বলা আছে, আপাতত relay family-কে key এবং MyFamily দুটিই configure করা উচিত। আপনার সব relay 0.4.9.2-alpha বা পরের version চালালে একটি key generate করুন এবং তা share করুন:

tor --keygen-family myfamily

এটি myfamily.secret_family_key লিখবে এবং একটি FamilyId line দেখাবে। key file-টি প্রতিটি relay-এ DataDirectory-এর keys subdirectory-তে copy করুন। Debian এবং Ubuntu-তে এটি /var/lib/tor/keys। .secret_family_key suffix অপরিবর্তিত রাখুন। প্রদর্শিত FamilyId line-টি প্রতিটি torrc-এ যোগ করুন এবং sudo systemctl reload tor@default দিয়ে reload করুন। MyFamily তালিকাটিও রেখে দিন। যে client-গুলো এখনও family key বোঝে না, তারা শুধু পুরোনো তালিকাটি পড়ে। এ কারণেই manual-এ দুটিই ব্যবহারের নির্দেশ দেওয়া হয়েছে।

চলমান অবস্থায় যা যা নষ্ট হতে পারে

ভার্সন পুরনো হয়ে যাওয়া। Unattended upgrades প্যাকেজটি প্রতিস্থাপন করলেও, চলমান প্রসেসটি তার শুরুর সময়ের বাইনারিটিই ব্যবহার করতে থাকে যতক্ষণ না সেটি রিস্টার্ট করা হয়। বক্সে থাকা tor --version-এর সাথে রিলে-এর Relay Search পেজে দেখানো ভার্সনটি মিলিয়ে দেখুন। যদি দুটির মধ্যে পার্থক্য থাকে, তবে নেটওয়ার্ক এখনও পুরনো ভার্সনটিই দেখছে, তাই সার্ভিসটি রিস্টার্ট করুন।

ঘড়ির সময় পিছিয়ে যাওয়া (Clock drift)। কনসেনসাস ডকুমেন্ট এবং সার্টিফিকেটগুলো সময়ের ওপর নির্ভরশীল, তাই যে মেশিনের ঘড়ি অনেক পিছিয়ে বা এগিয়ে থাকে তা কনসেনসাস প্রত্যাখ্যান করে এবং পাবলিশ করা বন্ধ করে দেয়। timedatectl-এর মাধ্যমে সিস্টেম ক্লক সিঙ্ক্রোনাইজড আছে কি না তা নিশ্চিত করুন। যদি তা না হয়, তবে systemd-timesyncd চালু করুন অথবা chrony ইনস্টল করুন।

IP অ্যাড্রেস পরিবর্তন। ডেসক্রিপ্টরে অ্যাড্রেসটি উল্লেখ থাকে, তাই অ্যাড্রেস পরিবর্তিত হলে ক্লায়েন্টরা আর রিলে-তে পৌঁছাতে পারে না। কোনো প্রোভাইডার মাইগ্রেশন বা অ্যাড্রেস পরিবর্তনের পর, tor রিস্টার্ট করুন এবং সেলফ-টেস্ট লাইনটির জন্য অপেক্ষা করুন।

রিলে-এর গতি পরিকল্পনার চেয়ে কম হওয়া। আধুনিক প্রসেসরে Tor-এর রিলে ক্রিপ্টো বেশ কার্যকর। Tor Project-এর মতে, AES-NI সাপোর্টসহ একটি CPU প্রতিটি দিকে প্রায় 400 থেকে 450 Mbit/s গতি দিতে সক্ষম। এই সীমার অনেক আগেই আপনি পোর্ট স্পিড এবং ট্রান্সফার লিমিটের কারণে সীমাবদ্ধ হয়ে পড়বেন, আর এই কারণেই হার্ডওয়্যারের চেয়ে উপরের অ্যাকাউন্টিং সেকশনটি বেশি গুরুত্বপূর্ণ।

FAQ

Tor relay কত bandwidth ব্যবহার করে?

আপনি যতটা অনুমতি দেবেন, ততটাই ব্যবহার করবে; এর বেশি নয়। RelayBandwidthRate প্রতিটি দিকের relayed traffic আলাদাভাবে সীমাবদ্ধ করে। তাই 1 Mbit/s-এ সেট করা একটি relay একই সময়ে 1 Mbit/s inbound এবং 1 Mbit/s outbound traffic বহন করতে পারে। উভয় দিক গণনা করলে এটি দিনে প্রায় 21.6 GB, অথবা 30 দিনের মাসে 648 GB হয়। এই rate-এর নিচে hard monthly quota হিসেবে AccountingMax-এর সঙ্গে AccountingRule sum যোগ করুন।

Tor relay চালালে কি abuse complaint পাব?

guard বা middle relay traffic শুধু অন্য Tor relay-এ পাঠায় এবং কোনো ব্যবহারকারীর হয়ে কখনো website-এ সংযোগ করে না। তাই Tor-এর মাধ্যমে কেউ কী করেছে, সে-সংক্রান্ত complaint exit operator-এর কাছে যায়, আপনার কাছে নয়। তবে relay-এর address public তালিকাভুক্ত থাকায় scanning এবং মাঝে মাঝে IP reputation listing দেখতে পারেন। Exit relay-গুলোই abuse mail ও legal notice পায়। এগুলো চালাতে এমন provider প্রয়োজন, যে আগে থেকেই এসব বিষয় সামলাতে সম্মত। যেকোনো ধরনের relay চালু করার আগে provider-এর terms পড়ুন।

আমার নতুন Tor relay কোনো traffic পাচ্ছে না কেন?

কারণ পরিমাপ না হওয়া পর্যন্ত নতুন relay-কে নকশা অনুযায়ী throttled রাখা হয়। প্রথম 3 দিন directory authority-গুলো published weight 20 KB-এ সীমাবদ্ধ রাখে। তাই client-রা প্রায় কখনো relay-টি বেছে নেয় না। Bandwidth authority-গুলো প্রায় তৃতীয় দিন থেকে relay-টি মাপতে শুরু করে। প্রায় অষ্টম দিনে এটি Guard flag পাওয়ার উপযুক্ত হয়। সেই সময় traffic আবার কমে, কারণ middle hop বাছাই করার সময় client-রা guard এড়িয়ে চলে। প্রায় 68তম দিনে পূর্ণ load আসে। লগে "Self-testing indicates your ORPort is reachable from the outside" দেখা যাচ্ছে কি না নিশ্চিত করুন। এরপর relay-টি আর পরিবর্তন করবেন না।

1 TB transfer allowance-সহ VPS-এ কি Tor relay চালাতে পারি?

হ্যাঁ। প্রতিটি দিকে প্রায় 1 Mbit/s হারে চালানো যায়, যা RelayBandwidthRate 125 KBytes। Provider যদি উভয় দিকের traffic মাপে, তাহলে মাসে প্রায় 648 GB হবে। এতে update ও backup-এর জন্য অতিরিক্ত capacity থাকবে। Plan-এর সীমা অতিক্রম না করে relay-কে hibernate করাতে AccountingMax 400 GBytes-এর সঙ্গে AccountingRule sum এবং AccountingStart month 1 00:00 যোগ করুন। Provider যদি শুধু outbound traffic-এর জন্য bill করে, তাহলে rate দ্বিগুণ করতে পারেন।

আমি শুধু একটি relay চালালে কি MyFamily সেট করতে হবে?

না। Family declaration-এর উদ্দেশ্য হলো, একই operator-এর মালিকানাধীন দুটি relay-এর মধ্য দিয়ে client যাতে circuit তৈরি না করে তা নিশ্চিত করা। একটি relay থাকলে এর কোনো অর্থ নেই। দ্বিতীয় relay যোগ করার সঙ্গে সঙ্গে এটি সেট করুন। প্রতিটি relay-এর fingerprint প্রতিটি relay-এর MyFamily line-এ তালিকাভুক্ত করুন। প্রতিটি relay-এ Tor 0.4.9.2-alpha বা পরবর্তী version চললে shared family key-এর FamilyId line-ও যোগ করুন। আপাতত tor manual উভয়টি configure করতে বলে, যাতে পুরোনো client-ও family চিনতে পারে।