VPN DNS'imi değiştirdi mi? Öncesini ve sonrasını karşılaştırın
Bir profil, sorgularınızı bilerek taşıyabilir. VPN bağlanmadan önce ve sonra çözümleyici ilkesini ve gerçek yanıtı karşılaştırın, tek değişkeni sabit tutun.
Tünele bağlanır, özel bir panoyu açarsınız ve ad, hiç görmediğiniz bir adrese çözülür. Ya da tersi olur: tarayıcı çalışmaya devam ederken komut satırı aracı birden hiçbir şeyi çözmez. İki sonuç da aynı değişiklikten gelir ve insanlar bunu genellikle VPN'in "kendi DNS'ini kullandığı" yönünde tek bir cümleyle açıklar; bu, hata ayıklamak ya da doğrulamak için yeterince kesin değildir. O cümlede iki soru gizlidir: bu profil hangi sorguları devralmalı ve makineniz bunları gerçekten kendisine verilen çözümleyiciye gönderdi mi? Bunları ayrı tutmak bütün yöntemdir, çünkü ikisini karıştıran bir test her iki yönde de kendinden emin ve yanlış bir yanıt üretir.
Bir profil neden çözümleyici sağlar
Bir tünelin içinde, uzak ucun arkasındaki adlar genellikle yalnızca o ağda var olan adreslere çözülür. corp.internal gibi özel bir bölgenin genel delegasyonu yoktur, bu yüzden onu sunan çözümleyicinin tünelin içinden erişilebilir olması gerekir. Aynı mekanizma ikinci bir amaca da hizmet eder: sorgular başka türlü sağlayıcınızdan çıkacaksa, uzak taraftaki bir çözümleyici sorguyu şifreli yolun içinde tutar. Bu yüzden DNS sunucusunun adresi, makine için bir kez seçtiğiniz küresel bir ayar olarak değil, bağlantının ilkesinin bir parçası olarak gelir.
Adres tek başına hiçbir şeyi belirlemez. Bir çözümleyici yalnızca ona giden bir yol varsa yanıtlayabilir ve en yaygın arıza, yalnızca tünel ayaktayken erişilebilen bir çözümleyicidir. Tünel düştüğünde ve ilke kaldığında, sorgular yolu olmayan bir adrese gider ve belirti temiz bir hata değil, zaman aşımıdır. Bu fark, sonraki test sonucunu okurken önemlidir, çünkü zaman aşımı insanları hiç ilgisi olmayan taşıma ayarlarına yönlendirir.
Yanıtları karşılaştırmadan önce iki tasarımı karşılaştırın
Tam tünel ve bölünmüş DNS karşıt beklentiler üretir ve hiçbiri arıza değildir. Tam tünel altında her sorgu sağlayıcıya veya kurumsal çözümleyiciye geçebilir, bu yüzden genel adların bağlandıktan sonra farklı yanıt vermesi beklenir. Bölünmüş DNS altında yalnızca listelenen alan adları özel çözümleyiciye gider, geri kalan her şey yerel kalır; Windows'ta alan adı listesi Name Resolution Policy Table içinde, macOS'ta DNS ayarlarının eşleşen alan adlarında, systemd-resolved konağında ise bağlantı başına yönlendirme alan adlarında yaşar.
Önce yapılması gereken karşılaştırma budur, çünkü neyin kusur sayılacağına o karar verir. Bölünmüş DNS ile yeni bir çözümleyiciden yanıt veren genel ad, araştırmaya değer olan şeydir; doğru yanıt veren iç ad ise sistemin işini yapmasıdır. Tam tünel ile anormallik, hâlâ sağlayıcınızın çözümleyicisinden yanıt veren genel addır. Microsoft'un VPN ad çözümlemesi belgeleri, bu kuralların Windows sırasını, eşleşen bir ilke girdisinin bağdaştırıcının kendi sunucularından önce nasıl değerlendirildiği dahil açıklar.
Odada unutulması kolay üçüncü bir çözümleyici daha vardır. Tarayıcının güvenli DNS'i adları kendi başına çözer ve tünel işletim sisteminin ilkesini değiştirdikten sonra da yanıt vermeye devam edebilir, bu yüzden yüklenen bir sayfa tarayıcının çözümleyicisinin çalıştığını kanıtlar, profilin uygulandığını değil. Yalnızca tarayıcının gösterdiklerini karşılaştırırsanız zamanın yarısında yanlış katmanı test edersiniz.
Yalnızca tek değişkenle bir başlangıç çizgisi kaydedin
Tüneli değiştirin. Aynı adımda adı, aracı veya arama sonekini de değiştirmeyin. Sorgulamanıza izin verilen bir ad seçin, hangi uygulamayı kullandığınızı not edin ve ya dönen adresi ya da tam hatayı yazın. Windows'ta Get-DnsClientServerAddress -AddressFamily IPv4 bağdaştırıcı başına sunucuları, Get-DnsClientNrptPolicy ilke girdilerini yazdırır; systemd-resolved kullanan Linux'ta resolvectl status bağlantı başına DNS sunucularını ve yönlendirme alan adlarını gösterir; macOS'ta scutil --dns sistemin gerçekten izleyeceği çözümleyici sırasını yazdırır.
Ardından istemcinin olağan denetimleriyle bağlanın ve tam olarak aynı komutları yineleyin. İlk çıktıyı hatırlamak yerine saklayın, çünkü karşılaştırma bütün meseledir ve önbellek boşaltıldıktan sonra alınan ikinci okuma artık başka bir ölçümdür. Başlangıç çizgisi tarayıcı öndeyken alındıysa ve bağlandıktan sonraki çalıştırma bir terminalde oluyorsa, iki çözümleyiciyi karşılaştırıyorsunuz, bir çözümleyicinin iki durumunu değil.
Açık bir sorgu ile uygulama araması farklı testlerdir
Belirli bir sunucuya nslookup name 10.20.0.1 veya dig @10.20.0.1 name ile sormak tek bir şeyi kanıtlar: adını verdiğiniz sunucu ona ulaşabildiğinizde yanıt verir. Seçim mantığını tamamen atlar, bu yüzden sistemin bu ad için o sunucuyu seçip seçmeyeceğini söyleyemez. Atanan çözümleyicinin erişilebilir olup olmadığını test etmek için kullanın ve ilkeyi test etmek için kullanmayın.
Yerel çözümleyici üzerinden yapılan arama seçimi gerçekten uygular. resolvectl query name aynı yönlendirme alan adı kurallarından geçer ve hangi protokolün yanıt verdiğini bildirir, Windows'ta Resolve-DnsName ilke tablosundan ve istemci önbelleğinden geçer, scutil --dns bir aramanın izleyeceği sırayı gösterir. İki türü de çalıştırın ve notlarınızın ayrı sütunlarında tutun. Başarılı bir açık sorgunun yanında başarısız bir uygulama araması, çözümleyicinin çalışmayı reddetmesi değil, yönlendirme veya seçim sorunudur.
Önbellek sizinle yanıt arasında durur. İşletim sistemi, yerel stub çözümleyici, tarayıcı ve olumsuz önbellek hepsi sonuç tutar, bu yüzden tek bir paket makineden çıkmadan bir arama başarılı olabilir. Herhangi bir şeyi temizlemeden önce sonucu kaydedin: ipconfig /flushdns, resolvectl flush-caches veya macOS'ta sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. Bu aşamada geniş ağ sıfırlamasını atlayın, çünkü hâlâ topladığınız kanıtları yok eder.
Fark ne anlama gelir
Kaydettiğiniz iki satırı karşılaştırın ve tek bir ayara dokunmadan önce değişikliği sınıflandırın.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Bir satır vurguyu hak eder. Çözülen bir ad, çalışan bir hizmet değildir ve DNS başarısı yalnızca bir adresin bulunduğunu söyler. Yönlendirme, güvenlik duvarı kuralları veya hesabınızın hizmeti kullanıp kullanamayacağı hakkında hiçbir şey söylemez, bu yüzden arızanın kendiliğinden çekildiğini varsaymak yerine gerçek uygulamayı test ederek bitirin.
Başlangıç çizgisini geri yükleyin ve doğrulayın
Süreci öldürmek yerine istemcinin kendi denetimleriyle bağlantıyı kesin, ardından aynı üç komutu yeniden okuyun. Bağlantı başına sunucular, ilke girdileri ve test adınızın yanıtı daha önce yazdığınız başlangıç çizgisine dönmelidir. Temiz bir bağlantı kesintisinden sonra kalan bir ilke girdisi, kaydedilmeye değer gerçek bir kusurdur ve üretilen çözümleyici dosyasında elle düzenleme yapmanın kötü bir alışkanlık olmasının nedeni de budur: dosya yeniden yazılır ve düzenleme kaybolur ya da düzenleme kalır ve artık yolu olmayan bir çözümleyiciyi sabitler.
Bu listeyi bir kez, sırayla geçin. Herhangi bir sonucu yargılamadan önce profilin hangi tasarımı uyguladığına karar verin. Adı, aracı ve soneki iki çalıştırmada da sabit tutun. Açık sorguyu uygulama aramasından ayırın. Yalnızca yanıtı değil, geçerli ilkeyi okuyun. Önbellekleri en son, karşılaştırma yazıldıktan sonra temizleyin. Gerçek uygulamayla doğrulayın, ardından bir kez yeniden başlatın ve bağlantı kesik durumun hâlâ temiz olduğunu onaylayın.