WireGuard-ը LXC-ում կամ VM-ում Proxmox-ի վրա. որտե՞ղ պետք է այն աշխատի։
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-ը արժե ավելորդ ծախսը։
Երեք պայման, որոնք ընտրում են ձեր փոխարեն
Եթե թունելին անհրաժեշտ է միջուկի տարբերակ կամ WireGuard-ի ֆունկցիա, որը Proxmox-ի հոսթը չի տրամադրում, կանգ առեք այստեղ և օգտագործեք 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 հաճախորդի հասցեի համար և հաստատեք, որ հաջորդ թռիչքը և ինտերֆեյսը համապատասխանում են նախագծին, և որ վերադարձի ուղին գոյություն ունի հեռավոր կողմում։
Թողեք տեղակայումը գրավոր տիրոջ հետ. որ միջուկն է կրում իրականացումը, որ անվանատարածքն է պահում ինտերֆեյսը, և որ նախածանցներն է դարպասին թույլատրվում փոխանցել։ Այդ մեկ նախադասությունը կանխում է ավելի շատ միջադեպեր, քան երեք տեղակայումների ցանկացած համեմատությունը։