Android SSH SOCKS-proxy: hoekom net die helfte van jou apps koppel

Jy meld aan oor SSH, voeg -D 1080, en die opdrag slaag. Nou bestaan daar ’n SOCKS-luisteraar op die foon, en die helfte van die apps gaan steeds oor mobiele data. Dit is die normale uitkoms, nie ’n stukkende tonnel nie: ssh -D skep ’n proxy-eindpunt, en Android-toepassings gebruik net ’n proxy as iets hulle daartoe dwing. Om die ketting stap vir stap te volg wys waar elke deel van die werk werklik sit.

Begin waar die verkeer begin

Kies een app wat die tonnel moet gebruik en kyk of dit ’n eie proxy-instelling het. ’n Blaaier met ’n SOCKS-veld is die maklike geval: wys dit na 127.0.0.1:1080, aktiveer afgeleë DNS as die instelling bestaan, en die versoek gaan deur. ’n Kletskliënt, ’n kaart-app of ’n speletjie sonder so ’n veld het geen manier om die luisteraar te gebruik nie, en niks wat jy in die SSH-opdrag tik verander dit nie.

Voordat jy enigiets anders betrek, bewys dat die luisteraar uit die foon se eie dop met ’n kliënt wat SOCKS direk praat, werk:

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

Die adres wat terugkom moet die SSH-bediener se adres wees, nie die foon s’n nie. As dit so is, is die proxy-helfte klaar en gaan die res oor dekking. Indien nie, herstel eers die SSH-kant: sleutelverifikasie, die bediener se vermoë om die bestemming te bereik, en die SSH-bediener se eie uitgang.

Voeg die deel by wat Android nodig het

Toepassings sonder ’n proxy-instelling het iets nodig om hulle pakkette te vang en in proxy-verbindings te omskep. Op ’n toestel sonder root is dit ’n VPN-diens-adapter: ’n app wat die virtuele koppelvlak neem en gekose verkeer in die plaaslike SOCKS-luisteraar stuur. Die ketting word dan app, adapter, SOCKS-luisteraar, SSH-verbinding, bestemming.

Installeer die adapter, gee dit die VPN-toestemming, en kies die apps of roetes wat dit moet vang. Die sleutelikoon in die statusbalk verteenwoordig dan die adapter, nie ’n aparte kommersiële VPN nie. Android laat een aktiewe VPN-diensverbinding per gebruikerprofiel toe, so ’n tweede VPN-app bysit voeg nie ’n laag by nie; dit ding om dieselfde rol mee.

Dit is ook die stap waar ’n suksesvolle toets jou kan mislei. As die adapter net die blaaier vang wat jy reeds na die proxy gewys het, werk alles en is niks anders gedek nie. Lees die vanglys voordat jy besluit die toestel is getonnel.

Hou die SSH-transport buite die vangs

Die SSH-verbinding self moet nie teruggevoer word in die SOCKS-tonnel wat dit onderhou nie. As die adapter die SSH-app se verkeer vang, hang die tonnel aan ’n verbinding wat op die tonnel wag, en die uitkoms is ’n lus wat vasval of misluk sodra die adapter begin.

Geïntegreerde implementerings beskerm hulle eie transportsok. Met aparte apps het jy ’n ondersteunde uitsondering nodig: laat die SSH-app buite die vangs, of sluit die SSH-eindpunt per adres uit. Albei het koste. Om ’n hele terminaal-app uit te sluit verwyder ook sy ander netwerkaktiwiteit uit die tonnel, en ’n adresuitsondering breek wanneer die bediener se adres verander of die naam volgende keer anders opgelos word.

Kontroleer die uitsondering van buite: koppel die adapter weer, en bevestig dan dat die SSH-sessie oorleef en die proxy-versoek steeds die bediener se adres rapporteer. ’n Sessie wat werk tot die adapter begin en dan vries, is die lus.

Volg DNS en UDP tot die einde van die ketting

OpenSSH se dinamiese forward dra TCP-verbindings. Dit is nie ’n UDP-associate of ICMP-transport nie, en ’n adapter kan nie UDP-aanstuur uitdink deur UDP-pakkette te aanvaar nie. Enigiets wat op UDP aandring, insluitend QUIC en WebRTC-media, sal misluk of na TCP terugval, afhangend van die app.

DNS het sy eie besluit nodig. ’n App wat ’n naam plaaslik oplos, stuur die navraag deur die gewone resolver voordat dit koppel, so die tonnel dra die verbinding maar nie die opsoek nie. ’n Proxy-bewuste kliënt met ’n afgeleë-DNS-opsie vermy dit; ’n gevange app sonder een nie. Kyk watter resolver geantwoord het eerder as om te aanvaar die adapter het dit verander.

Bly hou die SOCKS-luisteraar aan loopback gebind, verifieer die SSH-bediener se gasheersleutel by die eerste gebruik, en laat normale HTTPS-validering vir die finale webwerf in plek. SSH beskerm die segment van foon na bediener; dit enkripteer nie wat die bediener daarna doen nie.

Kyk na die twee leeftye en besluit

Die adapter en die SSH-sessie het aparte leeftye. As SSH val terwyl die adapter aanhou vang, kan apps hang sonder ’n duidelike fout, want hulle pakkette gaan steeds in ’n virtuele koppelvlak in wat nie meer ’n werkende uitgang het nie. As die adapter stop, gaan apps direk of word geblok, afhangend van die toestel se VPN-beleid.

Toets albei rigtings doelbewus: dood die SSH-sessie met die adapter aan, stop dan die adapter terwyl SSH op bly. Wat die foon in elke geval doen, is die beleid wat jy werklik ontplooi, ongeag wat die opstelinstruksies beweer.

As die werkvloei dekking vir die hele toestel met ’n voorspelbare foutmodus nodig het, is ’n regte IP-VPN, of ’n onderhoude adapter wat vir hierdie ketting ontwerp is, die eerlike antwoord. ’n Dophou-sessie wat langs ’n onverwante vang-app aanloop is nie ’n onderhoude toesteltonnel nie; dit is twee komponente sonder ooreenkoms oor wat gebeur wanneer een eindig.