Ответ на вопрос
Кратко — что означает симптом: серия TCP-пакетов с повторяющимися SYN и отсутствием ACK означает, что инициатор (клиент) многократно посылает SYN, но TCP-трехстороннее рукопожатие не завершается (нет финального ACK). Возможные причины, как проверить и что делать.
1) Возможные причины
- Сеть / маршрутизация:
- Сервер отправляет SYN‑ACK, но он теряется/фильтруется на пути к клиенту (асимметричная маршрутизация, ACL, stateful‑файрвол).
- NAT/CGN или балансировщик переписывает/терминирует соединения неправильно.
- Атака (SYN flood / spoofing):
- Большое число SYN с поддельными IP → сервер отвечает SYN‑ACK, ACK не приходит.
- Сбой/ошибка клиента:
- Клиент не получает SYN‑ACK (локальная сетевая проблема) или клиентское приложение/стек падает и не отправляет ACK; клиент повторно посылает SYN (обычный тайм‑ауt + ретрансляции).
- Локальные проблемы на сервере:
- Переполнен SYN‑backlog, соединения не обрабатываются, сетевой стек ведёт повторные ответы.
- Сетевые оффлоады/ошибки захвата:
- При анализе на хосте offload может показывать некорректные контрольные суммы / пакеты, отличие от реального трафика.
2) Как подтвердить диагноз (пошагово, с приоритетом)
- Захват трафика с обеих концов и/или на промежуточных устройствах:
- На сервере: tcpdump/wireshark и фильтр на SYN без ACK (пример): tcpdump -n -s0 -w srv.pcap 'tcp[tcpflags] & (tcp-syn) != 0 and tcp[tcpflags] & (tcp-ack) == 0'.
- На клиенте: аналогичный захват. Сравнить: видит ли клиент SYN‑ACK от сервера? видит ли сервер финальный ACK?
- Сравнить захваты:
- Если сервер видит SYN и отправляет SYN‑ACK, но клиент не видит SYN‑ACK → проблема в пути server→client (файрвол/асимметрия/NAT).
- Если клиент посылает SYN, но сервер не отвечает → проблема server←client или порт закрыт.
- Если много SYN с поддельных IP и сервер отвечает, но ACK не возвращается → вероятный SYN‑flood (spoofing).
- Анализ полей IP/TCP:
- TTL и IPID: постоянные/ожидаемые изменения у реального хоста; сильно различающиеся TTL/IPID в группе пакетов указывают на распределённый источник/спуфинг.
- MAC‑адреса в LAN‑захватах (покажут, кто реально передавал).
- Sequence/ISN одинаковы при ретрансмиссиях (обычный клиент) или различаются (скрытый ботнет/спуфинг).
- Проверить метрики стека и таблицы:
- netstat/ss: смотреть SYN_RECV, backlog.
- conntrack (если используется NAT): количество состояний и таймауты.
- Логи firewall/load‑balancer.
- Диагностические утилиты:
- hping3 для имитации SYN и проверки ответов (поможет понять, приходит ли SYN‑ACK до клиента).
- traceroute/mtr/tcptraceroute для поиска проблем на пути.
- Убедиться, что захват корректен:
- Отключить checksum offload при покапчe: ethtool -K eth0 gro off gso off tso off, чтобы увидеть истинные контрольные суммы в захвате.
- Оценка объёма:
- Если много уникальных источников и высокая скорость → вероятно DDoS; если один/несколько стабильных IP → скорее баг/конфигурация.
3) Инструменты и команды (коротко)
- tcpdump, tshark, Wireshark — анализ pcap и TCP‑флагов.
- ss / netstat — состояние TCP и backlog.
- conntrack-tools — состояние NAT/conntrack.
- hping3, nping — генерация SYN и тест ответов.
- traceroute/tcptraceroute/mtr — путь и потери.
- iperf — проверка пропускной способности (если нужно).
- iptables/nftables, nft‑limit, xt_SYNPROXY, fail2ban — защита и rate‑limit.
- DDoS‑protection (в облаке) или аппаратные фильтры.
4) Что предпринять для устранения и защиты
- Если подтверждён SYN‑flood (spoofing):
- Включить SYN cookies: sysctl -w net.ipv4.tcp_syncookies=1.
- Увеличить backlog: sysctl -w net.ipv4.tcp_max_syn_backlog=\(1024\) (подберите значение по нагрузке).
- Применить rate‑limit / SYN proxy (nftables/iptables recent/hashlimit, xt_SYNPROXY, или балансировщик с SYN‑proxy).
- Включить облачную/оператора защиту от DDoS.
- Если проблема в пути server→client (фильтрация):
- Проверить и исправить ACL/файрволы/маршрутизаторы по пути; проверить NAT/SNAT правила и ассоциированность назад.
- Захватить трафик на промежуточных устройствах, согласовать с провайдером.
- Если проблема на клиенте:
- Снять захват на клиенте, проверить стек, логи приложения; воспроизвести с hping3 и проследить.
- Если проблема на сервере (переполнение очередей):
- Увеличить backlog, оптимизировать приложение, горизонтальное масштабирование (LB).
- Включить мониторинг (метрики SYN_RECV, сокетов) и алерты.
- Если подозрение на offload/скаффолдинг при анализе:
- Отключить сетевые offload‑опции при захвате, повторить анализ.
5) Краткая диагностическая последовательность (практическая)
- Захват с сервера и клиента одновременно.
- Сравнить: видит ли клиент SYN‑ACK? если нет → искать проблему на пути/файрвол; если да → сервер не получает ACK → возможно NAT/AS‑issues.
- Проверить логи/ss/conntrack, включить SYN cookies при необходимости, настроить rate‑limit.
- Применить hping3 и traceroute для воспроизведения и локализации.
Если нужно, могу дать конкретные команды tcpdump/wireshark‑фильтры, sysctl‑настройки и примеры анализа pcap по образцу вашего захвата.
Еще