اساس کار یک روتر بر پایه packet ها بنا شده است. هر آنچه که در یک روتر اتفاق می افتد و یا تمام تکنولوژی هایی که در یک روتر قابل تنظیم هستند همگی بر پایه مشخصات ، خصوصیات و characteristics های packet بنا شده است. لذا براحتی می توان بر این تعاریف استناد کرد و به اهمیت و توجه به محتوای یک packet پی برد. بدست آوردن اطلاعات موجود در یک packet IP بسیار مهم است  و در مواقع بسیاری بویژه troubleshooting مفید واقع می شود. خوب درک این موضوع از یک سناریو با مضمون واقعی و real world ملموس تر هست ، خوب پس از همین روش استفاده می کنم.

فرض کنید که در شبکه یک ساختار چند لایه تعبیه شده و تمام ساختار های امنیتی اولیه در آن اعمال شده است. به علاوه شبکه مقصود ، شبکه ای است که بر پایه محصولات شرکت سیسکو بنا شده است. اما خوب ، مشکل از جایی شروع می شود که شما یکی از host ها و یک network های خود را ping می کنید و یک پیغام  : destination host unreachable را دریافت می کنید.

R1#ping 10.0.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:

U.U.U

Success rate is 0 percent (0/5)

دریافت چنین پیغامی اصلا مطلوب بنظر نمی رسد و ممکن است پیدا کردن منبع مشکل یک کار بسیار سخت باشد. بر طبق اصول اولیه troubleshootingاولین گام اطلاع از hop ای است در شبکه که این پبغام را برای ما ارسال می کند. با کمک traceroute و یا extended ping متوجه می شویم که آدرس IP منبع 192.168.1.2 یکی از روتر های شبکه است که این پیغام توسط آن ارسال می شود. برای اینکه بتوان از اتفاقاتی که در روتر مقصد رخ می دهد باخبر شد ابتدا باید به آن متصل شد . لذا می توان از ابزار هایی مثل Telnet ، Console و یا ssh استفاده کرد و تا  CLI روتر مورد نظر متصل شویم. حال فرض کنید با کمک یکی از ابزار های نام برده شده وارد CLI روتر مورد نظر شده ایم. از آنجایی که مشکل با packet ها است ، شاید در چنین مواقعی استفاده از فرمان debug ip packet یکی و با شاید بهترین راه برای مشاهده packet هایی است که وارد و/یا خارج روتر می شوند. استفاده از این فرمان در 2 زمان کاربرد دارد. این فرمان می تواند اطلاعات packet هایی را که توسط روتر دریافت ، ایجاد(generate) و یا ارسال(forward) می شود را capture کرده و نمایش دهد.به علاوه هنگامی که یک packet در تست های امنیتی اعمال شده در  IOS و تنظیمات fail شود ، آن را بصورت یک پیغام نمایش می دهد. اما این روش یک مشکل بسیار بزرگ دارد. در شبکه های enterprise که حجم بسیار وسیعی از packet وجود دارد ، این فرمان حجم بسیار زیادی از اطلاعات process و آنرا به terminal ارسال می کند که این امر بخش عمده ای از resource های سیستم را اشغال می کند و اصولا استفاده از آن باعث بالا رفتن CPU Utilization ،  exhaust شدن روتر و حتی crash کردن آن  می شود. پس چه باید کرد ؟؟

 برای بهینه کردن استفاده از فرمان debug ip packet دو راه وجود دارد. راه اول اینست که فرمان logging buffered را روتر فعال کنیم و اطلاعات حاصل از debug را به جای نمایش بر روی prompt ، logکنیم. راه دوم استفاده از قابلیتی دیگری است که در IOS جهت استفاده از فرمان debug تعبیه شده است. به فرمان های نوشته شده در زیر توجه کنید :

R2#debug ip packet ?

  <1-199>      Access list

  <1300-2699>  Access list (expanded range)

  detail       Print more debugging detail

در ادامه فرمان debug ip packet امکان استفاده از یک ACL قرار داده شده است. با استفاده از این ACL می توان packet های یک/چند Source ، Destination و حتی پروتکل نیاز به debug را مشخص کرد تا اطلاعات به فیلتر شده بر نمایش داده شوند. با وارد کردن گزینه detail نیز می توان نوع و کد packet و پورت های source و destination را نیز مشاهده کرد.

حالا از این فرمان با بکارگیری Option های مناسب استفاده می کنیم تا بلکه عیب شبکه پیدا شود.

R2#conf t

R2(config)#access-list 100 permit ip host 192.168.1.1 host 10.0.0.1

R2(config)#access-list 100 permit host 10.0.0.1 host 192.168.1.1

R2(config)#access-list 100 permit host 192.168.1.2 any

R2#debug ip packet 100 detail

-----------------

R1#ping 10.0.0.1 source 192.168.1.1 count 1

-----------------

R2#

*Jan  4 17:03:12.838: IP: s=192.168.1.1 (FastEthernet0/0), d=10.0.0.1, len 100,access denied

*Jan  4 17:03:12.842:     ICMP type=8, code=0

*Jan  4 17:03:12.842: ICMP: dst (10.0.0.1) administratively prohibited unreachable sent to 192.168.1.1

*Jan  4 17:03:12.846: IP: tableid=0, s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/0), routed via FIB

*Jan  4 17:03:12.850: IP: s=192.168.1.2 (local), d=192.168.1.1 (FastEthernet0/0), len 56, sending

*Jan  4 17:03:12.854:     ICMP type=3, code=13

با بررسی خروجی بدست آمده براحتی می توان متوجه شد که مشکل از یک Access List است که به اشتباه ترافیک مورد نظر را فیلتر کرده است !!!

نظرات (3)

1  خوب بود نوشته شده توسط This e-mail address is being protected from spam bots, you need JavaScript enabled to view it , روشن 24 خرداد سلام.  دستت درد نکنه ، جالب بود

2  نوشته شده توسط ممم, روشن 28 ارديبهشت

3  نوشته شده توسط الهام, روشن 04 خرداد   اصلا جالب نبود

نوشتن نظر
نام:
ايميل:
صفحه اصلي:
عنوان:
BBCode:
نظر:
كد:*
	من اين نظر را دوستانه جهت تماس ارسال ميكنم