Android uygulaması adları VPN dışında çözüyor: bağlama kontrol listesi

VPN etkinken Android adları varsayılan ağ üzerinden çözebilir. Süreci VPN ağına bağlayın ve uygulamanın gerçekte hangi resolver'ı kullandığını doğrulayın.

VPN istemcisinin kendi tarayıcısı ulaşırken bir Android uygulaması dahili bir adı çözemiyor ve aynı derleme başka bir telefonda çalışıyor. Değişken URL değil. Değişken, uygulama sürecinin çözümleme için hangi ağı kullanmasına izin verildiği ve Android, etkin VPN'in soketlerinizin kullandığı ağ olduğunu garanti etmiyor. Bu denetimleri sırayla yapın ve resolver anlık görüntüsü varsayımınızla uyuşmadığında durun.

Adım 1: uygulamanın hangi ağda olduğunu kanıtlayın

Durum çubuğunu değil, uygulamanın kendi görünümünü okuyun. ConnectivityManager üzerinden etkin ağı, onun LinkProperties, DNS sunucuları listesini ve özel DNS ayarını alın. Liste VPN'in resolver'ını içeriyorsa uygulamanın oraya bir yolu vardır; Wi-Fi'nin resolver'ını içeriyorsa tünel o süreç için varsayılan ağ değildir.

Etkin VPN simgesi yalnızca bir tünel olduğunu söyler. Uygulama sürecinin ona bağlandığını söylemez ve Android ad çözümlemesini her zaman etkin görünen ağ üzerinden yönlendirmez. Başka bir cihaza yönlendiren yerel VPN uygulamaları, interneti olmayan Wi-Fi ağları ve üretici derlemeleri uygulamayı tünelin sunucuları yerine varsayılan resolver'a sordurur bırakabilir.

Adım 2: VPN taşımasını isteyin ve süreci bağlayın

Uygulama tünelin resolver'ını kullanmak zorundaysa VPN taşıması olan bir ağ isteyin ve geri çağrımda süreci bağlayın, böylece kod ağın ne zaman görüneceğini tahmin etmez:

val request = NetworkRequest.Builder()
    .addTransportType(NetworkCapabilities.TRANSPORT_VPN)
    .build()

connectivityManager.requestNetwork(request, object : NetworkCallback() {
    override fun onAvailable(network: Network) {
        val bound = connectivityManager.bindProcessToNetwork(network)
        Log.i(TAG, "bound to VPN network: " + bound)
    }
})

Çağrı tüm sürecin varsayılan ağını değiştirir, bu yüzden sonrasında oluşturulan her soket onu kullanır. Zaten var olan soketler oluşturuldukları ağı korur, bu nedenle bağlamadan önce açılan bir bağlantı havuzu eski yoldan çözümlemeye devam edebilir. Dönen değer boolean'dır ve false sonucu bağlamanın gerçekleşmediği anlamına gelir; kısa bir gecikmeyle yeniden deneyin ve iki denemeyi de günlüğe yazın.

Adım 3: bağlamayı gereksinim duyulanla sınırlayın

Tüm süreci bağlamak kabadır. Telemetri, güncelleme denetimleri ve üçüncü taraf SDK'ları da tünele geçer ve tünelin interneti yoksa başarısız olmaya başlarlar. Tek bir istek için ağın soket fabrikasını kullanın ve geri kalan her şey için cihazın varsayılanını bırakın. Bilinçli olarak tek bir model seçin: bağlantı başına dar bağlama ya da VPN kaybolduğunda açık bir çözme ile süreç bağlaması.

Resolver'ın iki özelliği bağlamayı hiçbir hata olmadan bozabilir. Katı moddaki özel DNS, sorguları ağın resolver'ı yerine adlandırılmış bir DoT sunucusuna gönderir ve kendi DNS-over-HTTPS istemcisini getiren bir uygulama sistem resolver'ını tamamen atlar. Bağlamanın başarısız olduğu sonucuna varmadan önce ikisini de denetleyin. VPN'in DNS sunucusuna asla ulaşmayan bir sorgu tünel tarafındaki hiçbir günlükte görünmez.

Adım 4: CONNECTED kısıtına güvenmeyin

WorkManager'da NetworkType.CONNECTED bir ağın bağlı olduğu anlamına gelir ve VPN taşıması, altındaki Wi-Fi veya hücresel bağlantı gitse bile bunu karşılar. İş çalışır, her istek başarısız olur ve yeniden deneme ilkesi bunu zamanlama hatası gibi görünen bir fırtınaya dönüştürür. Tünel bir ağdır; kısıt hiçbir zaman internet denetimi olmadı.

İşin gerçekten ihtiyaç duyduğu yeteneği, örneğin doğrulanmış internet erişimini denetleyin ve geri çekilmeli sınırlı bir yeniden deneme ilkesi tutun. İş özel bir ada ihtiyaç duyuyorsa, işi yapmadan önce o adı seçilen ağda çözün ve başarılı olamayacak bir isteği yinelemek yerine açık bir hatayla hızlıca başarısız olun.

Adım 5: kanıtları kaydedin ve aralığı yeniden test edin

Seçilen ağın taşıma türlerini, LinkProperties üzerinden DNS sunucularını, bağlamanın true döndürüp döndürmediğini ve ilk isteğin tam hatasını günlüğe yazın. Ardından aynı bağlama altında özel bir ad ve genel bir ad çalıştırın. Bu çift, uygulamanın tünelin resolver'ını mı kullandığını yoksa sessizce cihazın varsayılanına mı düştüğünü gösterir ve kullanıcının yaşadığı fark budur.

Desteklediğiniz en eski Android sürümünde ve bir güncel sürümde yineleyin. Varsayılan yolu doğru gösteren resolver davranışı, cihazların ve sürümlerin ayrıldığı tam noktadır ve yalnızca en yeni test cihazında geçen bir derleme, gönderdiğiniz aralık için doğrulanmamıştır. adb shell dumpsys connectivity, hatayı yeniden üretirken cihazın hangi ağları ve yetenekleri bildirdiğini hızlıca doğrulamanın bir yoludur.

İlgili makaleler