WireGuard LXC-ben vagy VM-ben Proxmoxon: hol kellene futnia?

A WireGuardnak pontosan egy kernelre van szüksége, amely az interfészét birtokolja, és ez a tény a Proxmox-elhelyezés vitájának nagy részét eldönti, mielőtt a teljesítmény egyáltalán szóba kerülne. Az LXC-konténer a gazdagép kernelének névtér-nézete, míg a VM a sajátját indítja. A hasznos kérdés tehát nem az, melyik lehetőség könnyebb, hanem hogy melyik kernelt hajlandó módosítani, és melyik helyreállítási úttal tud együtt élni. Válaszoljon erre, és a gazdagép, konténer vagy VM közötti választás általában magától megszületik.

Az LXC-vendég a gazdagép kernelén belül működik

A wireguard-tools konténeren belüli telepítése a vezérlőprogramot adja, nem privát kernelt. A létrehozott wg0 interfész a gazdagép hálózati vermében regisztrálódik, és megjelenik a gazdagép modullistáján. Ezért egy konténer minden csomagellenőrzést átadhat, és mégis elbukhat az első wg parancsnál, ha a gazdagép kerneléből hiányzik a modul. És a Proxmox konténerreferenciája dokumentálja ezt a megosztott kernelű modellt, valamint a névtér- és jogosultsági határokat, amelyeken belül dolgozik.

A második korlát a jogosultság. Az interfész felhozatala és címek hozzákapcsolása hálózatkezelési jogokat igényel az őt birtokló névtéren belül, és a nem privilegizált konténer ezeket a jogokat a felhasználói névterén keresztül képezi le, ahelyett hogy közvetlenül tartaná őket. Soha ne a teljes jogosultság legyen az első válasz; nézze meg, mit kérnek valójában a konténertől, és azt adja meg.

A gazdagép kernelje is megosztott függőség. Egy Proxmox kernel-frissítés egyszerre változtatja meg a WireGuard megvalósítását minden konténer alatt, ami kényelmes addig, amíg egy frissítés és egy konténer elvárásai össze nem ütköznek.

Gazdagép, konténer, VM: mit birtokol valójában az egyes elhelyezések

A gazdagépre helyezés a VPN-t a hipervizor saját hálózatába teszi. Az útvonalak, a tűzfalszabályok és az alagút a gazdagép helyreállításának részévé válnak, és egy hiba ott magával viheti a kezelőfelületet. Ez elfogadható infrastruktúra-útvonalválasztáshoz egy olyan gazdagépen, amelyet konzolon keresztül ér el, és fájdalmas egy távoli gépen, sávon kívüli hozzáférés nélkül.

A konténer a szolgáltatást csomagoltan és újraindíthatóan tartja, miközben továbbra is kölcsönveszi a gazdagép kernelét. Szándékosan megosztott kernelű szolgáltatáshoz illik, és kis egységet ad az újraépítéshez. Nem ad független kernelt, ezért bármi, ami konkrét modulépítést igényel, elmutat ettől a lehetőségtől.

A VM több memóriába és még egy javítandó rendszerbe kerül, cserébe az alagút saját kernelt, saját útvonaltáblát és pillanatkép-határt kap. Amikor a VPN az, amit egy rossz változtatás után visszaállít, az a pillanatkép megéri a többletet.

Három feltétel, amely Ön helyett választ

Ha az alagútnak olyan kernelverzióra vagy WireGuard-funkcióra van szüksége, amelyet a Proxmox-gazdagép nem kínál, álljon meg itt, és használjon VM-et. Újabb kernelt nem lehet konténerbe telepíteni, és a hipervizor kernelét sem kellene lecserélni egyetlen vendég kedvéért.

Ha az alagút a telephely átjárója valódi LAN-előtagokhoz, kérdezze meg, ki birtokolja már a visszaútvonalat. A konténer tud forgalmat irányítani, de az interfészei a gazdagép vermében ülnek, így a gazdagép végül a konfiguráció egy részét hordozza, akár tervezte ezt, akár nem. A gazdagépre helyezés őszinte ebben; a konténerbe helyezés gyakran nem.

Ezután mérlegelje egy hiba hatókörét. Egy konténer újraindítása olcsó, egy VM-pillanatkép visszaállítása kiszámítható, a gazdagép hálózatának javítása pedig fizikai vagy konzol-hozzáférést igényelhet. A helyes választás az, amelynek legrosszabb esetét valóban helyre tudja állítani abban az órában, amikor bekövetkezik.

Egy negyedik kérdés ritkán döntő, de kimondásra érdemes: kell-e még valaminek a gazdagépen látnia az alagút interfészét? Ha igen, a gazdagépre vagy konténerbe helyezés helyben tartja ezt a láthatóságot, míg a VM arra kényszeríti, hogy a vendég és a gazdagép között irányítson.

Bizonyítsa a helyet, mielőtt forgalmat irányít rajta keresztül

Telepítés után erősítse meg, melyik kernel szolgálja ki valójában az interfészt, és kapott-e a konténer elég jogosultságot a megtartásához:

$ 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

Ezután ellenőrizze a továbbítási oldalt a gazdagépről, mert egy kézfogás önmagában csak azt bizonyítja, hogy az alagút áll. Használja a ip route get-öt egy kliens címéhez, és erősítse meg, hogy a következő ugrás és az interfész megfelel a tervnek, és hogy a visszaút létezik a túloldalon.

Hagyja a telepítést írott tulajdonossal: melyik kernel hordozza a megvalósítást, melyik névtér tartja az interfészt, és mely előtagokat továbbíthatja az átjáró. Ez a mondat több incidenst előz meg, mint a három elhelyezés bármilyen benchmark-összehasonlítása.