IP ثابت VPN: Framed-IP-Address در RADIUS یا رزرو در استخر آدرس

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

سه جایی که یک نشانی ثابت می‌تواند باشد

RADIUS وقتی مالک نشانی است که پاسخ Framed-IP-Address را حمل کند و دروازه آن مقدار را روی نشست اعمال کند. دروازه وقتی مالک آن است که مدیر حساب را به نشانی ثابتی داخل استخر نگاشت کند. کلاینت هیچ چیزی را مالک نیست، حتی وقتی آداپتورش نشانی دستی نشان می‌دهد، زیرا سرور نشانی داخلی را در جریان مذاکره تخصیص می‌دهد و تنظیم محلی فقط وقتی اهمیت دارد که سرور هیچ چیزی نفرستد. هر سه روی یک اتصال سالم یکسان به نظر می‌رسند، و به همین دلیل تعارض‌ها دیر آشکار می‌شوند. تفاوت هنگام اتصال دوباره، روی دستگاه دوم و پس از تغییر سیاست دیده می‌شود.

دو مالک همان پیکربندی‌ای است که می‌شکند. پاسخی از RADIUS که 172.28.4.77 را تخصیص می‌دهد در حالی که دروازه نگاشت ثابتی برای 172.28.4.90 دارد، هر مقداری را که کد فروشنده اول بررسی می‌کند برمی‌گرداند و بازنده بدون یک خط گزارش دور انداخته می‌شود. همان حساب روی دستگاه دوم سپس نشانی تکراری می‌گیرد و نشانه مانند خطای مسیریابی خوانده می‌شود نه تعارض تخصیص. پیش از افزودن مکانیسم دوم، مالک را مشخص کنید.

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

پاسخ RADIUS چه چیزی را می‌تواند و چه چیزی را نمی‌تواند وعده دهد

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

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

پاسخی که دروازه نادیده می‌گیرد دقیقاً مانند پاسخی است که هرگز فرستاده نشده. خواندن Access-Accept و نشانی نشست در کنار هم تنها راه جدا کردن این دو حالت است.

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

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

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

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

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

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

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

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

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

یک مالک انتخاب کنید و آن را بنویسید

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

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