AdGuard Home Menjawab Klien WireGuard Dari Alamat LAN Anda

Terowong berfungsi, firewall membenarkan port 53, AdGuard Home sedang berjalan, dan nama masih tidak dapat diselesaikan untuk klien WireGuard. Pertanyaan biasanya sampai dan jawapan biasanya keluar, jadi pengiraan peket pada penyelesai kelihatan sihat dan perkhidmatan kelihatan tidak bersalah. Apa yang salah ialah alamat sumber pada jawapan itu: ia keluar dari alamat tempatan yang tidak pernah diminta oleh klien, dan penyelesai stub klien membuangnya. Satu senarai dalam konfigurasi AdGuard Home menentukan ini, dan lalai biasanya menyerahkan keputusan itu kepada kernel.

Pertanyaan sampai, jawapan keluar dari tempat lain

Seorang klien yang dikonfigurasi dengan 10.6.0.1 sebagai resolvernya menghantar pertanyaan UDP ke 10.6.0.1 port 53. Pek tersebut melintasi terowong dan mendarat di hos, dan AdGuard Home menjawabnya. Namun, pada saluran penghantaran, balasannya adalah pek baru yang alamat sumbernya dipilih oleh sistem hos, bukan oleh jangkaan klien.

Apabila resolver klien adalah soket yang bersambung, iaitu apa yang digunakan oleh systemd-resolved, dnsmasq dan kebanyakan resolver stub, ia hanya menerima balasan dari alamat tepat yang dihantar. Balasan yang berpunca dari 192.168.1.10 kepada pertanyaan yang dihantar ke 10.6.0.1 akan ditolak sebelum sebarang pemprosesan berlaku. Resolver mencatat jawapan berjaya, klien mencatat masa tamat, dan kedua-duanya mengatakan perkara yang benar.

Jadi kaunter tidak berbohong dan begitu juga pelanggan. Bukti yang anda perlukan terdapat di tiga tempat, dalam urutan ini: alamat yang diikat oleh pendengar, laluan yang akan digunakan kernel kembali ke pelanggan, dan alamat sumber pada paket balasan sebenar.

Bagaimana kernel memilih sumber balasan

Soket UDP yang diikat ke0.0.0.0tidak mempunyai alamat sumber sendiri, jadi setiap balasan yang keluar mencetuskan pemeriksaan laluan untuk destinasi. Kernel kemudian mengambil sumber dari laluan itu: alamat yang ditetapkan oleh laluan, atau alamat utama bagi antara muka keluar. Tiada apa pun tentang alamat destinasi pertanyaan yang diingati.

Pada hos single-homed, ini tidak kelihatan, kerana hanya ada satu jawapan yang munasabah. Pada mesin yang memegang alamat LAN, alamat WireGuard dan alamat pengurusan, beberapa jawapan adalah munasabah, dan pemenangnya bergantung pada jadual penghalaan pada saat itu. Tambah laluan tambahan, alamat kedua pada antara muka yang sama, redirect NAT di hadapan penyelesai, atau jalankan AdGuard dalam bekas dengan namespace sendiri, dan sumber yang dipilih boleh berbeza daripada yang diminta oleh klien.

ss -lunp | grep :53menunjukkan permainan mana anda berada. Pendengar pada0.0.0.0:53adalah kes wildcard; pendengar pada10.6.0.1:53telah menetapkan jawapan. Membaca soket lebih cepat daripada membaca YAML, dan ia mencerminkan apa yang sebenarnya sedang berjalan dan bukannya apa yang terakhir disimpan.

Apa yang bind_hosts sebenarnya kawal

AdGuard Home'sdns.bind_hostsadalah senarai alamat tempatan yang digunakan oleh pendengar DNS. Default yang dihantar adalah wildcard, yang bermaksud terima pada setiap alamat tempatan dan biarkan kernel memilih sumber mengikut jawapan. Menggantikan wildcard dengan alamat yang dipertanyakan oleh klien mengubah soket, dan dengan itu alamat sumber pada setiap jawapan.

Senarai ini boleh mengambil lebih daripada satu entri, yang penting pada penyelesai yang melayani dua rangkaian. Menyenarai10.6.0.1dan192.168.1.10memberikan dua soket terikat, dan pertanyaan yang tiba pada salah satu daripadanya dijawab daripada alamat tempat ia tiba. Itulah tingkah laku yang kebanyakan orang anggap sudah disediakan oleh wildcard.

YAML adalah ringkas, dan alamat di dalamnya adalah alamat yang diberitahu kepada klien terowong anda untuk digunakan, bukan alamat utama hos:

dns:
  bind_hosts:
    - 10.6.0.1
  port: 53

Mengapa dua pemasangan satu penyelesai berbeza

Dalam konteks ini, dikendalikan oleh plugin bermaksud resolver dipasang dan diawasi oleh pakej lain: pakej firmware penghala, pakej NAS, atau tambah nilai automasi rumah. Pakej tersebut biasanya dihantar dengan salinan YAML AdGuard Home sendiri dan memulakan semula proses mengikut jadualnya sendiri, manakala contoh berdiri sendiri ialah binari vendor atau bekas yang anda konfigurasikan sendiri. Bagaimanapun, anda melihat dua proses bebas dengan fail konfigurasi berasingan dan pilihan bind yang berasingan, walaupun kedua-duanya membaca senarai huluan yang sama dan senarai penapis yang sama. Satu boleh mengikat alamat terowong tertentu manakala yang lain mewarisi wildcard, dan antara muka web kelihatan sama dari kedua-dua sisi.

Itulah sebabnya "penyelesai yang sama berfungsi sebelum migrasi" tidak membuktikan apa-apa mengenai pengikatan semasa. Semak soket, kemudian semak fail konfigurasi yang sebenarnya dimuat oleh proses yang sedang berjalan. Salinan lama di direktori lain adalah sebab biasa mengapa suntingan nampaknya tidak memberi kesan.

Pasangkan, kemudian uji dari sisi terowong

Tukarbind_hostskepada alamat terowong, mulakan semula perkhidmatan, dan sahkan soket berpindah:ss -lunp | grep :53kini sepatutnya menunjukkan10.6.0.1:53dan tiada entri wildcard. Jika ia masih menunjukkan0.0.0.0,proses yang sedang berjalan tidak membaca fail yang anda sunting.

Kemudian uji dari klien, kerana itu adalah satu-satunya sisi yang penting. Satu pertanyaan dengandig @10.6.0.1 example.commenggunakan laluan yang digunakan oleh pengguna, dan tangkapan pada hos dengantcpdump -ni wg0 udp port 53menunjukkan alamat sumber balasan di rangkaian. Bandingkan dengan alamat dalam tetapan resolver klien; apabila ia sama, tempoh tamat masa tidak lagi menjadi misteri.

ip route get 10.6.0.2Menjelaskan sebarang keanehan yang tinggal, kerana ia mencetak antara muka dan sumber yang akan digunakan hos kembali kepada klien. Jika output itu menamakan antara muka LAN, perubahan bind bukan penyelesaian sepenuhnya dan jadual penghalaan adalah perkara seterusnya yang perlu dibaca.

Apa yang tetapan bind tidak dapat perbaiki

Menyematkan pendengar tidak membaiki senarai akses yang mengabaikan subnet terowong, peraturan firewall yang membenarkan pertanyaan tetapi bukan balasan, atau laluan yang hilang kembali ke kumpulan WireGuard. Semua itu gagal lebih awal atau lebih lewat daripada alamat sumber, dan setiap satu mempunyai pemilik yang berbeza.

Ia juga tidak mengubahresolver hulu ke mana untuk dihantar, sama ada perlindungan pengikatan semula menolak jawapan peribadi untuk nama peribadi, atau bagaimana klien menggunakan domain carian sendiri. Itu adalah kawalan yang berasingan. Tukar alamat ikatan apabila sumber jawapan salah, dan tukar sesuatu yang lain apabila ia betul.