OpenVPN mengirim server DNS, tetapi Linux mengabaikannya

Server DNS yang dikirim ada di log, terowongan aktif, dan nama internal masih gagal. Tidak ada yang rusak pada pengirimannya sendiri; pengaturannya tiba lalu berhenti di situ. Opsi DNS yang dikirim adalah pesan kepada klien, bukan instruksi kepada resolver sistem operasi, dan penyerahan di antara keduanya adalah tempat sebagian besar kasus ini berakhir. Lima pemeriksaan, secara berurutan, menemukan penyerahan yang tidak terjadi.

Pemeriksaan satu: bagaimana koneksi dimulai

Pemilik koneksi menentukan siapa yang dapat menerapkan pengaturan resolver. Perintah openvpn langsung dari shell tidak memiliki apa pun selain prosesnya sendiri, sedangkan unit systemd, NetworkManager, atau klien vendor masing-masing punya caranya sendiri untuk menerbitkan DNS. Baca daftar proses dan nama unit sebelum menganggap salah satunya.

Proses baris perintah tidak otomatis merupakan koneksi NetworkManager, dan koneksi NetworkManager tidak otomatis merupakan hal yang menulis resolv.conf. Kedua anggapan itu menjelaskan sebagian besar jam yang terbuang dalam penyelidikan ini. Tanyakan komponen mana yang akan menerbitkan DNS untuk antarmuka yang benar-benar Anda lihat.

Catat pemiliknya sebelum melanjutkan. Setiap pemeriksaan berikutnya bergantung padanya.

Pemeriksaan dua: apa yang sebenarnya dipegang tautan resolver

Pada host systemd-resolved, resolvectl status mencantumkan setiap tautan beserta server DNS dan domainnya. Temukan tautan terowongan dan baca entrinya, dan jangan menganggap antarmuka bernama tun0, karena penomoran mengikuti urutan pembuatan. Jika alamat yang dikirim tidak ada pada tautan, penyerahan yang gagal, bukan kuerinya.

Jika alamat ada, pertanyaan berikutnya adalah domain mana yang diklaim tautan itu. Tautan tanpa daftar domain hanya menjawab nama yang ditanyakan langsung kepadanya, dan itu jarang menjadi yang diinginkan penerapan split-DNS. Alamat saja perlu tetapi tidak cukup.

Bandingkan nama tautan pada keluaran resolver dengan nama antarmuka di log VPN sebelum menarik kesimpulan apa pun. Ketidakcocokan di sana biasanya berarti baris log itu berasal dari proses lain.

Pemeriksaan tiga: apakah ruang nama memilih tautan itu

Resolver dapat memegang server yang benar namun tetap tidak dikonsultasikan. Domain per tautan menentukan kueri mana pergi ke tautan mana, dan tanpa domain perutean ruang nama privat kembali ke apa yang dikatakan tautan bawaan. Itulah sebabnya resolvectl query untuk nama internal bisa berhasil sementara aplikasi tetap gagal. Aplikasi mungkin memakai jalur resolver yang sama sekali berbeda.

Periksa penetapan domain, bukan hanya alamat server. Domain yang ditulis sebagai ~corp.example adalah domain perutean, dan tilde mengubah cara nama dicocokkan.

Jika aplikasi punya resolver sendiri, uji dengan mekanisme yang sama yang dipakainya, bukan dengan alat sistem. Alat kueri yang melewati resolver sistem akan berhasil terlepas dari keadaan tautan.

Pemeriksaan empat: satu pemilik, bukan dua

Jika NetworkManager sudah mengelola VPN dan keadaan resolver, menambahkan skrip kait yang tidak terkait menciptakan penulis yang bersaing. Kait yang disediakan paket untuk systemd-resolved adalah integrasi yang didukung, dan ia mengharapkan siklus hidup tertentu: script-security 2, jalur up, up-restart, jalur down, dan down-pre. Opsi itu membuat pendaftaran dan penghapusan terjadi pada saat yang tepat, bukan hanya pada koneksi pertama.

Gunakan jalur terpasang dari paket, bukan jalur ilustratif yang disalin dari panduan. Izin juga penting, karena kait berjalan setelah hak istimewa diturunkan.

Menyunting skrip resolver distribusi untuk mengubah target keluarannya mencatat akal-akalan satu host. Itu bukan perbaikan umum.

Pemeriksaan lima: hasil yang sama setelah menyambung ulang

Sambung ulang dan baca lagi tautannya. Pendaftaran yang muncul sekali lalu hilang pada transisi berikutnya adalah kegagalan yang membuat seluruh daftar periksa ini ada. Uji setelah suspend, setelah penyambungan ulang paksa, dan setelah layanan resolver dimulai ulang. Setiap transisi menguji anggapan urutan yang berbeda.

Hanya bila kelima pemeriksaan lolos saat menyambung ulang Anda dapat mengatakan pengaturan yang dikirim sedang dipakai. Apa pun yang lebih awal hanyalah cuplikan sesaat dari momen yang beruntung.