Android uygulaması VPN üzerinden çalışmayı reddediyor: hangi katman karar veriyor

Tünel devreye girdiği anda bir Android uygulaması çalışmayı bıraktığında üç farklı şey sorumlu olabilir ve bunlar benzer görünen hatalar üretir. Uygulama telefonun kendi ağ durumunu okuyup yerel olarak reddedebilir. Sunucu, geldiğiniz adresi sınıflandırıp reddedebilir. Ya da ret, VPN ile hiç ilgili olmayabilir. Aşağıdaki sıra, bir şeyi değiştirmeden önce kanıt toplar; çünkü çıkışı değiştirmek en pahalı adımdır ve denetim yereldeyse yardımcı olma olasılığı en düşüktür.

Adım 1: uygulamanın ne zaman reddettiğini öğrenin

Zaman ilk ayırıcıdır. Günlük tamponunu temizleyin, hatayı yeniden üretin ve uygulamanın şikâyet etmeden önce ne yaptığına bakın:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

Uygulama herhangi bir giden istek denenmeden önce reddediyorsa yerel bir kararla karşı karşıyasınız. Bağlanıyor, bir şey gönderiyor ve ancak ondan sonra hata gösteriyorsa ret diğer taraftan gelmiştir. Uygulama tünel kapalıyken de aynı şekilde başarısız oluyorsa VPN hiçbir zaman değişken olmadı.

Bu zamanı kanıt olarak görün, kesin hüküm olarak değil. Uygulama önbelleğe alınmış bir yanıtı yeniden oynatabilir ve arka plan istekleri siz bakmadan önce başarılı ya da başarısız olmuş olabilir. Yalnızca mesajın göründüğü anı değil, son başarılı isteğin ve hatanın zaman damgalarını not edin.

Adım 2: telefonun ağa kendi bakışını okuyun

Android, VPN durumunu bir ağ yeteneği olarak sunar; bu yüzden bir uygulamanın etkin bir tüneli fark etmek için ticari sağlayıcı listesine ihtiyacı yoktur. Bağlantı hizmetine geçerli ağın hangisi olduğunu sorar ve yanıt bir VPN taşıma biti içerir:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

Bu denetim yereldir ve ucuzdur; herhangi bir uzak sınıflandırma olmadan "bu uygulama VPN üzerinden çalışmıyor" türündeki bildirimlerin tamamını açıklar. Uygulamanın görebildikleri yine de kendi ağ bağlamına bağlıdır; bu yüzden her uygulamanın cihazdaki her profili denetlediğini varsaymayın.

Bir iş istasyonundan aynı durumu adb shell dumpsys connectivity ile ve VPN ağı girdisini arayarak test cihazında görebilirsiniz. Tünel açıkken yapılan bir çalıştırmayı kapalıyken yapılanla karşılaştırın ve iki çıktıyı da saklayın.

Adım 3: sunucunun gerçekte ne gördüğünü okuyun

Diğer gözlemci hizmettir. Gelen kaynak adresi görür ve adrese, arkasındaki barındırma ağına, bölgeye, operatöre veya hesap ve cihazla bağlı sinyallere göre işlem yapabilir. Bunların hiçbiri benzersiz bir kimlik değildir ve paylaşılan adresleme yan blokajları normal kılar: kısıtlı bir adres, aynı çevirinin arkasındaki ilgisiz kullanıcıları devre dışı bırakabilir.

Adresi uygulamanın kullandığı yoldan alın, dizüstü bilgisayardaki tarayıcıdan değil. Telefonda, bir adres yankı hizmetine yapılan düz bir istek uzak tarafın ne aldığını gösterir; bunu hücresel ağ üzerinden yapılan bir istekle karşılaştırmak adresin hiç değişip değişmediğini söyler.

Uygulama hücresel ağda çalışıp aynı hesapla tünel üzerinden başarısız oluyorsa ret uzak uçtadır ya da uygulamanın kendi politikasındadır. Her ikisinde de başarısız oluyorsa VPN fark değildir ve uç noktaları test etmeyi bırakmalısınız.

Adım 4: kanıtları üç hükümden biriyle eşleştirin

Üç kombinasyon neredeyse her bildirimi kapsar. Tünel etkinken giden bir deneme olmadan reddetmek yerel bir taşıma denetimine işaret eder. Giden ve hatayla dönen bir istek, belirli bir ana bilgisayarda zaman aşımı veya bölge mesajı uzak tarafa işaret eder. Tünel olmadan hücresel ağda tekrarlanan bir hata hesaba, uygulama sürümüne veya hizmetin kendi politikasına işaret eder ve hiçbir VPN değişikliği onu yerinden oynatmaz.

Hükmü, onu üreten kanıtlarla birlikte yazın. Bu adımın değeri, birinin telefondaki bir denetimi düzeltmek için dört kez çıkış düğümü değiştirdiği döngüyü durdurmasıdır.

Aynı zamanda iddiaları dürüst tutar. Kendi sunucunuzu barındırmak uç noktayı ve internet çıkışını değiştirir; Android'e bir VPN ağının etkin olduğunu unutturmaz ve adresleri sınıflandıran bir hizmetin kabulünü garanti etmez. Yerel bir filtre, size ait bir VPN ağında da ticari bir ağdaki kadar kolay tetiklenebilir.

Adım 5: desteklenen yolu izleyin ve doğrulayın

Ürünün belgelenmiş politikası ve destek sahibiyle başlayın. İstemci sürümünü, tam mesajı ve dar bir hata aralığını gönderin; yalnızca bir hatanın var olduğunu kanıtlamak için tam trafik kayıtları veya kimlik bilgileri göndermeyin.

Hizmet doğrudan erişime izin veriyorsa ve cihaz politikası buna izin veriyorsa, uygulama bazında hariç tutma desteklenen mekanizmadır ve tüneli gizlemek yerine o uygulamayı tünelden kasıtlı olarak çıkarır. Uygulamanın trafiği sonra kendi yolundan çıkar; bu, birinin sahiplenmesi gereken bir politika kararıdır. VPN olmadan bloklama yapılandırmasında, hariç tutulan bir uygulama bağlantısını basitçe kaybedebilir; bu yüzden çalıştığını vaat etmeden önce bu kombinasyonu test edin.

Her değişiklikten sonra birinci adımın zaman testini yineleyin, uygulamanın çalıştığını doğrulayın ve diğer tüm uygulamaların hâlâ tüneli kullandığını doğrulayın. Sonra önceki yapılandırmayı geri yükleyin ve hatanın geri dönüp dönmediğini kontrol edin, çünkü yeniden üretemediğiniz bir düzeltme, yeniden karşılaşacağınız bir tesadüftür.