Списки интерфейсов появились в 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=testether1-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. Черные линии.
Теперь в firewall можно разделить входящий(и проходящий со стороны wan/vpn) трафик с wan и vpn и написать отдельные правила, а исходящий(и проходящий в сторону wan/vpn) фильтровать вместе(там скорее всего будет банальный established, new) через inet.
Пример топорный, но другого у меня нет.
Добавление интерфейсов
Добавлять можно любые интерфейсы: 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.
Автор: Bulroh
