हबवरील 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 पर्यंतचा प्रवेश हे स्वतंत्र धोरण असलेले स्वतंत्र मार्ग आहेत। मॅट्रिक्स त्यापैकी कशाला व्यापते ते नोंदवा, कारण केवळ पीअर-ते-पीअर रहदारी तपासणारी चाचणी त्यापैकी कोणाबद्दलही काही सांगत नाही।