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

Що таке Tor bridge і навіщо він потрібен

Tor bridge — це точка входу до мережі Tor, адресу якої не публікують у загальному списку relay. Цей список називається consensus. Це підписаний документ, який може завантажити будь-хто, зокрема й цензор. Заблокувати Tor за цим списком можна за один день: завантажити consensus, а потім заблокувати всі адреси з нього на кордоні мережі. Bridge потрібні тому, що опублікований список є слабким місцем. Адреси bridge видають невеликими порціями, тому один запит не розкриває весь набір.

Непублікована адреса — це лише частина рішення. Deep packet inspection (DPI), який класифікує network traffic за вмістом, а не за адресою, розпізнає Tor-з’єднання за структурою його TLS (transport layer security) handshake. Цензор, який не має списку адрес, усе одно може побачити: «це схоже на Tor» — і заблокувати з’єднання. Pluggable transport усуває цю ознаку. На стороні клієнта він загортає Tor stream в інший протокол, а ваш bridge розгортає цю оболонку.

obfs4 — це transport, який використовує більшість bridge. Він перетворює stream на байти без заголовка та фіксованого handshake, тому DPI не має шаблону для розпізнавання. Він також автентифікує клієнта. Значення cert= у bridge line — це cryptographic key, наявність якого клієнт має довести до того, як bridge взагалі відповість. Це протидіє active probing: цензор, який підключається до вашої адреси, щоб перевірити, чи працює там Tor, не отримує відповіді й не дізнається нічого.

Який pluggable transport слід використовувати?

• obfs4 потребує одного VPS, двох TCP-портів і доменного імені. Це найпростіший корисний варіант, який можна запустити, і саме йому присвячено цей посібник.
• WebTunnel приховує з’єднання всередині звичайного HTTPS-трафіку до реального вебсайту. Tor Project вказує такі вимоги: статична IPv4-адреса, домен під вашим контролем, робочий вебсервер, наприклад NGINX або Apache, чинний TLS-сертифікат і щонайменше 1 GB RAM; рекомендовано 4 GB. Цей варіант підходить для мереж, де сам по собі трафік із випадковим виглядом викликає підозру, оскільки країна, у якій дозволено небагато іншого, крім перегляду вебсайтів, усе одно дозволяє HTTPS.
• Snowflake — це інший спосіб допомогти мережі Tor. Волонтери запускають короткоживучі WebRTC-проксі, тому точки входу постійно змінюються, і цензору немає стабільної адреси для блокування. Для цього не потрібно адмініструвати bridge. Потрібно запустити proxy, і фіксована адреса йому не потрібна.

Почніть з 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 Project вимагає від bridge щонайменше 1 Мбіт/с пропускної здатності на вхід і вихід. Для guard або middle relay вимагається 10 Мбіт/с, а рекомендоване значення становить 16 Мбіт/с. Це опубліковані вимоги, а не фактичні вимірювання. Новий bridge зазвичай протягом кількох тижнів працює значно нижче власного мінімального показника. На цій самій сторінці з вимогами зазначено, що relay має передавати щонайменше 100 GByte даних на місяць. Найменші тарифні плани це вже покривають, тому спочатку ознайомтеся з фактичною щомісячною вартістю невеликого VPS, перш ніж обирати більшу конфігурацію.

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

Не перетворюйте наявний публічний relay на bridge, зберігаючи ту саму адресу. Для такого випадку Tor Project радить змінити «IP address, name and fingerprint», оскільки стара адреса вже міститься в consensus, який завантажують цензори. Bridge, що минулого тижня був публічним relay, уже може бути у blocklist.

Час безперервної роботи важливіший за швидкість. У вимогах до relay зазначено: «якщо ваш relay не працює понад 2 години на день, його користь обмежена». Для bridge це ще критичніше, оскільки кожен клієнт має одну адресу й не має резервного варіанта. Перезапуск від’єднає всіх користувачів, підключених до нього. Налаштуйте перевірку 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

Тепер створіть файл джерела пакетів. У рядку 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

Якщо apt update повідомляє, що для вашого codename у репозиторії немає Release-файлу, Tor Project не підтримує цей реліз. Видаліть /etc/apt/sources.list.d/tor.sources, знову виконайте sudo apt update і встановіть пакет tor, який постачається разом із вашим дистрибутивом. Усе наведене нижче залишається без змін.

Пакет obfs4proxy постачається безпосередньо з Debian і Ubuntu (версія 0.0.14 у Debian 13 станом на August 2026). Перевірте, де розташований бінарний файл, оскільки його шлях буде вказано в конфігурації:

command -v obfs4proxy || command -v lyrebird

Upstream перейменував проєкт на 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 надсилати свій дескриптор до bridge authority, а не до публічного consensus. Саме цей рядок робить relay невидимим у списку.

ORPort — це фактичний порт Tor. Він має бути доступним з Інтернету, оскільки tor перевіряє його й відмовляється публікувати дескриптор, доки перевірка не завершиться успішно.

ServerTransportPlugin задає команду для запуску. tor запускає obfs4proxy як дочірній процес і взаємодіє з ним через pipe, тому obfs4proxy не має власного service unit і ніколи не з’являється в systemctl status.

ServerTransportListenAddr фіксує порт, на якому прослуховує obfs4proxy. Якщо не вказати цей рядок, obfs4proxy вибиратиме вільний порт під час запуску, а після більшості перезапусків — інший порт. У результаті кожен bridge line, який ви вже надали, вказуватиме на порт, де нічого не прослуховується. Клієнти отримають відмову в підключенні та припинять спроби.

ExtORPort auto відкриває розширений ORPort — loopback-канал, який obfs4proxy використовує для передавання встановлених з’єднань назад до tor разом з адресою клієнта. Посібник з налаштування Tor Project містить цей параметр для кожного bridge, оскільки без нього transport не може передати цю адресу до tor.

ContactInfo і Nickname є публічними. Використовуйте адресу, яку ви регулярно читаєте, оскільки саме так Tor Project повідомляє вас про несправний bridge. Якщо ви хочете залишатися непомітним, виберіть nickname, який не дає змоги вас ідентифікувати.

BridgeDistribution визначає, який distributor передаватиме вашу адресу користувачам. Допустимі значення: https, email, telegram, settings, none і any. Для першого bridge використовуйте any і дозвольте системі вибрати значення. Для приватного bridge, який ви роздаєте самостійно, використовуйте none. У такому разі адреса взагалі не потрапляє до публічного розподілу.

Чому вибір портів має значення

Не використовуйте 9001 для обох портів. Tor Project прямо не рекомендує цього, оскільки 9001 є традиційним ORPort, і цензори сканують інтернет у пошуках цього порту. Порти також мають відрізнятися один від одного, оскільки tor і obfs4proxy окремо прив’язуються до власних портів прослуховування.

Найкращий порт для obfs4 — 443. Вихідні з’єднання через 443 відкриті майже в кожній мережі з обмеженнями, а тривале з’єднання з цим портом виглядає як звичайний вебсеанс. Для прив’язування до порту з номером менше 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 не може прив’язатися до 443, доки цей параметр увімкнено.

Якщо ви не хочете виконувати цей крок, виберіть непомітний порт із номером понад 1024 і запишіть його. Що б ви не вибрали, надалі не змінюйте порт obfs4. Рядок bridge пов’язує адресу, порт, fingerprint і certificate в одну конфігурацію, тому кожна його копія, яка вже зберігається у браузері користувача, перестане працювати одразу після зміни порту.

Відкрийте порти в обох firewall

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

Обидва порти мають бути відкриті. Більшість провайдерів також використовує додатковий firewall у панелі керування, про який ufw нічого не знає. Правило, наявне на сервері, але відсутнє в панелі, створює міст, до якого неможливо підключитися і який не публікує descriptor. Якщо будь-яка з цих частин вам незнайома, ознайомтеся з матеріалами правила ufw, потрібні для нового VPS і що насправді означає listening port у Linux. Також обмежте доступ до 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 — це невелика обгортка, а 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'

Перший означає, що перевірку доступності пройдено, а дескриптор передано до bridge authority. Якщо цей рядок не з’являється, щось між інтернетом і сервером відкидає трафік до ORPort. У другому рядку має бути вказано налаштований порт. Інший порт означає, що tor не застосував ServerTransportListenAddr. Зазвичай причина полягає в невідповідності назви transport: в обох директивах має бути obfs4.

Переконайтеся, що обидва слухачі існують:

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

Перший файл містить ваш nickname і fingerprint ідентифікації, які потрібно вказати в рядку bridge. Другий містить хешований fingerprint. Саме його потрібно вставити в Relay Search, щоб перевірити, чи працює ваш bridge і приблизно скільки клієнтів до нього підключається. Ці значення не взаємозамінні. Рядок bridge із хешованим значенням не відповідає ключу ідентифікації, який представляє ваш bridge, тому клієнт відхиляє щойно встановлене з’єднання.

Як bridge фактично доходить до користувачів?

Ви не передаєте рядок bridge будь-кому. Коли descriptor надходить до bridge authority, система розподілу (rdsys, наступник BridgeDB) призначає ваш bridge одному distributor, а користувачі запитують bridge у цього distributor. Станом на August 2026 доступні такі способи:

• Вебформа на bridges.torproject.org/options, яка видає рядки bridge після проходження captcha.
• Надсилання email на bridges@torproject.org з адреси Gmail або Riseup. У відповідь надходять рядки bridge. Обмеження на провайдерів потрібне тому, що необмежена кількість безкоштовних облікових записів дала б змогу одному цензору перелічити всі bridge.
• Telegram-бот @GetBridgesBot. Надішліть /start, а потім /obfs4 або /webtunnel.
• Безпосередньо в Tor Browser: відкрийте Settings, потім Connection, і виберіть "Request bridges", щоб отримати їх через канал moat.

Новий bridge з’являється в Relay Search приблизно через три години після налаштування. Користувачі з’являються значно пізніше: у формулюванні самого Tor Project, "It can take several days or weeks until you see a consistent set of users." Відсутність активності протягом перших двох тижнів є нормальною і не свідчить про несправність.

Параметр BridgeDistribution none вимикає всі ці способи. Після цього рядок bridge можна передати потрібним людям через канал, який цензор не контролює.

Коли щось не працює

У журналі немає рядка про самоперевірку. ORPort недоступний. Перевірте його з іншої машини за допомогою nc -vz your.ip 8443. Якщо команда зависає, пакети відкидаються, тому перевірте ufw і панель керування провайдера. Якщо з’єднання відхилено, tor не прослуховує порт. Перевірте ss -lntp і перегляньте журнал на наявність помилки конфігурації.

Зареєстрований транспорт використовує порт, який ви не вибирали. tor проігнорував ServerTransportListenAddr. Назва транспорту має точно відповідати значенню в ServerTransportPlugin, і обидва значення мають бути obfs4.

obfs4proxy не може прив’язатися до порту 443. Перевірте можливість виконання за допомогою getcap /usr/bin/obfs4proxy, а потім переконайтеся, що перевизначення застосовано до unit, за допомогою systemctl show tor@default -p NoNewPrivileges. Якщо команда виводить NoNewPrivileges=yes, drop-in застосовано до unit, який не запущений.

У /var/lib/tor/pt_state/ нічого немає. tor не запустив транспорт, отже шлях у ServerTransportPlugin неправильний. Порівняйте його з результатом виконання command -v obfs4proxy.

Клієнти перестали підключатися після зміни. Будь-яка зміна адреси або порту obfs4 робить недійсними всі вже поширені bridge lines. Також перевірте, чи не змінилася публічна IP-адреса сервера. У деяких провайдерів це відбувається під час повторного створення сервера.

tor взагалі не запускається. Виконайте sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. Команда аналізує файл, виводить рядок, який спричинив помилку, і не змінює стан запущеного сервісу.

FAQ

Чи поскаржиться мій VPS-провайдер на Tor bridge?

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

Яку пропускну здатність використовує Tor bridge?

Опублікований мінімум становить 1 Mbit/s у напрямку від сервера та до нього. Для guard або middle relay цей показник становить 10 Mbit/s. Фактичне використання спочатку майже нульове, оскільки ваш bridge передає трафік лише користувачів, яких до нього спрямовує distributor. Якщо потрібне жорстке обмеження, задайте RelayBandwidthRate і RelayBandwidthBurst у torrc.

Чому до мого нового bridge ніхто не підключився?

Bridge з’являється в Relay Search приблизно через три години. За рекомендацією Tor Project, стабільний потік користувачів формується протягом кількох днів або тижнів. Перевірте, що descriptor опубліковано. Це рядок самоперевірки у journalctl -u tor@default. Знайдіть свій хешований fingerprint у Relay Search і переконайтеся, що BridgeDistribution не має значення none.

Що краще запустити: obfs4 чи WebTunnel?

Запускайте obfs4, якщо це ваш перший bridge: один VPS, два порти, без домену та сертифіката. Використовуйте WebTunnel там, де блокується сам трафік, що виглядає випадковим. Для нього потрібні домен під вашим контролем, справжній вебсервер, дійсний TLS-сертифікат і щонайменше 1 GB RAM. Якщо запускаєте обидва варіанти, використовуйте окремі адреси. Інакше блокування однієї IP-адреси одночасно вимкне два bridge.

Що станеться, якщо пізніше змінити порт obfs4?

Кожен уже розповсюджений bridge line перестане працювати. Bridge line пов’язує адресу, порт, fingerprint і сертифікат. Тому клієнт зі старим рядком підключається до порту, на якому нічого не прослуховується, і припиняє спробу. Те саме відбувається, якщо змінюється публічна IP-адреса сервера. Виберіть порт під час налаштування та більше його не змінюйте.