Proxy SOCKS SSH di Android: mengapa hanya separuh aplikasi Anda terhubung

Anda masuk lewat SSH, menambahkan -D 1080, dan perintahnya berhasil. Sekarang ada listener SOCKS di ponsel, dan separuh aplikasi tetap keluar lewat data seluler. Itu hasil normal, bukan tunnel rusak: ssh -D membuat titik akhir proxy, dan aplikasi Android hanya memakai proxy jika ada yang memaksa mereka. Menelusuri rantai langkah demi langkah menunjukkan di mana setiap bagian pekerjaan sebenarnya berada.

Mulai dari tempat lalu lintas dimulai

Pilih satu aplikasi yang seharusnya memakai tunnel dan periksa apakah ia punya pengaturan proxy sendiri. Peramban dengan kolom SOCKS adalah kasus mudah: arahkan ke 127.0.0.1:1080, aktifkan DNS jarak jauh jika pengaturannya ada, dan permintaan lewat. Klien obrolan, aplikasi peta, atau gim tanpa kolom itu tidak punya cara memakai listener, dan apa pun yang Anda ketik di perintah SSH tidak mengubahnya.

Sebelum melibatkan apa pun, buktikan listener bekerja dari shell ponsel itu sendiri dengan klien yang berbicara SOCKS langsung:

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

Alamat yang kembali seharusnya milik server SSH, bukan ponsel. Jika ya, separuh proxy selesai dan sisa pekerjaan soal cakupan. Jika tidak, perbaiki sisi SSH dulu: autentikasi kunci, kemampuan server menjangkau tujuan, dan egress server SSH itu sendiri.

Tambahkan bagian yang dibutuhkan Android

Aplikasi tanpa pengaturan proxy butuh sesuatu yang menangkap paketnya dan mengubahnya menjadi koneksi proxy. Di perangkat tanpa root, itu adaptor layanan VPN: aplikasi yang mengambil antarmuka virtual dan meneruskan lalu lintas terpilih ke listener SOCKS lokal. Rantainya menjadi aplikasi, adaptor, listener SOCKS, koneksi SSH, tujuan.

Pasang adaptor, beri izin VPN, dan pilih aplikasi atau rute yang harus ditangkapnya. Ikon kunci di bilah status lalu mewakili adaptor, bukan VPN komersial terpisah. Android mengizinkan satu koneksi layanan VPN aktif per profil pengguna, jadi menjalankan aplikasi VPN kedua tidak menambah lapisan pada rantai: ia bersaing untuk peran yang sama.

Ini juga langkah di mana uji yang berhasil bisa menyesatkan Anda. Jika adaptor diatur hanya menangkap peramban yang sudah Anda arahkan ke proxy, semuanya bekerja dan tidak ada yang lain tercakup. Baca daftar tangkapan sebelum menyimpulkan perangkat sudah bertunnel.

Jaga transport SSH di luar tangkapan

Koneksi SSH itu sendiri tidak boleh dialirkan kembali ke tunnel SOCKS yang dijaganya. Jika adaptor menangkap lalu lintas aplikasi SSH, tunnel bergantung pada koneksi yang menunggu tunnel, dan hasilnya adalah lingkaran yang macet atau gagal begitu adaptor mulai.

Implementasi terintegrasi melindungi soket transportnya sendiri. Dengan aplikasi terpisah Anda perlu pengecualian yang didukung: biarkan aplikasi SSH di luar tangkapan, atau kecualikan titik akhir SSH berdasarkan alamat. Keduanya punya biaya. Mengecualikan seluruh aplikasi terminal juga mengeluarkan aktivitas jaringan tak terkaitnya dari tunnel, dan pengecualian alamat rusak saat alamat server berubah atau saat nama diselesaikan berbeda pada koneksi berikutnya.

Periksa pengecualian dari luar: sambungkan ulang adaptor, lalu pastikan sesi SSH bertahan dan permintaan lewat proxy masih melaporkan alamat server. Sesi yang bekerja sampai adaptor mulai lalu membeku adalah lingkaran itu.

Ikuti DNS dan UDP sampai ujung rantai

Penerusan dinamis OpenSSH membawa koneksi TCP. Itu bukan transport UDP-associate atau ICMP, dan adaptor tidak bisa mengarang penerusan UDP dengan menerima paket UDP. Apa pun yang memaksa UDP, termasuk QUIC dan media WebRTC, akan gagal atau turun ke TCP tergantung aplikasinya.

DNS butuh keputusannya sendiri. Aplikasi yang menyelesaikan nama secara lokal mengirim kueri lewat resolver biasa sebelum terhubung, jadi tunnel membawa koneksinya tetapi bukan pencariannya. Klien yang sadar proxy dengan opsi DNS jarak jauh menghindarinya; aplikasi yang ditangkap tanpa opsi itu tidak. Periksa resolver mana yang menjawab alih-alih menganggap adaptor mengubahnya.

Jaga listener SOCKS terikat ke loopback, verifikasi kunci host server SSH saat pertama dipakai, dan biarkan validasi HTTPS normal tetap di tempatnya untuk situs akhir. SSH melindungi segmen ponsel-ke-server; ia tidak mengenkripsi apa yang server lakukan setelahnya.

Periksa dua masa hidup dan putuskan

Adaptor dan sesi SSH punya masa hidup terpisah. Jika SSH putus sementara adaptor terus menangkap, aplikasi bisa menggantung tanpa galat jelas, karena paketnya masih masuk ke antarmuka virtual yang tidak lagi punya jalan keluar yang bekerja. Jika adaptor berhenti, aplikasi entah langsung keluar atau diblokir, tergantung kebijakan VPN perangkat.

Uji kedua arah dengan sengaja: bunuh sesi SSH saat adaptor berjalan, lalu hentikan adaptor saat SSH tetap hidup. Apa yang ponsel lakukan dalam tiap kasus adalah kebijakan yang sebenarnya Anda terapkan, apa pun yang diklaim instruksi pemasangan.

Jika alur kerja butuh cakupan seluruh perangkat dengan mode kegagalan yang bisa diprediksi, VPN IP sungguhan, atau adaptor terpelihara yang dirancang untuk rantai ini, adalah jawaban jujurnya. Sesi shell yang dibiarkan berjalan di samping aplikasi penangkap tak terkait bukan tunnel perangkat terpelihara; itu dua komponen tanpa kesepakatan tentang apa yang terjadi saat salah satunya berakhir.