तपाईंको VPN प्रक्रियालाई कुन Linux क्षमताहरू चाहिन्छ?
इन्टरफेस सेटअप, रुट, यन्त्र पहुँच र साधारण सकेटहरू छुट्टाछुट्टै विशेषाधिकार हुन्। CAP_NET_ADMIN दिनु अघि असफल भएको अपरेशनको नाम भन्नुहोस्।
VPN डेमनलाई विशेषाधिकार प्राप्त नेटवर्क अपरेशनहरू चाहिन्छ, यद्यपि साधारण अनुप्रयोगहरू कुनै पनि विशेषाधिकार बिना बाहिर जाने सकेटहरू खोल्छन्। यही खाडलबाट धेरैजसो क्षमता-सम्बन्धी गल्तीहरू सुरु हुन्छन्: कसैले अनुमति त्रुटि देख्छ, पूरै सेट दिन्छ, र सेवा पछि कसैले पनि व्याख्या गर्न नसक्ने कारणले चल्छ। तलको मार्गदर्शन असफल भएको अपरेशनबाट सुरु हुन्छ, त्यसलाई एउटा अधिकारसँग जोड्छ, र त्यसपछि प्रक्रिया वास्तवमा जुन सन्दर्भमा चल्छ त्यो जाँच्छ। असीमित root को रूपमा चल्नु केही परिनियोजनका लागि मान्य उत्तर हो, तर यो पूर्वनिर्धारित नभई निर्णय हुनुपर्छ।
असफल भएको अपरेशनबाट सुरु गर्नुहोस्
ट्युटोरियल पढ्नु अघि त्रुटि पढ्नुहोस्। इन्टरफेस परिवर्तनमा «अपरेशन अनुमति छैन», यन्त्र नोड खोल्न अस्वीकार र कम पोर्टमा bind असफल हुनु — यी तीन फरक समस्या हुन्, तीन फरक अनुमतिसहित। यदि प्रक्रिया सुरु भई पहिलो रुट परिवर्तनमा मात्र असफल हुन्छ भने, त्यसले इन्टरफेस निर्माण पहिले नै सफल भइसकेको पनि बताउँछ, जसले उत्तरलाई निकै साँघुरो बनाउँछ।
सेवा बन्द राखेर त्रुटि पुनः उत्पादन गर्नुहोस्, त्यसपछि कार्यान्वयनले अनुमति दिन्छ भने त्यसै प्रयोगकर्ता अन्तर्गत अग्रभागमा सुरु गर्नुहोस्। तपाईंले देख्न सक्ने त्रुटि अनुमान गर्नुपर्ने लग लाइनभन्दा राम्रो हुन्छ, र यसले क्षमता-समस्या र SELinux वा AppArmor अस्वीकारबीचको फरक स्पष्ट पार्छ।
हरेक अपरेशनलाई एउटा अधिकारसँग जोड्नुहोस्
तालिका सुरुवाती नक्सा हो, कार्यान्वयनको कागजातको विकल्प होइन:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
त्यो तालिकाका दुई पङ्क्ति नै मानिसहरूले एकअर्कामा मिसाउने पङ्क्ति हुन्। /dev/net/tun खोल्नु फाइल-अनुमतिको प्रश्न हो; तपाईंले खोलेको कुरा कन्फिगर गर्न कर्नेललाई भन्नु क्षमताको प्रश्न हो। CAP_NET_ADMIN दिँदा तपाईंको सेवा-प्रयोगकर्ताले पढ्न नसक्ने यन्त्र नोड ठीक हुँदैन, र नोड ठीक गर्दा तपाईंलाई रुट अधिकार मिल्दैन। यीमध्ये कुनै पनि बदल्नु अघि दुवै जाँच्नुहोस्।
कर्नेल WireGuard र प्रयोगकर्ता-स्पेस टनेल प्रोग्रामहरूको आवश्यकता पनि एउटै हुँदैन। कर्नेल मोड्युलको मार्गले netlink मार्फत विद्यमान इन्टरफेस कन्फिगर गर्छ, जबकि प्रयोगकर्ता-स्पेस कार्यान्वयनलाई यन्त्र पनि चाहिन सक्छ र केही यातायातका लागि कच्चा सकेट पनि।
सन्दर्भ पढ्नुहोस्: सेवा, कन्टेनर वा शेल
होस्टको नेटवर्क नेमस्पेसमा रहेको क्षमताले जानाजान छुट्याइएको स्ट्याकभित्रको त्यही अपरेशनभन्दा धेरै बढी प्रभाव पार्न सक्छ। कन्टेनर रनटाइम सामान्यतया घटाइएको सीमा-सेटसँग सुरु हुन्छ; होस्ट नेटवर्क साझा गर्ने कन्टेनरमा NET_ADMIN थप्नु आफ्नै नेटवर्क नेमस्पेस र होस्ट माउन्ट नभएको कन्टेनरमा थप्नुभन्दा धेरै ठूलो अनुमति हो।
systemd युनिटका लागि युनिट फाइल बोल्छ जस्तो देखिने होइन, वास्तवमा लागू हुने पढ्नुहोस्: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities प्रभावकारी मानहरू रिपोर्ट गर्छ, जुन तपाईंले बिर्सनुभएको drop-in ले सेट गरेको हुन सक्छ। प्रभावकारी मान माग्नुहोस्, कहिल्यै इच्छित मान होइन। Ambient क्षमताहरू महत्त्वपूर्ण छन् किनभने root नभएको सेवाले ती बिना exec भरिमा क्षमता गुमाउँछ।
प्याकेज वा इमेजको समर्थित सेटअप आधार मान्नुहोस्। अर्को ट्युटोरियलले अर्को उपकरणका लागि तिनीहरू सूचीबद्ध गरेको भरमा कच्चा सकेट अनुमति वा विशेषाधिकृत मोड नथप्नुहोस्; त्यो तर्कले केही पनि सार्दैन र तपाईंले तिर्नुभएको अलगाव गुमाउँछ। शङ्का भए केही नदिनुहोस् र तपाईंलाई आवश्यक पर्ने ठ्याक्कै अपरेशनका लागि कार्यान्वयनका टिप्पणी पढ्नुहोस्।
विशेषाधिकार घटेपछि के हुन्छ हेर्नुहोस्
धेरै डेमन विशेषाधिकारसहित सुरु हुन्छन्, इन्टरफेस कन्फिगर गर्छन्, त्यसपछि विशेषाधिकार नभएको प्रयोगकर्तामा जान्छन् र टनेल राख्छन्। त्यो क्षणदेखि प्रक्रियाले रुट थप्न, फायरवाल नियम पुनःलेखन वा नयाँ विशेषाधिकृत यन्त्र खोल्न सक्दैन, जुन पुनः जडानलाई ठ्याक्कै त्यही चाहिने बेलासम्म ठीक हुन्छ। पछिको फाइल पढाइ र हुक कार्यान्वयन त्यही कारणले असफल हुन सक्छ।
पहिलो सेकेन्ड होइन, सम्पूर्ण जीवनचक्र परीक्षण गर्नुहोस्: सुरुवात, नवीकरण वा पुनः जडान, र रोक्दा सफाइ। इन्टरफेस पहिलो पटक सफल भएर बन्नुले पछिका हरेक विशेषाधिकृत अपरेशन चलिरहने प्रमाण दिँदैन, र असफलता सामान्यतया उत्पादनमा घण्टौंपछि देखा पर्छ।
प्रयोगकर्ता परिवर्तनभरि टनेल खुला राख्ने कार्यान्वयनहरू सामान्यतया यसलाई टनेल र कुञ्जीहरू कायम राख्ने विकल्पसँग जोड्छन्। systemd पक्षमा समान प्रश्न यो हो कि युनिटको क्षमता-सेटले तपाईंले कन्फिगर गरेको प्रयोगकर्ता परिवर्तन सहन्छ कि सहँदैन।
दिइएको अनुमति र त्यसको कारण लेख्नुहोस्
ठ्याक्कै अनुमति, त्यसले सम्भव बनाउने अपरेशन र त्यसले सुधारेको त्रुटि लेख्नुहोस्। परिनियोजन टिप्पणीमा एउटा लाइन — «युनिटको नेटवर्क नेमस्पेसमा CAP_NET_ADMIN, पुनः जडानपछिको रुट परिवर्तनका लागि आवश्यक» — अर्को व्यक्तिलाई अनुमति फेरि फराकिलो बनाउनबाट रोक्न पर्याप्त छ।
त्यसपछि हरेक अपग्रेडपछि प्रभावकारी सेट फेरि पढ्नुहोस्। विक्रेताहरूले सुविधा थप्छन्, इमेजहरूले पूर्वनिर्धारित बदल्छन्, र गत वर्ष अनावश्यक रहेको क्षमता कसैले नथाहा पाई भारवाहक बन्न सक्छ।