UID नियमसँग एउटा Linux खाता OpenVPN बाट रुट गर्नुहोस्

खाता-आधारित रुटिङ तब उपयुक्त हुन्छ जब एक Linux प्रयोगकर्ताको स्वामित्वमा रहेको प्रत्येक IPv4 सकेट विद्यमान टनेलबाट बाहिर जानुपर्छ, र यो तब उपयुक्त हुँदैन जब तपाईंलाई कार्यक्रम-स्तरको अलगाव चाहिन्छ। यसले UID अनुसार छान्छ, त्यसैले त्यो खातामा चल्ने सबै कुरा दायरामा पर्छ, तपाईंले बिर्सनुभएको ब्याच काम पनि। एउटा पनि ip rule छुनुअघि त्यो प्रश्न टुंग्याउनुहोस्।

तलको उदाहरणले UID 1500 मा रहेको समर्पित ब्राउजर खाता, 10.80.0.11 स्थानीय ठेगाना बोक्ने टनेल यन्त्र tun-office, र विचाराधीन गन्तव्यहरूलाई अनुमति दिने VPN मान्छ। डेमन स्वयं त्यो UID बाहिर चल्छ।

संयन्त्र छान्ने तीन सर्त

UID नियम तब छान्नुहोस् जब काम गर्ने पहिचान खाता हो, जब यसको सबै ट्राफिक सार्नु स्वीकार्य हुन्छ, र जब namespace कामको योग्यताभन्दा भारी हुन्छ। नेटवर्क namespace तब छान्नुहोस् जब कार्यभारलाई आफ्नै इन्टरफेस, रिजोल्भर र रुटिङ तालिका चाहिन्छ। प्रोक्सी वा प्रति-प्रक्रिया बाइन्ड तब छान्नुहोस् जब ठ्याक्कै एउटा अनुप्रयोग सार्नुपर्छ र सत्रको बाँकी स्थानीय मार्गमा रहन्छ। यी तीन लेखेर राख्दा इरादाभन्दा बढी चुपचाप ढाक्ने नियम टर्छ।

बच्नुपर्ने गल्ती भनेको लन्चरले मालिक निर्धारण गर्छ भनी मान्नु हो। अर्को प्रयोगकर्ताको सत्रले URL दिएको ब्राउजरले UID 1500 अन्तर्गत सकेट बनाएको छैन, र कुनै नियमले त्यसले उत्पन्न गर्ने ट्राफिक सार्ने छैन।

तालिका, नियम र रक्षक

विद्यमान नियम जाँचेर नप्रयोग गरिएका तालिका र प्राथमिकता नम्बर छानेपछि व्यवस्था छोटो हुन्छ: टनेलको स्रोत ठेगाना बोक्ने समर्पित तालिकामा डिफल्ट मार्ग, खाताका खोजहरू त्यो तालिकामा पठाउने नियम, र फलब्याक रोक्ने अन्तिम नियम। लेख्दा यो इडेम्पोटेन्ट मार्ग प्रतिस्थापन हो, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, त्यसपछि ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820।

रक्षक ip -4 rule add priority 12101 uidrange 1500-1500 unreachable हो, र यो यसको लम्बाइले संकेत गरेभन्दा बढी महत्त्वपूर्ण छ। यो बिना तालिका 51820 मा हराएको मार्ग सामान्य अपलिङ्कमा खस्छ र खाताले नीतिले समात्नुपर्ने ट्राफिक चुपचाप चुहाउँछ। यो सहित त्यही असफलता टाइमआउट बन्छ, अर्थात् फलब्याक नभई रोकावट।

सामान्य स्थानीय-ठेगाना नियम यीभन्दा अघि राख्नुहोस्, र LAN वा व्यवस्थापन अपवाद छानिएको तालिकाभन्दा अघि पर्छन् कि पर्दैनन् सचेत रूपमा निर्णय गर्नुहोस्। त्यहाँ भेटिएको डिफल्टले पछि अझ विशिष्ट LAN मार्गका लागि main लाई सोध्दैन, जसले तालिकाहरूबीच सबैभन्दा लामो प्रिफिक्स मिलान लागू हुन्छ भन्ने अपेक्षा गर्नेहरूलाई छक्क पार्छ। इच्छित अपवाद सूची परिवर्तन-टिप्पणीमा लेख्नुहोस्, तर्क अझै ताजा छँदै।

UID रुटिङले के छोड्छ: DNS

रिजोल्भर डेमनले आफ्ना अपस्ट्रिम सकेट आफ्नै UID अन्तर्गत खोल्छ, त्यसैले 1500 छान्दा ती क्वेरीहरू तालिका 51820 मा जाँदैनन्। DNS एकीकरण छुट्टै निर्णय हो: खातालाई टनेलबाट पुग्न सकिने रिजोल्भरतर्फ देखाउनुहोस्, वा नाम-समाधान होस्टको मार्ग पछ्याउँछ तर ट्राफिक पछ्याउँदैन भनी स्वीकार्नुहोस्।

स्थानीय stub मा loopback क्वेरी अपस्ट्रिम क्वेरीले ब्राउजरको मार्ग प्रयोग गरेको प्रमाण होइन, र क्यासबाट सफल पृष्ठ लोड पनि होइन।

IPv6 लाई डिजाइनमा आफ्नै वाक्य चाहिन्छ

माथिका नियमहरूले IPv4 मात्र समेट्छन्। यदि आवश्यकता यस खाताबाट सिधै IPv6 बिनाको IPv4 टनेल हो भने, समीक्षा गरिएको अन्तिम नियम थप्नुहोस् जस्तै ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, त्यसपछि अघिल्ला IPv6 नियमहरू र तपाईं राख्न चाहनुभएका loopback अपवादहरू जाँच्नुहोस्।

सिधै IPv6 रोक्नु दोहोरो-स्ट्याक टनेलिङ होइन; यो एउटा सीमा हो। यसलाई टनेलिङ भन्नु अर्को नीति पढ्ने व्यक्तिलाई अलमल्याउँछ, र त्यो अलमल बिग्रिएको IPv6 साइटबारे हेल्पडेस्क टिकटका रूपमा बाहिर आउँछ।

वास्तविक खाताबाट प्रमाणित गर्नुहोस्, त्यसपछि जीवनचक्रको जिम्मेवारी लिनुहोस्

खोजहरू तुलना गर्नुहोस्: सामान्य UID सँग त्यही गन्तव्यका लागि ip -4 route get 198.51.100.25 uid 1500। त्यसपछि समर्पित खाता अन्तर्गत अनुमति दिइएको अनुरोध गर्नुहोस् र टाढाको छेउले देख्ने स्रोत ठेगाना जाँच्नुहोस्। प्राथमिकता दिइएको स्रोत ठेगाना source NAT होइन, र यसले अरू केही बाइन्ड गर्ने अनुप्रयोगलाई जित्ने छैन। यदि दुवै खोजले एउटै मार्ग फर्काउँछन् भने, नियमले तपाईंले सोचेको कुरा गर्दैन।

तालिका, नियमहरू र टनेल-मार्गको आयु एकै मालिकको अधीनमा राख्नुहोस्, पुनः जडान र टनेल हानि परीक्षण गर्नुहोस्, र नीति हटाउँदा यसका ठ्याक्कै प्रविष्टिहरू मात्र हटाउनुहोस्। अलग इन्टरफेस र अलग अवस्था साँच्चै चाहिएको भए namespace अझै उपलब्ध छ।