Вопрос или проблема
Как описано в вопросе, я не могу получить unicast трафик для br0 (имя linux bridge) (конечно, broadast может быть получен) с помощью tcpdump -nni any -vvv
, но tcpdump -nni any -vvv
будет захватывать unicast трафик, когда я открою другой терминал и запущу команду tcpdump -nni br0 -vvv
, чтобы одновременно захватить только трафик br0.
И версия tcpdump
4.99.5 (версия libpcap 1.10.5 (с TPACKET_V3)) работает, но версия 4.9.3 (версия libpcap 1.8.1) не может работать с командой tcpdump -nni any -vvv
, чтобы показать unicast трафик br0.
Еще одно, я знаю, что br0 получает весь трафик, проходящий через устройство linux bridge, см. также Анатомия linux bridge.
В случаях, когда MAC-адрес назначения входящего кадра является многоадресным или широковещательным, устройство моста настроено
принимать весь трафик, или адрес совпадает с одним из локальных интерфейсов, клон кадра также передается вверх
по локальному сетевому стеку, вызывая функцию br_pass_frame_
up. Функция обновляет статистику устройства моста и передает входящий кадр вверх по сетевому стеку, вызывая
независимую от устройства функцию netif_receive_skb
Я предполагаю, что это связано с версией или параметром инструмента tcpdump
, но я не могу это проверить. Могу ли я узнать причину? Спасибо
Ответ или решение
Проблема, о которой вы упоминаете, связана с особенностями работы Linux-демона мостов (bridge) и характера захвата трафика с помощью tcpdump
.
При использовании команды tcpdump -i any
вы указываете захватывать пакеты на всех интерфейсах системы, включая виртуальные интерфейсы, такие как мосты. Однако, когда tcpdump
выполняется с использованием интерфейса any
, он не всегда может корректно захватывать unicast-трафик, который проходит через мост (br0
). Это связано с тем, как обрабатывается трафик в моста.
Работа Linux-мостов
Linux-мосты обрабатывают трафик следующим образом:
-
Unicast-трафик: Когда сообщение приходит на интерфейс моста, он проверяет адрес получателя. Если целевой MAC-адрес соответствует одному из локальных интерфейсов на мосту или является многоадресным (broadcast) или широковещательным (multicast), мост передает его вверх по стеку сети, где его может увидеть
tcpdump
. -
Проблема с
-i any
: При использованииtcpdump -i any
, он захватывает пакеты на уровнях сокетов, но в случае unicast-трафика, который проходит через мост, эти пакеты могут не отображаться в интерфейсеany
(по крайней мере в некоторых версияхlibpcap
). Они остаются на уровне сети моста и не поступают на общий интерфейсany
. Поэтому unicast-пакеты не будут видны с помощью этой команды.
Захват unicast-трафика с tcpdump -i br0
Когда вы пользуетесь командой tcpdump -i br0
, вы захватываете пакеты непосредственно на уровне интерфейса моста. Это позволяет вам видеть все пакеты, проходящие через мост, включая unicast-трафик. Мост в этом случае более "осведомлен" о трафике, который проходит через него, и может передать данные на уровень сети, позволяя tcpdump
их захватить.
Различия в версиях tcpdump
Вы также упомянули, что у вас наблюдается разница в поведении между версиями tcpdump
. Версия 4.9.3
(с libpcap 1.8.1
) может не поддерживать некоторые функции захвата, которые есть в версии 4.99.5
(libpcap 1.10.5
). В более новых версиях улучшена поддержка TPACKET_V3, что позволяет более эффективно и точно захватывать трафик, включая unicast. Версия -i any
в более старой версии может просто не иметь возможности отобразить unicast-трафик, приходящий к мосту, на интерфейсе any
.
Резюме
- Unicast-трафик не отображается при использовании
tcpdump -i any
из-за того, что он обрабатывается на уровне моста и не передается вверх по стеку сети. - Затем,
tcpdump -i br0
захватывает все пакеты, включая unicast, непосредственно на интерфейсе моста. - Различия между версиями tcpdump и libpcap могут повлиять на возможность захвата пакетов, особенно в старых версиях, где не поддерживаются улучшенные методы захвата трафика.
Надеюсь, это объяснение поможет вам понять, почему вы сталкиваетесь с такой проблемой в работе с tcpdump
в вашей среде.