Як запустити Tor relay на VPS

Що робить Tor relay на VPS

Tor relay — це демон Tor на машині з публічною IP-адресою, який пересилає зашифрований трафік для інших користувачів. Directory authorities публікують інформацію про нього, а клієнти Tor будують через нього ланцюжки. Guard або middle relay передає трафік лише іншому relay, тому не встановлює з’єднання з вебсайтом від імені сторонньої особи. Саме тому він не привертає повідомлень про зловживання і є внеском, який підходить для звичайного VPS.

Налаштування просте: один пакет, п’ятнадцять рядків конфігурації, одне правило firewall і один перезапуск. Решта цього посібника присвячена тому, що зазвичай спричиняє проблеми: розрахунку пропускної здатності в тарифному плані з обмеженим трафіком і причині, через яку справний новий relay може виглядати неактивним протягом тижня.

Guard, middle, bridge or exit: pick before you install

Один демон виконує всі чотири ролі. Роль визначають ваша конфігурація та directory authorities.

• Middle relay. Він отримує traffic від guard і передає його іншому relay. Він ніколи не підключається до сайту призначення. Кожен новий relay починає з цієї ролі.
• Guard relay. Це та сама конфігурація з додатковим flag. Directory authorities надають relay прапорець Guard, якщо він достатньо довго працював швидко та стабільно. Ви не обираєте цю роль. Її потрібно заслужити, і наведена нижче конфігурація допомагає це зробити.
• Bridge. Це relay, який навмисно не публікують у загальному directory і приватно передають користувачам у місцях, де Tor заблокований. Це найменше зобов’язання серед чотирьох ролей: низька пропускна здатність, відсутність у публічному переліку та правильний перший крок, якщо ваш план має невеликий масштаб.
• Exit relay. Це останній hop, який відкриває з’єднання із сайтом призначення. Кожен запит користувача виходить із вашої IP-адреси, тому повідомлення про зловживання та запити від поліції надходитимуть власнику цієї адреси.

Exit — єдина роль, для якої не підходить VPS загального призначення. Запускайте exit лише в провайдера, який заздалегідь погодився отримувати такі повідомлення, на окремій IP-адресі та з опублікованим контактом для повідомлень про зловживання. Більшість стандартних умов хостингу це забороняє. Зазвичай ігнорування цієї вимоги призводить до призупинення роботи сервера та втрати IP-адреси. Guard або middle relay передає той самий трафік користувачів без такого ризику.

Усе нижче стосується guard/middle relay. ExitRelay 0 — це рядок, який залишає його в цій ролі.

Що потрібно VPS перед початком

Tor Project публікує обов’язкові вимоги для relay. Станом на August 2026 це такі вимоги: одна публічна IPv4-адреса для relay, пропускна здатність щонайменше 10 Mbit/s у кожному напрямку, рекомендовано 16 Mbit/s, щонайменше 100 GB вихідного трафіку на місяць і 512 MB RAM за швидкості до 40 Mbit/s або 1 GB за вищої швидкості. Фіксованої вимоги до часу роботи немає, але relay, який працює менше двох годин на день, мало корисний для мережі.

Показник 10 Mbit/s описує пропускну здатність лінії, а не налаштування. Вам потрібен порт, який підтримує таку швидкість. Обсяг цієї пропускної здатності, який ви дозволите використовувати relay, є окремим рішенням і залежить від місячного ліміту передавання даних. Ознайомтеся зі своїм тарифом, перш ніж змінювати конфігурацію. Якщо ви ще обираєте сервер, у матеріалі скільки насправді коштує VPS на місяць пояснено, як продаються ліміти трафіку, а матеріал як виміряти фактичну пропускну здатність мережі VPS показує, як перевірити реальну швидкість лінії за допомогою iperf3, а не покладатися на сторінку з описом тарифу.

Спочатку захистіть машину. Relay — це публічний сервіс на публічній адресі, і цю адресу почнуть сканувати протягом кількох хвилин після публікації. Матеріал як обмежити SSH доступом за ключами та посилити конфігурацію sshd допоможе виконати це за десять хвилин. Це потрібно зробити до запуску relay, а не після нього.

Встановлення tor зі сховища Tor Project

Використовуйте власне apt-сховище Tor Project, а не пакет із дистрибутива. Код relay оновлюється швидше, ніж стабільні релізи, тому виправлення спочатку потрапляють у це сховище, а пакет дистрибутива відстає між релізами.

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, декодований ключ відсутній за шляхом, указаним у рядку Signed-By:, тому apt не має ключа для перевірки release-файлу. Пакет deb.torproject.org-keyring стане потрібним пізніше: він постачає ключ підпису як звичайний пакет, тому 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 публікується в descriptor relay. Це публічний документ, який може завантажити будь-хто, тому адресу буде зібрано автоматичними засобами. Використовуйте адресу, яку ви читатимете й через два роки. За бажанням замаскуйте її. Це єдиний канал, через який Tor Project може попередити вас про проблему з relay.

ORPort 9001 — це порт, до якого підключаються інші relay і клієнти. Порт 9001 є типовим вибором. Інший поширений варіант — порт 443, оскільки деякі мережі з обмеженнями дозволяють лише вихідні підключення до 443. Тому relay, який слухає цей порт, доступний більшій кількості клієнтів. Вибирайте 443 лише тоді, коли інший процес на сервері його не використовує.

SocksPort 0 вимикає локальний SOCKS-проксі, який relay не використовує, і прибирає один listening socket із системи. ExitRelay 0 явно записує цей намір у файл: цей relay ніколи не підключатиметься до призначення від імені користувача, і тому тому, хто пізніше читатиме конфігурацію, не потрібно буде робити такий висновок зі значення за замовчуванням.

Якщо VPS має IPv6-адресу, додайте другий рядок ORPort. Tor не може прив’язатися до "будь-якої" IPv6-адреси так само, як до IPv4, тому запишіть адресу у квадратних дужках.

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

На VPS із 1 GB пам’яті додайте MaxMemInQueues 512 MB. Tor визначає ліміт черги за обсягом пам’яті, доступної системі. На невеликому спільному сервері цей ліміт може бути більшим, ніж потрібно. Якщо задати ліміт вручну, tor під навантаженням відкидатиме комірки з черги. Relay продовжить працювати, замість того щоб збільшувати споживання пам’яті, доки kernel не завершить процес.

Відкрийте ORPort у firewall

Для вхідного трафіку ORPort має бути доступним з будь-якої точки інтернету. Для вихідного трафіку залиште relay без обмежень: він встановлює з’єднання з тисячами інших relay через багато різних портів, а allowlist для вихідного трафіку непомітно виведе його з ладу.

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

Потім перевірте власний мережевий firewall провайдера. Багато панелей керування запускають packet filter перед віртуальною машиною. Тому правило, додане через ufw, там не діє: на сервері порт буде відкритим, але ззовні — закритим. Якщо ви раніше не працювали з ufw, у матеріалі правила ufw, які потрібні на кожному VPS описано політику за замовчуванням і порядок зіставлення правил.

Визначте пропускну здатність відповідно до вашого тарифу

У посібнику RelayBandwidthRate описано як окремий token bucket, який обмежує «середнє використання вхідної пропускної здатності для ретрансльованого трафіку на цьому вузлі заданою кількістю байтів за секунду, а середнє використання вихідної пропускної здатності — тим самим значенням». Прочитайте це ще раз. Обмеження застосовується окремо до кожного напрямку. Relay, налаштований на 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 рядків містять розрахунки, а не результати вимірювань: вони показують вартість швидкості, якщо relay підтримує її протягом усіх 30 днів в обох напрямках. Насправді relay більшу частину часу працює нижче встановленого обмеження, особливо протягом перших тижнів. Використовуйте таблицю, щоб відкинути налаштування, які не вписуються в бюджет, а не для прогнозування рахунку з точністю до гігабайта.

За швидкості 1 Mbit/s у кожному напрямку relay передає приблизно 21.6 GB на день, тому за 30-денний місяць це становить близько 648 GB трафіку, який тарифікується. Це вкладається в ліміт 1 TB, і залишається запас для оновлень та резервних копій. Якщо збільшити швидкість до 2 Mbit/s, за місяць використовується 1,296 GB, що вже перевищує тарифний план на 1 TB. Для останнього рядка, 20 Mbit/s, потрібно 12,960 GB на місяць, тому він підходить для порту без обмеження трафіку. Якщо провайдер тарифікує лише вихідний трафік, поділіть усі значення навпіл. З’ясуйте, який варіант застосовується у вашому тарифі, перш ніж встановлювати швидкість, оскільки ці два варіанти відрізняються вдвічі.

Тепер перейдемо до конфігурації. Спочатку обмежте швидкість, а потім встановіть квоту.

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 GB вхідного і 400 GB вихідного трафіку, тобто 800 GB за умови обліку обох напрямків. AccountingRule sum враховує суму read і write в межах однієї квоти, що відповідає фактичному обліку за тарифом із лімітом трафіку.

Також задайте AccountingStart, а не лише AccountingMax. Квота визначає обсяг, а start line — період, на початку якого вона скидається. Квота без періоду залишає relay у режимі hibernation, і його ніщо не виведе з цього стану.

Hibernation — це грубий механізм. Коли квоту вичерпано, tor записує це в журнал і припиняє приймати роботу:

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

Relay не виходить із цього стану точно на початку наступного періоду. Tor відстежує, з якою швидкістю було використано попередню квоту, і вибирає випадковий момент у межах нового інтервалу, щоб тисячі relay не поверталися в мережу тієї самої секунди. Relay, який зникає протягом останнього тижня кожного місяця, постійно втрачає стабільність, яку 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 і побудували через нього circuit. Поки цей рядок не з’явиться, ваш relay відсутній у directory і взагалі не обробляє трафік. Помилка має такий вигляд:

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? Чи відкритий він також в окремому мережевому firewall у вашого провайдера? Чи є адреса в цьому повідомленні адресою, на яку вас справді маршрутизує інтернет, а не приватною адресою з NAT? Перевірте порт з іншої машини за допомогою nc -vz 203.0.113.10 9001. Tor самостійно повторює self-test, тому виправлений firewall буде виявлено без додаткових дій, а перезапуск дає змогу виконати перевірку негайно.

Постійний ідентифікатор вашого relay — його fingerprint:

sudo cat /var/lib/tor/fingerprint

Приблизно через три години після публікації descriptor relay з’явиться в Relay Search. Виконайте пошук за nickname або вставте fingerprint. Ця сторінка показує, як мережа бачить ваш relay: які flags він має, яку weight йому надають authorities і яку версію він публікує.

Чому новий Tor relay майже не отримує трафіку?

Тому що мережа ще не встигла його виміряти, а вимірювання триває кілька тижнів. Tor Project описує цей процес у чотири етапи. Оператор, який не ознайомився з ним, вирішує, що relay несправний, і починає щось змінювати.

Протягом перших трьох днів relay не вимірюється. Він передає результат власного self-test, але directory authorities все одно обмежують опубліковану вагу значенням 20 KB, тому клієнти майже ніколи його не обирають. Приблизно з третього до восьмого дня bandwidth authorities вимірюють його фактичну пропускну здатність, і вага зростає. Проте relay використовується лише як middle hop, оскільки жоден клієнт не готовий призначити абсолютно новий relay першим hop.

Приблизно на восьмий день relay отримує право на Guard flag. Після отримання цього прапорця трафік зменшується, що дивує операторів. Під час вибору middle hop клієнти не використовують guard, припускаючи, що він уже зайнятий. Тому relay втрачає middle-трафік раніше, ніж починає отримувати guard-трафік. Обсяг трафіку відновлюється лише в міру того, як клієнти змінюють свої набори guard, а це триває кілька тижнів. Приблизно на 68-й день relay досягає стабільного стану: кількість клієнтів, які його вилучають, зрівнюється з кількістю клієнтів, які його додають.

Отже, реалістичні очікування такі: протягом трьох днів — нічого, приблизно через тиждень — певний трафік, а через два місяці — помітне навантаження. Змініть один параметр і зачекайте тиждень, щоб оцінити результат. Самостійно розгорнута status page Uptime Kuma з TCP-перевіркою порту 9001 краще допоможе спрямувати занепокоєння: вона відповідає на запитання, яке ви справді можете контролювати, — чи продовжує порт приймати з’єднання.

Перегляд relay за допомогою nyx

nyx — це термінальний монітор для запущеного relay. Він підключається до control port Tor, тому спочатку увімкніть його в torrc:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort приймає підключення лише на 127.0.0.1, а cookie authentication означає, що програма має прочитати секретний файл, перш ніж надсилати команди. Tor записує цей cookie у /run/tor/control.authcookie від імені користувача debian-tor з mode 600, тому інші користувачі не можуть його прочитати. CookieAuthFileGroupReadable 1 відкриває доступ до нього для групи. Завдяки цьому ваш обліковий запис може запускати nyx без sudo.

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

Вийдіть із системи та увійдіть знову, потім запустіть nyx. Нова група має бути застосована під час входу, тому запуск nyx у тому самому shell-сеансі спричинить помилку доступу до cookie-файлу, навіть якщо конфігурацію налаштовано правильно. nyx показує поточну пропускну здатність, час роботи, потік журналу та список підключень. У перші тижні стежте за тим, щоб графік пропускної здатності залишався нижче вашого RelayBandwidthRate.

Запуск кількох relay: MyFamily і ключі family

Якщо використовується один relay, пропустіть цей розділ. Два або більше relay, якими керує один оператор, мають оголошувати один одного. Це не дає клієнтам будувати circuit, який входить і виходить через ваші машини. Інакше один оператор міг би бачити обидва кінці такого circuit.

Тривалий час для цього в torrc кожного relay використовували MyFamily. У ньому зазначали fingerprint усіх інших relay:

MyFamily AAAAAAAAAA,BBBBBBBB

Кожен relay містить список усіх інших relay. Тому додавання четвертого relay потребує редагування чотирьох файлів. У Tor 0.4.9 цей підхід замінили ключем family. Згенеруйте один ключ, а потім поширте його:

tor --keygen-family myfamily

Команда записує myfamily.secret_family_key і виводить рядок FamilyId. Скопіюйте файл ключа на кожен relay у підкаталог keys каталогу DataDirectory (/var/lib/tor/keys у Debian та Ubuntu), зберігши суфікс .secret_family_key. Додайте виведений рядок FamilyId до кожного torrc і перезавантажте конфігурацію за допомогою sudo systemctl reload tor@default. Поки що також залиште список MyFamily. Клієнти, які ще не підтримують family certificates, продовжують читати застарілий список. Tor Project повідомить, коли його можна буде видалити.

Що виходить з ладу після запуску

Версія застаріває. Автоматичні оновлення замінюють пакет, але запущений процес продовжує використовувати бінарний файл, з яким його було запущено, доки щось не перезапустить процес. Порівняйте tor --version на сервері з версією, указаною на сторінці Relay Search ретранслятора. Якщо версії відрізняються, мережа й далі бачить стару версію, тому перезапустіть сервіс.

Годинник відстає. Документи консенсусу та сертифікати мають обмежений термін дії, тому машина з неточним системним часом відхиляє консенсус і припиняє публікацію. Команда timedatectl має повідомляти, що системний годинник синхронізований. Якщо це не так, увімкніть systemd-timesyncd або встановіть chrony.

IP-адреса змінюється. Дескриптор містить адресу, а клієнти не можуть підключитися до адреси, яка змінилася. Після міграції до іншого провайдера або будь-якої зміни адреси перезапустіть tor і знову перевірте рядок самотестування.

Ретранслятор працює повільніше, ніж допускає тарифний план. Криптографія ретранслятора Tor ефективно працює на сучасних процесорах, а Tor Project оцінює пропускну здатність процесора з підтримкою AES-NI приблизно у 400–450 Mbit/s у кожному напрямку. Задовго до досягнення цього обмеження пропускну здатність визначатимуть швидкість порту та дозволений обсяг передавання даних. Саме тому наведений вище розділ про облік трафіку важливіший за апаратне забезпечення.

FAQ

Скільки пропускної здатності використовує ретранслятор Tor?

Стільки, скільки ви дозволите, і не більше. RelayBandwidthRate окремо обмежує ретрансльований трафік у кожному напрямку, тому ретранслятор із лімітом 1 Mbit/s може одночасно передавати 1 Mbit/s на вхід і 1 Mbit/s на вихід. Це становить приблизно 21.6 GB на день або 648 GB за місяць тривалістю 30 днів, якщо враховувати обидва напрямки. Додайте AccountingMax із AccountingRule sum як жорсткий місячний ліміт під цим значенням.

Чи отримуватиму я скарги на зловживання, якщо запущу ретранслятор Tor?

Guard- або middle-ретранслятор передає трафік лише іншим ретрансляторам Tor і не підключається до вебсайту від імені користувача. Тому скарги на дії, виконані кимось через Tor, надходять оператору exit-ретранслятора, а не вам. Ви можете побачити сканування та окремі записи у списках репутації IP-адрес, оскільки адресу публічно вказано як адресу ретранслятора. Саме exit-ретранслятори отримують листи про зловживання та юридичні повідомлення. Для них потрібен провайдер, який заздалегідь погодився їх опрацьовувати. Перед запуском будь-якого з цих типів ретранслятора ознайомтеся з умовами провайдера.

Чому мій новий ретранслятор Tor не отримує трафік?

Тому що нові ретранслятори навмисно обмежуються, доки не будуть виміряні. Протягом перших трьох днів directory authorities обмежують опубліковану вагу значенням 20 KB, тому клієнти майже ніколи не обирають цей ретранслятор. Bandwidth authorities вимірюють його приблизно з третього дня. Приблизно на восьмий день він отримує право на прапорець Guard, і в цей момент трафік знову зменшується, оскільки під час вибору middle-вузлів клієнти уникають guard-ретрансляторів. Повне навантаження з’являється приблизно на 68-й день. Переконайтеся, що в журналі є повідомлення "Self-testing indicates your ORPort is reachable from the outside", а потім не змінюйте конфігурацію.

Чи можна запустити ретранслятор Tor на VPS із дозволеним обсягом передавання 1 TB?

Так, приблизно на швидкості 1 Mbit/s у кожному напрямку, тобто RelayBandwidthRate 125 KBytes. Це становить приблизно 648 GB на місяць, якщо провайдер обліковує обидва напрямки, і залишає запас для оновлень та резервних копій. Додайте AccountingMax 400 GBytes із AccountingRule sum і AccountingStart month 1 00:00, щоб ретранслятор переходив у режим гібернації, а не перевищував ліміт тарифного плану. Якщо провайдер обліковує лише вихідний трафік, швидкість можна подвоїти.

Чи потрібно задавати MyFamily, якщо я запускаю лише один ретранслятор?

Ні. Декларації сімей потрібні для того, щоб клієнти не будували ланцюжок через два ретранслятори, якими керує один оператор. Для одного ретранслятора це не має сенсу. Задайте цей параметр одразу після додавання другого ретранслятора: укажіть fingerprint кожного ретранслятора в рядку MyFamily кожного ретранслятора або використайте ключ family, представлений у Tor 0.4.9, який поширює один FamilyId замість списку, що постійно зростає.