VPN कंटेनर में NET_ADMIN: यह क्या और कहाँ बदल सकता है

NET_ADMIN वह लिनक्स क्षमता है जो किसी प्रक्रिया को नेटवर्क प्रशासन करने देती है, और कंटेनर में यह ठीक वही उस नेटवर्क नामस्थान के भीतर करती है जिसमें प्रक्रिया चलती है। यह सॉकेट खोलने का लाइसेंस नहीं है, और यह किसी डिवाइस या रूट का विकल्प नहीं है। दिलचस्प सवाल कभी यह नहीं होता कि क्षमता दी गई है या नहीं, बल्कि यह कि बदलाव किस नामस्थान को मिलता है।

क्षमता क्या कवर करती है

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

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

नामस्थान नुकसान की त्रिज्या तय करता है

अपने ब्रिज नेटवर्क पर कंटेनर अपने loopback, अपने इंटरफ़ेस और अपनी रूटिंग तालिका तक पहुँचता है। वहाँ NET_ADMIN देना VPN क्लाइंट को मेज़बान के रूटिंग निर्णयों को छुए बिना टनल बनाने देता है, जो वह व्यवस्था है जो अधिकांश कंटेनर इमेज मान लेती हैं।

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

तीन पूर्वापेक्षाएँ जो एक में मिला दी जाती हैं

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

services:
  vpn:
    image: example/vpn-client:latest
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1

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

मोड नहीं, संकीर्ण क्रिया दें

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

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

रहस्य अलग निर्णय के विषय हैं। NET_ADMIN रखना इस बारे में कुछ नहीं कहता कि क्लाइंट कौन-सी पीयर पहचान प्रस्तुत करता है, कौन-से क्रेडेंशियल लोड करता है या उन्हें कैसे बदला जाता है। नेटवर्क प्रशासन भरोसा नहीं देता।

बदलाव सत्यापित करें और दर्ज करें कि अनुमति क्यों है

टनल को डिबग करने से पहले पुष्टि करें कि कंटेनर को वास्तव में क्या मिला। नीचे का निरीक्षण जोड़ी गई क्षमताओं और नेटवर्क मोड की रिपोर्ट करता है, फिर दिखाता है कि अंदर से इंटरफ़ेस सूची कैसी दिखती है:

docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.NetworkMode}} {{.HostConfig.Privileged}}' vpn
docker exec vpn sh -c 'grep CapEff /proc/self/status'
docker exec vpn ip -br addr
docker exec vpn ip route

यदि क्षमता मौजूद है और इंटरफ़ेस सूची अभी भी खाली है, तो क्लाइंट कुछ बनाने से पहले ही विफल हो गया, और कंटेनर लॉग देखने की अगली जगह हैं। यदि टनल मौजूद है लेकिन ट्रैफ़िक नहीं बहता, तो कंटेनर के अंदर की रूटिंग तालिका अगले सवाल का जवाब देती है।

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

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