Ping идеальный, а программа тормозит: как я ищу сетевой сбой в Wireshark

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

Когда Wireshark нужен, а когда нет

Когда «программа тормозит», а ping показывает ровные 18 мс, спор между провайдером, разработчиком и администратором может идти неделями. Я использую Wireshark, чтобы заменить мнения последовательностью пакетов: кто запросил, кто ответил, где возникла пауза и на каком участке пропали данные. В обслуживании офисных сетей это один из самых быстрых способов закончить спор фактами.

Но открываю я его только после того, как сформулирован проверяемый вопрос. Не «почему сеть плохая», а «почему рабочая станция 10.20.1.47 ждёт ответа сервера 10.10.0.20 по TCP/443 с 10:15 до 10:30». Без адресов, времени и воспроизводимого действия дамп превращается в сотни тысяч цветных строк, где можно найти что угодно и не доказать ничего.

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

Главная ловушка новичка — считать каждый красный или чёрный пакет доказательством аварии. Руководство Wireshark прямо называет Expert Information подсказками, а не диагнозом. TCP Retransmission, Out-Of-Order и неверная контрольная сумма возникают и из-за места захвата, и из-за старта записи посреди соединения, и из-за аппаратной разгрузки на самой машине — подробно про то, почему tcpdump показывает incorrect checksum у исходящих пакетов, я писал отдельно. Сначала сравниваю две точки, потом делаю вывод.

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

• Зафиксировать симптом одним предложением
• Записать IP клиента, IP сервера, порт и точное время
• Воспроизвести одну операцию на плохом и исправном месте
• Сверить дамп со счётчиками интерфейсов и журналами оборудования

Где снимать трафик: рабочая станция, SPAN или шлюз

В коммутируемой сети ноутбук в соседней розетке не увидит чужой unicast-трафик, даже в promiscuous mode. Поэтому варианта три: захват на проблемной рабочей станции, зеркалирование нужного порта на управляемом коммутаторе или захват на шлюзе. Для первого подхода чаще выбираю рабочую станцию: быстрее, меньше постороннего трафика, понятнее направление. Многие роутеры умеют снимать дамп сами — как это делается, например, на маршрутизаторах Huawei за минуту, я разбирал на отдельном примере.

Когда нужно понять, где именно теряется пакет, одного дампа мало. Ставлю две точки: у клиента и за подозрительным участком, например на сервере в основном офисе. Часы синхронизирую по NTP и записываю один короткий тест. Пакет есть в первой записи и нет во второй — участок поиска резко сужается. Определять место потери по единственному tcp.analysis.retransmission я считаю гаданием.

У SPAN есть ограничение, о котором постоянно забывают: сумма зеркалируемого входящего и исходящего трафика может превысить скорость порта назначения. Тогда пакеты выбросит само зеркало, а Wireshark покажет пропуски, которых в сети нет. Я зеркалирую один порт на короткое время, проверяю число потерянных пакетов в свойствах захвата и не использую порт назначения для обычной сети. Ещё одна тонкость: кадры с ошибкой FCS коммутатор обычно отбрасывает и в зеркало не отправляет, так что битые кадры в дампе вы не увидите.

Дамп содержит DNS-имена, токены, незашифрованные запросы, файлы и персональные данные. Статьи 7 и 19 закона № 152-ФЗ требуют обеспечивать конфиденциальность и принимать меры защиты персональных данных. Поэтому я заранее согласую цель и окно работ, ограничиваю адреса фильтром, храню pcapng в закрытой папке, передаю только нужный фрагмент и удаляю рабочие копии по регламенту компании.

• Рабочая станция — старт для проблемы одного пользователя
• SPAN на коммутаторе — когда нужен участок или несколько устройств
• Шлюз или VPN-маршрутизатор — когда подозрение на связь между площадками
• Две синхронные точки — когда нужно локализовать потерю

Как снять дамп dumpcap и tcpdump, не забив диск

На Windows для короткого теста использую графический интерфейс, а для ожидания плавающей ошибки — dumpcap из комплекта Wireshark. Сначала узнаю номер интерфейса, потом включаю кольцевой буфер: десять файлов по 50 000 кБ ограничивают объём примерно 500 МБ, старые файлы перезаписываются. -B 32 задаёт буфер захвата 32 МиБ (по умолчанию 2 МиБ): сеть это не ускоряет, но помогает пережить короткий всплеск без потерь на записывающей машине.

dumpcap.exe -D
dumpcap.exe -i 3 -f "host 10.10.0.20 and tcp port 443" -B 32 -b filesize:50000 -b files:10 -w "D:\Captures\branch.pcapng"

Фильтр после -f — capture filter на языке libpcap, он отбрасывает лишнее до записи на диск. Номер 3 нельзя копировать вслепую: на другом ноутбуке интерфейсы перечислятся иначе. На Linux-сервере вторую точку снимаю tcpdump с тем же принципом кольца: -C задаёт размер файла в миллионах байт, -W — число файлов.

tcpdump -i ens18 -n -w /var/tmp/srv.pcap -C 50 -W 10 'host 10.20.1.47 and tcp port 443'

У Wireshark два разных языка фильтрации, и это самая частая бытовая ошибка. При захвате пишут host 10.10.0.20 and tcp port 443, после открытия файла — ip.addr == 10.10.0.20 && tcp. Display filter ничего не удаляет из файла, а лишь скрывает строки. Поэтому при неизвестной причине не делаю capture filter слишком узким: вместе с шумом можно вырезать ICMP, DNS или ARP, которые и объясняют сбой. Обрезать пакеты через snapshot length тоже можно, но осознанно: обрезанное уже не восстановить, а разбор TLS handshake может стать невозможен.

• Проверить интерфейс по меняющемуся счётчику и IP-адресу
• Закрыть лишние приложения на диагностическом ноутбуке
• Записать время нажатия кнопки, вызывающей зависание
• После остановки проверить dropped packets и размер файлов

Как читать дамп: от разговора к задержке

Начинаю не с отдельных кадров, а с Statistics → Conversations: кто с кем обменивался, сколько байт и как долго. Выделяю нужный TCP-разговор и применяю conversation filter. В Analyze → Expert Information смотрю подсказки, потом возвращаюсь к потоку через Follow → TCP Stream. Такой порядок быстрее пролистывания и работает даже у администратора, который не помнит все флаги TCP. Мой базовый набор display filters невелик:

ip.addr == 10.10.0.20 && tcp
tcp.analysis.retransmission || tcp.analysis.fast_retransmission || tcp.analysis.spurious_retransmission
tcp.flags.syn == 1 && tcp.flags.ack == 0
dns.flags.response == 1 && dns.time > 0.2

Первый оставляет обмен с сервером, второй показывает предполагаемые повторные передачи, третий — начала соединений без SYN/ACK, четвёртый — ответы DNS дольше 200 мс. Порог 200 мс — мой рабочий сигнал для офисной сети, а не стандарт. Дальше временная линия. Долгая пауза между SYN и SYN/ACK указывает на путь, firewall или перегруженный узел. Быстрый handshake и пауза после запроса чаще ведут к приложению или базе. Серия duplicate ACK и повтор одного сегмента говорят о потере или переупорядочивании, но не о том, где это произошло. Нулевое окно означает, что получатель просит притормозить, и ругать провайдера здесь рано.

Для повторяемого отчёта использую TShark. Первая команда строит секундные интервалы с числом отмеченных ретрансмиссий, вторая — сводку TCP-разговоров. Так к заявке прикладывается не «на глаз много чёрных строк», а время всплеска, число кадров, адреса и сопоставление с действием пользователя.

tshark.exe -n -q -r branch.pcapng -z "io,stat,1,tcp.analysis.retransmission"
tshark.exe -n -q -r branch.pcapng -z conv,tcp

• Conversations — найти нужную пару узлов
• Expert Information — гипотезы, а не диагноз
• Follow TCP Stream — последовательность конкретного обмена
• I/O Graphs или TShark — связать всплеск со временем события

Разбор из практики: «Оздоровительная гавань» и один плохой патч-корд

Оздоровительный центр «Оздоровительная гавань», 16 рабочих мест: основная площадка на 11 мест и студия на 5 мест в другом здании. Администраторы обеих площадок работают в веб-системе онлайн-записи и карт клиентов, которая крутится на Linux-сервере основной площадки; студия ходит к ней через VPN-туннель между маршрутизаторами. В студии открытие карточки клиента занимало 8–20 секунд, а загрузка фото и документов иногда срывалась с повторной попыткой. На основной площадке та же операция укладывалась в 1,1–1,7 секунды. Сто ping-запросов показывали в среднем 17,8 мс и ноль потерь, поэтому провайдер считал канал исправным.

На диагностическом ноутбуке с Windows 11 стояли Wireshark 4.6.8 и Npcap 1.88. На управляемом коммутаторе студии я зеркалировал только порт маршрутизатора, вторую точку снимал tcpdump на сервере. Пятнадцать минут администратор пять раз открывал одну карточку и загружал тестовый файл. Кольцо было настроено по схеме выше; набор из студии занял 187 МБ и 241 тысячу кадров.

В дампе студии клиентские TCP-сегменты уходили вовремя, но часть из них не доходила до сервера. В проблемном разговоре Wireshark отметил 3 120 предполагаемых повторных передач среди примерно 118 тысяч TCP-сегментов — около 2,6 %, а в секунды загрузки доля подскакивала до 9–12 %. Одновременно счётчик порта между коммутатором и маршрутизатором вырос на 6 912 ошибок FCS/CRC за 22 минуты. Сам Wireshark битых кадров не показал — коммутатор отбрасывал их до зеркала. Именно поэтому я всегда сверяю pcap со статистикой порта.

Мы заменили короткий патч-корд между коммутатором и маршрутизатором, промаркировали резервный и повторили ровно те же пять операций. Новых CRC-ошибок не появилось, доля ретрансмиссий в сопоставимом трафике упала до 0,04 %, карточка открывалась за 1,2–1,8 секунды, загрузки прошли без повторов. Сервер, VPN и тариф менять не пришлось. Вся работа заняла полдня выезда и час на отчёт — против трёх недель переписки с провайдером до этого. Хороший ping не опровергает кратких потерь под нагрузкой, а Wireshark без счётчиков оборудования физическую причину не назвал бы.

• До: 8–20 секунд на карточку, ретрансмиссии до 9–12 % в пиках
• Подтверждение: 6 912 ошибок FCS/CRC за 22 минуты на одном порту
• Исправление: замена и маркировка патч-корда, повтор идентичного теста
• После: 1,2–1,8 секунды, новых CRC нет, ретрансмиссии около 0,04 %

Типовые находки в офисной сети и как они выглядят в дампе

За годы у меня сложился короткий список причин, которые встречаются в офисах до 50 мест чаще остальных. Первая — физика: плохой патч-корд, разъём или порт, дуплекс, согласованный не так на одной из сторон. В дампе это ретрансмиссии без явной закономерности, а на порту — растущие CRC и FCS. Вторая — MTU на VPN-туннеле. Маленькие пакеты проходят, ping идеальный, а большие молча теряются, если ICMP «требуется фрагментация» где-то режется. Признак в дампе: handshake и короткие запросы проходят, а на передаче крупных сегментов соединение замирает и повторяет один и тот же полноразмерный сегмент.

Проверить MTU можно без Wireshark, командой ping с запретом фрагментации: в Windows это ping -f -l 1472 10.10.0.20, где 1472 байта данных плюс 28 байт заголовков дают 1500. Если ответ «требуется фрагментация» или тишина, уменьшайте размер, пока не пройдёт, и сравните с MTU туннеля. Третья частая причина — медленный или недоступный DNS: фильтр dns.flags.response == 1 && dns.time > 0.2 сразу показывает, какие имена резолвятся долго. Четвёртая — DHCP: при жалобе «утром нет сети» фильтр dhcp показывает, дошли ли Discover и Offer и кто ответил, если в сети появился второй сервер DHCP.

Пятая — перегрузка канала. Здесь дамп показывает не потери, а рост задержек и очередей, а I/O Graph — упор в полосу в момент жалобы. Решается это не заменой оборудования, а ограничением фоновых задач: резервного копирования, обновлений, облачной синхронизации в рабочие часы. Во всех пяти случаях правило одно: дамп даёт гипотезу, а подтверждает её второй независимый источник — счётчик порта, журнал DHCP-сервера, график загрузки канала.

• Физика: ретрансмиссии + растущие CRC на порту
• MTU на VPN: маленькие пакеты проходят, большие теряются
• DNS: `dns.time > 0.2` показывает медленные имена
• DHCP: фильтр `dhcp` и второй сервер в сети
• Перегрузка: задержки и упор в полосу на I/O Graph

Что делать, если сбой плавающий, а трафик зашифрован

Если сбой воспроизводится, не начинайте с покупки нового маршрутизатора. Попросите сотрудника записать точное время, действие и имя рабочего места. Администратор проверяет загрузку интерфейсов, ошибки портов и делает короткий захват на проблемном узле. В половине затяжных расследований, которые доходят до меня, время теряется именно до этого шага: все обсуждают ощущения, никто не фиксирует событие.

Wireshark особенно полезен при плавающих обрывах, медленном DNS, повторных передачах, странных сбросах соединения, проблемах DHCP и различиях между площадками. Он слабее там, где уже видна стопроцентная загрузка процессора сервера, закончился диск или приложение само пишет понятную ошибку. Если тормозит учётная система, сначала проверьте сервер и запросы — как это делается для 1С, я описывал в методике диагностики, которая находит причину за пару часов.

TLS не делает диагностику бесполезной. Без расшифровки видны адреса, время handshake, размеры, направления, ретрансмиссии, RST и паузы — для сетевых проблем этого почти всегда хватает. Если нужен прикладной уровень, я использую временный key log тестовой сессии: браузер пишет сеансовые ключи в файл, указанный в переменной окружения SSLKEYLOGFILE, а Wireshark подхватывает их в настройках протокола TLS. Закрытый ключ сервера никому не передаю. Key log и внедрённые в pcapng секреты храню как учётные данные и удаляю после работы.

Критерий завершения простой: причина подтверждена минимум двумя независимыми признаками, исправление внесено, тот же тест повторён, метрики в норме, временный захват остановлен. Не превращайте Wireshark в круглосуточный мониторинг малого офиса. Для постоянного контроля есть SNMP, журналы, метрики каналов и оповещения; анализатор пакетов я достаю, когда они уже сузили время и место.

• Сначала факт и время, затем захват
• Сначала один узел и один поток, затем расширение области
• Сначала подтверждение второй точкой или счётчиком, затем замена железа
• После исправления — обязательный повтор исходного теста

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