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

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

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

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

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

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

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

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

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

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

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

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

#/!/bin/sh
tcpdump -i iface1 -w - " > iface1_dump.pcap &
tcpdump -i iface2 -w - " > iface2_dump.pcap

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

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

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

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

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

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

zolden

iptables нет

А вот это проблема. Не знаю :).

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

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

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

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

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

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

А вот это тебя не спасёт: http://www.wireshark.org/docs/wsug_html_chunked/ChStatCompareCaptureFiles.html ?

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

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

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

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

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

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

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

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

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

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

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