MikroTik site-to-site VPN через WireGuard: практичний досвід розгортання та виправлення факапів у продакшені

П’ятниця, 16:45. Дзвінок від керівника складу: «У нас не друкуються ТТН, ТСД-термінали не бачать базу, робота стоїть». Моніторинг показує, що тунель між центральним офісом на CCR2004 (RouterOS 7.12) та регіональним складом на hEX S піднятий, але пінг пакетами понад 1400 байт тупо зникає. Класичний MTU black hole: провайдер на точці без попередження змінив конфігурацію та зарізав MTU. Цей інцидент коштував нам двох годин простою логістики та змусив повністю переписати стандарт розгортання site-to-site VPN на WireGuard. Нижче — вистражданий на продакшені гайд, як налаштувати стабільний тунель і не наступити на наші граблі.

Чому WireGuard витіснив IPsec та EoIP у нашій інфраструктурі

До RouterOS v7 ми будували мережі на IPsec IKEv2 або EoIP поверх IPsec. Це працювало, але конфігурація виглядала як триповерхове простирадло, а дебаг приносив лише головний біль. Коли у v7 з’явився нативний WireGuard, ми перевели на нього понад 40 філій. Результати:

• Продуктивність: Навантаження на CPU hEX S на складі впало з 45% (на IPsec) до 12% при стабільному трафіку 80 Мбіт/с.
• Простота: Конфіг ініціалізується буквально кількома рядками коду.
• Швидкість підняття: Тунель відновлюється за частки секунди після обриву лінку або зміни динамічної IP-адреси на філії.

Але RouterOS не була б RouterOS, якби все завелося «з коробки» без тюнінгу під капотом.

Топологія та вхідні дані

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

• HQ (Центральний офіс): Статичний IP 198.51.100.2, локальна мережа 192.168.10.0/24, WireGuard порт 51820.
• Branch (Філія/Склад): Динамічний IP (за NAT провайдера), локальна мережа 192.168.20.0/24.
• Транзитна підмережа тунелю: 10.0.0.0/30 (HQ: 10.0.0.1, Branch: 10.0.0.2).

Конфігурація: Крок за кроком (без води)

1. Налаштування HQ (CCR2004)

Спочатку створюємо інтерфейс WireGuard. Нам потрібен приватний ключ. Роутер згенерує його автоматично.

/interface wireguard
add listen-port=51820 name=wg-hq comment="Site-to-Site to Branch"

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

/interface wireguard print

Призначаємо IP-адресу на інтерфейс тунелю:

/ip address
add address=10.0.0.1/30 interface=wg-hq network=10.0.0.0

Тепер додаємо Peer (філію). Оскільки у філії динамічний IP, параметр endpoint-address не вказуємо. Дозволяємо трафік з тунельної IP та локальної мережі філії:

/interface wireguard peers
add allowed-address=10.0.0.2/32,192.168.20.0/24 interface=wg-hq public-key="BRANCH_PUBLIC_KEY_HERE" comment="Branch Office"

Прописуємо маршрут до локальної мережі філії через IP тунелю:

/ip route
add dst-address=192.168.20.0/24 gateway=10.0.0.2 comment="Route to Branch"

2. Налаштування Branch (hEX S)

Створюємо інтерфейс на боці філії. Порт можна вказати той самий:

/interface wireguard
add listen-port=51820 name=wg-branch comment="Link to HQ"

Призначаємо IP-адресу:

/ip address
add address=10.0.0.2/30 interface=wg-branch network=10.0.0.0

Додаємо HQ як Peer. Тут ми обов’язково вказуємо публічну IP-адресу офісу, порт та параметр persistent-keepalive. Без останнього тунель «засинатиме», бо філія знаходиться за NAT:

/interface wireguard peers
add allowed-address=10.0.0.1/32,192.168.10.0/24 endpoint-address=198.51.100.2 endpoint-port=51820 interface=wg-branch public-key="HQ_PUBLIC_KEY_HERE" persistent-keepalive=25s comment="HQ Office"

Додаємо маршрут до центрального офісу:

/ip route
add dst-address=192.168.10.0/24 gateway=10.0.0.1 comment="Route to HQ"

Граблі, на які ми наступили (Факапи та їх вирішення)

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

Факап №1: Проблема з MTU та MSS (Чому «залипали» сайти та RDP)

Стандартний MTU для WireGuard — 1420 байт. Але якщо ваш провайдер використовує PPPoE або L2TP, реальний MTU фізичного каналу падає до 1480 або 1460. Додайте сюди 60 байт накладних витрат WireGuard — і ми отримуємо фрагментацію пакетів. На практиці це виглядає так: пінг йде, але RDP-сесія зависає при спробі відкрити важку графіку, а бази даних видають таймаут.

Рішення: Примусово затискаємо MSS для TCP-пакетів, що проходять через тунель. Це змушує клієнтів відправляти пакети правильного розміру без фрагментації.

/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtup passthrough=yes protocol=tcp tcp-flags=syn out-interface=wg-hq comment="Clamp MSS for HQ WG"
add action=change-mss chain=forward new-mss=clamp-to-pmtup passthrough=yes protocol=tcp tcp-flags=syn out-interface=wg-branch comment="Clamp MSS for Branch WG"

Примітка: Якщо провайдер зовсім поганий (наприклад, LTE-модем на резервному каналі), зменшуйте MTU безпосередньо на інтерфейсі WireGuard до 1360.

Факап №2: Fasttrack ламає маршрутизацію

За замовчуванням у конфігурації MikroTik увімкнений Fasttrack. Він пускає встановлені з’єднання в обхід ядра процесора для економії ресурсів. Проблема в тому, що Fasttrack не вміє коректно працювати з WireGuard-інтерфейсами. Як результат — пакети починають йти в обхід тунелю прямо в WAN, або просто дропаються.

Рішення: Додаємо правило-виключення у Firewall Filter ПЕРЕД дефолтним правилом Fasttrack:

/ip firewall filter
add action=accept chain=forward connection-state=established,related dst-address=192.168.20.0/24 src-address=192.168.10.0/24 comment="Bypass Fasttrack for WG Traffic" place-before=[find where action=fasttrack-connection]
add action=accept chain=forward connection-state=established,related dst-address=192.168.10.0/24 src-address=192.168.20.0/24 comment="Bypass Fasttrack for WG Traffic (Return)" place-before=[find where action=fasttrack-connection]

Факап №3: Firewall блокує тунель після зміни IP

Якщо на філії змінився зовнішній IP, вона намагається постукати на HQ. Але якщо у вас закритий Firewall на Input, роутер просто ігноруватиме ці пакети.

Рішення: Дозволяємо вхідні з’єднання на порт WireGuard на обох пристроях:

/ip firewall filter
add action=accept chain=input dst-port=51820 protocol=udp comment="Allow WireGuard Input" place-before=1

Висновки та експлуатація

Після впровадження MSS clamping та виключення тунельного трафіку з Fasttrack, аптайм нашої мережі складів наблизився до 99.9%. WireGuard на RouterOS v7 показав себе як залізобетонне рішення, яке переварює гігабіти трафіку без витоків пам’яті та зависань процесора.