OpenVPN mengirim DNS, tetapi resolver Anda mungkin tidak pernah melihatnya

Log klien menampilkan server DNS yang dikirim, terowongan terhubung, dan nama internal tetap tidak terurai. Tidak ada yang rusak pada pengirimannya sendiri. Opsi itu tiba dan resolver sistem operasi tidak pernah memakainya, karena pada sebagian besar klien Unix OpenVPN menyerahkan nilainya dan membiarkan aplikasinya kepada platform.

Gejalanya: log menampilkan DNS dan nama tetap gagal

OpenVPN dhcp-option membawa informasi DNS dan domain, dan klien mencatat apa yang diterimanya. Pada beberapa implementasi klien menerapkan pengaturan itu secara internal; pada yang lain klien mengekspornya agar dipakai skrip integrasi atau layanan jaringan. Baris log hanya menggambarkan paruh pertama cerita. Paruh kedua terjadi di tempat yang tidak dikendalikan klien. Di sanalah kegagalan biasanya bersemayam.

Itulah sebabnya terowongan yang terhubung dan nama internal yang gagal begitu sering muncul bersamaan. Nilainya ada, pemakainya tidak ada atau salah konfigurasi, dan resolver diam-diam tetap memakai server publik yang dipakainya sebelum koneksi.

Menerima bukan berarti menerapkan

Klien dapat mencatat nilai DNS yang dikirim sementara resolver sistem tetap dimiliki layanan lain. Peramban juga dapat memiliki kebijakan DNS terenkripsi sendiri yang sepenuhnya melewati resolver sistem, yang menghasilkan situasi mengesankan ketika satu aplikasi mengurai nama internal dan yang lain tidak.

Periksa integrasi yang didukung implementasi alih-alih mengasumsikan setiap klien Unix menulis ulang berkas yang sama. Asumsi itulah alasan orang menyunting konfigurasi resolver yang tidak dibaca apa pun.

Temukan pemilik resolver per platform

Di Windows, tabel kebijakan resolusi nama dapat mengarahkan sufiks tertentu ke server tertentu, dan klien VPN dapat memasang aturan di sana. Periksa kebijakannya, bukan hanya daftar DNS adaptor. Di Linux, NetworkManager atau systemd-resolved dapat memiliki konfigurasinya, dan mana yang memilikinya menentukan apa yang dipertahankan saat menyambung ulang.

Baca keadaan efektif dengan alat yang benar-benar menjawab kueri: resolvectl query internal.example.net pada hos systemd-resolved, atau padanan platformnya. Lalu bandingkan jawaban itu dengan server DNS yang diklaim log klien telah dikirim.

Hindari menjalankan beberapa layanan yang menimpa pengaturan resolver tanpa koordinasi. Dua pemilik menghasilkan hasil yang tampak berselang-seling, dan setiap penyambungan ulang tampak memperbaiki atau merusaknya secara acak.

Skrip dan foreign_option

OpenVPN mengekspor opsi yang dikirim ke skrip melalui variabel bernama foreign_option_N, dan skrip dapat menerjemahkannya menjadi perintah resolver. Susunan itu adalah integrasi yang didukung, bukan perilaku otomatis, dan harus dipasang serta dipanggil di klien.

Jika Anda bergantung pada skrip, catat eksekusi dan status keluarnya. Skrip yang berjalan tetapi gagal secara diam-diam meninggalkan gejala yang sama seperti tidak ada skrip, dan lebih sulit disadari karena konfigurasinya tampak lengkap. Periksa keluaran skrip, bukan berkas skrip. Berkas yang ada bukanlah skrip yang berjalan.

Uji namanya, bukan lognya

Kueri nama hos khusus internal dari klien setelah terhubung, lalu kueri nama publik, lalu periksa server mana yang menjawab. Dalam penyiapan yang bekerja, kedua jawaban datang dari tempat berbeda, dan keduanya harus sesuai dengan rancangan.

Jika nama terurai tetapi layanan gagal, lanjutkan ke perutean dan akses aplikasi alih-alih mengubah DNS lagi. Panduan OpenVPN mendokumentasikan dhcp-option dan lingkungan skrip; gunakan untuk memastikan apa yang diharapkan diterapkan klien Anda sebelum menyunting berkas resolver lain.