WireGuard LXC arba VM Proxmox aplinkoje: kur jis turėtų veikti?
WireGuard gali veikti Proxmox pagrindiniame kompiuteryje, konteineryje arba VM. Lemiami veiksniai yra branduolio nuosavybė, sąsajos kontrolė ir atkūrimas.
WireGuard reikia tiksliai vieno branduolio, kuriam priklausytų jo sąsaja, ir šis faktas išsprendžia didžiąją dalį Proxmox talpinimo ginčo dar prieš įsitraukiant našumui. LXC konteineris yra pagrindinio branduolio vardų erdvės vaizdas, o VM paleidžia savo branduolį. Taigi naudingas klausimas yra ne tai, kuri parinktis lengvesnė, o tai, kurį branduolį esate pasirengę keisti ir su kokiu atkūrimo keliu galite gyventi. Atsakykite į tai, ir pasirinkimas tarp pagrindinio kompiuterio, konteinerio ar VM dažniausiai padaromas savaime.
LXC svečias dirba pagrindinio branduolio viduje
Įdiegus wireguard-tools konteineryje gaunate valdymo programą, o ne privatų branduolį. Sukurta wg0 sąsaja registruojama pagrindinio kompiuterio tinklo kamino ir atsiranda jo modulių sąraše. Todėl konteineris gali praeiti visus paketų patikrinimus ir vis tiek nepavykti pirmosios wg komandos metu, kai pagrindinio branduolyje trūksta modulio. Ir Proxmox konteinerių informacinis vadovas dokumentuoja tą bendro branduolio modelį kartu su vardų erdvės ir privilegijų ribomis, kuriose dirbate.
Įgaliojimai yra antrasis apribojimas. Sąsajos pakėlimas ir adresų prijungimas reikalauja tinklo administravimo teisių vardų erdvėje, kuri jai priklauso, o neprivilegijuotas konteineris tas teises atvaizduoja per savo naudotojo vardų erdvę, o ne laiko jų tiesiogiai. Niekada nesiekite visiškos privilegijos kaip pirmojo atsakymo; pažiūrėkite, ko iš tikrųjų prašoma iš konteinerio, ir tada to duokite.
Pagrindinio kompiuterio branduolys taip pat yra bendra priklausomybė. Proxmox branduolio atnaujinimas vienu metu keičia WireGuard įgyvendinimą po kiekvienu konteineriu, kas yra patogu tol, kol atnaujinimas ir konteinerio lūkesčiai nesutampa.
Pagrindinis kompiuteris, konteineris, VM: ką iš tikrųjų turi kiekviena vieta
Talpinimas pagrindiniame kompiuteryje įdeda VPN į paties hipervizoriaus tinklą. Maršrutai, ugniasienės taisyklės ir tunelis tampa pagrindinio kompiuterio atkūrimo dalimi, o klaida ten gali pasiimti ir valdymo sąsają. Tai priimtina infrastruktūros maršrutizavimui pagrindiniame kompiuteryje, kurį pasiekiate per konsolę, ir skausminga nuotolinėje mašinoje be prieigos už juostos.
Konteineris laiko paslaugą supakuotą ir perkraunamą, vis dar skolindamasis pagrindinio branduolį. Jis tinka sąmoningai bendro branduolio paslaugai ir duoda mažą vienetą perstatymui. Jis neduoda nepriklausomo branduolio, todėl viskas, kam reikia konkretaus modulio kompiliavimo, nukreipia tolyn nuo šios parinkties.
| 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 kainuoja daugiau atminties ir dar vieną lopomą sistemą, o mainais tunelis gauna savo branduolį, savo maršrutizavimo lentelę ir momentinės kopijos ribą. Kai VPN yra tai, ką atšaukiate po blogo pakeitimo, ta momentinė kopija verta papildomų sąnaudų.
Trys sąlygos, kurios pasirenka už jus
Jei tuneliui reikia branduolio versijos arba WireGuard funkcijos, kurios Proxmox pagrindinis kompiuteris neteikia, sustokite čia ir naudokite VM. Negalite įdiegti naujesnio branduolio į konteinerį, ir neturėtumėte keisti hipervizoriaus branduolio, kad patenkintumėte vieną svečią.
Jei tunelis yra svetainės šliuzas tikriems LAN priešdėliams, paklauskite, kam jau priklauso grįžtamasis maršrutas. Konteineris gali maršrutizuoti srautą, bet jo sąsajos yra pagrindinio kompiuterio kamine, todėl pagrindinis kompiuteris galiausiai neša dalį konfigūracijos, nesvarbu, ar tai planavote. Talpinimas pagrindiniame kompiuteryje čia sąžiningas; talpinimas konteineryje dažnai ne.
Tada pasverkite klaidos poveikio spindulį. Konteinerio perkrovimas pigus, VM momentinės kopijos atkūrimas nuspėjamas, o pagrindinio kompiuterio tinklo taisymas gali pareikalauti fizinės ar konsolės prieigos. Teisingas pasirinkimas yra tas, kurio blogiausią atvejį iš tikrųjų galite atkurti tą valandą, kai jis įvyksta.
Ketvirtas klausimas retai būna lemiamas, bet verta jį pasakyti: ar kam nors kitam pagrindiniame kompiuteryje reikia matyti tunelio sąsają? Jei taip, talpinimas pagrindiniame kompiuteryje ar konteineryje išlaiko tą matomumą vietinį, o VM verčia jus maršrutizuoti tarp svečio ir pagrindinio kompiuterio.
Įrodykite talpinimą prieš praleisdami per jį srautą
Po diegimo patvirtinkite, kuris branduolys iš tikrųjų aptarnauja sąsają ir ar konteineriui suteikta pakankamai įgaliojimų ją išlaikyti:
$ 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
Tada patikrinkite perdavimo pusę iš pagrindinio kompiuterio, nes vien rankos paspaudimas įrodo tik tai, kad tunelis pakeltas. Naudokite ip route get kliento adresui ir patvirtinkite, kad kitas šuolis ir sąsaja atitinka projektą, o grįžtamasis kelias egzistuoja kitame gale.
Palikite diegimą su rašytiniu savininku: kuris branduolys neša įgyvendinimą, kuri vardų erdvė laiko sąsają ir kokius priešdėlius šliuzui leidžiama perduoti. Tas vienas sakinys užkerta kelią daugiau incidentų nei bet koks trijų talpinimo vietų palyginimas.