Mengapa pertanyaan dnsmasq keluar dari VPN selepas ubah hala DNS

Klien LAN mencapai VPN-nya dengan betul namun pertanyaan DNS-nya masih muncul pada pautan atas yang salah. Ini bukan kebocoran dalam erti kata biasa; inilah yang berlaku apabila penghala berhenti memajukan pertanyaan dan menjawabnya sendiri. Pemintasan menulis semula destinasi ke soket tempatan, dan penyelesai kemudian membuka perbualan kedua yang tidak berkaitan dengan alamat sumbernya sendiri dan keputusan penghalaannya sendiri. Tanda yang dikenakan pada aliran klien menerangkan perbualan pertama dan sama sekali tidak menerangkan yang kedua.

Tanda tidak bergerak bersama pertanyaan

Tanda paket hidup pada entri conntrack dan pada paket yang sedang terbang. Peraturan REDIRECT menamatkan penerbangan itu: muatan diserahkan kepada soket tempatan, dan entri asal sudah selesai tugasnya. Apa yang meninggalkan penghala selepas itu ialah soket baharu yang dicipta oleh proses penyelesai, dengan alamat penghala itu sendiri sebagai sumber.

Sebab itulah laluan dasar yang berkunci pada alamat klien LAN tidak pernah sepadan dengan pertanyaan huluan. Soket baharu itu milik dnsmasq dan bukan milik klien, dan kernel menilai laluan untuk trafik penghala itu sendiri. Peraturan sumber, peraturan antara muka dan peraturan tanda semuanya melihat tuple yang berbeza. Menganggap tanda itu merambat ialah kesilapan paling biasa dalam persediaan ini, dan ia tidak kelihatan dalam tangkapan di sebelah klien.

Kedua-dua perbualan memang berkongsi nama dan masa, dan itulah yang membuatkannya kelihatan seperti satu aliran apabila anda meninjau tangkapan dengan pantas.

Di mana pemajuan menjadi penyelesaian tempatan

Mulakan dengan mencari sama ada port 53 diubah hala, diterjemah ke hos lain, atau dibiarkan begitu sahaja, kerana ketiga-tiga kes berkelakuan berbeza. Ubah hala ke port tempatan menamatkan pemajuan, manakala terjemahan ke mesin lain mengekalkan paket bergerak dan mengekalkan tuple klien bermakna.

Lihat kedua-dua protokol. Penyelesai yang boleh dicapai melalui UDP dan TCP akan diuji pada kedua-duanya, dan set peraturan yang hanya meliputi UDP meninggalkan lubang senyap untuk jawapan besar. Peraturan yang dijana oleh pengurus konfigurasi penghala itu sendiri juga dikira, dan menyunting fail yang dijana biasanya kalah kepada pemuatan semula 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 soalan mengikut urutan: apa yang menulis semula pertanyaan, apa yang menerimanya, dan proses mana yang memiliki soket mendengar. Setelah pemiliknya diketahui, dasar huluan ada tempat untuk tinggal.

Beri penyelesai dasar egressnya sendiri

Huluan khusus domain ialah alat paling bersih apabila hanya sesetengah nama memerlukan terowong. dnsmasq menerima baris server yang terhad kepada domain, dengan antara muka atau alamat sumber pilihan yang mengarahkan pertanyaan keluar dari peranti yang dipilih. Pengarahan itulah yang membuatkan perbualan kedua mengikut VPN.

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

Domain, alamat dan antara muka di atas ialah pemegang tempat untuk nilai anda sendiri. Pemilihan domain dan kawalan egress kekal sebagai keputusan berasingan: laluan mesti wujud, alamat sumber mesti dibenarkan oleh penyelesai huluan, dan tembok api mesti membenarkan jawapannya. Pengarahan antara muka semata-mata bukan fail-closed, kerana terowong yang lenyap boleh membiarkan penyelesai jatuh ke laluan lain. Jauhkan sebarang sandaran awam daripada ruang nama yang mesti kekal peribadi.

Letakkan baris itu pada pemilik konfigurasi yang disokong penghala dan bukan dalam fail yang dijana, jika tidak pemuatan semula berikutnya memadam pembetulan itu.

Apa yang cache kongsi tidak dapat mengekalkan

Satu penghantar dengan satu cache melayani setiap klien LAN, dan itu meruntuhkan perbezaan yang diperlukan oleh sesetengah rangkaian. Jika dua klien mesti menyelesaikan nama yang sama secara berbeza, soket kongsi tiada cara untuk mendapatkan semula klien mana yang bertanya. Dasar setiap klien mesti hidup dalam instans penyelesai berasingan atau dalam ciri pemajuan yang mengekalkan identiti.

Jawapan yang dicache juga bukan bukti tentang laluan baharu. Jawapan boleh datang dari ingatan sementara laluan huluan kekal rosak.

Peraturan port 53 tidak mengatakan apa-apa tentang aplikasi yang bertutur DNS melalui HTTPS atau melalui TLS. Pertanyaan itu tidak pernah sampai ke ubah hala, jadi dasar yang dibina hanya atas port 53 menerangkan subset trafik dan wajar didokumenkan sebagai subset.

Sahkan perbualan kedua, bukan yang pertama

Uji dengan satu nama yang anda kawal dan perhatikan kedua-dua belah. Tangkapan di sebelah klien membuktikan pertanyaan meninggalkan LAN; hanya sebelah penghala membuktikan ke mana ia pergi seterusnya.

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 percubaan, kerana jawapan hangat menyembunyikan huluan yang rosak. Ulang melalui TCP, kemudian ulang dengan terowong dimatikan untuk melihat apa yang penyelesai lakukan apabila laluan pilihannya hilang. Tingkah laku terakhir itulah yang menentukan sama ada reka bentuk itu fail-closed atau hanya bertuah.