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 से अधिक मजबूत प्रमाण हैं।