हबमा WireGuard पियर समूह: स्रोतको स्वामित्व र नीति

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

दुई काम, अलग राखिएका

टनेल तहले साँघुरो प्रश्नको उत्तर दिन्छ: के यो पियरको कुञ्जीले यो आन्तरिक स्रोत ठेगानालाई अधिकृत गर्यो। फर्वार्डिङ तहले अझ फराकिलो प्रश्नको उत्तर दिन्छ: के यो प्याकेट त्यो गन्तव्यतर्फ निस्कन पाउँछ। कुनैले अर्कोको प्रश्नको उत्तर दिँदैन, र कुनै पनि एक्लै पूर्ण पहुँच नीति होइन।

यही विभाजनका कारण पियर प्रमाणित र सही ठेगानासहित हुँदै पनि नपुग्नुपर्ने होस्टमा पुग्न सक्दैन। यसले उल्टो पनि व्याख्या गर्छ: सबै कुरा अनुमति दिने फायरवाल नियमले कसले कुन ठेगाना दाबी गर्न सक्छ भन्नेबारे केही पनि प्रमाणित गर्दैन।

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

प्रत्येक पियरलाई उसको आफ्नै ठेगाना मात्र दिनुहोस्

बहु-होस्ट पियरहरूले तपाईंलाई सर्भरतर्फ पूरै समूह दायरा दिन लोभ्याउँछन्। त्यो अनुमति स्रोत-ठेगानाको दाबी हो, त्यसैले सम्झौता भएको वा गलत कन्फिगर भएको क्लाइन्टले दायराभित्रको कुनै पनि ठेगाना प्रस्तुत गर्न सक्छ र टनेलले त्यसलाई स्वीकार गर्छ। आफ्नै आन्तरिक ठेगानाका लागि प्रत्येक पियरलाई /32 दिनुहोस्। समूह दायरा क्लाइन्टहरूमा मात्र सेट गर्नुहोस्, जहाँ तिनीहरूले त्यो क्लाइन्टले कुन गन्तव्यसम्म पुग्न सक्छ भन्ने वर्णन गर्छन्, कुन स्रोत प्रयोग गर्न सक्छ भन्ने होइन।

त्यसपछि फायरवालले भरोसा गर्न सकिने स्रोतसँग मिलाउँछ। समूहको दायराका लागि लेखिएको नियम अझै उपयोगी समूहीकरण हो, र कुनै एकल पियरले अर्को सदस्यको ठेगाना दाबी गर्न नसकेपछि मात्र त्यो अर्थपूर्ण हुन्छ।

समूह अलग गर्ने फर्वार्ड नीति लेख्नुहोस्

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

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

पहिला दुई नियमले प्रत्येक समूहभित्रको ट्राफिकलाई अनुमति दिन्छन्। अन्तिमले त्यो इन्टरफेस पार गर्ने बाँकी सबै रोक्छ, र यसैले समूहहरूबीच अलगाव उत्पन्न गर्छ। आवश्यक परे अर्को ठेगाना परिवारका लागि स्पष्ट नियम थप्नुहोस्, किनकि IPv4 का लागि लेखिएको drop ले IPv6 को व्यवहारलाई न अधिकृत गर्छ न वर्णन गर्छ।

क्रमले नीति लागू हुन्छ वा हुँदैन भन्ने निर्धारण गर्छ

नियमहरूको क्रम टुक्राभन्दा बढी महत्त्वपूर्ण हुन्छ। स्थापित जडानहरू स्वीकार गर्ने सामान्य नियम यी प्रविष्टिहरूभन्दा अघि राखिएको छ भने पुरानो अन्तर-समूह प्रवाह जारी रहन्छ, त्यसैले अलगाव नयाँ जडानहरूमा मात्र लागू हुन्छ। पुनः लोड गर्नुअघि यी दुईमध्ये कुन नतिजा चाहनुहुन्छ निर्धारण गर्नुहोस्।

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

फाइल संख्या होइन, म्याट्रिक्स परीक्षण गर्नुहोस्

अपेक्षित नतिजाहरूको सानो म्याट्रिक्स बनाउनुहोस् र प्रत्येक कोष जाँच्नुहोस्। समूह A बाट समूह A सम्म काम गर्नुपर्छ, समूह B बाट समूह B सम्म काम गर्नुपर्छ, र A बाट B सम्म गर्नुहुँदैन, दुवै दिशामा र तपाईंले समर्थन गर्नुहुन्छ भने दुवै ठेगाना परिवारका लागि।

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

पहिला दुईले के कन्फिगर छ देखाउँछन्। गलत समूहको सदस्यबाट ping ले वास्तवमा के हुन्छ देखाउँछ। conntrack सूचीले पुरानो प्रवाह अझै स्वीकार भइरहेको छ कि छैन देखाउँछ, र अलगावको परिवर्तन चुपचाप लागू नहुने कारण यही हो।

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