Proksi SOCKS SSH di Android: mengapa hanya separuh aplikasi anda bersambung

Anda log masuk melalui SSH, menambah -D 1080, dan arahan itu berjaya. Kini ada pendengar SOCKS pada telefon, dan separuh aplikasi masih keluar melalui data mudah alih. Itu hasil biasa, bukan terowong rosak: ssh -D mencipta titik akhir proksi, dan aplikasi Android hanya menggunakan proksi jika sesuatu memaksa mereka. Menelusuri rantaian langkah demi langkah menunjukkan di mana setiap bahagian kerja sebenarnya berada.

Mulakan di tempat trafik bermula

Pilih satu aplikasi yang sepatutnya menggunakan terowong dan semak sama ada ia mempunyai tetapan proksi sendiri. Pelayar dengan medan SOCKS ialah kes mudah: halakan ia ke 127.0.0.1:1080, hidupkan DNS jauh jika tetapan itu wujud, dan permintaan itu berlalu. Klien sembang, aplikasi peta atau permainan tanpa medan itu tiada cara menggunakan pendengar, dan apa sahaja yang anda taip dalam arahan SSH tidak mengubahnya.

Sebelum melibatkan apa-apa lagi, buktikan pendengar berfungsi dari shell telefon sendiri dengan klien yang bercakap SOCKS secara langsung:

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

Alamat yang kembali sepatutnya milik pelayan SSH, bukan telefon. Jika ya, separuh proksi sudah selesai dan kerja selebihnya tentang liputan. Jika tidak, betulkan sisi SSH dahulu: pengesahan kunci, keupayaan pelayan mencapai destinasi, dan egress pelayan SSH itu sendiri.

Tambah bahagian yang diperlukan Android

Aplikasi tanpa tetapan proksi memerlukan sesuatu yang menangkap paket mereka dan menukarnya menjadi sambungan proksi. Pada peranti tanpa root, itu ialah penyesuai perkhidmatan VPN: aplikasi yang mengambil antara muka maya dan memajukan trafik terpilih ke pendengar SOCKS setempat. Rantaian menjadi aplikasi, penyesuai, pendengar SOCKS, sambungan SSH, destinasi.

Pasang penyesuai, berikan kebenaran VPN dan pilih aplikasi atau laluan yang perlu ditangkapnya. Ikon kunci dalam bar status kemudian mewakili penyesuai, bukan VPN komersial berasingan. Android membenarkan satu sambungan perkhidmatan VPN aktif bagi setiap profil pengguna, jadi memulakan aplikasi VPN kedua tidak menambah lapisan pada rantaian: ia bersaing untuk peranan yang sama.

Ini juga langkah di mana ujian yang berjaya boleh mengelirukan anda. Jika penyesuai ditetapkan untuk menangkap hanya pelayar yang sudah anda halakan ke proksi, semuanya berfungsi dan tiada apa-apa lagi dilindungi. Baca senarai tangkapan sebelum membuat kesimpulan peranti sudah berterowong.

Kekalkan pengangkutan SSH di luar tangkapan

Sambungan SSH itu sendiri tidak boleh disalurkan semula ke dalam terowong SOCKS yang dijaganya. Jika penyesuai menangkap trafik aplikasi SSH, terowong bergantung pada sambungan yang menunggu terowong, dan hasilnya ialah gelung yang tersangkut atau gagal sebaik penyesuai bermula.

Pelaksanaan bersepadu melindungi soket pengangkutan mereka sendiri. Dengan aplikasi berasingan anda perlukan pengecualian yang disokong: biarkan aplikasi SSH di luar tangkapan, atau kecualikan titik akhir SSH mengikut alamat. Kedua-duanya ada kos. Mengecualikan seluruh aplikasi terminal juga mengeluarkan aktiviti rangkaian tidak berkaitannya daripada terowong, dan pengecualian alamat rosak apabila alamat pelayan berubah atau apabila nama diselesaikan secara berbeza pada sambungan seterusnya.

Semak pengecualian dari luar: sambung semula penyesuai, kemudian pastikan sesi SSH bertahan dan permintaan melalui proksi masih melaporkan alamat pelayan. Sesi yang berfungsi sehingga penyesuai bermula kemudian membeku ialah gelung itu.

Ikuti DNS dan UDP hingga hujung rantaian

Pemajuan dinamik OpenSSH membawa sambungan TCP. Ia bukan pengangkutan UDP-associate atau ICMP, dan penyesuai tidak boleh mencipta pemajuan UDP dengan menerima paket UDP. Apa sahaja yang mendesak UDP, termasuk QUIC dan media WebRTC, akan gagal atau jatuh semula ke TCP bergantung pada aplikasi.

DNS perlukan keputusannya sendiri. Aplikasi yang menyelesaikan nama secara setempat menghantar pertanyaan melalui penyelesai biasa sebelum bersambung, jadi terowong membawa sambungan tetapi bukan carian. Klien yang sedar proksi dengan pilihan DNS jauh mengelakkannya; aplikasi yang ditangkap tanpa pilihan itu tidak. Semak penyelesai mana yang menjawab dan bukan menganggap penyesuai mengubahnya.

Kekalkan pendengar SOCKS terikat pada loopback, sahkan kunci hos pelayan SSH pada penggunaan pertama, dan biarkan pengesahan HTTPS biasa di tempatnya untuk tapak akhir. SSH melindungi segmen telefon-ke-pelayan; ia tidak menyulitkan apa yang pelayan lakukan selepas itu.

Semak dua jangka hayat dan putuskan

Penyesuai dan sesi SSH mempunyai jangka hayat berasingan. Jika SSH terputus semasa penyesuai terus menangkap, aplikasi boleh tergantung tanpa ralat jelas, kerana paket mereka masih masuk ke antara muka maya yang tiada lagi jalan keluar yang berfungsi. Jika penyesuai berhenti, aplikasi sama ada keluar terus atau disekat, bergantung pada dasar VPN peranti.

Uji kedua-dua arah dengan sengaja: bunuh sesi SSH semasa penyesuai berjalan, kemudian hentikan penyesuai semasa SSH masih hidup. Apa yang telefon lakukan dalam setiap kes ialah dasar yang sebenarnya anda gunakan, apa pun yang didakwa oleh arahan pemasangan.

Jika aliran kerja memerlukan liputan seluruh peranti dengan mod kegagalan yang boleh dijangka, VPN IP sebenar, atau penyesuai yang diselenggara dan direka untuk rantaian ini, ialah jawapan jujur. Sesi shell yang dibiarkan berjalan di sebelah aplikasi penangkap tidak berkaitan bukan terowong peranti yang diselenggara; ia dua komponen tanpa persetujuan tentang apa yang berlaku apabila salah satu daripadanya tamat.