LXD mengekspos perangkat karakter host ke kontainer dengan menambahkan node perangkat, bukan dengan mengajari tamu membuatnya. Jika kontainer tidak memiliki /dev/net/tun, host mungkin punya perangkatnya dan tamu tetap tidak bisa membukanya. Entri unix-char adalah separuh jalur itu di sisi pengelola, dan sengaja lebih sempit daripada kontainer istimewa. Karena itu node host dan node kontainer layak diperiksa terpisah.

Mekanismenya cukup singkat untuk diingat: LXD menyelesaikan jalur host, membuat node yang sesuai di dalam instans, dan menambahkan perangkat ke cgroup perangkat kontainer. Setelah itu proses tamu memerlukan izin dan kemampuannya sendiri untuk memakai node itu untuk apa pun.

Apa yang sebenarnya diubah entri unix-char

Perangkat unix-char memberi tahu LXD untuk mengekspos satu perangkat karakter host pada jalur yang dipilih di dalam kontainer. Entri ini punya tiga bagian penting: label perangkat yang dipakai pengelola, jalur source di host, dan path yang dilihat tamu. Hanya dua yang terakhir menggambarkan perangkatnya sendiri. Salah ketik pada salah satunya menghasilkan node di lokasi yang tidak pernah dibuka klien.

Di host, perangkatnya biasanya /dev/net/tun. Di dalam kontainer Anda bisa mempertahankan jalur yang sama atau memilih yang lain, tetapi jalurnya harus cocok dengan yang diharapkan klien VPN. Mempertahankan /dev/net/tun menghindari masalah konfigurasi kedua, karena sebagian besar klien membuka jalur itu tanpa bertanya.

Pengelola menerapkan entri saat instans mulai atau saat perangkat dipasang panas. Ia tidak menyalin driver ke tamu dan tidak membuat antarmuka tunnel. Ia membuat node terlihat dan mengizinkan akses melalui grup kendali perangkat kontainer.

Deklarasikan perangkat di instans, bukan di dalam tamu

Tambahkan entri dari konteks administrasi LXD, dengan menyebut instans dan label yang bisa Anda kenali nanti. Untuk kontainer bernama vpnbox, perintahnya adalah:

lxc config device add vpnbox tun unix-char source=/dev/net/tun path=/dev/net/tun
lxc config device show vpnbox

Label tun bersifat lokal pada konfigurasi instans. Itu bukan nama antarmuka dan tidak harus cocok dengan apa pun di tamu. Jika profil sudah menyediakan perangkat yang sama, menambahkan entri kedua membuat konflik, bukan redundansi, jadi periksa dulu konfigurasi yang berlaku.

Menyunting berkas di dalam kontainer adalah lapisan yang salah. mknod dalam skrip awal bisa tampak berfungsi pada kontainer istimewa, lalu hilang saat dibuat ulang atau gagal pada kontainer yang kurang istimewa. Pengelola memiliki kumpulan perangkat instans; biarkan ia juga memiliki node-nya.

Sesuaikan kepemilikan dan mode dengan proses tamu

Entri unix-char dapat menetapkan uid, gid dan mode untuk node di dalam kontainer. Gunakan itu agar cocok dengan akun yang menjalankan klien VPN, alih-alih membuka perangkat untuk semua pengguna atau mengalihkan kontainer ke mode istimewa.

Keterlihatan tidak sama dengan izin. Node milik root dengan mode 600 terlihat oleh layanan yang berjalan sebagai pengguna tanpa hak istimewa dan tetap tidak dapat dibukanya. Periksa dulu akun tamu, lalu tetapkan kepemilikan ke akun itu, dan jaga mode tidak lebih lebar daripada yang dibutuhkan klien.

Prosesnya juga memerlukan kemampuan untuk mengonfigurasi antarmuka tunnel, biasanya CAP_NET_ADMIN di ruang nama jaringan kontainer. Meneruskan perangkat tidak memberikan kemampuan itu, dan memberikan kemampuan tidak menyediakan perangkatnya; keduanya persyaratan yang independen.

Ketahui apa yang tidak diberikan entri

Node yang terlihat bukan VPN yang berfungsi. Paket klien tetap harus dipasang, profil tetap harus valid, dan layanan tetap harus dimulai. Autentikasi, rute, dan DNS tetap menjadi tugas klien, dan kegagalan di sana bukan bukti bahwa entri perangkat salah.

systemd dapat menambahkan batasan lain. Unit dengan DeviceAllow atau kebijakan perangkat yang diperketat dapat menolak akses ke node yang disediakan pengelola kontainer. Periksa kebijakan perangkat unit ketika node ada tetapi layanan melaporkan galat izin, dan ubah kebijakan itu alih-alih memperlebar kontainer.

Pemasangan panas bersifat opsional dan eksplisit. Entri dengan required=false memerlukan jalur sumber dan dapat muncul atau hilang saat perangkat host berubah. Siklus hidup itu cocok untuk perangkat keras yang datang dan pergi; bagi perangkat TUN yang dibutuhkan VPN saat boot, entri opsional dapat membuat layanan mulai sebelum prasyaratnya ada.

Verifikasi keterlihatan, pembukaan, dan antarmuka dalam urutan itu

Pertama pastikan node di dalam kontainer yang dimaksud. Jalur, nomor mayor dan minor, serta kepemilikan harus cocok dengan perangkat host dan entri yang Anda tambahkan. Node yang hilang berarti pengelola tidak menerapkan entri, atau menerapkannya pada instans lain.

lxc exec vpnbox -- ls -l /dev/net/tun
lxc exec vpnbox -- sh -c 'test -c /dev/net/tun && echo char-device-ok'

Berikutnya pastikan akun layanan dapat membukanya. Uji singkat sebagai akun itu memisahkan masalah kepemilikan dari masalah layanan. Terakhir, jalankan klien dan pastikan antarmuka tunnel muncul; hanya langkah ketiga itu yang membuktikan seluruh jalur, karena dua langkah pertama bisa lolos sementara profil atau kemampuan klien masih salah.

Catat instans, label perangkat, sumber host, jalur tamu, dan akun pemilik saat perubahan disetujui. Kelima nilai itu yang harus dipertahankan oleh pembuatan ulang, migrasi, atau perubahan profil berikutnya, dan jauh lebih mudah dibandingkan daripada galat izin tanpa konteks.

Artikel terkait