عیب‌یابی ACL و ارتباط آن با VPN

ACL در چند Context

همان Syntax ACL ممکن است در Contextهای مختلف نقش متفاوت داشته باشد: Interface Filtering، NAT Match، VTY Access یا Crypto/Policy Match روی برخی Platformها. بنابراین دیدن ACL Number به‌تنهایی کافی نیست؛ باید Reference آن را پیدا کنی.

یک ACL Match برای NAT لزوماً Packet را Drop نمی‌کند، در حالی که ACL اعمال‌شده با ip access-group می‌تواند Permit/Deny مستقیم انجام دهد. Context تعیین‌کننده است.

show access-lists
show running-config | include access-group
show running-config | include access-list

برای عیب‌یابی ACL و ارتباط آن با VPN، فهم ACL در چند Context باید همراه با مرزبندی دقیق انجام شود. قبل از هر تصمیم، مشخص کن این مفهوم در کدام لایه یا بخش از مسیر قرار دارد، چه Stateی ایجاد می‌کند و چه چیزی خارج از مسئولیت آن است. بسیاری از خطاهای عملی از اینجا شروع می‌شوند که یک علامت مشترک به فناوری اشتباه نسبت داده می‌شود. اگر بتوانی بگویی «این بخش دقیقاً چه چیزی را ثابت می‌کند و چه چیزی را ثابت نمی‌کند»، هنگام Incident به‌جای حدس زدن، Failure Domain را کوچک می‌کنی. در محیط واقعی همیشه فناوری مجاور، مسیر برگشت و Policyهای بین راه را هم در ذهن نگه دار.

Underlay ACL

ACL روی WAN ممکن است Traffic لازم برای VPN Negotiation یا ESP/NAT-T را مسدود کند. اگر پس از Security Hardening همه Tunnelها Down شده‌اند، WAN ACL و Hit Counter Deny را بررسی کن.

Protocol/Portهای دقیق به VPN Design بستگی دارند؛ به‌جای Permit کورکورانه، Log و Documentation راهکار را ببین و فقط Traffic لازم را باز کن.

برای تحلیل عملی Underlay ACL یک Flow Card کوچک بساز: Source، Destination، Protocol یا Service، Interface/VLAN/Prefix مرتبط و Timestamp. سپس Packet یا State را از یک Boundary به Boundary بعدی دنبال کن. این روش در عیب‌یابی ACL و ارتباط آن با VPN کمک می‌کند تفاوت میان Configuration موجود و رفتار واقعی شبکه دیده شود. اگر یک مرحله سالم است، همان مرحله را دوباره تغییر نده؛ Boundary بعدی را آزمایش کن. اگر مرحله‌ای شکست می‌خورد، خروجی و Counter همان نقطه را ثبت کن. این عادت ساده باعث می‌شود Troubleshooting حتی در شبکه‌ای با چند Switch، Router، Security Policy و Server قابل تکرار و قابل توضیح باشد.

Overlay ACL

Tunnel ممکن است Up باشد اما ACL داخلی اجازه ندهد Remote Subnet به Server برسد. اگر IPsec Counterها در هر دو جهت افزایش می‌یابند ولی Application Block می‌شود، ACL/Firewall در Overlay مسیر را بررسی کن.

Source Address بعد از Decrypt باید با چیزی که ACL انتظار دارد مقایسه شود. NAT یا Policy ممکن است Address را تغییر داده باشد.

Remote subnet -> decrypted packet -> inside ACL -> server

پیاده‌سازی Overlay ACL در شبکه شرکت باید به سه فاز Pre-check، Change و Post-check تقسیم شود. در Pre-check وضعیت فعلی، Dependencyها و مسیر مدیریت را ذخیره کن؛ در Change فقط Scope لازم را تغییر بده؛ در Post-check هم State فنی و هم سرویس کاربر را Verify کن. برای Changeهایی که ممکن است Access مدیریت، Routing یا Security را تحت تأثیر قرار دهند، Rollback را قبل از اجرای دستور بنویس و مسیر Recovery را مشخص کن. هدف این نیست که Configuration فقط از نظر Syntax پذیرفته شود؛ Desired State باید با Design، مستندات، Address Plan و Security Policy سازمان سازگار بماند.

Counter Correlation

هم‌زمان با یک Test مشخص، Counter ACL و VPN SA را ببین. اگر ACL Deny Counter بالا می‌رود و VPN Encrypt Counter ثابت است، Packet قبل از Crypto Drop می‌شود. اگر Encrypt/Decrypt بالا می‌رود ولی Server ACL Deny افزایش دارد، Failure بعد از Tunnel است.

این Correlation ارزش بیشتری از نگاه جداگانه به چند خروجی در زمان‌های متفاوت دارد.

show access-lists
show logging
! Compare with platform-specific VPN SA counters

در Verification مربوط به Counter Correlation، خروجی Command را به‌صورت «Expected در برابر Actual» بخوان. وجود یک Line در Running Configuration فقط Intent را نشان می‌دهد؛ Table، Neighbor State، Counter، Log یا Test End-to-End نشان می‌دهد Feature واقعاً چه می‌کند. اگر Counter وجود دارد، مقدار مطلق را تنها معیار نگذار؛ قبل و بعد از Test به Delta توجه کن. اگر Log وجود دارد، Timestamp و Source را با Flow آزمایشی تطبیق بده. در عیب‌یابی ACL و ارتباط آن با VPN بهتر است حداقل یک Positive Test و، هرجا Security مطرح است، یک Negative Test نیز داشته باشی تا هم Availability و هم Policy درست اثبات شوند.

Runbook یکپارچه

Scope، Flow و Timestamp را ثبت کن؛ Reference ACLها را پیدا کن؛ Underlay Reachability و VPN State را Verify کن؛ سپس Counterهای ACL/VPN را با Test مقایسه کن. فقط بعد از تعیین Drop Point، ACE را تغییر بده.

بعد از Fix، Test مثبت و منفی انجام بده تا Security Policy ناخواسته باز نشده باشد. حل Availability با ایجاد Permit بیش از حد یک Fix معتبر نیست.

show ip interface
show access-lists
show logging
show ip route <remote-prefix>

مسیر Troubleshooting Runbook یکپارچه را با کم‌هزینه‌ترین Test شروع کن که بیشترین اطلاعات را می‌دهد. ابتدا Scope و آخرین وضعیت سالم را مشخص کن، سپس نزدیک‌ترین Boundary سالم به کاربر یا Source را پیدا کن و قدم‌به‌قدم جلو برو. هر Test باید یک Hypothesis را رد یا تأیید کند؛ اگر نتیجه فرضیه را رد کرد، همان Configuration را بی‌دلیل دست‌کاری نکن. قبل از Reload، Clear State یا Disable کردن Feature، Evidence را ذخیره کن چون این عملیات می‌توانند سرنخ Root Cause را پاک کنند. بعد از Fix نیز تست اولیه را تکرار و Preventive Action را در Documentation ثبت کن.