feat(mcp): подготовить сервер и доступ к приёмке

deploy/PRODUCTION-ARN-275.md

@@ -0,0 +1,83 @@
+# Production275 — SYN и задержки API arn-gw01 (2026-10-16)
+
+Поручение: исследовать предупреждения SYN flooding на80/443 и периодически
+медленный HTTPS REST на `arn-gw01.rtnt.top`. Выполнены только чтение и короткие
+диагностические подключения. Конфигурация production/RouterOS не менялась.
+
+## Результаты
+
+Устройство ID1, DNS IPv4 `62.182.194.146`, REST HTTPS443 с проверкой сертификата.
+RouterOS7.24.5 stable,1 CPU. В разовом resource: CPU6%, свободно933036032 байт
+из1207959552, uptime5m41s. Перезапуск выполнен до диагностики, не агентом.
+
+1. Первый диагностический GET system/resource завершился тайм-аутом10с.
+   Следующие чтения: system/clock2307мс, ip/settings638мс, ip/service145мс,
+   log160мс; отдельный полный resource1170мс. Неверная авторизация не наблюдалась.
+2. В первоначальном журнале41 событие: первая отметка02:43:13, оба SYN warning
+   на80/443 —02:43:20. Совпадение с uptime указывает на события первых секунд
+   запуска. Позднее часы используют Europe/Stockholm/+02:00, в журнале есть
+   скачок02:43→04:44; ранние отметки нельзя механически переводить как уже
+   синхронизированное местное время. Непрерывную SYN-атаку из этих двух записей
+   вывести нельзя. Последующее кольцо1000 записей уже не содержало предупреждений.
+3. Четыре последовательных GET system/identity с новым TCP/TLS, один за раз:
+
+   | Замер | DNS | TCP установлен | TLS завершён | Заголовки ответа | Всего |
+   | --- | --- | --- | --- | --- | --- |
+   | 1 | 6 | 1042 | 1141 | 1161 | 1162 |
+   | 2 | 2 | 3071 | 3189 | 3208 | 3208 |
+   | 3 | 3 | 3088 | 3233 | 3254 | 3254 |
+   | 4 | 2 | 5136 | 5254 | 5273 | 5274 |
+
+   Значения — накопленные миллисекунды от начала запроса. Все HTTP200;
+   после TLS до ответа19–21мс. Основная задержка находится до TCP connect.
+4. Захват только SYN/SYN-ACK заголовков на eth0 production-хоста,20с,
+   фильтр строго target IPv4/TCP443. Полезная нагрузка не сохранялась.
+   Два наших контрольных GET прошли155/149мс; SYN-ACK через18–21мс.
+   Затем в обычном опросе приложения зафиксированы повторения исходящих SYN:
+   один исходный порт — первое SYN1792119069.651615, SYN-ACK1792119073.773299
+   (4.122с, несколько повторов); другой —1792119069.713556→1792119071.757179
+   (2.044с). При полученном ответе на SYN RTT около18мс. Захват16 пакетов,
+   dropped by kernel0, завершён автоматически через timeout20s.
+5. В02:52:33 UTC (09:52:33 Новосибирск) среди239 TCP conntrack записей4 к
+   локальным80/443: time-wait1/syn-sent2/syn-recv1. Две от приложения,
+   две с других внешних адресов — по одной80 и443. Массовый текущий SYN flood
+   этим одиночным снимком не подтверждён. В этой версии адрес и порт — отдельные
+   поля; для итогового подсчёта использованы dst-address **и** dst-port.
+6. tcp-syncookies=false. www80/www-ssl443/reverse-proxy443 включены,
+   max-sessions20; FTP/Telnet/SSH уже выключены. В input есть блокировка EVOFW_DENY,
+   drop UDP53 и accept WireGuard; отдельных ограничений80/443 доверенными
+   источниками и завершающего drop input в прочитанных правилах нет. RAW пустой.
+   Правила не менялись; обратный прокси потенциально использует те же порты,
+   поэтому закрывать их без проверки потребителей нельзя.
+7. Scheduler20минут на02:49 UTC: traffic4 error/36 ok, gre_bgp4 error/36 ok.
+   Выборка последних ошибок называет arn и тайм-аут10с; последние в02:43:49–50 UTC,
+   рядом с запуском устройства. Успешные задания иногда занимают9–11с суммарно.
+   Это не доказательство медленного SQL или обработки REST на RouterOS.
+
+## Вывод
+
+Воспроизведены задержки TCP-handshake и повторные SYN **до** TLS/REST.
+Разовые низкие CPU и conntrack не показывают постоянного истощения ресурсов.
+Причину нужно различать между сетью/фильтрацией по пути и обработкой SYN на CHR;
+захват только на отправителе не определяет точное место потери. Историческое
+предупреждение при запуске само по себе не доказывает текущую DDoS-атаку.
+
+Приложение сейчас создаёт новые соединения (keepAlive=false, maxSockets2 на origin).
+Это увеличивает количество TCP/TLS-handshake, но не доказывает, что приложение
+создаёт SYN flood. Менять поведение пула вслепую нельзя: прежние проверки273 касались
+также отказов входа. Повышение API timeout лишь скроет часть проявлений.
+
+## Подготовленный следующий шаг
+
+После отдельного разрешения владельца проверить ID1/host и исходный
+tcp-syncookies=false, изменить **только** `/ip/settings tcp-syncookies=true`
+через REST PATCH. Без перезагрузки, изменения паролей, служб, правил firewall
+и маршрутов. Повторно прочитать значение, повторить небольшой последовательный
+замер TCP/TLS/HTTP и сверить штатные опросы. Откат — вернуть исходное false после
+решения владельца; не объявлять положительный краткий замер доказательством
+устранения причины. Это пока предложение, изменение не применялось.
+
+[IP Settings MikroTik](https://help.mikrotik.com/docs/spaces/ROS/pages/103841817/IP%2BSettings)
+описывает SYN cookies при переполнении SYN backlog и ограничения TCP extensions.
+Это защита от переполнения очереди, она не устраняет потери в сети провайдера.
+Точный scope изменения и проверка должны быть согласованы до записи в production.