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

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

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

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

obfs4 — це transport, який використовує більшість bridge. Він перетворює потік на байти без заголовка та фіксованого handshake, тому DPI не має шаблону для розпізнавання. Він також автентифікує клієнта. Значення cert= у bridge line є ключем, володіння яким клієнт має довести, перш ніж 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 Mbit/s пропускної здатності в обох напрямках. Для guard або middle relay потрібно 10 Mbit/s, а рекомендоване значення становить 16 Mbit/s. Це опубліковані вимоги, а не виміряні показники. Новий bridge зазвичай протягом кількох тижнів працює зі значно меншим навантаженням, ніж його мінімальна вимога. На цій самій сторінці з вимогами relay рекомендується щонайменше 100 GByte вихідного трафіку на місяць. Найменші тарифні плани вже покривають цей обсяг, тому перед вибором більшого тарифу прочитайте скільки насправді коштує невеликий VPS на місяць.

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

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

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

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, доки цей параметр увімкнено.

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

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

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

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

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

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> — на відбиток ідентичності, який tor записав у каталог даних:

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

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

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

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

• Вебсайт bridges за адресою bridges.torproject.org/options, де пункт "Just give me bridges!" одразу повертає рядки obfs4. CAPTCHA немає: Tor Project видалив її після заміни BridgeDB на rdsys. Про цю зміну проєкт повідомив у December 2024.
• Електронний лист на bridges@torproject.org із адреси Gmail або Riseup. У відповідь надходять рядки bridge. Обмеження на провайдерів потрібне тому, що необмежені безкоштовні облікові записи дозволили б одному цензору перелічити всі bridge.
• Telegram-бот @GetBridgesBot. Надішліть /start, а потім /obfs4 або /webtunnel.
• Сам Tor Browser: відкрийте Settings, потім Connection. Пункт "Request bridges" отримує bridge через канал 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. Перевірте наявність відповідної capability за допомогою 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 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-адреса сервера. Виберіть порт під час налаштування та більше його не змінюйте.