SOCKS proxy sa SSH sa Android: bakit kalahati lang ng iyong mga app ang kumokonekta

Nag-login ka sa SSH, nagdagdag ng -D 1080, at nagtagumpay ang command. May SOCKS listener na ngayon sa telepono, at kalahati ng mga app ay dumadaan pa rin sa mobile data. Iyan ang normal na resulta, hindi sirang tunnel: ang ssh -D ay gumagawa ng proxy endpoint, at ang mga Android app ay gumagamit lang ng proxy kung may pumipilit sa kanila. Ang pagdaan sa chain nang hakbang-hakbang ay nagpapakita kung saan talaga nakatira ang bawat bahagi ng trabaho.

Magsimula kung saan nagsisimula ang traffic

Pumili ng isang app na dapat gumamit ng tunnel at tingnan kung may sariling proxy setting. Ang browser na may SOCKS field ang madaling kaso: itutok ito sa 127.0.0.1:1080, i-on ang remote DNS kung may ganoong setting, at dumadaan ang request. Ang chat client, map app o laro na walang ganoong field ay walang paraan para gamitin ang listener, at wala sa itatype mo sa SSH command ang makakabago niyon.

Bago isangkot ang anupaman, patunayang gumagana ang listener mula sa shell ng telepono mismo gamit ang client na direktang nagsasalita ng SOCKS:

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

Ang address na bumabalik ay dapat sa SSH server, hindi sa telepono. Kung gayon, tapos na ang kalahating proxy at ang natitirang trabaho ay tungkol sa coverage. Kung hindi, ayusin muna ang panig ng SSH: key authentication, kakayahan ng server na maabot ang destinasyon, at sariling labasan ng SSH server.

Idagdag ang bahaging kailangan ng Android

Ang mga app na walang proxy setting ay nangangailangan ng isang bagay na humuhuli sa kanilang mga packet at ginagawang proxy connection. Sa device na walang root, iyon ay isang VPN service adapter: app na kumukuha ng virtual interface at nagpapasa ng napiling traffic sa lokal na SOCKS listener. Ang chain ay nagiging app, adapter, SOCKS listener, SSH connection, destinasyon.

I-install ang adapter, bigyan ito ng VPN permission at piliin ang mga app o ruta na dapat nitong hulihin. Ang key icon sa status bar ay kumakatawan noon sa adapter, hindi sa hiwalay na commercial VPN. Pinapayagan ng Android ang isang aktibong VPN service connection bawat user profile, kaya ang paglunsad ng pangalawang VPN app ay hindi nagdadagdag ng layer sa chain: nakikipagkumpitensya ito para sa parehong papel.

Ito rin ang hakbang kung saan ang isang matagumpay na test ay maaaring manlinlang sa iyo. Kung ang adapter ay naka-set na hulihin lang ang browser na itinutok mo na sa proxy, gumagana ang lahat at wala nang iba pang sakop. Basahin ang capture list bago magpasya na ang device ay nasa tunnel.

Panatilihin ang SSH transport sa labas ng capture

Ang SSH connection mismo ay hindi dapat ibalik sa SOCKS tunnel na pinapanatili nito. Kung hinuhuli ng adapter ang traffic ng SSH app, ang tunnel ay nakadepende sa connection na naghihintay sa tunnel, at ang resulta ay loop na natigil o nabigo sa sandaling magsimula ang adapter.

Ang mga integrated implementation ay pinoprotektahan ang sariling transport socket. Sa hiwalay na mga app kailangan mo ng suportadong exception: iwanan ang SSH app sa labas ng capture, o i-exclude ang SSH endpoint ayon sa address. Pareho may halaga. Ang pag-exclude ng buong terminal app ay nag-aalis din sa tunnel ng walang kaugnayang network activity nito, at ang address exception ay nasisira kapag nagbago ang address ng server o kapag naiiba ang resolution ng pangalan sa susunod na koneksyon.

Suriin ang exception mula sa labas: ikonekta muli ang adapter, pagkatapos tiyakin na nabubuhay ang SSH session at ang request sa proxy ay nag-uulat pa rin ng address ng server. Ang session na gumagana hanggang magsimula ang adapter at pagkatapos ay nag-freeze ay ang loop na iyon.

Sundan ang DNS at UDP hanggang sa dulo ng chain

Ang dynamic forwarding ng OpenSSH ay nagdadala ng TCP connection. Hindi ito UDP-associate o ICMP transport, at hindi makakaimbento ang adapter ng UDP forwarding sa pamamagitan ng pagtanggap ng UDP packet. Anumang nagpipilit ng UDP, kasama ang QUIC at WebRTC media, ay mabibigo o babalik sa TCP depende sa app.

Ang DNS ay may sariling desisyon. Ang app na nagre-resolve ng pangalan nang lokal ay nagpapadala ng query sa normal na resolver bago kumonekta, kaya dinadala ng tunnel ang koneksyon pero hindi ang paghahanap. Ang proxy-aware client na may remote DNS option ay umiiwas doon; ang nahuling app na wala nito ay hindi. Suriin kung aling resolver ang sumagot sa halip na ipagpalagay na binago ito ng adapter.

Panatilihing nakatali sa loopback ang SOCKS listener, i-verify ang host key ng SSH server sa unang paggamit, at iwanan ang normal na HTTPS validation sa lugar para sa huling site. Pinoprotektahan ng SSH ang segment telepono-to-server; hindi nito ini-encrypt ang ginagawa ng server pagkatapos.

Suriin ang dalawang lifecycle at magpasya

Ang adapter at ang SSH session ay may hiwalay na lifecycle. Kung bumagsak ang SSH habang patuloy na humuhuli ang adapter, maaaring mag-hang ang mga app nang walang malinaw na error, dahil pumapasok pa rin ang kanilang packet sa virtual interface na wala nang gumaganang labasan. Kung huminto ang adapter, ang mga app ay dumadaan nang direkta o hinaharangan, depende sa VPN policy ng device.

Sadyang subukan ang parehong direksyon: patayin ang SSH session habang tumatakbo ang adapter, pagkatapos ihinto ang adapter habang nakatayo pa ang SSH. Ang ginagawa ng telepono sa bawat kaso ay ang policy na talagang ipinapakalat mo, anuman ang sinabi ng installation instructions.

Kung ang workflow ay nangangailangan ng coverage ng buong device na may predictable na failure mode, isang tunay na IP VPN, o isang maintained adapter na dinisenyo para sa chain na ito, ang tapat na sagot. Ang shell session na hinayaang tumakbo sa tabi ng walang kaugnayang capture app ay hindi maintained device tunnel; ito ay dalawang component na walang kasunduan tungkol sa nangyayari kapag natapos ang isa sa kanila.