OpenVPN menghantar DNS, tetapi penyelesai anda mungkin tidak pernah melihatnya

Log klien menunjukkan pelayan DNS yang dihantar, terowong bersambung, dan nama dalaman masih tidak diselesaikan. Tiada apa yang rosak pada penghantaran itu sendiri. Pilihan itu tiba dan penyelesai sistem pengendalian tidak pernah menggunakannya, kerana pada kebanyakan klien Unix OpenVPN menyerahkan nilai itu dan membiarkan aplikasi kepada platform.

Gejalanya: log menunjukkan DNS dan nama masih gagal

OpenVPN dhcp-option membawa maklumat DNS dan domain, dan klien merekodkan apa yang diterimanya. Pada sesetengah pelaksanaan klien menggunakan tetapan itu secara dalaman; pada yang lain ia mengeksportnya untuk skrip integrasi atau perkhidmatan rangkaian. Baris log hanya menerangkan separuh pertama cerita. Separuh kedua berlaku di tempat yang tidak dikawal oleh klien. Di situlah kegagalan biasanya tinggal.

Itulah sebabnya terowong yang bersambung dan nama dalaman yang gagal begitu kerap wujud bersama. Nilai itu ada, penggunanya tiada atau salah dikonfigurasikan, dan penyelesai terus menggunakan pelayan awam yang digunakannya sebelum sambungan secara senyap.

Menerima bukan bermakna menggunakan

Klien boleh merekodkan nilai DNS yang dihantar sementara penyelesai sistem masih dimiliki oleh perkhidmatan lain. Pelayar juga mungkin mempunyai dasar DNS tersulitnya sendiri yang memintas penyelesai sistem sepenuhnya, yang menghasilkan situasi mengagumkan apabila satu aplikasi menyelesaikan nama dalaman dan yang lain tidak.

Semak integrasi yang disokong oleh pelaksanaan dan bukannya menganggap setiap klien Unix menulis semula fail yang sama. Andaian itulah sebabnya orang mengedit konfigurasi penyelesai yang tidak dibaca oleh apa-apa.

Cari pemilik penyelesai mengikut platform

Pada Windows, jadual dasar penyelesaian nama boleh mengarahkan akhiran tertentu ke pelayan tertentu, dan klien VPN boleh memasang peraturan di sana. Semak dasar itu, bukan hanya senarai DNS penyesuai. Pada Linux, NetworkManager atau systemd-resolved boleh memiliki konfigurasi itu, dan yang mana memiliki menentukan apa yang akan dikekalkan oleh sambungan semula.

Baca keadaan berkesan dengan alat yang benar-benar menjawab pertanyaan: resolvectl query internal.example.net pada hos systemd-resolved, atau setara platform. Kemudian bandingkan jawapan itu dengan pelayan DNS yang didakwa oleh log klien telah dihantar.

Elakkan menjalankan beberapa perkhidmatan yang menimpa tetapan penyelesai tanpa penyelarasan. Dua pemilik menghasilkan keputusan yang kelihatan berselang-seli, dan setiap sambungan semula kelihatan membaikinya atau merosakkannya secara rawak.

Skrip dan foreign_option

OpenVPN mengeksport pilihan yang dihantar kepada skrip melalui pemboleh ubah bernama foreign_option_N, dan skrip boleh menterjemahkannya kepada arahan penyelesai. Susunan itu ialah integrasi yang disokong, bukan tingkah laku automatik, dan ia mesti dipasang serta dipanggil pada klien.

Jika anda bergantung pada skrip, rekodkan pelaksanaan dan status keluarnya. Skrip yang berjalan tetapi gagal secara senyap meninggalkan gejala yang sama seperti tiada skrip, dan lebih sukar untuk diperhatikan kerana konfigurasi kelihatan lengkap. Semak output skrip, bukan fail skrip. Fail yang wujud bukanlah skrip yang telah berjalan.

Uji namanya, bukan lognya

Tanya hos name dalaman sahaja daripada klien selepas bersambung, kemudian tanya nama awam, kemudian semak pelayan mana yang menjawab. Dalam persediaan yang berfungsi kedua-dua jawapan datang dari tempat berbeza, dan kedua-duanya harus sepadan dengan reka bentuk.

Jika nama diselesaikan tetapi perkhidmatan gagal, teruskan ke penghalaan dan akses aplikasi dan bukannya menukar DNS lagi. Manual OpenVPN mendokumentasikan dhcp-option dan persekitaran skrip; gunakannya untuk mengesahkan apa yang dijangka digunakan oleh klien anda sebelum mengedit fail penyelesai yang lain.