رلهٔ DHCP در ASA روی VPN سایت به سایت: راهنمای گام به گام

رله در سه مرحله کار می‌کند و فقط مرحلهٔ میانی از VPN عبور می‌کند. کلاینت در سگمنت شعبه پخش همگانی می‌فرستد، ASA آن پخش را به درخواست تک‌مقصدی به سرور DHCP تبدیل می‌کند و سرور به نشانی رله پاسخ می‌دهد نه به کلاینت. مراحل را به همین ترتیب طی کنید و بیشتر موارد «رله خراب است» به سیاستی ازقلم‌افتاده یا خط setroute بدخوانده‌شده ختم می‌شود.

مرحلهٔ یک: فعال‌کردن رله روی رابط رو به کلاینت

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

پیش از هر تغییری پیکربندی جاری را بررسی کنید: کدام رابط رله را فعال دارد، کدام شکل سرور موجود است و آیا setroute به رابط کلاینت متصل است. اگر ASA برای سگمنت دیگری هم سرور DHCP اجرا می‌کند، بایستید و فهرست محدودیت‌ها را بخوانید؛ سرور و رله نمی‌توانند هم‌زمان روی یک دستگاه فعال باشند.

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

مرحلهٔ دو: بردن ترافیک تولیدشده توسط ASA از روی تونل

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

تأیید کنید که ترافیک موردنظر مبدأ رلهٔ ASA و نشانی سرور را پوشش می‌دهد و جهت بازگشت هم مجاز است. در طراحی مبتنی بر VTI تصمیم مسیریابی ساده‌تر است، اما پشتیبانی رله روی VTI در نسخه‌ای مشخص آمد؛ راهنمای DHCP در ASA نسخهٔ 9.14(1) را مشخص می‌کند، پس پیش از کپی‌کردن نمونهٔ VTI روی دستگاهی قدیمی‌تر تصویر را بررسی کنید.

پینگ از ASA به سرور به‌تنهایی چیز زیادی ثابت نمی‌کند. ممکن است از مسیری دیگر، با نشانی مبدأ دیگر یا زیر سیاستی موفق شود که بسته‌های رله با آن مطابقت ندارند.

مرحلهٔ سه: خواندن پاسخ و گزینهٔ setroute

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

سپس دو چیز را که شبیه هم به گوش می‌رسند جدا کنید. کلیدواژهٔ setroute گزینهٔ مسیریاب پیش‌فرضی را که ASA به کلاینت می‌دهد تغییر می‌دهد یا اضافه می‌کند. این کلیدواژه مسیری روی ASA نصب نمی‌کند و سیاست VPN نمی‌سازد. کلاینتی که نشانی می‌گیرد اما به جایی نمی‌رسد غالباً مشکل setroute یا دامنه دارد، نه مشکل تونل. آن را با کلاینتی بدون دروازهٔ ایستا آزمایش کنید و ببینید کدام مسیریاب پیش‌فرض در پیشنهاد ظاهر می‌شود.

پیشنهاد را از ابتدا تا انتها بخوانید: نشانی پیشنهادی، ماسک، مسیریاب پیش‌فرض، DNS و مدت اجاره. سپس بگذارید اجاره تمدید شود. رله‌ای که یک بار کار می‌کند و در تمدید شکست می‌خورد معمولاً مشکل دامنه، اجاره یا مسیر بازگشت دارد که تبادل نخست آن را پنهان کرده بود.

پیش از آنکه بگویم درست شده چه چیزهایی را بررسی می‌کنم

از کلاینت شروع کنید و پخش همگانی را ثبت کنید، سپس تأیید کنید که ASA آن را با نشانی خودش به‌عنوان giaddr رله کرده است. در سمت دور تأیید کنید که سرور آن درخواست را دیده و دامنه‌ای متناسب با شعبه انتخاب کرده است. با بازگشت به شعبه تأیید کنید که کلاینت پیشنهاد را پذیرفته و به دروازه‌اش می‌رسد.

اگر هر مرحله‌ای ساکت است، سیاست یا مسیر متناظر را بررسی کنید نه اینکه اعلان رلهٔ دیگری اضافه کنید. پیکربندی رله معمولاً تا وقتی کسی موضوع را بالا می‌برد درست است؛ آنچه تغییر کرده سیاست تونل یا مسیر بازگشت است.

سه مرحله را در سند تغییرات بنویسید: رابط رو به کلاینت، سیاست VPN که ترافیک رله را پوشش می‌دهد و مسیر بازگشت سرور به giaddr. همین سند است که ساخت شعبهٔ بعدی را به کاری تکرارپذیر تبدیل می‌کند نه جلسهٔ اشکال‌زدایی. همچنین به مهندس بعدی می‌گوید کدام خروجی فرمان را نخست جمع کند.