जवाब लैन से निकलता है, टनल से नहीं: क्यों और कैसे

किसी गेटवे से प्रकाशित सेवा इंटरनेट के अधिकांश हिस्से से काम करती है और एक दफ़्तर से विफल हो जाती है। कोई टनल जाँचता है, अनुरोध आते देखता है और निष्कर्ष निकालता है कि जवाब उसी रास्ते से लौटना चाहिए। लिनक्स ऐसे काम नहीं करता, और टनल की कितनी भी जाँच जवाब नहीं बदलेगी। जवाब गंतव्य के अनुसार रूट होता है, और वह एक विफल कॉलर ऐसे सबनेट पर बैठा है जहाँ मेज़बान पहले से सीधे पहुँचता है।

बाहर जाने वाला पैकेट असल में क्या तय करता है

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

इसलिए टनल पर मिला अनुरोध ऐसा जवाब दे सकता है जो भौतिक इंटरफ़ेस से बाहर जाए, और प्रवाह बिना किसी उपकरण के त्रुटि बताए एकतरफ़ा हो जाता है। टनल के बारे में निष्कर्ष निकालने से पहले दोनों दिशाएँ जाँचें। गलत दिशा में जाने वाला जवाब टनल के काउंटर से गायब हो जाता है, इसीलिए दोनों सिरे इस बात पर सहमत नहीं होते कि कुछ भेजा गया या नहीं। किसी नियम को छूने से पहले देखें कौन-सा काउंटर बदला।

स्थानीय सबनेट क्यों जीतता है

स्थानीय नेटवर्क पर पता रखने वाले मेज़बान के पास मुख्य तालिका में उस प्रीफ़िक्स के लिए जुड़ा हुआ रूट होता है, और जुड़ा हुआ रूट सीधा मेल है। जब कॉलर उसी सबनेट से आता है, तो खोज टनल पर विचार करने से पहले ही स्थानीय लिंक ढूँढ लेती है।

यही असमानता निदान को उलझाने वाली बनाती है। व्यापक इंटरनेट के कॉलर काम करते हैं क्योंकि वे किसी स्थानीय रूट से मेल नहीं खाते, जबकि दफ़्तर का प्रीफ़िक्स साझा करने वाला अकेला कॉलर विफल होता है, और किसी परीक्षण के लिए ठीक वही कॉलर इस्तेमाल होता है।

पीयर कवरेज और स्थापित रूट एक जैसे नहीं हैं

टनल की ओर, किसी पीयर की अनुमत श्रेणियाँ बताती हैं कि टनल में क्या भेजा जा सकता है और उससे कौन-से स्रोत स्वीकार किए जाते हैं। वे इस बारे में कुछ नहीं कहतीं कि स्थानीय रूटिंग तालिका पैकेट कहाँ भेजेगी।

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

स्रोत पते के अनुसार तालिका चुनें

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

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

अंतिम पंक्ति अनुपस्थित रूट को स्थानीय लिंक पर लौटने के बजाय दृश्य रूप से विफल कर देती है। स्रोत वास्तव में मेज़बान को सौंपा होना चाहिए, और सामान्य स्थानीय तथा मुख्य खोजें अपनी पहले की स्थितियों में ही रहनी चाहिए। नियम स्रोत के अनुसार तालिका चुनता है; यह तालिकाओं के बीच प्रीफ़िक्स लंबाई की तुलना नहीं करता।

पहले रास्ता, फिर सेवा की पुष्टि करें

कैप्चर से अनुमान लगाने के बजाय कर्नेल से पूछें कि वह क्या करेगा, सेवा पते को स्रोत चयनकर्ता के रूप में इस्तेमाल करते हुए। यहाँ गलत जवाब पूरी पैकेट ट्रेस बचा लेता है।

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

आउटपुट में टनल का नाम होना चाहिए। फिर ऐसे स्रोत का परीक्षण करें जिसे आपने छुआ नहीं और पुष्टि करें कि वह अब भी स्थानीय लिंक लेता है, ताकि बदलाव एक पते तक सीमित रहे। अधिक व्यापक चयनकर्ता मूल शिकायत के बारे में कुछ साबित नहीं करता।

यह क्या ठीक नहीं करता

गेटवे पर फ़ॉरवर्डिंग, फ़ायरवॉल नियम और ICMPv6 व्यवहार पहले जैसे ही रखें, क्योंकि स्रोत-रूट इनमें से कोई भी नहीं बदलता। अनुपस्थित Packet Too Big संदेश बड़े जवाबों को अब भी तोड़ता है, चाहे खोज में कोई भी तालिका जीते। रूटिंग नियम जोड़ने से पहले इसे ठीक करें, वरना बदलाव के बाद भी लक्षण बना रहेगा।

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

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