Android'ning yagona VPN qoidasi xostingdagi SSH serverni bloklamaydi

Bu e'tiqod shunchalik keng tarqalganki, u fakt sifatida qabul qilinadi: Android faqat bitta VPN ga ruxsat beradi, shuning uchun telefonda ishlaydigan SSH server o'sha tunnel orqali ishlay olmaydi. Birinchi yarmi to'g'ri va xulosa undan kelib chiqmaydi. Platforma cheklovi VPN xizmatining o'rnini qancha ilova egallashi mumkinligi haqida, qancha socket bo'lishi yoki kim telefonga ulanishi mumkinligi haqida emas. Tinglovchi socketga ega SSH demon oddiy portli oddiy ilova, tunnel esa uning trafigi borishi mumkin bo'lgan yo'llardan biri.

Bitta VPN qoidasi aslida nimani cheklaydi

VpnService bitta o'rinli resurs. Ilova tunnel o'rnatganda u qurilmaning VPN iga aylanadi, tunnel o'rnatishga urinayotgan ikkinchi ilova esa birinchisi yo'qolguncha rad etiladi. Bu tunnel egaligi haqidagi qoida va ikki VPN mijozi nega bir vaqtda ishlay olmasligini tushuntiradi.

Tinglovchi socketlar haqida hech narsa demaydi. SSH server VpnService ni chaqirmaydi, paketlarni ushlamaydi va o'sha o'rin uchun raqobatlashmaydi. U portni bog'laydi va ulanishlarni qabul qiladi, bu VPN umuman o'rnatilmaganda ham shunday qilardi. Shuning uchun afsona tunnel provayderlariga qo'yilgan cheklovni tarmoq ulanishlariga qo'yilgan cheklov bilan aralashtiradi, ikkalasi o'rtasida hech qanday bog'liqlik yo'q.

Tinglovchi manzil, tunnelning qismi emas

Tunnel mavjud bo'lganda, telefonning unda manzili bor, hamkor qurilmaning esa o'sha manzilga yo'li bor. Biror narsa javob beradimi, buni tinglovchi hal qiladi. loopback ga bog'langan demon faqat telefonning o'zidan yetib borish mumkin; eski tunnel manziliga bog'langan demon qayta ulangandan keyin ham bog'lanishini saqlab qolishi mumkin, garchi u bog'langan manzil o'zgargan bo'lsa.

Bog'lash qoidalari oddiy SSH konfiguratsiyasi: tinglash manzili va porti, va kim autentifikatsiyadan o'ta oladi. Android da bu sozlamalar ilovaning o'z konfiguratsiyasida, va ilova jarayoni egasiga imtiyozli portlardan foydalanishga ruxsat berilmagan bo'lishi mumkin, shuning uchun ish stolida port 22 ni root sifatida bog'lash odati o'zgarmagan holda o'tmaydi.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Keyin yo'lning o'zidagi ruxsat bor. Chiquvchi veb-trafikni xursandchilik bilan tashiydigan iste'molchi VPN o'z mijozlariga kiruvchi ulanishlarga umuman ruxsat bermasligi mumkin; ko'pchilik bermaydi, chunki bu bir mijozni boshqasiga ochib qo'yadi. Agar hamkor telefonning tunnel manziliga hech qayerdan yetib bora olmasa, muammo xizmat siyosatida, telefonda emas.

Javob yo'li odatda uziladigan joy

Hamkor telefonning tunnel manziliga yetib, SYN keladi deb faraz qilaylik. Endi javob o'sha yo'l orqali chiqishi kerak, va bu telefon ichidagi marshrutlash qarori. Agar javob standart tarmoq bo'lgani uchun Wi-Fi orqali chiqsa, hamkor hech qachon tugamaydigan ulanishni ko'radi, bu xuddi xavfsizlik devoriga o'xshaydi.

Android buni ish stolidan murakkabroq qiladi, chunki standart tarmoq har bir jarayon uchun tanlanadi va VPN ilovasi siyosati uni o'zgartirishi mumkin. VPN mijozi faqat ruxsat etilgan ilovalar ro'yxatini marshrutlashi mumkin, shuning uchun o'sha ro'yxatdan tashqaridagi server ilovasi o'z javoblari uchun jismoniy tarmoqdan foydalanishda davom etadi, hamkor esa ularni tunnel orqali kutadi.

Ilova o'z socketlarini muayyan tarmoqqa ham bog'lashi mumkin, bu esa standartni bekor qiladi. Xizmat bir manzildan yetib borish mumkin, boshqasidan yo'q degan hisobotni o'qiganingizda, odatda shu mexanizm uning orqasida bo'ladi.

VPN ni chetlab o'tish kiruvchi xizmatni tuzatmaydi

Mashhur yechim, SSH ilovasini VPN dan chiqarib tashlash, shunda uning trafigi qayta yo'naltirilmaydi, qarama-qarshi muammoning tuzatishi. Bu chiquvchi SSH mijozining transporti tunnel sabab doimiy buzilganda yordam beradi. Xostingdagi server uchun u javoblarni hamkor ishlatayotgan tunneldan tashqariga olib chiqishi mumkin, bu qisman nosozlikni to'liq nosozlikka aylantiradi.

Xuddi shu marshrutizatorda ommaviy port ochishga ham tegishli. Agar talab bitta vakolatli qurilmaning VPN orqali telefonga yetib borishi bo'lsa, SSH ni internetga ochish boshqa tahdid modeli, tuzatish emas.

Avval xizmat manzilini hal qiling: telefonning LAN manzili, uning tunnel manzili yoki ataylab yo'naltirilgan oxirgi nuqta. Har birining o'z yetib borish va ochiqlik shartnomasi bor, ularni aralashtirish kichik kirish muammosini doimiy teshikka aylantirish yo'lidir.

Bir vaqtda bir yo'nalishni diagnostika qiling

Konfiguratsiyani o'zgartirishdan oldin to'rt faktni yozing: hamkor ulanayotgan manzil, telefondagi tinglovchi holati, uni egallagan ilova va foydalanuvchi konteksti, va har bir yo'nalishda kuzatilgan yo'l. VPN SSH ni uzadi degan hisobotda ularning hech biri yo'q va u mijoz transporti muammosini yetib bo'lmaydigan serverdan ajrata olmaydi.

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

Port tekshiruvini hamkordan ishga tushiring, telefondan emas, va SSH mijozining batafsil chiqishini o'qib, u TCP qo'l berishdan oldin yoki keyin muvaffaqiyatsiz bo'lishini ko'ring. Hech qachon ulanmaydigan socket va rad etilgan kirish turli bosqichlar, mas'ullar ham turli.

Nosozlikni bartaraf etishda xost kalitini tekshirish va hisob cheklovlarini daxlsiz saqlang. Tinglovchi va ruxsat etilgan foydalanuvchilarni cheklash yetib borish mumkin bo'lgan serverni maqbul qiladi; ulanish ishlashi uchun ularni bo'shashtirish bir muammoni yomonroqqa almashtiradi. Agar Android amalga oshirishingiz o'sha konfiguratsiya nomlariga rioya qilsa, OpenSSH server ma'lumotnomasi tinglash va kirish nazoratini qamrab oladi.