Laporan DNS VPN: apa yang perlu disertakan agar dapat direproduksi

«DNS rusak» adalah kesimpulan, dan bukan kesimpulan yang bisa ditindaklanjuti seorang penolong. Bagian berguna dari laporan adalah bentuk kegagalannya: nama mana, melalui resolver mana, dengan respons apa. Tiga detail mengubah keluhan menjadi sesuatu yang dapat direproduksi, dan ketiganya aman dibagikan setelah bagian pribadi diganti namanya. Berikut adalah minimum yang dibutuhkan laporan DNS VPN sebelum siapa pun dapat membantu.

Kategori nama, bukan putusan

Mulailah dari namanya sendiri dan klasifikasikan: publik, internal, pendek, sepenuhnya memenuhi syarat, atau dilayani oleh satu sufiks tertentu. Nama internal yang gagal sementara nama publik ter-resolve menunjukkan pemilihan resolver, bukan keterjangkauan. Jika semua nama gagal, itu menunjukkan jalur ke resolver, yang merupakan penyelidikan berbeda dengan bukti berbeda. Kategori membawa diagnosisnya, dan string persisnya dapat disamarkan.

Katakan apakah kegagalan memerlukan tunnel aktif, atau terjadi setelahnya terputus. Nama yang hanya rusak saat VPN aktif mengimplikasikan konfigurasi per tautan, sedangkan yang rusak setelah terputus mengimplikasikan keadaan sisa. Laporan biasanya menghilangkan ini lalu bertanya-tanya mengapa saran pertama tidak membantu.

Catat jalur resolver

Kueri yang dikirim ke server yang dipilih secara eksplisit dan pencarian biasa sebuah aplikasi adalah eksperimen yang berbeda. Sebutkan mana yang menghasilkan kegagalan, karena kueri manual ke server yang berfungsi hanya membuktikan bahwa server itu berfungsi. Perintah di bawah ini memisahkan jalur sistem dari pertanyaan langsung.

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

Output status menyebut server per tautan dan domain perutean, yaitu tempat split DNS diputuskan. Panggilan getent mengikuti jalur yang sama dengan aplikasi, termasuk urutan nsswitch. Kueri langsung melewati keduanya dan menguji satu server secara terisolasi. Laporkan mana dari ketiganya yang gagal dan mana yang berhasil, dan pembaca tidak perlu lagi menebak jalurnya.

Sebutkan perbandingan yang terkendali

Ubah satu variabel dan katakan apa yang berubah. Nama publik ter-resolve sementara nama internal gagal adalah masalah pemilihan; setiap nama kehabisan waktu adalah masalah jalur; dan nama privat yang ter-resolve ke alamat publik adalah kebocoran ke resolver yang salah. Dua dari tiga hal itu tidak ada hubungannya dengan apakah tunnel aktif. Laporan yang mengklaim semua kueri rusak biasanya memuat perbandingan yang tidak pernah dijalankan.

Pisahkan resolusi dari pengiriman. Ketika nama ter-resolve dan situs tetap gagal, tahap DNS berhasil dan laporan harus mengatakannya, karena langkah berikutnya adalah rute atau listener, bukan resolver. Satu pembedaan itu lebih sering menghemat satu putaran pertanyaan daripada kutipan log mana pun.

Rahasiakan ruang nama, pertahankan hubungan

Nama internal dapat diganti asalkan penggantinya mempertahankan struktur. Petakan setiap server dan sufiks yang berbeda ke label stabil, dan simpan pemetaan itu di luar salinan bersama. Mengganti setiap host internal dengan placeholder yang sama justru menghancurkan bukti yang dibutuhkan laporan, karena pembaca tidak lagi dapat melihat bahwa satu sufiks ter-resolve dan yang lain tidak. Aturan yang sama berlaku untuk alamat: pertahankan hubungan prefiks dan ubah bit host jika kebijakan mensyaratkannya.

Kirim catatan melalui saluran yang terverifikasi dan hilangkan apa yang tidak pernah dibutuhkan diagnosis. Kata sandi, kunci privat, dan nama perusahaan yang tidak terkait bukan bagian dari pertanyaan DNS. Yang dibutuhkan pembaca adalah kategori kegagalan, jalur resolver, kesalahan persisnya, dan satu perbandingan yang Anda jalankan.