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. Слышно ровно то же, что слышал клиент — бесценная вещь, когда объясняешь проблему директору, который не технарь.

Кейс 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 занимает 5 минут:

# 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 и открываете локально.