Proxmox-та LXC немесе VM ішінде WireGuard: оны қайда жүргізу керек?
WireGuard Proxmox хостында, контейнерде немесе VM ішінде жұмыс істей алады. Шешуші факторлар — ядроға иелік, интерфейсті бақылау және қалпына келтіру.
WireGuard өз интерфейсіне ие болатын дәл бір ядроны қажет етеді, және бұл факт өнімділік әңгімеге кірмей тұрып Proxmox-та орналастыру дауының көбін шешеді. LXC контейнері — хост ядросының атаулар кеңістігінің көрінісі, ал VM өз ядросын жүктейді. Сондықтан пайдалы сұрақ қай нұсқа жеңілірек екені емес, қай ядроны өзгертуге дайын екеніңіз және қай қалпына келтіру жолымен өмір сүре алатыныңыз. Осыған жауап берсеңіз, хост, контейнер немесе VM таңдауы әдетте өзінен-өзі жасалады.
LXC қонағы хост ядросының ішінде жұмыс істейді
Контейнер ішінде wireguard-tools орнату сізге басқару бағдарламасын береді, жеке ядро емес. Сіз жасаған wg0 интерфейсі хосттың желілік стекінде тіркеледі және хосттың модульдер тізімінде көрінеді. Сондықтан контейнер барлық пакет тексерістерінен өтіп, хост ядросында модуль болмаған кезде бірінші wg командасында сәтсіздікке ұшырауы мүмкін. Және Proxmox контейнерлерінің анықтамалығы осы ортақ ядро моделін, сондай-ақ сіз жұмыс істейтін атаулар кеңістігі мен артықшылық шекараларын құжаттайды.
Өкілеттік — екінші шектеу. Интерфейсті көтеріп, оған мекенжайларды қосу үшін оны иеленетін атаулар кеңістігінің ішіндегі желілік әкімшілік құқықтары қажет, ал артықшылығы жоқ контейнер бұл құқықтарды тікелей ұстаудың орнына өз пайдаланушы атаулар кеңістігі арқылы салыстырады. Бірінші жауап ретінде ешқашан толық артықшылыққа ұмтылмаңыз; контейнерден шын мәнінде не талап етілетінін қарап, соны беріңіз.
Хост ядросы да ортақ тәуелділік. Proxmox ядросын жаңарту WireGuard іске асырылуын барлық контейнерлердің астында бірден өзгертеді, бұл жаңарту мен контейнер күтетін нәрселер қайшы келмейінше қолайлы.
Хост, контейнер, VM: әр орналастыру шын мәнінде неге ие
Хостқа орналастыру VPN-ны гипервизордың өз желісіне қояды. Маршруттар, firewall ережелері және туннель хостты қалпына келтірудің бөлігі болады, ал ондағы қате басқару интерфейсін де алып кете алады. Бұл консоль арқылы жететін хостта инфрақұрылымдық маршруттау үшін қолайлы, ал жолақтан тыс қатынас жоқ қашықтағы машинада ауыр.
Контейнер қызметті қапталған және қайта іске қосылатын күйде ұстайды, сонымен бірге хост ядросын қарызға алады. Ол әдейі ортақ ядролы қызметке жарайды және қайта құру үшін шағын бірлік береді. Ол дербес ядро бермейді, сондықтан нақты модуль құрастыруын қажет ететін кез келген нәрсе осы нұсқадан алыстайды.
| Placement | Kernel owner | Typical failure mode |
|---|---|---|
| Proxmox host | Hypervisor | A routing change breaks host management access |
| LXC container | Host kernel, container namespace | Missing capability or missing module at wg0 creation |
| Virtual machine | Guest kernel | Extra maintenance and a second patch cycle |
VM көбірек жады мен патчтауды қажет ететін тағы бір жүйеге тұрады, ал орнына туннель өз ядросын, өз маршруттау кестесін және snapshot шекарасын алады. Егер жаман өзгерістен кейін кері қайтаратын нәрсе VPN болса, сол snapshot қосымша жүктемеге тұрарлық.
Сіздің орныңызға таңдайтын үш шарт
Егер туннельге Proxmox хост ұсынбайтын ядро нұсқасы немесе WireGuard мүмкіндігі қажет болса, осында тоқтап, VM қолданыңыз. Контейнерге жаңарақ ядро орнату мүмкін емес, әрі бір қонақты қанағаттандыру үшін гипервизор ядросын ауыстыруға болмайды.
Егер туннель нақты LAN префикстері үшін сайттың шлюзі болса, қайтару маршруты кімге тиесілі екенін сұраңыз. Контейнер трафикті маршруттай алады, бірақ оның интерфейстері хост стегінде отырады, сондықтан хост конфигурацияның бір бөлігін көтереді, оны жоспарлағаныңызға қарамастан. Хостқа орналастыру бұл жағынан адал; контейнерге орналастыру жиі олай емес.
Сосын қатенің әсер радиусын өлшеңіз. Контейнерді қайта іске қосу арзан, VM snapshot-ын қалпына келтіру болжамды, ал хосттың желісін жөндеу физикалық немесе консольдік қатынасты қажет етуі мүмкін. Дұрыс таңдау — ең нашар жағдайын сол орын алған сағатта шынымен қалпына келтіре алатын нұсқа.
Төртінші сұрақ сирек шешуші болады, бірақ айтуға тұрарлық: хосттағы басқа бір нәрсеге туннель интерфейсін көру керек пе? Егер иә болса, хостқа немесе контейнерге орналастыру бұл көрінушілікті жергілікті ұстайды, ал VM сізді қонақ пен хост арасында маршруттауға мәжбүр етеді.
Трафикті оның ішінен өткізбес бұрын орналастыруды дәлелдеңіз
Орнатқаннан кейін интерфейске шын мәнінде қай ядро қызмет етіп тұрғанын және контейнерге оны ұстап тұруға жеткілікті өкілеттік берілгенін растаңыз:
$ 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
Сосын хосттан жіберу жағын тексеріңіз, өйткені қол алысу туннельдің тұрғанын ғана дәлелдейді. Клиент мекенжайы үшін ip route get қолданыңыз және келесі секіріс пен интерфейс жобаға сәйкес келетінін, ал қайтару жолы алыс жақта бар екенін растаңыз.
Орналастыруды жазбаша иесімен қалдырыңыз: қай ядро іске асырылуды көтереді, қай атаулар кеңістігі интерфейсті ұстайды және шлюзге қай префикстерді жіберуге рұқсат. Сол бір сөйлем үш орналастырудың кез келген салыстыруынан да көп оқиғаны болдырмайды.