Android SSH SOCKS-proxy: kvifor berre halvparten av appane dine koplar seg til

Du loggar på over SSH, legg til -D 1080, og kommandoen lukkast. No finst det ein SOCKS-lyttar på telefonen, og halvparten av appane går framleis ut over mobildata. Det er det normale resultatet, ikkje ein øydelagd tunnel: ssh -D lagar eit proxy-endepunkt, og Android-appar brukar berre proxy viss noko tvingar dei. Å gå gjennom kjeda steg for steg viser kvar kvar del av arbeidet faktisk bur.

Start der trafikken startar

Vel éin app som skal bruke tunnelen, og sjekk om han har si eiga proxy-innstilling. Ein nettlesar med SOCKS-felt er det enkle tilfellet: peik han mot 127.0.0.1:1080, slå på ekstern DNS viss innstillinga finst, og førespurnaden går gjennom. Ein chatklient, ein kartapp eller eit spel utan eit slikt felt har ingen måte å bruke lyttaren på, og ingenting du skriv i SSH-kommandoen endrar det.

Før du involverer noko anna, prov at lyttaren verkar frå telefonen si eiga skal med ein klient som snakkar SOCKS direkte:

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

Adressa som kjem tilbake skal vere SSH-tenaren si, ikkje telefonen si. Er ho det, er proxy-halvdelen ferdig, og resten av arbeidet handlar om dekning. Er ho ikkje det, rett opp SSH-sida først: nøkkelautentisering, evna tenaren har til å nå målet, og eigen utgang for SSH-tenaren.

Legg til delen Android treng

Appar utan proxy-innstilling treng noko som fangar pakkane deira og gjer dei om til proxy-samband. På ei eining utan root er det ein VPN-tenesteadapter: ein app som tek det virtuelle grensesnittet og sender vald trafikk vidare til den lokale SOCKS-lyttaren. Kjeda blir app, adapter, SOCKS-lyttar, SSH-samband, mål.

Installer adapteren, gje han VPN-løyve og vel appane eller rutene han skal fange. Nykjelikonet i statuslinja representerer då adapteren, ikkje ein separat kommersiell VPN. Android tillèt berre eitt aktivt VPN-tenestesamband per brukarprofil, så å starte ein andre VPN-app legg ikkje eit lag på kjeda: han kjemper om same rolla.

Dette er også steget der ein vellukka test kan lure deg. Viss adapteren er sett til å fange berre den nettlesaren du alt peikte mot proxyen, verkar alt og ingenting anna er dekt. Les fangstlista før du konkluderer med at eininga er tunnelert.

Hald SSH-transporten utanfor fangsten

Sjølve SSH-sambandet må ikkje førast tilbake i SOCKS-tunnelen det held oppe. Viss adapteren fangar trafikken til SSH-appen, er tunnelen avhengig av eit samband som ventar på tunnelen, og resultatet er ei løkke som stoggar eller feilar så snart adapteren startar.

Integrerte implementasjonar vernar sin eigen transport-socket. Med separate appar treng du eit støtta unntak: hald SSH-appen utanfor fangsten, eller unnta SSH-endepunktet etter adresse. Begge har ein kostnad. Å unnta ein heil terminalapp fjernar også den urelaterte nettverksaktiviteten hans frå tunnelen, og eit adresseunntak bryt saman når serveradressa blir endra eller når namnet blir løyst annleis ved neste tilkopling.

Sjekk unntaket utanfrå: kople adapteren til på nytt, og stadfest deretter at SSH-økta overlever og at den proxyerte førespurnaden framleis rapporterer serveradressa. Ei økt som verkar til adapteren startar og deretter frys, er den løkka.

Følg DNS og UDP til enden av kjeda

Den dynamiske vidaresendinga til OpenSSH ber TCP-samband. Ho er ikkje ein UDP-associate- eller ICMP-transport, og ein adapter kan ikkje finne opp UDP-vidaresending ved å ta imot UDP-pakkar. Alt som insisterer på UDP, også QUIC og WebRTC-media, vil anten feile eller falle tilbake til TCP avhengig av appen.

DNS treng si eiga avgjerd. Ein app som løyser eit namn lokalt, sender spørjinga gjennom den vanlege resolvaren før han koplar til, så tunnelen ber sambandet men ikkje oppslaget. Ein proxyvaken klient med ekstern DNS-mogelegheit unngår det; ein fanga app utan den gjer det ikkje. Sjekk kva resolvar som svara i staden for å tru at adapteren endra det.

Hald SOCKS-lyttaren bunden til loopback, stadfest host-nykkelen til SSH-tenaren ved første bruk, og lat vanleg HTTPS-validering stå på plass for sluttstaden. SSH verner strekninga telefon-til-tenar; det krypterer ikkje det tenaren gjer etterpå.

Sjekk dei to levetidene og bestem

Adapteren og SSH-økta har separate levetider. Viss SSH fell medan adapteren held fram med å fange, kan appar henge utan openberr feil, fordi pakkane deira framleis går inn i eit virtuelt grensesnitt som ikkje lenger har ein fungerande utgang. Viss adapteren stoggar, går appane anten direkte eller blir blokkerte, avhengig av VPN-policyen til eininga.

Test begge retningane med vilje: drep SSH-økta medan adapteren køyrer, og stopp deretter adapteren medan SSH blir ståande. Det telefonen gjer i kvart tilfelle er policyen du faktisk rullar ut, uansett kva installasjonsrettleiinga hevda.

Viss arbeidsflyten treng dekning for heile eininga med ein føreseieleg feilmodus, er ein ekte IP VPN, eller ein vedlikehalden adapter laga for denne kjeda, det ærlege svaret. Ei skal-økt som får stå og gå ved sida av ein urelatert fangeapp er ikkje ein vedlikehalden einingsstunnel; det er to komponentar utan avtale om kva som skjer når ein av dei blir avslutta.