WireGuard у LXC або VM на Proxmox: де йому працювати?

WireGuard потребує рівно одного ядра, якому належить його інтерфейс, і цей факт знімає більшу частину суперечки про розміщення на Proxmox ще до того, як у розмову ввійде продуктивність. LXC-контейнер — це подання простору імен хостового ядра, а VM завантажує власне. Тому корисне питання не в тому, який варіант легший, а в тому, яке ядро ви готові змінювати і з яким шляхом відновлення можете жити. Дайте відповідь на це, і вибір між хостом, контейнером і VM зазвичай робиться сам.

Гість LXC працює всередині хостового ядра

Встановлення wireguard-tools у контейнері дає програму керування, а не окреме ядро. Створюваний інтерфейс wg0 реєструється в мережевому стеку хоста і з'являється в списку його модулів. Саме тому контейнер може пройти всі перевірки пакетів і все ж зазнати невдачі на першій команді wg, коли в ядрі хоста немає модуля. А довідка Proxmox щодо контейнерів описує цю модель спільного ядра разом із межами просторів імен і привілеїв, у яких ви працюєте.

Друге обмеження — повноваження. Щоб підняти інтерфейс і прив'язати до нього адреси, потрібні права мережевого адміністрування всередині простору імен, якому він належить, а непривілейований контейнер відображає ці права через свій простір імен користувача, а не тримає їх напряму. Ніколи не хапайтеся за повні привілеї як за першу відповідь; подивіться, що контейнеру насправді доручено, і дайте саме це.

Ядро хоста — теж спільна залежність. Оновлення ядра Proxmox змінює реалізацію WireGuard одразу під усіма контейнерами, що зручно, доки оновлення й очікування контейнера не розійдуться.

Хост, контейнер, VM: чим насправді володіє кожне розміщення

Розміщення на хості ставить VPN у власну мережу гіпервізора. Маршрути, правила брандмауера й тунель стають частиною відновлення хоста, і помилка там може забрати з собою інтерфейс керування. Це прийнятно для маршрутизації інфраструктури на хості, до якого дістаються через консоль, і болісно на віддаленій машині без доступу поза смугою.

Контейнер тримає службу спакованою та перезапускною, досі позичаючи ядро хоста. Він пасує для свідомо спільної за ядром служби і дає невелику одиницю для перезбирання. Незалежного ядра він не дає, тому все, що потребує конкретного збирання модуля, вказує геть від цього варіанта.

VM коштує більше пам'яті й ще однієї системи для патчів, а натомість тунель отримує власне ядро, власну таблицю маршрутизації та межу знімка. Коли після поганої зміни відкочують саме VPN, цей знімок вартий додаткових витрат.

Три умови, які обирають за вас

Якщо тунелю потрібна версія ядра або функція WireGuard, якої хост Proxmox не надає, зупиніться тут і використайте VM. Новіше ядро в контейнер встановити не можна, і не варто замінювати ядро гіпервізора заради одного гостя.

Якщо тунель — шлюз майданчика для справжніх префіксів LAN, запитайте, кому вже належить зворотний маршрут. Контейнер уміє маршрутизувати трафік, але його інтерфейси сидять у стеку хоста, тож хост зрештою несе частину конфігурації, планували ви це чи ні. Розміщення на хості чесне в цьому; розміщення в контейнері часто ні.

Потім зважте радіус ураження від помилки. Перезапустити контейнер дешево, відновити знімок VM передбачувано, а ремонт мережі хоста може вимагати фізичного доступу або консолі. Правильний вибір — той, чий найгірший випадок ви справді зможете відновити тієї години, коли він станеться.

Четверте питання рідко буває вирішальним, але його варто поставити: чи потрібно ще чомусь на хості бачити інтерфейс тунелю? Якщо так, розміщення на хості або в контейнері залишає цю видимість локальною, а VM змушує вас маршрутизувати між гостем і хостом.

Доведіть розміщення, перш ніж пускати через нього трафік

Після встановлення підтвердьте, яке ядро насправді обслуговує інтерфейс і чи отримав контейнер достатньо повноважень, щоб його втримати:

$ 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

Потім перевірте бік пересилання з хоста, бо один рукостиск лише доводить, що тунель піднято. Використайте ip route get для адреси клієнта і підтвердьте, що наступний хоп та інтерфейс відповідають проєкту, а зворотний шлях існує на далекому боці.

Залиште розгортання із записаним власником: яке ядро несе реалізацію, який простір імен тримає інтерфейс і які префікси шлюзу дозволено пересилати. Ця фраза запобігає більшій кількості інцидентів, ніж будь-яке порівняння трьох розміщень за бенчмарками.