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 за адреса на клиент и потврдете дека следниот скок и интерфејсот одговараат на проектот, и дека повратниот пат постои на далечната страна.

Оставете го распоредувањето со напишан сопственик: кое јадро ја носи имплементацијата, кој именски простор го држи интерфејсот и кои префикси портата смее да ги проследува. Таа една реченица спречува повеќе инциденти од кое било споредување на трите сместувања.