DNS OpenVPN pada gateway: dnsmasq dan skop firewall

Jalankan dnsmasq pada alamat terowong, benarkan DNS hanya dari kumpulan klien, tolak penghurai, kemudian uji pertanyaan langsung dan carian aplikasi itu sendiri.

Klien dalam terowong boleh mencapai gateway, dan gateway boleh mencapai penghurai dalaman, jadi DNS sepatutnya berfungsi. Ia tidak berfungsi, kerana itu dua kebenaran berbeza dan perkhidmatan DNS yang berfungsi ialah perkara ketiga. Pendengar mesti wujud pada alamat yang dicapai klien, firewall mesti membenarkan pertanyaan ke alamat itu, dan klien mesti diberitahu untuk menggunakannya. Membuka terowong dalam kedua-dua arah menyelesaikan dua yang pertama secara kebetulan dan membiarkan yang ketiga tidak selesai.

Pendengar ialah perkhidmatan tempatan dengan dua arah

Ke dalam, klien menghantar pertanyaan ke alamat terowong gateway pada port 53. Ke luar, daemon memajukan pertanyaan itu ke huluan yang dikonfigurasikan. Kedua-dua bahagian mesti berfungsi, dan ia gagal dengan cara berbeza.

Tamat masa yang dilaporkan klien dan tamat masa yang dilihat pada gateway bukan kerosakan yang sama.

Ikat alamat terowong, bukan setiap alamat

Contoh dnsmasq khusus untuk tugas ini memerlukan alamat mendengar yang jelas, mod pengikatan yang tahan kemunculan terowong selepas permulaan, dan satu huluan yang jelas. Ini versi terkecil yang saya gunakan:

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 individu dan menangani apabila tun0 muncul kemudian, yang penting pada hos tempat perkhidmatan VPN dimulakan semula. Menyenaraikan loopback memastikan alat tempatan berfungsi tanpa menambah pendengar awam. no-resolv menghalang daemon mewarisi huluan daripada konfigurasi penghurai hos, dan no-hosts menghalang contoh ini daripada menerbitkan fail hosts gateway. Tiada satu pun pilihan itu memberi sesiapa kebenaran untuk menanyakan perkhidmatan itu.

Semak sama ada ada pendengar sedia ada pada port 53 sebelum memulakan daemon kedua, dan gunakan pemilik konfigurasi edaran dan bukannya fail sesat dalam direktori yang salah.

Benarkan input DNS, bukan transit terowong

Peraturan firewall yang menjadikan ini berfungsi ialah peraturan input tempatan yang terhad kepada antara muka terowong, kumpulan klien, alamat gateway dan port 53. Dua peraturan, satu setiap protokol, sudah 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 melalui TCP serta UDP, jadi peraturan hanya UDP membiarkan jawapan besar gagal dengan cara yang kelihatan berselang-seli. Ini bukan ufw route kebenaran, dan ia tidak boleh menjadi kebenaran luas pada tun0. Urutan sama pentingnya dengan kandungan: peraturan terdahulu yang menggugurkan semua input dari tun0 masih menang, dan menambah kebenaran di bawah guguran terminal tidak mencipta apa-apa.

Jika DNS gateway kini sebahagian daripada reka bentuk, semak dasar terdahulu itu dengan sengaja dan catat mengapa.

Separuh huluan ialah laluan berasingan

Pertanyaan meninggalkan gateway dari alamatnya sendiri menuju penghurai huluan, jadi laluan gateway dan dasar output terhadap penghurai itu mesti membenarkan pertukaran. Ini peraturan berbeza daripada yang membenarkan klien mencapai pendengar, dan ia gagal dengan gejala berbeza.

Jangan tambah output terowong tanpa had untuk menjadikan jawapan berfungsi; jawapan yang dijejaki tidak memerlukannya.

Tolak pilihan itu, kemudian semak penyerahan

Pelayan boleh mengumumkan penghurai kepada klien dengan pilihan yang ditolak. Itu pilihan, bukan arahan yang sistem pengendalian mesti patuhi:

push "dhcp-option DNS 10.90.0.1"

Klien Linux baris arahan mungkin memerlukan integrasi penghurai pengurus sambungannya, dan peranti terurus mungkin memerlukan profil pengurusan yang dikemas kini. Sahkan penghurai aktif pada klien selepas menyambung dan bukannya menganggap tolakan telah digunakan. Apabila dua mekanisme cuba menetapkan DNS serentak, anda mendapat perlumbaan yang kelihatan sebagai penyelesaian berkelip.

Matlamatnya ialah satu pemilik untuk konfigurasi penghurai klien, dan tolakan biasanya menjadi pemilik itu hanya apabila platform klien bersetuju.

Uji apa yang sebenarnya anda bina

Tanyakan satu nama peribadi yang layak sepenuhnya dan satu nama luaran yang dibenarkan terus terhadap alamat terowong, melalui UDP dan TCP. Kemudian ulangi melalui laluan carian biasa aplikasi.

Jika pertanyaan langsung berfungsi dan aplikasi masih gagal, kesalahannya ada pada penyerahan dan bukan pada pelayan:

  • Klien tidak pernah menggunakan pilihan yang ditolak.
  • Penghurai lain ditetapkan kemudian dan memenangi perlumbaan.
  • Aplikasi menggunakan pustaka penghurai sendiri atau jawapan yang dicache.

Akhiri dengan mengesahkan bahawa sumber di luar laluan VPN yang diluluskan tidak boleh menggunakan pendengar sama sekali. Penyelesaian yang berjaya tidak memberi kuasa kepada alamat yang dikembalikannya, jadi asingkan kedua-dua soalan itu.

Artikel berkaitan