WireGuard në LXC ose në një VM në Proxmox: ku duhet të ekzekutohet?

WireGuard ka nevojë për saktësisht një kernel që zotëron ndërfaqen e tij, dhe ky fakt zgjidh pjesën më të madhe të debatit për vendosjen në Proxmox para se performanca të hyjë fare në bisedë. Një kontejner LXC është një pamje e hapësirës së emrave të kernelit të hostit, ndërsa një VM nis kernelin e vet. Pra pyetja e dobishme nuk është cili opsion është më i lehtë, por cilin kernel jeni të gatshëm të ndryshoni dhe me cilën rrugë rikuperimi mund të jetoni. Përgjigjuni kësaj dhe zgjedhja midis hostit, kontejnerit ose VM zakonisht bëhet vetë.

Një mysafir LXC punon brenda kernelit të hostit

Instalimi i wireguard-tools brenda një kontejneri ju jep programin e kontrollit, jo një kernel privat. Ndërfaqja wg0 që krijoni regjistrohet në stivën e rrjetit të hostit dhe shfaqet në listën e moduleve të tij. Kjo është arsyeja pse një kontejner mund të kalojë çdo kontroll paketash dhe prapë të dështojë në komandën e parë wg kur kernelit të hostit i mungon moduli. Dhe referenca e kontejnerëve të Proxmox dokumenton atë model kernel të përbashkët, së bashku me kufijtë e hapësirës së emrave dhe të privilegjeve brenda të cilëve punoni.

Autoriteti është kufizimi i dytë. Ngritja e një ndërfaqeje dhe lidhja e adresave me të kërkon të drejta administrimi rrjeti brenda hapësirës së emrave që e zotëron, dhe një kontejner pa privilegje i harton ato të drejta përmes hapësirës së emrave të përdoruesit të vet në vend që t'i mbajë drejtpërdrejt. Kurrë mos u drejtoni te privilegji i plotë si përgjigja e parë; shikoni çfarë kërkohet në të vërtetë nga kontejneri dhe pastaj jepeni atë.

Kerneli i hostit është gjithashtu një varësi e përbashkët. Një përditësim i kernelit të Proxmox ndryshon implementimin e WireGuard nën çdo kontejner njëherësh, gjë që është e përshtatshme derisa një përditësim dhe pritjet e një kontejneri nuk pajtohen.

Host, kontejner, VM: çfarë zotëron në të vërtetë secila vendosje

Vendosja në host e vë VPN-në në rrjetin e vetë hipervizorit. Rrugët, rregullat e firewall-it dhe tuneli bëhen pjesë e rikuperimit të hostit, dhe një gabim atje mund të marrë me vete edhe ndërfaqen e menaxhimit. Kjo është e pranueshme për rrugëtimin e infrastrukturës në një host që e arrini përmes konsolës, dhe e dhimbshme në një makinë të largët pa akses jashtë brezit.

Një kontejner e mban shërbimin të paketuar dhe të rinisëshëm ndërsa vazhdon të marrë hua kernelin e hostit. Përshtatet për një shërbim të qëllimshëm me kernel të përbashkët dhe ju jep një njësi të vogël për të rindërtuar. Nuk ju jep një kernel të pavarur, prandaj çdo gjë që kërkon një ndërtim specifik moduli tregon larg këtij opsioni.

Një VM kushton më shumë memorie dhe një sistem tjetër për t'u rregulluar, dhe në këmbim tuneli merr kernelin e vet, tabelën e vet të rrugëtimit dhe një kufi snapshot. Kur VPN-ja është ajo që kthehet pas një ndryshimi të keq, ai snapshot ia vlen mbingarkesa.

Tre kushte që zgjedhin për ju

Nëse tunelit i duhet një version kerneli ose një veçori WireGuard që hosti Proxmox nuk e ofron, ndaloni këtu dhe përdorni një VM. Nuk mund të instaloni një kernel më të ri në një kontejner, dhe nuk duhet të zëvendësoni kernelin e hipervizorit për të kënaqur një mysafir të vetëm.

Nëse tuneli është porta e faqes për parashtesat reale LAN, pyesni kush e zotëron tashmë rrugën e kthimit. Një kontejner mund të rrugëtojë trafikun, por ndërfaqet e tij qëndrojnë në stivën e hostit, kështu që hosti përfundimisht mban një pjesë të konfigurimit, pavarësisht nëse e kishit planifikuar apo jo. Vendosja në host është e sinqertë për këtë; vendosja në kontejner shpesh nuk është.

Pastaj peshoni rrezen e ndikimit të një gabimi. Rinisja e një kontejneri është e lirë, rikthimi i një snapshot VM është i parashikueshëm, dhe riparimi i rrjetit të hostit mund të kërkojë akses fizik ose konsol. Zgjedhja e duhur është ajo rasti më i keq i së cilës mund të rikuperohet vërtet në orën kur ndodh.

Një pyetje e katërt rrallë është vendimtare, por ia vlen të thuhet: a ka nevojë diçka tjetër në host të shohë ndërfaqen e tunelit? Nëse po, vendosja në host ose në kontejner e mban atë dukshmëri lokale, ndërsa një VM ju detyron të rrugëtoni midis mysafirit dhe hostit.

Provoni vendosjen para se të kaloni trafik përmes saj

Pas instalimit, konfirmoni cili kernel po i shërben në të vërtetë ndërfaqes dhe nëse kontejnerit i është dhënë autoritet i mjaftueshëm për ta mbajtur:

$ 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

Pastaj kontrolloni anën e përçimit nga hosti, sepse një shtrëngim duarsh i vetëm vërteton vetëm se tuneli është lart. Përdorni ip route get për një adresë klienti dhe konfirmoni që kërcimi i radhës dhe ndërfaqja përputhen me projektin, dhe që rruga e kthimit ekziston në anën e largët.

Lëreni vendosjen me një pronar të shkruar: cili kernel mban implementimin, cila hapësirë emrash mban ndërfaqen dhe cilat parashtesa porta lejohet të përçojë. Ai fjali parandalon më shumë incidente sesa çdo krahasim benchmark i tre vendosjeve.