Я пытаюсь регистрировать пакеты с помощью моста, созданного на SOC espressobin v5. Я установил его с помощью пакета arm archlinux. Эта плата встроена в стандартную комплектацию и обеспечивает встроенные возможности коммутации и маршрутизации. Я думаю, что отключил все эти функции, так как мне не нужны возможности маршрутизации. Мне нужны только возможности моста с проверкой пакетов.
Намерение состоит в том, чтобы разместить это устройство выше по потоку от ряда VoIP-телефонов и использовать его для проверки пакетов на эти телефоны и их регистрации. Регистрируемые пакеты будут служить индикатором для отдельного процесса (не в рамках этого вопроса), чтобы указать, что телефоны звонят. Эти пакеты перестанут регистрироваться, когда кто-то ответит на телефонный звонок (протокол меняется с UDP на TCP, тем самым аннулируя правило регистрации).
ootb Espressobin настроен с помощью моста br0, который подключается к lan0 lan1. Я отключил dnsamasq и мост по умолчанию br0.
Вместо br0 есть br1, который соединяет lan0 lan1 и устанавливается на статический IP-адрес, назначенный маршрутизатором. Я установил ebtables и выполнил следующее:
modprobe br_netfilter
modprobe nf_conntrack
вот ifconfig
br1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.1.216 netmask 255.255.255.0 broadcast 10.0.1.255
inet6 fe80::a423:15ff:fe81:681a prefixlen 64 scopeid 0x20<link>
ether a6:23:15:81:68:1a txqueuelen 1000 (Ethernet)
RX packets 211400 bytes 21894506 (20.8 MiB)
RX errors 0 dropped 696 overruns 0 frame 0
TX packets 11036 bytes 485479 (474.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::f2ad:4eff:fe08:6070 prefixlen 64 scopeid 0x20<link>
ether f0:ad:4e:08:60:70 txqueuelen 1000 (Ethernet)
RX packets 279130 bytes 32859949 (31.3 MiB)
RX errors 0 dropped 74 overruns 0 frame 0
TX packets 2615 bytes 132663 (129.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::f2ad:4eff:fe08:6070 prefixlen 64 scopeid 0x20<link>
ether f0:ad:4e:08:60:70 txqueuelen 1000 (Ethernet)
RX packets 13767 bytes 1200675 (1.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8539 bytes 361411 (352.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
вот мое правило ebtables:
[root@alarm ipv4]# ebtables -t nat -L
Bridge table: nat
Bridge chain: PREROUTING, entries: 3, policy: ACCEPT
-p IPv4 --ip-src 10.0.1.198 --log-level notice --log-prefix "nf_conn" --log-ip -j CONTINUE
вот вывод правила:
[91201.408471] nf_conn IN=lan1 OUT= MAC source = b8:27:eb:87:49:d4 MAC dest = ff:ff:ff:ff:ff:ff proto = 0x0800 IP SRC=10.0.1.198 IP DST=10.0.1.255, IP tos=0x00, IP proto=17 SPT=137 DPT=137
[91306.855593] nf_conn IN=lan1 OUT= MAC source = b8:27:eb:87:49:d4 MAC dest = ff:ff:ff:ff:ff:ff proto = 0x0800 IP SRC=10.0.1.198 IP DST=10.0.1.255, IP tos=0x00, IP proto=17 SPT=138 DPT=138
[91306.869812] nf_conn IN=lan1 OUT= MAC source = b8:27:eb:87:49:d4 MAC dest = ff:ff:ff:ff:ff:ff proto = 0x0800 IP SRC=10.0.1.198 IP DST=10.0.1.255, IP tos=0x00, IP proto=17 SPT=138 DPT=138
на 10.0.1.198 у меня работает небольшой сервер nodejs, который обменивается данными через порт 15000, espressobin помещается между моей рабочей станцией и 10.0.1.198 следующим образом:
router ---- workstation (10.0.1.X)
|_____espressobin (lan0) - (lan1) ---- nodejs server (10.0.1.198)
когда я скручиваюсь с экспрессобина до 10.0.1.198 (http://10.0.1.198:15000) я могу видеть, какие пакеты регистрируются.
когда я скручиваюсь с рабочей станции на 10.0.1.198, я не вижу зарегистрированных пакетов. Я ожидал увидеть пакеты.
в соответствии с этот документация ebtables не поддерживает полноценный IPv4, поэтому modprobe br_netfilter
Мой вопрос: на правильном ли я пути или я выполняю невыполнимую миссию?
Если это отчасти связано с этим ограничением ebtables, то каков был бы (если есть) возможный метод для достижения моей цели регистрации пакетов на мосту.
В системе ESPRESSObin используется встроенный чип коммутатора Ethernet, который поддерживается Linux DSA (архитектура распределенного коммутатора). Насколько я понимаю, когда вы соединяете 2 порта Ethernet, которые оба подключены к этой микросхеме коммутатора, все кадры, которые направляются от одного порта к другому (а не к самому SoC), будут полностью обходить основной SoC и обрабатываться чип переключателя. Вот почему tcpdump
не показывает трафик; он никогда не касается сетевой карты на SoC.