Wireshark для диагностики: как читать сетевой трафик без догадок

Wireshark превращает хаос пакетов в ясную историю причины и следствия; подробный путеводитель — Wireshark: как анализировать сетевой трафик для диагностики проблем — подсказывает, с чего начать. Смысл в том, чтобы поймать трафик там, где рождается задержка, задать фильтр как точный вопрос и прочесть хронометраж с первой до последней миллисекунды.

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

Wireshark не магия, а инструмент с сильной оптикой. Захват, фильтры, расшифровка, графики — будто объективы с разным фокусным расстоянием. Ошибиться можно на любом шаге, от выбора точки прослушивания до вывода о вине TLS. Но если читать трафик как хронику, а не как набор кадров, картинка выпрямляется.

Зачем Wireshark, если «всё и так работает»

Wireshark нужен, чтобы подтвердить или опровергнуть сетевую гипотезу фактами: временем, флагами, последовательностью. Он показывает, где именно рвётся цепочка — от DNS до TLS и приложения.

Симптомы похожи друг на друга: долгая загрузка страницы, редкие подвисания, всплеск ошибок на ровном месте. Метрики мониторинга дают общий фон, но не указывают пальцем на пакет, где началась беда. Захват трафика заполняет этот пробел. На уровне TCP видны рукопожатия, окна и ретрансмиссии; на уровне DNS — кеш, NXDOMAIN, SERVFAIL; на уровне TLS — затяжные рукопожатия и невидимый из‑за шифрования запрос, который всё же можно разложить по таймингу. Там, где логам свойственно молчать в кульминационный момент, последовательность кадров с микросекундной точностью оставляет след. И как только связь между симптомом и пакетом установлена, перестаёт работать гадание и начинается ремесло.

Где и как захватывать трафик, чтобы не лечить тени

Лучшее место захвата — там, где виден и симптом, и его источник. Иначе анализ отражений приведёт к ложному диагнозу. Порядок простой: определиться с точкой, обеспечить «прозрачность» канала и не повредить прод.

Захват на клиенте помогает понять, как приложение общается с сетью: локальные паузы стека, DNS‑задержки, потерянные SYN. Захват на сервере показывает, где сервер тратит секунды до ответа и как распределяются очереди. Посередине — порт‑зеркало или TAP, если граница между доменами ответственностей проходит через коммутатор или виртуальный свитч. В облаке к этому добавляются зеркальные потоки в VPC и агенты, отдающие pcap в кольцевой буфер. В любом варианте цель одна: поймать оригинал, а не тени. Поэтому промискуитетный режим важнее «красивых» интерфейсов, а синхронизация времени — даже важнее эстетики именования файлов.

Захват на конечной станции, шлюзе или в «облаке»?

Выбор точки — компромисс между полнотой картины и доступностью. На клиенте лучше видны DNS, TCP‑паузы и перезапросы, на сервере — обработка и очереди, на сетевой границе — потери и дропы.

Практика показывает, что спор «где ловить» решает поставленная цель. Диагностика «почему первый байт поздно» предпочтительнее на клиенте: так видны задержки рукопожатия, потери SYN/ACK, ошибки MTU и череда переназначений DNS. По жалобе «сервер иногда умирает» полезнее зеркало рядом с приложением: именно там считывается распределение времени между принятием connection, TLS‑рукопожатием и отдачей контента. В VPC возможен зеркальный трафик на специальный интерфейс захвата; в таких схемах важно помнить о пакетной аггрегации гипервизора и увеличенной джиттерности тайм‑штампов. Если захват идёт на высоконагруженной машине, dumpcap с кольцевым буфером оберегает диск от переполнения, а netdump в гипервизоре — от потери кадров при пиках.

Port mirroring, TAP и зеркала виртуальных свитчей

SPAN удобен, TAP точнее. Для инцидентов, где счёт идёт на доли миллисекунд, аппаратный мониторинг выигрывает у программного зеркалирования.

Коммутаторный SPAN часто притормаживает под нагрузкой, «расплющивает» bursts и не всегда сохраняет порядок кадров. TAP пропускает трафик мимо процессора коммутатора и даёт стабильный, «сырой» поток — бесценный при охоте на ретрансмиссии и дропы на грани MTU. В виртуализации зеркалирование порта vSwitch в отдельный интерфейс снижает нагрузку на гостевую ОС и устраняет вмешательство драйвера. Важно не забывать: зеркалировать нужно обе стороны диалога, иначе анализ RTT и dupACK превратится в лотерею.

Захват Wi‑Fi: мониторный режим и radiotap

Для беспроводной среды пассивный захват в мониторном режиме незаменим: только он покажет уровень сигнала, перехваты и ретраи на эфире. Без radiotap картина будет неполной.

В проводной сети теряется пакет или бит. В эфире теряется момент разговора. Радиокадр несёт не только полезную нагрузку, но и обстоятельства её доставки: канал, ширина, MCS, RSSI, фреймы управления, EAPOL, повторные передачи. Мониторный режим раскрывает их, а ключи расшифровки (PSK или ключевой лог файл) позволяют заглянуть внутрь полезной нагрузки. Важно правильно выбрать канал и зафиксировать его: иначе анализ затмит роуминг, а обрыв на соседнем канале пролезет призраком.

Фильтры как язык точного вопроса: capture и display

Capture‑фильтр экономит диск и CPU, display‑фильтр вырезает из записанного то, что важно сейчас. Первый — сито у входа, второй — скальпель на столе.

Слишком широкий захват превращает расследование в поиски иголки, слишком узкий — лишает контекста. Баланс достигается сочетанием BPF при съёме и выражений отображения при анализе. Когда цель — «посмотреть TCP‑рукопожатие к 443/tcp узла X», BPF отрежет всё лишнее, а display раскроет каждый сегмент с флагами, RTT и окнами. И наоборот, если инцидент ещё не локализован, стоит писать шире (ring buffer) и резать при просмотре, чтобы иметь шанс вернуться на минуту раньше и увидеть DNS‑ошибку перед провалом TLS.

Захватные фильтры BPF: сужать воронку у входа

BPF эффективен и предельно строг: пропустит только то, что описано. Подходит для известных портов, подсетей и протоколов, когда цена пропуска минимальна.

Фильтры на этапе захвата должны быть без двусмысленностей. Примеры рабочей формулы: host 203.0.113.10 and tcp port 443; net 10.0.0.0/8 and not port 22; vlan 200 and (tcp or udp). Они быстры, потому что выполняются в ядре и отбрасывают шум до попадания в файл. Но за точность придётся платить внимательностью: любая ошибка — и нужный пакет не попадёт в pcap. Поэтому принято «сужать» известное, а подозрительное — оставлять до анализа.

Отображаемые фильтры Wireshark: хирургия после факта

Display‑фильтры гибче: позволяют задавать условия по полям протокола, величинам времени и флагам. Это инструмент разметки истории, в которой важны детали.

Визуальная хирургия начинается с простых выражений: tcp.analysis.retransmission, http.response.code >= 500, dns.flags.rcode != 0, tls.handshake.type == 1. Со временем к ним добавляются составные условия: frame.time_delta_displayed > 0.200 and tcp.stream == 3 — так вылавливаются длинные паузы в конкретном диалоге; ip.len > 1400 and not tcp.analysis.retransmission — для проверки MTU и фрагментации. Display‑фильтры читаются как фразы и дают возможность слой за слоем снять то, что мешает добраться до сути.

• dns.flags.rcode != 0 — ответы DNS с ошибками;
• tcp.flags.syn == 1 and tcp.flags.ack == 0 — исходящие SYN;
• tcp.analysis.duplicate_ack — дублирующие ACK;
• tcp.window_size_value < 10000 — маленькое окно TCP;
• http.time > 0.5 — медленные HTTP‑ответы (если доступно поле);
• tls.handshake.extensions_server_name contains «api» — SNI для TLS;
• quic && http3 — трафик HTTP/3 поверх QUIC.

Диагностика по уровням: от DNS до TLS и HTTP/QUIC

Надёжный путь — идти снизу вверх: имя, маршрут, соединение, шифрование, приложение. Пропущенный слой порождает ложные версии событий.

Каждый уровень приносит свою метрику и свой тип сбоя. DNS отвечает на вопрос «куда»: без него всё остальное бессмысленно. TCP/UDP подтверждают «как добраться»: здесь живут окна, таймауты, MSS, ретраи. TLS рассказывает «как договорились шифроваться»: handshake, ciphers, SNI и резкие паузы при утилизации сессионных ключей. HTTP/2 и HTTP/3 дают «что именно делали»: коды, заголовки, мультиплексирование. Скорость чтения истории зависит от умения удерживать связку: если DNS шатается, TLS будет плясать, а HTTP станут штамповать полузакрытые потоки с подвисшим контентом.

DNS — первый камень домино

Проблемный DNS легко маскируется под «медленный сервер». Проверка фильтрами dns и графами времени часто срывает маску за минуту.

В pcap тревожные признаки у DNS выглядят как длинные frame.time_delta между запросом и ответом, множественные повторы одного и того же запроса с увеличивающимися ID, смешение A/AAAA с провалами по IPv6, а также всплеск NXDOMAIN/SERVFAIL. На клиенте заметен отход к кэшу и неожиданные обращения к публичным резолверам, если корпоративные недоступны. Важно обращать внимание на EDNS и размер ответа: фрагментация выше MTU способна сделать вид, будто «сервер не отвечает», хотя ответ развалился на пути.

TCP под лупой: рукопожатие, окна, ретрансмиссии

TCP — это дыхание соединения. Если вдохи прерываются — в статистике появятся dupACK, retransmission, zero window, window update и внезапное RTO.

Три рукопожатия складываются в неповторимую подпись сети: RTT считывается из пары SYN/SYN‑ACK, MSS намекает на MTU, опции SACK и window scaling раскрывают потенциал канала. Дальше — диалог ack и сегментов. Любой всплеск ретрансмиссий требует сопоставления с dupACK и графиком Time‑Sequence: если окно падает к нулю, виноват приёмник; если dupACK штампуются без падения окна, дешевле проверить потери в канале и работу очередей на коммутаторе. Паузы с ровным окном подсказывают, что задержка рождается выше — в приложении или TLS.

TLS 1.3 и расшифровка через SSLKEYLOGFILE

Даже без расшифровки TLS заметна по таймингам рукопожатия. Но ключевой лог откроет полезную нагрузку и снимет маску с HTTP‑задержек.

Wireshark понимает key log file, если его отдать в Preferences — TLS — (Pre)-Master-Secret log. Браузеры и многие клиенты умеют писать SSLKEYLOGFILE в переменную окружения. После этого трафик TLS 1.2/1.3 раскроется, а поля http.time и разметка потоков перестанут быть пустыми местами. В отсутствие ключей остаются косвенные признаки: затянувшийся ClientHello/ServerHello, неудачная договорённость об ALPN, многократные Hello Retry Request, отсутствие 0‑RTT там, где он должен быть. Схема «длинный TLS, короткий HTTP» часто указывает на инспекцию трафика посредником.

HTTP/2 и HTTP/3: что видно без расшифровки

HTTP/2 поверх TLS и HTTP/3 поверх QUIC шифруют полезную нагрузку. Но их поведение прочитывается по метаданным потоков и графам I/O.

Wireshark умеет отмечать открытие/закрытие потоков, RST, приоритизацию и масштабы одновременности. Для HTTP/3 полезна связка quic и http3 фильтров и статистика «Conversations»: смещения пакетов, потери, тайминги передачи ключей. Даже без содержимого заголовков видно, сколько параллельных запросов шли, где залип RST_STREAM, и сколько миллисекунд заняла отдача тела ответа. В инфраструктуре с прокси полезно сравнивать граф I/O до и после прокси: рассыпание пика на входе и ступени на выходе — верный знак насыщения очереди.

Практический сценарий: медленное приложение и где теряются секунды

Диагностика «медленно открывается страница» сводится к измерению: сколько занял DNS, handshake, TLS, первый байт, тело ответа. Сопоставив их, легко увидеть узкое место.

История повторяется: пользователь запускает страницу, «индикатор крутится», а в серверных логах — тишина. Захват на клиенте показывает: DNS‑запросы ушли в два адреса, первый ответил через 280 мс, второй — через 5 мс; клиент выбрал первый. Затем SYN‑SYN/ACK с RTT 20 мс, TLS 1.3 с ALPN h2 за 60 мс, потом запрос, и только через 1.8 с пришёл первый DATA‑кадр. В это время I/O Graph по серверу демонстрирует ступенчатый выход трафика. Сопоставив метки времени, становится ясно: сервер держал соединение, но ждал ответ бэкенда. Сеть невиновна, но доказательство — в пакетах: ретрансмиссий нет, окно стабильно, dupACK не штампуются, TLS не переторговывает ключи.

Тайминг как сюжет: время до первого байта, серверные паузы

Ключ в последовательности меток времени: DNS → TCP → TLS → TTFB → длина тела. Если какая‑то ступень нелинейна, там и искать.

Профессиональный рефлекс — первое дело закладывать маркеры времени. В Wireshark это делается и визуально (колонки delta, delta displayed), и аналитически (http.time, tcp.analysis.ack_rtt). Когда TTFB велик, но DNS/TCP/TLS малы, ответственность лежит за гранью сети. Когда TLS тянется, просматривается проблема ALPN, промежуточного прокси с инспекцией или истёкших сессий. Если TCP постоянно уходит в retransmission без снижения окна, на коммутаторе зреет перегрузка. Полезно сводить граф «Time‑Sequence (tcptrace)» к нарративу: ровный наклон — плавная передача; ступени — очереди; отвесы вниз — потери.

Flow Graph, I/O Graphs и Time‑Sequence Graph в роли хронометриста

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

Flow Graph показывает кто с кем говорил и как шло рукопожатие; им удобно сверять «уже было соединение или каждый раз по новой». I/O Graphs добавляют слой интенсивности: так видны bursts, «пилы», провалы на уровне десятков миллисекунд. Time‑Sequence Graph переводит дискуссию о TCP в геометрию линий: диагонали, плато, обрывы. На одном экране видно, где передатчик упёрся в окно, а где получатель закрыл заслонку. Наконец, «Expert Information» ловит нетипичные явления: «Previous segment not captured», «Spurious retransmission», «ACKed unseen segment» — метки, к которым тянется рука, когда устали глаза.

1. Снять захват на клиенте и/или на сервере с синхронным временем;
2. Проверить DNS: rcode, задержки, дубликаты запросов;
3. Оценить TCP: RTT, MSS, SACK, scaling, retrans/dupACK;
4. Замерить TLS: время рукопожатия, ALPN, повторы HRR;
5. Посчитать TTFB и разложить тело ответа на сегменты;
6. Свести графы I/O и Time‑Sequence к общей линии времени;
7. Сопоставить вывод с логами сервера и прокси, чтобы закрепить диагноз.

Командная строка, профили и автоматизация: TShark, dumpcap, кольцевой буфер

Графический интерфейс — для чтения. Для съёма и рутины удобнее TShark и dumpcap с кольцевым буфером, профилями и преднастроенными фильтрами.

Когда инцидент живёт своей жизнью в проде, записывать «вручную» рискованно. dumpcap, запущенный от имени службы, без декодирования (только запись), потребляет минимум ресурсов. Кольцевой буфер сохраняет последние N файлов по M мегабайт, что позволяет вернуться в прошлое, не переполняя диск. TShark берёт на себя извлечение статистики, экспорт в JSON/CSV и автоматическую разметку. Профили Wireshark — это сохранённые фильтры, цвета и колонки, которые задают одинаковую оптику команде: когда один и тот же pcap читается по одним и тем же правилам, шансов на согласованный диагноз больше.

Репродукция инцидента без переполнения диска

Кольцевой буфер — страховка. Он держит окно последних минут или часов и не даёт логам и pcap съесть файловую систему.

Практическая схема: dumpcap -i eth0 -b filesize:100 -b files:20 -f «tcp port 443» -w /var/capture/ssl.pcap. Такой набор оставляет двадцать файлов по 100 МБ, чего достаточно для «промотки» на десятки минут назад в типичных HTTP‑нагрузках. Когда сигнал инцидента поступает из мониторинга, достаточно скопировать пару последних файлов и уже в спокойной обстановке разобрать с помощью Wireshark и TShark, оставив продовый захват крутиться дальше. На серверах с высокой скоростью полезно включать PF_RING или аналог, чтобы минимизировать потери в драйвере.

Экспорт и анонимизация: что передавать в тикет безопасно

Передача pcap за периметр требует дисциплины. Личная информация и секреты не должны уехать вместе с полезной частью следствия.

Wireshark и editcap позволяют вырезать куски по времени, отбрасывать полезную нагрузку (—s snaplen), а также обнулять поля, по которым можно deanonymize. В деликатных кейсах легче договориться об экспорте статистики: Conversations, Endpoints, Expert Info, графы I/O. Для TLS — предпочтителен key log вместо приватных ключей; в некоторых юрисдикциях это критично. Если нужно передать содержимое HTTP, «Export Objects» поможет вытащить ровно те файлы, что нужны для воспроизведения бага, без фона всей сессии. Побочным бонусом становится дисциплина: появляясь на ревью, pcap больше похож на доказательство, чем на бесформенный слепок эфира.

FAQ: частые вопросы по анализу трафика в Wireshark

Как понять, что виновата сеть, а не приложение?

Если TCP стабилен (нет ретрансмиссий, окно не схлопывается, RTT ровный), TLS короткий, а TTFB велик — задержка за пределами сети. Наоборот, пики retrans/dupACK и провалы I/O укажут на потери и перегрузки в канале.

Полезно сопоставить Time‑Sequence Graph с логами приложения: если «провал» по наклону совпадает со всплеском GC, blame переключается на код. Если на графе всё ровно, а задержка рождается до первого DATA, причина чаще в прокси/инспекции или в медленном резолвинге.

Можно ли увидеть содержимое TLS без ключей?

Полное содержимое — нет. Но ключевой лог (SSLKEYLOGFILE) позволит расшифровать сессии и получить видимость HTTP. Без него доступен тайминг рукопожатия, ALPN и метаданные потоков.

В случаях, когда кейлог недоступен, остаются косвенные признаки: длина и частота фреймов, интервалы между ClientHello и Finished, повторы HRR. Этого достаточно, чтобы отделить сетевые задержки от серверных пауз после расшифровки.

Как ловить проблему, которая возникает раз в сутки?

Съём в кольцевой буфер с триггерами. dumpcap записывает «вечно», мониторинг сигналит о событии — сохраняются нужные минутные файлы для анализа.

Хорошая добавка — TShark, который по cron сохраняет Conversations и Expert Info в CSV. Так инцидент не проскочит между сменами, а pcap не сожрёт диск.

Почему в pcap нет части сегментов TCP?

Захват делался не на той стороне или зеркалирование потеряло кадры. «Previous segment not captured» — прямое указание на неполноту.

Стоит проверить SPAN под нагрузкой, поменять на TAP, включить promiscuous и сократить фильтр. Для виртуальных сетей — перепроверить offload и gro/lro настройки.

Чем отличается задержка сети от backpressure на получателе?

При задержке сети растут ретрансмиссии и dupACK при стабильном окне; при backpressure окно сжимается до нуля и растягиваются паузы между Window Update.

Граф Time‑Sequence даёт геометрию: «зубцы» вниз — потери; длительные горизонтали — закрытое окно. Это два разных ритма, их трудно перепутать.

Как анализировать HTTP/3, если всё зашифровано?

Смотреть на QUIC: потери, тайминг ключей, количество и длительность потоков. Даже без расшифровки видны ритм и ошибки транспортного уровня.

Дополняют картину сравнение I/O до/после прокси и метки Expert Info. Если доступен ключевой лог, Wireshark декодирует HPACK/QPACK и вернёт подробности ответов.

Когда достаточно NetFlow, а когда нужен pcap?

NetFlow годится для трендов и объёмов, pcap — для судебной экспертизы миллисекунд. Как только требуется «что именно произошло», без pcap не обойтись.

Часто связка идеальна: NetFlow ловит всплеск и отдаёт координаты времени/узлов, pcap отвечает на вопрос «почему» и «в каком пакете». Так бюджет тратится экономно, а глубина — там, где без неё нельзя.

Итоги и короткая инструкция к действию

Wireshark — это не набор кнопок, а способ думать о сети как о последовательности причин и следствий. Точка захвата, фильтры, хронометраж, графы, расшифровка — пять шагов, которые складываются в дисциплину чтения пакетов. Когда они отточены, даже странные сбои теряют мистику и превращаются в рабочие задачи.

Чтобы превратить инструмент в привычку, полезно закрепить минимальный ритуал. Он начинается с правильного места захвата и заканчивается тем, что в тикет уезжает не «подозрение на сеть», а обоснованный разбор с кадрами‑уликами, где время пронумеровано, а вывод можно перепроверить.

1. Определить точку съёма: клиент, сервер или зеркало; включить promiscuous и синхронизацию времени.
2. Запустить dumpcap с кольцевым буфером и умеренным BPF, чтобы не потерять контекст.
3. В момент инцидента пометить интервал и сохранить релевантные файлы pcap.
4. Открыть в Wireshark профиль диагностики: нужные колонки, цвета, display‑фильтры.
5. Пройти путь DNS → TCP → TLS → HTTP/QUIC, фиксируя тайминги и аномалии.
6. Свести графы Flow/I‑O/Time‑Sequence в единый сюжет и подтвердить вывод логами.
7. Подготовить артефакты: обрезанный pcap, статистику Conversations и краткий отчёт с метками времени.

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