Bölünmüş tünel tarayıcıyı hariç tutar, DNS sorgularını değil

Tarayıcı tünelden hariç tutulmuş, genel IP sayfası trafiğinin ev bağlantısından çıktığını doğruluyor ama iç wiki hâlâ açılmıyor. Ad çözümlemesi başka bir yere gitti ve o başka yer genellikle VPN’in ayarladığı çözümleyicidir. Veri yolu ile çözümleyici yolu çoğu bölünmüş tünel tasarımında ayrı kararlardır. Hariç tutmayı bozuk diye adlandırmadan önce tarayıcının gerçekte hangisini kullandığını denetleyin.

Veri yolu ile çözümleyici yolu ayrılır

Hariç tutma bir uygulamanın paketlerini tünelden çıkarır, bu veri yolunda yönlendirme ve güvenlik duvarı kararıdır. Ad çözümlemesi başka bir aramadır: bir süreç sistemin çözümleyicisine sorar ve o çözümleyici soruyu hangi sunucunun alacağına karar verir.

İkisi de kasıtlı ve farklı olabilir. Bir iş kurulumu iç ad alanlarını kurumsal çözümleyicide tutarken seçilmiş genel gezinmeyi tünelin dışına gönderebilir, tam da iç adlar başka hiçbir yerde çözülmediği için. Kafa karıştıran durum tersidir: genel bir site başarısız olur çünkü tarayıcı kurulumun beklediği çözümleyiciye hiç sormamıştır. Rotayı ve çözümleyiciyi ayrı ayrı kaydedin, tartışmaların yarısı kaybolur.

Soruyu hangi sürecin sorduğunu bulun

Bir tarayıcı sistemin çözümleyicisini, kendi şifreli DNS hizmetini veya işletim sisteminin her ağ için atadığı çözümleyiciyi kullanabilir. Birincisi platform ilkesini izler, ikincisi bu ilkeyi tamamen atlar, üçüncüsü sorgunun hangi bağlantıya yönlendirildiğine bağlıdır.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

Test etmeden önce yürürlükteki yapılandırmayı okuyun: hangi bağlantılar DNS sunucusu taşıyor, hangi ad alanlarını talep ediyor ve ad başına ilke varsayılanı geçersiz kılıyor mu. Linux’ta bölünmüş DNS yönlendirme alan adlarını kullanır; Windows’ta ad çözümleme ilkesi tablosu ad alanları için aynı işi yapar. Hiçbiri bir sızıntı testi sayfasından görünmez.

Hangi çözümleyicinin hangi adı gördüğüne karar verin

Herhangi bir şeyi değiştirmeden önce amaçlanan eşlemeyi yazın: iç adlar kurumsal çözümleyiciye, genel adlar ilkenin izin verdiği hizmete ve istisnalar bir sorumluyla birlikte. Bu liste olmadan sızıntı testindeki her etiket kimsenin kapatamayacağı bir ilke tartışmasına dönüşür.

Sonra tarayıcının kendi ayarını denetleyin, çünkü tarayıcıdaki şifreli DNS işletim sistemi sorguyu almadan önce uygulanır. Yakalama portalını atlatmak için bunu açan kullanıcı, kurulumun seçtiği çözümleyiciyi sessizce geçersiz kılmıştır. Bu bir sızıntı değil yapılandırma kararıdır ve engelleme listesi yerine kararı hak eder.

Bir test etiketini yeşile çevirmek için her DNS alanını yeniden yazmayın. Etiket bir sürecin bir andaki bir sorgusunu tanımlar.

Sorguyu ve bağlantıyı ayrı ayrı doğrulayın

İki yolu ayrı ayrı test edin. Bağlantı testi veri rotasını gösterir ve çözümleyici testi adı kimin aldığını gösterir.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

Çözümleyiciye açıkça da sorun, böylece başarısızlık yola değil sunucuya atfedilebilsin. Sonra tarayıcıyı yeniden başlatın ve yineleyin, çünkü uygulamalar olumsuz yanıtları önbelleğe alır ve eski bir başarısızlık kalıcı görünür.

Onaylanmış bir değişiklikten sonra veri rotasını ve çözümleyicinin alıcısını iki ayrı satır olarak tarihle birlikte kaydedin. Davranış bir sonraki yeniden bağlanmada geri dönerse düzeltilmesi gereken şey onu sağlayan profildir, tarayıcı değil.