WireGuard en LXC aŭ VM sur Proxmox: kie ĝi devus funkcii?
WireGuard povas funkcii sur la Proxmox-gastiganto, en ujo aŭ en VM. La decidaj faktoroj estas posedo de la kerno, kontrolo de la interfaco kaj restaŭrado.
WireGuard bezonas ekzakte unu kernon, kiu posedas sian interfacon, kaj tiu fakto solvas la plejparton de la Proxmox-loka debato antaŭ ol rendimento eĉ eniras la ĉambron. LXC-ujo estas nomspaca vido de la gastiganta kerno, dum VM ekŝarĝas sian propran. Do la utila demando ne estas, kiu opcio estas pli malpeza, sed kiun kernon vi pretas modifi kaj kun kiu restariga vojo vi povas vivi. Respondu tion, kaj la elekto inter gastiganto, ujo aŭ VM kutime faras sin mem.
LXC-gasto laboras ene de la gastiganta kerno
Instali wireguard-tools en ujon donas al vi la kontrolprogramon, ne privatan kernon. La interfaco wg0, kiun vi kreas, registriĝas en la reta stako de la gastiganto kaj aperas en ĝia modullisto. Tial ujo povas trapasi ĉiun pakaĵkontrolon kaj tamen malsukcesi ĉe la unua wg-komando, kiam la gastiganta kerno mankas la modulon. Kaj la Proxmox-uja referenco dokumentas tiun komunan-kernan modelon kune kun la nomspacaj kaj privilegiaj limoj, en kiuj vi laboras.
Aŭtoritato estas la dua limigo. Levi interfacon kaj aldoni adresojn al ĝi postulas retadministrajn rajtojn ene de la nomspaco, kiu posedas ĝin, kaj neprivilegia ujo mapas tiujn rajtojn tra sia uzantnomspaco anstataŭ teni ilin rekte. Neniam sin turnu al plena privilegio kiel unua respondo; rigardu, kion la ujo efektive estas petata fari, kaj poste donu tion.
La kerno de la gastiganto ankaŭ estas komuna dependeco. Proxmox-kerna ĝisdatigo ŝanĝas la WireGuard-implementon sub ĉiu ujo samtempe, kio estas oportuna ĝis ĝisdatigo kaj la atendoj de ujo malkonsentas.
Gastiganto, ujo, VM: kion ĉiu loko efektive posedas
Loko sur la gastiganto metas la VPN en la propran retadon de la hipervizoro. La vojoj, fajroŝirmilaj reguloj kaj la tunelo fariĝas parto de gastiganta restarigo, kaj eraro tie povas forpreni ankaŭ la administran interfacon. Tio akcepteblas por infrastruktura vojigo sur gastiganto, kiun vi atingas per konzolo, kaj dolora sur fora maŝino sen eksterbanda aliro.
Ujo tenas la servon pakaĵigita kaj restartebla, dum ĝi ankoraŭ prunteprenas la gastigantan kernon. Ĝi taŭgas por intenca komuna-kerna servo kaj donas al vi malgrandan unuon por rekonstrui. Ĝi ne donas al vi sendependan kernon, do io ajn, kio bezonas specifan modulan konstruon, montras for de ĉi tiu opcio.
| 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 kostas pli da memoro kaj ankoraŭ unu sistemon por fliki, kaj kontraŭe la tunelo ricevas sian propran kernon, sian propran vojigan tabelon kaj momentfotan limon. Kiam la VPN estas tio, kion vi restarigas post malbona ŝanĝo, tiu momentfoto indas la superkoston.
Tri kondiĉoj, kiuj elektas por vi
Se la tunelo bezonas kernan version aŭ WireGuard-funkcion, kiun la Proxmox-gastiganto ne liveras, haltu ĉi tie kaj uzu VM. Vi ne povas instali pli novan kernon en ujon, kaj vi ne devus anstataŭigi la hipervizoran kernon por kontentigi unu gaston.
Se la tunelo estas la pordego de la retejo por realaj LAN-prefiksoj, demandu, kiu jam posedas la revenan vojon. Ujo povas vojigi trafikon, sed ĝiaj interfacoj sidas en la stako de la gastiganto, do la gastiganto finfine portas parton de la agordo, ĉu vi planis tion aŭ ne. Loko sur la gastiganto estas honesta pri tio; loko en ujo ofte ne estas.
Poste pesu la eksplodradiuson de eraro. Restartigi ujon estas malmultekosta, restarigi VM-momentfoton estas antaŭvidebla, kaj ripari la reton de la gastiganto povas postuli fizikan aŭ konzolan aliron. La ĝusta elekto estas tiu, kies plej malbonan kazon vi povas efektive restarigi en la horo, kiam ĝi okazas.
Kvara demando malofte estas decida sed indas mencii: ĉu io alia sur la gastiganto bezonas vidi la tunelan interfacon? Se jes, loko sur la gastiganto aŭ en ujo tenas tiun videblecon loka, dum VM devigas vin vojigi inter la gasto kaj la gastiganto.
Pruvu la lokon antaŭ ol vojigi trafikon tra ĝi
Post instalado, konfirmu, kiu kerno efektive servas la interfacon kaj ĉu la ujo ricevis sufiĉan aŭtoritaton por teni ĝin:
$ 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
Poste kontrolu la plusendan flankon de la gastiganto, ĉar mansklamdo sola nur pruvas, ke la tunelo staras. Uzu ip route get por klienta adreso kaj konfirmu, ke la sekva salto kaj la interfaco kongruas kun la dezajno, kaj ke la reena vojo ekzistas ĉe la fora flanko.
Lasu la deplojon kun skribita posedanto: kiu kerno portas la implementon, kiu nomspaco tenas la interfacon, kaj kiujn prefiksojn la pordego rajtas plusendi. Tiu frazo malhelpas pli da incidentoj ol iu ajn referenca komparo de la tri lokoj.