WireGuard DNS-i ötürmür: xüsusi BIND zonasının xidməti

WireGuard-ı qaldırdınız, tunel trafiki keçirir, daxili ad isə hələ də həll olunmur. Növbəti addım adətən WireGuard konfiqurasiyasında DNS parametrini axtarmaqdır, sanki peer başqa VPN-lərin etdiyi kimi resolver ötürə bilər. Bacarmır. Handshake açarları, interfeys ünvanlarını və icazəli IP-ləri daşıyır və DNS serverləri və ya axtarış domenləri üçün sahəsi yoxdur. Resolver siyasəti müştəridə yaşayır və düzəliş orada olmalıdır.

Tunel və resolver ayrı müqavilələrdir

WireGuard qəsdən kiçikdir. Sadaladığınız ünvanlar üçün paketləri hərəkət etdirir və peer-ləri autentifikasiya edir; bu qatın üstündəki hər şey sizin dizaynınızdır. OpenVPN dhcp-option DNS ötürə bilər, çünki onun idarəetmə kanalı konfiqurasiya daşıyır və bu fərq ikisi arasında keçənləri çaşdırır.

Beləliklə işləyən tunel ad həlli haqqında heç nə demir. Müştərinin 10.90.0.1-ə mükəmməl marşrutu ola bilər və yenə sorğularını publik resolverə göndərə bilər; buna görə simptom “VPN DNS-i pozdu” kimi görünür, halbuki DNS heç vaxt VPN-ə yönəldilməmişdi.

Zonanı rekursiv resolver olmadan xidmət edin

Server tərəfi kiçik avtoritet zonadır, ümumi resolver deyil. Bu nümunədə şlüz 10.90.0.1, müştərilər 10.90.0.0/24 və əhəmiyyətli tətbiq 10.60.0.20 ünvanında cavab verir.

Bu parametrləri ikinci blok yaratmaq əvəzinə mövcud options blokuna birləşdirin:

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 zonanı və onun faylını elan edin:

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

Yenidən yükləməzdən əvvəl doğrulayın, çünki yükləmə zamanı sintaksis xətası xidmət etdiyi hər zona üçün bütün serveri söndürür:

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

UDP və TCP 53-ü yalnız VPN interfeysinə açın. Xüsusi avtoriteti publik interfeysdə yayımlamaq həm sorğuları, həm də sadalaması dəvət edir və allow-transfer yalnız ikinci dərəcəli həqiqətən ehtiyac duyduqda bağlı qalmalıdır.

Müştərini ona yönəldin, hər link üzrə

Fərz edin ki, bağlantıya NetworkManager sahibdir və systemd-resolved resolverdir. Əvvəlcə mövcud siyasəti oxuyun, xüsusən hər hansı kök marşrutlaşdırma domenini, çünki ~. qeydi əlavə etmək istədiyiniz şeydən üstün olacaq.

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

Tilde mühüm simvoldur. Domeni yalnız-marşrut kimi qeyd edir: corp.example altındakı adlar bu linkin DNS serverinə gedir və domen qısa ad axtarış şəkilçisi kimi əlavə edilmir. O olmadan portal yazmaq portal.corp.example həll etməyə başlayır, bu sizin üçün rahat, hamı üçün isə qəribədir. Tildeni dırnaqların içində saxlayın, çünki dırnaqsız olanı ev kataloqunuza işarə etməyi gözləyən shell genişlənməsidir.

Dəyişikliyi interfeysə sahib olan menecer vasitəsilə tətbiq edin, sonra bağlantını yenidən qoşun. Eyni interfeys üçün ikinci wg-quick nüsxəsi başlatmayın; iki sahib marşrutlar üstündə dalaşacaq və biri ən pis anda qalib gələcək.

Addan əvvəl yolu yoxlayın

Adı müştəridən sorğu edin və həm cavabı, həm də onu verən serveri təsdiqləyin:

resolvectl query portal.corp.example

Bu 10.60.0.20 qaytarırsa, DNS müqaviləsi bitdi. Vaxt bitirsə, əvvəlcə 10.90.0.1-ə marşrutu, sonra firewall qaydasını, sonra serverdə allow-query yoxlayın. Bu quruluşda ad həlli uğursuzluqları demək olar ki, həmişə əlçatanlıq və ya ACL-dir, zona faylı deyil. Müştəridən bayıra doğru işləyin, çünki server sorğunun niyə gəlmədiyini sizə deyə bilməz.

Unutmayın ki, tətbiq hələ də öz marşrutuna və öz xidmət icazəsinə ehtiyac duyur. Əlçatmayan ünvana işarə edən həll olunmuş ad eyni paltarda başqa bir nasazlıqdır.

Hələ də avtomatik olmayan

Öz resolver məntiqinə sahib tətbiqlər sistem resolverini tamamilə görməzdən gəlir və nə qədər nmcli olsa da bunu dəyişmir. DNSSEC-i doğrulayan yerləşdirmələr xüsusi zona üçün açıq trust anchor dizaynına ehtiyac duyur; cavab doğrulamanı söndürmək barədə ümumi göstəriş deyil. İstifadəçilərinizin işlətdiyi müştəri proqramı ilə sınayın, təsadüfən sistem resolverini işlədən alətlə deyil. Bu ikisi arasındakı fərq bütün xəta hesabatıdır.

Donanmalar bu müştəri siyasətini təchizat sistemi ilə avtomatlaşdıra bilər, lakin siyasət sahibi olan ayrı obyekt olaraq qalır. BIND 9 sənədi yuxarıda istifadə olunan dinləmə və sorğu nəzarətlərini əhatə edir və quraşdırılmış versiyanız üçün davranışı təsdiqləmək üçün doğru yerdir.

Növbəti addım: zonanın seriya artımını və yoxlama əmrlərini dəyişiklik prosedurunuza əlavə edin ki, qeyd redaktəsi yoxlanmadan istehsala çata bilməsin.