WireGuard di LXC atau VM pada Proxmox: di mana sebaiknya dijalankan?
WireGuard dapat berjalan di host Proxmox, di kontainer, atau di VM. Faktor penentunya adalah kepemilikan kernel, kendali antarmuka, dan pemulihan.
WireGuard membutuhkan tepat satu kernel yang memiliki antarmukanya, dan fakta itu menyelesaikan sebagian besar perdebatan penempatan di Proxmox sebelum performa masuk ke ruangan. Kontainer LXC adalah tampilan ruang nama dari kernel host, sedangkan VM mem-boot kernelnya sendiri. Jadi pertanyaan yang berguna bukanlah opsi mana yang lebih ringan, melainkan kernel mana yang bersedia Anda ubah dan jalur pemulihan mana yang bisa Anda jalani. Jawab itu, dan pilihan antara host, kontainer, atau VM biasanya terjadi dengan sendirinya.
Tamu LXC bekerja di dalam kernel host
Memasang wireguard-tools di dalam kontainer memberi Anda program kendali, bukan kernel pribadi. Antarmuka wg0 yang Anda buat terdaftar di tumpukan jaringan host dan muncul di daftar modul host. Itulah sebabnya kontainer bisa lolos setiap pemeriksaan paket dan tetap gagal pada perintah wg pertama ketika kernel host tidak memiliki modul itu. Dan referensi kontainer Proxmox mendokumentasikan model kernel bersama itu beserta batas ruang nama dan hak istimewa tempat Anda bekerja.
Kewenangan adalah kendala kedua. Menyalakan antarmuka dan melampirkan alamat memerlukan hak administrasi jaringan di dalam ruang nama yang memilikinya, dan kontainer tanpa hak istimewa memetakan hak itu melalui ruang nama penggunanya alih-alih memegangnya langsung. Jangan pernah meraih hak istimewa penuh sebagai jawaban pertama; lihat apa yang sebenarnya diminta dari kontainer, lalu berikan itu.
Kernel host juga merupakan ketergantungan bersama. Pembaruan kernel Proxmox mengubah implementasi WireGuard di bawah setiap kontainer sekaligus, yang nyaman sampai sebuah pembaruan dan ekspektasi sebuah kontainer tidak lagi sepakat.
Host, kontainer, VM: apa yang sebenarnya dimiliki setiap penempatan
Penempatan di host menaruh VPN di jaringan hypervisor itu sendiri. Rute, aturan firewall, dan terowongan menjadi bagian dari pemulihan host, dan kesalahan di sana bisa ikut membawa antarmuka manajemen. Itu dapat diterima untuk perutean infrastruktur pada host yang Anda jangkau lewat konsol, dan menyakitkan pada mesin jarak jauh tanpa akses di luar pita.
Kontainer menjaga layanan tetap terpaket dan dapat dijalankan ulang sambil tetap meminjam kernel host. Ia cocok untuk layanan dengan kernel bersama yang disengaja dan memberi Anda unit kecil untuk dibangun ulang. Ia tidak memberi kernel independen, jadi apa pun yang memerlukan build modul tertentu mengarah menjauh dari opsi ini.
| Placement | Kernel owner | Typical failure mode |
|---|---|---|
| Proxmox host | Hypervisor | A routing change breaks host management access |
| LXC container | Host kernel, container namespace | Missing capability or missing module at wg0 creation |
| Virtual machine | Guest kernel | Extra maintenance and a second patch cycle |
VM memakan memori lebih banyak dan satu sistem lagi untuk ditambal, dan sebagai gantinya terowongan mendapat kernel sendiri, tabel perutean sendiri, dan batas snapshot. Ketika VPN adalah hal yang Anda kembalikan setelah perubahan buruk, snapshot itu sepadan dengan tambahan bebannya.
Tiga kondisi yang memilih untuk Anda
Jika terowongan membutuhkan versi kernel atau fitur WireGuard yang tidak disediakan host Proxmox, berhentilah di sini dan gunakan VM. Anda tidak bisa memasang kernel yang lebih baru ke dalam kontainer, dan sebaiknya tidak mengganti kernel hypervisor demi memuaskan satu tamu.
Jika terowongan adalah gateway situs untuk prefiks LAN sungguhan, tanyakan siapa yang sudah memiliki rute pulang. Kontainer bisa merutekan lalu lintas, tetapi antarmukanya berada di tumpukan host, jadi host akhirnya memikul sebagian konfigurasi, entah Anda merencanakannya atau tidak. Penempatan di host jujur soal ini; penempatan di kontainer sering tidak.
Lalu timbang radius dampak sebuah kesalahan. Menjalankan ulang kontainer itu murah, memulihkan snapshot VM dapat diprediksi, dan memperbaiki jaringan host mungkin memerlukan akses fisik atau konsol. Pilihan yang tepat adalah pilihan yang kasus terburuknya benar-benar dapat Anda pulihkan pada jam ketika hal itu terjadi.
Pertanyaan keempat jarang menentukan tetapi layak dikatakan: apakah ada hal lain di host yang perlu melihat antarmuka terowongan? Jika ya, penempatan di host atau di kontainer menjaga visibilitas itu tetap lokal, sedangkan VM memaksa Anda merutekan antara tamu dan host.
Buktikan penempatan sebelum merutekan lalu lintas melaluinya
Setelah terpasang, pastikan kernel mana yang benar-benar melayani antarmuka dan apakah kontainer diberi kewenangan cukup untuk mempertahankannya:
$ pct config 101 | grep -E 'unprivileged|features'
unprivileged: 1
$ pct exec 101 -- wg show
interface: wg0
listening port: 51820
$ pct exec 101 -- ip -4 addr show wg0
inet 10.60.0.2/24 scope global wg0
Lalu periksa sisi penerusan dari host, karena jabat tangan saja hanya membuktikan terowongan menyala. Gunakan ip route get untuk alamat klien dan pastikan lompatan berikutnya serta antarmuka cocok dengan rancangan, dan rute pulang ada di sisi jauh.
Tinggalkan penerapan dengan pemilik tertulis: kernel mana yang membawa implementasi, ruang nama mana yang memegang antarmuka, dan prefiks mana yang boleh diteruskan gateway. Kalimat itu mencegah lebih banyak insiden daripada perbandingan tolok ukur apa pun dari ketiga penempatan.