WireGuard DNS itmez: özel bir BIND bölgesi sunmak

El sıkışma anahtarları ve izin verilen IP'leri taşır, asla bir çözümleyici taşımaz. İşte hazır özel bir BIND 9 bölgesi ve onu çözünür kılan bağlantı başına istemci politikası.

WireGuard'ı ayağa kaldırdınız, tünel trafiği geçiriyor ve iç ad hâlâ çözümlenmiyor. Sonraki adım genellikle WireGuard yapılandırmasında bir DNS ayarı aramaktır, sanki bir eş diğer bazı VPN'ler gibi bir çözümleyici itebilirmiş gibi. İtemez. El sıkışma anahtarları, arayüz adreslerini ve izin verilen IP'leri taşır ve DNS sunucuları ya da arama alanları için bir alanı yoktur. Çözümleyici politikası istemcide yaşar ve düzeltme de oraya aittir.

Tünel ve çözümleyici ayrı sözleşmelerdir

WireGuard bilerek küçüktür. Listelediğiniz adresler için paket taşır ve eşleri doğrular; o katmanın üstündeki her şey sizin tasarımınızdır. OpenVPN bir dhcp-option DNS itebilir çünkü denetim kanalı yapılandırma taşır ve bu fark ikisi arasında gidip gelenleri tökezletir.

Yani çalışan bir tünel ad çözümlemesi hakkında hiçbir şey söylemez. İstemcinin 10.90.0.1'e kusursuz bir rotası olabilir ve yine de sorgularını herkese açık bir çözümleyiciye gönderebilir, bu yüzden belirti “VPN DNS'i bozdu” gibi görünür, oysa DNS hiçbir zaman VPN'e yönlendirilmemişti.

Bölgeyi özyinelemeli bir çözümleyici olmadan sunun

Sunucu tarafı küçük bir yetkili bölgedir, genel bir çözümleyici değil. Bu örnekte ağ geçidi 10.90.0.1, istemciler 10.90.0.0/24 ve önemsediğiniz uygulama 10.60.0.20 üzerinde yanıt veriyor.

Bu ayarları ikinci bir blok oluşturmak yerine mevcut options bloğuyla birleştirin:

options {
    listen-on { 127.0.0.1; 10.90.0.1; };
    listen-on-v6 { none; };
    allow-query { 127.0.0.1; 10.90.0.0/24; };
    allow-transfer { none; };
    recursion no;
};

Sonra bölgeyi ve dosyasını bildirin:

zone "corp.example" {
    type primary;
    file "/etc/bind/db.corp.example";
};
$TTL 300
@ IN SOA ns.corp.example. hostmaster.corp.example. ( 1 3600 600 604800 300 )
@      IN NS ns.corp.example.
ns     IN A  10.90.0.1
portal IN A  10.60.0.20

Yeniden yüklemeden önce doğrulayın, çünkü yükleme sırasındaki bir sözdizimi hatası hizmet ettiği her bölge için tüm sunucuyu düşürür:

named-checkconf
named-checkzone corp.example /etc/bind/db.corp.example

UDP ve TCP 53'ü yalnızca VPN arayüzünde açın. Genel arayüzde özel bir yetki yayımlamak hem sorguları hem de sayımı davet eder ve bir ikincil gerçekten ihtiyaç duymadıkça allow-transfer kapalı kalmalıdır.

İstemciyi ona yönlendirin, bağlantı başına

Bağlantının NetworkManager'a ait olduğunu ve çözümleyicinin systemd-resolved olduğunu varsayın. Önce mevcut politikayı okuyun, özellikle kök yönlendirme alanı varsa, çünkü bir ~. girdisi eklemek üzere olduğunuz şeyi geçersiz kılacak.

nmcli connection modify wg-office +ipv4.dns 10.90.0.1
nmcli connection modify wg-office +ipv4.dns-search '~corp.example'

Önemli karakter tilde işaretidir. Alanı yalnızca-rota olarak işaretler: corp.example altındaki adlar bu bağlantının DNS sunucusuna gider ve alan kısa ad araması için son ek olarak eklenmez. O olmadan, portal yazmak portal.corp.example çözümlemeye başlar; bu sizin için kullanışlı, diğer herkes için şaşırtıcıdır. Tildeyi tırnak içinde tutun, çünkü tırnaksız olan ev dizininize işaret etmeyi bekleyen bir kabuk genişletmesidir.

Değişikliği arayüzün sahibi olan yönetici üzerinden uygulayın, ardından bağlantıyı yeniden bağlayın. Aynı arayüz için ikinci bir wg-quick örneği başlatmayın; iki sahip rotalar için çekişir ve biri en kötü anda kazanır.

Adı doğrulamadan önce yolu doğrulayın

Adı istemciden sorgulayın ve hem yanıtı hem de onu üreten sunucuyu doğrulayın:

resolvectl query portal.corp.example

Bu 10.60.0.20 döndürürse, DNS sözleşmesi yerine getirilmiştir. Zaman aşımına uğrarsa, önce 10.90.0.1'e giden rotayı, sonra güvenlik duvarı kuralını, sonra sunucudaki allow-query ayarını denetleyin. Bu kurulumda ad çözümleme hataları neredeyse her zaman erişilebilirlik veya bir ACL'dir, bölge dosyası değil. İstemciden dışarı doğru çalışın, çünkü sunucu bir sorgunun neden hiç ulaşmadığını size söyleyemez.

Uygulamanın hâlâ kendi rotasına ve kendi hizmet iznine ihtiyaç duyduğunu unutmayın. Ulaşılamayan bir adrese işaret eden çözümlenmiş bir ad, aynı kıyafetteki başka bir arızadır.

Hâlâ otomatik olmayanlar

Kendi çözümleyici mantığına sahip uygulamalar sistem çözümleyicisini tamamen yok sayar ve hiçbir nmcli miktarı bunu değiştirmez. DNSSEC doğrulayan kurulumların özel bölge için açık bir güven çapası tasarımına ihtiyacı vardır; yanıt, doğrulamayı kapatma yönünde genel bir talimat değildir. Kullanıcılarınızın çalıştırdığı aynı istemci yazılımıyla test edin, sistem çözümleyicisini tesadüfen kullanan bir araçla değil. İkisi arasındaki fark, hata raporunun tamamıdır.

Filolar bu istemci politikasını provizyon sistemleri üzerinden otomatikleştirebilir, ancak politika bir sahibi olan ayrı bir nesne olarak kalır. BIND 9 referansı yukarıda kullanılan dinleme ve sorgu denetimlerini kapsar ve kurulu sürümünüz için davranışı doğrulamak adına doğru yerdir.

Sonraki adım: bölgenin seri numarası artışını ve doğrulama komutlarını değişiklik prosedürünüze ekleyin, böylece bir kayıt düzenlemesi denetlenmeden üretime ulaşamasın.

İlgili makaleler