VPN Açıkken DNS Sorguları Neden Yanıt Vermez?
Trafiği şifreli bir tünelden taşıyan VPN uygulaması bağlantının kurulduğunu gösterse de web siteleri alan adlarıyla açılmıyor, uygulamalar sunucu adlarını çözemiyor veya DNS sorguları zaman aşımına uğruyorsa sorun tünelin tamamını etkilemeyebilir. Cihaz, alan adının IP adresini yerel kayıtlardan veya önbellekten bulamıyorsa adlarla adresleri eşleştiren DNS hizmetine başvurur. VPN açıldığında kullanılan DNS sunucusu ve ona giden ağ yolu değişebilir.
VPN'in atadığı DNS sunucusu, yönlendirme kuralları, güvenlik duvarı ve tarayıcının güvenli DNS ayarı bu soruna yol açabilir. VPN dışına trafik çıkmasını engelleyen kill switch ile ağ arabiriminin taşıyabileceği en büyük IP paketi boyutunu belirleyen MTU ayarı da sonucu etkileyebilir. Aynı sorgunun farklı koşullardaki sonuçlarını karşılaştırmak, sorunun kaynağını daraltmaya yardımcı olur.
Zaman aşımı, süresi içinde geçerli yanıt alınamamasıdır. SERVFAIL, REFUSED veya NXDOMAIN gibi bir DNS yanıtı alınması farklıdır: Bunlar sırasıyla sorgunun işlenemediğini, reddedildiğini veya sorgulanan adın ya da takip edilen takma adın hedefinin bulunmadığını bildirebilir. Bu durumlarda DNS sunucusuyla iletişim kurulmuştur; yalnız ağ erişimini değil, yanıtın nedenini de araştırmak gerekir.
VPN Açılınca DNS Yolu Nasıl Değişir?
Ad yerel kaynaklardan çözülemediğinde cihaz, yapılandırmasının seçtiği DNS sunucusuna sorgu gönderir. VPN devreye girdiğinde cihaz farklı bir DNS sunucusu kullanabilir. VPN uygulaması, belirli DNS trafiğini tünelden geçirmek için ek yönlendirme veya güvenlik kuralları da uygulayabilir. Bu nedenle VPN bağlantısının çalışması, DNS sunucusuna giden yolun da doğru olduğu anlamına gelmez.
VPN'in Atadığı DNS Sunucusu ve Tünel Yolu
IPsec, IP paketlerini koruyan bir protokol ailesidir; IKEv2 ise bu koruma için gerekli anahtarları ve bağlantı ayarlarını karşılıklı belirler. IKEv2 ile kurulan VPN bağlantıları, desteklenen yapılandırma seçenekleriyle cihaza IPv4 veya IPv6 DNS sunucularını bildirebilir; yalnız seçili hedeflerin trafiğini tünele alan split tunneling bağlantılarında hangi alan adlarının bu sunucularla çözüleceği de iletilebilir. Atanan DNS sunucusu özel bir IP adresindeyse fiziksel internet bağlantısından erişilemeyebilir. Cihazın sorguyu tünel içindeki doğru ağa göndermesi gerekir.
VPN doğru DNS sunucusu adresini verse bile uygulama bu adrese yönelik trafiği tünel kapsamına almazsa sorgu yanlış arabirime gidebilir. Güvenlik politikası da yanlış yola çıkan sorguyu engelleyebilir. Diğer VPN trafiği farklı hedeflere ulaştığı için kullanıcı sorunun yalnız ad çözümlemeyi etkilediğini görebilir.
Tam Tünel, Split Tunneling ve DNS Yönlendirmesi
Tam tünel yapılandırması genel trafiği VPN'e yönlendirir; split tunneling ise seçilen uygulama veya hedeflerin trafiğini tünele alıp diğer bağlantıları dışarıda bırakır. DNS sunucusunun seçimi ayrı bir karardır: Sistem, belirli alan adlarını VPN'in DNS sunucusuyla çözmek için özel bir kural kullanabilir. Bölünmüş DNS yapılandırmasında kurumsal veya özel adlar VPN'in DNS sunucusuna, diğer adlar ise başka bir DNS sunucusuna gidebilir. Alan adı ile DNS sunucusu eşlemesi yanlışsa yalnız belirli ad grupları zaman aşımına uğrayabilir.
DNS sorgusuna yanıt alınamaması ile sorgunun istenmeyen başka bir DNS sunucusuna başarıyla gitmesi aynı sorun değildir. İkinci durum DNS sızıntısıyla ilgilidir. Buradaki amaç, yanıt alamayan sorgunun hangi noktada kesildiğini bulmaktır.
DNS Zaman Aşımının Altı Olası Kaynağı
Aynı DNS zaman aşımı farklı nedenlerle ortaya çıkabilir. Tek bir belirti kesin teşhis sağlamaz. Aşağıdaki tablo, sonraki kontrolü hangi bileşende yapmanız gerektiğini belirlemenize yardımcı olur.
| Kontrol edilen kaynak | Ayırt edici belirti | İlk kontrol |
|---|---|---|
| VPN'in atadığı DNS sunucusu | VPN açılınca DNS sunucusu değişiyor ve bu adrese doğrudan gönderilen DNS sorgusuna yanıt gelmiyor. | DNS sunucusunun adresini, erişilebilirliğini ve hizmet durumunu kontrol edin. |
| Tünel yolu ve yönlendirme | VPN bağlı ve diğer tünel trafiği çalışıyor ancak DNS sunucusuna giden trafik doğru tünel yoluna girmiyor. | VPN yapılandırmasının DNS trafiğini tünel kapsamına alıp doğru arabirime yönlendirdiğini doğrulayın. |
| Kill switch | Cihaz VPN'in DNS sunucusuna ulaşamadığında kill switch yerel DNS sunucusuna geçişi de engelliyor; sorgu zaman aşımında kalıyor. | Kill switch arızalı olmak zorunda değildir; asıl sorun VPN'in DNS yolunda olabilir. |
| Güvenlik duvarı | Güvenlik duvarı belirli bir DNS hedefini, arabirimdeki trafiği veya kullanılan taşıma protokolünü engellerken diğer ağ trafiği devam ediyor. | Güvenlik duvarı kuralının yalnız doğru DNS hedefi ve ağ arabirimi için izin verdiğini doğrulayın. |
| Tarayıcı güvenli DNS ayarı | Tarayıcıda ad çözümleme başarısızken işletim sistemi düzeyindeki sorgu çalışıyor veya yalnız işletim sistemi sorgusu başarısız oluyor. | Tarayıcının HTTPS, yani şifreli web bağlantısı üzerinden farklı bir DNS sunucusuna sorgu gönderip göndermediğini kontrol edin. |
| MTU ve parçalanma | Küçük veya basit yanıtlar geliyor ancak bazı DNS yanıtları tünelde zaman aşımına uğruyor. | Tünelin paketlere eklediği yükü, yol MTU'sunu ve ara cihazların parçalanmış paketleri düşürüp düşürmediğini araştırın. |
VPN Açıkken DNS Zaman Aşımını Tanılama
Önce sorunun gerçekten VPN'e bağlı olduğunu doğrulayın, ardından DNS sunucusunu ve tünel yolunu kontrol edin. Temel ağ yolunu doğrulamadan güvenlik ayarlarını veya MTU'yu değiştirmek, geçici bir düzelmeyle asıl nedeni gizleyebilir.
1. VPN Kapalı ve Açık Durumlarını Karşılaştırma
Kişisel cihazınızda VPN olmadan bağlantı kurmanız güvenlik ve gizlilik açısından uygunsa, aynı ağdaki VPN öncesi ve sonrası DNS sonuçlarını karşılaştırın. VPN kapalıyken de aynı hata varsa sorun yalnız tünele özgü olmayabilir. Kurumun yönettiği cihazda zorunlu VPN'i kesmeyin veya DNS politikasını değiştirmeyin; karşılaştırmayı ağ yöneticisiyle yürütün.
VPN bağlıyken aynı tünelden erişilmesi beklenen, hizmet verdiğini bildiğiniz bir hedefi IP adresiyle test edin. Bu erişim çalışırken ad çözümleme başarısızsa DNS yolunu inceleyin. Tek bir başarısız ping testi genel bağlantının koptuğunu kanıtlamaz. Web sitesini doğrudan IP adresiyle açarken çıkan sertifika uyarısını da DNS arızası saymayın ve uyarıyı atlamayın; site alan adıyla erişim gerektirebilir.
VPN açıkken hiçbir hedefe trafik ulaşmıyorsa DNS ayarını değiştirmek doğru başlangıç değildir. Bu durumda sorun tünelin kurulması, bağlantının sürmesi veya genel yönlendirme katmanında olabilir.
2. VPN'in Atadığı DNS Sunucusunu Kontrol Etme
VPN bağlandıktan sonra işletim sisteminin etkin DNS yapılandırmasına bakın ve varsa VPN öncesindeki değerle karşılaştırın. Yalnız VPN uygulamasında yazan adresi değil, her ağ arabiriminin DNS sunucularını ve alan adına göre sunucu seçen kuralları inceleyin. Windows PowerShell içinde Get-DnsClientServerAddress arabirimlerin DNS adreslerini, Get-DnsClientNrptPolicy -Effective ise geçerli ad çözümleme politikalarını gösterir; bu komutlar ayar değiştirmez.
Atanan DNS sunucusu özel bir IP adresindeyse bu tek başına hata değildir. Ancak o adrese yönelik DNS sorgusuna yanıt gelmiyorsa sunucunun tünel içinden erişilebilirliğini ve bu hedef için gerekli yönlendirmeyi birlikte inceleyin. Tanılama sırasında hemen genel bir DNS sunucusuna geçmek, özel alan adlarını bozabilir veya asıl VPN yapılandırma sorununu gizleyebilir.
3. DNS Sunucusuna Giden Ağ Yolunu İnceleme
DNS sunucusunun adresi doğru olsa bile sorgunun hangi arabirimden çıktığı önemlidir. VPN politikası bu hedefi tünele dahil etmiyorsa trafik fiziksel ağ arabirimine yönlenebilir; kill switch veya IPsec güvenlik politikası da böyle bir paketi engelleyebilir.
Belirli DNS sunucusuna doğrudan sorgu gönderirken hedef adresi, kaynak adresi, kullanılan arabirimi ve izin veriliyorsa paket kayıtlarını karşılaştırın. Yönlendirme tablosu tek başına uygulamaya özel VPN kurallarını göstermeyebilir. Diğer tünel hedeflerine erişilmesi, DNS sunucusuna giden rotanın, güvenlik duvarı izninin veya DNS hizmetinin çalıştığını kanıtlamaz.
IPv4 ve IPv6 hedeflerini ayrı kontrol edin. IPv4 üzerinden gönderilen bir DNS sorgusu IPv6 adresi kaydı isteyebilir; istenen kayıt türüyle DNS sunucusuna ulaşmak için kullanılan IP sürümü aynı şey değildir. Yerel ağ ile VPN içindeki ağ aynı özel adres aralığını kullanıyorsa, çakışan rotalar sorguyu yanlış ağa da gönderebilir.
4. Tarayıcı ve İşletim Sistemi DNS Yollarını Karşılaştırma
DoH (DNS over HTTPS), DNS sorgularını HTTPS trafiği içinde taşır. Tarayıcı güvenli DNS için ayrı bir DNS sunucusu kullanıyorsa tarayıcıdaki ad çözümleme yolu, işletim sisteminin VPN üzerinden kullandığı DNS sunucusundan farklı olabilir.
Tarayıcının DoH kullanması, sorgunun mutlaka VPN tüneli dışına çıktığı anlamına gelmez; bu bağlantının izlediği ağ yolunu ayrıca kontrol edin. Koruma moduna göre DoH başarısız olduğunda sistem DNS hizmetine dönüş yapılabilir veya çözümleme durabilir. Tarayıcıdaki güncel ayarı ve varsa kurum politikasını birlikte değerlendirin.
Aynı tam alan adı ve kayıt türünü tarayıcı dışında da karşılaştırın. Windows'ta nslookup ad çözümleme politikası tablosunu uygulamaz; bu nedenle sonucu bütün uygulamaların DNS davranışıyla bir tutmayın. Ayrıca önbellekteki kayıt veya açık bir bağlantı sayesinde yüklenen sayfa, o anda yeni bir DNS sorgusunun başarılı olduğunu kanıtlamaz.
5. Kill Switch ve Güvenlik Duvarı Kurallarını İnceleme
Kill switch, yapılandırmaya bağlı olarak VPN dışına çıkacak trafiği yerel güvenlik duvarı veya yönlendirme kurallarıyla engelleyebilir. Cihaz VPN'in DNS sunucusuna ulaşamadığında bu koruma, işletim sisteminin başka bir DNS yoluna geçmesini de durdurabilir. Böylece DNS sızıntısı yerine zaman aşımı oluşur.
Kill switch'i veya güvenlik duvarını kapatmak yerine engellenen bağlantı kayıtlarını ve uygulanan kuralları inceleyin. DNS sorgusunun hangi hedef ve arabirimde engellendiğini belirleyin. Yetkili olduğunuz yapılandırmada yalnız gerekli DNS hedefine, ilgili arabirim ve taşıma yöntemi için izin verin. Yönetilen cihazda değişikliği ağ yöneticisinden isteyin; VPN sağlayıcısının uygulaması kuralları yönetiyorsa destek ekibine tanılama bilgilerini iletin.
Klasik DNS, bağımsız mesajlar taşıyan UDP veya sıralı ve güvenilir veri iletimi sunan TCP üzerinden 53 numaralı portu kullanır. UDP yanıtı boyut nedeniyle kısaltıldığında istemci TCP ile yeniden sorgulayabilir; yalnız UDP izni varsa küçük yanıtlar çalışırken bu sorgular başarısız olabilir. DoH ise HTTPS kullanır. DNS mesajının tünel içindeki taşıma yöntemiyle VPN tünelinin dış bağlantısını karıştırmayın; izin gereken noktada gerçek hedef ve protokolü esas alın.
6. MTU ve Parçalanma Belirtilerini İnceleme
VPN tünelinin eklediği protokol başlıkları, bir pakette veri için kalan alanı azaltabilir. Ağ, yol MTU'sunu doğru belirleyemiyor veya ara cihazlar parçalanmış paketleri düşürüyorsa bazı uygulamalar çalışırken daha büyük paketler takılabilir. Bu sorun, DNS sorgularının tamamını kesmek yerine yalnız bazı yanıtları zaman aşımına uğratabilir.
Büyük yanıtların kaybolması tek başına MTU kanıtı değildir; UDP ile TCP erişimini ve paket kayıtlarını birlikte değerlendirin. Yol üzerindeki cihazların paket boyutu sorununu bildiren ağ kontrol mesajlarını engellemesi de bu duruma yol açabilir. Yetkili olduğunuz cihazda, VPN yazılımının desteklediği aralıkta bir MTU karşılaştırması yapacaksanız önce mevcut değeri kaydedin. Sonuç düzelmiyorsa geri dönün; rastgele bir değeri kalıcılaştırmayın. Kalıcı ayarı kullanılan VPN yapısına ve doğrulanan ağ yoluna göre belirleyin.
Düzeltmenin VPN Yeniden Bağlandığında da Geçerli Kalması
Değişiklikten sonra VPN bağlantısını yeniden kurup etkin DNS sunucusunu, doğrudan sorguyu ve sorunu yaşayan uygulamayı tekrar test edin. Elle eklenmiş rota veya DNS ayarı yeniden bağlantıda kayboluyorsa, gerekli düzeltmeyi yetkiniz dahilinde kalıcı VPN profiline kaydedin; kurum politikasını ise ağ yöneticisinin güncellemesi gerekir. Kill switch ve güvenlik duvarı açıkken sorunlu alan adlarının çalıştığını, özel adların da yalnız izin verilen DNS hizmetine gittiğini doğrulayın.
