قبل اختبار eJPT: افهم مسار الاتصال عشان ما تضيع في الـ Pivoting

تشغّل الأداة، تنتظر، وبالأخير يطلع لك Timeout. تغيّر الأداة وتعيد، والنتيجة نفسها. في لابات اختبار الاختراق، المشكلة أحيانًا أبسط من الثغرة اللي تدور عليها: جهازك أصلًا ما عنده طريق يوصل للخدمة. هنا فهم الشبكة يوفر عليك أكثر من حفظ أمر جديد.

ارسم الاتصال من جهازك إلى الخدمة

خلنا نفترض لاب تملكه فيه جهاز تدريب وبوابة وجهاز داخلي. لا تبدأ بكلمة «الشبكة شغالة». اسأل: من وين يبدأ الطلب؟ وش عنوان المصدر؟ أي واجهة بيطلع منها؟ ووين المفروض يرجع الرد؟
نجاح اتصال الجهاز الوسيط بالهدف ما يعني إن جهازك يقدر يتصل به مباشرة. وبرضه وصولك لمنفذ واحد ما يثبت وصول كل المنافذ. اكتب المسار الخاص بالخدمة اللي تختبرها، حتى لو كان بس ثلاثة أسماء وأسهم في دفتر ملاحظاتك.

اقرأ جدول التوجيه قبل تغيّره

على جهاز لينكس في اللاب، هذان أمران للقراءة:
ip route show
ip route get 192.0.2.20
العنوان هنا مثال توثيقي؛ بدّله بعنوان جهازك التدريبي المصرح. الأمر الأول يعرض المسارات، والثاني يوضح قرار التوجيه لوجهة محددة، مثل الواجهة وعنوان المصدر والبوابة إن وجدت. ما يثبت أن الوجهة ردّت أو أن المنفذ مفتوح.
لاحظ الفرق بين «النظام اختار طريقًا» و«الاتصال نجح». إذا الطريق يطلع من واجهة غير متوقعة، حل هالسؤال أول. لا تضيف مسارات عشوائية لأن شرحًا في الإنترنت سواها؛ ممكن تكسر اتصالك أو ترسل الحركة إلى جهة غلط.

لا تخلط مشكلة الاسم مع مشكلة الطريق

لو الاتصال بالعنوان يعمل وبالاسم يفشل، ابدأ بمراجعة ترجمة الاسم. على لينكس تقدر تستعلم عن الاسم بحسب إعدادات النظام:
getent hosts server.lab.test
هنا الاسم افتراضي للاب. النتيجة توضح العناوين اللي حلّها النظام، وقد تأتي من مصادر مثل ملف hosts أو DNS بحسب الإعداد. ما هي دليل أن خادم DNS بعينه رد عليك.
وفي تطبيقات تعتمد على اسم الخدمة، استخدام العنوان بدل الاسم قد يغيّر سلوك المصادقة أو اختيار الموقع. لذلك دوّن الاثنين؛ لا تعتبر نجاح تجربة بالعنوان حكمًا نهائيًا على تجربة الاسم.

وش الفرق بين Route وPort Forward؟

المسار يحدد كيف تتجه حركة الشبكة إلى وجهة أو شبكة. تحويل المنفذ يربط نقطة اتصال بخدمة أخرى وفق إعداد محدد. وجود تحويل لخدمة ويب ما يحول الجهاز الداخلي كله إلى جهاز متاح لك.
في التدريب، اختبر خدمة واحدة معروفة قبل توسّع التجربة. راجع اتجاه التحويل والجهة اللي تستمع، ثم تحقق من وصول الطلب والرد. الأهم تعرف حدود اللي بنيته؛ لا تفسر فشل بروتوكول مختلف على أنه خلل في الهدف.

تمرين يكشف فهمك بسرعة

جهّز خدمة بسيطة في لاب معزول، واكتب توقعك لمسار الاتصال قبل تشغيلها. بعدها غيّر إعدادًا واحدًا في بيئتك، مثل الاسم المستخدم، وقارن النتيجة. احتفظ بسجل: المتوقع، اللي حصل، والتفسير.
إذا تقدر تشرح الفشل بدون عبارة «الأداة خربانة»، فأنت جاهز تستفيد من تدريب الـ Pivoting بشكل أفضل.
مرجع أوامر لينكس:
https://man7.org/linux/man-pages/man8/ip-route.8.html
https://man7.org/linux/man-pages/man1/getent.1.html