Android SSH SOCKS proxy-a: zergatik konektatzen dira zure aplikazioen erdia bakarrik

SSH bidez saioa hasten duzu, -D 1080 gehitzen duzu, eta komandoak ondo funtzionatzen du. Orain SOCKS entzule bat dago telefonoan, eta aplikazioen erdiak oraindik datu mugikorretik irteten dira. Hori da emaitza normala, ez tunel hautsia: ssh -D-k proxy puntu bat sortzen du, eta Android aplikazioek proxy bat erabiltzen dute zerbait haietara behartzen badu soilik. Katea urratsez urrats zeharkatzeak erakusten du lanaren pieza bakoitza non dagoen benetan.

Hasi trafikoa hasten den tokian

Aukeratu tunela erabili beharko lukeen aplikazio bat eta egiaztatu ea baduen bere proxy ezarpena. SOCKS eremua duen nabigatzailea kasurik erraza da: zuzendu 127.0.0.1:1080-ra, gaitu DNS urrunekoa ezarpena badago, eta eskaera pasatzen da. Txat bezero batek, mapa aplikazio batek edo eremu hori ez duen joko batek ez du entzulea erabiltzeko modurik, eta SSH komandoan idazten duzun ezerk ez du hori aldatzen.

Beste ezer sartu aurretik, frogatu entzulea telefonoaren shell beretik funtzionatzen duela SOCKS zuzenean hitz egiten duen bezero batekin:

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

Itzultzen den helbidea SSH zerbitzariarena izan behar da, telefonoarena ez. Hala bada, proxy erdia eginda dago eta gainerako lana estaldurarekin lotuta dago. Ez bada, konpondu lehenengo SSH aldea: gako autentifikazioa, zerbitzariaren helmugara iristeko gaitasuna eta SSH zerbitzariaren irteera propioa.

Gehitu Android-ek behar duen pieza

Proxy ezarpenik ez duten aplikazioek beren paketeak harrapatu eta proxy konexio bihurtuko dituen zerbait behar dute. Rootik gabeko gailu batean, hori VPN zerbitzuaren egokitzailea da: interfaze birtuala hartu eta hautatutako trafikoa tokiko SOCKS entzulera birbidaltzen duen aplikazioa. Katea aplikazio, egokitzaile, SOCKS entzule, SSH konexio, helmuga bihurtzen da.

Instalatu egokitzailea, eman VPN baimena eta aukeratu harrapatu behar dituen aplikazioak edo ibilbideak. Egoera barrako giltza ikonoak egokitzailea adierazten du orduan, ez VPN komertzial bereizi bat. Android-ek VPN zerbitzu konexio aktibo bakarra onartzen du erabiltzaile profileko, beraz bigarren VPN aplikazio bat abiatzeak ez du katearen gainean geruza gehitzen: rol beragatik lehiatzen da.

Hau ere proba arrakastatsu batek engainatu zaitzakeen urratsa da. Egokitzailea jada proxyra zuzendu duzun nabigatzailea soilik harrapatzeko konfiguratuta badago, dena funtzionatzen du eta beste ezer ez dago estalita. Irakurri harrapaketa zerrenda gailua tuneletuta dagoela ondorioztatu aurretik.

Eutsi SSH garraioa harrapaketatik kanpo

SSH konexioak berak ez du mantentzen duen SOCKS tunelera itzuli behar. Egokitzaileak SSH aplikazioaren trafikoa harrapatzen badu, tunela tunelaren zain dagoen konexio baten mende dago, eta emaitza egokitzailea abiatzen den unetan trabatzen edo huts egiten duen begizta bat da.

Inplementazio integratuek beren garraio socket-a babesten dute. Aplikazio bereiziekin onartutako salbuespen bat behar duzu: utzi SSH aplikazioa harrapaketatik kanpo, edo baztertu SSH muturra helbidearen arabera. Biek kostuak dituzte. Terminal aplikazio oso bat baztertzeak bere sare jarduera ez erlazionatua ere kentzen du tunelatik, eta helbide salbuespen bat apurtzen da zerbitzariaren helbidea aldatzen denean edo izenak hurrengo konexioan beste modu batera ebazten duenean.

Egiaztatu salbuespena kanpotik: berriro konektatu egokitzailea, eta gero baieztatu SSH saioa bizirik jarraitzen duela eta proxy bidezko eskaerak zerbitzariaren helbidea ematen jarraitzen duela. Egokitzailea hasi arte funtzionatzen duen eta gero izozten den saioa begizta da.

Jarraitu DNS eta UDP katearen amaieraraino

OpenSSH-ren birbidalketa dinamikoak TCP konexioak eramaten ditu. Ez da UDP-associate edo ICMP garraioa, eta egokitzaile batek ezin du UDP birbidalketarik asmatu UDP paketeak onartzean. UDPn tematzen den guztiak, QUIC eta WebRTC multimedia barne, huts egingo du edo TCPra itzuliko da aplikazioaren arabera.

DNSk bere erabakia behar du. Izena lokalki ebazten duen aplikazioak kontsulta resolutore normaletik bidaltzen du konektatu aurretik, beraz tunelak konexioa eramaten du, baina ez bilaketa. Proxyaz jabetzen den bezero batek DNS urruneko aukerarekin hori saihesten du; harrapatutako aplikazio batek hura gabe ez. Egiaztatu zein resolutorek erantzun zuen, egokitzaileak hori aldatu zuela suposatu beharrean.

Eutsi SOCKS entzulea loopback-era lotuta, egiaztatu SSH zerbitzariaren host gakoa lehen erabileran, eta utzi HTTPS baliozkotze normala bere lekuan amaierako gunerako. SSHk telefono-zerbitzari tartea babesten du; ez du zerbitzariak gero egiten duena zifratzen.

Egiaztatu bi bizitzak eta erabaki

Egokitzaileak eta SSH saioak bizi-denborak bereiziak dituzte. SSH erortzen bada egokitzaileak harrapatzen jarraitzen duen bitartean, aplikazioak zintzilik gera daitezke errorerik ageririk gabe, haien paketeak oraindik irteera funtzionalik ez duen interfaze birtual batera sartzen baitira. Egokitzailea gelditzen bada, aplikazioak zuzenean joaten dira edo blokeatuta geratzen dira, gailuaren VPN politikaren arabera.

Probatu bi norabideak nahita: hil SSH saioa egokitzailea martxan dela, eta gero gelditu egokitzailea SSH zutik mantentzen den bitartean. Telefonoak kasu bakoitzean egiten duena benetan zabaltzen ari zaren politika da, instalazio argibideek esan zutenarekin bat etorri ala ez.

Lan-fluxuak gailu osoko estaldura behar badu hutsegite modu aurreikustekoarekin, benetako IP VPN bat, edo kate honetarako diseinatutako egokitzaile mantendu bat da erantzun zintzoa. Shell saio bat harrapaketa aplikazio ez erlazionatu baten ondoan martxan edukitzea ez da gailu tunel mantendua; bi osagai dira, bat amaitzean zer gertatzen den adosten ez dutenak.