दुई क्लाइन्ट समूह, एउटा सर्भर: नीति कहाँ लागू गर्ने
सबनेटहरू समूहलाई लेबल गर्छन्; तिनीहरूलाई अलग गर्दैनन्। कुन फर्वार्डिङ मार्ग नियमको मालिक हो निर्णय गर्नुहोस्, त्यसपछि कार्यान्वयनले लागू गर्नुपर्ने म्याट्रिक्स लेख्नुहोस्।
दुई क्लाइन्ट समूहलाई फरक सबनेटमा राख्नु अलगाव जस्तो देखिन्छ, र त्यो होइन। ठेगानाले प्याकेट देखिने रूपमा कहाँबाट आउँछ भन्ने वर्णन गर्छ, जबकि अनुमति त्यसलाई फर्वार्ड गर्नेले लिने निर्णय हो। यो प्रश्नको उत्तर मास्कले होइन, कन्फिगरेसनले दिन्छ, त्यसैले कुनै पनि नियम लेख्नुअघि कुन घटकले साथीहरूको ट्राफिक फर्वार्ड गर्छ निर्णय गर्नुहोस्।
सबनेट एउटा लेबल हो, नियम होइन
प्रत्येक समूहलाई एउटा पूल दिनुले तपाईंलाई पढ्न सकिने ठेगाना दिन्छ र अरू केही होइन। थप मार्ग स्वीकार गर्ने क्लाइन्टले पहुँच प्राप्त गरेको छ, र पहुँच अनुमति होइन। बोल्ने अनुमति फर्वार्डिङ निर्णयमा हुन्छ, जो सर्भर कसरी कन्फिगर गरिएको छ त्यसअनुसार डेमन वा कर्नेलमा हुन सक्छ।
ठेगानाको स्वामित्वले नै प्रिफिक्सलाई समूह छनोटकर्ताका रूपमा प्रयोगयोग्य बनाउँछ। प्रत्येक प्रमाणित पहिचान पूर्वानुमानयोग्य ठेगाना वा दायरासँग मिल्नुपर्छ, र धेरै उपकरणले एउटै प्रमाणपत्र र एउटै आवंटन साझा गर्ने बित्तिकै त्यो मिलान असफल हुन्छ। स्रोत प्रिफिक्समा भर पर्नुअघि पहिचान र समवर्तीता समाधान गर्नुहोस्, किनकि कुन मेसिन कल गर्दैछ भनी अनुमान गर्ने नीतिले सबैभन्दा नराम्रो क्षणमा गलतलाई अनुमति दिन्छ।
साथीहरूको ट्राफिक बोक्ने मार्ग छान्नुहोस्
जब डेमनले आफ्नै प्रक्रिया भित्र साथीहरूका प्याकेट फर्वार्ड गर्छ, ती प्याकेट कहिल्यै होस्टको फर्वार्डिङ हुकसम्म पुग्दैनन्, त्यसैले कर्नेलको नियमले तिनलाई देख्न सक्दैन। त्यो आन्तरिक फर्वार्डिङ बन्द गर्नुहोस्, कर्नेल फर्वार्डिङ बिन्दु बन्छ, जहाँ सामान्य फर्वार्ड नियम लागू हुन्छन्।
# 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 बोक्छ भने त्यसमा जाँच दोहोर्याउनुहोस्, र सामान्य अनुप्रयोग प्रमाणीकरण राख्नुहोस्। स्रोत प्रिफिक्स खाता होइन, त्यसैले सञ्जाल नीति पार गर्नुको अर्थ सेवाले कल गर्नेलाई विश्वास गर्नुपर्छ भन्ने होइन।