पुनरावर्ती रूटिंग: जब सुरंग अपने ही पैकेट पकड़ लेती है

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

पहले बाहरी पथ जाँचें

खेल में दो पैकेट हैं, एक नहीं। भीतरी पैकेट अनुप्रयोग का है और उसे एन्क्रिप्ट होना चाहिए, जबकि बाहरी पैकेट सर्वर को संबोधित है और उसे ऐसे पथ से वहाँ पहुँचना चाहिए जो सुरंग पर निर्भर न हो।

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

सुरंग ऊपर आने के बाद कर्नेल से सर्वर के पते तक का मार्ग पूछें, और डिफ़ॉल्ट रूट बदलने के बाद फिर पूछें। अगला हॉप अगर सुरंग के उपकरण पर उतरता है तो वही पुनरावृत्ति है, और वह किसी पैकेट कैप्चर के बिना दिखाई देती है। इंटरफ़ेस बाइंडिंग, मार्क या नेटवर्क नेमस्पेस सामान्य खोज को अधूरा बना सकते हैं, इसलिए वही संदर्भ इस्तेमाल करें जो क्लाइंट स्वयं इस्तेमाल करता है। जब उत्तर सही लगे पर सत्र अब भी लूप में हो, केवल मुख्य तालिका नहीं, रूटिंग नीति के नियम पढ़ें।

सत्र कुछ पल क्यों टिकता है

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

यही क्रम बताता है कि सुरंग लैपटॉप पर क्यों काम कर सकती है और राउटर पर क्यों विफल हो सकती है, और विफलता क्यों अक्सर ट्रैफ़िक शुरू होने पर होती है, जुड़ने के समय नहीं। यह लूप को भी समझाता है: हर पुनःआरंभ सत्र को फिर से स्थापित करता है, इससे पहले कि मार्ग उसे असंभव बना दे।

पता करें एंडपॉइंट के अपवाद का स्वामी कौन है

समर्थित क्लाइंट अपना अपवाद स्वयं व्यवस्थित करते हैं: मूल गेटवे से सर्वर तक होस्ट मार्ग, या ऐसा मार्क जो बाहरी सॉकेट को सुरंग से बाहर रखता है। प्रश्न यह है कि क्या किसी और चीज़ ने उसे हटाया या उसका अतिक्रमण किया।

रूट-आधारित IPsec में उन नीति चयनकर्ताओं को देखें जो तय करते हैं कि कौन से पैकेट सुरंग में प्रवेश करते हैं, और पुष्टि करें कि पीयर का पता उनसे बाहर रखा गया है। WireGuard में इंटरफ़ेस का फ़ायरवॉल मार्क और उसके नीति नियम परिवहन पैकेटों को सुरंग से बाहर रखते हैं, इसलिए हाथ से जोड़ा गया डिफ़ॉल्ट रूट उस व्यवस्था को तोड़ सकता है। दूसरा VPN प्रोफ़ाइल या डिफ़ॉल्ट रूट फिर से लिखने वाली प्रबंधन स्क्रिप्ट आमतौर पर दोषी होती है। एक-एक करके जोड़े गए व्यापक बायपास नियम सामान्य परिणाम हैं, और वे रूटिंग बग को ऐसी तालिका में बदल देते हैं जिसे कोई बनाए नहीं रख सकता।

नेटवर्क बदलने के बाद फिर जाँचें

Wi-Fi गेटवे से जाने वाला होस्ट मार्ग तब तक सही है जब तक मशीन किसी दूसरे नेटवर्क पर न चली जाए। तब वही लक्षण बिना किसी कॉन्फ़िगरेशन बदलाव के लौट आता है।

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

नए नेटवर्क पर फिर से जुड़ें और पढ़ना दोहराएँ। अगर अपवाद फिर से गायब है, तो सुधार उसी प्रोफ़ाइल में है जो उसका स्वामी है, रुकावट के दौरान टाइप किए गए एक-बार के आदेश में नहीं।