Налаштування MikroTik IPsec Site-to-Site VPN

Коротко MikroTik IPsec site-to-site VPN шифрує трафік між двома цілими мережами — головним офісом і філією, NOC і вежею — так, що хости в кожній LAN звертаються до іншої, наче вона локальна. Ця інструкція налаштовує обидва роутери на RouterOS v7: peer IKEv2, identity зі спільним ключем, proposal для Phase 2, політику тунелю, правило обходу NAT, на якому спотикається більшість перших спроб, а також правила фаєрвола й перевірки, що підтверджують роботу тунелю.

Що таке MikroTik IPsec site-to-site VPN?

MikroTik IPsec site-to-site VPN — це постійний зашифрований тунель між двома роутерами, який об’єднує дві окремі LAN в одну маршрутизовану мережу на рівні L3 без того, щоб хоч один роутер виставляв порт керування в публічний інтернет. На відміну від клієнтських VPN на кшталт WireGuard чи OpenVPN — де підключається один адміністраторський пристрій — тунель site-to-site працює постійно й з’єднує підмережу з підмережею: кожен хост за роутером A автоматично дістається до кожного дозволеного хоста за роутером B. IPsec тут доречний, бо це відкритий стандарт, який підтримує практично кожен виробник фаєрволів і роутерів, він виконується в ядрі RouterOS і дає добру пропускну здатність, а на MikroTik уже вбудований — жодних додаткових пакетів ставити не треба.

Тунель будується у два узгодження. Phase 1 (IKE) автентифікує роутери один перед одним і піднімає захищений канал; Phase 2 (IPsec) узгоджує ключі, які власне шифрують ваш трафік. Якщо обидві фази збігаються на кожному кінці, тунель піднімається; якщо не збігається бодай один алгоритм, він тихо падає — саме тому кроки нижче тримають обидві сторони симетричними.

Перед початком

Вам потрібні два роутери MikroTik із RouterOS v7, кожен із публічною IP-адресою або робочим DDNS-іменем, і дві неперетинні LAN-підмережі. У цій інструкції на Site A використано 192.168.10.0/24, а на Site B — 192.168.20.0/24. Якщо обидва майданчики працюють на 192.168.88.0/24, маршрутизація неможлива — спершу переадресуйте один бік. Оскільки IPsec дуже чутливий до розбіжності годинників, увімкніть NTP на обох роутерах перед початком; якщо кінці розійдуться в часі, security associations спливуть і тунель постійно рватиметься.

Стежити за цією передумовою на більш ніж кількох майданчиках — уже морока. Коли ви керуєте парком пристроїв, MKController дає одну консоль, щоб перед перемиканням тунелю перевірити версію RouterOS і джерело часу на кожному роутері, і вам не доводиться заходити на кожен пристрій лише заради підтвердження готовності.

Крок 1: Створіть профіль IKE та peer

На Site A визначте профіль Phase 1 і спрямуйте peer на публічну адресу Site B:

/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \
    enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d

/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \
    profile=to-siteB exchange-mode=ike2

dh-group=modp2048 — це Diffie-Hellman Group 14, надійне сучасне значення за замовчуванням. exchange-mode=ike2 вибирає IKEv2, який швидший і стійкіший за застарілий режим main/IKEv1. Обидва кінці мають використовувати однакові значення профілю й однаковий exchange mode.

Крок 2: Додайте identity (спільний ключ)

/ip ipsec identity add peer=siteB auth-method=pre-shared-key \
    secret="<long-random-shared-secret>"

Використайте довгий випадковий секрет і зберігайте його так само, як SSH-ключ, — не в повідомленні чату. Той самий секрет ставиться на обидва роутери.

Крок 3: Визначте proposal для Phase 2

/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \
    enc-algorithms=aes-256-cbc pfs-group=modp2048

Perfect Forward Secrecy (pfs-group) означає, що кожне переузгодження ключів використовує свіжий ключовий матеріал, тож скомпрометований ключ ніколи не розкриє минулий трафік. Як і в Phase 1, алгоритми мають збігатися на обох кінцях.

Крок 4: Створіть політику тунелю

Політика вказує RouterOS, який трафік шифрувати, — з локальної LAN до віддаленої LAN:

/ip ipsec policy add peer=siteB tunnel=yes \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    proposal=to-siteB action=encrypt

Саме tunnel=yes робить це з’єднання site-to-site, а не host-to-host: початкові пакети загортаються цілком, тож дві LAN спілкуються прозоро.

Крок 5: Додайте правило обходу NAT (крок, про який усі забувають)

Ось де ламається більшість перших спроб. На вашому роутері вже є правило masquerade, яке переписує адресу джерела для вихідного трафіку LAN. Якщо воно спрацює раніше за IPsec, віддалений кінець отримає пакети, чиє джерело більше не збігається з політикою, і відкине їх. Додайте правило accept вище за masquerade, щоб трафік до тунелю оминав NAT:

/ip firewall nat add chain=srcnat action=accept place-before=0 \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24

place-before=0 ставить правило на самий верх ланцюжка srcnat, і це обов’язково — правило обходу після masquerade не робить нічого.

Крок 6: Відкрийте фаєрвол і перевірте тунель

Дозвольте порти IKE та NAT-T разом із протоколом ESP у ланцюжку input, щоб тунель зміг встановитися, — особливо якщо котрийсь із майданчиків стоїть за ще одним NAT-пристроєм:

/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept
/ip firewall filter add chain=input protocol=ipsec-esp action=accept

Потім переконайтеся, що тунель піднявся:

/ip ipsec active-peers print
/ip ipsec policy print

Здоровий тунель показує активний peer і політику, у якої ph2-state дорівнює established. Швидкий ping від хоста в одній LAN до хоста в іншій підтверджує наскрізну доступність.

Віддзеркальте конфігурацію на Site B

Повторіть кожен крок на Site B зі зворотними адресами: peer вказує на публічну IP-адресу Site A, а політика й обхід NAT використовують src-address=192.168.20.0/24 і dst-address=192.168.10.0/24. Профіль, proposal, секрет identity та режим IKEv2 лишаються ідентичними. Коли обидві сторони збігаються, Phase 1 і Phase 2 завершуються й тунель піднімається.

Поради з безпеки та експлуатації

Тримайте RouterOS оновленим — свіжі релізи привозили виправлення, що стосуються звіряння сертифікатів peer у IPsec/IKEv2, тож тунель, який працював минулого кварталу, вартий повторної перевірки після кожного оновлення. Віддавайте перевагу IKEv2 з PFS перед застарілими типовими налаштуваннями IKEv1. Де можливо, з ростом кількості тунелів переходьте зі спільного секрету на автентифікацію сертифікатами, бо один витеклий pre-shared key зачіпає кожен майданчик, який його використовує. І пишіть стан тунелю в лог, за яким ви справді стежите: мертвий site-to-site лінк невидимий, доки хтось не спробує дістатися до віддаленої LAN і не зможе.

У парку пристроїв IPsec-тунель, який тихо падає після розсинхронізації годинника чи стрибка WAN, — саме та несправність, яку клієнт помічає раніше за вас. MKController закриває цю прогалину: він наглядає за кожним роутером через захищений вихідний тунель, якому не потрібні ані публічна IP-адреса, ані проброс портів на пристрої, зберігає версійовані резервні копії конфігурації, щоб ви могли порівняти й відновити робочий блок IPsec після невдалої правки, і може відкрити тікет за подією link-down ще до того, як задзвонить телефон. Щодо самої конфігурації тунелю: наш посібник про NAT на MikroTik пояснює правило masquerade, яке ви тут обходите, а якщо треба дістатися до одного роутера, а не з’єднати дві LAN, дивіться віддалене керування за CGNAT і наш розбір віддаленого керування через WireGuard.

Зберіть усі тунелі під одним дахом

IPsec акуратно з’єднує два майданчики, але в ISP чи MSP, який росте, невдовзі з’являються десятки тунелів, ключів і правил фаєрвола, які треба тримати синхронними, — і кожна ручна правка це шанс замкнути себе поза віддаленим майданчиком. MKController зроблено саме для такого масштабу: централізоване керування парком, захищений віддалений доступ без відкритих портів, історія конфігурацій і резервні копії, а також розкочування змін фаєрвола й політик на весь парк, тож шаблон тунелю розгортається один раз, а не передруковується роутер за роутером. Оператори, які працюють із MikroTik у масштабі, перетворюють ним змарнований день у SSH на кожному пристрої на кілька кліків на зміну.

Почніть безкоштовний пробний період MKController