SSH SOCKS proxy na Androidu: proč se připojí jen polovina vašich aplikací

Přihlásíte se přes SSH, přidáte -D 1080, a příkaz projde. Na telefonu teď existuje SOCKS posluchač, a přesto polovina aplikací odchází přes mobilní data. To je normální výsledek, ne rozbitý tunel: ssh -D vytváří proxy koncový bod a aplikace pro Android používají proxy jen tehdy, když je k tomu něco donutí. Projít řetěz krok za krokem ukazuje, kde každá část práce skutečně žije.

Začněte tam, kde provoz začíná

Vyberte jednu aplikaci, která má tunel používat, a zkontrolujte, zda má vlastní nastavení proxy. Prohlížeč s polem SOCKS je snadný případ: namiřte ho na 127.0.0.1:1080, zapněte vzdálené DNS, pokud taková volba existuje, a požadavek projde. Chatovací klient, mapová aplikace nebo hra bez takového pole nemají jak posluchač použít a nic, co napíšete do příkazu SSH, to nezmění.

Než zapojíte cokoli dalšího, dokažte, že posluchač funguje z vlastního shellu telefonu s klientem, který mluví přímo SOCKS:

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

Adresa, která se vrátí, má být adresa SSH serveru, ne telefonu. Pokud ano, proxy polovina je hotová a zbytek práce je o pokrytí. Pokud ne, opravte nejdřív stranu SSH: ověřování klíčem, schopnost serveru dosáhnout cíle a vlastní odchod SSH serveru.

Přidejte část, kterou Android potřebuje

Aplikace bez nastavení proxy potřebují něco, co zachytí jejich pakety a převede je na proxy spojení. Na zařízení bez rootu je to adaptér služby VPN: aplikace, která převezme virtuální rozhraní a předá vybraný provoz do místního SOCKS posluchače. Řetěz se změní na aplikace, adaptér, SOCKS posluchač, SSH spojení, cíl.

Nainstalujte adaptér, dejte mu oprávnění VPN a vyberte aplikace nebo trasy, které má zachytávat. Ikona klíče ve stavovém řádku pak představuje adaptér, ne samostatný komerční VPN. Android povoluje jedno aktivní připojení služby VPN na uživatelský profil, takže spuštění druhé VPN aplikace nepřidává vrstvu navrch, ale soutěží o stejnou roli.

To je také krok, kde vás úspěšný test může zmást. Pokud adaptér zachytává jen prohlížeč, který jste už na proxy namířili, všechno funguje a nic jiného není pokryto. Přečtěte si seznam zachytávání, než usoudíte, že zařízení je v tunelu.

Držte SSH transport mimo zachytávání

Samotné SSH spojení se nesmí vracet do SOCKS tunelu, který udržuje. Pokud adaptér zachytí provoz SSH aplikace, tunel závisí na spojení, které čeká na tunel, a výsledkem je smyčka, která se zasekne nebo selže, jakmile adaptér začne.

Integrované implementace chrání vlastní transportní socket. S oddělenými aplikacemi potřebujete podporovanou výjimku: nechte SSH aplikaci mimo zachytávání, nebo vylučte SSH koncový bod podle adresy. Obě mají cenu. Vyloučení celé terminálové aplikace odebere z tunelu i její nesouvisející síťovou aktivitu a výjimka podle adresy se rozbije, když se adresa serveru změní nebo když se jméno při dalším připojení přeloží jinak.

Zkontrolujte výjimku zvenčí: znovu připojte adaptér a potvrďte, že SSH relace přežije a proxy požadavek stále hlásí adresu serveru. Relace, která funguje do startu adaptéru a pak zamrzne, je ta smyčka.

Sledujte DNS a UDP až na konec řetězu

Dynamický forward OpenSSH přenáší TCP spojení. Není to UDP asociace ani ICMP transport a adaptér nemůže vymyslet UDP předávání tím, že přijímá UDP pakety. Vše, co trvá na UDP, včetně QUIC a médií WebRTC, buď selže, nebo spadne na TCP podle aplikace.

DNS potřebuje vlastní rozhodnutí. Aplikace, která překládá jméno lokálně, pošle dotaz přes běžný resolver před připojením, takže tunel nese spojení, ale ne hledání. Klient, který zná proxy a má volbu vzdáleného DNS, tomu unikne; zachycená aplikace bez ní ne. Zkontrolujte, který resolver odpověděl, místo abyste předpokládali, že ho adaptér změnil.

Držte SOCKS posluchač vázaný na loopback, při prvním použití ověřte hostitelský klíč SSH serveru a ponechte běžnou validaci HTTPS pro koncový web. SSH chrání úsek z telefonu na server; nešifruje to, co server dělá dál.

Projděte obě životnosti a rozhodněte

Adaptér a SSH relace mají oddělené životnosti. Pokud SSH spadne, zatímco adaptér dál zachytává, aplikace mohou viset bez zjevné chyby, protože jejich pakety stále vstupují do virtuálního rozhraní, které už nemá funkční východ. Když adaptér skončí, aplikace buď jdou přímo, nebo jsou zablokované, podle VPN politiky zařízení.

Otestujte oba směry záměrně: zabijte SSH relaci se zapnutým adaptérem, pak zastavte adaptér, když SSH běží. Co telefon v každém případě dělá, je politika, kterou skutečně nasazujete, ať si návod tvrdí cokoli.

Pokud pracovní postup potřebuje pokrytí celého zařízení s předvídatelným selháním, poctivá odpověď je skutečný IP VPN nebo udržovaný adaptér navržený pro tento řetěz. Shell relace běžící vedle nesouvisející zachytávací aplikace není udržovaný tunel zařízení; jsou to dvě součásti bez dohody o tom, co se stane, když jedna skončí.