Начиная с версии 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 — заюзают как форвардер DNS запросов злые люди, как минимум) в цепочке input. Для этого в окне терминала необходимо выполнить следующие команды:
/ip firewall filter add chain=input comment="Allow IKE" dst-port=500 protocol=udp
/ip firewall filter add chain=input comment="Allow 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="Allow UDP" protocol=udp
Результатом выполнения команды будут добавленные правила фильтра фаервола. Думаю, что всем это очевидно, но для начинающих отмечу, что эти правила должны находиться выше запрещающих правил в цепочке input. В моем примере выше правила с номером 13.
Далее необходимо отредактировать (или создать) политики шифрования (Proposals) в настройке IPsec. Приведите свои настройки в соответствие с рисунком или выполните в окне терминала команду, указанную ниже.
Это команда, редактирующая существующее значение политики. В случае, если у вас в proposal нет никаких значений по умолчанию (пусто вообще, нет ни одного) их необходимо создать в соответствии с рисунком. И в этом случае команду выполнять не нужно.
/ip ipsec proposal set [find default=yes] enc-algorithms=3des,aes-128 pfs-group=none
Нам необходимо настроить peer и на этом остановимся особо. Нужно заметить, что в Router OS версии выше 6.0 изменились некоторые настройки, касаемые IPsec Peers и IPSec Policies. В частности, в настройки Peers добавлены новые опции. Теперь для Peer можно указать инициирует Mikrotik или принимает подключение (аналог пассивныйактивный в Kerio Control). Нюанс состоит в том, что параметр «passive» нельзя установить через GUI. Его нет ни в Winbox, ни веб интерфейсе управление роутером. По умолчанию, при создании peer через Winbox — он становится активным и начинает непрерывно пытаться установить подключение по адресу указанному в его настройке. Поэтому для создания пассивного конца нашего туннеля необходимо воспользоваться именно CLI и в окне терминала выполнить команду где вместо «password» необходимо указать предопределенный ключ, который вы указали на стороне 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
Результатом выполнения команды будет созданный peer, ожидающий подключения. В случае, если ваши WAN интерфейсы находятся за NAT провайдера – установите чекбокс NAT-Travesal
При настройке Peer мы указали параметр автоматической генерации политик IPsec. Поэтому нам не требуется создавать ничего в /ip ipsec policies. Необходимые политики будут созданы автоматически после установление соединения. В случае если вы не забыли в настройке туннеля в Kerio Control его включить — это произойдет сразу же, после добавления peer-а.
После этого туннель на стороне Kerio Control должен перейти в статус «Подключено». В Mikrotik на закладке «Policies» в должна появиться автоматически созданная политика для подсетей, которые указывали при настройке Kerio Control в «Удаленные сети» и «Локальные сети». В «Installed SAs» вы увидите, что ваши концы туннелей «подружились» и наконец в «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 и о которых Head Office уже знает. И соответственно расширить диапазон адресов в правиле NAT в Mikrotik которые не будут маскарадиться, например, создав группу таких адресов в «Address List» и указав эту группу в назначении правила.
Добавляем, переустанавливаем туннель. Видим, что туннель установился, в IPsec Policies весело добавились автоматические политики для всех подсетей, который мы указали в настройке туннеля на стороне Kerio Control. В Installed SAs видим созданные SAs для всех подсетей. Бинго? А не тут то было…
Вдумчивое курение интернетов на тему IPseс в Mikrotik и объединения локальных сетей за разными типами роутеров дало понимание, что при такой схеме у всех проблема однотипная – невозможность объяснить Mikrotik куда именно слать пакеты. Практически на всех типах роутеров IPSec туннель – это отдельный сетевой интерфейс, что логично. Но не в Mikrotik, и поэтому определить для него маршрут прохождения пакетов в удаленную подсеть невозможно. На практике в связке с Kerio Control — 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 Policies и создаст единственный SAs. Теперь он просто не сможет ошибиться куда слать пакеты. Проверка пингом должна показать доступность всех подсетей за Control для сети за Mikrotik. Если вы проверяете доступность по ICMP с Mikrotik – вы должны пускать ping не с WAN интерфейса, а с бриджа, например. Это очень распространенная ошибка, которая приводит к стенаниям в стиле ЧТЯДНТ, ничего не работает, мы все умрем, лапы ломит и хвост отваливается, спасите-помогите.
Для обратного прохождения пакетов из удаленный VPN сетей в сеть за Mikrotik необходимо добавить аналог правила в Mikrotik, которое не позволяет маскарадиться пакетам, отправленным в туннель. Т.к. весь трафик в сеть за Mikrotik из VPN сетей пойдет с интерфейса VPN центрального филиала, нам необходимо правила трафика, которое бы обманывали бы Mikrotik, подменив источник с адреса VPN на адрес из подсети, о которой Mikrotik знает. Правила на рисунке. Адрес 192.168.10.2 – внутренний адрес шлюза центрального офиса.
После этого обмен трафика между подсетями пойдет во все стороны.
Теперь о недостатках это метода. При такой схеме невозможно выдать локальной сети «маршруты» (я намерено беру слово в кавычки, т.к. в реальности никаких привычных для понимании маршрутов в таблице маршрутизации Mikrotik в удаленные подсети нет вообще) только для конкретных удаленных подсетей, подключенных к Head Office. Теоретически существует возможность, что вы не сможете логически объединить адреса в удаленных подсетях в одну при помощи маски. Т.к. они могут находиться вообще в разных классах сетей. В связи с тем, что в диапазон попадает громадное количество адресов, в теории существует возможность, что вам понадобится использовать другие адреса из этого диапазона не в 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 password=password 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="Route to 192.168.30.0/24" distance=1 dst-address=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. В настройках peer вы хоть и сможете указать DNS имя принимающего конца туннеля, но при сохранении оно будет отрезолвлено и записано как IP адрес. В таком случае придется изобретать скрипты, которые будут мониторить каналы (вместо PRTG) на Kerio Control и менять настройки peer в случае, если текущий канал, на который устанавливается соединение — становится недоступным. Плюс масса плясок с политиками IPSec. И это видится мне жуткой головомойкой.
Теперь же Kerio Control сам замечательно умеет обеспечивать отказоустойчивость в случае, если сам инициирует подключение, в настройке туннеля можно указать несколько IP адресов (или DNS имен) принимающего конца туннеля. Таким образом, создав на стороне Mikrotik два peer, принимающих подключение, можно добиться желанной отказоустойчивости. Ну, погнали наши городских… Примерная схема отображена на рисунке. Необходимо обеспечить живучесть туннеля при падении любого WAN интерфейса на Kerio или ISP на Mikrotik (названы по-разному во избежание путаницы).
Начнем с настройки Mikrotik. Т.к. он не умеет понимать имена DNS в значении адреса настроек IPsec Peers, то нам придется создать два пира, для обоих WAN интерфейсов центрального офиса. Для этого перейдем в окно терминала и введем команду, заменив значения адресов и предопределённый ключ на свои:
/ip 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
/ip 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
Я обращаю ваше внимание, что если вы уже создавали peer по инструкции приведенной в предыдущих частях статьи и решили вместо CLI воспользоваться Winbox и скопировали уже созданный до этого peer, то настройка passive (та самая, которая определяет инициирует или принимает Mikrotik подключения) – не копируется. Поэтому на этом этапе я настоятельно рекомендуется воспользоваться инструментами командной строки. Результатом выполнения команды должно быть успешное создание двух peers ожидающих подключения со стороны Kerio Control.
Но этого мало. При падении WAN1 на Kerio Control туннель успешно переустановится, а вот если упадет ISP1 канал на Mikrotik, то в таком случае значение «удаленный ИД» настроек туннеля в Kerio Control в котором мы указывали серый провайдерский IP на ISP интерфейсе Mikrotik — не совпадет с реальным значением. И мы вместо успешного переподключения получим милую ошибку в консоли администрирования Kerio Control – «Несовпадение ИД».
Засада? Засада… И я почти отчаялся, потому что фонтан мыслей иссяк, я решительно не понимал, как автоматизировать смену этого ИД. Поколдовал с hosts файлом, но безуспешно. Пришло время вспомнить слова одного умного дядьки с уже, наверняка, совсем седой задницей, который в мохнатом еще году говорил мне – если ничего не помогает, то самое время заглянуть в мануалы и логи. Ну… мануалы – это не про нас (здесь гомерический хохот автора), полез в debug-log Kerio Control, предварительно включив в него все сообщения, касаемые IPSec. Что я могу сказать – ищущий, да обрящет. В нашем случае, когда параметр «удаленный ИД» может динамически изменяться в зависимости от того, к какому IP адресу подключается туннель — в настройках туннеля Kerio Control можно в удаленный ИД указать значение «%any».
В именах хостов введем через точку с запятой все адреса ISP1 И ISP2 на Mikrotik и значение «%any» в «Удаленный ИД» как на рисунке ниже.
Сохраняем, применяем, счастливыми глазами смотрим на изменившийся статус туннеля на «Подключено» и приступаем к проверке. Эмулируем падение основного канала на 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, который почти прочитанная книга.
Автор: ivn
