کدام قاعده ASA ترافیک را پس از رمزگشایی VPN می‌بیند

نخستین فرضی که باید کنار گذاشت این است که ACL رمزنگاری یک خط‌مشی دسترسی است. نیست. روی Cisco ASA آن فهرست به یک پرسش باریک پاسخ می‌دهد: کدام بسته‌ها سزاوار حفاظت‌اند، و این پاسخ هیچ چیز درباره اینکه بسته رمزگشایی‌شده می‌تواند به سرور پشت دیوار آتش برسد یا نه نمی‌گوید. دسترسی بعداً تعیین می‌شود، با خط‌مشی رابط، با فیلتر خط‌مشی گروه، یا هر دو، بسته به اینکه تونل چگونه ساخته شده است.

ACL رمزنگاری به پرسش دیگری پاسخ می‌دهد

ACL رمزنگاری یک فهرست تطبیق است. به تونل می‌گوید بین دو همتا چه چیزی رمز شود؛ بسته‌ای که با آن تطبیق نکند به‌سادگی محافظت نمی‌شود. گستردن آن دامنه حفاظت را تغییر می‌دهد و نه چیز دیگری.

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

تنظیم عبور واقعاً چه چیزی را رد می‌کند

sysopt connection permit-vpn به ترافیک محافظت‌شده اجازه می‌دهد از بررسی ACL رابط که در غیر این صورت در سمت ورودی اعمال می‌شد بگذرد. این یک تسهیل برای استقرارهای VPN است و سراسری است. به خط‌مشی گروه دست نمی‌زند و به فیلتر مجوزدهی هر کاربر هم دست نمی‌زند.

مقدار واقعی را بخوانید نه فرض را: show running-config all sysopt تنظیم را حتی وقتی هرگز صریحاً پیکربندی نشده چاپ می‌کند، و بسیاری از سردرگمی‌ها از همان‌جا شروع می‌شود.

چون تنظیم سراسری است، آزمودن آن به‌عنوان آزمایشی سریع روی یک زیرشبکه خراب معامله بدی است. هر تونل دیگر روی آن دیوار آتش نتیجه را شریک می‌شود. آن را برای تغییری سنجیده با برنامه بازگشت نگه دارید.

فیلتر را در جهت رمزگشایی بخوانید

یک vpn-filter LAN-to-LAN از دید تونل نوشته می‌شود، نه رابط. شبکه دور در جایگاه مبدأ و شبکه محلی در جایگاه مقصد قرار می‌گیرد، چون بسته پس از رمزگشایی این‌گونه است. سپس همان فیلتر پیش از رمزگذاری دوباره در جهت مخالف ارزیابی می‌شود، با نقش‌های آدرس جابه‌جاشده.

شرایط پورت دقیقاً به همین دلیل بیش از یک ACL رابط کپی‌شده مستلزم دقت است. قاعده‌ای که یک پورت مقصد را مجاز می‌کند می‌تواند در جهت معکوس اثری ناخواسته داشته باشد، جایی که اتصال تازه‌ای از آن پورت به‌عنوان مبدأ استفاده می‌کند. پیش از ساختن فهرست بنویسید کدام سو می‌تواند شروع کند، سرویس واقعی چیست و طرف مقابل که باید بسته بماند کدام است.

تأیید کنید کدام فیلتر واقعاً پیوست شده است: show running-config group-policy و show vpn-sessiondb detail l2l با هم می‌گویند نشست چه چیزی را به ارث برده است. ویرایش ACL‌ای که هیچ خط‌مشی به آن ارجاع نمی‌دهد چیزی را تغییر نمی‌دهد.

از یک شیء ACL برای دو کار استفاده نکنید

access-group رابط و vpn-filter شبیه یک نوع شیء به نظر می‌رسند و در نقاط مختلف با جهت‌گیری آدرس متفاوت ارزیابی می‌شوند. اختصاص یک فهرست به هر دو، دعوت به تغییری است که تونل را درست می‌کند و رابط فیزیکی را بی‌صدا شل می‌کند.

آن‌ها را جدا نگه دارید، بر اساس کارشان نام‌گذاری کنید و تفاوت جهت را در نام‌ها آشکار بگذارید.

با اتصال‌های تازه، در هر دو جهت بررسی کنید

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

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

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