Permulaan pertama gagal dengan mesej tentang /dev/net/tun atau peranti TUN/TAP yang tidak boleh dibuka. Sijil belum dibaca lagi, jadi tiada apa dalam profil yang patut dipersalahkan. Daemon meminta kernel objek yang guest ini tidak ada.

Objek itu ialah peranti aksara yang disokong oleh modul tun. Sama ada anda boleh menciptanya bergantung pada siapa yang memiliki kernel.

Apa yang daemon minta daripada kernel

OpenVPN membuka /dev/net/tun dan meminta pemacu satu antara muka. Pemacu itu ialah modul tun, dan nod peranti ialah pemegang yang digunakan oleh ruang pengguna untuk mencapainya. Jika modul tidak dimuatkan, nod mungkin tiada atau pembukaan mungkin gagal. Kedua-dua keadaan tidak dibaiki dengan menyunting server.conf.

Baca ralat ini dahulu sebagai soalan tentang platform. Ralat konfigurasi muncul selepas peranti dibuka, bukan sebelum itu.

VM atau guest yang berkongsi kernel

Pada KVM, Xen atau mesin maya penuh yang lain, anda mengawal kernel. Anda boleh memuatkan modul dan mencipta nod. Pada OpenVZ, Virtuozzo atau kontena gaya LXC, guest berkongsi kernel hos, jadi root di dalamnya tidak boleh memuatkan modul yang hos tidak muatkan.

Kegagalan yang sama oleh itu mempunyai dua pemilik yang sangat berbeza. Dalam kes pertama anda boleh membaikinya dari dalam instans. Dalam kes kedua anda meminta hos, atau penyedia, mendedahkan sesuatu.

Jalankan ls -l /dev/net/tun, lsmod | grep tun dan ip -brief link show sebelum memutuskan kes mana anda berada.

Pada VM, muatkan modul semasa but

Pada mesin maya, modprobe tun biasanya mencipta nod peranti. Sahkan ia muncul, kemudian kekalkan pemuatan melalui konfigurasi modul pengedaran dan bukannya bergantung pada arahan yang ditaip sekali. Nod yang hilang selepas but semula menjadi tiket yang sama bulan depan.

Periksa juga sama ada kernel yang anda butkan mempunyai modul itu sama sekali. Kernel vendor yang dipangkas mungkin tidak memilikinya.

Jika nod wujud tetapi pembukaan masih gagal, kebenaran dan nombor major/minor peranti ialah syak seterusnya. Itu pembaikan setempat, bukan permintaan kepada penyedia.

Dalam kontena, peranti dimiliki oleh hos

Dalam kontena, peranti dan keupayaan ialah dua keperluan berasingan. Runtime mesti melalukan /dev/net/tun, dan kontena memerlukan keupayaan rangkaian untuk mencipta antara muka. Runtime tanpa root yang tidak memberikan kedua-duanya akan terus menghasilkan ralat pembukaan yang sama walau bagaimana profil ditulis. Banyak hos OpenVZ menyediakan togol TUN/TAP dalam panel pelanggan, dan menghidupkannya serta but semula selalunya keseluruhan penyelesaiannya.

Tanya penyedia dua soalan tepat: adakah modul tun dimuatkan pada hos, dan adakah peranti tersedia di dalam instans ini? Tiket yang kabur mendapat jawapan yang kabur.

Mengapa membina semula modul jarang membantu

Membina modul di dalam guest jarang membantu. Pengkompilan memerlukan konfigurasi kernel yang betul-betul berjalan, dan /proc/config.gz adalah pilihan dan selalunya tiada pada imej minimum. Modul yang berfungsi pun tidak boleh dimasukkan ke dalam kernel yang tidak dimiliki oleh kontena.

Selepas peranti muncul, mulakan semula perkhidmatan dan sahkan antara muka sebelum menguji trafik. Melihat tun0 menunjukkan daemon telah membuka peranti. Ia belum mengatakan apa-apa tentang penghantaran, peraturan tembok api atau laluan yang diterima pelanggan.

Itu soalan berasingan dengan bukti berasingan. Peranti yang tiada ialah kegagalan prasyarat; terowong yang wujud tetapi tidak membawa apa-apa ialah kegagalan dasar.

Artikel berkaitan