# Production276 — включение SYN cookies на arn-gw01 (2026-10-16)

Владелец явно разрешил: «Включить tcp-syncookies и проверить».
Исходная диагностика: [Production275](PRODUCTION-ARN-275.md).

## Применение

Перед записью проверены server ID1/host `arn-gw01.rtnt.top` и исходное
`tcp-syncookies=false`. Первая попытка PATCH `/ip/settings` была отклонена400
`missing or invalid resource identifier`; значение после отказа осталосьfalse.
Этот singleton-раздел изменяется командой POST `/ip/settings/set`.

Выполнена ровно одна успешная команда с единственным параметром
`{"tcp-syncookies":"true"}`. Подтверждение в02:55:01.749 UTC,
повторное чтение02:55:01.893 UTC —true и корректная identity.
Местное время: **2026-10-16 09:55:01 по Новосибирску**.

Пароли, пользователи, firewall, порты, маршруты, приложение, БД и контейнеры
не менялись; перезапуск не выполнялся. Уточнение протокола PATCH→POST не расширяет
согласованный scope и не меняет дополнительные параметры.

## Метод проверки

С тем же production-хостом, адресом устройства, учётной записью и проверкой TLS
повторяются GET system/identity с новым TCP/TLS, последовательно, без повторов
при ошибке. Один запрос каждые4 секунды,8 измерений. Отдельно захват45 секунд
только SYN/SYN-ACK на eth0, фильтр строго target IPv4/TCP443, без сохранения payload.
Проверяются результат чтения настройки, uptime и штатные задания scheduler.

## Контрольные запросы после изменения

С02:55:24 по02:55:53 UTC выполнены8 измерений. Все HTTP200, без повторов.

| Замер | DNS | TCP установлен | TLS завершён | Заголовки ответа | Всего |
| --- | --- | --- | --- | --- | --- |
| 1 | 6 | 25 | 138 | 158 | 159 |
| 2 | 9 | 29 | 137 | 158 | 158 |
| 3 | 3 | 22 | 125 | 144 | 145 |
| 4 | 3 | 22 | 123 | 143 | 143 |
| 5 | 3 | 25 | 130 | 152 | 152 |
| 6 | 2 | 22 | 126 | 168 | 169 |
| 7 | 2 | 21 | 126 | 145 | 145 |
| 8 | 2 | 45 | 313 | 334 | 334 |

Все значения — накопленные миллисекунды от начала запроса. Диапазон полного
запроса143–334мс против1162–5274мс в четырёх исходных измерениях; TCP21–45мс
против1042–5136мс. Настройка повторноtrue, uptime12m42s/CPU14% в замере02:55:54.

В повторном45-секундном захвате42 SYN/SYN-ACK пакета (44 received by filter,
0 dropped by kernel), повторов SYN с тем же исходным портом/sequence в полученном
выводе не обнаружено. Запись payload не выполнялась. Захват завершился по timeout,
фонового процесса захвата после него нет. Это короткая выборка, а не гарантия
отсутствия сетевых потерь при любой нагрузке.

На02:57:30 UTC /09:57:30 Новосибирск, через2мин29с после применения:

| Штатное задание | Успешно | Ошибки | Максимальная длительность |
| --- | --- | --- | --- |
| traffic | 5 | 0 | 1091мс |
| gre_bgp | 5 | 0 | 426мс |
| uptime_resources | 10 | 0 | 854мс |
| internet_path | 1 | 0 | 284мс |

Считались запуски с started_at после02:55:01.893 UTC. Финальный readbacktrue,
CPU6%, uptime14m19s, RouterOS7.24.5 stable — перезапуска не было. Доступное кольцо
логов04:55:53–04:57:16 по часам устройства не содержит новых SYN warning;
оно не покрывает весь интервал после изменения. Старые события не удалялись.

В коротком сравнении после включения SYN cookies многосекундная задержка TCP
не воспроизвелась, результаты существенно лучше. Это согласуется с гипотезой
проблемы обработки входящих SYN на CHR, но не устанавливает источник всех прежних
потерь и не доказывает результат под другой нагрузкой. Дополнительные изменения
не применялись. Наблюдение и захват завершены; новых фоновых циклов нет.

## Откат

При необходимости по решению владельца повторно проверить устройство и текущее
значение, выполнить POST `/ip/settings/set` с `tcp-syncookies=false`, затем чтение
`/ip/settings?.proplist=tcp-syncookies`. Автоматического отката после успешной
проверки не предусмотрено: включение разрешено явно. Другие настройки не трогать.