VPN'iniz DNS'yi mi şifreliyor, yoksa yalnızca sonraki atlamayı mı?
VPN sunucusundaki şifreli DNS, istemci tarafındaki DoT'tan farklı bir atlamayı korur. Herhangi bir şeyi etkinleştirmeden önce her sorguyu kimin aldığını izleyin.
VPN sunucusunda şifreli DNS'yi etkinleştirmek sıklıkla bir sızıntıyı kapatmak olarak tanımlanır ve bu tanım hangi bağlantının değiştiğini gizler. İstemciden çözümleyiciye giden atlama ile çözümleyiciden üst akışa giden atlama, ayrı sahipleri olan ayrı bağlantılardır. Birini şifrelemek diğerini tam olarak olduğu gibi bırakır.
Bir yapılandırma dosyasına dokunmadan önce her aşamada sorguyu kimin aldığını yazın.
İki düzenleme ayarlar sayfasında aynı görünür
İlk düzenlemede cihaz DNS over TLS'yi kendisi çalıştırır ve tünel yalnızca bu bağlantıyı seçtiğiniz çözümleyiciye taşır. TLS oturumu çözümleyicide sonlanır, yani çözümleyici sorguyu görür, VPN çıkışı ise okuyamadığı şifreli metni görür. İkinci düzenlemede cihaz sıradan DNS'yi tünel üzerinden VPN ana bilgisayarındaki bir ileticiye gönderir ve o iletici üst akış çözümleyicisine kendi şifreli bağlantısını açar. Bir özellik listesinde ikisi de "VPN ile şifreli DNS" gibi görünür ve okunabilir sorguyu farklı binalara yerleştirir.
Fark felsefi değil ölçülebilirdir. TLS oturumunu istemcide ya da sunucuda arayın, gerçekte hangi düzenlemeye sahip olduğunuzu öğrenirsiniz.
Değiştirmeden önce çözümleyici zincirini haritalayın
Yol üzerindeki çözümleyicileri sayın ve her birinin rolünü adlandırın. Bir iletme bileşeni isteği başka bir çözümleyiciye verir, oysa özyinelemeli çözümleyici yanıt bulma işini yapar ve yetkili sunucularla doğrudan konuşabilir. Bu roller tam da bu nedenle ayrı tanımlanmıştır ve RFC 9076 çözümleyici tanımları tek bir üst akış hedefi olduğunu varsaymadan önce okumaya değer. Kendi özyinelemeli çözümleyicisini çalıştıran bir ana bilgisayarın şifrelenecek tek bir "üst akışı" yoktur, bu da tüm planı geçersiz kılar.
Sonra istemcinin hangi bileşeni kullanacak şekilde yapılandırıldığını sorun. VPN profilinin verdiği DNS adresi sorguların nereye gittiğini söyler, hangi sürecin yanıtladığını değil.
Arıza davranışına da dikkat edin. Şifreli üst akış erişilemez hale gelirse iletici kapalı mı başarısız olur, düz metne mi döner, yoksa başka bir çözümleyiciye mi geçer? Bu karar kayıtta yer almalıdır, çünkü tünelin en sağlıksız olduğu anda gizlilik garantisini değiştirir.
Hangi atlamanın şifreli olduğunu doğrulayın
İstemciden başlayın ve 853 numaralı bağlantı noktasına bir TLS oturumu olup olmadığını doğrulayın. 53 numaralı bağlantı noktası üzerinden doğru çözülen bir sorgu şifreleme hakkında hiçbir şey kanıtlamaz.
resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A
Sonra VPN ana bilgisayarına geçin ve ileticinin açtığı giden şifreli bağlantıyı arayın. Soket tablosu üst akışta bir TLS oturumu olup olmadığını ve hangi sürecin ona sahip olduğunu söyler:
ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short
İstemci bir TLS oturumu gösteriyor ve sunucu hiçbir şey göstermiyorsa ilk düzenlemedesiniz ve sunucu IP katmanında ilettiği sorguları okuyamaz. Sunucu TLS oturumunu gösteriyor ve istemci tünelin içinde sıradan 53 numaralı bağlantı noktası trafiği gösteriyorsa ikinci düzenlemedesiniz: sonraki atlama korunur ve iletici cihazın istediği her adı hâlâ okur. Bu ikinci sonuç bir arıza değildir, ancak ona uçtan uca şifreleme demek yanlıştır.
Sahibi ve arıza davranışını kaydedin
Sahiplik neyi vaat edebileceğinize karar verir. Cihaz sahibi istemci tarafındaki şifreli bağlantıyı denetler, VPN yöneticisi ise ileticisinin oluşturduğu sonraki bağlantıyı denetler. İkisini de işletmeyen biri yalnızca yolu tanımlayabilir.
Herhangi bir şeyi etkinleştirmeden önce iç adlandırmayı kontrol edin. Kuruluş adlarını genel bir çözümleyiciye göndermek eşdeğer bir tasarım değildir ve yalnızca ağın içinde var olan bir split-horizon bölgesi üst akışta hiç çözülmez. Değişiklikten sonra bir iç ve bir genel adı test edin ve sonucu yapılandırma değişikliğiyle birlikte saklayın. Şifreli yol iç ana bilgisayarlar için çözümlemeyi bozarsa düzeltme daha geniş bir tünel değil, kapsamı sınırlı bir çözümleyici kuralıdır.
Her atlama için bir cümle yazarak bitirin: sorguyu hangi bileşen aldı, o atlama şifreli miydi ve adı kim okuyabilir. VPN ana bilgisayarıyla ilgili cümle hâlâ sorguları okuyabildiğini söylüyorsa belgeler de bunu söylemelidir, çünkü aksini iddia eden bir diyagrama komutları hiç çalıştırmamış biri güvenecektir.