VPS پر Tor relay کیسے چلائیں

VPS پر Tor relay کیا کرتا ہے

Tor relay عوامی IP address والی مشین پر چلنے والا Tor daemon ہے جو دوسرے لوگوں کے لیے encrypted traffic آگے بھیجتا ہے۔ Directory authorities اسے publish کرتی ہیں، اور Tor clients اس کے ذریعے circuits بناتے ہیں۔ Guard یا middle relay traffic صرف کسی دوسرے relay کو بھیجتا ہے، اس لیے وہ کسی اجنبی کی جانب سے website سے connection قائم نہیں کرتا۔ یہی وجہ ہے کہ اس پر abuse mail نہیں آتی، اور یہی کام عام VPS کے لیے موزوں contribution ہے۔ Relay دوسرے لوگوں کا traffic منتقل کرتا ہے اور اپنی طرف سے کچھ publish نہیں کرتا۔ اگر آپ کا مقصد network پر اپنی site دستیاب کرانا ہے، نہ کہ اس کے لیے packets منتقل کرنا، تو nginx کے پیچھے v3 onion service چلانا اسی tor daemon کے لیے ایک مختلف کام ہے۔ Relay چلانے سے آپ کی اپنی browsing کی privacy بہتر نہیں ہوتی۔ یہ الگ مسئلہ ہے، اور اس کی حد اکثر لوگوں کی توقع سے کم ہوتی ہے: SearXNG کو self-host کرنے سے حقیقتاً کیا چھپتا ہے اس بات کا مناسب اندازہ دیتا ہے کہ کسی service کو اپنے VPS پر منتقل کرنے سے آپ کو کتنا فائدہ ہوتا ہے۔

کام مختصر ہے: ایک package، config کی پندرہ سطریں، firewall کا ایک rule، اور ایک restart۔ اس guide کا باقی حصہ ان مسائل سے متعلق ہے جو عموماً پیدا ہوتے ہیں۔ اس میں metered plan پر bandwidth کا حساب اور یہ وجہ شامل ہے کہ بالکل درست کام کرنے والا نیا relay ایک ہفتے تک غیر فعال دکھائی دیتا ہے۔

Guard، middle، bridge یا exit: انسٹال کرنے سے پہلے کردار منتخب کریں

ایک ہی daemon یہ چاروں کردار ادا کر سکتا ہے۔ آپ کی configuration اور directory authorities مل کر طے کرتی ہیں کہ آپ کا relay کون سا کردار ادا کرے گا۔

• Middle relay۔ یہ guard سے traffic وصول کر کے اسے دوسرے relay تک پہنچاتا ہے۔ یہ کبھی destination site سے براہِ راست رابطہ نہیں کرتا۔ ہر نیا relay اسی کردار سے شروع ہوتا ہے۔
• Guard relay۔ یہی configuration استعمال ہوتی ہے، لیکن اس کے اوپر ایک flag موجود ہوتا ہے۔ Directory authorities ان relays کو Guard flag دیتی ہیں جو کافی عرصے تک تیز رفتار اور مستحکم رہے ہوں۔ آپ اسے خود منتخب نہیں کرتے۔ آپ اسے کارکردگی سے حاصل کرتے ہیں، اور نیچے دی گئی configuration اسی مقصد کے لیے ہے۔
• Bridge۔ یہ ایسا relay ہے جسے دانستہ طور پر public directory سے باہر رکھا جاتا ہے اور ان مقامات کے صارفین کو نجی طور پر دیا جاتا ہے جہاں Tor blocked ہے۔ چاروں کرداروں میں اس کے لیے سب سے کم commitment درکار ہوتی ہے: کم bandwidth، کوئی public listing نہیں، اور اگر آپ کا منصوبہ محدود ہو تو یہ درست پہلا قدم ہے۔ اس کے لیے daemon کے ساتھ obfs4 proxy بھی چلانا پڑتا ہے اور torrc کی مختلف lines درکار ہوتی ہیں۔ ایک کم لاگت والے VPS پر obfs4 bridge قائم کرنے کا طریقہ اس پورے عمل کی وضاحت کرتا ہے، بشمول اس کے کہ آخر میں صارفین کو bridge line کیسے دی جاتی ہے۔
• Exit relay۔ یہ آخری hop ہوتا ہے جو destination site سے connection قائم کرتا ہے۔ صارف کی ہر request آپ کے IP address سے باہر جاتی ہے، اس لیے abuse reports اور police inquiries اس address کے مالک تک پہنچتی ہیں۔

Exit کو general-purpose VPS پر نہیں چلانا چاہیے۔ Exit صرف ایسے provider پر چلائیں جو پہلے ہی اس mail کو وصول کرنے پر رضامند ہو، جس کا اپنا IP address اور شائع شدہ abuse contact ہو۔ زیادہ تر standard hosting terms اسے ممنوع قرار دیتی ہیں۔ اسے نظرانداز کرنے کا عام نتیجہ suspended server اور IP address سے محرومی ہوتا ہے۔ اگر آپ پھر بھی یہی کام کرنا چاہتے ہیں تو exit relay چلانے میں عملی طور پر کیا شامل ہوتا ہے میں exit-friendly host تلاش کرنے، exit policy اور reverse DNS لکھنے، اور mail آنے پر اس کا جواب دینے کی تفصیل موجود ہے۔ Guard یا middle relay یہی user traffic اس تمام exposure کے بغیر منتقل کرتا ہے۔

ذیل کا تمام طریقہ guard/middle relay تیار کرتا ہے۔ ExitRelay 0 وہ line ہے جو اسے ایک ہی کردار تک محدود رکھتی ہے۔

شروع کرنے سے پہلے VPS کے لیے ضروریات

Tor Project relays کے لیے سخت تقاضے شائع کرتا ہے۔ August 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 کے لیے کوئی مقررہ اصول نہیں ہے، لیکن جو relay روزانہ دو گھنٹے سے کم چلتا ہو وہ network کے لیے بہت کم مفید ہے۔

10 Mbit/s کی مقدار line کی رفتار بیان کرتی ہے، setting کی نہیں۔ آپ کو ایسا port درکار ہے جو یہ رفتار فراہم کر سکے۔ آپ relay کو اس line کی کتنی bandwidth استعمال کرنے دیں گے، یہ الگ فیصلہ ہے اور اسے ماہانہ transfer allowance کے مطابق کرنا ہوگا۔ configuration تبدیل کرنے سے پہلے اپنا plan پڑھیں۔ اگر آپ ابھی server منتخب کر رہے ہیں تو VPS کی ماہانہ حقیقی لاگت میں بتایا گیا ہے کہ transfer allowances کس طرح فروخت کیے جاتے ہیں، جبکہ VPS کی حقیقی network throughput کی پیمائش میں iperf3 کے ذریعے یہ معلوم کرنے کا طریقہ دیا گیا ہے کہ line واقعی کیا کارکردگی دیتی ہے، نہ کہ sales page پر درج معلومات پر انحصار کیا جائے۔

پہلے machine کو harden کریں۔ relay ایک public address پر public service ہوتی ہے، اور address شائع ہونے کے چند منٹ کے اندر scan ہونا شروع ہو جاتا ہے۔ SSH کو صرف keys اور hardened sshd config تک محدود کرنا دس منٹ لیتا ہے۔ یہ کام relay کے live ہونے سے پہلے کریں، بعد میں نہیں۔

Tor Project کے repository سے Tor انسٹال کریں

Distribution package کے بجائے Tor Project کا اپنا apt repository استعمال کریں۔ Relay code مستحکم release کے مقابلے میں زیادہ تیزی سے آگے بڑھتا ہے، اس لیے fixes اس repository تک پہلے پہنچتی ہیں، جبکہ distribution package releases کے درمیان پیچھے رہ جاتا ہے۔

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

Signing key شامل کریں، پھر repository شامل کریں۔ Codename machine سے پڑھا جاتا ہے، اس لیے یہی 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 کو print کرتا ہے۔ اگر apt update نے اس کے بجائے NO_PUBKEY error print کیا ہو تو dearmored key، Signed-By: line میں بیان کردہ path پر موجود نہیں ہے۔ اس لیے apt کے پاس release file کی جانچ کے لیے کوئی key نہیں ہے۔ deb.torproject.org-keyring package بعد میں اہم ہوگا: یہ signing key کو عام package کے طور پر فراہم کرتا ہے، اس لیے key rotate ہونے پر بھی apt کام کرتا رہتا ہے۔

Automatic upgrades فعال کریں، پھر انہیں نئے origin کے بارے میں بتائیں۔

sudo apt install -y unattended-upgrades apt-listchanges

Ubuntu پر Tor origin کو /etc/apt/apt.conf.d/50unattended-upgrades میں موجود Allowed-Origins block میں شامل کریں:

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 سے چیک کریں۔ یہ ان origins کو print کرتا ہے جن پر یہ عمل کرے گا اور کوئی file نہیں لکھتا۔

وہ torrc جو اہم ہے

پیکیج ایک طویل اور تفصیلی تبصروں والا /etc/tor/torrc install کرتا ہے۔ Relay کے لیے صرف چند سطریں اہم ہیں۔ انہیں فائل کے آخر میں شامل کریں۔

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

Nickname میں 1 سے 19 حروف تک شامل ہوتے ہیں، اور صرف حروف اور digits استعمال کیے جا سکتے ہیں۔ یہ network میں منفرد نہیں ہوتا؛ آپ کی شناخت fingerprint ہوتی ہے۔ Search box میں اپنا relay تلاش کرنے کے لیے یہی نام استعمال ہوگا، اس لیے ایسا نام منتخب کریں جسے آپ فون پر آسانی سے ہجے کر سکیں۔

ContactInfo relay descriptor میں شائع ہوتا ہے۔ Relay descriptor ایک public document ہے جسے کوئی بھی download کر سکتا ہے، اس لیے یہ address جمع کیا جائے گا۔ ایسا address استعمال کریں جسے آپ دو سال بعد بھی پڑھتے ہوں، اور اگر چاہیں تو اسے obfuscate کر دیں۔ Tor Project کے پاس آپ کو آپ کے relay کے مسئلے سے آگاہ کرنے کے لیے یہی واحد channel ہے۔

ORPort 9001 وہ port ہے جس سے دوسرے relays اور clients connect ہوتے ہیں۔ 9001 روایتی انتخاب ہے۔ Port 443 بھی عام انتخاب ہے، کیونکہ کچھ restrictive networks صرف outbound 443 کی اجازت دیتے ہیں۔ اس لیے وہاں listening کرنے والا relay زیادہ clients کے لیے reachable ہوتا ہے۔ 443 صرف اسی وقت منتخب کریں جب machine پر کوئی اور چیز اسے استعمال نہ کر رہی ہو۔

SocksPort 0 local SOCKS proxy کو بند کرتا ہے، جسے relay استعمال نہیں کرتا، اور machine سے ایک listening socket ہٹا دیتا ہے۔ ExitRelay 0 اس مقصد کو فائل میں واضح طور پر درج کرتا ہے: یہ relay کبھی بھی کسی user کی طرف سے کسی destination سے connect نہیں ہوگا، اور بعد میں configuration پڑھنے والے شخص کو یہ بات default settings سے اخذ نہیں کرنا پڑے گی۔

اگر VPS کے پاس IPv6 address ہے تو دوسری ORPort line شامل کریں۔ Tor IPv4 کی طرح IPv6 کے لیے "any" address پر bind نہیں کر سکتا، اس لیے address کو square brackets میں واضح طور پر لکھیں۔

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

1 GB VPS پر MaxMemInQueues 512 MB شامل کریں۔ Tor machine پر دستیاب memory کی بنیاد پر اپنی queue limit طے کرتا ہے۔ چھوٹی shared machine پر یہ limit آپ کی مطلوبہ حد سے زیادہ ہو سکتی ہے۔ Limit خود مقرر کرنے سے دباؤ کے دوران tor queued cells discard کر دیتا ہے اور relay چلتا رہتا ہے، بجائے اس کے کہ queue بڑھتی رہے اور آخرکار kernel process کو kill کر دے۔

فائر وال میں ORPort کھولیں

Inbound سمت میں ORPort انٹرنیٹ پر کہیں سے بھی قابل رسائی ہونا چاہیے۔ Outbound سمت میں relay پر پابندی نہ لگائیں۔ یہ مختلف ports پر ہزاروں دیگر relays سے connections قائم کرتا ہے، اور outbound allowlist اسے خاموشی سے ناقابلِ استعمال بنا دے گی۔

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

اس کے بعد provider کے اپنے network firewall کو بھی چیک کریں۔ بہت سے control panels virtual machine کے سامنے packet filter چلاتے ہیں۔ وہاں شامل کیا گیا rule، ufw کے ذریعے شامل کیے گئے rule سے متاثر نہیں ہوتا۔ اس لیے port سرور پر open، لیکن باہر سے closed دکھائی دے سکتا ہے۔ اگر ufw آپ کے لیے نیا ہے تو ہر VPS پر موجود ہونے والے ufw rules default policy اور rules کے match ہونے کی ترتیب کی وضاحت کرتا ہے۔

اپنے پلان کے مطابق bandwidth مقرر کریں

دستی کتابچہ RelayBandwidthRate کو ایک الگ token bucket کے طور پر بیان کرتا ہے۔ یہ "اس node پر relayed traffic کے لیے اوسط incoming bandwidth usage کو فی سیکنڈ مقررہ bytes تک، اور اوسط outgoing bandwidth usage کو اسی قدر تک محدود کرتا ہے"۔ اس بات کو دوبارہ پڑھیں۔ حد ہر سمت پر الگ لاگو ہوتی ہے۔ 1 Mbit/s پر مقرر relay بیک وقت 1 Mbit/s اندر اور 1 Mbit/s باہر منتقل کر سکتا ہے۔ جو provider دونوں سمتوں کی پیمائش کرتا ہے، وہ مجموعہ bill کرتا ہے۔

[
  {
    "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 rows پیمائش نہیں بلکہ حساب ہیں۔ یہ دکھاتی ہیں کہ اگر relay پورے 30 days تک دونوں سمتوں میں مسلسل اس rate پر چلے تو اس rate کی کیا لاگت ہوگی۔ حقیقی relay زیادہ تر وقت اپنی cap سے کم traffic چلاتا ہے، خاص طور پر ابتدائی ہفتوں میں۔ اس table کو ان settings کو خارج کرنے کے لیے استعمال کریں جو آپ کے بجٹ میں نہیں آ سکتیں۔ اسے gigabyte کے حساب سے invoice کی پیش گوئی کے لیے استعمال نہ کریں۔

1 Mbit/s فی سمت پر relay روزانہ تقریباً 21.6 GB منتقل کرتا ہے۔ اس لیے 30 day month میں تقریباً 648 GB metered traffic بنتا ہے۔ یہ 1 TB allowance میں updates اور backups کے لیے کچھ گنجائش کے ساتھ آ جاتا ہے۔ 2 Mbit/s تک بڑھانے پر month میں 1,296 GB بنتا ہے، جو پہلے ہی 1 TB plan سے زیادہ ہے۔ آخری row، 20 Mbit/s، کے لیے ہر month 12,960 GB درکار ہے، اس لیے اسے unmetered port پر چلائیں۔ اگر آپ کا provider صرف outbound traffic کا bill لیتا ہے تو ہر figure کو نصف کر دیں۔ Rate مقرر کرنے سے پہلے معلوم کریں کہ آپ کے پاس کون سا billing model ہے، کیونکہ دونوں صورتوں میں فرق دو گنا ہوتا ہے۔

اب config دیکھیں۔ پہلے rate limit کریں، پھر quota مقرر کریں۔

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

RelayBandwidthBurst token bucket کا size ہے۔ اس لیے average rate برقرار رہنے کے دوران مختصر spikes کی اجازت ملتی ہے۔ Rate سے تقریباً دو گنا ایک مناسب value ہے۔

AccountingRule وہ line ہے جسے زیادہ تر operators نظرانداز کر دیتے ہیں۔ Default max ہے، جو quota کے مقابلے میں دونوں سمتوں میں سے زیادہ والی direction کی پیمائش کرتا ہے۔ Default کے ساتھ AccountingMax 400 GBytes اندر آنے والے 400 GB اور باہر جانے والے 400 GB کی اجازت دیتا ہے۔ دونوں سمتوں کو count کرنے والے meter پر یہ 800 GB بنتا ہے۔ AccountingRule sum read اور write کو ایک ہی quota کے خلاف جمع کرتا ہے۔ Transfer allowance حقیقت میں اسی مقدار کی پیمائش کرتا ہے۔

AccountingStart بھی لکھیں۔ AccountingMax کو اکیلے کبھی نہ لکھیں۔ Quota number ہوتا ہے، جبکہ start line وہ period متعین کرتی ہے جس پر quota reset ہوتا ہے۔ Period کے بغیر quota relay کو hibernating حالت میں چھوڑ دیتا ہے اور اسے دوبارہ فعال کرنے کے لیے کوئی trigger نہیں رہتا۔

Hibernation ایک سخت طریقہ ہے۔ Quota ختم ہونے پر tor اس واقعے کو log کرتا ہے اور کام لینا بند کر دیتا ہے:

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

Relay اگلے period کے عین آغاز پر بھی بیدار نہیں ہوتا۔ Tor یہ دیکھتا ہے کہ پچھلا quota کتنی تیزی سے استعمال ہوا تھا، پھر نئے interval کے اندر ایک random point منتخب کرتا ہے۔ اس طرح ہزاروں relays ایک ہی second میں network پر واپس نہیں آتے۔ جو relay ہر month کے آخری ہفتے میں غائب رہتا ہے، وہ directory authorities کی جانب سے ناپی جانے والی stability مسلسل کھوتا رہتا ہے۔ RelayBandwidthRate کو اس طرح مقرر کریں کہ cap کبھی نہ پہنچے، اور invoice کو محفوظ رکھنے کے لیے AccountingMax کو backstop کے طور پر برقرار رکھیں۔

ریلے شروع کریں اور اس کی رسائی کی تصدیق کریں

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

چند منٹ کے اندر log میں یہ سطر شامل ہونی چاہیے:

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

اس جملے کا مطلب ہے کہ دوسرے relays آپ کے ORPort سے دوبارہ connected ہوئے اور اس کے ذریعے circuit بنایا۔ جب تک یہ سطر ظاہر نہیں ہوتی، آپ کا relay directory میں شامل نہیں ہوتا اور بالکل بھی traffic نہیں سنبھالتا۔ failure اس طرح ظاہر ہوتی ہے:

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.

اس مسئلے کو اسی ترتیب سے حل کریں۔ کیا ORPort، ufw میں open ہے؟ کیا provider کے الگ network firewall میں بھی یہ port open ہے؟ کیا اس پیغام میں دیا گیا address وہی address ہے جس پر internet واقعی آپ تک network traffic route کرتا ہے، نہ کہ NAT setup سے حاصل ہونے والا private address؟ کسی دوسری machine سے `nc -vz 203.0.113.10 9001` کے ذریعے port test کریں۔ Tor خود بھی self-test دہراتا ہے، اس لیے firewall درست ہونے کا فوراً پتہ چل جاتا ہے، جبکہ restart سے یہ عمل فوری ہو جاتا ہے۔

آپ کے relay کی مستقل شناخت اس کا fingerprint ہے:

sudo cat /var/lib/tor/fingerprint

descriptor publish ہونے کے تقریباً 3 hours بعد relay، Relay Search پر ظاہر ہو جاتا ہے۔ nickname تلاش کریں یا fingerprint paste کریں۔ یہ page network کے مطابق آپ کے relay کی حالت دکھاتا ہے: اس کے پاس کون سے flags ہیں، authorities اسے کتنا weight دیتے ہیں، اور یہ کون سا version publish کر رہا ہے۔

نیا Tor relay تقریباً کوئی network traffic کیوں نہیں سنبھالتا؟

کیونکہ network نے ابھی اس کی پیمائش نہیں کی، اور پیمائش میں کئی ہفتے لگتے ہیں۔ Tor Project اس ابتدائی مرحلے کو 4 مراحل میں بیان کرتا ہے، لیکن جس operator نے یہ وضاحت نہیں پڑھی ہوتی وہ سمجھتا ہے کہ relay خراب ہے اور configuration میں تبدیلیاں شروع کر دیتا ہے۔

پہلے 3 دن relay کی پیمائش نہیں کی جاتی۔ یہ اپنا self test result رپورٹ کرتا ہے، لیکن directory authorities شائع شدہ weight کو بہرحال 20 KB تک محدود رکھتی ہیں، اس لیے clients اسے تقریباً کبھی منتخب نہیں کرتے۔ تقریباً تیسرے دن سے آٹھویں دن تک bandwidth authorities اس کی باقاعدہ پیمائش کرتی ہیں اور weight بڑھتا ہے، لیکن اسے صرف middle hop کے طور پر استعمال کیا جاتا ہے، کیونکہ کوئی client بالکل نئے relay کو اپنا first hop بنانے پر آمادہ نہیں ہوتا۔

تقریباً آٹھویں دن relay Guard flag کے لیے اہل ہو جاتا ہے۔ یہ flag ملنے سے traffic کم ہو جاتا ہے، جو سب کو حیران کرتا ہے: clients middle hops منتخب کرتے وقت guards کو نظرانداز کرتے ہیں، کیونکہ وہ فرض کرتے ہیں کہ guard پہلے ہی مصروف ہے۔ اس لیے relay کو guard traffic حاصل ہونے سے پہلے middle traffic کم ہو جاتا ہے۔ جب clients اپنے guard sets تبدیل کرتے ہیں تو اس میں دوبارہ traffic آتا ہے، اور اس عمل میں کئی ہفتے لگتے ہیں۔ تقریباً 68 دن میں یہ مستقل حالت تک پہنچتا ہے، جہاں اسے چھوڑنے والے clients کی تعداد اسے شامل کرنے والے clients کے برابر ہو جاتی ہے۔

اس لیے حقیقت پسندانہ توقع یہ ہے: پہلے 3 دن کچھ نہیں، 1 ہفتے کے بعد کچھ traffic، اور 2 ماہ بعد حقیقی load۔ ایک وقت میں 1 setting تبدیل کریں، پھر یہ دیکھنے کے لیے 1 ہفتہ انتظار کریں کہ اس کا کیا اثر ہوا۔ self-hosted Uptime Kuma status page پر port 9001 کے خلاف TCP check کرنا اس بے چینی کو استعمال کرنے کا بہتر طریقہ ہے۔ اس سے اس سوال کا جواب ملتا ہے جس پر آپ واقعی قابو رکھتے ہیں: کیا port اب بھی requests کا جواب دے رہا ہے؟

nyx کے ذریعے relay کی نگرانی

nyx چلتے ہوئے relay کے لیے terminal monitor ہے۔ یہ Tor کے control port سے رابطہ کرتا ہے، اس لیے پہلے torrc میں اسے فعال کریں:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort صرف 127.0.0.1 پر listening کرتا ہے، اور cookie authentication کا مطلب ہے کہ کوئی program commands جاری کرنے سے پہلے ایک secret file پڑھے۔ Tor اس cookie کو /run/tor/control.authcookie میں debian-tor user کے طور پر mode 600 کے ساتھ لکھتا ہے، تاکہ کوئی دوسرا اسے نہ پڑھ سکے۔ CookieAuthFileGroupReadable 1 اس file کو group کے لیے بھی کھول دیتا ہے۔ اسی وجہ سے آپ کا اپنا 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 چلانے پر cookie file کے لیے permission error آتا ہے، حالانکہ configuration درست ہوتی ہے۔ nyx live bandwidth، uptime، log stream اور connection list دکھاتا ہے۔ ابتدائی ہفتوں میں bandwidth graph کو اپنے RelayBandwidthRate سے نیچے رہتے دیکھنا اہم ہے۔

ایک سے زیادہ relay چلانا: MyFamily اور family keys

اگر صرف ایک relay ہے تو یہ section چھوڑ دیں۔ ایک ہی operator کے زیر انتظام دو یا زیادہ relays کو ایک دوسرے کا اعلان کرنا ضروری ہے، تاکہ clients کبھی ایسا circuit نہ بنائیں جو آپ کی مشینوں میں داخل ہو کر انہی کے ذریعے باہر نکلے۔ بصورت دیگر ایک operator اس circuit کے دونوں سروں کو دیکھ سکتا ہے۔

روایتی طریقہ یہ ہے کہ ہر relay کے torrc میں MyFamily شامل کریں اور اس میں باقی تمام relays کے fingerprints درج کریں:

MyFamily AAAAAAAAAA,BBBBBBBB

ہر relay میں باقی ہر relay درج ہوتا ہے، اس لیے چوتھا relay شامل کرنے کے لیے چار files میں ترمیم کرنا پڑتی ہے۔ Tor 0.4.9 نے اس طریقے کی جگہ family key متعارف کرائی۔ ایک 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 list بھی برقرار رکھیں۔ جو clients ابھی family certificates کو نہیں سمجھتے، وہ legacy list پڑھتے رہیں گے۔ Tor Project بعد میں بتائے گا کہ اسے کب ہٹایا جا سکتا ہے۔

چلنے کے بعد کیا خراب ہوتا ہے

ورژن پرانا ہو جاتا ہے۔ Unattended upgrades package کو replace کر دیتے ہیں، لیکن چلتا ہوا process اسی binary کو استعمال کرتا رہتا ہے جس کے ساتھ وہ شروع ہوا تھا، جب تک کوئی اسے restart نہ کرے۔ باکس پر موجود tor --version کا موازنہ relay کے Relay Search صفحے پر دکھائے گئے version سے کریں۔ اگر دونوں مختلف ہوں تو network کو اب بھی پرانا version نظر آ رہا ہے، اس لیے service کو restart کریں۔

گھڑی کا وقت آگے پیچھے ہو جاتا ہے۔ Consensus documents اور certificates وقت کے پابند ہوتے ہیں، اس لیے جس machine کی گھڑی میں بہت زیادہ فرق ہو وہ consensus کو reject کر دیتی ہے اور publishing روک دیتی ہے۔ timedatectl کو system clock کے synchronized ہونے کی اطلاع دینی چاہیے۔ اگر ایسا نہ ہو تو systemd-timesyncd کو enable کریں یا chrony install کریں۔

IP address تبدیل ہو جاتا ہے۔ Descriptor میں address شامل ہوتا ہے، اور clients ایسے address تک نہیں پہنچ سکتے جو تبدیل ہو چکا ہو۔ کسی بھی provider migration یا address change کے بعد tor کو restart کریں اور self-test line دوبارہ ظاہر ہونے کی نگرانی کریں۔

Relay منصوبے میں مقررہ رفتار سے سست ہے۔ جدید processors پر Tor کی relay cryptography مؤثر ہے، اور Tor Project کے مطابق AES-NI support والے CPU کی رفتار ہر سمت میں تقریباً 400 سے 450 Mbit/s ہوتی ہے۔ اس حد تک پہنچنے سے بہت پہلے آپ port speed اور transfer allowance کے پابند ہو جاتے ہیں، اسی لیے اوپر والا accounting section hardware سے زیادہ اہم ہے۔

FAQ

Tor relay کتنی bandwidth استعمال کرتا ہے؟

جتنی آپ اجازت دیں گے، اس سے زیادہ نہیں۔ RelayBandwidthRate ہر سمت میں relay کیے جانے والے traffic کی حد الگ الگ مقرر کرتا ہے، اس لیے 1 Mbit/s پر configured relay ایک ہی وقت میں 1 Mbit/s inbound اور 1 Mbit/s outbound traffic منتقل کر سکتا ہے۔ دونوں سمتوں کو شمار کرنے پر یہ تقریباً 21.6 GB فی دن، یا 30 دن کے مہینے میں 648 GB بنتا ہے۔ اس rate کے نیچے سخت ماہانہ quota کے طور پر AccountingMax کو AccountingRule sum کے ساتھ شامل کریں۔

کیا Tor relay چلانے پر مجھے abuse complaints موصول ہوں گی؟

Guard یا middle relay traffic صرف دوسرے Tor relays کو منتقل کرتا ہے اور کسی user کے لیے website سے براہِ راست connect نہیں ہوتا۔ اس لیے Tor کے ذریعے کسی شخص کی سرگرمی سے متعلق complaints آپ کے بجائے exit operator کو بھیجی جاتی ہیں۔ آپ کو scanning اور کبھی کبھار IP reputation listing دکھائی دے سکتی ہے، کیونکہ یہ address publicly relay کے طور پر listed ہوتا ہے۔ Abuse mail اور legal notices exit relays کو موصول ہوتے ہیں، اس لیے انہیں ایسے provider کی ضرورت ہوتی ہے جو پہلے ہی انہیں handle کرنے پر رضامند ہو۔ شروع کرنے سے پہلے اپنے provider کی terms پڑھیں، خواہ آپ کوئی بھی قسم چلائیں۔

میرے نئے Tor relay کو traffic کیوں نہیں مل رہا؟

کیونکہ نئے relays کو جان بوجھ کر throttle کیا جاتا ہے، جب تک ان کی پیمائش نہ ہو جائے۔ پہلے 3 دن تک directory authorities published weight کو 20 KB تک محدود رکھتی ہیں، اس لیے clients تقریباً کبھی اس relay کو منتخب نہیں کرتے۔ Bandwidth authorities تقریباً تیسرے دن سے اس کی پیمائش شروع کرتی ہیں۔ آٹھویں دن کے آس پاس یہ Guard flag کے لیے eligible ہو جاتا ہے، اور اسی وقت traffic دوبارہ کم ہو جاتا ہے کیونکہ clients middle hops منتخب کرتے وقت guards سے گریز کرتے ہیں۔ مکمل load تقریباً 68 دن کے بعد آتا ہے۔ تصدیق کریں کہ log میں "Self-testing indicates your ORPort is reachable from the outside" دکھائی دے، پھر اسے اسی حالت میں رہنے دیں۔

کیا میں 1 TB transfer allowance والے VPS پر Tor relay چلا سکتا ہوں؟

ہاں، ہر سمت میں تقریباً 1 Mbit/s کی رفتار پر، جو RelayBandwidthRate 125 KBytes ہے۔ اگر آپ کا provider دونوں سمتوں کا traffic meter کرتا ہے تو یہ تقریباً 648 GB فی ماہ بنتا ہے، اور updates اور backups کے لیے کچھ گنجائش باقی رہتی ہے۔ AccountingMax 400 GBytes کو AccountingRule sum اور AccountingStart month 1 00:00 کے ساتھ شامل کریں تاکہ relay plan کی حد سے تجاوز کرنے کے بجائے hibernate ہو جائے۔ اگر provider صرف outbound traffic کا bill لیتا ہے تو آپ rate کو دگنا کر سکتے ہیں۔

اگر میں صرف ایک relay چلا رہا ہوں تو کیا مجھے MyFamily set کرنا ہوگا؟

نہیں۔ Family declarations اس لیے ہوتی ہیں کہ clients ایک ہی operator کی ملکیت والے دو relays کے ذریعے circuit بنانے سے گریز کریں۔ ایک relay کی صورت میں اس کا کوئی مفہوم نہیں۔ دوسرا relay شامل کرتے ہی اسے set کریں: ہر relay کی fingerprint، ہر relay کی MyFamily line میں درج کریں، یا وہ family key استعمال کریں جو Tor 0.4.9 میں متعارف ہوئی تھی۔ یہ مسلسل بڑھتی ہوئی فہرست کے بجائے ایک FamilyId تقسیم کرتی ہے۔