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 ही वह चीज़ हो जिसे आप वापस लौटाते हैं, तो वह स्नैपशॉट अतिरिक्त बोझ के लायक है।
तीन शर्तें जो आपके लिए चुनती हैं
अगर टनल को ऐसा कर्नेल संस्करण या WireGuard सुविधा चाहिए जो Proxmox होस्ट नहीं देता, तो यहीं रुकें और 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 इस्तेमाल करें और पुष्टि करें कि अगला हॉप और इंटरफ़ेस डिज़ाइन से मेल खाते हैं, और दूर वाले पक्ष पर वापसी मार्ग मौजूद है।
तैनाती को लिखित मालिक के साथ छोड़ें: कौन-सा कर्नेल कार्यान्वयन ढोता है, कौन-सा नेमस्पेस इंटरफ़ेस रखता है, और गेटवे को कौन-से प्रीफ़िक्स फ़ॉरवर्ड करने की अनुमति है। वह एक वाक्य तीनों प्लेसमेंट की किसी भी बेंचमार्क तुलना से अधिक घटनाएँ रोकता है।