Proxy SOCKS përmes SSH në Android: pse lidhet vetëm gjysma e aplikacioneve

Hyni përmes SSH, shtoni -D 1080 dhe komanda funksionon. Tani ekziston një dëgjues SOCKS në telefon, dhe gjysma e aplikacioneve ende dalin përmes të dhënave mobile. Ky është rezultati normal, jo një tunel i thyer: ssh -D krijon një pikë fundore proxy, dhe aplikacionet Android përdorin proxy vetëm nëse diçka i detyron. Kalimi nëpër zinxhir hap pas hapi tregon se ku jeton në të vërtetë secila pjesë e punës.

Filloni aty ku fillon trafiku

Zgjidhni një aplikacion që duhet të përdorë tunelin dhe kontrolloni nëse ka cilësimin e vet të proxy. Një shfletues me fushë SOCKS është rasti i lehtë: drejtojeni te 127.0.0.1:1080, aktivizoni DNS në distancë nëse cilësimi ekziston, dhe kërkesa kalon. Një klient chat, një aplikacion hartash ose një lojë pa një fushë të tillë nuk kanë asnjë mënyrë për të përdorur dëgjuesin, dhe asgjë që shkruani në komandën SSH nuk e ndryshon këtë.

Përpara se të përfshini diçka tjetër, provoni që dëgjuesi funksionon nga shell-i i vetë telefonit me një klient që flet drejtpërdrejt SOCKS:

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

Adresa që kthehet duhet të jetë e serverit SSH, jo e telefonit. Nëse është, gjysma proxy është kryer dhe pjesa tjetër e punës ka të bëjë me mbulimin. Nëse nuk është, rregulloni fillimisht anën SSH: vërtetimin me çelës, aftësinë e serverit për të arritur destinacionin dhe daljen e vetë serverit SSH.

Shtoni pjesën që i duhet Android

Aplikacionet pa cilësim proxy kanë nevojë për diçka që kap paketat e tyre dhe i kthen ato në lidhje proxy. Në një pajisje pa root, kjo është një përshtatës i shërbimit VPN: një aplikacion që merr ndërfaqen virtuale dhe përcjell trafikun e zgjedhur te dëgjuesi lokal SOCKS. Zinxhiri bëhet aplikacion, përshtatës, dëgjues SOCKS, lidhje SSH, destinacion.

Instaloni përshtatësin, jepini lejen e VPN dhe zgjidhni aplikacionet ose rrugët që duhet të kapë. Ikona e çelësit në shiritin e statusit përfaqëson atëherë përshtatësin, jo një VPN komerciale të veçantë. Android lejon një lidhje aktive të shërbimit VPN për profil përdoruesi, kështu që nisja e një aplikacioni të dytë VPN nuk shton një shtresë në zinxhir: konkurron për të njëjtin rol.

Ky është gjithashtu hapi ku një test i suksesshëm mund t'ju mashtrojë. Nëse përshtatësi është vendosur të kapë vetëm shfletuesin që e keni drejtuar tashmë te proxy, gjithçka funksionon dhe asgjë tjetër nuk është e mbuluar. Lexoni listën e kapjes përpara se të arrini në përfundimin se pajisja është në tunel.

Mbani transportin SSH jashtë kapjes

Vetë lidhja SSH nuk duhet të kthehet në tunelin SOCKS që mban. Nëse përshtatësi kap trafikun e aplikacionit SSH, tuneli varet nga një lidhje që pret tunelin, dhe rezultati është një lak që bllokohet ose dështon sapo përshtatësi nis.

Implementimet e integruara mbrojnë socket-in e tyre të transportit. Me aplikacione të veçanta ju nevojitet një përjashtim i mbështetur: lini aplikacionin SSH jashtë kapjes, ose përjashtoni pikën fundore SSH sipas adresës. Të dyja kanë kosto. Përjashtimi i një aplikacioni të tërë terminali heq nga tuneli edhe aktivitetin e tij të palidhur të rrjetit, dhe përjashtimi i adresës prishet kur adresa e serverit ndryshon ose kur emri zgjidhet ndryshe në lidhjen tjetër.

Kontrolloni përjashtimin nga jashtë: rilidhni përshtatësin, pastaj konfirmoni se sesioni SSH mbijeton dhe se kërkesa përmes proxy vazhdon të raportojë adresën e serverit. Një sesion që funksionon derisa nis përshtatësi dhe pastaj ngrin është ai lak.

Ndiqni DNS dhe UDP deri në fund të zinxhirit

Përcjellja dinamike e OpenSSH transporton lidhje TCP. Nuk është transport UDP-associate apo ICMP, dhe një përshtatës nuk mund të shpikë përcjellje UDP duke pranuar paketa UDP. Çdo gjë që këmbëngul për UDP, përfshirë QUIC dhe mediat WebRTC, ose dështon ose kthehet në TCP sipas aplikacionit.

DNS kërkon vendimin e vet. Një aplikacion që zgjidh një emër lokalisht e dërgon pyetjen përmes zgjidhësit normal përpara se të lidhet, kështu që tuneli transporton lidhjen por jo kërkimin. Një klient i vetëdijshëm për proxy me opsionin e DNS në distancë e shmang këtë; një aplikacion i kapur pa atë opsion nuk e shmang. Kontrolloni cili zgjidhës u përgjigj në vend që të supozoni se përshtatësi e ndryshoi.

Mbani dëgjuesin SOCKS të lidhur me loopback, verifikoni çelësin host të serverit SSH në përdorimin e parë dhe lini validimin normal HTTPS në vendin e vet për sajtin përfundimtar. SSH mbron segmentin telefon-te-server; nuk kripton atë që bën serveri më pas.

Kontrolloni dy ciklet e jetës dhe vendosni

Përshtatësi dhe sesioni SSH kanë cikle jete të veçanta. Nëse SSH bie ndërsa përshtatësi vazhdon të kapë, aplikacionet mund të varin pa gabim të dukshëm, sepse paketat e tyre ende hyjnë në një ndërfaqe virtuale që nuk ka më dalje funksionale. Nëse përshtatësi ndalon, aplikacionet ose shkojnë direkt ose bllokohen, sipas politikës VPN të pajisjes.

Testoni të dy drejtimet me qëllim: vrisni sesionin SSH ndërsa përshtatësi punon, pastaj ndaloni përshtatësin ndërsa SSH mbetet lart. Ajo që bën telefoni në secilin rast është politika që po vendosni vërtet, çfarëdo që pretendonin udhëzimet e instalimit.

Nëse rrjedha e punës kërkon mbulim të të gjithë pajisjes me një mënyrë dështimi të parashikueshme, një VPN IP e vërtetë, ose një përshtatës i mirëmbajtur i projektuar për këtë zinxhir, është përgjigjja e ndershme. Një sesion shell i lënë të punojë pranë një aplikacioni kapës të palidhur nuk është tunel i mirëmbajtur pajisjeje; janë dy komponentë pa marrëveshje për atë që ndodh kur njëri prej tyre mbaron.