VPN DNS'e karşı tarayıcı DoH'u: bir sızıntı testinin size söyleyemeyeceği şey
Bir sızıntı testi adresi yalnızca hangi çözümleyicinin yanıt verdiğini gösterir. Şifreli sorgular, bölünmüş DNS ve tarayıcı politikası, özel adların hâlâ çözülüp çözülmeyeceğini belirler.
Sızıntı testi sayfası DNS'inizin iyi olduğunu söylüyor, tarayıcı rozeti güvenli diyor ve dahili wiki hâlâ yüklenmiyor. Üçü aynı anda doğru olabilir, çünkü bir çözümleyicinin adresi, onu seçen politikayla ya da sorgunun izlediği yolla aynı şey değildir. İnsanların DNS sızıntısı dediği şey aslında tek bir sorudur: adı hangi çözümleyici aldı ve bu seçim kasıtlı mıydı? Bunu ayırmak üç kontrol gerektirir ve yalnızca sonuncusu bir ayarı değiştirmeyi içerir.
Yanılgı bir: rozet çözümleyicinizin adını verir
Bir sızıntı testi bir sonda adını çözer ve yanıt veren adresi bildirir. O çözümleyiciyi seçen politikayı bildirmez ve sorgu DNS over HTTPS ile sarıldığında yoldaki bir ara kutu adı hiç göremez. Birbirinden çok farklı iki makine aynı güven verici rozeti üretir: VPN'in 10.8.0.1 adresini ittiği ve tarayıcının onu kullandığı biri, tarayıcının sistem listesini görmezden gelip adı tünel içinden kendi şifreli sağlayıcısına gönderdiği diğeri.
Fark, özel bir adın başarısız olduğu anda önem kazanır. İlk kurulumda VPN çözümleyicisi kurumsal bölge için yanıt verir; ikincisinde tarayıcı ona hiç sormadı, bu yüzden kısa ana makine adı çözülmez ve hata bozuk bir VPN gibi görünür. Kontrol başka bir sızıntı testi değil, yalnızca bir çözümleyicinin bildiği bir ada yapılan aramadır.
Yanılgı iki: tarayıcı tünelden çıkar
DNS bir adres seçer, yönlendirme bağlantıyı taşır ve ikisi ayrı katmanlardır. Genel bir DoH sağlayıcısına gönderilen sorgu hâlâ yönlendirilebilir bir adrese TCP port 443'tür. Yönlendirme tablonuz varsayılan rotayı tünele gönderiyorsa o sorgu da tünelden geçer. Çözümleyicinin markası yolu belirlemez.
Tarayıcı DoH'unun değiştirdiği şey adların alıcısıdır. Bu gerçek bir gizlilik kararı ve gerçek bir politika kararıdır, ama yönlendirme atlatması değildir. Gereksiniminiz adların VPN işletmecisinde kalmasıysa, başkasına giden şifreli bir sorgu bu gereksinimi karşılamaz, yine de gerçek bağlantı için tüneli kullanır.
Yanılgı üç: her VPN her tarayıcıyı ezer
Tarayıcıda güvenli DNS'in modları vardır, anahtarı yoktur: kapalı, geri dönüşlü varsayılan sağlayıcı, özel bir şablon ya da işletim sistemi veya kuruluş tarafından uygulanan bir politika. Aralıklı raporlar üreten durum geri dönüş durumudur. Şifreli uç noktaya erişilemediğinde tarayıcı sistem çözümleyicisine geri dönebilir, bu yüzden aynı dizüstü pazartesi özel bir adı doğru çözer, salı günü çözmez.
Aynı zamanda çoğu VPN istemcisi bağlantı kurulduğunda sistem çözümleyicisini ayarlar ve bağlantı düştüğünde öncekini geri yükler. Özel şifreli bir çözümleyici tutan tarayıcı bu geri yüklemeyi hiç görmez. Aynı profilin iki dizüstünde farklı davranmasının ve tarayıcı hâlâ başkasına sorarken resolv.conf dosyasının doğru görünmesinin nedeni budur.
resolvectl status # per-link DNS servers and split-DNS domains
scutil --dns | head -30 # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1 # ask the VPN resolver directlyBağlıyken bunları çalıştırın, her çözümleyicinin talep ettiği alan adlarını not edin ve tarayıcının kendi modu hakkında bildirdikleriyle karşılaştırın. Mozilla'nın DoH belgeleri, bir tarayıcının varsayılan ve geri dönüş davranışının nasıl çalışması gerektiğine dair makul bir açıklamadır.
Kararın üç girdisi var, bir değil
Özel adlar, işletmeciye güven ve erişilebilirlik doğru düzenlemeyi belirler. Yalnızca VPN çözümleyicisinin bildiği adlar bölünmüş DNS'i zorunlu kılar: özel sonek itilen çözümleyiciye gider, geri kalan her şey genel adlar için seçtiğiniz politikayı izler. İşletmeciye güven, genel adların da o çözümleyiciye mi yoksa ayrı bir hizmete mi gitmesi gerektiğine karar verir. Erişilebilirlik, seçtiğiniz şifreli çözümleyicinin bu ağda kullanılabilir olup olmadığına karar verir.
| Condition | What it forces |
|---|---|
| Internal names must resolve | Split DNS: private suffixes to the VPN resolver, the rest to your chosen default |
| Queries must stay with one operator | Pin both the system resolver and the browser mode, and disable fallback |
| Resolver only reachable through the tunnel | Keep the pushed resolver; do not point DoH at an endpoint your routes exclude |
Bu satırların hiçbiri evrensel bir öneri değildir. VPN tarafından işletilen bir çözümleyici gözlemleri o işletmeciye toplar; ayrı bir hizmet sorgulanan adlara bir alıcı daha ekler. Politikanın kendisini okumazsanız hiçbir düzenleme saklama konusunda bir şey kanıtlamaz.
Kararı profil başına yazın, çünkü bu ayarlar kayar. Geçen ay bir çözümleyici iten profil bugün hiçbir şey itmiyor olabilir ve tarayıcı hâlâ yanıt veren eski bir özel uç noktayı memnuniyetle tutar. Notta yer alması gereken şey çözümleyici adresi, sahip olduğu sonekler ve tarayıcı modudur, hizmetin markası değil.
Yapılandırdığınızı düşündüğünüz politikayı test edin
Rozetle değil, adla test edin. Sistem çözümleyicisi üzerinden bir genel bir de özel adı çözün, sonra kullanmayı planladığınız modda tarayıcının kendi güvenli DNS ayarıyla tarayıcı içinde tekrarlayın. Özel ad yalnızca tarayıcıda başarısız oluyorsa, tek bir VPN ayarına dokunmadan alıcı uyuşmazlığını buldunuz.
Sonra yeniden bağlanın ve geri yüklemeyi kontrol edin, çünkü devir hataları orada yaşar: bağlantıyı kesin, önceki çözümleyicinin geri geldiğini doğrulayın, yeniden bağlanın, itilenin geri geldiğini doğrulayın. Son olarak, yönetilen politikası olan bir tarayıcınız varsa onu test edin, çünkü o mod değişikliğinizi tamamen reddedip sessizce önceki çözümleyiciyi tutabilir.
Ad alanı sorusuyla başlayın, bunun çoğundan kaçınırsınız. Makine dahili adlara ulaşmak zorundaysa, tarayıcının şifreli çözümleyicisi yalnızca genel yarıya dair bir karardır ve özel yarı VPN'in ittiği şeyde kalır.