Списки интерфейсов появились в MikroTik RouterOS довольно давно, но по наблюдением далеко не все про них знают и поэтому не используют.

Описание

Что это такое понятно из названия — Interfaces List, такие же как списки адресов(address list), только с интерфейсами. Не стоит путать из с мостами(bridge) и связанными(bounding) интерфейсами, это три разные технологии под разные задачи. Появился этот функционал около года назад и присутствует во всех актуальных(current и bugfix) релизах RouterOS 6.

Главное что стоит запомнить: Интерфейсы в составе списков продолжают быть независимыми, трафик не начнет ходить между ними насквозь(как в случае с bridge) и не будет распаралелен(как в случае с bounding), вот вам смешно, а ведь бывают умники.

Стандартные списки

[Interfaces]->[Interfaces List]->[Lists]
по умолчанию присутствуют три списка: all, none, dynamic. С первыми двумя все понятно, dynamic на данный момент заполняется из определенных ppp подключений и Detect Internet.

Консольный вариант:

/interface list print

Создание своего списка
[Interfaces]->[Interfaces List]->[Lists]->[+]
name — имя
include — включить в новый список интерфейсы из указанного списка
exclude — исключить из нового списка интерфейсы из указанного списка


Консольный вариант:

/interface list add name=test

Добавление интерфейсов

Добавлять можно любые интерфейсы: ethernet, wlan, bridge, vlan, vpn, vif,… Все делается из основного меню [Interface Lists].


Консольный вариант:

/interface list member
add interface=ether1 list=test

Использование в firewall filter

Основное применение — упростить правила firewall, допустим у вас есть vpn концентратор и необходимо хитро настроить правила для проходящего трафика, но сделать это максимально наглядно.


Раньше:

Проверяем in-interface, отправляем в цепочку-1.
В цепочке-1 проверяем out-interface, отправляем в цепочку-2.
В цепочке-2 настраиваем правила.


И так для каждого интерфейса. 4 подключения — 8 правил, 8 подключений — 16 правил. Подключения динамические? Можно выкрутиться и использовать all ppp, перекинуть в цепочку-1, а потом из цепочки-1 return'ить лишние интерфейсы.

Теперь:

Добавляем все интерфейсы в один список и создаем одно правило с одинаковыми in-interface-list и out-interface-list, которое переносит в цепочки с правилами фильтрации. Стало заметно короче.


В этой схеме есть и минус, если посмотреть на «раньше» то для каждого интерфейса прописаны подсети адресов которые ожидаются на интерфейсе, в новой схеме можно все интерфейсы загнать в address list, но адреса подсетей уже не будут четко привязаны к интерфейсам.

Другой пример — у вас несколько провайдеров и лень для каждого дублировать правила:

Использование в firewall nat

Когда списки интерфейсов только появились, на форуме mikrotik жаловались на работу interface lists в nat, сейчас вроде починили. Решил поисследовать

Тестовый стенд:


На схеме не хватает адресов для same

Результаты:

Chain src-nat:
* masquerade — работает. В зависимости от выходного интерфейса подставляет соответствующий ip.
* src-nat — работает. Подставляет указанный ip только для интерфейса на котором этот ip присутствует.
* same — работает. Аналогично с src-nat.

Chain dst-nat:

* redirect — работает.
* dst-nat — работает. В том числе в сочетании с masquerade.
* netmap — работает. Если вы его используете вместо dst-nat. При использовании по назначению тоже работает.

Использование в firewall mangle

Работает. Например если вам нужно пометить весь входящий трафик с интерфейсов для queue tree.

Использование в vpn profiles

Вспоминаем пример с региональными vpn. Добавился пятый регион и вы добавляете его руками в interface list, а можно поступить проще и в профиле vpn указать в какой список будет помещен интерфейс при подключении, в независимости от того есть для него binding или он создается автоматически, когда клиент отключается интерфейс из списка будет удален. Для исходящих vpn это тоже работает.

[PPP]->[Profiles]

Все хорошо, но присутствует баг(на момент публикации версия RoS 6.42.6). Если вы создали binding и статически добавили его в список указанный в profiles, то подключение не установится. В логах(сервера) будет примерно следующее:

Использование в bridge

Можно указать список интерфейсов в качестве участника bridge, но будут добавлены только интерфейсы способные работать на Layer 2(ethernet, wlan, bounding, eoip, ovpn-ethernet, ...) исключение — другие bridge.

Detect Internet

Функционал появился в current версии прошивки и пока не готов к использованию.
[Interfaces]->[Detect Intrnet]
* Detect Interface List — список с интерфейсами на которых будут производиться проверки.
* LAN Interface List — список, в который добавляются все активный layer2 интерфейсы. Получают статус lan.
* WAN Interface List — список, в который добавляются все интерфейсы lte и vpn туннели. Так-же интерфесы со статусом lan у которых нет dhcp server и с которых доступен адрес 8.8.8.8. В дополнение ко всему mikrotik добавит на интерфейс dhcp client в попытках получить настройки автоматически.
* Internet Interface List — список, в который попадают интерфесы со статусом wan, если с них доступен cloud.mikrotik.com:30000. Перепроверка каждую минуту, после 3 неудачных попыток интерфейс возвращается в статус wan. Изменить адрес проверки, либо интервалы нельзя.

[Interface Statuses] — результаты проверок.

Так оно должно работать, но на практике запросы на cloud.mikrotik.com не отправляются. Ждем и надеемся, что: починят; снимут ограничения; добавят возможность выполнять скрипты при смене состояния интерфейса.

Прочее

В current ветке MikroTik решили, что стоит использовать Interface List активнее и теперь следующие опции конфигурируются через списки интерфейсов, вместо конкретных интерфейсов:
* [IP]->[Neighbors]->[Discovery Settings]


* [Tools]->[MAC-Server]->[Mac-Telnet Server]&[Mac-Winbox Server]

После обновления не забывайте перенастроить.

Скрипты и cli

Вы можете столкнуться с ситуацией, когда один из интерфейсов в списке станет unknown(если удалите интерфейс до удаления из списка) и лично у меня так и не удалось найти способа простого(без зачистки всего списка и перезаполнения) удаления такого интерфейса средствами cli и скриптов. Если кто знает — пишите в комментарии.


На этом все. Надеюсь в мире станет меньше конфигураций с объединением интерфейсов в bridge ради уменьшения правил в firewall.