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