Linux EHOSTUNREACH OpenVPN सह: पुढील कोणता हॉप अयशस्वी झाला?

EHOSTUNREACH दूरच्या अपयशाइतकाच स्थानिक निर्णयही असतो. कर्नल पॅकेट नाकारू शकतो कारण मार्ग सांगतो की गंतव्य अगम्य आहे, कारण Ethernet चा पुढील हॉप कधीच उत्तर देत नाही, किंवा कारण मार्गाच्या पुढे दूरून ICMP host-unreachable अहवाल आला. प्रत्येक स्रोत वेगळ्या तक्त्यात किंवा कॅशेत राहतो आणि प्रत्येकजण वेगळ्या ठिकाणी दुरुस्त होतो. सिफरला स्पर्श करण्यापूर्वी किंवा बोगदा पुन्हा स्थापित करण्यापूर्वी निवडलेला मार्ग आणि पुढील हॉपची स्थिती वाचा.

क्लायंट प्रत्यक्षात वापरत असलेला पत्ता आणि नेमस्पेस निवडा

त्रुटी निर्माण करणारे गंतव्य आणि नेटवर्क नेमस्पेस निश्चित करून सुरुवात करा. VPN क्लायंट स्वतःच्या नेमस्पेसमध्ये चालू शकतो आणि डीफॉल्ट नेमस्पेसमधून केलेला शोध वेगळ्या धोरण नियमांसह दुसरा राउटिंग तक्ता पाहतो.

शोध अपयशी होणाऱ्या अनुप्रयोगाप्रमाणेच तोच स्रोत, मार्क आणि तक्ता संदर्भ वापरला पाहिजे, अन्यथा कोणीही न विचारलेल्या प्रश्नाचे उत्तर देऊ शकतो. उदाहरणार्थ IPv4 पीअरसाठी फक्त-वाचन तपासण्या या आहेत:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

प्रशासकीय शेलमधील निकाल त्या शेलने काय केले असते एवढेच सिद्ध करतो. जर क्लायंट फायरवॉल मार्क सेट करतो किंवा VRF ला बांधतो, तर जुळणाऱ्या मार्कसह किंवा VRF च्या आत शोध पुन्हा करा आणि निवडलेला मार्ग व पुढील हॉप यांची तुलना करा. पुष्टी करायचा पहिला पत्ता प्रोफाइलमधील पीअरचा पत्ता आहे, वापरकर्त्याने नाव दिलेले क्लस्टर किंवा सेवा नाही.

स्पष्ट अगम्य मार्ग पॅकेट स्थानिक पातळीवर नाकारतो

unreachable प्रकारचा मार्ग हेतुपूर्वक दिलेले स्थानिक उत्तर आहे. तो कर्नलला पॅकेट टाकून देण्यास आणि पाठवणाऱ्याला EHOSTUNREACH परत देण्यास सांगतो, म्हणून त्रुटी लगेच आणि यंत्रातून कोणताही रहदारी न जाता दिसते. कोणीतरी, किंवा कोणतेतरी ऑटोमेशन, तो मार्ग हेतुपूर्वक तिथे ठेवले आहे.

मार्गाचे प्रकार परस्पर बदलता येत नाहीत. Blackhole पाठवणाऱ्याला त्रुटी न देता पॅकेट टाकून देतो, prohibit EACCES परत देतो आणि unreachable EHOSTUNREACH परत देतो. त्यामुळे पुन्हा जोडणीच्या वेळी सिंक मार्ग स्थापित करणारा VPN सहाय्यक बोगदा उभा राहताच नाहीशा होणाऱ्या host-unreachable त्रुटींचा लोंढा निर्माण करू शकतो, तर blackhole मार्ग त्याऐवजी शांत कालबाह्यता निर्माण करेल.

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

मृत शेजारी Ethernet वर तीच त्रुटी निर्माण करतो

निवडलेला मार्ग ऑन-लिंक गेटवे वापरतो तेव्हा वितरणास सोडवलेला लिंक-स्तर पत्ता लागतो. कर्नल ARP किंवा IPv6 शेजारी विनंती पाठवतो आणि उत्तर न आल्यास पॅकेट फ्रेम करता येत नाही. मग मार्ग स्वतः वैध असला तरी पाठवणे EHOSTUNREACH ने अयशस्वी होते.

शेजारी तक्ता टप्प्याचे नाव देतो. INCOMPLETE म्हणजे निराकरण अजून सुरू आहे, FAILED म्हणजे शेवटच्या प्रयत्नाला उत्तर मिळाले नाही आणि REACHABLE किंवा STALE म्हणजे कर्नलकडे वापरण्यायोग्य पत्ता आहे. VPN गेटवेसाठी FAILED नोंद स्थानिक वितरण समस्या आहे, बोगद्याच्या दूरच्या बाजूबद्दल पुरावा नाही.

नोंद खऱ्या पुढील हॉपसाठी वाचा, दूरच्या इंटरनेट पत्त्यासाठी नाही. दूरच्या पत्त्यापर्यंत सामान्यतः राउटरमार्फत पोहोचतात, त्यामुळे त्याची स्वतःची ARP नोंद नसेल; ती मागणे ही श्रेणीविषयक चूक आहे जी लोकांना कधीच नसावी अशी गहाळ नोंद शोधायला पाठवते.

दूरचे अहवाल आणि असमकालिक UDP त्रुटी

EHOSTUNREACH बाहेरूनही येऊ शकतो. पॅकेट फॉरवर्ड करू न शकणारा राउटर ICMP host unreachable पाठवू शकतो आणि कर्नल तो अहवाल प्रवाहाच्या मालकीच्या सॉकेटला देतो. त्या बाबतीत मार्ग आणि शेजारी ठीक आहेत आणि अपयश स्थानिक नेटवर्कच्या पलीकडील हॉपचे आहे.

UDP आरोपण कठीण करते. नंतरच्या send किंवा receive कॉलने परत दिलेली त्रुटी आधीच्या डेटाग्रामला संदर्भित करू शकते, त्यामुळे अपयशी कॉलचा पत्ता आणि वेळ अहवाल उत्तेजित करणाऱ्या पॅकेटशी जुळणार नाही. जोडलेले UDP सॉकेट त्रुटी एकदा घेते आणि न जोडलेले सॉकेट ती कधीच पाहू शकत नाही.

म्हणून वेळ पुराव्याचा भाग आहे. त्रुटी कधी दिसली, सॉकेटने कोणता पीअर पत्ता वापरला आणि बोगदा नुकताच पुन्हा जोडला गेला का हे नोंदवा. मार्ग बदलानंतर लगेचचा लोंढा स्थानिक तक्त्याकडे निर्देश करतो; स्थिर प्रवाहाच्या काही मिनिटांनंतरची एकटी त्रुटी मार्ग अहवालाकडे.

क्रिप्टो बदलण्यापूर्वी स्तर वेगळे करा

तीन प्रश्न त्रुटीचे वर्गीकरण करतात. कर्नलने गंतव्य नाकारणारा मार्ग निवडला का? त्याने वैध मार्ग निवडला पण पुढील हॉप सोडवू शकला नाही का? किंवा स्थानिक नेटवर्कच्या पलीकडून अहवाल आला का? फक्त तिसरे प्रकरण बोगद्याच्या दूरच्या टोकाला गुंतवू शकते आणि तेव्हाही ते एन्क्रिप्शनला गुंतवत नाही.

प्रमाणीकरण आणि वाटाघाटीच्या समस्या वाहतूक पीअरपर्यंत पोहोचल्यानंतर स्वतःच्या त्रुटी म्हणून दिसतात. सिफर बदलणे किंवा क्लायंट पुन्हा स्थापित करणे स्थानिक unreachable मार्ग दुरुस्त करू शकत नाही आणि खऱ्या कारणासाठी लागणारे मार्ग व शेजारी पुरावे नष्ट करते.

पहिल्या बदलापूर्वी गंतव्य, नेमस्पेस, निवडलेला तक्ता, पुढील हॉप, शेजारीची स्थिती आणि त्रुटीची वेळ नोंदवा. दुरुस्तीनंतर तोच शोध पुन्हा चालवा; आता बोगद्याकडे निर्देश करणारा मार्ग आणि आता सोडवला जाणारा शेजारी नोंद असंबंधित पत्त्यावर यशस्वी ping पेक्षा मजबूत पुरावा आहे.