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 भन्दा बलियो प्रमाण हुन्।