Standard IPv4 ACL به‌صورت Numbered و Named

Numbered Standard ACL

Rangeهای Number استاندارد به IOS Release وابسته‌اند اما نمونه کلاسیک access-list 10 است. Standard ACL فقط Source را Match می‌کند. اگر permit 10.10.10.0/24 نوشته شود، هر Destination برای آن Source از دید این ACL Permit است؛ Context Apply مشخص می‌کند اثر واقعی چیست.

از host برای یک Source دقیق و any برای همه Sourceها استفاده می‌شود. هرچه Match عمومی‌تر باشد، Risk Impact بیشتر است.

access-list 10 permit 10.10.10.0 0.0.0.255
access-list 10 deny any log

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

Named Standard ACL

Named ACL با ip access-list standard NAME ساخته می‌شود و داخل Submode ACEها نوشته می‌شوند. Name معنی‌دار مثل MGMT-SOURCES بهتر از عدد بدون Context است. Sequence Number نیز ویرایش Policy را ساده‌تر می‌کند.

Remark می‌تواند هدف ACL یا Ticket Change را ثبت کند، اما اطلاعات حساس را در Config Comment قرار نده.

ip access-list standard MGMT-SOURCES
 10 permit 10.10.99.0 0.0.0.255
 20 deny any log

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

Apply روی Interface

ACL تا زمانی که در Context مناسب Apply نشود صرفاً تعریف شده است. برای IPv4 Interface معمولاً ip access-group NAME in یا out استفاده می‌شود. Direction از دید همان Interface است: in یعنی Packet هنگام ورود به Router از آن Interface و out یعنی هنگام خروج.

اشتباه در Direction ممکن است Policy را بی‌اثر یا بیش از حد محدود کند. روی Diagram یک Arrow برای Flow رسم کن و Interface/Direction را انتخاب کن.

interface GigabitEthernet0/2
 ip access-group MGMT-SOURCES in

پیاده‌سازی Apply روی Interface در شبکه شرکت باید به سه فاز 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 سازمان سازگار بماند.

Placement Standard ACL

چون Standard ACL Destination را نمی‌بیند، Guideline سنتی این است که نزدیک Destination قرار گیرد تا Source موردنظر فقط برای مقصد لازم محدود شود، نه برای همه مسیرهای دیگر. اما Design واقعی می‌تواند استثنا داشته باشد.

برای ACL مدیریت Device، Context ممکن است VTY access-class باشد نه Interface ACL. همیشه هدف Policy را قبل از انتخاب محل Apply مشخص کن.

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

Verification و Troubleshooting

show access-lists Counter هر ACE را نشان می‌دهد. هنگام Test از Source مجاز و غیرمجاز، Counter مربوط باید افزایش یابد. show ip interface نشان می‌دهد کدام ACL ورودی یا خروجی روی Interface فعال است.

اگر ACL تعریف شده ولی Hit صفر است، ممکن است روی Interface/Direction اشتباه Apply شده یا Flow از مسیر دیگری عبور کند. اگر Hit Deny بالا می‌رود، Flow واقعاً به ACL می‌رسد و Policy Match مشکل را توضیح می‌دهد.

show access-lists MGMT-SOURCES
show ip interface GigabitEthernet0/2

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