WireGuard u LXC-u ili VM-u na Proxmoxu: gdje bi trebao raditi?
WireGuard može raditi na Proxmox hostu, u kontejneru ili u VM-u. Odlučujući faktori su vlasništvo nad kernelom, kontrola interfejsa i oporavak.
WireGuardu treba tačno jedan kernel koji posjeduje njegov interfejs, i ta činjenica rješava većinu rasprave o smještaju na Proxmoxu prije nego što se performanse uopće pojave. LXC kontejner je prikaz imenskog prostora host kernela, dok VM podiže vlastiti. Zato korisno pitanje nije koja je opcija lakša, nego koji ste kernel spremni mijenjati i s kojim putem oporavka možete živjeti. Odgovorite na to i izbor između hosta, kontejnera ili VM-a obično se sam nametne.
LXC gost radi unutar host kernela
Instaliranje wireguard-tools unutar kontejnera daje vam kontrolni program, a ne privatni kernel. Interfejs wg0 koji kreirate registruje se u mrežnom steku hosta i pojavljuje se na listi modula hosta. Zato kontejner može proći svaku provjeru paketa i ipak pasti na prvoj komandi wg kada host kernelu nedostaje modul. A referenca za Proxmox kontejnere dokumentuje taj model dijeljenog kernela zajedno s granicama imenskog prostora i privilegija unutar kojih radite.
Ovlaštenje je drugo ograničenje. Podizanje interfejsa i pridruživanje adresa zahtijeva prava mrežne administracije unutar imenskog prostora koji ga posjeduje, a neprivilegovani kontejner ta prava preslikava kroz svoj korisnički imenski prostor umjesto da ih drži direktno. Nikada ne posežite za punim privilegijama kao prvim odgovorom; pogledajte šta se od kontejnera zapravo traži, pa to i dajte.
Host kernel je također dijeljena zavisnost. Proxmox ažuriranje kernela mijenja WireGuard implementaciju pod svakim kontejnerom odjednom, što je zgodno dok se ažuriranje i očekivanja kontejnera ne raziđu.
Host, kontejner, VM: šta svaki smještaj zapravo posjeduje
Smještaj na hostu stavlja VPN u vlastitu mrežu hipervizora. Rute, firewall pravila i tunel postaju dio oporavka hosta, a greška tamo može odnijeti i upravljački interfejs. To je prihvatljivo za infrastrukturno rutiranje na hostu do kojeg dolazite kroz konzolu, a bolno na udaljenoj mašini bez pristupa izvan pojasa.
Kontejner drži uslugu zapakovanom i restartabilnom, a ipak posuđuje host kernel. Odgovara namjernoj usluzi s dijeljenim kernelom i daje vam malu jedinicu za ponovnu izgradnju. Ne daje vam nezavisni kernel, pa sve što traži određenu izgradnju modula upućuje dalje od ove opcije.
| 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 košta više memorije i još jedan sistem za zakrpe, a zauzvrat tunel dobija vlastiti kernel, vlastitu tabelu rutiranja i granicu snimka. Kada je VPN ono što vraćate nakon loše promjene, taj snimak vrijedi dodatnog tereta.
Tri uslova koja biraju umjesto vas
Ako tunelu treba verzija kernela ili WireGuard funkcija koju Proxmox host ne isporučuje, zaustavite se ovdje i koristite VM. Ne možete instalirati noviji kernel u kontejner, i ne treba mijenjati kernel hipervizora da zadovoljite jednog gosta.
Ako je tunel gateway stranice za prave LAN prefikse, pitajte ko već posjeduje povratnu rutu. Kontejner može rutirati saobraćaj, ali njegovi interfejsi sjede u steku hosta, pa host na kraju nosi dio konfiguracije, planirali to ili ne. Smještaj na hostu je iskren u vezi s tim; smještaj u kontejneru često nije.
Zatim odmjerite radijus eksplozije greške. Restart kontejnera je jeftin, vraćanje VM snimka je predvidivo, a popravka mreže hosta može zahtijevati fizički ili konzolni pristup. Ispravan izbor je onaj čiji najgori slučaj zaista možete oporaviti u satu kada se dogodi.
Četvrto pitanje rijetko je presudno, ali vrijedi ga reći: treba li još nešto na hostu vidjeti interfejs tunela? Ako da, smještaj na hostu ili u kontejneru drži tu vidljivost lokalnom, dok vas VM tjera da rutirate između gosta i hosta.
Dokažite smještaj prije nego kroz njega rutirate saobraćaj
Nakon instalacije potvrdite koji kernel zapravo opslužuje interfejs i je li kontejneru dato dovoljno ovlaštenja da ga zadrži:
$ 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
Zatim provjerite stranu prosljeđivanja s hosta, jer samo rukovanje dokazuje da je tunel podignut. Koristite ip route get za adresu klijenta i potvrdite da se sljedeći skok i interfejs poklapaju s dizajnom, te da povratni put postoji na dalekoj strani.
Ostavite implementaciju s napisanim vlasnikom: koji kernel nosi implementaciju, koji imenski prostor drži interfejs i koji prefiksi gateway smije prosljeđivati. Ta rečenica sprječava više incidenata od bilo kojeg benchmark poređenja tri smještaja.