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 для адраса кліента і пацвердзіце, што наступны крок і інтэрфейс адпавядаюць праекту, а таксама што зваротны шлях існуе на далёкім баку.

Пакіньце разгортванне з запісаным уласнікам: якое ядро нясе рэалізацыю, якая прастора імёнаў трымае інтэрфейс і якія прэфіксы шлюзу дазволена перанакіроўваць. Гэтае сказ прадухіляе больш інцыдэнтаў, чым любое параўнанне трох размяшчэнняў па бенчмарках.