چرا کاربر راه دور ASA به زیرشبکه می‌رسد اما به برنامه نه
مسیرها ثابت می‌کنند که تونل کار می‌کند، نه اینکه کاربر مجاز به باز کردن برنامه است. فیلتری را که نشست دریافت کرده بخوانید، سپس یک اتصال مجاز و یک اتصال ردشده را آزمایش کنید.
کاربر شما متصل می‌شود، نشانی می‌گیرد، به سروری در زیرشبکه برنامه پینگ می‌کند و با این حال نمی‌تواند سرویس روی آن را باز کند. این ترکیب روی ASA عادی است، چون تونل موفق و مجوز قابل‌استفاده را تنظیمات متفاوتی تعیین می‌کنند. فهرست تونل تقسیم‌شده انتخاب کرد کدام مقصدها وارد تونل شوند؛ فیلتر VPN و قواعد دسترسی خود مقصد تعیین می‌کنند درخواست رمزگشایی‌شده به چه چیزی می‌رسد. سه تصمیم را به ترتیب بررسی کنید، نه اینکه فهرست مسیرها را تا وقتی چیزی تغییر کند گسترده‌تر کنید.
سه تصمیمی که به‌راحتی اشتباه گرفته می‌شوند
پذیرش پاسخ می‌دهد که آیا کاربر اصلاً می‌تواند تونل را برقرار کند: اعتبارنامه، گواهی و هر عامل دومی. انتخاب مسیر پاسخ می‌دهد مشتری کدام مقصدها را به آن تونل می‌فرستد. اختیاردهی پاسخ می‌دهد آیا درخواست رمزگشایی‌شده می‌تواند به سرویس برسد. تنها سومین مورد خطایی را تولید می‌کند که کاربر گزارش می‌دهد.
راه سریع تشخیص آن‌ها این است که بپرسید یک تغییر چه چیزی را می‌شکند. حذف یک مسیر از فهرست تقسیم‌شده ترافیک به آن زیرشبکه را متوقف می‌کند بدون آنکه چیزی بدهد؛ افزودن یک ACE به فیلتر VPN مقصدی را اعطا می‌کند بدون آنکه تغییر دهد مشتری چه چیزی را تونل می‌کند.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
فیلتری را بخوانید که نشست واقعاً دریافت کرده است
از نشست زنده شروع کنید، نه از پیکربندی که فکر می‌کنید اعمال می‌شود. show vpn-sessiondb detail anyconnect سیاست گروهی تخصیص‌یافته و نام فیلتر متصل به آن نشست را چاپ می‌کند. اگر این فیلد خالی باشد، هیچ فیلتری چیزی را اعمال نمی‌کند و مسدودسازی از جای دیگری می‌آید.
سپس سیاستی را که مالک مقدار است بخوانید، شامل پیش‌فرض‌ها، چون فیلتر ممکن است به ارث برسد نه اینکه جایی که نگاه می‌کنید نوشته شده باشد:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
نام فیلتر روی نشست را با ACLای که همین حالا ویرایش کردید مقایسه کنید. ACLی با نام مشابه که کاربر هرگز دریافت نکرده نمی‌تواند سیاست منابع آن نشست را تغییر دهد، و این رایج‌ترین دلیل بی‌اثر بودن تغییری است که درست به نظر می‌رسد.
اولویت بقیه را توضیح می‌دهد. برای تنظیم فیلتر، یک رکورد DAP بر ویژگی‌های نام کاربری اولویت دارد، و ویژگی‌های نام کاربری بر سیاست گروهی اولویت دارند. وقتی نشستی فیلتری نشان می‌دهد که انتظارش را نداشتید، پیش از دست زدن به گروه به دنبال سیاست DAP مطابق با آن کاربر بگردید.
فهرست تقسیم‌شده و فیلتر فیلدهای جداگانه‌اند
روی ASA 9.x سیاست گروهی split-tunnel-network-list و vpn-filter را به عنوان تنظیمات متفاوت نگه می‌دارد، و راهنمای سیاست گروهی 9.22 دقیقاً به همین دلیل آن‌ها را جداگانه مستند کرده است. فهرست شبکه یک اشاره مسیریابی برای مشتری است؛ فیلتر یک فهرست کنترل دسترسی است که بر ترافیک رمزگشایی‌شده اعمال می‌شود.
این تمایز وقتی مهم است که کاربر یک سرویس HTTPS روی یک زیرشبکه می‌خواهد. زیرشبکه را در فهرست تقسیم‌شده بگذارید تا بسته‌ها وارد تونل شوند، سپس فقط همان سرویس را در فیلتر مجاز کنید. گستردن فهرست مسیرها چیزی را مجاز نمی‌کند، و کوچک کردن آن سازوکار اجرا نیست.
بررسی کنید آیا ACL رابط اصلاً در مسیر هست
ترافیک رمزگشایی‌شده دسترسی راه دور همیشه مانند آنچه مردم فرض می‌کنند از ACL رابط بیرونی عبور نمی‌کند. جایی که sysopt connection permit-vpn فعال است، ASA دورزدن مستندشده VPN را برای آن ترافیک اعمال می‌کند، در حالی که فیلترهای VPN قابل‌اعمال پس از آن هنوز اعمال می‌شوند. تنظیم را با show run all sysopt بررسی کنید، نه با استدلال از نمودار توپولوژی.
در هر حال، دیوار آتش خود میزبان مقصد و اختیاردهی برنامه در مسیر باقی می‌مانند. قاعده‌ای در ASA که TCP 443 را مجاز می‌کند باعث نمی‌شود برنامه کاربر را بپذیرد.
تغییر را با یک اتصال ردشده هم بپذیرید
یک آزمون مجاز به‌تنهایی چیز کمی را ثابت می‌کند، چون تونل سالم همان بسته اول را تولید می‌کند چه فیلتری وجود داشته باشد چه نه. سرویس موردنظر را از مشتری باز کنید، سپس مقصدی را که باید بسته بماند امتحان کنید و تأیید کنید که به دلیل درست شکست می‌خورد.
هنگام بستن تیکت چهار واقعیت را ثبت کنید: هویت پذیرفته‌شده، سیاست و فیلتری که نشست واقعاً دریافت کرده، مقصدهای فهرست تقسیم‌شده، و منبعی که کاربر مجاز به رسیدن به آن بود. آن چهار مورد توضیح می‌دهند ترافیک کجا کنترل می‌شود بدون اینکه فهرست مسیرها به دیوار آتش تبدیل شود.
اگر سرویس پس از مجاز شدن توسط فیلتر همچنان رد می‌کند، به میزبان بروید: نشانی شنود، دیوار آتش میزبان و نگاشت کاربران خود برنامه. تونل در آن نقطه کار خود را انجام داده است و تغییرات بیشتر در ASA فقط ریسک می‌افزاید.