DNS OpenVPN di gateway: dnsmasq dan cakupan firewall

Jalankan dnsmasq di alamat tunnel, izinkan DNS hanya dari kumpulan klien, dorong resolver, lalu uji kueri langsung dan pencarian aplikasi sendiri.

Klien di tunnel bisa mencapai gateway, dan gateway bisa mencapai resolver internal, jadi DNS seharusnya bekerja. Namun tidak, karena keduanya adalah dua izin berbeda dan layanan DNS yang berfungsi adalah hal ketiga. Pendengar harus ada di alamat yang bisa dicapai klien, firewall harus mengizinkan kueri ke alamat itu, dan klien harus diberi tahu untuk memakainya. Membuka tunnel di kedua arah menyelesaikan dua hal pertama secara kebetulan dan meninggalkan yang ketiga belum selesai.

Pendengar adalah layanan lokal dengan dua arah

Ke dalam, klien mengirim kueri ke alamat tunnel gateway pada port 53. Ke luar, daemon meneruskan kueri itu ke hulu yang dikonfigurasi. Kedua belah pihak harus bekerja, dan mereka gagal dengan cara berbeda.

Batas waktu yang dilaporkan klien dan batas waktu yang terlihat di gateway bukan kerusakan yang sama.

Ikat alamat tunnel, bukan semua alamat

Instans dnsmasq khusus untuk tugas ini memerlukan alamat dengar yang eksplisit, mode pengikatan yang tahan terhadap munculnya tunnel setelah mulai, dan satu hulu yang jelas. Ini versi terkecil yang saya pakai:

listen-address=127.0.0.1,10.90.0.1
bind-dynamic
no-resolv
no-hosts
server=192.168.50.53

bind-dynamic mengikat alamat individual dan menangani saat tun0 muncul belakangan, yang penting pada host tempat layanan VPN dimulai ulang. Mendaftar loopback menjaga alat lokal tetap bekerja tanpa menambah pendengar publik. no-resolv mencegah daemon mewarisi hulu dari konfigurasi resolver host, dan no-hosts mencegah instans ini menerbitkan file hosts gateway. Tak satu pun opsi itu memberi siapa pun izin untuk menanyakan layanan.

Periksa apakah ada pendengar yang sudah ada di port 53 sebelum memulai daemon kedua, dan gunakan pemilik konfigurasi distribusi alih-alih file nyasar di direktori yang salah.

Izinkan masukan DNS, bukan transit tunnel

Aturan firewall yang membuat ini bekerja adalah aturan masukan lokal yang dibatasi pada antarmuka tunnel, kumpulan klien, alamat gateway, dan port 53. Dua aturan, satu per protokol, cukup:

sudo ufw allow in on tun0 proto udp from 10.90.0.0/24 to 10.90.0.1 port 53
sudo ufw allow in on tun0 proto tcp from 10.90.0.0/24 to 10.90.0.1 port 53

DNS berjalan lewat TCP maupun UDP, jadi aturan hanya UDP membuat jawaban besar gagal dengan cara yang tampak berkala. Ini bukan ufw route izin, dan tidak boleh menjadi izin luas pada tun0. Urutan sama pentingnya dengan isi: aturan sebelumnya yang membuang semua masukan dari tun0 tetap menang, dan menambahkan izin di bawah pembuangan akhir tidak menciptakan apa pun.

Jika DNS gateway kini bagian dari desain, tinjau kebijakan sebelumnya itu dengan sengaja dan catat alasannya.

Separuh hulu adalah jalur terpisah

Kueri meninggalkan gateway dari alamatnya sendiri menuju resolver hulu, jadi rute gateway dan kebijakan keluaran ke resolver itu harus mengizinkan pertukaran. Itu aturan berbeda dari yang membiarkan klien mencapai pendengar, dan gagal dengan gejala berbeda.

Jangan menambahkan keluaran tunnel tanpa batas agar jawaban bekerja; jawaban yang dilacak tidak membutuhkannya.

Dorong opsi, lalu periksa penyerahan

Server dapat mengumumkan resolver ke klien dengan opsi yang didorong. Itu opsi, bukan instruksi yang wajib dipatuhi sistem operasi:

push "dhcp-option DNS 10.90.0.1"

Klien Linux baris perintah mungkin perlu integrasi resolver manajer koneksinya, dan perangkat terkelola mungkin perlu profil manajemen yang diperbarui. Konfirmasikan resolver aktif di klien setelah tersambung alih-alih menganggap dorongan diterapkan. Saat dua mekanisme mencoba menetapkan DNS bersamaan, Anda mendapat balapan yang tampak sebagai resolusi berkedip.

Satu pemilik untuk konfigurasi resolver klien adalah tujuannya, dan dorongan biasanya menjadi pemilik itu hanya bila platform klien setuju.

Uji apa yang benar-benar Anda bangun

Kuerikan satu nama privat yang sepenuhnya memenuhi syarat dan satu nama eksternal yang diizinkan langsung ke alamat tunnel, lewat UDP dan TCP. Lalu ulangi melalui jalur pencarian biasa aplikasi.

Jika kueri langsung bekerja dan aplikasi masih gagal, kesalahannya ada pada penyerahan, bukan pada server:

  • Klien tidak pernah menerapkan opsi yang didorong.
  • Resolver lain ditetapkan belakangan dan memenangkan balapan.
  • Aplikasi memakai pustaka resolver sendiri atau jawaban yang di-cache.

Akhiri dengan memastikan bahwa sumber di luar jalur VPN yang disetujui sama sekali tidak dapat memakai pendengar. Resolusi yang berhasil tidak memberi wewenang pada alamat yang dikembalikannya, jadi pisahkan kedua pertanyaan itu.

Artikel terkait