SSD Nodes Learn Hosting plans →
Przewodniki Matt ConnorAutor: Matt Connor

Jak uruchomić most Tor z obfs4 na własnym VPS

Konfiguracja mostu Tor z transportem obfs4 na serwerze VPS. Instrukcja zawiera parametry pliku torrc, ustawienia firewalla, wybór portów oraz weryfikację logów działania.

Czym jest most Tor i dlaczego istnieje

Most Tor to punkt wejściowy do sieci Tor, którego adres nie jest publikowany na publicznej liście przekaźników. Lista ta, zwana konsensusem, jest podpisanym dokumentem, który może pobrać każdy, w tym również cenzor. Zablokowanie sieci Tor za jej pomocą zajmuje jedno popołudnie: wystarczy pobrać konsensus, a następnie zablokować na granicy sieci każdy znajdujący się na nim adres. Mosty istnieją, ponieważ opublikowana lista jest słabym punktem. Adresy mostów są udostępniane po kilka sztuk, więc pojedyncze żądanie nie ujawnia całego zestawu.

Niepubliczny adres to tylko połowa rozwiązania. Głęboka inspekcja pakietów (DPI), która klasyfikuje ruch na podstawie jego zawartości, a nie adresu, rozpoznaje połączenie Tor po charakterystyce jego handshake'u TLS (transport layer security). Cenzor nieposiadający listy nadal może stwierdzić, że ruch wygląda jak Tor i zerwać połączenie. Pluggable transport usuwa ten sygnał. Opakowuje on strumień Tor w inną formę po stronie klienta, a most dokonuje jego rozpakowania.

obfs4 to transport używany przez większość mostów. Przekształca on strumień w bajty pozbawione nagłówka i stałego handshake'u, dzięki czemu DPI nie znajduje wzorca do dopasowania. Protokół ten uwierzytelnia również klienta. Wartość cert= w linii mostu to klucz, który klient musi posiadać, aby most w ogóle odpowiedział. Zapobiega to aktywnemu sondowaniu: cenzor, który łączy się z adresem, aby sprawdzić, czy obsługuje on Tor, nie otrzymuje żadnej odpowiedzi i nie uzyskuje żadnych informacji.

Który pluggable transport uruchomić?

  • obfs4 wymaga jednego VPS, dwóch portów TCP i nie potrzebuje nazwy domenowej. Jest to najprostsze użyteczne rozwiązanie, które można uruchomić, i stanowi przedmiot tego przewodnika.
  • WebTunnel ukrywa połączenie wewnątrz zwykłego ruchu HTTPS kierowanego do rzeczywistej witryny internetowej. Tor Project określa wymagania jako: statyczny adres IPv4 (jeśli to możliwe), kontrolowaną domenę, działający serwer WWW, taki jak NGINX lub Apache, ważny certyfikat TLS oraz co najmniej 1 GB pamięci RAM (zalecane 4 GB). Rozwiązanie to sprawdza się w sieciach, w których ruch o losowym wyglądzie jest podejrzany, ponieważ kraje ograniczające dostęp do sieci zazwyczaj zezwalają na ruch HTTPS.
  • Snowflake to inny rodzaj wkładu. Wolontariusze uruchamiają krótkotrwałe proxy WebRTC, dzięki czemu punkty wejściowe stale się zmieniają, a cenzor nie ma stałego adresu do zablokowania. W tym przypadku nie obsługuje się mostka. Uruchamia się proxy, które nie wymaga stałego adresu.

Należy zacząć od obfs4. Mostek WebTunnel można dodać później, na drugim adresie: uruchomienie obu na jednym adresie IP oznacza, że zablokowanie tego adresu wyeliminuje oba rozwiązania.

Jakie są koszty utrzymania mostka?

WykresTor Project published minimum bandwidth, October 2026
Dane, na których opiera się ten wykres
[
  {
    "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
  }
]

Według stanu na październik 2026 roku Tor Project wymaga od mostka przepustowości wysyłania i pobierania na poziomie co najmniej 1 Mbit/s. Od przekaźnika typu guard lub middle relay wymaga się 10 Mbit/s, przy czym zalecane jest 16 Mbit/s. Są to opublikowane wymagania, a nie pomiary. Nowy mostek zazwyczaj przez wiele tygodni utrzymuje się znacznie poniżej własnego minimum. Ta sama strona z wymaganiami określa dla przekaźnika limit co najmniej 100 GB ruchu wychodzącego miesięcznie, co pokrywają już najmniejsze plany hostingowe, dlatego przed wyborem większej instancji warto sprawdzić ile faktycznie kosztuje mały VPS miesięcznie.

Powierzchnia nadużyć jest niewielka i jest to kwestia często błędnie rozumiana. Mostek jest pierwszym przeskokiem. Ruch opuszczający serwer trafia do innego przekaźnika sieci Tor, a nie bezpośrednio do witryny wybranej przez użytkownika. Adres IP operatora nigdy nie pojawia się w logach serwerów WWW jako źródło żądania, więc wiadomości z reklamacjami, z którymi mierzą się operatorzy exit relay, tutaj nie docierają. Mimo to należy sprawdzić regulamin dostawcy (AUP), ponieważ niektórzy usługodawcy traktują każdą usługę Tor jako przypadek szczególny. Mostek i usługa onion są pod tym względem swoimi lustrzanymi odbiciami: mostek jest użyteczny tylko wtedy, gdy jego adres jest osiągalny i ostatecznie udostępniany, podczas gdy usługa v3 onion na tym samym typie VPS jest użyteczna tylko wtedy, gdy publiczny adres IP pozostaje ukryty.

Czego nie należy robić: nie należy przekształcać istniejącego publicznego przekaźnika w mostek pod tym samym adresem. Zalecenie Tor Project w takim przypadku brzmi: należy zmienić „adres IP, nazwę oraz odcisk palca (fingerprint)”, ponieważ stary adres znajduje się już w konsensusie pobieranym przez systemy cenzurujące. Mostek, który w zeszłym tygodniu był publicznym przekaźnikiem, jest mostkiem, który znajduje się już na czarnej liście.

Czas pracy (uptime) jest ważniejszy niż prędkość. Wymagania dotyczące przekaźników mówią, że „jeśli przekaźnik nie działa przez ponad 2 godziny dziennie, jego użyteczność jest ograniczona”. W przypadku mostka sytuacja jest jeszcze trudniejsza, ponieważ każdy klient ma tylko jeden adres i brak mechanizmu przełączania awaryjnego. Restart powoduje rozłączenie wszystkich użytkowników. Warto skonfigurować sprawdzanie portu TCP w Uptime Kuma dla portu obfs4, aby otrzymać powiadomienie w dniu, w którym usługa przestanie odpowiadać.

Instalacja Tor z repozytorium Tor Project

Pakiety dystrybucyjne są przestarzałe, a bridge jest oprogramowaniem zabezpieczającym, które powinno być aktualne. Najpierw należy dodać repozytorium projektu.

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

Teraz należy utworzyć plik źródłowy. Linia Suites: musi zawierać nazwę kodową wydania, dlatego należy odczytać ją z systemu zamiast wpisywać z pamięci.

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

Jeśli apt update zgłosi, że repozytorium nie posiada pliku Release dla danej nazwy kodowej, oznacza to, że Tor Project nie wspiera tego wydania. Należy usunąć /etc/apt/sources.list.d/tor.sources, ponownie uruchomić sudo apt update i zainstalować pakiet tor dostarczany przez dystrybucję. Wszystkie poniższe kroki pozostają bez zmian.

Pakiet obfs4proxy pochodzi bezpośrednio z Debian i Ubuntu (wersja 0.0.14 w Debian 13, stan na październik 2026). Należy potwierdzić lokalizację pliku binarnego, ponieważ jego ścieżka jest wymagana w konfiguracji:

command -v obfs4proxy || command -v lyrebird

Twórcy zmienili nazwę projektu na lyrebird, więc nowszy pakiet może instalować /usr/bin/lyrebird. Należy użyć ścieżki zwróconej przez to polecenie.

Konfiguracja bridge w /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

Każda z tych linii wiąże się z ryzykiem błędu, dlatego należy je analizować pojedynczo.

BridgeRelay 1 instruuje tor, aby wysyłał deskryptor do bridge authority zamiast do publicznego konsensusu. Ta pojedyncza linia sprawia, że przekaźnik nie jest wymieniony na publicznych listach.

ORPort to właściwy port ORPort. Musi być on osiągalny z Internetu, ponieważ tor testuje go i odmawia publikacji deskryptora, dopóki test nie zakończy się powodzeniem.

ServerTransportPlugin przekazuje polecenie uruchomienia dla tor. tor uruchamia obfs4proxy jako proces potomny i komunikuje się z nim przez potok, dlatego obfs4proxy nie posiada własnej jednostki serwisowej i nigdy nie pojawia się w systemctl status.

ServerTransportListenAddr ustala port, na którym nasłuchuje obfs4proxy. Pominięcie tej linii spowoduje, że obfs4proxy wybierze wolny port przy starcie, a po większości restartów inny, co sprawi, że każda udostępniona linia bridge będzie wskazywać na port, na którym nikt nie nasłuchuje. Klienci otrzymają odmowę połączenia i przestaną podejmować próby.

ExtORPort auto otwiera rozszerzony ORPort, czyli kanał loopback, którego obfs4proxy używa do przekazywania zakończonych połączeń z powrotem do tor wraz z adresem klienta. Przewodnik konfiguracji The Tor Project uwzględnia go w każdym bridge, ponieważ bez niego transport nie może zgłosić tego adresu do tor.

ContactInfo oraz Nickname są publiczne. Należy użyć adresu, który jest sprawdzany, ponieważ w ten sposób The Tor Project kontaktuje się w sprawie awarii bridge, oraz wybrać pseudonim, który nie identyfikuje użytkownika, jeśli wymagana jest dyskrecja.

BridgeDistribution określa dystrybutor, który przekazuje adres użytkownikom. Akceptowane wartości to https, email, telegram, settings, none oraz any. Należy użyć any dla pierwszego bridge i pozwolić systemowi na wybór. Należy użyć none dla prywatnego bridge udostępnianego samodzielnie, co całkowicie wyklucza adres z publicznej dystrybucji.

Dlaczego wybór portu ma znaczenie

Należy unikać używania portu 9001 dla obu usług. Tor Project wyraźnie odradza takie rozwiązanie, ponieważ 9001 to tradycyjny port ORPort, a systemy cenzury skanują pod jego kątem całą sieć. Oba porty muszą się od siebie różnić, gdyż tor oraz obfs4proxy uruchamiają własne procesy nasłuchujące.

Najlepszym wyborem dla obfs4 jest port 443. Ruch wychodzący na porcie 443 jest dozwolony w niemal każdej restrykcyjnej sieci, a długotrwałe połączenie z nim wygląda jak zwykła sesja przeglądarki. Powiązanie usługi z portem poniżej 1024 wymaga dodatkowego kroku, ponieważ obfs4proxy nie działa z uprawnieniami root:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

W każdym otwartym edytorze należy dodać poniższe dwie linie:

[Service]
NoNewPrivileges=no

Sama zdolność (capability) nie wystarczy. Ustawienie NoNewPrivileges w systemd uniemożliwia procesowi uzyskanie jakichkolwiek uprawnień, których nie posiadał proces nadrzędny, a zdolność pliku jest właśnie takim uprawnieniem. W rezultacie obfs4proxy nie może powiązać się z portem 443, dopóki to ustawienie pozostaje aktywne.

Jeśli wolisz pominąć ten krok, wybierz dowolny wysoki port i zanotuj go. Niezależnie od wyboru, nie zmieniaj portu obfs4 w przyszłości. Linia mostka (bridge line) wiąże ze sobą adres, port, odcisk palca (fingerprint) oraz certyfikat, więc każda kopia zapisana w przeglądarce użytkownika przestanie działać w momencie zmiany portu.

Otwarcie portów na obu zaporach sieciowych

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

Oba porty muszą być otwarte. Większość dostawców stosuje drugą zaporę sieciową w panelu sterowania, o której ufw nie posiada informacji. Reguła istniejąca na serwerze, lecz nie w panelu, tworzy most, który pozostaje nieosiągalny i nigdy nie publikuje deskryptora. Jeśli którykolwiek z tych elementów jest nowy, reguły ufw wymagane dla nowego VPS oraz czym w systemie Linux jest port nasłuchujący zawierają niezbędne wyjaśnienia. Przy okazji warto zabezpieczyć SSH za pomocą kluczy oraz wzmocnionej konfiguracji sshd. Niezabezpieczony most na serwerze z uwierzytelnianiem hasłem SSH nadal pozostaje serwerem z uwierzytelnianiem hasłem SSH.

Uruchomienie i odczyt dziennika

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Systemy Debian i Ubuntu dostarczają dwie jednostki. tor.service to niewielki skrypt opakowujący, a tor@default.service to proces wykonujący właściwe zadania. Z tego powodu journalctl -u tor wydaje się niemal puste, podczas gdy poszukiwany dziennik znajduje się pod tor@default.

Dwie linie potwierdzają poprawne działanie:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

Pierwsza oznacza, że test osiągalności zakończył się powodzeniem, a deskryptor został wysłany do bridge authority. Jeśli komunikat się nie pojawia, oznacza to, że jakiś element między Internetem a serwerem blokuje ruch do ORPort. Druga linia musi wskazywać port skonfigurowany w pliku. Inny port oznacza, że tor nie zastosował ServerTransportListenAddr. Najczęstszą przyczyną jest niezgodność nazwy transportu: musi ona brzmieć obfs4 w obu dyrektywach.

Potwierdź istnienie obu procesów nasłuchujących:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

Gdzie znajduje się moja linia bridge?

obfs4proxy zapisuje szablon w katalogu danych tor:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

Katalog ten należy do użytkownika tor i posiada uprawnienia 700, więc bez sudo wystąpi błąd Permission denied. Plik zawiera linię o następującym formacie:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Należy zastąpić <IP ADDRESS> publicznym adresem serwera, <PORT> portem obfs4 (nie ORPort), a <FINGERPRINT> odciskiem palca (identity fingerprint), który tor zapisał w swoim katalogu danych:

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

Pierwszy plik zawiera nazwę (nickname) oraz odcisk palca, który należy umieścić w linii bridge. Drugi zawiera zahaszowany odcisk palca, który wkleja się w Relay Search, aby sprawdzić, czy bridge działa i ilu klientów mniej więcej z niego korzysta. Te dwie wartości nie są zamienne. Linia bridge zawierająca zahaszowaną wartość nie pasuje do klucza tożsamości prezentowanego przez bridge, przez co klient odrzuca właśnie otwarte połączenie.

W jaki sposób bridge faktycznie dociera do użytkowników?

Linia bridge nie jest przekazywana nikomu osobiście. Gdy deskryptor dotrze do bridge authority, system dystrybucji (rdsys, następca BridgeDB) przypisuje bridge do jednego z dystrybutorów, a użytkownicy zwracają się do niego z prośbą o bridge. Według stanu na październik 2026 roku ścieżki dystrybucji są następujące:

  • Strona internetowa bridge pod adresem bridges.torproject.org/options, gdzie opcja "Just give me bridges!" natychmiast zwraca linie obfs4. Nie ma tam captchy: Tor Project usunął ją, gdy rdsys zastąpił BridgeDB, co ogłoszono w grudniu 2024 roku.
  • Wiadomość e-mail wysłana na adres bridges@torproject.org z konta Gmail lub Riseup, w odpowiedzi na którą przesyłane są linie bridge. Ograniczenie dostawców istnieje, ponieważ nieograniczone darmowe konta pozwoliłyby cenzorowi na wyliczenie wszystkich dostępnych bridge'y.
  • Bot na Telegramie @GetBridgesBot. Należy wysłać /start, a następnie /obfs4 lub /webtunnel.
  • Przeglądarka Tor Browser, w sekcji Ustawienia, a następnie Połączenie, gdzie opcja "Request bridges" pobiera je przez kanał moat.

Nowy bridge pojawia się w Relay Search około trzy godziny po konfiguracji. Użytkownicy pojawiają się znacznie później: według oficjalnych informacji Tor Project "może minąć kilka dni lub tygodni, zanim zaobserwujesz stałą grupę użytkowników". Spokojne pierwsze dwa tygodnie są zjawiskiem normalnym, a nie błędem.

Ustawienie BridgeDistribution none wyłącza wszystkie powyższe mechanizmy. Linia bridge pozostaje wtedy do wyłącznej dyspozycji administratora, który może ją przekazać potrzebującym osobom za pośrednictwem kanału, który nie jest monitorowany przez cenzora.

Gdy coś nie działa

Brak linii autotestu w dzienniku. ORPort jest nieosiągalny. Należy przetestować go z innej maszyny za pomocą nc -vz your.ip 8443. Zawieszenie oznacza, że pakiety są odrzucane, więc należy sprawdzić ufw oraz panel dostawcy. Odmowa połączenia oznacza, że tor nie nasłuchuje, więc należy sprawdzić ss -lntp i odczytać dziennik w poszukiwaniu błędu konfiguracji.

Zarejestrowany transport wskazuje port, którego nie wybrano. tor zignorował ServerTransportListenAddr. Nazwa transportu musi być dokładnie zgodna z tą w ServerTransportPlugin, a obie muszą być obfs4.

obfs4proxy nie może powiązać portu 443. Należy potwierdzić uprawnienia za pomocą getcap /usr/bin/obfs4proxy, a następnie sprawdzić, czy nadpisanie dotarło do jednostki za pomocą systemctl show tor@default -p NoNewPrivileges. Jeśli polecenie to wyświetli NoNewPrivileges=yes, plik typu drop-in został przypisany do niedziałającej jednostki.

Brak zawartości w /var/lib/tor/pt_state/. tor nie uruchomił transportu, co oznacza, że ścieżka w ServerTransportPlugin jest błędna. Należy porównać ją z wynikiem command -v obfs4proxy.

Klienci przestali się łączyć po wprowadzeniu zmian. Każda zmiana adresu lub portu obfs4 unieważnia wszystkie linie bridge, które zostały już rozpowszechnione. Należy sprawdzić, czy publiczny adres IP serwera również uległ zmianie, co zdarza się podczas przebudowy instancji u niektórych dostawców.

tor w ogóle się nie uruchamia. Należy wykonać sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. Polecenie to analizuje plik, wyświetla linię, do której zgłasza zastrzeżenia, i nie wpływa na działającą usługę.

FAQ

Czy dostawca VPS będzie zgłaszał zastrzeżenia do mostka Tor?

Mostek jest punktem wejściowym, więc ruch opuszczający serwer kierowany jest do innych przekaźników sieci Tor, a nie do witryn odwiedzanych przez użytkowników. Adres IP serwera nie pojawia się w logach stron jako źródło żądania, co eliminuje skargi, z którymi mierzą się operatorzy przekaźników wyjściowych. Zasady hostingu różnią się jednak w zależności od dostawcy, a niektórzy traktują każdą usługę Tor jako przypadek szczególny. Należy zapoznać się z regulaminem świadczenia usług przed rozpoczęciem pracy i podać adres e-mail do kontaktu w ContactInfo.

Ile pasma zużywa mostek Tor?

Publikowane minimum to 1 Mbit/s w górę i w dół, w porównaniu do 10 Mbit/s dla przekaźnika typu guard lub middle. Rzeczywiste zużycie zaczyna się od zera, ponieważ mostek obsługuje ruch tylko dla użytkowników skierowanych przez dystrybutorów. Aby nałożyć sztywny limit, należy ustawić RelayBandwidthRate oraz RelayBandwidthBurst w pliku torrc.

Dlaczego nikt nie połączył się z moim nowym mostkiem?

Pojawienie się mostka w Relay Search zajmuje około trzech godzin, a według wytycznych Tor Project zbudowanie stałej grupy użytkowników trwa od kilku dni do kilku tygodni. Należy sprawdzić, czy deskryptor został opublikowany (wiersz self-testing w journalctl -u tor@default), wyszukać zahaszowany odcisk palca (fingerprint) w Relay Search oraz upewnić się, że BridgeDistribution nie jest ustawione na none.

Czy uruchomić obfs4 czy WebTunnel?

W przypadku pierwszego mostka należy wybrać obfs4: jeden VPS, dwa porty, brak domeny, brak certyfikatu. WebTunnel należy uruchomić tam, gdzie ruch wyglądający na losowy jest blokowany, ponieważ wymaga on posiadania domeny, działającego serwera WWW, ważnego certyfikatu TLS oraz co najmniej 1 GB pamięci RAM. W przypadku uruchamiania obu usług należy przypisać je do różnych adresów IP, aby zablokowanie jednego adresu nie wyeliminowało obu mostków jednocześnie.

Co się stanie, jeśli zmienię port obfs4 w późniejszym czasie?

Każda już rozpowszechniona linia mostka przestanie działać. Linia mostka wiąże ze sobą adres, port, odcisk palca oraz certyfikat, więc klient posiadający starą linię próbuje nawiązać połączenie z portem, na którym nie ma nasłuchującej usługi, i przerywa próbę. To samo dotyczy zmiany publicznego adresu IP serwera. Port należy wybrać podczas konfiguracji i pozostawić go bez zmian.