Domain VPN Anda di dnsmasq bukan transfer zona

Anda mencari zona perusahaan di konfigurasi dnsmasq klien, tidak menemukannya, lalu menyimpulkan bahwa VPN gagal mendorong domainnya. Yang didorong adalah petunjuk perutean, bukan zona. Klien mencatat domain dan resolver yang seharusnya menjawabnya, dan backend terkelola mengubahnya menjadi penerusan bersyarat. Mencari di tempat yang salah menghasilkan diagnosis yang yakin dan sepenuhnya salah.

Yang diterima klien bukan yang ditawarkan gateway

Gateway dapat menawarkan resolver, domain, dan rute yang diperlukan untuk mencapainya, dan klien dapat menerima ketiganya atau tidak sama sekali. Profil yang diimpor, skrip pembantu, atau kebijakan yang mengabaikan opsi yang didorong dapat membuat himpunan yang diterima kosong sementara sisi server terlihat benar. Mulailah dari keadaan tercatat klien, bukan dari konfigurasi server, karena keadaan itulah yang benar-benar diterima resolver. Jika domain yang diterima hilang, tidak ada yang lebih jauh lagi yang akan penting. Periksa properti DNS koneksi sebelum memeriksa cache apa pun.

Perbedaan itu menjelaskan sebagian besar laporan tentang domain yang tidak pernah tiba. Domain itu ditawarkan, dan tidak diterapkan.

Dua jenis entri domain

Koneksi dapat membawa domain pencarian biasa dan domain khusus rute, dan jenis kedua dimulai dengan tilde. Domain pencarian merutekan kueri dan memungkinkan nama pendek diperluas, yang nyaman di stasiun kerja dan mengejutkan di server. Domain khusus rute menyatakan bahwa kueri untuk sufiks itu harus pergi ke server tertentu tanpa mengubah cara nama pendek diselesaikan. Menulis domain yang sama dengan kedua cara bukanlah redundansi, karena kedua entri melakukan pekerjaan berbeda.

Untuk ruang nama pribadi, bentuk khusus rute biasanya yang Anda inginkan. Bentuk ini menjaga sufiks perusahaan tetap mengarah ke resolver perusahaan dan membiarkan yang lain.

localhost di resolv.conf bukan bug

Saat resolver cache lokal digunakan, berkas sistem menunjuk ke alamat loopback dan tidak ke yang lain. Entri itu menandai pendengar lokal, bukan server hulu yang diberikan manajer kepadanya. Alamat perusahaan akan sah tidak ada di berkas itu.

Mengganti entri itu dengan resolver publik adalah perbaikan keliru yang klasik. Ini memulihkan resolusi nama publik dan membuang kebijakan bersyarat dalam penyuntingan yang sama.

Jangan mencampuradukkan backend

Instans dnsmasq terkelola dan resolver sistem adalah program berbeda dengan konfigurasi berbeda dan tampilan status berbeda. Perintah status untuk yang satu tidak memberi tahu apa pun yang berguna tentang yang lain.

Tentukan backend mana yang dikonfigurasi untuk digunakan manajer, lalu baca konfigurasi yang dihasilkan backend itu, bukan berkas seluruh distribusi yang kebetulan ada. Manajer menulis konfigurasi instansnya sendiri dan mendukung opsi khusus untuk instans itu, jadi menyunting berkas global yang tidak terkait tidak mengubah apa pun dan tampak seperti perubahan tanpa efek. Menjalankan daemon kedua di port 53 lebih buruk daripada tidak berguna, karena sekarang dua program tidak sepakat siapa yang memiliki port itu. Tetapkan pemiliknya dulu, lalu sunting di tempat pemilik itu membaca.

Uji ruang nama, bukan hanya jawabannya

Kueri satu nama pribadi yang diizinkan dan satu nama kontrol publik melalui jalur normal aplikasi. Kueri langsung ke server perusahaan membuktikan catatan itu ada; itu tidak membuktikan klien memilih server tersebut. Kueri kedua adalah yang menguji kebijakan.

Lalu ulangi setelah menyambung ulang dan setelah memutus. Asosiasi harus mengikuti siklus hidup koneksi, dan nama pribadi harus berhenti diselesaikan saat terowongan hilang, bukan jatuh kembali ke resolver publik yang menjawab sufiks yang sama. Jika jatuh kembali, Anda menemukan kebocoran, yang merupakan cacat berbeda dari pencarian rusak. Catat backend mana yang berjalan, domain mana yang diterapkan, dan apa yang dikembalikan setiap kueri.