+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Редко отсутствие ответа на TCP SYN (сообщение журнала syn flood)

Редко отсутствие ответа на TCP SYN (сообщение журнала syn flood), RouterOS

Zaesch

Guest

27.12.2024 19:07:00

Привет, у меня уже пару часов проблема: Mikrotik (x86) иногда не отвечает на TCP SYN. Я вижу, что TCP SYN приходят через сниффер пакетов, но на любом интерфейсе нет никакого ответа. Иногда всё работает нормально, через секунды перестаёт. ICMP Echo-запросы отвечаются без проблем и без потерь пакетов. Перед этим не было никаких изменений в конфигурации. Версия софта 7.16.2, я пробовал откатиться на 7.15 — поведение одинаковое. От отчаяния попытался запустить ту же конфигурацию на CCR2004-16G-2S+ — та же история. Даже с отключенными или полностью удалёнными правилами фаервола. Есть идеи?

mark7477

Guest

23.01.2025 16:49:00

Думаю, я наблюдаю похожее поведение, о котором писал в своём посте здесь — http://forum.mikrotik.com/t/ovpn-intermittently-does-not-respond-to-tcp-syn-from-ovpn-clients/181422/1. Прихожу к выводу, что часть с OVPN в моей проблеме не имеет значения, если TCP-хэндшейк ещё не завершён. Если у тебя есть какие-то новые знания по своей проблеме, буду рад услышать любые обновления.

Zaesch

Guest

25.01.2025 10:38:00

Обновился до версии 7.17 прошлой ночью и снова столкнулся с той же проблемой. На этот раз кое-что понял: в логе после каждой перезагрузки появляется сообщение «possible SYN flooding on tcp port …». Есть устройство, которое отправляет намного больше tcp SYN-пакетов, чем обычно. Забавно, что это устройство Mikrotik, и, к сожалению, оно не находится под моим контролем. Я поставил правило в фаерволе, чтобы блокировать это устройство по tcp. Для остальных устройств ничего не изменилось. На их tcp SYN-пакеты не отвечается.

Следующий шаг: перезагрузка, сообщение в логе больше не появляется, и остальные устройства снова могут подключаться. Я бы это не назвал флудом, потому что устройство отправляет всего 5–10 tcp SYN-пакетов в секунду. Не очень приятно, но и не катастрофа — и, конечно, нет смысла блокировать весь tcp SYN-трафик. При том, что эти TCP SYN-пакеты легитимны, и если мое устройство ответит на первые из них, больше их не будет.

Итак, мое устройство снова доступно и стабильно (кроме “флудера”). Вопрос: почему мое устройство после «атаки» блокирует все tcp SYN? Ведь нет никакого правила блокировки флуда или чего-то подобного.

BartoszP

Guest

25.01.2025 13:48:00

http://forum.mikrotik.com/t/mikrotik-syn-cookie-protection/144747/1 Проверьте IP/Settings/TCP SynCookies. Отправляйте syn cookies, когда очередь syn backlog для сокета переполняется. Это сделано для защиты от распространённой «SYN flood атаки». Syncookies серьёзно нарушают TCP-протокол, не позволяют использовать TCP-расширения и могут привести к серьёзному ухудшению работы некоторых сервисов (например, SMTP-релэев), что станет заметно не вам, а вашим клиентам и реле, которые обращаются к вам.

Zaesch

Guest

25.01.2025 14:40:00

SYN cookies отключены. Их активация ничего не меняет. Появляется сообщение в логе о SYN flood, и все остальные TCP SYN больше не получают ответа. При этом, несмотря на активацию этой функции, возможно появление других проблем.

Zaesch

Guest

25.01.2025 14:46:00

Думаю, проблема в том, что эти TCP SYN-пакеты вполне легитимны, но по какой-то причине мой роутер решает не отвечать на (все) из них. В итоге получается куча повторных передач, и срабатывает механизм защиты от SYN-флудов. Думаю, это баг, но Mikrotik не отвечает на заявку в поддержку с 27 декабря.

Zaesch Guest	#7 0 06.02.2025 14:32:00 Хорошо. Я понял, как получить стабильную систему, но с маршрутизацией (routing marks) в ROS 7 что-то ужасно сломано. Подозреваю похожую проблему, как здесь описано: http://forum.mikrotik.com/t/how-to-use-ping-with-multiple-routing-marks-in-ros-version-7/175887/12. Существует разрыв между конфигурацией в Winbox и реальной (CLI-конфигурацией): в Winbox все маршруты выглядят нормально. Но при выполнении /ip route export появляются дополнительные записи: distance=1 routing-table=main scope=30 suppress-hw-offload=no target-scope=10. Обычно экспорт статического маршрута на моих устройствах выглядит так: /ip route add comment="important route" disabled=no dst-address=10.0.0.0/24 gateway=10.1.1.1 Никаких признаков distance, routing-table или других опций. Я не понимаю, в чем именно проблема с VRF и routing marks. У меня всего один VRF (main), остальные опции стоят по умолчанию, но если их задать через CLI — происходят странные вещи. В двух словах: я удалил все маршруты и заменил их «короткой» версией, и теперь всё работает нормально. После перезагрузки проблем нет. За исключением сообщения о TCP SYN flood, но это просто информация — всё работает без сбоев. В Winbox маршруты выглядят точно так же, как и раньше. Мой совет: сделайте экспорт таблицы маршрутизации, если что-то идет не так.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры