WireGuard potrzebuje dokładnie jednego jądra, które jest właścicielem jego interfejsu, i ten fakt rozstrzyga większość sporu o umiejscowienie na Proxmoxie, zanim wydajność w ogóle wejdzie do rozmowy. Kontener LXC to widok przestrzeni nazw jądra hosta, a VM uruchamia własne. Sensowne pytanie nie brzmi więc, która opcja jest lżejsza, ale które jądro jesteś gotów zmieniać i z jaką ścieżką odzyskiwania możesz żyć. Odpowiedz na to, a wybór między hostem, kontenerem a VM zwykle dokonuje się sam.

Gość LXC pracuje wewnątrz jądra hosta

Zainstalowanie wireguard-tools w kontenerze daje program sterujący, a nie prywatne jądro. Tworzony interfejs wg0 rejestruje się w stosie sieciowym hosta i pojawia się na jego liście modułów. Dlatego kontener może przejść każdą kontrolę pakietów i mimo to zawieść na pierwszym poleceniu wg, gdy w jądrze hosta brakuje modułu. A dokumentacja kontenerów Proxmox opisuje ten model współdzielonego jądra wraz z granicami przestrzeni nazw i uprawnień, w których pracujesz.

Uprawnienia to drugie ograniczenie. Podniesienie interfejsu i przypisanie do niego adresów wymaga praw administracji siecią w przestrzeni nazw, która go posiada, a nieuprzywilejowany kontener mapuje te prawa przez swoją przestrzeń nazw użytkownika, zamiast trzymać je bezpośrednio. Nigdy nie sięgaj po pełne uprawnienia jako pierwszą odpowiedź; sprawdź, czego naprawdę wymaga się od kontenera, i dopiero to przyznaj.

Jądro hosta jest też współdzieloną zależnością. Aktualizacja jądra Proxmox zmienia implementację WireGuard pod każdym kontenerem naraz, co jest wygodne, dopóki aktualizacja i oczekiwania kontenera się nie rozjadą.

Host, kontener, VM: co naprawdę posiada każde umiejscowienie

Umiejscowienie na hoście umieszcza VPN w sieci samego hipernadzorcy. Trasy, reguły zapory i tunel stają się częścią odzyskiwania hosta, a błąd tam może zabrać ze sobą interfejs zarządzania. To akceptowalne dla routingu infrastruktury na hoście dostępnym przez konsolę, i bolesne na zdalnej maszynie bez dostępu poza pasmem.

Kontener trzyma usługę zapakowaną i restartowalną, wciąż pożyczając jądro hosta. Pasuje do świadomie współdzielonej usługi jądra i daje małą jednostkę do odbudowy. Nie daje niezależnego jądra, więc wszystko, co wymaga konkretnej kompilacji modułu, wskazuje z dala od tej opcji.

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 kosztuje więcej pamięci i jeszcze jednego systemu do łatania, a w zamian tunel dostaje własne jądro, własną tablicę routingu i granicę migawki. Gdy VPN jest tym, co cofasz po złej zmianie, ta migawka jest warta narzutu.

Trzy warunki, które wybierają za ciebie

Jeśli tunel potrzebuje wersji jądra lub funkcji WireGuard, której host Proxmox nie dostarcza, zatrzymaj się tutaj i użyj VM. Nie da się zainstalować nowszego jądra w kontenerze i nie należy wymieniać jądra hipernadzorcy, by zadowolić jednego gościa.

Jeśli tunel jest bramą witryny dla prawdziwych prefiksów LAN, zapytaj, kto już jest właścicielem trasy powrotnej. Kontener potrafi routować ruch, ale jego interfejsy siedzą w stosie hosta, więc host ostatecznie niesie część konfiguracji, niezależnie od tego, czy to planowałeś. Umiejscowienie na hoście jest w tym uczciwe; umiejscowienie w kontenerze często nie.

Następnie zważ promień rażenia błędu. Restart kontenera jest tani, przywrócenie migawki VM przewidywalne, a naprawa sieci hosta może wymagać dostępu fizycznego lub konsoli. Właściwy wybór to ten, którego najgorszy przypadek naprawdę potrafisz odzyskać w godzinie, w której się zdarzy.

Czwarte pytanie rzadko jest rozstrzygające, ale warto je wypowiedzieć: czy coś jeszcze na hoście musi widzieć interfejs tunelu? Jeśli tak, umiejscowienie na hoście lub w kontenerze utrzymuje tę widoczność lokalnie, a VM zmusza cię do routowania między gościem a hostem.

Udowodnij umiejscowienie, zanim puścisz przez nie ruch

Po instalacji potwierdź, które jądro faktycznie obsługuje interfejs i czy kontener dostał dość uprawnień, by go utrzymać:

$ 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

Potem sprawdź stronę przekazywania z hosta, bo samo uścisk dłoni dowodzi tylko, że tunel stoi. Użyj ip route get dla adresu klienta i potwierdź, że następny skok i interfejs zgadzają się z projektem, a trasa powrotna istnieje po drugiej stronie.

Zostaw wdrożenie z zapisanym właścicielem: które jądro niesie implementację, która przestrzeń nazw trzyma interfejs i które prefiksy brama może przekazywać. To zdanie zapobiega większej liczbie incydentów niż jakiekolwiek porównanie benchmarków trzech umiejscowień.

Powiązane artykuły