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 अभी भी उपलब्ध है यदि अलग इंटरफ़ेस और अलग स्थिति वास्तव में वही हैं जो आपको चाहिए।