LINUX.ORG.RU

2 одновременных tcpdump'а с удалённой машины

 


0

2

Есть нужда снимать с удалённой машины 2 tcpdump'а одновременно с разных интерфейсов.
Сейчас это реализовано так:

ssh remotehost "tcpdump -i iface1 -w - " > iface1_dump.pcap &
ssh remotehost "tcpdump -i iface2 -w - " > iface2_dump.pcap

Результат в принципе устраивает, но всё-таки мучает идеалистический такой вопрос - можно ли сделать это за один ssh коннект, чтобы минимизировать потери пакетов во втором дампе, пока будет отрабатывать второй ssh коннект.

tcpdump -i any не подходит, так как искажаются Ethernet заголовки

★★★★★

Кстати, подпишусь. Волнует тот же вопрос, решения как задать несколько интерфейсов не нашел. any тоже не устраивает

Pinkbyte ★★★★★ ()

Может (не пробовал) получится сделать бридж и снимать с него?

anonymous ()

можно ли сделать это за один ssh коннект, чтобы минимизировать потери пакетов во втором дампе, пока будет отрабатывать второй ssh коннект.

Как должны измениться потери пакетов, если суммарное количество полученных данных останется таким же?

Deleted ()
Ответ на: комментарий от Deleted

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

zolden ★★★★★ ()

Если удалённая машина всё время одна, то может положить на неё скрипт берущий названия файлов и запускающий два tcpdump-а?
Разница сократится до «пока запустится второй tcpdump».

frob ★★★★★ ()
Ответ на: комментарий от frob

Если удалённая машина всё время одна, то может положить на неё скрипт берущий названия файлов и запускающий два tcpdump-а?

не уловил, можно пример (можно на псевдокоде)?
основная проблема у меня это вывод в файл с удалённой машины

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Ты б определился: вывод в файл или вывод в ДВА файла. Я tcpdump-ом пользуюсь редко, а в описываемом варианте и вовсе никогда, так что могу ошибаться, но сильно удивлюсь, если авторы предусмотрели опции «сохранять награбленное на первом интерфейсе в файл1, сохранять награбленное на втором интерфейсе в файл2».

То что ты делаешь с ssh remote соответствует двум последовательным заходам на машину и запуску tcpdump с разными параметрами в каждом заходе. Не очень понятно почему тебя так беспокоит, что между запусками пройдёт сколько-то времени (допустим несколько секунд) — всё равно потом для анализа два файла как-то «выравнивать». Если известно, что файл для первого интерфейса открыватся чуть-чуть раньше, то остаётся взять первый пакет из второго файла (если ты знаешь чего могло дропнуться/измениться, то с поправкой на это) и найти его в первом файле. Я в аналогичных ситуациях ориентировался на пролетающие NTP и/или слал через коробку пинги со специфическим payload.

Делаешь на целевой машине файл

#/!/bin/sh
tcpdump -i iface1 -w - " > iface1_dump.pcap &
tcpdump -i iface2 -w - " > iface2_dump.pcap
chmod +x на него и запускай 'ssh remote my_supercool_tcpdump_starter.sh'
может съэкономишь немножко.

frob ★★★★★ ()
Ответ на: комментарий от frob

извиняюсь за невнятные формулировки, для упрощения я опустил два нюанса - локально дампить нельзя (так что мне непонятно как перенаправление в файлы будет работать в случае локального скрипта) - на железке мало места, помимо указания интерфейса дамп надо запускать со своими параметрами (фильтрами)

zolden ★★★★★ ()

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

Harald ★★★★★ ()
Ответ на: комментарий от zolden

Понятно. Ну, я бы тогда забил на разницу по ранее указанным причинам.
Если через железку ходит NTP, то больше ничего не надо.
А если не ходит, то (в предположении что ICMP не блокируется) для «синхронизации» пускай через неё пинг (хотя бы даже нестандартного размера, 123 байта, например).

frob ★★★★★ ()

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

post-factum ★★★★★ ()
Ответ на: комментарий от Harald

не очень понял зачем VPN тут, про монтирование по NFS я тоже думал, но это опять же задержки (на монтирование) и усложнение, которых хотелось бы избежать

zolden ★★★★★ ()
Ответ на: комментарий от post-factum

можно пример, как именно зеркалировать?
железка специфичная, там ни netcat ни iptables нет, я вообще наделся на волшебные манипуляции с редиректами в шелле

zolden ★★★★★ ()

&
пока будет отрабатывать второй ssh коннект

Они же параллельно (одновременно) отрабатывают

sdio ★★★★★ ()
Ответ на: комментарий от zolden

Есть, конечно, одна приблуда на питоне, но я так понимаю, что питон там не влезет.

post-factum ★★★★★ ()
Ответ на: комментарий от sdio

Они же параллельно (одновременно) отрабатывают

Доказать не смогу :), но интуитивно догадываюсь, что
ssh remotehost «command1&command2»
(вариант, который мне видится в идеале) работает быстрее чем
ssh remotehost command1 & ssh remotehost command2

Но ты меня этим натолкнул на мысль использовать SSH ControlMaster, правда не могу пока придумать объективный тест результативности этого варианта

zolden ★★★★★ ()
Ответ на: комментарий от frob

вопрос не в понимании того, потерялся пакет или нет.
у всех есть timestamp и какой-нибудь sequence number
вопрос в том что если уж пакет не успел пойматься, то надо переделывать тест и ещё раз пытаться воспроизвести сценарий, что иногда довольно затруднительно

так что вопрос именно в оптимизации и минимизации задержек (но как я сказал, текущий вариант меня почти устраивает, и в 99% случаев я успеваю поймать всё, что нужно)

zolden ★★★★★ ()
Ответ на: комментарий от zolden

А что мешает сначала запустить захват, а потом тест?

frob ★★★★★ ()
Ответ на: комментарий от frob

Балансировка
Трафик может попасть на 1 из N серверов, по большому счёту случайным образом
Целевой сервер становится известен только после получения 1го пакета на балансировщике

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Что-то мне подсказывает, что «запустить на всех серверах захват, запустить тест, посмотреть куда полетело с балансировщика, прибить там где не надо» — это будет ещё вознявее чем иногда не захватывать нужное.

А малость подкудрачить тесты, так чтобы сначала пролетало что-нибудь ненужное/бесполезное нельзя? (Предполагая, что на балансировщике есть какая-нибудь persistence/stickiness).

frob ★★★★★ ()
Ответ на: комментарий от frob

А малость подкудрачить тесты, так чтобы сначала пролетало что-нибудь ненужное/бесполезное нельзя?

Ну да, в случае синтетического теста так и стараюсь делать.
Но иногда в 1 случае из 100 не получается воспроизвести проблему синтетикой, прииходится ловить наживую.

Спасибо за участие, думаю не буду больше задротствовать из-за пары-тройки наносекунд, пусть остаётся всё как есть

zolden ★★★★★ ()
Ответ на: комментарий от zolden

не уверен, что понял вопрос

Это я просто не сразу понял про потери пакетов. Теперь понял, что тебе нужно, чтобы захват пакетов начался одновременно...

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.