افزودن کاربر به یک گروه VPN به‌تنهایی دسترسی نمی‌دهد
عضویت در گروه یک شرط است، نه اجازه. ببینید دروازه واقعاً چه چیزی را تطبیق داده، رکورد پذیرش یا رد را بخوانید و هر دو نتیجه را آزمایش کنید.
حساب را در گروه درست گذاشته‌اید، ورود موفق شده و اتصال همچنان رد می‌شود یا برقرار می‌شود و به چیز مفیدی نمی‌رسد. واکنش معمول افزودن کاربر به گروه‌های بیشتر است تا جایی که چیزی کوتاه بیاید، و همین‌گونه سازمان‌ها بسیار بیشتر از خواسته تیکت اعطا می‌کنند. عضویت در گروه یک ورودی به تصمیم مجوزدهی است، هرگز خود تصمیم نیست: دروازه چند واقعیت درباره نشست جمع می‌کند، آن‌ها را با سیاست مرتب‌شده تطبیق می‌دهد و تنها پس از آن تصمیم می‌گیرد نشست به چه چیزی دسترسی دارد. اگر شرط دیگری شکست خورده باشد، تغییر گروه جز سطح مواجهه شما چیزی را عوض نمی‌کند.
عضویت در گروه یک شرط است، نه اجازه
در RADIUS گروه به‌صورت ویژگی مجوزدهی می‌رسد و ویژگی‌ها نشست را توصیف می‌کنند نه اینکه آن را مجاز کنند. سرور با Access-Accept یا Access-Reject پاسخ می‌دهد؛ هنگام پذیرش می‌تواند Filter-Id، Class یا ویژگی‌های تونل از RFC 2868 را ضمیمه کند و تجهیزات شبکه در طرف دیگر آن‌ها را آن‌گونه که سازنده تصمیم گرفته تفسیر می‌کنند. هیچ چیز در پروتکل گروه را به دسترسی کامل نگاشت نمی‌کند؛ این نگاشت را کسی می‌نویسد که سیاست را روی دروازه یا سرور دسترسی شبکه تنظیم کرده و می‌تواند به باریکی یک میزبان باشد.
به همین دلیل یک نام گروه یکسان در دو سامانه رفتار متفاوت دارد. Microsoft NPS سیاست‌های شبکه را از شرط‌ها، محدودیت‌ها و تنظیمات می‌سازد و آن‌ها را به ترتیب تعیین‌شده ارزیابی می‌کند. OpenVPN Access Server مدل گروه و قاعده دسترسی خود را دارد، در حالی که سرور OpenVPN جامعه اغلب کل پرسش را به اسکریپت client-connect یا فایل client-config-dir می‌سپارد. هر یک گروهی مصرف می‌کند؛ هیچ‌کدام منطق اولویت دیگری را شریک نیست.
قاعده‌ای که تطبیق یافت تصمیم می‌گیرد، نه گروهی که انتظار داشتید
بیشتر موتورها در نخستین سیاست منطبق یا در مشخص‌ترین آن متوقف می‌شوند. اگر سیاست 3 رد کند و سیاست 7 اجازه دهد، نشست می‌تواند شکست بخورد بدون اینکه هرگز به قاعده‌ای برسد که آن را عبور می‌داد. ترتیب یک تنظیم واقعی در NPS و بیشتر محصولات کنترل دسترسی شبکه است و در طول سال‌ها جابه‌جا می‌شود.
شرط‌هایی که همراه گروه می‌آیند نیمه دیگر ماجراست. وضعیت دستگاه، روش احراز هویت، تکمیل MFA، شبکه مبدأ، موضوع گواهی یا پنجره زمانی می‌توانند در همان سیاست باشند. وقتی یکی برآورده نشود سیاست تطبیق نمی‌یابد، موتور به پایین می‌افتد و رد پیش‌فرض اعمال می‌شود. از دید کاربر به نظر می‌رسد گروه نادیده گرفته شده؛ از دید موتور هرگز از گروه پرسیده نشده.
جزئیات دایرکتوری همان توهم را می‌سازد. سیاستی که بر عضویت گروه‌های Windows تطبیق می‌یابد SIDهای درون توکن کاربر را می‌خواند و آنجا فقط گروه‌های امنیتی فهرست می‌شوند، گروه توزیع هرگز ظاهر نمی‌شود. گروه اصلی در فیلد خودش حمل می‌شود نه در فهرست، پس سیاستی که به آن سنجاق شده می‌تواند بی‌صدا شکست بخورد.
پیش از دست زدن به گروه، رکورد پذیرش یا رد را بخوانید
نخست یک پرسش بپرسید: آیا درخواست اصلاً به مرحله مجوزدهی رسید؟ در NPS پاسخ در گزارش رویداد است، جایی که 6272 دسترسی داده‌شده، 6273 رد و 6274 درخواستی را ثبت می‌کند که سرور پیش از ارزیابی سیاست دور انداخته است. آن سه عدد مسئله را به سه بررسی متفاوت تقسیم می‌کنند و تنها یکی از آن‌ها درباره گروه‌هاست.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
وقتی گزارش در دسترس نیست، مستقیم از سرور بپرسید و آنچه برمی‌گرداند بخوانید. پاسخی بدون Filter-Id و بدون ویژگی‌های تونل می‌گوید سرور نشست را عادی می‌داند و دروازه قواعد خودش را اعمال می‌کند. پاسخی با ویژگی‌هایی که نقطه اعمال پیاده‌سازی نمی‌کند خطای دیگری است: مجوزدهی گذشت و دستگاه نتیجه را نادیده گرفت.
radtest alice 'password' 10.0.0.5 0 testing123ویژگی‌های برگشتی را با آنچه دروازه مستند می‌کند مقایسه کنید، نه با آنچه نام گروه القا می‌کند. این مقایسه معمولاً مسئله سیاست را از مسئله اعمال جدا می‌کند.
تغییر گروه به گذشته اثر نمی‌کند
ویژگی‌های مجوزدهی یک بار برگردانده می‌شوند، هنگام احراز هویت نشست. دروازه آن‌ها را روی نشست نگه می‌دارد و برای هر بسته دایرکتوری را دوباره نمی‌خواند، به همین دلیل نشست برقرارشده پس از حذف کسی از گروه همچنان کار می‌کند و نشست جدید ممکن است شکست بخورد.
برای اثر کردن تغییر به تصمیم مجوزدهی تازه نیاز دارید، نه فقط کلیدهای تازه. جایی که سرور مجوزدهی پویا RFC 5176 را پشتیبانی می‌کند، Disconnect-Request یا CoA-Request به UDP 3799 نشست را به ارزیابی دوباره وامی‌دارد؛ در غیر این صورت کلاینت را قطع کنید و بگذارید دوباره متصل شود. مذاکره مجدد کلیدهای تونل را تازه می‌کند و معمولاً نتیجه مجوزدهی را دست‌نخورده می‌گذارد.
شرط را درست کنید، نه گروه را
وقتی دانستید کدام سیاست عمل کرد، تعمیر معمولاً کوچک است: ردی که اجازه مورد نظر را سایه می‌اندازد بازچینش کنید، شرط دستگاه یا MFA گمشده را به سیاستی که منظورتان بود بیفزایید، یا برای همان یک منبع قاعده‌ای باریک بنویسید به‌جای ارتقای کاربر به گروهی که ده تای دیگر را حمل می‌کند.
یک حلقه کوتاه تغییر را صادق نگه می‌دارد:
- رد را با حساب اصلی بازتولید کنید و پیش از تغییر هر چیز، شناسه رویداد را بنویسید.
- یک شیء را تغییر دهید، ترتیب سیاست، یک شرط یا یک گروه، و ثبت کنید کدام.
- نشست تازه باز کنید، تأیید کنید اجازه در گزارش دیده می‌شود و منبع واقعاً باز می‌شود.
- کاربری را آزمایش کنید که باید همچنان رد شود، تا تعمیر سیاست را تصادفاً گسترده نکرده باشد.
اگر اجازه درست است و منبع باز نمی‌شود، مشکل به مسیریابی یا حل نام منتقل شده است در همان لحظه که مجوزدهی گذشت. آن دو خطا را جدا نگه دارید تا تیکت بعدی دقیقه بگیرد نه یک بعدازظهر.