दो क्लाइंट समूह, एक सर्वर: नीति कहाँ लागू करें
सबनेट समूहों को लेबल करते हैं; वे उन्हें अलग नहीं करते। तय करें कि कौन-सा फ़ॉरवर्डिंग पथ नियम का मालिक है, फिर वह मैट्रिक्स लिखें जिसे कार्यान्वयन को लागू करना है।
दो क्लाइंट समूहों को अलग-अलग सबनेट पर रखना अलगाव जैसा दिखता है, और वह है नहीं। पते बताते हैं कि पैकेट देखने में कहाँ से आ रहा है, जबकि अनुमति वह निर्णय है जो उसे फ़ॉरवर्ड करने वाला लेता है। इस प्रश्न का उत्तर मास्क नहीं, कॉन्फ़िगरेशन देता है, इसलिए कोई भी नियम लिखने से पहले तय करें कि कौन-सा घटक साथियों का ट्रैफ़िक फ़ॉरवर्ड करता है।
सबनेट एक लेबल है, नियम नहीं
हर समूह के लिए एक पूल देना आपको पढ़ने योग्य पते देता है और कुछ नहीं। अतिरिक्त मार्ग स्वीकार करने वाले क्लाइंट ने पहुँच प्राप्त कर ली है, और पहुँच अनुमति नहीं है। बोलने की अनुमति फ़ॉरवर्डिंग निर्णय में निहित है, जो सर्वर के कॉन्फ़िगरेशन के अनुसार डेमॉन या कर्नेल में रह सकता है।
पते का स्वामित्व ही प्रीफ़िक्स को समूह चयनकर्ता के रूप में उपयोगी बनाता है। हर प्रमाणित पहचान को किसी पूर्वानुमेय पते या श्रेणी से मेल खाना चाहिए, और यह मिलान तब टूट जाता है जब कई उपकरण एक ही क्रेडेंशियल और एक ही आवंटन साझा करते हैं। स्रोत प्रीफ़िक्स पर निर्भर होने से पहले पहचान और समवर्तीता सुलझाएँ, क्योंकि कौन-सी मशीन कॉल कर रही है इसका अनुमान लगाने वाली नीति सबसे बुरे क्षण में गलत मशीन को अनुमति दे देती है।
वह पथ चुनें जो साथियों का ट्रैफ़िक ले जाता है
जब डेमॉन अपनी प्रक्रिया के भीतर साथियों के पैकेट फ़ॉरवर्ड करता है, वे पैकेट कभी मेज़बान के फ़ॉरवर्डिंग हुक तक नहीं पहुँचते, इसलिए कर्नेल का नियम उन्हें नहीं देख सकता। उस आंतरिक फ़ॉरवर्डिंग को बंद करें और कर्नेल फ़ॉरवर्डिंग बिंदु बन जाता है, जहाँ सामान्य फ़ॉरवर्ड नियम लागू होते हैं।
# 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ऑफ़लोड किए गए डेटा चैनल और उत्पाद-प्रबंधित सर्वर अपने स्वयं के प्रवर्तन मॉडल प्रकाशित करते हैं, इसलिए समुदाय के व्यवहार को मान लेने के बजाय पुष्टि करें कि आप कौन-सा चला रहे हैं। बचने योग्य विफलता वह नियम है जो समीक्षा में सही दिखता है और रनटाइम में कभी नहीं देखा जाता।
नियम लिखने से पहले मैट्रिक्स लिखें
छोटा मैट्रिक्स नियम-समुच्चय की तुलना में समीक्षा करना आसान है, और यह वह अनुबंध है जिसे कार्यान्वयन को पूरा करना है: एक ही समूह के साथी अनुमत, समूहों के बीच साथी वर्जित, दोनों समूहों को एक नामित साझा सेवा तक अनुमति, बाकी सब वर्जित। फ़ायरवॉल संपादक खोलने से पहले वे चार पंक्तियाँ लिखें। जो समीक्षक नियमों का सिंटैक्स नहीं पढ़ता वह भी मैट्रिक्स जाँच सकता है। फिर कार्यान्वयन को केवल पंक्तियों से मेल खाना है।
| Source | Destination | Decision |
|---|---|---|
| Group A address | Another Group A address | Allow |
| Group A address | A Group B address | Deny |
| Either group | The shared internal service | Allow |
| Either group | Anything not listed | Deny |
लिखते समय तीन गंतव्य वर्गों को अलग रखें। VPN मेज़बान पर सेवा स्थानीय इनपुट है, दूसरा क्लाइंट साथी पारगमन है, और गेटवे के पीछे की मशीन भिन्न फ़ॉरवर्डिंग पथ है। एक उदार नियम गलती से तीनों दे सकता है, और इस तरह समूह नीति अतिरिक्त चरणों वाला सपाट नेटवर्क बन जाती है। हर पंक्ति के बगल में वर्ग लिखें ताकि इरादा अगले संपादन तक बचा रहे।
नियम वहाँ रखें जहाँ वे टिकते हैं
निर्णय उसी स्थान पर जोड़ें जहाँ फ़ायरवॉल का बाकी हिस्सा बनाए रखा जाता है, किसी भी अनुमति देने वाले नियम से पहले जो अन्यथा उन्हें निगल जाएगा। नियमों का क्रम नीति का हिस्सा है, और व्यापक स्वीकृति के बाद रखा सही नियम कुछ भी लागू नहीं करता। परिवर्तन से पहले और बाद में नियम-संख्या नोट करें। संपादक में मौजूद पर चल रहे नियम-समुच्चय में न होने वाली नीति योजना है, नियंत्रण नहीं।
नीति बदलने पर पहले से मौजूद प्रवाहों का क्या होगा यह तय करें, क्योंकि परिवर्तन से पहले खुला सत्र बाद में भी चल सकता है। यदि जाने वाले सदस्य को तुरंत पहुँच खोनी है, तो नियम-समुच्चय को उस स्थिति को समाप्त करने का तरीका चाहिए, न कि कनेक्शन के अपने आप बंद होने की प्रतीक्षा।
नियमों को उसी तंत्र से स्थायी बनाएँ जो फ़ायरवॉल के बाकी हिस्से का मालिक है, और उनके बगल में मैट्रिक्स दर्ज करें। दर्ज न की गई नीति अगली घटना के दौरान स्मृति से फिर से निकाली जाती है, आमतौर पर किसी जल्दबाज़ व्यक्ति द्वारा।
दोनों ओर से सिद्ध करें
हर समूह के एक क्लाइंट से समान-समूह पहुँच, समूहों के बीच विफलता और साझा सेवा का परीक्षण करें। एक क्लाइंट से एक ही परीक्षण मैट्रिक्स का आधा हिस्सा सिद्ध करता है, और जो आधा छूट जाता है वही आमतौर पर गलत होता है। निषेध की दिशा दो बार दोहराएँ, क्योंकि कैश किया गया सत्र प्रवर्तन की त्रुटि छिपा सकता है। दर्ज करें कि आपने कौन-सी जोड़ी परखी ताकि अगला व्यक्ति उसे न दोहराए।
यदि सुरंग IPv6 ले जाती है तो उस पर जाँच दोहराएँ, और सामान्य एप्लिकेशन प्रमाणीकरण बनाए रखें। स्रोत प्रीफ़िक्स खाता नहीं है, इसलिए नेटवर्क नीति पार करने का अर्थ यह नहीं कि सेवा को कॉल करने वाले पर भरोसा करना चाहिए।