همه چیزدرمورد

Access Control List : Standard & Extended

با سلام خدمت بازدید کنندگان محترم وبلاگ
اول از همه بهتون بگم همانطور که در تیتر این پست می بینید ، هدف فقط ACL Standard, Extended هست ، پس متوجه میشید که انواع دیگری هم داره . دو اینکه می خوام یه داستان بهتون بگم : یکی بود یکی نبود ، روزی روزگاری آقا و خانم سیسکو که بسیار پولدار هم بودند برای سفر وارد شهری میشن که مردم اون شهر همزبون اینا نبودن و بنابر این نه اینا حرفای مردمو میفهمیدن و نه مردم شهر حرفای اینا رو . مردم با دیدن این زوج خیلی شیک و پولدار قند تو دلشون آب میشه و هر کدوم برای مراوده با این زوج شروع میکنن به رقابت با همدیگه . اقامت این زوج در اوج ناز و نعمت و ولخرجی میگذره و از اونجایی که نمی تونستن حرفای مردمو بفهمن با زبون اشاره انواع خدمت ها و نعمتها براشون مهیا بود . القصه بعد از چند صباحی که مردم متوجه مزایای بی شمار اقامت این زوج در شهرشون میشن تصمیم می گیرن برای گسترش روابط تجاری شون زبون اونها رو یاد بگیرن . برای همین هم با هم جلسه ای می زارن و قرار میشه برن پیش همین زوج و از خودشون کمک بگیرن . آقا و خانم سیسکو هم که خیلی پولدار و ذاتا تجارت پیشه بودن تصمیم میگیرن برای آموزش زبانشون لیسانس و سرتیفیکیت درست کنن و مردم رو تشویق کنن برای یاد گیری زبان اونها در دوره های آموزشی سیسکو شرکت کنن . بعد از مدت کوتاهی مردم کم کم با زبان سیسکو آشنا میشن و شروع می کنن به پیشرفت . روزی آقای سیسکو چنین به ذهنش می رسه که اگر مردم کاملا به زبان سیسکو آشنا بشن دیگر چیزی برای یاد دهی باقی نمی مونه و حتی ممکنه بعد از مدتی دکان اموزش زبان بسته بشه . از طرفی اگر مردم نتونن به زبان سیسکو صحبت کنن راه های ارتباطی محدود میشه و تجارت و معامله هاش با مردم کم میشه . خلاصه چند روزی رو غرق در افکار خودش می گذرونه و نهایتا متوجه میشه تا قیامت هم نمی تونه چاره ای برای این مشکل پیدا کنه . نتیجتا تصمیم می گیره بره سراغ همسرش و از او مشورت بگیره . خانم سیسکو به محض شنیدن دغدغه های همسرش با خونسردی بهش میگه : مسخره !!! این که کاری نداره ، منو باش فکر میکردم این چند روز که پکربودی یونجت زیادی کرده و دل به یکی از این غربتی ها دادی . می مردی زودتر بگی ؟ آقای سیسکو هم سفیهانه و ملتمسانه که خب بالاخره راهکار بیزینس ما چیه ؟ خانم سیسکو در جوابش میگه تنها راه حل کسب و کار دایمی تو اینه که گاهی هم که شده با زبانی حرف بزنی که خودت هم حتی نفهمی چی میگی . اینطوری مردم  در ابتدا چیز هایی از تو یاد میگیرن که هم تو می فهمی و هم اونها وبعد چیز های دیگری رو یاد میگیرن که نه تو می فهمی نه اونها . بنابر این علاوه بر اینکه با تو معامله میکنن همیشه شاگرد کلاس زبان هم باقی میمونن ... و چنین شد که قابلیت ACL در IOS سیسکو متولد شد . الباقی داستان رو ایشاللا وقتی خواستین CCIE بگیرین خودتون می نویسید .
حالا نوبت به بیان ویژگی های ACL و Route Map از یک دید کلی و شامل تمام انواعشون می رسه . ACL و Route Map پنج ویژگی مهم دارن که البته من شش ویژگی مهم میدونم اون ها رو . اول این که بسیار پایه ای هستن یعنی مثل جدول ضرب در ریاضیات از همون ابتدا به عنوان یک ابزار دم دست باید یاد بگیرین . دوم این که بسیار پر کاربرد هستند  یعنی یک دیوایس سیسکو حتی برای اینکه بخواد دماغشو بالا بکشه باید از این دو تا استفاده کنه . سوم اینکه بسیار قدرتمند هستن یعنی مسایل و پیچیدگی هایی رو حل می کنن که باورش کمی سخته . چهارم اینکه عملکردشون بسیار پیچیده و پر از ریزه کاری و نکته هست . پنجم این که یادگیریشون هم بسیار پیچیده هست به نحوی که آخرش مطمین میشی اون بابایی که این ها رو ساخته خودش هم نفهمیده چی میگه . ویژگی ششم که خودم بهش اضافه می کنم اینه که بسیار مزخرف هست دلیل : برای کانفیگ معمولی برخی از چیزها نیاز صد در صد به این دو تا داری و بدتر از اون برای اینکه شما یک مشکل رو در شبکه حل کنی ازین دو تا استفاده میکنی بعد از اون باید بشینی 5 تا مشکلی که این دو تا ایجاد کردن رو حل کنی . تازه اگر حل همین 5 تا نیاز مجدد به این دو تا داشته باشه ممکنه تو لوپ بی نهایت بیفتی . بعد از یک آشنایی مختصر و مفید حالا می پردازم به هدف این پست :
در جلسه قبلی ، طبق فرمایش مهندس قادری ، قرار شد برای شما مثال هایی از ACL فراهم کنم . اول سراغ یادداشتها و خلاصه های قبلیم رفتم . یک فایل خلاصه خیلی خوب برای ACL پیدا کردم که مربوط به امتحان CCIE ام بود . انواع دیگر ACL هایی رو که به درد دوره CCNA نمی خورد ( مثل ACL های ipv6/Complex/Reflexive/Time Based ) رو حذف کردم و فقط موارد standard/Extended باقی موند . البته بدلیل اینکه همین دو نوع هم خودشون حاوی ریزه کاری ها و نکته های فراوانی هستند ، همونطور که بعد از دانلود و مشاهده فایل خواهید دید ، به نظر می رسه بخش هاییش بازهم به درد این دوره نخوره ، اما حقیقتش حیفم اومد که این دو نوع ACL رو ناقصش کنم ؛ شاید کسی علاقمند بود و خواست عمیقتر بدونه . ضمنا با مقایسه ای که کردم دیدم تمام مبحث فصل 13 کتاب CCNA فارسی دکتر محسن زاده رو پوشش میده. ماهیت این فایل بشکل خلاصه درس هست ، یعنی به شکلی هست که در زمان خودش با مطالعه منابع متعدد و کانفیگ اونها ، هم مطالب تیوری جمع بندی شده و هم راه کار های جمع و جور کانفیگی مطرح شده . ممکنه سطحش سنگین به نظر برسه اما عمرا هیچ جا منبعی به این شکل و اون هم به زبان فازسی برای ACL پیدا نخواهید کرد . به همین دلیل تقاضا می کنم واتر مارکشو حذف نکنید . بعد از دانلود و مطالعه دقیق این فایل ، برگردید سراغ مثال هایی که در ادامه متن براتون ذکر کردم . در انتها هم چند سایت خوب معرفی کردم که با جستار در اونها مهارت کافی برای حل معماهای ACL بدست خواهید آورد . در انتها یک نکته رو هم بگم که باعث شد من به این مبحث فوق العاده سنگین و مزخرف ACL که در اون دوره خیلی اذیتم کرد تا یاد بگیرم ، تا حدی تسلط پیدا کنم . من هنگام یادگیری ، به هر ACL به دید یک معمای جالب نگاه می کردم . در واقع هر task ای که نیاز به ACL داشت برای من حکم حل یک معما و چیستان رو داشت که با علاقه و قدم به قدم تحلیلش می کردم و حل می کردم . گفتم این راهکار رو بهتون بگم شاید به شما هم کمک کنه . 

مثال 1و 2 : اول از همه اجازه بدید با نوشتن دو ACL استاندارد خیلی کاربردی و پایه ای شروع کنیم . به شکل زیر دقت کنید . ما با هاست B که عضوی از شبکه B هست و شبکه A سرو کار داریم :


اول یک ACL میخواهیم بنویسیم که فقط اجازه دسترسی یک هاست به یک شبکه رو بده . در واقع می خواهیم هر گونه دسترسی شبکه B رو به شبکه A مسدود کنیم الا دسترسی هاست B . همانطور که در کانفیگ بالایی می بینید فقط کافی هست اون یک هاست رو پرمیت کنیم و تمام . چرا ؟ بخاطر اینکه implicit deny مخفی در انتهای تمام ACL ها خود بخود جلوی بقیه ترافیک رو می گیره . کامند implicit deny در ACL های استاندارد ، چیزی شبیه این هست :
Access-list num deny any
یعنی تمام هاست ها در تمام شبکه ها رو deny کن .
در مثال دوم می خواهیم برعکس عمل کنیم . یعنی به تمام هاست های یک شبکه به جز یکی اجازه دسترسی به به شبکه دیگری رو بدیم . در مثال ما ، حالا میخواهیم به کل شبکه B اجازه دسرسی به شبکه A رو بدیم الا هاست B . در کانفیگ پایینی می بینید که ابتدا هاست B رو deny کردیم و برای بقیه شبکه A اجازه دسترسی صادر کردیم . صدور فرمان پرمیت برای باقی شبکه A خیلی مهمه چرا که اگر نباشه ، implicit deny جلوی تمام دسترسی ها رو میگیره .

مثال 3 : کانفیگ Standard ACL : منبع : http://www.orbit-computer-solutions.com/Standard-Access-Lists-Configuration-example.php

یک ACL استاندارد مطابق شرایط زیر بنویسید .

دستورالعمل :

1 - هاست های R3 نباید به هاست های R2 دسترسی داشته باشند .

2 - فقط هاست A روی R1 می تواند به هاست های R2 دسترسی داشته باشد .

3 - تمام ارتباطات دیگر مجازند . از ACL استاندارد ACL 1 استفاده کنید .

4 - ACL 1 را روی اینترفیس سریال se0/se1 اعمال کنید .


R2>enable
R2#configure terminal
R2(config)#access-list 10 deny 172.16.2.0 0.0.0.255
R2(config)#access-list 10 permit host 172.16.3.2
R2(config)#access-list 10 deny 172.16.3.0 0.0.0.255
R2(config)#access-list 10 permit any
R2(config)#interface se0
R2(config-if)#ip access-group 10 in
R2(config-if)#exit
R2(config)#interface se1
R2(config-if)#ip access-group 10 in
R2(config-if)#exit
تشریح : 
به سه روتر میانی و محدوده ip بازوهای آن دقت کنید . قرار هست تمام هاست های سوییچ 3 که روی R3 هستند به هاست های سوییچ 2 که روی R2 هستند دسترسی نداشته باشند . همچنین وقتی میگوید فقط هاست A روی R1 بتواند به هاست های R2 دسترسی داشته باشد ، منظور اینست که فقط یکی از ip ها مجاز است و شما باید دسترسی کل محدوده را بجز یکی بگیرید . همچنین جمله باقی ارتباطات مجازند یعنی باید حواستان باشد ACL ، قبل از اینکه به دستور آخر  ( ACL ( implicit deny برسد باید تمام محدوده ip ها را permit کنید ، تا در تله این دستور مخفی گیر نکنند .
حل : 
الف : برای هاست های R3 ، خیلی ساده یک کامند deny می نویسیم که تمام محدوده ip های سوییچ 3 را پوشش دهد . اگر فایل اینجانب را مطالعه کرده باشید هم اکنون می دانید که صفر در Wildcard mask یعنی فقط خودش و 255 یعنی هر چی که بود . وقتی در wcm سه تا صفر قرار می دهید یعنی سه اکتت اول ip دقیقا خودشان باشند ولی اکتت آحر هر چی که بود . به این معنی که محدوده ای از ip های : 
172.16.2.0 ~ 172.16.2.255
نکته : اگر دقت کنید محدوده 172 در کلاس B هست . پس بازوی R3->E0 که فقط می تواند شامل یک subnet باشد احتمالا کل محدوده 172.16.0.0 را شامل می شود . از آنجایی که برای این بازو هیچ cidr/network mask ای نداده پس قاعده اینست که  ( classful ( /16 فرض بگیریم . اما این در دنیای واقعی خیلی بعید است و باید این فرض را هم مدنظر قرار داد که احتمالا باید subnetting صورت گرفته باشد . . اگر در توپولوژی دقت کنید می بینید که همین محدوده با تفاوت در اکتت سوم روی سوییچ 1 داده شده . پس اطمینان کسب می کنیم که تا 24/ ساب نت شده است .
 ب : در task بعدی خواسته است فقط هاست  A بتواند به هاست های R2 دسترسی داشته باشند . جمله فقط یک هاست ، خیلی ساده یعنی اینکه کل محدوده شبکه : net 172.16.3.0 0.0.0.255 دینای شود بجز یک ip : 172.16.3.2 0.0.0.0 . دو نکته : اول : همانطور که در فایلم هم گفته ام برای هاست می توانید به 3 صورت بنویسید :
172.16.3.2
172.16.3.2 0.0.0.0
Host 172.16.3.2

توصیه میکنم روش اول رو کلا فراموش کنید . دردسر سازه . روش دوم خوبه و روش سوم روش نوشتن حرفه ایهاست . ضمن اینکه اگر sh runn هم بگیرید می تونید ببینید که ios خود سیسکو هم به همین شکل مینویسه . نکته دوم : برای این task همونطور که گفتم یک دینای برای کل محدوده 172.16.3.0 میخواهیم و یک پرمیت برای هاست 172.16.3.2 . خوب کدام اول باشد ؟ طبیعتا اگر اول کل شبکه را دینای کنید حتی اگر هاست مجاز از راه برسد او هم دینای خواهد شد و اجازه عبور نخواهد یافت . پس بهتر است اول هاست مجاز را پرمیت کنیم و بعد کل محدوده را دینای کنیم . این نکته خیلی مهمی است که بدانید در جمله : اول دستورات محدود کننده تر را بنویسید و بعد با محدودیت کمتر را . محدود فقط به معنی deny نیست . بلکه ترکیب deny / permit / condition با هم هستند که محدودتر بودن را تعریف می کنند . همانطوری هم که اینجا میبینید پرمیت بودن یک هاست خیلی محدودتر از دینای شدن یک رنج ip است .
ج : در بخش آخر خواسته است بقیه ارتباطات مجاز باشند . نفس همین جمله یعنی حواستان به implicit deny ذاتی خود ACL باشد . برای نوشتن یک جمله سیسکویی که معنی : " همه شبکه های دیگر " را بدهد در بخش 3 فایلم شرح داده ام : 

 

همه هاست ها در همه subnet ها

فقط یک هاست در یک subnet

بوسیله subnet mask

0.0.0.0 0.0.0.0 یا any

x.x.x.x 255.255.255.255 یا host x.x.x.x

بوسیله wildcard mask

0.0.0.0 255.255.255.255 یا any

x.x.x.x 0.0.0.0  یا host x.x.x.x یا x.x.x.x

د : نکته ای که در اینجا یک کم مساله را پیچیده کرده است اینست که خواسته تنها از یک شماره ACL استفاده کنیم و ضمنا فقط مجازیم روی اینترفیس های سریال se0/se1 اعمال کنیم . باید تحلیل کنیم ببینیم رفتار ACL در برخورد با دستورات غیر مرتبط به اینترفیس اعمال شده چگونه است . دقت کنید اگر لینک بین R1 و R3 نبود ، در اعمال کل ACL روی اینترفیس R2:se0 ، طبعا دستور خط اول بیهوده و بی تاثیر است به شرط آنکه رنج 172.16.2.0 در جای دیگری از توپولوژی غیر از R3 ( بدلیل ساب نتینگ های vlsm ای یا NAT,PAT یا هر چیز دیگر - نکته CCIE  ای ) بکار نرفته باشد ؛ که خوب همینطور است . همچنین با نبود لینک بین R1 و R3 ، در اعمال کل ACL روی اینترفیس R2:se1 ، خط دوم و سوم نیز با همان شرط فوق که ذکر کردم بیهوده و بی اثر است . در نهایت میبینیم که خط آخر که تمام ترافیک های دیگر را مجاز کرده در هر دو مورد لازم و ضروری است . همه اینها برای موردی بود که لینک بین R1 و R3 نباشد . اما حالا که هست ، رفتار ACL به چه گونه است ؟ اگر دقت کنید می بینید که همان خطوط بی اثر مربوط به اینترفیس های R2:se0/se1 ، که در بالا ذکر شد اینجا لازم و ضروری می شود . چرا ؟ بدلیل اینکه به این لینک اصطلاحا Redundancy می گویند . این لینک های افزونه اگر چه قابلیت دسترسی شبکه را بالا می برند اما بر روی شبکه پیچیدگی ایجاد می کنند . در همین مثال می بینید که اگر قرار باشد دسترسی هاست های R3 را به هاست های R2 ببندیم ، این کار باید روی هر دو اینترفیس R2 ، اعمال شود . چرا که این هاست ها از لینک R2:se0 نیز قابل دسترسی هستند. همچنین اگر قرار باشد فقط یک هاست R1 به هاست های R2 دسترسی داشته باشد ، این دسترسی از هر دو اینترفیس R2:se0/se1 مقدور است . در انتهای تحلیل به این نتیجه می رسیم که اگر حتی نمی گفت تمام این دستورات را در یک ACL بگنجانید و روی هر دو اینترفیس R2 اعمال کنید ، خود ما باید این کار را می کردیم . در واقع این جملات خود یک راهنمایی بودند و نه یک پیچیدگی . نکته آخر اینکه این ACL را در این سناریوی خاص می توان بر روی R2:E0 نیز در جهت خروجی اعمال کرد . اما به سه دلیل نمی کنیم : 1- خود task از ما خواسته بر روی اینترفیس های خاصی اعمال شوند . 2 - کار همیشه معقولانه اینست که ACL Standard را در نزدیکترین محل به مبداء و رو به مبداء اعمال کنیم و ما هم بهتر است پیروی کنیم .3 - با اعمال آن به روی E0 ، همانطور که جایی از فایل ذکر کرده ام این پکت ها یک بار در روتر پراسس می شوند و سپس هنگام خروج از E0 به فیلتر ACL ما می رسند . این پراسس زاید است و باید پرهیز شود .

امیدوارم در سطور فوق نحوه تحلیل و حل معماهای ACL را به خوبی آموزش داده باشم . در منبع این مثال فقط توپولوژی و کانفیگ آن آمده است و تشریح و حل قدم به قدم آن به بیان و قلم اینجانب می باشد .

مثال 4 : کنترل دسترسی Telnet یا همان Line VTY . منبع : http://www.orbit-computer-solutions.com/How-To-Control-VTY--Telnet--Access.php


یکی از ساده ترین روشها برای کنترل دسترسی به Line VTY ها یا همان توانایی Telnet کردن به یک دیوایس ، استفاده از ACL Standard هست . در توپولوژی این مثال می خواهیم فقط هاست 192.168.30.10 بتواند به R1 ، Telnet کند .
R1#config t
R1(config)#access-list 10 permit 192.168.30.10
R1(config)#lines vty 0 4
R1(config-line)#access-class 10 in
همانطور که در مثال 1 و 2 هم شاهد بودید برای دادن توان دسترسی به فقط یک هاست کافی است همان هاست را پرمیت کنیم . 4 نکته : کامند اعمال به لاین های دیوایس ( مثل vty,aux,console,async ) و همچنین http  دستور access-class است . ضمنا یادتان باشد Line VTY را همیشه در جهت in اعمال کنید . همچنین می توانید از ACL Extended هم استفاده کنید ، اما باید بر روی تمام اینترفیس های ورودی روتر و در جهت in اعمال کنید . ضمنا در دنیای واقعی کمتر کسی از هر دوی این روشها استفاده می کند ، بلکه بهتر است با ACL Extended و پروتکل / پورت TCP/23 اقدام به مسدود کردن دسترسی Telnet نمایید .
ضمیمه : بد نیست در اینجا یک اشاره ای به این مطلب بکنم که پیش زمینه برقراری ارتباط Telnet که از طریق Line VTY ها انجام میشه ربطی به مجوز دسترسی و فیلترینگ توسط ACL نداره . برای همین برای اینکه هم یک یادآوری ای بشه براتون و هم این دو تا مطلب منفک بشن از هم ، یک یاد آوری از بستر سازی برای ارتباط Telnet می کنم :
برای آماده سازی دیوایس که افراد بتونن از راه دور بهش Telnet کنن سه تا کار باید انجام بدین :
1 - حداقل یک اینترفیس باید ip داشته باشد ؛ تا بتوان به آن یک ارتباط لایه 3 ای Telnet برقرار کرد . 
برای swl2 روش عمده کار اینست که فقط آن یک SVI ای را که می توان ساخت ، ip داد . اکثرا برای تمام sw هایی که در یک حوزه Layer2 Broadcast هستند ، یک management vlan با یک شماره واحد درست می کنند و این SVI ها را بر اساس آن شماره ساخته تا بعنوان Default Gateway آنها عمل کنند . برای روتر ها هم براحتی می توان یکی از اینترفیس ها را ip داد .
Vlan 99
Name mng
Interface vlan 99
Ip address 192.168.0.99 255.255.255.0
2 - برای حداقل یکی از لاین های VTY باید پسورد تعیین کنید .
Line vty 0 15
Password cisco
Login
3 - برای enable mode دیوایس نیز از یکی از دو روش زیر باید پسورد تنظیم کنید . بدلیل تاکید استاد قادری مبنی بر اینکه در sh runn نباید هیچ پسوردی clear text باشد ، توصیه میکنم حتما کامند اولی را بزنید .
service password-encryption
enable password cisco        OR      enable secret cisco
مثال 5 و 6 : ACL Extended
امیدوارم که تا الان فایل مربوط به ACL را حداقل دو بار خوانده باشید . پس حتما میدانید که اگر در ACL Standard فقط می توانستیم بر اساس آدرس ip مبدا ء و ارسال کننده پکت عمل فیلترینگ انجام دهیم ، با ACL Extended می توانیم بر اساس تمام مشخصات لایه های 3 و 4 این کار را انجام دهیم . 
در این دو مثال می خواهم روند کامل حذف ACL را نیز توضیح دهم . پس خوب دقت کنید . 
قبل از شروع به سه نکته اساسی توجه کنید . یک اینکه  در تمام ACL Extended ها ، حداقل سه عنصر ضروری باید بیان شود . آدرس ip فرستنده و گیرنده و پروتکل . به شکل کلی این کامند توجه کنید :

 Glob# access-list access-list-number {deny | permit} protocol 

{host | source source-wildcard | any} {host | destination destination-wildcard | any} [log]

نکته : در تمام کامند های سیسکویی که در منابع اصلی می ببینید به یاد داشته باشید کروشه {} فیلد های الزامی و براکت [] فیلد های اختیاری هستند . همچنین پایپ | به معنی یا می باشد . کلمات کلیدی که باید تایپ شوند بصورت Bold و کلماتی که جایگزین آن باید جایگزاری شود در اکثر موارد Italic و کج هستند . با ترکیب های متنوعی از اینها می توانید هر دستورالعملی را بیان کنید. 

در کامند کلی فوق می بینید که سه عنصر پروتکل و source ip و destination ip الزامی هستند . کلمه protocol کروشه ندارد یعنی باید بیان شود و ایتالیک است یعنی باید بجای خود این کلمه نام یا شماره یک پروتکل را بیان کنید . source ip و destination ip نیز به این دلیل که معادل host یا any دارند درون کروشه هستند ، و خود آنها به همراه wildcard شان باید جایگزین شوند . 
نکته دوم هم این که اگر پروتکل شما TCP یا UDP باشد ، باید یک عملگر به همراه شماره یا نام پورت فرستنده و گیرنده مشخص شود . 
نکته سوم هم اینکه خود پروتکل IP شامل تمام مجموعه پروتکل های IP در لایه 4 می باشد . به واقع تمام پروتکل هایی که سوار بر IP در لایه 3 می شوند را شامل می شود .

به شکل زیر دقت کنید :


خوب ، حتما به یاد دارید که (POP3(port110 و (SMTP(port25 دو پروتکل فراگیر ارسال ایمیل بودند . بیایید در قدم اول سعی کنیم تمام ترافیک های SMTP تولید شده از WAN را روی Router X مسدود کنیم تا از لینک A عبور نکند . برای این کار چون احتیاج به تعیین نوع پروتکل و مقصد داریم پس لازم است که از ACLextd استفاده کنیم . همچنین محل قرار گیری آن روی RX:S0 یعنی نزدیکترین جا به مقصد ترافیک می باشد . 

RX(config)#access-list 105 deny TCP any host 172.16.11.253 eq SMTP
RX(config)#access-list 105 permit IP any any
RX(config)#int s 0
RX(config-if)#ip access-group 105 out

خط اول : ترافیک پروتکل TCP با مبداء از هر جایی به مقصد دقیقا ip معلوم 172.16.11.253 که نام پورت آن SMTP باشد را نپذیر . تذکر : به جای نام پورت می توانید شماره آن را قرار دهید . عملگر eq یعنی Equal به معنی "برابر باشد با"

خط دوم : ترافیک IP از هر مبداء ی به هر مقصدی مجاز باشد .
با این ACL جلوی دسترسی ترافیک ایمیل SMTP که می خواهد از RX بگذرد ، گرفته می شود .
حالا بیایید این بار جلوی ترافیک ICMP شبکه پشت Router Y را بگیریم . می دانید که این پروتکل برای ping و trace بکار می رود .
RY(config)#access-list 102 deny icmp 192.168.115.0  0.0.0.255 any
RY(config)#access-list 102 permit IP any any
RY(config)#int s 1
RY(config-if)#ip access-group 102 out

خط اول : ترافیک پروتکل icmp با مبداء تمام هاست های شبکه 192.168.115.0 به مقصد هر جا ، deny شود .

حالا نوبت به پروسه پاک کردن ACL می رسد . بیایید ACL اعمال شده روی RX را پاک کنیم :

اولین کار پاک کردن ACL اعمال شده روی اینترفیس است .

RX(config-if)#no ip access-group 105 out

سپس در صورتی که مطمینید ACL قبلی هرگز به دردتان نمی خورد ، پاک کردن خود ACL است :

RX(config)#no access-list 105


مثال 7 : کنترل دسترسی web با ACL Extended . منبع : http://www.orbit-computer-solutions.com/Extended-ACLs-Configuration.php

کلی نکته به همراه گرفتن غلط کانفیگی سایت مذکور :)

پیش زمینه : حتما از ترم های قبل به یاد دارید که ترافیک Web مبتنی بر http با شماره پورت 80  و مبتنی بر https با شماره پورت 443 بود و هر دو پروتکل با tcp کار می کردند .

به این سناریو دقت کنید :


در این سناریو ادمین های شبکه تصمیم دارن نامردی کنن و به هاست های شبکه 192.168.2.0 ، فقط اجازه دسترسی web browsing بدن . حتما می دونید که ترافیک http رفت و برگشت هست . یعنی شما request ای به پورت های 80 و 443 با پروتکل tcp می فرستین و برگشتش یک پیام برقراری ( در اصطلاح establish ) به شما بر می گرده .
R1(config)#access-list 101 permit tcp 192.168.2.0 0.0.0.255 any eq 80
R1(config)#access-list 101 permit tcp 192.168.2.0 0.0.0.255 any eq 443
R1(config)#access-list 102 permit tcp 192.168.2.0 0.0.0.255 any eq established

چرا دو تا ACL نوشتم ؟ چون جهت اعمال هر کدوم فرق داره . در ACL 101 ، فقط به ترافیک tcp با پورت های 80 و 443 و از مبداء شبکه ما به مقصد هر جایی اجازه عبور دادم . بدلیل اینکه ادمین ها می خوان فقط ترافیک وب برای هاست هاشون مجاز باشه اونرو باید در R1:s0 و در جهت out اعمال کنم . اینجوری هیچ ترافیک زایدی اصلا وارد روتر نمیشه که بخواد پراسس بشه .

یک نکته : اسم پورت 80 ، www است که می تونید بجای عدد از اسم استفاده کنید .

در ACL 102 ، قصد داریم تنها ترافیکی را که به درخواست های 80 و 443 هاست ها reply شده و به مقصد هاست های من ارسال شده اند ، مجاز کنم . اما آیا به نظر شما این کامندی که سایت مربوطه زده درست است ؟ چند تا مشکل دارد ؟ بله ، من هم فکر می کنم اشتباه کرده اند . !!! قبل از ایراد گیری از این کامند ، دو نکته مهم را بدانید : 
اول اینکه اعمال آن منطقا روی R1:s0 و در جهت in است . 
دوم اینکه نحوه برقراری ارتباط TCP ، 3 مرحله دارد (three-way handshake )( رجوع شود به کتاب مهندسی اینترنت ص 189 ) . اما بطور خلاصه : مرحله اول ارسال درخواست به سرور است . بیت Ack=0 و بیت SYN=1 . مرحله دوم پذیرش ارتباط توسط سرور است . اگر نپذیرد بیت RST=1 . و اگر بپذیرد SYN=Ack=1 . مرحله سوم شروع کننده ارتباط SYN=Ack=1 را می فرستد . در انتها هر دو سرور و کلاینت یک Ack دریافت کرده اند . 
مرحله اول و دوم یک ارتباط یک طرفه Ack شده برقرار می سازد . یعنی سرور به کلاینت Ack داده است . به این مرحله half-open established گفته می شود . مراحل دوم و سوم نیز ارتباط طرف دیگر Ack شده برقرار می سازد . در این مرحله کلاینت نیز به سرور Ack داده است . بعد از مرحله سوم full-duplex established گفته می شود . 
کلمه کلیدی Established فقط برای پروتکل TCP بکار می رود و در کامند به معنی " یک ارتباط از قبل برقرار شده " ، می باشد . زمانی همخوانی ( match ) پیدا می کند ( یعنی زمانی این شرط صادق می شود ) که یکی از بیت های Ack یا RST در دیتا گرام TCP به 1 تنظیم شده باشد ، که مشخص کننده اینست که پکت متعلق است به یک ارتباط از قبل موجود . توضیح اضافه اینکه اگر به مرحله دوم دقت داشته باشید می دانید که از طرف سرور ، به هر حال یکی از دو وضعیت Ack=1 برای پذیرش یا RST=1 برای رد ارتباط پیش می آید . اگر سرور ارتباط را نپذیرفته باشد بیت Ack=0 را از مرحله قبل دست نخورده باقی گذاشته ولی بیت RST=1 می کند . اگر سرور ارتباط را پذیرفته باشد بیت RST=0 از مرحله قبل دست نخورده می ماند ولی بیت های SYN=Ack=1 می کند . در هر دو حالت میبینید که اگر یکی از بیت های Ack یا RST برابر 1 باشد ، مطمین می شویم که این یک reply به یک درخواست قبلی است .  و نهایتا همین کلمه کلیدی برای ما کافی هست تا مطمین شویم به ترافیکی مجوز ورود می دهیم که جواب به درخواست های هاست های خودمان است . 
حالا برگردیم به کامند ACl 102 : واضح ترین ایرادی که ابتدا به چشم میخورد اینست که مبداء و مقصد را برعکس نوشته است . در واقع ترافیک برگشتی از وب می تواند از هر آدرسی باشد ولی مقصد آنها حتما هاست های ما است . 

خیلی دوست دارم حالا که با همدیگر قدم به قدم تا اینجا آمده ایم قدرت ACl را اینجا نشانتان بدهم. من عین همین کامند را در GNS3 می زنم و حاصل ؟ را برای شما نشان می دهم :

می بینید که غیر از عملگرهای eq/gt/lt/neq ، تمام بیت های فیلد Flag در هدر دیتا گرام tcp ، اعم از ack/fin/psh/rst/syn/urg را توسط فیلترینگ ACL می توانید کنترل کنید . اینجاست که خون آدم به جوش میاد :)

خب ، بقیه ایرادات . اگر دقت کنید همینجا براحتی میشه کلمه کلیدی established رو وارد کرد . و درستش هم همینه . اما اومده عملگر eq ( به معنی برابراست با ) رو گذاشته و بعد established رو نوشته . بنده خدا نکرده خودش یکبار کامند رو بزنه . میگم اگر هر کدمتون وقتشو داشتید یه ایمیل بهش بزنید اصلاحش کنه . حالا ببینیم اگر eq بزنیم چه انتخاب هایی داریم :


خوب ، تنها چیزهایی که من می بینم یک قابلیت انتخاب شماره پورت از 0 تا 65535 هست و در ادامه لیست اسم بعضی از اون مهماشه . شما چیزی از established می بینید ؟؟؟
پس کامند رو اینطور اصلاح می کنم :

R1(config)#access-list 102 permit tcp any 192.168.2.0 0.0.0.255 established

آخر کار اعمال ACL extd :

R1(config)#int s 0
R1(config-if)#ip access-group 101 out
R1(config)#int s 0
R1(config-if)#ip access-group 102 in

خوب دیگه خیلی خسته شدم . این مقاله 10 ساعت وقت طی این 3 روز از من گرفت . ارایه مثال های بیشتر و یکسری نکته Troubleshooting و همچنین معرفی سایت بمونه برای روز جمعه ، بعد از امتحان . اگر واقعا خواهان یادگیری ACL هستید حتما فایل من و این مقاله رو چند بار بخونید و مثال هاشو برای خودتون پیاده سازی کنید .
اگر این مقاله براتون مفید بوده یا نه ، و اگر نظر خاصی دارید لطفا در کامنت همینجا اعلام کنید .