عیب‌یابی VPN در Cisco Firepower؛ وقتی Tunnel بالا است اما ترافیک عبور نمی‌کند

در Site-to-Site VPN زیاد پیش می‌آید که وضعیت tunnel در نگاه اول خوب به نظر برسد، اما کاربران هنوز به سرویس مقصد نمی‌رسند. اینجا اگر فقط به up بودن IKE یا IPsec نگاه کنیم، مسیر عیب‌یابی را اشتباه می‌رویم. VPN یک زنجیره است: peer، proposal، crypto domain، route، NAT exemption، Access Control Policy و لاگ‌ها باید با هم درست باشند.

در Cisco Firepower و FTD، بخش زیادی از پیکربندی از FMC مدیریت می‌شود، اما عیب‌یابی خوب هنوز به فهم مسیر packet نیاز دارد. باید بدانید ترافیک از کدام zone وارد می‌شود، قبل از encryption چه source و destination دارد، آیا NAT روی آن اعمال می‌شود یا exempt شده، و آیا مقصد برگشت route درستی دارد یا نه.

اول مشکل را دقیق تعریف کنید

قبل از تغییر policy، مشخص کنید دقیقاً چه چیزی قطع است. آیا هیچ ترافیکی از tunnel عبور نمی‌کند؟ فقط یک subnet مشکل دارد؟ فقط یک پورت خاص کار نمی‌کند؟ مشکل یک‌طرفه است یا دوطرفه؟ اگر این سؤال‌ها پاسخ داده نشوند، ممکن است چند تغییر بی‌ربط پشت سر هم انجام شود و وضعیت بدتر شود.

برای شروع، یک flow مشخص انتخاب کنید: source، destination، protocol و port. بعد همان flow را در route، NAT، ACL و VPN domain دنبال کنید. عیب‌یابی کلی با جمله‌هایی مثل «VPN مشکل دارد» معمولاً وقت را هدر می‌دهد.

Crypto domain و route را کنار هم ببینید

اگر subnetهای تعریف‌شده در دو سمت VPN با route واقعی یا نیاز سرویس هماهنگ نباشند، tunnel ممکن است بالا باشد اما ترافیک مورد نظر وارد IPsec نشود. در پروژه‌های واقعی، بعد از اضافه شدن یک VLAN جدید یا تغییر رنج آدرس، همین بخش فراموش می‌شود. نتیجه این است که فقط بخشی از شبکه کار می‌کند.

route هم به همان اندازه مهم است. اگر فایروال نداند ترافیک مقصد باید از کدام interface یا tunnel خارج شود، crypto domain درست هم کافی نیست. در سمت مقابل هم مسیر برگشت باید بررسی شود؛ چون خیلی از قطعی‌های VPN در واقع مشکل return path هستند.

NAT exemption را جدی بگیرید

در بسیاری از سناریوها، ترافیک VPN نباید مثل اینترنت NAT شود. اگر rule عمومی NAT بالاتر از exemption قرار بگیرد یا objectها درست تعریف نشده باشند، مقصد سمت مقابل source غیرمنتظره می‌بیند و ارتباط برقرار نمی‌شود. این مشکل مخصوصاً وقتی پیش می‌آید که بعد از راه‌اندازی VPN، ruleهای جدید برای publish سرویس یا اینترنت اضافه شده‌اند.

show crypto ikev2 sa
show crypto ipsec sa
show nat
packet-tracer input inside tcp 10.20.1.10 12345 10.30.5.20 443 detailed

Access Control Policy هنوز لازم است

VPN بالا بودن به معنی مجاز بودن ترافیک نیست. بعد از decrypt شدن یا قبل از encrypt شدن ترافیک، Access Control Policy باید اجازه عبور بدهد. بهتر است rule مربوط به VPN واضح و محدود باشد: source و destination مشخص، سرویس‌های لازم، logging روشن و توضیح کوتاه برای مالکیت سرویس. ruleهای خیلی باز شاید سریع مشکل را پنهان کنند، اما بعداً ریسک و ابهام ایجاد می‌کنند.

لاگ را از هر دو سمت بخوانید

اگر فقط سمت خودتان را ببینید، ممکن است مشکل سمت مقابل، route برگشت یا فایروال داخلی مقصد را نبینید. لاگ Firepower باید نشان دهد packet به کدام rule خورده، چه action گرفته، آیا NAT شده، و آیا event مرتبط با VPN دیده می‌شود یا نه. در سمت مقابل هم باید همین flow بررسی شود.

در شبکه‌های حساس بهتر است برای VPNهای مهم یک baseline کوتاه داشته باشید: subnetها، peerها، proposalها، ruleهای NAT exemption، ACLها و contact سمت مقابل. وقتی حادثه رخ می‌دهد، همین مستند کوتاه جلوی تغییرهای عجولانه را می‌گیرد.

جمع‌بندی

عیب‌یابی VPN در Cisco Firepower یعنی دنبال کردن یک flow واقعی از لحظه ورود تا خروج. IKE/IPsec فقط بخشی از ماجراست. اگر crypto domain، route، NAT exemption، Access Control و لاگ‌ها کنار هم بررسی شوند، معمولاً مشکل بدون باز کردن بی‌دلیل ruleها پیدا می‌شود.

این موضوع به‌خصوص کنار طراحی NAT در Cisco Firepower و طراحی Access Control Policy باید دیده شود، چون VPN سالم بدون این دو بخش پایدار نمی‌ماند.

منابع رسمی

• Cisco Secure Firewall Threat Defense Configuration Guides
• Cisco VPN and IPsec Configuration Examples