Apakah DNS VPN Anda Benar-Benar Dipakai? Tangkap Port 53 dan Lihat

Tanyakan kepada kebanyakan orang apa yang dilakukan klien VPN dengan DNS dan mereka akan berkata klien itu menyetel resolver, sehingga kueri berjalan di dalam terowongan. Dorongan itu nyata; anggapan bahwa ia menjadi kueri tidak. Di antara opsi yang didorong dan paket di kabel ada tiga tahap, dan masing-masing gagal secara mandiri dengan cara yang semuanya tampak seperti server DNS rusak. Itulah sebabnya halaman uji kebocoran dan peramban yang bekerja dapat berbeda pendapat tentang mesin yang sama pada saat yang sama.

Opsi yang didorong bukanlah kueri

Tahap pertama adalah server menawarkan pengaturan, misalnya opsi DNS yang didorong dan menyebut resolver di dalam terowongan. Tahap kedua adalah klien menerapkan pengaturan itu ke antarmuka. Tahap ketiga adalah aplikasi benar-benar mengirim kueri ke alamat itu. Kegagalan pada tahap kedua membuat opsi tetap terlihat di log koneksi sementara daftar resolver tidak berubah, dan kegagalan pada tahap ketiga membuat daftar resolver yang sepenuhnya benar tidak terpakai.

Sebagian besar pemecahan masalah melebur ketiganya menjadi satu dan menyalahkan server VPN, yang biasanya satu-satunya pihak yang dapat membuktikan bahwa ia menjalankan bagiannya. Bacalah keadaan resolver klien yang sebenarnya, lalu saksikan satu kueri keluar. Kedua pengamatan itu memisahkan konfigurasi dari perutean dan dari kebijakan, dan biayanya sekitar lima menit. Simpan tangkapannya, karena insinyur berikutnya ingin keadaan sebelum dan sesudah, bukan deskripsinya.

Periksa apa yang sebenarnya dipegang antarmuka

Di Linux resolver sistem bisa berupa berkas biasa, NetworkManager, atau systemd-resolved, dan mana di antaranya yang memilikinya menentukan ke mana server yang didorong mendarat. Proses OpenVPN di baris perintah tidak memperbarui resolver sistem sendirinya, jadi integrasi yang didokumentasikan adalah skrip up/down atau manajer koneksi yang sudah tahu cara menerapkan pengaturannya. Menjalankan keduanya adalah cara efisien untuk menciptakan perlombaan.

resolvectl status
cat /etc/resolv.conf

Di Windows daftarnya per adaptor, jadi adaptor terowongan dapat memegang server internal sementara adaptor fisik menyimpan yang lokal dan menang untuk sebagian nama. Bandingkan kedua adaptor alih-alih yang Anda anggap aktif.

Ikuti satu kueri keluar dari mesin

Tangkap kedua antarmuka secara bersamaan, lalu resolusi satu nama yang seharusnya memakai resolver internal. Pasangan tangkapan itu menjawab apa yang tidak dapat dijawab keluaran konfigurasi mana pun.

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

Kueri yang muncul di antarmuka fisik dan tidak pernah di terowongan berarti klien memilih resolver yang salah. Kueri yang tidak muncul di keduanya berarti aplikasi menjawab dari singgahan, bertanya ke stub yang mendengarkan di loopback, atau memakai resolver terenkripsi yang lalu lintasnya tidak pernah muncul sebagai port 53. Tangkap juga jawaban, bukan hanya kueri, karena kueri yang keluar lewat terowongan dengan jawaban dari alamat publik adalah gangguan yang berbeda dari jawaban yang tidak kunjung tiba.

Firewall yang hanya menerima DNS-nya sendiri

Klien komersial kadang memasang rantai penyaringnya sendiri. Satu pola yang didokumentasikan mengizinkan DNS ke resolver milik klien dan membuang semua sisa lalu lintas UDP port 53 yang mencoba meninggalkan antarmuka non-loopback, termasuk lalu lintas yang sengaja dirutekan pengguna ke tempat lain. Kueri daemon lenyap tanpa jejak, yang terbaca sebagai kegagalan resolver alih-alih penyaring.

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

Jika aturan pembuangan dievaluasi sebelum pengecualian Anda, aturan yang ditambahkan di akhir tidak pernah tercapai, jadi sisipkan di posisi pertama dan batasi tujuan pada resolver yang benar-benar Anda maksud.

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

Pengecualian itu bersifat diagnostik, bukan kebijakan. Jika aturan vendor memang disengaja, perbaikan yang didukung adalah mengonfigurasi klien agar mengizinkan resolver tersebut dan mencatat keputusannya, karena aturan yang disisipkan tidak akan bertahan setelah pemutakhiran klien berikutnya.

Mengapa halaman kebocoran membuktikan lebih sedikit dari yang tampak

Apa yang ditampilkan halaman uji kebocoran adalah resolver yang berbicara dengan operator uji, bukan yang dikonsultasikan mesin Anda. Penerus lokal yang melakukan rekursi ke luar menaruh alamat keluarnya sendiri di halaman itu, dan kueri terenkripsi dapat membuat halaman itu kosong sama sekali. Kedua hasil dibaca keliru, yang satu sebagai kebocoran dan yang lain sebagai jaminan, dan tidak ada dari kedua pembacaan itu yang mengikuti dari pengamatan.

Bukti yang dapat dipertahankan adalah tangkapannya: antarmuka, alamat tujuan, jawaban, dan stempel waktu. Ambil satu sebelum terowongan naik dan satu sesudahnya, lalu bandingkan keduanya saat sebuah nama gagal berikutnya. Pasangan itu juga memberi tahu orang berikutnya apakah gangguannya ada pada resolusi, perutean, atau kebijakan akses resolver itu sendiri.