Tcpdump: захват и чтение сетевого трафика

Собираем минимальный pcap с правильным интерфейсом и фильтром, читаем TCP-флаги и DNS, ограничиваем размер файла и не захватываем лишние данные. Ниже — последовательность, которую можно повторить на тестовом узле и затем перенести в рабочее окружение.

Короткий ответ

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

sudo tcpdump -D
sudo tcpdump -ni any 'host 203.0.113.10 and port 443'
sudo tcpdump -ni eth0 'tcp[tcpflags] & tcp-syn != 0'

Команды приведены как ориентир: имена интерфейсов, служб, пользователей, доменов и путей замените на значения своей системы. Если работа выполняется удалённо, оставьте открытой текущую административную сессию, пока новый способ доступа не проверен.

Что проверить до начала

• Текущие версии ОС и пакетов, имя узла, время и часовой пояс.
• Достаточный объём диска и памяти, отсутствие уже упавших системных служб.
• Наличие консольного или другого аварийного доступа для сетевых и защитных изменений.
• Точные имена объектов из команд: устройство, service unit, база, сайт, контейнер или домен.
• Ожидаемый результат и простой способ его измерить до и после изменения.

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

Пошаговая настройка

1. Соберите исходные данные

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

sudo tcpdump -D
sudo tcpdump -ni any 'host 203.0.113.10 and port 443'
sudo tcpdump -ni eth0 'tcp[tcpflags] & tcp-syn != 0'

2. Подготовьте конфигурацию

Используйте отдельный файл конфигурации или drop-in, если инструмент это поддерживает. Такой подход не смешивает локальные изменения с файлом пакета и уменьшает конфликты при обновлении. Права на файл должны соответствовать чувствительности данных: конфигурация с паролем или ключом не должна читаться обычными пользователями.

sudo tcpdump -ni eth0 -s 0 -B 4096 -C 100 -W 5 -w /var/tmp/incident.pcap 'port 53 or port 443'
tcpdump -nnr /var/tmp/incident.pcap | head

3. Проверьте синтаксис и примените изменение

До перезапуска найдите команду проверки синтаксиса или режима dry-run. Если она возвращает ошибку, не пытайтесь «продавить» изменение перезагрузкой. Исправьте первую содержательную ошибку, повторите проверку и лишь затем выполняйте reload. Полный restart нужен только там, где reload не перечитывает нужный параметр.

4. Подтвердите результат с точки зрения клиента

Статус «running» говорит только о процессе. Проверяйте реальную функцию: TCP-соединение, HTTP-код, DNS-ответ, вход под нужной учётной записью, чтение из восстановленной базы или запуск контейнера. Желательно выполнить проверку с другого узла и сравнить её с контрольным значением, записанным до работ.

Проверка результата

sudo tcpdump -nnr /var/tmp/incident.pcap 'tcp[tcpflags] & tcp-rst != 0'
sudo tcpdump -nnr /var/tmp/incident.pcap 'udp port 53'

Успешная проверка должна быть воспроизводимой. Сохраните короткий набор команд в журнале эксплуатации или monitoring check. Если система обслуживает пользователей, добавьте проверку прикладного уровня: главной страницы, API health endpoint, тестового запроса к базе либо типовой операции клиента.

Проверяйте соединение с той точки, где находится реальный клиент. Успешный запрос с самого сервера не подтверждает прохождение NAT, межсетевого экрана или внешнего балансировщика. Для спорных случаев короткий pcap обычно даёт больше фактов, чем серия изменений наугад.

Типичные ошибки и способы найти причину

• Ошибка: захватывают any без фильтра на нагруженном сервере. Сначала подтвердите состояние диагностической командой и только потом меняйте конфигурацию.
• Ошибка: pcap содержит чувствительные данные. Сначала подтвердите состояние диагностической командой и только потом меняйте конфигурацию.
• Ошибка: имена разрешаются и скрывают реальные IP. Сначала подтвердите состояние диагностической командой и только потом меняйте конфигурацию.

При диагностике не меняйте несколько независимых параметров одновременно. Иначе даже успешный результат не покажет, какое действие помогло. Сопоставляйте время ошибки в клиенте, системном журнале и журнале приложения. Если время отличается, сначала исправьте синхронизацию часов и повторите тест.

Эксплуатация в рабочей среде

После успешного теста документируйте не только итоговый файл, но и причину выбора параметров, способ проверки и процедуру возврата. Добавьте контроль свободного места, срока сертификата, состояния сервиса или результата задания — тот показатель, который раньше всего сообщит о деградации.

Не выводите секреты в командную строку, скриншоты и журналы CI. Для токенов, ключей и паролей используйте защищённый файл, переменную окружения с ограниченным доступом или менеджер секретов. Разделяйте учётные данные тестовой и рабочей среды и планируйте ротацию до инцидента.

Повторите проверку после планового обновления и перезагрузки. Конфигурация, которая работает только до следующего старта, ещё не завершена. Для критичной службы полезны автоматический healthcheck, уведомление об отказе и короткая инструкция дежурному.

Контрольный список

1. Исходное состояние и версии записаны.
2. Демонстрационные адреса и имена заменены.
3. Синтаксис проверен штатной командой.
4. Изменение применено без потери административного доступа.
5. Функция проверена со стороны клиента.
6. Журналы не содержат новых ошибок.
7. Мониторинг и процедура возврата обновлены.

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

Можно ли выполнить настройку сразу на production?

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

Почему команда из инструкции отличается в моей системе?

Пути, названия пакетов и unit-файлов зависят от дистрибутива и версии. Сверьте официальную документацию, вывод справки и фактически установленные пакеты. Не заменяйте различия случайным советом из старого обсуждения.

Как понять, что работа закончена?

Есть четыре признака: синтаксис валиден, сервис выполняет функцию, клиентский тест проходит, а после перезагрузки состояние сохраняется. Для данных дополнительно нужен тест чтения или восстановления, для безопасности — проверка запрещённого сценария.

Официальная документация: первоисточник по теме. Перед применением уточните поведение для своей версии продукта.