Tor najpierw oznacza, że klient VPN siedzi za serwerem proxy SOCKS, więc sam tunel jest budowany przez Tor, a ruch aplikacji wychodzi z punktu końcowego VPN. To jeden konkretny porządek i nie jest to to, co buduje większość ludzi. Otwarcie Tor Browser obok zwykłego klienta VPN nie zmusza żadnego z dwóch programów do korzystania ze ścieżki drugiego.

Przejdź kontrole po kolei. Każda decyduje, czy warto zaczynać następną.

Który porządek właściwie budujesz

Dwa porządki mylą się w tej samej rozmowie. Tor najpierw oznacza, że klient VPN dociera do swojego serwera przez serwer proxy SOCKS, więc tunel jest budowany nad Torem. VPN najpierw oznacza, że ruch Tora wychodzi przez tunel, co większość ludzi buduje przez pomyłkę, a potem opisuje jako ten drugi. Pierwszy koncentruje granicę przekazywania u operatora VPN, drugi koncentruje ją przy wejściu i wyjściu Tora. Żaden z nich nie jest tym, co dostajesz, trzymając obie aplikacje otwarte jednocześnie.

Zapisz, którego porządku wymaga zadanie, zanim cokolwiek skonfigurujesz, ponieważ oba wymagają innych ustawień oprogramowania i zawodzą w innych miejscach. Błędnie nazwany porządek wysyła cię na godzinę do debugowania niewłaściwej warstwy. Wszystko poniżej zakłada Tor najpierw.

Sprawdź transport przed wszystkim innym

Interfejs SOCKS Tora przenosi strumienie TCP i nie zapewnia ogólnego skojarzenia UDP. VPN, którego transportem jest UDP, nie może traktować tego serwera proxy jak zwykłego interfejsu sieciowego, a żadne ustawienie klienta nie zmienia tego, co serwer proxy jest gotów przekazać. WireGuard w swojej zwykłej formie jest oczywistą ofiarą. Profil OpenVPN w trybie TCP to zwykłe rozwiązanie i jemu też trzeba wyraźnie powiedzieć, żeby korzystał z serwera proxy.

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

Zanim zaczniesz debugować tunel przez ten serwer proxy, potwierdź, że nasłuchuje on i potrafi przenieść jedno zwykłe żądanie HTTPS. Jeśli zwykłe żądanie zawiedzie, klient VPN nigdy nie osiągnie sukcesu, a jego dzienniki nie powiedzą ci dlaczego.

Przepisz mapę obserwatora

Wejście Tora może widzieć źródło, które łączy się z Torem, chyba że coś wcześniejszego je zmieniło, więc ten skok poznaje twój adres. Dostawca VPN otrzymuje połączenie przychodzące od strony Tora, ale nadal może znać konto, zapis płatności lub dane uwierzytelniające wysłane wewnątrz tunelu. Cele osiągane przez VPN widzą jego wyjście, a nie wyjście Tora, i to koncentruje końcową granicę przekazywania u jednego operatora.

Nie odtwarza też rozproszonej ścieżki do każdego celu. Tor Browser buduje nowy obwód dla każdej witryny; VPN przenoszony przez Tora buduje jeden tunel, a każda witryna za nim dzieli ten punkt końcowy. Traktuj różnicę jako fakt projektowy, a nie ograniczenie do usunięcia.

Policz warstwy awarii, gdy coś się zepsuje

Zepsuta konfiguracja ma co najmniej cztery niezależne warstwy: połączenie SOCKS, uścisk dłoni TLS z serwerem VPN, sam uścisk dłoni VPN, a następnie trasowanie lub rozwiązywanie nazw wewnątrz tunelu. Każda zawodzi z innym objawem i każda wymaga innej naprawy. Poluzowanie kontroli certyfikatów, bo tunel nie wstaje, to klasyczna błędna diagnoza i zamienia problem transportu w problem bezpieczeństwa.

Zarejestruj pierwszą warstwę, która zawiedzie, i zatrzymaj się tam. Odmowa serwera proxy i odrzucony klucz nie są odmianami tego samego zdarzenia.

Zatrzymaj się, jeśli model zagrożeń wymaga obrony Tor Browser

Trasowanie dowolnych aplikacji przez VPN przenoszony przez Tora nie daje tym aplikacjom funkcji odcisku palca i izolacji Tor Browser. Ich konta, identyfikatory i własne zachowanie sieciowe pozostają istotne, a tunel nie normalizuje żadnego z nich. Jeśli celem jest przeglądarka wtapiająca się w innych użytkowników, ten porządek tego nie daje.

Sam Tor Project ostrzega przed kombinacjami, których użytkownicy nie potrafią poprawnie skonfigurować, i ta dotyczy większości ludzi. To świadomy projekt dla wąskiego modelu zagrożeń, a nie skrót do anonimowego ruchu całego urządzenia.

Powiązane artykuły