Aturan satu VPN Android tidak memblokir server SSH yang dihosting

Kepercayaan ini cukup umum untuk diperlakukan sebagai fakta: Android hanya mengizinkan satu VPN, jadi server SSH yang berjalan di ponsel tidak dapat bekerja melalui tunnel itu. Paruh pertama benar dan kesimpulannya tidak mengikuti. Batas platform adalah tentang berapa banyak aplikasi yang boleh memegang slot layanan VPN, bukan tentang berapa banyak socket yang boleh ada atau siapa yang boleh terhubung ke ponsel. Daemon SSH dengan socket pendengar adalah aplikasi biasa dengan port biasa, dan tunnel adalah salah satu jalur yang dapat diambil lalu lintasnya.

Apa yang sebenarnya dibatasi aturan satu VPN

VpnService adalah sumber daya satu slot. Ketika sebuah aplikasi membangun tunnel, aplikasi itu menjadi VPN perangkat, dan aplikasi kedua yang mencoba membangunnya ditolak sampai yang pertama hilang. Itu aturan tentang kepemilikan tunnel, dan menjelaskan mengapa dua klien VPN tidak dapat berjalan bersamaan.

Itu tidak mengatakan apa pun tentang socket pendengar. Server SSH tidak memanggil VpnService, tidak menyadap paket, dan tidak bersaing untuk slot itu. Ia mengikat port dan menerima koneksi, hal yang sama yang akan dilakukannya tanpa VPN terpasang sama sekali. Jadi mitos ini mencampuradukkan batas pada penyedia tunnel dengan batas pada koneksi jaringan, dan keduanya tidak berhubungan.

Listener adalah tujuan, bukan bagian dari tunnel

Setelah tunnel ada, ponsel memiliki alamat di atasnya dan perangkat peer memiliki rute ke alamat itu. Apakah ada yang menjawab ditentukan oleh listener. Daemon yang terikat ke loopback hanya dapat dijangkau dari ponsel itu sendiri; daemon yang terikat ke alamat tunnel lama dapat mempertahankan ikatannya setelah tersambung ulang sementara alamat yang diikatnya telah berubah.

Aturan pengikatan adalah konfigurasi SSH biasa: alamat dan port dengar, dan siapa yang boleh mengautentikasi. Di Android pengaturan itu berada di konfigurasi aplikasi itu sendiri, dan pemilik proses aplikasi mungkin tidak diizinkan menggunakan port istimewa, sehingga kebiasaan desktop mengikat port 22 sebagai root tidak berpindah tanpa perubahan.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Lalu ada izin pada jalur itu sendiri. VPN konsumen yang dengan senang hati membawa lalu lintas web keluar belum tentu mengizinkan koneksi masuk ke kliennya sama sekali; banyak yang tidak, karena itu akan memaparkan satu pelanggan ke pelanggan lain. Jika peer tidak dapat menjangkau alamat tunnel ponsel dari mana pun, masalahnya ada pada kebijakan layanan, bukan pada ponsel.

Jalur balasan adalah tempat yang biasanya rusak

Misalkan peer mencapai alamat tunnel ponsel dan SYN tiba. Sekarang balasan harus keluar melalui jalur yang sama, dan itu keputusan perutean di dalam ponsel. Jika balasan keluar melalui Wi-Fi karena itu jaringan default, peer melihat koneksi yang tidak pernah selesai, yang terlihat persis seperti firewall.

Android membuat ini lebih rumit daripada desktop karena jaringan default dipilih per proses dan dapat diubah oleh kebijakan aplikasi VPN. Klien VPN hanya dapat merutekan daftar aplikasi yang diizinkan, jadi aplikasi server yang berada di luar daftar itu tetap menggunakan jaringan fisik untuk balasannya sementara peer mengharapkannya melalui tunnel.

Aplikasi juga dapat mengikat socket-nya sendiri ke jaringan tertentu, yang menimpa default. Ketika Anda membaca laporan bahwa suatu layanan dapat dijangkau dari satu alamat dan tidak dari alamat lain, inilah mekanisme di baliknya.

Melewati VPN tidak memperbaiki layanan masuk

Solusi populer, mengecualikan aplikasi SSH dari VPN agar lalu lintasnya berhenti dialihkan, adalah perbaikan untuk masalah sebaliknya. Ini membantu ketika transport klien SSH keluar terus rusak karena tunnel. Untuk server yang dihosting, ini dapat memindahkan balasan dari tunnel yang digunakan peer, yang mengubah kegagalan sebagian menjadi kegagalan total.

Hal yang sama berlaku untuk membuka port publik di router. Jika persyaratannya adalah satu perangkat resmi mencapai ponsel melalui VPN, mengekspos SSH ke internet adalah model ancaman yang berbeda dan bukan perbaikan.

Putuskan dulu alamat layanan: alamat LAN ponsel, alamat tunnelnya, atau endpoint yang sengaja diteruskan. Masing-masing memiliki kontrak keterjangkauan dan paparannya sendiri, dan mencampurnya adalah cara masalah akses kecil menjadi lubang permanen.

Diagnosis satu arah pada satu waktu

Tuliskan empat fakta sebelum mengubah konfigurasi: alamat yang dihubungi peer, status listener di ponsel, konteks aplikasi dan pengguna yang memilikinya, dan jalur yang diamati di setiap arah. Laporan yang mengatakan VPN memutus SSH tidak memuat satu pun dari itu dan tidak dapat membedakan masalah transport klien dari server yang tidak dapat dijangkau.

adb shell ip -br addr
adb shell ip route get 10.90.0.9
nc -vz 10.90.0.4 2222

Jalankan pemeriksaan port dari peer, bukan dari ponsel, dan baca keluaran verbose klien SSH untuk melihat apakah gagal sebelum atau sesudah handshake TCP. Socket yang tidak pernah tersambung dan login yang ditolak adalah tahap berbeda dengan pemilik berbeda.

Jaga verifikasi kunci host dan pembatasan akun tetap utuh saat Anda men-debug. Membatasi listener dan pengguna yang diizinkan adalah yang membuat server yang dapat dijangkau menjadi dapat diterima; melonggarkannya agar koneksi berfungsi menukar satu masalah dengan masalah yang lebih buruk. Referensi server OpenSSH mencakup kontrol dengar dan akses jika implementasi Android Anda mengikuti nama konfigurasi yang sama.