MikrotikManager/deploy/PRODUCTION-ARN-275.md

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 описывает SYN cookies при переполнении SYN backlog и ограничения TCP extensions. Это защита от переполнения очереди, она не устраняет потери в сети провайдера. Точный scope изменения и проверка должны быть согласованы до записи в production.