Özel DNS'e karşı VPN: her katman gerçekte neyi kapsar

Telefonunuzda özel DNS bir sağlayıcı ana bilgisayar adına ayarlı ve aynı anda bir VPN uygulaması çalışıyor. Bunlardan birinin artık ad sorgularını yönettiğini varsaymak makul. Hiçbiri, bu cümlenin ima ettiği anlamda yönetmiyor ve nedenini görmenin en hızlı yolu, bir bağlantıya dokunduğunuz andan itibaren tek bir isteği izlemektir.

Bu iki özellik aynı yolculuğun farklı noktalarında durur. Özel DNS, bir çözümleyiciye sorduğunuz soruyu şifreler. VPN, yanıtın bağlantısının izlediği rotayı değiştirir.

Öyleyse bunu, ikisinin de etkin olduğu bir cihazda sırayla ele alın ve her katmanın hâlâ ne görebildiğini not edin.

Birinci adım: sorgu uygulamadan çıkar

Bir bağlantıya dokunursunuz. Herhangi bir şey bağlanmadan önce uygulamanın o ana bilgisayar adı için bir adrese ihtiyacı vardır. Android'de ilgili ekran Ayarlar, Ağ ve internet, Özel DNS'tir. Özel DNS sağlayıcı ana bilgisayar adını seçmek cihazı katı moda alır: bu ana bilgisayar adına 853 numaralı bağlantı noktasında TLS üzerinden DNS yapar ve şifreli alışveriş başarısız olursa sorgu, sessizce 53 numaralı bağlantı noktasında düz metne dönmek yerine başarısız olur.

Bu, fırsatçı şifreleme kullanan ve ağ işe karıştığında şifresiz bir çözümleyiciyi seve seve kullanan Otomatik'ten anlamlı bir farktır. Amacınız sorguların asla açıkta olmamasıysa, sağlayıcı ana bilgisayar adıyla katı mod buna uyan ayardır.

İşte bu yürüyüşün ortaya çıkardığı ilk şey: sorgu yerel ağa karşı korunur ve çözümleyici yine de adı öğrenir. Şifreleme sıçramayı kapsar. O çözümleyicinin işletmecisi sorguyu görür çünkü onu yanıtlamak onun işidir.

İkinci adım: bağlantı farklı bir rota izler

Çözümleyici bir adres döndürür ve uygulama ona bağlanır. Bu adım, sorgunun nasıl şifrelendiğinden etkilenmez. Tünel olmadan bağlantı normal genel adresinizden çıkar ve hedef IP ile TLS el sıkışması, şifreli DNS olsun ya da olmasın, ana bilgisayar adını genellikle ağa yine de görünür kılar.

VPN'i açın, değişen adım budur. İstemcinin yönlendirme ilkesine uyan trafik tünelden geçer, yerel ağ VPN uç noktasına bir bağlantı görür ve site genellikle çıkış adresini görür. Ad çözümlemesi, istemcinin ne gönderdiğine bağlı olarak tünelin içinde de yolculuk edebilir.

Bu ayrılık, tüm karşılaştırmanın tek cümlelik hâlidir. DNS şifrelemesi soruyu kimin okuyabileceğini yanıtlar. VPN sohbetin nereye gittiğini yanıtlar.

Üçüncü adım: tünelin içinde DNS bir ilke sorununa dönüşür

Şimdi iki özellik etkileşime girer ve tarayıcı her zamanki sürpriz kaynağıdır. Kendi güvenli DNS ayarına sahip bir tarayıcı, işletim sistemine sormak yerine sorguları seçtiği çözümleyiciye HTTPS üzerinden gönderebilir. Android'in özel DNS ayarı bu kararın içine ulaşmaz.

Firefox'ta anahtar Ayarlar, Gizlilik ve güvenlik, Güvenli DNS'i etkinleştir altındadır. Chrome'da ise Ayarlar, Gizlilik ve güvenlik, Güvenli DNS kullan altındadır. İkisi de belirli bir sağlayıcıya ayarlanabilir ya da kapalı bırakılabilir ve açık olduklarında, sayfa trafiği tüneli kullanmaya devam etse de bu sorgular için tünelin DNS yapılandırması atlanır.

VPN kendi çözümleyicisini gönderir ve tarayıcı kendi çözümleyicisinde ısrar ederse bir bölünme yaşarsınız: adlar çözülür, sayfalar yüklenir ve tünelden geçmesi gereken sorgular doğrudan dışarı çıkmıştır. VPN uç noktasından farklı bir çözümleyici adresi tek başına bir sızıntı kanıtı değildir, ama belirttiğiniz amaca aykırı düşen bir sorgu yolu düzeltilmeye değer.

Dördüncü adım: iç adlar kırılan yerdir

Bir iş VPN'ine bağlanın ve bir intranet ana bilgisayarı açın. Tarayıcının güvenli DNS'i açıksa ve genel bir çözümleyiciyi gösteriyorsa, o ad tarayıcı için yoktur. Tünel ayaktadır, her şey çalışır ve bir ana bilgisayar adı, site çökmüş gibi görünen bir hatayla başarısız olur.

Aynı arıza Android'de ters yönde ortaya çıkar. Genel bir sağlayıcıyla katı özel DNS, yalnızca iç çözümleyicinin bildiği adları çözmez ve katı modun bir geri dönüşü yoktur. Bir telefonun DNS'ini genel şifreli bir çözümleyici ile kurumsal bir çözümleyici arasında bölmek bir ayar değildir; VPN'i işletenin yanıtlaması gereken bir yönlendirme ilkesi sorunudur.

Tüneli suçlamadan önce bunu kontrol edin: iç adı sorgulayın, sonra aynı adı tarayıcının güvenli DNS'i kapalıyken sorgulayın. Çözülüyorsa sorun çözümleyici seçimiydi, bağlantı değil.

Yürüyüş size neyi değiştirmenizi söylüyor

Neredeyse her şeyi dört ekran taşır. Bunlara bu sırayla bakın ve her birinin ne dediğini yazın, çünkü yanıt genellikle bileşimde görünür:

1. Android Ayarlar, Ağ ve internet, Özel DNS: Otomatik veya bir sağlayıcı ana bilgisayar adı ve hangi ana bilgisayar adı.
2. Tarayıcının güvenli DNS ayarı: kapalı veya belirli bir çözümleyiciye sabitlenmiş.
3. VPN istemcisinin DNS ilkesi: bir çözümleyici gönderiyor mu ve bölünmüş tünel hâlâ adlara ihtiyaç duyan bir şeyi dışlıyor mu?
4. Tünel ayaktayken iç ana bilgisayar adı testi, iki kez çalıştırılmış, bir kez tarayıcı DNS'i açıkken ve bir kez kapalıyken.

Sonra düzeltmeyi gereksinime uyarlayın, tersini değil. Gereksinim sorguların şifreli çıkması ve seçtiğiniz bir çözümleyiciye gitmesiyse katı özel DNS'i ayarlayın ve tarayıcının buna katılmasını sağlayın. Gereksinim trafiğin başka bir yere çıkmasıysa tüneli yapılandırın ve bir DNS ayarının adresinizi taşımasını beklemeyi bırakın.

Ve sınırları göz önünde tutun. İki özellikten hiçbiri düşmanca bir hedefi güvenli kılmaz ve hiçbiri oturum açtığınız bir kimliği ortadan kaldırmaz. Şifreleme soruyu kimin okuyabileceğini değiştirir; tünel bağlantının nereye gittiğini değiştirir; bunların hiçbiri hesabı anonimleştirmez.