एक VPN साथी दूसरे इंटरफ़ेस पर पिंग करता है क्योंकि वे स्थानीय हैं

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

एक पथ किसी और के लिए पैकेट फ़ॉरवर्ड करता है; दूसरा उन्हें होस्ट तक ही पहुँचाता है।

होस्ट को संबोधित पैकेट होस्ट में ही रहता है

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

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

ip_forward लागू क्यों नहीं होता

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

इसीलिए फ़ॉरवर्डिंग बंद करना और यह मानना कि होस्ट अलग-थलग है, सुरक्षा का झूठा अहसास पैदा करता है।

वह स्थानीय तालिका पढ़ें जिसने निर्णय लिया

ip rule show आम तौर पर शून्य प्राथमिकता वाला नियम बताता है जो सभी खोजों को पहले स्थानीय तालिका में भेजता है, और ip route show table local होस्ट के अपने पतों को स्थानीय क्षेत्र के साथ सूचीबद्ध करता है। उस तालिका में उन इंटरफ़ेसों के पते भी शामिल हैं जो प्रशासनिक रूप से बंद हैं पर अभी भी कॉन्फ़िगर हैं। स्थिर रूप से दिए गए IPv4 पते आम तौर पर लिंक टूटने पर भी बने रहते हैं, और इसी तरह बंद पुल पर पिंग अभी भी सफल हो सकती है और ऑपरेटर को चौंका सकती है।

IPv6 ठीक इसी बिंदु पर असहमत है। लिंक टूटने पर उसके पते आम तौर पर वापस ले लिए जाते हैं, जब तक keep_addr_on_down सेट न हो। एक नियम दोनों को कवर करता है यह मानने के बजाय परिवारों की तुलना करें।

एक साथी वास्तव में कहाँ तक पहुँचता है

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

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

उन पतों की भी जाँच करें जिन्हें आप हटाना चाहते थे। किसी इंटरफ़ेस से पता हटाना पुराने पते के ऊपर फ़ायरवॉल नियमों को ढेर करने से अधिक विश्वसनीय है।