Mikrotik VRF+NAT — Управляем с одного хоста устройствами с одинаковыми IP-адресами

    Недавно знакомый попросил помощи с настройкой микротика. Просьба была не совсем простая. Идея в том, что нужно было одновременно управлять с одного хоста четырьмя устройствами с неуправляемым 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 - 192.168.2.11

    DEV2 - 192.168.2.12

    DEV3 - 192.168.2.13

    DEV4 - 192.168.2.14

    Комментарии 16

      0
      Мне кажется можно было сделать немного проще использовав отдельный vlan для каждого из интерфейсов и eth5 как транк?
        +3
        В смысле просто на уровне коммутации все? А как на управляющем хосте разделять эти устройства?
          0
          По vlan ID. Но похоже что действий будет столько же.
            0
            Если просто по Vlan ID на управляющем хосте, то как на разные устройства, у которых одинаковые IP, заходить? Какие настройки IP предлагаете на управляющем хосте сделать?
              0
              Я бы маркировал пакеты в зависимости от номера интерфейса и применял бы к ним правила NAT исходя из маркировки.
                0
                Теперь, я, похоже, понял идею. И, если я правильно ее понял, в таком случае на управляющем хосте придется делать 4 виртуальных интерфейса, для каждого vlan`a. В принципе, задачу это решит, но усложнит настройку интерфейсов на MGMT PC.
                В статье изложен вариант, в котором маршрутизатор берет на себя всю рутину и выступает в роли полноценного «переключателя». В таком случае на управляющем хосте нужно настроить только IP из нужной подсети.
                  0
                  Не обязательно. На маршрутизаторе одними правилами маркируем пакеты, а потом другими правилами распихиваем туда, куда нужно в зависимости от маркировки. Практически это повторяет вашу схему только не нужно делать несколько таблиц маршрутизации, достаточно правил NAT — одни маркируют, другие NAT-ят.
                  Мир многообразен и это хорошо ;-)
                    0
                    Коллега, у всех устройств одинаковые IP (их невозможно поменять по условию). Соответственно тогда на интерфейсах в сторону этих устройств должны быть IP-адреса из одной подсети или пересекающихся подсетей. Попробуйте используя лишь одну таблицу маршрутизации добавить одинаковые IP-адреса на разные интерфейсы маршрутизатора.
        0
        Замечательно оформили и легко читается, спасибо!
          0
          Удалил коментарий, так как пропустил один момент
            0
            Имел похожую проблему но куда тяжелей — нужно было поднимать с микротика несколько десятков РРТР-тунелей на одинаковую айпишку в разных виланах. Интересно как такое можно решить на микротике? Сама проблема в том что ДСТ-нат дейтсвует на входящий трафик, а к исходящему он не может применятся.
              0
              ИМХО, хватило бы и ip rule. VRF это все-таки немного более сильная штука, чем разделение таблиц маршрутизации на одном устройстве.
                0
                Оно сильнее грузит проц? По идее оно же и есть для такого — виртуального роутинга.
                  0
                  Да, согласен. Policy-routing тоже решил бы задачу. Действий было бы примерно столько же.
                    0
                    Хотя… Policy-routing ведь уже после NAT`а будет отрабатывать. Тогда снова встает вопрос — как различать адрес назначения? Ведь после NAT`а он будет одинаковый. В таком случае все равно придется использовать маркировку, что приведет практически к такому же решению, только с PBR. Имеет право на жизнь, как альтернативное решение. С точки зрения эстетики в чем-то Вы и правы — PBR проще VRF.
                    0
                    Можно ли сделать подобную «подмену» IP-адреса для IPSec VPN туннеля?
                    в туннеле на микротик сеть 172.27.88.0/24 а через VRF преобразуется в 192.168.88.0/24 (локалка микротика)
                    типа
                    172.27.88.4 -> 192.168.88.4
                    172.27.88.21 -> 192.168.88.21
                    и т.д.

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое