# 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.