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

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

یک Tor relay در واقع یک daemon شبکه Tor است که روی ماشینی با IP عمومی اجرا می‌شود و ترافیک رمزنگاری‌شده را برای سایر کاربران هدایت می‌کند. مراجع دایرکتوری (directory authorities) این relay را منتشر می‌کنند و کلاینت‌های Tor از طریق آن مسیرهای ارتباطی (circuits) خود را می‌سازند. یک guard یا middle relay ترافیک را فقط به relay دیگری تحویل می‌دهد، بنابراین هرگز به نمایندگی از یک فرد ناشناس، اتصالی به وب‌سایت‌ها برقرار نمی‌کند. همین یک نکته باعث می‌شود که هیچ ایمیل شکایتی (abuse mail) دریافت نشود و به همین دلیل، این مشارکت برای یک VPS معمولی کاملاً مناسب است.

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

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

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

• Middle relay (رله میانی): ترافیک را از یک Guard دریافت کرده و به رله دیگری می‌فرستد. این رله هرگز با سایت مقصد تماس نمی‌گیرد. هر رله جدیدی از اینجا شروع می‌شود.
• Guard relay (رله نگهبان): همان پیکربندی است، با این تفاوت که یک پرچم (flag) اضافی دارد. Directory authorities زمانی پرچم Guard را به رله‌ها می‌دهند که به اندازه کافی سریع و پایدار بوده باشند. شما این نقش را انتخاب نمی‌کنید؛ بلکه آن را کسب می‌کنید و پیکربندی زیر همان چیزی است که باعث کسب این نقش می‌شود.
• Bridge (پل): رله‌ای که عمداً در دایرکتوری عمومی قرار نمی‌گیرد و به‌صورت خصوصی در اختیار کاربرانی قرار می‌گیرد که در مناطقی هستند که Tor در آنجا مسدود شده است. این نقش کمترین تعهد را در میان چهار مورد دارد: پهنای باند کم، عدم ثبت در لیست عمومی، و بهترین گام نخست اگر برنامه شما در مقیاس کوچک است.
• Exit relay (رله خروجی): آخرین گام که اتصال به سایت مقصد را برقرار می‌کند. هر درخواستی که کاربر ارسال می‌کند از آدرس IP شما خارج می‌شود، بنابراین گزارش‌های سوءاستفاده و پیگیری‌های پلیسی به مالک آن آدرس ارسال خواهد شد.

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

تمام موارد زیر برای ساخت یک رله Guard/میانی است. 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، به‌جای اعتماد به صفحه فروش، عملکرد واقعی خط را بسنجید.

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

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

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

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 برای مراحل بعدی اهمیت دارد؛ این بسته کلید امضا را به‌عنوان یک بسته معمولی ارائه می‌دهد تا وقتی کلید چرخش (rotate) پیدا کرد، apt همچنان به کار خود ادامه دهد.

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

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 منتشر می‌شود که یک سند عمومی است و هر کسی می‌تواند آن را دانلود کند، بنابراین این آدرس توسط ربات‌ها جمع‌آوری خواهد شد. از آدرسی استفاده کنید که تا 2 سال آینده همچنان آن را چک می‌کنید و اگر مایل هستید، آن را obfuscate کنید. این تنها کانالی است که Tor Project برای هشدار دادن درباره مشکلات relay شما در اختیار دارد.

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

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

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

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

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

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

در جهت ورودی (Inbound)، دسترسی به ORPort باید از هر نقطه‌ای در اینترنت امکان‌پذیر باشد. در جهت خروجی (Outbound)، رله را محدود نکنید: این سرویس اتصالات متعددی را به هزاران رله دیگر روی پورت‌های مختلف برقرار می‌کند و ایجاد یک لیست مجاز (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 اندازه token bucket است، بنابراین اجازه می‌دهد در حالی که میانگین حفظ می‌شود، جهش‌های کوتاه بالاتر از نرخ مجاز باشد. حدود دو برابر نرخ، مقداری منطقی است.

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

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

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

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

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

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

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.

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

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 بلافاصله آن را اعمال می‌کند.

هویت دائمی رله شما، fingerprint آن است:

sudo cat /var/lib/tor/fingerprint

تقریباً سه ساعت پس از انتشار descriptor، رله در Relay Search ظاهر می‌شود. نام مستعار (nickname) را جستجو کنید یا fingerprint را در آنجا وارد کنید. آن صفحه نشان‌دهندهٔ دیدگاه شبکه نسبت به رله شماست: چه 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 check روی پورت 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 (در دبیان و اوبونتو مسیر /var/lib/tor/keys) کپی کنید و پسوند .secret_family_key را حفظ نمایید. خط FamilyId چاپ‌شده را به فایل torrc هر رله اضافه کرده و با دستور sudo systemctl reload tor@default آن را بازنشانی (reload) کنید. لیست MyFamily را فعلاً در جای خود نگه دارید. کلاینت‌هایی که هنوز گواهی‌های خانواده را نمی‌شناسند، همچنان از لیست قدیمی استفاده می‌کنند و پروژه Tor زمان مناسب برای حذف آن را اعلام خواهد کرد.

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

نسخه نرم‌افزار قدیمی می‌شود. قابلیت 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 Mbit/s در هر جهت تخمین می‌زند. بسیار پیش از رسیدن به این سقف، محدودیت سرعت پورت و حجم ترافیک مجاز مانع کار می‌شود؛ به همین دلیل بخش 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 جدید من ترافیکی دریافت نمی‌کند؟

زیرا رله‌های جدید طبق طراحی تا زمانی که اندازه‌گیری نشوند، محدود (throttle) می‌شوند. در سه روز اول، مراجع دایرکتوری (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 واحد را توزیع می‌کند.