Протокол динамічної маршрутизації OSPF - налаштування на Mikrotik RouterOS

Опис з Вікі: OSPF (англ. Open Shortest Path First) — протокол динамічної маршрутизації, що базується на технології відстеження стану каналу (link-state technology) і використовує для знаходження найкоротшого шляху алгоритм Дейкстри.

Для чого потрібний OSPF і як використовувати його на мережах, побудованих на Mikrotik RouterOS, ми і розглянемо в цій статті.

Опис роботи протоколу OSPF

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

Для тих, хто з цим не знайомий, поясню. Уявіть, що ми раптово захотіли потрапити з Челябінська до Києва, не ім'я ні карти, ні навігатора. Поїдемо за вказівниками – не дарма ж їх ставили.

Таким чином, подивившись на 10-20-100 укзателів, ми рано чи пізно дістанемося до Києва - пакет від відправника пішов до адресата. Зробили там всі свої справи і захотіли назад додому в Челябінськ - програма обробила пакет і надіслала відповідь ініціатору з'єднання. Але дорогу ми не пам'ятаємо (у пакеті немає жодних даних про проходження шляху. Насправді, є натяки на це, але за допомогою них не можна відновити шлях пакета). Не біда – поїдемо за вказівниками.

Так само як і вперше ми якимось чином повернемося до точки, з якої виїхали. Причому дуже важливо те, що повернутися ми можемо іншими дорогами - на якихось почали укладати асфальт за час нашого перебування в Києві і поставили знаки об'їзду, десь просто затор і ми вирішили об'їхати менш навантаженими трасами. Але ми все одно дістанемося місця, нехай і витративши більше часу.

Отже, ми інкапсульовані в автомобіль - це дані, інкапсульовані в IP-пакет. Перехрестя на дорозі - маршрутизатори, підключені до різних мереж (доріг). А покажчики на перехрестях - таблиці маршрутизації окремих маршрутизаторів, які знають, куди повернути, щоб потрапити в ту чи іншу точку. І якщо в один бік ми доїдемо за вказівниками, а в інший вказівників не буде, то пиши зникло – до вихідної точки не дістанемося. Отже, маршрути до мереж, що спілкуються, повинні бути прописані на обох сторонах. І дуже важливо розуміти, що доріг-маршрутів може бути кілька. І якщо одне перехрестя-маршрутизатор у ремонті, то попередній може послати нас в об'їзд, але спочатку він має дізнатися, що його сусід зламався. І якщо ми їздимо різними дорогами, значить і час пінгу у нас буде різний.

Отже, із маршрутами розібралися. Тепер поговоримо про шляховики, які ставлять покажчики.

Статичні покажчики на дорогах – добре. Але відстань між Челябінськом та Києвом 2400 км. А значить і покажчиків має бути не менше 24 – по одному на кожні 100 км. І якщо на одному з перехресть триває ремонт, необхідно внести зміни на два суміжні покажчики. А можливість одночасного ремонту на 24 перехрестях дуже висока. Тобто потрібна окрема бригада шляховиків, які змінюють покажчики.

Було б непогано з'єднати всі покажчики в мережу та дозволити їм самим оцінювати ситуацію на своїх ділянках та передавати ці дані між собою. На жаль, великі й жахливі служби обслуговування доріг про це ще не додумалися, та й навряд чи це треба - гроші то пиляти не вийде. А ось айтішники придумали технології, що дозволяють динамічно змінювати таблиці маршрутизації та обмінюватися цією інформацією. Ці технології називаються Протоколи Динамічної Маршрутизації. І один з них – OSPF, призначений для обміну інформацією всередині однієї автономної системи – AS.

Настроювання протоколу OSPF на устаткуванні Mikrotik

Терміни та робота OSPF добре описані у вікі мікротика. Але я насмілюсь дещо повторити і перефразувати.
Допустимо, є наступна мережа:

Як бачимо, до мережі 172.16.1.0 можна потрапити двома шляхами: через R2 та через зв'язку R3+R4. Cost'и, написані біля кожного лінка, задають вартість лінка, своєрідний аналог параметра distance в ip-route. Чим нижче значення cost'а, тим вища ймовірність того, що трафік піде цим шляхом. Але, як видно на наступному малюнку, сумарна вартість обох маршрутів до мережі 172.16.1.0 становить 20. То яким же шляхом піде трафік?

У такому разі в таблиці маршрутизації побачимо приблизно таку картину - до однієї мережі маємо два шлюзи. І трафік має піти через обидва шлюзи. У цьому випадку ми можемо керувати тим, куди піде трафік. Називається ця технологія Policy Based Routing, але тема управління трафіком - це зовсім інша історія.

Зробити, щоб OSPF “заробив” у Mikrotik RouterOS дуже просто – потрібно лише додати в backbone на кожному роутері у Routing – OSPF – Networks усі ваші мережі, між якими ви хочете динамічну маршрутизацію та “воно запрацює”.

Але ж ми хочемо керувати процесом. Той, хто не хоче керувати далі, може не читати. Решті - ласкаво просимо!

Приклад організації протоколу OSPF

Розглядатимемо мережу, типову для організації з кількома філіями. Маємо центральний офіс (Headquarter на схемі, для стислості зватимемо його ЦО) з мережею 192.168.0.0/24 (що я, до речі, не рекомендую при дефолтних налаштуваннях OSPF). Чому – скажу нижче). У ЦО розташовані всі основні елементи інфраструктури – контролер домену, сервер віддаленого доступу, поштовий сервер тощо. Всі філії повинні мати доступ до всіх цих сервісів.

Декілька філій (Branche на схемі, для стислості - СП - Структурний Підрозділ) з адресами 192.168.X.0/24. Між ЦО та кожним СП шифрований тунель SSTP (або будь-який інший VPN) - адреси в тунелях з підмережі 192.168.255.0/24 (192.168.255.10 - ЦО, 192.168.255.1 - СП1, 2.8.2 - СП1,2. Між філіями зв'язок не потрібна, т.к. всі служби в ЦО. Коли філій 3, нам легко додати 3 маршрути на роутер до ЦО та по одному на кожен з роутерів СП. Разом 6 рухів мишкою. А якщо СП у нас не 3, а 33 і необхідні маршрути від кожного кожному, а ще є підрядники з доступом до кількох СП? Тут і на допомогу OSPF.

Кому треба "швидко і все одно як воно працює" можуть піти за схемою, запропонованою вище - додати в backbone всі свої мережі.

Додавання мереж до Backbone

Чому саме backbone? Backbone у перекладі з англійської - хребет, хребет. OSPF оперує поняттями Area (область), Autonomous System (AS, автономна система). AS - всі мережі, які належать вам та між якими може працювати ваш протокол динамічної маршрутизації. Area – частина цієї мережі. На зображенні нижче показана одна AS з трьома Area, одна з яких - backbone (Area 0 з ID 0.0.0.0). Кожна Area має свій ID, схожий на IP-адресу. Backbone має ID 0.0.0.0. Всі області в OSPF повинні мати лінк з backbone. Інакше нічого не працюватиме.

У нашому прикладі ми вирішили довго не думати та гнати все у backbone. За великим рахунком, це нічим не загрожує і працюватиме. Але якщо провайдер віддає одному з ваших філій приватну адресу з 192.168.0.0/16 (наприклад, 192.168.18.27/29), то у вашій таблиці маршрутизації з'явиться мережа провайдера. І якщо хтось з іншого боку провайдера використовує такі ж налаштування (або просто вказав маршрут до ваших мереж), він зможе безперешкодно потрапити у вашу мережу. А вже випадково це зробили чи навмисно – дізнаєтесь коли дані з вашої БД спливуть в інтернеті.

У цьому випадку можна використовувати авторизацію на кожному інтерфейсі Routing – OSPF – Interfaces.

Або вказати, що інтерфейс, що дивиться до провайдера, буде в пасивному режимі.

Налаштування OSPF у ручному режимі

Тепер поговоримо про те, як зробити "правильно" - не вести мовлення свої мережі абияк і дозволити грамотно провести роботу OSPF.
Як ми говорили вище, кожна область має власний ID. Також кожен учасник OSPF має свій ID. За замовчуванням він виставляється автоматично та вибирається з IP адрес, присвоєних інтерфейсам роутера. Але нам треба проставити його в ручну, щоб була якась логіка в назві і ми завжди знали звідки прийшов запит. Ставиться це в Routing – OSPF – Instances – Router ID.

У нашій схемі є кілька областей. Як ми з'ясували, основна область, що з'єднує решту - backbone. Саме в цій галузі літають пакети від одного роутера до іншого, що дають змогу обмінюватися маршрутною інформацією. Значить, цією областю мають бути тунелі, що з'єднують СП та ЦО, що видно на малюнку нижче.

Таким чином, нам необхідно виділити на кожному маршрутизаторі по дві зони – backbone та свою локальну мережу. На прикладі ЦО:
routing ospf area add name=Area0 area-id=192.168.0.0
routing ospf network add area=Area0 network=192.168.0.0/24
routing ospf network add area=backbone network=192.168.255.0/24

І так само на інших маршрутизаторах, тільки замінивши Area-ID, Area name і network на свої.

Тепер на кожному маршрутизаторі можемо побачити маршрути до всіх інших мереж з літерами D та o в описі, що означає, що ці маршрути D - динамічні (прилетіли в результаті роботи протоколів динамічної маршрутизації) і o - з протоколу OSPF.

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