OpenVPN menghantar pelayan DNS, tetapi Linux mengabaikannya

Pelayan DNS yang dihantar ada dalam log, terowong aktif, dan nama dalaman masih gagal. Tiada apa yang rosak pada penghantaran itu sendiri; tetapan itu tiba dan berhenti di situ. Pilihan DNS yang dihantar ialah mesej kepada klien, bukan arahan kepada penyelesai sistem pengendalian, dan penyerahan antara keduanya ialah tempat kebanyakan kes ini berakhir. Lima semakan, mengikut urutan, menemui penyerahan yang tidak berlaku.

Semakan satu: bagaimana sambungan bermula

Pemilik sambungan menentukan siapa yang boleh menggunakan tetapan penyelesai. Arahan openvpn terus dari shell tidak memiliki apa-apa selain prosesnya sendiri, manakala unit systemd, NetworkManager atau klien vendor masing-masing mempunyai caranya sendiri untuk menerbitkan DNS. Baca senarai proses dan nama unit sebelum menganggap mana-mana daripadanya.

Proses baris arahan bukan secara automatik sambungan NetworkManager, dan sambungan NetworkManager bukan secara automatik perkara yang menulis resolv.conf. Kedua-dua andaian itu menjelaskan kebanyakan jam yang terbuang dalam siasatan ini. Tanya komponen mana yang akan menerbitkan DNS untuk antara muka yang anda benar-benar lihat.

Catat pemiliknya sebelum meneruskan. Setiap semakan seterusnya bergantung padanya.

Semakan dua: apa yang sebenarnya dipegang pautan penyelesai

Pada hos systemd-resolved, resolvectl status menyenaraikan setiap pautan bersama pelayan DNS dan domainnya. Cari pautan terowong dan baca entrinya, dan jangan menganggap antara muka itu bernama tun0, kerana penomboran mengikut urutan penciptaan. Jika alamat yang dihantar tiada pada pautan, penyerahan yang gagal, bukan pertanyaan.

Jika alamat itu ada, soalan seterusnya ialah domain mana yang dituntut oleh pautan itu. Pautan tanpa senarai domain hanya menjawab nama yang ditanya secara langsung, dan itu jarang menjadi apa yang dikehendaki oleh penggunaan split-DNS. Alamat sahaja perlu tetapi tidak mencukupi.

Bandingkan nama pautan dalam output penyelesai dengan nama antara muka dalam log VPN sebelum membuat apa-apa kesimpulan. Ketidakpadanan di situ biasanya bermakna baris log itu datang daripada proses lain.

Semakan tiga: sama ada ruang nama memilih pautan itu

Penyelesai boleh memegang pelayan yang betul namun tidak dirujuk. Domain bagi setiap pautan menentukan pertanyaan mana pergi ke pautan mana, dan tanpa domain penghalaan ruang nama peribadi kembali kepada apa yang dikatakan pautan lalai. Itulah sebabnya resolvectl query untuk nama dalaman boleh berjaya sementara aplikasi masih gagal. Aplikasi mungkin menggunakan laluan penyelesai yang sama sekali berbeza.

Periksa penetapan domain, bukan hanya alamat pelayan. Domain yang ditulis sebagai ~corp.example ialah domain penghalaan, dan tilde mengubah cara nama dipadankan.

Jika aplikasi mempunyai penyelesai sendiri, uji dengan mekanisme yang sama yang digunakannya dan bukan dengan alat sistem. Alat pertanyaan yang memintas penyelesai sistem akan berjaya tanpa mengira keadaan pautan.

Semakan empat: satu pemilik, bukan dua

Jika NetworkManager sudah menguruskan VPN dan keadaan penyelesai, menambah skrip cangkuk yang tidak berkaitan mencipta penulis yang bersaing. Cangkuk yang disediakan pakej untuk systemd-resolved ialah integrasi yang disokong, dan ia menjangka kitaran hayat tertentu: script-security 2, laluan up, up-restart, laluan down dan down-pre. Pilihan itu membuatkan pendaftaran dan pembuangan berlaku pada saat yang betul dan bukan hanya pada sambungan pertama.

Gunakan laluan yang dipasang daripada pakej dan bukan laluan ilustratif yang disalin daripada panduan. Kebenaran juga penting, kerana cangkuk berjalan selepas keistimewaan diturunkan.

Menyunting skrip penyelesai distribusi untuk mengubah sasaran outputnya merekodkan penyelesaian sementara satu hos. Itu bukan pembaikan umum.

Semakan lima: hasil yang sama selepas menyambung semula

Sambung semula dan baca pautan itu sekali lagi. Pendaftaran yang muncul sekali dan hilang pada peralihan seterusnya ialah kegagalan yang menyebabkan seluruh senarai semak ini wujud. Uji selepas penggantungan, selepas sambungan semula paksa dan selepas perkhidmatan penyelesai dimulakan semula. Setiap peralihan menguji andaian susunan yang berbeza.

Hanya apabila kelima-lima semakan lulus semasa menyambung semula anda boleh mengatakan tetapan yang dihantar sedang digunakan. Apa-apa yang lebih awal hanyalah petikan sesaat daripada detik yang bertuah.