Russian Users MikroTik | Форум пользователей MikroTik

Всем привет! Недавно стал счастливым обладателем роутера Микротик и теперь пытаюсь осваивать - как роутер, так и сетевые технологии

В частности, создал Bridge, добавил в него один физический порт и к этому порту подключил комп. Далее, создал на Mikrotik DHCP-сервер и повесил его на этот бридж. В принципе, все работает, комп получает ip-адрес. Но что удивляет - на фаерволе в цепочке input появляются пакеты такого вида:

Код: Выделить всё

BLK-IN> input: in:bridge1 out:(unknown 0), src-mac xx:xx:xx:xx:xx:xx, proto UDP, 172.18.1.106:68->172.18.1.1:67, len 328

"BLK-IN>" - это префикс правила, блокирующего все пакеты в цепочке input, кроме явно разрешенных. Микротик имеет адрес 172.18.1.1. Комп получает адрес 172.18.1.106. Собственно комп получает адрес, не смотря на заблокированный пакет.
Вопрос в том, должны ли вообще пакеты из bridge "видиться" в ip-фаерволе? Теоретически все хосты, подключенные к bridge имеют связанность на уровне ethernet (L2) и таким образом вообще не попадают на уровень маршрутизации (L3), где работает фаервол.

P_Dmitrij писал(а): ↑18 июл 2022, 17:24 Всем привет! Недавно стал счастливым обладателем роутера Микротик и теперь пытаюсь осваивать - как роутер, так и сетевые технологии
В частности, создал Bridge, добавил в него один физический порт и к этому порту подключил комп. Далее, создал на Mikrotik DHCP-сервер и повесил его на этот бридж. В принципе, все работает, комп получает ip-адрес. Но что удивляет - на фаерволе в цепочке input появляются пакеты такого вида:
Код: Выделить всё
BLK-IN> input: in:bridge1 out:(unknown 0), src-mac xx:xx:xx:xx:xx:xx, proto UDP, 172.18.1.106:68->172.18.1.1:67, len 328
"BLK-IN>" - это префикс правила, блокирующего все пакеты в цепочке input, кроме явно разрешенных. Микротик имеет адрес 172.18.1.1. Комп получает адрес 172.18.1.106. Собственно комп получает адрес, не смотря на заблокированный пакет.
Вопрос в том, должны ли вообще пакеты из bridge "видиться" в ip-фаерволе? Теоретически все хосты, подключенные к bridge имеют связанность на уровне ethernet (L2) и таким образом вообще не попадают на уровень маршрутизации (L3), где работает фаервол.

DHCP дает адреса по запросу, адреса это L3...

KaNelam писал(а): ↑18 июл 2022, 22:03
P_Dmitrij писал(а): ↑18 июл 2022, 17:24 Всем привет! Недавно стал счастливым обладателем роутера Микротик и теперь пытаюсь осваивать - как роутер, так и сетевые технологии
В частности, создал Bridge, добавил в него один физический порт и к этому порту подключил комп. Далее, создал на Mikrotik DHCP-сервер и повесил его на этот бридж. В принципе, все работает, комп получает ip-адрес. Но что удивляет - на фаерволе в цепочке input появляются пакеты такого вида:
Код: Выделить всё
BLK-IN> input: in:bridge1 out:(unknown 0), src-mac xx:xx:xx:xx:xx:xx, proto UDP, 172.18.1.106:68->172.18.1.1:67, len 328
"BLK-IN>" - это префикс правила, блокирующего все пакеты в цепочке input, кроме явно разрешенных. Микротик имеет адрес 172.18.1.1. Комп получает адрес 172.18.1.106. Собственно комп получает адрес, не смотря на заблокированный пакет.
Вопрос в том, должны ли вообще пакеты из bridge "видиться" в ip-фаерволе? Теоретически все хосты, подключенные к bridge имеют связанность на уровне ethernet (L2) и таким образом вообще не попадают на уровень маршрутизации (L3), где работает фаервол.
DHCP дает адреса по запросу, адреса это L3 - фаер тоже L3.....
судя по логу прилетел запрос на продление аренды, у клиента был адрес на момент запроса
хотиv блочbть раздачу адресов, это к фаеру на бридже, как раз L2

KaNelam писал(а): ↑18 июл 2022, 22:05 судя по логу прилетел запрос на продление аренды, у клиента был адрес на момент запроса

Так я пробовал и новое устройство добавлять в сеть. Оно получает адрес, даже если до этого никакого адреса не имело.

KaNelam писал(а): ↑18 июл 2022, 22:03 DHCP дает адреса по запросу, адреса это L3...

KaNelam писал(а): ↑18 июл 2022, 22:05 DHCP дает адреса по запросу, адреса это L3 - фаер тоже L3.....

Мне кажется такая логика не совсем верна. Ведь бридж, по сути, имитирует коммутатор L2. То есть, все клиенты сети бриджа видят ethernet-адреса друг друга. А значит пакеты должны доставляться внутри бриджа через arp, не выходя на уровень маршрутизации. Но даже если я не прав, то все равно странно. На фаерволе тогда должен заблокироваться весь DHCP траффик и dhcp-клиенты не должны получить адреса. Да и широковещательных адресов в логах нет. Они, очевидно, не попадают в фаервол.

P_Dmitrij писал(а): ↑19 июл 2022, 13:44
KaNelam писал(а): ↑18 июл 2022, 22:05 судя по логу прилетел запрос на продление аренды, у клиента был адрес на момент запроса
Так я пробовал и новое устройство добавлять в сеть. Оно получает адрес, даже если до этого никакого адреса не имело.

KaNelam писал(а): ↑18 июл 2022, 22:03 DHCP дает адреса по запросу, адреса это L3...

KaNelam писал(а): ↑18 июл 2022, 22:05 DHCP дает адреса по запросу, адреса это L3 - фаер тоже L3.....
Мне кажется такая логика не совсем верна. Ведь бридж, по сути, имитирует коммутатор L2. То есть, все клиенты сети бриджа видят ethernet-адреса друг друга. А значит пакеты должны доставляться внутри бриджа через arp, не выходя на уровень маршрутизации. Но даже если я не прав, то все равно странно. На фаерволе тогда должен заблокироваться весь DHCP траффик и dhcp-клиенты не должны получить адреса. Да и широковещательных адресов в логах нет. Они, очевидно, не попадают в фаервол.

Новое устройство не увидит L3 фаер, нечего видеть.
Тут нет логики, тут OSI. L3 фаер видит то что относится к нему, L2 соответственно свое. Фаер в тике переделанный iptables, изучите на досуге - станет яснее. Хотите блочить DHCP, блочим 67 и 68 порты в фаерволе бриджа, предварительно его включив.

Запустил tcpdump на клиентской машине и выполнил обновление адреса по dhcp. При это выяснилось, что все пакеты она получает, несмотря на запрет на фаерволе:

Код: Выделить всё

15:19:02.505699 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx (oui Unknown), length 300
15:19:02.506590 IP user.bootps > 172.18.1.106.bootpc: BOOTP/DHCP, Reply, length 300
15:19:02.537685 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from xx:xx:xx:xx:xx:xx (oui Unknown), length 300
15:19:02.538349 IP user.bootps > 172.18.1.106.bootpc: BOOTP/DHCP, Reply, length 300
15:19:16.180289 IP 172.18.1.106.bootpc > user.bootps: BOOTP/DHCP, Request from xx:x:xx:xx:xx:xx (oui Unknown), length 300
15:19:16.181440 IP user.bootps > 172.18.1.106.bootpc: BOOTP/DHCP, Reply, length 300

При этом в цепочке input на фаерволе:

Код: Выделить всё

dhcp-lan deassigned 172.18.1.106 from xx:xx:xx:xx:xx:xx
dhcp-lan assigned 172.18.1.106 to xx:xx:xx:xx:xx:xx
BLK-IN> input: in:bridge-l2tp-in-vlan1-usr out:(unknown 0), src-mac xx:xx:xx:xx:xx:xx proto UDP, 0.0.0.0:68->255.255.255.255:67, len 328
BLK-IN> input: in:bridge-l2tp-in-vlan1-usr out:(unknown 0), src-mac xx:xx:xx:xx:xx:xx, proto UDP, 0.0.0.0:68->255.255.255.255:67, len 328
BLK-IN> input: in:bridge-l2tp-in-vlan1-usr out:(unknown 0), src-mac xx:xx:xx:xx:xx:xx,, proto UDP, 172.18.1.106:68->172.18.1.1:67, len 328

Таким образом, напрашивается вывод, что
1) коммутация пакетов осуществляется внутри bridge, не поднимаясь на уровень фаервола
2) пакеты, предназначенные для Mikrotik (для цепочки input) при этом как-бы дублируются на уровень на фаервол
Достаточно неожиданный эффект, в документации такого я не нашел :)

Russian Users MikroTik | Форум пользователей MikroTik

DHCP на bridge и фаервол input chain

DHCP на bridge и фаервол input chain

Re: DHCP на bridge и фаервол input chain

Re: DHCP на bridge и фаервол input chain

Re: DHCP на bridge и фаервол input chain

Re: DHCP на bridge и фаервол input chain

Re: DHCP на bridge и фаервол input chain