Özel DNS adları VPN istemcilerinde neden başarısız olur ve nerede kontrol edilir

Bir otel odasında dizüstü bilgisayarı açarsınız, istemciyi başlatırsınız, dahili dosya sunucusunun adını yazarsınız ve hiçbir şey alamazsınız. Tünel bağlı olduğunu bildirir ve aynı alt ağdaki bir adrese ping hâlâ yanıt verir, yani taşıma katmanı yerindedir. Yalnızca ad başarısız olur ve bu boşluk sorunu iki yere daraltır: istemci hangi çözümleyiciye sordu ve aldığı yanıt tünelden geri dönebiliyor mu. Birini düzeltip diğerini atlarsanız arıza sadece yer değiştirir.

Herhangi bir profili düzenlemeden önce istemcinin adla ne yaptığını doğrulayın. Linux'ta resolvectl query files.corp.example yanıtı hangi bağlantının ve hangi çözümleyicinin ürettiğini gösterir. Windows'ta Resolve-DnsName files.corp.example yanıt veren sunucuyu ve döndürdüğü adresi gösterir.

Bir şeyi değiştirmeden önce yanıtı okuyun

Ad birkaç milisaniye içinde NXDOMAIN olarak dönerse sorgu bölgenize hiç ulaşmamış ve yerine bir genel veya otel çözümleyicisi yanıt vermiştir. Uzun bir duraklamadan sonra dönerse yolda bir şey UDP 53 numaralı bağlantı noktasını düşürüyordur ve istemci sonunda yedek yola geçmiştir. Doğru adresle yanıt veriyor ama bağlantı yine takılıyorsa arama yerindedir ve sorununuz yönlendirmede ya da hizmetin kendisindedir.

Bu üçe bölme bir saatlik tahmini ortadan kaldırır. Ayrıca VPN'e hiç dokunmanız gerekip gerekmediğini söyler: doğru özel adrese çözülen bir ad çözümleyici yolunu zaten kanıtlamıştır, dolayısıyla kalan iş veri yolundadır.

Çözümleyiciyi tünelin içinden dağıtın

İstemciler iki gruba ayrılır. Birine sunucu bağlantı kurulurken çözümleyici atayabilir; diğeri ayarı hiçbir ağ geçidinin uzaktan değiştiremediği yerel bir dosyada tutar.

OpenVPN birinci gruptadır. Sunucuda push "dhcp-option DNS 10.8.0.53" ve push "dhcp-option DOMAIN corp.example" denetim kanalından iner, ancak istemci yapılandırmasında pull hâlâ etkinse. Elle düzenlenmiş ve pull-filter ignore "dhcp-option" taşıyan bir istemci onları asla görmez ve o tek satır «sunucu bunu itiyor ama dizüstüm aynı fikirde değil» türünden şaşırtıcı sayıda durumu açıklar.

WireGuard ikinci gruptadır çünkü protokolde hiç seçenek görüşmesi yoktur. Çözümleyici ve arama alan adı istemcinin kendi [Interface] bloğuna DNS = 10.8.0.53, corp.example olarak girer. wg-quick bunu resolvconf veya systemd-resolved üzerinden uygular ve Windows'ta resmi istemci yalnızca tünel ayaktayken var olan NRPT kurallarını kurar: Get-DnsClientNrptPolicy bunları listeler, bu da istemcinin dosyanızı hiç uygulayıp uygulamadığını görmenin hızlı bir yoludur.

IPsec/IKEv2 ortadadır. strongSwan'ın attr eklentisi havuzdan alınan bir DNS sunucusu döndürebilir ve Windows istemcisi bunu genellikle kabul eder, ama kendi ad sunucusunu sabitleyen bir profil ağ geçidinin sunduğu her şeyi yener. Linux istemcisinde eşdeğer el adımı resolvectl dns wg0 10.8.0.53 ve ardından resolvectl domain wg0 '~corp.example''dir; ikisi de arayüzle birlikte kaybolur, bu da tünele bağlı bir ayar için tam olarak istediğiniz şeydir.

Her sorguyu yutmak yerine soneki kapsamlandırın

İstemcinin bütün çözümleyici listesini dahili sunucunuza yöneltmek kolaydır ve genellikle yanlıştır. O zaman her genel ad veri merkezinizin çıkışından çözülür, CDN'ler uzak adresler döndürür ve çözümleyicideki tek bir kesinti kullanıcının gezinmesini de beraberinde götürür.

İçeriye yalnızca özel soneki gönderin. systemd-resolved'da ~ ile başlayan bir alan adı yalnızca yönlendirme içindir, yani ~corp.example o sonek altındaki sorguların o bağlantının sunucularına gittiğini, geri kalan her şeyin ise fiziksel ağı kullanmaya devam ettiğini gösterir. Windows aynı işi ad alanına kapsamlandırılmış NRPT kurallarıyla, macOS ise /etc/resolver/ altındaki ek bir çözümleyici dosyasıyla yapar.

Çoklu yayın adları kendi yanıtlarını hak eder. .local adları tasarımı gereği link-local'dir (RFC 6762) ve noktadan noktaya bir tun arayüzü o çoklu yayın grubunu taşımaz, bu yüzden genel bir çözümleyici eklemek onları yayımlamaz ve dahili bir tek yayın çözümleyicisine onları sorduğunuzda NXDOMAIN döner. avahi gibi bir yansıtıcı, yansıtıcı kipinde iki kesimi köprüleyebilir, ama bu hiçbir istemcinin isteyemeyeceği sunucu tarafı bir karardır. Bir yazıcı ya da NAS adla erişilebilir olmak zorundaysa, bunun yerine bölgenizde ona bir A kaydı verin.

Yanıtın geri dönebildiğini kanıtlayın

Ulaşılamaz bir adresi işaret eden doğru bir yanıt, rotayı kontrol edene kadar tam olarak bir çözümleyici sorunu gibi görünür. Çekirdeğe yanıtın nereye gideceğini sorun: ip route get 10.20.5.20 arayüzü ve daha kullanışlısı, kullanacağı kaynak adresi adlandırır.

Çözümleyicinin adresini kendisini izleyin. DNS = 10.8.0.53 yanında AllowedIPs = 10.20.0.0/16 bulunan bir istemci sorgularını fiziksel NIC üzerinden dışarı gönderir ve orada sessizce ölürler, çünkü çözümleyici tünelin talep ettiği hiçbir önek içinde değildir. Bu uyumsuzluk bu alandaki en yaygın tek nedenli arızadır ve DNS ayarını izin verilen öneklerle satır satır karşılaştırmadıkça görünmez kalır.

Çakışan aralıklar ters arızaya yol açar. Yanıt doğrudur, rota vardır ve yanlış konağı gösterir, çünkü evdeki 192.168.0.0/24 tünelin aynı aralığa rotasından daha belirgindir. Bir tarafı yeniden numaralandırın ya da daha dar bir rota itin, sonra hizmet konağının güvenlik duvarını ve dönüş yolunu doğrulayın; strongSwan'ın iletme konusundaki notları o yolun sysctl tarafını kapsar.

Sertifikalar, insanların DNS'e yüklediği ayrı bir kimlik denetimidir. Tarayıcı çözümleme hatası yerine ad uyuşmazlığı bildirirse, arama zaten çalışmıştır ve düzeltilmesi gereken sertifikadaki SAN'dır. HTTPS'i adla test edin, asla çıplak IP ile değil.

Ağ geçidinden değil, istemciden yeniden test edin

Kullanıcının şikâyet ettiği uygulamanın içinde test edin, çünkü komut satırındaki bir arama tarayıcının aynı yolu izlediğini kanıtlamaz. Chrome'un güvenli DNS'i ve Firefox'un network.trr.mode ayarı sistem çözümleyicisini tamamen atlayabilir ve bunu yaptıklarında özel bir ad ya başarısız olur ya da genel bir çözümleyiciye sızar. resolvectl query çıktısını elle çalıştırılmış bir dig @10.8.0.53 files.corp.example ile karşılaştırmak ikisinden hangisinin olduğunu söyler.

Sonra düzeldi demeden önce bağlantıyı kesip yeniden bağlanın. Bir arayüze elle uygulanan ayarlar arayüzle birlikte kaybolur ve yalnızca unutulmuş yerel bir değişiklik yüzünden doğru görünen bir profil sonraki açılışta başarısız olur.

Sonraki makine için kısa bir kontrol listesi: ad tünelin çözümleyicisi üzerinden çözülüyor, sonek genel değil kapsamlı, çözümleyici adresi izin verilen öneklerin içinde, yanıttaki konak hizmet bağlantı noktasında yanıt veriyor ve sertifika kullanıcının yazdığı adı kapsıyor.