+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

[Ошибка?/Проблема] VLAN-aware Bridge + Bridge NAT

[Ошибка?/Проблема] VLAN-aware Bridge + Bridge NAT, RouterOS

rpfact

Guest

03.02.2019 18:52:00

Вижу проблему с NAT-правилами на мосту с включённым VLAN-фильтром (ROS v6.43). Мост содержит кучу портов (как с тегами, так и без), и я пытаюсь написать NAT-правило для одного порта, который подключён к мосту как нетегированный и у которого задан PVID. Правило, которое я пытаюсь создать — "dstnat", "In.Interface" — это именно тот порт, о котором речь, и я пытаюсь обработать либо только IP-пакеты (eth.type 0x800), либо опционально ARP-пакеты (eth.type 0x806).

Однако на этапе dstnat я вижу только VLAN-пакеты (0x8100), других типов eth. пакетов нет. Ладно, допустим VLAN-инкапсуляция (по порту с PVID) происходит до обработки правил моста dstnat, проблем нет — потому что в классификации правил я могу задать совпадение для кадров 0x8100, а потом уже дальше классифицировать по протоколу «VLAN/VLAN Encap». И вот эта классификация по «VLAN Encap» работает, по-моему, неправильно.

Что я обнаружил на этом правиле: MAC Protocol-Num совпадает с кадрами 0x8100 (VLAN), а VLAN Encap не совпадает ни с 0x800 (IP), ни с 0x806 (ARP), ни с !0x800 (то есть «не IP») — что вообще не имеет смысла.

Совершенно странное поведение проявляется (в winbox), когда я задаю VLAN Encap = 0x800 (IP). Счётчик этого правила (и вообще других nat-правил, если они есть) начинает показывать какие-то странные случайные числа, например Bytes: 5255520.0 GiB, Packets: 100895145455555555 (сразу после установки правила, так что, думаю, где-то происходит переполнение…).

Не уверен, ошибаюсь ли я или чего-то не понимаю, или это баг.

CoMMyz Guest	#2 0 06.06.2020 12:54:00 Спасибо!!! Я уже ломал голову, почему это не работает! Твой способ вроде помогает как временное решение. Видимо, проблема действительно есть на архитектурах ARM.

pnajm

Guest

05.04.2019 19:19:00

Это определённо ошибка. Мой сценарий: у меня включена фильтрация vlan на мосту, и есть 2 vlan — один для управления, второй для pppoe-трафика. Я пытаюсь использовать фильтр моста, и как только я устанавливаю vlan Encap, начинают происходить странные вещи. vlan encap=pppoe discovery не работает. vlan encap=pppoe session не работает. vlan id работает. Я также заметил, что при установке vlan encap в IP появляется какой-то странный ОГРОМНЫЙ рост в счётчике BYTES. Mikrotik, пожалуйста, исправьте это.

rpfact

Guest

08.05.2020 02:13:00

Да, это всё ещё баг. Я уже сообщил об этом, дал им примеры, как воспроизвести проблему, предложил доступ к окружению, где это настроено, чтобы они могли увидеть проблему в реальном времени, но либо им сложно понять, либо я просто живу в параллельной вселенной. Впрочем, я нашёл обходной путь. По крайней мере, как отфильтровать/NAT IPv4 (0x800) пакеты на мосту с включённым VLAN. Фишка в том, чтобы не использовать VLAN Encap = 0x0800 (ipv4), а просто «8», и вуаля — всё работает. Теперь видно, как у них сдвинуты байты в этих правилах. Даже не представляете, сколько времени у меня ушло, чтобы разобраться, что там происходит... Итак, для фильтрации/NAT на мосту с VLAN для ipv4 используйте: MAC proto-num (hex): 8100 (vlan), VLAN Encap (hex) = 8. К сожалению, для ваших 0x8863 (pppoe-discovery) и 0x8864 (pppoe-session) это не сработает — байты сдвинуты неправильно, а вот для ipv4 (0x0800) всё ок, там нули. Чувак, тебе не повезло с протоколом, который пытаешься отфильтровать. Может, напишешь в IEEE Registration Authority — пусть поменяют EtherType pppoe-xxx на что-то с нулями во втором байте заголовка EtherType, чтобы это стало «дружелюбным» для фильтрации MikroTik. Сейчас я даже не хочу, чтобы они это исправляли, у меня уже несколько правил завязано на этом обходе (работает как часы почти год).

sindy

Guest

08.05.2020 06:39:00

Шляпа! И в голову не приходило, что проблема может быть такой простой. Но раз ты указал направление, у меня есть хорошие новости — байты не сдвинуты, а поменяны местами (типа «big Endian/little Endian»): если поставить vlan-encap=0x0608, правило срабатывает на кадрах с ARP-пакетами. Чтобы убедиться, что это не случайность, я попробовал то же с pppoe-discovery:

/interface bridge filter add action=log chain=output log-prefix=pppoe-rule mac-protocol=vlan out-interface=pppoe-vlan vlan-encap=0x6388 vlan-id=234

И это работает:

[me@MyTik] > log print follow-only
08:03:19 firewall,info pppoe-rule output: in:(unknown 0) out:pppoe-vlan, src-mac 66:b0:c9:a3:c9:e1, dst-mac ff:ff:ff:ff:ff:ff, vlan-id 234, vlan-prio 0, eth-proto 8863

Минус в том, что фильтрация по полям внутреннего протокола (например, ip-protocol, src-port и dst-port при vlan-encap=ip или arp-opcode при vlan-encap=arp) не работает, если vlan-encap задан таким образом. То есть использовать все возможности фильтрации моста с vlan-тегированными кадрами не получится. Я подумал, может проблема проявляется только на некоторых архитектурах, и проверил на CHR (Intel, который использует little Endian) — но нет, там тоже самое.

rpfact

Guest

08.05.2020 10:46:00

Чувак, ты просто угадал, ты гуру. Нет ничего проще, чем это проверить, так что я настроил простой фильтр с прямой передачей, чтобы совпадать с 0x0806 (arp) как vlan encap = 0x0608, и да, это работает, так что ты прав — байты именно меняются местами, а не сдвигаются. У меня есть RB3011, на котором я это сейчас проверял. Немного сбивает с толку то, что если байты просто меняются местами, то почему счётчики переполняются или что там происходит, если поставить, например, 0x0800 (ip4). Вот это меня и остановило пытаться ставить двойные байтовые значения, потому что я видел, что что-то пишу туда, куда не должен. Ты писал: «Недостаток в том, что сопоставление на полях внутреннего протокола (например, ip-protocol, src-port и dst-port для vlan-encap=ip, или arp-opcode для vlan-encap=arp) не работает, когда vlan-encap установлен таким образом. Так что нельзя использовать весь потенциал фильтрации моста с vlan-тегированными кадрами». Ладно, но так задумано. Это не из-за этого бага. Я не вижу никакой возможности, например, отфильтровать vlan-инкапсулированный ip ethertype на основе типа ip-протокола и портов src/dst и так далее... Такое фильтрование я вижу только, если ты выбираешь mac-protocol-num напрямую как «ip» (0x0800), то есть без vlan-инкапсуляции. В любом случае, отличная работа, чувак!

mkx

Guest

08.05.2020 10:52:00

У меня нет ни оборудования для тестирования, ни тестового случая... Может, это как-то связано с архитектурой big-endian и little-endian? Все знают, что Ethernet — big-endian, но некоторые из наших роутеров — little-endian... Возможно, кто-то, кто разрабатывал эту часть интерфейса, об этом забыл?

sindy Guest	#8 0 08.05.2020 11:05:00 Конечно, это сделано преднамеренно, я написал это лишь для того, чтобы подчеркнуть, что обходной путь решает только часть всей проблемы.

sindy Guest	#9 0 08.05.2020 11:32:00 Вот почему я попробовал и на hAP ac², и на CHR, и получил тот же результат. 3011 работает на ARM, как и hAP ac², так что разницы нет. Но раз ты вернулся к этой теме, я протестировал на Powerbox (hEX lite PoE, RB70Pr2) с процессором mipsbe, и там этой проблемы нет, ни в версии 6.42.8, ни в 6.46.6. Так что, хотя я сначала не думал, скорее всего, дело действительно в обработке порядка байт (endianness). Тестовый сценарий легко настроить: pppoe-client → интерфейс vlan X (service-tag=no) → интерфейс bridge br-C-vlan → интерфейс vlan Y (service-tag=yes) → интерфейс bridge br-S-vlan (ethertype 0x88a8). Правило фильтра на br-C-vlan, которое логирует и срабатывает по mac-protocol=vlan vlan-id=X vlan-encap=pppoe-discovery, логирует, если отображение правильное, а с vlan-encap=0x6388 — логирует, когда отображение неправильное.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры