Przekaźnik wyjściowy Tor a serwer wyjściowy VPN: co wie każdy z nich
Przekaźnik wyjściowy Tor i serwer wyjściowy VPN pokazują jeden publiczny adres, ale inaczej dzielą wiedzę. Porównaj widoczność, zasięg i politykę portów.
Oba rozwiązania ukrywają twój adres za jednym publicznym IP, a strona, która wypisuje widziany adres, nie potrafi ich rozróżnić. Różnica polega na tym, kto po drodze czego się dowiaduje, jaka część ruchu jest objęta i które porty mogą działać. Przekaźnik wyjściowy Tor to ostatni skok obwodu z trzech przekaźników; serwer wyjściowy VPN kończy tunel i sam otwiera połączenie wychodzące. Oto jak decyduję, którego potrzebuje zadanie, i co sprawdzam, zanim założę, że jedno zachowuje się jak drugie.
Dwie drogi, które kończą się na jednym adresie
Tor buduje obwód przez strażnika, środkowy przekaźnik i wyjście, i szyfruje ładunek warstwami, tak że każdy przekaźnik zdejmuje tylko swoją warstwę. Wyjście nawiązuje zwykłe połączenie TCP z celem, dlatego cel widzi adres wyjścia. Twój klient nigdy nie rozmawia z celem bezpośrednio, a strażnik też go nie widzi.
VPN to jeden tunel do jednego punktu końcowego. Serwer operatora usuwa tunel i otwiera połączenie wychodzące, więc cel również widzi jeden adres, tym razem operatora. Obserwowalny wynik jest taki sam; wiedza nie. Test, który wypisze IP, odpowiada, w jakim systemie jesteś, i nic nie mówi o podziale zaufania, który naprawdę się różni.
Kto ostatecznie co wie
Punkt końcowy VPN widzi adres źródłowy, cel, czas i wolumen w jednym miejscu. Ta koncentracja jest projektem: jeden operator, jedna powierzchnia logów, jedno miejsce na wezwanie lub złą konfigurację. Wszystko, co zyskujesz, pochodzi z zaufania do tej strony i z polityki wyjściowej punktu końcowego.
Tor dzieli tę wiedzę. Strażnik zna twój adres, ale nie cel; wyjście zna cel, ale nie twój adres. Przekaźnik nie powinien poznawać obu. To cecha strukturalna, a nie obietnica wobec globalnego obserwatora, przekaźnika korelującego czasy czy przejętego punktu końcowego, więc traktuj to jako inny podział tego samego ryzyka, a nie jako anonimowość, która nie może zawieść.
| What is known | Tor exit relay | VPN exit server |
|---|---|---|
| Your public address | Seen by the guard relay, not the exit | Seen at the endpoint |
| Final destination | Seen at the exit | Seen at the endpoint |
| Coverage | Applications configured for Tor, chiefly Tor Browser | Whatever the route policy includes |
| Plain HTTP payload | Readable at the exit | Readable at the endpoint |
Zasięg to decyzja przeglądarki albo trasy
Przeglądarka Tor trasuje własny ruch i dodaje zabezpieczenia, których zwykły klient VPN nie odtwarza: odporność na odciski palców, izolację pierwszej strony, stały rozmiar okna i akcję Nowa tożsamość, która odrzuca stan sesji. Inne aplikacje nie korzystają z tego obwodu, jeśli nie są tak skonfigurowane, a instalacja Tor dla całego systemu to osobny projekt od instalacji przeglądarki.
VPN ma odwrotny kształt. Zasięg idzie za tablicą tras, więc profil WireGuard z AllowedIPs = 0.0.0.0/0 przechwytuje wszystko, a lista podzielonego tunelu tylko wymienione prefiksy. Właśnie w tym mechanizmie żyją też wycieki: zapytania DNS, IPv6 i WebRTC mogą każde pójść drogą, której polityka tras nie obejmowała. Sprawdzaj od wewnątrz aplikacji, która zawiodła, nie z karty przeglądarki, która może używać innego interfejsu.
Polityka portów, blokowane cele i HTTPS
Przekaźnik wyjściowy może odmawiać portów wychodzących, a domyślna polityka odrzuca listę portów podatnych na nadużycia, w tym port SMTP 25. Klient poczty skonfigurowany przez Tor zawodzi więc na wyjściu, co wygląda na awarię sieci i nią nie jest. Operatorzy utrzymujący przekaźnik ustawiają to wprost:
# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25
Cele też blokują, i blokują oba systemy inaczej. Adresy wyjściowe Tor są publikowane, więc witryna może odrzucić całą listę; punkty końcowe VPN siedzą w zakresach centrów danych, które są odrzucane równie lekko. Gdy strona zawodzi, oddziel trzy kandydatów, zanim cokolwiek zmienisz: politykę wyjścia lub ruchu wychodzącego, cel odrzucający źródło albo portal przechwytujący pierwsze żądanie.
Żaden z systemów nie zastępuje szyfrowania transportu. Zwykły HTTP jest czytelny zarówno na przekaźniku wyjściowym, jak i w punkcie końcowym VPN, więc zostaw HTTPS włączone i przeczytaj ostrzeżenie o certyfikacie, zamiast je odrzucać. Dwie kontrole szybko rozstrzygają kwestię trasy: curl -s https://check.torproject.org/api/ip zwraca IsTor, gdy żądanie przeszło przez obwód, a curl -s https://ifconfig.me pokazuje adres wyjściowy, który przedstawiłby VPN. Uruchomienie obu mówi, której drogi powłoka naprawdę używa.
Nie używaj jednego jako drugiego
Adres przekaźnika wyjściowego nie jest profilem VPN. Skierowanie klienta OpenVPN lub WireGuard na przekaźnik na porcie 443 nie tworzy tunelu, bo nie nasłuchuje tam żadna usługa VPN; przekaźnik to skok w cudzym obwodzie. W drugą stronę punkt końcowy VPN nie jest punktem wejścia dla Tor, a ustawienia mostków w przeglądarce Tor nie są miejscem na wklejenie nazwy hosta komercyjnego VPN. Jeśli uruchamiasz Tor przez VPN, strażnik widzi adres VPN zamiast twojego, co zmienia podział bez łączenia dwóch ról.
Przed wyborem odpowiedz na cztery pytania po kolei: kto prowadzi punkt końcowy i co zachowuje, co narzędzie obejmuje na tym urządzeniu, jakie porty i cele dopuszcza polityka wyjściowa i co aplikacja dodaje poza ścieżką sieciową. Zadanie, które potrzebuje zwykłego dostępu do sieci dla wielu programów, chce VPN. Zadanie, które potrzebuje zabezpieczeń na poziomie przeglądarki i modelu obwodu, chce przeglądarki Tor, utrzymywanej na bieżąco. Jeśli odpowiedź brzmi «oba», uruchamiaj je w przemyślanej kolejności i zapisuj, który adres widzi każda strona.