AdGuard Home Menjawab Klien WireGuard Dari Alamat LAN Anda

Terowongan aktif, firewall mengizinkan port 53, AdGuard Home berjalan, dan nama masih tidak terpecahkan untuk klien WireGuard. Permintaan biasanya tiba dan jawaban biasanya keluar, sehingga penghitung paket pada resolver terlihat sehat dan layanan tampak tidak bersalah. Yang salah adalah alamat sumber pada jawaban itu: jawaban tersebut keluar dari alamat lokal yang tidak pernah diminta oleh klien, dan resolver stub klien membuangnya. Satu daftar dalam konfigurasi AdGuard Home menentukan ini, dan default biasanya menyerahkan keputusan itu ke kernel.

Permintaan tiba, jawaban keluar dari tempat lain

Seorang klien yang dikonfigurasi dengan 10.6.0.1 sebagai resolver-nya mengirimkan kueri UDP ke 10.6.0.1 port 53. Paket itu melewati terowongan dan mendarat di host, dan AdGuard Home menjawabnya. Namun, di jaringan, balasan adalah paket baru yang alamat sumbernya dipilih oleh stack host, bukan oleh harapan klien.

Ketika resolver klien adalah soket yang terhubung, yang digunakan oleh systemd-resolved, dnsmasq, dan sebagian besar stub resolver, ia hanya menerima balasan dari alamat persis yang dikirimkan. Balasan yang berasal dari 192.168.1.10 untuk kueri yang dikirim ke 10.6.0.1 akan dibuang sebelum parsing apapun terjadi. Resolver mencatat jawaban berhasil, klien mencatat timeout, dan keduanya mengatakan kebenaran.

Jadi penghitung tidak berbohong dan begitu juga klien. Bukti yang Anda butuhkan ada di tiga tempat, dalam urutan ini: alamat yang terikat dengan pendengar, rute yang akan digunakan kernel kembali ke klien, dan alamat sumber pada paket balasan yang sebenarnya.

Bagaimana kernel memilih sumber balasan

Socket UDP yang terikat ke0.0.0.0tidak memiliki alamat sumber sendiri, jadi setiap balasan keluar memicu pencarian rute untuk tujuan tersebut. Kernel kemudian mengambil sumber dari rute itu: alamat yang ditetapkan oleh rute, atau alamat utama dari antarmuka keluar. Tidak ada yang diingat tentang alamat tujuan query.

Pada host yang hanya memiliki satu koneksi, hal ini tidak terlihat, karena hanya ada satu jawaban yang masuk akal. Pada mesin yang memiliki alamat LAN, alamat WireGuard, dan alamat manajemen, beberapa jawaban mungkin, dan pemenangnya bergantung pada tabel routing pada saat itu. Tambahkan rute tambahan, alamat kedua pada antarmuka yang sama, redirect NAT di depan resolver, atau jalankan AdGuard di dalam kontainer dengan namespace-nya sendiri, dan sumber yang dipilih bisa berbeda dari yang dikueri klien.

ss -lunp | grep :53menunjukkan permainan mana yang sedang Anda mainkan. Pendengar di0.0.0.0:53adalah kasus wildcard; pendengar di10.6.0.1:53sudah menetapkan jawabannya. Membaca socket lebih cepat daripada membaca YAML, dan itu mencerminkan apa yang sebenarnya berjalan daripada apa yang terakhir disimpan.

Apa yang sebenarnya dikontrol oleh bind_hosts

AdGuard Home'sdns.bind_hostsadalah daftar alamat lokal yang digunakan oleh pendengar DNS. Default bawaan adalah wildcard, yang berarti menerima di setiap alamat lokal dan membiarkan kernel memilih sumber per balasan. Menggantikan wildcard dengan alamat yang ditanyakan klien mengubah soket, dan dengan itu alamat sumber pada setiap jawaban.

Daftar ini dapat memuat lebih dari satu entri, yang penting pada resolver yang melayani dua jaringan. Mencantumkan10.6.0.1dan192.168.1.10memberikan dua soket yang terikat, dan query yang datang ke salah satunya dijawab dari alamat tempat query tersebut datang. Itulah perilaku yang sebagian besar orang anggap sudah disediakan oleh wildcard.

YAML-nya sederhana, dan alamat di dalamnya adalah yang diberikan kepada klien tunnel Anda untuk digunakan, bukan alamat utama host:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Mengapa dua instalasi dari satu resolver tidak sama

Dikelola oleh plugin, dalam konteks ini, berarti resolver diinstal dan diawasi oleh paket lain: paket firmware router, paket NAS, atau tambahan otomatisasi rumah. Paket itu biasanya menyertakan salinan YAML AdGuard Home sendiri dan me-restart proses sesuai jadwalnya sendiri, sementara instance mandiri adalah biner atau kontainer vendor yang Anda konfigurasikan sendiri. Bagaimanapun, Anda sedang melihat dua proses independen dengan file konfigurasi terpisah dan pilihan bind terpisah, bahkan ketika keduanya membaca daftar upstream yang sama dan daftar filter yang sama. Satu dapat mengikat alamat tunnel tertentu sementara yang lain mewarisi wildcard, dan antarmuka web terlihat identik dari kedua sisi.

Itulah mengapa "resolver yang sama bekerja sebelum migrasi" tidak membuktikan apa pun tentang binding saat ini. Periksa socket, lalu periksa file konfigurasi yang benar-benar dimuat oleh proses yang sedang berjalan. Salinan lama di direktori lain adalah alasan umum mengapa edit tidak terlihat berpengaruh.

Pasang, lalu uji dari sisi tunnel

Ubahbind_hostsmenjadi alamat tunnel, restart layanan, dan konfirmasi socket berpindah:ss -lunp | grep :53sekarang harus menunjukkan10.6.0.1:53dan tidak ada entri wildcard. Jika masih menunjukkan0.0.0.0,proses yang berjalan tidak membaca file yang Anda edit.

Lalu uji dari sisi klien, karena itu satu-satunya sisi yang penting. Sebuah query dengandig @10.6.0.1 example.commelibatkan jalur yang digunakan pengguna, dan tangkapan pada host dengantcpdump -ni wg0 udp port 53menunjukkan alamat sumber balasan di jaringan. Bandingkan dengan alamat di pengaturan resolver klien; ketika keduanya sama, waktu tunggu berhenti menjadi misteri.

ip route get 10.6.0.2Menjelaskan keanehan yang tersisa, karena mencetak antarmuka dan sumber yang digunakan host untuk kembali ke klien. Jika keluaran itu menyebutkan antarmuka LAN, perubahan bind bukanlah perbaikan seluruhnya dan tabel routing adalah hal berikutnya yang harus dibaca.

Apa yang tidak dapat diperbaiki oleh pengaturan bind

Menyematkan listener tidak memperbaiki daftar akses yang mengabaikan subnet tunnel, aturan firewall yang mengizinkan query tetapi tidak balasan, atau rute yang hilang kembali ke pool WireGuard. Masalah-masalah tersebut gagal lebih awal atau lebih lambat daripada alamat sumber, dan masing-masing memiliki pemilik yang berbeda.

Ini juga tidak mengubahresolver hulu mana yang diteruskan., apakah perlindungan pengikatan ulang menolak jawaban pribadi untuk nama pribadi, atau bagaimana klien menerapkan domain pencariannya sendiri. Itu adalah kontrol yang terpisah. Ubah alamat bind ketika sumber balasan salah, dan ubah hal lain ketika tidak salah.