Mac'inizin VPN'de kullandığı DNS çözümleyicileri nasıl incelenir

scutil --dns macOS'un gerçekten başvurduğu çözümleyici yapılandırmasını yazdırır, ayarlar paneline yazdığınız tek DNS sunucusunu değil. Çıktı çoğu insanın beklediğinden uzundur, çünkü sistem varsayılan yol, kapsamlı arayüzler ve etki alanına özgü yönlendirme için ayrı çözümleyici blokları tutar. Çıktının en üstündeki blok, sorguyu yanıtlayan blok olmak zorunda değildir. Özel bir ad ofiste çözülüp VPN kalktığı anda başarısız oluyorsa, uyuşmazlık eşleştirme kurallarında ve yollarda, sunucu adresinde değil. Önce sırayı okuyun, sonra yanıtı gerçek bir aramayla kanıtlayın.

Adreslerden önce blok sırasını okuyun

Her giriş resolver #N ile açılır ve nameserver[0], bazen if_index, bir flags satırı, reach ve blok sıradan bir varsayılan değilse bir domain ile search domain listesi gösterir. Etki alanı olmayan 1 numaralı çözümleyici, ortak adları işleyen varsayılandır. Bayraklarında Scoped taşıyan her şey if_index tarafından adlandırılan arayüze bağlıdır ve Supplemental ile işaretlenen her şey yalnızca altında listelenen etki alanları için geçerlidir.

Seçim sonek eşleştirmesidir. intranet.corp.example gibi bir ad için macOS, domain girdisi en uzun eşleşen sonek olan çözümleyiciyi tercih eder, bu yüzden domain : corp.example içeren blok çıktının çok altında dursa bile varsayılanı yener. Aynı uzunluktaki etki alanları arasındaki eşitliği order belirler. İlk bakış nadiren daha fazlasını ister: bir bloğu baştan sona okumak istediğinizde tüm çıktı, blok sırasını öğrenmek için ilk satırlar ve blok başlıklarını alan satırlarının yanına yazdıran süzülmüş bir tur. Kapsamlı bloklar kendi başlıklarının altında görünür ve üstlerindeki listenin devamı gibi okunur, bu yüzden çıktıdan alıntı yaptığınızda başlığı gözden uzak tutmayın.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

if_index'i tünel arayüzüyle eşleştirin

Dizin ancak arkasındaki arayüzü adlandırabiliyorsanız işe yarar. scutil --nwi sistemin tuttuğu ağ bilgilerini listeler, birincil arayüz ve erişilebilirlik dahil, ifconfig -l ise adları verir; burada utun0 ile utun9 arası bir istemcinin genellikle oluşturduğu tünel adaylarıdır. Apple kendi inceleme örneği olarak scutil --dns aracını dağıtım kılavuzunda kullanır ve Network Extension'ın seçilen etki alanlarını seçilen çözümleyicilere nasıl yönlendirebildiğini belgeler; kapsamlı blokların açığa çıkardığı mekanizma tam olarak budur.

Soruyu çözen kontrol, çözümleyicinin tünelin kurduğu yolda olup olmadığıdır:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

route -n get çözümleyici girdisiyle eşleşmeyen bir ağ geçidi ve arayüz döndürürse, adres tamamen doğru olabilir ve yine de erişilemez olabilir. Yalnızca kurumsal alt ağları taşıyan bölünmüş bir tünel, bunların dışındaki bir DNS sunucusuna yönelen sorguları düşürür ve hata zaman aşımı olarak görünür, bu yüzden yapılandırma çıktısı temiz görünmeye devam eder.

Önce sistem çözümleyicisine, sonra sunucuya sorun

Üç araç üç farklı soruya yanıt verir ve bunları karıştırmak bu alandaki yanlış sonuçların çoğunu üretir. dscacheutil -q host -a name sıradan uygulamaların kullandığı aynı sistem çözümleyicisinden geçer, bu yüzden kapsamlı ve ek bloklar geçerlidir. Sunucu argümanı olmadan dig /etc/resolv.conf dosyasını okur, bu macOS'ta kapsamlı çözümleme için gerçeğin kaynağı değildir ve etki alanı başına kuralları tamamen atlar. dig @address tam olarak bir sunucuya ulaşır ve seçim hakkında hiçbir şey söylemez.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

İlk komut yanıt verip ikincisi NXDOMAIN döndürdüğünde, aradığınız ayrımı buldunuz ve hiçbir şey bozuk değil. İlki zaman aşımına uğrarken dig @10.20.0.53 yanıt veriyorsa, çözümleyici çalışıyor ama tünelin seçtiği yolda erişilemez, bu yüzden sonraki adım DNS ayarlarını değiştirmek değil route -n get. Özel adları bir bilete veya paylaşılan notaya yapıştırdığınız her şeyin dışında tutun.

Çıktının size gösteremeyeceği şeyler

Çözümleyici listesinin üstünde veya yanında birkaç katman oturur ve her biri bir sorguyu çıktının hiç söz etmediği bir yere gönderebilir. Güvenli DNS'i açık bir tarayıcı kendi şifreli kanalı üzerinden çözebilir, bu yüzden dscacheutil zaman aşımına uğrarken bir sayfanın yüklenmesi çelişki değildir. Güvenlik yazılımının kurduğu bir DNS vekil sunucusu Network Extension sağlayıcısı olarak çalışır ve sorguları kendisi iletir, scutil --dns ise neyin yapılandırıldığını gösterir, vekilin sonunda kullandığı üst kaynak adresini değil. Arama etki alanları üçüncü kıvrımı ekler: niteliksiz bir ada listedeki her sonek sırayla eklenir, bu yüzden yanıtlayan blok hiç kuşkulanmadığınız bir blok olabilir.

Eski yanıtlar dışlaması en ucuz ve en sık atlanan şeydir:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

Temizlemeden sonra çıktı değişirse durum önbellekteydi ve önceki çıktı artık var olmayan bir tüneli anlatıyordu. Değişmezse yapılandırma olduğu gibidir ve soru rotalara ve uygulama politikasına kayar.

Öncesi ve sonrası için kısa bir el kitabı

Temel çizgiyi yalnızca politikanın izin verdiği yerde alın ve dosyaları eşitlenen herhangi bir klasörün dışında tutun. Aşağıdaki sıra istemci makinelerinde çalıştırdığımdır: temel çizgiyi al, bağlan, yeniden al, sonra karşılaştır ve ara.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

Farkı satır satır değil blok blok okuyun. Tünel arayüz dizinini ve özel sonek için domain girdisini taşıyan yeni kapsamlı çözümleyici beklenen biçimdir. Ortak bir adrese işaret eden yeni varsayılan çözümleyici, istemci profilinin sahibine taşınmaya değer bir bulgudur. Sonra aramayı yalnızca kabukta değil, gerçekten başarısız olan uygulamanın içinde yineleyin ve sonucun yanına route -n get arayüzünü not edin.

Bir değişikliği geri almak için bağlantıyı kesin ve temel çizgi alımını yineleyin. Kapsamlı blok gittiyse istemci arkasını temizlemiştir. Blok artık var olmayan bir arayüze karşı listeleniyorsa, durum eski, ve kimse profile dokunmadan önce temizleme artı yeniden bağlanma en yumuşak düzeltmedir.

Bu sırayla dört kontrol: bir çözümleyici bloğu adın en uzun sonekiyle eşleşiyor mu; o blok tünelin kurduğu arayüze bağlı mı; ad sunucusuna giden rota tüneli kullanıyor mu; ve yanıtı dig değil sistem çözümleyicisi mi döndürüyor. Başarısız olan ilk kontrol, DNS politikasını, tünel rotalarını yoksa uygulamayı mı değiştirmeniz gerektiğini söyler. Dördü de geçer ve ad hâlâ başarısız olursa sorun DNS'in üstündedir ve sırada incelenecek şey önünde 53 numaralı porta yanıt veren her şeydir.