Gönderilen DNS sunucusu günlükte, tünel ayakta ve iç adlar hâlâ başarısız oluyor. Göndermenin kendisinde hiçbir şey bozuk değil; ayar ulaştı ve orada durdu. Gönderilen DNS seçeneği istemciye bir mesajdır, işletim sisteminin çözümleyicisine bir talimat değildir ve bu ikisi arasındaki devir, bu tür vakaların çoğunun sona erdiği yerdir. Beş denetim sırayla gerçekleşmeyen devri bulur.

Birinci denetim: bağlantı nasıl başlar

Bağlantının sahibi, çözümleyici ayarlarını kimin uygulayabileceğini belirler. Kabuktan verilen doğrudan openvpn komutu kendi sürecinden başka bir şeye sahip değildir; systemd birimi, NetworkManager ya da satıcı istemcisi ise DNS yayımlamanın kendi yoluna sahiptir. Bunlardan herhangi birini varsaymadan önce süreç listesini ve birim adını okuyun.

Komut satırı süreci otomatik olarak bir NetworkManager bağlantısı değildir ve bir NetworkManager bağlantısı otomatik olarak resolv.conf dosyasını yazan şey değildir. Bu iki varsayım bu incelemede harcanan saatlerin çoğunu açıklar. Gerçekte gördüğünüz arayüz için hangi bileşenin DNS yayımlayacağını sorun.

Devam etmeden önce sahibi yazın. Sonraki her denetim ona bağlıdır.

İkinci denetim: çözümleyici bağlantısı gerçekte ne tutuyor

systemd-resolved çalışan bir sistemde resolvectl status her bağlantıyı DNS sunucuları ve alan adlarıyla listeler. Tünelin bağlantısını bulun ve girdilerini okuyun ve arayüzün adının tun0 olduğunu varsaymayın, çünkü numaralandırma oluşturulma sırasını izler. Gönderilen adres bağlantıda yoksa başarısız olan sorgu değil, devirdir.

Adres varsa sıradaki soru o bağlantının hangi alan adlarını talep ettiğidir. Alan adı listesi olmayan bir bağlantı yalnızca doğrudan sorulan adlara yanıt verir ve bu bir split-DNS kurulumunun nadiren istediği şeydir. Yalnızca adres gereklidir ama yeterli değildir.

Herhangi bir sonuca varmadan önce çözümleyici çıktısındaki bağlantı adını VPN günlüğündeki arayüz adıyla karşılaştırın. Oradaki uyumsuzluk genellikle günlük satırının başka bir süreçten geldiği anlamına gelir.

Üçüncü denetim: ad alanı o bağlantıyı seçiyor mu

Çözümleyici doğru sunucuyu tutuyor olabilir ve yine de ona danışılmıyor olabilir. Bağlantı başına alan adı hangi sorgunun hangi bağlantıya gideceğini belirler ve yönlendirme alan adı yoksa özel ad alanı varsayılan bağlantının söylediğine geri döner. Bu yüzden iç ad için resolvectl query başarılı olabilirken uygulama hâlâ başarısız olur. Uygulama tamamen farklı bir çözümleyici yolu kullanıyor olabilir.

Sunucu adresini değil, alan adı atamasını denetleyin. ~corp.example olarak yazılan bir alan adı yönlendirme alan adıdır ve tilde işareti adın nasıl eşleştirildiğini değiştirir.

Uygulamanın kendi çözümleyicisi varsa sistem aracıyla değil, onun kullandığı aynı mekanizmayla test edin. Sistem çözümleyicisini atlayan bir sorgu aracı, bağlantının durumu ne olursa olsun başarılı olacaktır.

Dördüncü denetim: bir sahip, iki değil

NetworkManager VPN'i ve çözümleyici durumunu zaten yönetiyorsa ilgisiz bir hook betiği eklemek birbiriyle yarışan yazıcılar oluşturur. Paketin systemd-resolved için sağladığı hook desteklenen bir entegrasyondur ve belirli bir yaşam döngüsü bekler: script-security 2, bir up yolu, up-restart, bir down yolu ve down-pre. Bu seçenekler kaydın ve kaldırmanın yalnızca ilk bağlantıda değil, doğru anlarda gerçekleşmesini sağlar.

Paketten kurulan yolu kullanın, bir kılavuzdan kopyalanmış örnek yolu değil. İzinler de önemlidir, çünkü hook ayrıcalıklar düştükten sonra çalışır.

Bir dağıtımın çözümleyici betiğini çıktı hedefini değiştirmek için düzenlemek tek bir ana makinenin geçici çözümünü kaydeder. Bu genel bir onarım değildir.

Beşinci denetim: yeniden bağlandıktan sonra aynı sonuç

Yeniden bağlanın ve bağlantıyı tekrar okuyun. Bir kez görünüp sonraki geçişte kaybolan bir kayıt, bu denetim listesinin var olma nedenidir. Askıya almadan sonra, zorunlu yeniden bağlanmadan sonra ve çözümleyici hizmeti yeniden başlatıldıktan sonra test edin. Her geçiş farklı bir sıra varsayımını sınar.

Ancak yeniden bağlanmada beş denetimin tümü geçerse gönderilen ayarların kullanımda olduğunu söyleyebilirsiniz. Bundan öncesi şanslı bir anın fotoğrafıdır.

İlgili makaleler