WireGuard पीयर गलत WAN से निकलता है: पाँच जाँच क्रम में

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

नीचे दी गई जाँचें क्रम में करें। हर एक की एक रुकने की शर्त है, और आगे कूदना आम तौर पर एक आत्मविश्वासी ग़लत उत्तर देता है।

हैंडशेक को फ़ॉरवर्ड किए गए प्रवाह से अलग करें

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

जैसे ही आप ख़ुद को हैंडशेक से तर्क करते पकड़ें, रुक जाएँ। यह केवल एंडपॉइंट पथ के बारे में सबूत है।

पॉलिसी नियम पढ़ें, डिफ़ॉल्ट तालिका नहीं

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

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

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

मार्क और अनुवाद एक साथ जाँचें

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

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

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

देखें कौन सा इंटरफ़ेस उत्तर ले जाता है

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

यदि उत्तर गलत अपलिंक से आता है, तो समस्या WireGuard से कनेक्शन ट्रैकिंग या अनुवाद की ओर चली गई है। पीयर कॉन्फ़िगरेशन में कोई भी बदलाव इसे ठीक नहीं करेगा।

वापसी के रास्ते के साथ एक चीज़ बदलें

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

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