Wireshark и tcpdump: диагностика потери пакетов в сети телеком-оператора

Телеком-оператор «ЛинкТелеком» столкнулся с жалобами клиентов на качество VoIP-связи и медленную загрузку сайтов. Мониторинг показывал 3% потерю пакетов на участке между ядром сети и пограничным маршрутизатором, но причина была неясна — все интерфейсы показывали 0 errors, 0 drops.

Стандартные средства диагностики (ping, mtr, SNMP-мониторинг) не давали достаточно информации. Нужен был глубокий анализ пакетов на уровне L3-L7. Мы развернули систему захвата трафика на основе tcpdump и Wireshark.

Инструментарий:

• tcpdump — захват пакетов на серверах и маршрутизаторах (CLI, минимальные требования).
• Wireshark — визуальный анализ захваченных дампов (GUI, мощные фильтры).
• tshark — CLI-версия Wireshark для скриптования и автоматизации.

tcpdump — основной инструмент захвата пакетов в Linux. Ключевые параметры:

# Базовый захват на интерфейсе eth0
tcpdump -i eth0

# Захват в файл для анализа в Wireshark
tcpdump -i eth0 -w /tmp/capture.pcap

# Ограничение по размеру файла (100 МБ) с ротацией (5 файлов)
tcpdump -i eth0 -w /tmp/capture.pcap -C 100 -W 5

# Захват полных пакетов (по умолчанию tcpdump обрезает до 262144 байт)
tcpdump -i eth0 -s 0 -w /tmp/capture.pcap

# Захват с временными метками высокого разрешения
tcpdump -i eth0 -tt -w /tmp/capture.pcap

Capture фильтры (BPF) — применяются при захвате, экономят дисковое пространство:

# Только трафик конкретного хоста
tcpdump -i eth0 host 192.168.1.100

# Только TCP на порт 443 (HTTPS)
tcpdump -i eth0 tcp port 443

# Только DNS-запросы
tcpdump -i eth0 udp port 53

# Трафик между двумя хостами
tcpdump -i eth0 host 10.0.0.1 and host 10.0.0.2

# Только SYN-пакеты (новые TCP-соединения)
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0 and tcp[tcpflags] & (tcp-ack) == 0'

# Только ICMP (ping и ошибки)
tcpdump -i eth0 icmp

# Исключить SSH (чтобы не захватывать собственную сессию)
tcpdump -i eth0 not port 22

# Комплексный фильтр для диагностики
tcpdump -i eth0 '(tcp port 80 or tcp port 443 or udp port 53) and not port 22' \
    -s 0 -w /tmp/diag.pcap -C 50 -W 10

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

# На маршрутизаторе A (вход)
tcpdump -i ge-0/0/1 -s 128 -w /tmp/point_a.pcap -c 1000000 &

# На маршрутизаторе B (выход)
tcpdump -i ge-0/0/0 -s 128 -w /tmp/point_b.pcap -c 1000000 &

# -s 128: захватываем только заголовки (экономия места)
# -c 1000000: остановка после 1 млн пакетов

Загрузив дампы в Wireshark, мы использовали display фильтры для поиска проблем.

Display фильтры Wireshark (отличаются синтаксисом от capture фильтров tcpdump):

# TCP retransmissions — повторные передачи (признак потери пакетов)
tcp.analysis.retransmission

# Все TCP-проблемы одним фильтром
tcp.analysis.flags

# Duplicate ACK — указывают на потери
tcp.analysis.duplicate_ack

# Zero Window — получатель не успевает обрабатывать
tcp.analysis.zero_window

# TCP Reset — аварийное закрытие соединения
tcp.flags.reset == 1

# Конкретный IP и порт
ip.addr == 192.168.1.100 && tcp.port == 443

# HTTP ошибки 5xx
http.response.code >= 500

# Пакеты с определённым размером (фрагментация)
ip.len > 1500

# Трафик конкретной TCP-сессии (по stream index)
tcp.stream eq 42

Анализ TCP handshake:

Нормальный трёхсторонний handshake: SYN → SYN-ACK → ACK. В Wireshark используем фильтр:

# Все SYN-пакеты без ответа SYN-ACK (проблемы подключения)
tcp.flags.syn == 1 && tcp.flags.ack == 0 && !tcp.analysis.retransmission

Мы обнаружили, что 3.2% SYN-пакетов не получали SYN-ACK ответ. При этом retransmission фильтр показал 47 000 повторных передач за 10-минутный дамп. Wireshark Statistics → TCP Stream Graphs → Round Trip Time Graph показал периодические всплески RTT до 800 мс (при норме 2 мс), совпадающие с потерями.

DNS-диагностика — первое, что проверяем при жалобах на «медленный интернет»:

# Захват DNS-трафика
tcpdump -i eth0 udp port 53 -w /tmp/dns.pcap

# Wireshark display фильтры для DNS
dns                              # Весь DNS-трафик
dns.time > 0.5                   # DNS-ответы дольше 500 мс
dns.flags.rcode != 0             # DNS-ошибки (NXDOMAIN, SERVFAIL)
dns.flags.rcode == 2             # SERVFAIL
dns.flags.rcode == 3             # NXDOMAIN
dns.qry.name contains "example"  # Запросы к конкретному домену
dns.resp.type == 1               # Только A-записи в ответах

В нашем случае DNS был в норме — все ответы приходили за 5-15 мс. Но мы нашли 200+ устройств, отправляющих DNS-запросы к нестандартным серверам (8.8.8.8 вместо корпоративного DNS) — признак возможного заражения.

TLS handshake анализ:

# TLS фильтры в Wireshark
tls.handshake                            # Все TLS handshake сообщения
tls.handshake.type == 1                  # Client Hello
tls.handshake.type == 2                  # Server Hello
tls.handshake.type == 11                 # Certificate
tls.alert_message                        # TLS alerts (ошибки)
tls.handshake.extensions.supported_versions_len > 0  # TLS 1.3

# Найти соединения с устаревшими TLS-версиями
tls.record.version == 0x0301             # TLS 1.0 (deprecated)
tls.record.version == 0x0302             # TLS 1.1 (deprecated)

# Найти конкретный SNI (Server Name Indication)
tls.handshake.extensions.server_name == "api.example.com"

TLS-анализ помог обнаружить, что 15 устройств в сети использовали TLS 1.0 для связи с платёжным шлюзом — нарушение PCI DSS. Мы составили список и передали клиенту для обновления.

Жалобы на качество VoIP-связи — основная причина обращения «ЛинкТелеком». Wireshark имеет встроенные инструменты для анализа VoIP:

# Захват SIP/RTP трафика
tcpdump -i eth0 'udp port 5060 or udp portrange 10000-20000' -s 0 -w /tmp/voip.pcap

# Wireshark display фильтры для VoIP
sip                              # Все SIP-сообщения
sip.Method == "INVITE"           # Начало звонков
sip.Status-Code >= 400           # SIP-ошибки
rtp                              # Все RTP-пакеты
rtcp                             # RTCP-отчёты о качестве
rtp.ssrc == 0x12345678           # Конкретный RTP-поток

В Wireshark открываем Telephony → VoIP Calls — показывает все звонки с визуализацией SIP-диалога. Telephony → RTP → RTP Streams — показывает все RTP-потоки с ключевыми метриками:

• Jitter — вариация задержки. Нормально: < 30 мс, у нас: 45-120 мс.
• Packet Loss — потеря пакетов. Нормально: < 1%, у нас: 3.1%.
• Delta — интервал между пакетами. Для G.711 кодека должен быть 20 мс.

Wireshark → Telephony → RTP → Stream Analysis показал паттерн: потери пакетов происходили кластерами по 5-15 пакетов каждые 30-40 секунд. Это характерно не для перегрузки (которая даёт равномерные потери), а для микролупов или периодических переключений маршрутов.

Мы коррелировали временные метки потерь RTP с логами маршрутизатора и обнаружили: OSPF-маршрут периодически пересчитывался из-за нестабильного линка между двумя коммутаторами. Замена оптического патч-корда устранила проблему.

Удалённый захват через SSH — захватываем трафик на сервере, анализируем локально в Wireshark:

# Запуск Wireshark с живым потоком через SSH
ssh root@10.0.0.1 'tcpdump -i eth0 -s 0 -w - not port 22' | wireshark -k -i -

# Или сохранить удалённый дамп локально
ssh root@10.0.0.1 'tcpdump -i eth0 -s 0 -c 100000 -w -' > remote_capture.pcap

# Для серверов за бастионом (jump host)
ssh -J bastion@jump.example.com root@10.0.0.1 'tcpdump -i eth0 -w - not port 22' \
    | wireshark -k -i -

tshark — CLI-версия Wireshark для скриптовой обработки дампов:

# Подсчёт TCP retransmissions в дампе
tshark -r capture.pcap -Y "tcp.analysis.retransmission" | wc -l

# Топ-10 IP-адресов по количеству пакетов
tshark -r capture.pcap -T fields -e ip.src | sort | uniq -c | sort -rn | head -10

# Статистика HTTP-ответов
tshark -r capture.pcap -Y "http.response" -T fields -e http.response.code | \
    sort | uniq -c | sort -rn

# Экспорт DNS-запросов в CSV
tshark -r capture.pcap -Y "dns.flags.response == 0" \
    -T fields -e frame.time -e ip.src -e dns.qry.name -e dns.qry.type \
    -E header=y -E separator=, > dns_queries.csv

# Расчёт jitter для RTP-потоков
tshark -r voip.pcap -Y rtp -T fields -e rtp.ssrc -e rtp.timestamp -e frame.time_delta

# Автоматический мониторинг retransmissions (запуск по cron)
#!/bin/bash
# retransmission_monitor.sh
RETRANS=$(tshark -i eth0 -a duration:60 -Y "tcp.analysis.retransmission" 2>/dev/null | wc -l)
TOTAL=$(tshark -i eth0 -a duration:60 -Y "tcp" 2>/dev/null | wc -l)

if [ "$TOTAL" -gt 0 ]; then
    PERCENT=$(echo "scale=2; $RETRANS * 100 / $TOTAL" | bc)
    if (( $(echo "$PERCENT > 2.0" | bc -l) )); then
        curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
            -d chat_id="${CHAT_ID}" \
            -d text="⚠️ TCP Retransmissions: ${PERCENT}% (${RETRANS}/${TOTAL} за 60 сек)"
    fi
fi

Сводка расследования с помощью Wireshark и tcpdump:

1. Симптом: 3% потеря пакетов, jitter 45-120 мс на VoIP.
2. Анализ tcpdump: захват на двух точках показал, что пакеты теряются на конкретном участке.
3. Wireshark TCP analysis: retransmissions кластерами по 5-15 пакетов каждые 30-40 секунд.
4. Wireshark RTP analysis: паттерн потерь совпадает с TCP — кластерный, не равномерный.
5. Корреляция: временные метки потерь совпадают с OSPF recalculation events в логах маршрутизатора.
6. Причина: нестабильный оптический линк между коммутаторами L2 вызывал периодические SPF-пересчёты OSPF, что приводило к микролупам на 200-500 мс.
7. Решение: замена оптического патч-корда + настройка OSPF SPF throttle timers:

! Cisco IOS: настройка SPF throttle
router ospf 1
  timers throttle spf 50 200 5000
  ! spf-start 50ms, spf-hold 200ms, spf-max-wait 5000ms
  ! Предотвращает слишком частые пересчёты при flapping-линке

После замены патч-корда и настройки SPF throttle потери упали до 0.01%, jitter — до 2-5 мс.

Ключевые уроки из этого расследования:

• Мониторинг интерфейсов не показывает всё. 0 errors/drops на интерфейсах не означает отсутствие потерь — пакеты могут теряться внутри ASIC коммутатора или при маршрутизации.
• tcpdump + Wireshark — незаменимая пара. tcpdump для захвата (лёгкий, работает везде), Wireshark для анализа (мощные визуализации и фильтры).
• Захватывайте на двух точках. Сравнение дампов на входе и выходе проблемного участка сразу локализует место потерь.
• Паттерн потерь важнее процента. Равномерные потери = перегрузка. Кластерные потери = маршрутизация/switching. Одиночные потери = CRC/физика.
• tshark для автоматизации. Встройте анализ трафика в мониторинг — 2-строчный скрипт с tshark может поймать проблему за минуту.