Підготовлений – значить озброєний, принаймні якщо це стосується вивчення для себе чогось нового, адже не відомо які можуть виникнути завдання з’єднання двох віддалених точок, і які підводні камені можуть перешкодити реалізувати тунель вчасно. Загалом я спробував мені сподобалося ? і вирішив викласти результат.
Використовуємо найпростішу топологію, чого достатньо для реалізації ipsec тунелю.

Налаштування мережі Fortigate:
Налаштування мережі MikroTik:
Налаштування FORTIGATE:
Переходимо до створення тунелю на Fortigate.
Даємо назву інтерфейсу і переходимо до ручного налаштування.
По факту, з боку Fortigate ми конфігуруємо сервер та ідентифікуємо клієнтів за ID, також важливо, щоб зійшлися обидві фази та загальний ключ.
Ми вказали наступні параметри:
Remote Gateway – клієнти, що підключаються (Dialup User)
Interface – наш зовнішній інтерфейс
NAT Traversal – включаємо інкапсуляцію трафіку (NAT-T)
Dead Peer Detection – увімкнення механізму виявлення простою з’єднання (DPD)
Далі вказуємо:
Метод – метод перевірки
Pre-shared Key – значення загального ключа, як приклад “5^PLDAsdf’!856d)”
Version – версія набору протоколів (IKE)
Mode – режим підключення
Accept Types – дозволений тип ID клієнта (все, один чи група)
Peer ID – значення ID клієнта
У полі Peer ID ми вказали явний ідентифікатор клієнта, саме такий ідентифікатор ми поставимо на MikroTik.
Переходимо до першої фази:
У профілі встановимо протокол шифрування, автентифікації, версію DH та час його життя (Phase 1):
Encryption – DES
Authentication – SHA1
Diffie-Hellman Group – 5
Key Lifetime – 86400
Вимикаємо механізм розширеної автентифікації (XAuth)
Друга фаза:
В данній фазі вказуємо наступні параметри:
Local Adress – оголошуємо локальну мережу, підключену до маршрутизатора
Remote Address – оголошуємо мережу, що знаходиться по ту сторону тунелю
На підставі цих двох полів формується політика, яка організовує маршрут між нашою локальною мережею та мережею, за MikroTik, тому в системі з’являється статичний маршрут, але про це трохи пізніше.
Далі вказуємо шифрування, автентифікацію та версію протоколу Діффі-Хеллмана (DH)
Відповідно:
Encryption – DES
Authentication – SHA1
Diffie-Hellman Group – 5
Шифруємо весь трафік, що потрапляє в тунель, так:
Local Port – ALL
Remote Port – ALL
Protocol – ALL
І нарешті параметри, що залишилися:
Enable Replay Detection – Функція виявлення пакетів, що повторюються.
Perfect Forward Secrecy – Функція генерації ключів DH після закінчення Key Lifetime
Key Lifetime – час життя ключа
Seconds – значення “Key Lifetime” у секундах
Докладніше про другу фазу (Phase 2)
Для безперешкодного проходження трафіку з тунелю до локальної мережі та назад необхідно створити в меню Policy & objects > IPv4 Policy кілька мережевих політик:
Настройка MikroTik
Почнемо з меню IP > IPsec :
Так виглядає підготовка першої фази: на вкладці “1 – Profiles” створюємо профіль, в якому вибирає такі самі параметри як при налаштуванні першої фази на Fortigate.
На кладці “2 – Peers” створюємо peer із зазначенням зовнішньої адреси Fortigate (vpn-server), застосовуємо раніше створений профіль та вказуємо агресивний режим підключення.
На вкладці “3 – Identities” вибираємо зі списку раніше створений peer, метод аутентифікації – pre shared key та значення цього ключа. Поля “My ID Type” та “My ID” налаштовані для ідентифікації з боку Fortigate, під час встановлення з’єднання. Інші поля, як я розумію, функціонують у разі реалізації vpn-сервера на MikroTik.
Продовжимо налаштування другої фази:
Тут також усе стандартно.
І родзинкою всього цього буде створення політики, на підставі якої маршрутизуватиметься трафік, policy-based vpn!!
Створюємо політику на вкладці “5 – Polices”, у меню “General”
для всього трафіку “Protocol – 255(all)”
вказуємо локальну мережу (Src. Address)
віддалену мережу (Dst. Address) відповідно.
Виконувати її за умовами, описаними на вкладці “Action”, тобто під час встановлення тунелю між нашими двома маршрутизаторами із застосуванням параметрів другої фази, свідомої раніше у “4 – Proposals”
Усі параметри IPsec описано на https://wiki.mikrotik.com.
Додамо кілька правил у фаєрвол: IP > Firewall > Filter rules:
Тим самим дозволивши транспорт для ipsec (esp), інкапсуляцію трафіку (4500/UDP) та керування шифруванням (500/UDP).
Та в IP > Firewall >NAT :
Дозволяємо трансляцію адрес між підмережами.
Дебаг/Мониторинг
Інструменти моніторингу стану тунелю та перегляду логів знаходяться у стандартних місцях.
На Fortigate стан тунелю:
А цей маршрут, який з’явився сам, після підняття тунелю:
Більш інформативно можемо подивитися, додавши правило логування:
Варіант реалізації викладено, цікавість перемогла лінь!
Вітаю, дякую за Ваш час і роботу. Може вирішували колись більш складну задачу побудови відмовостійкого з’єднання FortiGate та Mikrotik. Або з тунелями GRE та динамічною маршрутизацією OSPF чи SDWAN на стороні FortiGate.
В мене поки нічого путнього не виходить, але я ще той “інженер по мережам” 🙁
У варіанті з GRE та ОSPF все наче злітає, передаються маршрути і одразу відпадає GRE, маршрути зникають GRE піднімається і знову все спочатку. Напишіть будь ласка якщо мали такий досвід, дуже дякую.
Ватяємо, GRE у зв’язці зі статичною маршрутизацією в той час працює? Саме такої реалізації (Fortigate+Mikrotik+GRE+OSPF) під рукою немає, але, з урахуванням потреби ))) створимо в лабараторних умовах і мабуть коротенько про це буде пост.
Вітаю, чи вдалось комусь направити трафік в Інтернет с локальної мережі, що за Fortigate, через віддалений мікротік, що з’єднаний з Fortigate за допомогою IPSEC?
Доброго дня.
Так, дану реалізацію налаштовували. У другій фазі на стороні Fortigate, в полі “remote network” необхідно прописувати – 0.0.0.0/0. Також це потрібно зробити на стороні Мікротик. І не забути про masquerade.
Як альтернатива дана реалізація праціє за допомогою GRE over IPSec, Тоді ви на стороні Fortigate додаєте static route 0.0.0.0/0 в тунель.