OpenVPN ला root न देता CAP_NET_ADMIN देणे

सेवा सुरू होते, लॉग तक्रार करतो की तो tun उपकरण उघडू शकत नाही, आणि मार्ग कधीच दिसत नाहीत. तुमच्या शेलमध्ये capsh --print चालवा आणि cap_net_admin तिथेच आहे, ज्यामुळे अपयश अशक्य वाटते. तुमचे शेल आणि युनिट यांत जे वेगळे आहे ते म्हणजे विशेषाधिकार संक्रमण, कर्नलची क्षमता देण्याची इच्छा नाही. खालील चार तपासण्या क्रमाने करा आणि फरक स्पष्ट करणाऱ्या पहिल्यावर थांबा.

गहाळ क्षमता लपलेल्या उपकरणापासून वेगळी करा

लॉग ओळीवरून दोन अपयश सारखीच दिसतात. CAP_NET_ADMIN नसलेली प्रक्रिया बोगद्याचा इंटरफेस तयार किंवा संरचीत करू शकत नाही, आणि ज्याचे सँडबॉक्स /dev/net/tun लपवते ती प्रक्रिया तो सुरुवातीलाच उघडू शकत नाही. क्षमता जोडल्याने दुसरी स्थिती सुधारणार नाही.

काहीही संपादित करण्यापूर्वी उपकरण सेवेच्या नामविश्वात आहे का ते तपासा. PrivateDevices=yes ही tun नोड पूर्णपणे काढून टाकणारी सामान्य कठोरीकरण ओळ आहे, आणि निर्बंधक ProtectSystem संरचना मार्गाला परवानगी त्रुटीसारखा वाचला जाणारा फक्त-वाचनीय बनवू शकतो. दोन्ही बोगद्याचा उल्लेख करणाऱ्या लॉग ओळी निर्माण करतात, म्हणून दोष क्षमतांवर येतो. आधी नोड आहे आणि उघडता येतो याची खात्री करा, नंतर पुढे जा.

तुम्ही कोणता क्षमता-संच पाहत आहात ते जाणून घ्या

Linux अनुमत, प्रभावी, वारसाहक्काने मिळणारे, मर्यादित आणि परिवेश संच ठेवतो, आणि परिवेश संच हाच root नसलेल्या वापरकर्त्याच्या exec नंतर टिकतो. बायनरीवरील फाइल-क्षमता exec वेळी अनुमत आणि प्रभावी हक्क देऊ शकतात, पण साखळीत काहीही ते हस्तांतरण अडवत नाही तोपर्यंतच.

इथेच sudo लोकांना भ्रमित करतो. sudo -u द्वारे चालवलेला आदेश नवीन विशेषाधिकार संक्रमण सुरू करतो आणि परिवेश संच जातो, त्यामुळे root म्हणून यशस्वी होणारी तीच तपासणी तिथे अपयशी ठरते. सेवा व्यवस्थापक हा आणखी एक संक्रमण आहे, आणि युनिटने सांगितल्याशिवाय तो परिवेशातील काहीही देत नाही.

क्षमता युनिटमध्ये द्या, रॅपरमध्ये नाही

उपकरण तयार करून मार्ग स्थापित करावे लागणाऱ्या बोगद्यासाठी किमान सेवा विभाग असा दिसतो.

[Unit]
Description=OpenVPN client, office profile
After=network-online.target

[Service]
Type=notify
User=openvpn
Group=openvpn
NoNewPrivileges=yes
AmbientCapabilities=CAP_NET_ADMIN
CapabilityBoundingSet=CAP_NET_ADMIN
ExecStart=/usr/sbin/openvpn --config /etc/openvpn/office.conf

AmbientCapabilities प्रक्रिया सुरू होण्यापूर्वी हक्क परिवेश संचात ठेवतो, आणि CapabilityBoundingSet प्रक्रियेला त्या यादीबाहेर काहीही ठेवू देत नाही. NoNewPrivileges=yes setuid किंवा फाइल-क्षमतांद्वारे विशेषाधिकार मिळवणे अडवतो, तर युनिटने स्पष्टपणे दिलेली क्षमता तरीही लागू असते. CAP_NET_BIND_SERVICE सेवेला खालचा पोर्ट बांधावा लागतो तेव्हाच जोडा, आणि फोरम थ्रेडने तसे केले म्हणून कधीही CAP_SYS_ADMIN जोडू नका.

युनिटने बायनरीला sudo मध्ये गुंडाळले असेल, तर रॅपर काढा. systemd आधीच User= लागू करतो, आणि तो अतिरिक्त थर हेच परिवेश संच रिकामा असण्याचे सर्वाधिक संभाव्य कारण आहे.

युनिट फाइलवर नाही, जिवंत प्रक्रियेवर तपासणी करा

व्यवस्थापकाने प्रत्यक्षात काय लागू केले ते वाचा, नंतर त्याने निर्माण केलेली प्रक्रिया वाचा.

unit=openvpn-client@office
systemctl show -p User -p AmbientCapabilities "$unit"
systemctl show -p MainPID --value "$unit" | xargs -r getpcaps
grep -E '^Cap(Eff|Amb)' /proc/$(systemctl show -p MainPID --value "$unit")/status

युनिटने क्षमता सूचीबद्ध केली असेल आणि CapEff मध्ये ती अजून नसेल, तर एखादा drop-in सेटिंग बाजूला सारतो किंवा ExecStartPre पायरी परिवेश बदलते. मुख्य फाइल अधिकृत मानण्यापूर्वी drop-in संचिकांमध्ये युनिटचे नाव शोधा, कारण नंतरची फाइल शांतपणे जिंकते. युनिट आणि प्रक्रिया दोन्ही क्षमता दाखवत असतील आणि बोगदा तरीही अपयशी ठरत असेल, तर मर्यादित संच रुंदावण्याऐवजी उपकरण आणि मार्ग तपासण्यांकडे परत जा. तो रुंदावल्याने खरे कारण लपते आणि सेवा पूर्वीपेक्षा जास्त विशेषाधिकारयुक्त राहते.

सुरुवातीनंतर विशेषाधिकार सोडणे पसंत करा

OpenVPN स्वतःच्या user आणि group पर्यायांद्वारे विशेषाधिकारासह सुरू होऊन नंतर विशेषाधिकार नसलेल्या खात्यात उतरू शकतो, आणि persist-key व persist-tun बोगदा नंतरही वापरण्यायोग्य ठेवतात. अशी रचना प्रक्रियेकडे हक्क असलेली खिडकी अरुंद करते, आणि कायमस्वरूपी क्षमतांसह संपूर्ण डीमन विशेषाधिकारांशिवाय सुरू करण्यापेक्षा ती बऱ्याचदा अधिक योग्य ठरते.

तुम्ही कोणतेही मॉडेल निवडा, युनिट पुन्हा सुरू करा आणि रीबूटनंतर तपासण्या पुन्हा करा, कारण इंटरॅक्टिव्ह root शेलमधून काम करणारी पण बूटला अपयशी ठरणारी सेवा सामान्यतः क्षमता, उपकरण किंवा फाइल-परवानगीतील फरक असते. युनिट सेटिंग्ज प्रक्रियेच्या क्षमता आउटपुटजवळ नोंदवा, जेणेकरून पुढील पुनरावलोककाला पॅकेज अद्यतन किंवा drop-in ने सीमा हलवली का ते दिसेल.