ProHoster > Блог > адміністрування > Мультиван та маршрутизація на Mikrotik RouterOS

Мультиван та маршрутизація на Mikrotik RouterOS

Запровадження

Взятися за статтю, крім марнославства, спонукала гнітюча частота виникнення питань на цю тему в профільних групах російськомовного телеграм-спільноти. Стаття орієнтована на адміністраторів-початківців Mikrotik RouterOS (далі ROS). У ній розглядається лише мультиван, з акцентом на маршрутизацію. Бонусом є мінімально достатні налаштування для забезпечення безпечної та зручної роботи. Ті, хто шукає розкриття тем черг, балансування навантаження, вланів, бриджів, багатоступінчастого глибокого аналізу стану каналу тощо — можуть не витрачати часу та сил на прочитання.

Початкові дані

Як піддослідний, обраний п'ятипортовий маршрутизатор Mikrotik із ROS версії 6.45.3. Він маршрутизуватиме трафік між двома локальними мережами (LAN1 і LAN2) і трьома провайдерами (ISP1, ISP2, ISP3). Канал до ISP1 має статичний "сірий" адресу, ISP2 - "білий", що отримується по DHCP, ISP3 - "білий" з PPPoE авторизацією. Схема підключення представлена ​​малюнку:

Мультиван та маршрутизація на Mikrotik RouterOS

Завдання налаштувати роутер "МТК" на основі схеми так, щоб:

  1. Забезпечити автоматичне перемикання на резервного провайдера. Основний провайдер - ISP2, перший резерв - ISP1, другий резерв - ISP3.
  2. Організувати вихід мережі LAN1 в Інтернет лише через ISP1.
  3. Передбачити можливість маршрутизувати трафік з локальних мереж до Інтернету через вибраного провайдера на основі address-list.
  4. Передбачити можливість опублікування сервісів з локальної мережі в Інтернет (DSTNAT)
  5. Налаштувати фільтр брандмауера для забезпечення мінімально достатньої безпеки з боку Інтернет.
  6. Роутер міг випускати свій трафік через будь-якого з трьох провайдерів залежно від обраної адреси джерела.
  7. Забезпечити маршрутизацію пакетів у відповідь у канал, з якого вони прийшли (включаючи LAN).

Зауваження. Налаштовувати роутер будемо "з чистого аркуша", щоб гарантувати відсутність сюрпризів у мінливих від версії до версії стартових конфігураціях "з коробки". Як інструмент налаштування вибрано Winbox, де наочно відображатимуться зміни. Самі установки будуть задаватися командами в терміналі Winbox. Фізичне підключення для налаштування здійснюється прямим з'єднанням з інтерфейсом Ether5.

Небагато міркувань про те, що таке мультиван, чи це проблема чи хитрі розумники навколо плетуть мережі змов

Допитливий та уважний адмін, самостійно налаштовуючи таку чи подібну схему, раптом несподівано усвідомлює, що воно й так нормально працює. Так-так, без цих ваших користувацьких таблиць маршрутизації та інших route rules, якими рясніють більшість статей на цю тему. Перевіримо?

Адресацію на інтерфейсах та шлюзи за замовчуванням налаштувати можемо? Так:

На ISP1 прописали адресу та шлюз з відстань=2 и check-gateway=ping.
На ISP2 налаштування dhcp клієнта за умовчанням - відповідно distance дорівнюватиме одиниці.
На ISP3 у налаштуваннях pppoe клієнта при add-default-route=yes ставимо default-route-distance=3.

NAT на вихід прописати не забуваємо:

/ip firewall nat add action=masquerade chain=srcnat out-interface-list=WAN

За підсумками, у користувачів локалок котики весело вантажаться через основного провайдера ISP2 і є резервування каналу за допомогою механізму check gateway Див. примітку 1

Пункт 1 завдання реалізовано. Де ж мультиван зі своїми мітками? Ні…

Далі. Потрібно випустити конкретних клієнтів із LAN через ISP1:

/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=yes route-dst=100.66.66.1 src-address-list=Via_ISP1
/ip firewall mangle add action=route chain=prerouting dst-address-list=!BOGONS
passthrough=no route-dst=100.66.66.1 src-address=192.168.88.0/24

Пункти 2 та 3 завдання реалізовані. Мітки, марки, route rules, де ви?!

Чи потрібно дати доступ до улюбленого OpenVPN сервера з адресою 172.17.17.17 для клієнтів з Інтернету? Будь ласка:

/ip cloud set ddns-enabled=yes

Клієнтам як бенкет даємо результат висновку: “:put [ip cloud get dns-name]"

Прописуємо прокидання порту з инета:

/ip firewall nat add action=dst-nat chain=dstnat dst-port=1194
in-interface-list=WAN protocol=udp to-addresses=172.17.17.17

Пункт 4 готовий.

Налаштовуємо фаєрвол та іншу безпеку для пункту 5, паралельно радіємо тому, що у користувачів вже все працює і тягнемося до ємності з улюбленим напоєм.
А! Тунелі ще забули.

l2tp-клієнт, налаштований за нагугленою статтею, до улюбленого голландського VDS піднявся? Так.
l2tp-сервер з IPsec піднявся і клієнти по ДНС-імені з IP Cloud(див. вище) чіпляються? Так.
Відкинувшись на спинку стільця, прихлинаючи напій, ліниво розглядаємо пункти 6 і 7 завдання. Думаємо, а воно нам треба? Все ж таки і так працює (с)… Так от якщо воно таки не треба, то на цьому все. Мультиван реалізовано.

Що таке мультіван? Це підключення кількох каналів Інтернету до одного роутера.

Далі статтю можна не читати, оскільки що там окрім випендрежа сумнівної застосовності може бути?

З тими, хто залишився, хто зацікавлений пунктами 6 і 7 завдання, а також відчуває свербіж перфекціонізму, поринаємо глибше.

Найважливішим завданням реалізації мультиван є коректна маршрутизація трафіку. А саме: незалежно від того, в якій (або в які) Див. 3 канал(и) провайдера дивиться маршрут за замовчуванням на нашому роутері, він повинен повертати відповідь саме в той канал, з якого пакет прийшов. Завдання зрозуміле. Проблема де? Адже в простій локальній мережі завдання те саме, але ніхто додатковими налаштуваннями не морочиться і біди не відчуває. Відмінність у тому, що будь-який маршрутизований вузол в Інтернеті доступний через кожен з наших каналів, а не через суворо конкретний, як у простій локалці. А "біда" полягає в тому, що якщо до нас прийшов запит на IP адресу ISP3, то в нашому випадку відповідь піде через канал ISP2, оскільки туди направлений стандартний шлюз. Піде і буде відкинуто провайдером, як некоректний. Із проблемою визначилися. Як її вирішувати?

Рішення розділимо на три етапи:

  1. Попереднє налаштування. На цьому етапі будуть задані базові налаштування маршрутизатора: локальна мережа, фаєрвол, address lists, hairpin NAT та ін.
  2. Мультиван. На цьому етапі будуть промарковані та розсортовані за таблицями маршрутизації необхідні з'єднання.
  3. Підключення до ISP. На цьому етапі будуть налаштовані інтерфейси, що забезпечують підключення до Інтернету, задіяна маршрутизація та механізм резервування каналів Інтернету.

1. Попереднє налаштування

1.1. Очищаємо конфігурацію роутера командою:

/system reset-configuration skip-backup=yes no-defaults=yes

погоджуємося з “Dangerous! Reset anyway? [y/N]:” і, після перезавантаження, підключаємося Winbox-ом по MAC. На цьому етапі конфігурація та база користувачів очищені.

1.2. Створюємо нового користувача:

/user add group=full name=knight password=ultrasecret comment=”Not horse”

логінимся під ним і видаляємо дефолтного:

/user remove admin

Зауваження. Саме видалення, а не відключення дефолтного користувача, автор вважає більш безпечним і рекомендує до застосування.

1.3. Створюємо базові interface lists для зручності оперування у фаєрволлі, налаштуваннях discovery та інших MAC серверах:

/interface list add name=WAN comment="For Internet"
/interface list add name=LAN comment="For Local Area"

Підписуємо коментарями інтерфейси

/interface ethernet set ether1 comment="to ISP1"
/interface ethernet set ether2 comment="to ISP2"
/interface ethernet set ether3 comment="to ISP3"
/interface ethernet set ether4 comment="to LAN1"
/interface ethernet set ether5 comment="to LAN2"

і заповнюємо interface lists:

/interface list member add interface=ether1 list=WAN comment=ISP1
/interface list member add interface=ether2 list=WAN comment=ISP2 
/interface list member add interface=ether3 list=WAN comment="to ISP3"
/interface list member add interface=ether4 list=LAN  comment="LAN1"
/interface list member add interface=ether5 list=LAN  comment="LAN2"

Зауваження. Писати зрозумілі коментарі варто витраченого на це часу плюс сильно полегшує траблшутинг та розуміння конфігурації.

Автор вважає за необхідне, з метою безпеки, додати в interface list "WAN" інтерфейс ether3, незважаючи на те, що по ньому не ходитиме протокол ip.

Не забуваймо, що після того, як на ether3 буде піднятий інтерфейс PPP, його також потрібно буде додати в interface list “WAN”

1.4. Приховуємо роутер від виявлення сусідства та управління з мереж провайдерів МАС:

/ip neighbor discovery-settings set discover-interface-list=!WAN
/tool mac-server set allowed-interface-list=LAN
/tool mac-server mac-winbox set allowed-interface-list=LAN

1.5. Створюємо мінімально достатній набір правил фільтра файрволу для захисту роутера:

/ip firewall filter add action=accept chain=input comment="Related Established Untracked Allow" 
connection-state=established,related,untracked

(правило забезпечує дозвіл для встановлених та споріднених з'єднань, які ініційовані як із підключених мереж, так і самим роутером)

/ip firewall filter add action=accept chain=input comment="ICMP from ALL" protocol=icmp

(пінг і не тільки пінг. Дозволено весь icmp на вхід. Дуже корисно для знаходження проблем з MTU)

/ip firewall filter add action=drop chain=input comment="All other WAN Drop" in-interface-list=WAN

(закриває ланцюжок input правило забороняє все інше, що прилітає з Інтернету)

/ip firewall filter add action=accept chain=forward 
comment="Established, Related, Untracked allow" 
connection-state=established,related,untracked

(Правило дозволяє встановилися та споріднені з'єднання, які проходять крізь роутер)

/ip firewall filter add action=drop chain=forward comment="Invalid drop" connection-state=invalid

(Правило скидає з'єднання, з connection-state=invalid, що проходять крізь роутер. Воно настійно рекомендовано Mikrotik, але в деяких рідкісних ситуаціях може викликати блокування корисного трафіку)

/ip firewall filter add action=drop chain=forward comment="Drop all from WAN not DSTNATed"  
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

(Правило забороняє проходити крізь роутер пакетам, які йдуть з Інтернету і не пройшли процедуру dstnat. Це вбереже локальні мережі від зловмисників, які, перебуваючи в одному широкомовному домені з нашими зовнішніми мережами, пропишуть як шлюз наші зовнішні IP і, таким чином, спробують “дослідити” наші локальні мережі.

Зауваження. Приймемо за умову, що мережі LAN1 та LAN2 є довіреними та трафік між ними і з них не фільтрується.

1.6. Створюємо список з переліком мереж, що не маршрутизуються:

/ip firewall address-list
add address=0.0.0.0/8 comment=""This" Network" list=BOGONS
add address=10.0.0.0/8 comment="Private-Use Networks" list=BOGONS
add address=100.64.0.0/10 comment="Shared Address Space. RFC 6598" list=BOGONS
add address=127.0.0.0/8 comment=Loopback list=BOGONS
add address=169.254.0.0/16 comment="Link Local" list=BOGONS
add address=172.16.0.0/12 comment="Private-Use Networks" list=BOGONS
add address=192.0.0.0/24 comment="IETF Protocol Assignments" list=BOGONS
add address=192.0.2.0/24 comment=TEST-NET-1 list=BOGONS
add address=192.168.0.0/16 comment="Private-Use Networks" list=BOGONS
add address=198.18.0.0/15 comment="Network Interconnect Device Benchmark Testing"
 list=BOGONS
add address=198.51.100.0/24 comment=TEST-NET-2 list=BOGONS
add address=203.0.113.0/24 comment=TEST-NET-3 list=BOGONS
add address=224.0.0.0/4 comment=Multicast list=BOGONS
add address=192.88.99.0/24 comment="6to4 Relay Anycast" list=BOGONS
add address=240.0.0.0/4 comment="Reserved for Future Use" list=BOGONS
add address=255.255.255.255 comment="Limited Broadcast" list=BOGONS

(Це список адрес і мереж, які не маршрутизуються в Інтернет і, відповідно, ми також будемо це слідувати.)

Зауваження. Список може змінюватись, тому раджу періодично перевіряти актуальність.

1.7. Налаштовуємо DNS для самого роутера:

/ip dns set servers=1.1.1.1,8.8.8.8

Зауваження. У поточній версії ROS динамічні сервери мають пріоритет перед статично заданими. Запит на дозвіл імені надсилається першому серверу за порядком прямування у списку. На наступний сервер перехід здійснюється за недоступності поточного. Таймаут великий – понад 5 сек. Повернення назад, при відновленні роботи сервера, що впав, автоматично не відбувається. З урахуванням цього алгоритму та наявності мультивану автор рекомендує не використовувати сервери, що видаються провайдерами.

1.8. Налаштовуємо локальну мережу.
1.8.1. Конфігуруємо статичні IP-адреси на інтерфейсах локальних мереж:

/ip address add interface=ether4 address=192.168.88.254/24 comment="LAN1 IP"
/ip address add interface=ether5 address=172.16.1.0/23 comment="LAN2 IP"

1.8.2. Задаємо правила маршрутів до наших локальних мереж через головну таблицю маршрутизації:

/ip route rule add dst-address=192.168.88.0/24 table=main comment=”to LAN1”
/ip route rule add dst-address=172.16.0.0/23 table=main comment="to LAN2"

Зауваження. Це один із простих і швидких способів отримати доступ до адрес локальних мереж із соурсами зовнішніх IP адрес інтерфейсів роутера, через які не йде маршрут за замовчуванням.

1.8.3. Включаємо Hairpin NAT для LAN1 та LAN2:

/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN1" 
out-interface=ether4 src-address=192.168.88.0/24 to-addresses=192.168.88.254
/ip firewall nat add action=src-nat chain=srcnat comment="Hairpin to LAN2" 
out-interface=ether5 src-address=172.16.0.0/23 to-addresses=172.16.1.0

Зауваження. Це дозволяє отримати доступ через зовнішній IP на свої ресурси (dstnat), перебуваючи всередині мережі.

2. Власне, реалізація того самого коректного мультивану

Для вирішення завдання “відповідати туди, звідки запитали” будемо використовувати два інструменти ROS: connection mark и routing mark. Connection mark дозволяє позначити потрібне з'єднання і надалі працювати з цією міткою як умовою для застосування routing mark. А вже з routing mark можливо працювати в ip маршрут и route rules. З інструментами розібралися, тепер треба вирішити якісь сполуки мітити — раз, де саме мітити — два.

З першим все просто — ми маємо помітити всі з'єднання, які приходять на роутер із Інтернету по відповідному каналу. У нашому випадку це будуть три мітки (за кількістю каналів): "conn_isp1", "conn_isp2" та "conn_isp3".

Нюанс з другим полягає в тому, що вхідні з'єднання будуть двох видів: транзитні та ті, що призначені самому роутеру. Механізм connection mark працює у таблиці гадюка. Розглянемо рух пакету на спрощеній діаграмі, люб'язно зібраній фахівцями ресурсу www.microtik-trainings.com (не реклама):

Мультиван та маршрутизація на Mikrotik RouterOS

Наслідуючи стрілки, ми бачимо, що пакет, що приходить у “Вхідний інтерфейс”, проходить ланцюжком “Prerouting” і лише потім поділяється на транзитний та локальний у блоці “Рішення про маршрутизацію”. Тому, для вбивства двох зайців, задіємо Знак підключення в таблиці Mangle Prerouting ланцюжки Prerouting.

зауваження. У ROS мітки “Routing mark” вказані у розділі Ip/Routes/Rules як “Table”, а інших розділах, як “Routing Mark”. Це може внести якусь плутанину в розуміння, але, по суті, це те саме, і є аналогом rt_tables в iproute2 на linux.

2.1. Маємо вхідні з'єднання від кожного з провайдерів:

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP1" connection-mark=no-mark in-interface=ether1  new-connection-mark=conn_isp1 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP2" connection-mark=no-mark in-interface=ether2  new-connection-mark=conn_isp2 passthrough=no

/ip firewall mangle add action=mark-connection chain=prerouting 
comment="Connmark in from ISP3" connection-mark=no-mark in-interface=pppoe-isp3  new-connection-mark=conn_isp3 passthrough=no

Зауваження. Для того, щоб не мітити вже позначені з'єднання я використовую умову connection-mark=no-mark замість connection-state=new тому, що вважаю це коректнішим, як і відмова від drop invalid з'єднань у фільтрі input.


passthrough = no - тому, що в цьому способі реалізації перемаркування виключена і для прискорення можна перервати перебір правил після першого збігу.

Слід мати на увазі, що ми поки що ніяк не втручаємося в маршрутизацію. Нині тривають лише етапи підготовки. Наступним етапом реалізації буде обробка транзитного трафіку, який повертається по з'єднанню, що встановилося, від адресата в локальній мережі. Тобто. тих пакетів, які (див діаграму) пройшли через роутер шляхом:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” і потрапили до свого адресата у локальній мережі.

Важливо! У ROS немає логічного поділу на зовнішній та внутрішній інтерфейси. Якщо простежити шлях руху пакету у відповідь по наведеній діаграмі, то він пройде тим же логічним шляхом, що і запит:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Forward”=>”Post Routing”=>”Output Interface” просто для запиту “вхідний інтерфейс” був інтерфейс ISP, а відповіді — LAN

2.2. Надсилаємо транзитний трафік у відповідність до таблиць маршрутизації:

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP1" connection-mark=conn_isp1 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP2" connection-mark=conn_isp2 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Routemark transit out via ISP3" connection-mark=conn_isp3 
dst-address-type=!local in-interface-list=!WAN new-routing-mark=to_isp3 passthrough=no

Зауваження. in-interface-list=!WAN — ми працюємо тільки з трафіком з локальної мережі та dst-address-type=!local, що не має адреси призначення адреси інтерфейсів самого роутера.

Те саме для локальних пакетів, які прийшли на роутер шляхом:

“Input Interface”=>”Prerouting”=>”Routing Decision”=>”Input”=>”Local Process”

Важливо! Відповідь піде наступним шляхом:

”Local Process”=>”Routing Decision”=>”Output”=>”Post Routing”=>”Output Interface”

2.3. Надсилаємо локальний трафік у відповідь за відповідними таблицями маршрутизації:

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP1" connection-mark=conn_isp1 dst-address-type=!local 
new-routing-mark=to_isp1 passthrough=no

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP2" connection-mark=conn_isp2 dst-address-type=!local 
new-routing-mark=to_isp2 passthrough=no

/ip firewall mangle add action=mark-routing chain=output 
comment="Routemark local out via ISP3" connection-mark=conn_isp3 dst-address-type=!local 
new-routing-mark=to_isp3 passthrough=no

На цьому етапі завдання підготовки до відправки відповіді в той Інтернет, з якого прийшов запит можна вважати вирішеною. Все позначено, промарковано та готове маршрутизуватися.
Відмінним “побічним” ефектом такого налаштування є можливість роботи прокидання портів DSNAT з обох (ISP2, ISP3) провайдерів одночасно. Не на всіх, тому що на ISP1 у нас не маршрутизується адреса. Цей ефект важливий, наприклад, для поштового сервера із двома MХ, які дивляться у різні канали Інтернет.

Для усунення нюансів роботи локальних мереж із зовнішніми IP роутерами використовуємо рішення з пп. 1.8.2 та 3.1.2.6.

Крім того, можна задіяти інструмент з маркуванням та для вирішення пункту 3 завдання. Реалізуємо так:

2.4. Надсилаємо трафік від локальних клієнтів зі списків маршрутизації до відповідних таблиць:

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP1" dst-address-list=!BOGONS new-routing-mark=to_isp1 
passthrough=no src-address-list=Via_ISP1

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP2" dst-address-list=!BOGONS new-routing-mark=to_isp2 
passthrough=no src-address-list=Via_ISP2

/ip firewall mangle add action=mark-routing chain=prerouting 
comment="Address List via ISP3" dst-address-list=!BOGONS new-routing-mark=to_isp3 
passthrough=no src-address-list=Via_ISP3

За підсумками, це виглядає приблизно так:

Мультиван та маршрутизація на Mikrotik RouterOS

3. Налаштовуємо підключення до ISP і використовуємо маршрутизацію по марках

3.1. Налаштовуємо підключення до ISP1:
3.1.1. Конфігуруємо статичну IP адресу:

/ip address add interface=ether1 address=100.66.66.2/30 comment="ISP1 IP"

3.1.2. Налаштовуємо статичну маршрутизацію:
3.1.2.1. Додаємо “аварійний” маршрут за замовчуванням:

/ip route add comment="Emergency route" distance=254 type=blackhole

Зауваження. Цей маршрут дозволяє трафіку від локальних процесів проходити етап Route Decision незалежно від стану каналів будь-якого провайдера. Нюанс вихідного локального трафіку полягає в тому, щоб пакет хоч кудись рушив, в основній таблиці маршрутизації повинен бути активний маршрут до шлюзу за замовчуванням. Якщо його немає, пакет просто буде знищений.

Як розширення інструменту check gateway для глибшого аналізу стану каналу пропоную використовувати метод рекурсивних маршрутів. Суть методу у тому, що ми вказуємо маршрутизатору шукати шлях до свого шлюзу не безпосередньо, а ще через проміжний шлюз. Як такі “перевірочні” шлюзи будуть обрані 4.2.2.1, 4.2.2.2 та 4.2.2.3 відповідно для ISP1, ISP2 та ISP3.

3.1.2.2. Маршрут до "перевірочної" адреси:

/ip route add check-gateway=ping comment="For recursion via ISP1"  
distance=1 dst-address=4.2.2.1 gateway=100.66.66.1 scope=10

Зауваження. Значення scope знижуємо до дефолтного в ROS target scope, щоб використовувати надалі 4.2.2.1 як рекурсивний шлюз. Підкреслюю: scope маршруту до “перевірочної” адреси має бути меншою або рівною target scope того маршруту, який буде посилатися на перевірочний.

3.1.2.3. Рекурсивний маршрут за промовчанням для трафіку без routing mark:

/ip route add comment="Unmarked via ISP1" distance=2 gateway=4.2.2.1

Зауваження. Значення distance=2 використовується тому, що ISP1 за умовами задачі заявлено як резервний.

3.1.2.4. Рекурсивний маршрут за промовчанням для трафіку c routing mark “to_isp1”:

/ip route add comment="Marked via ISP1 Main" distance=1 gateway=4.2.2.1 
routing-mark=to_isp1

Зауваження. Власне, тут ми починаємо користуватися плодами тієї підготовчої роботи, що була проведена в пункті 2.


За цим маршрутом весь трафік, який має mark route “to_isp1”, буде спрямований на шлюз першого провайдера незалежно від того, який активний шлюз за замовчуванням для таблиці main.

3.1.2.5. Перший резервний рекурсивний маршрут за промовчанням для маркованого трафіку провайдерів ISP2 та ISP3:

/ip route add comment="Marked via ISP2 Backup1" distance=2 gateway=4.2.2.1 
routing-mark=to_isp2
/ip route add comment="Marked via ISP3 Backup1" distance=2 gateway=4.2.2.1 
routing-mark=to_isp3

Зауваження. Ці маршрути потрібні, в тому числі, для резервування трафіку з локальних мереж, які є членами address list “to_isp*”'

3.1.2.6. Прописуємо маршрут для локального трафіку роутера в інтернет через ISP1:

/ip route rule add comment="From ISP1 IP to Inet" src-address=100.66.66.2 table=to_isp1

Зауваження. У поєднанні з правилами пункту 1.8.2 забезпечується вихід у потрібний канал із заданим соурсом. Це є критичним для побудови тунелів, в яких задається IP-адреса локальної сторони (EoIP, IP-IP, GRE). Оскільки правила в ip route rules виконуються зверху вниз, до першого збігу умов, це правило має бути після правил з пункту 1.8.2.

3.1.3. Прописуємо правило NAT для вихідного трафіку:

/ip firewall nat add action=src-nat chain=srcnat comment="NAT via ISP1"  
ipsec-policy=out,none out-interface=ether1 to-addresses=100.66.66.2

Зауваження. NAT їм все, що виходить, крім того, що потрапляє в політики IPsec. Я намагаюся не використовувати action=masquerade без нагальної потреби. Воно працює повільніше і ресурсомісткіше, ніж src-nat, оскільки для кожного нового з'єднання обчислює адресу для NAT.

3.1.4. Надсилаємо клієнтів зі списку, яким заборонено вихід через решту провайдерів відразу на шлюз провайдера ISP1.

/ip firewall mangle add action=route chain=prerouting comment="Address List via ISP1 only" 
dst-address-list=!BOGONS passthrough=no route-dst=100.66.66.1 
src-address-list=Via_only_ISP1 place-before=0

Зауваження. action=route має вищий пріоритет і застосовується раніше від інших правил маршрутизації.


place-before=0 - поміщає наше правило першим у списку.

3.2. Налаштовуємо підключення до ISP2.

Оскільки провайдер ISP2 налаштування нам видає DHCP, розумно необхідні зміни робити скриптом, який стартує при спрацюванні DHCP клієнта:

/ip dhcp-client
add add-default-route=no disabled=no interface=ether2 script=":if ($bound=1) do={r
    n    /ip route add check-gateway=ping comment="For recursion via ISP2" distance=1 
           dst-address=4.2.2.2/32 gateway=$"gateway-address" scope=10r
    n    /ip route add comment="Unmarked via ISP2" distance=1 gateway=4.2.2.2;r
    n    /ip route add comment="Marked via ISP2 Main" distance=1 gateway=4.2.2.2 
           routing-mark=to_isp2;r
    n    /ip route add comment="Marked via ISP1 Backup1" distance=2 gateway=4.2.2.2 
           routing-mark=to_isp1;r
    n    /ip route add comment="Marked via ISP3 Backup2" distance=3 gateway=4.2.2.2 
           routing-mark=to_isp3;r
    n    /ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none 
           out-interface=$"interface" to-addresses=$"lease-address" comment="NAT via ISP2" 
           place-before=1;r
    n    if ([/ip route rule find comment="From ISP2 IP to Inet"] ="") do={r
    n        /ip route rule add comment="From ISP2 IP to Inet" 
               src-address=$"lease-address" table=to_isp2 r
    n    } else={r
    n       /ip route rule set [find comment="From ISP2 IP to Inet"] disabled=no 
              src-address=$"lease-address"r
    n    }      r
    n} else={r
    n   /ip firewall nat remove  [find comment="NAT via ISP2"];r
    n   /ip route remove [find comment="For recursion via ISP2"];r
    n   /ip route remove [find comment="Unmarked via ISP2"];r
    n   /ip route remove [find comment="Marked via ISP2 Main"];r
    n   /ip route remove [find comment="Marked via ISP1 Backup1"];r
    n   /ip route remove [find comment="Marked via ISP3 Backup2"];r
    n   /ip route rule set [find comment="From ISP2 IP to Inet"] disabled=yesr
    n}r
    n" use-peer-dns=no use-peer-ntp=no

Сам скрипт у вікні Winbox:

Мультиван та маршрутизація на Mikrotik RouterOS
Зауваження. Перша частина скрипту спрацьовує за успішного отримання оренди, друга — після звільнення оренди.Див. примітку 2

3.3. Налаштовуємо підключення до провайдера ISP3.

Оскільки провайдер налаштування нам видає динамічні, то розумно необхідні зміни робити скриптами, які стартують після підняття та падіння інтерфейсу ppp.

3.3.1. Спочатку конфігуруємо профіль:

/ppp profile
add comment="for PPPoE to ISP3" interface-list=WAN name=isp3_client 
on-down="/ip firewall nat remove  [find comment="NAT via ISP3"];r
    n/ip route remove [find comment="For recursion via ISP3"];r
    n/ip route remove [find comment="Unmarked via ISP3"];r
    n/ip route remove [find comment="Marked via ISP3 Main"];r
    n/ip route remove [find comment="Marked via ISP1 Backup2"];r
    n/ip route remove [find comment="Marked via ISP2 Backup2"];r
    n/ip route rule set [find comment="From ISP3 IP to Inet"] disabled=yes;" 
on-up="/ip route add check-gateway=ping comment="For recursion via ISP3" distance=1 
    dst-address=4.2.2.3/32 gateway=$"remote-address" scope=10r
    n/ip route add comment="Unmarked via ISP3" distance=3 gateway=4.2.2.3;r
    n/ip route add comment="Marked via ISP3 Main" distance=1 gateway=4.2.2.3 
    routing-mark=to_isp3;r
    n/ip route add comment="Marked via ISP1 Backup2" distance=3 gateway=4.2.2.3 
    routing-mark=to_isp1;r
    n/ip route add comment="Marked via ISP2 Backup2" distance=3 gateway=4.2.2.3 
    routing-mark=to_isp2;r
    n/ip firewall mangle set [find comment="Connmark in from ISP3"] 
    in-interface=$"interface";r
    n/ip firewall nat add action=src-nat chain=srcnat ipsec-policy=out,none 
    out-interface=$"interface" to-addresses=$"local-address" comment="NAT via ISP3" 
    place-before=1;r
    nif ([/ip route rule find comment="From ISP3 IP to Inet"] ="") do={r
    n   /ip route rule add comment="From ISP3 IP to Inet" src-address=$"local-address" 
    table=to_isp3 r
    n} else={r
    n   /ip route rule set [find comment="From ISP3 IP to Inet"] disabled=no 
    src-address=$"local-address"r
    n};r
    n"

Сам скрипт у вікні Winbox:

Мультиван та маршрутизація на Mikrotik RouterOS
Зауваження. Рядок
/ip firewall mangle set [find comment = "Connmark in from ISP3"] in-interface = $ "interface";
дозволяє коректно обробляти перейменування інтерфейсу, оскільки працює з його кодом, а не іменем, що відображається.

3.3.2. Тепер, використовуючи профіль, створюємо підключення ppp:

/interface pppoe-client add allow=mschap2 comment="to ISP3" disabled=no 
interface=ether3 name=pppoe-isp3 password=isp3_pass profile=isp3_client user=isp3_client

Як останній штрих налаштуємо годинник:

/system ntp client set enabled=yes server-dns-names=0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org

Для тих, хто дочитав до кінця

Запропонований спосіб реалізації мультиван є особиста перевага автора і не є єдино можливим. Інструментарій ROS є широким і гнучким, що з одного боку викликає складності для початківців, з іншого — причина популярності. Вивчайте, спробуйте, відкривайте для себе нові інструменти та рішення. Наприклад, як застосування отриманих знань, можна в цій реалізації мультиван замінити інструмент Сheck-gateway з рекурсивними маршрутами на Netwatch.

Примітки

  1. Check-gateway - Механізм, який дозволяє деактивувати маршрут після двох поспіль не успішних перевірок шлюзу на доступність. Перевірка здійснюється раз на 10 секунд, плюс тайм відповіді. Отже, фактичний таймінг перемикання лежить у діапазоні 20-30 секунд. Якщо такий таймінг перемикання не достатній, є варіант скористатися інструментом. Netwatch, де таймер перевірки можна задавати вручну. Check-gateway не спрацьовує за періодичних втрат пакетів у каналі.

    Важливо! Деактивація основного маршруту спричиняє деактивацію решти маршрутів, що на нього посилаються. Тому для них вказувати check-gateway=ping немає необхідності.

  2. Буває, що в механізмі роботи DHCP відбувається збій, який виглядає, як клієнт, що підвис у стані renew. У такому разі друга частина скрипту не відпрацює, але коректно ходити трафіку не завадить, оскільки стан відстежує рекурсивний маршрут.
  3. ECMP (Equal Cost Multi-Path) — у ROS є можливість задати маршрут з кількома шлюзами та однаковою distance. У такому випадку з'єднання розподілятимуться каналами, використовуючи алгоритм round robin, пропорційно кількості зазначених шлюзів.

За поштовх до написання статті, допомога при формуванні її структури та розміщенні акцентів — особиста подяка Євгену. @jscar

Джерело: habr.com