چرا درخواست‌های TACACS+ خود ASA از تونل VPN شعبه شما عبور نمی‌کند

تونل شعبه برپاست، کاربران در برابر سرور TACACS+ راه دور احراز هویت می‌شوند، اما ورود خود فایروال هنوز با اتمام زمان مواجه می‌شود. دلیل، ایراد در تونل نیست: تونل LAN-to-LAN ترافیکی را حمل می‌کند که با انتخابگرهایش منطبق است، و ترافیک مدیریتی که ASA درباره خودش تولید می‌کند جریان جدایی با آدرس مبدأ خودش است. بیشتر تیم‌ها این را هنگام پنجره تغییر کشف می‌کنند، وقتی تنها حساب مدیر همان حسابی است که شکست می‌خورد. نشست AAA که ASA آغاز می‌کند را جریانی بدانید که باید طراحی کنید، نه اثر جانبی اتصالی که از قبل کار می‌کند.

ASA خودش کلاینت است و ترافیک خودش مسیر خودش را می‌خواهد

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

آدرسی را که انتظار دارید سرور ببیند بنویسید. اگر نمی‌توانید آن را در یک خط بیان کنید، هنوز طراحی ندارید.

رابط در خط aaa-server تزئینی نیست

در ASA، ورودی میزبان aaa-server اتصال به رابط را داخل پرانتز می‌گیرد، و مرجع دستورات میزبان AAA از Cisco آن را رابطی توصیف می‌کند که سرور احراز هویت روی آن قرار دارد. همین اتصال است که درخواست را به رابط و به سیاستی که آن رابط اعمال می‌کند گره می‌زند. انتخاب آن بر اساس هر رابطی که به اینترنت نگاه می‌کند، یا رها کردن آنچه از آخرین مهاجرت مانده، آدرس مبدئی می‌سازد که سرور راه دور و تونل هرگز برای آن ساخته نشده‌اند.

inside تنها زمانی پاسخ درست است که رابط نام‌برده همان آدرسی را داشته باشد که طراحی شما می‌خواهد به‌عنوان مبدأ به کار ببرد. در دستگاه شعبه اغلب همین‌طور است؛ در دستگاهی با چند بخش خصوصی شاید نه.

تغییر اتصال یعنی بازساختن ورودی

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

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

انتخابگرها، ترجمه و مسیر بازگشت را با هم بررسی کنید

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

در سمت سرور، هویت دستگاه، راز مشترک و سیاست مدیریتی را جداگانه تأیید کنید. TACACS+ احراز هویت، مجوزدهی و حسابداری را عملیات‌های متمایز نگه می‌دارد، بنابراین ردّی که پس از تبادل کامل می‌رسد پاسخ سیاست است، نه شکست انتقال. خواندن آن به‌عنوان مشکل شبکه شما را به جای اشتباه می‌فرستد.

هنگام عیب‌یابی راز را از ضبط بسته‌ها، تیکت‌ها و رونوشت‌ها دور نگه دارید، و به یاد داشته باشید آدرس مبدئی که سرور ثبت می‌کند همانی است که طراحی شما باید توضیح دهد.

تغییر را بدون قفل کردن خودتان انجام دهید

هنگام تغییر احراز هویت مدیریتی راه دور از کنسول یا یک مسیر مدیریت مستقل استفاده کنید، و تا وقتی مسیر جدید یک ورود واقعی را حمل نکرده، یک جایگزین محلی تأییدشده نگه دارید. سپس باریک اعتبارسنجی کنید: یک سرور، یک دستگاه، یک احراز هویت موفق با مشاهده آدرس مبدأ در هر دو سر.

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