WireGuard în LXC sau într-o VM pe Proxmox: unde ar trebui să ruleze?

WireGuard are nevoie de exact un nucleu care să dețină interfața sa, iar acest fapt închide cea mai mare parte a dezbaterii despre plasarea pe Proxmox înainte ca performanța să intre măcar în discuție. Un container LXC este o vedere a spațiului de nume al nucleului gazdă, în timp ce o VM pornește propriul nucleu. Deci întrebarea utilă nu este care opțiune este mai ușoară, ci pe care nucleu sunteți dispus să îl modificați și cu ce cale de recuperare puteți trăi. Răspundeți la asta, iar alegerea între gazdă, container sau VM se face de obicei singură.

Un invitat LXC lucrează în interiorul nucleului gazdă

Instalarea wireguard-tools într-un container vă dă programul de control, nu un nucleu privat. Interfața wg0 pe care o creați este înregistrată în stiva de rețea a gazdei și apare în lista sa de module. De aceea un container poate trece toate verificările de pachete și totuși poate eșua la prima comandă wg când nucleului gazdei îi lipsește modulul. Și referința containerelor Proxmox documentează acel model de nucleu partajat, împreună cu limitele de spațiu de nume și de privilegii în care lucrați.

Autoritate este a doua constrângere. Ridicarea unei interfețe și atașarea de adrese la ea necesită drepturi de administrare a rețelei în spațiul de nume care o deține, iar un container neprivilegiat mapează acele drepturi prin spațiul său de nume de utilizator în loc să le dețină direct. Nu recurgeți niciodată la privilegiul complet ca prim răspuns; priviți ce i se cere de fapt containerului și apoi acordați exact asta.

Nucleul gazdei este și o dependență partajată. O actualizare a nucleului Proxmox schimbă implementarea WireGuard sub fiecare container deodată, ceea ce este comod până când o actualizare și așteptările unui container nu mai sunt de acord.

Gazdă, container, VM: ce deține de fapt fiecare plasare

Plasarea pe gazdă pune VPN-ul în rețeaua proprie a hipervizorului. Rutele, regulile de firewall și tunelul devin parte din recuperarea gazdei, iar o greșeală acolo poate lua cu ea interfața de administrare. Asta este acceptabil pentru rutarea infrastructurii pe o gazdă la care ajungeți prin consolă, și dureros pe o mașină îndepărtată fără acces în afara benzii.

Un container ține serviciul împachetat și repornibil în timp ce împrumută în continuare nucleul gazdei. Se potrivește unui serviciu deliberat cu nucleu partajat și vă dă o unitate mică de reconstruit. Nu vă dă un nucleu independent, așa că tot ce necesită o compilare de modul specific indică departe de această opțiune.

O VM costă mai multă memorie și încă un sistem de peticit, iar în schimb tunelul primește propriul nucleu, propriul tabel de rutare și o graniță de instantaneu. Când VPN-ul este ceea ce readuceți după o schimbare proastă, acel instantaneu merită suprasarcina.

Trei condiții care aleg în locul dumneavoastră

Dacă tunelul are nevoie de o versiune de nucleu sau de o funcție WireGuard pe care gazda Proxmox nu o oferă, opriți-vă aici și folosiți o VM. Nu puteți instala un nucleu mai nou într-un container și nu ar trebui să înlocuiți nucleul hipervizorului pentru a satisface un singur invitat.

Dacă tunelul este poarta site-ului pentru prefixe LAN reale, întrebați cine deține deja ruta de întoarcere. Un container poate ruta trafic, dar interfețele sale stau în stiva gazdei, așa că gazda ajunge să poarte o parte din configurație, indiferent dacă ați planificat asta sau nu. Plasarea pe gazdă este onestă în privința asta; plasarea într-un container adesea nu este.

Apoi cântăriți raza de impact a unei greșeli. Repornirea unui container este ieftină, restaurarea unui instantaneu de VM este previzibilă, iar repararea rețelei gazdei poate necesita acces fizic sau la consolă. Alegerea corectă este cea al cărei cel mai rău caz îl puteți recupera cu adevărat la ora la care se întâmplă.

O a patra întrebare este rareori decisivă, dar merită spusă: mai are ceva de pe gazdă nevoie să vadă interfața tunelului? Dacă da, plasarea pe gazdă sau într-un container păstrează acea vizibilitate locală, în timp ce o VM vă obligă să rutați între invitat și gazdă.

Dovediți plasarea înainte de a ruta trafic prin ea

După instalare, confirmați care nucleu servește de fapt interfața și dacă containerului i s-a acordat suficientă autoritate pentru a o păstra:

$ 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

Apoi verificați partea de redirecționare de pe gazdă, pentru că o strângere de mână dovedește doar că tunelul este sus. Folosiți ip route get pentru o adresă de client și confirmați că următorul salt și interfața corespund proiectului, și că ruta de întoarcere există în partea cealaltă.

Lăsați implementarea cu un proprietar scris: care nucleu poartă implementarea, ce spațiu de nume ține interfața și ce prefixe are voie poarta să redirecționeze. Acea propoziție previne mai multe incidente decât orice comparație de referință a celor trei plasări.