Обзор IPSec в Mikrotik

IPSec (IP Security) — набор протоколов и алгоритмов для шифрования данных в IPv4 и IPv6 сетях. Звучит не сложно, но IPSec не устанавливает четких правил для шифрования трафика, вместо этого разработчики реализуют набор инструментов (протоколов и алгоритмов), используя которые администратор создает защищенный канал для данных.

Я хочу затронуть тему IPSec в RouterOS немного глубже простого HOWTO, с минимальным погружением в теорию и примерами по настройке и отладки IPSec. Это не гайд и без практики на тестовом стенде не рекомендуется приступать к настройке реальных туннелей и VPN серверов.


Преимущества и недостатки IPSec

Сильные стороны:


  • Работает на сетевом уровне модели OSI
  • Может шифровать исходный пакет целиком либо от транспортного уровня и выше
  • Присутствует механизм преодоления NAT
  • Большой набор алгоритмов шифрования и хеширования трафика, на выбор
  • IPSec — набор открытый, расширяемых стандартов
  • В случае с Mikrotik, не требует покупку дополнительных плат или лицензий

Слабые стороны:


  • Сложность
  • Различная терминология и инструменты конфигурации у различных вендеров
  • Использование сильных алгоритмов шифрования требует хорошие вычислительные мощности
  • Легко обнаруживается DPI


Протоколы в составе IPSec

ndk60mwkllka7jpnl2flzdqt8ce.png

Глобально, все протоколы, с которыми вы будите иметь дело при конфигурации, можно разделить на две группы: протоколы обмена ключами и протоколы защиты данных.

Протоколы обмена ключами (IKE)
Основная задача — аутентифицировать участников соединения и договориться о параметрах и ключах шифрования для защиты передаваемой информации.


  • IKE (Internet Key Exchange) — определен в 1998 году. Многие возможности (например преодоление NAT) были добавлены позже в виде дополнений и могут быть не реализованы у различных вендеров. Основой для согласования ключей является протокол ISAKMP.
  • IKEv2 (Internet Key Exchange version 2) — последняя редакция от 2014 года. Является развитием протокола IKE, в котором были решены некоторые проблемы, упрощен механизм согласования ключей, расширения (NAT-T, Keepalives, Mode Config) стали частью протокола.

На практике большая часть IPSec соединений реализуется с использованием IKE, в силу устаревшего оборудования, либо нежелания что-то менять у администраторов.

Протоколы защиты данных (ESP, AH)
Основная задача — защищать данные пользователя.


  • ESP (Encapsulating Security Payload) — шифрует и частично аутентифицирует передаваемые данные
  • AH (Authentication Header) — аутентифицирует пакет целиком (за исключением изменяемых полей), не шифрует данные, но позволяет убедиться, что пакет не был изменен при передачи по сети


Порядок установки IPSec соединения

lurvpsvrdub2tcgkmpx8ut5ep58.png

Участников IPSec соединения принято называть пирами (peers), что показывает на их равнозначность в устанавливаемом соединении. Возможна конфигурация близкая к клиент-серверной, но при построении постоянных IPSec туннелей любой из пиров может быть инициализатором.


  1. Один из пиров инициализирует соединение IPSec
  2. Происходит обмен ключевой информацией, аутентификация пиров, согласование параметров подключения
  3. На основе полученной ключевой информации формируется вспомогательный шифрованный туннель
  4. Используя шифрованный туннель пиры определяют параметры шифрования данных и обмениваются информацией для генерации ключей
  5. Результатом работы предыдущей фазы является набор правил и ключи для защиты данных (SA)
  6. Периодически пиры производят обновление ключей шифрования

Одним из ключевых понятий в IPSec является SA (Security Association) — это согласованный пирами набор алгоритмов шифрования и хеширования информации, а также ключи шифрования.

Иногда можно встретить разделение на:


  • ISAKMP SA — параметры и ключи относящиеся к вспомогательному туннелю
  • Data SA (или просто SA) — параметры и ключи относящиеся к шифрованию трафика


Порядок работы протоколов согласования ключей

Протокол IKE может работать в двух режимах: основном (main) и агрессивном (aggressive), протокол IKEv2 содержит один режим.


IKE Main

zwjbyvrpmup5t7nfgaol329rudi.png

Первая фаза состоит из шести пакетов:
1–2: Согласование параметров шифрования вспомогательного туннеля и различных опции IPSec
3–4: Обмен информацией для генерации секретного ключа
5–6: Аутентификация пиров используя вспомогательный шифрованный канал

Вторая фаза состоит из трех пакетов:
1–3: Используя шифрованный вспомогательный канал. Согласование параметров защиты трафика, обмен информацией для генерации секретного ключа


IKE Aggressive

xuwzqu4qle5lxlcvb-hnvuhqehg.png

Певая фаза состоит из трех пакетов:
1: Отправка предложения для установки вспомогательного шифрованного канала и информации для генерации секретного ключа
2: Ответ на предложение, информация для генерации секретного ключа, данные для аутентификации
3: Данные для аутентификации

Вторая фаза состоит из трех пакетов:
1–3: Используя шифрованный вспомогательный канал. Согласование параметров защиты трафика, обмен информацией для генерации секретного ключа

В агрессивном режиме инициатор отправляет только один набор параметров в предложении. Обмен информацией для аутентификации пиров происходит до установки защищенного вспомогательного туннеля. Агрессивный режим согласуется быстрее, но менее безопасен.


IKEv2

evmqnimq5_sdeybuz63x3ddssbu.png

В IKEv2 фазы получили имена: IKE_SA_INIT и IKE_AUTH. Но если ниже по тексту я говорю про Phase1 и Phase2, то это относится и к фазам IKEv2.

Каждая фаза IKEv2 состоит из двух пакетов:
IKE_SA_INIT: Согласование параметров шифрования вспомогательного туннеля, обмен информацией для генерации секретного ключа

IKE_AUTH: используя шифрованный вспомогательный канал. Аутентификация пиров, согласование параметров защиты трафика, обмен информацией для генерации секретного ключа


Security Assotiations Database (SAD)

Результатом работы IKE (и IKEv2) являются Security Assotiations (SA), определяющие параметры защиты трафика и ключи шифрования. Каждый SA является однонаправленным и соединение IPSec содержит пару SA. Все SA хранятся в базе SAD и доступны администратору для просмотра и сброса.


Инкапсуляция данных

3z3kaaj2rwmnx59apvueigp3lno.png

IPSec предоставляет два варианта инкапсуляции данных:


  • Транспортный режим — защищается только полезную нагрузку пакета, оставляя оригинальный заголовок. Для построения туннелей транспортный режим обычно используется в связке с ipip или gre, полезная нагрузка которых уже содержит весь исходный пакет.
  • Туннельный режим — полностью инкапсулирует исходный пакет в новый (по аналогии с gre или ipip). Но для туннельного ipsec не создается явного интерфейса в системе, это может быть проблемой если используется динамическая или сложная статическая маршрутизация.


Security Policy Database (SPD)

База правил, определяющих какой трафик необходимо подвергать шифрованию, протокол защиты данных, тип инкапсуляции и ряд других параметров.
Положение проверки пакета SPD можно отобразить на схеме Packet Flow.

nhjorm-je866yymx0_cxwdnyop8.png


Преодоление NAT

IPSec использует протоколы сетевого уровня для передачи данных, которые не может обработать NAT. Для решения проблемы используется протокол NAT-T (расширение в IKE и часть IKEv2). Суть NAT-T в дополнительной инкапсуляции пакетов IPSec в UDP пакеты, которые обрабатывает NAT.


IPSec в Mikrotik

IPSec доступен бесплатно на любом устройстве под управлением RouterOS с установленным пакетом Security.


Апапратное шифрование

Для разгрузки CPU в некоторые модели маршрутизаторов MikroTik добавляют аппаратное ускорение шифрования, полный список можно найти на wiki.
Наиболее бюджетные варианты: RB750Gr3, RB3011, HAP AC^2.

Своими силами проверял скорость IPSec между двумя RB1100AHx2 и между двумя RB750Gr3.

Для достижения максимального результата на RB1100AHx2 необходимо:


  • Использовать 11 порт, напрямую подключенный к CPU и настроить одно ядро CPU для обработки трафика 11 порта
  • Использовать only-hardware-queues на интерфейсах, отключить RPS
  • Задействовать Layer3 FastPath (около 800mb/sec), либо исключить IPSec трафик из conntrack (около 700mb/sec)
    Без описанных манипуляций на самом медленном порту (ether13) удается получить ~170Mb/sec, на обычном ~400Mb/sec.

На RB750Gr3 без оптимизаций около 200Mb/sec.

Маршрутизаторы на одноядерных Qualcomm показывают результат 10–40mb/sec в зависимости от модели, оптимизаций и загруженности другими процессами.

Рекомендую ознакомиться с презентацией от сотрудника mikrotik, там затронуты темы оптимизации настроек для уменьшения нагрузки на CPU и увеличения скорости, которые я не стал добавлять в текст.


Различия 6.42.X и 6.43.X

В зависимости от используемой версии RouterOS меню конфигурации IPSec будет различаться.

6qpz5cgthate04bihl8gq2zr9t8.png

ngughirhx6nwd1v8mjaa9omfb7g.png

kvow3-bmivzfr_tf6bqnywr5wu8.png

В testing версии уже есть новые изменения, так что читайте Release Notes перед обновлением.

rirdgucrebbf1ucxjqbj65gzf-s.png


Конфигурация IPSec

r6lfj5hlclkbx9qmph0owsqf_ak.png
Меню [IP]→[IPSec] не такое страшное, как кажется на первый взгляд. Из схемы видно, что основными пунктами конфигурации являются: Peers и Profiles.
Вкладки Remote Peers и Installed SAs являются информационными.


Peers и Peers Profiles

Конфигурация пиров IPSec для установки IKE соединения и создания вспомогательного защищенного туннеля.

image

Настройка удаленных пиров IPSec

pq9dcvyqrf64pdklohgf1eapoze.png


Примечания
  • Начиная с 6.43 RouterOS ругается при использовании PSK без дополнительной аутентификации. Если не хочется дополнительно настраивать ключи, сертификаты или xAuth можно перейти на IKEv2 или игнорировать предупреждение.
  • В качестве пиров можно указывать конкретные IP либо подсети (актуально для Client-Server VPN)
  • При наличии конфликтующих правил, для соединения с пиром будет использовано правило с более точной подсетью (по аналогии с routes)
  • Аутентификация xAuth и rsa key не работает в IKEv2
  • Для IKEv2 Mikrotik сделали свою реализацию xAuth не совместимую с другими платформами
  • Passive режим обычно используется для создания Client-Server VPN (L2TP/IPsec или IKEv2 mode config), но может быть полезен при подключении большого числа Site-to-Site туннелей к одной точке, для снижения паразитного трафика.
  • Если планируете использовать xAuth, то «сервер» должен быть passive. Пользователи для сервера создаются в [IPSec]→[Users]
  • При использовании Generate policy выбирайте режим port-strict

Настройка профилей (Proposalas) для согласования Phase 1

image

_vx3ff1ogwsxjggebdjqazfqhve.png


Примечания
  • Дополнительные опции для IKE стали частью IKEv2, настройки игнорируются
  • Соотношение групп DH с их номерами (номера групп используются у других вендеров)
  • При отправке предложений (Proposalas) система сортирует пары алгоритм+группа dh от более стойких к менее стойким
    7ih8fjegurxodmq-daxuwxfhpii.png


Policies и Policy Proposalas

Политики проверяют проходящие пакеты на соответствие условиям и применяют указанные действия. Если вернетесь к Packet flow, то блоки с IPSec Policy и есть сверка с политиками. В действиях задается: протокол защиты IPSec (ESP или AH), предложения для согласования SA, режим инкапсуляции.
image

Пакет проходит политики поочередно, пока не совпадет с условиями одной из них.

Настройка политик
ywcpnjdyjonrxpnfel79irfov4g.png


Примчания
  • Обычно не требуется указывать конкретный Src. и Dst. Port, но в целом возможность шифровать трафик отдельного приложения интересна
  • В списке Protocols представлены не все протоколы ip (например нет gre), можно указать номер нужного протокола вручную.
  • Шаблоны не являются политиками! Они используются, если в конфигурации пира установлено generate-policy
  • Что делать, если определенные SA для политике не были найдены. Раньше с L2TP/IPSec была проблема, когда несколько клиентов из-за одного NAT не могли подключиться (при использовании IKE), данный баг решается (при условии, что эти клиенты не windows) если установить level=unique. Иначе переходите на IKEv2
  • При настройке политик используйте [Safe mode], одно неловкое движение и вы рискуете потерять доступ к роутеру по Level3

Настройка предложений (Proposalas) для согласования SA
mhyfcd2-2nsxbouuxhgbecj3kyu.png

0nxktwxmxyu2quyanfw-rco-yqa.png


Groups

Используются для связи шаблонов политик и пиров.

image

В одной из старых версий RouterOS был баг с нерабочей группой default.


Mode Config

Отправка и получение параметров IP без использования дополнительных протоколов. Позволяет создавать самодостаточный Client-to-Server VPN только средствам IPSec.

srs2dl4tcpixxiwi2mrletlguva.png

osr2ggrnm_0-vqtoukxb5hnzfjs.png


Keys и Users

Используются для расширенной аутентификации пиров.
Keys
Ключи RSA: генерация, импорт, экспорт. Не поддерживаются в IKEv2.

ec7zj4doiqkdgwe4soh7lrk21f8.png

Users
База данных пользователей xAuth, для «сервера». Клиент указывает настройки xAuth в конфигурации пира. Возможно пересылать аутентификацию xAuth на RADIUS сервер.

piwlvq80v1cnndmhyjg91jzrqle.png


Remote Peers

Список всех пиров устанавливающих и установивших вспомогательный туннель (Phase 1). Можно удалять пиров для обновления ключей вспомогательного туннеля.

image

image


Installed SAs

база данных SAD или список всех согласованных SA. Можно посмотреть используемые алгоритмы защиты данных и ключи.

image

image

Флаг Hardware AEAD указывает на использование аппаратного шифрования.

image

Администратор может сбросить SA, но только одновременно все одного типа (esp или ah).


IPSec и Firewall

В Firewall можно проверить соответствует трафик входящей или исходящей IPSec политики или нет. Очевидное применение — L2TP/IPSec, можно запретить установку L2TP соединений если трафик не был предварительно зашифрован.

xt06swif3vlsv_vjcyywb1lepf0.png

Протоколы и порты, используемые в IPSec


  • IKE — UDP:500
  • IKEv2 — UDP:4500
  • NAT-T — UDP:4500
  • ESP — ipsec-esp (50)
  • AH — ipsec-ah (51)


IPSec и Endpoinds

А теперь о наболевшем…
На wiki mikrotik есть таблицы с алгоритмами хеширования и шифрования для: Windows, iOS, OS-X.

Про встроенный в android vpn клиент я информации не нашел, но в целом он работает с proposalas от windows. Поддержки IKEv2 в Android нет, необходимо использовать StrongSwan.


Примеры конфигурации

Схема и базовая конфигурация для примеров с Site-to-Site туннелями:

bna7xud0pazv4ipia2k0083wqom.png

#Mikrotik1
/ip address
add address=10.10.10.10/24 interface=ether1 network=10.10.10.0
add address=192.168.100.1/24 interface=ether2 network=192.168.100.0
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
/ip route
add distance=1 gateway=10.10.10.1 dst-address=0.0.0.0/0

#Mikrotik2
/ip address
add address=10.20.20.20/24 interface=ether1 network=10.20.20.0
add address=192.168.200.1/24 interface=ether2 network=192.168.200.0
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
/ip route
add distance=1 gateway=10.20.20.1 dst-address=0.0.0.0/0


IPSec в туннельно режиме

wycgadjksxuyftckhoctoxciub4.png

Пошаговая конфигурация:


  1. Создаем Proposals для IKE Phase1
  2. Создаем пира. Указываем адрес, proposalas, режим обмена, ключ PSK. Я выбрал IKEv2, можно использовать main/agressive по желанию
  3. Создаем Proposals для SA
  4. Указываем подсети между которыми создаем туннель
  5. Указываем адреса SA, туннельный режим и proposalas для шифрования трафика
  6. Редактируем правило NAT


Mikrotik1

c2tgatfqb3bgw5qer0u6lvi_jt0.png

Консольный вариант:

#1
/ip ipsec peer profile
add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=ipsec-tunnel-ike nat-traversal=no

#2
/ip ipsec peer
add address=10.20.20.20/32 exchange-mode=ike2 profile=ipsec-tunnel-ike secret=test-ipsec

#3
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=ipsec-tunnel-sa

#4-5
/ip ipsec policy
add dst-address=192.168.200.0/24 proposal=ipsec-tunnel-sa sa-dst-address=10.20.20.20 sa-src-address=10.10.10.10 src-address=192.168.100.0/24 tunnel=yes

#6
/ip firewall nat
set 0 ipsec-policy=out,none


Mikrotik2

je5ygqbnhfjklyqxu8pg1kf2saq.png

Консольный вариант:

#1
/ip ipsec peer profile
add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=ipsec-tunnel-ike nat-traversal=no

#2
/ip ipsec peer
add address=10.10.10.10/32 exchange-mode=ike2 profile=ipsec-tunnel-ike secret=test-ipsec

#3
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=tets-ipsec-sa

#4-5
/ip ipsec policy
add dst-address=192.168.100.0/24 proposal=tets-ipsec-sa sa-dst-address=10.10.10.10 sa-src-address=10.20.20.20 src-address=192.168.200.0/24 tunnel=yes

#6
/ip firewall nat
set 0 ipsec-policy=out,none


Причем тут NAT?

Для работы в туннельном режиме необходим фейковый маршрут до удаленной подсети, либо маршрут по умолчанию, иначе пакеты не пройдут дальше Routing decision. С первым вариантом проблем обычно нет, а вот с дефолтным маршрутом и Source NAT (первое и второе присутствует на подавляющем большинстве домашних и офисных маршрутизаторов) будут проблемы.

Вспоминаем Packet Flow. Пакеты проходят Source NAT раньше чем политики IPSec, правило с masquerade ничего не знает о том что трафик предназначен для отправки в «эфимерный» туннель и будет транслировать заголовки пакетов подлежащих отправки в IPSec, когда пакет с измененным заголовком попадет на проверку в Policies адрес источкина в заголовке не будет подходить под правило и пакет улетит на default route, который увидев адрес назначения из приватной сети вероятнее всего его отбросит.

Есть несколько решений проблемы:


  • Использование фейкового маршрута
  • Использование дополнительного accept правила перед SourceNAT
  • Подвергать src-nat только те пакеты, для которых нет политик IPSec (в примере)
  • Исключать трафик из connection tracking средствами RAW

Проверка установленного соединения
image


  1. Видим соседа в Remote Peers
  2. Видим установленные SA (счетчики трафика не будут меняться, пока вы его не пустите)
  3. В политике статус Established и флаг (A)ctive


IPIP/IPSec

2bhy1d1tnwd57iyppymvb8dbkww.png

Предварительная настройка IPIP туннеля:

#Mikrotik1
#Настройка интерфейса ipip
/interface ipip
add allow-fast-path=no clamp-tcp-mss=no name=ipip-vpn remote-address=10.20.20.20
#Установка ip адреса на ipip интерфейс
/ip address
add address=10.30.30.1/30 interface=ipip-vpn
#Статический маршрут до удаленной подсети
/ip route
add distance=1 dst-address=192.168.200.0/24 gateway=10.30.30.2

#Mikrotik2
#Все аналогично, меняются только адреса и подсети
/interface ipip
add allow-fast-path=no clamp-tcp-mss=no name=ipip-vpn remote-address=10.10.10.10
/ip address
add address=10.30.30.2/30 interface=ipip-vpn
/ip route
add distance=1 dst-address=192.168.100.0/24 gateway=10.30.30.1

Пошаговая конфигурация IPSec:


  1. Создаем Proposals для IKE Phase1
  2. Создаем пира. Указываем адрес, proposalas, режим обмена, ключ PSK
  3. Создаем Proposals для SA
  4. Указываем подсети между которыми создаем туннель
  5. Указываем адреса SA, тип трафика который будем шифровать и proposalas


Mikrotik1

c2tgatfqb3bgw5qer0u6lvi_jt0.png

Консольный вариант:

#1
/ip ipsec peer profile
add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=ipsec-tunnel-ike nat-traversal=no

#2
/ip ipsec peer
add address=10.20.20.20/32 exchange-mode=ike2 profile=ipsec-tunnel-ike secret=test-ipsec

#3
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=ipsec-tunnel-sa

#4-5
/ip ipsec policy
add dst-address=10.20.20.20/32 proposal=ipsec-tunnel-sa protocol=ipencap src-address=10.10.10.10/32 sa-dst-address=10.10.10.10 sa-src-address=10.20.20.20


Mikrotik2

je5ygqbnhfjklyqxu8pg1kf2saq.png

#1
/ip ipsec peer profile
add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=ipsec-tunnel-ike nat-traversal=no

#2
/ip ipsec peer
add address=10.10.10.10/32 exchange-mode=ike2 profile=ipsec-tunnel-ike secret=test-ipsec

#3
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=tets-ipsec-sa

#4-5
/ip ipsec policy
add dst-address=10.10.10.10/32 proposal=tets-ipsec-sa protocol=ipencap src-address=10.20.20.20/32 sa-dst-address=10.10.10.10 sa-src-address=10.20.20.20

Для невнимательных, реальная разница конфигурации туннельного и транспортного режима в IPSec Policies:
image

Проверка соединения аналогична туннельному режиму.


L2TP/IPSec

Предыдущие примеры хорошо подходят для создания постоянных VPN между двумя пирами, со статическими внешними IP адресами.

Если адрес одного из пиров динамический (и обычно находится за NAT’ом), необходимо использовать другую Client-to-Server VPN.
image

Предварительная конфигурация L2TP:

#Создание пула адресов для клиентов
/ip pool
add name=pool-l2tp ranges=192.168.77.10-192.168.77.20
#Создание профиля для клиентов
/ppp profile
add change-tcp-mss=yes local-address=192.168.77.1 name=l2tp-ipsec only-one=yes remote-address=pool-l2tp use-compression=no use-encryption=no use-mpls=no use-upnp=no
#Создание учетных записей
/ppp secret
add name=user1 password=test1 profile=l2tp-ipsec service=l2tp
add name=user2 password=test2 profile=l2tp-ipsec service=l2tp
add name=user3 password=test3 profile=l2tp-ipsec service=l2tp
#Включение сервера L2TP (без автонастройки ipsec)
/interface l2tp-server server
set authentication=chap,mschap2 default-profile=l2tp-ipsec enabled=yes


Почему я игнорирую автонастройку IPSec

В конфигурации ipip, gre, eoip, l2tp присутствует автонастройка ipsec соединения, по сути система создает динамические правила для Peers и Policies за вас, но во-первых — мы не ищем легких путей, во-вторых при обновлении с 6.42 на 6.43 автоматически созданные туннели ломались и не факт, что этого не повторится.

Пошаговая конфигурация IPSec:


  1. Создаем новую группу (можно использовать default)
  2. Создаем Proposals для IKE Phase1
  3. Создаем пира, точнее подсеть. Ругается на PSK ключ, но если мы имеем дело в windows в качестве клиента, то у нас на выбор: Сертификаты или PSK.
  4. Устанавливаем passive=yes и send-init-contact=no, в generate-policy=port-strict (принимать порт от клиента)
  5. Создаем Proposals для SA
  6. Создаем шаблон для генерации политик
  7. Указываем proposal для SA


Конфигурация Mikrotik

image
На скриншоте ошибка — указывать dst. port и src. port не нужно

Консольный вариант:

#1
/ip ipsec policy group
add name=l2tp-ipsec

#2
/ip ipsec peer profile
add dh-group=modp1024 enc-algorithm=aes-256 hash-algorithm=sha256 name=l2tp-ipsec-ike

#3-4
/ip ipsec peer
add address=0.0.0.0/0 generate-policy=port-strict passive=yes policy-template-group=l2tp-ipsec profile=l2tp-ipsec-ike secret=secret-ipsec-pass send-initial-contact=no

#5
/ip ipsec proposal
add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-128-cbc name=l2tp-ipsec-sa pfs-group=none

#6-7
/ip ipsec policy
add dst-address=0.0.0.0/0 group=l2tp-ipsec proposal=l2tp-ipsec-sa protocol=udp src-address=0.0.0.0/0 template=yes

Конфигурация firewall для создания L2TP подключений только после IPSec

/ip firewall filter
#Разрешаем IKE, NAT-T и ipsec-esp
add chain=input protocol=17 dst-port=500,4500 action=accept
add chain=input protocol=50 action=accept

#Разрешаем L2TP, только если есть политика ipsec для данного трафика
add chain=input protocol=17 dst-port=1701 ipsec-policy=in,ipsec action=accept
add chain=input protocol=17 dst-port=1701 action-drop


IKEv2 VPN

Вариант с L2TP является популярным, но благодаря mode config можно настроить VPN сервер используя только IPSec. Это перспективный тип VPN, но пока редко используемый, поэтому помимо конфигурации серверной части, я приведу пример настройки клиента strongSwan на android.

image

Конечно, не все так радужно. Большинство «пользовательских» ОС (в частности Windows и Android) согласны работать с таким VPN только при условии аутентификации по сертификатам или EAP.

Сертификаты — это мое слабое место, если кто в курсе как правильно сгенерировать самоподписные сертификат который windows импортирует и будет использовать в соединении — пишите в комментарии.

Предварительная генерация сертификатов:

#Root CA и сапомодпись
/certificate add name=ca common-name="IKEv2 CA" days-valid=6928
/certificate sign ca ca-crl-host=

#Сертификат для сервера vpn
/certificate add common-name= subject-alt-name=IP: key-usage=tls-server name=vpn days-valid=6928

#Подпись серверного сертификата
/certificate sign vpn ca=ca

#Сертификат для клиента
#Клиенты с одним сертификатам не смогут работать одновременно, поэтому генерируйте по одному для каждого
#Для отмены доступа необходимо сделать Revoke клиентского сертификата
/certificate add common-name=client key-usage=tls-client name=client days-valid=6928

#Подпись клиентского сертификата
/certificate sign client ca=ca

Пошаговая конфигурация IKEv2 VPN:


  1. Создаем пул адресов для раздачи клиентам
  2. Создаем профиль mode config для раздачи параметров IP клиентам
  3. Создаем группы для связи Peers и шаблонов policies
  4. Создаем Proposalas для IKE Phase1
  5. Создаем профиль для подключения пиров. Аутентификация через сертификаты, протокол IKEv2, пассивный режим
  6. Указываем профиль mode config, группу из 3 шага и включаем генерацию политик
  7. Создаем Proposalas для SA
  8. Создаем шаблон для генерации политик
  9. Указываем Proposalas для SA


Настройка Mikrotik

image

#1
/ip pool
add name=pool-ike ranges=192.168.77.10-192.168.77.20

#2
/ip ipsec mode-config
add address-pool=pool-ike address-prefix-length=32 name=ikev2-vpn static-dns=77.88.8.8 system-dns=no

#3
/ip ipsec policy group
add name=ikev2-vpn

#4
/ip ipsec peer profile
add enc-algorithm=aes-256,aes-128 hash-algorithm=sha256 name=ikev2-vpn

#5-6
/ip ipsec peer
add address=0.0.0.0/0 auth-method=rsa-signature certificate=vpn exchange-mode=ike2 generate-policy=port-strict mode-config=ikev2-vpn passive=yes policy-template-group=ikev2-vpn profile=ikev2-vpn send-initial-contact=no

#7
/ip ipsec proposal
add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-128-cbc name=ikev2-vpn

#8-9
/ip ipsec policy
add dst-address=0.0.0.0/0 group=ikev2-vpn proposal=ikev2-vpn src-address= 0.0.0.0/0 template=yes


Конфигурация strongSwan на android.

Предварительно необходимо перенести client и ca сертификаты на телефон.
https://habrastorage.org/webt/tp/pk/ad/tppkadaifd1k7xi6hf3jxgg7vcs.png

Для глазастых: Крестик около wi-fi стоит т.к. большая часть системных приложений заблокирована средствами AFWall+.

Если соединение прошло успешно появятся: динамическая политика, запись в remote Peers и пара SA.

image

image

image

У RouterOS x86 demo лицензии нет ограничений на число IPSec туннелей, включая IKEv2 VPN. Можно развернуть RouterOS x86 demo (не путайте с RouterOS CHR free, там все грустно) на VPS и получить личный VPN сервер с минимальным напрягом по администрированию, без покупки лицензии на RouterOS или RouterOS CHR.


Пара слов про анализ логов IPSec

Логи в Mikrotik — отдельная история, да иногда они достаточно подробные для анализа проблемы, но отсутствие банальных возможностей: очистить, скопировать, найти вынуждает устанавливаеть отдельный syslog сервер.

Что касается IPSec, вот вариант быстрого анализа логов (оставляем только нужное на отдельной вкладке):

image

/system logging action
add memory-lines=100000 name=ipsec target=memory
/system logging
add action=ipsec topics=ipsec,error
add action=ipsec topics=ipsec,debug,!packet
add action=ipsec topics=ipsec,info

И пара примеров типичных проблем с конфигурацией IPSec:


Проблема согласования Proposalas на Phase1

image


  1. Читаем сообщение об ошибке. Проблема при согласовании Proposalal на первой фазе.
  2. Смотрим выше, роутер сам подсказывает что прислал пир, а что настроено локально


Проблема согласования proposalas IKE_SA_INIT

В логах вы увидите примерно следующее:

8id9ghqgdgxsjjsfhn3zcn5_vtq.png

Анализируем трафик

В запросе можно посмотреть proposalas от пира:

pwu2ibw3dyxswemrr74wcbphcoy.png

В ответе видим, что не найдено подходящих proposalas:

q2lbqkcr8qvtd1hgia4fj0hrb44.png


Проблема согласования Proposalas для SA

2yyg7ma7ko4lce5vsyef4nmojdi.png
Роутер подсказывает о ошибке proposalas на phase2 и показыает что настроено локально, а что удаленно.


Проблема согласования Proposalas IKE_AUTH

bnpkvnfazxyqmpbvdg78e26mfgy.png
Видим, что произошло соединение и аутентификация пиров, но дальше ошибка proposalas. В debug подробностей не увидите, в wireshark тоже (трафик IKE_AUTH зашифрован).


Ошибка аутентификации PSK

Для IKE:

cpwmb55qp8qyjmba_xijboxmiwa.png

Для IKEv2:
ksfnk0qdgmgizzusfsyrlwxvcfs.png


Неправильный режим IKE

image
Видим, что Phase1 рвется по таймауту, хотя пакеты между пирами ходят. Но размер входящего пакета значительно больше, если проанализировать через wireshark, то увидим, что удаленный пир использует aggressive mode.

3gkeiidaj8m-fs0ky7ucxqjxx6k.png
Видим, что от нас пакеты отправляются на UDP:500, а приходят на UDP:4500 причем довольно крупные. Тут у удаленного пира стоит режим IKEv2.

И напоследок почитайте раздел troubleshooting из wiki. И весь материал про IPSec желателен для ознакомления, я описал только базовый набор инструментов и настроек.

© Habrahabr.ru