WireGuard yn LXC of in VM op Proxmox: wêr moat it rinne?
WireGuard kin rinne op 'e Proxmox-host, yn in kontener of yn in VM. De beslissende faktoaren binne eigenerskip fan 'e kernel, kontrôle oer de interface en herstel.
WireGuard hat krekt ien kernel nedich dy't syn ynterface besit, en dat feit beslist it meastepart fan 'e Proxmox-plakkingsdiskúsje foardat prestaasjes de keamer yn komme. In LXC-kontener is in nammromtesicht fan 'e hostkernel, wylst in VM syn eigen kernel opstart. Dat de nuttige fraach is net hokker opsje lichter is, mar hokker kernel jo ree binne te feroarjen en mei hokker herstelpaad jo libje kinne. Beäntwurdzje dat, en de kar tusken host, kontener of VM makket himsels meastentiids.
In LXC-gast wurket binnen de hostkernel
It ynstallearjen fan wireguard-tools yn in kontener jout jo it kontrôleprogramma, net in privee kernel. De interface wg0 dy't jo meitsje wurdt registrearre yn 'e netwurkstapel fan 'e host en ferskynt yn 'e modulelist fan 'e host. Dêrom kin in kontener elke pakketkontrôle trochstean en dochs misse by it earste wg-kommando as de hostkernel de module mist. En de Proxmox-kontenerreferinsje dokumintearret dat model fan dielde kernel tegearre mei de nammromte- en privilezjesgrinzen dêr't jo yn wurkje.
Autoriteit is de twadde beheining. In interface omheech bringe en adressen deroan koppelje freget netwurkbeheardersrjochten binnen de nammromte dy't him besit, en in net-privilegearre kontener mappet dy rjochten fia syn brûkersnammromte ynstee fan se direkt te hâlden. Gryp nea nei folsleine privilezjes as earste antwurd; sjoch wat der eins fan 'e kontener frege wurdt, en jou dat dan.
De hostkernel is ek in dielde ôfhinklikens. In Proxmox-kernelfernijing feroaret de WireGuard-ymplemintaasje ûnder elke kontener tagelyk, wat handich is oant in fernijing en de ferwachtings fan in kontener net mear oerienkomme.
Host, kontener, VM: wat elke plakking eins besit
Plakking op 'e host set de VPN yn it eigen netwurk fan 'e hypervisor. Rûtes, firewallregels en de tunnel wurde diel fan hostherstel, en in flater dêr kin de behearinterface meinimme. Dat is akseptabel foar ynfrastruktuerrouting op in host dy't jo fia in konsôle berikke kinne, en pynlik op in fiere masine sûnder tagong bûten de bân.
In kontener hâldt de tsjinst ferpakt en werstartber wylst er noch de hostkernel liend. It past by in bewust dielde-kernaltsjinst en jout jo in lytse ienheid om wer op te bouwen. It jout gjin ûnôfhinklike kernel, dus alles wat in spesifike modulebou nedich hat, wiist by dizze opsje wei.
| 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 |
In VM kostet mear ûnthâld en noch in systeem om te patchjen, en yn ruil krijt de tunnel syn eigen kernel, syn eigen routingtabel en in snapshotgrins. As de VPN it ding is dat jo nei in minne feroaring weromsette, is dat snapshot de oerlêst wurdich.
Trije betingsten dy't foar jo kieze
As de tunnel in kernelferzje of in WireGuard-funksje nedich hat dy't de Proxmox-host net leveret, stopje hjir en brûk in VM. Jo kinne gjin nijer kernel yn in kontener ynstallearje, en jo moatte de hypervisorkernel net ferfange om ien gast tefreden te stellen.
As de tunnel de gateway fan 'e side is foar echte LAN-prefiksen, freegje dan wa't de weromrûte al besit. In kontener kin ferkear route, mar syn interfaces sitte yn 'e stapel fan 'e host, dus de host draacht úteinlik in part fan 'e konfiguraasje, oft jo dat pland hawwe of net. Plakking op 'e host is earlik dêroer; plakking yn in kontener faak net.
Weagje dan de ynfloedradius fan in flater. In kontener werstarte is goedkeap, in VM-snapshot weromsette is foarsisber, en it reparearjen fan hostnetwurk kin fysike of konsôletagong freegje. De juste kar is dy't jo slimste gefal echt herstelle kinne op it oere dat it bart.
In fjirde fraach is selden beslissend mar wol neamen wurdich: moat eat oars op 'e host de tunnelinterface sjen? As ja, hâldt plakking op 'e host of yn in kontener dy sichtberens lokaal, wylst in VM jo twingt tusken gast en host te routen.
Bewiis de plakking foardat jo ferkear der troch route
Ienris ynstallearre, befêstigje hokker kernel de interface eins tsjinnet en oft de kontener genôch autoriteit krigen hat om him te hâlden:
$ 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
Kontrolearje dan de trochstjoerkant fan 'e host, want in hânskot allinnich bewiist dat de tunnel oer ein is. Brûk ip route get foar in kliïntadres en befêstigje dat de folgjende hop en interface oerienkomme mei it ûntwerp, en dat it werompaad oan 'e oare kant bestiet.
Lit de útrôl mei in skriftlike eigner: hokker kernel de ymplemintaasje draacht, hokker nammromte de interface hâldt en hokker prefiksen de gateway trochstjoere mei. Dy sin foarkomt mear ynsidinten as hokker benchmarkfergeliking fan 'e trije plakkings dan ek.