VPN do Tor, Tor do VPN: dlaczego łańcuch się rwie
Gdy VPN, Tor i proxy są nakładane na siebie, kolejność decyduje o tym, co jest rozwiązywane, a co przenoszone. Znajdź pierwszą zerwaną granicę, zanim zmienisz wszystkie trzy.
Nakładanie VPN, Tora i proxy aplikacji wygląda jak zwielokrotnianie prywatności, a w rzeczywistości zwielokrotnia liczbę miejsc, w których połączenie może umrzeć. Zwykły wynik to przeglądarka, która się kręci, podczas gdy wszystkie trzy narzędzia zgłaszają, że są zdrowe. Zmiana wszystkich trzech ustawień naraz usuwa jedyną wskazówkę, które z nich kłamie.
Najpierw narysuj zamierzoną ścieżkę w kolejności, nazywając program, który otwiera każde połączenie, i nazwę rozwiązywaną na każdym kroku.
Warstwy się nie sumują, działają na siebie
VPN przed Torem oznacza, że połączenie wejściowe klienta Tora podróżuje wewnątrz tunelu. VPN przenoszony przez Tora oznacza, że własny punkt końcowy klienta VPN musi być osiągalny przez Tora, co jest zupełnie innym wymaganiem. Proxy przeglądarki dodaje jeszcze jeden skok, o którym system operacyjny nic nie wie. Trzy układy, trzy osobne listy zależności.
Każdy układ zmienia to, co można rozwiązać, co można przenieść i kto widzi pierwszy pakiet. Tylko jeden z nich może być konfiguracją, którą miałeś na myśli.
Dodaj do schematu także ścieżkę bezpośrednią. Trasa zapasowa, wyjątek podzielonego tunelu lub obejście proxy mogą sprawić, że strona się wczyta, po cichu pomijając łańcuch, który chciałeś przetestować, a taki sukces wprowadza w błąd bardziej niż porażka.
Kolejność decyduje, co można przenieść
Tor przenosi strumienie TCP przez swój interfejs SOCKS, a klient, który prosi proxy o rozwiązanie nazwy hosta, trzyma zapytanie wewnątrz obwodu. UDP w zwykłych konfiguracjach nie podróżuje w ten sposób, dlatego tunelu WireGuard nie da się zagnieździć w Torze bez dodatkowego przekaźnika TCP pośrodku.
OpenVPN można wymusić na TCP, więc ten układ jest przynajmniej opisywalny. Jest też wolniejszy i bardziej kruchy, a sposób awarii przy zerwaniu wygląda identycznie jak zablokowany port. Spodziewaj się spędzić więcej czasu na odróżnianiu tych dwóch niż na naprawie któregokolwiek.
Rozwiązywanie to druga połowa. Z --socks5-hostname proxy rozwiązuje cel, podczas gdy zwykły --socks5 najpierw pyta lokalny resolver i wycieka nazwę poza obwód. Właśnie ta jedna flaga decyduje, czy wyszukiwanie nazwy należy do łańcucha, czy do twojego dostawcy internetu.
| Order | What must resolve the endpoint | What usually breaks |
|---|---|---|
| VPN, then Tor | The tunnel's resolver | Entry guards blocked by the VPN provider's filters |
| Tor, then VPN | The SOCKS proxy, remotely | UDP transports, which Tor does not carry |
| App proxy on top | The application itself | Proxy bypass rules and cached connections |
Znalezienie pierwszej zerwanej granicy
Testuj etapy w kolejności, w jakiej podróżują pakiety, nieszkodliwymi żądaniami, i zatrzymaj się na pierwszym, który zawiedzie. Zanotuj, która komenda wykonała się pierwsza, bo kolejność jest częścią dowodu. Dwie komendy oddzielają martwy obwód od martwego wyjścia:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Pierwsza informuje, czy żądanie w ogóle kończy się przez proxy SOCKS, a druga pokazuje adres, który sieć obecnie przedstawia. Jeśli pierwsza zawiedzie, a druga się powiedzie, problem jest przy kliencie Tora lub przed nim. Jeśli obie się powiodą, a przeglądarka nadal zawodzi, aplikacja korzysta z innej ścieżki niż powłoka.
Strona z publicznym IP również opisuje tylko ostatnie widoczne wyjście. Nie potrafi powiedzieć, ile skoków je poprzedziło, więc łącz ją z obsługiwanym wyjściem stanu każdego narzędzia, zamiast traktować jedną liczbę jako schemat.
Kiedy przestać dodawać warstwy
Jeśli nie potrafisz jednym zdaniem powiedzieć, co wnosi warstwa, usuń ją. Łańcuch, którego cel nie jest jasny, to łańcuch, którego nikt nie zdiagnozuje o trzeciej w nocy, a zysk prywatności z niewyjaśnionego skoku jest zwykle mniejszy niż tracona dostępność.
Jeśli warstwa naprawdę zasługuje na swoje miejsce, przetestuj ją najpierw samą, potem dodaj następną i ponownie potwierdź ścieżkę tymi samymi dwiema komendami. Przywróć pełny łańcuch przed zwykłym użytkowaniem i pozostaw włączoną walidację TLS oraz uwierzytelnianie; ostrzeżenie o certyfikacie zaakceptowane po to, by strona się wczytała, jest obejściem routingu, nie naprawą. Zapisz kolejność, na której się zatrzymałeś, dopóki jest świeża.
Zapisz tę kolejność, wraz z resolverem, który odpowiada na każdym etapie. Działający łańcuch, który umiesz opisać, przetrwa następną aktualizację, podczas gdy działający łańcuch złożony metodą prób znika wraz z nią. Dodaj datę i wersje, aby późniejszą awarię można było porównać ze znanym dobrym stanem, a nie spierać się o nią z pamięci. Dziesięć linii w pliku tekstowym oszczędza wieczór zgadywania.