Proxmox वर LXC किंवा VM मध्ये WireGuard: ते कुठे चालवायला हवे?
WireGuard Proxmox होस्टवर, कंटेनरमध्ये किंवा VM मध्ये चालू शकतो। निर्णायक घटक म्हणजे कर्नेलची मालकी, इंटरफेसवरील नियंत्रण आणि पुनर्प्राप्ती।
WireGuard ला त्याच्या इंटरफेसची मालकी घेण्यासाठी नेमका एक कर्नेल आवश्यक असतो, आणि ही गोष्ट कार्यक्षमता चर्चेत येण्याआधीच Proxmox प्लेसमेंटच्या बहुतेक वादाची निकाली काढते। LXC कंटेनर होस्ट कर्नेलच्या नेमस्पेसचे दृश्य आहे, तर VM स्वतःचे कर्नेल बूट करते। त्यामुळे उपयुक्त प्रश्न कोणता पर्याय हलका आहे हा नाही, तर तुम्ही कोणते कर्नेल बदलायला तयार आहात आणि कोणत्या पुनर्प्राप्ती मार्गासोबत जगू शकता हा आहे। त्याचे उत्तर द्या, आणि होस्ट, कंटेनर किंवा VM ही निवड सहसा स्वतःच होते।
LXC पाहुणा होस्ट कर्नेलच्या आत काम करतो
कंटेनरमध्ये wireguard-tools स्थापित केल्याने तुम्हाला नियंत्रण कार्यक्रम मिळतो, खाजगी कर्नेल नाही। तुम्ही तयार करता तो wg0 इंटरफेस होस्टच्या नेटवर्क स्टॅकमध्ये नोंदवला जातो आणि होस्टच्या मॉड्यूल यादीत दिसतो। म्हणूनच कंटेनर प्रत्येक पॅकेज तपासणी पास होऊनही पहिल्या wg कमांडवर अयशस्वी होऊ शकतो, जेव्हा होस्ट कर्नेलमध्ये ते मॉड्यूल नसते। आणि Proxmox कंटेनर संदर्भ त्या सामायिक-कर्नेल प्रतिमानाचे, तसेच तुम्ही ज्या नेमस्पेस आणि विशेषाधिकार सीमांमध्ये काम करता त्यांचे दस्तऐवजीकरण करतो।
अधिकार हा दुसरा अडथळा आहे। इंटरफेस वर आणणे आणि त्यावर पत्ते जोडणे यासाठी त्याची मालकी असलेल्या नेमस्पेसच्या आत नेटवर्क-प्रशासन अधिकार आवश्यक आहेत, आणि अविशेषाधिकारित कंटेनर ते अधिकार थेट ठेवण्याऐवजी त्याच्या वापरकर्ता नेमस्पेसद्वारे मॅप करतो। पहिले उत्तर म्हणून कधीही पूर्ण विशेषाधिकाराकडे वळू नका; कंटेनरकडून प्रत्यक्षात काय मागितले जाते ते पाहा, आणि मग तेच द्या।
होस्ट कर्नेलही सामायिक अवलंबित्व आहे। Proxmox कर्नेल अद्ययावत प्रत्येक कंटेनरखालील WireGuard अंमलबजावणी एकाच वेळी बदलते, जे अद्ययावत आणि कंटेनरच्या अपेक्षा जुळत नाहीत तोपर्यंत सोयीचे असते।
होस्ट, कंटेनर, VM: प्रत्येक प्लेसमेंट प्रत्यक्षात काय ठेवते
होस्टवरील प्लेसमेंट VPN ला हायपरव्हायझरच्या स्वतःच्या नेटवर्कमध्ये ठेवते। मार्ग, फायरवॉल नियम आणि बोगदा होस्ट पुनर्प्राप्तीचा भाग बनतात, आणि तिथली चूक व्यवस्थापन इंटरफेसही घेऊन जाऊ शकते। कन्सोलद्वारे पोहोचता येणाऱ्या होस्टवर पायाभूत सुविधा मार्गनिर्देशनासाठी हे स्वीकारार्ह आहे, आणि बँडबाहेरील प्रवेश नसलेल्या दूरच्या मशीनवर वेदनादायक।
कंटेनर सेवा पॅकेज केलेली आणि पुन्हा सुरू करण्यायोग्य ठेवतो, तर तरीही होस्ट कर्नेल उधार घेतो। जाणीवपूर्वक सामायिक-कर्नेल सेवेसाठी तो योग्य आहे आणि पुनर्बांधणीसाठी लहान एकक देतो। तो स्वतंत्र कर्नेल देत नाही, म्हणून विशिष्ट मॉड्यूल बिल्ड आवश्यक असलेले काहीही या पर्यायापासून दूर निर्देश करते।
| 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 अधिक मेमरी आणि दुरुस्ती करायची अजून एक प्रणाली खर्च करते, आणि बदल्यात बोगद्याला स्वतःचे कर्नेल, स्वतःचे मार्गनिर्देशन तक्ते आणि स्नॅपशॉट सीमा मिळते। वाईट बदलानंतर VPN हीच गोष्ट तुम्ही मागे फिरवत असाल, तर तो स्नॅपशॉट अतिरिक्त भाराला पात्र आहे।
तुमच्यासाठी निवडणाऱ्या तीन अटी
बोगद्याला Proxmox होस्ट पुरवत नसलेली कर्नेल आवृत्ती किंवा WireGuard सुविधा आवश्यक असल्यास, इथे थांबा आणि VM वापरा। कंटेनरमध्ये नवीन कर्नेल स्थापित करता येत नाही, आणि एका पाहुण्याला संतुष्ट करण्यासाठी हायपरव्हायझर कर्नेल बदलू नये।
बोगदा खऱ्या LAN प्रीफिक्ससाठी साइटचा गेटवे असेल, तर परतीच्या मार्गाची मालकी आधीच कोणाकडे आहे ते विचारा। कंटेनर रहदारी मार्गनिर्देशित करू शकतो, पण त्याचे इंटरफेस होस्टच्या स्टॅकमध्ये बसतात, त्यामुळे होस्ट शेवटी संरचनेचा काही भाग वाहतो, तुम्ही त्याची योजना केली असो वा नसो। होस्टवरील प्लेसमेंट याबाबत प्रामाणिक आहे; कंटेनरमधील प्लेसमेंट अनेकदा नाही।
मग चुकीच्या परिणामाची त्रिज्या तोलून पाहा। कंटेनर पुन्हा सुरू करणे स्वस्त आहे, VM स्नॅपशॉट पुनर्संचयित करणे अंदाजयोग्य आहे, आणि होस्ट नेटवर्किंग दुरुस्त करण्यासाठी भौतिक किंवा कन्सोल प्रवेश लागू शकतो। योग्य निवड ती आहे जिची सर्वात वाईट परिस्थिती ती घडते त्या तासात तुम्ही खरोखर पुनर्प्राप्त करू शकता।
चौथा प्रश्न क्वचितच निर्णायक असतो पण म्हणण्यासारखा आहे: होस्टवरील दुसऱ्या कशाला बोगद्याचा इंटरफेस पाहण्याची गरज आहे का? होय असल्यास, होस्टवर किंवा कंटेनरमधील प्लेसमेंट ती दृश्यता स्थानिक ठेवते, तर 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 वापरा आणि पुढील हॉप व इंटरफेस रचनेशी जुळतात, आणि दूरच्या बाजूला परतीचा मार्ग आहे याची खात्री करा।
तैनाती लिखित मालकासोबत सोडा: कोणते कर्नेल अंमलबजावणी वाहते, कोणता नेमस्पेस इंटरफेस ठेवतो, आणि गेटवेला कोणते प्रीफिक्स फॉरवर्ड करण्याची परवानगी आहे। ते एक वाक्य तीन प्लेसमेंटच्या कोणत्याही बेंचमार्क तुलनेपेक्षा अधिक घटना टाळते।