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 फाइलमध्ये ते स्पष्ट करणार्या टिपेशिवाय कायमची आवश्यकता म्हणून वर्णन करू नये।

प्रत्येक क्षमतेच्या पुढे कारण लिहा: कोणत्या क्रियेला ती लागली आणि तिच्याशिवाय काय अपयशी होते। ती टीप इमेज अद्ययावतांनंतरही टिकते, आणि तोच फरक पुनरावलोकित विशेषाधिकार यादी आणि कॉपी-पेस्टने वाढलेली यादी यांच्यात आहे।