Hangi bağlantı yanıtlıyor: bölünmüş tünelli VPN DNS’i için yönlendirme alan adları

Sıradan gezinmeyi yerel bağlantıda tutun, şirket adları tünelin sağladığı DNS sunucusu üzerinden çözülsün. VPN’in varsayılan yolunu kapatmak size ilk yarıyı verir, ikinci yarıyı ise kurulmamış bırakır. Ardından eksik ayar, anlamını değiştiren noktalama ve hangi bağlantının gerçekten yanıtladığını gösteren tek komut gelir. Metin boyunca NetworkManager ve systemd-resolved varsayılır, çünkü karışıklık genellikle bu ikilide başlar.

Birinci adım: yolu çözücüden ayırın

ipv4.never-default bir yönlendirme sorusunu yanıtlar ve NetworkManager’ın bu bağlantıyı tüm IPv4 trafiği için yol olarak kurmasını engeller. Bir DNS yönlendirme alan adı başka bir soruyu yanıtlar: eşleşen sonek için sorguyu hangi bağlantının ad sunucuları alır. Hiçbiri diğerini gerektirmez ve bir profil yıllarca birini taşırken diğeri eksik olabilir. Yalnızca yol, tünelin şirket alt ağlarını taşıdığı ve çözücüsünün şirket adlarını yanıtladığı, geri kalan her şeyin ise dokunulmadan bırakıldığı anlamına gelir.

Yalnızca yol özelliğini ayarlayın, iç adlar başarısız olur, genellikle bozuk bir tünel gibi duyulan bir zaman aşımıyla. Yalnızca alan adını ayarlayın, makinedeki her kısa ada sessizce bir arama soneki eklemiş olursunuz. İki hata da bileti VPN sunucusuna gönderir, oysa yanlış olan kısım nadiren orasıdır.

İkinci adım: profile yalnızca yönlendirme alan adı ekleyin

Bağlantının adı corp-vpn, şirket soneki internal.example ve tünelin çözücüsü zaten erişilebilir olsun. Önce mevcut değerleri okuyun, çünkü aşağıdaki komutlar hâlihazırda girdileri olabilecek özellikleri değiştirir.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Kendi bağlantı adınız ve sonekinizle değiştirin, çünkü yukarıdaki değerler örnektir. Artı işareti göründüğünden daha önemlidir: onunla değer mevcut listeye eklenir, onsuz özellik değiştirilir ve dün çalışan bir profilden ilgisiz alan adları kaybolur. Tilde stil değil davranış değiştirir ve aşağıdaki paragraf neyi seçtiğini açıklar. Yazmadan önce okumayı koruyun, böylece değiştirme biçimi sizi asla şaşırtmasın.

Baştaki tilde yalnızca yönlendirme alan adını işaretler, böylece eşleşen sorgular bu bağlantının sunucularına gider ve sonek kısa adlara eklenmez. Tildeyi kaldırın, aynı dize arama soneki de olur; bu, insanların nadiren amaçladığı farklı bir sonuçtur. Yukarıdaki iki ayar da IPv4’tür, bu yüzden çift yığınlı profil ipv6.never-default ve ipv6.dns-search içinde aynı yönlendirme alan adını gerektirir; aksi hâlde IPv6 tarafı varsayılan yolu kullanmaya devam eder ve iç adlar orada başarısız olur.

Üçüncü adım: resolvectl’ye hangi bağlantının yanıtladığını sorun

resolvectl status çalıştırıp her bağlantının DNS sunucularını ve alan adlarını okuyun, ardından sorgulamanıza izin verilen gerçek bir iç ad için resolvectl query host.internal.example çalıştırın. İkinci komut, yönlendirme alan adının işini yaptığının tek doğrudan kanıtıdır, çünkü yanıtlayan bağlantıyı adlandırır. Tek başına durum listesi yapılandırmayı kanıtlar; sorgu çözümlemeyi kanıtlar.

systemd-resolved en iyi eşleşen yönlendirme alan adını seçer, bu yüzden başka bir bağlantıdaki daha belirgin alan adı yarışı yine de kazanabilir. Sorgu beklemediğiniz bir bağlantıdan dönerse, VPN’in DNS sunucusuna dokunmadan önce alan adı listelerini okuyun. ~. kök alan adı her şeyle eşleşir ve zaten varsa kendi adlarınız için belirgin alan adınız yine kazanır, ancak bağlantı istediğinizden çok daha fazlasını yanıtlar. Amaç yalnızca şirket adlarıysa o kök girdiyi kaldırın veya daraltın.

VPN bağlantısı hiç DNS sunucusu listelemiyorsa, istemci hiçbirini kaydetmemiştir. Arkasında sunucu olmayan yönlendirme alan adı, eksik alan adından farklı şekilde başarısız olur, bu yüzden önce kaydı düzeltin.

Dördüncü adım: ad çözümlenir ama hizmet çözümlenmezse

Doğru yanıt yalnızca çözümlemenin çalıştığını kanıtlar ve uygulama aldığı adrese giden bir yola hâlâ ihtiyaç duyar. Bu yol, az önce yapılandırdığınız bölünmüş varsayılan yoldan geçmelidir, bu yüzden DNS’i yeniden suçlamadan önce onu kontrol edin. Ardından hizmetin bağlantı noktasındaki erişilebilirliği kontrol edin, çünkü dosya paylaşımı veya dizin hizmeti çözümleme, yönlendirme ya da kimlik doğrulamada başarısız olur ve her durumda çok benzer iletiler verir. Sonucu bildirirken bu üç katmanı ayrı tutun, aksi hâlde sıradaki kişi zaten doğru olan DNS’i yeniden denetler.

Bu soruyla birlikte dolaşan Samba değişikliği erişim katmanıyla ilgilidir, DNS seçimiyle değil. Onu bir ad çözümleme arızasına uygulamak, küçük bir sorunun ikincisini edinme yoludur.

Beşinci adım: eksik alan adını düzeltmek için çözücüyü değiştirmeyin

Çözücü dosyasının üzerine yazan veya başka bir çözücü yöneticisi kuran öneri başka bir sorunu çözer. Bunlar kendi hata kipleri olan sistem entegrasyonu değişiklikleridir ve hiçbiri hiç yapılandırılmamış bir yönlendirme alan adı eklemez. Makinede ad çözümlemesinin hangi bileşene ait olduğunu değiştirmeden önce belirleyin, çünkü systemd-resolved ile NetworkManager masaüstünde bu sahiplik zaten tanımlıdır. Onunla savaşmak, çalışan bir kurulumun kimsenin yeniden üretemeyeceği bir şeye dönüşme yoludur.

İş sırası: tünelin bir çözücü sağladığını doğrulayın, yalnızca yönlendirme alan adını ekleyin, profil denetimleriyle yeniden bağlanın, yanıtlayan bağlantıyı doğrulayın ve ardından hizmeti bağlantı noktasında test edin. Bu sıra, ikinci bir görüşme olmadan bir sonraki kişiye devredebileceğiniz bir sonuç bırakır.