क्यों विशेषाधिकार प्राप्त मोड VPN की ज़रूरत से ज़्यादा व्यापक है

कंटेनर अपनी टनल नहीं खोल रहा था, इसलिए विशेषाधिकार वाला फ़्लैग जोड़ दिया गया, और अब यह काम करता है। उस क्रम ने केवल यह सिद्ध किया कि कम से कम एक अनुमति गायब थी, और यह नहीं बताता कि कौन सी। विशेषाधिकार प्राप्त मोड क्षमताओं का एक समूह और डिवाइस तक पहुँच देता है जो टनल इंटरफ़ेस की ज़रूरत से कहीं अधिक व्यापक है।

फ़्लैग वास्तव में क्या बदलता है

विशेषाधिकार प्राप्त कंटेनर को व्यापक क्षमताएं और होस्ट डिवाइस तक पहुँच मिलती है, जो नेटवर्क पथ की आवश्यकता से कहीं बड़ी अनुमति है। सटीक समूह को लोककथा नहीं, रनटाइम प्रलेखित करता है, और Docker का कंटेनर चलाने का दस्तावेज़ उपलब्ध विशेषाधिकार विकल्पों का वर्णन करता है। एक बार पढ़ना ही यह देखने के लिए पर्याप्त है कि टनलिंग पूरे का छोटा हिस्सा है।

दो अधिक संकीर्ण आवश्यकताएं ज़्यादातर VPN कंटेनरों को कवर करती हैं। किसी इंटरफ़ेस को कॉन्फ़िगर करने के लिए नेटवर्क प्रशासन क्षमता चाहिए, और टनल डिवाइस खोलने के लिए उसी विशिष्ट डिवाइस नोड तक पहुँच चाहिए। ये अलग-अलग अनुमतियाँ हैं, और दोनों देने पर भी यह सर्वव्यापी विकल्प से अधिक संकीर्ण ही रहता है। विशेषाधिकार समूह के बाकी हिस्से का टनल से कोई संबंध नहीं है। यह ऐसे वर्कलोड के लिए मौजूद है जिन्हें सचमुच होस्ट-स्तरीय पहुँच चाहिए, और VPN कंटेनर आमतौर पर उनमें से एक नहीं होता।

हर त्रुटि को एक पूर्वापेक्षा से मिलाएँ

त्रुटि संदेश आपको बताता है कि कौन सी पूर्वापेक्षा गायब है, अगर आप उसे दबाने से पहले पढ़ें। डिवाइस नोड के बारे में संदेश डिवाइस का नाम लेता है, अनुमति न मिलने वाले ऑपरेशन के बारे में संदेश किसी क्षमता का नाम लेता है, और मॉड्यूल या sysctl के बारे में संदेश कर्नेल समर्थन का नाम लेता है। इनमें से हर एक का अलग समाधान है, और इनमें से केवल एक ही क्षमता है।

गायब कॉन्फ़िगरेशन फ़ाइल हर क्षमता दिए जाने के बाद भी गायब ही रहती है, इसीलिए विशेषाधिकार प्राप्त मोड कभी-कभी कुछ भी नहीं बदलता। कंटेनर शुरू होता है, टनल फिर भी विफल होती है, और असली त्रुटि कभी अनुमतियों के बारे में नहीं थी। कर्नेल समर्थन तीसरा मामला है और गलत पढ़ा जाने वाला सबसे आसान। होस्ट पर लोड न किया गया मॉड्यूल बिना विशेषाधिकार वाले कंटेनर के अंदर से लोड नहीं किया जा सकता, और कंटेनर के अंदर अधिक क्षमताएं देने से होस्ट की स्थिति नहीं बदलती।

लक्षण नहीं, आवश्यकता जाँचें

इमेज जिस न्यूनतम कॉल का दस्तावेज़ देती है उससे शुरू करें, उसे चलाएँ, और विफलता का सटीक पाठ रखें। फिर एक बार में एक अनुमति जोड़ें और नोट करें कि किस जोड़ ने परिणाम बदला।

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

जो कंटेनर डिवाइस देख सकता है और क्षमता रखता है पर फिर भी विफल होता है, वह आपको बता रहा है कि समस्या कहीं और है। यह एक उपयोगी परिणाम है, और विशेषाधिकार प्राप्त मोड इसे छिपा देता।

होस्ट पर डिवाइस की अनुमतियाँ भी जाँचें, क्योंकि सही तरीके से दिया गया डिवाइस नोड गलत समूह स्वामित्व के साथ गायब अनुमति जैसी ही त्रुटि पैदा करता है।

जो सबसे संकीर्ण अनुमति काम करे उसे दर्ज करें

तैनाती को ज़रूरी हर डिवाइस और क्षमता लिखें, साथ में वह त्रुटि जिसने उन्हें उचित ठहराया। यही रिकॉर्ड अगले व्यक्ति को कुछ भी सुरक्षित रूप से हटाने देता है, और यही लेखा-परीक्षक माँगेगा जब किसी कंटेनर को विशेषाधिकार प्राप्त बताया जाए।

आसपास के संदर्भ की भी समीक्षा करें, क्योंकि होस्ट नेटवर्किंग, होस्ट माउंट और रनटाइम विकल्प हर एक किसी अनुमति का प्रभाव बढ़ा सकते हैं। उन सबको जोड़ने वाला अलग प्रयोगशाला कॉल उत्पादन कॉन्फ़िगरेशन नहीं है, चाहे वह कितना भी अच्छा काम किया हो। तैनाती को पूर्ण कहने से पहले एप्लिकेशन, उसका DNS व्यवहार और एक टनल विफलता जाँचें। इंटरफ़ेस बनाने की अनुमति बाहर जाने की नीति नहीं है, और पूरी तरह टनल कर सकने वाला कंटेनर फिर भी वह सब रूट करता है जो एप्लिकेशन भेजता है।