Proxy SOCKS przez SSH na Androidzie: dlaczego łączy się tylko połowa aplikacji

Logujesz się przez SSH, dodajesz -D 1080 i polecenie się udaje. Na telefonie istnieje teraz nasłuch SOCKS, a połowa aplikacji nadal wychodzi przez dane mobilne. To normalny wynik, a nie zepsuty tunel: ssh -D tworzy punkt końcowy proxy, a aplikacje Androida używają proxy tylko wtedy, gdy coś je do tego zmusi. Przejście łańcucha krok po kroku pokazuje, gdzie naprawdę mieszka każda część pracy.

Zacznij tam, gdzie zaczyna się ruch

Wybierz jedną aplikację, która powinna używać tunelu, i sprawdź, czy ma własne ustawienie proxy. Przeglądarka z polem SOCKS to łatwy przypadek: wskaż ją na 127.0.0.1:1080, włącz zdalny DNS, jeśli takie ustawienie istnieje, i żądanie przechodzi. Klient czatu, aplikacja map czy gra bez takiego pola nie mają sposobu użyć nasłuchu, a nic, co wpiszesz w poleceniu SSH, tego nie zmienia.

Zanim włączysz cokolwiek innego, udowodnij, że nasłuch działa z powłoki samego telefonu, klientem mówiącym bezpośrednio SOCKS:

ssh -N -D 1080 [email protected]
curl --socks5-hostname 127.0.0.1:1080 https://ifconfig.me

Adres, który wraca, powinien należeć do serwera SSH, a nie do telefonu. Jeśli tak jest, połowa proxy jest gotowa, a reszta pracy dotyczy pokrycia. Jeśli nie, najpierw napraw stronę SSH: uwierzytelnianie kluczem, zdolność serwera do dotarcia do celu i własne wyjście serwera SSH.

Dodaj część, której potrzebuje Android

Aplikacje bez ustawienia proxy potrzebują czegoś, co przechwyci ich pakiety i zamieni je w połączenia proxy. Na urządzeniu bez roota to adapter usługi VPN: aplikacja, która przejmuje interfejs wirtualny i przekazuje wybrany ruch do lokalnego nasłuchu SOCKS. Łańcuch staje się aplikacją, adapterem, nasłuchem SOCKS, połączeniem SSH, celem.

Zainstaluj adapter, przyznaj mu uprawnienie VPN i wybierz aplikacje lub trasy, które ma przechwytywać. Ikona klucza na pasku stanu oznacza wtedy adapter, a nie osobną komercyjną VPN. Android pozwala na jedno aktywne połączenie usługi VPN na profil użytkownika, więc uruchomienie drugiej aplikacji VPN nie dodaje warstwy do łańcucha: konkuruje o tę samą rolę.

To także etap, na którym udany test może cię zmylić. Jeśli adapter ma przechwytywać tylko przeglądarkę, którą już wskazałeś na proxy, wszystko działa i nic więcej nie jest pokryte. Przeczytaj listę przechwytywania, zanim uznasz, że urządzenie jest w tunelu.

Trzymaj transport SSH poza przechwytywaniem

Samo połączenie SSH nie może być zawracane do tunelu SOCKS, który utrzymuje. Jeśli adapter przechwytuje ruch aplikacji SSH, tunel zależy od połączenia, które czeka na tunel, a wynikiem jest pętla, która zatyka się lub zawodzi, gdy tylko adapter ruszy.

Zintegrowane implementacje chronią własne gniazdo transportowe. Przy osobnych aplikacjach potrzebujesz obsługiwanego wyjątku: zostaw aplikację SSH poza przechwytywaniem albo wyklucz punkt końcowy SSH po adresie. Oba mają koszt. Wykluczenie całej aplikacji terminala usuwa z tunelu także jej niepowiązaną aktywność sieciową, a wyjątek adresowy psuje się, gdy adres serwera się zmieni lub gdy nazwa przy następnym połączeniu rozwiąże się inaczej.

Sprawdź wyjątek z zewnątrz: połącz adapter ponownie, a potem potwierdź, że sesja SSH przeżywa i że żądanie przez proxy nadal zgłasza adres serwera. Sesja, która działa do startu adaptera, a potem zastyga, to właśnie ta pętla.

Śledź DNS i UDP do końca łańcucha

Dynamiczne przekazywanie OpenSSH przenosi połączenia TCP. To nie transport UDP-associate ani ICMP, a adapter nie może wymyślić przekazywania UDP, przyjmując pakiety UDP. Wszystko, co wymaga UDP, w tym QUIC i media WebRTC, albo zawiedzie, albo wróci do TCP, zależnie od aplikacji.

DNS potrzebuje własnej decyzji. Aplikacja, która rozwiązuje nazwę lokalnie, wysyła zapytanie przez zwykły resolver, zanim się połączy, więc tunel przenosi połączenie, ale nie wyszukiwanie. Klient świadomy proxy z opcją zdalnego DNS tego unika; przechwycona aplikacja bez tej opcji nie. Sprawdź, który resolver odpowiedział, zamiast zakładać, że adapter to zmienił.

Trzymaj nasłuch SOCKS związany z loopbackiem, zweryfikuj klucz hosta serwera SSH przy pierwszym użyciu i zostaw zwykłą walidację HTTPS na miejscu dla docelowej witryny. SSH chroni odcinek telefon-serwer; nie szyfruje tego, co serwer robi potem.

Sprawdź dwa czasy życia i zdecyduj

Adapter i sesja SSH mają osobne czasy życia. Jeśli SSH padnie, gdy adapter nadal przechwytuje, aplikacje mogą zawisnąć bez wyraźnego błędu, bo ich pakiety nadal trafiają do interfejsu wirtualnego, który nie ma już działającego wyjścia. Jeśli adapter się zatrzyma, aplikacje albo idą bezpośrednio, albo zostają zablokowane, zależnie od polityki VPN urządzenia.

Przetestuj oba kierunki celowo: zabij sesję SSH, gdy adapter działa, a potem zatrzymaj adapter, gdy SSH pozostaje włączony. To, co telefon robi w każdym przypadku, jest polityką, którą naprawdę wdrażasz, niezależnie od tego, co twierdziły instrukcje instalacji.

Jeśli przepływ pracy wymaga pokrycia całego urządzenia z przewidywalnym trybem awarii, uczciwą odpowiedzią jest prawdziwy IP VPN albo utrzymywany adapter zaprojektowany dla tego łańcucha. Sesja powłoki pozostawiona obok niepowiązanej aplikacji przechwytującej nie jest utrzymywanym tunelem urządzenia; to dwa komponenty bez porozumienia co do tego, co się stanie, gdy jeden z nich się skończy.