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 अजूनही उपलब्ध आहे.