नेस्टेड WireGuard: बीच का हॉप अपने ही पोर्ट पर जवाब नहीं दे सकता
जब बीच का हॉप सब कुछ एक टनल में भेजता है, तो उसकी आने वाली सेवा के जवाब गलत रास्ते से निकलते हैं। इंटरफ़ेस पर स्रोत-पोर्ट नियम इसे ठीक करता है।
तीन WireGuard हॉप ऐसे नेटवर्क तक पहुँचते हैं जिसका कोई सार्वजनिक पता नहीं है, और फिर बीच की मशीन उस पोर्ट पर जवाब देना बंद कर देती है जिस पर उसे सुनना था। आगे की टनल अब भी काम करती है, दूर का होस्ट अब भी प्रतिक्रिया देता है, और केवल बीच का सर्वर ही बाहर से चुप हो गया है। यह संयोजन भ्रमित करने वाला है ठीक इसलिए कि यह स्वयं किया गया है: बीच का हॉप अपनी ही रूटिंग तालिका का पालन कर रहा है, और तालिका उसके जवाबों को गलत दिशा में भेजती है।
एक श्रृंखला जो तब तक काम करती है जब तक आप बीच के बक्से से बात न करें
एक उदाहरणात्मक श्रृंखला लें: क्लाइंट A UDP 500 पर सर्वर B तक पहुँचता है, और B UDP 500 पर सर्वर C तक आगे बढ़ता है। C केवल अपने एकमात्र साथी के पते से ट्रैफ़िक स्वीकार करता है, जो उसे एक पत्ता बनाता है और उसका व्यवहार सरल रखता है। B पत्ता नहीं है, और इस विफलता के बारे में सब कुछ दिलचस्प वहीं होता है।
यह अंतर मायने रखता है क्योंकि पत्ता और मध्य भूमिकाएँ विपरीत दिशाओं में खींचती हैं। एक पत्ता बिना किसी परिणाम के सब कुछ एक टनल में भेज सकता है, क्योंकि उस पर और कुछ निर्भर नहीं है। एक मध्य हॉप एक ही समय में क्लाइंट के लिए अंतिम बिंदु और दूर की ओर के लिए क्लाइंट है, और वे दो काम अलग रूटिंग चाहते हैं।
जवाब टनल से बाहर क्यों निकलता है
B पर, C की ओर मुख वाला इंटरफ़ेस मेल खाते डिफ़ॉल्ट रूट के साथ AllowedIPs = 0.0.0.0/0 वहन करता है। इसलिए B द्वारा उत्पन्न हर पैकेट उस टनल में जाता है, जब तक कि कोई अधिक विशिष्ट चीज़ प्राथमिकता न ले।
A से B को संबोधित पैकेट आता है और स्वीकार किया जाता है, क्योंकि B गंतव्य है और स्थानीय वितरण पहले होता है। जवाब A के सार्वजनिक पते पर लक्षित बिल्कुल नया स्थानीय रूप से उत्पन्न पैकेट है, और वह गंतव्य टनल में जाने वाले डिफ़ॉल्ट रूट से मेल खाता है। C उसे प्राप्त करता है, उस पते का स्वामी नहीं है, और उसे गिरा देता है।
लक्षण फ़ायरवॉल समस्या या कुंजी बेमेल जैसा पढ़ा जाता है, और यहाँ दोनों में से कोई सच नहीं है। C की ओर टनल पर कैप्चर दिखाता है कि जवाब गलत दिशा में जा रहे हैं। वह एक अवलोकन किसी भी मात्रा में कॉन्फ़िगरेशन पढ़ने से अधिक समय बचाता है, इसलिए कुंजियाँ बदलना शुरू करने से पहले उसे लिख लें। जिसने कैप्चर नहीं देखा वह मान लेगा कि टनल ही टूटी है।
संकीर्ण मरम्मत: स्रोत पोर्ट से मेल खाने वाले नीति नियम
B के सुनने वाले सॉकेट से जवाब स्रोत पोर्ट 500 के साथ निकलते हैं। एक नीति नियम उससे मेल खा सकता है और उन पैकेटों को सामान्य तालिका में वापस भेज सकता है:
ip rule add sport 500 table main priority 100
ip rule add sport 8080 table main priority 101नीति नियम प्राथमिकता क्रम में देखे जाते हैं, और मुख्य तालिका 32766 पर बैठती है, इसलिए 100 पर एक नियम टनल के डिफ़ॉल्ट रूट के बोलने से पहले पूछा जाता है। बाहर से पहुँचने योग्य रहने वाले हर पोर्ट के लिए एक प्रविष्टि जोड़ें और इससे अधिक कुछ नहीं, ताकि अग्रेषित ट्रैफ़िक उसी टनल का उपयोग करता रहे जिसके लिए उसे बनाया गया था।
इस युक्ति की सीमा जानें। sport चयनकर्ता स्थानीय रूप से उत्पन्न पैकेटों से मेल खाता है, जो ठीक जवाब के मामले को कवर करता है और जानबूझकर उस ट्रैफ़िक को कवर नहीं करता जिसे B केवल किसी और के लिए अग्रेषित करता है। B के पीछे होस्ट की गई सेवा को अब भी अपना जवाब चाहिए, और इसके विपरीत दिखावा करने से ऐसा उपाय मिलता है जो पहली सेवा के लिए काम करता है और दूसरी के लिए विफल होता है।
नियम को एक स्वामी दें
प्रॉम्प्ट पर टाइप किया गया नियम अगली बार इंटरफ़ेस के फिर से बनने पर गायब हो जाता है। WireGuard सेटअप में इसे वहाँ रखें जहाँ इंटरफ़ेस बनाया और हटाया जाता है:
PostUp = ip rule add sport 500 table main priority 100
PostDown = ip rule del sport 500 table main priority 100यदि NetworkManager, कोई वितरण हुक या कंटेनर प्रवेश बिंदु इंटरफ़ेस का स्वामी है, तो यह जोड़ी हाथ से संपादित फ़ाइल के बजाय उसी स्वामी की होनी चाहिए। फिर से कनेक्ट होने के बाद प्रभावी नियम जाँचें, केवल पहली शुरुआत के बाद नहीं, क्योंकि पहली शुरुआत वह मामला है जो हमेशा काम करता है।
विकल्पों की ईमानदार तुलना करें
स्रोत-पोर्ट नियम चार रास्तों में से एक है, और इनमें सबसे संकीर्ण है। इसका लाभ यह है कि यह टनल नीति को बिल्कुल नहीं छूता, इसलिए यह बाद के बदलावों में टिकने की प्रवृत्ति रखता है। संकीर्ण सुधार लागू होना बंद होने पर ज़ोर से विफल भी होते हैं, जबकि एक व्यापक अपवाद उसका कारण गायब होने के बहुत बाद तक चुपचाप काम करता रहता है। दो साल बाद जब बक्से का मालिक कोई और हो, तब यह अंतर सुरुचि से अधिक मायने रखता है।
| Approach | What it costs | Where it breaks |
|---|---|---|
| Source-port policy rule | One rule per exposed port | Anything B forwards rather than originates |
| Destination exception route | A route pinned to specific client addresses | Clients whose address changes |
| Stop full-tunnelling on B | Loses the catch-all path toward C | Designs that depend on it |
| Split into two tunnels | More interfaces and more policy | Nothing, at the cost of complexity |
चुनाव के बाद दोनों सिरों से सत्यापित करें। A से, B के पोर्ट पर कनेक्शन शुरू करें और उसे कुछ समय व्यस्त रखें। B पर, कर्नेल को ip route get <address-of-A> sport 500 जैसी किसी चीज़ से जवाब-पथ को न्यायसंगत ठहराने दें, और पुष्टि करें कि यह टनल के बजाय WAN इंटरफ़ेस का नाम लेता है। उसके बाद, जाँचें कि C के पीछे कुछ अब भी श्रृंखला से जवाब देता है, जो साबित करता है कि अपवाद बायपास बनने के बजाय संकीर्ण ही रहा। अंत में, पोर्ट डिज़ाइन नोट्स में दर्ज करें, वरना अगला ऑपरेटर इसे किसी दूसरी सेवा पर फिर से खोजेगा।