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