Android-in tək-VPN qaydası telefondakı SSH serverini bloklamır

Bu inanc fakt kimi qəbul ediləcək qədər geniş yayılıb: Android yalnız bir VPN-ə icazə verir, ona görə telefondakı SSH serveri bu tuneldən işləyə bilməz. Birinci yarısı doğrudur, nəticə isə çıxmır. Platforma məhdudiyyəti VPN xidməti slotunu neçə tətbiqin tuta biləcəyi ilə bağlıdır, neçə soketin ola biləcəyi və ya telefonla kimin əlaqə qura biləcəyi ilə deyil. Dinləyici soketi olan SSH demonu adi portu olan adi tətbiqdir və tunel onun trafikinin gedə biləcəyi yollardan biridir.

Tək-VPN qaydası əslində nəyi məhdudlaşdırır

VpnService tək slotlu resursdur. Tətbiq tunel quranda cihazın VPN-i olur, ikinci tətbiq də qurmağa çalışsa, birincisi getməyənə qədər rədd edilir. Bu, tunelin sahibliyi haqqında qaydadır və iki VPN müştərisinin niyə eyni vaxtda işləyə bilmədiyini izah edir.

Dinləyici soketlər barədə heç nə demir. SSH serveri VpnService çağırmır, paketləri tutmur və o slot uğrunda yarışmır. Port bağlayır və bağlantıları qəbul edir, bu da VPN heç quraşdırılmadıqda etdiyi şeydir. Beləliklə mif tunel təminatçılarına qoyulan limiti şəbəkə bağlantılarına qoyulan limitlə qarışdırır və ikisinin əlaqəsi yoxdur.

Dinləyici təyinat nöqtəsidir, tunelin hissəsi deyil

Tunel yarandıqdan sonra telefonun üzərində ünvanı olur və həmkar cihazın həmin ünvana marşrutu olur. Nəyinsə cavab verib-vermədiyini dinləyici həll edir. Loopback-ə bağlanmış demon yalnız telefondan əlçatandır; köhnə tunel ünvanına bağlanmış demon yenidən qoşulmadan sonra ünvan dəyişsə də bağlantısını saxlaya bilər.

Bağlama qaydaları adi SSH konfiqurasiyasıdır: dinləmə ünvanı və portu, həmçinin kimin autentifikasiya edə biləcəyi. Android-də bu parametrlər tətbiqin öz konfiqurasiyasındadır və tətbiq prosesinin sahibinə imtiyazlı portlardan istifadə icazəsi verilməyə bilər, ona görə masaüstündə 22 portunu root kimi bağlamaq vərdişi dəyişmədən keçmir.

ListenAddress 10.90.0.4
Port 2222
AllowUsers alice

Sonra yolun özündə icazə var. Gedən veb-trafiki məmnuniyyətlə daşıyan istehlakçı VPN müştərilərinə daxil olan bağlantılara ümumiyyətlə icazə verməyə borclu deyil; çoxları vermir, çünki bu bir müştərini digərinə məruz qoyardı. Həmkar telefonun tunel ünvanına heç yerdən çata bilmirsə, problem xidmətin siyasətindədir, telefondadır deyil.

Cavab marşrutu adətən burada qırılır

Fərz edin ki, həmkar telefonun tunel ünvanına çatır və SYN gəlir. İndi cavab eyni yolla çıxmalıdır və bu, telefonun daxilində marşrut qərarıdır. Cavab Wi-Fi ilə çıxsa, çünki bu default şəbəkədir, həmkar heç vaxt tamamlanmayan bağlantı görür, bu da tam olaraq firewall kimi görünür.

Android bunu masaüstündən daha mürəkkəb edir, çünki default şəbəkə proses üzrə seçilir və VPN tətbiqinin siyasəti ilə dəyişdirilə bilər. VPN müştərisi yalnız icazə verilən tətbiqlər siyahısını marşrutlaşdıra bilər, ona görə bu siyahıdan kənar server tətbiqi cavabları üçün fiziki şəbəkədən istifadə etməyə davam edir, həmkar isə onları tuneldən gözləyir.

Tətbiq öz soketlərini konkret şəbəkəyə də bağlaya bilər və bu, defaultu üstələyir. Xidmətin bir ünvandan əlçatan, digərindən deyil yazıldığı hesabatı oxuyanda, adətən arxadakı mexanizm budur.

VPN-i yan keçmək daxil olan xidməti düzəltmir

Populyar həll, SSH tətbiqini VPN-dən çıxarmaq ki, trafiki yönləndirilməsin, əks problemin düzəlişidir. Gedən SSH müştərisinin nəqli tunel üzündən daim qırılanda kömək edir. Hostinq serveri üçün isə cavabları həmkarın istifadə etdiyi tuneldən kənara çıxara bilər və bu, qismən nasazlığı tam nasazlığa çevirir.

Routerdə açıq port açmaq üçün də eyni şey doğrudur. Tələb bir səlahiyyətli cihazın telefonu VPN ilə əldə etməsidirsə, SSH-ı internetə açmaq başqa təhdid modelidir, təmir deyil.

Əvvəlcə xidmət ünvanını qərar verin: telefonun LAN ünvanı, tunel ünvanı və ya qəsdən yönləndirilmiş son nöqtə. Hər birinin öz əlçatanlıq və məruzqalma müqaviləsi var və onları qarışdırmaq kiçik giriş probleminin daimi deşik olması yoludur.

Bir dəfə bir istiqaməti diaqnoz edin

Konfiqurasiyanı dəyişməzdən əvvəl dörd faktı yazın: həmkarın qoşulduğu ünvan, telefondakı dinləyici vəziyyəti, onu saxlayan tətbiq və istifadəçi konteksti, hər istiqamətdə müşahidə olunan yol. VPN SSH-ı kəsir deyən hesabat bunlardan heç birini saxlamır və müştəri nəqli problemini əlçatmaz serverdən ayıra bilmir.

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

Port yoxlamasını telefondan deyil, həmkardan aparın və SSH müştərisinin ətraflı çıxışını oxuyaraq TCP əl sıxmasından əvvəl və ya sonra uğursuz olduğunu görün. Heç qoşulmayan soket və rədd edilən giriş fərqli mərhələlər və fərqli sahiblərdir.

Sazlama zamanı host açarının yoxlanmasını və hesab məhdudiyyətlərini toxunulmaz saxlayın. Dinləyicini və icazə verilən istifadəçiləri məhdudlaşdırmaq əlçatan serveri məqbul edən şeydir; bağlantı işləsin deyə onları yumşaltmaq bir problemi daha pis biri ilə dəyişir. OpenSSH server sənədi dinləmə və giriş nəzarətlərini əhatə edir, əgər Android tətbiqiniz eyni konfiqurasiya adlarına əməl edirsə.