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

چه می‌رسد و چه نمی‌رسد

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

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

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

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

اگر خط‌مشی از 10.20.0.0/24 محافظت کند و ASA از نشانی بیرونی خود به‌عنوان مبدأ استفاده کند، بسته گزارش یا به‌صورت متن آشکار به سوی گردآورنده‌ای که به آن نمی‌رسد خارج می‌شود، یا دور انداخته می‌شود. هر دو نتیجه از سمت گردآورنده یکسان به نظر می‌رسند. همین استدلال برای ترافیک مدیریت نیز صادق است، و به همین دلیل management-access تصمیمی طراحی جداگانه است.

ASA کدام مبدأ را روی شبکه می‌گذارد

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

برخی نسخه‌ها اجازه می‌دهند مبدأ ثبت را به یک رابط سنجاق کنید، و مرجع فرمان برای نسخه شما مرجع معتبر در این است که آیا آن گزینه وجود دارد و چه چیزی را تغییر می‌دهد. فرمان source-interface از پلتفرم دیگر Cisco به‌طور خودکار روی ASA معتبر نیست.

اگر مبدأ را تغییر دادید، آگاهانه تغییر دهید و آن را ثبت کنید، زیرا ACLهای گردآورنده و هر همبستگی‌ای که بر syslog ساخته شده به آن وابسته است.

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

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

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

در گردآورنده بررسی کنید، سپس مبدأ را ثبت کنید

تأیید کنید که پیام می‌رسد، سپس نشانی مبدأیی را که ASA استفاده کرد، سلکتوری که آن را حمل کرد و شدت آزمونی که با آن آزمایش کردید بنویسید.

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

پرسش‌های متداول ثبت ASA از Cisco موردی با مبدأ بیرونی را مستند می‌کند که به تعریف متناظر ترافیک محافظت‌شده نیاز دارد، و نمونه با مبدأ داخلی آن هم میزبان ثبت در داخل و هم management-access در داخل را شامل می‌شود. ترکیب مستند و زمینه نرم‌افزار را با هم در نظر بگیرید، نه با فرض اینکه یک خط کپی‌شده به هر پیکربندی می‌خورد.

تونلی که ترافیک LAN را حمل می‌کند، تونلی نیست که صدای خود دیوار آتش را حمل کند.

مقالات مرتبط