WireGuard у LXC-у или VM-у на Proxmox-у: где би требало да ради?
WireGuard може да ради на Proxmox домаћину, у контејнеру или у VM-у. Одлучујући фактори су власништво над кернелом, контрола интерфејса и опоравак.
WireGuard-у је потребно тачно једно кернел које поседује његов интерфејс, и та чињеница решава већину расправе о смештају на Proxmox-у пре него што перформансе уопште уђу у разговор. LXC контејнер је приказ именског простора кернела домаћина, док VM подиже сопствени. Зато корисно питање није која је опција лакша, него које сте кернел спремни да мењате и са којим путем опоравка можете да живите. Одговорите на то, и избор између домаћина, контејнера или VM-а обично се сам наметне.
LXC гост ради унутар кернела домаћина
Инсталирање wireguard-tools у контејнеру даје вам контролни програм, а не приватни кернел. Интерфејс wg0 који креирате региструје се у мрежном стек-у домаћина и појављује се на његовој листи модула. Зато контејнер може да прође сваку проверу пакета и ипак не успе на првој wg команди када кернелу домаћина недостаје модул. А референца за Proxmox контејнере документује тај модел дељеног кернела заједно са границама именског простора и привилегија у којима радите.
Овлашћење је друго ограничење. Подизање интерфејса и придруживање адреса захтева права мрежне администрације унутар именског простора који га поседује, а непривилеговани контејнер та права пресликава кроз свој кориснички именски простор уместо да их држи директно. Никада не посегните за пуним привилегијама као првим одговором; погледајте шта се од контејнера заиста тражи, па то и дајте.
Кернел домаћина је такође дељена зависност. Ажурирање кернела Proxmox-а мења имплементацију WireGuard-а под сваким контејнером одједном, што је згодно док се ажурирање и очекивања контејнера не разиђу.
Домаћин, контејнер, VM: шта сваки смештај заиста поседује
Смештај на домаћину ставља VPN у сопствену мрежу хипервизора. Руте, правила заштитног зида и тунел постају део опоравка домаћина, а грешка тамо може да однесе и интерфејс за управљање. То је прихватљиво за инфраструктурно рутирање на домаћину до ког долазите кроз конзолу, и болно на удаљеној машини без приступа ван опсега.
Контејнер држи услугу упаковану и поново покретљиву док још позајмљује кернел домаћина. Одговара намерној услузи са дељеним кернелом и даје вам малу јединицу за поновну изградњу. Не даје вам независни кернел, па све што захтева одређену изградњу модула показује даље од ове опције.
| 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 кошта више меморије и још један систем за закрпе, а заузврат тунел добија сопствени кернел, сопствену табелу рутирања и границу снимка. Када је 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 за адресу клијента и потврдите да се следећи скок и интерфејс поклапају са пројектом, и да повратни пут постоји на далекој страни.
Оставите распоређивање са написаним власником: који кернел носи имплементацију, који именски простор држи интерфејс и који префикси капија сме да прослеђује. Та реченица спречава више инцидената од било каквог поређења три смештаја.