SSH SOCKS-proxy op Android: waarom maar de helft van je apps verbinding maakt

Je logt in via SSH, voegt -D 1080 toe en de opdracht lukt. Nu bestaat er een SOCKS-listener op de telefoon, en de helft van de apps gaat nog steeds via mobiele data naar buiten. Dat is het normale resultaat, geen kapotte tunnel: ssh -D maakt een proxy-eindpunt, en Android-apps gebruiken alleen een proxy als iets ze daartoe dwingt. De keten stap voor stap doorlopen laat zien waar elk stuk van het werk werkelijk zit.

Begin waar het verkeer begint

Kies één app die de tunnel zou moeten gebruiken en controleer of die een eigen proxy-instelling heeft. Een browser met een SOCKS-veld is het eenvoudige geval: wijs hem naar 127.0.0.1:1080, zet remote DNS aan als die instelling bestaat, en het verzoek gaat erdoor. Een chatclient, een kaartapp of een game zonder zo'n veld heeft geen manier om de listener te gebruiken, en niets wat je in de SSH-opdracht typt verandert dat.

Voordat je iets anders erbij betrekt, bewijs je dat de listener werkt vanuit de shell van de telefoon zelf, met een client die rechtstreeks SOCKS spreekt:

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

Het adres dat terugkomt hoort dat van de SSH-server te zijn, niet van de telefoon. Is dat zo, dan is de proxyhelft klaar en gaat de rest van het werk over dekking. Is dat niet zo, repareer dan eerst de SSH-kant: sleutelauthenticatie, het vermogen van de server om de bestemming te bereiken, en de eigen uitgang van de SSH-server.

Voeg het stuk toe dat Android nodig heeft

Apps zonder proxy-instelling hebben iets nodig dat hun pakketten onderschept en er proxyverbindingen van maakt. Op een toestel zonder root is dat een VPN-serviceadapter: een app die de virtuele interface overneemt en geselecteerd verkeer naar de lokale SOCKS-listener stuurt. De keten wordt app, adapter, SOCKS-listener, SSH-verbinding, bestemming.

Installeer de adapter, geef hem VPN-toestemming en kies de apps of routes die hij moet onderscheppen. Het sleutelicoon in de statusbalk staat dan voor de adapter, niet voor een aparte commerciële VPN. Android staat één actieve VPN-serviceverbinding per gebruikersprofiel toe, dus een tweede VPN-app starten voegt geen laag toe aan de keten: hij dingt mee naar dezelfde rol.

Dit is ook de stap waarin een geslaagde test je kan misleiden. Als de adapter alleen de browser onderschept die je al naar de proxy wees, werkt alles en is niets anders gedekt. Lees de onderscheppingslijst voordat je concludeert dat het toestel in een tunnel zit.

Houd het SSH-transport buiten de onderschepping

De SSH-verbinding zelf mag niet teruggevoerd worden in de SOCKS-tunnel die hij onderhoudt. Als de adapter het verkeer van de SSH-app onderschept, hangt de tunnel af van een verbinding die op de tunnel wacht, en het resultaat is een lus die vastloopt of faalt zodra de adapter start.

Geïntegreerde implementaties beschermen hun eigen transportsocket. Met losse apps heb je een ondersteunde uitzondering nodig: houd de SSH-app buiten de onderschepping, of sluit het SSH-eindpunt uit op adres. Beide hebben een prijs. Een hele terminalapp uitsluiten haalt ook de ongerelateerde netwerkactiviteit uit de tunnel, en een adresuitzondering breekt wanneer het adres van de server verandert of wanneer de naam bij de volgende verbinding anders wordt opgelost.

Controleer de uitzondering van buitenaf: verbind de adapter opnieuw en bevestig daarna dat de SSH-sessie overleeft en dat het verzoek via de proxy nog steeds het adres van de server meldt. Een sessie die werkt tot de adapter start en dan bevriest, is die lus.

Volg DNS en UDP tot het einde van de keten

De dynamische doorstuur van OpenSSH draagt TCP-verbindingen. Het is geen UDP-associate- of ICMP-transport, en een adapter kan geen UDP-doorstuur verzinnen door UDP-pakketten te accepteren. Alles wat op UDP staat, inclusief QUIC en WebRTC-media, mislukt of valt terug naar TCP, afhankelijk van de app.

DNS heeft zijn eigen beslissing nodig. Een app die een naam lokaal oplost, stuurt de query via de normale resolver voordat hij verbindt, dus de tunnel draagt de verbinding maar niet de opzoeking. Een proxybewuste client met een remote-DNS-optie vermijdt dat; een onderschepte app zonder die optie niet. Controleer welke resolver antwoordde in plaats van aan te nemen dat de adapter het veranderde.

Houd de SOCKS-listener gebonden aan loopback, verifieer de hostsleutel van de SSH-server bij eerste gebruik, en laat de normale HTTPS-validatie op zijn plaats voor de uiteindelijke site. SSH beschermt het stuk telefoon-naar-server; het versleutelt niet wat de server daarna doet.

Controleer de twee levensduurs en beslis

De adapter en de SSH-sessie hebben aparte levensduurs. Als SSH wegvalt terwijl de adapter blijft onderscheppen, kunnen apps hangen zonder duidelijke fout, omdat hun pakketten nog steeds een virtuele interface binnenkomen die geen werkende uitgang meer heeft. Als de adapter stopt, gaan apps ofwel rechtstreeks of worden ze geblokkeerd, afhankelijk van het VPN-beleid van het toestel.

Test beide richtingen doelbewust: dood de SSH-sessie terwijl de adapter draait, stop daarna de adapter terwijl SSH blijft staan. Wat de telefoon in elk geval doet, is het beleid dat je werkelijk uitrolt, wat de installatiehandleiding ook beweerde.

Als de werkwijze dekking van het hele toestel nodig heeft met een voorspelbare faalmodus, is een echte IP VPN, of een onderhouden adapter die voor deze keten is ontworpen, het eerlijke antwoord. Een shell-sessie die naast een ongerelateerde onderscheppingsapp blijft draaien is geen onderhouden apparaattunnel; het zijn twee componenten zonder afspraak over wat er gebeurt wanneer een van beide eindigt.