مبانی IPv4 ACL، ACE و Wildcard Mask

ACL و ACE

ACL ظرف Policy است و هر خط آن ACE یا Access Control Entry محسوب می‌شود. ACE مشخص می‌کند چه Trafficی Permit یا Deny شود. Router هنگام رسیدن Packet به ACL از اولین ACE شروع می‌کند و در اولین Match تصمیم می‌گیرد؛ خطوط بعدی دیگر بررسی نمی‌شوند.

به همین دلیل Order بخشی از منطق Security است. یک permit ip any any در ابتدای ACL عملاً Denyهای پایین‌تر را بی‌اثر می‌کند.

10 permit tcp 10.10.10.0 0.0.0.255 host 192.0.2.20 eq 443
20 deny ip any any log

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

Implicit Deny

در انتهای هر ACL یک deny منطقی وجود دارد که معمولاً در Config به‌صورت خط قابل ویرایش دیده نمی‌شود. اگر هیچ ACE Match نشود، Packet Deny می‌شود. بنابراین ساخت ACL فقط با یک Permit محدود می‌تواند تمام Traffic دیگر را قطع کند اگر همان ACL روی Interface اعمال شود.

قبل از Apply باید Trafficهای ضروری مدیریت، Routing و Application را فهرست کنی. ACL Change بدون شناخت Baseline یکی از روش‌های رایج Lockout است.

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

Wildcard Mask

Wildcard Mask در ACL مشخص می‌کند کدام بیت‌های Address باید دقیق Match شوند و کدام می‌توانند متفاوت باشند. بیت ۰ یعنی «باید برابر باشد» و بیت ۱ یعنی «اهمیتی ندارد». برای /24 با Mask 255.255.255.0، Wildcard معمولاً 0.0.0.255 است.

Wildcard را با Subnet Mask اشتباه نکن. برای یک Host می‌توان از host keyword استفاده کرد و برای همه Addressها any نوشت.

/24 mask: 255.255.255.0 -> wildcard 0.0.0.255
/26 mask: 255.255.255.192 -> wildcard 0.0.0.63
host 10.10.10.25 -> exact host match

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

Standard و Extended

Standard ACL عمدتاً Source IPv4 را Match می‌کند. Extended ACL می‌تواند Source، Destination، Protocol و TCP/UDP Port را بررسی کند. بنابراین Extended برای Policy دقیق Application مناسب‌تر است. Numbered و Named بودن شیوه نام‌گذاری است؛ Standard/Extended بودن دامنه Match را مشخص می‌کند.

قاعده سنتی Placement این است که Standard را نزدیک Destination و Extended را نزدیک Source قرار دهیم، اما این یک Guideline است و باید با Topology و Operational Risk سنجیده شود.

access-list 10 permit 10.10.10.0 0.0.0.255
ip access-list extended WEB-ONLY
 permit tcp 10.10.10.0 0.0.0.255 host 192.0.2.20 eq 443

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

پیش‌بینی Policy قبل از Apply

برای چند Flow نمونه Source/Destination/Protocol/Port را بنویس و ACL را خط‌به‌خط روی کاغذ اجرا کن. این روش ساده بسیاری از خطاهای Order و Wildcard را قبل از Production پیدا می‌کند. سپس Interface و Direction اعمال ACL را مشخص کن.

یک ACL خوب علاوه بر Security قابل Troubleshoot است: Name و Remark مناسب، Sequence منطقی، Logging کنترل‌شده و Documentation باعث می‌شود تیم بعدی بداند هر ACE چرا وجود دارد.

show access-lists
show ip interface

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