UDP przez port SOCKS Tora: co nie przechodzi

Wskazanie aplikacji na port SOCKS działa dla przeglądarki, a zawodzi dla gry, i powodem nie jest konfiguracja. SOCKS5 definiuje kilka poleceń, a implementacja może obsługiwać tylko niektóre z nich; interfejs Tora przyjmuje połączenia strumieniowe i rozwiązywanie nazw, a nie dowolne przekazywanie datagramów. Klient, który wysyła UDP i oczekuje, że proxy je przekaże, żąda polecenia, którego serwer nie implementuje. Poniższy przewodnik sprawdza to w kilka minut, a następnie wybiera transport, który naprawdę może działać.

Sprawdź, co aplikacja naprawdę wysyła

Zacznij od rozpoznania transportu, a nie nazwy protokołu. Klient głosowy może zalogować się przez HTTPS, a następnie przesyłać media przez UDP; gra może uwierzytelniać się przez TCP i grać przez UDP; transfer plików może używać TCP do sterowania i UDP do wykrywania. Dwa pierwsze zachowania wyglądają identycznie, dopóki logowanie się nie powiedzie, a połączenie nadal zawodzi, dlatego „połączyło się” nie jest dowodem, że cała aplikacja działa. Niektórzy klienci sami wracają z UDP do TCP, przez co częściowo działająca sesja wygląda jak niestabilna sieć, a nie zablokowany transport.

Zapisz port docelowy i transport dla tej części, która zawodzi. Ta jedna linia decyduje, czy proxy w ogóle może pomóc.

Co przyjmie interfejs SOCKS Tora

Tor implementuje polecenie SOCKS5 CONNECT dla połączeń strumieniowych oraz polecenia rozszerzeń do rozwiązywania nazw, dlatego przeglądarka działa przez niego bez zmian. UDP ASSOCIATE, polecenie, które pozwoliłoby klientowi przekazać datagramy proxy do przesłania, nie jest częścią tego, co oferuje Tor. Dokumentacja rozszerzeń znajduje się w specyfikacji rozszerzeń SOCKS projektu i jest krótka. Brak polecenia dla datagramów jest zamierzony: przekazywanie dowolnego UDP dałoby sieci rolę przekaźnika, do której nigdy nie została zaprojektowana.

To jest także odpowiedź dla WireGuard, który z założenia jest UDP i nie ma zapasowej ścieżki TCP. Nie ma obsługiwanej ścieżki, która kierowałaby WireGuard na port SOCKS, a wszystko, co twierdzi inaczej, jest nakładką z własną historią zaufania i utrzymania, a nie funkcją któregoś z tych dwóch narzędzi.

OpenVPN jest częściowym wyjątkiem, ponieważ można go skonfigurować do tunelowania przez TCP i rozumie on opcję proxy SOCKS. To nadal wymaga serwera skonfigurowanego pod TCP i świadomej decyzji o skutkach dla wydajności i odcisku palca, więc jest to wybór projektowy, a nie poprawka zgodności.

Wykonaj test po kolei

Najpierw potwierdź, że proxy działa dla strumieni, aby późniejsza awaria nie została przypisana nieosiągalnemu portowi. Następnie potwierdź własny ruch aplikacji i sprawdź, które gniazda faktycznie otwiera.

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

Udane pierwsze polecenie i ustanowiony strumień w drugiej linii pokazują, że ścieżka proxy działa zgodnie z projektem. Trzecie polecenie szuka lokalnych gniazd datagramowych należących do aplikacji; jeśli klient otworzy jedno i wyśle bezpośrednio na adres zdalny, nigdy nie zapytał proxy i żadne ustawienie proxy tego nie zmieni. Jeśli zawiedzie już na pierwszym kroku, zatrzymaj się i napraw ścieżkę proxy, zanim zaczniesz badać aplikację, ponieważ dwie usterki naraz dają raport, z którym nikt nie może nic zrobić.

Wycofaj zmiany i wybierz właściwe narzędzie

Usuń wszystkie zmienne środowiskowe proxy lub ustawienia proxy dla poszczególnych aplikacji, które kierowały klienta UDP na port SOCKS; pozostawienie ich sprawia, że późniejsze testy są niejednoznaczne. Przywróć poprzednią konfigurację z kopii, uruchom aplikację ponownie i potwierdź, że pierwotne zachowanie wraca, aby porównanie było czyste. Wycofanie, które nie zostało zweryfikowane, jest tylko nadzieją, że stan się zmienił.

Dla transportu, który musi pozostać UDP, VPN zwykle pasuje lepiej: przenosi pakiety aplikacji, nie wymagając od niej mówienia protokołem proxy, za cenę zupełnie innych właściwości anonimowości. Używaj każdego narzędzia do tego, co dokumentuje, a każdego mostu między nimi traktuj jako odrębny system, który wymaga własnego przeglądu. Zapisz w raporcie końcowym, która warstwa przenosi który transport, aby następna osoba nie odkryła ponownie tej samej granicy z inną aplikacją.