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 за клиентски адрес и потвърдете, че следващият хоп и интерфейсът отговарят на дизайна, както и че обратният път съществува от другата страна.

Оставете внедряването със записан собственик: кое ядро носи реализацията, кое именно пространство държи интерфейса и кои префикси шлюзът има право да препраща. Това изречение предотвратява повече инциденти от всяко бенчмарк сравнение на трите разположения.