एक सामान्य 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 के रूप में चलाना उन भूमिकाओं को बिना कुछ समझाए बिखेर देता है।