[KD]

Прошу помощи в решении следующей задачи:

Есть сетевой трафик, SNMP trap на порт udp/162, src разные, dst один и тот же.

Необходимо забрать этот трафик с зеркального порта коммутатора и скормить приложению (zabbix) на сервере.

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

Т.е. на сетевуху с маком aa:bb:cc:00:11:22 и ip 192.168.0.1/24 прилетает пакет с dst 192.168.100.100/dd:ee:ff:99:88:77, нужно  чтобы zabbix слушающий 192.168.0.1 его "скушал".

Подскажите правила iptables, пробовал через TEE завернуть на lo интерфейс - tcpdump ничего не поймал (на физическом интерфейсе трафик естественно присутствует).

Цель - резервирование мониторинга сети железок, у которых можно прописать только одну ловушку.

 

Edited November 9, 2020 by KD

[pppoetest]

Засунуть интерфейс в бридж, затем

ebtables -t nat -A PREROUTING -i br0 -d  dd:ee:ff:99:88:77 -j dnat --to-destination aa:bb:cc:00:11:22

iptables -t nat -A PREROUTING -i br0 -p udp --dport 162 -d 192.168.100.100 -j DNAT --to-destination 192.168.0.1

 

[KD]

Что-то я делаю не так, не удалось заставить работать

Создал бридж br1

добавлен к нему физический интерфейс

 #brctl show
bridge name     bridge id               STP enabled     interfaces
br1             8000.ac162d87df83       no              eno4
и навешен ip

 #ip addr show dev br1
6: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ac:16:2d:87:df:83 brd ff:ff:ff:ff:ff:ff
    inet 192.168.235.1/24 scope global br1
       valid_lft forever preferred_lft forever
    inet6 fe80::ae16:2dff:fe87:df83/64 scope link
       valid_lft forever preferred_lft forever
#iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       udp  --  anywhere             192.168.100.100          udp dpt:162 to:192.168.235.1:162

#ebtables -t nat -L
Bridge table: nat

Bridge chain: PREROUTING, entries: 1, policy: ACCEPT
-d dd:ee:ff:99:88:77 -i br0 -j dnat --to-dst ac:16:2d:87:df:83 --dnat-target ACCEPT

tcpdump на интерфейсе br1 ловит только исходный трафик, без NAT

[pppoetest]

В tcpdump и будет только то, что пришло, до всех трансляций. И во втором правиле у тебя ошибка, интерфейс не бр0 а бр1 должен быть.

[KD]

а если входной интерфейс для ...tables указать физику? (eno4) в бридж они тогда уже измененными попадут?

[pppoetest]

ebtables работает только с бриджами, если бы не это, бридж был бы не нужен.

 

15 минут назад, KD сказал:

в бридж они тогда уже измененными попадут?

Ты не понял, tcpdump не отображает манипуляции со входящим пакетом/фреймом. Он покажет только то, что пришло/ушло в/на интерфейс.

И ещё, ты сервис слушающий юдп 162 порт перевесил на айпи 192.168.235.1 на бридж?

[KD]

"tcpdump не отображает манипуляции со входящим пакетом/фреймом"

вот потому я и хочу dnat iptables перенести на физику

точнее даже перенес, но результата это не дало

"162 юдп перевесил на айпи 192.168.235.1 на бридж"

да, слушает по всем интерфейсам

[pppoetest]

Без бриджа у тебя ничего не выйдет.

 

1 минуту назад, KD сказал:

"tcpdump не отображает манипуляции со входящим пакетом/фреймом"

вот потому я и хочу dnat iptables перенести на физику

Вне зависимости что и куда ты перенесёшь, тцпдамп внутренние манипуляции с сетевым трафиком не отображает.

[KD]

примерно понял, буду думать дальше

[pppoetest]

Схему я показал, в лабе проверил, всё работает.

[kayot]

3 часа назад, pppoetest сказал:

ebtables работает только с бриджами, если бы не это, бридж был бы не нужен.

Насколько я помню ebtables работает с чем угодно. Когда-то использовали для блокировки dhcp/pppoe по MAC на БРАСах без каких-либо бриджей на eth.

Это его отличие что может работать на бридже в отличие от iptables, но не требование.

[NewUse]

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

[pppoetest]

53 минуты назад, NewUse сказал:

не очень понимаю, чем форвардинг на уровне iptables не угодил?

Тем что до этого уровня трафик просто не дойдёт, так как дст мак левый.

 

5 часов назад, kayot сказал:

для блокировки dhcp/pppoe по MAC на БРАСах без каких-либо бриджей на eth.

Дропнуть может и можно, а вот nat врядли, у меня по крайней мере без бриджа dnat не завёлся.

[KD]

Не удалось мне победить iptables

Сделал на микротике, все работает

[Ivan_83]

Мельчают инженера в провайдерах %)

 

Я вот такую штуку сгородил чтобы просто поиграть по сетке, в 2011 году:

pass in quick on ng0 dup-to (vlan777 172.16.0.3) to 255.255.255.255
pass in quick on vlan777 dup-to (ng0 172.16.0.119) to 255.255.255.255
pass quick inet proto udp to 255.255.255.255

Это всё для того чтобы зарулить броадкаст от игры в впн тоннель.

Для трёх игроков правил стало бы заметно больше.

 

В 10.11.2020 в 06:04, pppoetest сказал:

Засунуть интерфейс в бридж, затем

ebtables -t nat -A PREROUTING -i br0 -d  dd:ee:ff:99:88:77 -j dnat --to-destination aa:bb:cc:00:11:22

Ради общего развития: а зачем тут бридж и замена маков?

Вроде должно быть достаточно заменить dst ip, а дальше пакет вылетит сам на нужный MAC, который система достанет из ARP/ND кеша.

[KD]

6 минут назад, Ivan_83 сказал:

Ради общего развития: а зачем тут бридж и замена маков?

Вроде должно быть достаточно заменить dst ip, а дальше пакет вылетит сам на нужный MAC, который система достанет из ARP/ND кеша.

dst ip на той же машине где трансляция происходит

[Ivan_83]

29 минут назад, KD сказал:

dst ip на той же машине где трансляция происходит

И что?

 

rdr proto { tcp, udp } from <childs_hosts> to any port 53 -> 172.16.0.254 port 53535

rdr inet proto tcp from <int_nets_tbl> to !<int_nets_tbl> port 80 -> 127.0.0.1 port 8080

Вот, оно заворачивает весь транзитный трафик на свои сервисы.

(<childs_hosts>, <int_nets_tbl> - таблицы)

(на самом деле первое правило косячное, потому что оно IPv6 трафик тоже цепляет но отредиректить не может, ибо dst ip - IPv4, но к делу это отношения не имеет)

 

rdr proto udp from <int_nets_tbl> to $self_addrs port 123 -> 127.0.0.1 port 123

($self_addrs - в конечном итоге тоже ссылается на таблицу)

Этот костыль потому что я хотел иметь единый конфиг chrony для десктопов и серверов, поэтому повешал на lo, на серверах потребовалось добавить вот такой заворот чтобы сервис стал доступен из сети.

 

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

[KD]

пакеты не попадают в сетевой стек машины (и дальше приложению), они на 2-м уровне отсеиваются т.к. dst mac не равен маку интерфейса

в случае с микротиком у меня получилось именно поэтому - с микротика маршрутизацией пакет выплевывался на нужный dst и ему проставлялся нужный arp из таблицы

[pppoetest]

1 час назад, Ivan_83 сказал:

Вроде должно быть достаточно заменить dst ip, а дальше пакет вылетит сам на нужный MAC

Либо я чего-то не понимаю, либо фрейм с дст мак хренпоймикому до сетевого не долетит, а так и останется на линклеер

[Ivan_83]

Ну и кто вам мешает включить промиск/отключить мак фильтр?

(как по мне так мак фильтр уже стал бесполезен, один коммутатор разруливает, и делает это вполне годно)

(кстати, мак фильтр отключается драйвером сетевого адаптера когда количество подписок к мультикаст группам превышает количество слотов фильтра в сетевухе)

[pppoetest]

6 часов назад, Ivan_83 сказал:

Ну и кто вам мешает включить промиск/отключить мак фильтр?

Никто, только зачем, решение задачи есть, рабочее.

[Ivan_83]

9 часов назад, pppoetest сказал:

Никто, только зачем, решение задачи есть, рабочее.

Оно выглядит переусложнённым.

Впрочем, я узнал что хотел :)