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 колдонуңуз жана кийинки секирик менен интерфейс долбоорго дал келерин, ал эми кайтаруу жолу алыс тарапта бар экенин ырастаңыз.
Жайгаштырууну жазуу түрүндөгү ээси менен калтырыңыз: кайсы ядро ишке ашырылышты көтөрөт, кайсы аттар мейкиндиги интерфейсти кармайт жана дарбазага кайсы префикстерди өткөрүүгө уруксат. Ошол бир сүйлөм үч жайгаштыруунун каалаган салыштыруусунан да көп окуяны алдын алат.