Як запустити 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 — це 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 — це інший спосіб зробити внесок. Волонтери запускають короткочасні 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
  }
]

Станом на August 2026 Tor Project вимагає від bridge щонайменше 1 Mbit/s вхідної та вихідної пропускної здатності. Для guard або middle relay потрібно 10 Mbit/s, а рекомендоване значення становить 16 Mbit/s. Це опубліковані вимоги, а не результати вимірювань. Новий bridge зазвичай протягом кількох тижнів працює зі значеннями, значно нижчими за власний мінімум. На тій самій сторінці з вимогами зазначено, що relay має передавати щонайменше 100 GByte даних на місяць. Найменші тарифні плани вже покривають цей обсяг, тому перед вибором більшого ресурсу прочитайте скільки насправді коштує невеликий VPS на місяць.

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

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

Пакет obfs4proxy постачають самі Debian і Ubuntu (версія 0.0.14 у Debian 13 станом на серпень 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, а не до публічного консенсусу. Саме цей рядок робить 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, оскільки без нього транспорт не може передати цю адресу 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 прив’язують кожен свій listener.

Найкращий порт для 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 забороняє процесу отримувати будь-які привілеї, яких не мав його батьківський процес. Файлова capability є саме таким привілеєм, тому obfs4proxy не може прив’язатися до 443, доки цей параметр увімкнено.

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

Відкрийте порти в обох брандмауерах

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

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

Перший означає, що перевірку доступності пройдено, а descriptor передано bridge authority. Якщо цей рядок не з’являється, щось між інтернетом і вашим сервером відкидає network traffic до ORPort. У другому рядку має бути вказаний вами порт. Інший порт означає, що tor не застосував ServerTransportListenAddr. Зазвичай причина полягає в невідповідності назви transport: в обох директивах має бути 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

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

Як міст насправді знаходить користувачів?

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

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

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

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

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

У журналі немає рядка про самоперевірку. 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, які вже розповсюджено. Перевірте також, чи не змінилася публічна 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 приблизно через three hours. За рекомендаціями Tor Project, стабільний потік користувачів формується протягом кількох днів або тижнів. Перевірте, чи опубліковано descriptor, тобто рядок самоперевірки у journalctl -u tor@default, знайдіть ваш hashed fingerprint у Relay Search і переконайтеся, що BridgeDistribution не має значення none.

Чи слід запускати obfs4 або WebTunnel?

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

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

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