يفترض أن تكون قرأت الموضوعين السابقين (لوائح التحكم بالوصول القياسية ، لوائح التحكم بالوصول الموسعة) حتى يكون لديك فهم جيد للمفاهيم الأساسية في قوائم ACL يناقش هذا الملف قوائم ACL المسماة وآلية التحرير والتعديل على قوائم ACL عن طريق الأرقام التسلسلية وعلى الرغم من أهميتهما إلا أنهما لا يضيفان أي وظيفة جديدة فيما يتعلق بما يمكن لجهاز التوجيه أن يقوم بتصفيته وما لا يمكنه تصفيته والفائدة الأساسية لهما هو تسهيل تذكر أسماء قوائم ACL وتعديل قوائم ACL الموجودة عندما تحتاج قائمة ACL إلى أي تغيير.
قوائم التحكم بالوصول ACL المسماة
تحتوي قوائم ACL المسماة على العديد من أوجه التشابه مع قوائم ACL المرقمة فهي تستخدم أيضاً لتصفية الحزم ويمكن أن تتطابقان في نفس الحقول بحيث يمكن أن تتطابق قوائم ACL المرقمة القياسية مع نفس الحقول في قائمة ACL القياسية المسماة ويمكن أن تتطابق قوائم ACL المرقمة الموسعة مع نفس الحقول في قائمة ACL المسماة الموسعة.
وبالطبع فهناك بعض الاختلافات بين قوائم ACL المسماة والأخرى المرقمة ومن أبرزها:
■ استخدام الأسماء بدلاً من الأرقام لتعريف قائمة التحكم بالوصول ACL مما يسهل تذكر هدف وغاية قائمة التحكم بالوصول ACL.
■ استخدام الأوامر في وضع الاعداد الخاص لـ ACL بدلاً من الأوامر في وضع الاعداد العام لتحديد الإجراءات والمعلمات المطلوبة للمطابقة المطابقة.
■ تستخدم في تحرير قائمة التحكم بالوصول ACL والتي تمكن مستخدم واجهة سطر الأوامر CLI من حذف عبارة محددة ضمن قائمة التحكم بالوصول وإدراج عبارة جديدة.
تعتبر أسهل في معرفة إعدادات لائحة ACL المسماة ويوضح الشكل مثل هذا الفرق بين اللوائح المرقمة والمسماة:
الجزء الجديد فعلياً في إعداد لوائح ACL المسماة هو أمر الإعداد العام لقائمة التحكم بالوصول بحيث يحدد هذا الأمر ما إذا كانت القائمة هي قائمة قياسية أم موسعة كما يحدد الاسم المختار لها. كما أنه ينقل المستخدم إلى وضع الاعداد الخاص لـ ACL كما هو موضح في المثال أدناه فبمجرد الدخول في وضع الإعداد الخاص لـ ACL يمكنك وضع أوامر السماح (permit) والرفض (deny) والملاحظة (remark) والتي تماثل نظيراتها في بناء جملة أوامر قائمة التحكم بالوصول المرقمة.
يوضح المثال أدناه إعداد قائمة ACL الموسعة المسماة ولاحظ بشكل خاص أوامر وضع الإعداد الخاص وكيفية الوصول لذلك الوضع:
بدأ المثال السابق بإنشاء قائمة ACL سميت بـ barney بحيث يقوم الأمر:
ip Access-list Extended barney
بإنشاء قائمة ACL وتسميتها barney ومن ثم وضع المستخدم في وضع الإعداد الخاص لـ ACL كما يقوم هذا الأمر أيضًا بإشعار نظام التشغيل بأن barney تمثل قائمة تحكم بالوصول وهي من النوع الموسع.
بعد ذلك تحدد الخمس عبارات الخاصة بالسماح والرفض منطق المطابقة والإجراء الذي يجب اتخاذه.
يظهر مخرج الأمر:
show Running-config
إعداد قائمة التحكم بالوصول المسماة وذلك قبل إجراء أي تعديل على أي من عباراتها.
وكما ذُكر سابقاً فإن قوائم ACL المسماة تسمح للمستخدم بحذف وإضافة أسطر عبارات جديدة في قائمة ACL وذلك من داخل وضع الإعداد الخاص لـ ACL ويوضح المثال أدناه كيف يتم ذلك باستخدام الأمر no Deny IP وهو الأمر الذي يقوم بحذف عبارة واحدة من قائمة التحكم بالوصول ACL ولاحظ مخرجات الأمر show access-list في نهاية المثال والتي تحوي أربعة عبارات للسماح والرفض بدلاً من خمسة.
تحرير وتعديل قوائم التحكم بالوصول باستخدام الأرقام التسلسلية
كانت قوائم ACL المرقمة موجودة في نظام IOS منذ الأيام الأولى لأجهزة توجيه Cisco إلا أن القدرة على تحرير قائمة ACL المرقمة كانت محدودة فعلى سبيل المثال لحذف سطر من قائمة ACL كان على المستخدم حذف قائمة الـ ACL بالكامل ثم إعادة إنشاءها.
تستخدم ميزة تعديل قائمة التحكم بالوصول رقم تسلسل قائمة التحكم بالوصول والذي تتم إضافته إلى كل عبارة (permit) أو (deny) لقائمة التحكم بالوصول (ACL) ومع الأرقام التي تمثل تسلسل العبارات في قائمة التحكم بالوصول توفر هذه الأرقام الميزات التالية لكل من قوائم التحكم بالوصول سواء المرقمة أو المسماة:
نمط إعداد جديد للوائح المرقمة: تستخدم ACL المرقمة نمط إعداد مثل نمط إعداد ACL المسماة وهو النمط الجديد الذي يمكن من إجراء التحرير والتعديل على لوائح ACL.
حذف الأسطر أو العبارات بشكل فردي: يمكن حذف عبارة (permit) أو (deny) بشكل فردي باستخدام الأمر:
no sequence-number subcommand
إدراج أسطر أو عبارات جديدة: يمكن إعداد أوامر (permit) و (deny) المضافة حديثاً برقم تسلسلي يوضع قبل أمر (permit) أو (deny) مما يحدد موقع العبارة داخل قائمة التحكم بالوصول (ACL).
ترقيم التسلسل التلقائي: يضيف نظام IOS الأرقام التسلسلية إلى العبارات أثناء إعدادها بشكل تلقائي حتى إذا لم تقم بتضمينها.
للاستفادة من إمكانية حذف الأسطر وإدراجها في قائمة ACL يجب أن تستخدم كل من قوائم ACL المرقمة والمسماة نفس نمط الإعداد العام والأوامر المستخدمة لقوائم ACL المسماة والفرق الوحيد في بناء الجملة هو ما إذا كان يتم استخدام اسم أو رقم يوضح المثال أدناه إعداد قائمة ACL مرقمة القياسية باستخدام نمط الإعداد البديل هذا ويوضح المثال قوة فكرة رقم تسلسل ACL لأغراض التحرير والتعديل ففي هذا المثال يحدث ما يلي:
الخطوة 1. تم إعداد ACL 24 المرقم باستخدام هذا النمط الجديد مع ثلاثة عبارات (permit).
الخطوة 2. يعرض الأمر show ip Access-lists أوامر (permit) الثلاثة بأرقام تسلسلية هي 10 و20 و30.
الخطوة 3. يقوم المهندس بحذف أمر الـ(permit) الثاني فقط باستخدام الأمر الإعداد الخاص no 20 ACL والذي يشير ببساطة إلى الرقم التسلسلي 20.
الخطوة 4. يؤكد الأمر show ip Access-lists أن قائمة ACL تحتوي الآن على عبارتين فقط (أرقامهما التسلسلية هي 10 و30).
الخطوة 5. يقوم المهندس بإضافة أمر (deny) جديد إلى بداية قائمة التحكم بالوصول ACL باستخدام الأمر الفرعي:
5 deny 10.1.1.1
الخطوة 6. يؤكد الأمر show ip Access-lists التغييرات مرة أخرى ويدرج هذه المرة ثلاثة أوامر والأرقام التسلسلية هي 5 و10 و30.
إعداد ACL المرقم وإعداد ACL المسمى
يسمح نظام التشغيل IOS فعليًا بطريقتين لإعداد قوائم ACL المرقمة في الإصدارات الأحدث من IOS. فهو يدعم الطريقة التقليدية باستخدام الأمر access-list الموضح في الأمثلة السابقة ويدعم أيضًا إعداد ACL المرقمة بأوامر مماثلة للمستخدمة في إعداد ACL المسماة كما هو موضح في المثال السابق.
ومن الغريب أن نظام IOS يقوم دائمًا بتخزين قوائم ACL المرقمة بالنمط الأصلي للإعداد كأوامر مدخلة في الوضع العام وبغض النظر عن الطريقة المستخدمة لإعداد قائمة الوصول. ويوضح المثال أدناه هذا الأمر حيث يستكمل ما انتهى اليه المثال السابق مع الخطوات الإضافية التالية:
الخطوة 7. يُظهر المهندس ما تم من الإعدادات عن طريق الأمر (show running-config) والذي يسرد أوامر الإعداد ذات النمط القديم على الرغم من إنشاء قائمة التحكم بالوصول (ACL) باستخدام أوامر النمط الجديد.
الخطوة 8. يضيف المهندس عبارة جديدة إلى نهاية قائمة التحكم بالوصول (ACL) باستخدام أمر التكوين العام القديم:
access-list 24 permit 10.1.4.0 0.0.0.255
الخطوة 9. يؤكد أمر show ip Access-lists أن أمر قائمة التحكم بالوصول ذي النمط القديم من الخطوة السابقة تتبع قاعدة الإضافة إلى نهاية قائمة التحكم بالوصول (ACL) فقط.
الخطوة 10. يعرض المهندس ما تم من إعدادات للتأكد من أن أجزاء الـACL التي تم إعدادها باستخدام أوامر النمط الجديد وأوامر النمط القديم كلها مدرجة في نفس قائمة التحكم بالوصول (ACL) ذات النمط القديم.
اعتبارات مهمة أثناء تنفيذ ACL
يمكن أن تكون قوائم ACL أداة رائعة لتعزيز أمان الشبكة ولذلك فيتطلب من المهندسين التفكير في بعض المشكلات التي قد تواجههم وذلك قبل إعداد قائمة ACL ولذلك تقدم Cisco التوصيات العامة التالية في الدورات التدريبية التي تعتمد عليها اختبارات CCNA R&S:
■ ضع قوائم ACL الموسعة في أقرب مكان ممكن من مصدر الحزمة بحيث تسمح هذه الإستراتيجية لقوائم ACL بتجاهل الحزم مبكرًا.
■ ضع قوائم ACL القياسية في أقرب مكان ممكن من وجهة الحزمة بحيث تتجنب هذه الإستراتيجية الخطأ في قوائم ACL القياسية والتي تتطابق مع عنوان IPv4 المصدر فقط والمتمثلة في المنع غير المقصود من الحزم التي لا تحتاج إلى منع.
■ ضع العبارات الأكثر تحديدًا في بداية قائمة التحكم بالوصول (ACL).
■ قم بتعطيل قائمة التحكم بالوصول (ACL) من المنفذ الخاص بها (باستخدام أمر الإعداد الخاص no ip Access-group Interface) وذلك قبل إجراء أي تغييرات على قائمة التحكم بالوصول (ACL).
في النقطة الأولى بشأن تحديد مكان قوائم ACL الخاصة. فعند الرغبة في تصفية حزمة ما فإن التصفية بالقرب من مصدر الحزمة تعني أن الحزمة لن تشغل نطاقًا تردديًا كبير في الشبكة وهو فعلياً أكثر كفاءة ولذلك تقترح Cisco تحديد موقع قوائم ACL الموسعة بالقرب من المصدر قدر الإمكان.
وأما بالنسبة للنقطة الثانية فنظرًا لأن قوائم ACL القياسية تنظر فقط إلى عنوان IP المصدر، فإنها تميل إلى التصفية أكثر مما تريد تصفيته عند وضعها بالقرب من المصدر. فمثلاً تخيل أن (محمد) و (حمزة) مفصولان بأربعة أجهزة توجيه. إذا قمت بتصفية حركة مرور حمزة المرسلة إلى محمد على جهاز التوجيه الأول، فلن يتمكن حمزة من الوصول إلى أي مضيفين بالقرب من أجهزة التوجيه الثلاثة الأخرى. لذا، توصي Cisco بأن تكون لوائح ACL القياسية بالقرب من الوجهة لتجنب تصفية حركة المرور الغير مرغوبة.
بالنسبة للنقطة الثالثة فمن خلال وضع معلمات مطابقة أكثر تحديدًا في وقت مبكر من كل قائمة تقل احتمالية ارتكاب الأخطاء في قائمة التحكم بالوصول (ACL). فمثلاً تخيل أن قائمة التحكم بالوصول (ACL) أدرجت أولاً أمرًا يسمح بحركة المرور المتجهة إلى 10.1.1.0/24 وأن الأمر الثاني يرفض حركة المرور المتجهة إلى الجهاز 10.1.1.1 فإن الحزم المرسلة إلى ذلك الجهار سوف تتطابق مع الأمر الأول ولن تتطابق أبدًا مع الأمر الثاني والأكثر تحديدًا. لاحظ أن إصدارات IOS الأحدث تمنع حدوث هذا الخطأ أثناء الإعداد وفي بعض الحالات كما سأوضح ذلك لاحقًا.
وأخيرًا توصي Cisco بتعطيل قوائم ACL على المنافذ قبل تغيير البيانات في اللائحة. لأجل تجنب المشكلات التي قد تحدث اثناء إعداد عبارات اللائحة. ولإيضاح ذلك لنفترض أننا أعددنا ACL 101 ومكناه على المنفذ S0/0/0 للحزم الخارجة منه ثم لسبب ما قمنا بحذف القائمة 101 رغبةً في إعادة صياغتها مثلاً حينها سيتم السماح لجميع الحزم بالمرور لعدم وجود أي عبارات مدخلة على اللائحة 101 وذلك مع أن المنفذ لازال معد لتنفيذ اللائحة 101 فإذا قمنا بإدخال أمر واحد للقائمة 101 وبمجرد الضغط على Enter تكون القائمة موجودة ويقوم جهاز التوجيه بتصفية جميع الحزم الخارجة من S0/0/0 بناءً على القائمة المكونة من سطر واحد فلو افترضنا أننا نريد إدخال قائمة ACL طويلة فقد يقوم الموجه بتصفية الحزم التي لا تريد تصفيتها مؤقتًا وذلك ريثما نكمل جميع أوامر اللائحة. ولذلك فإن الطريقة الأفضل هي تعطيل القائمة من المنفذ وإجراء التغييرات ثم إعادة تمكينها على المنفذ.
استكشاف الأخطاء وإصلاحها في قوائم ACL
تؤدي قوائم ACL أحياناً إلى صعوبة استكشاف أخطاء توجيه IPv4 وإصلاحها. فيمكن مثلاً أن تكون جميع أجهزة الشبكة تعمل بشكل جيد، وتكون إعدادات DHCP صحيحة، وجميع الشبكات المحلية تعمل بشكل جيد، وجميع منافذ أجهزة التوجيه تعمل بشكل جيد ولديها جداول توجيه صحيحة وتحوي جميع المسارات اللازمة للوصول لأي وجهة إلا أن هناك خلل بسبب وجود لوائح التحكم في الوصول (ACL) تصفية بعض الحزم التي يجب ألا تصفيها. فعلى الرغم من أن قوائم ACL توفر خدمة تصفية بعض الحزم إلا أنها أحيانا تجعل عملية استكشاف الأخطاء وإصلاحها أكثر صعوبة.
تناقش هذه الأوراق فكرة استكشاف الأخطاء وإصلاحها في حالة وجود قوائم ACL. وستقسم المناقشة إلى قسمين الأول نصائح حول المشكلات الشائعة التي قد تراها في الاختبار وكيفية تحديدها والتعرف عليها وذلك استناداً على أوامر show وبعض التحليلات اللازمة. ثم يبحث القسم الثاني في كيفية تأثير قوائم ACL على أمر ping
تحليل سلوك ACL في الشبكة
تتسبب قوائم ACL في إيجاد بعض التحديات الكبيرة في إطار استكشاف المشكلات وإصلاحها في الميدان العملي للشبكات الحقيقية. فالحزم التي يتم إنشاؤها بأوامر مثل ping وtraceroute لا تتطابق تماماً مع الحقول الموجودة في الحزم التي المراد مطابقتها مع ACL فتقوم قوائم ACL أحياناً بتصفية حركة مرور ping وtraceroute مما يجعل مهندس الشبكة يعتقد أن هناك نوعاً ما من المشكلات في حين أنه لا توجد أي مشكلات على الإطلاق. أو أن مشكلة حركة مرور الحقيقة سببها قائمة التحكم بالوصول (ACL) ولكن حركة مرور ping وtraceroute تعمل بشكل جيد لأن قائمة التحكم بالوصول (ACL) تطابق حركة مرور المستخدم العادي مع الإجراء (deny) بينما تطابق حركة مرور ping وtraceroute مع الإجراء (permit)
ونتيجة لذلك، يتطلب استكشاف الأخطاء الناتجة عن قوائم التحكم بالوصول (ACL) وإصلاحها الكثير من الجهد والتفكير، التفكير في إعداد قائمة التحكم بالوصول (ACL) ومقارنتها بالحزم التي تتدفق في الشبكة. أوامر show التي تساعدك في هذا الأمر هي تلك التي تظهر لك إعدادات قائمة التحكم بالوصول (ACL)، والمنافذ التي يتم تمكين قائمة التحكم بالوصول (ACL) عليها. كما يفيد أيضًا الاطلاع على إحصائيات حول عبارات القوائم التي تمت مطابقتها وتطابقها. ويمكن أن يساعد كذلك استخدام اختبارات ping وtraceroute مع تذكر أن قوائم التحكم في الوصول (ACL) قد تطبق إجراءات مختلفة على تلك الحزم مقابل حركة مرور المستخدم النهائي.
أدناه خطوات مهمة في استكشاف أخطاء ACL وإصلاحها تم وضعها في شكل قائمة لتسهل الفهم. الخطوة الثالثة تركز على فكرة تحليل كل قائمة:
الخطوة 1. تحديد المنافذ التي تم تمكين قوائم ACL عليها وفي أي اتجاه
(show running-config , show ip interfaces)
الخطوة 2. ابحث عن إعدادات كل قائمة ACL
)show access-lists, show ip access-lists, show running-config(
الخطوة 3. قم بتحليل قوائم ACL لمحاولة اكتشاف الخلل مع التركيز على النقاط التالية:
أ. قوائم ACL ذات ترتيب خاطئ: ابحث عن عبارات ACL ذات الترتيب الخاطئ وتذكر أن IOS يستخدم منطق أول مطابقة عند البحث في قائمة التحكم بالوصول (ACL).
ب. عناوين المصدر/الوجهة المعكوسة: قم بالتأكد من منفذ جهاز التوجيه والاتجاه الذي يتم فيه تمكين قائمة التحكم بالوصول (ACL) وقارن موقع نطاقات عناوين IP المطلوب مطابقتها مع قائمة التحكم بالوصول (ACL) وتأكد من أن حقل عنوان IP المصدر مدخل بشكل صحيح وليس عنوان IP الوجهة والعكس صحيح بالنسبة لحقل عنوان IP الوجهة.
ج. منافذ المصدر/الوجهة المعكوسة: بالنسبة لقوائم ACL الموسعة والتي تحوي أرقام منافذ UDP أو TCP استمر في تحليل موقع واتجاه قائمة ACL ومقارنة ذلك بالنظر للأجهزة المراد تطبيقه عليها مع التركيز على الجهاز الذي يعمل كخادم باستخدام منفذ معروف (well-known). تأكد من أن عبارة ACL تتطابق مع منفذ المصدر أو الوجهة الصحيح مراعياً ما إذا كان الخادم المرسل للحزمة أو المستقبل لها.
د. بنية الجملة: تذكر أن أوامر ACL الموسعة يجب أن تستخدم كلمات مثل tcp وudp إذا كان الأمر يحتاج إلى التحقق من أرقام المنافذ.
هـ. بنية الجملة: تذكر أن حزم ICMP لا تستخدم UDP أو TCP بحيث يعتبر ICMP بروتوكول آخر يمكن مطابقته مع الكلمة icmp (بدلاً من tcp أو udp).
و. الرفض الصريح للجميع: فبدلاً من الاعتماد على الرفض الضمني للجميع والموجود في نهاية كل قائمة ACL يفضل استخدم أمر إعداد صريح لرفض كل حركة المرور في نهاية قائمة ACL فهذا يفيد احتساب عدد المطابقة بحيث يزداد عداد الأمر show عند اتخاذ هذا الإجراء.
ز. قوائم ACL ذات الاتجاه (in) الخطرة: دقق النظر في قوائم ACL الواردة خاصة تلك التي تتضمن رفض الكل في نهاية قائمة ACL. قد تتسبب قوائم ACL هذه في تجاهل البروتوكولات العامة الواردة مثل رسائل بروتوكول التوجيه
ح. موقع ACL القياسي: يمكن لقوائم ACL القياسية التي تم تمكينها بالقرب من مصدر العناوين أن تمنع الحزم المقصودة ولكنها تمنع أيضًا الحزم التي ينبغي السماح لها بالمرور.
أوامر استكشاف أخطاء ACL وإصلاحها
الخطوة الأولى لمعالجة المشكلة هي معرفة موقع قوائم ACL واتجاهها وأسرع طريقة للقيام بذلك هي إلقاء نظرة على مخرجات الأمر:
show Running-config
والبحث ضمن كل منفذ عن مخرجات أوامر:
ip Access-group
ومع ذلك ففي بعض الحالات التي لا يُسمح بالوصول فيها إلى وضع الامتياز وتكون أوامر show مطلوبة فيمكن استخدم الأمر:
show ip Interfaces
للعثور على قوائم ACL التي تم تمكينها على أي منافذ كما هو موضح في المثال أدناه:
لاحظ أن مخرجات الأمر تُظهر ما إذا كانت قائمة التحكم بالوصول (ACL) ممكنة على المنفذ وذلك في كلا الاتجاهين وتظهر كذلك ما هي قائمة التحكم بالوصول (ACL) المفعلة على ذلك المنفذ. يوضح المثال الجزء المختصر من الأمر:
show ip Interface S0/0/1
والذي يُظهر الرسائل الخاصة بهذا المنفذ فقط وكذلك سيدرج الأمر:
show ip Interface
نفس الرسائل لكل منفذ في جهاز التوجيه.
تنص الخطوة 2 من قائمة استكشاف أخطاء ACL وإصلاحها السابقة هي العثور على محتويات قائمة ACL. وأسرع طريقة للنظر في قائمة التحكم بالوصول (ACL) هي استخدام الأمر:
show Running-config
وإذا لم يكن متاحًا، فإن الأمرين:
show access-lists
show ip Access-lists
يسردان نفس التفاصيل الموضحة في الإعداد وتسرد هذه الأوامر أيضاً عداد مفيد يسرد عدد الحزم التي تطابقت مع كل سطر في قائمة التحكم بالوصول (ACL) ويوضح المثال أدناه ذلك.
يمكن أن يكون هذا العداد مفيد جداً لاستكشاف الأخطاء وإصلاحها فإذا كان بإمكانك إنشاء حركة مرور تعتقد أنها ستتطابق مع سطر معين في قائمة ACL فيجب أن ترى زيادة عدد المطابقات على هذا العداد إذا واصلت توليد حركة المرور المتطابقة أما إذا كان العداد هذا لا يزيد فإن تلك الحزم لا تتطابق مع هذا السطر في قائمة التحكم بالوصول (ACL) تلك وعليه فيمكن أن يكون السبب هو تتطابق هذه الحزم مع سطر سابق في نفس قائمة التحكم بالوصول (ACL) أو ربما لم تصل الحزمة إلى جهاز التوجيه هذا.
بعد الوقوف والاطلاع على المواقع والاتجاهات وتفاصيل الإعدادات الخاصة بقوائم ACL المختلفة والمشار لهم في الخطوتين 1 و 2 يبدأ الجزء الصعب والأهم والمرتبط بتحليل ما تقوم به وتفعله قائمة ACL فعلياً فعلى سبيل المثال فإحدى المهام الأكثر شيوعًا والتي يجب القيام بها هي إلقاء نظرة على حقول العناوين وتحديد نطاق العناوين المطابقة لهذا الحقل.
فبالنسبة لقائمة التحكم بالوصول (ACL) الموجودة في إعدادات جهاز التوجيه يمكن بسهولة الاطلاع على نطاق العناوين علماً بأن الحد الأدنى للنطاق هو عنوان واحد والنهاية العليا للنطاق هي مجموعة عناوين الشبكة التي يحددها قناع wildcard. على سبيل المثال مع ACL 102 في المثال السابق والذي تم إعداده بشكل واضح في بعض أجهزة التوجيه تكون النطاقات للمصدر هي:
Source: 10.1.2.0
Wildcard: 0.0.0.255
Matches from 10.1.2.0 through 10.1.2.255
بينما النطاقات للوجهة هي:
Destination: 10.1.4.0
Wildcard: 0.0.1.255
Matches from 10.1.4.0 through 10.1.5.255
مثال: أخطاء عناوين IP للمصدر/الوجهة المعكوسة
لا يمكن لنظام IOS تخمين ومعرفة ما الذي تحاول مطابقته من العناوين وعليه فهو غير قادر على تحديد ما إذا كانت خاطئة أم لا وذلك في حقل عناوين المصدر أو الوجهة. لذا من المهم الاستعداد لتحليل قوائم ACL الممكّنة واتجاهها ومقارنتها بمواقع الشبكات الفرعية المختلفة في الشبكة. ثم التساؤل عن الحزم التي تتعامل مع قائمة التحكم بالوصول (ACL) أي ما هو عنوان المصدر والوجهة لتلك الحزم؟ وهل تتطابق قائمة التحكم بالوصول (ACL) مع نطاقات العناوين الصحيحة أم لا؟
على سبيل المثال انظر الى الشكل أدناه وهو نفس الشكل الذي سيتم استخدامه في العديد من الأمثلة الخاصة باستكشاف الأخطاء وإصلاحها في هذه الورقة.
بالنسبة لقائمة التحكم بالوصول (ACL) التالية تريد تحقيق المتطلبات أدناه والتي تحوي السماح والمنع:
■ السماح للأجهزة في الشبكة الفرعية 10.3.3.0/25 والأجهزة في الشبكة الفرعية 10.1.1.0/24 بالتواصل
■ منع الأجهزة في الشبكة الفرعية 10.4.4.0/23 والأجهزة في الشبكة الفرعية 10.1.1.0/24 بالتواصل
■ السماح بجميع الاتصالات الأخرى بين الأجهزة في الشبكة 10.0.0.0
■ منع كافة الاتصالات الأخرى
يوضح المثال أدناه قائمة ACL المستخدمة في هذه الحالة على جهاز التوجيه R2. للوهلة الأولى قد تظن أنه يلبي جميع هذه المتطلبات.
المشكلة في هذه الحالة هي أنه تم تمكين قائمة التحكم بالوصول القياسية (ACL) على المنفذ G0/2 الخاص بـ R2 وذلك لحركة المرور الواردة. ووفقاً لتوصيات Cisco وللشكل يفترض أن تكون في المنفذ الأقرب من الوجهة أي أنه يفترض أن تكون في R1 وفي المنفذ G0/1 كما يفترض أن تكون لحركة البيانات الصادرة من المنفذ لذا لا تدع منطق المطابقة في قائمة التحكم بالوصول (ACL) الذي يعكس المتطلبات بشكل مثالي يخدعك وتأكد وتحقق من موقع قائمة التحكم بالوصول (ACL) والاتجاه وموقع عناوين IP.
أخطاء بنية الأمر الشائعة:
من الأخطاء النحوية الشائعة أيضاً هي عدم استخدام البرتوكول الصحيح عند كتابة عبارة ACL الموسعة ، فلمطابقة حزم TCP يجب أن تحوي عبارة ACL كلمة TCP بدلاً من IP وإلا فإن IOS لا ينفذ الأمر بالشكل الصحيح لأن بناء الجملة غير صحيح ونفس المشكلة تحدث عند محاولة مطابقة حزم UDP وكتابة بروتوكول آخر. ولمطابقة حزم ICMP يجب استخدام الكلمة icmp في عبارة ACL لاستخدامها بدلاً من tcp أو udp.
أخطاء تصفية حزم بروتوكولات التوجيه الواردة
يتجاوز ويهمل جهاز التوجيه مطابقة لائحة ACL للحزم الصادرة منه إذا كان هو من أنشأها وقد يبدو هذا المنطق سليم ولكنه قد يبدو غريباً في نفس الوقت ففي الواقع يمكن أن يحتوي جهاز التوجيه على قائمة ACL يتم تنفيذها على الحزم الصادرة منه وقد تقوم قائمة التحكم بالوصول (ACL) هذه بمنع الحزم التي يتلقاها جهاز التوجيه من الخروج من منفذ محدد ثم يحاول إعادة توجيهها الى منفذ آخر. ولكن إذا قام جهاز التوجيه بإنشاء الحزمة مثل (رسالة بروتوكول توجيه) فإن جهاز التوجيه يتجاوز الـ ACL للحزم الصادرة، بينما لا يقوم بنفس التصرف مع الـ ACL المطبقة على الحزم الواردة فهو حينها يقوم بالتحقق من قائمة التحكم بالوصول (ACL) وأخذ جميع حزم بعين الاعتبار ومطابقتها مع قائمة التحكم بالوصول (ACL) بما في ذلك الحزم المهمة مثل رسائل تحديثات بروتوكول التوجيه.
على سبيل المثال لنفترض قائمة ACL جيدة ومفعلة على جهاز التوجيه مثل Step3G في المثال أدناه بحيث تُظهر قائمة التحكم بالوصول (ACL) بضعة أوامر سماح ويوجد الرفض الضمني الافتراضي في نهاية القائمة. عند النظرة الأولى تبدو مثل أي ACL منطقي آخر
انظر الآن إلى الموقع والاتجاه (الحزم الواردة إلى R1 على المنفذ G0/2) وتأمل في هذا الموقع آخذاً في عين الاعتبار بنية الشبكة في الشكل السابق للشبكة. لا تتطابق أي من عبارات السماح هذه مع تحديثات RIP التي أرسلها R2 والتي تم إرسالها من منفذ G0/1 الخاص بـ R2 إلى R1. تستخدم رسائل RIP بروتوكول UDP (عبر المنفذ المعروف 520)، والمنفذ G0/1 الخاص بـ R2 هو 10.2.2.2 بحسب الشكل. سيطابق R1 رسائل RIP الواردة مع الرفض الضمني الافتراضي للجميع في نهاية القائمة. الوضع في هذه الحالة هو أن R1 لن يتعلم المسارات من R2 بينما سيستمر R2 في تعلم مسارات RIP من R1.
من بين بروتوكولات التوجيه الثلاثة RIPv2 و OSPFوEIGRP يستخدم RIPv2 البروتوكول UDP كبروتوكول نقل في حين أن OSPF وEIGRP لا يستخدمان أي بروتوكول نقل. وكنتيجة لذلك ولمطابقة حزم RIPv2 مع قائمة ACL فيجب استخدام الكلمة udp في عبارات أوامر ACL ويجب كذلك مطابقة المنفذ 520 ، ويمكن مطابقة OSPF وEIGRP بكلمات أساسية خاصة لهما كما هو موضح في الجدول أدناه ويظهر الجدول كذلك العناوين التي يستخدمها كل بروتوكول.
يوضح المثال أدناه نموذج لقائمة التحكم بالوصول (ACL) بثلاثة أسطر أحدها لمطابقة كل بروتوكولات التوجيه وذلك فقط لإظهار بنية الجملة ولاحظ أنه في هذه الحالة تقوم قائمة التحكم بالوصول (ACL) بمطابقة حقول العناوين مع الكلمة الأساسية any ويمكن تضمين أسطر مثل هذه في أي قائمة تحكم بالوصول (ACL) واردة للتأكد من السماح بحزم بروتوكول التوجيه.
تفاعل الـ ACL مع الحزم التي ينشئها جهاز التوجيه نفسه
يتجاوز جهاز التوجيه الـ ACL للحزم الصادرة منه والتي تم إنشاؤها بواسطته. معرفة وفهم ذلك يساعد في تجنب الحالات التي يتجاهل فيها جهاز التوجيه حركة المرور الخاصة به وينطبق هذا المنطق على الحزم التي ينشئها جهاز التوجيه مثل رسائل تحديثات بروتوكولات التوجيه وكذلك الأوامر مثل ping وtraceroute. يضيف هذا القسم بعض وجهات النظر حول كيفية تأثير قوائم ACL على استكشاف الأخطاء وإصلاحها وكيفية تطبيق هذا الاستثناء لمنطق ACL للحزم الصادرة منه وخاصة الأوامر المستخدمة من واجهة سطر الأوامر (CLI) لجهاز التوجيه.
قوائم ACL المحلية وPing من جهاز التوجيه
بالنسبة للسيناريو الأول فكر في أمر ping والصادر من جهاز التوجيه بحيث يقوم الأمر بإنشاء حزم ويقوم جهاز التوجيه بإرسال تلك الحزم (محتفظًا برسائل ICMP echo) الى إحد منافذ جهاز التوجيه وعادةً ما يتم استلام بعض رسائل ICMP echo reply. وكما تبين لن تحاول قوائم ACL تصفية تلك الحزم
ولمناقشة ما يحدث يوضح الشكل أدناه بنية شبكة بسيطة بها جهازي توجيه متصلين بارتباط تسلسلي. لاحظ أنه في هذا الشكل توجد أربع لوائح ACL تسمى A وB وC وD، كما هو موضح بالأسهم في الرسم. وهذا يعني أن A هي قائمة ACL للخارج من S0/0/0 والخاص بـ R1، و Bهي قائمة ACL للوارد إلى S0/0/1 والخاص بـ R2، وهكذا.
على سبيل المثال ضع في اعتبارك أمر ping والصادر من واجهة سطر الأوامر (CLI) والخاصة بـ R1 (وذلك بعد أن يتصل المستخدم بواجهة سطر الأوامر (CLI) الخاصة بـ R1 باستخدام SSH). يقوم أمر ping باختبار عنوان IP الخاص بالخادم S1. فتتدفق حزم IPv4 مع رسائل ICMP من R1 إلى S1 وتعود مرة أخرى. أي من قوائم ACL الأربعة هذه يمكن أن يقوم بتصفية طلب ICMP echo باتجاه S1 وكذلك تصفية ICMP echo reply مرة أخرى باتجاه R1؟
تتجاوز أجهزة التوجيه قوائم ACL للحزم الصادرة منها والتي تم إنشاؤها بواسطة جهاز التوجيه نفسه كما هو موضح في الشكل أدناه وذلك على الرغم من وجود قائمة A كقائمة ACL للحزم الصادرة من جهاز التوجيه R1 إلا أن R1 يتجاوز الـ ACL للحزم الصادرة منه الخاص بـ A لطلبات صدى ICMP التي تم إنشاؤها بواسطة R1.
اختبار الـ (Self-Ping) لجهاز التوجيه لعنوان IPv4 للمنفذ التسلسلي
في المثال السابق تم استخدام الأمر ping الخاص بجهاز التوجيه عند إجراء اختبار ping على جهاز وكان الجهاز S1. إلا أننا غالبًا ما نحتاج إلى اختبار اتصال عناوين IP لجهاز التوجيه بما في ذلك استخدام اختبار الاتصال الذاتي (Self-Ping) ويشير مصطلح اختبار الاتصال الذاتي إلى اختبار اتصال عنوان IPv4 الخاص بالجهاز. وبالنسبة للارتباطات التسلسلية من نقطة إلى نقطة يرسل اختبار الاتصال الذاتي بالفعل حزمًا عبر الارتباط التسلسلي مما يسبب بعض التأثيرات المهمة مع قوائم التحكم في الوصول (ACL).
فعندما يرسل مستخدم اختبار اتصال ذاتي لعنوان IP التسلسلي لجهاز التوجيه المحلي يرسل جهاز التوجيه هذا فعلياً طلب ICMP echo عبر الرابط إلى جهاز التوجيه الآخر. ويقوم الجهاز الآخر بعد ذلك باستلام الحزمة وتوجيهها باستخدام طلب ICMP echo مرة أخرى إلى جهاز التوجيه الأصلي. يوضح الشكل الفكرة ومثالاً على اختبار الاتصال الذاتي (ping 172.16.4.1) لعنوان IP الخاص بجهاز التوجيه R1 على رابط تسلسلي من نقطة إلى نقطة. ففي الخطوة 2 يعامل R2 الحزمة مثل أي حزمة أخرى غير مخصصة لأحد عناوين منافذه الخاصة به بحيث يقوم R2 بتوجيه الحزمة. لتعود مباشرة إلى جهاز التوجيه R1 كما هو موضح في الشكل
فكر الآن في قوائم ACL الأربعة المذكورة في المثال الأسبق وقارنها بالشكل السابق سيقوم R1 بإنشاء طلب ICMP echo ، لذا فإن R1 يتجاوز A الصادرة. ويمكن لقوائم B وC وD أن تقوم بتصفية الحزمة. لاحظ هنا أن الحزمة التي أرسلها R2 مرة أخرى إلى R1 لم يتم إنشاؤها بواسطة R2 وإنما يقوم R2 فقط بتوجيه الحزمة الأصلية إلى R1.
يقوم الـ Self-Ping للمنفذ التسلسلي باختبار أجزاء كثيرة كما يلي:
■ يجب أن يعمل المنفذ في الطبقات 1 و2 و3. وعلى وجه التحديد يجب أن يكون لدى كلا الموجهين منفذ تسلسلي يعمل (up/up) مع إعداد عناوين IPv4 صحيحة.
■ يجب أن تسمح قوائم B وC وD بطلب ICMP echo وكذلك ICMP echo reply.
لذا، عند استكشاف الأخطاء وإصلاحها وعند استخدام اختبارات Self-Ping وفشلها بينما المنافذ التسلسلي في حالة up/up، فلا تنس التحقق من كون قوائم ACL قد قامت بتصفية حركة بروتوكول (ICMP).
اختبار الـ (Self-Ping) لجهاز التوجيه لعنوان IPv4 لمنفذ Ethernet
يعمل اختبار Self-Ping لعنوان IP لمنفذ Ethernet الخاص بجهاز التوجيه بشكل يشبه إلى حد ما اختبار Self-Ping لعنوان IP التسلسلي لجهاز التوجيه ولكن مع بعض التغييرات:
■ كما هو الحال مع المنافذ التسلسلية يجب أن يعمل منفذ جهاز التوجيه المحلي (في حالة up/up)؛ وإلا سيفشل الأمر ping.
■ على عكس المنافذ التسلسلية لا يقوم جهاز التوجيه بإعادة توجيه رسائل ICMP echo فعلياً إلى خارج المنفذ لذا لا يمكن لميزات الأمان الموجودة على المبدلات المجاورة (مثل port security) أو أجهزة التوجيه (مثل قوائم ACL) تصفية الرسائل المستخدمة بواسطة أمر ping.
■ كما هو الحال مع المنافذ التسلسلية تقوم قائمة ACL للحزم الواردة على جهاز التوجيه المحلي بمعالجة اختبار Self-Ping لجهاز التوجيه لعنوان IP المستند إلى Ethernet.
يوضح الشكل أدناه أحد الأمثلة. ففي هذه الحالة يصدر R2 أمر ping 172.16.2.2 لإجراء اختبار الاتصال بعنوان الـ IP على المنفذ G0/2 الخاص به. تمامًا كما هو الحال مع اختبار Self-Ping على الارتباطات التسلسلية ويقوم R2 بإنشاء طلب ICMP echo. ومع ذلك يقوم R2 بشكل أساسي بمعالجة اختبار الاتصال (ping) عن طريق الـ TCP/IP الخاص به ثم إجراء نسخ احتياطي مرة أخرى وذلك مع عدم مغادرة ICMP echo مطلقاً لمنفذ Ethernet الخاص بالموجه. يقوم R2 بالتحقق من حالة منفذ Ethernet، مما يوضح الفشل إذا لم تكن الواجهة up/up. لا يطبق R2 منطق ACL على الحزمة الصادرة لأن R2 قام بإنشائها لكن R2 سيطبق منطق ACL على الحزم الواردة كما لو تم استلام الحزمة فعليًا على المنفذ.
