نشانی پایدار کلاینت VPN با Framed-IP-Address در RADIUS

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

تعیین کنید کدام لایه مالک نشانی است

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

RFC 2865 Framed-IP-Address را به‌عنوان نشانی‌ای تعریف می‌کند که باید برای کاربر پیکربندی شود و هیچ نمی‌گوید درباره آمادگی هیچ دروازه خاصی برای احترام به آن. مستندات فروشنده مرجع تقدم است، نه تعریف ویژگی.

یک درخواست آزمایشی بفرستید و پاسخ را بخوانید

نخست سرور را به‌تنهایی بیازمایید تا ویژگی غایب با مشکل دروازه اشتباه گرفته نشود. radtest یک Access-Request می‌فرستد و ویژگی‌هایی را که برمی‌گردند چاپ می‌کند.

radtest alice 'S3cret' 127.0.0.1 0 testing123

به‌دنبال Framed-IP-Address در Access-Accept بگردید و تأیید کنید که مقدار همان مقدار موردنظر است و نه نشانی استخر از یک قاعده پشتیبان. وقتی ویژگی غایب است، ورودی کاربر یا سیاست مجوزدهی مطابقت ندارد و تنظیم دروازه نمی‌تواند چیزی را فراهم کند که سرور هرگز نفرستاده است. اگر ردیابی پاسخ به قاعده‌ای مشخص دشوار است، درخواست را در حالی که سرور در حالت اشکال‌زدایی اجرا می‌شود تکرار کنید. راز مشترک را بیرون از تاریخچه پوسته و تیکت‌ها نگه دارید، زیرا نگهدارنده بالا اعتبارنامه نیست.

تأیید کنید که دروازه به مقدار احترام گذاشته است

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

ip -4 addr show tun0

آن نشانی را با ویژگی Access-Accept مقایسه کنید. ناسازگاری یعنی دروازه مقدار را نادیده گرفته یا بازنویسی کرده است، که پرسش تقدم از بخش اول را دوباره باز می‌کند. یک بار دیگر متصل شوید، زیرا رزروی که فقط در نخستین تلاش کار می‌کند معمولاً به نشست کهنه یا اجاره‌ای اشاره دارد که اتصال پیشین هنوز نگه داشته است. نسخه دروازه و پروتکل را کنار نتیجه ثبت کنید تا نفر بعدی بتواند بگوید آیا رفتار وابسته به نسخه است.

هم‌زمانی و لغو را برنامه‌ریزی کنید

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

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