Mengapa kueri dnsmasq keluar dari VPN setelah pengalihan DNS

Klien LAN menjangkau VPN-nya dengan benar, namun kueri DNS-nya tetap muncul di uplink yang salah. Ini bukan kebocoran dalam pengertian biasa; inilah yang terjadi ketika router berhenti meneruskan kueri dan menjawabnya sendiri. Penyadapan menulis ulang tujuan ke soket lokal, lalu resolver membuka percakapan kedua yang tidak berkaitan dengan alamat sumbernya sendiri dan keputusan peruteannya sendiri. Tanda yang diterapkan pada aliran klien menjelaskan percakapan pertama dan sama sekali tidak menjelaskan yang kedua.

Tanda tidak ikut bepergian bersama kueri

Tanda paket hidup pada entri conntrack dan pada paket yang sedang melayang. Aturan REDIRECT mengakhiri penerbangan itu: muatan diserahkan ke soket lokal, dan entri asli sudah menyelesaikan tugasnya. Yang meninggalkan router sesudahnya adalah soket baru yang dibuat proses resolver, dengan alamat router itu sendiri sebagai sumber.

Itulah sebabnya rute kebijakan yang dikunci pada alamat klien LAN tidak pernah cocok dengan kueri upstream. Soket baru itu milik dnsmasq dan bukan milik klien, dan kernel mengevaluasi rute untuk lalu lintas router sendiri. Aturan sumber, aturan antarmuka, dan aturan tanda semuanya melihat tuple yang berbeda. Menganggap tanda ikut menyebar adalah kesalahan paling umum dalam penyiapan ini, dan hal itu tidak terlihat dalam tangkapan di sisi klien.

Kedua percakapan memang berbagi nama dan waktu, dan itulah yang membuatnya tampak seperti satu aliran ketika Anda memindai tangkapan dengan cepat.

Di mana penerusan berubah menjadi resolusi lokal

Mulailah dengan mencari tahu apakah port 53 dialihkan, diterjemahkan ke host lain, atau dibiarkan apa adanya, karena ketiga kasus berperilaku berbeda. Pengalihan ke port lokal mengakhiri penerusan, sedangkan penerjemahan ke mesin lain menjaga paket tetap bergerak dan menjaga tuple klien tetap bermakna.

Perhatikan kedua protokol. Resolver yang dapat dijangkau lewat UDP dan TCP akan diuji pada keduanya, dan seperangkat aturan yang hanya mencakup UDP meninggalkan lubang sunyi untuk jawaban besar. Aturan yang dihasilkan pengelola konfigurasi router sendiri juga dihitung, dan menyunting berkas hasil bangkitan biasanya kalah oleh pemuatan ulang berikutnya.

sudo nft list ruleset | grep -n -B2 -A4 'dport 53'
sudo iptables -t nat -L -n -v | grep -E ':53|dns'
sudo ss -lunp | grep ':53'

Keluaran itu menjawab tiga pertanyaan secara berurutan: apa yang menulis ulang kueri, apa yang menerimanya, dan proses mana yang memiliki soket pendengar. Setelah pemiliknya diketahui, kebijakan upstream punya tempat untuk tinggal.

Beri resolver kebijakan egress miliknya sendiri

Upstream khusus domain adalah alat paling bersih ketika hanya sebagian nama membutuhkan terowongan. dnsmasq menerima baris server yang dibatasi pada satu domain, dengan antarmuka atau alamat sumber opsional yang mengarahkan kueri keluar dari perangkat pilihan. Pengarahan itulah yang membuat percakapan kedua mengikuti VPN.

server=/corp.example/10.30.0.53@tun_work
log-queries

Domain, alamat, dan antarmuka di atas adalah pengganti untuk nilai Anda sendiri. Pemilihan domain dan kendali egress tetap menjadi keputusan terpisah: rute harus ada, alamat sumber harus diizinkan oleh resolver upstream, dan firewall harus mengizinkan jawabannya. Pengarahan antarmuka saja bukan fail-closed, karena terowongan yang lenyap dapat membuat resolver jatuh ke jalur lain. Jauhkan setiap cadangan publik dari ruang nama yang harus tetap privat.

Letakkan baris itu pada pemilik konfigurasi yang didukung router, bukan pada berkas hasil bangkitan, atau pemuatan ulang berikutnya menghapus perbaikannya.

Apa yang tidak dapat dipertahankan cache bersama

Satu penerus dengan satu cache melayani setiap klien LAN, dan itu meruntuhkan pembedaan yang dibutuhkan sebagian jaringan. Jika dua klien harus menyelesaikan nama yang sama secara berbeda, soket bersama tidak punya cara memulihkan klien mana yang bertanya. Kebijakan per klien harus hidup dalam instans resolver terpisah atau dalam fitur penerusan yang mempertahankan identitas.

Jawaban yang di-cache juga bukan bukti tentang jalur baru. Jawaban bisa datang dari memori sementara rute upstream tetap rusak.

Aturan port 53 tidak mengatakan apa pun tentang aplikasi yang berbicara DNS lewat HTTPS atau lewat TLS. Kueri itu tidak pernah mencapai pengalihan, jadi kebijakan yang dibangun hanya di atas port 53 menjelaskan sebagian dari lalu lintas dan sebaiknya didokumentasikan sebagai himpunan bagian.

Verifikasi percakapan kedua, bukan yang pertama

Uji dengan satu nama yang Anda kendalikan dan awasi kedua sisi. Tangkapan di sisi klien membuktikan kueri meninggalkan LAN; hanya sisi router yang membuktikan ke mana ia pergi selanjutnya.

sudo tcpdump -ni tun_work udp port 53
ip route get 10.30.0.53
dig +short corp.example @10.30.0.53

Kosongkan cache sebelum setiap percobaan, karena jawaban hangat menyembunyikan upstream yang rusak. Ulangi lewat TCP, lalu ulangi dengan terowongan dimatikan untuk melihat apa yang dilakukan resolver ketika jalur pilihannya hilang. Perilaku terakhir itulah yang menentukan apakah rancangannya fail-closed atau sekadar beruntung.