MikroTik BGP налаштування двох провайдерів: практичний посібник для малого офісу

Коли бізнес починає реально залежати від стабільного інтернету, звичайні тимчасові рішення на кшталт перемикання каналів через Netwatch або самописні скрипти перестають рятувати. Вони часто дають збої, смикають з’єднання у невідповідний момент і змушують нервувати. Якщо у вас вже є власна автономна система (AS) та свій незалежний блок IP-адрес (так звані PI-адреси), єдиний надійний спосіб вирішити проблему — це налаштувати протокол динамічної маршрутизації BGP (Border Gateway Protocol) безпосередньо на вашому роутері MikroTik. Це дозволить повністю автоматизувати роботу з провайдерами та отримати справді безшовне перемикання трафіку, яке користувачі в офісі навіть не помітять.

Коротко

Якщо пояснити максимально просто: ми налаштовуємо MikroTik так, щоб він підняв прямі сусідські сесії (піринг) з обладнанням обох ваших інтернет-провайдерів. Роутер сам розповідає їм про вашу мережу, а від них отримує інформацію, куди відправляти пакети (зазвичай нам достатньо дефолтного маршруту — Default Route). Якщо один кабель переріжуть або у провайдера виникне аварія на магістралі, ваш MikroTik автоматично перекине весь потік даних на іншого оператора. При цьому ваші зовнішні IP-адреси не змінюються, сервери залишаються доступними, а користувачам не доводиться чекати, поки оновляться DNS-записи чи перепідключаться робочі програми.

Кому актуально

У моїй практиці найчастіше з цим стикаються компанії, де інтернет потрібен постійно, а будь-яка зміна зовнішньої IP-адреси перетворюється на локальну проблему для робочих процесів. Ось кілька класичних сценаріїв, коли перехід на власну AS та запуск BGP стають реальною необхідністю:

• Офіси, філії чи склади, де одночасно працюють від 15 до 30 людей. Усі вони постійно користуються хмарними CRM, ERP-системами або базами даних. Якщо IP-адреса раптово змінюється, користувачів просто викидає з робочих сесій, дані не зберігаються, і роботу доводиться починати спочатку.
• Компанії, які тримають власні локальні сервери для бухгалтерії, віддаленого доступу чи внутрішніх баз. Якщо вам потрібна постійна та стабільна доступність цих ресурсів ззовні, раджу також глянути мою послугу налаштування Windows Server, RDS та M.E.Doc.
• Організації, які вже пройшли шлях реєстрації в RIPE, отримали через LIR власну автономну систему та блок незалежних IP-адрес (Provider Independent), щоб назавжди забути про прив’язку до конкретного кабелю одного провайдера.
• Мережі, де розгорнуто MikroTik VPN для малого офісу між різними точками, офісами чи складами. Коли падає основний канал, тунелі мають миттєво підніматися через резервний без ручного переписування конфігурацій та адрес на кожній точці.

Типові симптоми

Коли я приходжу на аудит мережі в малі компанії, то майже завжди бачу схожі проблеми, які свідчать про те, що поточна схема резервування без BGP просто не справляється зі своїми задачами:

• Під час перемикання на резервного провайдера за допомогою скриптів виникає неприємна пауза. Поки скрипт відпрацює та перевірить пінг, минає час. За цей період термінальні сесії замерзають, а бази даних видають помилки з’єднання.
• Співробітники на віддаленій роботі втрачають доступ до офісного VPN. Роутер перемкнувся на іншого провайдера, отримав нову IP-адресу, але люди про це не знають і продовжують стукати на стару адресу, яка вже не відповідає.
• З’являється так звана асиметрична маршрутизація. Це коли ваші пакети вилітають в інтернет через одного провайдера, а відповіді намагаються повернутися через іншого. Фаєрвол MikroTik бачить такі пакети, не розуміє, звідки вони взялися, і просто блокує їх як невалідні з’єднання (invalid connections), через що інтернет взагалі перестає нормально працювати.
• Ви справно платите за другий інтернет-канал повну вартість, але він просто простоює як дорогий резерв. Ви не можете гнучко розподілити навантаження між лініями, бо без динамічної маршрутизації це перетворюється на постійний клопіт із ручними правилами.

Що перевірити

Перед тим як вносити зміни в конфігурацію MikroTik, треба ретельно підготувати технічний грунт. Без цього ви ризикуєте застрягти на півдорозі. Ось мій чек-лист, що треба перевірити заздалегідь:

1. Наявність власної AS та мережі. Переконайтеся, що у вас на руках є всі офіційні дані від RIPE або вашого LIR. Вам потрібен номер автономної системи (наприклад, AS65530) та виділена IP-мережа. Пам’ятайте, що мінімальний розмір мережі для IPv4, який провайдери погодяться анонсувати в глобальну таблицю — це /24. Дрібніші шматки просто зафільтрують на першому ж магістральному вузлі.
2. Параметри стику від провайдерів. Обидва оператори мають чітко підтвердити, що вони готові підняти з вами eBGP-сесію. Запитуйте у них номери їхніх AS, IP-адреси для point-to-point з’єднання (так звану сітку стику) та обов’язково уточніть, які саме маршрути вони вам віддаватимуть.
3. Ресурси вашого MikroTik. Це дуже важливий момент. Якщо ви вирішите прийняти Full View (повну таблицю маршрутів інтернету, де зараз уже понад 900 000 записів), звичайний офісний роутер просто зависне від нестачі оперативної пам’яті та процесорної потужності. Для Full View потрібне серйозне залізо, наприклад, лінійка CCR з гігабайтами RAM. Для малого офісу я наполегливо рекомендую просити у провайдерів тільки Default Route (0.0.0.0/0). Це дозволить спокійно працювати навіть на бюджетних моделях MikroTik без перевантаження заліза.
4. Версію операційної системи RouterOS. Дуже раджу оновитися до RouterOS v7. У сьомій версії розробники MikroTik повністю переписали BGP-рушій. Тепер він багатопотоковий, працює значно швидше, а налаштування фільтрів стало набагато логічнішим та зручнішим, ніж у старій v6.
5. Резервні копії конфігурації. Перед будь-яким серйозним налаштуванням обов’язково робіть бекап. Також це чудовий привід перевірити, чи взагалі у вас правильно налаштовані резервні копії та базова безпека для всієї мережевої інфраструктури офісу.

Типові помилки

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

• Спроба запхати Full View в слабкий роутер. Адміністратор думає, що краще прийняти всю таблицю для максимальної точності. Як результат — процесор завантажується на 100%, роутер перестає відповідати навіть на локальні запити, а офіс повністю зупиняє роботу.
• Відсутність вихідних фільтрів (Out Filters). Це, мабуть, найнебезпечніша помилка. Якщо ви не налаштуєте жорсткий фільтр анонсів, ваш MikroTik може почати розповідати першому провайдеру про маршрути, які він отримав від другого. У результаті ваш маленький офісний роутер перетвориться на транзитний вузол для чужого інтернет-трафіку. Ваша лінія миттєво заб’ється чужими гігабайтами, а провайдери швидко заблокують таку сесію за порушення правил.
• Відсутність вхідних фільтрів (In Filters). Навіть якщо менеджер провайдера пообіцяв, що вони надсилатимуть лише Default Route, через людський фактор або збій у їхніх налаштуваннях вам може прилетіти шматок глобальної таблиці. Без вхідного фільтра ваш роутер спробує це обробити і, швидше за все, зависне.
• Зловживання AS-Path Prepend. Намагаючись зробити один із каналів резервним, адміністратори іноді додають занадто довгі хвости з повторів своєї AS. Це може призвести до того, що деякі автономні системи в інтернеті взагалі заплутаються в маршрутах і втратять зв’язок з вашою мережею.

Як краще зробити

Давайте розберемо реальний практичний кейс налаштування eBGP з двома провайдерами на MikroTik під керуванням сучасної RouterOS v7. Уявімо наступну задачу: ми маємо анонсувати нашу власну мережу 203.0.113.0/24 з нашої автономної системи AS 65530. Від обох операторів ми хочемо отримувати виключно Default Route (0.0.0.0/0).

Наші вхідні дані для стику:
ISP1 (основний канал): AS 100, IP-адреса провайдера на стику — 192.0.2.1, наша адреса — 192.0.2.2.
ISP2 (резервний канал): AS 200, IP-адреса провайдера на стику — 198.51.100.1, наша адреса — 198.51.100.2.

Крок 1. Налаштування IP-адрес

Для початку нам потрібно прописати IP-адреси на фізичних інтерфейсах, які дивляться в бік провайдерів, та створити локальний міст (bridge) для нашої власної незалежної мережі:

/ip address
add address=192.0.2.2/30 interface=ether1 comment="Стик з ISP1"
add address=198.51.100.2/30 interface=ether2 comment="Стик з ISP2"
add address=203.0.113.1/24 interface=bridge-local comment="Наша PI мережа"

Крок 2. Створення BGP шаблону

У RouterOS v7 вся логіка налаштування починається зі створення шаблону (template). Тут ми чітко вказуємо номер нашої автономної системи та Router ID (як правило, це перша IP-адреса з нашого власного блоку):

/routing bgp template
set default as=65530 router-id=203.0.113.1

Крок 3. Створення фільтрів маршрутизації

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

/routing filter rule
add chain=bgp-in-isp1 rule="if (dst == 0.0.0.0/0) { accept } else { reject }"
add chain=bgp-in-isp2 rule="if (dst == 0.0.0.0/0) { accept } else { reject }"

add chain=bgp-out-isp1 rule="if (dst == 203.0.113.0/24) { accept } else { reject }"
add chain=bgp-out-isp2 rule="if (dst == 203.0.113.0/24) { accept } else { reject }"

Крок 4. Налаштування BGP підключень (Connections)

Тепер ми створюємо безпосередньо самі сесії з нашими провайдерами, обов’язково прив’язуючи до них створені на попередньому кроці вхідні та вихідні фільтри:

/routing bgp connection
add name=bgp-to-isp1 remote.address=192.0.2.1/32 .as=100 local.role=ebgp \
    templates=default input.filter=bgp-in-isp1 output.filter=bgp-out-isp1 \
    connect=yes listen=yes

add name=bgp-to-isp2 remote.address=198.51.100.1/32 .as=200 local.role=ebgp \
    templates=default input.filter=bgp-in-isp2 output.filter=bgp-out-isp2 \
    connect=yes listen=yes

Крок 5. Трафік-інжиніринг (керування пріоритетами)

Якщо залишити все як є, вихідний трафік може розподілятися хаотично. Щоб зробити ISP1 основним каналом для виходу в інтернет, а ISP2 — резервним, ми використаємо параметр Local Preference для вхідних маршрутів. Чим вище це значення, тим привабливішим є канал для нашого роутера (стандартне значення — 100).

Знизимо пріоритет для маршруту від ISP2 до 50:

/routing filter rule
set [find chain=bgp-in-isp2] rule="if (dst == 0.0.0.0/0) { set bgp-local-pref 50; accept } else { reject }"

Тепер налаштуємо вхідний трафік (як зовнішній світ буде йти до нас). Для цього ми штучно подовжимо наш шлях для резервного провайдера ISP2 за допомогою механізму AS-Path Prepend. Ми просто додамо нашу власну AS тричі у вихідному фільтрі для другого провайдера:

/routing filter rule
set [find chain=bgp-out-isp2] rule="if (dst == 203.0.113.0/24) { set bgp-path-prepend 3; accept } else { reject }"

Крок 6. Перевірка працездатності

Щоб переконатися, що все налаштовано правильно і сесії піднялися, виконайте в консолі команду:

/routing/bgp/session/print

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

Коли звертатись до адміністратора

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

• Провайдери висувають специфічні вимоги: просять налаштувати MD5-паролі для захисту сесії, вимагають змінити параметри TTL (eBGP Multihop) або надіслати їм певні ком’юніті (BGP Communities).
• Після запуску схеми ви помітили, що деякі сайти або державні портали перестали відкриватися. Зазвичай це пов’язано з тонкощами налаштування MTU/MSS або виникненням асиметричної маршрутизації на стороні одного з операторів, і тут потрібен детальний аналіз трафіку.
• Вам потрібна складніша схема балансування. Наприклад, коли ви хочете пустити один відділ офісу через першого провайдера, інший — через другого, але при цьому зберегти повне автоматичне резервування на випадок аварії.
• Ваш офісний роутер все ще працює на старій гілці RouterOS v6, і ви побоюєтеся самостійно оновлювати його та переносити конфігурацію на v7, щоб не зупинити роботу компанії.
• Потрібно правильно підготувати технічні дані для провайдерів, заповнити опитувальники або створити об’єкти типу route та aut-num у базі даних RIPE DB, щоб ваші анонси не блокувалися на світовому рівні.

FAQ

Питання: Чи можна налаштувати BGP, якщо у мене немає власної AS та виділеного блоку IP-адрес?
Відповідь: Ні, це технічно неможливо. Для запуску повноцінного eBGP з двома різними провайдерами наявність власної автономної системи та блоку адрес (мінімум /24) є обов’язковою умовою. Якщо у вас просто два звичайних підключення від різних операторів, для резервування та балансування слід використовувати інші інструменти — наприклад, статичні маршрути з перевіркою доступності шлюзів через Netwatch або механізми балансування PCC/ECMP.

Питання: Що краще приймати від провайдерів: Default Route чи Full View?
Відповідь: Для абсолютного малого офісу найкращим вибором є Default Route (маршрут за замовчуванням). Це дозволяє тримати таблицю маршрутизації крихітною, не навантажує процесор вашого MikroTik і економить оперативну пам’ять. Приймати повну таблицю інтернету (Full View) має сенс лише тоді, коли ви самі є оператором зв’язку або якщо вам критично важливо обирати найкоротші шляхи до конкретних закордонних мереж для мінімізації затримок у специфічних сервісах.

Питання: Як швидко BGP перемикає трафік при аварії у провайдера?
Відповідь: За замовчуванням стандартні таймери утримання сесії (Hold Time) становлять 90 секунд. Тобто повне перемикання може тривати до півтори хвилини. Щоб зробити цей процес майже непомітним, можна погодити з провайдерами зменшення таймерів (наприклад, Keepalive 10, Hold Time 30) або налаштувати технологію BFD (Bidirectional Forwarding Detection), яка дозволяє виявити обрив фізичного лінка чи проблеми на стороні оператора за лічені частки секунди.

Питання: Чому після налаштування BGP деякі сайти перестали відкриватися?
Відповідь: Найчастіше це класична проблема з розміром пакетів — MTU (Maximum Transmission Unit). Через особливості тунелювання або налаштувань на стороні провайдера великі пакети можуть просто відкидатися. Ця проблема вирішується дуже просто — додаванням спеціального правила зміни MSS (Change MSS) у розділі фаєрволу MikroTik (Mangle) для всього TCP-трафіку.