DHCP नवीनीकरण के बाद OpenVPN गिर जाता है: एंडपॉइंट रूट बनाए रखें

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

लक्षण की तुलना आधे-डिफ़ॉल्ट रूट से करें

redirect-gateway def1 के साथ, OpenVPN डिफ़ॉल्ट रूट बदलने के बजाय 0.0.0.0/1 और 128.0.0.0/1 स्थापित करता है। दोनों मिलकर पूरे पता-स्थान को ढक लेते हैं, और वे केवल प्रीफ़िक्स लंबाई से 0.0.0.0/0 को हरा देते हैं। इसलिए अधिक विशिष्ट मिलान के बिना कोई भी गंतव्य टनल में प्रवेश कर जाता है।

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

कुछ और छूने से पहले तालिका का आकार पुष्टि करें। ip route show को दोनों आधे और सर्वर पते के लिए एक होस्ट रूट सूचीबद्ध करना चाहिए; जब होस्ट रूट गायब हो, तो जाँच के बाकी हिस्से को स्पष्ट शुरुआती बिंदु मिल जाता है।

मीट्रिक बदले बिना आधे-डिफ़ॉल्ट क्यों जीतते हैं

कम मीट्रिक लंबे प्रीफ़िक्स को नहीं हराता। /1 रूट जीतते हैं क्योंकि कर्नेल पहले सबसे विशिष्ट रूट का मिलान करता है, इसलिए डिफ़ॉल्ट रूट पर मीट्रिक बढ़ाने से टनल की ओर जाने वाले ट्रैफ़िक की दिशा में कुछ नहीं बदलता। मीट्रिक के पीछे भागना इस निदान में सबसे आम ग़लत मोड़ है।

ip route get 203.0.113.10 से चयन जाँचें, उसमें सर्वर का असली पता डालकर। जवाब वह इंटरफ़ेस और अगला हॉप बताता है जो कर्नेल वास्तव में उपयोग करता, और यह तालिका पढ़कर उस पर सोचने से अधिक जानकारीपूर्ण है।

वह कमांड टनल शुरू होने से पहले, चालू रहने के दौरान और लीज़ घटना के बाद चलाएँ। एक कमांड से तीन जवाब, और विचलन बिंदु दिखाई देने लगता है।

एक नहीं, तीन स्नैपशॉट लें

एक्सेस पता, एक्सेस गेटवे, एंडपॉइंट गंतव्य, चयनित रूट और कोई भी नीति नियम तीन क्षणों में इकट्ठा करें: एक्सेस लिंक कॉन्फ़िगर होने के बाद, VPN जुड़ने के बाद, और लीज़ या कैरियर घटना के बाद। हर स्नैपशॉट मुट्ठी भर कमांड है, और उनका अर्थ केवल साथ में है। विफलता के बाद का एक अकेला स्नैपशॉट बदलाव को नहीं, स्थिति को दर्ज करता है। कमांड को एक छोटी स्क्रिप्ट में लिखें ताकि हर स्नैपशॉट एक ही तरह से लिया जाए।

स्नैपशॉट को टाइमस्टैम्प के साथ एक फ़ाइल में रखें, क्योंकि बाद में दिलचस्प सवाल क्रम है। DHCP घटना OpenVPN के अपना रूट ताज़ा करने से पहले आई या बाद में? जवाब तय करता है कि इसे किसे ठीक करना है। गलत घड़ी का टाइमस्टैम्प न होने से बुरा है, इसलिए इसे उस होस्ट से लें जो रूटिंग तालिका का मालिक है।

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

तय करें कि कौन-सा घटक अपवाद को ताज़ा करता है

dhcpcd सिस्टम में, हुक हुक निर्देशिका से और एग्ज़िट हुक से चलते हैं, और मैनेजर मोड का दायरा प्रति-इंटरफ़ेस मोड से अलग होता है। हुक जो भी करे, उसे इडेम्पोटेंट होना चाहिए, क्योंकि नवीनीकरण झुंड में आ सकते हैं।

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

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

केवल फिर से जुड़ाव नहीं, जीवनचक्र परखें

dhcpcd -n eth0 से या लीज़ छोड़कर फिर लेकर नवीनीकरण थोपें, फिर एंडपॉइंट के लिए ip route get फिर से जाँचें। इसे दो बार करें, क्योंकि दूसरा दौर उन हुक पकड़ता है जो डुप्लिकेट रूट जोड़ते हैं। फिर रीबूट करें, क्योंकि स्थायित्व शुद्धता से अलग गुण है।

नवीनीकरण और रीबूट दोनों झेलने वाली टनल का एक स्वामी और काम करने वाला अपवाद होता है। जो केवल मैन्युअल रीस्टार्ट झेलती है, उसके पास दोनों नहीं हैं, और वह अगली उस घटना पर विफल होगी जिसे आप शेड्यूल नहीं कर सकते।