Android SSH SOCKS-proxy: kial nur duono de viaj aplikaĵoj konektiĝas

Vi ensalutas per SSH, aldonas -D 1080, kaj la komando sukcesas. SOCKS-aŭskultanto nun ekzistas en la telefono, kaj duono de la aplikaĵoj ankoraŭ eliras tra la poŝtelefona datumtrafiko. Tio estas la normala rezulto, ne rompita tunelo: ssh -D kreas proksejan finpunkton, kaj Android-aplikaĵoj uzas proksejon nur se io devigas ilin. La paŝa trairado de la ĉeno montras, kie ĉiu peco de la laboro efektive loĝas.

Komencu tie, kie komenciĝas la trafiko

Elektu unu aplikaĵon, kiu devus uzi la tunelon, kaj kontrolu, ĉu ĝi havas propran proksejan agordon. Retumilo kun SOCKS-kampo estas la facila kazo: direktu ĝin al 127.0.0.1:1080, ŝaltu foran DNS se la agordo ekzistas, kaj la peto trapasas. Babilejo, mapa aplikaĵo aŭ ludo sen tia kampo havas nenian rimedon uzi la aŭskultanton, kaj nenio, kion vi tajpas en la SSH-komando, tion ŝanĝas.

Antaŭ ol engaĝi ion alian, pruvu, ke la aŭskultanto funkcias el la propra ŝelo de la telefono per kliento, kiu parolas SOCKS rekte:

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

La adreso, kiu revenas, devus esti tiu de la SSH-servilo, ne de la telefono. Se jes, la prokseja duono pretas kaj la resta laboro temas pri kovrado. Se ne, unue riparu la SSH-flankon: ŝlosila aŭtentigo, la kapablo de la servilo atingi la celon, kaj la propra eliro de la SSH-servilo.

Aldonu la pecon, kiun Android bezonas

Aplikaĵoj sen prokseja agordo bezonas ion, kio kaptas iliajn pakaĵojn kaj transformas ilin en proksejajn konektojn. En aparato sen radikrajtoj tio estas adaptilo de VPN-servo: aplikaĵo, kiu prenas la virtualan interfacon kaj plusendas elektitan trafikon al la loka SOCKS-aŭskultanto. La ĉeno fariĝas aplikaĵo, adaptilo, SOCKS-aŭskultanto, SSH-konekto, celo.

Instalu la adaptilon, donu al ĝi la VPN-permeson, kaj elektu la aplikaĵojn aŭ itinerojn, kiujn ĝi kaptu. La ŝlosila piktogramo en la statobreto tiam reprezentas la adaptilon, ne apartan komercan VPN. Android permesas unu aktivan VPN-servan konekton por uzantprofilo, do startigi duan VPN-aplikaĵon ne aldonas tavolon sur la ĉenon: ĝi konkuras pri la sama rolo.

Ĉi tio ankaŭ estas la paŝo, kie sukcesa testo povas trompi vin. Se la adaptilo estas agordita kapti nur la retumilon, kiun vi jam direktis al la proksejo, ĉio funkcias kaj nenio alia estas kovrita. Legu la kaptoliston antaŭ ol konkludi, ke la aparato estas tuneligita.

Tenu la SSH-transporton ekster la kaptado

La SSH-konekto mem ne rajtas esti reenkondukata en la SOCKS-tunelon, kiun ĝi subtenas. Se la adaptilo kaptas la trafikon de la SSH-aplikaĵo, la tunelo dependas de konekto, kiu atendas la tunelon, kaj la rezulto estas buklo, kiu haltas aŭ malsukcesas tuj kiam la adaptilo ekfunkcias.

Integraj efektivigoj protektas sian propran transportan ingon. Kun apartaj aplikaĵoj vi bezonas subtenatan escepton: lasu la SSH-aplikaĵon ekster la kaptado, aŭ esceptu la SSH-finpunkton laŭ adreso. Ambaŭ havas kostojn. Escepti tutan terminalan aplikaĵon ankaŭ forigas ĝian nerilatan retan agadon el la tunelo, kaj adresa escepto rompiĝas, kiam la adreso de la servilo ŝanĝiĝas aŭ kiam la nomo solviĝas alie ĉe la sekva konekto.

Kontrolu la escepton de ekstere: rekonektu la adaptilon, poste konfirmu, ke la SSH-sesio pluvivas kaj ke la prokseja peto ankoraŭ raportas la adreson de la servilo. Sesio, kiu funkcias ĝis la adaptilo ekfunkcias kaj poste frostas, estas la buklo.

Sekvu DNS kaj UDP ĝis la fino de la ĉeno

La dinamika plusendo de OpenSSH portas TCP-konektojn. Ĝi ne estas UDP-associate aŭ ICMP-transporto, kaj adaptilo ne povas elpensi UDP-plusendon akceptante UDP-pakaĵojn. Io ajn, kio insistas pri UDP, inkluzive QUIC kaj WebRTC-amaskomunikiloj, aŭ malsukcesos aŭ refalos al TCP laŭ la aplikaĵo.

DNS bezonas sian propran decidon. Aplikaĵo, kiu solvas nomon loke, sendas la demandon tra la normala solvilo antaŭ ol konekti, do la tunelo portas la konekton sed ne la serĉon. Prokseja kliento kun opcio de fora DNS tion evitas; kaptita aplikaĵo sen ĝi ne. Kontrolu, kiu solvilo respondis, anstataŭ supozi, ke la adaptilo ŝanĝis tion.

Tenu la SOCKS-aŭskultanton ligita al loopback, kontrolu la gastigan ŝlosilon de la SSH-servilo ĉe unua uzo, kaj lasu normalan HTTPS-kontroladon en loko por la fina retejo. SSH protektas la segmenton telefono-al-servilo; ĝi ne ĉifras tion, kion la servilo faras poste.

Kontrolu la du vivodaŭrojn kaj decidu

La adaptilo kaj la SSH-sesio havas apartajn vivodaŭrojn. Se SSH falas dum la adaptilo daŭre kaptas, aplikaĵoj povas pendi sen videbla eraro, ĉar iliaj pakaĵoj ankoraŭ eniras virtualan interfacon, kiu jam ne havas funkcian eliron. Se la adaptilo haltas, aplikaĵoj aŭ iras rekte aŭ estas blokataj, laŭ la VPN-politiko de la aparato.

Testu ambaŭ direktojn intence: mortigu la SSH-sesion kun la adaptilo funkcianta, poste haltigu la adaptilon dum SSH restas supre. Tio, kion la telefono faras en ĉiu kazo, estas la politiko, kiun vi efektive deplojas, kion ajn asertis la instrukcioj.

Se la laborfluo bezonas tutaparatan kovradon kun antaŭvidebla fiaskmaniero, vera IP VPN, aŭ konservata adaptilo desegnita por ĉi tiu ĉeno, estas la honesta respondo. Ŝelsesio lasita funkcii apud nerilata kaptaplikĵo ne estas konservata aparata tunelo; ĝi estas du komponantoj sen interkonsento pri tio, kio okazas, kiam unu el ili finiĝas.