VPN kill switch'i 53 numaralı bağlantı noktasını engellediğinde DNS çözülmüyor
Kill switch, DNS'i bilerek engelleyebilir. Yalnızca tünel içindeki çözümlemeyi yerel bir çözümleyici istisnasıyla karşılaştırın, sonra hangi katmanın gerçekten başarısız olduğunu belirleyin.
Kill switch tüneli düşürdüğünde DNS yolunu da beraberinde götürür ve geriye kalan çözümleyici nadiren beklediğiniz olandır. İki tasarım o ana çok farklı yaklaşır: tünelin içinde olmayan her DNS paketini engellemek ya da bir çözümleyiciyi istisna olarak ayakta bırakmak. İkisi de savunulabilir. Tarayıcı sekmesinden belirtiler neredeyse aynı görünür, bu yüzden ilk iş gerçekte hangi tasarımı devreye aldığınızı bulmaktır.
Bu ayrımı gözümün önünde tutuyorum çünkü düzeltme her durumda ters yönde. Bir tasarım daha geniş bir istisna ister, diğeri daha dar bir istisna. Tahmin etmek size ya gizliliğe ya da yarım güne mal olur.
Aynı kesinti için iki DNS tasarımı
Tasarım A, çözümleyiciyi tünelin arkasındaki sıradan bir hizmet olarak görür. Güvenlik duvarı kuralları UDP ve TCP 53'e yalnızca tünel arayüzünde izin verir ve istemciye verilen adres tünelin içindeki bir çözümleyicidir. Tünel düştüğünde aramalar durur ve bu bir arıza değil, amaçlanan sonuçtur.
Tasarım B yerel ağda bir çözümleyiciyi erişilebilir tutar; genellikle 192.168.1.1 adresindeki yönlendirici ya da 127.0.0.53 adresindeki işletim sistemi stub'ı; ad çözümlemesinin tünelle birlikte ölmemesi gerektiği gerekçesiyle. Ev LAN'ında yönlendirici bütün ev için çözümlediğinde bu kullanışlıdır. Otel veya havalimanı Wi-Fi'sinde aynı istisna başkasının sunucusunu gösterir ve yazdığınız her ad, web trafiğiniz engellenmiş kalsa bile açığa çıkar.
Sınır, çözümleyicinin kime ait olduğudur. Yerel olana güveniyorsanız istisna küçük ve dürüst bir deliktir. Güvenmiyorsanız yalnızca tünel tasarımı ayakta kalan tek seçenektir ve bedeli, düşen bir tünelin bütün adları beraberinde götürmesidir.
VPN istemcisinin kendi araması neden hâlâ çalışıyor
İstemci, tünel var olmadan önce ağ geçidinin ana makine adını çözümlemek zorundadır, bu yüzden katı bir engel istemcinin önyükleme yolunu kapsamamalıdır. Çoğu istemci ya uç nokta adresini önbelleğe alır ya da yalnızca o tek ana makine için belgelenmiş bir önyükleme istisnası sunar. Kural kümeniz bu aramayı engelliyorsa tünel asla geri gelmez ve günlükler kendi sunucusuna ulaşamayan bir istemci gösterir; bu DNS değil, ilke kusurudur.
Bölünmüş DNS bunun ortaya çıktığı ikinci yerdir. İstemci bir iç bölgeyi özel bir çözümleyiciye iter ve geri kalan her şeyi sistem çözümleyicisine bırakır. Düşüşten sonra genel adlar hâlâ çözülebilirken iç adlar zaman aşımına uğrar, çünkü özel bölgenin artık bir yolu yoktur. Kullanıcı için bu "VPN interneti bozdu"; çözümleyici günlüğü için hiç ulaşmayan bir sorgudur.
systemd-resolved altında bölünmeyi doğrudan görürsünüz. resolvectl status bağlantı başına DNS sunucularını ve yönlendirme alan adlarını listeler ve tünel düştükten sonra iç alan adı artık var olmayan bir bağlantıdaki sunucuyu göstermeye devam eder. 127.0.0.53 adresindeki stub sorguyu hâlâ kabul eder, sonra yanıt vermeyecek bir üst akışı bekler ve bu yüzden arıza hemen dönmek yerine saniyeler sürer.
Şifreli DNS bir paket filtresini atlatmaz
DNS over HTTPS ve DNS over TLS 443 ve 853 üzerinden gider, yani 53 numaralı bağlantı noktasını engelleyen bir kural onlar hakkında hiçbir şey söylememiştir. "DNS"i bağlantı noktasına göre engellemek bir bağlantı noktası ilkesidir, ad çözümlemesi ilkesi değil. Kill switch'iniz tünelin dışındaki tüm trafiği engelliyorsa DoH kazara kapsanır. Bir captive portal veya genel çözümleyici için istisna açtıysanız kapsanmaz.
İstemci tarafındaki denetimler daha ucuz kaldıraçtır. Firefox kanarya adı use-application-dns.net çözülemediğinde kendi DoH çözümleyicisini bırakır ve yönetilen ağların o alan adını NXDOMAIN olarak yayımlamasının nedeni budur; kurumsal ilke onu kapalı olarak sabitleyebilir de. Android Private DNS ve Chrome'un güvenli DNS'i kendi anahtarlarına ve kendi varsayılanlarına sahiptir. Onları kapatmak çözümleyici adreslerinin peşinden koşmaktan daha güvenilirdir, çünkü adres listesi değişir ve kural kümeniz değişmez.
Bunun sızıntıyla hiç ilgisi olmayan bir sürümü de var. Sabitlenmiş bir çözümleyiciye sahip bir uygulama ona ulaşmak için yine de bir ağ yolu ister. Şifreleme, sorguyu kimin okuyabileceğini değiştirir, paketin makineden çıkıp çıkamayacağını değil, bu yüzden tüm cihaz için bir engel ayarı ona dokunmadan alt eder.
Belirtiyi katmanla eşleştirin
Raporların çoğu tek bir cümle olarak gelir ve o cümle genellikle katmanı zaten adlandırır. Aşağıdaki tablo bir kurala dokunmadan önce gözden geçirdiğim şeydir; amaç sorgunun engellendiğine, yanlış yönlendirildiğine ya da hiç gönderilmediğine karar vermektir.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
İlk iki satır, insanların yanlış teşhis ettiği satırlardır. Sessiz bir düşüş ve bir ret, tarayıcıda aynı şekilde "DNS bozuldu" gibi görünür, ama yalnızca biri kill switch'inizin işini yaptığı anlamına gelir. Ret, bir şeyin yanıt verdiği anlamına gelir, yani engel düşündüğünüz yerde değildir.
Çözümleyici ilkesini geri yükleyin, sonra kanıtlayın
Tasarımı düzeltin, belirtiyi değil. Yalnızca tünel içi çözümleme için tünel arayüzünde 53'e izin verin, iç çözümleyiciyi tünel yapılandırmasıyla birlikte itin ve fiziksel bağlantıyı hiçbir DNS izni olmadan bırakın. wg-quick'te çözümleyiciyi arayüz yapılandırmasına yazan satır DNS = satırıdır, bu yüzden onu atlayan bir tünel eski çözümleyiciyi yerinde bırakır ve her sorgu yanlış yola gider. wg-quick kılavuzu bu davranışı platform başına belgeler.
Sonra bu sırayla doğrulayın. Linux'ta resolvectl status etkin bağlantıyı gösterir, dig +short example.com genel bir adı sınar, dig @10.8.0.1 internal.example.com özel olanı sınar ve sudo tcpdump -ni any port 53 ikisini çalıştırırken paketlerin hangi arayüzü kullandığını gösterir. Windows'ta Get-DnsClientServerAddress -AddressFamily IPv4 ve Resolve-DnsName example.com aynı iki olguyu verir: kimin yapılandırıldığı ve kimin yanıt verdiği.
Olumsuz testle bitirin. Tüneli kesin, yeni bir genel adın başarısız olduğunu doğrulayın, özel adın başarısız olduğunu doğrulayın ve 53 numaralı bağlantı noktasından hiçbir paketin fiziksel bağdaştırıcıdan çıkmadığını doğrulayın. Yalnızca önbelleğe alınmış yanıtlar için ayakta kalan bir engel hiç ayakta kalmaz.
Kaydı kapatmadan önce denetim listesi:
- Kesinti sırasında kullanılan çözümleyici, ilkenin amaçladığı olandır.
- İstemcinin kendi uç nokta araması önbellek ya da istisna yoluyla hâlâ izinlidir.
- DoH ve DoT ya engel tarafından kapsanır ya da ilkeyle devre dışı bırakılır.
- Özel bölgeler, tünel gittikten sonra açık değil kapalı olarak başarısız olur.