Недавно знакомый попросил помощи с настройкой микротика. Просьба была не совсем простая. Идея в том, что нужно было одновременно управлять с одного хоста четырьмя устройствами с неуправляемым TCP/IP стеком. На всех этих устройствах были одинаковые настройки IP, причем просто IP-адрес и маска, ни шлюз, ни DNS не указаны. Странная, но, как оказалось, весьма реальная ситуация. Не будем вдаваться в подробности причин невозможности перенастройки адресации на этих устройствах, а просто примем этот факт за аксиому. Задача поставлена так, как есть, и ее нужно решить.

Итак, исходные данные:
1. Четыре устройства с одинаковыми настройками IP — 192.168.1.1/24; GW и DNS не указаны; изменить эти настройки невозможно.
2. ПК, с которого необходимо одновременно иметь доступ ко всем четырем устройствам, допустим на WEB-интерфейс.
3. Простенький MikroTik RB750GL на 5 портов.

MikroTik RB750GL с настройками по умолчанию использует 1 порт для подключения к Интернету (NAT, FW), а остальные порты для подключения к локальной сети с настроенным DHCP — как обычный домашний роутер или роутер Small Business серии. Нам нужно задействовать все 5 портов, поэтому для начала полностью чистим конфиг и избавляемся от NAT, FW и DHCP.

Итак, кофиг очистили, собираем схему:
image

Теперь к делу…
Первая и основная проблема, которая встает перед нами — это использование одинаковых IP-адресов или IP-адресов из одной подсети на разных интерфейсах маршрутизатора для обеспечения сетевой доступности целевых устройств. Как трактуют основы сетевого взаимодействия с одной таблицей маршрутизации такое сделать невозможно. Значит надо сделать несколько таблиц маршрутизации, и в этом нам поможет Virtual Routing and Forwarding (VRF). Не будем сильно погружаться в VRF — нам достаточно просто поместить разные интерфейсы в разные таблицы маршрутизации:

/ip route vrf
add interfaces=ether1 routing-mark=DEV1
add interfaces=ether2 routing-mark=DEV2
add interfaces=ether3 routing-mark=DEV3
add interfaces=ether4 routing-mark=DEV4


Отлично. Теперь настроим IP-адресацию согласно схеме:
image

IP-адрес 192.168.2.1 будет использоваться для доступа к менеджменту самого MikroTik'а:
/ip address
add address=192.168.2.1/24 interface=ether5 network=192.168.2.0
add address=192.168.1.2/24 interface=ether1 network=192.168.1.0
add address=192.168.1.2/24 interface=ether2 network=192.168.1.0
add address=192.168.1.2/24 interface=ether3 network=192.168.1.0
add address=192.168.1.2/24 interface=ether4 network=192.168.1.0


Вспомним, что на самих устройствах, которыми нужно управлять, также отсутствует возможность настройки шлюза по умолчанию. Еще нам нужно как-то разделять эти устройства для доступа с MGMT PC. Естественно NAT. Для каждого устройства выделим IP из подсети 192.168.2.0/24 и настроим на интерфейсе ether5:
/ip address
add address=192.168.2.11/24 interface=ether5 network=192.168.2.0
add address=192.168.2.12/24 interface=ether5 network=192.168.2.0
add address=192.168.2.13/24 interface=ether5 network=192.168.2.0
add address=192.168.2.14/24 interface=ether5 network=192.168.2.0


Сам NAT пока не трогаем и вспоминаем, что наши пакеты должны «бегать» между разными таблицами маршрутизации. Для этого нужно ставить маршрутные метки согласно новым IP-адресам, которые в дальнейшем будем NAT'ировать. Согласно документации NetFilter таблица Mangle, которая отвечает за маркировку трафика, отрабатывает раньше таблицы NAT. Опираясь на этот факт делаем следующее:
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=192.168.2.11 new-routing-mark=DEV1
add action=mark-routing chain=prerouting dst-address=192.168.2.12 new-routing-mark=DEV2
add action=mark-routing chain=prerouting dst-address=192.168.2.13 new-routing-mark=DEV3
add action=mark-routing chain=prerouting dst-address=192.168.2.14 new-routing-mark=DEV4

На основе данных правил пакеты, поступающие на интерфейс ether5 от хоста управления, согласно IP-адресу назначения будут перекладываться в нужную таблицу маршрутизации, на нужный порт к целевому устройству.
Обратные пакеты от устройств необходимо возвращать в основную таблицу маршрутизации на интерфейс ether5, куда подключен наш хост управления. Для этого добавляем в Mangle еще одно правило:
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=192.168.2.2 new-routing-mark=main

На основе данного правила все пакеты с адресом назначения 192.168.2.2 будут перекладываться в основную таблицу маршрутизации «main», в которой и находится интерфейс хоста управления.

Осталось подумать о NAT. Для каждого устройства у нас будет по два правила:
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=192.168.2.11 in-interface=ether5 to-addresses=192.168.1.1
add action=src-nat chain=srcnat out-interface=ether1 to-addresses=192.168.1.2
add action=dst-nat chain=dstnat dst-address=192.168.2.12 in-interface=ether5 to-addresses=192.168.1.1
add action=src-nat chain=srcnat out-interface=ether2 to-addresses=192.168.1.2
add action=dst-nat chain=dstnat dst-address=192.168.2.13 in-interface=ether5 to-addresses=192.168.1.1
add action=src-nat chain=srcnat out-interface=ether3 to-addresses=192.168.1.2
add action=dst-nat chain=dstnat dst-address=192.168.2.14 in-interface=ether5 to-addresses=192.168.1.1
add action=src-nat chain=srcnat out-interface=ether4 to-addresses=192.168.1.2


Таким образом с помощью NAT'а и VRF мы представили для управляющего хоста устройства с одинаковыми IP-адресами, как устройства с разными IP-адресами, а с помощью NAT'а на интерфейсах, которые смотрят в сторону этих устройств, позволили им работать без шлюза по умолчанию.
В итоге, для управления целевыми устройствами (например, через web-интерфейс) на управляющем хосте необходимо набрать в браузере:
DEV1 - http://192.168.2.11
DEV2 - http://192.168.2.12
DEV3 - http://192.168.2.13
DEV4 - http://192.168.2.14

Комментарии (15)


  1. AxianLTD
    14.08.2015 17:28

    Мне кажется можно было сделать немного проще использовав отдельный vlan для каждого из интерфейсов и eth5 как транк?


    1. milex
      14.08.2015 17:41
      +3

      В смысле просто на уровне коммутации все? А как на управляющем хосте разделять эти устройства?


      1. AxianLTD
        16.08.2015 17:03

        По vlan ID. Но похоже что действий будет столько же.


        1. milex
          17.08.2015 01:13

          Если просто по Vlan ID на управляющем хосте, то как на разные устройства, у которых одинаковые IP, заходить? Какие настройки IP предлагаете на управляющем хосте сделать?


          1. AxianLTD
            17.08.2015 06:38

            Я бы маркировал пакеты в зависимости от номера интерфейса и применял бы к ним правила NAT исходя из маркировки.


            1. milex
              17.08.2015 07:07

              Теперь, я, похоже, понял идею. И, если я правильно ее понял, в таком случае на управляющем хосте придется делать 4 виртуальных интерфейса, для каждого vlan`a. В принципе, задачу это решит, но усложнит настройку интерфейсов на MGMT PC.
              В статье изложен вариант, в котором маршрутизатор берет на себя всю рутину и выступает в роли полноценного «переключателя». В таком случае на управляющем хосте нужно настроить только IP из нужной подсети.


              1. AxianLTD
                17.08.2015 07:18

                Не обязательно. На маршрутизаторе одними правилами маркируем пакеты, а потом другими правилами распихиваем туда, куда нужно в зависимости от маркировки. Практически это повторяет вашу схему только не нужно делать несколько таблиц маршрутизации, достаточно правил NAT — одни маркируют, другие NAT-ят.
                Мир многообразен и это хорошо ;-)


                1. milex
                  17.08.2015 09:45

                  Коллега, у всех устройств одинаковые IP (их невозможно поменять по условию). Соответственно тогда на интерфейсах в сторону этих устройств должны быть IP-адреса из одной подсети или пересекающихся подсетей. Попробуйте используя лишь одну таблицу маршрутизации добавить одинаковые IP-адреса на разные интерфейсы маршрутизатора.


  1. iluvar
    14.08.2015 20:33

    Замечательно оформили и легко читается, спасибо!


  1. erazel
    14.08.2015 21:13

    Удалил коментарий, так как пропустил один момент


  1. erazel
    14.08.2015 21:26

    Имел похожую проблему но куда тяжелей — нужно было поднимать с микротика несколько десятков РРТР-тунелей на одинаковую айпишку в разных виланах. Интересно как такое можно решить на микротике? Сама проблема в том что ДСТ-нат дейтсвует на входящий трафик, а к исходящему он не может применятся.


  1. Night_Snake
    14.08.2015 23:45

    ИМХО, хватило бы и ip rule. VRF это все-таки немного более сильная штука, чем разделение таблиц маршрутизации на одном устройстве.


    1. erazel
      15.08.2015 10:12

      Оно сильнее грузит проц? По идее оно же и есть для такого — виртуального роутинга.


    1. milex
      17.08.2015 07:19

      Да, согласен. Policy-routing тоже решил бы задачу. Действий было бы примерно столько же.


    1. milex
      17.08.2015 07:32

      Хотя… Policy-routing ведь уже после NAT`а будет отрабатывать. Тогда снова встает вопрос — как различать адрес назначения? Ведь после NAT`а он будет одинаковый. В таком случае все равно придется использовать маркировку, что приведет практически к такому же решению, только с PBR. Имеет право на жизнь, как альтернативное решение. С точки зрения эстетики в чем-то Вы и правы — PBR проще VRF.