Кратко: клиент отправил SYN, сервер ответил SYN‑ACK, но со стороны клиента соединение не переходит в ESTABLISHED. Возможные причины и шаги отладки.
Возможные причины
- Сеть
- потеря/фильтрация ACK по пути (firewall/NAT/load‑balancer/ACL) — асимметричная маршрутизация; middlebox «теряет» или модифицирует пакет;
- NAT / stateful firewall не пропускает завершающий ACK (или переписывает SEQ/ACK);
- ICMP/PMTU/MTU/фрагментация нарушает доставку (особенно при опциях TCP);
- ARP/маршрутизация на промежуточном устройстве; трассировка возвращающего пути;
- L4‑шардинг/прокси (load‑balancer) отвечает за SYN‑ACK, но не перенаправляет ACK в бэкенд;
- сетевые устройства сбрасывают по политике (rate‑limit SYN/ACK) или DOS‑защита.
- ОС/стек TCP (клиент или сервер)
- переполнение SYN backlog на сервере (сервер отвечает SYN‑ACK но не помещает socket в accept queue);
- включены/исключены TCP syncookies — поведение при переполнении;
- локальный firewall (iptables/nftables) блокирует исходящий ACK;
- reverse path filtering (`rp_filter`) или неверные маршруты;
- offloading (checksum/GSO/TSO) и tcpdump показывает «поврежденные» пакеты — видимость проблемы;
- ограничения conntrack / количество состояний в netfilter;
- системные лимиты / недоступные ресурсы (memory, filedescriptors).
- Приложение
- сервер не вызывает accept() / принимает медленно → accept queue заполняется;
- приложение слушает на другом интерфейсе/протоколе (только IPv6, не IPv4) или на другом порту;
- процесс аварийно завершается после отправки SYN‑ACK;
- неправильные socket‑опции (bind на конкретный IP, SO_LINGER и т.п.);
- баг в приложении/библиотеке, приводящий к неправильной обработке подключений.
Шаги отладки (порядок и конкретика)
1) Снимки трафика (tcpdump)
- Запишите трафик одновременно на клиенте и на сервере (и на ближайших роутерах/балансировщиках, если можно).
- Пример фильтра (на интерфейсе):
sudo tcpdump -i eth0 -n -s 0 -vvv 'tcp and host CLIENT_IP and host SERVER_IP and port PORT'
- Что смотреть:
- клиент → сервер: SYN;
- сервер → клиент: SYN‑ACK (количество и интервалы retransmits);
- клиент → сервер: ACK (последний шаг 3‑way).
- Интерпретация:
- если SYN‑ACK не виден на сервере: сервер не получил SYN — проблема исходного трафика/маршрутизации;
- если сервер видит SYN и отправляет SYN‑ACK, но клиент не получает SYN‑ACK — сетевой путь/маршрутизация/NAT;
- если клиент получает SYN‑ACK, но tcpdump на клиенте не показывает исходящий ACK — клиент/OS/iptables/stack блокирует или не отправляет ACK;
- учтите offload: tcpdump на хосте может показывать «bad checksum» — для отладки временно отключите checksum/GSO/TSO.
2) Посмотреть состояния сокетов (ss / netstat)
- найти сокеты в состоянии ожидания/handshake:
- ss -nt state syn‑sent (на клиенте)
- ss -nt state syn‑recv (на сервере)
- ss -antp | grep PORT — показать PID/программу, прослушивание и состояния
- netstat эквиваленты: netstat -antp
- ss -s — краткая статистика (количество установленных/ожид. соединений).
- Если на сервере много SYN_RECV → backlog переполнен; проверить /proc/net/tcp и sysctl `net.ipv4.tcp_max_syn_backlog`.
3) Проверить процесс/приложение
- lsof -iTCP -sTCP:LISTEN -P -n — увидеть процесс, порт, fd.
- ss -lpn | grep PID — убедиться, что процесс действительно слушает на нужном адресе.
- Проверить, что приложение вызывает accept() и не зависает; посмотреть загрузку CPU/IO, количество открытых FD (ulimit -n).
- Если слушает только на ::1 / :: вместо 0.0.0.0 — возможно только IPv6.
4) Проверить firewall / conntrack / kernel
- iptables -L -v -n / nft list ruleset — нет ли правил, блокирующих ACK;
- conntrack -L | grep SERVER_IP (если используется conntrack) — нет ли лимитов;
- sysctl-параметры: посмотреть `net.ipv4.tcp_syncookies`, `net.ipv4.tcp_max_syn_backlog`, `net.netfilter.nf_conntrack_max`, `net.ipv4.conf.*.rp_filter`.
- dmesg / journalctl -k — системные сообщения о сетевых проблемах.
5) Диагностика offload / checksum / tcpdump артефакты
- при подозрении на checksum‑offload: отключить offload для интерфейса (для дебага): ethtool -K eth0 rx off tx off gso off gro off lro off; затем вновь снять tcpdump и сравнить.
6) Локальная проверка отправки ACK
- tcpdump на клиенте: если клиент видел SYN‑ACK, но в tcpdump не видно исходящего ACK — значит клиент OS не отправляет или локальный firewall блокирует отправку.
- ss -o state syn‑sent покажет таймеры (retransmit) у клиентского сокета.
7) Варианты по результатам
- Если tcpdump на сервере не показывает SYN: проблема на пути от клиента → маршрут/ARP/NAT.
- Если сервер отвечает, но клиент не видит SYN‑ACK: проверить intermediate NAT, MTU, балансировщик; захватить на пограничных устройствах.
- Если клиент видит SYN‑ACK и не отправляет ACK: смотреть iptables/iptables raw table, SELinux, баги ядра; обновить стек/патчить.
- Если на сервере много SYN_RECV и нет перехода в ESTABLISHED: увеличить backlog, включить/посмотреть tcp_syncookies, оптимизировать приложение (быстрее accept).
Короткая методика «быстрого триажа»
1. tcpdump клиент и сервер → подтвердить кто что видит.
2. ss/netstat на обоих хостах → какие TCP‑состояния.
3. проверить firewall/nat/conntrack на промежуточных устройствах.
4. проверить приложение (listen/accept) и системные параметры (backlog/syncookies).
5. при сомнениях — отключить offloads и повторить захват.
Если нужно, могу дать точные команды под ваш сценарий (IP клиента/сервера, порт, интерфейсы) и подсказать, как интерпретировать конкретный tcpdump‑лог.