दोन क्लायंट गट, एक सर्व्हर: धोरण कुठे लागू करावे

दोन क्लायंट गट वेगवेगळ्या सबनेटवर ठेवणे अलगीकरणासारखे दिसते, आणि ते नाही. पत्ते सांगतात की पॅकेट दिसायला कुठून येत आहे, तर परवानगी हा तो फॉरवर्ड करणाऱ्याने घेतलेला निर्णय आहे. या प्रश्नाचे उत्तर मास्क नाही तर संरचना देते, म्हणून कोणताही नियम लिहिण्यापूर्वी कोणता घटक समवयस्कांची रहदारी फॉरवर्ड करतो ते ठरवा.

सबनेट हे लेबल आहे, नियम नाही

प्रत्येक गटाला एक पूल देणे तुम्हाला वाचनीय पत्ते देते आणि दुसरे काहीही नाही. अतिरिक्त मार्ग स्वीकारणाऱ्या क्लायंटने पोहोच मिळवली, आणि पोहोच ही परवानगी नाही. बोलण्याची परवानगी फॉरवर्डिंग निर्णयात असते, जो सर्व्हर कसा संरचित आहे त्यानुसार डेमॉन किंवा कर्नेलमध्ये असू शकतो.

पत्त्याची मालकी हीच पूर्वचिन्हाला गट-निवडक म्हणून वापरण्यायोग्य बनवते. प्रत्येक प्रमाणित ओळखीने अंदाजे पत्ता किंवा श्रेणीशी जुळले पाहिजे, आणि अनेक उपकरणे एकच क्रेडेन्शियल आणि एकच वाटप वाटून घेताच ते जुळणे तुटते. स्रोत पूर्वचिन्हावर विसंबण्यापूर्वी ओळख आणि समवर्तीता सोडवा, कारण कोणते यंत्र कॉल करत आहे याचा अंदाज लावणारे धोरण सर्वात वाईट क्षणी चुकीच्याला परवानगी देते.

समवयस्कांचा रहदारी वाहून नेणारा मार्ग निवडा

जेव्हा डेमॉन स्वतःच्या प्रक्रियेत समवयस्कांचे पॅकेट फॉरवर्ड करतो, ते पॅकेट कधीही होस्टच्या फॉरवर्डिंग हुकपर्यंत पोहोचत नाहीत, म्हणून कर्नेलचा नियम त्यांना पाहू शकत नाही. ते अंतर्गत फॉरवर्डिंग बंद करा, कर्नेल फॉरवर्डिंग बिंदू होतो, जिथे सामान्य फॉरवर्ड नियम लागू होतात.

# peer forwarding inside the daemon: enforce with per-group policy instead of FORWARD rules
client-to-client
# kernel forwarding path: remove the line above, then filter in the forward chain

ऑफलोड केलेले डेटा चॅनेल आणि उत्पादन-व्यवस्थापित सर्व्हर स्वतःचे अंमलबजावणी मॉडेल प्रकाशित करतात, म्हणून समुदायाचे वर्तन गृहीत धरण्याऐवजी तुम्ही कोणते चालवत आहात याची खात्री करा. टाळण्यासारखे अपयश म्हणजे असे नियम जे पुनरावलोकनात बरोबर दिसतात आणि रनटाइमला कधीही विचारले जात नाहीत.

नियम लिहिण्यापूर्वी मॅट्रिक्स लिहा

छोटे मॅट्रिक्स नियमसंचापेक्षा पुनरावलोकनास सोपे असते, आणि तोच करार अंमलबजावणीने पूर्ण करायचा असतो: एकाच गटातील समवयस्कांना परवानगी, गटांमधील समवयस्कांना नकार, दोन्ही गटांना एका नामांकित सामायिक सेवेपर्यंत परवानगी, बाकी सर्व नकार. फायरवॉल संपादक उघडण्यापूर्वी त्या चार ओळी लिहा. नियमांची वाक्यरचना न वाचणारा पुनरावलोककही मॅट्रिक्स तपासू शकतो. मग अंमलबजावणीला फक्त ओळींशी जुळायचे असते.

लिहिताना तीन गंतव्य वर्ग वेगळे ठेवा. VPN होस्टवरची सेवा स्थानिक इनपुट आहे, दुसरा क्लायंट समवयस्क पारगमन आहे, आणि गेटवेच्या मागील यंत्र वेगळा फॉरवर्डिंग मार्ग आहे. एक उदार नियम तिन्ही अपघाताने देऊ शकतो, आणि अशा प्रकारे गट धोरण अतिरिक्त पावलांसह सपाट जाळ्यात बदलते. प्रत्येक ओळीच्या शेजारी वर्ग लिहा जेणेकरून हेतू पुढील संपादनात टिकेल.

नियम जिथे टिकतात तिथे ठेवा

फायरवॉलचा उर्वरित भाग जिथे सांभाळला जातो तिथेच निर्णय जोडा, त्यांना गिळून टाकणाऱ्या कोणत्याही परवानगी देणाऱ्या नियमापूर्वी. नियमांचा क्रम धोरणाचा भाग आहे, आणि विस्तृत परवानगीनंतर ठेवलेला बरोबर नियम काहीही लागू करत नाही. बदलापूर्वी आणि नंतर नियम क्रमांक नोंदवा. संपादकात असलेले पण चालू नियमसंचात नसलेले धोरण हे योजना आहे, नियंत्रण नाही.

धोरण बदलल्यावर आधीच अस्तित्वात असलेल्या प्रवाहांचे काय होईल हे ठरवा, कारण बदलापूर्वी उघडलेले सत्र नंतरही चालू राहू शकते. निघणाऱ्या सदस्याला तात्काळ प्रवेश गमवावा लागत असेल, तर जोडणी स्वतः बंद होण्याची वाट न पाहता ती स्थिती संपवण्याचा मार्ग नियमसंचात असावा.

फायरवॉलच्या उर्वरित भागाचा मालक असलेल्या यंत्रणेद्वारे नियम टिकाऊ करा, आणि त्यांच्या शेजारी मॅट्रिक्स नोंदवा. न नोंदवलेले धोरण पुढील घटनेत स्मरणातून पुन्हा काढले जाते, सहसा घाईत असलेल्या व्यक्तीकडून.

दोन्ही बाजूंनी सिद्ध करा

प्रत्येक गटातील एका क्लायंटकडून त्याच गटातील पोहोच, गटांमधील अपयश आणि सामायिक सेवा तपासा. एका क्लायंटकडून एकच चाचणी मॅट्रिक्सचा अर्धा भाग सिद्ध करते, आणि जो अर्धा सुटतो तोच सहसा चुकीचा असतो. नकाराची दिशा दोन वेळा पुन्हा करा, कारण कॅशे केलेले सत्र अंमलबजावणीची चूक लपवू शकते. तुम्ही कोणती जोडी तपासली ते नोंदवा जेणेकरून पुढची व्यक्ती ती पुन्हा करणार नाही.

बोगदा IPv6 वाहत असेल तर त्यावर तपासणी पुन्हा करा, आणि सामान्य अनुप्रयोग प्रमाणीकरण ठेवा. स्रोत पूर्वचिन्ह खाते नाही, म्हणून जाळ्याचे धोरण पार करणे म्हणजे सेवेने कॉल करणाऱ्यावर विश्वास ठेवावा असे नाही.