mDNS बनाम WireGuard: पीयर के जवाब देने से पहले तीन द्वार
Avahi को एक योग्य इंटरफ़ेस, समूह तक एक रूट और गंतव्य का स्वामी एक पीयर चाहिए। तीन द्वार, तीन अलग जाँचें और कोई फ़ैन-आउट नहीं।
WireGuard डिवाइस पर मल्टीकास्ट फ़्लैग सेट करने से इंटरफ़ेस डिस्कवरी सॉफ़्टवेयर के लिए योग्य हो जाता है, और फ़्लैग बस इतना ही करता है। यह प्रोटोकॉल को नहीं बताता कि समूह पैकेट कहाँ जाना चाहिए, और कई पीयर वाले डिवाइस पर कोई एक स्पष्ट उत्तर नहीं होता। चल रहे डेमॉन और खोजी गई सेवा के बीच तीन अलग द्वार खड़े हैं।
इन्हें क्रम में जाँचें, क्योंकि एक पार करना अगले के बारे में कुछ नहीं बताता।
पहला द्वार: फ़्लैग और डेमॉन की नीति
Linux WireGuard डिवाइस ARP के बिना पॉइंट-टू-पॉइंट लिंक के रूप में बनाया जाता है, और डिफ़ॉल्ट रूप से मल्टीकास्ट फ़्लैग नहीं रखता। फ़्लैग जोड़ना एक स्थानीय इंटरफ़ेस परिवर्तन है, जो डिवाइस को प्रबंधित करने वाला कोई भी करता है। Avahi का इसके ऊपर अपना विश्वदृष्टिकोण है, और उसकी डिफ़ॉल्ट नीति पॉइंट-टू-पॉइंट इंटरफ़ेस को पूरी तरह छोड़ देती है। इसलिए एक भी पैकेट हिलने से पहले दो स्वतंत्र योग्यता परीक्षण लागू होते हैं।
इसलिए डेमॉन को स्पष्ट निर्णय चाहिए, केवल चल रही प्रक्रिया नहीं। इसके प्रलेखित नियंत्रणों में allow-interfaces, deny-interfaces और allow-point-to-point शामिल हैं, और अंतिम वह सेटिंग है जिसे लोग चूक जाते हैं।
नीचे दी गई जाँचें लिंक फ़्लैग, मल्टीकास्ट रूट और यह बताती हैं कि डेमॉन का कॉन्फ़िगरेशन पार्स होता भी है या नहीं:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkसफलतापूर्वक शुरू हुआ डेमॉन ज़रूरी नहीं कि आपके लिए महत्वपूर्ण इंटरफ़ेस पर सॉकेट खोल चुका हो। सेवा की स्थिति को कवरेज मान लेने के बजाय उसका प्रभावी कॉन्फ़िगरेशन पढ़ें।
दूसरा द्वार: समूह तक रूट
दूसरा द्वार सामान्य रूटिंग है। 224.0.0.251 पर भेजा गया पैकेट बाकी सब की तरह फ़ॉरवर्डिंग तालिका का पालन करता है, और यदि तालिका उसे भौतिक LAN इंटरफ़ेस से बाहर भेजती है तो कोई WireGuard कॉन्फ़िगरेशन इसे नहीं बदलेगा। पहले रूट ठीक करें, फिर बाकी जाँच छोटी हो जाएगी। कोई भी पीयर कुंजी छूने से पहले देखें कि कर्नेल समूह पते के बारे में क्या बताता है।
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
विशिष्ट रूट के बिना, कर्नेल लिंक की अपनी मल्टीकास्ट हैंडलिंग पर लौट आता है, इसलिए डिफ़ॉल्ट एक सपाट LAN पर सही दिखता है और तभी ग़लत जब वही समूह ट्रैफ़िक टनल से बाहर जाना हो। विफलता भेजने वाले की ओर से शांत होती है: क्वेरी कहीं जाती है, और जवाब कभी नहीं आता।
तीसरा द्वार: WireGuard प्रति पैकेट एक पीयर चुनता है
WireGuard अनुमत पते के समुच्चय में गंतव्य खोजकर बाहर जाने वाला पीयर चुनता है, और Linux का ट्रांसमिट पथ यह खोज प्रति पैकेट एक बार करता है। परिणाम एक ही होता है, और पैकेट उस पीयर के लिए एन्क्रिप्ट होता है। एक ही समूह प्रीफ़िक्स कई पीयर की अनुमत सूचियों में दिखने से सदस्यता या प्रतिकृति नहीं बनती; यह एक अस्पष्ट खोज बनाती है जो उनमें से एक पर तय होती है।
दो-सिरे वाले समर्पित लिंक पर यह ठीक वही है जो आप चाहते हैं, क्योंकि जान-बूझकर ढोए जाने वाले समूह ट्रैफ़िक के लिए एक ही इच्छित प्राप्तकर्ता है। पाँच पीयर वाले इंटरफ़ेस पर यह सीमा है, विशेषता नहीं, और सुधार किसी एक पीयर के कॉन्फ़िगरेशन में नहीं, डिज़ाइन में होना चाहिए।
फ़ैन-आउट डिज़ाइन को स्पष्ट रिले, अलग लिंक या पूरी तरह भिन्न डिस्कवरी तंत्र चाहिए। हर क्लाइंट गेटवे को पिंग कर सकता है इसलिए दो-सिरे वाले नुस्खे को बहु-क्लाइंट समाधान के रूप में प्रकाशित करना — इसी तरह यह ग़लत तैनात होता है।
आवक दिशा अलग तरह से जाँची जाती है: प्राप्त पैकेट का स्रोत प्रमाणित पीयर की अनुमत सूची के भीतर होना चाहिए। वहाँ मल्टीकास्ट गंतव्य जोड़ना भेजने वाले के वास्तविक स्रोत-स्वामित्व का स्थान नहीं लेता।
परावर्तन एक सीमा है, पुल नहीं
Avahi का परावर्तक अपने चुने हुए इंटरफ़ेस के बीच mDNS संदेशों को अनुप्रयोग परत पर पुनरुत्पादित करता है। यह नेटवर्क के बीच डिस्कवरी सीमा है, Ethernet पुल नहीं और सामान्य मल्टीकास्ट राउटर नहीं। एक ही नेटवर्क से जुड़े दो परावर्तक आसानी से दोहराई गई घोषणाओं का लूप बना देंगे।
परावर्तन सेवा नाम और उनका मेटाडेटा किसी दूसरे नेटवर्क को भी सौंपता है, जो रूटिंग निर्णय जितना ही गोपनीयता का निर्णय है। चुने हुए इंटरफ़ेस को सीमित करें, और जहाँ स्थापित संस्करण समर्थन देता है वहाँ सेवा फ़िल्टर का उपयोग करें, ताकि केवल अधिकृत उपयोगकर्ता को ज़रूरी घोषणाएँ ही सीमा पार करें।
खोज और उपयोग अलग परिणाम रहते हैं। कोई क्लाइंट ऐसी सेवा की घोषणा देख सकता है जिसका घोषित पता क्लाइंट जहाँ है वहाँ से पहुँच से बाहर है, या जिसका पोर्ट उसकी एक्सेस नीति अस्वीकार करती है। घोषणा दिखने के बाद सेवा कनेक्शन की पुष्टि करें, और यदि अनुप्रयोग स्थिर DNS नाम या स्पष्ट सर्वर पता समर्थित करता है तो लिंक-लोकल डिस्कवरी बढ़ाने के बजाय उसे प्राथमिकता दें। क्रिप्टोकी रूटिंग का विवरण उस गंतव्य-आधारित पीयर चयन को कवर करता है जिस पर यह सब निर्भर है।