Как настроить туннель на mikrotik

Материал из MikroTik Wiki

В статье разбирается настройка IPIP/IPSec-туннеля на оборудовании MikroTik с целью объединения двух сетей (site-to-site VPN). Рассматривается метод экспресс-настройки с аутентификацией с помощью пароля. После создания VPN-канала между сетями будет настроена маршрутизация и выполнена проверка работоспособности. Также будут разобраны типичные проблемы, которые могут возникнуть в процессе настройки и проверки.

Содержание

Введение
Полезные материалы по MikroTik
Схема сети
Настройка
Настройка второго маршрутизатора
На первом маршрутизаторе
На втором маршрутизаторе
Проверка
Через графический интерфейс
IPsec (аутентификация с помощью пароля)
Зачем все это
Исходные данные
Конфигурация
Mikrotik (Winbox)
Cisco FTD (Firepower Management Center)
Конфигурация StrongSwan
Импорт сертификатов и настройка IPSec MikroTik
Настройка маршрутизации трафика и списка ресурсов
Заключение
IPsec Tunnel
Настройка фазы 1
Настройка фазы 2
Настройка пира
Настройка идентификации
Настройка политики
Настройка NAT IPsec Policy
Настройка VPN средствами IPsec Mikrotik
Принципы работы протокола IPsec и базовые термины
Создание постоянного VPN IPsec
Обход NAT и Fasttrack
Настройка IPsec на роутере офиса №1
Конфигурация IPsec для роутера офиса №2
Создание IPSec VPN туннеля между двумя MikroTik

Введение

IP in IP — это протокол IP-туннелирования, который инкапсулирует один IP-пакет в другой IP-пакет. Инкапсуляция одного IP пакета в другой IP пакет, это добавление внешнего заголовка с SourceIP — точкой входа в туннель, и Destination — точкой выхода из туннеля. При этом внутренний пакет не был изменен (кроме поля TTL, которое уменьшилось). Поля Don’t Fragment и The Type of Service должны быть скопированы в внешний пакет. Если размер пакета больше чем Path MTU, пакет фрагментируется в инкапсуляторе, это должно быть во внешнем заголовке. Декапсулятор должен будет собрать пакет. Многие маршрутизатора, включая Cisco и Linux-based, поддерживают этот протокол.

Полезные материалы по MikroTik

На Telegram-канале Mikrotik сэнсей можно получить доступ к закрытой информации от официального тренера MikroTik. В апреле и мае 2023 будут разбираться темы Wi-Fi и QoS. Подписывайтесь

Схема сети

В головном офисе установлен маршрутизатор GW1. В филиале установлен маршрутизатор GW2.

Настройка

Первым делом надо создать IPIP-туннель. Маршрутизатор добавить динамический IPsec peer с предназначенным ключом безопасности и политиков с параметрами поумолчанию (по умолчанию phase2 использует sha1/aes128cbc).

/interface ipipadd name=filial1 keepalive=10s,10 local-address=10.1.100.1 remote-address=10.1.200.1 allow-fast-path=no ipsec-secret=ipsec-password

/ip addressadd address=172.16.30.1/30 interface=filial1

Настройка второго маршрутизатора

Создадим IPIP-туннель. Маршрутизатор добавить динамический IPsec peer с предназначенным ключом безопасности и политиков с параметрами поумолчанию (по умолчанию phase2 использует sha1/aes128cbc).

/interface ipipadd name=HQ keepalive=10s,10 local-address=10.1.200.1 remote-address=10.1.100.1 allow-fast-path=no ipsec-secret=ipsec-password

/ip addressadd address=172.16.30.2/30 interface=HQ

Если на предыдущих шагах все было сделано верно, то VPN-соединение между двумя офисами было установлено, но для того, что бы обе сети могли обмениваться информацией друг с другом они должны знать друг о друге, т. е. между ними должна быть настроена маршрутизация. Для этого надо выполнить следующие шаги:

На первом маршрутизаторе

/ip routeadd comment=»route to filial1 through VPN» dst-address=192.168.25.0/24 gateway=172.16.30.2 pref-src=192.168.15.1

На втором маршрутизаторе

Через консоль/ip route add comment=»route to HQ through VPN» dst-address=192.168.15.0/24 gateway=172.16.30.1 pref-src=192.168.25.1

HQ — это аббревиатура от headquarter, что в переводе означает головной офис.

Параметр Pref. Source (pref-src) не является обязательным. Он становится нужен, если количество филиалов будет более одного. Без этого параметра не будут проходить ping’и с маршрутизатора одного филиала до хостов и внутреннего интерфейса маршрутизатора другого филиала. Не будут проходить ping’и именно с маршрутизаторов, т. е. между хостами двух филиалов связь будет.

Проверка

Проверка состоит из двух частей:

Надо убедиться, что между двумя маршрутизаторами MikroTik установлено VPN-соединение. Это описано ниже.
Если VPN-соединение установлено успешно, то далее надо проверить есть ли связь между хостами в двух сетях. Для этого достаточно запустить ping с любого компьютера в сети на любой компьютер другой сети.

При проверке работоспособности IPIP-туннеля надо учитывать параметр keepalive. Если он отсутствует, то IPIP-туннель всегда будет отображаться в рабочем состоянии даже, если это не так. Если параметр стоит, как 10 секунд + 10 попыток, то это значит, что маршрутизатор сделает 10 попыток по 10 секунд каждая (итого 100 секунд) и только по истечении этого периода интерфейс будет отображаться как нерабочий. Т. е. теоретически возможна ситуация, когда интерфейс только-только перестал работать, но время по keepalive еще не вышло, и вы в этот промежуток времени проверите состояние туннеля, которое будет отображаться, как рабочее.

Через графический интерфейс

Если подключение установлено, то статус подключения должен отображаться с буквой «R». Что значит running, т. е. запущено.

На обоих маршрутизаторах выполнить команду /interface ipip print
Если соединение установлено успешно, то статус подключения, так же, как и через графический интерфейс, должен отображаться с буквой «R».

Не мешает ли файервол. Для уверенности лучше временно отключить все правила файерволов на обоих маршрутизаторах.
Совпадают ли имя пользователя и пароль на обоих маршрутизаторах.
На VPN-клиенте указан правильный адрес VPN-сервера к которому должно происходить подключение.

Правильно ли сделаны настройки маршрутизации на обоих маршрутизаторах не зависимо от того из какой сети в какую будет идти пинг.
На брэндмауэре компьютера, который будет пинговаться, сделаны необходимые разрешения для протокола ICMP. Для уверенности можно отключить встроенный брэндмауэр и выгрузить антивирус.

IPsec (аутентификация с помощью пароля)

В статье разбирается настройка IPSec-туннеля с аутентификацией с помощью пароля на оборудовании MikroTik с целью объединения двух сетей (site-to-site VPN). После создания VPN-канала между сетями будет настроена маршрутизация и выполнена проверка работоспособности. Также будут разобраны типичные проблемы, которые могут возникнуть в процессе настройки и проверки.

В головном офисе установлен маршрутизатор GW1. В филиале установлен маршрутизатор GW2. Маршрутизатор в филиале будет инициатором установления защищенного соединения. Маршрутизатор в головном офисе будет ожидать, когда инициатор запросит установление соединения.

Настройка IPsec-пира. На первом этапе надо указать адрес пира (маршрутизатора с которым будет устанавливаться соединение) и ключ (secret) с помощью, которого будет проходить авторизация. В качестве алгоритма шифрования мы выбрали aes-128. Конечно можно использовать и более длинные ключи, но это не имеет практического смысла, т. к. даже для подбора такого ключа требуется очень-очень много лет. Поэтому мы считаем, что более длинные ключи нужны либо в маркетинговых целях либо, если вы очень заморочены на глобальной слежке правительства.

Настройка политики IPsec. Следующим шагом надо настроить политику IPsec. Политика описывает в каких случаях должно использоваться шифрование. Т. е., если пакет совпадает с правилом описанным в политике, то выполняется заданное действие. В нашем случае это шифрование. Если пакет не совпадает с правилом, то он идет дальше без обработки политикой.

Если правило обхода NAT было создано после того, как было установлено защищенное соединение, то оно не заработает. Для того, что бы оно начало работать надо либо удалить все соединения на вкладке «Connections» у файервола либо перезагрузить маршрутизатор.

И с помощью захвата и перетаскивания мышью перетянем правило так, что бы оно находилось выше правила «masquerade».

/ip ipsec peeradd address=10.1.200.1/32 hash-algorithm=sha1 enc-algorithm=aes-128 secret=ipsec-password send-initial-contact=no nat-traversal=no comment=filial1

/ip ipsec policyadd action=encrypt src-address=192.168.15.0/24 dst-address=192.168.25.0/24 sa-src-address=10.1.100.1 sa-dst-address=10.1.200.1 ipsec-protocols=esp tunnel=yes comment=filial1

/ip firewall natadd chain=srcnat action=accept place-before=0 src-address=192.168.15.0/24 dst-address=192.168.25.0/24

Расписывать заново каждое действие мы не будем, т. к. они полностью аналогичны настройкам на первом маршрутизаторе.
Настройка IPsec-пира.

Правило обхода NAT.

/ip ipsec peeradd address=10.1.100.1/32 hash-algorithm=sha1 enc-algorithm=aes-128 secret=ipsec-password send-initial-contact=yes nat-traversal=no comment=HQ

/ip ipsec policyadd action=encrypt src-address=192.168.25.0/24 dst-address=192.168.15.0/24 sa-src-address=10.1.200.1 sa-dst-address=10.1.100.1 ipsec-protocols=esp protocol=all tunnel=yes comment=HQ

/ip firewall natadd chain=srcnat action=accept place-before=0 src-address=192.168.25.0/24 dst-address=192.168.15.0/24

AES является единственным алгоритмом, который поддерживается модулем аппаратного шифрования, если такой установлен на маршрутизатор.
Максимальное значение MTU при котором не будет фрагментации с использованием IPsec с алгоритмами SHA1 для подписи и AES-128 для шифрования = 1418. При использовании других алгоритмов значение MTU будет другим. Если используется механизм обхода NAT IPsec, следует понизить MTU на 28.

Если IPSec-соединение установлено успешно, то в графе Established должен появиться таймер времени (5), который показывает, как давно установлено соединение. Индикатором является именно наличие таймера, а не факт наличия соединения (4), которое в случае проблем будет отображаться, но таймер будет отсутствовать.

Выполнить команду /ip ipsec policy print stats, которая покажет актуальное состояние соединения IPSec. В случае удачи мы должны получить: ph2-state=established.
GW1:

Состояние established через консоль будет отображаться только после того, как между двумя сетями произойдет попытка соединения. Например будет запущен ping. До тех пор пока соединение не будет установлено будет отображаться статус no-phase2. При этом через графический интерфейс всегда будет отображаться актуальная информация.

Не мешает ли файервол. Для уверенности лучше временно отключить все правила файерволов на обоих маршрутизаторах.
Совпадают ли пароли (Secret) на обоих маршрутизаторах.
Указан правильный адрес узла (peer) к которому должно происходить подключение.
Совпадают ли способ аутентификации и алгоритм шифрования на обоих маршрутизаторах МикроТик. В приведенном примере использовался предопределенный proposal с настройками по умолчанию.

В статье разбирается настройка GRE/IPSec-туннеля на оборудовании MikroTik с целью объединения двух сетей (site-to-site VPN). Рассматривается метод экспресс-настройки с аутентификацией с помощью пароля. После создания VPN-канала между сетями будет настроена маршрутизация и выполнена проверка работоспособности. Также будут разобраны типичные проблемы, которые могут возникнуть в процессе настройки и проверки.

Создать GRE-туннель. Укажем параметр «keepalive», который определяет находится ли туннель в рабочем состоянии. Если параметр не включен, то даже, если второй маршрутизатор будет выключен интерфейс все равно будет показывать рабочее состояние, что не удобно для диагностики. Мы рекомендуем использоваться значение 10 попыток по 10 секунд. т. е., если в течении 100 секунд не будет никаких сигналов с противоположной стороны туннель перейдет в нерабочее состояние. При этом он автоматически включится, если противоположная сторона попытается установить соединение. Мы рекомендуем выбирать имя интерфейса, которое бы позволяло однозначно идентифицировать кто находится на противоположной стороне туннеля. Если филиалов 1-2, то достаточно и простых идентификаторов. А вот если их число начнет расти, то идентификаторы вроде filial1, filial2, filial3 и т. д. будут не самыми удобными. В отличии от настройки GRE без IPSec в этой конфигурации должна быть отключена опция «Allow Fast Path», а параметр «Local Address:» является обязательным потому что без него не получится создать автоматические настройки IPsec.
При указании параметра «IPsec Secret:» будут автоматически созданы необходимые настройки IPsec. При этом надо учитывать, что внести изменения в эти настройки не будет возможности.

На картинке имеется опечатка. Значения параметров Local Address и Remote Address надо поменять местами.

/interface greadd name=GRE1 keepalive=10s,10 local-address=10.1.100.1 remote-address=10.1.200.1 allow-fast-path=no ipsec-secret=ipsec-password

/ip addressadd address=172.16.30.1/30 interface=GRE1

Настройки второго маршрутизатора полностью идентичны настройкам на первом. Поэтому комментировать их мы не будем.

/interface greadd name=GRE1 keepalive=10s,10 local-address=10.1.200.1 remote-address=10.1.100.1 allow-fast-path=no ipsec-secret=ipsec-password

/ip addressadd address=172.16.30.2/30 interface=GRE1

При проверке работоспособности GRE-туннеля надо учитывать параметр keepalive. Если он отсутствует, то GRE-туннель всегда будет отображаться в рабочем состоянии даже, если это не так. Если параметр стоит, как 10 секунд + 10 попыток, то это значит, что маршрутизатор сделает 10 попыток по 10 секунд каждая (итого 100 секунд) и только по истечении этого периода интерфейс будет отображаться как нерабочий. Т. е. теоретически возможна ситуация, когда интерфейс только-только перестал работать, но время по keepalive еще не вышло, и вы в этот промежуток времени проверите состояние туннеля, которое будет отображаться, как рабочее.

На обоих маршрутизаторах выполнить команду /interface gre print
Если соединение установлено успешно, то статус подключения, так же, как и через графический интерфейс, должен отображаться с буквой «R».

Не мешает ли файервол. Для уверенности лучше временно отключить все правила файерволов на обоих маршрутизаторах.
Совпадают ли пароли IPsec на обоих маршрутизаторах.
Указан правильный адрес маршрутизатора к которому должно происходить подключение.

Время на прочтение

Зачем все это

Эта заметка написана для того, чтобы облегчить путь тем, кто столкнется с проблемой после меня. Задача кажется тривиальной, но как обычно, в процессе вылезли проблемы, которые решать пришлось методом долгого изучения манов и бесконечных перенастроек. В интернете почему то очень мало информации по настройке Cisco Firepower Threat Defense (FTD), а тем более — в связке с Mikrotik.

Исходные данные

У нас есть:

Mikrotik hEX S
Несколько маршрутизируемых сетей за Cisco, одна или несколько локальных сетей за Mikrotik.
Необходимость связать туннелем удаленный офис на Mikrotik с головным офисом за Cisco FTD.

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

Изначально нам нужно убедиться, что обе наши стороны имеют «белый» маршрутизируемый ip адрес. Теоретически, все это можно прокинуть через NAT, если устройство находится внутри сети, но это осложняет конфигурацию, а еще далеко не все провайдеры позволяют one-to-one NAT в наше время.

Начнем со стороны Mikrotik. Предполагаю, что на нем стоит свежая прошивка (в моем случае это 6.48.4), и он уже настроен как роутер «белым» адресом наружу.

Локальная сеть Mikrotik в нашем случае:

Сети со стороны Cisco это множество локальных подсетей:

Маршрутизируемый адрес в примере для Mikrotik будет:

Маршрутизируемый адрес для Cisco:

Mikrotik (Winbox)

Начинаем настройку IPsec:

IP — IPsec — Profiles

Hash алгоритмы sha256
PRF алгоритмы sha256
Diffie Hellman группа modp2048 (она же группа 14 в другом наименовании, подробнее есть в мануале у Mikrotik’а)Все остальное оставляем по умолчанию.

Дальше открываем вкладку proposals

Алгоритмы аутентификации sha256
Алгоритмы шифрования aes-256 cbc
PFS группа modp2048

Address — это адрес пира, то есть Cisco (1.2.3.2)
Local Address — это адрес самого Mikrotik (1.2.3.1)
Выбираем ранее созданный профиль
Exchange Mode нам нужен IKE2

Переходим на вкладку Identities

Выбираем настроенный пир (FTD)
В поле Secret указываем сам ключ (желательно длинный и сложный. Сохраним его для настройки ответной стороны)
Notrack Chain нужно выбрать prerouting

Теперь переходим к главному — настройке Policies

Основная загвоздка в настройке со стороны Mikrotik — это то, что для одной политики возможно указать только одну подсеть. Если нам нужно связать 2 подсети, это не проблема. В случае же с множеством подсетей из разных диапазонов — возникает первая сложность. Нужно делать политику для каждой подсети.

Выбираем созданный ранее пир (FTD)
Выбираем чекбокс Tunnel
Dst.Address — это подсеть, которую мы хотим получить от FTD (172.16.110.0/24)

На второй вкладе (Actions) указываем

Level: unique — для того, чтобы иметь возможность работы нескольких политик одновременно.
Выбираем proposal из ранее созданного (FTD_proposal)

Повторяем настройки для каждой подсети, которую хотим добавить в туннель. От каждой локальной, к каждой удаленной.

Теперь нужно настроить Firewall. Начнем с создания адресных листов.

IP — Firewall — Address Lists

Наша задача: создать 2 листа. Один — FTD_networks — с сетями, которые мы будем получать. А второй — Mikrotik_networks — с локальными сетями на Mikrotik.

Переходим на вкладку Filter Rules. Здесь нам нужно создать разрешающие правила для наших подсетей, чтобы роутер их пропускал.

Advanced — Src. Address List: Mikrotik_networks
Advanced — Dst. Address List: FTD_networks

И второе правило, где Source и Destination Address List меняются местами. Наши разрешающие правила должны быть выше запрещающих! Поэтому их нужно перетащить вверх, если это не так.

Переходим на вкладку NAT.

Нужно сделать исключения для наших подсетей, чтобы они не улетали в обычный NAT маскарадинг.

Как и в правилах фильтрации, нужно сделать 2 правила, поменяв во втором местами Source и Destination. А так же, поднять эти правила выше правила masquerade.

Переходим на вкладку Raw.

Здесь аналогично, нужно сделать 2 правила для прероутинга

Как и в предыдущих вкладках, нужно сделать 2 правила, поменяв во втором местами Source и Destination.

На этом настройка со стороны Mikrotik закончена. Можно приступать к ответной стороне.

Cisco FTD (Firepower Management Center)

Логика настройки firewall и NAT со стороны FTD практически такая же, а вот сам туннель настраивается по-другому. С него и начнем.

Для начала, нам нужно создать группы для подсетей, которые мы отдаем в туннель и которые получаем.

Заходим Objects — Object Management. Add Group

В моем случае, для подсетей, которые мы отдаем это FTD_Subnets. Добавляем в Selected Networks все подсети, что хотим отдавать в туннель. А получаем мы одну подсеть, поэтому ее задаем через Add network — Mikrotik_network.

Несмотря на это, лучше задавать группу, даже если внутри будет лишь одна подсеть, так как в случае расширения — намного проще будет добавить в группу новую подсеть, чем добавлять новые правила под каждый объект.

Переходим к созданию туннеля. Devices — VPN -Site to Site. Add VPN Firepower Threat Defense.

Во вкладке Endpoints указываем:

Node A — это Mikrotik

Device Name: указываем имя
IP Address: static, 1.2.3.1
Protected Networks: сети, которые мы хотим получать (Mikrotik_network).

Node B — это наша локальная FTD

Interface: выбираем наружный интерфейс
IP Address: 1.2.3.2 — должен подставиться сам
Protected Networks: сети, которые мы хотим отдавать (FTD_Subnets).

На вкладке IKE заполняем IKEv2 Settings:

На вкладке IPsec заполняем:

Crypto Map Type: Dynamic
IKEv2 Mode: Tunnel
IKEv2 IPsec Proposals: создаем новые:ESP Hash: SHA-256ESP Encryption: AES-256
Enable reverse Route Injection: должна быть включена
Самое важное! Enable Perfect Forward Secrecy: должна быть включенаModulus Group: 14

Без включения этой функции, на Mikrotik будет активна только одна Policy одновременно. То есть работать будет только одна подсеть.

Все остальные параметры оставляем по умолчанию. Не забываем сохранить конфигурацию.

Теперь нам нужно (аналогично Mikrotik’у) сделать разрешающие правила и исключения NAT.

Переходим в Policies — Access Control и создаем 2 правила

Из зоны Inside в Outside, от Mikrotik_network к FTD_Subnets, Allow. Inspection и Logging можно добавить по вкусу. И второе правило, где все поменяно местами.

В моем случае, зона Inside_Zone — это зона, за которой находятся все подсети, которые необходимо отправить в туннель.Outside_Zone — зона интернет. Если есть дополнительные зоны (DMZ, интерконнекты к другим подсетям) — то нужно сделать правила и для них.

Переходим в Devices — NAT и создаем правило Static, Manual NAT Rule:

Source Interace Objects: Inside_Zone
Destination Interace Objects: Outside_Zone
Original Source: FTD_Subnets
Original Destination: Address — Mikrotik_network
Translated Source: Address — FTD_subnets
Translated Destination: Mikrotik_network
На вкладке Advanced: Чекбокс Do not proxy ARP on Destination Interface должен быть включен.

Правило должно быть выше, чем NAT для локальный подсетей.

FTD, к сожалению, показывает не настолько много информации, как хотелось бы. посмотреть состояние туннеля и возможные ошибки можно по пути Devices — VPN — Troubleshooting.

Со стороны Mikrotik мы, во-первых, должны увидеть на вкладке IPsec — Active Peers наше соединение в состоянии established

а во-вторых, в IPsec — Policies все политики должны стать A (active) и PH2 State established.

Если политики висят в состоянии no phase 2 все кроме одной — то в первую очередь смотрим на настройку Level (unique) в Policies на Mikrotik и на чекбокс Enable Perfect Forward Secrecy в настройке туннеля на cisco FTD.

UPD: в комментах подсказали, что в DH группе можно выставить протокол посерьезнее. Например, ecp521 со стороны Mikrotik (group 21 со стороны Cisco) — на скорость передачи данных и загрузку процессора Mikrotik это практически не влияет (проверил).

Так же, Filter Rules на Mikrotik избыточны, если есть правила по умолчанию (accept inout ipsec policy), которые разрешают всё в ipsec и наружу из него.

Идея статьи возникла из желания пропускать определенные сайты через VPN-туннель напрямую через маршрутизатор, так как дома большое количество устройств, а пускать весь трафик через VPN неудобно в связи с низкой пропускной способностью туннеля. Статья написана сразу после создания конфигурации. Настройка будет проходить в Winbox MikroTik.

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

Здесь я рассмотрю только основные конфигурационные файлы StrongSwan, без углубления в настройку данного демона.

config setup
charondebug=»ike 2, knl 2, cfg 2, net 2, esp 2, dmn 2, mgr 2″
uniqueids=never

conn ikev2-vpn
auto=add
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
dpdaction=clear
dpddelay=300s
rekey=no
left=%any
leftid=
leftcert=server-cert.pem
leftsendcert=always
leftsubnet=0.0.0.0/0
right=%any
rightid=%any
rightauth=eap-mschapv2
rightsourceip=10.10.10.0/24
rightdns=8.8.8.8,8.8.4.4
rightsendcert=never
eap_identity=%identity

iptables на VPS

-A FORWARD -s 10.10.10.0/24 -o eth0 -p tcp -m policy —dir in —pol ipsec -m tcp —tcp-flags SYN,RST SYN -m tcpmss —mss 1361:1536 -j TCPMSS —set-mss 1360

-A POSTROUTING -s 10.10.10.0/24 -o eth0 -m policy —dir out —pol ipsec -j ACCEPT
-A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE

-A INPUT -m state —state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp —dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp —dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp —dport 80 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m udp —dport 500 -j ACCEPT
-A INPUT -p udp -m udp —dport 4500 -j ACCEPT
-A INPUT -j DROP
-A FORWARD -s 10.10.10.0/24 -m policy —dir in —pol ipsec —proto esp -j ACCEPT
-A FORWARD -d 10.10.10.0/24 -m policy —dir out —pol ipsec —proto esp -j ACCEPT
-A FORWARD -j DROP

Импорт сертификатов и настройка IPSec MikroTik

Для добавления сертификатов, необходимо перенести их в память вашего MikroTik в раздел Files.

Импортируем открытый ключ корневого сертификата вашего центра сертификации на VPS на котором установлен StrongSwan.

Последовательно импортируем открытый и закрытый ключи авторизации используемые в конфигурации StrongSwan.

Настройка клиента IPsec

Импортируем закрытый ключ авторизации StrongSwan, для использования в клиенте.

Далее, последовательно настраиваем профиль VPN-клиента.

Вместо «VPS IP» указываем адрес вашего сервера, где развернут StrongSwan.

В разделе IPsec Idenity настраиваем профиль авторизации, указываем учётные данные и сертификат импортированный ранее.

После выполнения этого шага туннель между MikroTik и StrongSwan будет поднят автоматически.

Вывод в разделе Log при успешной авторизации

Настройка маршрутизации трафика и списка ресурсов

В разделе NAT создаем правило перенаправления трафика.

В данном случае я использовал списки адресов.

local — подсеть маршрутизатора.

List1 — список сайтов.

Перенаправляем трафик на шлюз(IP адрес выданный StrongSwan)

В разделе Address Lists необходимо добавить следующие списки:

local — подсеть маршрутизатора, в моем случае 192.168.1.0/24

List1 — список сайтов. Например habr.com, можно добавить сайт по fqdn, ip адрес будет определён автоматически.

Заключение

В данной статье я постарался подробно описать настройку туннеля между MicroTik и StrongSwan. Очень жду фидбека и вашей конструктивной критики.

Рассмотрим как создать IPSec VPN туннель между двумя .

Данная инструкция уже не актуальна для новых прошивок.

Настройки на первом устройстве:

1. Создаем IP Tunnel, заходим меню Interfaces и переходим на вкладку IP Tunnel и нажимаем +

Name — вбиваем имя туннеля

Local Address — наш внешний ip

Remote Adress — удаленный ip

Address — вбиваем внутренний ip адрес туннеля

Interface — выбираем созданный нами туннель

Scr. Address — вводим наш внешний IP

Dst. Address — удаленный ip

Переходим на вкладку Action

Action — encrypt

Level — require

IPsec Protocols — esp

Tunnel — ставим галочку

SA Scr. Address — вводим наш внешний IP

SA Dst. Address — удаленный ip

4. Переходим на вкладку Peers и нажимаем +

На вкладке General в поле Address — вбиваем удаленный ip

Exchange Mode — main

Secret — ключ шифрования (придумываем сами, на втором устройстве должен быть такой же)

переходим на вкладку Advanced

Настраиваем все как на рисунке ниже

Переходим на вкладку Encryption

Hash Algorithm — md5

DH Group — modp1024

На этом настройка первого устройства завершена, переходим ко второму.

Настройки на втором устройстве:

Secret — ключ шифрования (который ввели на первом устройстве)

IPSec будет находится «в режиме ожидания» пока вы не инициируете подключение к удаленной подсети или пингом, или любым другим обращением.

Как мы видим пинг идет, значит туннель работает.

Далее нам нужно что бы ресурсы удаленной сети были доступны нам, создадим для этого правило.

Dst. Address — указываем удаленную подсеть (в нашем случаи это 192.168.24.0/24)

Gateway — созданный нами туннель и нажимаем ОК.

Если необходим доступ к локальным ресурсам из второй сети в первую, аналогично создадим такое же правило, только измениться Dst. Adress, в этом поле укажем нашу подсеть (192.168.0.0/24).

IPsec Tunnel

IPsec в туннельном режиме используется в основном для подключения с сторонними сетями. Указываем какие сети с нашей и с той стороны во 2 фазе IPsec, трафик начинает бегать (но не сразу).

Настройка фазы 1

Никогда не используйте дефолтные профили, создавайте под каждую настройку отдельные!

Название должно отражать для какого подключения профиль

Хэш алгоритмы, группа Диффи — Хеллмана подбирается исходя из аппаратных возможностей MikroTik и согласуется с противоположной стороной

NAT-T так же согласуется с противоположной сторонойНо если по пути нет NAT, то эта опция не используется.

Настройка фазы 2

Всё аналогично настройкам 1 фазы по настройкам шифрования

Для параноиков можно уменьшить время жизни 2 фазы и выбрать PFS Group для генерации нового ключа, отличного от сгенерированного DF в 1 фазе.

Настройка пира

Создаем соединение с другой стороной, с указанием профиля 1 фазыЕсли сервер является центральный, то ему незачем стучаться самому до клиентов, можно выставить режим Passive

Настройка идентификации

Связываем пира с настройками идентификации, вешаем пароль (Secret) или ключ.

Настройка политики

Выбираем Peer, ставим опцию Tunnel и указываем какие IP адреса нужно связать 2 фазой IPsec

Указываем шифрование, Level — unique, если у вас несколько сетей на 2 фазе, протокол esp, если нужно шифровать, ah если нужно проверять заголовок на «подмену»И указываем профиль 2 фазы.

Настройка NAT IPsec Policy

Чтобы трафик проходил через NAT и не нужно было делать лишних правил, добавим настройку IPsec Policy: out: none

Тем самым NAT не будет обрабатывать IPsec траифик

Чтобы «обхитрить» схему прохождения трафика, завернем маршрут до другой сети в lo интерфейс. Это даст возможность объявить об этом маршруте в OSPF

Настройка VPN средствами IPsec Mikrotik

Стандарт IPsec создавался для обеспечения безопасности незащищенного протокола IP. Достигается это путем добавления собственных заголовков в оригинальный пакет для его инкапсуляции, т.е. сокрытия оригинального содержимого.

Не смотря на появление более новых протоколов, позволяющих организовать защищенный канал связи через сеть интернет, IPsec остается довольно популярным так как обладает довольно высокой степенью безопасности и хорошей производительностью.

Чтобы правильно настроить VPN с помощью IPsec, необходимо понимать базовые принципы.

Принципы работы протокола IPsec и базовые термины

IPsec — это набор протоколов, которые можно разделить на следующие основные группы:

Internet Key Exchange (IKE) — протоколы, которые генерируют и раздают ключи шифрования для AH и ESP;
Authentication Header (AH) — протокол заголовка аутентификации, предназначен для проверки целостности передаваемого пакета данных (защита от изменения содержимого пакета или подмены исходного адреса);
Encapsulating Security Payload (ESP) — защищенный протокол инкапсуляции данных, обеспечивает непосредственную защиту данных путем шифрования на общих ключах, а также имеет собственную схему аутентификации подобную AH;

IPsec может работать в двух режимах: транспортном и туннельном:

В транспортном режиме, ESP-заголовок вставляется между IP-заголовком и полезными данными оригинального пакета, а в конец добавляется ESP-трейлер и ESP-аутентификация. Шифруются только полезные данные и ESP-трейлер. Транспортный режим может быть использован для защиты туннелей, организованных иным способом (например L2TP).
В туннельном режиме, оригинальный ip-пакет инкапсулируется в новый и таким образом шифруется весь исходный пакет. Туннельный режим используется для создания VPN.

При создании туннеля создается связь, которая называется SA (Security Association).Каждая связь SA создается для однонаправленного соединения. Так как данные необходимо передавать в двух направлениях, то SA создаются парами. Одна пара SA создается для протокола AH, другая для ESP. Созданные SA хранятся в базе данных узлов (роутеров Mikrotik), которые создают туннель.

Если на узле создалась SA — значит VPN туннель успешно установлен.

На каждом узле имеется база данных политики безопасности (Security Policy Database).Политики содержат следующие настройки:

алгоритмы шифрования/дешифрования;
как часто повторять идентификацию узла и менять ключ шифрования;
использовать режим туннеля или транспорта;
контрольные суммы целостности данных;
использовать AH, ESP или оба;
опция PFS и выбор группы Deffie Hellman.

Установка соединения IPsec происходит в два этапа: Phase 1 и Phase 2.

Первоначальная аутентификация сторон и обмен общими секретными ключами происходит с помощью протокола IKE. Процесс работы протокола IKE состоит из двух этапов:

Phase 1Узлы согласовывают алгоритмы для последующего обмена информацией и аутентифицируются. Происходит обмен общими ключами по алгоритму Deffie Hellman. В результате создается безопасный канал IKE SA.

Phase2Генерируются ключи шифрования IPsec, согласовываются политики. В результате создается соединение IPsec SA

В новой версии протокола IKEv2 процесс происходит за одну фазу в несколько шагов.

Создание постоянного VPN IPsec

Site-to-site туннель позволяет создать постоянный защищенный канал VPN между двумя офисами через интернет. Каждый офис имеет свою локальную сеть и нуждается в доступе к локальной сети другого офиса.

Нормальной работе IPsec туннеля могут препятствовать правила NAT и Fasttrack. Это необходимо учесть и создать правила обхода перед настройкой VPN или после.

Обход NAT и Fasttrack

Без обхода NAT и Fasttrack туннель IPsec не будет работать!

Правила трансляции в NAT (masquerade) меняют адрес источника и роутер не сможет зашифровать пакет с адресом источника отличающимся от заданного в политике IPsec. Это приведет к тому, что сетевой траффик не будет проходить через туннель и пакеты будут теряться.

Правило обхода NAT помогает решить эту проблему.

Правило должно находиться выше всех остальных правил в таблице NAT.

Если на роутере используется Fasttrack, то это тоже сломает работу IPsec так как пакеты будут обходить политики IPsec. Для решения этой проблемы добавьте разрешающие правила accept перед Fasttrack.

Нужно на обоих роутерах разрешить прохождение транзитного трафика в двух направлениях — из сети офиса 1 в сеть офиса 2 и в обратном направлении:

На картинке ниже пример правила для трафика из сети Офиса 1 в сеть Офиса 2. Правило для обратного направления трафика будет отличаться адресами Src. Address 192.168.2.0/24 и Dst. Address 192.168.1.0/24

Однако создание правил в таблице Filter сможет существенно повысить нагрузку на CPU в случаях, когда используется множество туннелей и передается значительное количество траффика. В такой ситуации лучше не использовать таблицу Filter для правил обхода, а создать их в IP/Firewall/RAW. Это позволит не отслеживать соединения и исключить обработку находящихся выше правил , что приведет к снижение нагрузки на CPU.

После добавление правил на обоих роутерах, в таблице RAW должны присутствовать следующие правила:

Настройка IPsec на роутере офиса №1

1. Настройте Profile для фазы 1

dh-groupe — выбор группы Deffie Hellmanenc-algoritn — алгоритм шифрованияname — имя профиля

При выборе алгоритма шифрования следует учитывать влияние на производительность канала. Если скорость канала важна для вас — выбирайте алгоритмы, которые Mikrotik поддерживает аппаратно. На wiki Mikrotik есть таблица.

2. Настройте Proposal для фазы 2

Proposal или предложение — информация, которая будет отправлена сервисами IKE, чтобы установить соединения SA по определенным политикам.

auth-algorithms — алгоритм аутентификации;enc-algorithms — алгоритм шифрования;name — имя политики (указывайте такое же как в профиле, чтобы было понятно к какому профилю относится политика);pfs-group (Perfect Foorward Security) — генерирует дополнительные сессионные ключи на основе ключей сторон и согласует их по алгоритму Деффи Хеллмана (даже если общий ключ будет перехвачен, то трафик им расшифровать не получится).

3. Добавьте Peer

Здесь указывается информация необходимая для установки соединения между демонами IKE двух узлов. Затем это соединение будет использовано для согласования ключей и алгоритмов для соединений SA.

address — публичный адрес удаленного роутераname — любое понятное имяprofile — профиль используемый для соединения

Для работы IPsec должны быть доступны порты UDP/4500 (IPsec NAT traversal) и UDP/500 (IKE). Проверьте файрволл, чтобы не было правил, блокирующих трафик на эти порты.

4. Создайте Identity — секретная фраза для идентификации.

Выберите Peer и укажите секретный идентификатор Secret. Чем сложнее Secret тем лучше, поэтому для его создания лучше воспользоваться генератором пароля.

5. На завершающем этапе создайте Policy (Политику), которая контролирует сети/хосты защищенного канала.

src-address — адрес сети источника (офиса 1)dst-address — адрес сети назначения (офиса 2)src-port — порт источника (any — все порты)dst-port — порт назначенияtunnel — туннельный режимaction — что делать с пакетами (encrypt — шифровать)proposal — какое применять предложениеpeer — с каким узлом устанавливать соединение