Imej kontena boleh membawa setiap binari dan fail konfigurasi OpenVPN yang diperlukan dan masih gagal pada panggilan rangkaian pertama. Ralat menyebut /dev/net/tun kerana aplikasi meminta antara muka TUN daripada kernel dan kontena tidak mempunyai nod peranti mahupun keupayaan untuk menciptanya. Itu dua kebenaran berasingan, dan membaiki satu membiarkan yang lain tepat di tempatnya.

Mengasingkan kedua-duanya memerlukan satu arahan bagi setiap satu. Mesej ralat selepas itu memberitahu anda di sempadan mana anda sebenarnya berdiri.

Nod peranti dan keupayaan ialah dua pintu

Nod peranti ialah objek sistem fail, jadi kontena perlu melihatnya dalam ruang nama lekapannya sendiri. Keupayaan ialah kebenaran, jadi proses memerlukan CAP_NET_ADMIN dalam ruang nama tempat antara muka akan dicipta. Menghantar peranti tanpa keupayaan memberi anda nod yang terbuka dan ioctl yang gagal. Memberi keupayaan tanpa peranti menjadikan aplikasi tidak dapat membuka apa-apa, sebab itulah kedua-duanya biasanya muncul bersama dalam contoh.

Tetapan devices Docker memetakan peranti hos ke dalam kontena, manakala cap_add melaras set keupayaan. Bind mount bagi laluan yang sama meletakkan fail dalam pandangan tanpa menggunakan semantik akses peranti.

Hasilkan semula di luar fail Compose

Sebelum menyunting perkhidmatan, pastikan hos mempunyai peranti itu dan kontena kosong boleh mencipta antara muka. Arahan di bawah sengaja minimum, dan satu-satunya tujuannya ialah mengasingkan masalah hos daripada masalah compose. Jika ia gagal, tiada perubahan compose akan membantu.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun:/dev/net/tun alpine sh -c 'apk add -q iproute2 && ip tuntap add dev tun9 mode tun && ip link show tun9'

Nod yang tiada pada hos bermakna modul tun tidak tersedia, yang merupakan pembetulan di pihak hos dan bukan kontena. Nod yang wujud tetapi tidak dapat dibuka dalam kontena menunjukkan akses peranti, dan mesejnya akan menyebut permission denied dan bukan no such file. Urutan kedua-dua kegagalan itu ialah keseluruhan diagnosis. Catat yang mana anda lihat sebelum menukar sebarang bendera.

Ralat selepas TUN ialah masalah yang berbeza

Sebaik sahaja antara muka muncul, kegagalan seterusnya mempunyai pemilik yang berbeza. Ralat pengesahan bermaksud terowong sampai ke pelayan dan kelayakan ditolak, jadi perubahan keupayaan tidak akan membantu. Terowong yang terbentuk sementara aplikasi masih gagal menunjukkan laluan, penghantaran, penyelesaian DNS dalam kontena atau susun atur rangkaian kontena itu sendiri. Setiap satu daripadanya ialah soalan rangkaian biasa yang tidak dapat dijawab oleh kebenaran TUN. Mengulangi ujian asal selepas setiap perubahan menghalang kegagalan daripada bercantum menjadi satu tanggapan.

Menyalin setiap tetapan daripada contoh yang berfungsi ialah cara pembetulan minimum menjadi definisi perkhidmatan yang tidak boleh dibaca. Bawa hanya yang diperlukan oleh penggunaan ini dan catat mengapa setiap satu ada.

Sahkan antara muka di dalam kontena

Periksa antara muka dan set keupayaan dari dalam kontena yang berjalan dan bukan dari hos. Arahan di bawah menunjukkan nod peranti, senarai keupayaan dan sama ada antara muka boleh dicipta langsung. Jalankannya dalam kontena yang sama yang menjalankan klien, dan pasang alat jika imej minimum.

ls -l /dev/net/tun
capsh --print | grep -i net_admin
ip link add dev tun9 type tun && ip link show tun9

Keupayaan yang hadir dalam bounding set tetapi tiada dalam effective set berkelakuan berbeza daripada yang tidak pernah diberikan, dan capsh menunjukkan kedua-duanya. Jika nod wujud dan keupayaan ada sementara penciptaan masih gagal, runtime sedang mengenakan sesuatu yang lain, seperti profil seccomp atau dasar AppArmor yang mengehadkan operasi. Itu sempadan ketiga, didokumenkan oleh runtime dan bukan oleh aplikasi.

Catat bendera kontena, imej dan ralat tepat daripada setiap percubaan. Orang seterusnya yang membaca nota itu boleh mengetahui pintu mana yang tertutup tanpa mengulangi seluruh siasatan.

Artikel berkaitan