VPN DNS'i her sorguyu alıyor: NetworkManager'da dns-priority'yi düzeltin

Ofis VPN'ine bağlanın ve aniden her ad sorgusu kurumsal çözümleyiciye gider. Genel adlar hâlâ çözümlenir, bu yüzden yerel bir yazıcı adı başarısız olana veya bir split-horizon kaydı ofis adresini döndürene kadar hiçbir şey bozuk görünmez. Bazı Fedora kurulumlarında tersi olur: sağlayıcının çözümleyicisi tünel kalktıktan sonra da yanıt vermeye devam eder. İkisi de tek bir sorudur — bu sorgunun sahibi hangi çözümleyici — ve NetworkManager sistemlerinde yanıt her bağlantının DNS özelliklerinde yaşar.

İki bağlantı, tek kazanan çözümleyici

Her bağlantı bir DNS önceliği bildirir. Sıradan bağlantılar varsayılan olarak 50, VPN bağlantıları 0'dır ve düşük değer kazanır. Tam da bu varsayılan, bir VPN bağlantısının talep ettiği her alan adı için kablolu bağlantıyı sessizce geçmesinin nedenidir: sıfır, kimse seçmeden elli'yi yener.

Öncelik adayları sıralar. Kazanana ne sorulacağını sınırlamaz. Arama alan adı olmayan bir VPN bağlantısı her şeyi talep eder, bu yüzden onu tercih etmek genel sorguları da tünele ve bölünmüş tünel tasarımında kurumsal çözümleyicinin ilettiği yere gönderir.

Öncelik sırayı, arama listesi sahipliği belirler

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Arama listesi sahiplik beyanıdır. corp.example gibi çıplak bir alan adı arama son eki ve yönlendirme alan adı olur. Yalnızca yönlendirme biçimi ~corp.example, o son ekin altındaki sorguları alan adını kısa adlara eklemeden bu bağlantıya gönderir. O tilde, «bu sunucuya sor» ile «bu sunucuya sor ve yazımı bitir» arasındaki farktır.

Kullanıcılar kısa ana bilgisayar adları yazdığında ve kayıtlar tam nitelikli adlarla da adreslendiğinde iki biçimi de kullanın. Bölünmeyi, çözümleyicinin çıplak adı nasıl tamamladığını değiştirmeden istediğinizde yalnızca yönlendirme biçimini kullanın.

Ardından tercihi açık hale getirin ve yeniden etkinleştirin:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Negatif öncelik, «bu bağlantıyı tercih et» demenin belgelenmiş yoludur ve iki adres ailesini de ayarlamak IPv6 bağlantısı olan bir ana bilgisayarda davranışı tutarlı tutar. Bağlantıyı yeniden etkinleştirmeden özelliği değiştirmek şu anda çalışan hiçbir şeyi değiştirmez, bu yüzden dizi açık bir up ile biter.

Bölünmeyi systemd-resolved tutsun

Varsayılan dnsmasq eklentisi sorguları tek bir yerel çözümleyiciye akıtır, bu yüzden bağlantı başına ayrım kaba kalır. systemd-resolved bölünmeyi her bağlantı için gösterir ve resolvectl query yanıt veren bağlantıyı adlandırır.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Bundan sonra kurumsal bağlantı corp.example adresini taşır ve genel bir çözümleyici geri kalanına hizmet eder. Bir sorgu yanlış bağlantıya ulaştığında, komut ona yanıt veren bağlantıyı adlandırır ve bunu bilmek yalnızca adresi bilmekten iyidir.

DNS tasarımını tünel türüne uydurun

Her şeyi tünelden geçiren gizlilik tasarımları bir bölünme listesi taşımamalıdır, çünkü bu genel adları yerel çözümleyiciye geri verir ve amacı boşa çıkarır. Bölünmüş tünel tasarımlarının buna ihtiyacı vardır: o olmadan kurumsal çözümleyici her genel sorguyu görür ve kurulum tünelin düştüğü anda bozulur.

Sonra tünel dışındaki DNS'i engelleyen kill switch vardır. Adlar tünelin bölgeleri için çözümlenir ve başka her yerde başarısız olur, oysa bağlantı tamamen sağlıklıdır. İşe yarayan yanıtlar LAN çözümleyicisi için açık bir izin veya yalnızca kurumsal bölgeyi ileten yerel bir önbellektir ve her ikisi de tüneldeki bir kusur değil, sahibi olan bir istisnadır.

Arayüz başlarken çözümleyici yapılandırmasını yeniden yazan bir profil de neredeyse aynı davranır: yerel çözümleyiciye ulaşılamadığında yalnızca tünelin bildiği adlar çözümlenir. Hangi mekanizma geçerli olursa olsun, her durumda hangi adların çalışması gerektiğini yazın ve bu listeyi raporlarla ilgilenen kişiye verin.

Her bağlantıda doğrulayın, sonra yeniden bağlandıktan sonra tekrar doğrulayın

Bir iç ve bir genel ad sorun ve sorgunun gerçekte nereye gittiğini görün. Bir sızıntı denetim sayfası hangi çözümleyicinin yanıt verdiğini söyler, sistemin hangi bağlantıyı seçtiğini değil, bu yüzden az önce yapılandırdığınız sıra hakkında hiçbir şey söylemez.

Bağlantıyı kesip yeniden bağlandıktan sonra iki sorguyu tekrar çalıştırın. Öncelikler bir bağlantı etkinleştiğinde yeniden uygulanır ve eski bir sembolik bağlantı kimsenin hatırlamadığı bir yükseltmeden sağ çıkabilir. Sonunda yazılı olarak bırakmak istediğiniz şey, hangi çözümleyicinin hangi son ekin sahibi olduğu ve yarın da geçerli olacak bir denetimdir.