Linux VPN मा ठेगाना, रुट, DNS र फायरवालको मालिक को हो?

एउटै रुटको लागि लड्ने दुई स्क्रिप्टहरू Linux VPN समस्याको सामान्य रूप हुन्, जसलाई रुटिङ बगको रूपमा दर्ता गरिन्छ। एउटा घटकले टनेल उपकरण बनाउँछ, अर्कोले डिफल्ट रुट थप्छ, तेस्रोले रिजोल्भर कन्फिगरेसन पुनः लेख्छ, र चौथोले फायरवाल नियमहरू पुनः लोड गर्छ। तीमध्ये जुनसुकैले अर्कोको काम रद्द गर्न सक्छ, र विजेता त्यो हो जो अन्तिममा चलेको थियो। जवाफ दिन लायक प्रश्न यो होइन कि कुन प्याकेज स्थापना गर्ने, बरु यो हो कि स्थितिको प्रत्येक भागको लागि कुन घटक अधिकारिक छ।

यो नक्सा एकचोटि लेख्नुहोस्, र अधिकांश पुनःजडान असफलताहरू रहस्यमय हुन छोड्छन्। चार वस्तुहरू महत्त्वपूर्ण छन्: उपकरण र यसका ठेगानाहरू, रुट र नीति नियमहरू, DNS कन्फिगरेसन र फायरवाल।

उपकरण र यसका ठेगानाहरू

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

सत्र सकिँदा उपकरण कसले हटाउँछ त्यो लेख्नुहोस्। आफ्नो सत्रभन्दा लामो बाँच्ने उपकरण पुराना ठेगानाहरू र तिनीपछिको भ्रमको सबैभन्दा सामान्य स्रोत हो।

रुट र नीति नियमहरू

रुटमै मालिकत्व द्वन्द्वहरूले देखिने हानि गर्छन्। एक जडान म्यानेजरले टनेलको लागि डिफल्ट रुट र टाढाको सञ्जालको लागि बढी विशिष्ट रुट राख्छ; त्यसपछि हातले लेखिएको स्क्रिप्टले अर्को मेट्रिकसँग आफ्नै डिफल्ट थप्छ र समयअनुसार चुपचाप जित्छ वा हार्छ। कुन प्रविष्टिहरू जडान-आधारित छन्, कुन स्थायी नीति हुन्, र कुन घटकले पुनःजडानपछि तिनीहरूलाई ताजा गर्छ भनेर निर्धारण गर्नुहोस्। त्यसपछि अन्य घटकहरूलाई त्यो तालिकाबाट बाहिर राख्नुहोस्।

नीति नियमहरू पनि त्यही स्पष्टताको योग्य छन्, किनकि कसैले नभर्ने तालिकातर्फ देखाउने नियमले मृत टनेलजस्तै देखिने कालो प्वाल बनाउँछ। यदि नियम ट्राफिकलाई कतै धकेल्नको लागि छ भने, यसले छान्ने तालिका त्यही मालिकले मर्मत गर्नुपर्छ।

DNS सधैं अलग मालिक हो

रिजोल्भर डेमन आफ्नै पहिचानमा आफ्नै प्रक्रियाको रूपमा चल्छ, त्यसैले यसले टनेलका रुटिङ निर्णयहरू संयोगवश उत्तराधिकारमा लिँदैन। VPN ले DNS सर्भर धकेल्दा, कसैले यसलाई रिजोल्भरले मान्ने प्रति-लिङ्क कन्फिगरेसनमा अनुवाद गर्नुपर्छ, र पछि कसैले त्यो हटाउनुपर्छ।

यहाँको मिथक यो हो कि प्रोफाइलमा नेमसर्भर लेख्दा क्वेरी कहाँ जान्छन् भन्ने परिवर्तन हुन्छ। यसले रिजोल्भरलाई के भनिन्छ त्यो परिवर्तन गर्छ, रिजोल्भरले माथिल्लो तहमा कुन सकेट प्रयोग गर्छ त्यो होइन। फाइलमा भरोसा गर्नुको सट्टा क्वेरी र रुट लुकअपसँग परीक्षण गर्नुहोस्।

फायरवाल स्थिति, र यसलाई कसले पुनर्स्थापित गर्छ

फायरवाल नियमहरू VPN होस्टमा सबैभन्दा धेरै पटक पुनःलेखिने वस्तु हुन्। म्यानेजरले प्रत्येक जडानको लागि NAT वा फर्वार्डिङ नियम थप्न सक्छ, जबकि बुटको समयको फायरवाल सेवाले सुरक्षित नियमसमूह पुनः लोड गरेर तिनलाई मेटाउँछ। नीतिको लागि एउटा अधिकार छान्नुहोस् र अर्कोलाई त्यसको उपभोक्ता बनाउनुहोस्, वा रिबुटले व्यवहार चुपचाप परिवर्तन गर्छ भनेर स्वीकार गर्नुहोस्। जडान-आधारित अपवादहरू त्यही फाइलमा हुनुपर्छ जुन त्यही मालिकले लोड गर्छ, समस्या समाधान गर्दा टाइप गरिएको iptables आदेशमा होइन।

यदि नियमहरूले पुनःजडान सहनुपर्ने हो भने, त्यो स्पष्ट भन्नुहोस्। नसहने हो भने, त्यो पनि भन्नुहोस्, किनकि अर्को इन्जिनियरले बढी सुविधाजनक उत्तर मान्नेछ।

जीवनचक्र: बुट, पुनःजडान, टियरडाउन

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

अवलोकनको लागि ip monitor link address route कर्नेल परिवर्तनहरू हुँदै गर्दा देखाउँछ, तर यसले मनसाय होइन, घटनाहरू रिपोर्ट गर्छ: हटाइएको रुटले कुन प्रक्रियाले हटायो भन्ने केही बताउँदैन। यसलाई मालिकत्व नक्सासँग जोड्नुहोस्, र भ्रमित बन्द हुने क्रम छोटो उम्मेदवार सूची बन्छ।

अपवादहरूको पनि मूल्य हुन्छ। द्वन्द्वबाट बच्न पूरै उपकरण वर्गलाई अव्यवस्थित भनेर चिन्ह लगाउनु त्यो स्थिति कसैलाई दिँदैन, जो सुधार होइन, निर्णय हो।