Android SSH SOCKS-proxy: wêrom't mar de helte fan dyn apps ferbynt

Do meldest dy oan fia SSH, foegest -D 1080 ta en it kommando slagget. Der is no in SOCKS-harker op 'e telefoan, en de helte fan 'e apps giet noch altyd oer mobile data nei bûten. Dat is it normale resultaat, gjin stikken tunnel: ssh -D makket in proxy-einpunt, en Android-apps brûke allinne in proxy as iets har dêrta twingt. De keatling stap foar stap trochrinne lit sjen wêr't elk stik fan it wurk eins wennet.

Begjin dêr't it ferkear begjint

Kies ien app dy't de tunnel brûke moat en kontrolearje oft dy syn eigen proxy-ynstelling hat. In browser mei in SOCKS-fjild is it maklike gefal: rjochtsje him op 127.0.0.1:1080, skeakelje remote DNS yn as de ynstelling bestiet, en it fersyk giet troch. In chatklant, in kaart-app of in spultsje sûnder sa'n fjild hat gjin manier om de harker te brûken, en neat datsto yn it SSH-kommando typst feroaret dat.

Foardatsto eat oars belûkst, bewiisje dat de harker fan 'e shell fan 'e telefoan sels wurket mei in klant dy't direkt SOCKS praat:

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

It adres dat weromkomt moat fan 'e SSH-tsjinner wêze, net fan 'e telefoan. Is dat sa, dan is de proxy-helte dien en giet de rest fan it wurk oer dekking. Is dat net sa, reparearje dan earst de SSH-kant: kaai-autentikaasje, it fermogen fan 'e tsjinner om it bestimming te berikken, en de eigen útgong fan 'e SSH-tsjinner.

Foegje it stik ta dat Android nedich hat

Apps sûnder proxy-ynstelling hawwe eat nedich dat har pakketten fangt en se yn proxy-ferbiningen omset. Op in apparaat sûnder root is dat in VPN-tsjinstadapter: in app dy't de firtuele yndruk nimt en selektearre ferkear trochstjoert nei de lokale SOCKS-harker. De keatling wurdt app, adapter, SOCKS-harker, SSH-ferbining, bestimming.

Ynstallearje de adapter, jou him de VPN-befêstiging en kies de apps of rûtes dy't er fange moat. It kaai-ikoan yn 'e statusbalke stiet dan foar de adapter, net foar in apart kommersjeel VPN. Android tastiet ien aktive VPN-tsjinstferbining per brûkersprofyl, dus in twadde VPN-app starte foeget gjin laach ta op 'e keatling: hy konkurrearret om deselde rol.

Dit is ek de stap wêrby't in slagge test dy misliede kin. As de adapter allinne de browser fangt dy'tst al op 'e proxy rjochte hast, wurket alles en is neat oars dekt. Lês de fanglist foardatst konkludearrest dat it apparaat tunnelle is.

Hâld it SSH-transport bûten de fangst

De SSH-ferbining sels mei net weromfierd wurde yn 'e SOCKS-tunnel dy't er ûnderhâldt. As de adapter it ferkear fan 'e SSH-app fangt, dan hinget de tunnel ôf fan in ferbining dy't op 'e tunnel wachtet, en it resultaat is in lus dy't fêst komt te sitten of mislearret sa gau as de adapter start.

Yntegrearre ymplemintaasjes beskermje har eigen transport-socket. Mei aparte apps hast in stipe útsûndering nedich: lit de SSH-app bûten de fangst, of slút it SSH-einpunt út op adres. Beide hawwe kosten. In hiele terminal-app útslute hellet ek syn net-relatearre netwurkaktiviteit út 'e tunnel, en in adresútsûndering brekt as it adres fan 'e tsjinner feroaret of as de namme by de folgjende ferbining oars oplost.

Kontrolearje de útsûndering fan bûten: ferbyn de adapter opnij, en befêstigje dan dat de SSH-sesje oerbliuwt en dat it proxye fersyk noch altyd it adres fan 'e tsjinner rapporteart. In sesje dy't wurket oant de adapter start en dan befriest, is de lus.

Folgje DNS en UDP oant it ein fan 'e keatling

De dynamyske trochstjoering fan OpenSSH draacht TCP-ferbiningen. It is gjin UDP-associate- of ICMP-transport, en in adapter kin gjin UDP-trochstjoering betinke troch UDP-pakketten oan te nimmen. Alles dat op UDP stiet, ynklusyf QUIC en WebRTC-media, sil mislearje of weromfalle nei TCP, ôfhinklik fan 'e app.

DNS hat syn eigen beslissing nedich. In app dy't in namme lokaal oplost, stjoert de fraach fia de normale resolver foardat er ferbynt, dus de tunnel draacht de ferbining mar net it sykjen. In proxy-bewuste klant mei in remote-DNS-opsje foarkomt dat; in fongen app sûnder sa'n opsje net. Kontrolearje hokker resolver antwurde ynstee fan oan te nimmen dat de adapter dat feroare hat.

Hâld de SOCKS-harker bûn oan loopback, ferifiearje de hostkaai fan 'e SSH-tsjinner by it earste gebrûk, en lit normale HTTPS-falidaasje stean foar de ein-side. SSH beskermet it segmint telefoan-nei-tsjinner; it fersiferet net wat de tsjinner dêrnei docht.

Kontrolearje de twa libbensdielen en beslute

De adapter en de SSH-sesje hawwe aparte libbensdielen. As SSH falt wylst de adapter trochgiet mei fangen, kinne apps hingje sûnder dúdlike flater, om't har pakketten noch altyd in firtuele yndruk yngeane dy't gjin wurkjende útgong mear hat. As de adapter stopt, geane apps of direkt of wurde se blokkearre, ôfhinklik fan it VPN-belied fan it apparaat.

Test beide rjochtingen mei opset: deadzje de SSH-sesje wylst de adapter rint, en stop dan de adapter wylst SSH oerein bliuwt. Wat de telefoan yn elk gefal docht, is it belied datst echt útrôlest, wat de ynstallaasje-ynstruksjes ek bewearden.

As de workflow dekking fan it hiele apparaat nedich hat mei in foarsisbere flatermodus, dan is in echte IP VPN, of in ûnderhâlden adapter dy't foar dizze keatling ûntwurpen is, it earlike antwurd. In shell-sesje dy't njonken in net-relatearre fang-app rint is gjin ûnderhâlden apparaattunnel; it binne twa komponinten sûnder ôfspraak oer wat der bart as ien fan har einiget.