टनेल जोडते, नंतर प्रवेश लिंकवरील लीज नूतनीकरण ते मारते, आणि लॉग मार्गाला नाही तर कालबाह्यतेला दोष देतो। 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 पुन्हा तपासा। ते दोन वेळा करा, कारण दुसरी फेरी डुप्लिकेट मार्ग जोडणारे हुक पकडते। नंतर रीबूट करा, कारण टिकाऊपणा अचूकतेपेक्षा वेगळा गुण आहे।

नूतनीकरण आणि रीबूट टिकून राहणाऱ्या टनेलला मालक आणि कार्यरत अपवाद असतो। फक्त मॅन्युअल रीस्टार्ट टिकणाऱ्या टनेलकडे दोन्ही नसतात, आणि तुम्ही नियोजित करू शकत नाही अशा पुढील घटनेत ते अयशस्वी होईल।

संबंधित लेख