Linux VPN वर पत्ता, मार्ग, DNS आणि फायरवॉलचा मालक कोण आहे?

एकाच मार्गासाठी भांडणार्या दोन स्क्रिप्ट या Linux VPN समस्येचे नेहमीचे स्वरूप आहेत, जी राउटिंग बग म्हणून नोंदवली जाते। एक घटक टनेल डिव्हाइस तयार करतो, दुसरा डीफॉल्ट मार्ग जोडतो, तिसरा रिझॉल्व्हर कॉन्फिगरेशन पुन्हा लिहितो, आणि चौथा फायरवॉल नियम पुन्हा लोड करतो। यापैकी कोणताही दुसर्याचे काम रद्द करू शकतो, आणि विजेता तोच असतो जो शेवटी चालला। उत्तर देण्यासारखा प्रश्न हा नाही की कोणते पॅकेज इन्स्टॉल करावे, तर हा की स्थितीच्या प्रत्येक भागासाठी कोणता घटक अधिकृत आहे।

हा नकाशा एकदा लिहा, आणि बहुतेक पुनःकनेक्शन अपयश रहस्यमय राहणे थांबतील। चार वस्तू महत्त्वाच्या आहेत: डिव्हाइस आणि त्याचे पत्ते, मार्ग आणि धोरण नियम, DNS कॉन्फिगरेशन आणि फायरवॉल।

डिव्हाइस आणि त्याचे पत्ते

टनेल डिव्हाइस एकतर प्रोफाइल ओळखणारा मॅनेजर तयार करतो, किंवा कोणी हाताने सुरू केलेला डेमन तयार करतो। दोन्ही व्यवस्था स्वतंत्रपणे चालतात; त्या मिसळणे नाही। NetworkManager प्रोफाइलचा मालक असेल, तर डिव्हाइसचाही मालक असू द्या, आणि त्याच टनेल नावाविरुद्ध अव्यवस्थित OpenVPN प्रक्रिया सुरू करू नका।

सत्र संपल्यावर डिव्हाइस कोण काढतो ते नोंदवा। आपल्या सत्रापेक्षा जास्त जगणारे डिव्हाइस हे जुन्या पत्त्यांचे आणि त्यानंतरच्या गोंधळाचे सर्वात सामान्य स्रोत आहे।

मार्ग आणि धोरण नियम

मार्गांवरच मालकी संघर्ष दृश्य नुकसान करतात। कनेक्शन मॅनेजर टनेलसाठी डीफॉल्ट मार्ग आणि दूरच्या नेटवर्कसाठी अधिक विशिष्ट मार्ग बसवतो; नंतर हाताने लिहिलेली स्क्रिप्ट वेगळ्या मेट्रिकसह स्वतःचा डीफॉल्ट जोडते आणि वेळेनुसार शांतपणे जिंकते किंवा हरते। कोणत्या नोंदी कनेक्शन-आधारित आहेत, कोणत्या कायम धोरण आहेत, आणि कोणता घटक पुनःकनेक्शननंतर त्यांना ताज्या करतो ते ठरवा। नंतर इतर घटकांना त्या टेबलाबाहेर ठेवा।

धोरण नियमही त्याच स्पष्टतेस पात्र आहेत, कारण कोणीही न भरणार्या टेबलकडे निर्देश करणारा नियम मृत टनेलसारखाच दिसणारा काळा छिद्र निर्माण करतो। जर नियम रहदारीला कुठेतरी ढकलण्यासाठी असेल, तर तो जे टेबल निवडतो ते त्याच मालकाने सांभाळले पाहिजे।

DNS नेहमी वेगळा मालक असतो

रिझॉल्व्हर डेमन स्वतःच्या ओळखीखाली स्वतःची प्रक्रिया म्हणून चालतो, म्हणून तो टनेलचे राउटिंग निर्णय अपघाताने वारसा घेत नाही। VPN DNS सर्व्हर ढकलते तेव्हा, काहीतरी त्याचे रिझॉल्व्हर आदर करतो अशा प्रति-लिंक कॉन्फिगरेशनमध्ये भाषांतर करणे आवश्यक आहे, आणि नंतर काहीतरी ते काढून टाकणे आवश्यक आहे।

इथला गैरसमज असा आहे की प्रोफाइलमध्ये नेमसर्व्हर लिहिल्याने क्वेरी कुठे जातात ते बदलते। ते रिझॉल्व्हरला काय सांगितले जाते ते बदलते, रिझॉल्व्हर अपस्ट्रीममध्ये कोणता सॉकेट वापरतो ते नाही। फाइलवर विश्वास ठेवण्याऐवजी क्वेरी आणि मार्ग लुकअपने चाचणी करा।

फायरवॉल स्थिती, आणि ती कोण पुनर्संचयित करतो

फायरवॉल नियम VPN होस्टवर सर्वात जास्त वेळा पुन्हा लिहिले जाणारे वस्तू आहेत। मॅनेजर प्रत्येक कनेक्शनसाठी NAT किंवा फॉरवर्डिंग नियम जोडू शकतो, तर बूटच्या वेळची फायरवॉल सेवा साठवलेला नियमसंच पुन्हा लोड करते आणि ते पुसून टाकते। धोरणासाठी एक प्राधिकरण निवडा आणि दुसर्याला त्याचा ग्राहक बनवा, किंवा रीबूट वर्तन शांतपणे बदलते हे स्वीकारा। कनेक्शन-आधारित अपवाद त्याच फाइलमध्ये असावेत जी तोच मालक लोड करतो, ट्रबलशूटिंगदरम्यान टाइप केलेल्या iptables आदेशात नाही।

जर नियमांनी पुनःकनेक्शन टिकवायचे असेल, तर ते स्पष्ट सांगा। नसेल, तर तेही सांगा, कारण पुढचा अभियंता अधिक सोयीचे उत्तर गृहीत धरेल।

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

या तीन क्षणांपैकी प्रत्येकाला एक मालक द्या। बूटवेळी पूर्वअटी कोण तयार करतो आणि कोणत्या क्रमाने हे ठरवा। मऊ रीस्टार्टवेळी लक्षात ठेवा की डिव्हाइस टिकू शकते पण सत्र स्थिती नाही, म्हणून निर्मात्याऐवजी सत्यापनकर्त्याने चालले पाहिजे। टियरडाउनवेळी केवळ ह्या कनेक्शनने तयार केलेले काढा, कारण प्रत्येक मार्ग रीसेट करणे किंवा संपूर्ण फायरवॉल रिकामे करणे एक टनेल सेवेतून काढण्यासारखे नाही।

निरीक्षणासाठी ip monitor link address route कर्नेल बदल होताच दाखवतो, पण तो हेतू नाही, घटना कळवतो: हटवलेला मार्ग कोणत्या प्रक्रियेने हटवला हे सांगत नाही। त्याला मालकी नकाशासोबत जोडा, आणि गोंधळात टाकणारे शटडाउन उमेदवारांच्या छोट्या यादीत बदलेल।

अपवादांनाही किंमत असते। संघर्ष टाळण्यासाठी संपूर्ण डिव्हाइस वर्ग अव्यवस्थित म्हणून चिन्हांकित करणे ती स्थिती कोणालाही देत नाही, जो सुधारणा नाही, निर्णय आहे।