Android, iOS və Windows-da ping etmədən VPN statusunu necə yoxlamaq olar
Ping yalnız bir hostun cavab verdiyini sübut edir, tunelin işlədiyini yox. Android, iOS və Windows status API-lərini sorğulayın, sonra tətbiqinizin həqiqətən ehtiyac duyduğu marşrutu yoxlayın.
192.0.2.10 ünvanına ping göndərmək sizə yalnız bir ünvanın ICMP echo-ya cavab verdiyini deyir və bununla bitir. Tunelsiz şəbəkədə bu yenə uğurlu ola bilər, çünki ünvan lokal alt şəbəkədə ola bilər; sağlam tunel ilə isə uğursuz ola bilər, çünki server HTTPS xidmət edərkən ICMP-ni atır. Skriptinizə lazım olan yoxlama platforma statusu sorğusu və tətbiqin istifadə etdiyi hədəf üçün marşrut testidir. Bunları iki ayrı sahə kimi qəbul edin, heç vaxt tək boolean kimi yox.
Echo cavabı əslində nəyi sübut edir
ICMP interfeyslər və ya tunellər anlayışı olmayan əlçatanlıq protokoludur. Cavab gəldikdə nüvə yalnız bir hostun cavab verdiyini bildirir; sorğunu və ya cavabı hansı marşrutun daşıdığını bildirmir. Filtrləmə siqnalı daha da qarışıq edir, çünki echo sorğularını bloklayan firewall arxasındakı portlar haqqında heç nə demir. Split-tunnel profili isə yoxlanan ünvanı qəsdən kənarda saxlaya bilər, halbuki bütün digər hədəflər işləyir.
Əsl bilmək istədiyiniz konkret xidmətin tətbiqin getdiyi yol üzərindən istifadə oluna biləcəyidir. Tətbiqin müraciət etdiyi host və portu seçin, sonra tətbiq qatında cavab tələb edin.
Əlçatanlıq və tunel vəziyyəti fərqli faktlardır və biri doğru ola bilər, digəri isə yox. Onları ayrı saxlamaq sizə nasazlığın kimə aid olduğunu deyir. Onları bir yoxlamada birləşdirmək isə heç kimin yönləndirə bilməyəcəyi bir bilet yaradır.
Android-dən ping yox, transport soruşun
Android status sualına birbaşa ConnectivityManager vasitəsilə cavab verir. Aktiv şəbəkənin imkanları VPN transport bayrağı daşıyır və trafik VPN interfeysi ilə yönləndirildikdə qurulur. Çağırış lokaldır, ucuzdur və hər hansı uzaq hostun cavab verməsindən asılı deyil.
Bu Java versiyası aktiv şəbəkə olmadıqda istisna atmaq əvəzinə false qaytarır. Aktiv şəbəkəni oxuduğu üçün istifadəçinin Parametrlərdə seçdiyi profili əks etdirir.
ConnectivityManager cm = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE);
NetworkCapabilities caps = cm.getNetworkCapabilities(cm.getActiveNetwork());
boolean tunnel = caps != null && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);
Dəyişiklik bildirişləri üçün taymerlə sorğulamaq əvəzinə NetworkCallback qeyd edin. Bunu VpnService.prepare ilə qarışdırmayın; o yalnız istifadəçinin VPN üçün icazə verdiyini bildirir, paketlərin axdığını yox. Ləğv VpnService.onRevoke vasitəsilə gəlir, lakin Parametrlərdə profili unutmaq heç bir yayım yaratmır.
iOS: interfeys adları müqavilə deyil, evristikadır
Bir çox iOS kodu proksi parametrlərini yoxlayır, __SCOPED__ lüğətini tapır və tap, tun, utun2, ppp və ya ipsec kimi interfeys açarlarını axtarır. Bu yanaşma adlandırma konvensiyasıdır, sənədləşdirilmiş zəmanət deyil, ona görə interfeysin adını dəyişən OS yeniləməsi onu poza bilər. O həmçinin tuneldən sonra da qalan köhnə qeydlər üçün doğru nəticə verməyə meyllidir.
Tətbiqiniz konfiqurasiyaya sahib olduqda NEVPNManager sizə real status verir. O, tətbiqinizin başlatdığı tuneli təsvir edir; tətbiq başına VPN ilə digər tətbiqlər tamamilə həmin tuneldən kənarda qala bilər.
Statusu oxumadan əvvəl tərcihləri yenidən yükləyin, çünki dəyər tunel gəlib-getdikcə dəyişir:
let manager = NEVPNManager.shared()
manager.loadFromPreferences { error in
let up = manager.connection.status == .connected
print(up)
}
Platforma status bayrağı hələ də trafikin həmsöhbətə çatdığını sübut etmir. Bu boşluğu marşrut testi örtür və buna görə dəstək üçün tək boolean kifayət deyil.
Windows profilləri real status sahəsi təqdim edir
Windows VPN profillərini adapterlərdən ayrı izləyir və Get-VpnConnection bildiyi hər profil üçün ConnectionStatus verir. Windows müştərisi və ya provizinq paketi ilə yaradılan profillər burada görünür. Bu cmdlet ümumi tunel detektoru deyil.
Adlı profil üçün sahəni oxuyun, profil bütün istifadəçilərə aid olduqda -AllUserConnection əlavə edin:
Get-VpnConnection -Name "Fabrikam" | Select-Object Name, ConnectionStatus, ServerAddress
Üçüncü tərəf müştəriləri tunelləri işlədiyi halda belə bu cmdlet üçün çox vaxt görünməz qalır, ona görə boş nəticə bilinməz deməkdir, bağlı deyil. Adapter siyahıları da eyni dərəcədə aldadıcıdır: vendor adapteri boş qalsa da qala bilər, bəzi adapterlər isə yalnız sessiya zamanı mövcuddur. Windows-un sahib olduğu profil üçün rasdial budaqlana biləcəyiniz çıxış kodu bildirir. Bütün bunlar yerli inancı təsvir edir, həmsöhbətin əlçatanlığını yox.
Status və marşrut: iki hissəli yoxlama
Bağlı profil paketlərin hara getdiyi haqqında heç nə demir. Split tunneling tuneli işlək saxlayarkən bəyəndiyiniz hədəfi kənarda saxlaya bilər. Always-on profillər ölü serverlə bağlı qalır, kill switch isə tunel düşdükdə trafiki qəsdən bloklayır.
Hər iki qatı yoxlayın: VPN transportunun və ya profilin aktiv olduğunu təsdiqləyin, sonra hədəfin həll olunduğunu və həmin yol üzərindən cavab verdiyini təsdiqləyin. Linux-da nüvədən hansı interfeysi istifadə edəcəyini soruşun:
ip route get 192.0.2.10
resolvectl query intranet.example.test
Müştəri sizin nəzarətinizdən kənardadırsa, hər iki nəticəni qeyd edin və qoy naxış qatı göstərsin. Bağlı və uğursuz marşrut testi split tunneling, DNS və ya siyasətə işarə edir. Bağlı deyil və işləyən marşrut testi trafiki başqa yolun daşıdığını bildirir.
Sıra ilə işlədə biləcəyiniz test
Hər hansı şəbəkə vəziyyətini dəyişməzdən əvvəl platforma statusunu qeyd edin. Host adını həll edin və ünvan ailəsini qeyd edin, çünki AAAA qeydi A qeydindən fərqli yol tuta bilər. Xidmət portunu açın və sadə əl sıxışmadan çox tətbiq cavabı tələb edin. Hər müşahidəni öz log sahəsində saxlayın.
dig və curl olan Linux maşınında üç əmr həlli, marşrutu və xidmətin özünü əhatə edir. Onları tunel işlək ikən və yenidən söndürülmüş halda işlədin:
dig +short intranet.example.test
ip route get 198.51.100.20
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 https://intranet.example.test/health
Dörd ayrı sahə tək boolean-dan üstündür, çünki status, DNS, marşrut və siyasət müstəqil şəkildə sıradan çıxır və fərqli komandalara düşür. Terminalda ping yaxşı manual sağlamlıq yoxlaması olaraq qalır. Avtomatlaşdırma üçün isə o, əlaqənin zəif tərifidir; orada platforma API-si və marşrut testi əsl suala cavab verir.