SSH SOCKS-proxy på Android: därför ansluter bara hälften av dina appar

Du loggar in via SSH, lägger till -D 1080 och kommandot lyckas. Nu finns en SOCKS-lyssnare på telefonen, och hälften av apparna går fortfarande ut över mobildata. Det är det normala resultatet, inte en trasig tunnel: ssh -D skapar en proxyändpunkt, och Android-appar använder bara proxy om något tvingar dem. Att gå igenom kedjan steg för steg visar var varje del av arbetet faktiskt bor.

Börja där trafiken börjar

Välj en app som borde använda tunneln och kontrollera om den har en egen proxyinställning. En webbläsare med SOCKS-fält är det enkla fallet: peka den mot 127.0.0.1:1080, slå på fjärr-DNS om inställningen finns, och begäran går igenom. En chattklient, en kartapp eller ett spel utan sådant fält har ingen väg att använda lyssnaren, och inget du skriver i SSH-kommandot ändrar det.

Innan du blandar in något annat, bevisa att lyssnaren fungerar från telefonens eget skal med en klient som talar SOCKS direkt:

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

Adressen som kommer tillbaka ska vara SSH-serverns, inte telefonens. Är den det är proxyhalvan klar och resten av arbetet handlar om täckning. Är den inte det, fixa SSH-sidan först: nyckelautentisering, serverns förmåga att nå målet och SSH-serverns egen utgång.

Lägg till delen som Android behöver

Appar utan proxyinställning behöver något som fångar deras paket och gör dem till proxyanslutningar. På en enhet utan root är det en VPN-tjänsteadapter: en app som tar det virtuella gränssnittet och vidarebefordrar vald trafik till den lokala SOCKS-lyssnaren. Kedjan blir app, adapter, SOCKS-lyssnare, SSH-anslutning, mål.

Installera adaptern, ge den VPN-tillstånd och välj de appar eller rutter den ska fånga. Nyckelikonen i statusfältet representerar då adaptern, inte en separat kommersiell VPN. Android tillåter en aktiv VPN-tjänsteanslutning per användarprofil, så att starta en andra VPN-app lägger inte ett lager på kedjan: den konkurrerar om samma roll.

Det här är också steget där ett lyckat test kan lura dig. Om adaptern är inställd att bara fånga den webbläsare du redan pekat mot proxyn fungerar allt och inget annat är täckt. Läs fångstlistan innan du drar slutsatsen att enheten är i en tunnel.

Håll SSH-transporten utanför fångsten

Själva SSH-anslutningen får inte matas tillbaka in i SOCKS-tunneln som den upprätthåller. Om adaptern fångar SSH-appens trafik beror tunneln på en anslutning som väntar på tunneln, och resultatet är en loop som fastnar eller misslyckas så snart adaptern startar.

Integrerade implementationer skyddar sin egen transport-socket. Med separata appar behöver du ett stött undantag: håll SSH-appen utanför fångsten eller undanta SSH-ändpunkten efter adress. Båda har en kostnad. Att undanta en hel terminalapp tar också bort dess orelaterade nätverksaktivitet från tunneln, och ett adressundantag går sönder när serverns adress ändras eller när namnet löses upp annorlunda vid nästa anslutning.

Kontrollera undantaget utifrån: återanslut adaptern och bekräfta sedan att SSH-sessionen överlever och att den proxade begäran fortfarande rapporterar serverns adress. En session som fungerar tills adaptern startar och sedan fryser är den loopen.

Följ DNS och UDP till kedjans slut

OpenSSH:s dynamiska vidarebefordran bär TCP-anslutningar. Det är inte en UDP-associate- eller ICMP-transport, och en adapter kan inte hitta på UDP-vidarebefordran genom att ta emot UDP-paket. Allt som insisterar på UDP, inklusive QUIC och WebRTC-media, misslyckas eller faller tillbaka till TCP beroende på appen.

DNS behöver sitt eget beslut. En app som löser ett namn lokalt skickar frågan via den vanliga resolvern innan den ansluter, så tunneln bär anslutningen men inte uppslagningen. En proxy-medveten klient med fjärr-DNS-alternativ undviker det; en fångad app utan det gör det inte. Kontrollera vilken resolver som svarade i stället för att anta att adaptern ändrade det.

Håll SOCKS-lyssnaren bunden till loopback, verifiera SSH-serverns host-nyckel vid första användningen och låt vanlig HTTPS-validering stå kvar för slutsajten. SSH skyddar sträckan telefon-till-server; det krypterar inte det servern gör efteråt.

Kontrollera de två livscyklerna och bestäm

Adaptern och SSH-sessionen har separata livscykler. Om SSH faller medan adaptern fortsätter fånga kan appar hänga utan tydligt fel, eftersom deras paket fortfarande går in i ett virtuellt gränssnitt som inte längre har en fungerande utgång. Om adaptern stoppar går apparna antingen direkt eller blockeras, beroende på enhetens VPN-policy.

Testa båda riktningarna med avsikt: döda SSH-sessionen med adaptern igång och stoppa sedan adaptern medan SSH står kvar. Det telefonen gör i varje fall är den policy du faktiskt rullar ut, vad installationsanvisningarna än påstod.

Om arbetsflödet kräver täckning för hela enheten med ett förutsägbart felfall är ett riktigt IP VPN, eller en underhållen adapter byggd för den här kedjan, det ärliga svaret. En skal-session som lämnas att köra bredvid en orelaterad fångstapp är inte en underhållen enhetstunnel; det är två komponenter utan överenskommelse om vad som händer när en av dem tar slut.