mDNS WireGuard माथि: सहकर्मीले जवाफ दिनुअघि तीन ढोका
Avahi लाई योग्य इन्टरफेस, समूहसम्मको रुट र गन्तव्यको मालिक सहकर्मी चाहिन्छ। तीन ढोका, तीन छुट्टै जाँच र कुनै फ्यान-आउट छैन।
WireGuard यन्त्रमा multicast झन्डा सेट गर्दा इन्टरफेस खोजी सफ्टवेयरका लागि योग्य हुन्छ, र झन्डाले यत्ति मात्र गर्छ। यसले प्रोटोकललाई समूह प्याकेट कहाँ जानुपर्छ भनी बताउँदैन, र धेरै सहकर्मी भएको यन्त्रमा एउटै स्पष्ट जवाफ हुँदैन। चलिरहेको डेमन र फेला परेको सेवाबीच तीन छुट्टै ढोका उभिएका छन्।
तिनीहरूलाई क्रममा जाँच्नुहोस्, किनकि एउटा पार गर्नुले अर्कोबारे केही भन्दैन।
पहिलो ढोका: झन्डा र डेमनको नीति
Linux WireGuard यन्त्र ARP बिना पोइन्ट-टु-पोइन्ट लिङ्कका रूपमा बनाइन्छ, र पूर्वनिर्धारित रूपमा multicast झन्डा बोक्दैन। झन्डा थप्नु स्थानीय इन्टरफेस परिवर्तन हो, जुन यन्त्र व्यवस्थापन गर्ने जुनसुकैले गर्छ। Avahi को यस माथि आफ्नै संसारदृष्टि छ, र यसको पूर्वनिर्धारित नीतिले पोइन्ट-टु-पोइन्ट इन्टरफेसलाई पूर्ण रूपमा छोड्छ। त्यसैले एक प्याकेट पनि सर्नुअघि दुई स्वतन्त्र योग्यता परीक्षण लागू हुन्छन्।
त्यसैले डेमनलाई स्पष्ट निर्णय चाहिन्छ, केवल चलिरहेको प्रक्रिया होइन। यसका अभिलेखित नियन्त्रणहरूमा allow-interfaces, deny-interfaces र allow-point-to-point पर्छन्, र अन्तिम त्यो सेटिङ हो जुन मानिसहरूले छुटाउँछन्।
तलका जाँचहरूले लिङ्क झन्डा, multicast रुट र डेमनको कन्फिगरेसन पार्स हुन्छ कि हुँदैन भनी जानकारी दिन्छन्:
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 |
विशेष रुट नभएमा कर्नेल लिङ्कको आफ्नै multicast ह्यान्डलिङमा फर्किन्छ, त्यसैले पूर्वनिर्धारित समतल LAN मा सही देखिन्छ र त्यही समूह ट्राफिक सुरुङबाट बाहिर जानुपर्ने बित्तिकै गलत देखिन्छ। विफलता पठाउनेको तर्फबाट शान्त हुन्छ: क्वेरी कतै जान्छ, र जवाफ कहिल्यै आउँदैन।
तेस्रो ढोका: WireGuard प्रति प्याकेट एक सहकर्मी छान्छ
WireGuard ले अनुमत ठेगाना समूहहरूमा गन्तव्य खोजेर बाहिर जाने सहकर्मी छनोट गर्छ, र Linux को ट्रान्समिट मार्गले त्यो खोजी प्रति प्याकेट एक पटक गर्छ। नतिजा एउटै हुन्छ, र प्याकेट त्यो सहकर्मीका लागि इन्क्रिप्ट हुन्छ। एउटै समूह प्रिफिक्स धेरै सहकर्मीका अनुमत सूचीमा देखिनुले सदस्यता वा प्रतिलिपि बनाउँदैन; यसले एउटा अस्पष्ट खोजी बनाउँछ जो तिनीहरूमध्ये एकमा टुंगिन्छ।
दुई छेउ भएको समर्पित लिङ्कमा यो ठ्याक्कै तपाईंले चाहेको हो, किनकि जानाजानी बोकिएको समूह ट्राफिकका लागि एउटै अभीष्ट प्राप्तकर्ता हुन्छ। पाँच सहकर्मी भएको इन्टरफेसमा यो सीमा हो, विशेषता होइन, र सुधार कुनै एक सहकर्मीको कन्फिगरेसनमा होइन, डिजाइनमा हुनुपर्छ।
फ्यान-आउट डिजाइनलाई स्पष्ट रिले, छुट्टै लिङ्क वा पूर्ण रूपमा फरक खोजी संयन्त्र चाहिन्छ। प्रत्येक क्लाइन्टले गेटवे पिङ गर्न सक्छ भनेर दुई-छेउ रेसिपीलाई बहु-क्लाइन्ट समाधानका रूपमा प्रकाशित गर्नु — यसरी नै यो गलत रूपमा तैनाथ हुन्छ।
आगमन दिशा फरक तरिकाले जाँचिन्छ: प्राप्त प्याकेटको स्रोत प्रमाणित सहकर्मीको अनुमत सूचीभित्र पर्नुपर्छ। त्यहाँ multicast गन्तव्य थप्नुले पठाउनेको वास्तविक स्रोत-स्वामित्वको प्रतिस्थापन गर्दैन।
परावर्तन सीमा हो, पुल होइन
Avahi को परावर्तकले आफ्ना छानिएका इन्टरफेसबीच mDNS सन्देशहरू अनुप्रयोग तहमा पुनरुत्पादन गर्छ। यो नेटवर्कबीचको खोजी सीमा हो, इथरनेट पुल होइन र सामान्य multicast राउटर होइन। एउटै नेटवर्कमा जोडिएका दुई परावर्तकले सजिलै दोहोरिएका घोषणाहरूको लूप बनाउनेछन्।
परावर्तनले सेवाका नाम र तिनका मेटाडाटा अर्को नेटवर्कमा पनि सुम्पन्छ, जो रुटिङ निर्णयजत्तिकै गोपनीयताको निर्णय हो। छानिएका इन्टरफेस सीमित गर्नुहोस्, र स्थापित संस्करणले समर्थन गर्ने ठाउँमा सेवा फिल्टर प्रयोग गर्नुहोस्, ताकि अधिकृत प्रयोगकर्तालाई आवश्यक घोषणाहरू मात्र सीमा पार गरून्।
खोजी र प्रयोग छुट्टै नतिजा रहन्छन्। क्लाइन्टले क्लाइन्ट रहेको ठाउँबाट घोषित ठेगाना पुग्न नसकिने सेवाको वा त्यसको पहुँच नीतिले पोर्ट अस्वीकार गर्ने सेवाको घोषणा देख्न सक्छ। घोषणा देखा परेपछि सेवा जडान पुष्टि गर्नुहोस्, र यदि अनुप्रयोगले स्थिर DNS नाम वा स्पष्ट सर्भर ठेगाना समर्थन गर्छ भने लिङ्क-स्थानीय खोजी विस्तार गर्नुको सट्टा त्यसैलाई प्राथमिकता दिनुहोस्। क्रिप्टोकी रुटिङको विवरण ले यी सबै अवलम्बित गन्तव्य-आधारित सहकर्मी छनोट समेट्छ।