दुई WireGuard peer एउटै दायरा साझा गर्छन्: प्याकेट कसले पाउँछ

दुई peer एकअर्कालाई छुने दायराहरू सूचीबद्ध गर्छन्, र ट्राफिक गलत कहाँ पुग्छ। केही पनि बिग्रिएको छैन: WireGuard गन्तव्यलाई कन्फिगर गरिएका दायराहरूसँग मिलाएर peer छान्छ, र सबैभन्दा विशिष्ट मिलान जित्छ। केही फराकिलो बनाउनुअघि कुन peer ले कुन प्रिफिक्स राख्नुपर्छ भन्ने निर्णय गर्नुहोस्।

WireGuard भित्र सबैभन्दा लामो प्रिफिक्स जित्छ

प्रत्येक peer प्रविष्टिले गन्तव्य प्रिफिक्सहरूको समूह बोक्छ। जब प्याकेट इन्टरफेसमा रुट हुन्छ, कार्यान्वयनले सबैभन्दा विशिष्ट मिल्ने प्रिफिक्स भएको प्रविष्टि खोज्छ — रुटिङ तालिकाले लागू गर्ने त्यही नियम। त्यसैले /24 ले यसलाई समावेश गर्ने /16 लाई हराउँछ, र साँघुरो peer ले ट्राफिक प्राप्त गर्छ।

road-warrior सेटअपहरूले यो जानाजान प्रयोग गर्छन्। एउटा peer ले साइटका लागि फराकिलो दायरा राख्छ, र व्यक्तिगत होस्टहरू अरू peer का /32 प्रविष्टिले अलग गरिन्छन्। यो ढाँचा काम गर्छ किनभने अलग गरिएका भागहरू बढी विशिष्ट छन्, क्रमको कारणले होइन।

स्वामित्वलाई प्रिफिक्स र peer को तालिकाका रूपमा लेख्नुहोस्। यदि दुई प्रविष्टिले एउटै प्रिफिक्स वर्णन गर्छन् भने, कन्फिगरेसनले अब इरादा व्यक्त गर्दैन, यसले दौड व्यक्त गर्छ।

अपरेटिङ सिस्टमले पहिले इन्टरफेस छान्छ

WireGuard एउटा इन्टरफेसका peer हरूबीच मात्र छान्छ। कुन इन्टरफेसले प्याकेट पाउँछ भन्ने पहिले नै होस्टको रुटिङ तालिकाले निर्धारण गर्छ, र दोस्रो पूर्वनिर्धारित रुट वा पुरानो रुटले ट्राफिकलाई peer सूचीले कहिल्यै नदेख्ने ठाउँमा पठाउन सक्छ। त्यसैले peer स्तरको निदान सही हुन सक्छ र तैपनि विफलता व्याख्या गर्न सक्दैन। peer कन्फिगरेसन पढ्नुअघि गन्तव्यको रुट जाँच्नुहोस्, किनभने भौतिक इन्टरफेसतर्फ देखाउने रुटले सम्पूर्ण प्रश्नलाई वास्ता गर्दैन।

उपकरणले सामान्यतया ती रुटहरू peer दायराहरूबाट स्थापना गर्छ, जसको अर्थ एउटा peer को सूचीमा परिवर्तनले पहिले अर्काको भएको ट्राफिकलाई चुपचाप पुनः निर्देशित गर्न सक्छ। त्यसैले peer सम्पादन भेष बदलेको रुटिङ परिवर्तन हो। दुवैलाई एकैचोटि समीक्षा गर्नुहोस्, नत्र एक सुधार्नुहुनेछ र अर्को तोड्नुहुनेछ।

आउने प्याकेटहरू स्रोतअनुसार जाँचिन्छन्

दायरा सूचीले दोहोरो भूमिका निभाउँछ। बाहिर जाने ट्राफिकका लागि यसले गन्तव्यअनुसार peer छान्छ, र भित्र आउने ट्राफिकका लागि यसले स्रोत ठेगानालाई अधिकृत गर्छ। त्यो peer का दायराबाहिरको ठेगानाबाट आउने प्याकेट कुनै फायरवालले देख्नुअघि नै खारेज गरिन्छ।

कन्फिगरेसनको एक पक्ष पढ्दा यो असमानता चुक्नु सजिलो छ। सबनेटसम्म पुग्न सक्ने peer लाई त्यसैले त्यो सबनेटबाट पठाउन अनुमति दिइँदैन, र दुवै दिशा फरक जाँचद्वारा लागू गरिन्छ।

साँघुरो स्रोत स्वामित्वले यसलाई लाभमा बदल्छ। प्रत्येक peer लाई आफ्नै ठेगानाका लागि /32 दिनुहोस् र तलको फायरवालसँग मिलाउन विश्वसनीय स्रोत हुनेछ, कुनै पनि सदस्यले दाबी गर्न सक्ने समूहव्यापी दायराको सट्टा।

नक्कली दायराहरू failover होइनन्

एउटै प्रिफिक्स दुई peer लाई दिनुले लोड ब्यालेन्सर वा स्ट्यान्डबाइ मार्ग बनाउँदैन। स्वास्थ्य जाँच छैन र सत्र आसक्ति छैन: जित्ने प्रविष्टि कार्यान्वयनको आन्तरिक क्रमले निर्धारण गर्छ, जो डिजाइन गर्नुपर्ने करार होइन। तपाईंलाई वैकल्पिक निकास चाहिएमा, चयन परिभाषित भएको ठाउँमा तिनलाई व्यक्त गर्नुहोस्। रुटिङ नीति, मेट्रिक, वा प्रत्येकको दस्तावेजीकृत मालिक भएका दुई फरक प्रिफिक्सले तपाईंले अनुमान र परीक्षण गर्न सक्ने व्यवहार उत्पादन गर्छ।

असम्बन्धित विफलता सुधार्न दायरा फराकिलो बनाउनु अर्को सामान्य गल्ती हो। यसले ट्राफिकलाई काम गरिरहेको peer बाट टाढा सार्छ, र पुरानो बुझिनुअघि नै नयाँ लक्षण आउँछ।

सम्पादन गर्नुअघि चयन प्रमाणित गर्नुहोस्

तीन आदेशले तीन प्रश्नको क्रममा उत्तर दिन्छन्। पहिलोले प्रत्येक peer ले दाबी गर्ने दायराहरू सूचीबद्ध गर्छ। दोस्रोले होस्टले गन्तव्यका लागि कुन इन्टरफेस प्रयोग गर्ने देखाउँछ। तेस्रोले ट्राफिक बहेपछि peer हरूको प्रत्यक्ष अवस्था देखाउँछ।

wg show wg0 allowed-ips
ip route get 10.66.8.20
wg show wg0
ip rule show

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

टिकटमा गन्तव्य, छानिएको इन्टरफेस र छानिएको peer लेख्नुहोस्। त्यही त्रिकले ओभरल्यापलाई पछि समीक्षा गर्न सकिने बनाउँछ, र यो कन्फिगरेसनको स्क्रिनसटभन्दा धेरै उपयोगी छ।