NPS समूह नीति VPN संसाधन प्रवर्तन नहीं है

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

समूह से मेल खाती नेटवर्क नीति प्रवेश का प्रमाण है। यह पैकेटों का प्रमाण नहीं है, और इन दो कथनों के बीच का अंतर ही वह जगह है जहाँ इस काम का अधिकांश हिस्सा होता है।

वह नीति खोजें जिसने वास्तव में सत्र स्वीकार किया

NPS क्रमबद्ध नेटवर्क नीतियों का मूल्यांकन करता है, और पहला सक्षम नियम जिसकी शर्तें मेल खाती हैं, जीतता है। शर्तों में उपयोगकर्ता या कंप्यूटर समूह की सदस्यता, कनेक्शन प्रकार, समय और डिवाइस की स्थिति शामिल हो सकती है। इसलिए सूची में पहले रखी गई व्यापक नीति नीचे के संकीर्ण नियम पर विचार होने से पहले ही कनेक्शन स्वीकार कर लेती है। क्रम इंटरफ़ेस का विवरण नहीं है; क्रम ही नीति है।

सूची को क्रम से पढ़ें और पहचानें कि कौन सा मेल खाया, फिर नोट करें कि उसने कौन-सी सेटिंग्स लौटाईं। एडिटर में समूह का नाम परिणाम नहीं है; परिणाम वह प्राधिकरण है जो सर्वर को मिला। जहाँ परिनियोजन दोनों का उपयोग करता है वहाँ उपयोगकर्ता प्राधिकरण और डिवाइस प्राधिकरण अलग रखें, क्योंकि सुरंग खोल सकने वाला खाता स्वतः ऐसा खाता नहीं है जिसे हर आंतरिक सेवा तक पहुँचना चाहिए।

RADIUS उत्तर एक निर्देश है, फ़िल्टर नहीं

एक Filter-Id विशेषता फ़िल्टर सूची का नाम रखती है। यह हर प्राप्तकर्ता द्वारा समझे जाने वाले पैकेट-फ़िल्टर नियमों का पोर्टेबल सेट नहीं भेजती, और ऐसा नाम भेजना जिसे गेटवे ने कभी परिभाषित नहीं किया, कुछ भी लागू नहीं करता। यही सावधानी VLAN विशेषताओं पर भी लागू होती है: सुरंग सत्र को VLAN को सौंपना अपने आप में उस उपयोगकर्ता के लिए रूट किया गया एक्सेस नियम नहीं है।

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

प्रवर्तन को वहाँ रखें जहाँ से ट्रैफ़िक गुज़रता है

उपयोगकर्ता के पैकेट संसाधित करने वाला गेटवे प्रति सत्र फ़िल्टर लागू कर सकता है, समूह को गेटवे नीति पर मैप कर सकता है, या सत्र को अलग किए गए पूल से पता दे सकता है जिसे फ़ायरवॉल अलग तरह से देखता है। इनमें से कोई भी काम कर सकता है, और वे अलग-अलग तरह से विफल होते हैं। नीति लिखने से पहले तय करें कि आपका गेटवे किस तंत्र का समर्थन करता है। फिर लिखें कि उस तंत्र के न होने पर सत्र के साथ क्या होता है, क्योंकि मौन ही डिफ़ॉल्ट है।

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

अनुवाद को भी ध्यान में रखें। यदि नीचे का फ़ायरवॉल हर सुरंग उपयोगकर्ता के लिए एक अनूदित स्रोत पता देखता है, तो वह केवल उस पते से व्यक्तियों को अलग नहीं कर सकता, और ऐसा नियम जो लिखा गया हो जैसे वह कर सकता है, या तो बेकार होगा या बहुत व्यापक।

क्लाइंट प्रोफ़ाइल अविश्वसनीय पक्ष पर रहते हैं

प्रबंधित VPN प्रोफ़ाइल रूट, विभाजित-सुरंग नियम या एप्लिकेशन फ़िल्टर धकेल सकती है, और ये अच्छी तरह व्यवहार करने वाले डिवाइस का व्यवहार गढ़ते हैं। ये सेवा के लिए सुरक्षा नहीं हैं, क्योंकि क्लाइंट वह पक्ष है जिसे आप सीमित करने का प्रयास कर रहे हैं। प्रोफ़ाइल में रूट हटाना भी प्राधिकरण नहीं है, क्योंकि क्लाइंट के पास उसी गंतव्य का दूसरा मार्ग हो सकता है।

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

दो खातों के साथ स्वीकार करें, फिर क्रम से पीछा करें

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

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