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 फाइलमा त्यो व्याख्या गर्ने टिप्पणीबिना स्थायी आवश्यकताका रूपमा वर्णन गर्नु हुँदैन।

हरेक क्षमताको छेउमा कारण लेख्नुहोस्: कुन कार्यलाई त्यो चाहियो र त्यसबिना के असफल हुन्छ। त्यो टिप्पणी इमेज अद्यावधिकपछि पनि टिक्छ, र त्यही समीक्षित विशेषाधिकार सूची र प्रतिलिपि-टाँसाबाट बढेको सूचीबीचको फरक हो।