Гайд по Interface List в MikroTik

Списки интерфейсов появились в 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 — исключить из нового списка интерфейсы из указанного списка
o87ueiwn9n0infdw2bhp2xx9fla.png
Консольный вариант:

/interface list add name=test


Пример использования include
Есть следующие интерфейсы для выхода в интернет:
ether1-wan (real ip)
ether2-wan (real ip)
l2tp-vpn1(gray ip)
l2tp-vpn2(gray ip)

С первых двух, ожидаем входящие соединения из вне, со вторых если они и будут, то нас не интересуют.
Интерфейсы ether1-wan и ether2-wan объединены в список wan. Зеленые линии.
Интерфейсы l2tp-vpn1 и l2tp-vpn2 объединены в список vpn. Красные линии.
Список inet содержит (include) в себе wan и vpn. Черные линии.
hrv7yclcksuwd13nk2pzqcbe7lq.png
Теперь в firewall можно разделить входящий (и проходящий со стороны wan/vpn) трафик с wan и vpn и написать отдельные правила, а исходящий (и проходящий в сторону wan/vpn) фильтровать вместе (там скорее всего будет банальный established, new) через inet.

Пример топорный, но другого у меня нет.


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

/interface list member
add interface=ether1 list=test

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

Раньше:
Проверяем in-interface, отправляем в цепочку-1.
В цепочке-1 проверяем out-interface, отправляем в цепочку-2.
В цепочке-2 настраиваем правила.
qez9jawzudxpqwsg11hfq8hj8mg.png
И так для каждого интерфейса. 4 подключения — 8 правил, 8 подключений — 16 правил. Подключения динамические? Можно выкрутиться и использовать all ppp, перекинуть в цепочку-1, а потом из цепочки-1 return’ить лишние интерфейсы.

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

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

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

Использование в firewall nat
Когда списки интерфейсов только появились, на форуме mikrotik жаловались на работу interface lists в nat, сейчас вроде починили. Решил поисследовать
Тестовый стенд:
e8koyeez2ohyxyitrjoj9ycdheg.png
На схеме не хватает адресов для 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]
8mvhsh4bgd0y2k0hykyvf2jyywc.png

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

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

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 не отправляются. Ждем и надеемся, что: починят; снимут ограничения; добавят возможность выполнять скрипты при смене состояния интерфейса.

Заголовок спойлера
3alkluuy0cepvpkwqbyra0_txus.png


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

* [Tools]→[MAC-Server]→[Mac-Telnet Server]&[Mac-Winbox Server]
pfbxgrlkcsrorvbwweyi7png9ps.pngnvjkccfj5qcpk_n31qetk2zqo8e.png
После обновления не забывайте перенастроить.

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

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

© Habrahabr.ru