Настройка проброса IPsec через роутер является одним из важных шагов для обеспечения безопасности вашей сети. IPsec (Internet Protocol Security) — это набор протоколов, которые обеспечивают защиту данных, передаваемых по сети.
Проброс IPsec позволяет создать шифрованный туннель между двумя сетями или устройствами, обеспечивая безопасность и конфиденциальность передаваемой информации. Для настройки проброса IPsec нужно выполнить несколько шагов.
Во-первых, убедитесь, что ваш роутер поддерживает проброс IPsec и имеет последнюю версию прошивки. Если нет, обновите прошивку до последней версии.
Во-вторых, зайдите в настройки роутера через веб-интерфейс. Обычно адрес веб-интерфейса указан на задней панели роутера. Войдите в настройки, используя свои учетные данные администратора.
Далее найдите раздел настройки проброса портов или DMZ-хоста. В этом разделе вы должны найти возможность настройки проброса IPsec. Выберите эту опцию и введите необходимые параметры для настройки проброса.
Не забудьте указать IP-адрес устройства или сети, с которой вы хотите установить защищенное подключение через IPsec. Настройки могут отличаться в зависимости от модели вашего роутера, поэтому следуйте инструкциям производителя.
После введения необходимых настроек сохраните изменения и перезагрузите роутер. Теперь проброс IPsec должен быть настроен и готов для использования. Проверьте соединение и удостоверьтесь, что вы можете обмениваться данными безопасно через IPsec.
Содержание
- Как настроить проброс IPsec через роутер
- Подготовка к настройке проброса IPsec
- Установка и настройка роутера для проброса IPsec
- Настройка IPsec-туннеля
- Проверка работоспособности настроенного проброса IPsec
- Советы и рекомендации по настройке проброса IPsec через роутер
Как настроить проброс IPsec через роутер
Настройка проброса IPsec через роутер может быть полезной во многих случаях, особенно если вы хотите создать защищенное соединение для удаленного доступа или обмена данными между сетями. Если вы хотите узнать, как настроить проброс IPsec через роутер, следуйте этой пошаговой инструкции.
Шаг 1: Подключение к роутеру
Сначала подключитесь к роутеру, использовав его IP-адрес и учетные данные администратора. В большинстве случаев вы можете найти эту информацию на задней панели роутера или в его документации.
Шаг 2: Открытие портов
Для настройки проброса IPsec вам нужно открыть порты, используемые протоколом IPsec. Откройте порты UDP 500 и UDP 4500 на вашем роутере. Как это сделать, зависит от модели роутера, но обычно вам нужно зайти в раздел настройки портов или протоколов.
Шаг 3: Создание правил фильтрации
Чтобы пробросить IPsec через роутер, вы должны создать правила фильтрации, которые позволят пропустить трафик IPsec через роутер. Откройте настройки фильтрации или правил NAT на роутере и добавьте правила, которые перенаправляют весь трафик IPsec на нужное устройство в вашей локальной сети.
Шаг 4: Настройка IPsec
После того, как вы открыли порты и создали правила фильтрации, перейдите к настройке IPsec на вашем устройстве. В большинстве случаев вам нужно будет указать IP-адрес роутера как конечную точку IPsec, а также настроить другие параметры безопасности, такие как протокол шифрования и алгоритм аутентификации.
Шаг 5: Тестирование соединения
После завершения настройки проброса IPsec и IPsec-туннеля можно приступить к тестированию соединения. Подключитесь к удаленной сети или попробуйте установить соединение с удаленным устройством, чтобы проверить, работает ли проброс IPsec.
Следуя этой пошаговой инструкции, вы сможете настроить проброс IPsec через роутер и создать защищенное соединение, которое позволит вам безопасно обмениваться данными между сетями или получать удаленный доступ к вашей сети.
Подготовка к настройке проброса IPsec
Для успешной настройки проброса IPsec через роутер необходимо выполнить несколько предварительных шагов:
- Установите на компьютер программу для конфигурирования роутера, например, Winbox.
- Свяжитесь с администратором сети и узнайте следующую информацию:
- IP-адрес роутера сети, через который будет осуществляться проброс;
- IP-адрес внешнего узла VPN-сервера;
- Настройки безопасности IPsec (ключи, протоколы и т.д.), предоставленные оператором VPN-сервера.
- Подготовьте необходимые данные, включая:
- Сетевое имя интерфейса внешней сети;
- Идентификаторы IPsec протоколов, которые будут использоваться;
- Настройки безопасности (шифрование, аутентификация и т.д.).
- Убедитесь, что ваш роутер поддерживает и включает IPsec протокол.
После выполнения всех этих шагов, вы готовы приступить к настройке проброса IPsec через роутер.
Примечание: Обратитесь к документации по вашему роутеру и операционной системе для получения дополнительной информации о настройке IPsec.
Установка и настройка роутера для проброса IPsec
Для того чтобы настроить проброс IPsec через роутер, необходимо выполнить следующие шаги:
- Подключите компьютер к роутеру с помощью Ethernet-кабеля.
- Откройте веб-браузер и введите IP-адрес роутера в адресной строке.
- Войдите в настройки роутера, введя имя пользователя и пароль.
- Найдите раздел «Настройки безопасности» или «Firewall» и перейдите в него.
- Включите опцию «Проброс портов» или «Port Forwarding».
- Добавьте новое правило проброса портов для протокола IPsec.
- Укажите внутренний и внешний порт, а также IP-адрес компьютера, к которому будет осуществляться проброс.
- Сохраните изменения и перезагрузите роутер.
После выполнения этих шагов проброс IPsec будет настроен и будет работать через роутер.
Настройка IPsec-туннеля
Для настройки IPsec-туннеля, следуйте приведенным ниже шагам:
- Откройте настройки маршрутизатора веб-интерфейсом, введя в браузере IP-адрес маршрутизатора.
- Войдите в систему, используя учетные данные администратора. Эти данные обычно поставляются с маршрутизатором или могут быть изменены в настройках.
- Перейдите на страницу настройки IPsec-туннеля.
- Создайте новый IPsec-туннель, нажав на кнопку «Добавить» или «Создать новую» (в зависимости от модели маршрутизатора).
- Настройте параметры IPsec-туннеля:
- Сохраните настройки и активируйте IPsec-туннель.
- После этого IPsec-туннель будет настроен и активирован. Вы сможете проверить его статус и, при необходимости, внести изменения в настройки.
| Параметр | Значение |
| Имя туннеля | Введите уникальное имя для туннеля. |
| IP-адрес удаленной сети | Введите IP-адрес удаленной сети, с которой будет установлен туннель. |
| Протокол шифрования | Выберите протокол шифрования для туннеля (например, AES, 3DES). |
| Алгоритм аутентификации | Выберите алгоритм аутентификации для туннеля (например, MD5, SHA-1). |
| Общий секретный ключ | Введите общий секретный ключ для туннеля. |
| Метод обмена ключами | Выберите метод обмена ключами для туннеля (например, прекратить-продолжить, инициатор-ответчик). |
Проверка работоспособности настроенного проброса IPsec
После того как вы завершили настройку проброса IPsec через роутер, необходимо проверить его работоспособность для обеспечения безопасного и стабильного соединения между сетями. Вот несколько шагов, которые помогут вам провести проверку:
Шаг 1: Убедитесь, что оба роутера, между которыми вы настроили проброс, подключены к интернету и успешно соединены между собой.
Шаг 2: Зайдите в настройки каждого из роутеров и убедитесь, что настройки безопасности IPsec соответствуют заданным параметрам. Проверьте совпадение паролей, алгоритмов шифрования и аутентификации.
Шаг 3: Проверьте статус соединения IPsec на обоих роутерах. Обычно это можно сделать в разделе «Статус» или «Дашборд» настроек роутера.
Шаг 4: Попробуйте отправить пакеты данных между двумя сетями, используя проброшенное соединение IPsec. Для этого можно воспользоваться утилитой «ping» или любой другой утилитой для проверки соединения.
Пример использования утилиты ping:
— Откройте командную строку на компьютере, подключенном к одной из сетей.
— Введите команду «ping [IP-адрес устройства в другой сети]» и нажмите Enter.
— Если получаете ответ от удаленного устройства, проброс IPsec настроен успешно и работает исправно. Если нет, проверьте настройки роутеров и повторите проверку.
Следуя этим шагам, вы можете проверить работоспособность настроенного проброса IPsec и быть уверены, что ваши сети правильно соединены и защищены.
Советы и рекомендации по настройке проброса IPsec через роутер
-
Проверьте совместимость вашего роутера с протоколом IPsec. Некоторые модели роутеров могут не поддерживать данную функциональность.
-
Убедитесь, что ваш роутер имеет последнюю версию прошивки, чтобы избежать возможных уязвимостей и ошибок в работе IPsec.
-
Перейдите в настройки роутера и найдите раздел, отвечающий за проброс портов или настройку IPsec.
-
Создайте правило проброса портов для IPsec, указав необходимые параметры, такие как порт и протокол (обычно UDP или TCP).
-
Укажите внутренний IP-адрес устройства, на которое будет перенаправляться трафик по проброшенному порту. Это может быть IP-адрес компьютера или другого сетевого устройства, на котором запущен IPsec-сервер.
-
Установите правило проброса портов и перезагрузите роутер, чтобы изменения вступили в силу.
-
Проверьте работоспособность проброса IPsec, попытавшись подключиться к удаленной сети или устройству, используя клиент IPsec.
-
В случае возникновения проблем, обратитесь к документации вашего роутера или обратитесь в службу технической поддержки производителя.
Время на прочтение
20 мин
Количество просмотров 115K
Добрый день, друзья. Не секрет, что многим из нас хоть раз, но пришлось столкнуться с необходимостью настройки VPN. Являясь активным читателем Хабра я заметил, что несмотря на обилие статей про IPSec, многим он всё равно представляется чем-то сложным и перегруженным. В данной статье я попытаюсь развеять данные мифы на примере собственной полностью рабочей конфигурации. В четырех примерах мы полностью пройдемся по настройке наиболее популярного решения под Linux (Strongswan) начиная от простого туннеля с аутентификацией сторон PSK-ключами до установки host-to-host соединения с аутентификацией обеих сторон на базе сертификатов от Let’s Encrypt. Интересно? Добро пожаловать под кат!
История вопроса
Изначально VPN планировался только для организации канала между мини-роутером родителей и домашним «подкроватным» сервером, по совместительству выступающим в роли маршрутизатора.
Спустя небольшой промежуток времени к этой компании из двух устройств добавился Keenetic.
Но единожды начав, остановиться оказалось сложно, и вскоре на схеме появились телефоны и ноутбук, которым захотелось скрыться от всевидящего рекламного ока MT_Free и прочих нешифрованных WiFi-сетей.
Потом у всеми любимого РКН наконец-то окреп банхаммер, которым он несказанно полюбил прилюдно размахивать во все стороны, и для нейтрализации его заботы о простых смертных пришлось
поддержать иностранный IT-сектор
приобрести VPS за рубежом.
К тому же некоей гражданке, внешне напоминающей Шапокляк, всюду бегающей со своим
ридикюлем
Пакетом и, вероятно, считающей что «Кто людям помогает — тот тратит время зря. Хорошими делами прославиться нельзя», захотелось тайком подглядывать в чужой трафик и брать его на карандаш. Придется тоже защищаться от такой непрошенной любви и VPN в данном случае именно то, что доктор прописал.
Подведем небольшой итог. Нужно было подобрать решение, которое в идеале способно закрыть сразу несколько поставленных задач:
- Объединить сети между Linux-маршрутизаторами
- Построить туннель между Linux и бытовым Keenetic
- Дать доступ к домашним ресурсам и интернету носимым устройствам (телефоны, ноутбуки) из недоверенных сетей
- Создать надежно зашифрованный туннель до удаленной VPS
Не стоит также забывать про прекрасный принцип KISS — Keep It Simple, Stupid. Чем меньше компонентов будет задействовано и чем проще настройка каждого из них — тем надежнее.
Обзор существующих решений
Коротко пройдемся по тому что есть сейчас:
PPTP
Дедушка Ленин всех протоколов. Умер, «разложился на плесень и на липовый мёд».
L2TP
Кто-то, кроме одного провайдера, это использует?
Wireguard
Проект развивается. Активно пилится. Легко создать туннель между двумя пирами, имеющими статический IP. В остальных случаях на помощь всегда готовы придти костыли, велосипеды с квадратными колёсами и синяя изолента, но это не наш путь.
OpenVPN
Плюсы:
- Поддержка множества платформ — Windows, Linux, OpenWRT и её производные, Android
- Стойкое шифрование и поддержка сертификатов.
- Гибкость настройки.
И минусы:
- Работа целиком и полностью в user-space.
- Ограниченная поддержка со стороны домашних машрутизаторов — кривенько-косенько на Mikrotik (не умаляя остальных достоинств железок) и нормально в OpenWRT.
- Сложности с настройкой мобильных клиентов: нужно скачивать, либо создавать свой инсталлятор, копировать куда-то конфиги.
- В случае наличия нескольких туннелей ждут танцы с правкой systemd-юнитов на сервере.
OpenConnect (open-source реализация протокола Cisco Anyconnect)
Очень интересное решение о котором, к сожалению, довольно мало информации.
Плюсы:
- Относительно широкая поддержка различных платформ — Windows, Android, Mac на базе родного приложения Cisco Anyconnect из магазина — идеальный вариант предоставить доступ ко внутренней сети носимым устройствам.
- Стойкое шифрование, поддержка сертификатов, возможность подключения 2FA
- Сам протокол полностью TLS-based (в отличие от OpenVPN, который легко детектится на 443 порту). Кроме TLS поддерживается и DTLS — во время установленного сеанса клиент может переключится на передачу данных через UDP и обратно.
- Прекрасное сосуществование на одном порту как VPN, так и полноценного web-сервера при помощи sniproxy.
- Простота настройки как сервера, так и клиентов.
Здесь тоже не обошлось без минусов:
- Работа целиком и полностью в user-space.
- TCP поверх TCP плохая идея.
- Поддержки со стороны customer-grade оборудования нет.
- Сложность установки туннелей между двумя Linux: теоретически можно, практически — лучше потратить время на что-то более полезное.
- В случае наличия нескольких туннелей ждут танцы с несколькими конфигами и правкой systemd-юнитов.
Казалось бы тупик, но присмотревшись внимательнее и потратив немного времени на изучение я понял, что IPSec на базе IKEv2 способен заменить всё остальное.
IKEv2 IPSEC
Плюсы:
- С появлением IKEv2 сам протокол стал проще в настройке, в сравнении с предыдущей версией, правда ценой потери обратной совместимости.
- Благодаря стандартизации обеспечивается работа где угодно и на чём угодно — список можно вести до бесконечности. Linux, Mikrotik (в последних версиях RouterOS), OpenWRT, Android, iPhone. В Windows также есть нативная поддержка начиная с Windows 7.
- Высокая скорость: обработка трафика полностью в kernel-space. User-space часть нужна только для установки параметров соединения и контроля работоспособности канала.
- Возможность использовать несколько методов аутентификации: используя как PSK, так и сертификаты, причем в любых сочетаниях.
- Несколько режимов работы: туннельный и транспортный. Чем они отличаются можно почитать в том числе и на Хабре.
- Нетребовательность к настройкам промежуточных узлов: если в первой версии IKE были проблемы, вызванные NAT, то в IKEv2 есть встроенные механизмы для преодоления NAT и нативная фрагментация IKE-сообщений, позволяющая установить соединение на каналах с кривым MTU. Забегая вперед скажу, что на практике я еще ни разу не сталкивался с WiFi сетью, где бы клиенту не удалось установить соединение.
Минусы, впрочем, тоже есть:
- Необходимо потратить немного времени на изучение и понять как это работает
- Особенность, которая может сбить с толку новичка: IPSec, в отличие от привычных VPN решений, не создает сетевые интерфейсы. Задаются только политики обработки трафика, всё остальное разруливается средствами firewall.
Прежде чем приступить к настройке будем считать что читатель уже немного знаком с базовыми понятиями и терминами. В помощь новичку можно посоветовать статью с Википедии и сам Хабр, на котором уже достаточно интересных и полезных статей по данной тематике.
Приступаем к настройке
Определившись с решением приступаем к настройке. Схема сети в моем случае имеет следующий вид (убрал под спойлер)
Схема сети
ipsecgw.example.com — домашний сервер, являющийся центром сети. Внешний IP 1.1.1.1. Внутренняя сеть 10.0.0.0/23 и еще один адрес 10.255.255.1/30 для установки приватной BGP-сессии с VPS;
mama — Linux-роутер на базе маленького беззвучного неттопа, установленный у родителей. Интернет-провайдер выдает динамический IP-адрес. Внутренняя сеть 10.0.3.0/24;
keenetic — маршрутизатор Keenetic с установленным модулем IPSec. Интернет-провайдер выдает динамический IP-адрес. Внутренняя сеть 10.0.4.0/24;
road-warriors — переносные устройства, подключающиеся из недоверенных сетей. Адреса клиентам выдаются динамически при подключении из внутренного пула (10.1.1.0/24);
rkn.example.com — VPS вне юрисдикции уважаемого РКН. Внешний IP — 5.5.5.5, внутренний адрес 10.255.255.2/30 для установки приватной BGP-сессии.
Первый шаг. От простого к сложному: туннели с использованием pre-shared keys (PSK)
На обоих Linux-box устанавливаем необходимые пакеты:
sudo yum install strongswan
На обоих хостах открываем порты 500/udp, 4500/udp и разрешаем прохождение протокола ESP.
Правим файл /etc/strongswan/ipsec.secrects (на стороне хоста ipsecgw.example.com) и вносим следующую строку:
mama@router.home.local: PSK "Very strong PSK"На второй стороне аналогично:
root@root.mama.local: PSK "Very strong PSK"В данном случае в качестве ID выступает вымышленный адрес элестронной почты. Больше информации можно подчерпнуть на официальной вики.
Секреты сохранены, движемся дальше.
На хосте ipsecgw.example.com редактируем файл /etc/strongswan/ipsec.conf:
config setup //Настройки самого демона charon
charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0" //Отключаем избыточное логирование
conn %default //Общие настройки для всех соединений
reauth = yes
rekey = yes
keyingtries = %forever
keyexchange = ikev2 //Протокол обмена ключами для всех соединений - IKEv2
dpdaction = hold
dpddelay = 5s //Каждые 5 секунд шлем DPD (Dead Peer Detection) удаленной стороне
mobike = yes //Включаем Mobile IKE - пир может менять свой IP без необходимости переустановки тоннеля
conn mama //Описываем конкретное соединение
left = %defaultroute //Left - наш пир. Директива %defaultroute указывает демону слушать на предмет установки IKE-сессии интрейфейс, котороый смотрит в default route
right = %any //Удаленный пир может иметь любой IP-адрес
authby = psk //Механизм проверки подлинности - используя секретый ключ
leftid = mama@router.home.local //Наш ID, указанный в ipsec.secrets
rightid = root@router.mama.local //ID удаленного пира
leftsubnet = 10.0.0.0/23,10.1.1.0/24
rightsubnet = 10.0.3.0/24
type = tunnel
ike = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha384-x25519!
esp = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha256-sha384-x25519!
auto = add //При старте charon просто добавляем соединение и ждем подключения удаленной стороны
Аналогично редактируем на удаленном пире /etc/strongswan/ipsec.conf:
config setup
charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0"
conn %default
reauth = yes
rekey = yes
keyingtries = %forever
keyexchange = ikev2
dpdaction = restart
dpddelay = 5s
mobike = yes
conn mama
left = %defaultroute
right = ipsecgw.example.com
authby = psk
leftid = root@router.mama.local
rightid = mama@router.home.local
leftsubnet = 10.0.3.0/24
rightsubnet = 10.0.0.0/23,10.1.1.0/24
type = tunnel
ike = aes128gcm16-sha384-x25519!
esp = aes128gcm16-sha384-x25519!
auto = route
Если сравнить конфиги, то можно увидеть что они почти зеркальные, перекрёстно поменяны местами только определения пиров.
Директива auto = route заставляет charon установить ловушку для трафика, подпадающего в заданные директивами left/rightsubnet (traffic selectors). Согласование параметров туннеля и обмен ключами начнутся немедленно после появления трафика, попадающего под заданные условия.
На сервере ipsecgw.example.com в настройках firewall запрещаем маскарадинг для сети 10.0.3.0/24. Разрешаем форвардинг пакетов между 10.0.0.0/23 и 10.0.3.0/24 и наоборот. На удаленном узле выполняем аналогичные настройки, запретив маскарадинг для сети 10.0.0.0/23 и настроив форвардинг.
Рестартуем strongswan на обоих серверах и пробуем выполнить ping центрального узла:
sudo systemctl restart strongswan
ping 10.0.0.1
Убеждаемся что все работает:
sudo strongswan status
Security Associations (1 up, 0 connecting):
mama[53]: ESTABLISHED 84 minutes ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
mama{141}: INSTALLED, TUNNEL, reqid 27, ESP in UDP SPIs: c4eb45fe_i ca5ec6ca_o
mama{141}: 10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24
Нелишним будет так же убедиться что в файле /etc/strongswan/strongswan.d/charon.conf на всех пирах параметр make_before_break установлен в значение yes. В данном случае демон charon, обслуживающий протокол IKEv2, при выполнении процедуры смены ключей не будет удалять текущую security association, а сперва создаст новую.
Шаг второй. Появление Keenetic
Приятной неожиданностью оказался встроенный IPSec VPN в официальной прошивке Keenetic. Для его активации достаточно перейти в Настройки компонентов KeeneticOS и добавить пакет IPSec VPN.
Готовим настройки на центральном узле, для этого:
Правим /etc/strongswan/ipsec.secrects и добавляем PSK для нового пира:
keenetic@router.home.local: PSK "Keenetic+PSK"Правим /etc/strongswan/ipsec.conf и добавляем в конец еще одно соединение:
conn keenetic
left = %defaultroute
right = %any
authby = psk
leftid = keenetic@router.home.local
rightid = root@router.keenetic.local
leftsubnet = 10.0.0.0/23
rightsubnet = 10.0.4.0/24
type = tunnel
ike = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha384-x25519!
esp = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha256-sha384-x25519!
auto = add
Со стороны Keenetic настройка выполняется в WebUI по пути: Интернет → Подключения →
Другие подключения. Всё довольно просто.
Если планируется через тоннель гонять существенные объемы трафика, то можно попробовать включить аппаратное ускорение, которое поддерживается многими моделями. Включается командой crypto engine hardware в CLI. Для отключения и обработки процессов шифрования и хеширования при помощи инструкций CPU общего назначения — crypto engine software
После сохранения настроек рестрартуем strongswan и даём подумать полминуты Keenetic-у. После чего в терминале видим успешную установку соединения:
Все работает:
sudo strongswan status
Security Associations (2 up, 0 connecting):
keenetic[57]: ESTABLISHED 39 minutes ago, 1.1.1.1[keenetic@router.home.local]...3.3.3.3[root@router.keenetic.local]
keenetic{146}: INSTALLED, TUNNEL, reqid 29, ESP SPIs: ca8f556e_i ca11848a_o
keenetic{146}: 10.0.0.0/23 === 10.0.4.0/24
mama[53]: ESTABLISHED 2 hours ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
mama{145}: INSTALLED, TUNNEL, reqid 27, ESP in UDP SPIs: c5dc78db_i c7baafd2_o
mama{145}: 10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24
Шаг третий. Защищаем мобильные устройства
После чтения стопки мануалов и кучи статей решено было остановиться на связке бесплатного сертификата от Let’s Encrypt для проверки подлинности сервера и классической авторизации по логину-паролю для клиентов. Тем самым мы избавляемся от необходимости поддерживать собственную PKI-инфраструктуру, следить за сроком истечения сертификатов и проводить лишние телодвижения с мобильными устройствами, устанавливая самоподписанные сертификаты в список доверенных.
Устанавливаем недостающие пакеты:
sudo yum install epel-release
sudo yum install certbotПолучаем standalone сертификат (не забываем предварительно открыть 80/tcp в настройках iptables):
sudo certbot certonly --standalone -d ipsecgw.example.comПосле того как certbot завершил свою работу мы должны научить Strongswan видеть наш сертификат:
- в директории /etc/strongswan/ipsec.d/cacerts создаем 2 символические ссылки: одну на корневое хранилище доверенных сертификатов в /etc/pki/tls/certs; и вторую с названием ca.pem, указывающую на /etc/letsencrypt/live/ipsecgw.example.com/chain.pem
- В директории /etc/strongswan/ipsec.d/certs также создаются два симлинка: первый, с именем certificate.pem, ссылается на файл /etc/letsencrypt/live/ipsecgw.example.com/cert.pem. И второй, с именем fullchain.pem, ссылающийся на /etc/letsencrypt/live/ipsecgw.example.com/fullchain.pem
- В директории /etc/strongswan/ipsec.d/private размещаем симлинк key.pem, указывающий на закрытый ключ, сгенерированный certbot и лежащий по пути /etc/letsencrypt/live/ipsecgw.example.com/privkey.pem
Добавляем в ipsec.secrets аутентификацию через RSA и связку логинов/паролей для новых пользователей:
ipsecgw.example.com : RSA key.pem
username phone : EAP "Q1rkz*qt"
username notebook : EAP "Zr!s1LBz"
Перезапускаем Strongswan и при вызове sudo strongswan listcerts мы должны видеть информацию о сертификате:
List of X.509 End Entity Certificates
subject: "CN=ipsecgw.example.com"
issuer: "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
validity: not before May 23 19:36:52 2020, ok
not after Aug 21 19:36:52 2020, ok (expires in 87 days)
serial: 04:c7:70:9c:a8:ce:57:cc:bf:6f:cb:fb:d3:a9:cf:06:b0:a8
altNames: ipsecgw.example.com
flags: serverAuth clientAuth
OCSP URIs: http://ocsp.int-x3.letsencrypt.org
certificatePolicies:
2.23.140.1.2.1
1.3.6.1.4.1.44947.1.1.1
CPS: http://cps.letsencrypt.org
После чего описываем новое соединение в ipsec.conf:
conn remote-access
dpddelay = 30s //Переопределяем частоту посылок DPD запросов, чтобы не сажать батарейку телефона
left = %defaultroute
leftid = "CN=ipsecgw.example.com"
leftcert = fullchain.pem //При подключении отдаем клиенту наш сертификат с полной цепочкой доверия
leftsendcert = always
leftsubnet = 0.0.0.0/0 //Инструктируем клиента заворачивать весь трафик в туннель
right = %any
rightid = %any
rightauth = eap-mschapv2 //Аутентифицируем пир, используя EAP-MSCHAP2
rightsendcert = never
eap_identity = %identity
rightsourceip = 10.1.1.0/24 //Strongswan будет выдавать адреса клиентам из данного пула
rightdns = 10.0.0.1,10.0.0.3 //И отдавать указанные DNS
type = tunnel
ike = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha384-x25519!
esp = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha256-sha384-x25519!
auto = add //Добавляем соединение и ждем подключения удаленного пира
dpdaction = restart //Рестартуем соединение, если пир перестал отвечать на DPDНе забываем отредактировать файл /etc/sysconfig/certbot указав, что обновлять сертификат тоже будем как standalone, внеся в него CERTBOT_ARGS=»—standalone».
Так же не забываем включить таймер certbot-renew.timer и установить хук для перезапуска Strongswan в случае выдачи нового сертификата. Для этого либо размещаем простенький bash-скрипт в /etc/letsencrypt/renewal-hooks/deploy/, либо еще раз редактируем файл /etc/sysconfig/certbot.
Перезапускаем Strongswan, включаем в iptables маскарадинг для сети 10.1.1.0/24 и переходим к настройке мобильных устройств.
Android
Устанавливем из Google Play приложение Strongswan.
Запускаем и создаем новый
профиль
Сохраняем профиль, подключаемся и, спустя секунду, можем не переживать о том, что кто-то сможет подсматривать за нами.
Проверяем:
sudo strongswan statusall
Security Associations (3 up, 0 connecting):
remote-access[109]: ESTABLISHED 2 seconds ago, 1.1.1.1[CN=ipsecgw.example.com]...4.4.4.4[phone]
remote-access{269}: INSTALLED, TUNNEL, reqid 55, ESP in UDP SPIs: c706edd1_i e5c12f1d_o
remote-access{269}: 0.0.0.0/0 ::/0 === 10.1.1.1/32
mama[101]: ESTABLISHED 34 minutes ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
mama{265}: INSTALLED, TUNNEL, reqid 53, ESP in UDP SPIs: c8c83342_i c51309db_o
mama{265}: 10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24
keenetic[99]: ESTABLISHED 36 minutes ago, 1.1.1.1[keenetic@router.home.local]...3.3.3.3[root@router.keenetic.local]
keenetic{263}: INSTALLED, TUNNEL, reqid 52, ESP SPIs: c3308f33_i c929d6f1_o
keenetic{263}: 10.0.0.0/23 === 10.0.4.0/24
Windows
Windows актуальных версий приятно удивил. Вся настройка нового VPN происходит путем вызова двух командлетов PowerShell:
Add-VpnConnection -Name "IKEv2" -ServerAddress ipsecgw.example.com -TunnelType "IKEv2"
Set-VpnConnectionIPsecConfiguration -ConnectionName "IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PfsGroup PFS2048 -DHGroup Group14 -PassThru -ForceИ еще одного, в случае если Strongswan настроен на выдачу клиентам IPv6 адреса (да, он это тоже умеет):
Add-VpnConnectionRoute -ConnectionName "IKEv2" -DestinationPrefix "2000::/3"Часть четвертая, финальная. Прорубаем окно в Европу
Насмотревшись провайдерских заглушек «Сайт заблокирован по решению левой пятки пятого зампрокурора деревни Трудовые Мозоли Богозабытского уезда» появилась и жила себе одна маленькая неприметная VPS (с благозвучным доменным именем rkn.example.com) в тысяче километров от обезьянок, любящих размахивать банхаммером и блокировать сети размером /16 за раз. И крутилось на этой маленькой VPS прекрасное творение коллег из NIC.CZ под названием BIRD. Птичка первой версии постоянно умирала в панике от активности обезьянок с дубинками, забанивших на пике своей трудовой деятельности почти 4% интернета, уходя в глубокую задумчивость при реконфиге, поэтому была обновлена до версии 2.0.7. Если читателям будет интересно — опубликую статью по переходу с BIRD на BIRD2, в котором кардинально изменился формат конфига, но работать новая вервия стала намного быстрее и нет проблем с реконфигом при большом количестве маршрутов. А раз у нас используется протокол динамической маршрутизации, то должен быть и сетевой интерфейс, через который нужно роутить трафик. По умолчанию IPSec интерфейсов не создает, но за счет его гибкости мы можем воспользоваться классическими GRE-туннелями, которые и будем защищать в дальнейшем. В качестве бонуса — хосты ipsecgw.example.com и rkn.example.com будут аутентифицировать друга друга, используя самообновляемые сертификаты Lets Encrypt. Никаких PSK, только сертификаты, только хардкор, безопасности много не бывает.
Считаем что VPS подготовлена, Strongswan и Certbot уже установлены.
На хосте ipsecgw.example.com (его IP — 1.1.1.1) описываем новый интерфейс gif0:
sudo vi /etc/sysconfig/network-scripts/ifcfg-gif0
DEVICE="gif0"
MY_OUTER_IPADDR="1.1.1.1"
PEER_OUTER_IPADDR="5.5.5.5"
MY_INNER_IPADDR="10.255.255.1/30"
PEER_INNER_IPADDR="10.255.255.2/30"
TYPE="GRE"
TTL="64"
MTU="1442"
ONBOOT="yes"
Зеркально на хосте vps.example.com (его IP — 5.5.5.5):
sudo vi /etc/sysconfig/network-scripts/ifcfg-gif0
DEVICE="gif0"
MY_OUTER_IPADDR="5.5.5.5"
PEER_OUTER_IPADDR="1.1.1.1"
MY_INNER_IPADDR="10.255.255.2/30"
PEER_INNER_IPADDR="10.255.255.1/30"
TYPE="GRE"
TTL="64"
MTU="1442"
ONBOOT="yes"
Поднимаем интерфейсы, но поскольку в iptables нет правила, разрешающего GRE-протокол, трафик ходить не будет (что нам и надо, поскольку внутри GRE нет никакой защиты от любителей всяких законодательных «пакетов»).
Готовим VPS
Первым делом получаем еще один сертификат на доменное имя rkn.example.com. Создаем симлинки в /etc/strongswan/ipsec.d как описано в предыдущем разделе.
Правим ipsec.secrets, внося в него единственную строку:
rkn.example.com : RSA key.pemПравим ipsec.conf:
config setup
charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0"
strictcrlpolicy = yes
conn %default
reauth = yes
rekey = yes
keyingtries = %forever
keyexchange = ikev2
dpdaction = restart
dpddelay = 5s
mobike = yes
conn rkn
left = %defaultroute
right = ipsecgw.example.com
authby = pubkey
leftcert = fullchain.pem
leftsendcert = always
leftauth = pubkey
rightauth = pubkey
leftid = "CN=rkn.example.com"
rightid = "CN=ipsecgw.example.com"
rightrsasigkey = /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem
leftsubnet = %dynamic
rightsubnet = %dynamic
type = transport
ike = aes256gcm16-sha384-x25519!
esp = aes256gcm16-sha384-x25519!
auto = routeНа стороне хоста ipsecgw.example.com тоже добавляем в ipsec.conf в секцию setup параметр strictcrlpolicy = yes, включающий строгую проверку CRL. И описываем еще одно соединение:
conn rkn
left = %defaultroute
right = rkn.example.com
leftcert = fullchain.pem
leftsendcert = always
leftauth = pubkey
rightauth = pubkey
rightrsasigkey = /etc/strongswan/ipsec.d/certs/rkn.exapmle.com.pem
leftid = "CN=ipsecgw.example.com"
rightid = "CN=rkn.example.com"
leftsubnet = %dynamic
rightsubnet = %dynamic
type = transport
ike = aes256gcm16-sha384-x25519!
esp = aes256gcm16-sha384-x25519!
auto = route
dpdaction = restart
Конфиги почти зеркальные. Внимательный читатель мог сам уже обратить внимание на пару моментов:
- left/rightsubnet = %dynamic — инструктирует Strongswan применять политики ко всем типам трафика между пирами
- В каждом из конфигов указан параметр rightrsasigkey. Без него попытка установки IKE SA всегда будет оканчиваться ошибкой IKE AUTH ERROR в логе, поскольку Strongswan не сможет подписать сообщение без знания открытой части RSA-ключа удаленного пира. Для получения открытых ключей мы можем воспользоваться openssl. На каждом из хостов (ipsecgw и RKN) выполняем sudo /usr/bin/openssl rsa -in /etc/letsencrypt/live/ipsecgw.example.com/privkey.pem -pubout > ~/ipsecgw.example.com.pem и sudo /usr/bin/openssl rsa -in /etc/letsencrypt/live/rkn.example.com/privkey.pem -pubout > ~/rkn.example.com.pem, после чего при помощи scp перекрестно копируем их между серверами в расположения, указаные в конфиге
Не забываем настроить файрвол и автообновление сертификатов. После перезапуска Strongswan на обоих серверах, запустим ping удаленной стороны GRE-туннеля и увидим успешную установку соединения. На VPS (rkn):
sudo strongswan status
Routed Connections:
rkn{1}: ROUTED, TRANSPORT, reqid 1
rkn{1}: 5.5.5.5/32 === 1.1.1.1/32
Security Associations (1 up, 0 connecting):
rkn[33]: ESTABLISHED 79 minutes ago, 5.5.5.5[CN=rkn.example.com]...1.1.1.1[CN=ipsecgw.example.com]
rkn{83}: INSTALLED, TRANSPORT, reqid 1, ESP SPIs: cb4bc3bb_i c4c35a5a_o
rkn{83}: 5.5.5.5/32 === 1.1.1.1/32И на стороне хоста ipsecgw
под спойлером
Routed Connections:
rkn{1}: ROUTED, TRANSPORT, reqid 1
rkn{1}: 1.1.1.1/32 === 5.5.5.5/32
Security Associations (4 up, 0 connecting):
remote-access[10]: ESTABLISHED 5 seconds ago, 1.1.1.1[CN=ipsecgw.example.com]...4.4.4.4[phone]
remote-access{12}: INSTALLED, TUNNEL, reqid 7, ESP in UDP SPIs: c7a31be1_i a231904e_o
remote-access{12}: 0.0.0.0/0 === 10.1.1.1/32
keenetic[8]: ESTABLISHED 22 minutes ago, 1.1.1.1[keenetic@router.home.local]...3.3.3.3[root@router.keenetic.local]
keenetic{11}: INSTALLED, TUNNEL, reqid 6, ESP SPIs: cfc1b329_i c01e1b6e_o
keenetic{11}: 10.0.0.0/23 === 10.0.4.0/24
mama[4]: ESTABLISHED 83 minutes ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
mama{8}: INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c4a5451a_i ca67c223_o
mama{8}: 10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24
rkn[3]: ESTABLISHED 83 minutes ago, 1.1.1.1[CN=ipsecgw.example.com]...5.5.5.5[CN=rkn.example.com]
rkn{7}: INSTALLED, TRANSPORT, reqid 1, ESP SPIs: c4c35a5a_i cb4bc3bb_o
rkn{7}: 1.1.1.1/32 === 5.5.5.5/32
Туннель установлен, пинги ходят, в tcpdump видно что между хостами ходит только ESP. Казалось бы можно радоваться. Но нельзя расслабляться не проверив всё до конца. Пробуем перевыпустить сертификат на VPS и…
Шеф, всё сломалось
Начинаем разбираться и натыкаемся на одну неприятную особенность прекрасного во всём остальном Let’s Encrypt — при любом перевыпуске сертификата меняется так же ассоциированный с ним закрытый ключ. Изменился закрытый ключ — изменился и открытый. На первый взгляд ситуация для нас безвыходная: если даже открытый ключ мы можем легко извлечь во время перевыпуска сертификата при помощи хука в certbot и передать его удаленной стороне через SSH, то непонятно как заставить удаленный Strongswan перечитать его. Но помощь пришла откуда не ждали — systemd умеет следить за изменениями файловой системы и запускать ассоциированные с событием службы. Этим мы и воспользуемся.
Создадим на каждом из хостов служебного пользователя keywatcher с максимально урезанными правами, сгенерируем каждому из них SSH-ключи и обменяемся ими между хостами.
На хосте ipsecgw.example.com создадим каталог /opt/ipsec-pubkey в котором разместим 2 скрипта.
sudo vi /opt/ipsec-pubkey/pubkey-copy.sh#!/bin/sh
if [ ! -f /home/keywatcher/ipsecgw.example.com.pem ]; then
/usr/bin/openssl rsa -in /etc/letsencrypt/live/ipsecgw.example.com/privkey.pem -pubout > /home/keywatcher/ipsecgw.example.com.pem;
/usr/bin/chown keywatcher:keywatcher /home/keywatcher/ipsecgw.example.com.pem;
/usr/bin/chmod 0600 /home/keywatcher/ipsecgw.example.com.pem;
sudo -u keywatcher /usr/bin/scp /home/keywatcher/ipsecgw.example.com.pem rkn.example.com:/home/keywatcher/ipsecgw.example.com.pem;
status=$?;
if [ $status -eq 0 ]; then
rm -f /home/keywatcher/ipsecgw.example.com.pem;
logger "Public key ipsecgw.example.com.pem has been successfully uploaded to remote host";
else
logger "Public key ipsecgw.example.com.pem has not been uploaded to remote host due to error";
fi
else
logger "Public key ipsecgw.example.com.pem already exist on /home/keywatcher directory, something went wrong";
fi
exit 0sudo vi /opt/ipsec-pubkey/key-updater.sh#!/bin/sh
/usr/bin/cp /home/keywatcher/rkn.example.com.pem /etc/strongswan/ipsec.d/certs/rkn.example.com.pem
/usr/bin/chown root:root /etc/strongswan/ipsec.d/certs/rkn.example.com.pem
/usr/bin/chmod 0600 /etc/strongswan/ipsec.d/certs/rkn.example.com.pem
logger "Public key of server rkn.example.com has been updated, restarting strongswan daemon to re-read it"
/usr/bin/systemctl restart strongswan
exit 0
На VPS (хосте rkn.example.com) аналогично создаем каталог с тем же именем, в котором тоже создаем аналогичные скрипты, изменяя только название ключа. Код, чтобы не загромождать статью, под
спойлером
sudo vi /opt/ipsec-pubkey/pubkey-copy.sh
#!/bin/sh
if [ ! -f /home/keywatcher/rkn.example.com.pem ]; then
/usr/bin/openssl rsa -in /etc/letsencrypt/live/rkn.example.com/privkey.pem -pubout > /home/keywatcher/rkn.example.com.pem;
/usr/bin/chown keywatcher:keywatcher /home/keywatcher/rkn.example.com.pem;
/usr/bin/chmod 0600 /home/keywatcher/rkn.example.com.pem;
sudo -u keywatcher /usr/bin/scp /home/keywatcher/rkn.example.com.pem ipsecgw.example.com:/home/keywatcher/rkn.example.com.pem;
status=$?;
if [ $status -eq 0 ]; then
rm -f /home/keywatcher/rkn.example.com.pem;
logger "Public key rkn.example.com.pem has been successfully uploaded to remote host";
else
logger "Public key rkn.example.com.pem has not been uploaded to remote host";
fi
else
logger "Public key rkn.example.com.pem already exist on /home/keywatcher directory, something went wrong";
fi
exit 0
sudo vi /opt/ipsec-pubkey/key-updater.sh
#!/bin/bash
/usr/bin/cp /home/keywatcher/ipsecgw.example.com.pem /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem;
/usr/bin/chown root:root /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem
/usr/bin/chmod 0600 /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem
logger "Public key of server ipsecgw.example.com has been updated, restarting connection"
/usr/bin/systemctl restart strongswan
exit 0
Скрипт pubkey-copy.sh нужен для извлечения открытой части ключа и копирования его удаленному хосту во время выпуска нового сертификата. Для этого в каталоге /etc/letsencrypt/renewal-hooks/deploy на обоих серверах создаем еще один микроскрипт:
#!/bin/sh
/opt/ipsec-pubkey/pubkey-copy.sh > /dev/null 2>&1
/usr/bin/systemctl restart strongswan
exit 0Половина проблемы решена, сертификаты перевыпускаются, публичные ключи извлекаются и копируются между серверами и пришло время systemd с его path-юнитами.
На сервере ipsecgw.example.com в каталоге /etc/systemd/system создаем файл keyupdater.path
[Unit]
Wants=strongswan.service
[Path]
PathChanged=/home/keywatcher/rkn.example.com.pem
[Install]
WantedBy=multi-user.targetАналогично на VPS хосте:
[Unit]
Wants=strongswan.service
[Path]
PathChanged=/home/keywatcher/ipsecgw.example.com.pem
[Install]
WantedBy=multi-user.targetИ, напоследок, на каждом сервере создаем ассоциированную с данным юнитом службу, которая будет запускаться при выполнении условия (PathChanged) — изменении файла и его закрытии его после записи. Создаем файлы /etc/systemd/system/keyupdater.service и прописываем:
[Unit]
Description= Starts the IPSec key updating script
Documentation= man:systemd.service
[Service]
Type=oneshot
ExecStart=/opt/ipsec-pubkey/key-updater.sh
[Install]
WantedBy=multi-user.targetНе забываем перечитать конфигурации systemd при помощи sudo systemctl daemon-reload и назначить path-юнитам автозапуск через sudo systemctl enable keyupdater.path && sudo systemctl start keyupdater.path.
Как только удаленный хост запишет файл, содержащий публичный ключ, в домашний каталог пользователя keywatcher и файловый дескриптор будет закрыт, systemd автоматически запустит соответствующую службу, которая скопирует ключ в нужное расположение и перезапустит Strongswan. Туннель будет установлен, используя правильный открытый ключ второй стороны.
Можно выдохнуть и наслаждаться результатом.
Вместо заключения
Как мы только что увидели
чёрт
IPSec не так страшен, как его малюют. Всё, что было описано — полностью рабочая конфигурация, которая используется в настоящее время. Даже без особых знаний можно настроить VPN и надежно защитить свои данные.
Конечно за рамками статьи остались моменты настройки iptables, но и сама статья уже получилась и без того объемная и про iptables написано много.
Есть в статье и моменты, которые можно улучшить, будь-то отказ от перезапусков демона Strongswan, перечитывая его конфиги и сертификаты, но у меня не получилось этого добиться.
Впрочем и рестарты демона оказались не страшны: происходит потеря одного-двух пингов между пирами, мобильные клиенты тоже сами восстанавливают соединение.
Надеюсь коллеги в комментариях подскажут правильное решение.
Задача объединения нескольких сетей в разных офисах одна из наиболее часто встречающихся у системных администраторов. Для ее решения могут использоваться различные виды VPN и туннельных соединений, выбор которых может зависеть от множества требований и условий. Одной из альтернатив туннелям и VPN может служить «чистое» IPsec-соединение, которое имеет как свои достоинства, так и недостатки. В данном материале мы рассмотрим реализацию подобного соединения между сетями офисов (site-to-site) c использованием оборудования Mikrotik.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
IPsec — набор протоколов для обеспечения защиты данных, передаваемых в сетях по протоколу IP. Основным преимуществом IPsec является высокий уровень безопасности, на сегодняшний день он является лучшим протоколом для защиты передаваемых данных. Также следует отметить высокий уровень производительности, при условии достаточного количества вычислительных ресурсов для работы с криптографией. Применительно к устройствам Mikrotik IPsec позволяет получить одни из самых высоких результатов, особенно на устройствах с аппаратной поддержкой шифрования.
Но есть и недостатки, они тоже достаточно существенны. IPsec сложен, как в настройке, так в понимании его работы, это требует от администратора более глубокого уровня знаний и может вызвать серьезные затруднения при отладке и диагностике неисправностей. Также IPsec не использует интерфейсы, а обрабатывает трафик на основании собственных политик, это также приводит к ряду затруднений, начиная от прохождения трафика через брандмауэр и заканчивая невозможностью применения маршрутизации для таких соединений. Часть сетевых конфигураций легко реализуемых при помощи VPN и туннелей построить при помощи IPsec в принципе невозможно.
Далее мы рассмотрим объединение двух офисных сетей по представленной ниже схеме:
Где LAN 1 с диапазоном 192.168.111.0/24 и LAN 2 — 192.168.186.0/24 — это сети двух офисов, которые мы будем объединять, а 192.168.3.107 и 192.168.3.111 — выполняют роль внешних белых адресов в сети интернет. Наша задача обеспечить прозрачный доступ устройств одной сети в другую через защищенный канал связи.
Настройка IPsec соединения
Соединение IPsec имеет отличия как от предусматривающего клиент-серверную схему VPN, так и от stateless туннелей. В отличие от последних мы всегда можем проверить состояние соединения, но понятие клиента и сервера здесь отсутствует, в IPsec одно из устройств выступает в качестве инициатора (initiator), а второе в качестве ответчика (responder). Эти роли не являются жестко закрепленными и могут меняться между устройствами, хотя при необходимости мы можем закрепить за определенным устройством постоянную роль.
Например, это позволяет установить IPsec соединение, когда один из узлов не имеет выделенного IP-адреса, в этом случае ему следует настроить роль инициатора, а второму узлу роль ответчика. В нашем случае подразумевается наличие выделенных адресов с обоих сторон и каждое из устройств может выступать в любой роли.
Настройку начнем с определения алгоритмов шифрования для каждой фазы соединения. Так как мы соединяем два собственных устройства, то можем не оглядываться на требования совместимости и настроить параметры шифрования на собственное усмотрение. Но без фанатизма, не забываем, что многие устройства Mikrotik достаточно слабые и не имеют аппаратной поддержки шифрования, а те, которые имеют, поддерживают различный набор протоколов.
Так популярный RB750Gr3 (hEX) поддерживает аппаратное ускорение только SHA1/SHA256 — AES-CBC, а более новый RB3011 уже поддерживает SHA1/SHA256 — AES-CBC и SHA1/SHA256 — AES-CTR. Желание использовать сильные шифры безусловно похвально, но оно не должно опережать возможности имеющегося оборудования.
Первая фаза — обмен ключами и взаимная идентификация устройств, за ее настройки отвечает раздел IP — IPsec — Profiles, перейдем в него и создадим новый профиль. Для него укажем: Hash Algorithms — sha1, Encryption Algorithm — aes-256, DH Group — ecp384. В поле Name укажем имя профиля, в нашем случае ipsec-sts (site-to-site).
В терминале для выполнения этого же действия выполните:
/ip ipsec profile
add dh-group=ecp384 enc-algorithm=aes-256 name=ipsec-stsЭто достаточно сильные настройки шифров, для устройств без аппаратного ускорения мы бы посоветовали ограничиться aes-128 и modp1024, хотя никто не мешает протестировать желаемые варианты и остановиться на наиболее оптимальном.
Вторая фаза — установление защищённого соединения и передача данных, настройки шифров для нее задаются в IP — IPsec — Proposal, перейдем в данный раздел и создадим новое предложение. Укажем Auth. Algorithms — sha1, Encr. Algorithms — aes-256-cbc, PFS Group — ecp384.
Это же действие в терминале:
/ip ipsec proposal
add enc-algorithms=aes-256-cbc name=ipsec-sts pfs-group=ecp384В данном примере мы использовали не самые сильные шифры, так режим шифрования CBC является наиболее слабым и при наличии аппаратной поддержки стоит использовать CTR или GCM. Но не забывайте о достаточной разумности, если нагрузка на устройство велика — понижайте уровень шифрования.
Теперь перейдем в IP — IPsec — Peer и создадим новое подключение. В поле Address указываем внешний адрес второго роутера, в Profile выбираем созданный нами на предыдущем этапе профиль, в нашем случае ipsec-sts, а в поле Exchange Mode указываем IKE2.
В терминале:
/ip ipsec peer
add address=192.168.3.111/32 exchange-mode=ike2 name=sts-peer profile=ipsec-stsВ целом того, что мы уже настроили достаточно для установления защищенного соединения, но IPsec не VPN и работает по-другому. Для того, чтобы трафик начал шифроваться он должен соответствовать одной из политик IPsec, поэтому перейдем в IP — IPsec — Policies и создадим новую политику. В поле Peer укажем созданное ранее соединение, ниже установим флаг Tunnel для работы соединения в туннельном режиме, в поле Src. Address укажем диапазон собственной сети — 192.168.111.0/24, а в поле Dst. Address — диапазон удаленной сети — 192.168.186.0/24.
Затем на закладке Action установите Proposal — ipsec-sts, предложение которое мы создали ранее.
Для терминала используйте следующие команды:
/ip ipsec policy
add dst-address=192.168.186.0/24 peer=sts-peer proposal=ipsec-sts src-address=192.168.111.0/24 tunnel=yesНу и осталось совсем немного — научить узлы идентифицировать друг друга, так как оба роутера контролируются администратором и настроены принимать подключения только от другого узла, то мы будем использовать аутентификацию по предварительному ключу. Перейдем в IP — IPsec — Identities и создадим новую настройку идентификации. Здесь нам нужно заполнить поля: Peer — указываем созданное нами соединение, в нашем случае ipsec-sts, Auth. Method — pre shared key, Secret — предварительный ключ. В качестве предварительного ключа рекомендуется использовать строку с использованием цифр, букв в разных регистрах и специальных символов, сформированных в случайном порядке и с длинной не менее 16-32 символов. Не следует использовать в качестве ключа словарные слова и фразы. Предупреждения внизу окна можно проигнорировать.
В терминале:
/ip ipsec identity
add peer=sts-peer secret="2KuSY2%QKt\$\$gs8V9nrERD@V8zAuh\$3S"
На втором узле следует выполнить аналогичные настройки, только в качестве адреса в Peer указав внешний адрес первого роутера, а в Policy поменяв местами сеть источника и сеть назначения.
Настройка брандмауэра
Будем считать, что вы используете нормально закрытый брандмауэр настроенный в соответствии с нашими рекомендациями. Для того, чтобы разрешить входящее IPsec-соединение перейдем в IP — Firewall — Filter Rules и добавим следующие правила. Первое из них разрешает работу протокола обмена ключами IKE: Chain — input, Protocol — udp, Dst. Port — 500,4500, In. Interface — внешний интерфейс, в нашем случае ether1.
Второе правило разрешает протокол шифрования полезной нагрузки Encapsulating Security Payload (ESP): Chain — input, Protocol — 50 (ipsec-esp), In. Interface — внешний интерфейс — ether1.
Обратите внимание, что мы нигде не указываем действие, потому что по умолчанию все правила имеют в качестве действия accept — разрешить.
Эти же действия можно быстро выполнить в терминале:
/ip firewall filter
add action=accept chain=input dst-port=500,4500 in-interface=ether1 protocol=udp
add action=accept chain=input in-interface=ether1 protocol=ipsec-espДля того, чтобы пакеты из одной сети могли попасть в другую, следует разрешить их транзит. Создадим еще одно правило: Chain — forward, In. Interface — внешний интерфейс — ether1, затем на закладке Advanced укажем IPsec Policy — in:ipsec. Это разрешит транзит любых входящих пакетов, которые попадают под любую установленную политику IPsec.
В терминале:
/ip firewall filter
add action=accept chain=forward in-interface=ether1 ipsec-policy=in,ipsecАналогичные настройки следует выполнить на втором узле.
Обход NAT и Fasttrack
Как мы уже говорили, IPsec не использует интерфейсы, а следовательно, обрабатываемый им трафик, хоть и уходит в защищенный туннель, но продолжает использовать в качестве исходящего внешний интерфейс, что может привести к ряду коллизий. Прежде всего нужно исключить обработку такого трафика правилами snat или masquerade. Для этого перейдем в IP — Firewall — NAT и создадим новое правило: Chain — srcnat, Src. Address — 192.168.111.0/24 — диапазон локальной сети, Dst. Address — 192.168.186.0/24 — диапазон удаленной сети, так как действие по умолчанию accept, то явно его не указываем. Данное правило поднимаем в самый верх, одно должно быть первым в цепочке srcnat.
Через терминал добавить его можно следующей командой:
/ip firewall nat
add action=accept chain=srcnat dst-address=192.168.186.0/24 src-address=192.168.111.0/24 place-before=0Опция place-before=0 позволяет поставить правило в самое начало цепочки.
Если вы используете Fasttrack, то также следует исключить обработку проходящего через IPsec трафика этим механизмом, для этого следует добавить два правила. Первое для трафика из локальной сети в удаленную: Chain — forward, Src. Address — 192.168.111.0/24 — диапазон локальной сети, Dst. Address — 192.168.186.0/24 — диапазон удаленной сети, Сonnection State — established, related.
Второе правило для трафика из удаленной сети в локальную, оно полностью повторяет первое, только меняем местами сеть источника (Src. Address) и сеть назначения (Dst. Address).
В терминале:
/ip firewall filter
add chain=forward action=accept place-before=0 src-address=192.168.111.0/24 dst-address=192.168.186.0/24 connection-state=established,related
add chain=forward action=accept place-before=0 src-address=192.168.186.0/24 dst-address=192.168.111.0/24 connection-state=established,relatedАналогичные настройки, с учетом адресов, следует выполнить и на втором узле.
Заключение
После того, как мы завершили процесс настройки перейдем в IP — IPsec — Active Peers и убедимся, что соединение между двумя узлами установлено. Если это не так — еще раз проверяем все настройки и изучаем файл лога, скорее всего у вас не совпадают параметры шифрования или идентификации.
Теперь откроем IP — IPsec — Installed SAs. В терминах IPsec — SA (Security Association) — ассоциация безопасности, обозначает установленное защищенное соединение. Для каждого соединения создается отдельная пара SA, так как каждая SA — это однонаправленное соединение, а данные нужно передавать по двум направлениям. Если запустить обмен данными между сетями, скажем пропинговать с узла одной сети узел другой сети, то мы увидим, что данные счетчика Current Bytes начинают меняться, а следовательно, шифрование работает и данные передаются внутри защищенного соединения.
Как видим, если хотя бы на базовом уровне понимать принципы действия IPsec, то настроить туннель между двумя сетями относительно несложно. Надеемся, что данный материал будет вам полезен.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Стандарт IPsec создавался для обеспечения безопасности незащищенного протокола IP. Достигается это путем добавления собственных заголовков в оригинальный пакет для его инкапсуляции, т.е. сокрытия оригинального содержимого.
Стандарт IPsec создавался для обеспечения безопасности незащищенного протокола IP. Достигается это путем добавления собственных заголовков в оригинальный пакет для его инкапсуляции, т.е. сокрытия оригинального содержимого.
Не смотря на появление более новых протоколов, позволяющих организовать защищенный канал связи через сеть интернет, IPsec остается довольно популярным так как обладает довольно высокой степенью безопасности и хорошей производительностью.
Чтобы правильно настроить VPN с помощью 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).
Политики содержат следующие настройки:
- алгоритмы шифрования/дешифрования;
- способы идентификация узла: pre-shared keys или RSA-сертификат;
- как часто повторять идентификацию узла и менять ключ шифрования;
- использовать режим туннеля или транспорта;
- контрольные суммы целостности данных;
- использовать AH, ESP или оба;
- опция PFS и выбор группы Deffie Hellman.
Установка соединения IPsec происходит в два этапа: Phase 1 и Phase 2.
Первоначальная аутентификация сторон и обмен общими секретными ключами происходит с помощью протокола IKE. Процесс работы протокола IKE состоит из двух этапов:
Phase 1
Узлы согласовывают алгоритмы для последующего обмена информацией и аутентифицируются. Происходит обмен общими ключами по алгоритму Deffie Hellman. В результате создается безопасный канал IKE SA.
Phase2
Генерируются ключи шифрования IPsec, согласовываются политики. В результате создается соединение IPsec SA
В новой версии протокола IKEv2 процесс происходит за одну фазу в несколько шагов.
Site-to-Site туннель: создание постоянного VPN IPsec
Site-to-site туннель позволяет создать постоянный защищенный канал VPN между двумя офисами через интернет. Каждый офис имеет свою локальную сеть и нуждается в доступе к локальной сети другого офиса.
Адреса 10.1.100.1 и 10.2.100.1 в реальности не относятся к публичным ip-адресам и не используются в сети интернет.
Нормальной работе IPsec туннеля могут препятствовать правила NAT и Fasttrack. Это необходимо учесть и создать правила обхода перед настройкой VPN или после.
Обход NAT и Fasttrack
Без обхода NAT и Fasttrack туннель IPsec не будет работать!
Правила трансляции в NAT (masquerade) меняют адрес источника и роутер не сможет зашифровать пакет с адресом источника отличающимся от заданного в политике IPsec. Это приведет к тому, что сетевой траффик не будет проходить через туннель и пакеты будут теряться.
Правило обхода NAT помогает решить эту проблему.
Office 1:
/ip firewall nat
add chain=srcnat action=accept place-before=0 src-address=192.168.1.0/24 dst-address=192.168.2.0/24
Office 2:
/ip firewall nat
add chain=srcnat action=accept place-before=0 src-address=192.168.2.0/24 dst-address=192.168.1.0/24
Правило должно находиться выше всех остальных правил в таблице NAT.
Если на роутере используется Fasttrack, то это тоже сломает работу IPsec так как пакеты будут обходить политики IPsec. Для решения этой проблемы добавьте разрешающие правила accept перед Fasttrack.
Нужно на обоих роутерах разрешить прохождение транзитного трафика в двух направлениях — из сети офиса 1 в сеть офиса 2 и в обратном направлении:
/ip firewall filter
add chain=forward action=accept place-before=1
src-address=192.168.1.0/24 dst-address=192.168.2.0/24 connection-state=established,related
add chain=forward action=accept place-before=1
src-address=192.168.2.0/24 dst-address=192.168.1.0/24 connection-state=established,relatedНа картинке ниже пример правила для трафика из сети Офиса 1 в сеть Офиса 2. Правило для обратного направления трафика будет отличаться адресами Src. Address 192.168.2.0/24 и Dst. Address 192.168.1.0/24
Однако создание правил в таблице Filter сможет существенно повысить нагрузку на CPU в случаях, когда используется множество туннелей и передается значительное количество траффика. В такой ситуации лучше не использовать таблицу Filter для правил обхода, а создать их в IP/Firewall/RAW. Это позволит не отслеживать соединения и исключить обработку находящихся выше правил , что приведет к снижение нагрузки на CPU.
/ip firewall raw
add action=notrack chain=prerouting src-address=192.168.1.0/24 dst-address=192.168.2.0/24
add action=notrack chain=prerouting src-address=192.168.2.0/24 dst-address=192.168.1.0/24После добавление правил на обоих роутерах, в таблице RAW должны присутствовать следующие правила:
Настройка IPsec на роутере офиса №1:
1. Настройте Profile для фазы 1
Профили определяют набор параметров, которые будут использованы для согласования IKE в фазе 1.
dh-groupe — выбор группы Deffie Hellman
enc-algoritn — алгоритм шифрования
name — имя профиля
/ip ipsec profile
add hash-algorithm=md5 dh-group=modp2048 enc-algorithm=3des name=Office2-ike1
При выборе алгоритма шифрования следует учитывать влияние на производительность канала. Если скорость канала важна для вас — выбирайте алгоритмы, которые Mikrotik поддерживает аппаратно. На wiki Mikrotik есть таблица.
2. Настройте Proposal для фазы 2
Proposal или предложение — информация, которая будет отправлена сервисами IKE, чтобы установить соединения SA по определенным политикам.
auth-algorithms — алгоритм аутентификации;
enc-algorithms — алгоритм шифрования;
name — имя политики (указывайте такое же как в профиле, чтобы было понятно к какому профилю относится политика);
pfs-group (Perfect Foorward Security) — генерирует дополнительные сессионные ключи на основе ключей сторон и согласует их по алгоритму Деффи Хеллмана (даже если общий ключ будет перехвачен, то трафик им расшифровать не получится).
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=3des name=Office2-ike1 pfs-group=modp2048
3. Добавьте Peer
Здесь указывается информация необходимая для установки соединения между демонами IKE двух узлов. Затем это соединение будет использовано для согласования ключей и алгоритмов для соединений SA.
address — публичный адрес удаленного роутера
name — любое понятное имя
profile — профиль используемый для соединения
Для работы IPsec должны быть доступны порты UDP/4500 (IPsec NAT traversal) и UDP/500 (IKE). Проверьте файрволл, чтобы не было правил, блокирующих трафик на эти порты.
/ip ipsec peer
add address=10.2.100.1/32 name=Office2-ike1 profile=Office2-ike1
4. Создайте Identity — секретная фраза для идентификации.
Выберите Peer и укажите секретный идентификатор Secret. Чем сложнее Secret тем лучше, поэтому для его создания лучше воспользоваться генератором пароля.
/ip ipsec identity
add peer=Office2-ike1 secret=MySecret!
5. На завершающем этапе создайте Policy (Политику), которая контролирует сети/хосты защищенного канала.
src-address — адрес сети источника (офиса 1)
dst-address — адрес сети назначения (офиса 2)
src-port — порт источника (any — все порты)
dst-port — порт назначения
tunnel — туннельный режим
action — что делать с пакетами (encrypt — шифровать)
proposal — какое применять предложение
peer — с каким узлом устанавливать соединение
/ip ipsec policy
add src-address=192.168.1.0/24 src-port=any dst-address=192.168.2.0/24 dst-port=any tunnel=yes action=encrypt proposal=Office2-ike1 peer=Office2-ike1
Конфигурация IPsec для роутера офиса №2:
Конфигурация второго узла идентична первому, с соответствующими ip-адресами. Последовательность настройки выполняйте в таком же порядке.
Начните с настройки Profile и Proposal.
/ip ipsec profile
add hash-algorithm=md5 dh-group=modp2048 enc-algorithm=3des name=Office1-ike1
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=3des name=Office1-ike1 pfs-group=modp2048Затем добавьте Peer и Identity.
/ip ipsec peer
add address=10.1.100.1/32 name=Office1-ike1 profile=Office1-ike1
/ip ipsec identity
add peer=Office1-ike1 secret=MySecret!В завершении создайте Policy.
/ip ipsec policy
add src-address=192.168.1.0/24 src-port=any dst-address=192.168.2.0/24 dst-port=any tunnel=yes action=encrypt proposal=Office1-ike1 peer=Office1-ike1Ниже, на слайде, представлены все настройки IPsec второго узла в Winbox:
После настройки двух узлов установится туннельное соединение и на роутерах будут созданы связи IPsec Security Associations:
/ip ipsec
active-peers print
installed-sa print
Дополнительно можно проверить работу политик:
/ip ipsec
policy print status
IPsec туннель установлен. Можете проверить хождение трафика, пустив icmp-запрос (ping) с рабочей станции одной сети на рабочую станцию в другой сети.
This guide describes the following situation:
- VPN site-to-site tunnel using IPSec setup is created in MikroTik routers between two private networks: 10.10.10.0/24 and 10.10.20.0/24
- Both private networks use MikroTik router as a gateway
- Each MikroTik router is behind a NAT and have private network range on WAN ports as well: 192.168.10.0/24 and 192.168.20.0/24
- Each MikroTik router has IPSec NAT-Traversal (4500/UDP) forwarded from its gateway (ISP Router)
- Both public network connections change public IP occasionally
Some more remarks:
- I didn’t find any guide which would describe this setup, so I created one.
- Before the start, make sure that you have a separate access to each router, in case you will break your connection.
- Examples contain some additional security settings which can provide better security. Before you use or change these settings, make sure you know what you are doing.
- IPSec tunnel setup in examples uses pre-shared-key authentication method, which has been chosen only for demonstrative purpose and more secure method should be considered. In any case, make sure that if you are going to use PSK method then you need to use a different secret than the one in the examples – also don’t forget that the secret needs to be the same on both sides.
- Names of interfaces on MikroTik routers in this example are:
- WAN: ether1-gateway
- LAN: bridge-local
- I successfully tested the setup on 2x Mikrotik hAP lite classic devices, each running behind different routers ( in one case Draytek Vigor 2700 and Ubee EVW3226, in another case TP-Link TD-W8951NB and Compal CH7465LG )
- Also there is a lot of useful documentation about IPSec VPN on MikroTik Wiki – check it out.
Update 1:
- I have experienced tunnel instability when upload link ( provided by ISP ) has been overloaded and when IPSec tunnel was configured with AES GCM. This issue occurred for me at least on Router OS versions 6.38 – 6.39.1. Therefore I have updated the example to use AES CBC, which proved to be stable. But GCM is more secure than CBC, so I recommend to upgrade the RouterOS to the latest version and try with GCM at first.
Update 2:
- RouterOS 6.38 (2016-Dec-30) added IKEv2 support as key exchange mode for IPSec. This mode can be used to improve the security of the tunnel establishment, so I’ve updated the examples in this article accordingly. IKEv2 is also more recent and updated version of the key exchange mode than previously available modes. Except the security improvements, it has embedded the “dead peer detection” and “NAT traversal”, which makes the configuration easier. Additionally, IKEv2 NAT traversal ensures that if connection cannot be created directly between two peers, port 4500/UDP is used. Therefore in RouterOS firewall you need to allow only 4500/UDP.
- RouterOS 6.41 (2017-Dec-22) introduced possibility to use DNS name as IPSec peer address instead IP address. If you will use DNS names in /ip ipsec peer configurations, you can skip the respective part in ipsec-peer-update script mentioned later in this guide, but it is still required to update the IP address of sa-dst-address in IPSec policy, in case the remote router’s public IP has changed. Examples here do not use DNS names in IPSec peer addresses.
Update 3:
- RouterOS 6.43.12 (2019-Feb-11) moved the IPSec profile outside peer configuration and RouterOS 6.44 (2019-Feb-26) added the IPSec identity menu for peers. Therefore I’ve updated the IPSec configurations with versions before RouterOS 6.43.12 and after RouterOS 6.44.
Update 4:
- RouterOS since some version around 6.46 (2019-Dec-02) requires script policy permission “test” for DNS requests using :resolve command. Script and scheduler creation commands have been updated accordingly.
Update 5:
- Refresh on compatibility and features of long-term support version 6.47.9 (2021-02-09). Change to elliptic-curve crypto in some examples, if your non-Mikrotik peer does not connect, try to switch to RSA/DHmodp/smaller curves.
Update 6:
- To simplify the setup with new features available, this guide now:
- describes only requirements for IKEv2
- uses no dedicated script for update of peer’s IP address as peers already support hostnames
- uses no dedicated script for update of IPSec policy sa-dst-address as that is handled now differently by RouterOS
VPN Tunnel
IPSec tunnel will provide secure site-to-site VPN.
MikroTik router 1
/ip ipsec profile add name="secure-profile" hash-algorithm=sha512 enc-algorithm=aes-256,aes-128 dh-group=ecp521 peer add name="vpn01" comment="vpn01" address="router2.sn.mynetname.net" exchange-mode=ike2 profile=secure-profile identity add comment="vpn01" auth-method=pre-shared-key secret=REPLACE_THIS_WITH_RANDOM_SECRET peer=vpn01 proposal add name="secure-proposal" auth-algorithms=sha512 enc-algorithms=aes-256-gcm pfs-group=ecp521 policy add comment="vpn01" dst-address=10.10.20.0/24 src-address=10.10.10.0/24 tunnel=yes proposal=secure-proposal peer=vpn01
MikroTik router 2
/ip ipsec profile add name="secure-profile" hash-algorithm=sha512 enc-algorithm=aes-256,aes-128 dh-group=ecp521 peer add name="vpn01" comment="vpn01" address="router1.sn.mynetname.net" exchange-mode=ike2 profile=secure-profile identity add comment="vpn01" auth-method=pre-shared-key secret=REPLACE_THIS_WITH_RANDOM_SECRET peer=vpn01 proposal add name="secure-proposal" auth-algorithms=sha512 enc-algorithms=aes-256-gcm pfs-group=ecp521 policy add comment="vpn01" dst-address=10.10.10.0/24 src-address=10.10.20.0/24 tunnel=yes proposal=secure-proposal peer=vpn01
Firewall
If some rules are used in NAT tables, they need to exclude IPSec traffic, so they will not translate IP addresses in them. This is managed now in default configuration for masquerade rule by ipsec-policy=out,none. In case of manual configuration add this parameter to your masquerade rule. Alternatively you can exclude IPSec traffic by using IPSec accept rule before the NAT rules ( see NAT bypass on MikroTik Wiki for more info ). The same thing applies for a destination NAT ( known sometimes as port forwarding or DMZ host ) – in such case dstnat rules need ipsec-policy=in,none parameter or NAT bypass in opposite direction before them. Here are examples of NAT bypass rules in both directions.
MikroTik router 1
/ip firewall nat add comment="vpn01" action=accept chain=srcnat dst-address=10.10.20.0/24 src-address=10.10.10.0/24 place-before=0 nat add comment="vpn01" action=accept chain=dstnat dst-address=10.10.10.0/24 src-address=10.10.20.0/24 place-before=0
MikroTik router 2
/ip firewall nat add comment="vpn01" action=accept chain=srcnat dst-address=10.10.10.0/24 src-address=10.10.20.0/24 place-before=0 nat add comment="vpn01" action=accept chain=dstnat dst-address=10.10.20.0/24 src-address=10.10.10.0/24 place-before=0
In addition, IPSec IKE traffic needs to be allowed by firewall. For IKEv2 this traffic is 4500/UDP.
MikroTik router 1
/ip firewall filter add comment="ipsec-ike-natt" chain=input dst-port=4500 in-interface=ether1-gateway protocol=udp filter add comment="vpn01" chain=forward dst-address=10.10.10.0/24 in-interface=ether1-gateway ipsec-policy=in,ipsec src-address=10.10.20.0/24
MikroTik router 2
/ip firewall filter add comment="ipsec-ike-natt" chain=input dst-port=4500 in-interface=ether1-gateway protocol=udp filter add comment="vpn01" chain=forward dst-address=10.10.20.0/24 in-interface=ether1-gateway ipsec-policy=in,ipsec src-address=10.10.10.0/24
Public IP Change Adaptation
IP Cloud
IP Cloud is used as a dynamic DNS system for lookup of remote site’s public IP. This step can be skipped if different DDNS system is used. Time update via IP Cloud is disabled for a case when NTP is used, however you can enable it if necessary.
MikroTik router 1 and MikroTik router 2
/ip cloud set ddns-enabled=yes update-time=no
Afterwards, you can use following command to get dns-name value of a local router, which will be used in configuration of script on remote router:
/ip cloud print
IPSec Remote Address Update Script
This script is no longer needed, but it is kept here for a reference. In the past RouterOS could use only IPs in peer address configuration, so dynamically updated addresses needed to be updated – now hostnames are allowed. Additionally in the past IPSec policies required to have the sa-dst-address attribute updated with IP of remote peer as well – this is now updated automatically by RouterOS.
Following script updates IPSec peer address and policy SA destination address, if remote peer’s address has changed. Make sure to fill out correct peerid and peerhost variables:
- peerid: Identifies IPSec peer and policy records, which will get updated, by comment field value. In this example it is “vpn01”.
- peerhost: Remote router’s value of dns-name from IP Cloud setup. If different DDNS solution than MikroTik IP Cloud is used for remote site, enter remote DDNS hostname here. In this example it is “0123456789.sn.mynetname.net”. Be aware that peerhost is different for each router.
MikroTik router 1 and MikroTik router 2
/system script add name="ipsec-peer-update-vpn01" policy=read,write,test source=":local peerid \"vpn01\"\
\n:local peerhost \"0123456789.sn.mynetname.net\"\
\n:local peerip [:resolve \$peerhost]\
\n:local peeruid\
\n:set peeruid [/ip ipsec peer find comment=\"\$peerid\" and address!=\"\$peerip/32\"]\
\n:local policyuid\
\n:set policyuid [/ip ipsec policy find comment=\"\$peerid\" and sa-dst-address!=\"\$peerip\"]\
\n:if (\$peeruid != \"\") do={\
\n /ip ipsec peer set \$peeruid address=\"\$peerip/32\"\
\n :log info \"Script ipsec-peer-update updated peer '\$peerid' with address '\$peerip'\"\
\n}\
\n:if (\$policyuid != \"\") do={\
\n /ip ipsec policy set \$policyuid sa-dst-address=\"\$peerip\"\
\n :log info \"Script ipsec-peer-update updated policy '\$peerid' with address '\$peerip'\"\
\n}"
Schedulers
This scheduler periodically executes enforced update of IP Cloud DDNS IP. Enforced IP Cloud update is used, because MikroTik router behind NAT does not always check public IP in required intervals. Therefore by scheduler and enforced update, this interval is controlled.
Configured intervals should reflect how promptly routers will detect and process public IP change, but also they should avoid any excessive usage. In case of often VPN connection break downs, because of public IP changes, it should be considered to use static public IPs instead and thus avoid IP changes altogether.
MikroTik router 1 and MikroTik router 2
/system scheduler add disabled=yes interval=10m name=ip-cloud-forceupdate on-event="/ip cloud force-update" policy=read,write
As mentioned before, in the past, script was required to update IPSec addresses with remote DDNS IP. This is no longer the case, so creation of such scheduler is now skipped. Using this will rewrite the hostname set in peer’s configuration with IP address, so avoid setting this up if it is not necessary. The script execution scheduler looked like this:
/system scheduler add disabled=yes interval=1m name=ipsec-peer-update-vpn01 on-event="/system script run ipsec-peer-update-vpn01" policy=read,write,test
Netwatch and Route
Netwatch checks availability of remote MikroTik router’s LAN IP address. In case remote router is unavailable, Netwatch enables schedulers for update of IP Cloud DDNS IP and IPSec remote address (not needed anymore, so no longer present in this guide). When remote router is available again, schedulers are disabled back. Netwatch is not able to identify correct interface for remote router’s LAN IP, therefore route needs to be added as well. Make sure that gateway is set to your local router’s LAN interface or bridge.
MikroTik router 1
/ip route add comment="vpn01" distance=1 dst-address=10.10.20.0/24 gateway=bridge-local /tool netwatch add comment=ipsec-peer-update-vpn01 down-script="/system scheduler enable ip-cloud-forceupdate" host=10.10.20.1 up-script="/system scheduler disable ip-cloud-forceupdate"
MikroTik router 2
/ip route add comment="vpn01" distance=1 dst-address=10.10.10.0/24 gateway=bridge-local /tool netwatch add comment=ipsec-peer-update-vpn01 down-script="/system scheduler enable ip-cloud-forceupdate" host=10.10.10.1 up-script="/system scheduler disable ip-cloud-forceupdate"
Result
Netwatch on both Mikrotik routers should detect unavailability of remote router and trigger down-script, enforcing IP Cloud update. If public IP did not change since IP Cloud has been set up. When the tunnel is up, Netwatch will detect presence of remote router via VPN tunnel and disable schedulers, until next public IP change will break the tunnel and trigger the Netwatch again. While tunnel is up, hosts in both private networks can communicate with each other.