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 पत्ते नेमते, इच्छित रूट उपस्थित आहे, आणि अंतर्गत होस्टला विनंती यशस्वी होते। नंतर क्लायंट थांबवा आणि यापैकी प्रत्येक काढले किंवा पुनर्संचयित केले आहे याची खात्री करा। टनेल बंद झाल्यावरही होस्ट अंतर्गत नावे सोडवत असेल किंवा अजूनही रूट धरत असेल, तर मालकी हातांतरण अपूर्ण आहे।