Вопрос или проблема
Я использую роутер ASUS-RT-N16 и смог установить tcpdump через entware. Когда я запускаю tcpdump (на роутере) -i any -vvv -X udp
или
tcpdump -i br0 -vvv -X udp
[br0 это мост], я вижу только udp мультикаст-трафик, а не udp трафик к устройствам, подключенным к LAN портам (я проверил, что устройства обмениваются UDP). Также пробовал опцию -p с tcpdump, но не вижу ничего, кроме 192.168.1.255 в качестве адресата.
Есть идеи?
На большинстве таких маршрутизаторов все ‘LAN’ порты внутренне подключены к Ethernet коммутатору.1 Процессор маршрутизатора не получает трафик напрямую, он просто является другим подключением к этому коммутатору (через “процессорный порт”), и, как и с другими портами коммутатора Ethernet, “процессорный порт” получает только те Ethernet кадры, которые а) широковещательные или б) адресованы специально к MAC-адресу роутера.2
Коммутатор управляется ядром, так что вы все еще видите отдельные eth
интерфейсы (по одному на порт), но при помещении этих интерфейсов в мост драйвер DSA автоматически активирует аппаратное ускорение для мостирования. В этот момент весь трафик, который не адресован специально к MAC-адресу процессора (или не является широковещательным), пересылается аппаратно, не достигая процессора.
Я не знаю, какая у вашего роутера прошивка, но по-видимому, встройка управления коммутатором Linux DSA не имеет способа отключить offloading индивидуально (это было предложено только в прошлом месяце). Если вы хотите мониторить трафик между двумя узлами, возможно, вам придется поместить их в две отдельные VLAN (что обязательно будет происходить через роутер), или купить внешний коммутатор с функциональностью “портового зеркалирования” (или мониторинга порта, или SPAN).
(Две VLAN могут не потребоваться, если вы можете настроить две подсети, или хотя бы уменьшить “маски подсети” узлов, чтобы заставить их думать, что они больше не находятся в одной подсети.)
Я уверен, что по крайней мере некоторые такие внутренние коммутаторы достаточно программируемы, чтобы они могли реализовать либо зеркальный порт, либо захват процессором – например, я видел такие возможности на RB951G, но это сильно зависит от аппаратного обеспечения и прошивки.
1 (Он может физически являться частью SoC, но тем не менее логически отделен от процессора.)
2 (И когда интерфейсы не объединены в мост, весь их трафик достигает процессора через этот единый внутренний порт с использованием тегов, похожих на VLAN, которые распознает драйвер коммутатора. Таким образом, все эти eth
интерфейсы, видимые ОС, работают очень похоже на “vlan” интерфейсы.)
Ответ или решение
В вашем вопросе проблема заключается в использовании утилиты tcpdump на маршрутизаторе ASUS RT-N16 для захвата трафика UDP, который проходит через LAN-порты, но вы сталкиваетесь с тем, что захватывается только широковещательный (multicast) трафик, а остальной трафик, адресованный конкретным устройствам в сети, не отображается. Это связано с особенностями архитектуры оборудования и управления сетевыми процессами на маршрутизаторе.
Теория
На большинстве современных маршрутизаторов, таких как ASUS RT-N16, все порты LAN физически связаны через встроенный Ethernet-коммутатор, который является частью маршрутизатора. В теории, коммутатор обеспечивает возможность подключения нескольких устройств к одному маршрутизатору, минимизируя нагрузку на центральный процессор маршрутизатора (CPU). CPU маршрутизатора получает только те кадры Ethernet, которые имеют широковещательную адресацию либо предназначены конкретно для этого устройства (например, для маршрутизации сервисных сообщений).
Этот феномен можно объяснить тем, что коммутатор обрабатывает трафик между устройствами напрямую в "жестком режиме" (hardware offload), не проходя через основную процессора, когда речь идет о связи между устройствами, подключенными к различным портам коммутатора. Это делает передачу данных более эффективной, снижая задержку и повышая скорость передачи.
Пример
Когда вы запускаете tcpdump на интерфейсе br0 (который представляет собой мост между физическими интерфейсами маршрутизатора), вы можете видеть только тот трафик, который либо содержит ваш маршрутизатор в качестве адресата, либо является широковещательным внутри сети. Это объясняет, почему вы видите только широковещательный трафик (multicast), адресованный, например, 192.168.1.255.
В зависимости от конфигурации и характеристик устройства существует ограниченное количество способов отключить аппаратное оффлоадинг (hardware offloading) либо перестроить коммутацию так, чтобы маршрутизатор участвовал в обработке трафика.
Применение
Учитывая происходящее, есть несколько подходов, которые могут решить вашу проблему в улавливании TCP/IP пакетов между устройствами в одной сети с помощью tcpdump:
-
VLAN конфигурация: Разделение устройств, чьи данные необходимо мониторить, в разные VLAN. Этот подход потребует, чтобы трафик между различными VLAN проходил через CPU маршрутизатора, что позволит вам наблюдать за данными через tcpdump. Однако, настройка VLAN может быть нетривиальной и потребовать дополнительных знаний о сетевого оборудования.
-
Использование внешнего коммутатора с портом зеркалирования: Потратьтесь на покупку коммутатора с функцией порт-мониторинга (SPAN или зеркалирования), который умеет дублировать весь трафик с одного или нескольких портов на другой порт, где вы можете подключить устройство с tcpdump для прохождения данных сети.
-
Изменение подсети: Путем изменения масок подсетей устройств (например, уменьшив их), вы сможете "обмануть" устройства, заставив их посылать пакеты через маршрутизатор. Этот трюк может увеличить администрирование сети и повлиять на её производительность.
-
Поиск дополнительного программного обеспечения: Некоторые прошивки маршрутизаторов (например, альтернативные прошивки OpenWRT, DD-WRT) предоставляют более гибкие возможности для управления трафиком и захвата данных, чем штатное ПО.
Важно подчеркнуть, что вышеописанные решения могут различаться в зависимости от конкретного оборудования и версии прошивки вашего маршрутизатора. Для применения данных методов может потребоваться достаточно глубокое понимание сетевых технологий и административных привилегий для изменения конфигурации сетевого устройства.
Таким образом, успешное решение вашей задачи лежит, скорее всего, в изменении топологии сети или в использовании более специализированного оборудования для мониторинга трафика.