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 व्यवहार र टनेल असफलता परीक्षण गर्नुहोस्। इन्टरफेस बनाउने अनुमति बाहिर जाने नीति होइन, र पूर्ण रूपमा टनेल गर्न सक्ने कन्टेनरले पनि अनुप्रयोगले पठाउने सबै रुट गर्छ।