سیاست گروهی NPS اجرای منابع VPN نیست

دو گروه، دو نمایه دسترسی، یک دروازه VPN، و در پایان هر دو گروه به همان سرورها می‌رسند. دلیل معمول یک سیاست خراب نیست، بلکه نیمه دوم گمشده طراحی است: NPS تصمیم می‌گیرد چه کسی می‌تواند نشستی برقرار کند، و چیز دیگری باید تصمیم بگیرد که آن نشست به چه چیزی می‌تواند برسد. وقتی فقط نیمه اول وجود دارد، مجوز برای هر کسی که احراز هویت می‌کند موفق است. سیاست کار خود را انجام می‌دهد و طراحی هنوز ناقص است.

یک سیاست شبکه منطبق با گروه، شاهدی درباره پذیرش است. شاهدی درباره بسته‌ها نیست، و شکاف میان این دو گزاره جایی است که بیشتر این کار رخ می‌دهد.

سیاستی را پیدا کنید که واقعاً نشست را پذیرفت

NPS سیاست‌های شبکه مرتب‌شده را ارزیابی می‌کند و نخستین قاعده فعالی که شرایطش منطبق باشد برنده می‌شود. شرایط می‌تواند شامل عضویت در گروه کاربر یا رایانه، نوع اتصال، زمان و وضعیت دستگاه باشد. بنابراین یک سیاست گسترده که زودتر در فهرست قرار دارد، اتصالی را می‌پذیرد پیش از آنکه قاعده باریک‌تری در پایین فهرست حتی بررسی شود. ترتیب جزئیات رابط کاربری نیست؛ ترتیب همان سیاست است.

فهرست را به ترتیب بخوانید و آن موردی را که منطبق شد مشخص کنید، سپس یادداشت کنید چه تنظیماتی بازگرداند. نام گروه در ویرایشگر نتیجه نیست؛ نتیجه همان مجوزی است که سرور دریافت کرد. مجوز کاربر و مجوز دستگاه را جدا نگه دارید جایی که استقرار از هر دو استفاده می‌کند، زیرا حسابی که می‌تواند تونلی باز کند به‌طور خودکار حسابی نیست که باید به هر سرویس داخلی برسد.

پاسخ RADIUS یک دستور است، نه یک فیلتر

ویژگی Filter-Id نام یک فهرست فیلتر را حمل می‌کند. مجموعه‌ای قابل حمل از قواعد فیلتر بسته که هر دریافت‌کننده‌ای بفهمد را ارسال نمی‌کند، و فرستادن نامی که دروازه هرگز تعریف نکرده اصلاً چیزی را اجرا نمی‌کند. همین احتیاط درباره ویژگی‌های VLAN هم صادق است: اختصاص یک نشست تونل به یک VLAN به خودی خود قاعده دسترسی مسیریابی‌شده برای آن کاربر نیست.

اینجاست که طراحی‌ای که در سمت NPS کامل به نظر می‌رسد بی‌صدا هیچ کاری نمی‌کند. با مستندات فروشنده دروازه تأیید کنید کدام ویژگی‌های مجوز پشتیبانی می‌شوند و دریافت‌کننده با هر یک چه می‌کند، به‌جای آنکه فرض کنید نام استاندارد یک ویژگی به معنای رفتار استاندارد است.

اجرا را جایی بگذارید که ترافیک می‌گذرد

دروازه‌ای که بسته‌های کاربر را پردازش می‌کند می‌تواند فیلتری برای هر نشست اعمال کند، گروهی را به سیاست دروازه نگاشت کند، یا به نشست نشانی از یک استخر جداگانه بدهد که دیوار آتش آن را متفاوت می‌بیند. هر یک از اینها می‌تواند کار کند و هر کدام به شیوه‌ای متفاوت شکست می‌خورند. پیش از نوشتن سیاستی که آن را نام می‌برد، مشخص کنید دروازه شما کدام سازوکار را پشتیبانی می‌کند. سپس بنویسید وقتی آن سازوکار وجود ندارد چه بر سر نشست می‌آید، زیرا سکوت حالت پیش‌فرض است.

مجوز مورد نظر را در چهار بخش توصیف کنید: هویت منبع یا گروه، مقصد، پروتکل و درگاه. وابستگی‌هایی را که کاربر واقعاً نیاز دارد بیفزایید، مانند DNS یا یک سرویس احراز هویت، وگرنه محدودیت جریان‌های ورودی را می‌شکند که کسی به فکر آزمایششان نبوده. قاعده را در برابر رابطی بنویسید که واقعاً فیلتر می‌کند، نه رابطی که تصادفاً در ویرایشگر باز است.

ترجمه نشانی را هم در نظر بگیرید. اگر دیوار آتش پایین‌تر برای هر کاربر تونل یک نشانی منبع ترجمه‌شده ببیند، نمی‌تواند افراد را تنها از آن نشانی تشخیص دهد، و قاعده‌ای که طوری نوشته شده که گویی می‌تواند، یا بی‌فایده یا بیش از حد گسترده خواهد بود.

نمایه‌های کارخواه در سمت غیرقابل اعتماد زندگی می‌کنند

یک نمایه VPN مدیریت‌شده می‌تواند مسیرها، قواعد تونل تقسیم‌شده یا فیلترهای برنامه را هل دهد، و اینها شکل می‌دهند که یک دستگاه خوش‌رفتار چگونه رفتار کند. آنها محافظت برای سرویس نیستند، زیرا کارخواه همان طرفی است که می‌خواهید محدودش کنید. حذف یک مسیر در نمایه هم مجوز نیست، چون کارخواه ممکن است مسیر دیگری به همان مقصد داشته باشد.

تنظیمات کارخواه را راحتی و تنظیمات دروازه را کنترل بدانید. وقتی این دو اختلاف دارند، دروازه درست می‌گوید چون همان است که بسته‌ها را می‌بیند.

با دو حساب بپذیرید، سپس به ترتیب دنبال کنید

دو حساب آزمایشی معمولی با مجوزهای مورد نظر متفاوت بسازید، نشست‌های تازه برقرار کنید و سیاست مؤثر دروازه را برای هر یک بررسی کنید. سپس یک عملیات بی‌ضرر مجاز و یک منبع مشخصاً ردشده را بیازمایید. یک ping ناموفق به‌تنهایی چیز بسیار کمی را ثابت می‌کند، چون ممکن است ICMP فیلتر شده باشد در حالی که سرویس TCP پشت آن با خوش‌رویی پاسخ می‌دهد.

وقتی هر دو حساب هنوز دسترسی گسترده می‌گیرند، به ترتیبی ثابت دنبال کنید: کدام سیاست منطبق شد، پاسخ چه مجوزی داشت، و دروازه با آن چه کرد. افزودن ویژگی‌های بیشتر NPS پیش از تأیید اینکه دریافت‌کننده آنها را پیاده‌سازی می‌کند، همان راهی است که یک مشکل کوچک مجوز به پنجره‌ای برای تغییر بدون نتیجه تبدیل می‌شود.