Комментарии 16
Мне кажется можно было сделать немного проще использовав отдельный vlan для каждого из интерфейсов и eth5 как транк?
В смысле просто на уровне коммутации все? А как на управляющем хосте разделять эти устройства?
По vlan ID. Но похоже что действий будет столько же.
Если просто по Vlan ID на управляющем хосте, то как на разные устройства, у которых одинаковые IP, заходить? Какие настройки IP предлагаете на управляющем хосте сделать?
Я бы маркировал пакеты в зависимости от номера интерфейса и применял бы к ним правила NAT исходя из маркировки.
Теперь, я, похоже, понял идею. И, если я правильно ее понял, в таком случае на управляющем хосте придется делать 4 виртуальных интерфейса, для каждого vlan`a. В принципе, задачу это решит, но усложнит настройку интерфейсов на MGMT PC.
В статье изложен вариант, в котором маршрутизатор берет на себя всю рутину и выступает в роли полноценного «переключателя». В таком случае на управляющем хосте нужно настроить только IP из нужной подсети.
В статье изложен вариант, в котором маршрутизатор берет на себя всю рутину и выступает в роли полноценного «переключателя». В таком случае на управляющем хосте нужно настроить только IP из нужной подсети.
Не обязательно. На маршрутизаторе одними правилами маркируем пакеты, а потом другими правилами распихиваем туда, куда нужно в зависимости от маркировки. Практически это повторяет вашу схему только не нужно делать несколько таблиц маршрутизации, достаточно правил NAT — одни маркируют, другие NAT-ят.
Мир многообразен и это хорошо ;-)
Мир многообразен и это хорошо ;-)
Коллега, у всех устройств одинаковые IP (их невозможно поменять по условию). Соответственно тогда на интерфейсах в сторону этих устройств должны быть IP-адреса из одной подсети или пересекающихся подсетей. Попробуйте используя лишь одну таблицу маршрутизации добавить одинаковые IP-адреса на разные интерфейсы маршрутизатора.
Замечательно оформили и легко читается, спасибо!
Удалил коментарий, так как пропустил один момент
Имел похожую проблему но куда тяжелей — нужно было поднимать с микротика несколько десятков РРТР-тунелей на одинаковую айпишку в разных виланах. Интересно как такое можно решить на микротике? Сама проблема в том что ДСТ-нат дейтсвует на входящий трафик, а к исходящему он не может применятся.
ИМХО, хватило бы и ip rule. VRF это все-таки немного более сильная штука, чем разделение таблиц маршрутизации на одном устройстве.
Оно сильнее грузит проц? По идее оно же и есть для такого — виртуального роутинга.
Да, согласен. Policy-routing тоже решил бы задачу. Действий было бы примерно столько же.
Хотя… Policy-routing ведь уже после NAT`а будет отрабатывать. Тогда снова встает вопрос — как различать адрес назначения? Ведь после NAT`а он будет одинаковый. В таком случае все равно придется использовать маркировку, что приведет практически к такому же решению, только с PBR. Имеет право на жизнь, как альтернативное решение. С точки зрения эстетики в чем-то Вы и правы — PBR проще VRF.
Можно ли сделать подобную «подмену» 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
и т.д.
в туннеле на микротик сеть 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
и т.д.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Mikrotik VRF+NAT — Управляем с одного хоста устройствами с одинаковыми IP-адресами