तुमच्या VPN प्रक्रियेला कोणत्या Linux क्षमता लागतात?
इंटरफेस सेटअप, रूट, डिव्हाइस प्रवेश आणि सामान्य सॉकेट वेगवेगळे विशेषाधिकार आहेत. CAP_NET_ADMIN देण्यापूर्वी अयशस्वी झालेल्या ऑपरेशनचे नाव सांगा.
VPN डेमनला विशेषाधिकारित नेटवर्क ऑपरेशन्स लागतात, तरी सामान्य अनुप्रयोग कोणत्याही विशेषाधिकाराशिवाय बाहेर जाणारे सॉकेट उघडतात। नेमक्या याच अंतरातून बहुतेक क्षमता-चुका सुरू होतात: कोणीतरी परवानगी त्रुटी पाहतो, संपूर्ण संच देतो, आणि सेवा नंतर कोणीही स्पष्ट करू शकत नाही अशा कारणांमुळे चालते। खालील फेरी अयशस्वी झालेल्या ऑपरेशनपासून सुरू होते, तिला एका अधिकाराशी जोडते आणि नंतर प्रक्रिया प्रत्यक्षात ज्या संदर्भात चालते तो तपासते। अमर्यादित root म्हणून चालवणे काही तैनातीसाठी वैध उत्तर आहे, पण ते डीफॉल्ट नसून निर्णय असावे।
अयशस्वी झालेल्या ऑपरेशनपासून सुरुवात करा
प्रशिक्षणिका वाचण्यापूर्वी त्रुटी वाचा। इंटरफेस बदलावर «ऑपरेशनला परवानगी नाही», डिव्हाइस नोड उघडण्यास नकार आणि कमी पोर्टवर bind अयशस्वी होणे — ह्या तीन वेगळ्या समस्या आहेत, तीन वेगळ्या परवानग्यांसह। प्रक्रिया सुरू होऊन फक्त पहिल्या रूट बदलावर अयशस्वी झाली, तर त्याचा अर्थ इंटरफेस तयार होणे आधीच यशस्वी झाले आहे, ज्यामुळे उत्तर बरेच संकुचित होते।
सेवा बंद असताना त्रुटी पुन्हा निर्माण करा, नंतर अंमलबजावणी परवानगी देत असेल तर तीच वापरकर्ता अंतर्गत फोरग्राउंडमध्ये सुरू करा। तुम्हाला दिसणारी त्रुटी अंदाज घ्यावा लागणाऱ्या लॉग ओळीपेक्षा बरी आहे, आणि ती क्षमता-समस्या व SELinux किंवा AppArmor नकार यातील फरक स्पष्ट करते।
प्रत्येक ऑपरेशन एका अधिकाराशी जोडा
तक्ता हा सुरुवातीचा नकाशा आहे, अंमलबजावणीच्या दस्तऐवजाचा पर्याय नाही:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
त्या तक्त्यातील दोन ओळीच अशा आहेत ज्या लोक एकमेकांत मिसळतात। /dev/net/tun उघडणे हा फाइल-परवानगीचा प्रश्न आहे; तुम्ही उघडलेले कॉन्फिगर करण्यास कर्नेलला सांगणे हा क्षमतेचा प्रश्न आहे। CAP_NET_ADMIN दिल्याने तुमचा सेवा-वापरकर्ता जो डिव्हाइस नोड वाचू शकत नाही तो सुधारत नाही, आणि नोड सुधारल्याने तुम्हाला रूट अधिकार मिळत नाही। यापैकी कोणतेही बदलण्यापूर्वी दोन्ही तपासा।
कर्नेल WireGuard आणि वापरकर्ता-जागेतील टनेल प्रोग्रामच्याही आवश्यकता सारख्याच नाहीत। कर्नेल मॉड्यूलचा मार्ग netlink द्वारे विद्यमान इंटरफेस कॉन्फिगर करतो, तर वापरकर्ता-जागेतील अंमलबजावणीला डिव्हाइसही लागू शकते आणि काही वाहतुकीसाठी कच्चे सॉकेटही।
संदर्भ वाचा: सेवा, कंटेनर की शेल
होस्टच्या नेटवर्क नेमस्पेसमधील एक क्षमता जाणीवपूर्वक वेगळ्या केलेल्या स्टॅकमधील त्याच ऑपरेशनपेक्षा खूप जास्त परिणाम करू शकते। कंटेनर रनटाइम सहसा कमी केलेल्या सीमा-संचासह सुरू होते; होस्ट नेटवर्क सामायिक करणाऱ्या कंटेनरमध्ये NET_ADMIN जोडणे हे स्वतःचे नेटवर्क नेमस्पेस आणि होस्ट माउंट नसलेल्या कंटेनरमध्ये जोडण्यापेक्षा खूप मोठी परवानगी आहे।
systemd युनिटसाठी युनिट फाइल बोलते असे वाटते ते नव्हे, तर प्रत्यक्षात लागू होते ते वाचा: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities प्रभावी मूल्ये नोंदवते, जी तुम्ही विसरलेल्या drop-in ने ठेवलेली असू शकतात। प्रभावी मूल्य मागा, कधीही इच्छित मूल्य नाही। Ambient क्षमता महत्त्वाच्या आहेत कारण root नसलेली सेवा त्यांशिवाय exec दरम्यान क्षमता गमावते।
पॅकेज किंवा इमेजचे समर्थित सेटअप आधार माना। दुसऱ्या प्रशिक्षणिकेने दुसऱ्या साधनासाठी त्यांची यादी दिली म्हणून कच्च्या सॉकेटच्या परवानग्या किंवा विशेषाधिकारित मोड जोडू नका; तो युक्तिवाद काहीही हस्तांतरित करत नाही आणि तुम्ही दिलेले अलगीकरण गमावते। शंका असल्यास काहीही देऊ नका आणि तुम्हाला आवश्यक असलेल्या नेमक्या ऑपरेशनसाठी अंमलबजावणीच्या टिपा वाचा।
विशेषाधिकार घसरल्यानंतर काय होते ते पाहा
अनेक डेमन विशेषाधिकारासह सुरू होतात, इंटरफेस कॉन्फिगर करतात, नंतर विशेषाधिकार नसलेल्या वापरकर्त्याकडे जातात आणि टनेल ठेवतात। त्या क्षणापासून प्रक्रिया रूट जोडू शकत नाही, फायरवॉल नियम पुन्हा लिहू शकत नाही किंवा नवीन विशेषाधिकारित डिव्हाइस उघडू शकत नाही, जे पुन्हा जोडणीला नेमके तेच लागेपर्यंत ठीक आहे। नंतरचे फाइल वाचन आणि हुक चालवणे त्याच कारणाने अयशस्वी होऊ शकते।
पहिला सेकंद नव्हे, संपूर्ण जीवनचक्र तपासा: सुरुवात, नूतनीकरण किंवा पुन्हा जोडणी, आणि थांबवताना स्वच्छता। इंटरफेस पहिल्यांदा यशस्वी तयार होणे हे सिद्ध करत नाही की पुढील प्रत्येक विशेषाधिकारित ऑपरेशन चालू राहील, आणि अयशस्वीता सहसा उत्पादनात तासांनंतर दिसते।
वापरकर्ता बदलाच्या काळात टनेल उघडे ठेवणारी अंमलबजावणी सहसा ते टनेल व किल्ल्या टिकवण्याच्या पर्यायांशी जोडते। systemd बाजूला समतुल्य प्रश्न हा आहे की युनिटचा क्षमता-संच तुम्ही कॉन्फिगर केलेला वापरकर्ता बदल टिकून राहतो का।
दिलेली परवानगी आणि तिचे कारण नोंदवा
नेमकी परवानगी, ती जे ऑपरेशन शक्य करते आणि जी त्रुटी दुरुस्त केली ते लिहा। तैनाती टिपांमधील एक ओळ — «युनिटच्या नेटवर्क नेमस्पेसमधील CAP_NET_ADMIN, पुन्हा जोडणीनंतर रूट बदलांसाठी आवश्यक» — पुढील व्यक्तीने परवानगी पुन्हा रुंदावण्यापासून थांबवण्यास पुरते।
नंतर प्रत्येक अपग्रेडनंतर प्रभावी संच पुन्हा वाचा। विक्रेते वैशिष्ट्ये जोडतात, इमेज डीफॉल्ट बदलतात, आणि गेल्या वर्षी अनावश्यक असलेली क्षमता कोणालाही कळल्याशिवाय भारवाहक बनू शकते।