OpenVPN dalam Docker: kontrak masa jalan yang diperlukan oleh klien minimum
Imej yang disemak, satu profil terlindung, akses TUN dan NET_ADMIN. Apa yang diterima kontena, apa yang tidak boleh diterima dan cara membuktikan terowong berfungsi.
Letakkan klien VPN dalam kontena dan anda mendapat satu ruang nama dengan terowong di dalamnya, bukan hos yang menghalakan semua trafiknya melalui VPN. Itu projek berasingan, dan menganggapnya sebagai satu ialah cara kontena akhirnya menjadi istimewa secara tidak sengaja. Panduan ini hanya merangkumi yang pertama: satu imej yang disemak, satu profil terlindung dan proses klien yang terhad kepada ruang nama rangkaiannya sendiri.
Mulakan dengan artifak yang telah diluluskan oleh seseorang. Langkah di bawah menganggap imej yang mengandungi fail boleh laku openvpn dan profil klien lengkap dengan sijil dan bahan kuncinya sudah diselesaikan dalam pelekap. Ia tidak membina perisian, tidak mengeluarkan kelayakan dan tidak merangkumi masa jalan tanpa root atau kontena Windows asli, yang setiap satunya mengubah jawapan.
Apa yang diterima kontena dan apa yang tidak
Simpan profil dan semua yang dirujuknya dalam direktori tempatan dengan kebenaran terhad, dilekap sebagai baca sahaja. Laluan relatif dalam profil mesti diselesaikan dalam pelekap itu; ini butiran yang orang terlepas apabila sijil berada satu direktori di atas profil dan kontena tidak pernah melihatnya.
services:
vpn:
image: ${VPN_CLIENT_IMAGE:?set the reviewed image reference}
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
volumes:
- ./vpn:/vpn:ro
working_dir: /vpn
entrypoint: ["openvpn"]
command: ["--config", "/vpn/client.ovpn"]
Fail itu memberikan tiga perkara dan tidak meminta apa-apa lagi. Rujukan imej hendaklah dipin dengan digest jika dasar penggunaan anda menyatakannya, dan profil hendaklah yang disemak, bukan salinan yang seseorang sunting di tempat pada hos.
Baca sahaja di sini bermaksud kontena tidak boleh mengubah fail anda pada hos; ia tidak bermaksud kontena tidak boleh membaca kunci peribadi yang anda lekapkan. Itulah keseluruhan tujuan pelekap, dan sebab itulah kebenaran fail, pemilikan dan cara rahsia itu sampai ke hos masih penting. Jangan sekali-kali menghantar kata laluan pada baris arahan atau membakarnya ke dalam lapisan imej, kerana kedua-duanya kekal di tempat yang tidak boleh anda bersihkan kemudian.
Keupayaan, entrypoint dan perangkap di antaranya
Dua tetapan diperlukan dan ia melakukan kerja yang tidak berkaitan. NET_ADMIN membenarkan manipulasi antara muka dan laluan dalam ruang nama kontena. Entri peranti /dev/net/tun membenarkan proses membuka peranti terowong sama sekali. Memberi satu tanpa yang lain menghasilkan kegagalan yang jelas, yang memudahkan: peranti TUN yang tiada gagal semasa dibuka, manakala keupayaan yang tiada gagal apabila klien cuba mengkonfigurasi antara muka.
Tiada satu pun daripada itu mewajarkan privileged: true. Kontena istimewa menerima semua keupayaan serta akses peranti, dan itu jauh lebih besar daripada yang diperlukan oleh beban kerja ini. rujukan keistimewaan dan keupayaan masa jalan menerangkan sejauh mana pemberian itu sampai. Jika chart atau jawatan blog memintanya, semak dahulu sama ada keperluan itu sebenarnya laluan peranti yang tiada atau keupayaan yang tiada.
Mengatasi entrypoint ialah bahagian yang menggigit. Memanggil openvpn secara langsung betul untuk imej biasa dan salah untuk mana-mana imej produk yang skrip permulaannya menyediakan peraturan tembok api, fail penyelesai atau kelayakan sebelum melaksanakan daemon. Mengatasi skrip itu melangkau penyediaan dan meninggalkan anda menyahpepijat terowong yang naik dalam ruang nama yang separuh dikonfigurasi.
Jalankan klien di latar depan dan biarkan ia menjadi proses utama kontena. Proses yang menjadi daemon keluar serta-merta, kontena dimulakan semula dalam gelung, dan log yang anda perlukan tersebar merentasi permulaan semula yang semuanya kelihatan sama.
Sahkan dari dalam ruang nama, bukan dari hos
Naikkan tindanan, sahkan dalam log bahawa klien mencapai keadaan bersambung, kemudian periksa ruang nama yang benar-benar memegang terowong.
docker compose up -d
docker compose logs --tail 40 vpn
docker compose exec vpn ip -br addr
docker compose exec vpn ip route
Senarai alamat sepatutnya menunjukkan antara muka terowong dengan alamat daripada kolam, dan jadual laluan sepatutnya menunjukkan destinasi yang ditolak menunjuk ke arahnya. Jika antara muka tiada, klien tidak pernah sampai ke peringkat menciptanya. Jika ia wujud tetapi tiada laluan menggunakannya, tempat untuk mencari ialah push atau pilihan laluan.
Kemudian uji destinasi yang anda pentingkan, dari ruang nama yang sepatutnya menggunakan terowong, dengan aplikasi dan bukan hanya ping. Penyelesaian nama ialah kegagalan berasingan yang wajar diuji secara eksplisit: alamat DNS yang ditolak tidak mengemas kini penyelesai kontena dengan sendirinya, dan klien berdiri sendiri yang mengabaikan push akan menyelesaikan nama melalui apa sahaja yang dikonfigurasi oleh imej.
Keadaan terputus ialah sebahagian daripada kontrak
Tingkah laku sambung semula memerlukan pemeriksaannya sendiri, kerana dasar permulaan semula membuktikan proses itu dimulakan semula dan tidak mengatakan apa-apa tentang apa yang trafik lakukan di antaranya. Hentikan terowong, cuba destinasi yang dimaksudkan dan perhatikan sama ada sambungan ditolak, tergantung atau berjaya secara senyap melalui laluan biasa kontena. Hasil terakhir itulah yang penting, dan ia tidak kelihatan dalam log yang sihat.
Jika beban kerja tidak boleh sekali-kali menggunakan laluan biasa, reka bentuknya secara eksplisit dengan peraturan tembok api dan isyarat kesediaan dalam ruang nama. Kill switch ialah dasar yang anda tulis dan uji, bukan sifat yang anda warisi dengan menjalankan klien dalam kontena.
Akhir sekali, ingat sempadan: laluan ini hidup dalam ruang nama kontena dan tidak menggantikan jadual penghalaan hos. Peraturan pemajuan, terjemahan dan tembok api Docker kekal sebahagian daripada laluan luar, dan port yang diterbitkan bukan antara muka VPN.