Windows'ta OpenVPN bağlandıktan sonra DNS neden çalışmayı durdurur

53 portu hiçbir yere varmazken çözümleyici hâlâ ping'e yanıt veriyor. block-outside-dns filtreleniyor mu bakın, sonra tünelin ulaşabildiği bir çözümleyici sağlayın.

Ofis çözümleyicisine ping, "OpenVPN" bağlandıktan sonra da yanıt alıyor ve yine de her ad araması başarısız oluyor. Adres erişilebilirken port değil; Windows'un DNS'i bağdaştırıcıya göre filtreleyebildiğini bilince bu birleşim anlam kazanıyor. Profilde block-outside-dns varsa o filtre ilk şüpheli, yönlendirme tablosu ise bakılacak yanlış yer. Aşağıdaki iki test katmanları saniyeler içinde ayırıyor.

Erişilebilir adres, ölü port

Başarılı bir ping ana makinenin çalıştığını ve bir yol bulunduğunu kanıtlar. 53 portuna ulaşma izni konusunda hiçbir şey söylemez, çünkü söz konusu filtre başka bir katmanda çalışır ve bağdaştırıcıya bağlıdır. Bu yüzden aynı makine ICMP'ye yanıt verebilir ve aynı adrese gönderilen her sorguyu reddedebilir. Herhangi bir yapılandırmayı değiştirmeden önce iki testi de aynı oturumda çalıştırın.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Bu çift tanının kendisi. Alt ağa giden olağan trafik sürerken ad çözümlemesi ölüyor ve insanlar sunucunun bozuk olduğu ya da DNS'in hiç gönderilmediği sonucuna varıyor. İki açıklamanın peşinden gitmek pahalı, kanıtlar ise daha dar bir yeri işaret ediyor. Bir ayara dokunmadan önce çifti doğrulayın.

Bu seçenek filtreleme platformunun kuralıdır

OpenVPN başvurusu block-outside-dns'i, uygulamaların tünel dışındaki bağdaştırıcılarda DNS'e ulaşmasını engelleyen bir Windows Filtering Platform kısıtlaması olarak tanımlıyor. TCP ve UDP 53 portunu kapsıyor. Filtre olağan güvenlik duvarı kural listesinde değil WFP içinde yaşadığı için başka bir yere izin kuralı eklemek sonucu mutlaka değiştirmez. Bu yüzden DNS'e izin verme yolundaki yaygın öneri başarısız olmaya devam ediyor.

Ayar içe aktarılan profilden ya da sunucudan gelebilir ve en son düzenlediğiniz dosya "istemcinin ne yüklediğinin kanıtı değildir". Etkin yapılandırmayı ve bağlantı günlüğünü birlikte okuyun. Seçenek aynı zamanda Windows'a özgüdür ve taşınabilir sayılması geçerli olmayan öneriler üretir.

Daha fazla kural eklemek yerine bu kısıtlamayı elinde tutan istemci bileşenini arayın. Sahibi, onu gerçekten kaldırabilen şeydir.

Filtre çözümleyici değildir

Tünel dışındaki trafiği engellemek, içinde çalışan bir çözümleyici kurmaz. Seçenek bir yolu kaldırır ve tünelin DNS yapılandırmasını profili kuran kişiye bırakır. Hiç çözümleyici göndermeyen bir profilde artık hiç yok.

Üç denetimi sırayla yapın. Birincisi, başarısız uygulamanın gerçekte hangi çözümleyiciyi kullandığı. İkincisi, istemcinin VPN DNS ayarlarını uygulayıp uygulamadığı. Üçüncüsü, hangi arabirimin trafiği o çözümleyiciye taşıdığı.

  1. Kullanılan çözümleyici: Resolve-DnsName -Server <resolver-ip> <name> çıktısını ipconfig /all öğesinin listelediği DNS sunucularıyla karşılaştırın.
  2. VPN DNS uygulandı: aynı ipconfig /all çıktısında tünel bağdaştırıcısının DNS girdilerini inceleyin.
  3. Kullanılan arabirim: Find-NetRoute -RemoteIPAddress <resolver-ip> o hedef için giden arabirimi adlandırır.

Bir LAN çözümleyicisi bu ilke altında tasarım gereği erişilemez hâle gelir, başka LAN trafiği çalışırken bile. Bu, seçeneğin işini yapmasıdır. Tasarım VPN üzerinden DNS gerektiriyorsa çözümleyici kaydını ve tünel yolunu düzeltin; yerel istisnalarla bölünmüş DNS gerekiyorsa yapılandırmanın sahibi bu istisnaları desteklenen bir biçimde ifade etmelidir.

Seçeneğin kapsamadığı şeyler

53 portu ad çözümlemesinin tamamı değildir. DNS over HTTPS ve DNS over TLS farklı taşıma kullanır ve bazı uygulamalar sistem ayarlarından bağımsız olarak kendi çözümleyici mantığını çalıştırır. Bu yüzden tarayıcı adları çözebilirken komut satırı çözemeyebilir.

Bu farkı çelişki değil tanı olarak ele alın. Sistem çözümleyicisinin bozuk olduğuna karar vermeden önce ikisini karşılaştırın.

Yazarken sonucu dar tutun. Bu seçenek bir platformda bir taşımayı sınırlar; çözümleme yolunun geri kalanı kendi sahibi olan ayrı bir tasarım sorusudur.

Bağlantı kesilmeden önce ve sonra durumu denetleyin

Aynı aramayı bağlantı sırasında ve sahip istemci bağlantıyı kestikten sonra yeniden çalıştırın. Birincisi tünel ayaktayken dış çözümleyici için başarısız olmalı, ikincisi filtre kaldırılınca başarılı olmalı. Bağlantı kesildikten sonra hâlâ başarısızsa filtre temizlenmemiştir.

ipconfig /displaydns
nslookup <name> <resolver-ip>

İstemci hizmetini veya makineyi yeniden başlatmak genellikle eski bir filtreyi temizler. Bu tanıyı doğrular ama kalıcı bir düzeltmeyi kanıtlamaz. Gördüğünüzü yazın, çünkü bağlantı kesilmesini atlatan bir filtre bunu yeniden yapar ve kayıt, hata bildirimini haklı çıkaran şeydir.

Ancak bu denetimlerden sonra çözümleyiciyi değiştirmek veya güvenlik duvarı ilkesini yeniden kurmak anlamlıdır. İkisi de kanıtların desteklediğinden büyük değişikliklerdir.

İlgili makaleler