VPS پر obfs4 کے ساتھ Tor bridge چلائیں

Tor bridge کیا ہے اور یہ کیوں موجود ہے

Tor bridge، Tor network میں داخلے کا ایسا نقطہ ہے جس کا address عوامی relay list میں شائع نہیں ہوتا۔ اس list کو consensus کہا جاتا ہے۔ یہ ایک signed document ہے جسے کوئی بھی download کر سکتا ہے، اور censor بھی اسے download کر لیتا ہے۔ اسے استعمال کرتے ہوئے Tor کو block کرنے میں صرف ایک دوپہر لگتی ہے: consensus حاصل کریں، پھر اس میں موجود ہر address کو سرحدی سطح پر drop کر دیں۔ Bridges اس لیے موجود ہیں کہ شائع شدہ list کمزور نقطہ ہے۔ Bridge addresses ایک وقت میں صرف چند فراہم کیے جاتے ہیں، اس لیے کوئی ایک request پورا set حاصل نہیں کرتی۔

غیر فہرست شدہ address صرف آدھا حل ہے۔ Deep packet inspection (DPI)، جو traffic کو address کے بجائے اس کے content کی بنیاد پر classify کرتا ہے، TLS (transport layer security) handshake کی ساخت سے Tor connection کو پہچان لیتا ہے۔ کسی censor کے پاس list نہ بھی ہو، وہ پھر بھی دیکھ سکتا ہے کہ "یہ Tor جیسا معلوم ہوتا ہے" اور connection کو drop کر سکتا ہے۔ Pluggable transport اس signal کو ختم کر دیتا ہے۔ یہ client side پر Tor stream کو کسی اور چیز میں wrap کرتا ہے، اور آپ کا bridge اسے unwrap کر دیتا ہے۔

obfs4 وہ transport ہے جسے زیادہ تر bridges چلاتے ہیں۔ یہ stream کو ایسے bytes میں تبدیل کرتا ہے جن میں کوئی header یا fixed handshake نہیں ہوتا، اس لیے DPI کے پاس مطابقت کے لیے کوئی pattern نہیں رہتا۔ یہ client کی authentication بھی کرتا ہے۔ Bridge line کے اندر موجود cert= value ایک key ہے، جس کے رکھنے کا ثبوت client کو bridge کے جواب دینے سے پہلے دینا ہوتا ہے۔ اس سے active probing ناکام ہو جاتی ہے: جو censor آپ کے address سے connect ہو کر یہ جانچنا چاہے کہ آیا وہاں Tor چل رہا ہے، اسے کوئی reply نہیں ملتا اور وہ کچھ معلوم نہیں کر پاتا۔

آپ کو کون سا pluggable transport چلانا چاہیے؟

• obfs4 کے لیے 1 VPS، 2 TCP ports اور کسی domain name کی ضرورت نہیں ہوتی۔ یہ وہ سب سے آسان مفید سروس ہے جسے آپ چلا سکتے ہیں، اور یہی اس guide کا موضوع ہے۔
• WebTunnel connection کو کسی حقیقی website کے معمول کے HTTPS traffic کے اندر چھپا دیتا ہے۔ Tor Project کے مطابق اس کے لیے static IPv4 address، آپ کے زیرِ اختیار domain، NGINX یا Apache جیسا فعال web server، valid TLS certificate، اور کم از کم 1 GB RAM درکار ہے؛ 4 GB تجویز کی جاتی ہے۔ یہ ایسے networks کے لیے موزوں ہے جہاں بے ترتیب دکھائی دینے والا traffic ہی مشتبہ سمجھا جاتا ہے، کیونکہ جس ملک میں web browsing کے علاوہ بہت کم traffic کی اجازت ہو، وہاں بھی HTTPS کی اجازت ہوتی ہے۔
• Snowflake ایک مختلف قسم کی شراکت ہے۔ رضاکار مختصر مدت کے لیے WebRTC proxies چلاتے ہیں، اس لیے entry points مسلسل تبدیل ہوتے رہتے ہیں اور censor کے لیے block کرنے کو کوئی مستحکم address موجود نہیں ہوتا۔ آپ اس کے لیے bridge operate نہیں کرتے۔ آپ proxy چلاتے ہیں، اور اسے کسی fixed address کی ضرورت نہیں ہوتی۔

obfs4 سے شروع کریں۔ بعد میں دوسرے address پر WebTunnel bridge شامل کیا جا سکتا ہے: دونوں کو ایک ہی IP پر چلانے کا مطلب یہ ہے کہ ایک address block ہونے سے دونوں سروسز بند ہو جائیں گی۔

Bridge چلانے کی لاگت کیا ہے؟

[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

August 2026 تک Tor Project کسی bridge سے کم از کم 1 Mbit/s upstream اور downstream bandwidth کا تقاضا کرتا ہے۔ guard یا middle relay کے لیے 10 Mbit/s درکار ہے، جبکہ 16 Mbit/s تجویز کیا جاتا ہے۔ یہ شائع شدہ تقاضے ہیں، پیمائشیں نہیں۔ نیا bridge عموماً کئی ہفتوں تک اپنی کم از کم حد سے بہت کم bandwidth استعمال کرتا ہے۔ اسی requirements page پر relay سے ہر ماہ کم از کم 100 GByte outbound traffic بھی طلب کیا گیا ہے، جسے سب سے چھوٹے plans پہلے ہی پورا کر دیتے ہیں۔ اس لیے زیادہ بڑی sizing کرنے سے پہلے دیکھیں کہ چھوٹے VPS کی ماہانہ حقیقی لاگت کیا ہوتی ہے۔

abuse کا امکان محدود ہے، اور یہی وہ نکتہ ہے جسے لوگ اکثر غلط سمجھتے ہیں۔ bridge پہلا hop ہوتا ہے۔ آپ کے server سے نکلنے والا traffic کسی دوسرے Tor relay تک جاتا ہے، صارف کے منتخب کردہ website تک براہ راست نہیں جاتا۔ آپ کا IP address کسی اجنبی کے web log میں request کے source کے طور پر ظاہر نہیں ہوتا، اس لیے وہ complaint mail جو exit relay operators کو سنبھالنی پڑتی ہے، یہاں نہیں آتی۔ پھر بھی اپنے provider کی acceptable use policy ضرور دیکھیں، کیونکہ کچھ hosts ہر Tor service کو خصوصی معاملہ سمجھتے ہیں۔ bridge اور onion service اس معاملے میں ایک دوسرے کے برعکس ہیں: bridge صرف اس لیے مفید ہوتا ہے کہ اس کا address قابل رسائی ہو اور آخرکار صارفین کو فراہم کیا جائے، جبکہ اسی نوعیت کے VPS پر v3 onion service صرف اس وقت مفید رہتی ہے جب آپ کا public IP پوشیدہ رہے۔

ایک کام نہ کریں: موجودہ public relay کو اسی address پر bridge میں تبدیل نہ کریں۔ اس صورت کے لیے Tor Project کا مشورہ ہے کہ "IP address, name and fingerprint" تبدیل کریں، کیونکہ پرانا address پہلے ہی اس consensus میں شامل ہوتا ہے جسے censoring systems download کرتے ہیں۔ جو bridge گزشتہ ہفتے public relay تھا، وہ پہلے ہی blocklist میں شامل bridge ہو سکتا ہے۔

uptime رفتار سے زیادہ اہم ہے۔ relay requirements میں کہا گیا ہے کہ "if your relay is not running for more than 2 hours a day its usefulness is limited"، اور اس معاملے میں bridge کی حالت relay سے بھی زیادہ کمزور ہوتی ہے، کیونکہ ہر client کے پاس ایک ہی address ہوتا ہے اور کوئی fallback نہیں ہوتا۔ restart ہوتے ہی اس سے منسلک ہر user کا connection ختم ہو جاتا ہے۔ Uptime Kuma میں TCP port check ترتیب دیں اور اسے obfs4 port کے خلاف چلائیں، تاکہ port کے جواب دینا بند کرتے ہی آپ کو معلوم ہو جائے۔

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

Distribution packages پیچھے رہ سکتے ہیں، جبکہ bridge ایسا security software ہے جسے جدید حالت میں ہونا چاہیے۔ پہلے project کا اپنا repository شامل کریں۔

sudo apt update
sudo apt install -y apt-transport-https gnupg wget lsb-release
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

اب source file لکھیں۔ Suites: لائن میں آپ کا release codename ہونا چاہیے، اس لیے اسے یاد سے لکھنے کے بجائے system سے حاصل کریں۔

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
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 obfs4proxy

اگر apt update رپورٹ کرے کہ آپ کے codename کے لیے repository میں Release file موجود نہیں ہے، تو Tor Project اس release کو support نہیں کرتا۔ /etc/apt/sources.list.d/tor.sources حذف کریں، دوبارہ sudo apt update چلائیں، اور وہ tor package انسٹال کریں جو آپ کی distribution فراہم کرتی ہے۔ اس کے بعد کے تمام مراحل یکساں ہیں۔

obfs4proxy package خود Debian اور Ubuntu فراہم کرتے ہیں؛ August 2026 تک Debian 13 میں اس کا version 0.0.14 ہے۔ تصدیق کریں کہ binary کہاں انسٹال ہوئی ہے، کیونکہ اس کا path configuration میں شامل کیا جائے گا:

command -v obfs4proxy || command -v lyrebird

Upstream نے project کا نام بدل کر lyrebird کر دیا ہے، اس لیے نیا package اس کے بجائے /usr/bin/lyrebird انسٹال کر سکتا ہے۔ اس command سے جو path ظاہر ہو، وہی استعمال کریں۔

/etc/tor/torrc میں bridge configure کریں

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

ان میں سے ہر لائن کے ساتھ ایک failure وابستہ ہے، اس لیے انہیں ایک ایک کرکے دیکھیں۔

BridgeRelay 1، tor کو ہدایت دیتا ہے کہ اپنا descriptor public consensus کے بجائے bridge authority کو بھیجے۔ یہی واحد لائن relay کو unlisted بناتی ہے۔

ORPort اصل Tor port ہے۔ یہ internet سے قابل رسائی ہونا چاہیے، کیونکہ tor اس کی جانچ کرتا ہے اور یہ test کامیاب ہونے تک descriptor publish نہیں کرتا۔

ServerTransportPlugin، tor کو چلانے والی command فراہم کرتا ہے۔ tor، obfs4proxy کو child process کے طور پر شروع کرتا ہے اور pipe کے ذریعے اس سے رابطہ کرتا ہے۔ اس لیے obfs4proxy کی اپنی service unit نہیں ہوتی اور یہ systemctl status میں بھی ظاہر نہیں ہوتا۔

ServerTransportListenAddr اس port کو مقرر کرتا ہے جس پر obfs4proxy listening کرتا ہے۔ اگر یہ لائن شامل نہ ہو تو obfs4proxy startup کے وقت ایک free port منتخب کرتا ہے، اور زیادہ تر restarts کے بعد مختلف port منتخب کرتا ہے۔ اس طرح آپ کی پہلے سے فراہم کردہ ہر bridge line ایسے port کی طرف اشارہ کرتی ہے جہاں کوئی چیز listening نہیں کر رہی ہوتی۔ ان clients کو connection refused ملتا ہے اور وہ دوبارہ کوشش کرنا بند کر دیتے ہیں۔

ExtORPort auto extended ORPort کھولتا ہے۔ یہ loopback channel ہے جسے obfs4proxy مکمل شدہ connections کو client کے address کے ساتھ واپس tor تک پہنچانے کے لیے استعمال کرتا ہے۔ Tor Project کی setup guide اسے ہر bridge میں شامل کرتی ہے، کیونکہ اس کے بغیر transport یہ address tor کو report نہیں کر سکتا۔

ContactInfo اور Nickname دونوں public ہیں۔ ایسا address استعمال کریں جس کے messages آپ پڑھتے ہوں، کیونکہ Tor Project broken bridge کے بارے میں آپ سے اسی ذریعے سے رابطہ کرتا ہے۔ اگر آپ اپنی شناخت ظاہر نہیں کرنا چاہتے تو ایسا nickname منتخب کریں جس سے آپ کی شناخت نہ ہو۔

BridgeDistribution یہ منتخب کرتا ہے کہ کون سا distributor آپ کا address users کو فراہم کرے گا۔ قابل قبول values https، email، telegram، settings، none اور any ہیں۔ پہلے bridge کے لیے any استعمال کریں اور system کو فیصلہ کرنے دیں۔ ایسے private bridge کے لیے none استعمال کریں جسے آپ خود فراہم کرتے ہیں۔ اس سے address مکمل طور پر public distribution سے باہر رہتا ہے۔

پورٹ کا انتخاب کیوں اہم ہے

دونوں ports کے لیے 9001 استعمال نہ کریں۔ Tor Project اس کی براہِ راست ہدایت دیتا ہے، کیونکہ 9001 روایتی ORPort ہے اور سنسر اسے تلاش کرنے کے لیے internet scan کرتے ہیں۔ دونوں ports ایک دوسرے سے مختلف بھی ہونے چاہییں، کیونکہ tor اور obfs4proxy اپنی اپنی listener bind کرتے ہیں۔

obfs4 کے لیے سب سے مضبوط port 443 ہے۔ تقریباً ہر restricted network میں outbound 443 کھلا ہوتا ہے، اور اس سے قائم رہنے والا connection عام web session جیسا دکھائی دیتا ہے۔ 1024 سے کم port پر bind کرنے کے لیے ایک اضافی مرحلہ درکار ہے، کیونکہ obfs4proxy root کے طور پر نہیں چلتا:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

ہر کھلنے والے editor میں یہ دو lines شامل کریں:

[Service]
NoNewPrivileges=no

صرف capability کافی نہیں ہے۔ systemd کا NoNewPrivileges کسی process کو وہ privilege حاصل کرنے سے روکتا ہے جو اس کے parent کے پاس نہیں تھا، اور file capability بھی عین یہی ہے۔ اس لیے setting فعال رہنے کی صورت میں obfs4proxy 443 پر bind نہیں کر پاتا۔

اگر آپ یہ مرحلہ چھوڑنا چاہتے ہیں تو کوئی غیر نمایاں high port منتخب کریں اور اسے لکھ کر محفوظ رکھیں۔ آپ جو بھی port منتخب کریں، بعد میں obfs4 port تبدیل نہ کریں۔ Bridge line address، port، fingerprint اور certificate کو ایک ساتھ مقرر کرتی ہے۔ اس لیے صارف کے browser میں پہلے سے موجود ہر copy port تبدیل ہوتے ہی کام کرنا بند کر دیتی ہے۔

دونوں firewalls پر ports کھولیں

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

دونوں ports کھلے ہونے چاہییں، اور زیادہ تر providers اپنے control panel میں ایک دوسرا firewall چلاتے ہیں جس کے بارے میں ufw کو کچھ معلوم نہیں ہوتا۔ اگر rule server پر موجود ہو لیکن control panel میں موجود نہ ہو تو bridge قابلِ رسائی نہیں رہتا اور descriptor بھی publish نہیں کرتا۔ اگر ان میں سے کوئی بھی موضوع نیا ہے تو وہ ufw rules جو ایک نئے VPS کے لیے ضروری ہیں اور Linux میں listening port کا اصل مطلب اس کی وضاحت کرتے ہیں۔ اسی دوران keys کے ذریعے SSH کو lock down کریں اور hardened sshd config استعمال کریں۔ password SSH والے server پر unlisted bridge موجود ہو، تب بھی وہ password SSH والا server ہی رہتا ہے۔

اسے شروع کریں، پھر لاگ پڑھیں

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian اور Ubuntu دو units فراہم کرتے ہیں۔ tor.service ایک مختصر wrapper ہے، جبکہ tor@default.service وہ process ہے جو اصل کام کرتا ہے۔ اسی لیے journalctl -u tor تقریباً خالی دکھائی دیتا ہے، جبکہ مطلوبہ لاگ tor@default کے تحت موجود ہوتا ہے۔

دو سطریں بتاتی ہیں کہ یہ کامیاب رہا:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

پہلی سطر کا مطلب ہے کہ قابلِ رسائی ہونے کا ٹیسٹ کامیاب رہا اور descriptor bridge authority کو بھیج دیا گیا۔ اگر یہ سطر کبھی ظاہر نہ ہو تو internet اور آپ کے server کے درمیان کوئی چیز ORPort تک network traffic کو روک رہی ہے۔ دوسری سطر میں وہی port دکھائی دینا چاہیے جو آپ نے configure کیا ہے۔ وہاں مختلف port کا مطلب ہے کہ tor نے ServerTransportListenAddr نافذ نہیں کیا۔ اس کی عام وجہ transport name کا عدم مطابقت ہونا ہے: دونوں directives میں یہ obfs4 ہی پڑھا جانا چاہیے۔

تصدیق کریں کہ دونوں listeners موجود ہیں:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

میری bridge line کہاں ہے؟

obfs4proxy، tor کی data directory میں ایک template لکھتا ہے:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

یہ directory tor user کی ملکیت ہے اور اس کا mode 700 ہے، اس لیے sudo کے بغیر آپ کو Permission denied ملتا ہے۔ اس file میں درج ذیل ساخت کی ایک line ہوتی ہے:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

<IP ADDRESS> کو اپنے server کے public address، <PORT> کو ORPort کے بجائے obfs4 port، اور <FINGERPRINT> کو اس identity fingerprint سے تبدیل کریں جو tor نے اپنی data directory میں لکھا ہے:

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

پہلی file میں آپ کا nickname اور وہ identity fingerprint ہوتا ہے جو bridge line میں شامل ہونا چاہیے۔ دوسری file میں hashed fingerprint ہوتا ہے۔ آپ اسے Relay Search میں paste کر کے دیکھ سکتے ہیں کہ آپ کا bridge چل رہا ہے یا نہیں، اور تقریباً کتنے clients اس تک پہنچ رہے ہیں۔ دونوں ایک دوسرے کے متبادل نہیں ہیں۔ hashed value رکھنے والی bridge line اس identity key سے match نہیں کرتی جو آپ کا bridge پیش کرتا ہے، اس لیے client کھولا گیا connection مسترد کر دیتا ہے۔

پل حقیقت میں صارفین تک کیسے پہنچتا ہے؟

آپ اپنی bridge line کسی کو براہ راست نہیں دیتے۔ descriptor کے bridge authority تک پہنچنے کے بعد distribution system (rdsys، جو BridgeDB کا جانشین ہے) آپ کے bridge کو ایک distributor کے حوالے کرتا ہے، اور صارفین اسی distributor سے bridges طلب کرتے ہیں۔ August 2026 تک راستے یہ ہیں:

• bridges.torproject.org/options پر web form، جو captcha کے بعد bridge lines فراہم کرتا ہے۔
• Gmail یا Riseup address سے bridges@torproject.org پر email، جس کے جواب میں bridge lines موصول ہوتی ہیں۔ provider کی یہ پابندی اس لیے ہے کہ unlimited free accounts کے ذریعے کوئی بھی censor ہر bridge کی فہرست حاصل نہ کر سکے۔
• Telegram bot @GetBridgesBot۔ /start بھیجیں، پھر /obfs4 یا /webtunnel بھیجیں۔
• خود Tor Browser میں Settings، پھر Connection کے تحت "Request bridges" منتخب کریں۔ اس سے moat channel کے ذریعے bridges حاصل ہوتے ہیں۔

نیا bridge setup مکمل ہونے کے تقریباً 3 گھنٹے بعد Relay Search میں ظاہر ہوتا ہے۔ صارفین کو شامل ہونے میں کہیں زیادہ وقت لگتا ہے۔ Tor Project کے اپنے الفاظ میں، "It can take several days or weeks until you see a consistent set of users." ابتدائی 2 ہفتوں تک کم استعمال معمول کی بات ہے، یہ خرابی کی علامت نہیں۔

BridgeDistribution none مقرر کرنے سے آپ ان تمام ذرائع سے opt out ہو جاتے ہیں۔ اس کے بعد bridge line ان لوگوں کو بھیجنا آپ کی ذمہ داری ہے جنہیں اس کی ضرورت ہے، ایسے channel کے ذریعے جسے censor monitor نہ کر رہا ہو۔

جب کچھ کام نہ کرے

لاگ میں self-testing لائن موجود نہیں۔ ORPort قابل رسائی نہیں ہے۔ کسی دوسری مشین سے nc -vz your.ip 8443 کے ذریعے اس کی جانچ کریں۔ اگر کنکشن معطل رہے تو پیکٹس drop ہو رہے ہیں، اس لیے ufw اور provider کے panel کو چیک کریں۔ اگر connection refused ملے تو tor کسی port پر listening نہیں کر رہا، اس لیے ss -lntp چیک کریں اور configuration error کے لیے لاگ پڑھیں۔

رجسٹرڈ transport میں وہ port دکھائی دے رہا ہے جسے آپ نے منتخب نہیں کیا۔ tor نے ServerTransportListenAddr کو نظر انداز کر دیا۔ transport name کا ServerTransportPlugin میں موجود نام سے عین مطابق match ہونا ضروری ہے، اور دونوں کا obfs4 ہونا بھی ضروری ہے۔

obfs4proxy port 443 پر bind نہیں ہو رہا۔ getcap /usr/bin/obfs4proxy کے ذریعے capability کی تصدیق کریں، پھر systemctl show tor@default -p NoNewPrivileges کے ذریعے تصدیق کریں کہ override unit تک پہنچا ہے۔ اگر اس کا output NoNewPrivileges=yes ہو تو آپ کا drop-in ایسی unit میں گیا ہے جو چل نہیں رہی۔

/var/lib/tor/pt_state/ کے اندر کچھ موجود نہیں۔ tor نے transport شروع نہیں کیا، جس کا مطلب ہے کہ ServerTransportPlugin میں دیا گیا path غلط ہے۔ اس کا موازنہ command -v obfs4proxy کے output سے کریں۔

تبدیلی کے بعد clients نے connect کرنا بند کر دیا۔ address یا obfs4 port میں کی گئی کوئی بھی تبدیلی پہلے سے تقسیم کی گئی تمام bridge lines کو invalid کر دیتی ہے۔ یہ بھی چیک کریں کہ آیا server کا public IP تبدیل ہوا ہے، کیونکہ بعض providers کے ساتھ rebuild کے دوران ایسا ہوتا ہے۔

tor بالکل start نہیں ہو رہا۔ sudo -u debian-tor tor --verify-config -f /etc/tor/torrc چلائیں۔ یہ file کو parse کرتا ہے، جس line پر اسے اعتراض ہو اسے print کرتا ہے، اور چلتی ہوئی service کو تبدیل نہیں کرتا۔

FAQ

کیا میرا VPS provider Tor bridge کے بارے میں شکایت کرے گا؟

bridge ایک entry point ہوتا ہے، اس لیے آپ کے server سے باہر جانے والا network traffic دوسرے Tor relays تک جاتا ہے، نہ کہ صارف کی منتخب کردہ کسی site تک۔ آپ کا IP address کسی کی web log میں request کے source کے طور پر ظاہر نہیں ہوتا، اور یہی وہ چیز ہے جس کی وجہ سے exit relay operators کو شکایات کا سامنا کرنا پڑتا ہے۔ Hosting rules پھر بھی مختلف ہوتے ہیں، اور بعض providers ہر Tor service کو special case سمجھتے ہیں؛ اس لیے شروع کرنے سے پہلے acceptable use policy پڑھیں اور جس address کو پڑھیں اسے ContactInfo میں درج کریں۔

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

شائع شدہ minimum upload اور download دونوں کے لیے 1 Mbit/s ہے، جبکہ guard یا middle relay کے لیے یہ 10 Mbit/s ہے۔ حقیقی استعمال تقریباً صفر سے شروع ہوتا ہے، کیونکہ آپ کا bridge صرف ان users کے لیے traffic منتقل کرتا ہے جنہیں distributor اس تک بھیجتا ہے۔ اگر آپ مقررہ maximum لگانا چاہتے ہیں تو torrc میں RelayBandwidthRate اور RelayBandwidthBurst set کریں۔

میرے نئے bridge سے کسی نے connection کیوں نہیں کیا؟

bridge کو Relay Search میں ظاہر ہونے میں تقریباً تین گھنٹے لگتے ہیں، اور Tor Project کی guidance کے مطابق users کا مستقل مجموعہ بننے میں کئی دن یا ہفتے لگ سکتے ہیں۔ تصدیق کریں کہ descriptor publish ہو چکا ہے، جو journalctl -u tor@default میں self-testing line ہے، Relay Search میں اپنا hashed fingerprint تلاش کریں، اور تصدیق کریں کہ BridgeDistribution کو none پر set نہیں کیا گیا۔

کیا مجھے obfs4 یا WebTunnel چلانا چاہیے؟

اگر یہ آپ کا پہلا bridge ہے تو obfs4 چلائیں: ایک VPS، دو ports، کوئی domain نہیں، اور کوئی certificate نہیں۔ WebTunnel وہاں چلائیں جہاں بظاہر random traffic بھی block کیا جاتا ہو، کیونکہ اسے آپ کے زیرِ انتظام domain، حقیقی web server، درست TLS certificate، اور کم از کم 1 GB RAM درکار ہوتی ہے۔ اگر آپ دونوں چلاتے ہیں تو انہیں الگ addresses پر رکھیں، کیونکہ بصورتِ دیگر ایک IP block ہونے سے بیک وقت دونوں bridges ختم ہو جائیں گے۔

اگر میں بعد میں obfs4 port تبدیل کر دوں تو کیا ہوگا؟

پہلے سے تقسیم کی گئی ہر bridge line کام کرنا بند کر دے گی۔ bridge line address، port، fingerprint اور certificate کو ایک ساتھ مقرر کرتی ہے، اس لیے پرانی line رکھنے والا client ایسے port سے connection کھولے گا جہاں کوئی service listening نہیں کر رہی، اور پھر کوشش ترک کر دے گا۔ یہی بات اس وقت بھی لاگو ہوتی ہے جب server کا public IP تبدیل ہو جائے۔ Setup کے دوران port منتخب کریں اور اسے تبدیل نہ کریں۔