Adakah DNS VPN Anda Benar-Benar Digunakan? Tangkap Port 53 dan Lihat

Tanya kebanyakan orang apa yang klien VPN lakukan dengan DNS dan mereka akan berkata ia menetapkan penyelesai, jadi pertanyaan bergerak di dalam terowong. Tolakan itu nyata; andaian bahawa ia menjadi pertanyaan tidak. Antara pilihan yang ditolak dan paket di wayar ada tiga peringkat, dan setiap satu gagal secara berasingan dengan cara yang semuanya kelihatan seperti pelayan DNS rosak. Itulah sebabnya halaman ujian kebocoran dan pelayar yang berfungsi boleh berselisih faham tentang mesin yang sama pada saat yang sama.

Pilihan yang ditolak bukan pertanyaan

Peringkat pertama ialah pelayan menawarkan tetapan, contohnya pilihan DNS yang ditolak yang menamakan penyelesai di dalam terowong. Peringkat kedua ialah klien menggunakan tetapan itu pada antara muka. Peringkat ketiga ialah aplikasi benar-benar menghantar pertanyaan ke alamat itu. Kegagalan pada peringkat kedua membiarkan pilihan itu kelihatan dalam log sambungan sementara senarai penyelesai kekal tidak berubah, dan kegagalan pada peringkat ketiga membiarkan senarai penyelesai yang betul sepenuhnya tidak digunakan.

Kebanyakan penyelesaian masalah menggabungkan ketiga-tiganya menjadi satu dan menyalahkan pelayan VPN, yang biasanya satu-satunya pihak yang boleh membuktikan ia telah memainkan peranannya. Baca sebaliknya keadaan penyelesai sebenar klien, kemudian tonton satu pertanyaan keluar. Kedua-dua pemerhatian itu memisahkan konfigurasi daripada penghalaan dan daripada dasar, dan ia mengambil masa kira-kira lima minit. Simpan tangkapan itu, kerana jurutera seterusnya mahu keadaan sebelum dan selepas, bukan penerangannya.

Periksa apa yang sebenarnya dipegang antara muka

Di Linux penyelesai sistem boleh jadi fail biasa, NetworkManager atau systemd-resolved, dan yang mana antara itu memilikinya menentukan di mana pelayan yang ditolak mendarat. Proses OpenVPN baris arahan tidak mengemas kini penyelesai sistem dengan sendirinya, jadi integrasi yang didokumenkan ialah skrip up/down atau pengurus sambungan yang sudah tahu cara menggunakan tetapan itu. Menjalankan kedua-duanya ialah cara cekap untuk mencipta perlumbaan.

resolvectl status
cat /etc/resolv.conf

Di Windows senarainya adalah bagi setiap penyesuai, jadi penyesuai terowong boleh memegang pelayan dalaman sementara penyesuai fizikal menyimpan yang setempat dan menang bagi sesetengah nama. Bandingkan kedua-dua penyesuai dan bukan yang anda anggap aktif.

Ikuti satu pertanyaan keluar dari mesin

Tangkap kedua-dua antara muka serentak, kemudian selesaikan satu nama yang sepatutnya menggunakan penyelesai dalaman. Pasangan tangkapan itu menjawab apa yang tiada output konfigurasi boleh jawab.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

Pertanyaan yang muncul pada antara muka fizikal dan tidak pernah dalam terowong bermakna klien memilih penyelesai yang salah. Pertanyaan yang tidak muncul pada mana-mana daripada keduanya bermakna aplikasi menjawab dari cache, bertanya kepada stub yang mendengar pada loopback, atau menggunakan penyelesai tersulit yang trafiknya tidak pernah muncul sebagai port 53. Tangkap juga jawapan, bukan hanya pertanyaan, kerana pertanyaan yang keluar melalui terowong dengan jawapan dari alamat awam ialah kerosakan berbeza daripada tiada jawapan yang tiba.

Tembok api yang hanya menerima DNS sendiri

Klien komersial kadangkala memasang rantai penapis mereka sendiri. Satu corak yang didokumenkan membenarkan DNS ke penyelesai milik klien sendiri dan membuang semua baki trafik UDP port 53 yang cuba meninggalkan antara muka bukan loopback, termasuk trafik yang pengguna halakan dengan sengaja ke tempat lain. Pertanyaan daemon hilang tanpa jejak, yang dibaca sebagai kegagalan penyelesai dan bukan penapis.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Jika peraturan buang dinilai sebelum pengecualian anda, peraturan yang ditambah di hujung tidak pernah dicapai, jadi masukkan di kedudukan pertama dan hadkan destinasi kepada penyelesai yang benar-benar anda maksudkan.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Pengecualian itu bersifat diagnostik dan bukan dasar. Jika peraturan vendor memang disengajakan, pembaikan yang disokong ialah mengkonfigurasi klien untuk membenarkan penyelesai itu dan merekodkan keputusan, kerana peraturan yang dimasukkan tidak akan bertahan selepas peningkatan klien seterusnya.

Mengapa halaman kebocoran membuktikan kurang daripada yang kelihatan

Apa yang ditunjukkan halaman ujian kebocoran ialah penyelesai yang bercakap dengan pengendali ujian, bukan yang dirujuk oleh mesin anda. Pemaju semula setempat yang membuat rekursi ke luar meletakkan alamat keluarnya sendiri pada halaman itu, dan pertanyaan tersulit boleh membiarkan halaman itu kosong sepenuhnya. Kedua-dua hasil dibaca salah, satu sebagai kebocoran dan satu lagi sebagai jaminan, dan tiada satu pun bacaan itu berpunca daripada pemerhatian.

Bukti yang boleh dipertahankan ialah tangkapan: antara muka, alamat destinasi, jawapan dan cap masa. Ambil satu sebelum terowong naik dan satu selepasnya, dan bandingkan keduanya pada kali seterusnya sesuatu nama gagal. Pasangan itu juga memberitahu orang seterusnya sama ada kerosakan itu pada penyelesaian, penghalaan atau dasar akses penyelesai itu sendiri.