Wireshark и tcpdump для диагностики офисной сети в 2026

Меня зовут Семёнов Евгений Сергеевич, и я директор АйТи Фреш. Могу вам сказать, что за все 15 лет обслуживания московских офисов я не припомню ни одного месяца без вопросов вроде «а почему у нас 1С тормозит?» или «почему в переговорной голос по IP-телефонии дрожит?». И что удивительно, в 80% случаев ответ мы находим с помощью Wireshark, причём всего за 15–30 минут. Здесь я поделюсь, как именно мы диагностируем типичные офисные проблемы у наших клиентов — никаких заумных теорий на 50 страниц, только то, что реально работает на практике.

Почему ping и «всё нормально у провайдера» — не диагностика

Типичный сценарий: клиент жалуется «медленно открывается 1С». Что делает обычный хелпдеск? Пингует сервер, видит time<1ms, звонит провайдеру, слышит «у нас всё в порядке» — и разводит руками. Проходит неделя, жалобы копятся, директор уже на стенку лезет.

А причина, как правило, кроется в ретрансмиссиях TCP, которые на уровне ICMP вообще не видны. Или, бывает, виноват кривой DNS, который умудряется резолвиться по 3 секунды вместо положенных 30 миллисекунд. Ну и не стоит забывать про антивирус на файловом сервере, который тщательно сканирует каждый открытый документ. Обычным пингом, трассировкой или даже счётчиками интерфейсов такое не поймаешь. Здесь спасает только детальный анализ пакетов.

Вот мои три незаменимых инструмента, без которых я вообще на выезд не отправляюсь: это tcpdump — его использую на серверах и сетевом оборудовании для быстрого захвата трафика; Wireshark — он всегда со мной на ноутбуке для углублённого анализа; и tshark, то есть консольный Wireshark, который идеально подходит для скриптов и автоматизации. И что самое приятное — всё это абсолютно бесплатно и успешно работает аж с 2006 года.

Быстрый захват на сервере через tcpdump

Если проблема на стороне сервера (1С, файловый, почта), я захожу по SSH и сразу снимаю трафик — никаких GUI на проде, только tcpdump. Чаще всего хватает трёх команд:

# Захватить трафик конкретного клиента
tcpdump -i eth0 -w /tmp/client.pcap -s 0 host 10.10.20.15

# Захватить только обращения к 1С (порт TCP/1541)
tcpdump -i eth0 -w /tmp/1s.pcap -s 0 tcp port 1541

# Захватить всё, кроме SSH (чтобы не шумела своя сессия)
tcpdump -i eth0 -w /tmp/all.pcap -s 0 -C 100 -W 5 not port 22

# Живой анализ через SSH на свой ноут с Wireshark
ssh root@server "tcpdump -i eth0 -w - -s 0 not port 22" | wireshark -k -i -

Флаг -s 0 — захват полного пакета без обрезки (по умолчанию tcpdump обрезает до 262144 байт, что для диагностики payload недостаточно). Флаг -w file.pcap пишет в формат, совместимый с Wireshark. -C 100 -W 5 — ротация по 100 МБ и 5 файлов, чтобы не забить диск. Последняя команда — мой любимый трюк: захват на удалённом сервере, а окно Wireshark открывается локально, в реальном времени.

Capture и display фильтры — главная магия

В Wireshark есть два совершенно разных языка для фильтров, и знаете, путаница между ними — это, наверное, источник половины всех ошибок. Capture filters, использующие синтаксис BPF, срабатывают ещё на этапе захвата: если пакет не соответствует фильтру, он просто не попадёт в итоговый файл. А вот Display filters, с их собственным синтаксисом Wireshark, работают уже с тем трафиком, который вы захватили: они могут показать или скрыть нужные пакеты, но при этом ничего не удаляют из самого дампа.

Правило простое: capture filter — когда заранее знаешь, что ищешь, и не хочешь забивать диск. Display filter — когда крутишь готовый дамп. В офисной диагностике чаще нужны именно display filters: собрали «всё подряд», а потом смотрим под разными углами:

# === Display filters — вбивайте в строку фильтра в GUI Wireshark ===

# Только трафик между клиентом и сервером 1С
ip.addr == 10.10.20.15 and ip.addr == 10.10.30.10 and tcp.port == 1541

# Показать проблемы TCP (ретрансмиссии, дубликаты, окно 0)
tcp.analysis.flags

# Медленные DNS-ответы
dns.time > 0.2

# HTTP-ошибки 4xx и 5xx
http.response.code >= 400

# TLS handshake — видеть, на чём залипает SSL
tls.handshake

# SIP-сообщения (IP-телефония)
sip

# RTP-пакеты (голосовой поток)
rtp

# RDP-трафик (порт 3389)
tcp.port == 3389

Кейс 1: 1С тормозит — ретрансмиссии TCP

Звонок из логистической компании на Варшавке: «1С открывается минуты три, иногда виснет». Ping до сервера — 0.3 мс, у провайдера всё в порядке, на коммутаторе — ноль ошибок. Стандартный ступор. Приехал, подключился к свитчу, настроил SPAN-порт на сервер 1С, запустил на ноутбуке Wireshark. Через 5 минут картина такая:

# Вбиваю в display filter:
tcp.analysis.retransmission or tcp.analysis.fast_retransmission

# Результат: 340 ретрансмиссий за минуту при обычной нагрузке
# Нормальный показатель — меньше 0.1% от общего числа TCP-пакетов

Следующий шаг — смотрю Expert Info (Analyze → Expert Information). Видно, что ретрансмиссии идут в обе стороны от одного конкретного коммутатора на 3-м этаже. Пошёл туда: из серверной к этажу идёт патч-корд, кем-то пережатый в дверной косяк, на коннекторе половина жил окислена. Заменил патч-корд за 5 минут и 200 руб. — жалобы прекратились. 1С стала летать.

Без Wireshark мы бы этот несчастный кабель, наверное, полгода искали! Списывали бы всё то на провайдера, то на якобы «устаревший сервер». А тут что? Захват трафика, каких-то 15 минут анализа — и вуаля! Это помогло нам сэкономить 200 тыс. руб., которые могли бы уйти на совершенно бесполезные апгрейды.

Кейс 2: IP-телефония хрипит — джиттер RTP

Представьте: адвокатская контора прямо в центре города, 25 сотрудников. Они установили себе 3CX с SIP-транком. Прошёл всего месяц, и тут начались проблемы: голос дрожит, собеседники постоянно жалуются на эхо, да ещё и периодические обрывы связи. Админ клиента, бедняга, что только не делал: менял провайдера, покупал новые гарнитуры, перепрошивал все IP-телефоны — всё безрезультатно. В итоге меня позвали уже как последнюю надежду.

Я сразу же установил Wireshark на свой ноутбук, подключил порт в SPAN с IP-телефонов, затем сделал тестовый звонок и сохранил весь дамп. Потом оставалось только открыть фильтры специально для анализа голосового потока.

# 1. Все RTP-пакеты от телефона
rtp and ip.src == 10.10.50.12

# 2. Открываю Telephony → RTP → RTP Streams
# Смотрю колонки Max Jitter, Max Delta, Lost Packets

Wireshark показал: джиттер до 45 мс (норма — до 20 мс), потери пакетов 2.3% (норма — меньше 0.5%). Причина — VoIP-трафик шёл без приоритизации, и на линке пересекался с большими файлами, которые сотрудники шарили между папками. Решение: настроили QoS на Mikrotik с приоритетом DSCP EF для RTP-пакетов, выделили голосовому трафику гарантированные 20% полосы. Через час жалобы прекратились навсегда.

Главная фишка Wireshark, на мой взгляд, в том, что он не просто выводит сухую статистику. Он ещё и позволяет проиграть голос прямо из дампа! Для этого нужно пройти по пути: Telephony → VoIP Calls → Play Streams. И что самое крутое — вы слышите ровно то же, что и ваш клиент. Это просто бесценная штука, особенно когда нужно объяснить техническую проблему директору, который далёк от IT.

Кейс 3: медленный RDP — tcp window full

Вот ещё случай: офис, где работают 40 юристов, и все они подключаются к терминальному серверу по RDP. Жалобы были такие: «курсор тормозит», «окна рисуются рывками», а «печатаешь букву — и она появляется только через секунду». При этом ping до сервера показывал идеальную 1 мс. Смотрим на сервер: CPU загружен всего на 25%, памяти полно, диск не забит. Ну, просто классический тупик!

Делаю захват прямо на сервере:

ssh admin@rdp-server "sudo tcpdump -i eth0 -s 0 -w - tcp port 3389 and host 10.10.10.45" \
  | wireshark -k -i -

# Display filter в Wireshark:
tcp.analysis.window_full or tcp.analysis.zero_window

Картина: window=0 от клиента несколько раз в секунду. То есть клиентский ПК не успевает разбирать входящий поток RDP — проблема на клиенте, не на сервере. Пришёл к клиенту, посмотрел диспетчер задач — а там процесс антивируса съедает 90% CPU, потому что включена проверка сетевого трафика в реальном времени. Отключили сетевой модуль в антивирусе (политиками GPO на всех ПК разом) — RDP залетал как новый.

Кейс 4: почему не открывается сайт «только у нас»

Это прямо классика жанра: сотрудники вдруг начинают жаловаться, что у них не открывается какой-то определённый сайт — например, mos.ru, банк-клиент или портал госзакупок. При этом у всех остальных всё прекрасно работает! К счастью, алгоритм диагностики с помощью Wireshark в таких случаях занимает от силы минут пять.

# 1. Запускаем захват на ПК пользователя
# Display filter:
ip.addr == 

# 2. Смотрим последовательность:
# - DNS-запрос (udp.port == 53) → ответ получен? Правильный IP?
# - TCP SYN → пришёл SYN-ACK от сервера? Или RST?
# - TLS ClientHello → есть ServerHello? Или разрыв?

Варианты, что вижу чаще всего:

• DNS не резолвится — запрос уходит, ответа нет. Проверяю, какой DNS-сервер настроен (обычно криво настроенный внутренний DNS). Меняю на 1.1.1.1 или Яндекс 77.88.8.8.
• SYN уходит, SYN-ACK не приходит — блокировка на файрволе офиса или у провайдера. Смотрю правила на Mikrotik, если там — снимаю, если у провайдера — звоню им с конкретными данными из дампа.
• TLS обрывается на ClientHello — подозрение на DPI провайдера (привет, РКН). Решается переездом сайта через VPN или сменой провайдера для критичных сотрудников.
• TCP-соединение устанавливается, но данных не идёт — MTU mismatch. Ставлю mss=1400 на интерфейсе Mikrotik — и полетело.

TShark для автоматизации мониторинга

Wireshark, конечно, отлично подходит для ручного, детального разбора. Но если возникает потребность постоянно мониторить состояние сети, то мы подключаем tshark в паре с cron. Например, у нас в АйТи Фреш на объектах ключевых клиентов всегда работает вот такой скрипт для мониторинга качества сети.

#!/bin/bash
# net_health.sh — ежеминутный замер здоровья сети
# Запускается из cron каждую минуту

IFACE="eth0"
DURATION=30

# Захват 30 секунд
tshark -i $IFACE -a duration:$DURATION -w /tmp/probe.pcap 2>/dev/null

# Подсчёт ретрансмиссий
RETRANS=$(tshark -r /tmp/probe.pcap -Y "tcp.analysis.retransmission" 2>/dev/null | wc -l)

# Подсчёт window=0
ZEROWIN=$(tshark -r /tmp/probe.pcap -Y "tcp.analysis.zero_window" 2>/dev/null | wc -l)

# DNS-проблемы
SLOWDNS=$(tshark -r /tmp/probe.pcap -Y "dns.time > 1.0" 2>/dev/null | wc -l)

# Если ретрансмиссий больше 100 за 30 секунд — алерт
if [ $RETRANS -gt 100 ] || [ $ZEROWIN -gt 20 ] || [ $SLOWDNS -gt 5 ]; then
    curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
         -d chat_id="${CHAT_ID}" \
         -d text="ALERT: retrans=$RETRANS, zerowin=$ZEROWIN, slowdns=$SLOWDNS"
fi

rm -f /tmp/probe.pcap

Скрипт висит на Mikrotik через container (или на отдельной виртуалке в серверной), раз в минуту собирает показатели, сравнивает с порогами и присылает алерт в Telegram. Если ретрансмиссии полезли — инженер узнаёт до того, как юзеры напишут в поддержку.

Грабли, на которые наступают все

За годы практики у меня накопился топ ошибок при анализе трафика. Вот что стоит запомнить новичкам:

1. Смотреть трафик только с одной точки. Если проблема между двумя устройствами, захватывайте одновременно на обоих концах. Часто оказывается, что с одной стороны пакет отправлен, а с другой не пришёл — и только сравнение двух дампов это показывает.
2. Забывать флаг -s 0. Без него tcpdump обрезает пакеты, и в дампе не видно payload — не разобрать ни HTTP-запросы, ни SIP-заголовки, ни TLS handshake.
3. Путать capture и display фильтры. Вбиваете в строку захвата tcp.port == 80 — и ничего не захватывается, потому что правильный синтаксис BPF — tcp port 80 без точки и без двойного равенства.
4. Гонять Wireshark на промышленном сервере. GUI Wireshark жрёт память и ресурсы. На продакшене только tcpdump в файл, анализ — на ноутбуке.
5. Не настраивать port mirroring на коммутаторе. Без SPAN на управляемом свитче вы увидите только трафик своего ПК + broadcast. Анализировать трафик других устройств так не получится.

Что у нас в АйТи Фреш под капотом

На каждом объекте, который мы обслуживаем, у нас развернута специальная виртуалка с полным набором диагностических инструментов. Туда входят: tcpdump, tshark, ntopng (удобный веб-интерфейс для анализа трафика), Suricata (это IDS для обнаружения атак), а также Arkime, который раньше назывался Moloch, — это мощное хранилище pcap-дампов с удобным поиском. Весь трафик с ключевых портов свитча зеркалируется к нам через SPAN и хранится в течение недели.

Так что, когда клиент звонит и, к примеру, жалуется: «Вчера в 15:20 у нас упала связь», — мы не начинаем разводить руками. Вместо этого мы спокойно открываем Arkime, быстро находим это точное время и видим, что именно происходило в сети. И это не какая-то дополнительная опция, а полноценная часть нашего абонентского обслуживания, включённая в тарифы «Стандарт» и «Премиум».

FAQ — частые вопросы по Wireshark и tcpdump

Нужны ли права администратора для Wireshark?

Для захвата трафика — да. На Windows это решается установкой с Npcap, на Linux — добавлением пользователя в группу wireshark через usermod -aG wireshark $USER. Чтение готовых .pcap-файлов прав не требует — можно открывать на любой машине.

Можно ли перехватить чужой трафик в офисной сети?

На современных коммутаторах — нет, трафик идёт только между отправителем и получателем. Для захвата чужого трафика нужен port mirroring (SPAN) на управляемом коммутаторе, который направляет копию трафика в диагностический порт, или TAP-устройство. Без этого Wireshark увидит только свой и broadcast-трафик.

Почему 1С зависает, а сеть показывает «всё нормально»?

Классика — ретрансмиссии TCP из-за плохого кабеля или конфликта IP. На коммутаторе счётчики ошибок показывают ноль, потому что ошибки на L3/L4, а не на L1/L2. Запустите tcpdump на сервере 1С и на клиенте одновременно — увидите ретрансмиссии или window=0 от сервера. Лечится заменой патч-корда или разбором конфликта адресов.

Сколько стоит диагностика сети в офисе?

Разовый выезд инженера с Wireshark-анализом проблемы в Москве — 8 500 руб. за 2–3 часа работы. Полный аудит офисной сети на 50–100 ПК с письменным отчётом — 25 000–45 000 руб. в АйТи Фреш. По абонентке такие вещи входят бесплатно.

Можно ли использовать Wireshark удалённо?

Да, через связку tcpdump на сервере + Wireshark на своём ПК. Команда ssh user@server "sudo tcpdump -i eth0 -w - not port 22" | wireshark -k -i - показывает трафик в реальном времени. Либо собираете дамп на сервере через tcpdump -w, копируете scp и открываете локально.