Настройка mikrotik ipsec: Настройка IPSec MikroTik to MikroTik: VPN туннель между офисами

Настройка IPSec MikroTik to MikroTik: VPN туннель между офисами

Сегодня речь пойдет о том, как настроить IPSec между двумя MikroTik и тем самым объединить VPN туннелем два офиса. Рассмотрим следующую схему, есть два маршрутизатора один в Москве другой Санкт Петербурге. Предполагается что оба роутера уже функционируют, раздают интернет на рабочие станции по средствам NAT masquerade.

Если вы хотите углубить свои знания по работе с роутерами MikroTik, то наша команда рекомендует пройти курсы которые сделаны на основе MikroTik Certified Network Associate и расширены автором на основе опыта . Подробно читайте ниже.

Конфигурирование устройств

Покажу все на примере одного роутера, так как настройки у них идентичны. Начинаем с настройки IPSec Peer. Вообще для поднятия туннеля достаточно добавить address, auth-method and secret но все по порядку. Идем в раздел IP-> IPSec вкладка Peers, добавляем новый элемент через плюс. Далее на первой вкладке изменим следующие параметры:

• Address – 192.168.13.27 (белый ip удаленного роутера)
• Auth. Method – метод авторизации, выбираем «pre shared key»
• Secret – пароль который должен быт одинаковый на обоих микротиках.

Здесь мы все закончили, сохраняем и переходим к добавлению политики шифрования. Данная настройка делается на вкладке Policies, добавляем новую и в разделе General пишем следующие:

• Src. Address – 10.1.202.0/24 (адрес локальной сети в Москве)
• Dst. Address – 10.1.101.0/24 (адрес локальной сети в Питере)

Здесь же на вкладке Action выбираем протокол шифрования и указываем SA для каждого микторика. Обязательно поставьте галочку Tunnel.

Сохраняем все и идем проверять установился ли IPSec туннель между городами. Посмотреть это можно в разделе Installed SAs. Если у вас примерно также как у меня, значить трафик шифруется и VPN работаем.

Настройка NAT для IPSec

На этом можно и попрощаться, но, если вы попробуете пингануть любое устройства в сети с Москвы в Питер, то скорее всего этого у вас не получится. Как же так спросите вы? А я отвечу, это связано с тем что оба маршрутизатора имеют правила NAT (masquerade), которые изменяют адрес источника перед шифрованием пакета (это можно посмотреть на диаграмме прохождения пакетов предоставляемой производителем). Mikrotik не может зашифровать трафик, поскольку адрес источника не соответствует адресу указанному в конфигурации политики. Чтобы это исправить нужно настроить правило обхода для туннеля.

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

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

На сегодня все, если будет вопросы задавайте их в нашей группе Телеграмм.

89 вопросов по настройке MikroTik

Вы хорошо разбираетесь в Микротиках? Или впервые недавно столкнулись с этим оборудованием и не знаете, с какой стороны к нему подступиться? В обоих случаях вы найдете для себя полезную информацию в курсе «Настройка оборудования MikroTik». 162 видеоурока, большая лабораторная работа и 89 вопросов, на каждый из которых вы будете знать ответ. Подробности и доступ к началу курса бесплатно тут.

Mikrotik. IPSEC vpn за NAT как клиент / Хабр

Доброго всем дня!

Так уж сложилось, что в нашей компании в течении последних двух лет мы потихоньку переходим на микротики. Основные узлы построены на CCR1072, а локальные точки подключения компов на устройствах попроще. Само собой существует и объединение сетей по IPSEC tunnel, в данном случае настройка достаточно проста и не вызывает никаких трудностей, благо есть множество материалов в сети. А вот с мобильным подключением клиентов есть определенные трудности, вики производителя подсказывает, как использовать Shrew soft VPN client (по этой настройке все вроде понятно) и именно этот клиент использует 99% пользователей удаленного доступа, а 1% это я, мне стало просто лень каждый раз вводить логин и пароль в клиент и захотелось ленивого расположения на диване и удобного подключения к рабочим сетям. Инструкций по настройки Микротика для ситуаций, когда он находится даже не за серым адресом, а совсем за черным и может быть даже несколькими NAT в сети я не нашел. Потому пришлось импровизировать, а потому предлагаю посмотреть на результат.

Имеется:

1. CCR1072 как основное устройство. версия 6.44.1
2. CAP ac как домашняя точка подключения. версия 6.44.1

Главная особенность настройки в том, что ПК и микротик должны находиться в одной сети с одной адресацией, что и выдается основым 1072.

Переходим к настройке:

1. Конечно включаем Fasttrack, но так как с впн fasttrack не совместим, то приходится вырезать его трафик.

/ip firewall mangle
add action=mark-connection chain=forward comment="ipsec in" ipsec-policy=\
    in,ipsec new-connection-mark=ipsec passthrough=yes
add action=mark-connection chain=forward comment="ipsec out" ipsec-policy=\
    out,ipsec new-connection-mark=ipsec passthrough=yes
/ip firewall filter add action=fasttrack-connection chain=forward connection-mark=!ipsec

2. Добавляем пробросы сетей из/в домашнюю и рабочую

/ip firewall raw
add action=accept chain=prerouting dst-address=192.168.33.0/24 src-address=\
    10.7.76.0/24
add action=accept chain=prerouting dst-address=192.168.33.0/24 src-address=\
    10.7.98.0/24
add action=accept chain=prerouting dst-address=10.7.76.0/24 src-address=\
    192.168.33.0/24
add action=accept chain=prerouting dst-address=10.7.77.0/24 src-address=\
    192.168.33.0/24
add action=accept chain=prerouting dst-address=10.7.98.0/24 src-address=\
    192.168.33.0/24
add action=accept chain=prerouting dst-address=192.168.33.0/24 src-address=\
    10.7.77.0/24

3. Создаем описание подключения пользователя

/ip ipsec identity
add auth-method=pre-shared-key-xauth notrack-chain=prerouting peer=CO secret=\
    общий ключ xauth-login=username xauth-password=password

4. Создаем IPSEC Proposal

/ip ipsec proposal
add enc-algorithms=3des lifetime=5m name="prop1" pfs-group=none

5. Создаем IPSEC Policy

/ip ipsec policy
add dst-address=10.7.76.0/24 level=unique proposal="prop1" \
    sa-dst-address=<white IP 1072> sa-src-address=0.0.0.0 src-address=\
    192.168.33.0/24 tunnel=yes
add dst-address=10.7.77.0/24 level=unique proposal="prop1" \
    sa-dst-address=<white IP 1072> sa-src-address=0.0.0.0 src-address=\
    192.168.33.0/24 tunnel=yes

6. Создаем IPSEC profile

/ip ipsec profile
set [ find default=yes ] dpd-interval=disable-dpd enc-algorithm=\
    aes-192,aes-128,3des nat-traversal=no
add dh-group=modp1024 enc-algorithm=aes-192,aes-128,3des name=profile_1
add name=profile_88
add dh-group=modp1024 lifetime=4h name=profile246

7. Создаем IPSEC peer

/ip ipsec peer
add address=<white IP 1072>/32 local-address=<ваш адрес роутера> name=CO profile=\
    profile_88

А теперь немного простой магии. Так как мне не очень хотелось менять настройки на всех устройствах в домашней сети, то надо было как-то повесить DHCP на туже сеть, но разумно, что Микротик не позволяет повесить более одного адресного пула на один bridge, потому нашел обходной вариант, а именно для ноутбука просто создал DHCP Lease с ручным указанием параметров, а так как netmask, gateway & dns также имеют номера опций в DHCP, то и их указал вручную.

1. DHCP Option

/ip dhcp-server option
add code=3 name=option3-gateway value="'192.168.33.1'"
add code=1 name=option1-netmask value="'255.255.255.0'"
add code=6 name=option6-dns value="'8.8.8.8'"

2. DHCP Lease

/ip dhcp-server lease
add address=192.168.33.4 dhcp-option=\
    option1-netmask,option3-gateway,option6-dns mac-address=<MAC адрес ноутбука>

При этом настройка 1072 является практически базовой, только при выдаче IP адреса клиенту в настройках указывается, что выдавать ему IP адрес введенный вручную, а не из пула. Для обычных клиентов с персональных компьютеров подсеть такая же, как в конфигурации с Wiki 192.168.55.0/24.

И немного добавлю, на основном сервере подключения 1072 необходимо также добавить в IP-Firewall-RAW правила для симметричного проброса сетей. При добавлении нового проброса сети необходимо добавить правила в IPSEC-Policy на клиенте, сервере, а также на сервере IP-Firewall-RAW и список вырезки из NAT.

Подобная настройка позволяет на ПК не подключаться через сторонний софт, а туннель сам поднимается роутером по мере необходимости. Нагрузка клиентского CAP ac практически минимальная, 8-11% при скорости 9-10МБ/с в туннеле.

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

IPIP IPsec VPN туннель между Linux машиной и Mikrotik за NAT провайдера / Хабр

upd: Отличный разбор про устройство современного стэка IPsec протоколов ESPv3 и IKEv2 опубликовал stargrave2. Рекомендую почитать.

Linux: Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-91-generic x86_64)

• Eth0 1.1.1.1/32 внешний IP
• ipip-ipsec0 192.168.0.1/30 будет наш туннель

Miktoik: CCR 1009, RouterOS 6.46.5

• Eth0 10.0.0.2/30 внутренний IP от провайдера. Внешний IP NAT провайдера динамический.
• ipip-ipsec0 192.168.0.2/30 будет наш туннель

IPsec туннель на Linux машине будем поднимать с помощью racoon. Не буду описывать подробности, есть хорошая статья у vvpoloskin.

Устанавливаем необходимые пакеты:

sudo install racoon ipsec-tools

Настраиваем racoon, он условно будет выступать в роли ipsec сервера. Так как mikrotik в main режиме не может передавать дополнительный идентификатор клиента, а внешний ip адрес через который он коннектится к Linux динамический, использовать preshared key (авторизацию по паролю) не получится, так как пароль должен сопоставляться либо с ip адресом подключающегося хоста, либо с идентификатором.

Будем использовать авторизацию по RSA ключам.

Демон racoon использует ключи в формате RSA, а mikrotik — в формате PEM. Если генерировать ключи утилитой plainrsa-gen идущей вместе с racoon, то конвертировать публичный ключ для Mikrotika в формат PEM с ее помощью не получится — она конвертирует только в одну сторону: PEM в RSA. Сгенерированный plainrsa-gen ключ не смогли прочитать ни openssl, ни ssh-keygen, поэтому с их помощью также не получится выполнить конвертацию.

Мы сгенерируем PEM ключ с помощью openssl, а затем конвертируем его для racoon с помощью plainrsa-gen:

#  Генерируем ключ
openssl genrsa -out server-name.pem 1024
# Извлекаем публичный ключ
openssl rsa -in server-name.pem -pubout > server-name.pub.pem
# Конвертируем
plainrsa-gen -i server-name.pem -f server-name.privet.key
plainrsa-gen -i server-name.pub.pem -f server-name.pub.key

Полученные ключи положим в папку: /etc/racoon/certs/server. Не забываем установить владельцем пользователя, от чьего имени запускается демон racoon (обычно root), права 600.

Настройку mikrotik опишу при подключении через WinBox.

Ключ server-name.pub.pem загрузим в mikrotik: Меню «Files» — «Upload».

Открываем раздел «IP» — «IP sec» — вкладка «Keys». Теперь генерируем ключи — кнопка «Generate Key», затем экспортируем публичный ключ mikrotika «Expor Pub. Key», скачать его можно из раздела «Files», правой кнопкой по файлу — «Download».

Импортируем публичный ключ racoon, «Import», в выпадающем списке поля «File name» ищем загруженный ранее нами server-name.pub.pem.

Публичный ключ mikrotik нужно сконвертировать

plainrsa-gen -i mikrotik.pub.pem -f mikrotik.pub.key

и положить в папку /etc/racoon/certs не забыв про владельца и права.

Конфиг racoon с комментариями: /etc/racoon/racoon.conf

log info; # Уровень логирования, при отладке используем Debug или Debug2.

listen {

    isakmp 1.1.1.1 [500]; # Адрес и порт, на котором будет слушать демон.
    isakmp_natt 1.1.1.1 [4500]; # Адрес и порт, на котором будет слушать демон для клиентов за NAT.
    strict_address; # Выполнять обязательную проверку привязки к указанным выше IP.
}

path certificate "/etc/racoon/certs"; # Путь до папки с сертификатами.

remote anonymous { # Секция, задающая параметры для работы демона с ISAKMP и согласования режимов с подключающимися хостами. Так как IP, с которого подключается Mikrotik, динамический, то используем anonymous, что разрешает подключение с любого адреса. Если IP у хостов статический, то можно указать конкретный адрес и порт.

    passive on; # Задает "серверный" режим работы демона, он не будет пытаться инициировать подключения.
    nat_traversal on; # Включает использование режима NAT-T для клиентов, если они за NAT. 
    exchange_mode main; # Режим обмена параметрами подключения, в данном случае ---согласование.
    my_identifier address 1.1.1.1; # Идентифицируем наш linux хост по его ip адресу.
    certificate_type plain_rsa "server/server-name.priv.key"; # Приватный ключ сервера.
    peers_certfile plain_rsa "mikrotik.pub.key"; # Публичный ключ Mikrotik.

    proposal_check claim; # Режим согласования параметров ISAKMP туннеля. Racoon будет использовать значения подключающегося хоста (инициатора) для срока действия сессии                   и длины ключа, если его срок действия сессии больше, или длина его ключа короче, чем у инициатора. Если срок действия сессии короче, чем у инициатора, racoon использует собственное значение срока действия сессии и будет отправлять сообщение RESPONDER-LIFETIME.
    proposal { # Параметры ISAKMP туннеля.

        encryption_algorithm aes; # Метод шифрования ISAKMP туннеля.
        hash_algorithm sha512; # Алгоритм хеширования, используемый для ISAKMP туннеля.
        authentication_method rsasig; # Режим аутентификации для ISAKMP туннеля - по RSA ключам.
        dh_group modp2048; # Длина ключа для алгоритма Диффи-Хеллмана при согласовании ISAKMP туннеля.
        lifetime time 86400 sec; Время действия сессии.
    }

    generate_policy on; # Автоматическое создание ESP туннелей из запроса, пришедшего от подключающегося хоста.
}

sainfo anonymous { # Параметры ESP туннелей, anonymous - указанные параметры будут использованы как параметры по умолчанию. Для разных клиентов, портов, протоколов можно              задавать разные параметры, сопоставление происходит по ip адресам, портам, протоколам.

    pfs_group modp2048; # Длина ключа для алгоритма Диффи-Хеллмана для ESP туннелей.
    lifetime time 28800 sec; # Срок действия ESP туннелей.
    encryption_algorithm aes; # Метод шифрования ESP туннелей.
    authentication_algorithm hmac_sha512; # Алгоритм хеширования, используемый для аутентификации ESP туннелей.
    compression_algorithm deflate; # Сжимать передаваемые данные, алгоритм сжатия предлагается только один.
}

Конфиг mikrotik

Возвращаемся в раздел «IP» — «IPsec»

Скорее всего у вас, как и у меня, на WAN интерфейсе настроен snat/masquerade, это правило надо скорректировать, чтобы исходящие пакеты ipsec уходили в наш туннель:

Переходим в раздел «IP» — «Firewall».

Вкладка «NAT», открываем наше правило snat/masquerade.

Рестартуем демона racoon

sudo systemctl restart racoon

Если при рестарте racoon не запускается, значит в конфиге имеется ошибка, в syslog racoon выводит информацию о номере строки, в которой обнаружена ошибка.

Демон racoon при загрузке ОС стартует раньше поднятия сетевых интерфейсов, а мы указали в секции listen опцию strict_address, необходимо добавить в файл systemd юнита racoon

/lib/systemd/system/racoon.service, в секцию [Unit], строку After=network.target.

Сейчас наши ipsec туннели должны подняться, смотрим вывод:

sudo ip xfrm policy

src 192.168.0.0/30 dst 192.168.0.0/30 
    dir out priority 2147483648 
    tmpl src 1.1.1.1 dst "IP NAT через который подключается mikrotik"
        proto esp reqid 0 mode tunnel
src 192.168.0.0/30 dst 192.168.0.0/30 
    dir fwd priority 2147483648 
    tmpl src "IP NAT через который подключается mikrotik" dst 1.1.1.1
        proto esp reqid 0 mode tunnel
src 192.168.0.0/30 dst 192.168.0.0/30 
    dir in priority 2147483648 
    tmpl src "IP NAT через который подключается mikrotik" dst 1.1.1.1
        proto esp reqid 0 mode tunnel

Если туннели не поднялись, смотрите syslog, либо journalctl -u racoon.

Теперь необходимо настроить L3 интерфейсы, чтобы можно было маршрутизировать трафик. Есть разные варианты, мы будем использовать IPIP, так как его mikrotik поддерживает, я бы использовал vti, но, к сожалению, в mikrotik его до сих пор не реализовали. От IPIP он отличается тем, что дополнительно может инкапсулировать multicast и ставить метки (fwmark) на пакеты, по которым можно их фильтровать в iptables и iproute2 (policy-based routing). Если нужна максимальная функциональность — тогда, например, GRE. Но не стоит забывать, что за дополнительную функциональность платим большим оверхедом.

Перевод неплохого обзора туннельных интерфейсов можно посмотреть тут.

На Linux:

# Создаем интерфейс
sudo ip tunnel add ipip-ipsec0 local 192.168.0.1 remote 192.168.0.2 mode ipip
# Активируем
sudo ip link set ipip-ipsec0 up
# Назначаем адрес
sudo ip addr add 192.168.0.1/30 dev ipip-ipsec0

Теперь можно добавить маршруты для сетей за mikrotik

sudo ip route add A.B.C.D/Prefix via 192.168.0.2

Чтобы наш интерфейс и маршруты поднимались после перезагрузки, нужно описать интерфейс в /etc/network/interfaces и там же в post-up добавлять маршруты, либо прописать все в одном файле, например, /etc/ipip-ipsec0.conf и дергать его через post-up, не забудьте про владельца файла, права и сделать его исполняемым.

Под катом пример файла

#!/bin/bash
ip tunnel add ipip-ipsec0 local 192.168.0.1 remote 192.168.0.2 mode ipip
ip link set ipip-ipsec0 up
ip addr add 192.168.0.1/30 dev ipip-ipsec0

ip route add A.B.C.D/Prefix via 192.168.0.2

На Mikrotik:

Раздел «Interfaces», добавляем новый интерфейс «IP tunnel»:

Раздел «IP» — «Addresses», добавляем адрес:

Теперь можно добавлять маршруты в сети за linux машиной, при добавлении маршрута, gateway будет наш интерфейс IPIP-IPsec0.

PS

Так как наш сервер linux является транзитным, то на нем имеет смысл задать параметр Clamp TCP MSS для ipip интерфейсов:

создаем файл /etc/iptables.conf со следующим содержимым:

*mangle
-A POSTROUTING -o ipip+ -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT

и в /etc/network/interfaces

post-up iptables-restore < /etc/iptables.conf

В сети за mikrotik у меня работает nginx (ip 10.10.10.1), делаем доступным его из интернета, добавим в /etc/iptables.conf:

*nat
-A PREROUTING -d 1.1.1.1/32 -p tcp -m multiport --dports 80,443 -j DNAT --to-destination 10.10.10.1
#На mikrotik, в таблице mangle, надо добавить правило route с назначением 192.168.0.1 для пакетов с адресом источника 10.10.10.1 и портов 80, 443.

# Так же на linux работает OpenVPN сервер 172.16.0.1/24, для клиентов которые используют подключение к нему в качестве шлюза даем доступ в интернет
-A POSTROUTING -s 172.16.0.0/24 -o eth0 -j SNAT --to-source 1.1.1.1
COMMIT 

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

Будьте здоровы!

Mikrotik IPsec и EoIP — объединяем офисы

Рано или поздно у админа возникает необходимость объединения офисов компании в единую сеть, причем офисы могут быть разбросаны по всей стране. Методов много. В этой статье я остановлюсь на одном из них: создадим туннель EoIP (Ethernet over IP) и зашифруем трафик с помощью IPsec. В качестве подопытных будут использоваться два Mikrotik’а RB493G.

Начальная настройка стендовых MikroTik

Конечно, для большей наглядности мне надо было взять три устройства, но считаю, что без этого можно и обойтись. В конце статьи опишу процесс масштабирования, который на самом деле довольно прост при понимании принципа работы такой схемы. Как было сказано выше, в качестве подопытных два Mikrotik RB493G, которые перед экспериментами были обновлены до последней (на момент написания статьи) прошивки 6.37.1 (как обновиться, читайте здесь). Подразумевается, что оба роутера находятся в пределах видимости друг друга — будь то реальные IP при подключении через интернет, либо это какая-то общественная локальная сеть (например, у вас несколько торговых точек и офис в торговом центре).

Роутеры будут называться M151-office — центральны офис и M152-remote1 — удаленный офис. На каждом роутере есть порт wan, который смотрит наружу. На этом же порту поднят VLAN, который будет эмулировать интерфейс, смотрящий внутрь сети. Зачем мне здесь понадобился интерфейс VLAN, станет понятно во время тестирования.

Начальная настройка микротика M151-office

Интерфейс v200-office vlanID=200 на интерфейсе wan.
Внешний IP — 192.168.10.151 на интерфейсе wan, внутренний — 192.168.200.1 на интерфейсе v200-office.

#
#
/interface vlan
add interface=wan name=v200-office vlan-id=200
/ip address
add address=192.168.10.151/24 interface=wan network=192.168.10.0
add address=192.168.200.1/24 interface=v200-office network=192.168.200.0

Начальная настройка микротика M152-remote1

Интерфейс v200-office vlanID=200 на интерфейсе wan.
Внешний IP — 192.168.10.152 на интерфейсе wan, внутренний — 192.168.200.2 на интерфейсе v200-office.

#
#
/interface vlan
add interface=wan name=v200-office vlan-id=200
/ip address
add address=192.168.10.152/24 interface=wan network=192.168.10.0
add address=192.168.200.2/24 interface=v200-office network=192.168.200.0

Туннель EoIP

Теперь нам надо создать туннель между нашими устройствами. Делается это также просто.

MikroTik M151-office

#
#
[admin@M151-office] > interface eoip
[admin@M151-office] /interface eoip> add name=tunnel-m152 tunnel-id=0 remote-address=192.168.10.152

MikroTik M152-remote1

#
#
[admin@M152-remote1] > interface eoip
[admin@M152-remote1] /interface eoip> add name=tunnel-m151 tunnel-id=0 remote-address=192.168.10.151

О работоспособности туннеля нам скажет буква R (running).

В консоли:

#
#
[admin@M152-remote1] > interface eoip print
Flags: X — disabled, R — running
0 R name=»tunnel-m151″ mtu=auto actual-mtu=1424 l2mtu=65535 mac-address=FE:21:B4:13:CD:2D arp=enabled arp-timeout=auto
loop-protect=default loop-protect-status=off loop-protect-send-interval=5s loop-protect-disable-time=5m
local-address=0.0.0.0 remote-address=192.168.10.151 tunnel-id=0 keepalive=10s,10 dscp=inherit clamp-tcp-mss=yes
dont-fragment=no allow-fast-path=yes
[admin@M152-remote1] >

В winbox:

Если вам такой проверки недостаточно, то можете присвоить туннельным интерфейсам на обоих роутерах адреса одной подсети и попинговать.

Настраиваем на MikroTik IPsec

Здесь все сводится к тому, что сначала мы укажем, что между такими-то точками трафик надо шифровать (policy), а затем укажем, как (peer).

MikroTik M151-office

#
#
[admin@M151-office] > ip ipsec policy
[admin@M151-office] /ip ipsec policy> add src-address=192.168.10.151 dst-address=192.168.10.152 sa-src-address=192.168.10.151 sa-dst-address=192.168.10.152 tunnel=no action=encrypt

[admin@M151-office] > ip ipsec peer
[admin@M151-office] /ip ipsec peer> add address=192.168.10.152 secret=vedernikoff.ru nat-traversal=no

MikroTik M152-remote1

#
#
[admin@M152-remote1] > ip ipsec policy
[admin@M152-remote1] /ip ipsec policy> add src-address=192.168.10.152 dst-address=192.168.10.151 sa-src-address=192.168.10.152 sa-dst-address=192.168.10.151 tunnel=no action=encrypt

[admin@M152-remote1] > ip ipsec peer
[admin@M152-remote1] /ip ipsec peer> add address=192.168.10.151 secret=vedernikoff.ru nat-traversal=no

Практически все параметры здесь по-умолчанию, а мы ввели только необходимые, чтобы наша схема заработала. Также необходимо настроить firewall на каждом роутере, добавив три правила (нет, четыре! Я упустил из внимания протокол GRE для поднятия туннеля. Спасибо читателю Павлу, указавшему на это):

#
#
/ip firewall filter
add action=accept chain=input dst-port=500 protocol=udp
add action=accept chain=input protocol=ipsec-esp
add action=accept chain=input protocol=ipsec-ah
add action=accept chain=input protocol=gre

Последние штрихи

Осталось объединить нужные интерфейсы в мосты и проверить работу.

MikroTik M151-office

Создадим мост office-bridge и добавим туда туннель и ранее созданный VLAN интерфейс v200office

#
#
/interface bridge
add name=office-tunnels
/interface bridge port
add bridge=office-tunnels interface=v200office
add bridge=office-tunnels interface=tunnel-m152

Как раз здесь я и поясную, зачем поднимал интерфейсы VLAN на портах wan обоих микротиков. Мне (и вам) они нужны для тестирования. Т.е. в физический внешний интерфейс wan кабель воткнут. Он работает. Соответственно работают и все поднятые на нем VLAN-интерфейсы. А так как я присвоил этим интерфейсам IP-адреса 192.168.200.1 в офисе и 192.168.200.2 в «удаленном» офисе, то мне этого будет достаточно для проверки. А увидит ли микротик центрального офиса внутреннюю сеть удаленого офиса, я узнаю пропинговав соответствующие адреса. Заодно посмотрю как тикает счетчик байтов в IPsec, подтверждая, что трафик шифруется. В дальнейшем эти айпишники не нужны, достаточно будет объединить нужные интерфейсы (внутренней сети и моста) в бридж.

MikroTik M152-remote1

#
#
/interface bridge
add name=office-tunnels
/interface bridge port
add bridge=office-tunnels interface=tunnel-m151
add bridge=office-tunnels interface=v200-office

Если все было сделано правильно, то вы должны увидеть такую картину на обоих ваших роутерах:

#
#
[admin@M151-office] > ping 192.168.200.2
SEQ HOST SIZE TTL TIME STATUS
0 192.168.200.2 56 64 1ms
1 192.168.200.2 56 64 1ms
2 192.168.200.2 56 64 1ms
3 192.168.200.2 56 64 1ms
4 192.168.200.2 56 64 1ms

#
#
[admin@M152-remote1] > ping 192.168.200.1
SEQ HOST SIZE TTL TIME STATUS
0 192.168.200.1 56 64 1ms
1 192.168.200.1 56 64 1ms
2 192.168.200.1 56 64 1ms
3 192.168.200.1 56 64 1ms
4 192.168.200.1 56 64 1ms

Если так, то поздравляю, мы построили прозрачную сеть, по которой будет бегать любой трафик, включая DHCP. Т.е. вы можете поставить один DHCP-сервер в центральном офисе и он будет вещать на все остальные офисы. Правда, с одной важной оговоркой: вы должны быть стопроцентно (нет, двестипроцентно) уверены в качестве связи, чего не скажешь про интернет. Но если ваши офисы (или точки продаж) расположены в одном здании — в торговом центре, например, то один настроенный DHCP-сервер в центральном офисе облегчит вашу нелегкую админскую жизнь.

Масштабирование

Как было обещано ранее, пару слов (а больше и не понадобится) о масштабировании. Суть проста: сейчас мы создали туннель tunnel-id=0, связывающий центральный офис и офис remote1. Теперь создаем новый туннель tunnel-id=1, который свяжет центральный офис с удаленным офисом2 (remote2, например). Так же настраиваете IPsec. Настройка роутера remote2 повторяет настройку remote1, а на центральном роутере надо будет добавить  tunnel-id=1 в ранее созданный бридж.

В заключение

IPsec — обширная тема, суть которой мы здесь в общем-то не затронули. В данной статье был рассмотрен частный случай объединения офисов с помощью MikroTik и применением IPsec и EoIP. А если вы любознательны и хотите знать больше о защите данных, то начните, как минимум, с Википедии. 🙂

До новых встреч!

Реклама:

Читайте также

настройка IPsec на автоматическое обновление адреса VPN сервера / Хабр

При настройке IPSec рано или поздно все сталкиваются с тем, что можно задать только IP-адреса удаленного VPN-сервера. Указание DNS-записей в настройках IPsec Policies и IPsec Peers не поддерживается.

Это может вызывать определенные неудобства в случаях, если на VPN-сервере:

• сменили одного провайдера на другого;
• решили изменить используемый статический IP-адрес;
• используется динамический (серый) IP-адрес.

Взяв даже простейшую схему, становится видно, что нам придется менять настройки трех роутеров-клиентов VPN-сервера:

И в каждом из трех роутеров сменить значения:

• IpSec/Policy/dst-address
• IpSec/Policy/sa-dst-address
• IpSec/Peer/address

В реальности, когда клиентов десятки и сотни, автоматизация этого процесса становится необходимостью. Рассмотрим, как это реализовать, используя стандартные возможности Microtik: DDNS, Scripts и Scheduler.

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

Включаем на обоих VPN-серверах DDNS, предоставляемый компанией. Mikrotik предоставляет DDNS как бесплатный сервис покупателям RouterOS.

ip cloud set ddns-enabled=yes

Другие поставщики DDNS

Я использую платный сервис DynECT от DynDNS, но схема работы от этого не меняется.

Можем увидеть результат: полученные A-записи в домене sn.mynetname.net, указывающие на наши VPN-серверы.

 > ip cloud print 
    ddns-enabled: yes
  public-address: 1.1.1.1
        dns-name: 111111111111.sn.mynetname.net
          status: updated

Переходим к роутерам, которые выступают клиентами.

В настройках IpSec/Policy и IpSec/Peer в комментарии к каждой строке подпишем DNS-имена VPN-серверов:

Далее добавляем скрипт SetIpSecDstAddrFromDns, который будет получать DNS-имена наших VPN-серверов из комментария и сравнивать их со значениями в настройках:

:if ([:len [/system script job find script=SetIpSecDstAddrFromDns]]>1) do={
  :error
}

:local DnsNameFromComment
:local ResolvedIpFromComment
:local ResolvedIpWithMaskFromComment

:local IpDstAddr
:local IpSaDstAddr


:foreach IpSecPolicyCount in=[/ip ipsec policy find] do={
  :set DnsNameFromComment [/ip ipsec policy get $IpSecPolicyCount comment]
  :if ($DnsNameFromComment!="") do={
    :do {
      :set ResolvedIpFromComment ([:resolve $DnsNameFromComment])
      :set ResolvedIpWithMaskFromComment ($ResolvedIpFromComment . "/32")
      :set IpDstAddr [/ip ipsec policy get $IpSecPolicyCount dst-address]
      :set IpSaDstAddr [/ip ipsec policy get $IpSecPolicyCount sa-dst-address]
      :if ($ResolvedIpWithMaskFromComment!=$IpDstAddr or $ResolvedIpFromComment!=$IpSaDstAddr) do={
        :log warning ("[SetIpSecDstAddrFromDns] Change IpSec policy dst-addr from " . $IpSaDstAddr . " to " . $ResolvedIpFromComment)
        /ip ipsec policy set $IpSecPolicyCount dst-address=$ResolvedIpWithMaskFromComment sa-dst-address=$ResolvedIpFromComment
      }
    } on-error={
      :set ResolvedIpFromComment "unknown"
      :log error ("[SetIpSecDstAddrFromDns] Cant resolve name " . $DnsNameFromComment)
    }
  }
}

:local IpPeerAddr
:foreach IpSecPeerCount in=[/ip ipsec peer find] do={
  :set DnsNameFromComment [/ip ipsec peer get $IpSecPeerCount comment]
  :if ($DnsNameFromComment!="") do={
    :do {
      :set ResolvedIpFromComment [:resolve $DnsNameFromComment]
      :set ResolvedIpWithMaskFromComment ($ResolvedIpFromComment . "/32")
      :set IpPeerAddr [/ip ipsec peer get $IpSecPeerCount address]
      :if ($ResolvedIpWithMaskFromComment!=$IpPeerAddr) do={
        :log warning ("[SetIpSecDstAddrFromDns] Change IpSec peer addr from " . $IpPeerAddr . " to " . $ResolvedIpFromComment)
        /ip ipsec peer set $IpSecPeerCount address=$ResolvedIpWithMaskFromComment
      }
    } on-error={
      :set ResolvedIpFromComment "unknown"
      :log error ("[SetIpSecDstAddrFromDns] Cant resolve name " . $DnsNameFromComment)
    }
  }
}

Добавляем задание в планировщик, которое будет каждые 30 секунд запускать скрипт и проверять, актуальны ли адреса наших VPN-серверов и обновлять их при необходимости.

Спасибо за внимание.

P. S. Статья не рассчитана на новичков, поэтому простейшие вещи, такие как настройка VPN-туннеля или описание скриптового языка Mikrotik, я опустил.

Настройка IPsec site-to-site VPN с Mikrotik

Для использования защищённого доступа к виртуальной инфраструктуре IaaS под управлением VMware vCloud Director рекомендуем использовать туннелирование трафика с помощью алгоритмов шифрования данных. В данной статье представлена информация по настройке IPsec site-to-site VPN.

Используемая топология:

Публичный IP в офисе — 91.10.20.254
Публичный IP vShield Edge — 109.248.46.105
Адресация используемая в облачной инфраструктуре — 10.50.100.0/24
Адресация используемая в офисе — 192.168.0.0/24

1. В разделе «Administration» перейдите в ваш виртуальный дата-центр. В появившемся меню настроек перейдите во вкладку «Edge Gateways». Выберите нужный «vShield Edge». Нажмите правой кнопкой мыши и в появившемся меню выберите опцию «Edge Gateway Services».

2. Откройте вкладку VPN и нажмите на «Enable VPN». Для смены IP-адреса с которого будет устанавливаться VPN-соединение, нажмите на кнопку «Configure Public IPs». Для создание нового VPN-соединения нажмите кнопку «Add».

3. В открывшемся окне настройте следующие параметры:

Для установки соединения с удалённой сетью, требуется настроить следующие параметры.

• Local Networks – указываем сеть в облачной инфраструктуре: 10.50.100.0/24

• Peer Networks – указываем офисную сеть: 192.168.0.0/24

• Local Endpoint – по умолчанию OutsideZone

• Local ID – 109.248.46.105

• Peer ID – 91.10.20.254

• Peer IP – 91.10.20.254

• Encryption protocol – алгоритм шифрования, для примера выбираем AES

• Shared key – общий секретный ключ;

Важно: по умолчанию используется PFS и DH group 2.

Для применения настроек нажмите кнопку ОК.

Настройка VPN для Mikrotik:

/ip ipsec proposal add name=TUNNEL-MCLOUDS auth-algorithms=sha1 enc-algorithms=aes-256 lifetime=1h pfs-group=modp1024
/ip ipsec policy add dst-address=10.50.100.0/24 proposal=TUNNEL-MCLOUDS sa-dst-address=109.248.46.105 sa-src-address=91.10.20.254 src-address=192.168.0.0/24 tunnel=yes protocol=255 action=encrypt level=require ipsec-protocols=esp priority=0
/ip ipsec peer add address=109.248.46.105/32 port=500 enc-algorithm=aes-256 lifetime=8h nat-traversal=no secret=#SECRET passive=no exchange-mode=main send-initial-contact=yes proposal-check=obey hash-algorithm=sha1 dh-group=modp1024 generate-policy=no dpd-interval=120 dpd-maximum-failures=5
/ip firewall filter
add chain=forward src-address=192.168.0.0/24 dst-address=10.50.100.0/24
add chain=forward src-address=10.50.100.0/24 dst-address=192.168.0.0/24

/ip firewall nat
add chain=srcnat src-address=192.168.0.0/24 dst-address=10.50.100.0/24 place-before=0
/ip ipsec export

Что нужно настроить что бы проходит трафик из ipsec за mikrotik? — Хабр Q&A

Если вопрос касается «чистого» IPSec, то:
— в нем нет маршрутизации, как таковой. Вся информация заложена в SAD и SPD. SPD — это закладка Policies в окне IPSec, SAD — закладка Installed SAs, она формируется динамически.
Что здесь нужно помнить:
IPSec проходит файрволл два раза. Для четкого понимания, как это все фурычет — всегда рекомендую вот эту картинку.
Разберем на пример моего домашнего роутера (RB450G), где 1.1.1.1 — мой внешний IP, 2.2.2.2 — внешний IP удаленной сети. Моя подсетка — 10.54.2.0/24, удаленная — 10.54.1.0/24
Самое первое — это настройка политик (policy). Именно политика решает — нужно данный пакет шифровать или нет?

/ip ipsec proposal
add auth-algorithms="" enc-algorithms=aes-256-gcm lifetime=1h name=proposal1
/ip ipsec policy
add comment="To Cat's Home main VPN" dst-address=10.54.1.0/24 proposal=proposal1 sa-dst-address=\
    2.2.2.2 sa-src-address=1.1.1.1 src-address=10.54.2.0/24 tunnel=yes

Что сделали:
Добавили proposal1, в котором в качестве алгоритма шифрования выбран ASES256 со счетчиком Галуа . Поскольку он самоаутентифицирующийся, отдельного алгоритма аутентификации задавать не надо. Замена ключей шифрования через каждый час.
Задали политику, согласно которой все пакеты в сеть 10.,54.1.0/24 от 10.54.2.0/24 будут превращены в пакеты протокола ESP от IP 1.1.1.1 до IP 2.2.2.2. Собственно это и есть наша «таблица маршрутизации».

/ip ipsec peer
add address=2.2.2.2/32 auth-method=rsa-signature certificate=\
    "RB2011 cert (SHA256) with key" comment="To Cat's Home main VPN" dpd-interval=\
    disable-dpd enc-algorithm=aes-256 hash-algorithm=sha256 lifetime=2h nat-traversal=no \
    proposal-check=strict remote-certificate="RB450G cert (SHA256)"

Что сделали:
Добавили пира — удаленный сервер. Аутентификация по сертификатам, шифрование AES256, повторный обмен ключами через 2 ч.
Теперь нужно настроить файрволл. Потому что как нарисовано на картинке, пакеты IPSec проходят его два раза.
Предположим я на компе с адресом 10.54.2.1 набираю команду «ping 10.54.1.1».
Пакет проходит таблицы mangle prerouting, nat prerouting, mangle forward, filter forward (и вот тут, если у Вас строгая фильтрация и нет правила, разрешающего трафик от 10.54.2.0/24 на 10.54.1.0/24, он и помрет), mangle postrouting, nat postrouting и уже готов отправиться на default gateway, но в этот момент ведро проверяет его по SPD — а не надо ли его зашифровать и переотправить? Ага, пакет подпадает под политику, значит мы его шифруем и преобразовываем. И пакет icmp от 10.54.2.1 на 10.54.1.1 шифруется и упаковывается в пакет esp от 1.1.1.1 на 2.2.2.2!
Вот здесь надо не забыть подстраховаться от NAT. Дело в том, что когда пакет проходил nat postrouting, общее правило

/ip firewall nat
add action=src-nat chain=srcnat out-interface=ether6 to-addresses=1.1.1.1

заменило IP источника, чтобы «обратный адрес» был уникальным и теперь пакет не подходит под политику. А не подходит под политику — не будет зашифрован, а пойдет по общим правилам маршрутизации. А default gateway роутера повертит пакет, повертит — да и скажет «ты кто такой? Давай, до свидания».
Чтобы избежать этого, нужно указать не трогать пакеты, к которым применима политика IPSec — пусть проходят за NAT неизменными, все равно их шифровать:

add chain=srcnat comment="Does not touch IPSec ESP packets to avoid break packets checksum" \
    ipsec-policy=out,ipsec log-prefix="NAT avoid" out-interface=ether6

Пошифрованный пакет ведро снова ренижектит в сетевой стек, он снова — уже в своем новом качестве — проходит mangle output, nat output, filter output (и вот тут, если нет разрешения на трафик в сторону 2.2.2.2 или на протокол esp, он и помрет), mangle postrouting, nat postrouting — и отправляется в тырнет на удаленную точку.

Предоплагаем, что с другой стороны роутер настроен таким же образом, то есть у него есть и своя SPD и свой список пиров. Что произойдет, когда пакет будет получен:
пакет пройдет mangle prerouting, nat prerouting, mangle input, filter input (и , если трафик от 1.1.1.1 или протокол esp не разрешен, то тут и помрет)…и уже готов к передаче на более верхние уровни OSI, но тут ведро проверяет — а не нужно ли его расшифровать? (и вот тут, если контрольная сумма не сходится — он и помрет). Если пакет подпадает под политику — он будет расшифрован и превратится из esp-пакета от 1.1.1.1 к 2.2.2.2 в icmp пакет от 10.54.1.1 к 10.54.2.1 — и будет заново помещен в сетевой стек. И заново пойдет mangle prerouting, nat prerouting, mangle forward, filter forward (и вот тут, если не разрешен трафик от 10.54.2.0/24 к 10.54.1.0/24 он и помрет), mangle postrouting, nat postrouting — и наконец-то попадет на выходной интерфейс туда, где у нас подключен 10.54.2.1.
Таблица маршрутизации (та, что в ведре) — не использовалась, весь трафик для роутеров выглядит локальным 🙂

Настройка IPSec MikroTik на MikroTik: VPN туннель между офисами

Сегодня речь пойдет о том, как настроить IPSec между двумя MikroTik и тем самым объединить VPN туннелем два офиса. Рассмотрим следующую схему, есть два маршрутизатора один в Москве другой Санкт-Петербург. Предполагается, что оба роутера уже функционируют, раздают интернет на рабочие станции по средствам NAT masquerade.

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

Конфигурирование устройств

Покажу все на примере одного роутера, так как настройки у нихны. Начинаем с настройки IPSec Peer. Вообще для поднятия туннеля достаточно добавить адрес, метод аутентификации и секрет, но все по порядку. Идем в раздел IP-> IPSec вкладка Peers, добавляем новый элемент через плюс. Далее на первую вкладку изменим следующие параметры:

• Адрес — 192.168.13.27 (белый ip удаленного роутера)
• Auth.Метод — метод авторизации, выбираем «предварительный общий ключ»
• Secret — пароль который должен быт одинаковый на обоих микротиках.

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

• Src. Адрес — 10.1.202.0/24 (адрес локальной сети в Москве)
• Dst. Адрес — 10.1.101.0/24 (адрес локальной сети в Питере)

Здесь же на вкладке Action выбираем протокол шифрования и указываем SA для каждого микторика.Обязательно поставьте галочку Tunnel.

Сохраняем все и идем проверять установился ли IPSec туннель между городами. Посмотреть это можно в разделе Установленные SA. Если у вас примерно также как у меня, значить трафик шифруется и VPN работаем.

Настройка NAT для IPSec

На этом можно и попрощаться, но, если вы попробуете пингануть любое устройство в сети с Москвы в Питер, то скорее всего этого у вас не получится. Как же так спросите вы? А я отвечу, это связано с тем, что оба маршрутизатора имеют NAT (маскарад), которые изменяют адрес источника перед шифрованием пакета (это можно посмотреть на диаграмме прохождения пакета данных предоставляемого правила).Mikrotik не может зашифровать трафик, поскольку адрес источника не соответствует указанному в конфигурации политики. Чтобы это исправить нужно настроить правило обхода для туннеля.

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

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

На сегодня все, если будут задавайте их в нашей группе Телеграмм.

89 вопросов по настройке MikroTik

Вы хорошо разбираетесь в Микротиках? Или впервые столкнулись с этим оборудованием и не знаете, с какой стороны к нему подступиться? В обоих случаях вы найдете для себя полезную информацию в курсе «Настройка оборудования MikroTik».162 видеоурока, большая лабораторная работа и 89 вопросов, на каждый из которых вы будете знать ответ. Подробности и доступ к началу курса бесплатно тут.

.

настройка IPsec на автоматическое обновление адреса VPN сервера / Хабр

При настройке IPSec рано или поздно все сталкиваются с тем, что можно задать только IP-адрес удаленного VPN-сервера. Примечание DNS-настроек в настройках Политики IPsec и Одноранговые узлы IPsec не поддерживается.

Это может вызвать неудобства в случаях, если на VPN-сервере:

• сменили одного провайдера на другое;
• решили изменить использование статического IP-адреса;
• используется динамический (серый) IP-адрес.

Взяв даже простейшую схему, становится видно, что нам придется менять настройки трех роутеров-клиентов VPN-сервера:

И в каждом из трех роутеров сменить значения:

• IpSec / Policy / dst-address
• IpSec / Политика / sa-dst-адрес
• IpSec / Peer / адрес

В реальности, когда клиентов десятки и сотни, автоматизация этого процесса становится необходимой. Рассмотрим, как это реализовать, используя стандартные возможности Microtik: DDNS, Scripts и Scheduler.

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

Включаем на обоих VPN-серверах DDNS, предоставляемый компанией. Mikrotik предоставляет DDNS как бесплатный сервис покупателям RouterOS.

  ip cloud set ddns-enabled = да
  

Другие поставщики DDNS

Я использую платный сервис DynECT от DynDNS, но схема работы от этого не меняется.

Можем увидеть результат: полученную A-записи в домене сн.mynetname.net , указывающие на наши VPN-серверы.

 > ip облачная печать
    ddns-включен: да
  публичный адрес: 1.1.1.1
        dns-имя: 111111111111.sn.mynetname.net
          статус: обновлено

  

Переходим к роутерам, которые выступают клиентов.

В настройках Политика IpSec / и IpSec / Peer в комментариях к каждой строке подпишем DNS-имена имен VPN-серверов:

Далее добавляем скрипт SetIpSecDstAddrFromDns , который будет получать наши DNS-серверы из комментариев и сравнивать их со значениями в настройках:

 : if ([: len [/ system script job find script = SetIpSecDstAddrFromDns]]> 1) do = {
  :ошибка
}

: местный DnsNameFromComment
: local ResolvedIpFromComment
: местный ResolvedIpWithMaskFromComment

: местный IpDstAddr
: местный IpSaDstAddr


: foreach IpSecPolicyCount in = [/ ip ipsec policy find] do = {
  : set DnsNameFromComment [/ ipsec policy get $ IpSecPolicyCount comment]
  : if ($ DnsNameFromComment! = "") do = {
    :делать {
      : set ResolvedIpFromComment ([: resolve $ DnsNameFromComment])
      : установить ResolvedIpWithMaskFromComment ($ ResolvedIpFromComment."/ 32")
      : установить IpDstAddr [/ ipsec policy get $ IpSecPolicyCount dst-address]
      : set IpSaDstAddr [/ ipsec policy get $ IpSecPolicyCount sa-dst-address]
      : if ($ ResolvedIpWithMaskFromComment! = $ IpDstAddr или $ ResolvedIpFromComment! = $ IpSaDstAddr) do = {
        : предупреждение журнала ("[SetIpSecDstAddrFromDns] Изменить dst-addr политики IpSec с". $ IpSaDstAddr. "на". $ ResolvedIpFromComment)
        / ip ipsec policy set $ IpSecPolicyCount dst-address = $ ResolvedIpWithMaskFromComment sa-dst-address = $ ResolvedIpFromComment
      }
    } при ошибке = {
      : set ResolvedIpFromComment "unknown"
      : ошибка журнала ("[SetIpSecDstAddrFromDns] Невозможно разрешить имя".$ DnsNameFromComment)
    }
  }
}

: местный IpPeerAddr
: foreach IpSecPeerCount in = [/ ip ipsec peer find] do = {
  : set DnsNameFromComment [/ ipsec peer получить комментарий $ IpSecPeerCount]
  : if ($ DnsNameFromComment! = "") do = {
    :делать {
      : set ResolvedIpFromComment [: resolve $ DnsNameFromComment]
      : set ResolvedIpWithMaskFromComment ($ ResolvedIpFromComment. "/ 32")
      : установить IpPeerAddr [/ ipsec peer получить адрес $ IpSecPeerCount]
      : if ($ ResolvedIpWithMaskFromComment! = $ IpPeerAddr) do = {
        : log warning ("[SetIpSecDstAddrFromDns] Изменить адрес однорангового узла IpSec с".$ IpPeerAddr. "к". $ ResolvedIpFromComment)
        / ipsec peer set $ IpSecPeerCount address = $ ResolvedIpWithMaskFromComment
      }
    } при ошибке = {
      : set ResolvedIpFromComment "unknown"
      : ошибка журнала ("[SetIpSecDstAddrFromDns] Невозможно разрешить имя". $ DnsNameFromComment)
    }
  }
}
  

Добавляем задание в планировщик, которое будет каждые 30 секунд, запускать скрипт и проверять, актуальны ли адреса наших VPN-серверов и обновлять их при необходимости.

Спасибо за внимание.

P. S. Статья не рассчитана на новичков, поэтому простейшие вещи, такие как настройка VPN-туннеля или описание скриптового языка Mikrotik, я опустил.

.

Mikrotik. IPSEC vpn за NAT как клиент / Хабр

Доброго всем дня!

Так уж сложилось, что в нашей компании за последние двух лет мы потихоньку переходим на микротики. Основные узлы построены на CCR1072, а локальные точки подключения компов на устройстве попроще. Само собой существует и объединение сетей по туннелю IPSEC, в данном случае настройка достаточно проста и не вызывает никаких трудностей, благо есть множество материалов в сети. А вот с мобильным подключением клиентов есть эти трудности, вики производитель подсказывает, как использовать Shrew soft VPN client (по этой настройке все вроде понятно) и именно клиент использует 99% пользователей удаленного доступа, а 1% это я, мне стало просто лень каждый ввести логин и пароль в клиент и захотелось ленивого расположения на диване и удобного подключения к рабочим сетям.Инструкций по настройке Микротика для ситуаций, когда он находится даже не за серым адресом, а совсем за черным и может быть даже через NAT в сети я не нашел. Потому что пришлось импровизировать, а потому предлагаю посмотреть на результат.

Имеется:

1. CCR1072 как основное устройство. версия 6.44.1
2. CAP ac как домашняя точка подключения. версия 6.44.1

Главная особенность настройки в том, что ПК и микротик должны находиться в одной сети с одной адресацией, что и выдается основым 1072.

Переходим к настройке:

1. Включаем конечно Fasttrack, так как с впн fasttrack не соответствует, то приходится учитывать его трафик.

  / IP firewall mangle
добавить action = mark-connection chain = forward comment = "ipsec in" ipsec-policy = \
    in, ipsec new-connection-mark = ipsec passthrough = да
add action = mark-connection chain = forward comment = "ipsec out" ipsec-policy = \
    out, ipsec new-connection-mark = ipsec passthrough = да
/ ip firewall filter add action = fasttrack-connection chain = forward connection-mark =! ipsec
  

2.Добавляем пробросы сетей из / в домашнюю и рабочую

  / ip firewall raw
добавить действие = принять цепочку = предварительная маршрутизация dst-address = 192.168.33.0 / 24 src-address = \
    10.7.76.0/24
добавить действие = принять цепочку = предварительная маршрутизация dst-address = 192.168.33.0 / 24 src-address = \
    10.7.98.0/24
добавить действие = принять цепочку = предварительная маршрутизация dst-address = 10.7.76.0 / 24 src-address = \
    192.168.33.0/24
добавить действие = принять цепочку = предварительная маршрутизация dst-address = 10.7.77.0 / 24 src-address = \
    192.168.33.0/24
добавить действие = принять цепочку = предварительная маршрутизация dst-address = 10.7.98.0 / 24 src-адрес = \
    192.168.33.0/24
добавить действие = принять цепочку = предварительная маршрутизация dst-address = 192.168.33.0 / 24 src-address = \
    10.7.77.0/24
  

3. Создаем описание подключения пользователя

  / ipsec identity
добавить auth-method = pre-shared-key-xauth notrack-chain = prerouting peer = CO secret = \
    общий ключ xauth-login = имя пользователя xauth-password = пароль
  

4. Создаем IPSEC Proposal

  / ip ipsec предложение
добавить код-алгоритмы = 3des, время жизни = 5м, имя = "prop1", pfs-group = none
  

5.Создаем IPSEC Policy

  / ipsec policy
добавить dst-address = 10.7.76.0 / 24 level = unique offer = "prop1" \
    sa-dst-address = <белый IP 1072> sa-src-address = 0.0.0.0 src-address = \
    192.168.33.0/24 туннель = да
добавить dst-адрес = 10.7.77.0 / 24 уровень = уникальное предложение = "prop1" \
    sa-dst-address = <белый IP 1072> sa-src-address = 0.0.0.0 src-address = \
    192.168.33.0/24 туннель = да
  

6. Создаем профиль IPSEC

  / ipsec profile
установить [найти по умолчанию = да] dpd-interval = disable-dpd enc-algorithm = \
    aes-192, aes-128,3des nat-traversal = нет
добавить dh-group = modp1024 enc-algorithm = aes-192, aes-128,3des name = profile_1
добавить name = profile_88
добавить dh-group = modp1024 life = 4h name = profile246
  

7.Создаем IPSEC peer

  / ipsec peer
добавить адрес = <белый IP 1072> / 32 local-address = <ваш адрес роутера> name = CO profile = \
    profile_88
  

А теперь немного простой магии. Так как мне не очень хотелось менять настройки на всех устройствах в домашней сети, то надо было как-то повесить DHCP на туже сеть, но разумно, что Микротик не позволяет повесить более адресного пула на один мост, потому что нашел обходной вариант, а именно для ноутбука просто создал DHCP Lease с указанием параметров, а также имеют сетевую маску, шлюз и DNS, а также номера опций в DHCP, то и их указанными вручную.

1. Опция DHCP

  / ip dhcp-server option
добавить код = 3 name = option3-gateway value = "'192.168.33.1'"
добавить код = 1 имя = option1-netmask value = "'255.255.255.0'"
добавить код = 6 name = option6-dns value = "'8.8.8.8'"
  

2. Аренда DHCP

  / ip dhcp-server аренда
добавить адрес = 192.168.33.4 dhcp-option = \
    option1-netmask, option3-gateway, option6-dns mac-address = 
  

При этой настройке 1072 является основным, только при выдаче IP-адреса клиенту в настройках указывается, что выдавать ему IP-адрес вводится вручную, а не из пула.Для обычных клиентов с помощью компьютеров подсеть такую ​​же, как в конфигурации с Wiki 192.168.55.0/24.

И немного добавлю, на основном сервере подключения 1072 необходимо также добавить правила IP-Firewall-RAW для симметричного проброса сетей. При добавлении нового проброса сети необходимо добавить правила в IPSEC-Policy на клиенте, сервере, а также на сервере IP-Firewall-RAW и список вырезок из NAT.

Подобная настройка позволяет на ПК не подключаться через сторонний софт, а туннель сам поднимается роутером по мере необходимости.Нагрузка клиентского CAP ac практически минимальная, 8-11% при скорости 9-10МБ / с в туннеле.

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

.

Создание отказоустойчивого IPSec VPN-туннеля между Mikrotik RouterOS и Kerio Control / Хабр

Начиная с версии 8.1 Kerio Control для создания туннелей VPN можно использовать не только пропиетарный протокол Kerio VPN, но и вполне себе расово правильный IPSec. И конечно же мне сразу захотелось скрестить Mikrotik и Kerio Control.

В этой статье я расскажу о нескольких схемах подключения. Итак, схема первая.

Объединение двух подсетей. Это просто.

И сразу маленькое лирическое отступление на тему направления установки соединения.Т.е. какой из концов туннеля принимает, а какой запускает соединение VPN. Схема, когда Kerio Control запускает подключение для упрощения отказоустойчивости VPN туннелей в случае использования Kerio Control и Mikrotik нескольких интерфейсов WAN. Подробно на этом я остановлюсь в четвертой части этой статьи. Во всех случаях я буду использовать аутентификацию по предопределенному ключу (паролю).

Для подключения про протокол IPsec между Kerio Control и Mikrotik RouterBoard на RouterOS 6.1 на стороне Control создать новый туннель IPsec с настройками:

• Общие необходимо параметры. Активный режим (Control запускает подключение к Mikrotik). Ведите IP-адрес или DNS имя внешнего интерфейса Mikrotik. В примере — 109.172.41.XXX
• Аутентификация. Предопределенный ключ. Введите надежный пароль.
• Локальный ИД. Произвольное имя шлюза Control или внешний IP-адрес Control.В примере — drgs1-gtw02
• Отдаленный ИД. Внешний адрес Mikrotik. Если адрес WAN-интерфейса Mikrotik отличается от внешнего адреса — укажите адрес WAN-интерфейса в Mikrotik. Классический пример, когда провайдер выдает сетевой интерфейс Mikrotik IP-адрес по DHCP из своей серой локальной сети, на который пробрасывает пакеты приходящие на выданный вам внешний статический IP-адрес. В этой статье описан именно такой вариант. Поэтому в примере 10.48.113.102.
• Удаленные сети. Укажите сеть \ маску локализации подсети за Mikrotik. Например 192.168.88.0/24.
• Локальные сети. Укажите сеть \ маску локализации подсети за Kerio Control. Например 192.168.10.0/24.

Для настройки туннеля на стороне Mikrotik необходимо подключиться к роутеру через Winbox и добавить правила фаервола, разрешающие IKE, IPSec-esp, IPSec-ah или временно для отладки весь трафик UDP (очень не советую разрешать весь трафик UDP). как минимум) в цепочке ввод.Для этого в окне терминала необходимо выполнить следующие команды:

/ ip firewall filter add chain = input comment = "Allow IKE" dst-port = 500 protocol = udp
/ ip firewall filter add chain = input comment = "Разрешить IPSec -esp "protocol = ipsec-esp
/ ip firewall filter add chain = input comment =" Allow IPSec-ah "protocol = ipsec-ah
/ ip firewall filter add chain = input comment =" Разрешить протокол UDP " = udp

Результат выполнения команды будут добавленные правила фильтра фаервола.Думаю, что всем это очевидно, но для начинающих отмечу, что эти правила должны находиться выше запрещающих правил в цепочке ввод. В моем примере выше правила с номером 13.

Далее необходимо отредактировать (или создать) политику шифрования (Proposals) в настройке IPsec. Приведите свои настройки в соответствие с рисунком или выполните в окне терминала команду, указанную ниже.

Это команда, редактирующая существующее значение политики. В случае, если у вас в предложении нет никаких значений по умолчанию (пусто вообще, нет ни одного) их необходимо создать в соответствии с рисунком.И в этом случае команду выполнять не нужно .

/ ipsec набор предложений [найти по умолчанию = да] enc-алгоритмы = 3des, aes-128 pfs-group = none

Нам необходимо настроить одноранговый узел и на этом остановимся особо. Нужно заметить, что в ОС маршрутизатора версии выше 6.0 изменились некоторые настройки, касаемые одноранговых узлов IPsec и политик IPSec. В частности, в настройке Peers добавлены новые опции. Теперь для Peer можно указать инициирует Mikrotik или принимает (аналог пассивный \ активный подключение в Kerio Control).Нюанс состоит в том, что параметр «пассивный» нельзя установить через графический интерфейс. Его нет ни в Winbox, ни вебсе интерфейс управление роутером. По умолчанию, при создании однорангового узла через Winbox — он активным и начинает непрерывно пытаться установить подключение по адресу указанному в его настройке. Поэтому для создания пассивного конца нашего туннеля необходимо запустить именно CLI и в окне выполнить команду где вместо «пароль» необходимо указать предопределенный ключ, который вы указали на стороне Kerio Control при его настройке.

/ ip ipsec peer add address = 109.172.42.XXX / 32 dh-group = modp1536 exchange-mode = main-l2tp generate-policy = port-override hash-algorithm = sha1 passive = yes secret = password

Результатом выполнения команды будет созданный партнер, ожидающий подключения. В случае, если ваши WAN-интерфейсы находятся за провайдером — установите чекбокс NAT-Travesal

При настройке Peer мы указали параметр автоматической генерации политик IPsec. Поэтому нам не требуется создавать ничего в / ip ipsec policy.Необходимые стратегии создания автоматического после установление. В случае если вы не забыли в настройке туннеля в Kerio Control его включить — это произойдет сразу же, после добавления peer-а.
После этого туннель на стороне Kerio Control должен перейти в статус «Подключено». В Mikrotik на закладке «Политики» должны появиться автоматически созданные политики для подсетей, которые указываются при настройке Kerio Control в «Удаленные сети» и «Локальные сети». В «установленных SA» вы увидите, что ваши концы туннелей «подружились» и наконец в «Remote Peers» вы увидите статус подключения.

Туннель установлен. Но для прохождения трафика между подсетями за Kerio Control и Mikrotik необходимо добавить в правила NAT фаервола правило, которое не позволит замаскарадиться трафику, который вы отправляете в туннель. Если вы не сделаете этого правила — сети дружить не будут, даже если туннель будет установлен. Для этого в окне терминала необходимо выполнить команду:

/ ip firewall nat add chain = srcnat dst-address = 192.168.10.0 / 24 src-address = 192.168.88.0 / 24

Важно! Правило должно стоять выше правил маскарадинга. Т.е быть самым верхним в списке правил NAT.

После этой связи по внутренним адресам между подсетями 192.168.88.0/24 и 192.168.10.0/24 должна работать. На этом настройка туннеля между двумя подсетями окончена. Но это было просто. Дальше интереснее…

Объединение сети за Mikrotik и нескольких сетей VPN за Kerio Control

Рассмотрим более сложный вариант, когда предоставляется доступ к сети для Mikrotik к локальным сетям за Kerio Control, подключенным к центральному офису при помощи других VPN туннелей по протоколу Kerio VPN (например).Примерная схема отражена на рисунке ниже.

Казалось бы, чего проще? Для настройки VPN-туннеля в Kerio Control необходимо всего лишь в списке «Локальные сети» добавить список всех подсетей, к которому необходимо получить доступ из локальной сети за Mikrotik и головной офис которых уже знает. И соответственно расширены адреса в правиле NAT в Mikrotik, которые не будут маскарадиться, например, создав группу таких адресов в «Список адресов» и указав эту группу в назначении правил.

Добавляем, переустанавливаем туннель. Видим, что туннель установился, в политики IPsec весело добавились автоматические политики для всех подсетей, которые мы указали в настройке туннеля на стороне Kerio Control. В установленных SA видимых SA для всех подсетей. Бинго? А не тут то было…

Вдумчивое курение интернетов на тему IPseс в Mikrotik и объединение локальных сетей за разными типами роутеров дало понимание, что при такой схеме у всех проблема однотипная — невозможно объяснить Mikrotik куда именно слать пакеты.Практически на всех типах роутеров IPSec туннель — это отдельный сетевой интерфейс, что логично. Но не в Mikrotik, и поэтому определить для него маршрут прохождения пакетов в удаленную подсеть невозможно. На практике в связке с управлением Kerio — Mikrotik упорно слал пакеты через последний добавленный SAs. Пакеты честно приходили в центральный офис и там отбрасывались Kerio Control. Ни в одной статье я не нашел объяснения логики поведения Mikrotik в таком случае. Я перепробовал все, кажется, возможные варианты с одинаковым результатом.С нулевым. Связь была только с одной подсетью — с последней автоматически добавленной при установке туннеля.

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

Если Mikrotik отлично работает с одной подсетью в политике IPSec, то нам необходимо логически объединить наши подсети за маской подсети Kerio Control.Т.е. агрегировать подсети за Kerio Control в одну. Адреса в подсетях 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24 и 192.168.40.0/24 будут в пределах одной подсети 192.168.0.0/18, добавим именно эту подсеть в список «Локальные сети» при настройке туннеля в Kerio Control и установим туннельное соединение. Mikrotik создаст единственную политику IPsec и создаст единственные SA. Теперь он просто не сможет ошибиться куда слать пакеты. Проверка пингом должна показать доступность всех подсетей для Control для сети Mikrotik.Если вы проверяете доступность по ICMP с Mikrotik — , вы должны запустить ping не с интерфейсом WAN, а с бриджа, например . Это очень распространенная ошибка, которая приводит к стенаниям в стиле ЧТЯДНТ, ничего не работает, мы все умрем, лапы ломит и хвост отваливается, спасите-помогите.

Для обратного прохождения пакетов из удаленных сетей VPN в сеть за Mikrotik необходимо добавить аналогичные правила в Mikrotik, которое не позволяет маскарадиться пакетам, отправленным в туннель.Т.к. Через весь трафик в сети за Mikrotik из сетей VPN проходит через интерфейс центрального филиала VPN, через который мы обманываем правила трафика, которые бы обманывали Mikrotik, подменив источник с VPN на адресе из подсети, о которой Mikrotik знает. Правила на рисунке. Адрес 192.168.10.2 — внутренний адрес шлюза центрального офиса.

После этого обмена трафиком между подсетями пойдет во все стороны.

Теперь о недостатках этого метода. При такой схеме невозможно выдать форму сети «маршруты» (я намерено беру слово в кавычки, т.к. в реальности никаких привычных для понимании маршрутов в таблице маршрутизации Mikrotik в удаленных подсети нет вообще) только для конкретных удаленных подсетей, подключенных к головному офису. Теоретически существует возможность объединить адреса в удаленных подсетях в одну при помощи маски. Т.к. они могут находиться вообще в разных классах сетей. В связи с тем, что вам понадобится использовать другие адреса из диапазона этого диапазона IPSec туннеле, что будет невозможно. Внимание , если ваш адрес Mikrotik попадает в этот диапазон (!!!) то установка туннеля приведет к тому, что вы потеряете связь с Mikrotik. В этом случае зайдите на него через Winbox по адресу MAC и отключите туннель или отключите его на стороне Kerio Control. После этого или оказывает локальный адрес Mikrotik за пределы диапазона, который он получает от Contol при установке VPN туннеля или это (т.е. вариант с агрегацией локальных сетей за Kerio Control) не ваш случай.

В общем я бы сказал, что решение кривое до нельзя.Кривое, но рабочее. В уже существующей инфраструктуре, возможно, придется перепиливать локальные адреса подсетей. Но разработчики RouterOS не оставили мне выбора. Добавление интерфейса для IPSec в хотелках, насколько я знаю, уже давно. На русскоязычных форумах неоднократно видел петиции к разработчикам, полные слез и отчаяния.

Используем роутер Mikrotik в качестве клиента VPN

Использование Mikrotik как клиента даст возможность забыть о плясках с IPSec и маршрутизацией не маршрутизируемого.Но имейте ввиду, что доступа к сети за Mikrotik со стороны локальной сети за Kerio Control не будет. И это логично. Учтите, что т.к. Kerio Control лицензируется на подключения в том числе и клиентов VPN — такой тип подключения уменьшает счетчик лицензированных подключений на единицу. Ну или если по-простому — использует одну лицензию на подключение.

Здесь все предельно просто. Создадим пользователя в Kerio Control или отредактируем существующего. На закладке «Права» установим чекбокс «Пользователи могут подключаться через VPN».

Правила трафика добавляем правило позволяющее подключаться к Kerio Control по протоколу L2TP из интернета или можете ограничить источник списком доверенных адресов. На рисунке у меня позволено подключение только для списка доверенных адресов удаленных администраторов.

На стороне Mikrotik необходимо добавить новый интерфейс L2TP Client, выполнив команду в окне терминала:

add comment = "L2TP VPN Client" connect-to = 109.172.42.XXX disabled = no max-mru = 1460 max-mtu = 1460 name = INTERFACE-NAME пароль = пароль user = username

Значения адреса, имени интерфейса, имени и подключения пароля вам необходимо заменить на свой Kerio Control, свое произвольное имя интерфейса и свой логин \, который создали или отредактировали в настройках пользователя. Результатом выполнения команды должен быть новый созданный интерфейс, который немедленно установит соединение с сервером.

В списке адресов Mikrotik появится новый адрес, динамически выданный ему VPN-сервером Kerio Control.

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

/ ip route add comment = "Route to 192.168.20.0/24" distance = 1 dst-address = 192.168.20.0 / 24 gateway = INTERFACE -NAME
/ ip route add comment = "Маршрут до 192.168.30.0/24" расстояние = 1 dst-адрес = 192.168.30.0 / 24 gateway = INTERFACE-NAME
/ ip route add comment = "Route to 192.168.40.0/24" distance = 1 dst-address = 192.168.40.0 / 24 gateway = INTERFACE-NAME

Результатом будут добавленные статические маршруты в удаленные подсети за Kerio Control через интерфейс VPN.

Теперь добавим правило маскарадинга в Mikrotik. Для этого в окне терминала выполним команду:

/ ip firewall nat add action = masquerade chain = srcnat out-interface = INTERFACE-NAME src-address = 192.168.88.0 / 24

На этом все доступе из локальной сети Mikrotik в сети за Kerio Control и во все сети, подключенные к нему по другим VPN туннелям должен быть. Не забудьте исправить мои значения в командух на свои.

Обеспечение отказоустойчивости туннеля VPN

Ну и на закуску самое сладкое. Обещанный рассказ про организацию отказоустойчивости туннелей. До версии Kerio Control 8.1 в настройке активного подключения нельзя было указать больше одного адреса принимающего конца туннеля, поэтому для обеспечения отказоустойчивости VPN туннелей я бы голосовал за схему, когда Kerio Control в центральном офисе именно принимает подключение.В этом случае отказоустойчивость можно было бы обеспечить мониторинг входящего канала центрального офиса и автоматической смены единственного DNS имени, на который филиалы устанавливают подключения. Я использую этот сервис DynDNS и систему мониторинга PRTG Network Monitor. Краткая суть метода такова. При помощи PRTG проверяется доступность каналов центрального офиса и в случае, если фиксируется падение канала, который филиалы устанавливает подключение, через API DynDNS, PRTG автоматически меняет DNS-имя, зарегистрированное на сервисе DynDNS на которое филиалы устанавливают соединение, дергая ссылку в интернете.Метод рабочий 146%. Проверен у меня на более чем полусотне туннелей подключенных к центральному офису классической звездой. В случае восстановления можно изменить IP адрес обратно, можно оставить как есть. Тут как пожелаете.

Казалось бы, что мешает в случае с Mikrotik сделать также? Но и тут подножка от RouterOS. В настройках однорангового узла вы хоть и сможете указать DNS имя принимающего конца туннеля, но при сохранении оно будет отрезано и записано как IP-адрес. В таком случае придется изобретать скрипты, которые будут мониторить каналы (вместо PRTG) на Kerio Control и настроить одноранговый канал в случае, если текущий канал, который устанавливается, становится недоступным.Плюс масса плясок с политиками IPSec. И это видится мне жуткой головомойкой.

Теперь же Kerio Control сам замечательно умеет обеспечивать отказоустойчивость в случае, если сам инициирует подключение, в настройке туннеля можно указать несколько адресов (или DNS) имен принимающего конца туннеля. Таким образом, создается на стороне Mikrotik два партнера, принимающих подключение, можно добиться желанной отказоустойчивости. Ну, погнали наши городские… Примерная схема отображена на рисунке. Необходимо живучесть туннеля при падении любого интерфейса WAN на Kerio или ISP на Mikrotik (названы по-разному обеспечению во избежание путаницы).

Начнем с настройки Mikrotik. Т.к. Он не умеет понимать имена DNS в значении адресов настроек одноранговых узлов IPsec, чтобы нам пришлось создать два пира, для обоих интерфейсов WAN центрального офиса. Для этого перейдем в окно терминала и введем команду, заменив значения адресов и предопределенный ключ на свои:

/ ipsec peer add address = 109.172.42.XXX / 32 dh-group = modp1536 exchange-mode = main-l2tp generate- policy = port-override hash-algorithm = sha1 nat-traversal = yes passive = yes secret = PASSWORD
/ ipsec peer add address = 95.179.13.YYY / 32 dh-group = modp1536 exchange-mode = main-l2tp generate-policy = port-override hash-algorithm = sha1 nat-traversal = yes passive = yes secret = PASSWORD

Я обращаю ваше внимание, что если вы уже создавали одноранговый узел по приведенной в предыдущих частях статьи и решили вместо CLI использовать Winbox и скопировать уже созданный до однорангового узла, чтобы настроить пассивный (та самая, которая инициирует или принимает Mikrotik подключения) — не копируется. На этом этапе я рекомендую использовать различные инструменты командной строки.Результатом выполнения двух команд должно быть успешное создание ожидающих подключения со стороны Kerio Control.

Но этого мало. При падении WAN1 на Kerio Control туннель успешно переустановится, а вот если упадет ISP1 канал на Mikrotik, то в таком случае «удаленный ИД» настроек туннеля в Kerio Control, в котором указывали серый провайдерский IP на ISP интерфейсе Mikrotik — не совпадение с реальным. . И мы вместо успешного переподключения получим милую ошибку в консоли администрирования Kerio Control — «Несовпадение ИД».

Засада? Засада… И я почти отчаялся, потому что фонтан мыслей иссяк, я решительно не понимал, как автоматизировать смену этого ИД. Поколдовал с файлами, но безуспешно. Пришло время вспомнить слова одного умного дядьки с уже, наверняка, совсем седой задницей, который в мохнатом еще году говорил мне — если ничего не помогает, то самое время заглянуть в мануалы и логи. Ну… мануалы — это не про нас (здесь гомерический хохот автора), полез в журнал отладки Kerio Control, добавив в него все сообщения, касаемые IPSec.Что я могу сказать — ищущий, да обрящет. В нашем случае, когда параметр «удаленный ИД» может динамически изменяться в зависимости от того, к какому IP адресу подключается туннель — в настройках туннеля Kerio Control можно в удаленном ИД указать значение «% any».
В именах хостов введен через точку с запятой все адреса ISP1 И ISP2 на Mikrotik и значение «% любой» в «Удаленный ИД» как на рисунке ниже.

Сохраняем, применяем, счастливыми глазами смотрим на изменившийся статус туннеля на «Подключено» и приступаем к проверке.Эмулируем падение основного канала на Kerio Control сменой мест и основного канала — туннель переподключился и живой. Эмулируем падение основного канала на Mikrotik выдергиванием из него шнурка провайдера. Пока Kerio Control осилил, что туннеля уже нет — прошло около двух минут, но он все таки увел VPN на резерв. Бинго!

Все эксперименты проводились на Kerio Control 8.1 и RouterOS 6.1. Названия и настроек ROS в командах терминала, приведенные здесь, соответствуют этой версии (6.1). На сегодняшний день версия 6.10 имеет несколько измененных названий настроек, но при минимальном тюнинге все работает и на текущих версиях Kerio Control 8.2 и RouterOS 6.10. Все вышесказанное может быть чуть меньше, чем бредом сумасшедшего ИТ-ишника, я не претендую на правильную формулировку и определений и с удовольствием приму замечания и рекомендации, ведь Mikrotik для меня зверушка новая и загадочная, в отличии от Kerio Control, который почти прочитанная книга.

.