एउटा साधारण 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 का रूपमा चलाउँदा ती भूमिका केही नबताई भत्किन्छन्।