जब openfortivpn कनेक्ट होता है तो रूट और DNS का मालिक कौन होना चाहिए?

काम कर रहे openfortivpn सत्र में चार चरण एक-दूसरे पर चढ़ते हैं। क्लाइंट गेटवे पर प्रमाणित होता है और TLS कनेक्शन शुरू करता है, फिर उस कनेक्शन के भीतर PPP चलाता है, फिर पता और DNS जानकारी प्राप्त करता है, और अंत में होस्ट रूट और रिज़ॉल्वर सेटिंग्स लागू करता है। हर चरण जीवित हो सकता है जबकि अगला नहीं, और इसीलिए सहायता थ्रेड में “कनेक्टेड” इतना फिसलन भरा शब्द है।

सबसे अधिक भ्रम दूर करने वाला निर्णय यह है कि अंतिम चरण का मालिक कौन है। या तो VPN क्लाइंट स्वयं होस्ट परिवर्तन लागू करता है, या कोई अन्य घटक करता है, और दोनों को आधे रास्ते मिलाना ही वह तरीका है जिससे रूट और रिज़ॉल्वर फ़ाइलें अलग-अलग सत्रों का वर्णन करने लगती हैं।

एक ही कनेक्शन जैसे दिखने वाले चार चरण

पहला चरण प्रवेश है। नामित प्रमाणीकरण डोमेन या एकबारगी कोड के माध्यम से, और आगे बढ़ने के लिए आवश्यक पैरामीटर प्राप्त करता है। जब क्लाइंट छापता है कि वह गेटवे से जुड़ा है, तो इसका अर्थ है कि TLS परिवहन चालू है। इसका अर्थ यह नहीं है कि PPP ने बातचीत कर ली, और निश्चित रूप से इसका अर्थ यह नहीं है कि कोई आंतरिक अनुप्रयोग पहुँच योग्य है।

दूसरा चरण PPP लिंक है। क्लाइंट टनल डिवाइस के विरुद्ध PPP प्रक्रिया शुरू करता है, और दोनों पक्ष लिंक विकल्पों और पतों पर बातचीत करते हैं। उसके बाद ही होस्ट जानता है कि सत्र कौन से स्थानीय और दूरस्थ पते उपयोग करता है, और तभी टनल की ओर इंगित रूट का अर्थ हो सकता है।

तीसरा चरण उस जानकारी को होस्ट पर लागू करना है, और यहीं स्वामित्व मायने रखता है। क्लाइंट रूट जोड़ सकता है और रिज़ॉल्वर कॉन्फ़िगरेशन फिर से लिख सकता है, या उसे पीछे हटने को कहा जा सकता है और दोनों को उस मशीन पर नेटवर्क प्रबंधित करने वाले किसी भी चीज़ पर छोड़ सकता है। परियोजना का README इन्हें एक स्वचालित व्यवहार के बजाय अलग-अलग ज़िम्मेदारियों के रूप में वर्णित करता है।

रूटिंग तालिका कौन संपादित करता है

डिफ़ॉल्ट रूप से क्लाइंट ही मालिक है। यह भौतिक इंटरफ़ेस के माध्यम से गेटवे की ओर एक रूट, टनल के साथी के लिए एक रूट, और उन नेटवर्कों के लिए रूट जोड़ता है जिनका उपयोग सत्र को करने की अनुमति है, फिर प्रक्रिया बाहर निकलने पर उन्हें हटा देता है। यह डिफ़ॉल्ट एकल नेटवर्क प्रबंधक और कोई अन्य VPN सॉफ़्टवेयर न होने वाले लैपटॉप पर सुविधाजनक है।

हैंडओवर केवल तब चुनें जब कोई और वास्तव में रूटिंग का मालिक हो। नेटवर्क प्रबंधक एकीकरण, कंटेनर नेटवर्क नामस्थान, या साइट-व्यापी रूटिंग एजेंट पहले से जान सकते हैं कि उन्हीं प्रीफ़िक्सों को कैसे स्थापित और साफ़ करना है। तब no-routes विकल्प देना दो लेखकों को एक ही तालिका पर लड़ने से रोकता है, जो एक दौड़ है जो साफ़ विफलता के बजाय एक सबनेट के रुक-रुक कर खोने के रूप में दिखती है।

अतिव्यापन हैंडओवर का दूसरा कारण है। यदि धकेले गए रूट में ऐसा प्रीफ़िक्स है जो स्थानीय नेटवर्क पहले से उपयोग करता है, तो क्लाइंट आपके लिए संघर्ष हल नहीं कर सकता। किसी को तय करना होगा कि वह प्रीफ़िक्स टनल के माध्यम से, भौतिक लिंक के माध्यम से, या अधिक विशिष्ट रूट के माध्यम से पहुँच योग्य है, और वह निर्णय टोपोलॉजी के मालिक का है।

सफ़ाई तीसरा है। जो क्लाइंट अपने रूट हटाने से पहले क्रैश हो जाता है वह एक काला छेद छोड़ जाता है जो सत्र से अधिक जीता है, और अगला कनेक्शन उसके ऊपर एक नकल जोड़ सकता है। जो रूटिंग का मालिक है वह पुरानी प्रविष्टियाँ गई हैं इसकी जाँच का भी मालिक है। उस जाँच को स्टार्टअप पथ का हिस्सा बनाएँ, वैकल्पिक सफ़ाई चरण नहीं।

DNS और रिज़ॉल्वर फ़ाइल का मालिक कौन है

DNS वही निर्णय है, अधिक तीखे किनारों के साथ। क्लाइंट गेटवे या PPP साथी जो DNS सर्वर बताते हैं उन्हें स्वीकार कर सकता है और उन्हें होस्ट रिज़ॉल्वर कॉन्फ़िगरेशन में लिख सकता है। सरल मशीन पर यही आप चाहते हैं, क्योंकि आंतरिक नाम तब केवल तब ही हल होते हैं जब टनल चालू हो।

आधुनिक Linux होस्ट पर रिज़ॉल्वर स्थानीय स्टब द्वारा प्रबंधित हो सकता है, और उस स्टब की पीठ पीछे रिज़ॉल्वर फ़ाइल फिर से लिखने से ऐसा कॉन्फ़िगरेशन बनता है जो सही दिखता है और असंगत व्यवहार करता है। यदि होस्ट पहले से रिज़ॉल्वर प्रबंधक चलाता है, तो उसे DNS का मालिक बनने दें और उसके समर्थित इंटरफ़ेस के माध्यम से टनल के सर्वर उसे दें। क्लाइंट का no-dns विकल्प वहाँ सही चुनाव है, कोई कामचलाऊ उपाय नहीं।

विभाजित DNS इस बात से अलग प्रश्न है कि फ़ाइल कौन लिखता है। हर क्वेरी टनल के माध्यम से भेजना सरल और धीमा है; उसके माध्यम से केवल आंतरिक ज़ोन भेजने के लिए प्रति-डोमेन कॉन्फ़िगरेशन चाहिए जो अधिकांश सरल क्लाइंट प्रदान नहीं करते। क्लाइंट के रिज़ॉल्वर परिवर्तन सक्षम करने से पहले तय करें कि होस्ट को कौन सा व्यवहार चाहिए। यहाँ गलत चुनाव नाम-हल विफलता जैसा दिखता है, तब भी जब टनल स्वयं ठीक हो।

विशेषाधिकार, तैयारी और हैंडओवर

टनल डिवाइस बनाना और होस्ट रूट या रिज़ॉल्वर स्थिति संपादित करना उन्नत नेटवर्क अधिकार चाहता है। सामान्य गलती यह निष्कर्ष निकालना है कि इसलिए सब कुछ root के रूप में चलना चाहिए, जिसमें ब्राउज़र या टनल उपयोग करने वाला अनुप्रयोग भी शामिल है। विशेषाधिकार प्राप्त हिस्से को छोटा रखें: क्लाइंट और उसकी कॉन्फ़िगरेशन फ़ाइल, एक प्रशासक के स्वामित्व में, जबकि उपयोगकर्ता अनुप्रयोग अपना सामान्य खाता रखते हैं।

तैयारी हर उपभोक्ता के लिए परिभाषित होनी चाहिए। एक सुपरवाइज़र सेवा को शुरू मान सकता है जब क्लाइंट प्रक्रिया चल रही हो और टनल डिवाइस मौजूद हो। बैकअप कार्य VPN को केवल तब उपयोगी माने जब उसका भंडारण एंडपॉइंट टनल के माध्यम से उत्तर दे। ये अलग जाँचें हैं, और कमज़ोर को अधिक मज़बूत उद्देश्य के लिए उपयोग करने से ऐसे कार्य बनते हैं जो बहुत जल्दी शुरू होते हैं और रुक-रुक कर विफल होते हैं। चुनी गई परिभाषा लिखें, क्योंकि तैयारी पर असहमत सुपरवाइज़र और कार्य होना एक सहायता टिकट है जो होने की प्रतीक्षा में है।

चार अवलोकनों से अनुबंध का परीक्षण करें: गेटवे चरण पूरा होता है, PPP पते आवंटित करता है, इच्छित रूट मौजूद है, और आंतरिक होस्ट को अनुरोध सफल होता है। फिर क्लाइंट बंद करें और पुष्टि करें कि इनमें से हर एक हटाया या बहाल किया गया है। यदि टनल बंद होने के बाद भी होस्ट आंतरिक नाम हल करता है या अभी भी रूट रखता है, तो स्वामित्व हैंडओवर अधूरा है।