Как можно собирать трафик (traffic sniffer) с удаленных linux серверов?

Question

[Виталий]

Посоветуйте оптимальное решение проблемы.

Есть группа linux серверов с запущенным приложением, входящий трафик равномерно распределяется между ними внешним tcp load balancer'ом (LB пропускает трафик сквозь себя, source IP при этом сохраняется).
Периодически для диагностики возникает необходимость собрать дампы трафика определённого клиента (по известному IP адресу), в идеале - смотреть на этот трафик в реальном времени через wireshark на windows рабочей станции.
Возможности собирать трафик через SPAN на сетевом оборудовании у меня, к сожалению, нет. Задачу нужно решать только софтом на серверах.

Штатное решение (запускаем wireshark на всех хостах, собираем дамп, сливаем на одну машину, объединяем в один файл и открываем в wireshark) крайне трудозатратно и позволяет смотреть данные только в offline'е.

Единственное, что удалось найти для сбора трафика с удалённых серверов - rpcapd, но это совсем не то, собирать сразу с десятка серверов так не получится.

В качестве временного решения-костыля написал простейшую утилитку, которая запускается на серверах, собирает нужный трафик (на базе libpcap), инкапсулирует его в TZSP/ERSPAN и отправляет его на заданный хост по UDP.

Проблему это решило, но остаётся ощущение, что есть что-то готовое и правильное решение моей задачи.
Кто сталкивался с подобной задачей? Как вы её решали?

Answer 1

[Евгений]

Я вообще не спец в этом деле, но попробовал бы следующее:
- заточил бы Вашу утилиту, чтоб она писала все необходимое в текстовый файл
- на каждом целевом сервере ставим logstash, натравливаем его на этот самый текстовый файл
- где-то у себя поднимаем Elasticsearch + Kibana
- говорим логстэшам на серверах, отправлять данные в наш elasticsearch
- в кибане настраиваем красивые диаграммы/графики/таблички
- ???
- PROFIT

Так я, например, собираю статистику http запросов к своему приложению с серверов заказчика.

Как все это дело настроить/установить замечательно описано на оф. сайте Elasticsearch

Comments

[Виталий]

Сила WireShark'а в том, что он "из коробки" может декодировать множество сложных бинарных протоколов и он де-фактом стал стандартным средством диагностики (и, что более важно, может использоваться как независимое средство диагностики, которому доверяют обе стороны) обмена данными между разными системами.

ElasticSearch тут не поможет - его сила в сборе огромных массивов данных и поиска по ним.
Утилитка уже решает задачу - собирает трейсы на целевой хост, просто хотелось найти уже готовый стандартный инструмент.

Answer 2

[TOParh]

Посмотрите в сторону NetFlow-протокола, вам должно помочь

Comments

[Виталий]

А чем тут поможет NetFlow? Это скорее средство подсчёта/учёта трафика, а не его анализа.

[TOParh]

NetFlow умеет собирать трафик гуляющий по сети категоризировать по протоколам и количеству, вам вроде как это и надо?

[Виталий]

TOParh: Нужно смотреть содержимое TCP пакетов от определённых клиентов (IP адресов) во время диагностики проблем. Тут только снятие дампа, других вариантов нет.

Answer 3

[Ярослав]

Насчёт rpcapd...
Точно ли при использовании rpcapd дамп не снять с нескольких источников?

В man tshark есть такое:

-i | -
Set the name of the network interface or pipe to use for live packet capture.
...
This option can occur multiple times. When capturing from multiple interfaces, the capture file will be saved in pcap-ng format.

Что, если попробовать сделать так?
tshark -i rpcap://host1/eth0 -i rpcap://host2/eth0 -f "какой-то фильтр"

Comments

[Виталий]

Спасибо, в таком ключе не подумал.
Собрал небольшой тестовый стенд, в принципе работает, но есть несколько неудобных для меня моментов:
1. В Windows версии в GUI необходимо при каждом запуске регистрировать Remote Interfaces, при перезапуске информация теряется (возможно, проблема в моём компьютере?), при регистрации цепляются сразу все возможные интерфейсы (у меня подцепились eth0, lo0 и usb1, который совсем уже не сетевой интерфейс)
2. В меню Capture -> Options все подобные зарегистрированные становятся выбранными по умолчанию (двойной клик по "capture all interfaces" решает проблему, но всё-же)
3. Если на сервере используется firewall, то начинаются танцы с бубнами - rpcapd использует как основной порт (на который принимает коннекты с wireshark'а), так и дополнительный рандомный (!!!) порт для запуска capture сессии.
4. Не особо большой недостаток, но всё-же - нельзя на уровне сервера жестко задать разрешенный фильтр (полезно с точки зрения безопасности).

Пока останусь на своей самописной тулзе,... у которой тоже есть огромный недостаток с точки зрения firewall'ов, но в моём случае это не проблема - трафик посылается по UDP, а значит, у серверов должна быть возможность достучаться по клиента (т.е. отсутствие NAT'а по пути). Никто, конечно, не мешает использовать различные схемы NAT Traversal, но это уже становится заметным усложнением.