آیا یک زیرشبکه VPN سطح امنیتی رابط ASA را می‌گیرد؟

کسی می‌پرسد آیا زیرشبکه VPN شعبه روی ASA «سطح امنیتی 0 یا 100» دارد یا نه، و خود پرسش از پیش خطا را در خود دارد. سطح امنیتی ویژگی یک رابط محلی است و در پیکربندی رابط از 0 تا 100 تعیین می‌شود. زیرشبکه دوری که از طریق تونل می‌رسد هیچ سطحی به دست نمی‌آورد، هر طور که crypto map نوشته شده باشد. به همین دلیل پرسش پاسخ عددی ندارد.

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

سطح‌های امنیتی به رابط‌ها تعلق دارند

show running-config interface را اجرا کنید و security-level را زیر هر رابط فیزیکی یا رابط VLAN خواهید دید، نه زیر گروه تونل یا crypto map. مجوز پیش‌فرض از بالاتر به پایین‌تر بین همان رابط‌ها ارزیابی می‌شود، به همین دلیل عدد رفتار بازرسی و ACL ضمنی را روی مسیری که به آن تعلق دارد تغییر می‌دهد.

در یک جریان VPN رمزگشایی‌شده، ورودی همچنان رابط outside است که تونل در آن پایان می‌یابد، و خروجی رابط inside به سمت سرور است. هر دو را قبل از دست زدن به چیزی بنویسید. همین یک گام بیشتر سردرگمی را از بین می‌برد، چون یک پرسش انتزاعی اعتماد را به یک جفت رابط تبدیل می‌کند.

دور زدن ACL مرز نام‌دار دارد

sysopt connection permit-vpn همان تنظیمی است که مردم نیمه‌یاد می‌آورند وقتی می‌گویند ترافیک VPN قواعد ACL را نادیده می‌گیرد. واقعاً ACL رابط را برای ترافیکی که به عنوان ترافیک VPN واجد شرایط است دور می‌زند، و راهنمای پارامترهای 9.x آن را بر اساس رابط و جهت محدود می‌کند نه اعلام یک استثنای جهانی.

پیش از استدلال از حافظه، بررسی کنید چه چیزی پیکربندی شده است:

• show running-config all sysopt برای دیدن مقدار مؤثر، نه فقط خطوط غیر پیش‌فرض.
• show running-config access-group برای دیدن اینکه کدام ACL روی کدام رابط و جهت اعمال شده است.
• show vpn-sessiondb detail l2l برای تأیید اینکه نشست واقعاً از کدام گروه تونل و فیلتر استفاده می‌کند.

خاموش کردن آن تنظیم برای سخت‌تر کردن دسترسی VPN تغییری با دامنه اثر گسترده است. هر جریان VPN واجد شرایط را دوباره تابع ACL بیرونی می‌کند، که معمولاً تونل‌های سالم را به روش‌هایی می‌شکند که ربطی به شعبه‌ای که درباره‌اش پرسیده شد ندارد.

فیلتر متصل به نشست را بخوانید

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

اولویت را تأیید کنید نه اینکه آن را فرض بگیرید. show running-config group-policy <name> مقدار گروه را نشان می‌دهد و show running-config username <name> نشان می‌دهد آیا مقداری برای هر کاربر وجود دارد. اگر هر دو وجود داشته باشند، مقدار کاربر برنده است. سپس ورودی‌های آن ACL را با جریانی که برایتان مهم است، در جهتی که فیلتر ارزیابی می‌کند مقایسه کنید.

فیلتری که سرور برنامه را مجاز می‌کند هیچ چیزی درباره مدیریت نمی‌گوید. این‌ها قواعد جداگانه روی مسیری جداگانه هستند.

یک مجوز و یک رد را بررسی کنید

Packet-tracer سریع‌ترین راه دیدن تصمیم است بدون اینکه منتظر گزارش کاربر بمانید. جریان سمت رمزگشایی‌شده را به آن بدهید و بگذارید مراحل ACL، NAT و بازرسی را که از آن‌ها می‌گذرد نام ببرد.

1. packet-tracer input outside tcp 10.20.30.10 49152 10.0.5.20 443 detailed
2. خط نتیجه را بخوانید: نام ACL‌ای را می‌آورد که بسته را مجاز کرده یا انداخته است.
3. با مقصد مدیریتی روی رابط inside تکرار کنید و یک رد را تأیید کنید.
4. بعد از هر تغییر یک بار دیگر تکرار کنید تا هم وضعیت قبل و هم بعد ثبت شود.

سپس با ترافیک واقعی بررسی کنید: یک درخواست موفق برنامه از شعبه و یک تلاش ناموفق SSH به ASA. Packet-tracer مسیر را مدل می‌کند؛ یک جریان زنده ثابت می‌کند که مدل مطابقت داشته است.

تغییری را که آن را به کار انداخت برگردانید

اگر راه‌حل غیرفعال کردن دور زدن ACL یا گسترده کردن فیلتر بود، پیکربندی قبلی را نگه دارید. یک ضبط show run از اشیای متأثر، که پیش از تغییر ذخیره شده باشد، برای بازگرداندن آن‌ها کافی است؛ پیکربندی ASA خط‌محور است، پس برگرداندن یعنی دوباره وارد کردن خطوط قدیمی، نه بازگرداندن یک فایل.

جفت رابط، فیلتر مؤثر، نام ACL از packet-tracer و دستورهای دقیقی که تغییر دادید را ثبت کنید. این ثبت بازبینی بعدی را به یک بررسی پنج‌دقیقه‌ای تبدیل می‌کند نه بحثی دیگر درباره سطح‌های اعتماد.