Итак, исходные данные:
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.
Итак, кофиг очистили, собираем схему:
Теперь к делу…
Первая и основная проблема, которая встает перед нами — это использование одинаковых 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-адресацию согласно схеме:
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)
erazel
14.08.2015 21:26Имел похожую проблему но куда тяжелей — нужно было поднимать с микротика несколько десятков РРТР-тунелей на одинаковую айпишку в разных виланах. Интересно как такое можно решить на микротике? Сама проблема в том что ДСТ-нат дейтсвует на входящий трафик, а к исходящему он не может применятся.
Night_Snake
14.08.2015 23:45ИМХО, хватило бы и ip rule. VRF это все-таки немного более сильная штука, чем разделение таблиц маршрутизации на одном устройстве.
erazel
15.08.2015 10:12Оно сильнее грузит проц? По идее оно же и есть для такого — виртуального роутинга.
milex
17.08.2015 07:19Да, согласен. Policy-routing тоже решил бы задачу. Действий было бы примерно столько же.
milex
17.08.2015 07:32Хотя… Policy-routing ведь уже после NAT`а будет отрабатывать. Тогда снова встает вопрос — как различать адрес назначения? Ведь после NAT`а он будет одинаковый. В таком случае все равно придется использовать маркировку, что приведет практически к такому же решению, только с PBR. Имеет право на жизнь, как альтернативное решение. С точки зрения эстетики в чем-то Вы и правы — PBR проще VRF.
AxianLTD
Мне кажется можно было сделать немного проще использовав отдельный vlan для каждого из интерфейсов и eth5 как транк?
milex
В смысле просто на уровне коммутации все? А как на управляющем хосте разделять эти устройства?
AxianLTD
По vlan ID. Но похоже что действий будет столько же.
milex
Если просто по Vlan ID на управляющем хосте, то как на разные устройства, у которых одинаковые IP, заходить? Какие настройки IP предлагаете на управляющем хосте сделать?
AxianLTD
Я бы маркировал пакеты в зависимости от номера интерфейса и применял бы к ним правила NAT исходя из маркировки.
milex
Теперь, я, похоже, понял идею. И, если я правильно ее понял, в таком случае на управляющем хосте придется делать 4 виртуальных интерфейса, для каждого vlan`a. В принципе, задачу это решит, но усложнит настройку интерфейсов на MGMT PC.
В статье изложен вариант, в котором маршрутизатор берет на себя всю рутину и выступает в роли полноценного «переключателя». В таком случае на управляющем хосте нужно настроить только IP из нужной подсети.
AxianLTD
Не обязательно. На маршрутизаторе одними правилами маркируем пакеты, а потом другими правилами распихиваем туда, куда нужно в зависимости от маркировки. Практически это повторяет вашу схему только не нужно делать несколько таблиц маршрутизации, достаточно правил NAT — одни маркируют, другие NAT-ят.
Мир многообразен и это хорошо ;-)
milex
Коллега, у всех устройств одинаковые IP (их невозможно поменять по условию). Соответственно тогда на интерфейсах в сторону этих устройств должны быть IP-адреса из одной подсети или пересекающихся подсетей. Попробуйте используя лишь одну таблицу маршрутизации добавить одинаковые IP-адреса на разные интерфейсы маршрутизатора.