Android, iOS ve Windows'ta ping olmadan VPN durumu nasıl kontrol edilir

Ping yalnızca bir ana makinenin yanıt verdiğini kanıtlar, tünelin çalıştığını değil. Android, iOS ve Windows durum API'lerine sorun, ardından uygulamanızın gerçekten ihtiyaç duyduğu rotayı doğrulayın.

192.0.2.10 adresine ping atmak size yalnızca bir adresin ICMP yankısına yanıt verdiğini söyler, o kadar. Tünelsiz bir ağda yine başarılı olabilir, çünkü adres yerel alt ağda bulunuyor olabilir; sağlıklı bir tünelle başarısız olabilir, çünkü sunucu HTTPS sunarken ICMP'yi düşürür. Betiğinizin ihtiyaç duyduğu kontrol, platform durumu sorgusu artı uygulamanın kullandığı hedefe yönelik bir rota testidir. Bunları iki ayrı alan olarak ele alın, asla tek bir boolean olarak değil.

Yankı yanıtı gerçekte neyi kanıtlar

ICMP, arayüz veya tünel kavramı olmayan bir erişilebilirlik protokolüdür. Bir yanıt geldiğinde çekirdek bir ana makinenin yanıt verdiğini bildirir; isteği hangi rotanın taşıdığını veya yanıtı hangi rotanın getirdiğini bildirmez. Filtreleme sinyali daha da gürültülü yapar, çünkü yankı isteklerini engelleyen bir güvenlik duvarı arkasındaki bağlantı noktaları hakkında hiçbir şey söylemez. Ayrıca bölünmüş tünel profili, diğer tüm hedefler çalışırken test edilen adresi bilerek dışlayabilir.

Gerçekte bilmek istediğiniz şey, belirli bir hizmetin uygulamanın izlediği yolda kullanılabilir olup olmadığıdır. Uygulamanın çağırdığı ana makineyi ve bağlantı noktasını seçin, ardından uygulama katmanında yanıt talep edin.

Erişilebilirlik ve tünel durumu farklı gerçeklerdir ve biri doğruyken diğeri yanlış olabilir. Bunları ayrı tutmak arızanın kime ait olduğunu söyler. Tek bir kontrolde birleştirmek, kimsenin yönlendiremeyeceği bir kayıt üretir.

Android'e ping değil, taşıma sorun

Android durum sorusunu doğrudan ConnectivityManager üzerinden yanıtlar. Etkin ağın yetenekleri bir VPN taşıma bayrağı taşır ve bu bayrak trafik bir VPN arayüzünden yönlendirildiğinde ayarlanır. Çağrı yereldir, ucuzdur ve herhangi bir uzak ana makinenin yanıt verip vermemesinden bağımsızdır.

Bu Java sürümü, etkin ağ yokken istisna fırlatmak yerine false döndürür. Etkin ağı okuduğu için kullanıcının Ayarlar'da seçtiği profili yansıtır.

ConnectivityManager cm = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE);
NetworkCapabilities caps = cm.getNetworkCapabilities(cm.getActiveNetwork());
boolean tunnel = caps != null && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);

Değişiklik bildirimleri için zamanlayıcıyla yoklamak yerine bir NetworkCallback kaydedin. Bunu, yalnızca kullanıcının VPN için izin verip vermediğini bildiren VpnService.prepare ile karıştırmayın; paketlerin akıp akmadığını bildirmez. İptal VpnService.onRevoke üzerinden gelir, ancak Ayarlar'da bir profili unutmak hiçbir yayın üretmez.

iOS: arayüz adları bir sezgidir, sözleşme değil

Birçok iOS kod parçası proxy ayarlarını inceler, __SCOPED__ sözlüğünü bulur ve tap, tun, utun2, ppp veya ipsec gibi arayüz anahtarlarını arar. Bu yaklaşım bir adlandırma geleneğidir, belgelenmiş bir garanti değildir, bu yüzden bir arayüzü yeniden adlandıran işletim sistemi güncellemesi onu bozabilir. Ayrıca tünelden daha uzun yaşayan eski girdiler için true bildirme eğilimindedir.

Yapılandırma uygulamanıza aitse NEVPNManager gerçek bir durum verir. Uygulamanızın başlattığı tüneli tanımlar; uygulama başına VPN ile diğer uygulamalar o tünelin tamamen dışında kalabilir.

Durumu okumadan önce tercihleri yeniden yükleyin, çünkü tünel kalkıp indikçe değer değişir:

let manager = NEVPNManager.shared()
manager.loadFromPreferences { error in
    let up = manager.connection.status == .connected
    print(up)
}

Platform durum bayrağı yine de trafiğin eşe ulaştığını kanıtlamaz. Tam bu boşluğu rota testi kapatır ve bu yüzden destek için tek bir boolean yeterli değildir.

Windows profilleri gerçek bir durum alanı sunar

Windows, VPN profillerini bağdaştırıcılardan ayrı izler ve Get-VpnConnection bildiği her profil için bir ConnectionStatus sunar. Windows istemcisi veya hazırlama paketiyle oluşturulan profiller burada görünür. Bu cmdlet genel bir tünel algılayıcısı değildir.

Adlandırılmış bir profil için alanı okuyun ve profil tüm kullanıcılara aitse -AllUserConnection ekleyin:

Get-VpnConnection -Name "Fabrikam" | Select-Object Name, ConnectionStatus, ServerAddress

Üçüncü taraf istemciler tünelleri çalışırken bile bu cmdlet için görünmez kalır, bu yüzden boş sonuç bilinmiyor demektir, bağlantı kesildi değil. Bağdaştırıcı listeleri de aynı ölçüde yanıltıcıdır: satıcı bağdaştırıcısı boşta dururken kalıcı olabilir ve bazı bağdaştırıcılar yalnızca oturum sırasında bulunur. Windows'un sahip olduğu bir profil için rasdial, dallanabileceğiniz bir çıkış kodu bildirir. Bütün bunlar yerel inancı tanımlar, eşin erişilebilirliğini değil.

Durum artı rota: iki parçalı kontrol

Bağlı bir profil paketlerin nereye gittiği hakkında hiçbir şey söylemez. Bölünmüş tünel, önemsediğiniz hedefi dışlayarak tüneli açık tutabilir. always-on profiller ölü bir sunucuyla bağlı kalır ve kill switch tünel düştüğünde trafiği bilerek engeller.

Her iki katmanı test edin: bir VPN taşımasının veya profilin etkin olduğunu doğrulayın, ardından hedefin o rota boyunca çözümlendiğini ve yanıt verdiğini doğrulayın. Linux'ta çekirdeğe hangi arayüzü kullanacağını sorun:

ip route get 192.0.2.10
resolvectl query intranet.example.test

İstemci kontrolünüz dışındaysa iki sonucu da günlüğe yazın ve desenin katmanı göstermesine izin verin. Bağlı ve başarısız rota testi bölünmüş tünel, DNS veya ilke önerir. Bağlantı kesik ve çalışan rota testi, trafiği başka bir yolun taşıdığı anlamına gelir.

Sırayla çalıştırabileceğiniz bir test

Herhangi bir ağ durumunu değiştirmeden önce ilk olarak platform durumunu kaydedin. Ana makine adını çözümleyin ve adres ailesini not edin, çünkü bir AAAA kaydı bir A kaydından farklı bir yol izleyebilir. Hizmet bağlantı noktasını açın ve sadece el sıkışma yerine uygulama yanıtı talep edin. Her gözlemi kendi günlük alanında tutun.

dig ve curl bulunan bir Linux makinesinde üç komut çözümlemeyi, rotayı ve hizmetin kendisini kapsar. Tünel açıkken ve ardından kapalıyken çalıştırın:

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ört ayrı alan bir boolean'ı yener, çünkü durum, DNS, rota ve ilke bağımsız olarak başarısız olur ve farklı ekiplere düşer. Terminaldeki ping iyi bir elle kontrol olmayı sürdürür. Otomasyon için zayıf bir bağlantı tanımıdır; orada platform API'si ve bir rota testi gerçek soruyu yanıtlar.

İlgili makaleler