OpenVPN'in ittiği DNS yok sayılıyor: hangi bileşen uyguluyor

Günlük, sunucunun ittiği seçeneği gösteriyor, tünel açık, ama iç adlar hâlâ çözülemiyor. Çözümleyiciye doğrudan sorgu yanıt veriyor, yani sunucu sağlam, ancak her uygulama yerel yönlendiriciye sormaya devam ediyor. İstemciye ulaşan şey bir teklif, çözümleyicide değişiklik değil, ve ad çözümlemesine sahip bileşen Linux, Windows ve macOS'ta farklı. Seçeneği sahibinden ayırdığınızda dört arıza neredeyse her raporu kapsıyor: kanca yok, iki rakip kanca, tasarlandığı gibi çalışan bölünmüş DNS, ya da sunucu değil sonek gerektiren kısa bir ad.

İtilen seçenek bir tekliftir, kurulum değil

Sunucuda iki yönerge niyeti anlatır, etkiyi değil:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

İstemci yapılandırılmış bir çözümleyici almıyor. Ortam değişkenleri alıyor, foreign_option_1 ve sonrakileri, itilen her satır için bir tane, ve yerel bir şeyin bunları okuyup işletim sisteminin çözümleyici durumunu yeniden yazması gerekiyor. Linux'ta varsayılan olarak hiçbir şey bunu yapmıyor, bu yüzden doğru bir sunucu ve bağlı bir istemci hâlâ LAN üzerinden ad çözebiliyor.

İki uç arasında üç aşama var: itme ulaşmalı, istemci onu açığa çıkarmalı ve bir kanca onu uygulamalı. Orta aşamayı istemci günlüğünde, son aşamayı çözümleyici durumunda okuyun, asla tersini yapmayın, çünkü bir günlük satırı yalnızca ilk ikisini kanıtlar.

İtmenin ulaştığını doğrulayın ve sahibini bulun

Başlatıcıyı adlandırarak başlayın: çıplak bir openvpn komut, bir systemd örneği, NetworkManager ya da satıcı istemcisi. Bu, kancanın nerede yaşayabileceğini belirler. systemd-resolved olan bir ana makinede, resolvectl status her bağlantıyı gerçekten kullandığı DNS sunucuları ve arama alanlarıyla listeler ve tünel bağlantısının adı her zaman tun0 değildir.

İtilen adres günlükte görünüp hiçbir bağlantıda yoksa entegrasyon eksiktir. Bağlantıda görünüp sorgular yine başka yere çıkıyorsa sorun şudur: hangi sorgular o bağlantıyı seçiyor. NetworkManager dns=dnsmasq dosyasında /etc/NetworkManager/NetworkManager.conf bölünmüş DNS'i bilerek uygulayan yerel bir iletici çalıştırır: VPN alanı içindeki adlar VPN çözümleyicisine gider, geri kalan her şey önceki yolunu korur. Tüm trafiğin taşınmasını beklediğinizde bu davranış arıza gibi görünür; bağlantı başına ayarları şununla denetleyin nmcli connection show "My VPN", burada ipv4.dns ve ipv4.dns-search aygıtın bildirdiğinin arkasındaki değerleri tutar, onu bozuk diye adlandırmadan önce. Her sorgu gerçekten VPN çözümleyicisine ulaşmalıysa, dns=dnsmasq öğesini NetworkManager.conf dosyasından kaldırın ve NetworkManager'ı yeniden başlatın; bu, ad çözümlemesini bağlantı ayarlarına geri verir; aksi halde bölünmüş DNS'i koruyun ve itilen alan listesini düzeltin.

Linux: seçenekleri çözümleyiciye verin

Dağıtım paketleri bunun için bir kanca sağlar ve istemcinin onu çalıştırmasına izin verilmelidir. systemd-resolved olmayan bir ana makinede tipik düzen:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

systemd-resolved ile eski resolv.conf betiği önemli bir şeyi değiştirmeyebilir, çünkü stub çözümleyici bağlantı başına durum tutar. update-systemd-resolved yardımcı, şunu kullanan bir kanca biçimi belgeler up-restart ve down-pre, bu bir arayüz tek bir bağlantı denemesinden daha uzun yaşadığında önemlidir. Neyi seçerseniz seçin, durumun sahibi tek bir bileşen olmalıdır. NetworkManager'ın yanına ilgisiz bir kanca eklemek aynı bağlantıya iki yazıcı verir ve sonuç o zaman yapılandırmanıza değil sıralamaya bağlı olur.

NetworkManager'ın itilen seçeneği tamamen yok saydığı bir durum da var: sunucu adresi bağlantının IPv4 ayarlarına girilene kadar böyleydi, sonra çözümleyici durumu kullanımda olduğunu gösterdi. Betikleri yeniden yazmadan önce denemeye değer, çünkü sorunu kabuk kancasından tüneli zaten taşıyan bağlantı profiline taşır.

Windows ve macOS farklı bölümleri uygular

Windows istemcisi VPN bağdaştırıcısının DNS sunucularını gerçekten ayarlar, ama Windows hâlâ ölçüte göre arayüz seçer ve kısa adı genişletmek için hâlâ sonek gerekir. Profili değil bağdaştırıcının durumunu doğrulayın:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

Adres yoksa şununla ayarlayın Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, sonra soneki bağdaştırıcının IPv4 özelliklerine ekleyin, böylece fileserver olur fileserver.corp.example. Makine geneli SearchList değeri Tcpip\Parameters altında aynısını yapar. Uzun adın çözülüp çıplak adın çözülmediği yerde çözümleyici zaten doğrudur ve suç arama listesindedir. Düzeltmeler sırayla: şunu itin DOMAIN istemci soneki öğrensin diye, o soneki bağdaştırıcının veya bağlantının arama listesine ekleyin ve geçici önlem olarak adı şuraya sabitleyin hosts dosyasında, ya da LMHOSTS içinde Windows'ta; NetBIOS taraması yönlendiriciyi aşmaz, bu yüzden ofis LAN'ında kısa bir adı bulan yayın asla bir tünel istemcisine ulaşmaz.

block-outside-dns block-outside-dns bir Windows istemcisi davranışıdır, taşınabilir bir profil satırı değildir ve Linux ya da macOS profiline kopyalamak onu orada yeniden üretmez. Windows'ta genel adlar çalışıp iç adlar başarısız olursa, Gelişmiş ayarlar altındaki bağdaştırıcı sırasını şununla karşılaştırın ipconfig /all. macOS'ta hizmet başına çözümleyici sırası sisteme aittir, bu yüzden scutil --dns kullanarak hangi alan için hangi çözümleyicinin sorulduğunu görün ve bildirilen her tekil profil düzeltmesini genel değil istemciye bağlı sayın.

Aynı dizüstü bilgisayardaki sanal makine bundan hiçbir şey devralmaz. Misafire iç alan için kendi çözümleyici girdisini verin ya da hipervizörün NAT'ının sorgularını ana makine üzerinden iletmesine izin verin; bu yalnızca ana makinenin tüneli açıkken doğrudur.

Geçmiş üçüncü nedendir. Önceki profilden kalan DNS sunucuları veya sonek ayarları yeniden bağlanmaları atlatabilir, bu yüzden bağdaştırıcı doğru görünürken aramalar hâlâ başarısızsa, canlı bağdaştırıcıyı şununla karşılaştırın Get-VpnConnection ve sunucuya dokunmadan önce eski girdiyi silin ya da üzerine yazın.

Sorgunun nereye gittiğini kanıtlayın

Bir arama sırasında alınan kayıt tartışmayı bitirir: tcpdump -ni eth0 port 53 fiziksel arayüzde sorguları gösterir, yani tünelin dışına çıkıyorlar ve çözümleyici hiç değiştirilmedi. dig @10.8.0.1 name.corp.example sonra kalan iki durumu ayırır. Doğrudan sorgu yanıt veriyorsa çözümleyici çalışıyor ve istemci onu kullanmıyor; zaman aşımına uğruyorsa çözümleyiciye tünel üzerinden ulaşılamıyor ve hiçbir yerel değişiklik yardımcı olmaz.

Hâlâ kullanılan çözümleyici sağlayıcının dağıttığı ise tünel trafiği şifreler ama adlar o sağlayıcıya görünür kalır. Bu işlevsellik değil sızıntı sorunudur ve aynı kayıt onu yanıtlar: fiziksel arayüzdeki sorgu tünelin dışındaki birine gidiyor.

Erişilebilirlik, VPN ana makinesindeki güvenlik duvarını da içerir; bu duvar havuzdan UDP ve TCP 53'e izin vermelidir. Kapalı bir bağlantı noktası tam olarak bozuk bir itme gibi görünür ve tünel ağının içinden yanıt veren bir çözümleyici de öyle. Bir kez bağlantıyı kesip yeniden bağlandıktan sonra kaydı yineleyin, çünkü ilk bağlantıda görünüp ikincisinde kaybolan ayarlar kancadaki bir yaşam döngüsü arızasıdır, eksik seçenek değil.

Tek bir sahip tutun ve sırayla doğrulayın

Bağdaştırıcı DNS'ini tahmin edilen tünel durumuna göre yeniden yazan bir betik, profilin zaten taşıdığı yapılandırmayı çoğaltır ve tahmin ilk kez yanlış olduğunda sessizce başarısız olur. Bağlantının kendi DNS ayarlarını ya da belgelenmiş tek bir kancayı yeğleyin ve hangisini seçtiğinizi yazın ki sonraki kişi ikincisini eklemesin.

Döngüyü dört denetimle kapatın: itilen adres tünel bağlantısında, iç ad tam nitelikli ad olarak çözülüyor, aynı ad sonek olmadan çözülüyor ve bir yeniden bağlanmadan sonra ikisi de hâlâ doğru. Bir kayıt dördünden hangisinin başarısız olduğunu söyler. OpenVPN 2.6 kılavuzu şunları listeler dhcp-option ve betik yönergelerini platform notlarıyla birlikte.