NPS समूह नीति VPN स्रोत कार्यान्वयन होइन

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

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

सत्रलाई साँच्चै स्वीकार गर्ने नीति खोज्नुहोस्

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

सूची क्रममा पढ्नुहोस् र मिलेको पहिचान गर्नुहोस्, त्यसपछि यसले कुन सेटिङ फर्कायो भनी लेख्नुहोस्। सम्पादकमा देखिने समूहको नाम नतिजा होइन; नतिजा भनेको सर्भरले पाएको अनुमति हो। जहाँ परिनियोजनले दुवै प्रयोग गर्छ त्यहाँ प्रयोगकर्ता अनुमति र यन्त्र अनुमति अलग राख्नुहोस्, किनकि सुरुङ खोल्न सक्ने खाता स्वतः हरेक आन्तरिक सेवामा पुग्नुपर्ने खाता होइन।

RADIUS जवाफ निर्देश हो, फिल्टर होइन

एक Filter-Id विशेषता फिल्टर सूचीको नाम बोक्छ। यसले हरेक प्राप्तकर्ताले बुझ्ने पोर्टेबल प्याकेट-फिल्टर नियमहरूको समूह पठाउँदैन, र गेटवेले कहिल्यै परिभाषित नगरेको नाम पठाउँदा केही पनि लागू हुँदैन। यही सावधानी VLAN विशेषताहरूमा पनि लागू हुन्छ: सुरुङ सत्रलाई VLAN मा तोक्नु आफैमा त्यो प्रयोगकर्ताका लागि मार्गनिर्देशित पहुँच नियम होइन।

यहीँ NPS पक्षबाट पूर्ण देखिने डिजाइन चुपचाप केही गर्दैन। गेटवे आपूर्तिकर्ताको कागजातबाट कुन अनुमति विशेषता समर्थित छन् र प्राप्तकर्ताले हरेकसँग के गर्छ भनी पुष्टि गर्नुहोस्, मानक विशेषता नामको अर्थ मानक व्यवहार हो भनी मान्नुको सट्टा।

कार्यान्वयनलाई ट्राफिक गुज्रने ठाउँमा राख्नुहोस्

प्रयोगकर्ताको प्याकेट प्रशोधन गर्ने गेटवेले प्रत्येक सत्रका लागि फिल्टर लागू गर्न, समूहलाई गेटवे नीतिमा म्याप गर्न, वा फायरवालले फरक तरिकाले हेर्ने छुट्टै पूलबाट सत्रलाई ठेगाना दिन सक्छ। यीमध्ये कुनै पनि काम गर्न सक्छ, र ती फरक तरिकाले असफल हुन्छन्। नीति लेख्नुअघि तपाईंको गेटवेले कुन संयन्त्र समर्थन गर्छ निर्धारण गर्नुहोस्। त्यसपछि त्यो संयन्त्र नहुँदा सत्रमा के हुन्छ लेख्नुहोस्, किनकि मौनता नै पूर्वनिर्धारित हो।

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

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

क्लाइन्ट प्रोफाइल अविश्वसनीय पक्षमा बस्छन्

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

क्लाइन्ट सेटिङलाई सुविधा र गेटवे सेटिङलाई नियन्त्रण मान्नुहोस्। जब दुवै मतभेद गर्छन्, गेटवे ठीक हुन्छ, किनकि प्याकेट हेर्ने त्यही हो।

दुई खातासँग स्वीकार गर्नुहोस्, त्यसपछि क्रममा पछ्याउनुहोस्

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

जब दुवै खाताले अझै फराकिलो पहुँच पाउँछन्, निश्चित क्रममा पछ्याउनुहोस्: कुन नीति मिल्यो, जवाफले कुन अनुमति बोकेको थियो, र गेटवेले त्यसको के गर्‍यो। प्राप्तकर्ताले ती लागू गर्छ भनी पुष्टि गर्नुअघि थप NPS विशेषता थप्नु नै सानो अनुमति समस्यालाई नतिजाविहीन परिवर्तन विन्डो बनाउने बाटो हो।