Linux VPN पर पता, रूट, DNS और फ़ायरवॉल का मालिक कौन है?

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

यह नक्शा एक बार लिखिए, और ज़्यादातर पुनः कनेक्शन विफलताएँ रहस्यमय रहना बंद कर देंगी। चार वस्तुएँ मायने रखती हैं: डिवाइस और उसके पते, रूट और नीति नियम, DNS कॉन्फ़िगरेशन और फ़ायरवॉल।

डिवाइस और उसके पते

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

सेशन खत्म होने पर डिवाइस कौन हटाता है, यह दर्ज कीजिए। जो डिवाइस अपने सेशन से ज़्यादा जीता है, वही पुराने पतों और उनके बाद की उलझन का सबसे आम स्रोत है।

रूट और नीति नियम

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

नीति नियम भी उसी स्पष्टता के हकदार हैं, क्योंकि ऐसी टेबल की ओर इशारा करने वाला नियम जिसे कोई नहीं भरता, एक काला छेद बनाता है जो ठीक मरे हुए टनल जैसा दिखता है। अगर कोई नियम ट्रैफ़िक को कहीं धकेलने के लिए है, तो जिस टेबल को वह चुनता है उसे उसी मालिक को बनाए रखना होगा।

DNS हमेशा अलग मालिक है

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

यहाँ मिथक यह है कि प्रोफ़ाइल में नेमसर्वर लिखने से बदलता है कि क्वेरी कहाँ जाती हैं। यह बदलता है कि रिज़ॉल्वर को क्या बताया जाता है, यह नहीं कि रिज़ॉल्वर अपस्ट्रीम में कौन-सा सॉकेट इस्तेमाल करता है। फ़ाइल पर भरोसा करने के बजाय क्वेरी और रूट लुकअप से परखिए।

फ़ायरवॉल स्टेट, और उसे कौन बहाल करता है

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

अगर नियमों को पुनः कनेक्शन झेलना है, तो यह स्पष्ट कहिए। अगर नहीं झेलना, तो वह भी कहिए, क्योंकि अगला इंजीनियर ज़्यादा सुविधाजनक जवाब मान लेगा।

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

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

निरीक्षण के लिए ip monitor link address route कर्नेल बदलाव होते ही दिखाता है, लेकिन यह मंशा नहीं, घटनाएँ बताता है: हटाया गया रूट यह नहीं बताता कि किस प्रक्रिया ने उसे हटाया। इसे मालिकी नक्शे के साथ जोड़िए, और उलझाने वाला शटडाउन उम्मीदवारों की छोटी सूची बन जाता है।

अपवादों की भी कीमत होती है। टकराव से बचने के लिए पूरी डिवाइस श्रेणी को अप्रबंधित चिह्नित करना उस स्टेट को किसी को नहीं देता, जो सुधार नहीं, एक निर्णय है।