Image kontainer dapat membawa setiap biner dan berkas konfigurasi OpenVPN yang mereka butuhkan dan tetap gagal pada panggilan jaringan pertama. Kesalahan menyebut /dev/net/tun karena aplikasi meminta antarmuka TUN kepada kernel dan kontainer tidak memiliki simpul perangkat maupun kemampuan untuk membuatnya. Itu dua izin terpisah, dan memperbaiki yang satu membiarkan yang lain persis di tempatnya.

Memisahkan keduanya membutuhkan satu perintah untuk masing-masing. Pesan kesalahan sesudahnya memberi tahu Anda di batas mana Anda sebenarnya berdiri.

Simpul perangkat dan kemampuan adalah dua pintu

Simpul perangkat adalah objek sistem berkas, jadi kontainer perlu melihatnya di ruang nama pemasangannya sendiri. Kemampuan adalah izin, jadi proses membutuhkan CAP_NET_ADMIN di ruang nama tempat antarmuka akan dibuat. Meneruskan perangkat tanpa kemampuan memberi Anda simpul yang terbuka dan ioctl yang gagal. Memberikan kemampuan tanpa perangkat membuat aplikasi tidak dapat membuka apa pun, itulah sebabnya keduanya biasanya muncul bersama dalam contoh.

Pengaturan devices Docker memetakan perangkat host ke dalam kontainer, sedangkan cap_add menyesuaikan himpunan kemampuan. Bind mount pada jalur yang sama menampilkan berkas tanpa menerapkan semantik akses perangkat.

Reproduksi di luar berkas Compose

Sebelum menyunting layanan, periksa bahwa host memiliki perangkat dan bahwa kontainer polos dapat membuat antarmuka. Perintah di bawah sengaja minimal, dan satu-satunya tujuannya adalah memisahkan masalah host dari masalah compose. Jika gagal, tidak ada perubahan compose yang 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'

Simpul yang hilang di host berarti modul tun tidak tersedia, yang merupakan perbaikan di sisi host dan bukan sisi kontainer. Simpul yang ada tetapi tidak dapat dibuka di dalam kontainer menunjuk ke akses perangkat, dan pesannya akan mengatakan permission denied alih-alih no such file. Urutan kedua kegagalan itu adalah seluruh diagnosis. Catat mana yang Anda lihat sebelum mengubah tanda.

Kesalahan setelah TUN adalah masalah yang berbeda

Begitu antarmuka muncul, kegagalan berikutnya memiliki pemilik yang berbeda. Kesalahan autentikasi berarti terowongan mencapai server dan kredensial ditolak, jadi perubahan kemampuan tidak akan membantu. Terowongan yang terbentuk sementara aplikasi masih gagal menunjuk ke rute, penerusan, resolusi DNS di dalam kontainer, atau tata letak jaringan kontainer itu sendiri. Masing-masing adalah pertanyaan jaringan biasa yang tidak dapat dijawab oleh izin TUN. Mengulangi uji asli setelah setiap perubahan mencegah kegagalan menyatu menjadi satu kesan.

Menyalin setiap pengaturan dari contoh yang berfungsi adalah cara perbaikan minimal menjadi definisi layanan yang tidak terbaca. Bawa hanya yang dibutuhkan penerapan ini dan catat mengapa masing-masing ada.

Verifikasi antarmuka di dalam kontainer

Periksa antarmuka dan himpunan kemampuan dari dalam kontainer yang berjalan, bukan dari host. Perintah di bawah menunjukkan simpul perangkat, daftar kemampuan, dan apakah antarmuka dapat dibuat sama sekali. Jalankan di kontainer yang sama yang menjalankan klien, dan pasang perkakas jika image minimal.

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

Kemampuan yang ada di bounding set tetapi tidak ada di effective set berperilaku berbeda dari yang tidak pernah diberikan, dan capsh menunjukkan keduanya. Jika simpul ada dan kemampuannya ada sementara pembuatan masih gagal, runtime menegakkan sesuatu yang lain, seperti profil seccomp atau kebijakan AppArmor yang membatasi operasi. Itu batas ketiga, didokumentasikan oleh runtime dan bukan oleh aplikasi.

Catat tanda kontainer, image, dan kesalahan persis dari setiap percobaan. Orang berikutnya yang membaca catatan itu dapat mengetahui pintu mana yang tertutup tanpa mengulangi seluruh penyelidikan.

Artikel terkait