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

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

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

Unlisted 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 کو کسی اور format میں wrap کرتا ہے، اور آپ کا bridge اسے unwrap کر دیتا ہے۔

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

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

• obfs4 کے لیے ایک VPS، دو TCP ports اور کسی domain name کی ضرورت نہیں ہوتی۔ یہ ایسا مفید setup ہے جسے چلانا سب سے آسان ہے، اور یہی اس 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 ایک مختلف نوعیت کی contribution ہے۔ Volunteers مختصر مدت کے لیے WebRTC proxies چلاتے ہیں، اس لیے entry points مسلسل تبدیل ہوتے رہتے ہیں اور censor کے لیے block کرنے کو کوئی مستقل address موجود نہیں ہوتا۔ اس کے لیے آپ bridge operate نہیں کرتے۔ آپ proxy چلاتے ہیں، اور اسے کسی fixed address کی ضرورت نہیں ہوتی۔

obfs4 سے شروع کریں۔ بعد میں دوسرے address پر WebTunnel bridge شامل کیا جا سکتا ہے۔ ایک ہی IP پر دونوں چلانے سے ایک blocked address دونوں services کو بند کر دیتا ہے۔

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
  }
]

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

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

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

Uptime رفتار سے زیادہ اہم ہے۔ relay requirements میں کہا گیا ہے کہ "اگر آپ کا relay روزانہ 2 گھنٹے سے زیادہ بند رہے تو اس کی افادیت محدود ہو جاتی ہے"، اور اس معاملے میں 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 انسٹال کر سکتا ہے۔ وہی path استعمال کریں جو یہ command دکھائے۔

/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 کو فہرست میں شامل ہونے سے روکتی ہے۔

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

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

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

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

ContactInfo اور Nickname دونوں public ہیں۔ ایسا address استعمال کریں جس کے پیغامات آپ پڑھتے ہوں، کیونکہ 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 ہے اور censoring ادارے اسے تلاش کرنے کے لیے 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 عین ایسا ہی privilege ہے۔ اس لیے setting فعال رہنے کی صورت میں obfs4proxy، 443 پر bind نہیں کر پاتا۔

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

دونوں فائر والز پر ports کھولیں

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

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

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

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 تقریباً خالی دکھائی دیتا ہے، جبکہ مطلوبہ log tor@default کے تحت موجود ہوتا ہے۔

دو lines سے معلوم ہوتا ہے کہ یہ کامیاب رہا:

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

پہلی line کا مطلب ہے کہ reachability test کامیاب رہا اور descriptor bridge authority کو بھیج دیا گیا۔ اگر یہ کبھی ظاہر نہ ہو تو internet اور آپ کے server کے درمیان کوئی چیز ORPort کی طرف جانے والا traffic روک رہی ہے۔ دوسری line میں وہی port دکھائی دینا چاہیے جسے آپ نے configure کیا ہے۔ اگر وہاں مختلف port ہو تو tor نے ServerTransportListenAddr apply نہیں کیا۔ اس کی عام وجہ 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، آپ کے bridge کی پیش کردہ identity key سے match نہیں ہوتی، اس لیے client ابھی کھولا گیا connection مسترد کر دیتا ہے۔

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

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

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

نیا پل setup کے تقریباً تین گھنٹے بعد Relay Search میں دکھائی دیتا ہے۔ صارفین کو نمایاں ہونے میں اس سے کہیں زیادہ وقت لگتا ہے: Tor Project کے اپنے الفاظ میں، "مسلسل صارفین کا مجموعہ دکھائی دینے میں کئی دن یا ہفتے لگ سکتے ہیں۔" پہلے دو ہفتوں میں کم سرگرمی معمول ہے، خرابی نہیں۔

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

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

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

رجسٹر شدہ transport میں وہ port دکھائی دے رہا ہے جو آپ نے منتخب نہیں کیا تھا۔ tor نے ServerTransportListenAddr کو نظر انداز کر دیا۔ transport کا نام ServerTransportPlugin میں موجود نام سے عین مطابق ہونا چاہیے، اور دونوں 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 کو غیر مؤثر کر دیتی ہے۔ یہ بھی چیک کریں کہ server کا public IP تبدیل تو نہیں ہوا؛ کچھ providers کے ساتھ rebuild کے بعد ایسا ہوتا ہے۔

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

FAQ

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

Bridge ایک entry point ہے، اس لیے آپ کے server سے باہر جانے والا 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 upstream اور downstream دونوں کے لیے 1 Mbit/s ہے، جبکہ guard یا middle relay کے لیے یہ 10 Mbit/s ہے۔ حقیقی استعمال تقریباً صفر سے شروع ہوتا ہے، کیونکہ آپ کا bridge صرف ان users کا traffic منتقل کرتا ہے جنہیں distributor اس تک بھیجتا ہے۔ اگر آپ سخت حد مقرر کرنا چاہتے ہیں تو torrc میں RelayBandwidthRate اور RelayBandwidthBurst set کریں۔

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

کسی bridge کو Relay Search میں ظاہر ہونے میں تقریباً تین گھنٹے لگتے ہیں، اور Tor Project کی guidance کے مطابق users کا مستقل set بننے میں کئی دن یا ہفتے لگتے ہیں۔ تصدیق کریں کہ 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 اس وقت چلائیں جب عام web traffic جیسا دکھائی دینے والا traffic بھی block کیا جاتا ہو، کیونکہ اسے آپ کے control میں ایک domain، ایک حقیقی web server، ایک valid TLS certificate، اور کم از کم 1 GB RAM درکار ہوتی ہے۔ اگر آپ دونوں چلاتے ہیں تو انہیں الگ addresses پر رکھیں، کیونکہ بصورت دیگر ایک blocked IP بیک وقت دونوں bridges کو غیر فعال کر دے گا۔

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

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