TCP RST и PCAP-анализ сброса соединения: кто и почему закрыл соединение

---

«Сброс соединения по одноранговому узлу» — распространенная ошибка в HTTP-клиентах, базах данных, инструментах TLS, прокси-серверах и пользовательских TCP-приложениях. Пользователи ищут «анализ TCP RST pcap», «сброс соединения по одноранговому узлу Wireshark», «RST после SYN», «сброс соединения TLS» и «сброс TCP брандмауэра», поскольку им необходимо знать, кто разорвал соединение и произошел ли сброс из приложения, операционной системы, брандмауэра, балансировщика нагрузки или сервера.

TCP RST является явным. Там написано "прервать это соединение". Самое сложное — это атрибуция.

PCAP Surgery полезен, поскольку для расследования сброса требуется чистая, целенаправленная трассировка с указанием направления, временных меток, порядковых номеров и достаточного количества пакетов перед сбросом.

Общие шаблоны сброса

RST может произойти:

• Сразу после SYN.
• После SYN-ACK.
• После ClientHello.
• После HTTP-запроса.
• Во время тайм-аута простоя.
• После неверных данных протокола.
• Когда приложение закрывает сокет с непрочитанными данными.
• Когда брандмауэр отклоняет политику.
• Когда у балансировщика нагрузки нет работоспособного бэкэнда.
• Когда серверный процесс выходит из строя или отказывается от состояния.

Время подскажет вам, где искать.

Кто отправил RST

Сначала определите IP-адрес источника, порт источника, IP-адрес назначения и порт назначения пакета сброса. Если IP-адрес сервера отправляет RST, это означает, что сторона сервера или что-то, выдающее себя за эту сторону, завершило его. Если IP-адрес клиента отправляет RST, клиентская сторона завершила его. Если поведение TTL, MAC или пути предполагает наличие промежуточного блока, может быть введен сброс.

Не полагайтесь только на формулировку заявления. О «Сбросе по узлу» может сообщить сторона, получившая RST.

Сброс после SYN

RST после SYN часто означает, что порт закрыт или политика отклоняет соединение. Если SYN получает RST немедленно, приложение никогда не достигало TLS или HTTP.

Искать:

• СИН -> РСТ, ПОДТВЕРЖДЕНИЕ
• Нет сервера, здравствуйте!
• Нет данных приложения
• Согласованное поведение во всех попытках

Это не сбой сертификата или ошибка HTTP; это ошибка доступности/состояния службы TCP.

Сброс во время TLS

RST после ClientHello может быть вызван неправильным портом, неподдерживаемым TLS, несоответствием SNI, политикой промежуточного блока или отклонением сервера. Сохраните метаданные DNS и ClientHello, чтобы вы могли видеть имя хоста, ALPN, версии TLS и время.

Если сброс происходит после оповещения TLS, оно более информативно, чем сброс. Если оповещения нет, сброс может быть выполнен на более низком уровне или на основе политики.

Сброс после запроса

RST после HTTP-запроса, запроса к базе данных или команды протокола часто означает, что приложение достаточно понято, чтобы отклонить или аварийно завершить запрос. Это также может означать, что прокси-сервер закрыт, поскольку восходящий сервер недоступен.

Коррелировать:

• Последние отправленные байты приложения.
• Ответ сервера или отсутствие ответа.
• Время простоя перед сбросом.
• Журналы серверной части/балансировщика нагрузки.
• Происходит ли сброс только для определенных размеров запроса.

Checklist

Используйте этот рабочий процесс:

1. Определите первый RST в разговоре.
2. Определите, кто его отправил.
3. Проверьте, что произошло непосредственно перед этим.
4. Проверьте, завершено ли TCP-квитирование.
5. Проверьте, начался или завершился TLS.
6. Проверьте, были ли отправлены данные приложения.
7. Проверьте тайм-аут простоя.
8. Сравните подсказки TTL/MAC/path для внедрения промежуточного блока.
9. Сохраните DNS, TCP, TLS и байты приложения после сброса.
10. Используйте журналы сервера/балансировщика нагрузки для подтверждения атрибуции.

Окончательный диагноз

TCP RST — это прерывание соединения, но причина зависит от времени и отправителя. PCAP может различать закрытый порт, отклонение брандмауэра, отклонение TLS, закрытие приложения, тайм-аут простоя, сбой балансировщика нагрузки и сброс промежуточного блока.

PCAP Surgery помогает сохранить последовательность пакетов, которая отвечает на самый важный вопрос: кто сбросил соединение и что произошло непосредственно перед этим?