Peraturan satu VPN Android tidak menyekat pelayan SSH yang dihoskan

Kepercayaan ini cukup biasa untuk dianggap sebagai fakta: Android hanya membenarkan satu VPN, jadi pelayan SSH yang berjalan pada telefon tidak boleh berfungsi melalui terowong itu. Separuh pertama benar dan kesimpulannya tidak menyusul. Had platform adalah tentang berapa banyak aplikasi boleh memegang slot perkhidmatan VPN, bukan tentang berapa banyak soket boleh wujud atau siapa yang dibenarkan menyambung ke telefon. Daemon SSH dengan soket mendengar ialah aplikasi biasa dengan port biasa, dan terowong ialah salah satu laluan yang boleh dilalui trafiknya.

Apa yang sebenarnya dihadkan oleh peraturan satu VPN

VpnService ialah sumber slot tunggal. Apabila aplikasi menubuhkan terowong, ia menjadi VPN peranti, dan aplikasi kedua yang cuba menubuhkannya ditolak sehingga yang pertama hilang. Itu peraturan tentang pemilikan terowong, dan ia menjelaskan mengapa dua klien VPN tidak boleh berjalan serentak.

Ia tidak berkata apa-apa tentang soket mendengar. Pelayan SSH tidak memanggil VpnService, tidak memintas paket dan tidak bersaing untuk slot itu. Ia mengikat port dan menerima sambungan, perkara yang sama yang akan dilakukannya tanpa VPN dipasang langsung. Jadi mitos ini mengelirukan had pada penyedia terowong dengan had pada sambungan rangkaian, dan kedua-duanya tidak mempunyai kaitan.

Pendengar ialah destinasi, bukan bahagian terowong

Setelah terowong wujud, telefon mempunyai alamat padanya dan peranti rakan mempunyai laluan ke alamat itu. Sama ada sesuatu menjawab ditentukan oleh pendengar. Daemon yang terikat pada loopback hanya boleh dicapai dari telefon itu sendiri; daemon yang terikat pada alamat terowong lama mungkin mengekalkan ikatannya selepas sambungan semula walaupun alamat yang diikatnya telah berubah.

Peraturan pengikatan ialah konfigurasi SSH biasa: alamat dan port mendengar, dan siapa yang boleh mengesahkan. Pada Android tetapan itu berada dalam konfigurasi aplikasi itu sendiri, dan pemilik proses aplikasi mungkin tidak dibenarkan menggunakan port istimewa, jadi tabiat desktop mengikat port 22 sebagai root tidak berpindah tanpa perubahan.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Kemudian ada kebenaran pada laluan itu sendiri. VPN pengguna yang dengan senang hati membawa trafik web keluar tidak semestinya membenarkan sambungan masuk kepada kliennya langsung; banyak yang tidak, kerana ia akan mendedahkan seorang pelanggan kepada yang lain. Jika rakan tidak dapat mencapai alamat terowong telefon dari mana-mana, masalahnya terletak pada dasar perkhidmatan, bukan pada telefon.

Laluan balasan ialah tempat ia biasanya rosak

Katakan rakan mencapai alamat terowong telefon dan SYN tiba. Kini balasan mesti keluar melalui laluan yang sama, dan itu keputusan penghalaan di dalam telefon. Jika balasan keluar melalui Wi-Fi kerana itu rangkaian lalai, rakan melihat sambungan yang tidak pernah selesai, yang kelihatan sama seperti tembok api.

Android menjadikannya lebih rumit daripada desktop kerana rangkaian lalai dipilih mengikut proses dan boleh diubah oleh dasar aplikasi VPN. Klien VPN hanya boleh menghalakan senarai aplikasi yang dibenarkan, jadi aplikasi pelayan di luar senarai itu terus menggunakan rangkaian fizikal untuk balasannya sementara rakan mengharapkannya melalui terowong.

Aplikasi juga boleh mengikat soketnya sendiri pada rangkaian tertentu, yang mengatasi lalai. Apabila anda membaca laporan bahawa sesuatu perkhidmatan boleh dicapai dari satu alamat dan bukan dari alamat lain, biasanya inilah mekanisme di sebaliknya.

Memintas VPN tidak membaiki perkhidmatan masuk

Penyelesaian popular, mengecualikan aplikasi SSH daripada VPN supaya trafiknya berhenti dilencongkan, ialah pembaikan untuk masalah yang bertentangan. Ia membantu apabila pengangkutan klien SSH keluar terus rosak kerana terowong. Untuk pelayan yang dihoskan ia boleh memindahkan balasan keluar dari terowong yang digunakan oleh rakan, yang menukar kegagalan separa menjadi kegagalan total.

Perkara yang sama berlaku untuk membuka port awam pada penghala. Jika keperluan ialah satu peranti sah mencapai telefon melalui VPN, mendedahkan SSH kepada internet ialah model ancaman yang berbeza dan bukan pembaikan.

Tentukan dahulu alamat perkhidmatan: alamat LAN telefon, alamat terowongnya, atau titik akhir yang dihantar terus dengan sengaja. Setiap satu mempunyai kontrak kebolehcapaian dan pendedahannya sendiri, dan mencampurkannya ialah cara masalah akses kecil menjadi lubang kekal.

Diagnos satu arah pada satu masa

Tulis empat fakta sebelum menukar konfigurasi: alamat yang disambung oleh rakan, keadaan pendengar pada telefon, konteks aplikasi dan pengguna yang memilikinya, dan laluan yang diperhatikan dalam setiap arah. Laporan yang mengatakan VPN memutuskan SSH tidak mengandungi satu pun daripadanya dan tidak dapat membezakan masalah pengangkutan klien daripada pelayan yang tidak dapat dicapai.

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 rakan, bukan dari telefon, dan baca keluaran terperinci klien SSH untuk melihat sama ada ia gagal sebelum atau selepas jabat tangan TCP. Soket yang tidak pernah bersambung dan log masuk yang ditolak ialah peringkat berbeza dengan pemilik berbeza.

Kekalkan pengesahan kunci hos dan sekatan akaun tanpa diubah semasa menyahpepijat. Mengehadkan pendengar dan pengguna yang dibenarkan itulah yang menjadikan pelayan yang boleh dicapai boleh diterima; melonggarkannya supaya sambungan berfungsi menukar satu masalah dengan yang lebih buruk. Rujukan pelayan OpenSSH merangkumi kawalan mendengar dan akses jika pelaksanaan Android anda mengikut nama konfigurasi yang sama.