MikroTik IPsec IKEv2 між офісами: як зробити його стабільним (і чому він флапає)

Що насправді означає «флапінг» (і що це не)

Коли кажуть, що IPsec тунель «флапає», зазвичай мають на увазі одну з трьох різних речей:

• Хаос IKE SA: контрольна площина IKEv2 постійно переукладається. Ви побачите повторювані переговори «ініціатор»/«респондент», часті видалення або таймаути DPD.
• Хаос Child SA: IKE тримається, але ESP (дані) SAs занадто часто перезаписуються, видаляються або замінюються, порушуючи довготривалі потоки.
• Чорна діра трафіку: тунель «вгорі», але трафік періодично не підпадає під політику, маршрути змінюються, спрацьовує NAT або MTU ламає лише певні додатки.

Не трактуйте їх як одну й ту саму проблему. У них різні підписи, різні причини і різні виправлення.
«Тунель піднятий» — не метрика успіху. «Бізнес‑трафік лишається нудним» — ось справжня метрика.

Також: якщо ваш WAN‑лінк падає — VPN падає. Це не «флапінг», це фізика. Трюк у тому, щоб VPN не вигадував збої на здоровому WAN.

Цікавинки та історія, якими можна скористатися о 2 ночі

1. IKEv2 був створений, щоб зменшити складність у порівнянні з IKEv1, особливо навколо рекейкінгу та обходу NAT, але реалізації все ще відрізняються в граничній поведінці.
2. Обхід NAT старший за кар’єри багатьох інженерів: UDP‑инкапсуляція для ESP (NAT‑T) стала поширеною на початку 2000‑х, бо NAT‑пристрої псували IPsec.
3. DPD існує тому, що «байдужість» ≠ «здоров’я». Проміжні пристрої тихо видаляють стан; DPD — контрольований спосіб виявити це до того, як користувачі постраждають.
4. Perfect Forward Secrecy (PFS) не безкоштовний: він додає навантаження на CPU під час рекейку. На малих роутерах агресивні таймлайти можуть призвести до самонанесених відмов.
5. UDP 500/4500 сам по собі не ненадійний; просто це протокол, який найчастіше «оптимізують» stateful‑фаєрволи, CGNAT і обладнання провайдерів.
6. Виявлення MTU (PMTUD) майже завжди «працює частково». Фільтрація ICMP досі ламає його, а інкапсуляція VPN збільшує зону ураження.
7. RouterOS значно еволюціонував у частині IPsec між релізами; поведінка щодо пропозицій, ідентичностей і апаратного оффлоаду відрізняється за платформою і версією.
8. Колізії при рекейку — класика: обидва пірени одночасно рекейкують, кожен думає, що «виграв», і трафік падає, поки один не прибере старі стани. Сучасні стеки краще, але не ідеальні.

Референсна архітектура для стабільного IKEv2 між офісами на MikroTik

Оберіть одну модель: policy‑based або route‑based. Не робіть помилку гібриду.

MikroTik підтримує policy‑based IPsec (селекторами в політиках) і може реалізувати route‑based дизайни, використовуючи VTI‑подібні підходи залежно від версії RouterOS і функцій.
Історії про флапи, з якими я стикався, зазвичай відбувалися у конфігураціях «переважно policy‑based, але додали маршрут тут і тепер у вівторок половина мережі не працює».

Для двох офісів policy‑based підходить, якщо у вас стабільні підмережі й невелика кількість селекторів. Він стає крихким, коли:
додаєте більше підмереж, робите hairpin‑трафік, маєте перекривання діапазонів або вводите множинні WAN‑інтерфейси.
У такому випадку віддавайте перевагу route‑based дизайну та робіть маршрути явними.

Ідентичності та адресація: уникайте «як дасть провайдер»

Якщо хоча б одна сторона має динамічну публічну IP‑адресу, стабільність можлива, але потрібна свідомість:
використовуйте FQDN ідентичності, строгий матчинг peer‑ів і чисту конфігурацію респондента. Якщо можете купити статичні IP — зробіть це. Це дешевше за простій.

Крипто й таймлайти: нудне виграє

Базова стійка конфігурація, яку я зазвичай використовую, якщо політики не вимагають інакше:

• IKE (фаза 1): AES‑256, SHA‑256, DH група 14+ (або ECP групи, якщо обидві сторони їх коректно підтримують)
• ESP (фаза 2): AES‑256‑GCM якщо підтримується наскрізь; інакше AES‑256 + SHA‑256
• Таймлайти: не «якомога коротші». Ціль — розумні значення (години, не хвилини), вирівняні на обох кінцях.
• PFS: включайте, якщо вистачає CPU; інакше вимкніть і компенсуйте довшим IKE SA та сильною IKE крипто‑набором.

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

NAT і правила фаєрволу: зробіть контрольну площину нудною

Дозвольте UDP 500 і UDP 4500 на вхід, і дозволяйте ESP якщо ви не використовуєте NAT‑T (переважно використовують NAT‑T). Переконайтесь, що правила NAT не транслюють трафік, який має захищатися.
Стабільний тунель часто вмирає тому, що правило NAT «допомагає» і маскує офісну підмережу по дорозі в тунель.

MTU/MSS: ставте це в ранг першокласних залежностей

Накладення інкапсуляції зменшує ефективний MTU. Якщо ви цього не плануєте, отримаєте селективні відмови: веб працює, копіювання файлів повільне, RDP підскакує,
і хтось звинуватить «провайдера». Майже завжди це MTU разом з блокуванням ICMP.

Чому MikroTik IKEv2 флапає: реальні режими відмов

1) Тайм‑аути стану NAT і зміни портів (особливо за CGNAT)

IKEv2 через NAT‑T йде по UDP 4500. Багато NAT‑пристроїв дуже агресивно закривають UDP‑стан, особливо коли трафік «байдужий».
Коли мапінг змінюється, пірен шле пакети на «мертвий» порт і ви отримуєте DPD‑відмови або завислі SAs.
Якщо ви за CGNAT — ситуація гірша: ви навіть не маєте доступу налаштувати NAT.

Виправлення: увімкніть NAT keepalive і зробіть DPD розумним. Не ставте DPD у «режим молотка», якщо вам не до вподоби штучні шквали реконфігурацій.

2) Колізії рекейка та невирівняні таймлайти

Якщо обидві сторони рекейкують одночасно (або таймлайти не вирівняні), Child SAs можуть замінюватися так, що перервуть потоки.
Симптом — «кожні X хвилин з’єднання скидаються», часто як по таймеру.

Виправлення: вирівняйте таймлайти, додайте маржу рекейка, уникайте надто коротких таймлайтів. Також виміряйте навантаження CPU під час рекейку.

3) Невідповідність пропозицій, що проявляється лише при рекейку

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

Виправлення: явно вкажіть набори пропозицій на обох сторонах. Не покладайтеся на «дефолт». За різних версій RouterOS значення за замовчуванням змінюються.

4) Проблеми MTU/фрагментації (для IKE‑повідомлень і плоскості даних)

IKEv2‑повідомлення можуть бути великими, особливо з сертифікатами, множинними пропозиціями або vendor ID.
Якщо фрагментацію UDP блокує щось посередині, хендшейк може періодично падати.
Потім плоскость даних матиме класичну проблему «великі пакети вмирають», якщо PMTUD не працює.

Виправлення: тримайте крипто‑конфіг простішою, дозвольте фрагментацію при потребі і обмежуйте MSS для TCP‑потоків, щоб не покладатися на PMTUD.

5) Дрейф маршрутів або селекторів політик

Policy‑based тунелі залежать від селекторів. Додали нову підмережу на одному сайті і забули додати на іншому? Тунель піднімається, але трафік до тієї підмережі не проходить.
Гірше: при перекриваючих політиках трафік може співпадати з хибною і викликати «неочікувані» установлення SA.

Виправлення: тримайте селектори симетричними, контролюйте порядок політик і лог‑дропи у forward‑ланці, щоб бачити, що реально блокується.

6) Правила фаєрволу, що майже правильні

«Ми дозволяємо UDP 500 і 4500». Чудово. А ви дозволяєте established/related? А чи дозволяєте ви IPsec‑політику у forward‑ланці?
Чи не поставили ви fasttrack попереду IPsec‑виключень?

RouterOS може fasttrack‑ити трафік так, що він обминає IPsec‑опрацювання, якщо це не враховано. Це може створити чорні діри, що виглядають як флапи тунелю.

7) Запас продуктивності: тунель стабільний, роутер — ні

При навантаженні CPU keepalive і DPD‑запити затримуються. Тоді пірени оголошують один одного мертвими і реконфігурують тунель.
На папері пропускна спроможність нормальна; насправді роутер завалений шифруванням, чергуванням і NAT/фаєрволом без оффлоаду.

Виправлення: виміряйте CPU у піку, перевірте апаратний оффлоад, спростіть правила і припиніть рекейки кожні кілька хвилин.

Жарт №1: IPsec не хитрий; він просто дуже чесно повідомляє про кожну маленьку брехню вашої мережі.

Швидкий план діагностики (перший/другий/третій)

Коли тунель «флапає», не починайте з зміни крипто. Спочатку доведіть, який рівень нестабільний.
Ось порядок швидкої триаж‑діагностики, що заощаджує час і рятує від забобонів.

Перший: доведіть, що WAN достатньо стабільний для UDP 4500

• Перевірте помилки/дропи інтерфейсу, події link up/down.
• Перевірте, чи змінюється публічна IP (динамічна IP, PPPoE перепідключення, LTE‑фейловер).
• Перевірте втрати пакетів і джиттер до публічної IP пірена з часом.

Другий: доведіть здоров’я контрольної площини IKE

• Спостерігайте за віком IKE SA, подіями рекейку, таймаутами DPD.
• Шукайте повтори «no proposal chosen», «auth failed», «peer not responding».
• Підтвердьте виявлення NAT‑T і постійність портів.

Третій: доведіть правильність плоскості даних

• Переконайтесь, що політики/селектори співпадають з реальним трафіком.
• Підтвердьте, що маршрути направляють потрібні підмережі в IPsec.
• Проведіть перевірку MTU/MSS реальними тестами (не довіряйте дефолтним pingам).
• Перевірте, чи fasttrack/NAT не заважають.

Четвертий: тільки тоді тонко налаштовуйте крипто та таймлайти

Якщо WAN і політики чисті, тоді налаштовуйте пропозиції, PFS, таймлайти і маржі рекейку.
Раннє роблення цього — причина конфігів, що «іноді працюють».

Практичні завдання: команди, виводи та рішення (12+)

Ці завдання написані як рукопис для виїзду на інцидент: запустіть команду, інтерпретуйте вивід, потім прийміть рішення.
Команди показані так, ніби виконуються з Linux‑jump‑host, що може SSH на обидва MikroTik. Адаптуйте імена хостів під себе.

Завдання 1: Підтвердити версію RouterOS і платформу (поведінка різна)

cr0x@server:~$ ssh admin@mtk-office-a '/system/resource/print'
                   uptime: 2w1d3h
                  version: 7.15.3 (stable)
               build-time: 2025-08-01 10:12:45
              free-memory: 312.4MiB
             total-memory: 512.0MiB
                      cpu: ARM
                cpu-count: 4
            cpu-frequency: 1400MHz
                 cpu-load: 18%

Що це означає: основна/друга версія RouterOS впливає на деталі IPsec‑стеку і значения за замовчуванням. CPU і пам’ять кажуть, чи ви на межі ресурсів.

Рішення: Якщо версії сильно різняться між сайтами — вирівняйте їх. Якщо навантаження CPU стрибкоподібно зростає під час падінь — це проблема ємності, а не крипто.

Завдання 2: Перевірити стабільність лінку і зміну WAN IP

cr0x@server:~$ ssh admin@mtk-office-a '/ip/address/print where interface~"wan"'
 #   ADDRESS            NETWORK         INTERFACE
 0   203.0.113.10/24    203.0.113.0     wan1

cr0x@server:~$ ssh admin@mtk-office-a '/log/print where message~"link down|link up|pppoe"'
 0 time=2025-12-27 10:12:01 topics=interface,info message=wan1 link down
 1 time=2025-12-27 10:12:05 topics=interface,info message=wan1 link up (speed 1G, full duplex)

Що це означає: Якщо WAN‑інтерфейс підстрибає — IPsec тут просто побічна жертва. Тунель не «флапає» сам по собі; провайдер.

Рішення: Спочатку виправте фізичний лінк/провайдера. Якщо IP часто змінюється — віддавайте перевагу FQDN‑ідентичності або DDNS‑процесу та перевіряйте матч peer.

Завдання 3: Перевірити IPsec peers і чи застосовується NAT‑T

cr0x@server:~$ ssh admin@mtk-office-a '/ip/ipsec/peer/print detail'
 0 name="office-b" address=198.51.100.20/32 local-address=203.0.113.10
   exchange-mode=ike2 send-initial-contact=yes nat-traversal=yes
   dpd-interval=10s dpd-maximum-failures=3 profile=ike2-prof

Що це означає: NAT‑traversal увімкнений — зазвичай правильно. Інтервал DPD і кількість невдач визначають, як швидко ви оголосите пірена мертвим.

Рішення: Якщо бачите nat-traversal=no при наявності NAT на одній зі сторін — виправте. Якщо DPD надто агресивний для вашого WAN — послабте його.

Завдання 4: Переглянути активні SAs і шукати закономірності хенжів

cr0x@server:~$ ssh admin@mtk-office-a '/ip/ipsec/active-peers/print detail'
 0 ike2=yes name="office-b" state=established
   local-address=203.0.113.10 remote-address=198.51.100.20
   side=initiator nat-traversal=yes
   uptime=00:43:12 last-dpd=00:00:07

cr0x@server:~$ ssh admin@mtk-office-a '/ip/ipsec/installed-sa/print detail'
 0 spi=0xC1A2B3C4 src-address=203.0.113.10 dst-address=198.51.100.20
   state=mature auth-algorithm=sha256 enc-algorithm=aes-256-gcm
   lifetime=00:58:21 expires-in=00:01:39

Що це означає: Якщо SAs постійно витікають і перевстановлюються — ймовірно, таймлайти надто короткі або рекейкові проблеми.

Рішення: Якщо рекейки трапляються частіше, ніж раз на годину для простого офіс‑тунелю — перегляньте таймлайти і PFS.

Завдання 5: Тимчасово увімкнути детальне логування IPsec (а потім вимкнути)

cr0x@server:~$ ssh admin@mtk-office-a '/system/logging/add topics=ipsec,debug action=memory'
cr0x@server:~$ ssh admin@mtk-office-a '/log/print where topics~"ipsec"'
 0 time=2025-12-28 09:14:02 topics=ipsec,debug message=initiating IKE_SA to 198.51.100.20
 1 time=2025-12-28 09:14:02 topics=ipsec,debug message=IKE_SA established
 2 time=2025-12-28 09:15:33 topics=ipsec,debug message=DPD timeout, peer not responding
 3 time=2025-12-28 09:15:33 topics=ipsec,debug message=deleting IKE_SA

Що це означає: Логи показують причину на контрольній площині: тут — таймаути DPD, а не проблеми з пропозиціями.

Рішення: Якщо DPD таймаути відбуваються при стабільному WAN — підозрюйте закінчення стану NAT, фільтрацію upstream або затримки CPU.

Завдання 6: Перевірити, що фаєрвол дозволяє IKEv2 і NAT‑T на роутер

cr0x@server:~$ ssh admin@mtk-office-a '/ip/firewall/filter/print where chain="input"'
 0 chain=input action=accept connection-state=established,related
 1 chain=input action=accept protocol=udp dst-port=500,4500
 2 chain=input action=drop in-interface=wan1

Що це означає: UDP 500/4500 дозволені перед drop. Добре. Якщо ці правила стоять після drop — ви зробили VPN‑прошарок паперу.

Рішення: Переконайтесь, що accept‑правила йдуть перед drop. Якщо використовуєте address‑lists, обмежте доступ IP пірена з міркувань гігієни.

Завдання 7: Виявити, чи fasttrack заважає IPsec

cr0x@server:~$ ssh admin@mtk-office-a '/ip/firewall/filter/print where action~"fasttrack"'
 0 chain=forward action=fasttrack-connection connection-state=established,related

Що це означає: Загальне fasttrack‑правило може обминати обробку IPsec, якщо ви не зробите винятків.

Рішення: Додайте виняток для IPsec‑політики перед fasttrack або вимкніть fasttrack, якщо можете дозволити собі трохи меншу продуктивність.

Завдання 8: Переконатися, що правила NAT не NAT‑ять захищені підмережі

cr0x@server:~$ ssh admin@mtk-office-a '/ip/firewall/nat/print'
 0 chain=srcnat action=masquerade out-interface=wan1
 1 chain=srcnat action=accept ipsec-policy=out,ipsec
 2 chain=srcnat action=masquerade src-address=10.10.0.0/16 out-interface=wan1

Що це означає: Правило 1 — критичне «не NAT‑ити IPsec» виняток. Без нього трафік може NAT‑итися й перестати співпадати з селекторами.

Рішення: Переконайтесь, що accept‑правило є і стоїть вище masquerade. Якщо бачите masquerade, що зачіпає VPN‑трафік — виправте порядок.

Завдання 9: Перевірити, що селектори політик збігаються в обох напрямках

cr0x@server:~$ ssh admin@mtk-office-a '/ip/ipsec/policy/print detail'
 0 src-address=10.10.10.0/24 dst-address=10.20.10.0/24 action=encrypt
   tunnel=yes peer=office-b proposal=esp-prof

cr0x@server:~$ ssh admin@mtk-office-b '/ip/ipsec/policy/print detail'
 0 src-address=10.20.10.0/24 dst-address=10.10.10.0/24 action=encrypt
   tunnel=yes peer=office-a proposal=esp-prof

Що це означає: Симетрія важлива. Якщо Office B має 10.10.0.0/16, а Office A — 10.10.10.0/24, отримаєте часткову доступність і заплутані SA.

Рішення: Нормалізуйте селектори. Якщо потрібно багато підмереж — акуратно консолідуйте селектори або перейдіть на route‑based підхід.

Завдання 10: Спостерігати дропи й матчі політик за допомогою лічильників

cr0x@server:~$ ssh admin@mtk-office-a '/ip/firewall/filter/print stats where chain="forward"'
 0 chain=forward action=accept ipsec-policy=in,ipsec packet-count=124992 byte-count=98311234
 1 chain=forward action=accept ipsec-policy=out,ipsec packet-count=121887 byte-count=96733122
 2 chain=forward action=drop in-interface=wan1 packet-count=22 byte-count=1452

Що це означає: Трафік з IPsec‑політикою приймається і рахується. Якщо лічильники стоять на нулі, а користувачі скаржаться — трафік не співпадає з політикою (маршрути, NAT або селектори).

Рішення: Якщо лічильники accept для IPsec не рухаються — припиніть ковирятися в IPsec і виправляйте маршрути/NAT/адресацію.

Завдання 11: Реальна перевірка MTU за допомогою ping з «do not fragment»

cr0x@server:~$ ping -M do -s 1472 10.20.10.10 -c 3
PING 10.20.10.10 (10.20.10.10) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1460
ping: local error: message too long, mtu=1460
ping: local error: message too long, mtu=1460

--- 10.20.10.10 ping statistics ---
3 packets transmitted, 0 received, +3 errors, 100% packet loss

Що це означає: Path MTU менший, ніж очікувалося. Через VPN це нормально — але потрібно підлаштуватися для TCP.

Рішення: Обмежте TCP MSS на MikroTik для трафіку у тунель або налаштуйте MTU інтерфейсів, якщо контролюєте шлях.

Завдання 12: Перевірка фрагментації IKE або проблем з великими хендшейками (за симптомом)

cr0x@server:~$ ssh admin@mtk-office-a '/log/print where message~"fragment|too large|invalid"'
 0 time=2025-12-28 08:01:19 topics=ipsec,debug message=received packet too large, dropping
 1 time=2025-12-28 08:01:19 topics=ipsec,debug message=peer not responding

Що це означає: Деякі мережі блокують фрагментовані UDP. Великі IKE‑повідомлення можуть вмирати в дорозі, спричиняючи періодичні відмови переговорів.

Рішення: Скоротіть набір пропозицій, розгляньте PSK замість великих ланцюгів сертифікатів там, де доречно, і переконайтесь, що upstream‑пристрої не блокують фрагменти.

Завдання 13: Заміряти CPU та навантаження переривань під час рекейка

cr0x@server:~$ ssh admin@mtk-office-a '/tool/profile'
name                    cpu        memory
firewall                22%        0 B
ipsec                   31%        0 B
ethernet                6%         0 B
management              2%         0 B

Що це означає: IPsec, що споживає третину CPU, не обов’язково погано, але якщо під час піку воно стрибає до 90%, DPD і таймери рекейка стають «неохайними».

Рішення: Якщо IPsec — один із топ‑споживачів CPU і ви бачите флапи, збільште таймлайти, зменшіть вартість PFS, увімкніть апаратний оффлоад або оновіть обладнання.

Завдання 14: Перевірити маршрути до віддалених підмереж (не припускайте)

cr0x@server:~$ ssh admin@mtk-office-a '/ip/route/print where dst-address=10.20.10.0/24'
 0 dst-address=10.20.10.0/24 gateway=ipsec policy distance=1 scope=30 target-scope=10

Що це означає: Залежно від дизайну, ви можете бачити політично‑керовану маршрутизацію без явних маршрутів, або покладатися на маршрути. Не покладайтеся на відчуття.

Рішення: Якщо маршрути вказують в інше місце (default, неправильний gateway, інший VRF), тунель може бути «вгорі», а трафік іти в інтернет і загубитись.

Завдання 15: Захопити пакети, щоб довести, чи губите IKE або ESP

cr0x@server:~$ ssh admin@mtk-office-a '/tool/sniffer/quick interface=wan1 ip-protocol=udp port=500,4500'
 0  2025-12-28 09:21:11 203.0.113.10:4500 -> 198.51.100.20:4500 UDP  92
 1  2025-12-28 09:21:21 203.0.113.10:4500 -> 198.51.100.20:4500 UDP  92
 2  2025-12-28 09:21:31 203.0.113.10:4500 -> 198.51.100.20:4500 UDP  92

Що це означає: Ви бачите вихідні keepalive/DPD‑пакети, але чи бачите відповіді? Якщо ні — це фільтрація upstream, закінчення стану NAT або далека сторона мертва.

Рішення: Якщо вихідні пакети є, а вхідних немає — припиніть переконфігурацію локального роутера. Доведіть шлях або те, що віддалена сторона відкидає.

Три корпоративні міні‑історії з передової

Міні‑історія 1: Інцидент через хибне припущення

Середня компанія мала два офіси і «простий» IKEv2 тунель. Він працював місяцями, потім почав обриватися щодня після обіду. Helpdesk звинувачував провайдера,
мережники — IPsec, а безпека — «когось змінив крипто».

Хибне припущення було тонким: вони вважали, що «немає трафіку» означає «немає проблем». Насправді тунель був переважно неактивним, поки співробітники не почали використовувати новий SaaS,
що спричиняв періодичні вибухи трафіку з довгими простоями. NAT‑пристрій провайдера мав агресивний UDP‑тайм‑аут. Мапінг для UDP 4500 зникав під час простою,
а наступний пакет виходив з нового порту. Далека сторона надсилала на старий мапінг, поки DPD не оголошував пірена мертвим.

Логи це показували з повторами: DPD timeout, delete IKE SA, renegotiate. Але всі дивилися лише після того, як все «знову піднялося», бачили SAs і відходили.

Виправлення було нудним: увімкнули регулярні NAT keepalive (і перестали їх вимикати «щоб менше шуму»), пом’якшили DPD під джиттер і встановили таймлайти так, щоб рекейки не збігалися з щоденним бекапом.
Тунель став знову невидимим — найкращий вид VPN.

Міні‑історія 2: Оптимізація, що відбилася бумерангом

Ще одна компанія мала RouterOS‑фаєрвол з увімкненим fasttrack. Вони пишалися цим: пропускна здатність була чудова, CPU низький, графіки симпатичні.
Потім перейшли з IKEv1 на IKEv2 і раптово отримали випадкові односторонні проблеми трафіку. Тунель не «падав», але копіювання файлів зависало і VoIP перетворювався на роботизоване звучання на 10–30 секунд.

«Оптимізація» була в fasttrack на established/related без винятку для IPsec. Деякі потоки оброблялися fasttrack‑ом так, що обходили політику, потрібну для шифрування/дешифрування.
Фактично, частина трафіку їхала швидкою смугою прямо в стіну.

Вони пробували змінювати крипто. Потім таймлайти. Потім обладнання. Класика. Жоден з цих кроків не допоміг, бо фаєрвол пропускав частину логіки визначення, куди належить трафік.

Виправлення було хірургічним: вставити accept‑правила для ipsec-policy=in,ipsec і ipsec-policy=out,ipsec перед fasttrack, і переконатися, що NAT‑правила мають верхній «accept якщо ipsec-policy=out,ipsec».
Пропускна здатність трохи впала. Стабільність зросла драматично. Усі прикинулися, що так було заплановано.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

Розподілена компанія мала три невеликі офіси і один хаб. Кожен офіс — інший провайдер, один офіс — на LTE як резерв.
Проблеми з VPN були очікувані; але ніхто не очікував, що їх можна швидко діагностувати.

Нудна практика: у них був стандартизований рукопис і однакова номенклатура. Peers називались по сайту, пропозиції і таймлайти ідентичні на всіх роутерах,
логи IPsec йшли в центральний syslog з достатнім рівнем дебагу, щоб бути корисними, але не перевантажувати.

Одного дня один офіс почав флапати після техобслуговування провайдера. Інженер на чергуванні не гадував. Він перевірив WAN‑логи — змін лінку не було. Переглянув IPsec‑логи — побачив нові закономірності DPD.
Запустив снифер і підтвердив вихідні UDP 4500 без вхідних відповідей. Висновок був миттєвий: проблема шляху upstream, а не конфіг MikroTik.

Вони ескалували з доказами: часові мітки, підсумки захоплення пакетів і чітке «ми шлемо, ми не отримуємо». Провайдер виправив поламане stateful‑правило на краю. VPN став стабільним.
Нікому не довелося вночі відкатувати прошивку. Нудьга перемогла.

Поширені помилки: симптом → корінь → виправлення

1) Тунель переукладається кожні кілька хвилин по годинах

• Симптом: передбачувані обриви кожні 5–30 хвилин; логи показують цикли рекейк/видалення.
• Корінь: дуже короткі таймлайти, колізії рекейка або стрибки CPU під час рекейка.
• Виправлення: збільшити IKE/ESP таймлайти, вирівняти обидві сторони, зменшити вартість PFS якщо потрібно, і явно вказати набори пропозицій.

2) «Peer not responding», але WAN виглядає нормально

• Симптом: таймаути DPD; тунель швидко відновлюється; користувачі бачать короткі збої.
• Корінь: закінчення NAT‑мапінгу або upstream фільтрація UDP 4500.
• Виправлення: увімкніть keepalive, налаштуйте DPD під реалії WAN, уникайте подвійного NAT, і доведіть втрати пакетів снифером.

3) Тунель піднятий, але деякі підмережі не працюють

• Симптом: одна VLAN дістається до віддаленого офісу; інша — ні; SAs існують.
• Корінь: невідповідність селекторів, відсутні політики або NAT транслює одну підмережу.
• Виправлення: зробіть селектори симетричними; додайте відсутні політики; додайте ipsec-policy=out,ipsec в NAT accept над masquerade.

4) Веб працює, великі копії файлів падають, RDP нестабільний

• Симптом: малі пакети проходять; великі пакети зависають; періодичні таймаути.
• Корінь: MTU/PMTUD помилка через накладення інкапсуляції і блокування ICMP fragmentation‑needed.
• Виправлення: кліпайте TCP MSS для VPN‑трафіку; дозволяйте необхідні типи ICMP; тестуйте DF‑pingами і реальними payload‑тестами.

5) Працює, поки ви не ввімкнете fasttrack — тоді «рандомні» збої

• Симптом: тунель залишається встановленим, але плоскость даних стає переривчастою, часто односторонньою.
• Корінь: fasttrack обходить обробку, потрібну для IPsec політик.
• Виправлення: додайте явні accept‑правила для IPsec перед fasttrack або вимкніть fasttrack.

6) Переговори падають лише після оновлення прошивки

• Симптом: «no proposal chosen», «auth failed» або нова поведінка навколо таймлайтів.
• Корінь: зміни дефолтів, порядок алгоритмів або вилучені застарілі шифри.
• Виправлення: закріпіть пропозиції й профілі явно; вирівняйте версії; тестуйте рекейки перед масовим розгортанням.

7) Трафік проходить лише в одному напрямку

• Симптом: Office A може дістатися B; B не може дістатися A, або навпаки.
• Корінь: асиметричні селектори, асиметрія маршрутів або відсутні accept‑правила у forward‑ланці для IPsec.
• Виправлення: забезпечте матч політик в обох напрямках; перевірте маршрути; додайте forward‑accept правила для in/out IPsec‑політик.

Жарт №2: Найшвидший спосіб «виправити» VPN — оголосити його «працює як задумано» і піти на обід — аж поки CFO не спробує надрукувати.

Чеклісти / покроковий план для стабільності

Крок 1: Стандартизувати і задокументувати контракт тунелю

• Перелічіть локальні/віддалені підмережі, включно з можливим майбутнім ростом.
• Свідомо оберіть policy‑based або route‑based.
• Визначте крипто‑набір і таймлайти; запишіть їх.
• Називайте об’єкти послідовно: peers, identities, proposals, policies.

Крок 2: Зробити контрольну площину стійкою

• Дозвольте UDP 500 і 4500 на роутер від пірена.
• Увімкніть NAT‑T, якщо не можете гарантувати відсутність NAT у шляху.
• Налаштуйте DPD так, щоб він виявляв реальні відмови, але не панікував через джиттер.
• Вирівняйте IKE і ESP таймлайти; уникайте «надто маленьких» таймлайтів.

Крок 3: Зробити плоскость даних явною

• Додайте forward‑правила для accept ipsec-policy=in,ipsec і ipsec-policy=out,ipsec.
• Додайте NAT‑виняток: chain=srcnat action=accept ipsec-policy=out,ipsec вище masquerade.
• Переконайтесь, що селектори політик точно співпадають з обох сторін.
• Віддавайте перевагу нерозперезним RFC1918 діапазонам між сайтами.

Крок 4: Вирішіть MTU/MSS до того, як користувачі знайдуть проблему

• Протестуйте PMTU за допомогою DF‑ping.
• Кліпайте TCP MSS для трафіку, що заходить у тунель (поширене значення: 1360–1400; вимірюйте, не вгадуйте).
• Дозвольте ICMP fragmentation‑needed якщо ваша політика безпеки це дозволяє.

Крок 5: Моніторте те, що має значення

• Логуйте події IPsec (не повний debug постійно) та зберігайте часові мітки.
• Графуйте CPU, помилки/дропи інтерфейсів і кількість IPsec SA з часом.
• Піднімайте алерти на часті реконфігурації, а не тільки «тунель вниз».

Крок 6: Операційна дисципліна при змінах

• Оновлюйте RouterOS в контрольованому вікні; тримайте сумісність обох кінців.
• Змінюйте по одній змінній за раз: DPD, таймлайти, пропозиції, NAT‑правила.
• Після будь‑якої зміни форсуйте рекейк і перевірте трафік для всіх підмереж.

Принцип надійності, який варто запозичити

Перефразована ідея: Джон Оустергаут стверджував, що складність — ворог надійності; простіші системи рідше падають у несподіваний спосіб.

FAQ

1) Чи використовувати IKEv2 або IKEv1 на MikroTik для site‑to‑site?

Використовуйте IKEv2, якщо тільки у вас немає застарілого peer, який вимагає IKEv1. IKEv2 загалом краще поводиться з NAT‑T і логікою рекейка.
Стабільність більше залежить від шляху мережі і дисципліни конфігурації, ніж від версії.

2) Які налаштування DPD слід використовувати, щоб уникнути флапів?

Починайте консервативно: інтервал DPD близько 10–30 секунд і максимум невдач 3–5, потім адаптуйте під поведінку WAN.
Якщо зробити його надто агресивним на джиттерному лінку — ви скажете роутеру розірвати стосунки через дрібні затримки.

3) Тунель встановлений, але трафік не проходить. Куди дивитися в першу чергу?

Перевірте NAT‑винятки і forward‑правила фаєрволу для IPsec‑політики. Потім перевірте, чи селектори/політики співпадають обома сторонами.
Після цього — перевірка маршрутів і перекриваючих підмереж.

4) Чи потрібно дозволяти ESP (протокол 50) у фаєрволі?

Якщо ви використовуєте NAT‑T (UDP 4500), ESP інкапсулюється в UDP і зазвичай достатньо UDP 500/4500.
Якщо NAT‑T вимкнено і в шляху немає NAT — тоді так, ESP потрібно дозволити.

5) Як зрозуміти, що MTU — моя проблема?

Якщо маленькі ping‑и проходять, а великі передавання зависають — підозрюйте MTU. Доведіть це DF‑pingами і відрегулюйте TCP MSS.
Також перевірте, чи не блокується ICMP fragmentation‑needed між сайтами.

6) Чи треба вмикати PFS?

Якщо у вас є запас CPU і вимоги відповідності/безпеки — увімкніть. Якщо MikroTik малий і вже завантажений,
PFS плюс короткі таймлайти можуть спричинити шквали рекейків. Безпека — це властивість системи; стабільність теж важлива.

7) Чому він флапає більше в години піку?

Години піку корелюють з навантаженням CPU, тиском у чергах і перевантаженням WAN. Якщо таймери IPsec (DPD, рекейк) затримуються, пірени оголошують відмову.
Перевіряйте /tool/profile, помилки інтерфейсів і наскільки роутер робить багато речей одночасно (NAT, firewall, черги) поруч із шифруванням.

8) Чи можна залишити fasttrack увімкненим з IPsec?

Можливо, але потрібно додати винятки, щоб IPsec‑політика трафіку не проходила через fasttrack у спосіб, що обходить обробку.
Якщо ви не можете гарантовано зрозуміти порядок правил під навантаженням — вимкніть fasttrack і інвестуйте в краще обладнання.

9) Чи добре «send-initial-contact=yes»?

Зазвичай корисно для очищення застарілих SAs на респондентові, коли ініціатор перепідключається (особливо після зміни IP).
У сценаріях з багатьма піренами або HA воно може видалити SAs, яких не хотіли чіпати. Використовуйте, коли розумієте, хто має право підключатися під тим ідентифікатором.

10) Який найпростіший спосіб зменшити падіння через рекейк?

Вирівняйте таймлайти, тримайте набір пропозицій малим і явним, і не рекейкуйте занадто часто. Потім перевірте запас CPU під час рекейка.
Рекейк має бути непомітною подією, а не тренуванням на випадок відмови.

Висновок: наступні кроки, що реально зменшують флапи

Стабільний IKEv2 між офісами — це не магія. Це ланцюг нудних істин:
WAN має бути достатньо стабільним, NAT має тримати стан, правила фаєрволу/NAT мають поважати IPsec, селектори мають співпадати, і MTU треба обробляти проактивно.
Якщо ці речі зробити правильно, крипто стає питанням політики, а не лотереєю при діагностиці.

Практичні наступні кроки:

1. Пройдьте швидкий план діагностики і класифікуйте проблему: WAN, контрольна площина чи плоскость даних.
2. Явно закріпіть пропозиції і таймлайти на обох кінцях; припиніть покладатися на дефолти.
3. Додайте й перевірте NAT‑винятки і accept‑правила для IPsec у forward; перевірте лічильники.
4. Протестуйте MTU DF‑pingами і кліпайте MSS, щоб додатки припинили «вивчати» MTU жорстким способом.
5. Заміряйте CPU під час піку і рекейка; якщо ви на межі — налаштуйте таймлайти або оновіть обладнання.
6. Зберігайте логи достатньо довго, щоб зафіксувати флапи, і тримайте імена послідовними, щоб майбутньому вам було легше розбиратися з ситуацією.

Ваша мета — не тунель, який може підключитися. Ваша мета — тунель, про який ніхто не думає. Ось так визначається production‑рівень «стабільності».