WireGuard sa LXC o VM sa Proxmox: saan ito dapat tumakbo?

Ang WireGuard ay nangangailangan ng eksaktong isang kernel na magmamay-ari ng interface nito, at ang katotohanang iyon ay nagtatapos sa halos buong debate sa paglalagay sa Proxmox bago pa man pumasok ang performance. Ang LXC container ay isang tanaw ng namespace ng kernel ng host, habang ang VM ay nagbo-boot ng sarili nitong kernel. Kaya ang kapaki-pakinabang na tanong ay hindi kung aling opsyon ang mas magaan, kundi kung aling kernel ang handa mong baguhin at kung aling landas ng pagbawi ang kaya mong pakisamahan. Sagutin iyon, at ang pagpili sa pagitan ng host, container o VM ay kadalasang nagagawa nang kusa.

Ang LXC guest ay nagtatrabaho sa loob ng kernel ng host

Ang pag-install ng wireguard-tools sa loob ng container ay nagbibigay sa iyo ng control program, hindi pribadong kernel. Ang interface na wg0 na ginagawa mo ay nakarehistro sa network stack ng host at lumilitaw sa listahan ng module nito. Kaya naman ang isang container ay makakapasa sa lahat ng pagsusuri ng package at mauulit pa ring mabigo sa unang utos na wg kapag kulang ang kernel ng host sa module. At ang sanggunian ng container ng Proxmox ay nagdodokumento ng modelong iyon ng pinagsasaluhang kernel kasama ang mga hangganan ng namespace at pribilehiyo na iyong ginagalawan.

Ang awtoridad ang pangalawang hadlang. Ang pag-angat ng interface at pagkakabit ng mga address dito ay nangangailangan ng mga karapatang pangangasiwa ng network sa loob ng namespace na nagmamay-ari nito, at ang container na walang pribilehiyo ay nagmamapa ng mga karapatang iyon sa pamamagitan ng namespace ng user nito sa halip na hawakan ang mga ito nang direkta. Huwag kailanman dumulong sa buong pribilehiyo bilang unang sagot; tingnan kung ano ang talagang hinihiling sa container, at pagkatapos ay ibigay iyon.

Ang kernel ng host ay isa ring pinagsasaluhang dependency. Ang pag-update ng kernel ng Proxmox ay nagbabago ng implementasyon ng WireGuard sa ilalim ng bawat container nang sabay, na maginhawa hanggang sa ang isang update at ang inaasahan ng isang container ay hindi na magkasundo.

Host, container, VM: ano ang tunay na pagmamay-ari ng bawat paglalagay

Ang paglalagay sa host ay naglalagay ng VPN sa sariling network ng hypervisor. Ang mga ruta, patakaran ng firewall at ang tunnel ay nagiging bahagi ng pagbawi ng host, at ang isang pagkakamali doon ay maaaring magdala ng management interface kasama nito. Katanggap-tanggap iyon para sa pagruruta ng imprastruktura sa host na nararating mo sa pamamagitan ng console, at masakit sa malayong makina na walang access sa labas ng banda.

Ang container ay nagpapanatili ng serbisyo na nakabalot at naire-restart habang hiniram pa rin ang kernel ng host. Angkop ito sa sadyang pinagsasaluhang serbisyo ng kernel at binibigyan ka ng maliit na yunit na muling itatayo. Hindi ito nagbibigay ng malayang kernel, kaya ang anumang nangangailangan ng tiyak na build ng module ay tumuturo papalayo sa opsyong ito.

Ang VM ay gumagastos ng mas maraming memory at isa pang sistemang ipa-patch, at kapalit nito ay nakakakuha ang tunnel ng sarili nitong kernel, sariling routing table at hangganan ng snapshot. Kapag ang VPN ang bagay na ibinabalik mo pagkatapos ng masamang pagbabago, sulit ang snapshot na iyon sa karagdagang bigat.

Tatlong kundisyon na pumipili para sa iyo

Kung ang tunnel ay nangangailangan ng bersyon ng kernel o tampok ng WireGuard na hindi ibinibigay ng host ng Proxmox, huminto dito at gumamit ng VM. Hindi ka makakapag-install ng mas bagong kernel sa container, at hindi mo dapat palitan ang kernel ng hypervisor para mapasiya ang isang guest.

Kung ang tunnel ang gateway ng site para sa tunay na mga prefix ng LAN, itanong kung sino ang nagmamay-ari na ng ruta ng pagbalik. Ang container ay makakapagruta ng trapiko, ngunit ang mga interface nito ay nakaupo sa stack ng host, kaya ang host sa huli ay nagdadala ng bahagi ng configuration, planado mo man ito o hindi. Ang paglalagay sa host ay tapat tungkol dito; ang paglalagay sa container ay kadalasang hindi.

Pagkatapos ay timbangin ang saklaw ng epekto ng isang pagkakamali. Ang pag-restart ng container ay mura, ang pagpapanumbalik ng snapshot ng VM ay mahuhulaan, at ang pag-aayos ng networking ng host ay maaaring mangailangan ng pisikal o console access. Ang tamang pagpili ay ang pinakamasamang kaso nito ay tunay mong maibabalik sa oras na nangyari ito.

Ang ikaapat na tanong ay bihirang maging mapagpasya ngunit sulit sabihin: may iba pa bang bagay sa host na kailangang makakita ng interface ng tunnel? Kung oo, ang paglalagay sa host o sa container ay nagpapanatili ng visibility na iyon sa lokal, samantalang ang VM ay pumipilit sa iyong magruta sa pagitan ng guest at host.

Patunayan ang paglalagay bago mo pagdaanan ng trapiko

Pagkatapos ng pag-install, kumpirmahin kung aling kernel ang tunay na nagseserbisyo sa interface at kung ang container ay binigyan ng sapat na awtoridad upang panatilihin ito:

$ 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

Pagkatapos ay suriin ang panig ng pagpapasa mula sa host, dahil ang isang handshake lamang ay nagpapatunay lamang na ang tunnel ay nakatayo. Gamitin ang ip route get para sa address ng kliyente at kumpirmahin na ang susunod na hop at interface ay tumutugma sa disenyo, at ang landas ng pagbalik ay umiiral sa kabilang dulo.

Iwanan ang deployment na may nakasulat na may-ari: aling kernel ang nagdadala ng implementasyon, aling namespace ang may hawak ng interface at aling mga prefix ang pinapayagang ipasa ng gateway. Ang isang pangungusap na iyon ay pumipigil ng mas maraming insidente kaysa sa anumang paghahambing ng benchmark ng tatlong paglalagay.