Захват пакетов в Windows на практике — pktmon, netsh trace и Wireshark

«Серверная связь бизнес-приложения несколько раз в месяц срывается. В журнале приложения только “timeout”. В журнале на стороне сервера в это время нет соответствующей ошибки. Неизвестно, как воспроизвести» — в консультациях по расследованию дефектов такая форма встречается постоянно.

В журнале приложения остаётся только то, что приложение «решило записать». Результат — timeout — виден, но был ли SYN без ответа, установилось ли соединение и сервер замолчал на полпути, оборвали ли сессию RST, и дошёл ли пакет до назначения вообще — живёт уровнем ниже журнала: в пакетах, которые реально прошли по проводу. Если Process Monitor смотрит уровнем ниже на доступ к файлам и реестру, захват пакетов смотрит уровнем ниже на сам обмен.

flowchart TB
    accTitle: Пакеты уровнем ниже журнала приложения
    accDescr: В журнале приложения остаётся только то, что приложение решило записать; был ли SYN без ответа, замолчал ли узел после connect, оборвал ли RST или пакет дошёл — живёт только в пакетах, реально прошедших по проводу
    log["Журнал приложения"] --> dec["Остаётся только то, что решили записать"]
    dec --> to["Результат — timeout одним словом"]
    to -->|смотреть уровнем ниже| pkt["Пакеты, реально прошедшие по проводу"]
    pkt --> q1["Нет ответа на SYN?"]
    pkt --> q2["Тишина после connect?"]
    pkt --> q3["Оборвано RST?"]
    pkt --> q4["Дошло ли до назначения?"]

Рис. 1: Журнал хранит только результат; разбор тайм-аута живёт только в пакетах уровнем ниже.

Типичное место, где расследование стопорится, — ограничение «на сервере заказчика нельзя поставить Wireshark». Площадки, где контроль изменений или политика безопасности не утвердят лишнее ПО ради расследования, не редкость. Но в Windows уже есть два штатных средства захвата пакетов: pktmon и netsh trace. Снять штатными средствами ОС, унести файл на свой ПК и разобрать в Wireshark — при таком разделении пакеты видны и там, где установку запрещают.

Статья рассчитана на IT-специалистов малого и среднего бизнеса и разработчиков приложений Windows. Она выстраивает выбор между pktmon, netsh trace и Wireshark и практическую процедуру каждого. Ловушки loopback-трафика, решение, снимать на клиенте или на сервере, как жить с тем, что TLS скрывает полезную нагрузку, и сопоставление захвата с журналом приложения разобраны по первоисточникам на август 2026 года.

1. Сначала вывод

• «Снимать штатным инструментом, читать в Wireshark» — базовая схема на площадке. Даже если на сервер заказчика нельзя ставить ПО, pktmon и netsh trace уже в Windows. Переведите снятый журнал в pcapng и разбирайте в Wireshark на своей машине.¹²
• pktmon — штатный захват пакетов в Windows 10 / Windows Server 2019 и новее. Им пользуются в четыре шага — зарегистрировать фильтр, запустить, остановить, преобразовать — и его отличие в том, что видно, какой компонент сетевого стека отбросил пакет (причина drop).³⁴
• netsh trace — более старое штатное средство; оно может включить набор ETW-провайдеров как «сценарий». Кроме пакетов оно хранит события внутри компонентов Windows, а с persistent=yes захват переживает перезагрузку.⁵⁶
• Оба пишут ETL, который Wireshark как есть не открывает. В pcapng переводят pktmon etl2pcap для pktmon и открытый etl2pcapng Microsoft для netsh trace.¹²
• Сам Microsoft указывает «сначала pktmon, затем netsh trace, если этого мало, и Wireshark для разбора протокола». Разделение в статье следует этой официальной рекомендации.⁷
• По умолчанию pktmon записывает только первые 128 байт каждого пакета. Если собираетесь читать нагрузку в Wireshark, при старте не забудьте --pkt-size 0 (записать весь пакет).⁸
• Трафик на localhost в обычном захвате не появляется. Он не проходит через NIC. В Wireshark используйте loopback-адаптер Npcap, со штатными средствами — захват внутри стека pktmon.⁹
• Даже когда TLS скрывает нагрузку, узнать можно многое. Установка соединения, успех рукопожатия TLS, RST и какая сторона замолчала видны и в шифре. Расшифровка через SSLKEYLOGFILE — приём только для среды разработки.¹⁰
• В захвате лежит сама связь. Исходите из того, что там могут быть учётные данные и персональные сведения, и встройте в процедуру минимально нужный захват и сужение перед передачей.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 21, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Три инструмента захвата и как их выбирать

Сначала одна таблица ролей трёх инструментов.

Одним предложением: pktmon и netsh trace — инструменты «захвата», Wireshark — инструмент «чтения». Wireshark тоже умеет снимать, но там, где его нельзя поставить, этим не воспользоваться. Обратно, ETL штатных средств можно перевести в текст и читать, но смотреть без фильтра отображения и разбора TCP — изнурительно. «На площадке снять штатным средством, перевести в pcapng и читать в Wireshark на своей машине» — самый короткий путь на ограниченной площадке.

flowchart TB
    accTitle: Снимать штатным средством, читать в Wireshark
    accDescr: На площадке снимают ETL через pktmon или netsh trace, каждый переводят в pcapng своим средством и разбирают в Wireshark на своей машине
    pk["pktmon (штатный)"] --> etla["Файл ETL"]
    ns["netsh trace (штатный)"] --> etlb["ETL+.cab"]
    etla -->|pktmon etl2pcap| pcap["pcapng"]
    etlb -->|etl2pcapng| pcap
    pcap --> ws["Разбор в Wireshark на своей машине"]

Рис. 2: На площадке снимают ETL штатными средствами, переводят в pcapng и читают в Wireshark на своей машине.

Руководство Microsoft по потере пакетов той же формы: сначала захват и локализация причины через pktmon, затем при нехватке — трассировки уровня компонентов вроде netsh trace start scenario=InternetClient, а поведение протокола разбирают в Wireshark.⁷

Чтобы читать, что пакет на самом деле показывает, полезно иметь картину слоёв — Ethernet, IP, TCP, прикладные данные. Анатомия слоёв разобрана в «По-настоящему разобраться в модели OSI».

3. pktmon на практике — фильтр, старт, стоп, преобразование

Базовый поток pktmon — четыре шага. Выполняйте их в терминале с правами администратора.

:: 1. Сначала зарегистрировать фильтр, чтобы сузить цель (TCP 8443 на сервере 192.168.10.20)
pktmon filter add App8443 -i 192.168.10.20 -t tcp -p 8443
pktmon filter list

:: 2. Начать захват. Записывать целые пакеты, перезаписывать в кольцевом буфере 1 ГБ
pktmon start --capture --pkt-size 0 --file-name C:\temp\app-timeout.etl --file-size 1024 --log-mode circular

:: 3. Воспроизвести сбой. Пока ждёте, объём и отбросы можно проверить через counters
pktmon counters --drop-reason

:: 4. Остановить, затем преобразовать в pcapng для Wireshark
pktmon stop
pktmon etl2pcap C:\temp\app-timeout.etl --out C:\temp\app-timeout.pcapng

:: 5. Убрать зарегистрированный фильтр (фильтры остаются, пока их явно не удалят).
::    Внимание: filter remove не принимает имя; он удаляет «все» зарегистрированные фильтры.
::    Если на машине могут остаться фильтры другого расследования, сначала проверьте pktmon filter list
pktmon filter remove

flowchart TB
    accTitle: Базовая процедура pktmon
    accDescr: Сузить цель фильтром, запустить захват, воспроизвести сбой, остановить, перевести в pcapng через etl2pcap и в конце снять зарегистрированный фильтр
    fa["1. Сузить цель через filter add"] --> st["2. Запустить захват start --capture"]
    st --> re["3. Воспроизвести сбой"]
    re -.-> ct["Проверить объём и drop через counters"]
    re --> sp["4. Остановить"]
    sp --> cv["Перевести в pcapng через etl2pcap"]
    cv --> rm["5. Убрать через filter remove"]

Рис. 3: pktmon начинается с регистрации фильтра, затем захват, стоп и преобразование, а фильтр в конце снимают явно.

На что обратить внимание:

• Регистрируйте фильтры до старта захвата. Документация Microsoft тоже настоятельно рекомендует применить фильтр до старта: захват всего трафика слишком шумный. Фильтры задают IP-адрес, порт, MAC, протокол, VLAN ID и т. д., зарегистрировать можно до 32. Несколько фильтров — это ИЛИ: пакет пишется, если совпал с любым.³
• Фильтр pktmon не различает источник и назначение. -i 192.168.10.20 значит «пакеты, где этот адрес — источник или назначение». Направление сужают позже фильтром отображения Wireshark после преобразования.³
• Размер пакета по умолчанию — 128 байт. Этого хватает для разбора заголовков, но если нужны и прикладные данные, пишите весь пакет через --pkt-size 0.⁸
• Журнал по умолчанию в режиме circular (кольцевой буфер), размер по умолчанию 512 МБ. Потолок меняют --file-size, а --log-mode real-time печатает на экран в реальном времени и файл журнала не создаёт. Сначала в реальном времени убедитесь, что нужный трафик реально виден, затем ставьте боевой захват — так избежите пустой съёмки.⁸

flowchart TB
    accTitle: Как срабатывают фильтры pktmon
    accDescr: Несколько зарегистрированных фильтров пишут по совпадению ИЛИ, указанный адрес не различает источник и назначение, направление сужают позже фильтром отображения Wireshark после преобразования
    f1["Фильтр 1"] --> orc["Писать, если совпал любой"]
    f2["Фильтр 2"] --> orc
    f3["Фильтр 3 (до 32)"] --> orc
    orc --> rec["Записано в журнал захвата (ИЛИ)"]
    rec -.-> nodir["Источник и назначение не различаются"]
    nodir -.-> ws["Сузить направление в Wireshark после преобразования"]

Рис. 4: Несколько фильтров работают как ИЛИ, а является ли узел источником или назначением сужают в Wireshark после преобразования.

3.1. Чем pktmon сильнее — видно, где пакет отбросили

Отличие pktmon от Wireshark в том, что он снимает пакет в нескольких точках внутри сетевого стека, а не на одной NIC, и может сообщить, где и почему его отбросили (dropped). Раз видно, до какого компонента пакет дошёл и где исчез, причины drop вроде «несовпадение MTU» или «фильтр VLAN» выводят к причине без слепого перебора.⁴

flowchart TB
    accTitle: pktmon снимает в нескольких точках стека
    accDescr: pktmon снимает пакет в нескольких точках сетевого стека, а не на одной NIC, поэтому может сообщить с причиной, до какого компонента пакет дошёл и где его отбросили
    pin["Пакет"] --> p1["Снят в точке 1"]
    p1 --> p2["Снят в точке 2"]
    p2 --> p3["Отброшен в точке 3"]
    p3 -.-> rz["Сообщает место и причину drop"]
    rz -.-> ex["напр. несовпадение MTU или фильтр VLAN"]

Рис. 5: Съёмка в нескольких точках стека показывает, как далеко дошёл пакет и где его отбросили, с причиной.

• pktmon list показывает сетевые компоненты, которые можно наблюдать (NIC, стеки протоколов, фильтр-драйверы и т. д.), и их ID.
• pktmon counters --drop-reason перечисляет счётчики прохождения/drop по компонентам и последнюю причину drop. Удобно как первый срез до разбора журнала.¹¹
• Перевод в текст через pktmon etl2txt выдаёт отброшенные пакеты с drop и dropReason.³

Подозрение, что «что-то в ОС отбрасывает это до приложения», одним Wireshark не закрыть. Эта возможность помогает, например, отделить случай, когда брандмауэр отбрасывает из‑за отсутствия входящего правила («Брандмауэр Windows и бизнес-приложения»).

Оговорка. pktmon пишет один и тот же пакет в нескольких точках стека, поэтому перевод как есть в pcapng может показать один пакет больше одного раза. pcapng не несёт «какой компонент это снял», поэтому при чтении в Wireshark стандартный ход — преобразовать с --component-id, выбрав одну точку (или вынести drop отдельно файлом --drop-only).¹

flowchart TB
    accTitle: Почему один пакет может появиться дважды после перевода в pcapng
    accDescr: pktmon пишет один пакет в нескольких точках стека, pcapng не хранит, какой компонент снял, поэтому возможны дубли; стандартный ход — преобразовать после сужения точки через component-id или вынести drop в отдельный drop-only файл
    same["Один пакет записан в нескольких точках"] --> conv["Перевести в pcapng как есть"]
    conv --> lost["Информация о точке съёмки не переносится"]
    lost --> dup["Один пакет появляется больше одного раза"]
    dup --> c1["Сузить точку через --component-id"]
    dup --> c2["Отдельный файл через --drop-only"]

Рис. 6: Информация о точке съёмки в pcapng не переносится, поэтому стандартный ход — сузить точку до преобразования.

4. netsh trace на практике — сценарии, ETL и захват, переживающий перезагрузку

netsh trace — механизм трассировки, который в Windows дольше, чем pktmon. Его черта: как «сценарий» он может разом включить весь набор ETW-провайдеров, связанных с этой проблемой.⁶

:: Список доступных сценариев и провайдеры внутри сценария
netsh trace show scenarios
netsh trace show scenario netconnection

:: Начать захват. Пакеты включены, кольцевой буфер 1 ГБ
netsh trace start scenario=netconnection capture=yes tracefile=C:\temp\nettrace.etl maxSize=1024 filemode=circular

:: Воспроизвести сбой, затем остановить (объединение merge занимает немного времени)
netsh trace stop

• Добавьте capture=yes, чтобы включить захват пакетов, и сузьте цель фильтром захвата вроде ipv4.address=192.168.10.20. Список фильтров — в netsh trace show capturefilterHelp.⁶
• Остановка даёт .cab помимо ETL. В .cab — системные сведения вроде конфигурации адаптеров и сборки ОС, то есть это ещё и сбор среды.⁶
• Одновременно может идти только одна сессия трассировки. Перед новым захватом проверьте netsh trace show status, что не осталась старая сессия.⁶
• Добавьте persistent=yes — и сессия переживёт перезагрузку. Снимать «связь на миг падает сразу после перезагрузки» или «подключение службы при старте срывается» — сбои, которые вручную не успеть запустить, — уникальная область netsh trace.⁵

flowchart TB
    accTitle: Захват сценария netsh trace
    accDescr: Старт со сценарием включает набор ETW-провайдеров, capture=yes ещё и захватывает пакеты, остановка даёт файл ETL и файл .cab
    sc["Старт со сценарием"] --> pv["Включить набор провайдеров"]
    sc -->|capture=yes| pc["Пакеты тоже захватываются"]
    pv --> re["Воспроизвести сбой"]
    pc --> re
    re --> sp["Остановить"]
    sp --> etl["Файл ETL"]
    sp --> cab[".cab (системные сведения)"]

Рис. 7: Старт со сценарием включает набор провайдеров, остановка даёт ETL и .cab.

4.1. Сделать ETL читаемым в Wireshark — etl2pcapng

ETL netsh trace в Wireshark как есть не открыть. etl2pcapng, открытое средство Microsoft на GitHub, переводит в pcapng пакеты из ETL, снятого через netsh trace start capture=yes.²

etl2pcapng.exe C:\temp\nettrace.etl C:\temp\nettrace.pcapng

При преобразовании etl2pcapng пишет идентификатор процесса, связанный с каждым пакетом, как комментарий пакета. Видеть в Wireshark «чей это процесс» помогает, когда на одном сервере говорят несколько приложений.²

Сторона ETW-событий (внутренние события Windows, которые записали провайдеры сценария) в pcapng не переводится. Если нужны и события, переведите в текст через netsh trace convert input=C:\temp\nettrace.etl или откройте ETL в Windows Performance Analyzer.⁵⁷

flowchart TB
    accTitle: Чтение ETL netsh trace расходится на два пути
    accDescr: Пакеты в ETL переводят в pcapng через etl2pcapng и читают в Wireshark; ETW-события в pcapng не переводятся, их читают через netsh trace convert или Windows Performance Analyzer
    etl["ETL netsh trace"] --> pk["Пакеты"]
    etl --> ev["ETW-события"]
    pk -->|etl2pcapng| pc["Перевести в pcapng"]
    pc --> ws["Читать в Wireshark"]
    pc -.-> pid["ID процесса остаётся комментарием"]
    ev -.-> no["В pcapng не переводится"]
    no --> alt["Читать через convert или WPA"]

Рис. 8: Из ETL пакеты переводят в pcapng для чтения; ETW-события читают иначе.

5. Первый взгляд на чтение в Wireshark — фильтры отображения и разбор TCP

Открыв pcapng, сначала уберите шум фильтром отображения. Частые — в таблице.¹²¹³

tcp.analysis.* — флаги разбора, которые Wireshark ставит, отслеживая номера последовательности TCP. Повторные передачи, дубли ACK, нарушение порядка, ZeroWindow и подобное ловятся механически, поэтому стандартный старт чтения — сначала ввести tcp.analysis.flags и выписать места «похоже на проблему».¹³

В расследовании тайм-аута ищите следующие формы по порядку.

1. Завершилось ли трёхстороннее рукопожатие? Есть ли все три пакета SYN → SYN/ACK → ACK? Если SYN повторяется без ответа, он не дошёл до узла или был тихо отброшен по пути (типичная картина брандмауэра).
2. Какая сторона послала RST? Немедленный RST на SYN значит, на порту назначения никто не слушает; RST после установленного соединения значит, одна сторона принудительно оборвала. Исходный IP RST — прямое доказательство «кто оборвал».
3. Продолжаются ли повторные передачи? Повторная передача того же сегмента — знак, что подтверждение (ACK) не возвращается отправителю. Пропали исходящие данные или возвращающийся ACK, с одностороннего захвата не закрыть (поэтому в следующей главе важен «захват с обеих сторон»). Повторные передачи и тайм-аут глубже разобраны в «Почему TCP-ретрансмиссии останавливают связь с промышленной камерой».
4. Есть ли ZeroWindow? Это знак, что принимающее приложение не читает из сокета и буфер приёма полон. Основание подозревать устройство принимающего приложения («Заблуждение, что TCP отдаёт данные через Receive такими же порциями»), а не сеть.

flowchart TB
    accTitle: Порядок форм в расследовании тайм-аута
    accDescr: Подтвердить завершение трёхстороннего рукопожатия, наличие и источник RST, продолжающиеся повторные передачи, затем ZeroWindow, чтобы поставить первую метку на причину
    hs{"Был ли ответ на SYN?"} -->|нет| ng["Не дошёл (типичный брандмауэр)"]
    hs -->|да| rs{"Есть RST?"}
    rs -->|да| who["Источник RST оборвал"]
    rs -->|нет| rt{"Повторные передачи продолжаются?"}
    rt -->|да| ack["ACK не возвращается"]
    rt -->|нет| zw{"Есть ZeroWindow?"}
    zw -->|да| app["Приёмник не читает"]

Рис. 9: Поиск рукопожатия, RST, повторной передачи, затем ZeroWindow в этом порядке сужает, куда смотреть дальше.

Прежде чем читать пакеты по одному, полезно взять общую картину статистикой. [Статистика] → [Диалоги (Conversations)] — список «какая пара IP / портов говорила, с какого по какое время, сколько», чтобы найти нужный обмен и отфильтровать только его. [Статистика] → [График ввода/вывода (I/O Graph)] — график объёма во времени; формы вроде «с этого момента одно направление замолчало» сразу видны. Правый щелчок по нужному TCP-обмену и [Следовать за] → [TCP-потоком (Follow TCP Stream)] позволяет прочитать обмен этого соединения как открытый текст.

flowchart TB
    accTitle: Сначала статистика целиком, затем сузить до обмена
    accDescr: Перечислить, какие обмены когда и сколько шли, в Conversations, взять интервал тишины с I/O Graph, отфильтровать нужный обмен и прочитать его как TCP-поток
    ov["Взять общую картину статистикой"] --> cv["Список обменов в Conversations"]
    ov --> io["Видеть объём на I/O Graph"]
    cv --> flt["Отфильтровать нужный обмен"]
    io -.-> mute["Интервал тишины становится видимым"]
    flt --> fs["Прочитать как TCP-поток"]

Рис. 10: Прежде чем читать пакет за пакетом, возьмите картину статистикой, сузьте до нужного обмена и прочитайте его целиком.

6. Ловушка loopback — трафик на localhost никогда не проходит через NIC

Пытаться расследовать связь между приложениями на одном ПК — например, бизнес-приложение подключается к промежуточному сервису на localhost:8080 — и застревать на «в Wireshark ничего нет» — классическая ловушка.

Причина ясна. Трафик на localhost (127.0.0.1) никогда не проходит через физическую NIC; ОС замыкает его на внутреннем loopback-пути. Обычный захват с физического адаптера его поэтому не видит.⁹

flowchart TB
    accTitle: Почему трафик на localhost не виден в захвате
    accDescr: Трафик на localhost никогда не проходит через физическую NIC и замыкается на внутреннем loopback-пути ОС, поэтому не появляется в обычном захвате с физического адаптера
    app["Приложение"] --> stack["Сетевой стек"]
    stack -->|внешний| nic["Физическая NIC"]
    nic --> seen["Видно в обычном захвате"]
    stack -->|localhost| lo["Замыкание внутри ОС"]
    lo -.-> miss["Нет в обычном захвате"]
    lo -.-> alt["Loopback Npcap или pktmon"]

Рис. 11: Трафик на localhost замыкается до NIC, захват с физического адаптера его не видит.

Есть два способа.

• При захвате в Wireshark: Выберите «Adapter for loopback traffic capture» Npcap как цель захвата. Установщик Windows Wireshark (3.0 и новее) несёт Npcap, поэтому если Wireshark уже стоит, ничего дополнительно делать не нужно.⁹
• При захвате штатными средствами: pktmon снимает в нескольких точках внутри сетевого стека, а не снаружи NIC⁴, поэтому тоже видит loopback. Чтобы быть уверенным, до боевого ожидания воспроизведения подтвердите на этой машине режимом реального времени pktmon start -c -m real-time, что нужный loopback реально виден.

Следите и за двумя путаницами.

• «localhost» может резолвиться в IPv6 ::1. Приложение идёт на IPv6 ::1, а расследователь смотрит только 127.0.0.1 (IPv4) и ошибочно заключает «трафика нет». Расширьте фильтр отображения на оба, как в ip.addr == 127.0.0.1 || ipv6.addr == ::1, или сделайте назначение приложения явным адресом.⁹
• Трафик на свой настоящий IP тоже не выходит на провод. Когда тот же ПК соединяется с 192.168.10.5 на 192.168.10.5, назначение — настоящий IP, но ОС всё равно замыкает внутри. Помните: «я указал настоящий IP, значит пройдёт через NIC» не гарантировано.

flowchart TB
    accTitle: Путаница, когда localhost резолвится в IPv6
    accDescr: localhost приложения может резолвиться в IPv6 ::1, и если расследователь смотрит только 127.0.0.1, он ошибочно заключает, что трафика нет; расширьте фильтр отображения на оба адреса или подтвердите назначение явным адресом
    app["Приложение идёт на localhost"] --> v6["На деле резолвится в ::1 (IPv6)"]
    look["Расследователь смотрит только 127.0.0.1"] --> none["На экране ничего нет"]
    v6 --> none
    none --> fix1["Расширить фильтр на оба адреса"]
    none --> fix2["Сделать назначение явным адресом"]

Рис. 12: Следите за путаницей, когда localhost резолвится в ::1 и взгляд только на 127.0.0.1 даёт «трафика нет».

7. Где снимать — одна сторона, обе стороны и синхронизация часов

Цену захвата решает «где сняли». Ориентир такой.

Односторонний захват говорит только «факты с моей позиции». Продолжающиеся повторные передачи на клиенте не различают, пропал ли отправленный пакет на пути или дошёл до сервера, а пропал ответ. Захват с обеих сторон и сопоставление устанавливают «клиент отправил / сервер никогда не получил» — какая сторона замолчала. Когда нужно закрыть границу ответственности (приложение, ОС, сетевое устройство или противоположная сторона), стоит с самого начала готовить двусторонний захват.

flowchart TB
    accTitle: Что говорят односторонний и двусторонний захват
    accDescr: Односторонний захват не различает, пропал ли исходящий пакет или возвращающийся ответ; захват с обеих сторон и сопоставление устанавливают, какая сторона замолчала
    one["Захват с одной стороны"] --> fact["Факты с вашей стороны"]
    fact --> und["Исходящее или возврат?"]
    both["Захват с обеих сторон"] --> mt["Сопоставить"]
    mt --> fix["Какая сторона замолчала"]
    mt -.-> pre["Нужна синхронизация часов"]

Рис. 13: Одна сторона показывает только факты, которые вы видели; сопоставление обеих сторон впервые закрывает границу ответственности.

7.1. Условие сопоставления — синхронизация часов

Чтобы сопоставить захваты с обеих сторон, часы обеих машин должны совпадать. Перед стартом захвата проверьте и запишите смещение часов.

:: Проверить состояние синхронизации времени (источник, время последней синхронизации)
w32tm /query /status

:: Измерить смещение относительно сервера-партнёра (5 выборок)
w32tm /stripchart /computer:sv-app01 /dataonly /samples:5

w32tm /stripchart показывает смещение времени между вами и узлом-партнёром и становится основанием правки вроде «часы сервера были +0,8 секунды» при сопоставлении захватов.¹⁴ В среде с большим смещением короче сначала починить синхронизацию времени, а потом снимать.

flowchart TB
    accTitle: Процедура проверки смещения часов перед сопоставлением
    accDescr: Подтвердить свой статус синхронизации через w32tm, измерить и записать смещение к серверу-партнёру через stripchart, использовать это смещение как основание правки при сопоставлении, а при большом смещении сначала починить синхронизацию и затем снимать
    st["Проверить статус sync через query"] --> mc["Измерить смещение через stripchart"]
    mc --> rc["Записать смещение"]
    rc --> use["Основание правки в момент сопоставления"]
    mc -.-> big["Если смещение велико, сначала починить sync"]

Рис. 14: Измерьте и запишите смещение часов до захвата и используйте его как основание правки при сопоставлении.

7.2. Для «неизвестно, когда случится» — кольцевой буфер

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

• pktmon: По умолчанию режим circular. Потолок (МБ) задают --file-size; старые пакеты перезаписываются.⁸
• netsh trace: Указывают как maxSize=1024 filemode=circular.⁵
• Wireshark: В [Захват (Capture)] → [Параметры (Options)] → [Вывод (Output)] можно настроить «несколько файлов + кольцевой буфер». Он крутится по размеру файла или времени и хранит только последние N файлов, поэтому можно долго работать с потолком диска.¹⁵

В любом случае договоритесь с человеком на площадке: когда сбой случится, «сначала записать время, потом» остановить захват. Кольцевой буфер стирает прошлое, чем дольше ждёте: если путь от события до стопа длинен, нужный интервал перезапишется.

flowchart TB
    accTitle: Ожидание с захватом в кольцевом буфере
    accDescr: При неизвестных условиях воспроизведения оставить кольцевой буфер, а когда сбой случится, записать время и быстро остановить; поздний стоп перезаписывает старые пакеты и нужный интервал исчезает
    st["Запустить захват в кольцевом буфере"] --> wt["Оставить работать и ждать"]
    wt --> ev["Сбой случается"]
    ev --> memo["Записать время"]
    memo --> sp["Быстро остановить"]
    wt -.-> ow["Старые пакеты перезаписываются"]
    ow -.-> late["Поздний стоп стирает нужный интервал"]

Рис. 15: Кольцевой буфер стирает прошлое, чем дольше ждёте, поэтому записав время, останавливайте быстро.

8. Проблема, что TLS скрывает нагрузку — что всё равно видно

Большая часть делового трафика сегодня — TLS (HTTPS). Легко подумать «если зашифровано, захват бесполезен», но большая часть того, что нужно в расследовании тайм-аута, видна при оставленном шифре.

• Установилось ли TCP-соединение (трёхстороннее рукопожатие)
• До куда дошло рукопожатие TLS — вернулся ли ServerHello на ClientHello, оборвали ли RST или alert во время рукопожатия
• Имя узла назначения в ClientHello (SNI) и согласованная версия TLS
• После подъёма соединения какая сторона перестала слать. Место тишины, повторные передачи, RST или чистый close (FIN)

Иначе говоря, отделить «не соединяется», «обрывается посередине» и «ответ не возвращается» почти никогда не требует расшифровки нагрузки. Шифрование теряет «что сказали»; «кто замолчал и когда» остаётся.

flowchart TB
    accTitle: Что захват TLS может и не может показать
    accDescr: Шифрование скрывает только нагрузку прикладных данных; установка TCP, успех или срыв рукопожатия TLS, SNI и версия TLS, RST и какая сторона замолчала видны при оставленном шифре
    tls["Захват TLS-трафика"] --> vis["Видно"]
    tls --> hid["Не видно"]
    vis --> v1["Установка TCP"]
    vis --> v2["Результат TLS и SNI"]
    vis --> v3["RST / кто замолчал"]
    hid --> h1["Нагрузка прикладных данных"]

Рис. 16: Шифрование теряет только нагрузку; каркас обмена читается и при оставленном TLS.

Когда нагрузка всё же нужна, Wireshark может расшифровать TLS ключами сессии, выписанными через переменную окружения SSLKEYLOGFILE. Поддержка ограничена некоторыми реализациями вроде Firefox, Chrome, Edge на Chromium и библиотек семейства OpenSSL; штатный SChannel Windows (приложения на WinHTTP или WinINET) этот механизм не поддерживает.¹⁰ «Ключ сессии пишется в файл» значит, что у кого есть файл, тот расшифрует весь обмен, это не приём для боя; считайте его воспроизведением и отладкой в среде разработки.

flowchart TB
    accTitle: Как работает расшифровка SSLKEYLOGFILE и её пределы
    accDescr: Ключи сессии, выписанные через SSLKEYLOGFILE, позволяют Wireshark расшифровать TLS, но поддерживают лишь некоторые реализации вроде Firefox и семейства Chrome, а SChannel нет; у кого есть файл ключа, тот расшифрует обмен, поэтому считайте приём только для среды разработки
    env["Задать SSLKEYLOGFILE"] --> key["Выписать ключи сессии"]
    key --> ws["Читать в Wireshark"]
    key -.-> risk["Держатель ключа может расшифровать"]
    risk -.-> dev["Только разработка"]
    env -.-> sup["Только некоторые стеки TLS"]
    sup -.-> sch["SChannel: нет поддержки"]

Рис. 17: Выписывание ключей сессии может расшифровать, но поддерживаемые реализации ограничены, а природа ключа делает это приёмом только для среды разработки.

Когда трафик идёт через внутренний прокси, назначение в захвате — прокси-сервер, а TLS течёт внутри туннеля CONNECT. Предварительный вопрос, к какому прокси вообще идёт приложение, разобран в парной статье того же дня «Корпоративные прокси и приложения Windows — разбор разрешения прокси в WinINET, WinHTTP и .NET».

9. Сопоставление с журналом приложения — время на одну ось

Один захват редко даёт вывод. Решающий ход на практике — положить одну строку журнала приложения и один оборот пакетов на одну ось времени.

Процедура такая.

1. Определите время сбоя из журнала приложения (например, исключение timeout в 10:23:41). Если значение тайм-аута — 30 секунд, старт должен быть около 10:23:11.
2. Переключите отображение времени Wireshark на [Вид (View)] → [Формат отображения времени (Time Display Format)] → [Дата и время суток (Date and Time of Day)] и сузьте интервал фильтром отображения (можно и по времени, как в frame.time >= "2026-08-20 10:23:00" && frame.time <= "2026-08-20 10:24:00").
3. В этом интервале подтвердите порядок главы 5 (рукопожатие → RST → повторная передача → ZeroWindow). Если удаётся сопоставить до «за 30 секунд до времени timeout в журнале ушёл SYN, дальше только повторные SYN», «timeout» журнала сменяется наблюдением «в этой точке захвата ответа не вернулось вовсе» (дошёл ли SYN до узла или пропал возвращающийся SYN/ACK на обратном пути, с одной этой точки захвата не закрыть. Чтобы закрыть, снимите на сервере и сопоставьте).
4. Всегда правьте смещение между временем захвата и временем журнала (смещение часов из раздела 7.1 и обозначение часового пояса журнала). Ошибка сопоставления в несколько секунд примет за виновника чужой обмен.

flowchart TB
    accTitle: Процедура сопоставления журнала приложения и пакетов
    accDescr: Определить время сбоя из журнала приложения, отсчитать старт от значения тайм-аута, сузить интервал в Wireshark фильтром отображения, подтвердить формы по порядку, поправить смещение часов и положить на одну ось времени
    lg["1. Определить время сбоя из журнала"] --> rev["Отсчитать старт от значения тайм-аута"]
    rev --> flt["2. Сузить интервал фильтром отображения"]
    flt --> chk["3. Подтвердить формы в порядке главы 5"]
    chk --> adj["4. Поправить смещение часов"]
    adj --> done["Одно слово журнала становится наблюдением"]

Рис. 18: Сузьте интервал от времени журнала, подтвердите форму, поправьте смещение часов и положите на одну ось.

Когда отдаёте результаты расследования третьей стороне (вендору, оператору, сетевикам заказчика), убрать шум фильтром до передачи — и вежливость, и мера безопасности. В Wireshark сузьте до нужного обмена фильтром отображения и сохраните «только отображённые пакеты» через [Файл (File)] → [Экспортировать указанные пакеты (Export Specified Packets)] — получите маленький pcapng только нужного диапазона.

Наконец, осторожность обращения. Файл захвата содержит саму связь. Там могут быть учётные данные открытых протоколов, HTTP-cookie и ключи API, содержимое почты или отчётов и персональные данные. Решите следующие три пункта комплектом с процедурой захвата.

• Минимально нужный захват: Сузьте цель фильтрами до захвата (главы 3 и 4) и держите окно времени как можно короче. Не делайте «просто снять всё» на среде заказчика
• Сузить до передачи: Экспортируйте только нужный обмен; не включайте чужой посторонний трафик. Если остались чувствительные части, договоритесь с получателем о маскировании или другом пути
• Хранение и удаление: Решите, где лежат файлы захвата, сколько и когда удаляются, и удалите после окончания расследования

flowchart TB
    accTitle: Три решения до передачи файла захвата
    accDescr: Захват содержит саму связь, поэтому решите комплектом с процедурой захвата, что сузите до минимума фильтрами до захвата и окном времени, до передачи извлечёте только нужный обмен чтобы посторонний трафик не вошёл, и зададите место и срок хранения и удалите после расследования
    cap["Захват = трафик"] --> p1["Снимать минимум"]
    cap --> p2["Сначала извлечь цель"]
    cap --> p3["Задать хранение, удалить"]
    p2 -.-> exp["Фильтровать и экспортировать"]

Рис. 19: Решите минимальный захват, сужение до передачи, хранение и удаление комплектом с процедурой захвата.

10. Итог

• Уровнем ниже «timeout» журнала приложения лежит факт пакетов, реально прошедших по проводу. Не было ли ответа на SYN, оборвал ли RST, продолжались ли повторные передачи или появился ZeroWindow — меняет, куда смотреть дальше.
• Даже на площадке, где нельзя поставить Wireshark, можно снимать штатными pktmon и netsh trace. Снимать штатным средством, читать в Wireshark на своей машине — эта схема и есть базовая форма.
• pktmon — четыре шага: зарегистрировать фильтр → pktmon start --capture → pktmon stop → pktmon etl2pcap. По умолчанию обрезка до 128 байт, если нужна нагрузка, не забудьте --pkt-size 0. Видеть место и причину drop — сила только pktmon.
• netsh trace захватывает набор ETW-провайдеров сценарием, и с persistent=yes может пережить перезагрузку. ETL переводят в pcapng через etl2pcapng, чтобы читать.
• В Wireshark начинайте с tcp.analysis.flags и ищите рукопожатие, RST, повторную передачу и ZeroWindow в этом порядке. Быстрее, если сначала взять картину через Conversations и I/O Graph, затем сузить.
• Трафик на localhost не проходит через NIC, обычным способом его не снять. Используйте loopback-адаптер Npcap или захват внутри стека pktmon.
• Захват с обеих сторон и сопоставление устанавливают, «какая сторона замолчала». Условие — синхронизация часов (w32tm). Для сбоя с неизвестными условиями воспроизведения ждите кольцевым буфером.
• Даже под TLS каркас обмена виден. Расшифровку (SSLKEYLOGFILE) считайте приёмом только для среды разработки, а сам файл захвата — конфиденциальным: встройте минимальный захват, сужение и удаление в работу.

Захват пакетов часто считают «инструментом сетевого специалиста», но на практике это средство расследования со стороны приложения, которое начинает что-то значить, только когда его сопоставляют с журналом приложения. В следующий раз, когда расследование остановится на одном слове «timeout», идите смотреть уровнем ниже.

Похожие статьи

• Почему TCP-ретрансмиссии останавливают связь с промышленной камерой, и как это диагностировать
• Заблуждение, что TCP отдаёт данные через Receive такими же порциями, какими их отправили через Send — как проектировать приём, работая с байтовым потоком
• По-настоящему разобраться в модели OSI — препарируем один HTTP-запрос на семь уровней
• Практическое руководство по Process Monitor (ProcMon) — как за 10 минут выяснить, почему «настройки не читаются» или возникает ACCESS DENIED
• Брандмауэр Windows и бизнес-приложения — регистрировать входящие правила из установщика
• Корпоративные прокси и приложения Windows — разбор разрешения прокси в WinINET, WinHTTP и .NET

Смежные области консультирования

KomuraSoft LLC берёт расследования дефектов связи вроде «связь бизнес-приложения время от времени срывается, причину не находим» и «хотим отделить ошибку соединения, которая бывает только на среде заказчика». Проектирование захвата (где, что и сколько снимать), разбор в Wireshark, сопоставление с журналом приложения и правку на стороне приложения мы ведём как одну непрерывную работу.

• Разработка Windows-приложений
• Исследование дефектов и анализ первопричин
• Техническая консультация и ревью проекта
• Связаться с нами

Справочные ссылки

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Как снять пакеты на сервере заказчика, куда нельзя поставить Wireshark?

Возьмите штатные средства Windows — pktmon или netsh trace: ставить ничего не нужно. В pktmon в терминале с правами администратора регистрируют фильтр, запускают захват командой pktmon start --capture и останавливают pktmon stop. Полученный ETL переводят в pcapng через pktmon etl2pcap, а разбирают уже в Wireshark на своей машине. «Снимать штатным инструментом, читать в Wireshark» — базовая схема там, где установку ПО запрещают.

Что выбрать: pktmon или netsh trace?

Если в ОС есть pktmon (Windows 10 / Windows Server 2019 и новее), начинайте с pktmon. Команды простые, видно, какой компонент сетевого стека отбросил пакет (причина drop), а перевод в pcapng самодостаточен. netsh trace удобнее, когда снимаете на старой ОС без pktmon, когда нужно собрать ETW-события компонентов Windows сценарием или когда захват должен пережить перезагрузку с persistent=yes. Материалы Microsoft по диагностике указывают тот же порядок: сначала pktmon, затем netsh trace, если этого мало.

Почему трафик на localhost (127.0.0.1) не виден в Wireshark?

Трафик на localhost никогда не проходит через физическую NIC: ОС замыкает его на внутреннем loopback-пути. Обычный захват с физического адаптера его поэтому не видит. В Wireshark выберите «Adapter for loopback traffic capture» Npcap — тогда loopback можно снять. pktmon пишет внутри сетевого стека, поэтому тоже видит loopback. Ещё путаница: «localhost» резолвится в IPv6 ::1, и экран, настроенный на 127.0.0.1, пуст — проверяйте, явно указав адрес.

Можно ли в дампе пакетов увидеть содержимое HTTPS (TLS)?

Полезная нагрузка прикладных данных зашифрована и не видна. Каркас обмена — установка и разрыв TCP, успех рукопожатия TLS, обрыв RST, какая сторона перестала отвечать — виден и в шифре, поэтому большинство расследований тайм-аута идёт с нерасшифрованным TLS. Если нужна нагрузка, есть расшифровка через SSLKEYLOGFILE, но её поддерживают лишь некоторые реализации TLS вроде Firefox и семейства Chrome; штатный SChannel Windows не поддерживается. Механизм выписывает ключевой материал, считайте его опцией только для среды разработки.

Безопасно ли отправлять файл захвата внешней поддержке?

Отправлять как есть опасно. В захвате лежит сама связь: там могут быть учётные данные открытых протоколов, cookie, ключи API и персональные данные. Сначала на этапе захвата сузьте фильтр и окно времени до необходимого минимума, а перед передачей извлеките только нужный обмен фильтром отображения Wireshark и экспортируйте его. По тому, что останется, заранее договоритесь с получателем, как обрабатывать чувствительные части (маскирование или другая доставка). Заранее решите, сколько хранить файлы захвата и когда их удалять.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

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