WireGuard tarvitsee täsmälleen yhden ytimen, joka omistaa sen rajapinnan, ja tämä tosiasia ratkaisee suurimman osan Proxmox-sijoittelun väittelystä ennen kuin suorituskyky edes tulee huoneeseen. LXC-kontti on näkymä isäntäytimen nimiavaruuteen, kun taas VM käynnistää oman ytimensä. Hyödyllinen kysymys ei siis ole, mikä vaihtoehto on kevyin, vaan minkä ytimen olet valmis muuttamaan ja minkä palautuspolun kanssa voit elää. Vastaa siihen, ja valinta isännän, kontin tai VM:n välillä tekee yleensä itse itsensä.

LXC-vieras toimii isäntäytimen sisällä

Kun asennat wireguard-tools konttiin, saat hallintaohjelman, et yksityistä ydintä. Luomasi wg0-rajapinta rekisteröidään isännän verkkopinon ja näkyy isännän moduuliluettelossa. Siksi kontti voi läpäistä kaikki pakettitarkistukset ja silti epäonnistua ensimmäisessä wg-komennossa, kun isäntäytimeltä puuttuu moduuli. Ja Proxmoxin konttiviite dokumentoi tuon jaetun ytimen mallin sekä nimiavaruuden ja oikeuksien rajat, joiden sisällä työskentelet.

Toinen rajoite on valtuus. Rajapinnan nostaminen ja osoitteiden liittäminen siihen vaatii verkon ylläpito-oikeudet sen omistavan nimiavaruuden sisällä, ja ei-privilegoitu kontti kuvaa nuo oikeudet käyttäjänimiavaruutensa kautta sen sijaan että pitäisi niitä suoraan. Älä koskaan tartu täysiin oikeuksiin ensimmäisenä vastauksena; katso, mitä kontilta itse asiassa pyydetään, ja myönnä sitten juuri se.

Isäntäydin on myös jaettu riippuvuus. Proxmoxin ydinpäivitys muuttaa WireGuardin toteutusta jokaisen kontin alla kerralla, mikä on kätevää kunnes päivitys ja kontin odotukset eivät enää sovi yhteen.

Isäntä, kontti, VM: mitä kukin sijoitus todella omistaa

Sijoitus isännälle laittaa VPN:n hypervisorin omaan verkkoon. Reitit, palomuurisäännöt ja tunneli tulevat osaksi isännän palautumista, ja virhe siellä voi viedä hallintarajapinnan mukanaan. Se on hyväksyttävää infrastruktuurireititykselle isännällä, johon pääset konsolin kautta, ja kivuliasta etäkoneella ilman kaistan ulkopuolista pääsyä.

Kontti pitää palvelun paketoituna ja uudelleenkäynnistettävänä lainaten silti isäntäydintä. Se sopii tietoisesti jaettuun ydinpalveluun ja antaa pienen yksikön uudelleenrakennukseen. Se ei anna riippumatonta ydintä, joten kaikki tietyn moduulibuildin vaativa osoittaa poispäin tästä vaihtoehdosta.

PlacementKernel ownerTypical failure mode
Proxmox hostHypervisorA routing change breaks host management access
LXC containerHost kernel, container namespaceMissing capability or missing module at wg0 creation
Virtual machineGuest kernelExtra maintenance and a second patch cycle

VM maksaa enemmän muistia ja vielä yhden paikattavan järjestelmän, ja vastineeksi tunneli saa oman ytimensä, oman reititystaulunsa ja tilannekuvarajan. Kun VPN on se, jonka palautat huonon muutoksen jälkeen, tuo tilannekuva on lisävaivan arvoinen.

Kolme ehtoa, jotka valitsevat puolestasi

Jos tunneli tarvitsee ydinvestä tai WireGuard-ominaisuutta, jota Proxmox-isäntä ei tarjoa, pysähdy tähän ja käytä VM:ää. Konttiin ei voi asentaa uudempaa ydintä, eikä hypervisorin ydintä pitäisi vaihtaa yhden vieraan tyydyttämiseksi.

Jos tunneli on sivuston yhdyskäytävä todellisille LAN-etuliitteille, kysy, kuka jo omistaa paluureitin. Kontti voi reitittää liikennettä, mutta sen rajapinnat istuvat isännän pinossa, joten isäntä kantaa lopulta osan kokoonpanosta, suunnittelit sitä tai et. Sijoitus isännälle on siinä rehellinen; sijoitus konttiin usein ei.

Arvioi sitten virheen räjähdysetäisyys. Kontin uudelleenkäynnistys on halpaa, VM-tilannekuvan palauttaminen ennustettavaa ja isännän verkon korjaaminen voi vaatia fyysistä tai konsolipääsyä. Oikea valinta on se, jonka pahimman tapauksen voit todella palauttaa sinä tuntina, jona se tapahtuu.

Neljäs kysymys on harvoin ratkaiseva mutta mainitsemisen arvoinen: tarvitseeko jokin muu isännällä nähdä tunnelirajapinnan? Jos kyllä, sijoitus isännälle tai konttiin pitää näkyvyyden paikallisena, kun taas VM pakottaa reitittämään vieraan ja isännän välillä.

Todista sijoitus ennen kuin reitität liikennettä sen kautta

Asennuksen jälkeen vahvista, mikä ydin todella palvelee rajapintaa ja saiko kontti tarpeeksi valtuutta pitääkseen sen:

$ 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

Tarkista sitten edelleenlähetyspuoli isännältä, koska kättely yksin todistaa vain, että tunneli on pystyssä. Käytä ip route get asiakasosoitteelle ja vahvista, että seuraava hyppy ja rajapinta vastaavat suunnittelua, ja että paluupolku on olemassa vastapuolella.

Jätä käyttöönotto kirjallisen omistajan kanssa: mikä ydin kantaa toteutuksen, mikä nimiavaruus pitää rajapinnan ja mitä etuliitteitä yhdyskäytävä saa välittää. Tuo lause estää enemmän tapauksia kuin mikään kolmen sijoituksen vertailu.

Aiheeseen liittyvät artikkelit