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 प्रयोग गर्नुहोस् र अर्को हप र इन्टरफेस डिजाइनसँग मिल्छन्, र टाढाको पक्षमा फर्कने मार्ग छ भनी पुष्टि गर्नुहोस्।
तैनाती लिखित मालिकसँग छोड्नुहोस्: कुन कर्नेलले कार्यान्वयन बोक्छ, कुन नेमस्पेसले इन्टरफेस राख्छ, र गेटवेलाई कुन प्रिफिक्स फर्वार्ड गर्न अनुमति छ। त्यो एउटा वाक्यले तीन राखाइको कुनै पनि बेन्चमार्क तुलनाभन्दा बढी घटना रोक्छ।