VPN przed Tor: co naprawdę zmienia kolejność

Połączenie najpierw z VPN tworzy określony łańcuch: urządzenie, punkt końcowy VPN, wejście Tor, obwód Tor, cel. Twoja sieć lokalna widzi jedno szyfrowane połączenie z VPN, a węzeł wejściowy Tor widzi wyjście VPN jako bezpośrednie źródło zamiast adresu twojego dostawcy. Operator VPN z kolei widzi połączenia do infrastruktury wejściowej Tor i może wywnioskować korzystanie z Tor na podstawie celów. Każdy obserwator coś traci i coś zyskuje, dlatego kolejność jest wymianą, a nie ulepszeniem.

Nic w tym łańcuchu nie zmienia tego, czego strona dowiaduje się z twojego konta, plików cookie lub wpisanych danych.

Co zmienia kolejność

Sieć lokalna i dostawca internetu tracą bezpośredni wgląd w twój ruch Tor, ponieważ pierwszy skok jest teraz szyfrowanym tunelem do dostawcy. Strażnik wejściowy Tor traci twój adres domowy i widzi wyjście VPN. Dostawca VPN zyskuje metadane, które wcześniej miał twój dostawca internetu: które adresy odwiedzasz, o jakich porach i ile danych się przemieszcza.

Za strażnikiem wejściowym obwód zachowuje się jak wcześniej. Przekaźniki nadal rozdzielają role wejścia, środka i wyjścia, a VPN nie widzi końcowej treści więcej niż twój dostawca internetu.

Potwierdź ścieżkę, która jest faktycznie używana

Podzielone tunelowanie to zwykły powód, dla którego zamierzony łańcuch nie jest tym rzeczywistym.Jeśli Tor Browser jest wykluczony z tunelu, lub drugi profil trasuje inaczej, strażnik wejściowy znów widzi adres dostawcy, podczas gdy interfejs nadal wygląda na połączony. Sprawdzaj trasę i zaobserwowane wyjście, a nie ikonę.

ip route get 1.1.1.1
ss -tunp | grep -E 'tor|9150|9050'
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip
resolvectl status | grep -A3 'DNS Servers'

Żądanie SOCKS przez port 9150 obsługuje własny klient Tor Browser, więc odpowiedź IsTor true potwierdza obwód przeglądarki, a nie to, że używa go każdy inny program. Warto zapisać wynik resolvera, ponieważ DNS może wyjść ścieżką, której tunel nie obejmuje. Zachowaj oba wyniki ze znacznikiem czasu. Są one podstawą następnego porównania.

Porównaj z bezpośrednim żądaniem ze zwykłego terminala: jeśli ono również zgłasza Tor, coś innego przekierowuje ruch i łańcuch nie jest taki, jak zakładał projekt.

Obserwuj, co się dzieje, gdy tunel pada

Klient, który po cichu wraca do lokalnego interfejsu, zmienia źródło widziane przez strażnika wejściowego, a użytkownik zwykle o tym nie wie, ponieważ strona wciąż się ładuje. To właśnie ta awaria jest warta testowania, a nie szczęśliwa ścieżka. Rozłącz tunel celowo i sprawdź, czy ruch Tor zatrzymuje się, czy trwa bez ochrony.

nft list ruleset | grep -i -E 'vpn|tun|drop'
iptables -S | grep -i tun
ip link show | grep -E 'tun|wg'

Reguły zapory blokujące ruch wychodzący poza tunel to jedyna niezawodna kontrola awaryjna i muszą obejmować zarówno klienta SOCKS przeglądarki, jak i każdy inny ważny dla ciebie program. Rozszerzenie przeglądarki nie jest VPN urządzenia i nie wpływa na inne programy ani zewnętrznych obserwatorów.

Zdecyduj, czy dodatkowa warstwa zasługuje na zaufanie

Projekt Tor odradza układanie VPN pod Tor, chyba że sam możesz ocenić konfigurację. Podanym powodem jest dodatkowa zależność: kolejna strona, kolejne konto i kolejny tryb awarii. Jeśli celem jest powstrzymanie dostawcy internetu przed zobaczeniem, że używasz Tor, VPN adresuje właśnie tego obserwatora. Jeśli celem jest silniejsza anonimowość wobec globalnego obserwatora, VPN jej nie zapewnia.

Istnieje też odwrotna kolejność, a nazwy nie są wymienne:Tor ponad VPN i VPN ponad Tor opisują różne relacje zaufania i różne zachowanie przy awarii. Przeczytaj porównanie, zanim je zmieszasz.

Zapisz, którego obserwatora próbujesz przesunąć, następnie sprawdź, czy rzeczywista ścieżka odpowiada projektowi, a następnie sprawdź zachowanie przy awarii. Jeśli te trzy odpowiedzi nie uzasadniają dodatkowego konta i konfiguracji, udokumentowana konfiguracja Tor Browser ma mniej części, które można zepsuć.