DNS üzerinden VPN, VPN DNS sunucusu ile aynı şey değil

DNS üzerinden VPN bir taşıma fikrini tanımlar ve bir cihazı özel bir çözümleyiciye yönlendirmekle eşanlamlı değildir. Karışıklığı çözen soru basittir: DNS iletileri gerçekte ne taşır? Sıradan bir VPN, kapsanan uygulamalar özel adları bulabilsin diye bir çözümleyici kurabilir ve o çözümleyiciyi değiştirmek yalnızca ad çözümlemesini değiştirir. Aşağıdaki kontrolleri sırayla yapın, çünkü üç düzenleme yalnızca sözcük dağarcığını paylaşır, neredeyse başka hiçbir şeyi değil.

Üç düzenlemeyi ayırın

İlk düzenlemede VPN bir çözümleyici veya ad ilkesi ayarı sağlar. Uygulama verileri hâlâ kendi ağ bağlantıları üzerinden gider ve tünel yalnızca hangi sunucunun sorguya yanıt verdiğini etkiler.

İkincisinde şifreli DNS, DNS alışverişinin kendisini korur. HTTPS üzerinden DNS ve TLS üzerinden DNS, sorguları seçilen çözümleyiciye sarar ve başka bir uygulamanın paketlerini taşımaz. Ayrıca sorgu adlarını seçtiğiniz çözümleyiciden gizlemezler; bu, onları yerel ağdan gizlemekten farklı bir güven sınırıdır.

Üçüncüsünde işbirliği yapan bir istemci başka verileri DNS iletilerine kodlar ve işbirliği yapan bir uç nokta bunları yeniden kurar. Olağan çözümleyici yolu taşıma hâline gelir ve çözümleyici artık ad hizmeti değil, veri yolunun bir bileşenidir.

DNS iletilerinin ne taşıdığını kontrol edin

Çözümleyiciyi değiştirin ve uygulamanın trafik yolunun değişip değişmediğini gözleyin. Uygulama hâlâ aynı soketler üzerinden aynı adreslere bağlanıyorsa ad çözümlemesini değiştirdiniz, başka bir şeyi değil.

DNS ile taşınan bir tünel, sunucu tarafında buna uygun bir düzenleme gerektirir. Iodine belgelenmiş bir örnektir: proje belgeleri DNS üzerinden bir IP tüneli tanımlar ve kodlamayı anlayan bir sunucu bileşeni gerektirir. Android'de genel bir çözümleyici adresi girmek o uç noktayı sağlamaz ve iki ürünün paylaştığı bir pazarlama terimi protokol belirtimi değildir.

Yakalama belirleyici kontroldür. Çözümleyiciye yalnızca olağan sorgular görüyorsanız tünel yoktur. Sorgu adlarına ve yanıtlara kodlanmış yük görüyorsanız taşıyıcıyı buldunuz ve sıradaki soru ne kadar hareket ettirebildiğidir.

Taahhüt vermeden önce kapasiteyi kontrol edin

DNS sorgular ve yanıtlar için tasarlandı, toplu teslimat için değil. Kodlama yükü, ileti boyutu sınırları ve çözümleyici davranışı nominal yolun bir payını alır, bu yüzden kullanılabilir kapasite alttaki bağlantının ima ettiğinden düşüktür. Kendi yolunuzda ölçmediğiniz her aktarım sayısını bütçe değil varsayım olarak ele alın. İki yönü de ölçün, çünkü istek-yanıt taşıyıcısında yükleme ve indirme farklı sınırlara çarpabilir.

Hangi trafiğin tünele gireceğine istemci de karar vermelidir. Yerel bir VPN hizmeti arayüzü paketleri toplayabilir, ancak arayüz uzak taşımanın bunları nasıl koruduğu veya ilettiği konusunda hiçbir şey söylemez. Taşıyıcı akış değil de istek-yanıt protokolü olduğunda parçalama ve yeniden iletim farklı davranır ve açık kalan bir bağlantı etkileşimli gecikme hakkında az şey söyler.

Taşımayı düşündüğünüz trafikle ölçün. Düzenli bir kalp atışı için iyi görünen bir tünel etkileşimli bir oturum için kullanılamaz olabilir ve tersi de doğrudur.

Taşıyıcının güvenliğini kontrol edin

DNS kapsüllemesinin gizlilik veya güçlü kimlik doğrulama sağladığını varsaymayın. Çözümleyici yolu ve tünel uç noktası, uygulamanın açığa çıkardığını görür ve bu açığa çıkma tasarıma göre değişir.

Şifreleme ve taşıyıcı seçimi ayrı özelliklerdir. Bir tünel düz bir IP yolu üzerinde şifrelenebilir ve DNS ile taşınan bir tünel yükünün korunmasıyla veya korumasız kurulabilir. Ne olursa olsun uygulamanın HTTPS'ini yerinde tutun ve tünelin adını değil gerçek güvenlik tasarımını değerlendirin.

Gereksinim yerel ağa karşı gizlilikse, şifreli DNS ve bir veri tüneli bunun farklı kısımlarına yanıt verir. Birini seçmeden önce hangi gözlemciye karşı savunduğunuzu yazın.

Düzeltmeyi gerçek arızaya uyarlayın

Olağan yavaş bir VPN için DNS ile taşınan bir tünelle değiştirmek, sorunun üstüne kısıtlı bir taşıma ekler. Radyo kalitesini, tıkanıklığı veya sunucu yükünü onarmaz ve genellikle bunları daha görünür kılar.

Özel ad arızalarında önce amaçlanan çözümleyici ilkesini inceleyin: hangi sunucu yanıt vermeli, hangi adlar kapsamda ve istemcinin onu kullanmasına izin veriliyor mu. Ardından gereksinime uyan yetkili bir taşıma seçin ve bir sonraki olayın aynı araştırmayı yeniden başlatmaması için çözümleyici yapılandırmasını değişiklik kaydında tutun.

Kontrol listesi kısadır: düzenlemeyi tanımlayın, iletilerin ne taşıdığını doğrulayın, kapasiteyi ölçün ve ardından güveni gözden geçirin. Belirtiyle uyuşmayan her adım, diğer iki düzenlemenin hâlâ oyunda olduğu anlamına gelir.