👋 Привет, сетевой друг!

Давай разберём несколько TCP-флагов и состояний, которые особенно полезны, когда смотришь трафик в Wireshark и пытаешься понять, где именно всё сломалось.

🟣SYN без SYN-ACK
Клиент отправляет

Client → Server   SYN
Client → Server   SYN
Client → Server   SYN

а ответа нет.
Это ещё не значит «сервер лежит». SYN мог потеряться, его мог отбросить файрвол, либо обратный маршрут сломан. Поэтому следующий шаг - смотреть, доходят ли пакеты до сервера и есть ли от него ответ.

🟣SYN-ACK приходит, но клиент отвечает RST: Здесь картина уже интереснее:

Client → Server   SYN
Server → Client   SYN-ACK
Client → Server   RST

Сервер явно ответил, но клиент сразу сбросил соединение. Такое бывает, например, когда клиентский стек уже не ожидает этот ответ или состояние соединения исчезло из-за NAT/stateful firewall.

🟣RST вместо SYN-ACK

Client → Server   SYN
Server → Client   RST

TCP-порт на той стороне явно отверг попытку соединения. Классический случай - приложение не слушает этот порт.
Но RST может генерироваться и сетевым оборудованием или security-механизмом, поэтому источник пакета тоже стоит проверить.

🟣FIN и RST - совсем разные истории

FIN означает: «я закончил отправлять данные».
RST означает: «эту TCP-сессию прекращаем прямо сейчас».

Например, нормальное закрытие выглядит примерно так:

Client → Server   FIN
Server → Client   ACK
Server → Client   FIN
Client → Server   ACK

А RST посреди нормального обмена уже требует посмотреть, что происходило непосредственно перед ним.

🟣ACK с неожиданным номером: TCP подтверждает не отдельные пакеты, а последовательность байтов.

Например:

SEQ=1000 LEN=500
ACK=1500

Если сервер продолжает получать ACK=1000, хотя уже отправил данные дальше, можно увидеть retransmission, duplicate ACK и проблемы с доставкой.
Именно по комбинации SEQ, ACK, SYN, FIN, RST и времени между пакетами часто можно восстановить всю историю TCP-сессии - кто начал соединение, где потерялся пакет и на каком этапе оно развалилось.

Серверная Админа | Zeroday | #Инструмент