WireGuard tidak mendorong DNS: menyajikan zona BIND privat

Handshake membawa kunci dan IP yang diizinkan, tidak pernah membawa resolver. Berikut zona BIND 9 privat yang sudah jadi plus kebijakan klien per tautan yang membuatnya resolve.

Anda menaikkan WireGuard, tunnel melewatkan lalu lintas, dan nama internal tetap tidak ter-resolve. Langkah berikutnya biasanya mencari pengaturan DNS di konfigurasi WireGuard, seolah peer bisa mendorong resolver seperti yang dilakukan beberapa VPN lain. Tidak bisa. Handshake membawa kunci, alamat antarmuka, dan IP yang diizinkan, dan tidak punya bidang untuk server DNS atau domain pencarian. Kebijakan resolver tinggal di klien, dan di situlah perbaikannya.

Tunnel dan resolver adalah dua kontrak terpisah

WireGuard sengaja dibuat kecil. Ia memindahkan paket untuk alamat yang Anda daftarkan dan mengautentikasi peer; semua di atas lapisan itu adalah desain Anda. OpenVPN bisa mendorong dhcp-option DNS karena kanal kontrolnya membawa konfigurasi, dan perbedaan itulah yang menjatuhkan orang yang berpindah antara keduanya.

Jadi tunnel yang berfungsi tidak memberi tahu apa pun tentang resolusi nama. Klien bisa punya rute sempurna ke 10.90.0.1 dan tetap mengirim kuerinya ke resolver publik, itulah sebabnya gejalanya tampak seperti “VPN merusak DNS” padahal DNS tidak pernah diarahkan ke VPN.

Sajikan zona tanpa menjadi resolver rekursif

Sisi server adalah zona otoritatif kecil, bukan resolver umum. Pada contoh ini gateway adalah 10.90.0.1, klien adalah 10.90.0.0/24, dan aplikasi yang Anda pedulikan menjawab di 10.60.0.20.

Gabungkan pengaturan ini ke blok options yang sudah ada alih-alih membuat blok kedua:

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;
};

Lalu deklarasikan zona dan berkasnya:

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

Validasi sebelum memuat ulang, karena kesalahan sintaksis saat memuat ulang menjatuhkan seluruh server untuk setiap zona yang dilayaninya:

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

Buka UDP dan TCP 53 hanya pada antarmuka VPN. Menerbitkan otoritas privat pada antarmuka publik mengundang kueri sekaligus enumerasi, dan allow-transfer sebaiknya tetap tertutup kecuali sekunder benar-benar membutuhkannya.

Arahkan klien ke sana, per tautan

Anggap NetworkManager memiliki koneksi dan systemd-resolved adalah resolver-nya. Baca kebijakan yang ada lebih dulu, terutama domain perutean akar, karena entri ~. akan mengalahkan apa yang akan Anda tambahkan.

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

Tilde adalah karakter pentingnya. Ia menandai domain sebagai hanya-rute: nama di bawah corp.example pergi ke server DNS tautan ini, dan domain tidak ditambahkan sebagai akhiran pencarian nama pendek. Tanpanya, mengetik portal mulai me-resolve portal.corp.example, yang nyaman bagi Anda dan mengejutkan bagi orang lain. Simpan tilde di dalam tanda kutip, karena yang tanpa kutip adalah ekspansi shell yang menunggu untuk menunjuk ke direktori rumah Anda.

Terapkan perubahan melalui manajer yang memiliki antarmuka, lalu sambungkan ulang koneksi. Jangan jalankan instans wg-quick kedua untuk antarmuka yang sama; dua pemilik akan bertengkar soal rute dan salah satunya menang di saat terburuk.

Verifikasi jalurnya sebelum namanya

Kueri nama itu dari klien dan pastikan jawabannya sekaligus server yang menghasilkannya:

resolvectl query portal.corp.example

Jika itu mengembalikan 10.60.0.20, kontrak DNS selesai. Jika waktu habis, periksa dulu rute ke 10.90.0.1, lalu aturan firewall, lalu allow-query di server. Kegagalan resolusi nama pada penyiapan ini hampir selalu soal keterjangkauan atau ACL, bukan berkas zona. Bekerjalah dari klien ke luar, karena server tidak bisa memberi tahu Anda mengapa sebuah kueri tidak pernah tiba.

Ingat bahwa aplikasi tetap butuh rutenya sendiri dan izin layanannya sendiri. Nama yang sudah ter-resolve tetapi menunjuk ke alamat tak terjangkau adalah kegagalan lain dengan pakaian yang sama.

Apa yang masih belum otomatis

Aplikasi dengan logika resolver sendiri mengabaikan resolver sistem sepenuhnya, dan berapa pun banyaknya nmcli tidak mengubah itu. Penerapan yang memvalidasi DNSSEC memerlukan desain jangkar kepercayaan eksplisit untuk zona privat; jawabannya bukan instruksi menyeluruh untuk mematikan validasi. Ujilah dengan perangkat lunak klien yang sama dengan yang dijalankan pengguna Anda, bukan dengan alat yang kebetulan memakai resolver sistem. Selisih antara keduanya adalah seluruh laporan bug.

Armada dapat mengotomatiskan kebijakan klien ini melalui sistem penyediaan mereka, tetapi kebijakan itu tetap objek terpisah dengan pemilik. Referensi BIND 9 mencakup kontrol pendengaran dan kueri yang digunakan di atas, dan itu tempat yang tepat untuk memastikan perilaku untuk versi yang Anda pasang.

Langkah berikutnya: tambahkan kenaikan nomor seri zona dan perintah pemeriksaan ke prosedur perubahan Anda, agar penyuntingan record tidak bisa mencapai produksi tanpa diperiksa.

Artikel terkait