Android always-on VPN: uç nokta adı neden önce çözümlenir

Telefon yeniden başlar, always-on açıktır, «VPN olmadan bağlantıları engelle» açıktır ve tünel asla yükselmez. Hiçbir şey yanlış yapılandırılmamıştır: engelleme işini yapıyordur ve istemcinin kendi uç noktasına ulaşma girişimi de ona tabidir. Uç noktanın adı, tünel var olmadan önce, diğer tüm uygulamalara izin verilmezken ağla konuşmasına izin verilen bir istemci tarafından çözümlenmelidir. Hangi bileşenin bunu yaptığını ve hangi sırayla yaptığını anlamak, bu gizemi bir yapılandırma sorusuna dönüştürür.

VPN oluşturucusu gerçekte ne ister

Bir Android VPN uygulaması platforma sunucu adresi vermez. Yerel bir arayüz kurar: tünel için adresler ve rotalar, uygulamaların içinde kullanması gereken çözümleyiciler ve ardından establish() uygulamanın ham IP paketleri olarak okuyup yazdığı bir dosya tanımlayıcısı döndürür. Uzak uç nokta o oluşturucuda hiç görünmez.

Kilit yapısal gerçek budur. Platform bir tun arayüzü oluşturur ve üzerinde ilke uygular; uygulama taşımayı kullanıcı alanında gerçekleştirir, yani uç noktasının adını kendisi çözer ve şifreli bağlantıyı kendisi açar. Bu nedenle ana makine adı biçimindeki bir uç nokta mümkündür — platform adları desteklediği için değil, platform uç noktayı hiç görmediği için.

Oluşturucudaki tek bir alan adres alır: DNS sunucuları. Bunlar sayısal çözümleyici adresleri olmalıdır, genellikle operatörün tünel üzerinden sorgulamak istedikleri. O alan, tünel yükseldikten sonra uygulamaların sorguları nereye gönderdiğini anlatır. İstemcinin uç noktayı nasıl bulduğu hakkında hiçbir şey söylemez ve bu ikisini aynı ayar sanmak karışıklığın başladığı yerdir.

Bir değil iki DNS sorusu

İlk soru şudur: tünel yükseldikten sonra uygulamalar sorguları nereye gönderir? Yanıt, tünelin içindeki bir çözümleyici adresidir; tun arayüzü üzerinden ulaşılabilir ve yapısı gereği sayısaldır.

İkinci soru şudur: istemci, o tünel var olmadan önce kendi uç noktasını nasıl bulur? Bu arama tünelin dışında, alttaki ağda, istemcinin sürecinde gerçekleşir. Bir ad kullanabilir ve cihazın VPN olmadan ulaşabildiği bir çözümleyici kullanmak zorundadır.

Üç aşama, üç farklı belirti. «Bağlanılamıyor» diyen tek bir hata iletisi hepsini birbirine karıştırır; bu yüzden insanlar o alan hiç okunmadan önce gerçekleşen bir sorunu düzeltmek için DNS sunucusu alanını düzenlemeye başlar.

Bootstrap neden kilitlenebilir

Always-on ve etkin engelleme, VPN içinde olmayan trafiğin atıldığı anlamına gelir; VPN'i sahiplenen uygulamanın trafiği de buna dahildir. Çıkış açıktır: uygulama bir sokette protect() çağırır, bu onu alttaki ağa bağlar, böylece tüneli atlar ve dışarı çıkmasına izin verilir. Her VPN istemcisi bunu kendi taşıması için yapmak zorundadır, aksi halde bir sunucuya asla ulaşamaz.

Şimdi, uç noktanın adını bilen tek çözümleyicinin kendisinin tünelin içinde olduğu bir kurulum düşünün. İstemcinin adı çözümlemek için tünele, tüneli kurmak için ada ihtiyacı vardır. Bu gerçek bir döngüsel bağımlılıktır ve hiçbir istemci yapılandırması bunu çözmez. Bu bir tasarım hatasıdır, yazılım hatası değil.

Zamanlama aynı bağımlılığı daha hafif biçimlerde ortaya koyar. İlk kilit açılmadan önceki önyüklemede cihazın henüz kullanılabilir bir ağı olmayabilir; bir captive portalda ağ vardır ama portal dışındaki her şeyi engeller; Wi-Fi'den hücresele geçişte korumalı soketin alttaki ağı değişir ve istemcinin bunu fark edip yeniden çözümlemesi gerekir. Bunların her biri bir bootstrap olayıdır ve her biri gece 3'te keşfedilmek yerine bilerek test edilmeye değer.

Yanıtı sabitlemek neden çözüm değil

Cazip kısa yol, adı bir kez çözümleyip elde edilen adresi sayısal bir alana yapıştırmak ya da özel bir derlemeye sabit kodlamaktır. İşe yarıyor gibi görünür ve adı bir fotoğrafa dönüştürür. Operatör uç noktayı taşıdığında — bir geçiş, bir anycast değişikliği, yeni bir bölgesel adres — istemci eskisini aramaya devam eder ve arayüzde hiçbir şey nedenini açıklamaz.

DNS kayıtları bir yaşam süresi taşır, tam da yanıtların değişebilmesi için; önbellekleme o süreye göre tanımlanır, sonsuza kadar değil. Bir yanıtı sabitlemek, adı adresten daha iyi yapan mekanizmayı çöpe atar, ama ad kullanmanın işletme maliyetini korur.

Sabitleme genellikle ikinci bir kötü alışkanlıkla birlikte gelir: bağlantı artık farklı biçimde başarısız olduğu için kimlik denetimlerini gevşetmek. Sunucu kimliği doğrulaması bootstrap sorununun parçası değildir ve onu zayıflatmak bir DNS rahatsızlığını bir dinleme riskiyle değiştirir.

Yeniden başlatmayı atlatan tasarımlar

Dayanıklı düzen gösterişsizdir. Korumalı soketleri doğru uygulayan ve uç noktasını alttaki ağda çözümleyen bir istemci kullanın ve ona herkese açık ya da tünelden önce ulaşılabilen bir çözümleyici aracılığıyla çözümlenen bir uç nokta adı verin. Engellemeyi açık bırakın; DNS çalışsın diye tamamen kapatmak, kurulumun var olma sebebi olan özelliği ortadan kaldırır.

Uç noktanın özel kalması gereken yerlerde, platformun kullanabileceği açık bir bootstrap yolu sağlayın — tünel olmadan ulaşılabilen bir çözümleyici ya da operatörün sürdürdüğü bir yönetim bağlantısı — ve bu istisnayı dar tutun, kullanıcı anahtarına değil ilkeye ait kılın. Android VpnService belgeleri, platformun koruma ve yaşam döngüsü konusunda neyi garanti ettiğinin referansıdır ve VpnService.Builder referansı DNS alanının sayısal adresler aldığını doğrular.

Ardından yeniden başlatmadan sonraki yeni bir bağlantıda üç aşamayı sırayla doğrulayın: uç nokta adı çözümlenir, tünel kurulur ve eş kimliği doğrulanır ve özel bir ad tünelin çözümleyicisi aracılığıyla çözümlenir. İlk aşama başarısız olursa sonrasındaki hiçbir şey çalışamaz ve düzeltme bootstrap yoluna aittir — asla çözümleyici alanına değil.

• Uç noktanın çözümlenmesi uygulamanın içinde, tünelin dışında, korumalı bir sokette gerçekleşir.
• Oluşturucudaki DNS alanı tünelin içindeki uygulamalar içindir, istemcinin kendi uç noktası için değil.
• Yalnızca tünel üzerinden ulaşılabilen bir çözümleyici kilitlenmedir, yavaş başlangıç değil.
• Yeniden başlatmadan sonra uç noktayı, kimlik doğrulamayı ve özel aramayı ayrı ayrı test edin.