Основи статичної маршрутизації у Mikrotik RouterOS

Маршрутизація — процес пошуку оптимального шляху передачі пакетів у мережах TCP/IP. Будь-який пристрій підключений до мережі IPv4 містить процес та таблиці маршрутизації.

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

Комутація та маршрутизація

Комутація – процес обміну пакетами в межах одного Layer2 сегмента (Ethernet, ppp, …). Якщо пристрій бачить, що одержувач пакета знаходиться з ним в одній Ethernet підмережі, він дізнається адресу mac за протоколом arp і передає пакет безпосередньо, минаючи маршрутизатор. ppp (point-to-point) з'єднання може бути тільки два учасники і пакет завжди відправляється на одну адресу 0xff.

Маршрутизація – процес передачі пакетів між Layer2 сегментами. Якщо пристрій хоче відправити пакет, одержувач якого знаходиться за межами Ethernet сегмента, він дивиться в свою таблицю маршрутизації і передає пакет шлюзу, який знає, куди відправити пакет далі (а може й не знає, початковий відправник пакета про це не обізнаний).

Найпростіше розглядати маршрутизатор, як пристрій підключений до двох або більше сегментів Layer2 і здатний передавати пакети між ними визначаючи оптимальний маршрут по таблиці маршрутизації.

Якщо вам усе зрозуміло чи ви й так це знали, читайте далі. Решту настійно рекомендую ознайомитися з маленькою, але дуже ємною статтею.

Маршрутизація в RouterOS та PacketFlow

Практично весь функціонал, що відноситься до статичної маршрутизації, знаходиться в пакеті система. Пакет Маршрутизація додає підтримку алгоритмів динамічної маршрутизації (RIP, OSPF, BGP, MME), Routing Filters та BFD.

Основне меню для налаштування маршрутизації: [IP]->[Route]. Складні схеми можуть вимагати попереднє маркування пакетів маршрутною міткою в: [IP]->[Firewall]->[Mangle] (ланцюжки PREROUTING и OUTPUT).

На PacketFlow можна виділити три місця, де приймаються рішення щодо маршрутизації IP пакетів:

1. Маршрутизація пакетів, що надійшли на роутер. На даному етапі вирішується піде пакет локального процесу або буде відправлений далі до мережі. Транзитні пакети отримують Вихідний інтерфейс
2. Маршрутизація локальних вихідних пакетів. Вихідні пакети отримують Вихідний інтерфейс
3. Додатковий етап маршрутизації для вихідних пакетів, дозволяє змінити рішення про маршрутизацію [Output|Mangle]

• Шлях пакета в блоках 1, 2 залежить від правил [IP]->[Route]
• Шлях пакету в пунктах 1, 2 та 3 залежить від правил у [IP]->[Route]->[Rules]
• На шлях пакета в блоках 1, 3 можна вплинути використовуючи [IP]->[Firewall]->[Mangle]

RIB, FIB, Routing Cache

Routing Information Base
База в якій збираються маршрути від протоколів динамічної маршрутизації, маршрути від ppp та dhcp, статичні та підключені (connected) маршрути. Ця база містить усі маршрути, за винятком відфільтрованих адміністратором.

Умовно, можна вважати що [IP]->[Route] відображає RIB.

Forwarding Information Base

База в якій збираються кращі маршрути з RIB. Всі маршрути FIB є активними і використовуються для пересилання пакетів. Якщо маршрут стає неактивним (відключений адміністратором (системою), або інтерфейс через який має відправлятися пакет не активний) маршрут видаляється з FIB.

Для ухвалення рішення про маршрутизацію у таблиці FIB використовуються такі дані про IP пакет:

• Адреса джерела
• Адреса призначення
• Source Interface
• Routing mark
• ToS (DSCP)

Потрапляючи у FIB пакет проходить такі стадії:

• Пакет призначений для локального процесу роутера?
• Пакет потрапляє під системні або користувацькі правила PBR?
  • Якщо так, то пакет відправляється у вказану таблицю маршрутизації
• Пакет надсилається до таблиці main

Умовно, можна вважати що [IP]->[Route Active=yes] відображає FIB.

Routing Cache
Механізм кешування маршрутів. Маршрутизатор запам'ятовує куди були відправлені пакети і якщо зустрічаються схожі (імовірно з одного з'єднання) пускає їх тим же маршрутом, без перевірки в FIB. Кеш маршрутів періодично очищується.

Для адміністраторів RouterOS не зробили засобів перегляду та управління Routing Cache, але за його можна відключити в [IP]->[Settings].

Даний механізм був видалений з ядра linux 3.6, але в RouterOS досі використовується kernel 3.3.5, можливо, Routing cahce — одна з причин.

Діалог додавання маршруту

[IP]->[Route]->[+]

1. Підсіть для якої необхідно створити маршрут (за замовчуванням: 0.0.0.0/0)
2. IP шлюзу або інтерфейс на який буде відправлено пакет (може бути кілька, див. нижче ECMP)
3. Перевірка доступності шлюзу
4. Тип запису
5. Дистанція (метрика) для маршруту
6. Таблиця маршрутизації
7. IP для локальних вихідних пакетів через цей маршрут
8. Про призначення Scope та Target Scope написано наприкінці статті

Прапори маршрутів

• X - Маршрут відключений адміністратором (disabled=yes)
• A — Маршрут використовується для передачі пакетів
• D - Маршрут доданий динамічно (BGP, OSPF, RIP, MME, PPP, DHCP, Connected)
• C — Підключення підключено безпосередньо до маршрутизатора
• S — Статичний маршрут
• r,b,o,m — Маршрут додано одним із протоколів динамічної маршрутизації
• B,U,P - Фільтруючий маршрут (відкидає пакети замість передачі)

Що вказувати в gateway: ip-адресу чи інтерфейс?

Система дозволяє вказувати і те, й інше, при цьому не лається і не підказує, якщо ви щось зробили неправильно.

IP адреса
Адреса шлюзу має бути доступна за Layer2. Для Ethernet це означає, що роутер повинен мати на одному з активних інтерфейсів IP адресу з тієї ж підмережі, для ppp - що адреса gateway вказана на одному з активних інтерфейсів як адреса підмережі.
Якщо умова доступності по Layer2 не виконується, маршрут вважається неактивним і не потрапляє до FIB.

Інтерфейс
Все складніше та поведінка маршрутизатора залежить від типу інтерфейсу:

• PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) з'єднання передбачає наявність лише двох учасників і пакет завжди буде направлений шлюзу для передачі, якщо шлюз виявить, що одержувачем є він сам, то передасть пакет своєму локальному процесу.
  
• Ethernet передбачає наявність безлічі учасників і буде відправляти на інтерфейс arp запити з адресою одержувача пакета, це очікувана і цілком нормальна поведінка для підключення маршрутів.
  Але при спробі використовувати інтерфейс як маршрут для віддаленої підмережі ви отримаєте таку ситуацію: маршрут активний, ping до шлюзу проходить, але не доходять до одержувача із зазначеної підмережі. Якщо подивіться на інтерфейс через сніффер, побачите arp запити з адресами з віддаленої підмережі.
  

Намагайтеся вказувати IP адресу як gateway завжди коли це можливо. Виняток – connected маршрути (створюються автоматично) та PPP (Async, PPTP, L2TP, SSTP, PPPoE, OpenVPN*) інтерфейси.

OpenVPN не містить заголовка PPP, але можна використовувати ім'я OpenVPN інтерфейсу для створення маршруту.

More Specific Route

Основне правило маршрутизації. Маршрут описує більш маленьку підмережу (з найбільшою маскою підмережі) має більший пріоритет при ухваленні рішення про маршрутизацію пакета. Положення записів у таблиці маршрутизації немає відношення до вибору — основне правило More Specific.

Усі маршрути із зазначеної схеми активні (перебувають у FIB), т.к. вказують на різні підмережі та не конфліктують між собою.

Якщо один із шлюзів стане недоступним, зв'язаний маршрут буде вважатися неактивним (видалений з FIB) і для пакетів буде здійснюватися пошук з маршрутів, що залишилися.

Маршруту з підмережею 0.0.0.0/0 іноді надають особливого значення і називають "Маршрут за замовчуванням" (Default Route) або "Шлюз останньої надії" (gateway of last resort). Насправді в ньому немає нічого магічного і він просто включає всі можливі адреси IPv4, але дані назви добре описують його завдання - він вказує на шлюз, куди пересилати пакети для яких немає інших, точніших маршрутів.

Максимально можлива маска підмережі для IPv4 – /32, такий маршрут вказує на конкретний хост і може використовуватись у таблиці маршрутизації.

Розуміння More Specific Route є фундаментальним для будь-яких пристроїв, що працюють з TCP/IP.

відстань

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

Якщо є декілька маршрутів до однієї підмережі з однаковою метрикою, маршрутизатор додати до таблиці FIB лише один з них, керуючись своєю внутрішньою логікою.

Метрика може набувати значення від 0 до 255:

• 0 — Метрика для підключених маршрутів. Дистанція 0 не може бути виставлена ​​адміністратором
• 1-254 - Метрики доступні адміністратору для встановлення маршрутів. Метрики з меншим значенням мають більший пріоритет
• 255 — Метрика доступна адміністратору для встановлення маршрутів. На відміну від 1-254, маршрут із метрикою 255 завжди залишається неактивним і не потрапляє у FIB
• Особливі метрики. У маршрутів отриманих від протоколів динамічної маршрутизації є стандартні значення метрик

Check gateway

Check gateway — розширення MikroTik RoutesOS для перевірки доступності шлюзу icmp або arp. Раз на 10 секунд (змінити не можна) на шлюз надсилається запит, якщо двічі не надходить відповідь маршрут вважається недоступним і видаляється з FIB. Якщо check gateway відключив маршрут перевірки, продовжується і маршрут знову стане активним після однієї успішної перевірки.

Check gateway відключає запис, в якому він налаштований та всі інші записи (у всіх таблицях маршрутизації та ecmp маршрутах) із зазначеним шлюзом.

Загалом check gateway працює нормально, якщо не виникає проблем із втратою пакетів до шлюзу. Check gateway не знає, що відбувається зі зв'язком за межами шлюзу, що перевіряється, для цього необхідні додаткові інструменти: скрипти, рекурсивна маршрутизація, протоколи динамічної маршрутизації.

Більшість VPN та тунельних протоколів містять вбудовані засоби для перевірки активності з'єднання, включати для них check gateway – це додаткове (але дуже маленьке) навантаження на мережу та продуктивність пристрою.

ECMP маршрути

Equal-Cost Multi-Path — відправлення пакетів до одержувача, використовуючи одночасно кілька шлюзів з перебором за алгоритмом Round Robin.

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

ECMP використовується для балансування навантаження між двома каналами, теоретично, якщо в ecmp маршруті два канали, то для кожного пакета вихідний канал повинен відрізнятися. Але механізм Routing cache відправляє пакети зі з'єднання маршрутом, яким пішов перший пакет, в результаті отримуємо подібність балансування на базі з'єднань (per-connection loading balancing).

Якщо відключити Routing Cache, то пакети в ECMP маршруті ділитися правильно, але виникає проблема з NAT. Правило NAT обробляє лише перший пакет із з'єднання (інші обробляються автоматично) і виходить ситуація, що з різних інтерфейсів йдуть пакети з однією адресою джерела.

У ECMP маршрутах не працює check gateway (баг RouterOS). Але можна обійти це обмеження, якщо створити додаткові маршрути для перевірки, які відключатимуть записи до ECMP.

Фільтрування засобами Routing

Опція Type визначає, що зробити з пакетом:

• unicast — надіслати на вказаний шлюз (інтерфейс)
• blackhole - відкинути пакет
• prohibit, unreachable — відкинути пакет та надіслати icmp повідомлення відправнику

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

Пара прикладів

Для закріплення базових речей щодо маршрутизації.

Типовий домашній роутер

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1

1. Статичний маршрут до 0.0.0.0/0 (default route)
2. Connected маршрут на інтерфейсі з провайдером
3. Connected маршрут на інтерфейсі з локальною мережею

Типовий домашній роутер із PPPoE

1. Статичний маршрут до default route, автоматично доданий т.к. це зазначено у властивостях підключення
2. Connected маршрут для PPP з'єднання
3. Connected маршрут на інтерфейсі з локальною мережею

Типовий домашній роутер із двома провайдерами та резервуванням

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 distance=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

1. Статичний маршрут до default route через першого провайдера з метрикою 1 та перевіркою доступності шлюзу
2. Статичний маршрут до default route через другого провайдера з метрикою 2
3. Connected маршрути

Трафік до 0.0.0.0/0 йде через 10.10.10.1, поки цей шлюз доступний, інакше перемикається на 10.20.20.1

Таку схему вважатимуться резервуванням каналу, але не позбавлена ​​недоліків. Якщо відбувається обрив за межами шлюзу провайдера (наприклад, усередині операторської мережі), ваш роутер про це не дізнається і продовжить вважати маршрут активним.

Типовий домашній роутер з двома провайдерами, резервуванням та ECMP

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.10.10.1,10.20.20.1 distance=1

1. Статичні маршрути для перевірки chack gateway
2. Маршрут ECMP
3. Connected маршрути

Маршрути для перевірки синього кольору (колір неактивних маршрутів), але це не заважає роботі check gateway. У поточній версії (6.44) RoS автоматичний пріоритет віддається ECMP маршруту, але краще додати перевірочні маршрути до інших таблиць маршрутизації (опція routing-mark)

На Speedtest та інших подібних сайтах приросту швидкості не буде (ECMP ділить трафік по з'єднаннях, а не по пакетах), але програми p2p повинні завантажувати швидше.

Фільтрування через Routing

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1
add dst-address=192.168.200.0/24 gateway=10.30.30.1 distance=1
add dst-address=192.168.200.0/24 gateway=10.10.10.1 distance=2 type=blackhole

1. Статичний маршрут до default route
2. Статичний маршрут до 192.168.200.0/24 через ipip тунель
3. Статичний маршрут, що забороняє, до 192.168.200.0/24 через маршрутизатор провайдера.

Варіант фільтрації, при якій тунельний трафік не піде на маршрутизатор провайдера при відключенні ipip інтерфейсу. Такі схеми потрібні рідко, т.к. можна реалізувати блокування через firewall.

Routing Loop
Петля маршрутизації — ситуація, коли пакет бігає між маршрутизаторами до закінчення ttl. Зазвичай є наслідком помилки зміни, у великих мережах лікується використанням протоколів динамічної маршрутизації, у невеликих — уважністю.

Виглядає це приблизно так:

Приклад (найпростіший) як отримати подібний результат:

Приклад з Routing loop немає практичного застосування, але показує що маршрутизатори уявлення немає про таблиці маршрутизації своїх сусідів.

Policy Base Routing та додаткові таблиці маршрутизації

При виборі маршруту, роутер використовує лише одне поле із заголовка пакета (Dst. Address) – це базова маршрутизація. Маршрутизація на базі інших умов, наприклад адреси джерела, типу трафіку (ToS), балансування без ECMP, відноситься до Policy Base Routing (PBR) та використовує додаткові таблиці маршрутизації.

More Specific Route є основним правилом вибору маршруту, у межах таблиці маршрутизації.

За промовчанням всі правила маршрутизації додаються до таблиці main. Адміністратор може створити довільну кількість додаткових таблиць маршрутизації та направляти пакети до них. Правила у різних таблицях не конфліктують між собою. Якщо пакет не знайшов відповідного правила у зазначеній таблиці, він піде в таблицю main.

Приклад із розподілом через Firewall:

• 192.168.100.10 -> 8.8.8.8
  1. Трафік від 192.168.100.10 отримує мітку через-isp1 в [Prerouting|Mangle]
  2. На етапі Routing у таблиці через-isp1 провадиться пошук маршруту до 8.8.8.8
  3. Маршрут знайдено, трафік відправляється на шлюз 10.10.10.1
• 192.168.200.20 -> 8.8.8.8
  1. Трафік від 192.168.200.20 отримує мітку через-isp2 в [Prerouting|Mangle]
  2. На етапі Routing у таблиці через-isp2 провадиться пошук маршруту до 8.8.8.8
  3. Маршрут знайдено, трафік відправляється на шлюз 10.20.20.1
• Якщо один із шлюзів (10.10.10.1 або 10.20.20.1) стане недоступним, то пакет піде в таблицю основний і буде шукати підходящий маршрут там

Проблеми термінології

У RouterOS є певні проблеми із термінологією.
При роботі з правилами [IP]->[Routes] вказується таблиця маршрутизації, хоча й написано, що мітка:

В [IP]->[Routes]->[Rule] все правильно, за умови мітки у дії таблиці:

Як відправити пакет до певної таблиці маршрутизації

RouterOS пропонує кілька інструментів:

• Правила у [IP]->[Routes]->[Rules]
• Маршрутні мітки (action=mark-routing) В [IP]->[Firewall]->[Mangle]
• Розширення VRF

Правила [IP]->[Route]->[Rules]
Правила обробляються послідовно, якщо пакет збігся з умовами правила, він не проходить далі.

Routing Rules дозволяють розширити можливості маршрутизації, спираючись не тільки на адресу одержувача, але й адресу джерела та інтерфейс, на який було отримано пакет.

Правила складаються з умов та дії:

• умови. Практично повторюють список ознак, за якими пакет перевіряється у FIB, відсутній тільки ToS.
• Дії
  • lookup — надіслати пакет до таблиці
  • lookup only in table — замкнути пакет у таблиці, якщо маршрут не буде знайдений пакет не піде в таблицю main
  • drop - відкинути пакет
  • unreacheable — відкинути пакет із повідомленням відправника

У FIB трафік до локальних процесів обробляється в обхід правил [IP]->[Route]->[Rules]:

маркування [IP]->[Firewall]->[Mangle]
Маршрутні мітки дозволяють встановлювати шлюз для пакета, використовуючи практично будь-які умови Firewall:

Практично, тому що не всі мають сенс, а деякі можуть працювати нестабільно.

Маркувати пакет можна двома способами:

• Відразу ставити routing-mark
• Спочатку ставити connection-mark, потім на основі connection-mark ставити routing-mark

У статті про firewall я писав, що другий варіант краще т.к. знижує навантаження на CPU, у випадку з маркуванням маршрутів - це не зовсім так. Зазначені способи маркування не завжди є рівноцінними та зазвичай використовуються для вирішення різних завдань.

приклади використання

Переходимо до прикладів використання Policy Base Routing, на них набагато простіше показати, навіщо все це потрібно.

MultiWAN і вихідний (Output) трафік у відповідь
Найпоширеніша проблема, при MultiWAN конфігурації: Mikrotik доступний з мережі інтернет тільки за «активним» провайдером.

Роутеру не важливо, на який ip прийшов запит, при генерації відповіді він шукатиме маршрут у таблиці маршрутизації, де активний маршрут через isp1. Далі такий пакет швидше за все буде відфільтрований на шляху до одержувача.

Ще один цікавий момент. Якщо на інтерфейсі ether1 налаштований "простий" source nat: /ip fi nat add out-interface=ether1 action=masquerade пакет піде в мережу із src. address=10.10.10.100, що ще більше посилить ситуацію.

Виправити проблему можна декількома способами, але для будь-якого з них будуть потрібні додаткові таблиці маршрутизації:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 check-gateway=ping distance=1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 check-gateway=ping distance=2
add dst-address=0.0.0.0/0 gateway=10.10.10.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 routing-mark=over-isp2

Використання [IP]->[Route]->[Rules]
Вказуємо таблицю маршрутизації яка буде використана для пакетів із зазначеними Source IP.

/ip route rule
add src-address=10.10.10.100/32 action=lookup-only-in-table table=over-isp1
add src-address=10.20.20.200/32 action=lookup-only-in-table table=over-isp2

Можна використовувати action=lookup, але локального вихідного трафіку зазначений варіант повністю виключає з'єднання з неправильного інтерфейсу.

• Система генерує пакет у відповідь з Src. Address: 10.20.20.200
• На етапі Routing Decision(2) відбувається перевірка [IP]->[Routes]->[Rules] та пакет відправляється до таблиці маршрутизації over-isp2
• Відповідно до таблиці маршрутизації пакет має бути відправлений на шлюз 10.20.20.1 через інтерфейс ether2

Цей спосіб не вимагає робочого Connection Tracker, на відміну від таблиці Mangle.

Використання [IP]->[Firewall]->[Mangle]
З'єднання починається з вхідного пакета, тому маркуємо його (action=mark-connection), для вихідних пакетів від маркованого з'єднання встановлюємо маршрутну мітку (action=mark-routing).

/ip firewall mangle
#Маркировка входящих соединений
add chain=input in-interface=ether1 connection-state=new action=mark-connection new-connection-mark=from-isp1
add chain=input in-interface=ether2 connection-state=new action=mark-connection new-connection-mark=from-isp2
#Маркировка исходящих пакетов на основе соединений
add chain=output connection-mark=from-isp1 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=output connection-mark=from-isp2 action=mark-routing new-routing-mark=over-isp2 passthrough=no

Якщо на одному інтерфейсі налаштовано декілька ip, можна додати до умови dst-address для уточнення.

• На інтерфейс ether2 надходить пакет, що відкриває з'єднання. Пакет потрапляє в [INPUT|Mangle] де йдеться маркувати всі пакети зі з'єднання як from-isp2
• Система генерує пакет у відповідь з Src. Address: 10.20.20.200
• На етапі Routing Decision(2) пакет відповідно до таблиці маршрутизації відправляється на шлюз 10.20.20.1 через інтерфейс ether1. Можете переконатися в цьому залогіровавши пакети в [OUTPUT|Filter]
• На етапі [OUTPUT|Mangle] відбувається перевірка на наявність мітки з'єднання from-isp2 і пакет отримує маршрутну мітку over-isp2
• На етапі Routing Adjusment(3) відбувається перевірка на наявність маршрутної мітки та відправлення у відповідну таблицю маршрутизації
• Відповідно до таблиці маршрутизації пакет має бути відправлений на шлюз 10.20.20.1 через інтерфейс ether2

MultiWAN і dst-nat трафік у відповідь

Приклад складніше, що робити, якщо за роутером знаходиться сервер (наприклад web) у приватній підмережі і необхідно забезпечити доступ до нього по будь-якому провайдеру.

/ip firewall nat
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether1 action=dst-nat to-address=192.168.100.100
add chain=dstnat proto=tcp dst-port=80,443 in-interface=ether2 action=dst-nat to-address=192.168.100.100

Суть проблеми буде та ж, рішення схоже на варіант із Firewall Mangle, тільки будуть використовуватися інші ланцюжки.

/ip firewall mangle
add chain=prerouting connection-state=new in-interface=ether1 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp1
add chain=prerouting connection-state=new in-interface=ether2 protocol=tcp dst-port=80,443 action=mark-connection new-connection-mark=web-input-isp2
add chain=prerouting connection-mark=web-input-isp1 in-interface=ether3 action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting connection-mark=web-input-isp2 in-interface=ether3 action=mark-routing new-routing-mark=over-isp2 passthrough=no

На схемі не відображено NAT, але думаю і так все зрозуміло.

MultiWAN та вихідні з'єднання

Можна використовувати PBR для створення кількох vpn (у прикладі SSTP) з'єднань з різних інтерфейсів роутера.

Додаткові таблиці маршрутизації:

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.100.1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 routing-mark=over-isp3

add dst-address=0.0.0.0/0 gateway=192.168.100.1 distance=1
add dst-address=0.0.0.0/0 gateway=192.168.200.1 distance=2
add dst-address=0.0.0.0/0 gateway=192.168.0.1 distance=3

Маркування пакетів:

/ip firewall mangle
add chain=output dst-address=10.10.10.100 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp1 passtrough=no
add chain=output dst-address=10.10.10.101 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp2 passtrough=no
add chain=output dst-address=10.10.10.102 proto=tcp dst-port=443 action=mark-routing new-routing-mark=over-isp3 passtrough=no

Прості правила NAT, інакше пакет піде з інтерфейсу з неправильним Src. Address:

/ip firewall nat
add chain=srcnat out-interface=ether1 action=masquerade
add chain=srcnat out-interface=ether2 action=masquerade
add chain=srcnat out-interface=ether3 action=masquerade

Розбір:

• Роутер створює три процеси SSTP
• На етапі Routing Decision (2) для даних процесів вибирається маршрут, з таблиці маршрутизації main. Від цього маршруту пакет отримує Src. Address прив'язаний до інтерфейсу ether1
• В [Output|Mangle] пакети від різних з'єднань отримують різні мітки
• Пакети потрапляють у відповідні мітки таблиці на етапі Routing Adjusment і отримує новий маршрут для відправлення пакетів
• Але пакети все ще залишаються Src. Address від ether1, на етапі [Nat|Srcnat] адреса підміняється відповідно до інтерфейсу

Цікаво, що на роутері ви побачите таку таблицю з'єднань:

Connection Tracker відпрацьовує раніше [Mangle] и [Srcnat], тому всі з'єднання йдуть від однієї адреси, якщо подивитись детальніше Replay Dst. Address будуть адреси після NAT:

На VPN сервері (на тестовому стенді він у мене один) можна побачити, що всі з'єднання походять з правильних адрес:

Стривай спосіб
Є спосіб простіше, можна просто вказати певний шлюз для кожної адреси:

/ip route
add dst-address=10.10.10.100 gateway=192.168.100.1
add dst-address=10.10.10.101 gateway=192.168.200.1
add dst-address=10.10.10.102 gateway=192.168.0.1

Але такі маршрути впливатимуть не лише на вихідний, а й на транзитний трафік. Плюс, якщо вам не потрібно щоб трафік на vpn сервері йшов через невідповідні канали зв'язку, то доведеться додати ще 6 правил [IP]->[Routes]с type=blackhole. У попередньому варіанті - 3 правила в [IP]->[Route]->[Rules].

Розподіл з'єднань користувачів каналами зв'язку

Прості, повсякденні завдання. Знову ж таки знадобляться додаткові таблиці маршрутизації:

/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2

Використовуючи [IP]->[Route]->[Rules]

/ip route rules
add src-address=192.168.100.0/25 action=lookup-only-in-table table=over-isp1
add src-address=192.168.100.128/25 action=lookup-only-in-table table=over-isp2

якщо використовувати action=lookup, то при відключенні одного з каналів трафік піде в таблицю main і піде робочим каналом. Чи потрібно це чи ні — залежить від завдання.

Використовуючи маркування в [IP]->[Firewall]->[Mangle]
Простий приклад зі списками IP адрес. У принципі, можна використовувати практично будь-які умови. Єдина застереження layer7, навіть у парі з мітками з'єднань, може здатися, що все працює правильно, але частина трафіку все одно піде не туди.

/ip firewall mangle
add chain=prerouting src-address-list=users-over-isp1 dst-address-type=!local action=mark-routing new-routing-mark=over-isp1
add chain=prerouting src-address-list=users-over-isp2 dst-address-type=!local action=mark-routing new-routing-mark=over-isp2

"Заперети" користувачів в одній таблиці маршрутизації можна через [IP]->[Route]->[Rules]:

/ip route rules
add routing-mark=over-isp1 action=lookup-only-in-table table=over-isp1
add routing-mark=over-isp2 action=lookup-only-in-table table=over-isp2

Або через [IP]->[Firewall]->[Filter]:

/ip firewall filter
add chain=forward routing-mark=over-isp1 out-interface=!ether1 action=reject
add chain=forward routing-mark=over-isp2 out-interface=!ether2 action=reject

Відступ про dst-address-type=!local
Додаткова умова dst-address-type=!local необхідно, щоб трафік від користувачів доходив до локальних процесів роутера (dns, winbox, ssh, …). Якщо до роутера підключено кілька локальних підмереж, необхідно передбачити, щоб трафік між ними не йшов в інтернет, наприклад, використовуючи dst-address-table.

У прикладі з використанням [IP]->[Route]->[Rules] подібних винятків немає, але трафік до локальних процесів доходить. Справа в тому, що потрапляючи у FIB пакет промаркований у [PREROUTING|Mangle] має маршрутну мітку і йде у таблицю маршрутизації відмінну від main, де немає локального інтерфейсу. У випадку з Routing Rules, спочатку перевіряється, чи призначений пакет локальному процесу і тільки на етапі User PBR він йде в задану таблицю маршрутизації.

Використовуючи [IP]->[Firewall]->[Mangle action=route]
Дана дія працює тільки в [Prerouting|Mangle] і дозволяє спрямовувати трафік на вказаний шлюз без використання додаткових таблиць маршрутизації, вказуючи адресу шлюзу безпосередньо:

/ip firewall mangle
add chain=prerouting src-address=192.168.100.0/25 action=route gateway=10.10.10.1
add chain=prerouting src-address=192.168.128.0/25 action=route gateway=10.20.20.1

Дія route має нижчий пріоритет ніж правила маршрутизації ([IP]->[Route]->[Rules]). У випадку з маршрутними мітками все залежить від положення правил, якщо правило з action=route коштує вище ніж action=mark-route, то буде використано воно (незалежно від прапора passtrough), інакше маркування маршруту.
На Wiki дуже мало інформації про дану дію і всі висновки отримані експериментальним шляхом, в будь-якому випадку я не знайшов варіанти коли застосування даного варіанту дає переваги перед іншими.

Динамічний баланс на основі PPC

Per Connection Classificator є більш гнучким аналогом ECMP. На відміну від ECMP ділить трафік по з'єднанням суворо (ECMP нічого про з'єднання не знає, але в парі з Routing Cache виходить щось схоже).

PCC бере вказані поля з ip заголовка, перетворює їх на 32-бітне значення і ділить на знаменник. Залишок від поділу порівнюється із зазначеним залишком і якщо вони збігаються, то застосовується вказана дія. Детальніше. Звучить дико, але працює.

Приклад із трьома адресами:

192.168.100.10: 192+168+100+10 = 470 % 3 = 2
192.168.100.11: 192+168+100+11 = 471 % 3 = 0
192.168.100.12: 192+168+100+12 = 472 % 3 = 1

Приклад динамічного розподілу трафіку по src.address між трьома каналами:

#Таблица маршрутизации
/ip route
add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=2 check-gateway=ping
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=3 check-gateway=ping

add dst-address=0.0.0.0/0 gateway=10.10.10.1 dist=1 routing-mark=over-isp1
add dst-address=0.0.0.0/0 gateway=10.20.20.1 dist=1 routing-mark=over-isp2
add dst-address=0.0.0.0/0 gateway=10.30.30.1 dist=1 routing-mark=over-isp3

#Маркировка соединений и маршрутов
/ip firewall mangle
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/0 action=mark-connection new-connection-mark=conn-over-isp1
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/1 action=mark-connection new-connection-mark=conn-over-isp2
add chain=prerouting in-interface=br-lan dst-address-type=!local connection-state=new per-connection-classifier=src-address:3/2 action=mark-connection new-connection-mark=conn-over-isp3

add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp1 action=mark-routing new-routing-mark=over-isp1
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp2 action=mark-routing new-routing-mark=over-isp2
add chain=prerouting in-interface=br-lan connection-mark=conn-over-isp3 action=mark-routing new-routing-mark=over-isp3

При маркуванні маршрутів є додаткова умова: in-interface=br-lan, без нього під action=mark-routing потрапить трафік у відповідь з інтернету і відповідно до таблиць маршрутизації піде назад до провайдера.

Перемикання каналів зв'язку

Check ping - хороший інструмент, але він перевіряє зв'язок тільки з найближчим IP бенкетом, мережі провайдерів зазвичай складаються з великої кількості маршрутизаторів і обрив зв'язку може статися за межами найближчого бенкету, а далі йдуть магістральні оператори зв'язку у яких теж можуть траплятися проблеми, загалом check ping не завжди показує актуальну інформацію про доступ до глобальної мережі.
Якщо у провайдерів та великих корпорацій є протокол динамічної маршрутизації BGP, то домашнім та офісним користувачем доводиться самостійно вигадувати, як перевіряти доступ в інтернет через певний канал зв'язку.

Зазвичай використовуються скрипти, які через певний канал зв'язку перевіряють доступність ip адреси в мережі інтернет, при цьому вибирається щось надійне, наприклад google dns: 8.8.8.8. 8.8.4.4. Але у спільноті Mikrotik для цього пристосували цікавіший інструмент.

Пари слів про рекурсивну маршрутизацію
Рекурсивна маршрутизація необхідна при побудові Multihop BGP пірінгу і в статтю про основи статичної маршрутизації потрапила тільки за рахунок вухлих користувачів MikroTik, які придумали використання рекурсивних маршрутів у парі з check gateway для перемикання каналів зв'язку без додаткових скриптів.

Настав час загалом розібратися з опціями scope/target scope і яким чином маршрут прив'язується до інтерфейсу:

1. Маршрут шукає інтерфейс для відправки пакету виходячи зі свого значення scope та всіх записів у таблиці main з меншими або рівними значеннями target scope
2. Зі знайдених інтерфейсів вибирається той, через який можна відправити пакет вказаному шлюзу
3. Інтерфейс знайденого connected запису вибирається для відправки пакета на шлюз

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

• 1-3 До connected маршрутів додається ще один, через який можна досягти вказаного шлюзу
• 4-6 Пошук маршруту connected маршруту для «проміжного» шлюзу

Усі маніпуляції з рекурсивним пошуком відбуваються у RIB, а у FIB передається лише підсумковий результат: 0.0.0.0/0 via 10.10.10.1 on ether1.

Приклад використання рекурсивної маршрутизації для перемикання маршрутів

Конфігурація:

/ip route
add dst-address=0.0.0.0/0 gateway=8.8.8.8 check-gateway=ping distance=1 target-scope=10
add dst-address=8.8.8.8 gateway=10.10.10.1 scope=10
add dst-address=0.0.0.0/0 gateway=10.20.20.1 distance=2

Можна перевірити, що пакети надсилатимуться на 10.10.10.1:

Check gateway нічого не знає про рекурсивну маршрутизацію і просто відправляє ping'і на адресу 8.8.8.8, яка (виходячи з таблиці main) доступна через шлюз 10.10.10.1.

Якщо відбувається втрата зв'язку між 10.10.10.1 і 8.8.8.8, відбувається відключення маршруту, але пакети (включаючи перевірочні ping) до 8.8.8.8 продовжують йти через 10.10.10.1:

Якщо відбувається втрата лінка на ether1, виходить неприємна ситуація, коли пакети до 8.8.8.8 підуть через другого провайдера:

Це проблема, якщо ви використовуєте NetWatch для запуску скриптів у разі недоступності 8.8.8.8. При обриві лінка NetWatch просто відпрацює по резервному каналу зв'язку і вважатиме, що все нормально. Вирішується додаванням додаткового фільтруючого маршруту:

/ip route
add dst-address=8.8.8.8 gateway=10.20.20.1 distance=100 type=blackhole

На хабрі є статтяде ситуація з NetWatch розглянута більш детально.

І так, при використанні подібного резервування адреса 8.8.8.8 буде жорстко прив'язана до одного з провайдерів, відповідно вибирати його як джерело dns не найкраща ідея.

Пари слів про Virtual Routing and Forwarding (VRF)

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

Але VRF в Mikrotik організований на базі таблиць маршрутизації і має ряд недоліків, наприклад, локальні ip адреси роутера доступні з усіх VRF, докладніше можна почитати за посиланням.

Приклад конфігурації vrf:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0

З пристрою підключеного до Ether2 бачимо, що проходить ping до адреси роутера з іншого vrf (і це проблема), при цьому ping в інтернет не йде:

Для доступу в інтернет необхідно прописати додатковий маршрут, що звертається до таблиці main (у термінології vrf це називається route leaking):

/ip route
add distance=1 gateway=172.17.0.1@main routing-mark=vrf1
add distance=1 gateway=172.17.0.1%wlan1 routing-mark=vrf2

Тут показано два способи route leaking: використовуючи таблицю маршрутизації: 172.17.0.1@main та використовуючи ім'я інтерфейсу: 172.17.0.1%wlan1.

І налаштувати маркування для трафіку у відповідь в [PREROUTING|Mangle]:

/ip firewall mangle
add chain=prerouting in-interface=ether1 action=mark-connection new-connection-mark=from-vrf1 passthrough=no
add chain=prerouting connection-mark=from-vrf1 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf1 passthrough=no 
add chain=prerouting in-interface=ether2 action=mark-connection new-connection-mark=from-vrf2 passthrough=no
add chain=prerouting connection-mark=from-vrf2 routing-mark=!vrf1 action=mark-routing new-routing-mark=vrf2 passthrough=no 

Підмережі з однаковою адресацією
Організація доступу до підмереж з однаковою адресацією на одному роутері використовуючи VRF та netmap:

Базова конфігурація:

/ip route vrf
add interfaces=ether1 routing-mark=vrf1
add interfaces=ether2 routing-mark=vrf2

/ip address
add address=192.168.100.1/24 interface=ether1 network=192.168.100.0
add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
add address=192.168.0.1/24 interface=ether3 network=192.168.0.0

Правила firewall:

#Маркируем пакеты для отправки в правильную таблицу маршрутизации
/ip firewall mangle
add chain=prerouting dst-address=192.168.101.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf1 passthrough=no
add chain=prerouting dst-address=192.168.102.0/24 in-interface=ether3 action=mark-routing new-routing-mark=vrf2 passthrough=no

#Средствами netmap заменяем адреса "эфимерных" подсетей на реальные подсети
/ip firewall nat
add chain=dstnat dst-address=192.168.101.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24
add chain=dstnat dst-address=192.168.102.0/24 in-interface=ether3 action=netmap to-addresses=192.168.100.0/24

Правила маршрутизації для зворотного трафіку:

#Указание имени интерфейса тоже может считаться route leaking, но по сути тут создается аналог connected маршрута
/ip route
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf1
add distance=1 dst-address=192.168.0.0/24 gateway=ether3 routing-mark=vrf2

Додавання маршрутів отриманих по dhcp у задану таблицю маршрутизації
VRF може бути цікавим, якщо необхідно автоматично додати динамічний маршрут (наприклад, від dhcp client) в певну таблицю маршрутизації.

Додавання інтерфейсу до vrf:

/ip route vrf
add interface=ether1 routing-mark=over-isp1

Правила для відправки трафіку (вихідного та транзитного) через таблицю over-isp1:

/ip firewall mangle
add chain=output out-interface=!br-lan action=mark-routing new-routing-mark=over-isp1 passthrough=no
add chain=prerouting in-interface=br-lan dst-address-type=!local action=mark-routing new-routing-mark=over-isp1 passthrough=no

Додатковий, фейковий маршрут для роботи вихідної маршрутизації:

/interface bridge
add name=bare

/ip route
add dst-address=0.0.0.0/0 gateway=bare

Цей маршрут необхідний тільки для того, щоб локальні вихідні пакети могли пройти через Routing decision (2) до [OUTPUT|Mangle] і отримати маршрутну мітку, якщо на маршрутизаторі є інші активні маршрути до 0.0.0.0/0 у таблиці main, воно не потрібно.

Ланцюжки connected-in и dynamic-in в [Routing] -> [Filters]

Фільтрування маршрутів (вхідний та вихідних) — це інструмент, який зазвичай використовується разом з протоколами динамічної маршрутизації (тому доступний тільки після встановлення пакету). Маршрутизація), але у вхідних фільтрах є два цікаві ланцюжки:

• connected-in - фільтрація connected маршрутів
• dynamic-in - фільтрація динамічних маршрутів отриманих PPP та DCHP

Фільтрування дозволяє не тільки відкидати маршрути, а й змінювати ряд опцій: distance, routing-mark, comment, scope, target scope, …

Це дуже точковий інструмент і якщо можете зробити щось без Routing Filters (але не скриптами), то не використовуйте Routing Filters, не плутайте себе і тих, хто конфігуруватиме роутер після вас. У контексті динамічної маршрутизації Routing Filters будуть використовуватися значно частіше та продуктивніше.

Установка Routing Mark для динамічних маршрутів
Приклад із домашнього маршрутизатора. У мене налаштовані два VPN з'єднання і трафік в них повинен загортатися відповідно до таблиць маршрутизації. При цьому я хочу щоб маршрути створювалися автоматично при активації інтерфейсу:

#При создании vpn подключений указываем создание default route и задаем дистанцию
/interface pptp-client
add connect-to=X.X.X.X add-default-route=yes default-route-distance=101 ...
add connect-to=Y.Y.Y.Y  add-default-route=yes default-route-distance=100 ...

#Фильтрами отправляем маршруты в определенные таблицы маршрутизации на основе подсети назначения и дистанции
/routing filter
add chain=dynamic-in distance=100 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn1
add chain=dynamic-in distance=101 prefix=0.0.0.0/0 action=passthrough set-routing-mark=over-vpn2

Не знаю чому, напевно баг, але якщо створити vrf для ppp інтерфейсу, то маршрут до 0.0.0.0/0 все одно потрапить до таблиці main. Інакше все було б ще простіше.

Вимкнення Connected маршрутів
Іноді потрібно таке:

/route filter
add chain=connected-in prefix=192.168.100.0/24 action=reject

Інструменти налагодження

RouterOS надає ряд засобів для налагодження маршрутизації:

• [Tool]->[Tourch] — дозволяє переглянути пакети на інтерфейсах
• /ip route check — дозволяє подивитися на який шлюз буде надіслано пакет, не працює з таблицями маршрутизації
• /ping routing-table=<name> и /tool traceroute routing-table=<name> — ping та трасування використовуючи вказану таблицю маршрутизації
• action=log в [IP]->[Firewall] — відмінний інструмент, який дозволяє простежити шлях пакету по packet flow, ця дія доступна у всіх ланцюжках та таблицях

Джерело: habr.com