एक सामान्य Linux ॲप TUN ला स्पर्श न करता VPN वापरते

स्थापित Linux VPN वापरणारा ब्राउझर /dev/net/tun उघडत नाही। तो एक सॉकेट उघडतो, आणि त्या सॉकेटचे पॅकेट कोणत्या इंटरफेसने बाहेर पडतात हे कर्नेल ठरवते। बोगदा तयार केलेली प्रक्रिया, ती वाहून नेते त्या प्रवाहाच्या प्रक्रियेपेक्षा वेगळे काम करत असते। या दोन भूमिका वेगळ्या ठेवल्यास बहुतेक परवानगीच्या प्रश्नांची उत्तरे ते विचारले जाण्यापूर्वीच मिळतात।

सॉकेटपासून बोगद्यापर्यंत एक पॅकेट अनुसरा

सामान्य ॲप connect किंवा send म्हणते, आणि कर्नेल गंतव्यासाठी मार्ग शोधते। निवडलेला मार्ग बोगद्याच्या इंटरफेसकडे निर्देश करत असल्यास, पॅकेट VPN डेमॉन वाचतो त्या डिव्हाइसच्या रांगेत जाते। डेमॉन ते एन्क्रिप्ट करतो आणि भौतिक इंटरफेसने बाहेर पाठवतो। त्या वर्णनातील प्रत्येक बाण हे परवानगीच्या प्रश्नाचे उत्तर देता येणारे ठिकाण आहे।

त्या मार्गावर ॲपला डिव्हाइसबद्दल माहिती असावी अशी काहीही मागणी नाही। डेमॉन फाइल डिस्क्रिप्टर धरून ठेवतो आणि इंटरफेसच्या क्रिया करतो, तर ॲप फक्त सामान्य नेटवर्क API पाहते।

दोन्ही अर्धे एकदा काढा, मग परवानगीचे प्रश्न ठेवणे सोपे होईल। वरचा अर्धा भाग ॲप्सचे जग आहे, आणि खालचा भाग डेमॉनचा आहे।

कोणाला डिव्हाइस हवे आणि कोणाला नको ते ठरवा

TUN इंटरफेस तयार करणे किंवा त्याला जोडणे यासाठी डिव्हाइस प्रवेश आणि त्याशिवाय ते कॉन्फिगर करण्याची क्षमता लागते, म्हणून समर्थित VPN सेवा नेटवर्क प्रशासनाच्या अधिकाराने सुरू होते किंवा विशेष सहाय्यक वापरते। ती गरज डेमॉनची आहे। ती ब्राउझर, डेटाबेस क्लायंट किंवा फाइल हस्तांतरण साधनाबद्दल काहीही सांगत नाही। ज्या सेवेला ही क्षमता हवी आहे तिला ती स्वतःच्या सेटअप टप्प्यासाठी हवी आहे, तिच्या क्लायंटसाठी नाही।

मार्ग आणि धोरण तयार झाल्यावर, सामान्य प्रक्रिया तयार झालेला मार्ग आपल्या नेहमीच्या सॉकेट कॉलद्वारे वापरते। तिला डिव्हाइस नोड लागत नाही, आणि root सुद्धा लागत नाही।

डिव्हाइसच्या परवानग्या बदलणे हा ॲपला गंतव्य प्रवेश देण्याचा मार्ग नाही। ते फक्त डिव्हाइसची सीमा दुसरीकडे सरकवते।

ॲप प्रत्यक्षात कोणत्या नेमस्पेसमध्ये चालते ते तपासा

कंटेनर, किंवा दुसरा नेटवर्क नेमस्पेस, आपल्या प्रक्रियांना वेगळा इंटरफेस संच आणि मार्ग सारणी देतो। होस्टवरील बोगदा तिथे आपोआप दिसत नाही, आणि डिव्हाइस परवानग्यांमधील कोणताही बदल ते बदलत नाही। ॲप फक्त त्या नेमस्पेसने दिलेल्या गोष्टींतून मार्ग काढते। म्हणून कंटेनर इमेज अपघाताने होस्ट बोगदा वारसा घेऊ शकत नाही।

ते ip netns list आणि ip -n NAME route ने, किंवा प्रक्रियेची नेमस्पेस लिंक पाहून तपासा। उत्तर सहसा एकाच कमांडमध्ये दिसते।

एकाच होस्टवरील दोन वापरकर्त्यांना धोरणाने वेगवेगळे मार्गही दिले जाऊ शकतात। ते नेटवर्कचा निर्णय आहे, डिव्हाइस मालकीचा पुरावा नाही।

क्षमता नेटवर्क धोरणापासून वेगळ्या करा

काही साधनांना सॉकेटपेक्षा अधिक लागते। पॅकेट पकडण्यासाठी कच्चा सॉकेट लागतो, आणि मार्ग बदलण्यासाठी प्रशासकीय अधिकार लागतो। हे वेगळ्या परवानग्या असलेल्या वेगळ्या क्रिया आहेत, आणि एक देणे हे VPN वापरण्याची सर्वसाधारण अट म्हणून वाचू नये।

स्वतःचा बोगदा अमलात आणणारा कार्यक्रम हे तिसरे प्रकरण आहे। तो खरोखर TUN उघडतो कारण तो डेमॉनची भूमिका घेतो, म्हणून त्याला डेमॉनची विशेषाधिकार लागतात।

विशेषाधिकाराचे नाव घेण्यापूर्वी क्रियेचे नाव घ्या। दोन्ही वेगळे करणे सहसा दिसते त्यापेक्षा सोपे असते।

दोन खात्यांसह विभाजन तपासा

बोगदा सेवा म्हणून जोडा, नंतर ॲप सामान्य वापरकर्ता म्हणून चालवा आणि ते खाजगी संसाधनापर्यंत पोहोचते याची खात्री करा। त्या वापरकर्त्याच्या शेलमधून गंतव्यासाठी ip route get तपासा आणि कोणता इंटरफेस निवडला गेला ते पाहा। मार्ग बरोबर असूनही कनेक्शन अयशस्वी होत असल्यास, समस्या धोरणात आहे, विशेषाधिकारात नाही।

परिणामी रचना स्पष्ट सीमेसह किमान विशेषाधिकार आहे: एक घटक सेटअप आणि बोगद्याची संसाधने मालक आहे, कामाचे भार त्यांची सामान्य खाती राखतात, आणि नेटवर्क धोरण ठरवते कोणते जाऊ शकते। सर्व काही root म्हणून चालवल्यास त्या भूमिका काहीही न सांगता कोसळतात।