راه اندازی Tor Bridge با obfs4 روی VPS

پل Tor چیست و چرا وجود دارد

پل Tor یک نقطهٔ ورود به شبکهٔ Tor است که آدرس آن در لیست عمومی رله‌ها منتشر نمی‌شود. آن لیست که consensus نامیده می‌شود، سندی امضاشده است که هر کسی می‌تواند آن را دانلود کند؛ سانسورچی‌ها نیز همین کار را می‌کنند. مسدود کردن Tor از طریق این لیست تنها یک بعدازظهر زمان می‌برد: دریافت consensus و سپس مسدود کردن تمام آدرس‌های موجود در آن در سطح مرز شبکه. پل‌ها به این دلیل وجود دارند که لیست منتشرشده، نقطهٔ ضعف شبکه است. آدرس‌های پل‌ها به‌صورت محدود و در هر نوبت به تعداد کمی ارائه می‌شوند، بنابراین هیچ درخواست واحدی نمی‌تواند کل مجموعه را لو بدهد.

داشتن یک آدرس ثبت‌نشده تنها نیمی از راه حل است. بازرسی عمیق بسته (DPI) که ترافیک را بر اساس محتوا و نه آدرس طبقه‌بندی می‌کند، اتصال Tor را از روی الگوی handshake پروتکل TLS (امنیت لایه انتقال) تشخیص می‌دهد. سانسورچی بدون داشتن لیست هم می‌تواند تشخیص دهد که «این شبیه به Tor است» و اتصال را قطع کند. یک pluggable transport این سیگنال را حذف می‌کند. این ابزار جریان دادهٔ Tor را در سمت کلاینت در قالب دیگری بسته‌بندی می‌کند و پل شما آن را باز می‌کند.

obfs4 پروتکل انتقالی است که اکثر پل‌ها از آن استفاده می‌کنند. این پروتکل جریان داده را به بایت‌هایی بدون هدر و بدون handshake ثابت تبدیل می‌کند، بنابراین DPI هیچ الگوی مشخصی برای تطبیق پیدا نمی‌کند. این پروتکل همچنین کلاینت را احراز هویت می‌کند. مقدار cert= در خط تنظیمات پل، کلیدی است که کلاینت باید پیش از دریافت هرگونه پاسخ از پل، مالکیت آن را اثبات کند. این ویژگی مانع از کاوش فعال (active probing) می‌شود: سانسورچی که به آدرس شما متصل می‌شود تا بررسی کند آیا آن آدرس با پروتکل Tor صحبت می‌کند یا خیر، هیچ پاسخی دریافت نمی‌کند و چیزی دستگیرش نمی‌شود.

کدام pluggable transport را باید اجرا کنید؟

• obfs4 به یک VPS، دو پورت TCP و هیچ نام دامنه‌ای نیاز ندارد. این ساده‌ترین ابزار کاربردی است که می‌توانید اجرا کنید و موضوع این راهنما نیز همین است.
• WebTunnel اتصال را در ترافیک عادی HTTPS به یک وب‌سایت واقعی پنهان می‌کند. پروژه Tor نیازمندی‌های آن را شامل یک آدرس IPv4 ثابت، دامنه‌ای که تحت کنترل شماست، یک وب‌سرور فعال مانند NGINX یا Apache، یک گواهی TLS معتبر، و حداقل 1 GB رم (با پیشنهاد 4 GB) اعلام کرده است. این ابزار برای شبکه‌هایی مناسب است که در آن‌ها ترافیک با ظاهر تصادفی، خود مشکوک تلقی می‌شود؛ زیرا کشوری که دسترسی به چیزی فراتر از وب‌گردی را محدود کرده، همچنان HTTPS را مجاز می‌شمارد.
• Snowflake نوع متفاوتی از مشارکت است. داوطلبان پروکسی‌های WebRTC کوتاه‌مدت اجرا می‌کنند، بنابراین نقاط ورود دائماً تغییر می‌کنند و هیچ آدرس پایداری برای مسدودسازی توسط سانسورچی وجود ندارد. شما برای این مورد یک bridge را مدیریت نمی‌کنید. شما یک پروکسی اجرا می‌کنید که به هیچ آدرس ثابتی نیاز ندارد.

با obfs4 شروع کنید. می‌توانید بعداً یک bridge از نوع WebTunnel روی آدرس دوم اضافه کنید: اجرای هر دو روی یک IP به این معناست که با مسدود شدن یک آدرس، هر دو از دسترس خارج می‌شوند.

هزینهٔ اجرای یک 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 از یک bridge حداقل 1 مگابیت بر ثانیه پهنای باند آپ‌استریم و داون‌استریم درخواست می‌کند. برای یک guard یا middle relay، حداقل 10 مگابیت بر ثانیه درخواست شده و 16 مگابیت بر ثانیه توصیه می‌شود. این‌ها الزامات اعلام‌شده هستند، نه اندازه‌گیری‌های واقعی. یک bridge جدید معمولاً تا هفته‌ها بسیار کمتر از حداقلِ خود فعالیت می‌کند. همان صفحهٔ الزامات، برای یک relay حداقل 100 گیگابایت ترافیک خروجی در ماه را درخواست می‌کند که کوچک‌ترین پلن‌های سرور مجازی نیز آن را پوشش می‌دهند؛ بنابراین پیش از انتخاب هر گزینهٔ بزرگ‌تری، هزینهٔ واقعی یک VPS کوچک در ماه را مطالعه کنید.

سطح سوءاستفاده (abuse) کوچک است و این بخشی است که افراد در مورد آن دچار اشتباه می‌شوند. یک bridge اولین گام (hop) است. ترافیکی که از سرور شما خارج می‌شود به یک relay دیگر در شبکه Tor می‌رود و هرگز مستقیماً به وب‌سایتی که کاربر انتخاب کرده ارسال نمی‌شود. آدرس IP شما هرگز در لاگ وب‌سایت‌های دیگر به عنوان منبع درخواست ظاهر نمی‌شود، بنابراین ایمیل‌های شکایتی که اپراتورهای exit relay دریافت می‌کنند، به اینجا نمی‌رسد. با این حال، سیاست استفادهٔ قابل‌قبول (AUP) ارائه‌دهندهٔ خود را بررسی کنید، زیرا برخی میزبان‌ها با هر نوع سرویس Tor به عنوان یک مورد خاص برخورد می‌کنند.

یک کار را انجام ندهید: یک relay عمومی موجود را به یک bridge در همان آدرس تبدیل نکنید. توصیهٔ پروژه Tor برای این مورد، تغییر «آدرس IP، نام و اثر انگشت (fingerprint)» است، زیرا آدرس قدیمی قبلاً در consensus قرار گرفته که سانسورچی‌ها آن را دانلود می‌کنند. bridgeای که تا هفتهٔ گذشته یک relay عمومی بوده، bridgeای است که از قبل در لیست مسدودشده‌ها قرار دارد.

پایداری (uptime) اهمیت بیشتری نسبت به سرعت دارد. الزامات relay می‌گوید که «اگر relay شما بیش از 2 ساعت در روز در دسترس نباشد، کارایی آن محدود است» و وضعیت یک bridge در اینجا حتی از relay بدتر است، زیرا هر کلاینت فقط یک آدرس دارد و هیچ جایگزینی برای آن وجود ندارد. یک راه‌اندازی مجدد (restart)، تمام کاربران متصل به آن را قطع می‌کند. برای اینکه روزی که سرویس پاسخ‌دهی را متوقف می‌کند مطلع شوید، یک بررسی پورت TCP در Uptime Kuma برای پورت obfs4 تنظیم کنید.

نصب Tor از مخزن Tor Project

بسته‌های توزیع‌شده در مخازن رسمی معمولاً قدیمی هستند و یک bridge نرم‌افزاری امنیتی است که باید به‌روز باشد. ابتدا مخزن اختصاصی پروژه را اضافه کنید.

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

sudo apt install apt-transport-https
echo "deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/tor.list
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/tor-archive-keyring.gpg >/dev/null
sudo apt update

اکنون فایل منبع را بنویسید. خط Suites: باید حاوی نام رمز (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: $(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

. /etc/os-release
echo "deb [signed-by=/usr/share/keyrings/tor-archive-keyring.gpg] https://deb.torproject.org/torproject.org $VERSION_CODENAME main" | sudo tee /etc/apt/sources.list.d/tor.list

اگر apt update گزارش داد که مخزن فاقد فایل Release برای نام رمز سیستم شماست، یعنی Tor Project آن نسخه را پشتیبانی نمی‌کند. فایل /etc/apt/sources.list.d/tor.sources را حذف کنید، sudo apt update را دوباره اجرا کنید و بسته tor موجود در مخازن توزیع خود را نصب کنید. تمام مراحل زیر یکسان است.

بسته obfs4proxy مستقیماً توسط Debian و Ubuntu ارائه می‌شود (نسخه 0.0.14 در Debian 13، تا آگوست 2026). بررسی کنید که فایل اجرایی در کجا قرار گرفته است، زیرا مسیر آن در فایل پیکربندی وارد می‌شود:

command -v obfs4proxy || command -v lyrebird

which obfs4proxy

توسعه‌دهندگان نام پروژه را به lyrebird تغییر داده‌اند، بنابراین ممکن است در نسخه‌های جدیدتر، بسته /usr/bin/lyrebird نصب شود. از هر مسیری که دستور فوق نمایش می‌دهد استفاده کنید.

پیکربندی bridge در /etc/tor/torrc

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

هر یک از این خطوط ممکن است باعث بروز خطا شوند، بنابراین آن‌ها را یکی‌یکی بررسی کنید.

BridgeRelay 1 به tor دستور می‌دهد که descriptor خود را به‌جای اجماع عمومی (public consensus)، به bridge authority ارسال کند. همین یک خط باعث می‌شود relay در لیست عمومی قرار نگیرد.

ORPort پورت اصلی Tor است. این پورت باید از طریق اینترنت قابل‌دسترسی باشد، زیرا tor آن را تست می‌کند و تا زمانی که این تست با موفقیت انجام نشود، از انتشار descriptor خودداری می‌کند.

ServerTransportPlugin دستور اجرایی را به tor می‌دهد. tor برنامه obfs4proxy را به‌عنوان یک child process اجرا کرده و از طریق یک pipe با آن ارتباط برقرار می‌کند؛ بنابراین obfs4proxy واحد سرویس (service unit) مستقلی ندارد و هرگز در systemctl status دیده نمی‌شود.

ServerTransportListenAddr پورتی را که obfs4proxy روی آن گوش می‌دهد، تعیین می‌کند. اگر این خط را حذف کنید، obfs4proxy در هر بار راه‌اندازی یک پورت آزاد را انتخاب می‌کند که پس از اکثر ری‌استارت‌ها تغییر می‌یابد؛ در نتیجه هر خط bridge که قبلاً به کاربران داده‌اید به پورتی اشاره می‌کند که هیچ سرویسی روی آن گوش نمی‌دهد. در این حالت، اتصال کلاینت‌ها رد می‌شود و آن‌ها تلاش برای اتصال را متوقف می‌کنند.

ExtORPort auto پورت extended ORPort را باز می‌کند؛ یک کانال loopback که obfs4proxy از آن برای تحویل اتصالات تکمیل‌شده به tor، همراه با آدرس کلاینت، استفاده می‌کند. راهنمای راه‌اندازی Tor Project این مورد را برای همه bridgeها توصیه می‌کند، زیرا بدون آن، transport نمی‌تواند آدرس کلاینت را به tor گزارش دهد.

ContactInfo و Nickname هر دو عمومی هستند. از آدرسی استفاده کنید که به آن دسترسی دارید، زیرا Tor Project از این طریق در صورت خرابی bridge با شما تماس می‌گیرد. همچنین نام مستعاری انتخاب کنید که اگر مایل به ناشناس ماندن هستید، هویت شما را فاش نکند.

BridgeDistribution تعیین می‌کند که کدام توزیع‌کننده (distributor) آدرس شما را به کاربران ارائه دهد. مقادیر پذیرفته‌شده عبارتند از https، email، telegram، settings، none و any. برای اولین bridge خود از any استفاده کنید و اجازه دهید سیستم تصمیم بگیرد. برای bridge خصوصی که خودتان آن را توزیع می‌کنید از none استفاده کنید؛ این کار باعث می‌شود آدرس شما به‌طور کامل از توزیع عمومی خارج بماند.

چرا انتخاب پورت اهمیت دارد

از انتخاب پورت 9001 برای هر دو مورد خودداری کنید. پروژه Tor مستقیماً بر این موضوع تأکید دارد، زیرا 9001 پورت سنتی ORPort است و سانسورچی‌ها اینترنت را برای یافتن آن اسکن می‌کنند. این دو پورت باید با یکدیگر متفاوت باشند، زیرا tor و obfs4proxy هر کدام listener اختصاصی خود را bind می‌کنند.

بهترین پورت برای obfs4، پورت 443 است. ترافیک خروجی 443 تقریباً در تمام شبکه‌های محدود باز است و یک اتصال طولانی‌مدت به آن، شبیه به یک نشست وب معمولی به نظر می‌رسد. bind کردن روی پورت‌های زیر 1024 به یک گام اضافی نیاز دارد، زیرا obfs4proxy با دسترسی root اجرا نمی‌شود:

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

این دو خط را در هر ویرایشگری که باز می‌شود، اضافه کنید:

[Service]
NoNewPrivileges=no

قابلیت (capability) به تنهایی کافی نیست. تنظیم NoNewPrivileges در systemd مانع از آن می‌شود که یک پردازش، امتیازی فراتر از امتیاز والد خود کسب کند، و یک file capability دقیقاً همین وضعیت را دارد؛ بنابراین تا زمانی که این تنظیم فعال باشد، obfs4proxy در bind کردن پورت 443 شکست می‌خورد.

اگر ترجیح می‌دهید از این مرحله صرف‌نظر کنید، یک پورت بالا و غیرمعمول انتخاب کرده و آن را یادداشت کنید. هر چه انتخاب می‌کنید، پورت obfs4 را بعداً تغییر ندهید. یک خط bridge، آدرس، پورت، اثر انگشت (fingerprint) و گواهی را به هم پیوند می‌دهد؛ بنابراین به محض تغییر پورت، تمام نسخه‌هایی که از قبل در مرورگر کاربران ذخیره شده‌اند، از کار می‌افتند.

باز کردن پورت‌ها در هر دو فایروال

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

هر دو پورت باید باز باشند؛ اکثر ارائه‌دهندگان سرویس، یک فایروال دوم در پنل مدیریتی خود دارند که ufw از آن بی‌اطلاع است. قانونی که روی سرور تعریف شده اما در پنل اعمال نشده باشد، منجر به ایجاد یک پل ارتباطی می‌شود که هرگز در دسترس نخواهد بود و هیچ توصیف‌گری را منتشر نمی‌کند. اگر هر یک از این دو بخش برای شما تازگی دارد، قوانین ufw مورد نیاز برای یک VPS تازه و مفهوم واقعی پورت listening در لینوکس را مطالعه کنید. در همان حین، دسترسی SSH را با استفاده از کلید و پیکربندی سخت‌گیرانه sshd محدود کنید. یک پل ارتباطی ثبت‌نشده روی سروری که از رمز عبور برای SSH استفاده می‌کند، همچنان یک سرور با دسترسی SSH مبتنی بر رمز عبور باقی می‌ماند.

آن را اجرا کرده و لاگ را بخوانید

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

توزیع‌های Debian و Ubuntu دو unit ارائه می‌دهند. tor.service یک wrapper کوچک است و tor@default.service فرآیندی است که کار اصلی را انجام می‌دهد؛ به همین دلیل است که 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 ارسال شده است. اگر این خط ظاهر نشد، یعنی چیزی بین اینترنت و سرور شما ترافیک ورودی به ORPort را مسدود می‌کند. خط دوم باید پورتی که پیکربندی کرده‌اید را نشان دهد. اگر پورت متفاوتی در آنجا مشاهده می‌کنید، یعنی tor دستور ServerTransportListenAddr را اعمال نکرده است؛ دلیل معمول این اتفاق، عدم تطابق نام transport است: این نام باید در هر دو دستور به صورت obfs4 نوشته شود.

تأیید کنید که هر دو listener فعال هستند:

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

خط bridge من کجاست؟

برنامه obfs4proxy یک الگو در دایرکتوری داده‌های tor می‌نویسد:

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

آن دایرکتوری متعلق به کاربر tor است و دسترسی آن روی 700 تنظیم شده است، بنابراین بدون sudo با خطای Permission denied مواجه می‌شوید. این فایل شامل خطی با این ساختار است:

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

عبارت <IP ADDRESS> را با آدرس عمومی سرور خود، <PORT> را با پورت obfs4 (نه ORPort) و <FINGERPRINT> را با اثر انگشت (fingerprint) هویتی که tor در دایرکتوری داده‌های خود نوشته است، جایگزین کنید:

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

فایل اول شامل نام مستعار و اثر انگشت هویتی است که باید در خط bridge قرار گیرد. فایل دوم شامل اثر انگشت هش‌شده است که آن را در Relay Search وارد می‌کنید تا ببینید آیا bridge شما در حال اجراست و تقریباً چند کلاینت به آن متصل می‌شوند. این دو مورد قابل جایگزینی با یکدیگر نیستند. خط bridgeای که حاوی مقدار هش‌شده باشد با کلید هویتی که bridge شما ارائه می‌دهد مطابقت ندارد، بنابراین کلاینت اتصالی را که به‌تازگی برقرار کرده است، رد می‌کند.

یک پل (bridge) چگونه واقعاً به دست کاربران می‌رسد؟

شما نباید خط پل (bridge line) خود را مستقیماً به کسی بدهید. هنگامی که توصیف‌گر (descriptor) به مرجع پل (bridge authority) می‌رسد، سیستم توزیع (rdsys، جایگزین BridgeDB) پل شما را به یکی از توزیع‌کنندگان اختصاص می‌دهد و کاربران از آن توزیع‌کننده درخواست پل می‌کنند. تا اوت 2026 مسیرهای دسترسی به شرح زیر است:

• فرم وب در bridges.torproject.org/options که پس از حل یک کپچا، خطوط پل را ارائه می‌دهد.
• ارسال ایمیل به bridges@torproject.org از یک آدرس Gmail یا Riseup که در پاسخ، خطوط پل را برای شما می‌فرستد. محدودیت ارائه‌دهنده ایمیل به این دلیل است که حساب‌های رایگان نامحدود به یک سانسورچی اجازه می‌دهد تمام پل‌ها را فهرست کند.
• ربات تلگرام @GetBridgesBot. دستور /start و سپس /obfs4 یا /webtunnel را ارسال کنید.
• خودِ Tor Browser، در بخش Settings و سپس Connection، که در آن گزینه "Request bridges" پل‌ها را از طریق کانال moat دریافت می‌کند.

یک پل جدید حدود سه ساعت پس از راه‌اندازی در Relay Search ظاهر می‌شود. اما رسیدن کاربران به آن بسیار طولانی‌تر است: طبق عبارت خودِ Tor Project، «ممکن است چندین روز یا هفته طول بکشد تا شاهد مجموعه‌ای پایدار از کاربران باشید.» یک دوره دو هفته‌ای بدون ترافیک، عادی است و نشان‌دهنده خطا نیست.

تنظیم BridgeDistribution none باعث انصراف از تمام این سیستم‌های توزیع می‌شود. در این حالت، خط پل در اختیار شماست تا آن را از طریق کانالی که سانسورچی نظارت نمی‌کند، برای افرادی که به آن نیاز دارند ارسال کنید.

وقتی چیزی کار نمی‌کند

هیچ خط خودآزمایی (self-testing) در لاگ وجود ندارد. پورت ORPort در دسترس نیست. آن را از یک ماشین دیگر با nc -vz your.ip 8443 تست کنید. توقف (hang) به این معنی است که بسته‌ها در حال حذف شدن هستند، بنابراین ufw و پنل ارائه‌دهنده سرویس را بررسی کنید. رد اتصال (refusal) به این معنی است که tor در حال گوش دادن نیست، بنابراین ss -lntp را بررسی کرده و لاگ را برای یافتن خطای پیکربندی بخوانید.

ترنسپورت ثبت‌شده پورتی را نشان می‌دهد که شما انتخاب نکرده‌اید. tor مقدار ServerTransportListenAddr را نادیده گرفته است. نام ترنسپورت باید دقیقاً با نام موجود در ServerTransportPlugin مطابقت داشته باشد و هر دو باید obfs4 باشند.

obfs4proxy نمی‌تواند پورت 443 را bind کند. قابلیت آن را با getcap /usr/bin/obfs4proxy تأیید کنید، سپس تأیید کنید که override به unit رسیده است با systemctl show tor@default -p NoNewPrivileges. اگر این دستور NoNewPrivileges=yes را چاپ کرد، فایل drop-in شما به unitای رفته است که در حال اجرا نیست.

هیچ چیزی داخل /var/lib/tor/pt_state/ نیست. tor هرگز ترنسپورت را شروع نکرده است، که به این معنی است که مسیر در ServerTransportPlugin اشتباه است. آن را با خروجی command -v obfs4proxy مقایسه کنید.

کلاینت‌ها پس از یک تغییر، اتصال را قطع کردند. هر تغییری در آدرس یا پورت obfs4، تمام خطوط bridgeای که قبلاً توزیع شده‌اند را باطل می‌کند. بررسی کنید که آیا IP عمومی سرور نیز تغییر کرده است یا خیر؛ این اتفاق در برخی از ارائه‌دهندگان سرویس هنگام rebuild رخ می‌دهد.

tor اصلاً شروع نمی‌شود. دستور sudo -u debian-tor tor --verify-config -f /etc/tor/torrc را اجرا کنید. این دستور فایل را تجزیه (parse) می‌کند، خطی که به آن ایراد دارد را چاپ می‌کند و سرویس در حال اجرا را دست‌نخورده باقی می‌گذارد.

FAQ

آیا ارائه‌دهنده VPS من بابت یک Tor bridge شکایت خواهد کرد؟

یک bridge نقطهٔ ورود است، بنابراین ترافیکی که از سرور شما خارج می‌شود به سایر relayهای شبکه Tor می‌رود و هرگز به سایتی که کاربر انتخاب کرده است نمی‌رسد. آدرس IP شما در لاگ وب هیچ‌کس به‌عنوان منبع درخواست ظاهر نمی‌شود؛ این همان موضوعی است که باعث ایجاد شکایت برای اپراتورهای exit relay می‌شود. قوانین میزبانی همچنان متفاوت هستند و برخی ارائه‌دهندگان با هر سرویس Tor به‌عنوان یک مورد خاص برخورد می‌کنند، بنابراین پیش از شروع، سیاست استفاده قابل‌قبول (AUP) را مطالعه کنید و آدرسی که بررسی کرده‌اید را در ContactInfo قرار دهید.

یک Tor bridge چقدر پهنای باند مصرف می‌کند؟

حداقل مقدار اعلام‌شده 1 مگابیت بر ثانیه برای آپلود و دانلود است، در حالی که این مقدار برای یک guard یا middle relay برابر با 10 مگابیت بر ثانیه است. مصرف واقعی از نزدیک صفر شروع می‌شود، زیرا bridge شما فقط ترافیک کاربرانی را حمل می‌کند که توسط توزیع‌کننده به آن هدایت می‌شوند. اگر می‌خواهید سقف مشخصی تعیین کنید، RelayBandwidthRate و RelayBandwidthBurst را در torrc تنظیم کنید.

چرا هیچ‌کس به bridge جدید من متصل نشده است؟

حدود سه ساعت طول می‌کشد تا یک bridge در Relay Search ظاهر شود و طبق راهنمایی Tor Project، جذب مجموعه‌ای پایدار از کاربران چندین روز یا هفته زمان می‌برد. بررسی کنید که descriptor منتشر شده باشد (این همان خط self-testing در journalctl -u tor@default است)، اثر انگشت (fingerprint) هش‌شده خود را در Relay Search جستجو کنید و تأیید کنید که BridgeDistribution روی none تنظیم نشده باشد.

آیا باید obfs4 اجرا کنم یا WebTunnel؟

اگر این اولین bridge شماست، obfs4 را اجرا کنید: یک VPS، دو پورت، بدون دامنه و بدون گواهی. اگر ترافیک با ظاهر تصادفی نیز مسدود می‌شود، از WebTunnel استفاده کنید؛ زیرا این روش به دامنه‌ای که کنترل می‌کنید، یک وب‌سرور واقعی، یک گواهی TLS معتبر و حداقل 1 گیگابایت رم نیاز دارد. اگر هر دو را اجرا می‌کنید، آن‌ها را روی آدرس‌های جداگانه قرار دهید، زیرا در غیر این صورت مسدود شدن یک IP باعث از دسترس خارج شدن هم‌زمان دو bridge می‌شود.

اگر بعداً پورت obfs4 را تغییر دهم چه اتفاقی می‌افتد؟

تمام خطوط bridge که قبلاً توزیع شده‌اند از کار می‌افتند. یک خط bridge آدرس، پورت، اثر انگشت و گواهی را به هم متصل می‌کند؛ بنابراین کاربری که خط قدیمی را دارد، اتصالی به پورتی برقرار می‌کند که هیچ سرویسی روی آن گوش نمی‌دهد و در نهایت منصرف می‌شود. همین موضوع در مورد تغییر IP عمومی سرور نیز صدق می‌کند. پورت را در زمان راه‌اندازی انتخاب کنید و آن را تغییر ندهید.