راهنمای کامل راه‌اندازی Tor relay روی سرور مجازی

عملکرد یک Tor relay روی VPS

یک Tor relay در واقع یک daemon شبکه Tor است که روی ماشینی با IP عمومی اجرا می‌شود و ترافیک رمزنگاری‌شده را برای دیگران بازنشر می‌کند. مراجع دایرکتوری (directory authorities) این relay را منتشر می‌کنند و کلاینت‌های Tor از طریق آن مسیرهای ارتباطی (circuits) خود را می‌سازند. یک guard یا middle relay ترافیک را فقط به relay دیگری تحویل می‌دهد، بنابراین هرگز به نمایندگی از یک شخص ثالث، اتصالی به وب‌سایت‌ها برقرار نمی‌کند. همین یک نکته باعث می‌شود که هیچ ایمیل شکایتی (abuse mail) دریافت نکنید و به همین دلیل است که این مشارکت برای یک VPS معمولی کاملاً مناسب است. یک relay صرفاً ترافیک دیگران را جابه‌جا می‌کند و محتوایی از خود منتشر نمی‌کند؛ بنابراین اگر قصد دارید سایت خود را روی این شبکه قرار دهید و نه اینکه صرفاً بسته‌های داده را برای آن جابه‌جا کنید، اجرای یک v3 onion service پشت nginx وظیفه متفاوتی برای همان daemon شبکه Tor محسوب می‌شود. اجرای یک relay همچنین تأثیری بر حریم خصوصی وب‌گردی خود شما ندارد؛ این موضوع یک مسئله جداگانه است که محدودیت‌های آن بیش از حد انتظار اکثر افراد است: آنچه میزبانی شخصی SearXNG واقعاً پنهان می‌کند معیار مناسبی است برای اینکه بدانید انتقال یک سرویس به VPS شخصی تا چه حد شما را به هدف می‌رساند.

حجم کار اندک است: یک بسته نرم‌افزاری، پانزده خط پیکربندی، یک قانون فایروال و یک بار راه‌اندازی مجدد. باقی این راهنما به بخش‌هایی می‌پردازد که ممکن است با مشکل مواجه شوند. محاسبات پهنای باند در طرح‌های دارای محدودیت مصرف (metered plan) و دلیلی که باعث می‌شود یک relay جدید و کاملاً سالم، تا یک هفته غیرفعال به نظر برسد.

انتخاب نقش: Guard، میانی، Bridge یا Exit پیش از نصب

یک daemon تمامی چهار نقش را اجرا می‌کند. پیکربندی شما، در کنار directory authorities، تعیین می‌کند که شما کدام نقش را بر عهده دارید.

• Middle relay: ترافیک را از یک Guard دریافت کرده و به relay دیگری می‌فرستد. این نقش هرگز مستقیماً با سایت مقصد ارتباط برقرار نمی‌کند. هر relay جدید کار خود را از اینجا آغاز می‌کند.
• Guard relay: همان پیکربندی است، با این تفاوت که یک flag اضافی دریافت می‌کند. directory authorities زمانی flag مربوط به Guard را به relayها می‌دهند که برای مدت کافی سریع و پایدار بوده باشند. شما این نقش را انتخاب نمی‌کنید؛ بلکه آن را کسب می‌کنید و پیکربندی زیر همان چیزی است که باعث کسب این امتیاز می‌شود.
• Bridge: یک relay که عمداً در directory عمومی قرار نمی‌گیرد و به‌صورت خصوصی در اختیار کاربرانی قرار می‌گیرد که در مناطقی با فیلترینگ Tor هستند. این نقش کمترین تعهد را در میان چهار مورد دارد: پهنای باند کم، عدم لیست شدن عمومی، و بهترین گام نخست اگر برنامه شما کوچک است. این نقش همچنین به یک obfs4 proxy در کنار daemon و مجموعه‌ای متفاوت از خطوط torrc نیاز دارد که در راه‌اندازی یک obfs4 bridge روی یک VPS ارزان به آن پرداخته شده است، از جمله نحوه ارائه bridge line به کاربران در پایان کار.
• Exit relay: آخرین گام که اتصال به سایت مقصد را برقرار می‌کند. هر درخواستی که کاربر ارسال می‌کند از آدرس IP شما خارج می‌شود، بنابراین گزارش‌های سوءاستفاده و پیگیری‌های قانونی به مالک آن آدرس ارسال خواهد شد.

نقش Exit تنها نقشی است که برای یک VPS عمومی مناسب نیست. یک Exit را تنها روی سرویس‌دهنده‌ای اجرا کنید که از قبل با دریافت چنین ایمیل‌هایی موافقت کرده باشد، دارای IP اختصاصی باشد و اطلاعات تماس برای گزارش سوءاستفاده را منتشر کرده باشد. اکثر شرایط استفاده از سرویس‌های میزبانی استاندارد، این کار را ممنوع کرده‌اند و نتیجه معمول نادیده گرفتن این موضوع، تعلیق سرور و از دست دادن آدرس IP است. اگر با این وجود قصد انجام این کار را دارید، آنچه اجرای یک exit relay واقعاً شامل می‌شود به موضوعاتی مانند یافتن میزبان مناسب برای Exit، نوشتن سیاست‌های خروجی (exit policy)، تنظیم reverse DNS و پاسخگویی به ایمیل‌های دریافتی می‌پردازد. یک Guard یا Middle relay همان ترافیک کاربر را منتقل می‌کند، بدون آنکه شما را در معرض چنین خطراتی قرار دهد.

تمام موارد زیر برای ساخت یک Guard/Middle relay است. ExitRelay 0 خطی است که آن را در همین نقش نگه می‌دارد.

پیش‌نیازهای VPS پیش از شروع

پروژه Tor الزامات سخت‌گیرانه‌ای برای relayها منتشر کرده است. تا اوت 2026 این الزامات عبارتند از: یک آدرس IPv4 عمومی برای relay، حداقل 10 Mbit/s پهنای باند در هر جهت (که 16 Mbit/s توصیه می‌شود)، حداقل 100 GB ترافیک خروجی در ماه، و 512 MB رم برای سرعت‌های زیر 40 Mbit/s یا 1 GB برای سرعت‌های بالاتر. قانون ثابتی برای uptime وجود ندارد، اما relayای که کمتر از دو ساعت در روز فعال باشد، برای شبکه کارایی چندانی ندارد.

عدد 10 Mbit/s به توانایی خط اشاره دارد، نه تنظیمات نرم‌افزاری. شما به پورتی نیاز دارید که بتواند این سرعت را تأمین کند. این‌که چه مقدار از این خط را به relay اختصاص دهید، تصمیمی جداگانه است که باید با توجه به سهمیه انتقال ماهانه اتخاذ شود. پیش از تغییر در پیکربندی، طرح سرویس خود را مطالعه کنید. اگر هنوز در حال انتخاب سرور هستید، هزینه واقعی یک VPS در ماه توضیح می‌دهد که سهمیه‌های انتقال چگونه فروخته می‌شوند، و سنجش توان عملیاتی واقعی شبکه در یک VPS نشان می‌دهد که چگونه با استفاده از iperf3، به‌جای اعتماد به صفحه فروش، عملکرد واقعی خط را بسنجید.

ابتدا امنیت ماشین را تقویت کنید. یک relay سرویسی عمومی روی یک آدرس عمومی است و این آدرس دقایقی پس از انتشار، اسکن خواهد شد. محدود کردن SSH به کلیدها و پیکربندی امن sshd ده دقیقه زمان می‌برد و باید پیش از آنلاین شدن relay انجام شود، نه پس از آن.

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

به‌جای استفاده از بسته موجود در توزیع، از مخزن apt اختصاصی Tor Project استفاده کنید. کد مربوط به relay سریع‌تر از نسخه‌های پایدار (stable) به‌روزرسانی می‌شود؛ بنابراین اصلاحات ابتدا به این مخزن می‌رسند و بسته‌های توزیع معمولاً بین هر انتشار، عقب می‌مانند.

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

ابتدا کلید امضا و سپس مخزن را اضافه کنید. نام رمز (codename) به‌طور خودکار از سیستم خوانده می‌شود، بنابراین همین بلوک برای 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 نسخه‌ای را که به‌تازگی نصب کرده‌اید نمایش می‌دهد. اگر apt update خطای NO_PUBKEY را چاپ کرد، به این معناست که کلید dearmor شده در مسیر مشخص‌شده در خط Signed-By: وجود ندارد و در نتیجه apt کلیدی برای بررسی فایل release در اختیار ندارد. بسته deb.torproject.org-keyring برای مراحل بعدی اهمیت دارد؛ این بسته کلید امضا را به‌عنوان یک بسته معمولی ارائه می‌دهد تا وقتی کلید تغییر کرد (rotated)، عملکرد apt مختل نشود.

ارتقاهای خودکار را فعال کنید و سپس منبع جدید را به آن‌ها معرفی کنید.

sudo apt install -y unattended-upgrades apt-listchanges

در Ubuntu، منبع Tor را به بلوک Allowed-Origins در فایل /etc/apt/apt.conf.d/50unattended-upgrades اضافه کنید:

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

در Debian، همین فایل از Origins-Pattern استفاده می‌کند که خطی که باید اضافه شود "origin=TorProject"; است. نتیجه را با sudo unattended-upgrade --debug --dry-run بررسی کنید؛ این دستور منابعی را که روی آن‌ها عمل می‌کند چاپ کرده و خروجی دیگری تولید نمی‌کند.

فایل torrc که اهمیت دارد

این بسته یک فایل /etc/tor/torrc طولانی و پر از توضیحات را نصب می‌کند. تنها تعداد انگشت‌شماری از خطوط برای یک relay اهمیت دارند. آن‌ها را به انتهای فایل اضافه کنید.

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

مقدار Nickname بین 1 تا 19 کاراکتر است و فقط شامل حروف و اعداد می‌شود. این مقدار در کل شبکه منحصربه‌فرد نیست و هویت شما محسوب نمی‌شود؛ هویت شما همان fingerprint است. این نام برای پیدا کردن relay خودتان در کادر جستجو استفاده می‌شود، پس نامی انتخاب کنید که بتوانید به‌راحتی آن را پشت تلفن هجی کنید.

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

مقدار ORPort 9001 پورتی است که سایر relayها و کلاینت‌ها به آن متصل می‌شوند. پورت 9001 یک انتخاب مرسوم است. پورت 443 انتخاب رایج دیگر است، زیرا برخی شبکه‌های محدودکننده فقط اجازه خروجی روی پورت 443 را می‌دهند، بنابراین relay که روی این پورت گوش می‌دهد، برای کلاینت‌های بیشتری در دسترس است. فقط در صورتی پورت 443 را انتخاب کنید که هیچ سرویس دیگری روی سرور به آن نیاز نداشته باشد.

گزینه SocksPort 0 پراکسی SOCKS محلی را غیرفعال می‌کند که یک relay از آن استفاده نمی‌کند و یک سوکت listening را از روی ماشین حذف می‌کند. گزینه ExitRelay 0 این قصد را در فایل ثبت می‌کند: این relay هرگز به نمایندگی از یک کاربر به مقصدی متصل نخواهد شد و هر کسی که بعداً این پیکربندی را می‌خواند، نیازی ندارد آن را از تنظیمات پیش‌فرض حدس بزند.

اگر VPS دارای آدرس IPv6 است، یک خط ORPort دوم اضافه کنید. Tor نمی‌تواند به همان شکلی که برای IPv4 عمل می‌کند، به "هر" آدرس IPv6 متصل شود (bind شود)، بنابراین آدرس را داخل کروشه بنویسید.

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

روی یک VPS با 1 گیگابایت رم، گزینه MaxMemInQueues 512 MB را اضافه کنید. Tor محدودیت صف خود را بر اساس حافظه‌ای که روی ماشین می‌بیند تعیین می‌کند که در یک سرور اشتراکی کوچک، بیشتر از مقداری است که می‌خواهید مصرف کند. تعیین دستی این محدودیت باعث می‌شود tor تحت فشار، سلول‌های صف‌بندی‌شده را حذف کند (که relay در این شرایط پایدار می‌ماند)، به‌جای اینکه مصرف حافظه تا حدی رشد کند که هسته سیستم‌عامل (kernel) پروسه را بکشد.

باز کردن ORPort در فایروال

در جهت ورودی، ORPort باید از هر نقطه‌ای در اینترنت قابل دسترس باشد. در جهت خروجی، محدودیت‌های relay را حذف کنید: این سرویس اتصالات متعددی را به هزاران relay دیگر روی پورت‌های مختلف برقرار می‌کند و اعمال لیست سفید (allowlist) برای ترافیک خروجی، عملکرد آن را به‌شدت مختل خواهد کرد.

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

سپس فایروال شبکهٔ ارائه‌دهندهٔ سرویس را بررسی کنید. بسیاری از پنل‌های مدیریتی، یک فیلتر بسته (packet filter) در مقابل ماشین مجازی اجرا می‌کنند. در این حالت، قانونی که با ufw اضافه کرده‌اید تأثیری نخواهد داشت؛ بنابراین پورت روی سرور باز به نظر می‌رسد اما از بیرون بسته است. اگر با ufw آشنایی ندارید، قوانین ufw که باید روی هر VPS اعمال شوند، سیاست‌های پیش‌فرض و ترتیب اولویت بررسی قوانین را توضیح می‌دهد.

تخمین پهنای باند متناسب با طرح سرویس

در راهنما از RelayBandwidthRate به‌عنوان یک توکن‌باکت (token bucket) مجزا یاد شده است که «میانگین پهنای باند ورودی برای ترافیک رله‌شده روی این نود را به تعداد بایت‌های مشخص‌شده در ثانیه محدود می‌کند و میانگین پهنای باند خروجی را نیز به همان مقدار محدود می‌سازد». این جمله را دوباره بخوانید. محدودیت برای هر جهت به‌صورت جداگانه اعمال می‌شود. رله‌ای که روی 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 گیگابایت در روز جابه‌جا می‌کند، بنابراین یک ماه 30 روزه تقریباً 648 گیگابایت ترافیک محاسبه‌شده مصرف می‌کند. این مقدار در سقف 1 ترابایت جای می‌گیرد و فضایی برای به‌روزرسانی‌ها و پشتیبان‌گیری‌ها باقی می‌ماند. با افزایش نرخ به 2 Mbit/s، هزینه ماهانه به 1,296 گیگابایت می‌رسد که از طرح 1 ترابایتی فراتر است. ردیف آخر، یعنی 20 Mbit/s، به 12,960 گیگابایت در ماه نیاز دارد و باید روی پورتی با ترافیک نامحدود (unmetered) قرار گیرد. اگر ارائه‌دهنده شما فقط ترافیک خروجی را محاسبه می‌کند، تمام ارقام را نصف کنید. پیش از تنظیم نرخ، نوع محاسبه ارائه‌دهنده خود را مشخص کنید، زیرا این دو پاسخ با ضریب دو با هم تفاوت دارند.

حالا نوبت پیکربندی است. ابتدا محدودیت نرخ (Rate limit) و سپس سهمیه (Quota).

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

RelayBandwidthBurst اندازه توکن‌باکت است، بنابراین اجازه می‌دهد در حالی که میانگین حفظ می‌شود، جهش‌های کوتاه‌مدت بالاتر از نرخ مجاز رخ دهد. مقداری حدود دو برابر نرخ، عددی منطقی است.

AccountingRule خطی است که اکثر اپراتورها از آن غافل می‌شوند. مقدار پیش‌فرض max است که بزرگ‌ترینِ دو جهت را در برابر سهمیه می‌سنجد. با مقدار پیش‌فرض، AccountingMax 400 GBytes اجازه 400 گیگابایت ورودی و 400 گیگابایت خروجی را می‌دهد که در صورت‌حسابی که هر دو را می‌شمارد، 800 گیگابایت محسوب می‌شود. AccountingRule sum مجموع خواندن و نوشتن را در برابر یک سهمیه واحد می‌سنجد، که همان چیزی است که سقف انتقال داده واقعاً اندازه‌گیری می‌کند.

AccountingStart را نیز بنویسید و هرگز AccountingMax را به‌تنهایی استفاده نکنید. سهمیه همان عدد است و خط شروع، دوره‌ای است که سهمیه در آن بازنشانی می‌شود. سهمیه‌ای که دوره زمانی نداشته باشد، رله را در وضعیت خواب (hibernation) رها می‌کند و راهی برای بازگشت آن باقی نمی‌گذارد.

وضعیت خواب یک ابزار خشن است. وقتی سهمیه تمام می‌شود، Tor این موضوع را در لاگ ثبت کرده و پذیرش ترافیک را متوقف می‌کند:

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

رله در لحظه دقیق شروع دوره بعدی نیز بیدار نمی‌شود. Tor ردیابی می‌کند که سهمیه قبلی با چه سرعتی مصرف شده است و یک نقطه تصادفی در بازه جدید انتخاب می‌کند تا هزاران رله در یک ثانیه به شبکه بازنگردند. رله‌ای که در هفته آخر هر ماه ناپدید شود، پایداری خود را که توسط دایرکتوری‌های مرجع (directory authorities) اندازه‌گیری می‌شود، از دست می‌دهد. مقدار RelayBandwidthRate را طوری تنظیم کنید که سقف هرگز پر نشود و AccountingMax را به‌عنوان آخرین سنگر برای محافظت از صورت‌حساب حفظ کنید.

راه‌اندازی relay و تأیید دسترسی به آن

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.

این جمله به این معناست که سایر relayها به ORPort شما متصل شده و یک مدار از طریق آن ایجاد کرده‌اند. تا زمانی که این پیام ظاهر نشود، relay شما در دایرکتوری قرار ندارد و هیچ ترافیکی را منتقل نمی‌کند. پیام خطا به این صورت است:

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 باز است؟ آیا این پورت در فایروال شبکهٔ جداگانهٔ ارائه‌دهندهٔ سرویس نیز باز است؟ آیا آدرسی که در آن پیام آمده، همان آدرسی است که اینترنت واقعاً به سمت شما مسیریابی می‌کند، یا یک آدرس خصوصی از تنظیمات NAT است؟ پورت را از یک دستگاه دیگر با استفاده از nc -vz 203.0.113.10 9001 تست کنید. Tor به‌طور خودکار تست سلامت را تکرار می‌کند، بنابراین پس از اصلاح فایروال، مشکل بدون دخالت شما برطرف می‌شود؛ با این حال، یک restart بلافاصله وضعیت را به‌روز می‌کند.

هویت دائمی relay شما، اثر انگشت (fingerprint) آن است:

sudo cat /var/lib/tor/fingerprint

تقریباً سه ساعت پس از انتشار descriptor، relay شما در Relay Search ظاهر می‌شود. نام مستعار (nickname) را جستجو کنید یا اثر انگشت را در آنجا وارد کنید. آن صفحه نشان‌دهندهٔ دیدگاه شبکه نسبت به relay شماست: چه flagهایی دارد، چه وزنی توسط authorities به آن اختصاص داده شده و چه نسخه‌ای را منتشر می‌کند.

چرا یک Tor relay جدید تقریباً هیچ ترافیکی ندارد؟

به این دلیل که شبکه هنوز آن را اندازه‌گیری نکرده است و این فرآیند اندازه‌گیری هفته‌ها زمان می‌برد. پروژه Tor این روند افزایش ترافیک را در چهار مرحله توصیف می‌کند، اما اپراتوری که آن را مطالعه نکرده باشد، تصور می‌کند relay دچار مشکل شده و شروع به تغییر تنظیمات می‌کند.

در سه روز نخست، relay اندازه‌گیری‌نشده باقی می‌ماند. این relay نتیجه تست خودکار خود را گزارش می‌دهد، اما directory authorities به هر حال وزن منتشرشده را روی 20 KB محدود می‌کنند، بنابراین کلاینت‌ها تقریباً هرگز آن را انتخاب نمی‌کنند. از حدود روز سوم تا هشتم، bandwidth authorities آن را به‌طور واقعی اندازه‌گیری می‌کنند و وزن افزایش می‌یابد، اما فقط به عنوان یک middle hop استفاده می‌شود، زیرا هیچ کلاینتی تمایل ندارد یک relay کاملاً جدید را به عنوان اولین hop خود انتخاب کند.

حدود روز هشتم، relay واجد شرایط دریافت Guard flag می‌شود. دریافت این پرچم باعث کاهش ترافیک می‌شود که همه را غافلگیر می‌کند: کلاینت‌ها هنگام انتخاب middle hop از guardها صرف‌نظر می‌کنند، با این فرض که یک guard از قبل مشغول است، بنابراین relay ترافیک middle خود را پیش از آنکه ترافیک guard به دست آورد، از دست می‌دهد. این ترافیک تنها زمانی دوباره پر می‌شود که کلاینت‌ها guard setهای خود را تغییر دهند که این کار هفته‌ها طول می‌کشد. تا حدود روز 68، relay به وضعیت پایداری می‌رسد که در آن کلاینت‌هایی که آن را حذف می‌کنند با کلاینت‌هایی که آن را اضافه می‌کنند، به تعادل می‌رسند.

بنابراین انتظار منطقی این است که تا سه روز هیچ ترافیکی نباشد، پس از یک هفته مقداری ترافیک ایجاد شود و پس از دو ماه بار کاری واقعی برقرار گردد. یک تنظیم را تغییر دهید و سپس یک هفته صبر کنید تا نتیجه آن را ببینید. استفاده از یک صفحه وضعیت Uptime Kuma شخصی‌سازی‌شده با یک بررسی TCP روی پورت 9001، استفاده بهتری از انرژی عصبی شماست: این کار به سوالی پاسخ می‌دهد که واقعاً می‌توانید آن را کنترل کنید، یعنی اینکه آیا پورت همچنان پاسخگو است یا خیر.

نظارت بر رله با استفاده از nyx

nyx یک مانیتور ترمینالی برای رله‌ای است که در حال اجراست. این ابزار با پورت کنترلی tor ارتباط برقرار می‌کند، بنابراین ابتدا آن را در torrc فعال کنید:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort فقط روی 127.0.0.1 گوش می‌دهد و احراز هویت کوکی به این معناست که برنامه باید پیش از صدور دستورات، یک فایل محرمانه را بخواند. Tor این کوکی را با کاربر debian-tor و مجوز 600 در /run/tor/control.authcookie می‌نویسد تا هیچ موجودیت دیگری قادر به خواندن آن نباشد. CookieAuthFileGroupReadable 1 دسترسی به این فایل را برای گروه باز می‌کند، که این کار به حساب کاربری شما اجازه می‌دهد nyx را بدون نیاز به sudo اجرا کنید.

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

از سیستم خارج شده و دوباره وارد شوید، سپس nyx را اجرا کنید. گروه جدید باید در زمان ورود به سیستم شناسایی شود، بنابراین اجرای nyx در همان نشست ترمینال قبلی، با وجود درست بودن پیکربندی، منجر به خطای دسترسی به فایل کوکی می‌شود. nyx پهنای باند لحظه‌ای، زمان فعالیت (uptime)، جریان لاگ‌ها و لیست اتصالات را نمایش می‌دهد. در هفته‌های اول، عددی که باید زیر نظر داشته باشید، نمودار پهنای باند است که باید زیر مقدار RelayBandwidthRate شما باقی بماند.

اجرای بیش از یک رله: MyFamily و کلیدهای خانواده

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

روش قدیمی و رایج، استفاده از MyFamily در فایل torrc هر رله و فهرست کردن اثرانگشت (fingerprint) تمام رله‌های دیگر است:

MyFamily AAAAAAAAAA,BBBBBBBB

در این روش، هر رله تمام رله‌های دیگر را فهرست می‌کند، بنابراین افزودن رله چهارم به معنای ویرایش چهار فایل است. Tor 0.4.9 این روش را با یک کلید خانواده (family key) جایگزین کرده است. یک کلید تولید کنید و سپس آن را به اشتراک بگذارید:

tor --keygen-family myfamily

این دستور فایل myfamily.secret_family_key را ایجاد کرده و یک خط FamilyId را چاپ می‌کند. فایل کلید را به هر رله کپی کنید و در زیرپوشه keys از DataDirectory (در Debian و Ubuntu مسیر /var/lib/tor/keys است) قرار دهید؛ دقت کنید که پسوند .secret_family_key حفظ شود. خط FamilyId چاپ‌شده را به فایل torrc هر رله اضافه کرده و با دستور sudo systemctl reload tor@default آن را reload کنید. فعلاً فهرست MyFamily را نیز در جای خود نگه دارید. کلاینت‌هایی که هنوز گواهی‌های خانواده را نمی‌شناسند، همچنان از فهرست قدیمی استفاده می‌کنند و Tor Project زمانی که امکان حذف آن فراهم شود، اطلاع‌رسانی خواهد کرد.

چه مواردی پس از اجرا دچار اختلال می‌شوند

نسخه نرم‌افزار قدیمی می‌شود. قابلیت Unattended upgrades بسته را جایگزین می‌کند، اما پردازش در حال اجرا تا زمانی که سرویس مجدداً راه‌اندازی نشود، از همان باینری اولیه استفاده می‌کند. نسخه موجود در tor --version روی سرور را با نسخه‌ای که در صفحه Relay Search نمایش داده می‌شود مقایسه کنید. اگر این دو متفاوت باشند، شبکه همچنان نسخه قدیمی را می‌بیند؛ بنابراین سرویس را restart کنید.

ساعت سیستم دچار انحراف می‌شود. اسناد اجماع (Consensus) و گواهی‌ها همگی دارای محدودیت زمانی هستند؛ بنابراین ماشینی که ساعت آن اختلاف زیادی داشته باشد، اجماع را رد کرده و انتشار داده را متوقف می‌کند. دستور timedatectl باید ساعت سیستم را همگام‌سازی‌شده گزارش دهد. اگر این‌طور نیست، systemd-timesyncd را فعال کنید یا chrony را نصب نمایید.

آدرس IP تغییر می‌کند. توصیف‌گر (Descriptor) شامل آدرس است و کلاینت‌ها نمی‌توانند به آدرسی که تغییر کرده متصل شوند. پس از هرگونه مهاجرت به ارائه‌دهنده جدید یا تغییر آدرس، tor را restart کرده و مجدداً منتظر مشاهده خط self-test بمانید.

سرعت رله کمتر از حد پیش‌بینی‌شده است. رمزنگاری رله Tor روی پردازنده‌های مدرن کارآمد است و Tor Project توان پردازشی یک CPU با پشتیبانی از AES-NI را تقریباً 400 تا 450 مگابیت بر ثانیه در هر جهت تخمین می‌زند. بسیار پیش از رسیدن به این سقف، محدودیت سرعت پورت و حجم ترافیک مجاز مانع شما خواهد شد؛ به همین دلیل است که بخش حسابداری (accounting) در بالا، اهمیت بیشتری نسبت به سخت‌افزار دارد.

FAQ

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

به همان اندازه‌ای که شما اجازه می‌دهید و نه بیشتر. RelayBandwidthRate ترافیک رله‌شده را در هر جهت به‌صورت جداگانه محدود می‌کند، بنابراین رله‌ای که روی 1 Mbit/s تنظیم شده باشد، می‌تواند هم‌زمان 1 Mbit/s ورودی و 1 Mbit/s خروجی داشته باشد. این مقدار در مجموع حدود 21.6 گیگابایت در روز یا 648 گیگابایت در یک ماه 30 روزه (با احتساب هر دو جهت) خواهد بود. می‌توانید با استفاده از AccountingMax و AccountingRule sum، یک سهمیه ماهانه سخت‌گیرانه نیز زیر آن نرخ تعیین کنید.

آیا اجرای یک رله Tor باعث دریافت شکایات سوءاستفاده (abuse) می‌شود؟

یک رله Guard یا Middle ترافیک را فقط به سایر رله‌های Tor ارسال می‌کند و هرگز برای کاربر به وب‌سایتی متصل نمی‌شود؛ بنابراین شکایات مربوط به فعالیت‌های انجام‌شده از طریق Tor به اپراتور Exit ارسال می‌شود، نه به شما. آنچه ممکن است مشاهده کنید، اسکن‌های شبکه و گاهی قرار گرفتن در لیست‌های شهرت IP است، زیرا آدرس شما به‌صورت عمومی به‌عنوان یک رله ثبت شده است. رله‌های Exit هستند که ایمیل‌های سوءاستفاده و اخطارهای قانونی را دریافت می‌کنند و باید از ارائه‌دهنده‌ای استفاده کنند که از قبل با این موضوع موافقت کرده باشد. پیش از راه‌اندازی هر نوع رله، شرایط خدمات ارائه‌دهنده خود را مطالعه کنید.

چرا رله Tor جدید من ترافیکی دریافت نمی‌کند؟

زیرا رله‌های جدید طبق طراحی تا زمانی که اندازه‌گیری نشوند، محدود می‌شوند. در سه روز اول، مراجع دایرکتوری (directory authorities) وزن منتشرشده را روی 20 KB محدود می‌کنند، بنابراین کلاینت‌ها تقریباً هرگز آن رله را انتخاب نمی‌کنند. مراجع پهنای باند از حدود روز سوم شروع به اندازه‌گیری می‌کنند، رله در حدود روز هشتم واجد شرایط دریافت پرچم Guard می‌شود و در آن نقطه ترافیک دوباره کاهش می‌یابد، زیرا کلاینت‌ها هنگام انتخاب hopهای میانی از انتخاب Guardها اجتناب می‌کنند. بار کامل ترافیک در حدود روز 68 می‌رسد. تأیید کنید که لاگ عبارت "Self-testing indicates your ORPort is reachable from the outside" را نشان می‌دهد، سپس آن را به حال خود رها کنید.

آیا می‌توانم یک رله Tor را روی یک VPS با سقف انتقال 1 ترابایت اجرا کنم؟

بله، با نرخ حدود 1 Mbit/s در هر جهت که معادل RelayBandwidthRate 125 KBytes است. اگر ارائه‌دهنده شما هر دو جهت را محاسبه کند، این مقدار حدود 648 گیگابایت در ماه می‌شود که فضای کافی برای به‌روزرسانی‌ها و پشتیبان‌گیری‌ها باقی می‌گذارد. با استفاده از AccountingMax 400 GBytes، AccountingRule sum و AccountingStart month 1 00:00 تنظیمات را اعمال کنید تا رله به‌جای عبور از سقف طرح، به حالت خواب (hibernate) برود. اگر ارائه‌دهنده فقط ترافیک خروجی را محاسبه می‌کند، می‌توانید نرخ را دو برابر کنید.

اگر فقط یک رله اجرا می‌کنم، آیا نیاز به تنظیم MyFamily دارم؟

خیر. اعلام Family برای این است که کلاینت‌ها از ایجاد مدار (circuit) از طریق دو رله متعلق به یک اپراتور اجتناب کنند، که این موضوع برای یک رله بی‌معنی است. به‌محض افزودن رله دوم، آن را تنظیم کنید: اثر انگشت (fingerprint) هر رله را در خط MyFamily تمام رله‌ها لیست کنید، یا از کلید family که در Tor 0.4.9 معرفی شد استفاده کنید که به‌جای یک لیست در حال رشد، یک FamilyId واحد را توزیع می‌کند.