WireGuard LXC-s või VM-is Proxmoxil: kus see peaks jooksma?
WireGuard võib joosta Proxmoxi hostil, konteineris või VM-is. Otsustavad tegurid on kerneli omand, liidese kontroll ja taastamine.
WireGuard vajab täpselt ühte kerneli, mis omab selle liidest, ja see tõsiasi otsustab suurema osa Proxmoxi paigutuse vaidlusest enne, kui jõudlus üldse tuppa jõuab. LXC konteiner on hosti kerneli nimeruumi vaade, samas kui VM käivitab oma kerneli. Nii et kasulik küsimus ei ole, milline valik on kergem, vaid millist kerneli olete nõus muutma ja millise taastamisteega saate elada. Vastake sellele ja valik hosti, konteineri või VM-i vahel teeb end tavaliselt ise.
LXC külaline töötab hosti kerneli sees
Kui paigaldate konteinerisse wireguard-tools, saate juhtprogrammi, mitte privaatse kerneli. Loodud liides wg0 registreeritakse hosti võrgupinus ja ilmub hosti moodulite nimekirja. Seetõttu võib konteiner läbida kõik paketikontrollid ja siiski ebaõnnestuda esimesel wg käsul, kui hosti kernelil puudub moodul. Ja Proxmoxi konteinerite viide dokumenteerib selle jagatud kerneli mudeli koos nimeruumi ja õiguste piiridega, mille sees töötate.
Teine piirang on volitus. Liidese üles tõstmine ja aadresside kinnitamine nõuab võrguadministreerimise õigusi nimeruumis, mis seda omab, ja mitteprivilegeeritud konteiner kaardistab need õigused oma kasutaja nimeruumi kaudu, selle asemel et neid otse hoida. Ärge kunagi haarake täisõiguste järele esimese vastusena; vaadake, mida konteinerilt tegelikult nõutakse, ja andke siis just see.
Hosti kernel on ka jagatud sõltuvus. Proxmoxi kerneli uuendus muudab WireGuardi teostust kõigi konteinerite all korraga, mis on mugav seni, kuni uuendus ja konteineri ootused ei lähe kokku.
Host, konteiner, VM: mida iga paigutus tegelikult omab
Paigutus hostil paneb VPN-i hüpervisori enda võrku. Marsruudid, tulemüüri reeglid ja tunnel saavad hosti taastamise osaks ning sealne viga võib kaasa viia haldusliidese. See on vastuvõetav infrastruktuuri marsruutimiseks hostil, kuhu pääsete konsooli kaudu, ja valus kaugmasinal, millel puudub ribaväline juurdepääs.
Konteiner hoiab teenust pakendatuna ja taaskäivitatavana, laenates samal ajal hosti kerneli. See sobib teadlikult jagatud kerneliga teenusele ja annab teile väikese üksuse ülesehitamiseks. See ei anna iseseisvat kerneli, seega kõik, mis vajab konkreetset mooduli ehitust, osutab sellest valikust eemale.
| 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 maksab rohkem mälu ja veel ühe plaastrit vajava süsteemi eest ning vastutasuks saab tunnel oma kerneli, oma marsruutimistabeli ja hetktõmmise piiri. Kui VPN on see, mille halva muudatuse järel tagasi kerite, on see hetktõmmis lisakoormuse väärt.
Kolm tingimust, mis valivad teie eest
Kui tunnel vajab kerneli versiooni või WireGuardi funktsiooni, mida Proxmoxi host ei paku, peatuge siin ja kasutage VM-i. Konteinerisse ei saa uuemat kerneli paigaldada ja ühe külalise rahuldamiseks ei tohiks hüpervisori kerneli välja vahetada.
Kui tunnel on saidi lüüs päris LAN-i prefiksite jaoks, küsige, kellele kuulub juba tagasituleku marsruut. Konteiner suudab liiklust marsruutida, kuid selle liidesed istuvad hosti pinus, nii et host kannab lõpuks osa konfiguratsioonist, kas te seda planeerisite või mitte. Paigutus hostil on selles aus; paigutus konteineris sageli mitte.
Seejärel kaaluge vea plahvatusraadiust. Konteineri taaskäivitamine on odav, VM-i hetktõmmise taastamine on ettearvatav ja hosti võrgu parandamine võib nõuda füüsilist või konsoolijuurdepääsu. Õige valik on see, mille halvimat juhtu suudate tõesti taastada just sel tunnil, kui see juhtub.
Neljas küsimus on harva otsustav, kuid väärib mainimist: kas midagi muud hostil peab tunneliliidest nägema? Kui jah, hoiab paigutus hostil või konteineris selle nähtavuse kohalikuna, samas kui VM sunnib teid marsruutima külalise ja hosti vahel.
Tõestage paigutus enne, kui suunate selle kaudu liiklust
Pärast paigaldamist kinnitage, milline kernel tegelikult liidest teenindab ja kas konteinerile anti piisavalt volitust selle hoidmiseks:
$ 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
Seejärel kontrollige edastamise poolt hostilt, sest üks kätlus tõestab ainult, et tunnel on üleval. Kasutage kliendi aadressi jaoks ip route get ja kinnitage, et järgmine hüpe ja liides vastavad projektile ning et tagasitee on teisel pool olemas.
Jätke juurutus kirjaliku omanikuga: milline kernel kannab teostust, milline nimeruum hoiab liidest ja milliseid prefikseid võib lüüs edastada. See lause hoiab ära rohkem juhtumeid kui ükski kolme paigutuse võrdlus.