- Введение
- Gre туннель ipsec в mikrotik, создание и настройка
- L2tp клиент
- Pptp клиент
- Зачем нужен еще один vpn?
- Импорт сертификатов и настройка ipsec mikrotik
- Использование рутокен эцп 2.0 для работы с эдо сбис
- Настраиваем ipsec
- Настройка eoip tunnel ipsec
- Настройка ipsec ikev2 туннеля
- Настройка openvpn сервера
- Настройка rb750gr3(hex) — ipsec client
- Настройка rb760igs(hex s) — ipsec server
- Создание ключей и сертификатов
- Сравнение скорости l2tp, pptp, eoip, gre и openvpn туннелей
- Заключение
Введение
Сразу хочу обратить внимание, что эта статья будет скорее обзорной, нежели передачей реального опыта, так как сам я чаще всего использую в качестве vpn сервера openvpn. Тем не менее с vpn в микротик тоже приходилось сталкиваться. Настраивал как pptp сервера для подключения удаленных клиентов, так и l2tp для объединения двух и более микротиков в общую приватную сеть. В основном по дефолту, не вникая в тонкости настроек.
Сегодня хочу рассмотреть этот вопрос более внимательно и посмотреть, что вообще предлагает микротик из коробки для настройки vpn соединений. Своими исследованиями я и хочу поделиться с вами, написав небольшой обзор на тему средств организации vpn сервера в mikrotik.
А попутно хочу собрать отзывов и исправлений на тему написанного, чтобы укрепить свои знания. В комментариях к своим статьям я черпаю массу советов, за что благодарен всем писавшим полезные вещи. Так что замечания, дополнения и исправления категорически приветствуются.
Для тех, кто хочет хорошо разбираться в сетях, но пока по какой-то причине не умеет этого, рекомендую вот этот цикл статей – сети для самых маленьких. Так же, если вы не очень хорошо знакомы с микротиками, рекомендую мою статью на тему настройки микротика с нуля.
Gre туннель ipsec в mikrotik, создание и настройка
Для настройки GRE туннеля в Mikrotik идем в раздел Interfaces -> GRE Tunnel и добавляем новый со следующими настройками:
Назначаем GRE туннелю ip адрес в IP -> Adresses.
Сразу же создаем статический маршрут для доступа к ресурсам удаленной сети.
Для организации vpn соединения через GRE tunnel то же самое проделываем на удаленном микротике, только меняем соответствующие адреса.
Создаем GRE Tunnel.
Назначаем ip адрес.
Добавляем маршрут в удаленную локальную сеть.
После этого маршрутизация трафика между локальными сетями должна заработать. Не забудьте на firewall разрешить gre протокол.
Проверим теперь скорость соединения по GRE туннелю.
У меня получилось 247 мбит/сек. Напомню, что это нешифрованный маршрутизируемый vpn туннель. Отличие от l2 туннеля EoIP примерно в 3 раза по скорости в меньшую сторону. Выводы делайте сами какие туннели использовать. Если не нужна маршрутизация, то однозначно EoIP.
Теперь проверим то же самое, только настроив в GRE шифрование Ipsec. Добавляем соответствующие настройки в GRE туннели на обоих микротиках.
Измеряю скорость GRE Ipsec, алгоритм шифрования aes-128 cbc.
Получилось в среднем 29,7 мбит/сек, что примерно соответствует всем результатам с ipsec. Не удивительно, ведь алгоритм шифрования во всех случаях один и тот же. Но тем не менее, в GRE Tunnel скорость немного выше всех остальных участников.
L2tp клиент
Здесь все достаточно просто. Идем в PPP и добавляем L2TP Client. Указываем настройки, которые задавали ранее на сервере.
Добавляем статический маршрут, чтобы клиенты этого роутера знали, куда обращаться к абонентам удаленной локальной сети за vpn.
На этом все. Мы настроили l2tp на удаленном микротике и таким образом объединили 2 локальных сети с помощью vpn. В списке ip адресов при активном l2tp соединении на сервере и клиенте вы должны увидеть ip адреса из заданного на сервере диапазона для vpn сети – 10.10.5.1-10.10.5.100. Теперь можно пропинговать с обоих сетей противоположные.
У меня для теста к обоим микротикам подключены ноутбуки. Сейчас я измерю скорость соединения с помощью iperf3. За роутером m-remote на ноутбуке 10.30.1.254 запускаю сервер, а на 10.20.1.3 агента. Запускаем тест скорости vpn соединения:
Средняя скорость 194 мбит/сек. Откровенно говоря, я не понял, почему такая низкая скорость. Мой тестовый стенд собран на двух роутерах микротиках и гигабитного микротик свитча между ними. Ожидал увидеть что-то в районе 500 мбит/сек. Напомню, что туннель пока без шифрования. При этом загрузка процессоров на роутерах была в районе 90-95%. То есть фактически потолок этих железок.
Попробуем теперь включить шифрование ipsec и замерить скорость с ним.
Pptp клиент
Отправляемся на удаленный роутер и там настраивает подключение через pptp client. Идем, как обычно, в раздел PPP и добавляем PPTP Client. На вкладке General ничего не трогаем, а на Dial Out указываем адрес pptp сервера и имя пользователя для подключения.
Добавляем статический маршрут до удаленного офиса через vpn туннель.
Все готово. Активируем pptp подключение и пробуем пинговать адреса в локальной сети. Убедиться в том, что шифрование отключено можно в статуте pptp соединения на клиенте.
Проверим теперь скорость vpn соединения по pptp.
Те же самые 194 мбит/сек, что на нешифрованном l2tp при 100% загрузке процессора. Вообще, было немного странно увидеть абсолютно такие же цифры. Проводил тесты несколько раз, но везде был стабильно один и тот же результат. Без шифрования нет разницы по скорости между l2tp и pptp соединением.
Теперь включим шифрование в pptp на сервере и посмотрим на скорость. Для этого указываем в pptp профиле явно, чтобы использовалось шифрование. Идем в PPP -> Profiles и редактируем наш профиль.
Убедимся в статусе клиента, что шифрование работает.
Тестирую скорость vpn соединения по pptp с включенным шифрованием.
Получилось в среднем 71 мбит/сек. Неплохой результат в сравнении с шифрованием ipsec в l2tp. Как я и говорил ранее, pptp сервер хорошо подходит там, где шифрование либо совсем не нужно, либо допускается возможность, что зашифрованный трафик будет расшифрован.
Но при этом он все равно закрыт шифрованием и каждый проходящий не сможет ничего увидеть. Нужно как минимум снять дампт трафика и каким-то образом подбирать ключ по словарю или перебором. Не знаю точно, как это реализуется на практике. Не изучал вопрос.
Перейдем теперь к openvpn серверу в микротик. Очень любопытно посмотреть на тесты скорости этого типа vpn соединений.
Зачем нужен еще один vpn?
Как известно, события последних полутора лет стимулировали развитие рынка VPN, и сегодня он переживает эпоху роста. Конкуренция на этом рынке значительная, цены на услуги растут. Одновременно Россия в 2021 году остается в десятке топ-потребителей VPN сервисов, т.е. спрос на рынке присутствует.
Создавая Рутокен VPN, основной «фишкой» мы решили сделать ориентацию на малый и средний бизнес, т.е. на компании, которые, вероятно, не имеют в штате постоянного и высококвалифицированного системного администратора. Именно для таких компаний мы сделали версию продукта Рутокен VPN, которая упрощает настройку VPN-сервера и клиента.
Кроме того, нашей целью было предоставить разработчикам возможность развивать интересный и востребованный продукт, совершенствовать свои навыки, получая таким образом бесценный опыт и дополнительные очки к своему CV. Не скроем также, что заинтересованы и в советах участников профессионального сообщества по улучшению Рутокен VPN, которым будем максимально рады.
Чем может быть полезен Рутокен VPN Community Edition:
В результате обеспечивается безопасность соединения за счет использования RSA 2048 для аутентификации и AES 256 для шифрования канала связи. Аутентификация удаленного пользователя происходит с применением криптографического токена, а это значит, что ключи аутентификации не могут быть скопированы, ведь криптографические операции с ними выполняются на самом устройстве.
Использование VPN повышает безопасность при удаленном подключении к корпоративной сети, в том числе обеспечивает защиту от перехвата паролей, подмены сертификатов, хищения платежной информации, адресов корпоративной почты и других ценных данных компаний, передаваемых по сети.
Рутокен VPN Community Edition можно развернуть на Linux-based ОС. Мы поддерживаем работу в Ubuntu 16 и Ubuntu 20.
Клиентская часть поддерживается на:
Импорт сертификатов и настройка ipsec mikrotik
Импорт сертификатов
Для добавления сертификатов, необходимо перенести их в память вашего MikroTik в раздел Files.
System -> Certificates
Импортируем открытый ключ корневого сертификата вашего центра сертификации на VPS на котором установлен StrongSwan.
Последовательно импортируем открытый и закрытый ключи авторизации используемые в конфигурации StrongSwan.
Настройка клиента IPsec
IP -> IPsec
Импортируем закрытый ключ авторизации StrongSwan, для использования в клиенте.
Далее, последовательно настраиваем профиль VPN-клиента.
Вместо “VPS IP” указываем адрес вашего сервера, где развернут StrongSwan.
В разделе IPsec Idenity настраиваем профиль авторизации, указываем учётные данные и сертификат импортированный ранее.
После выполнения этого шага туннель между MikroTik и StrongSwan будет поднят автоматически.
В разделе IP -> Addresses при успешной авторизации, появится IP адрес выданный StrongSwan.
Использование рутокен эцп 2.0 для работы с эдо сбис
Работа с ЭЦП до сих пор вызывает у многих администраторов существенные затруднения. Мало того, что сама тема является достаточно сложной и требует некоторых базовых знаний, так еще используемые в РФ системы СКЗИ имеют собственные особенности, которые нужно учитывать. Осложняет ситуацию еще и то, что разные типы электронных сервисов используют по умолчанию различные типы СКЗИ и вряд ли смогут оказать качественную поддержку в нестандартной ситуации. В нашем случае все именно так и было, поэтому пришлось во всем разбираться самостоятельно.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Начнем с Рутокен ЭЦП 2.0 – на первый взгляд это самый обычный токен красного цвета, который широко используется в системе ЕГАИС, вместо показавшей низкую надежность JaCarta. Используется для хранения ЭЦП ГОСТ предприятия или индивидуального предпринимателя и RSA-сертификата для доступа к ЕГАИС.
На самом деле Рутокен ЭЦП 2.0 – это не просто токен, а полноценное СКЗИ (средство криптографической защиты информации). В чем разница? Обычные токены являются контейнерами для хранения закрытого ключа (подписи, ЭЦП) и сертификата, при этом закрытый ключ может быть неизвлекаемым, т.е. выполнить его экспорт из токена невозможно. Но для работы с криптографическими функциями требуется специальное приложение – СКЗИ, которое будет шифровать, подписывать, проверять подпись, расшифровывать и т.д. и т.п. Наиболее известными программными СКЗИ являются КриптоПро и ViPNet.
Но у таких систем есть один серьезный недостаток – закрытый ключ выгружается в оперативную память, и хотя предпринимаются серьезные методы защиты этой области памяти, сам факт такой выгрузки дает возможность осуществления атаки с целью завладения закрытым ключом.
Рутокен ЭЦП 2.0 выполняет все криптографические операции самостоятельно, на собственном контроллере, при этом закрытый ключ никогда не покидает пределов токена. Дополнительный плюс – для работы с Рутокен ЭЦП 2.0 не требуется никакое дополнительное ПО, достаточно самого токена и драйверов в системе к нему.
Если брать область малого и среднего бизнеса, то чаще всего Рутокен ЭЦП 2.0 можно увидеть в составе системы УТМ ЕГАИС, в последние годы он безальтернативно вытеснил с этого рынка JaCarta. А так как токен уже содержит ЭЦП предприятия, то возникает желание использовать эту подпись и для других целей. Желание это вполне здравое, с некоторыми ограничениями ЭЦП из Рутокен 2.0 можно использовать практически для любых целей. К ограничениям относится невозможность работы с шифрованием CBC, это делает невозможным сдачу отчетов в МВД, Росприроднадзор. а также некоторых отчетов в ПФР и ФСС.
Но обычно этого и не требуется, чаще всего возникает необходимость использовать имеющуюся ЭЦП для ЭДО (электронного документооборота) и интеграции в систему Честный знак (маркировка). Одним из крупнейших провайдеров, предоставляющих услуги ЭДО является СБИС и об интеграции этой системы и подписи размещенной в Рутокен ЭЦП 2.0 у нас сегодня и пойдет речь.
Для понимания ситуации немного обрисуем диспозицию: имеется небольшой сельский магазин уровня минимаркета, одной из первых в нем была внедрена система ЕГАИС, ЭЦП для которой было получено в одном из региональных УЦ. затем возникла необходимость в ЭДО с поставщиками табачной продукции, которое было предоставлено СБИС, при этом использовалась уже существующая подпись из Рутокен ЭЦП 2.0, мы в этой настройке не участвовали, все было выполнено силами сотрудников СБИС.
Прошел год, ЭЦП ГОСТ была перевыпущена, с ЕГАИС никаких проблем не возникло, а вот ЭДО работать отказалось, сообщая, что сертификат не соответствует закрытому ключу. Это понятно и логично, если поменялся закрытый ключ, то нужно заменить и сертификат в ЭДО.
Откроем Панель управления Рутокен и на вкладке Сертификаты выполним экспорт сертификата в формат DER X.509.
Следующим шагом, вполне логичным на первый взгляд, будет импорт этого сертификата в СБИС. Он отлично импортируется, но отказывается работать, сообщая, что не может найти контейнер закрытого ключа. Еще одним настораживающим фактором является то, то при попытке импортировать сертификат в СБИС система упорно предлагает старый сертификат, хотя нигде в системе он не установлен.
Здесь мы проявили небольшую слабость и воспользовались опцией “звонок другу”, т.е. в техническую поддержку. Приятная дама из СБИС, пробежав по базовым настройкам сообщила, что скорее всего что-то с подписью, а так как подпись выпустила другая организация, то обращайтесь туда. На наше возражение, что ЕГАИС работает нормально, значит подпись в порядке, дама осталась непреклонна.
Ну за спрос денег не берут, позвонили в УЦ выдавший подпись, там еще раз все проверили, подтвердили, что ЭЦП в порядке, а на вопрос про ЭДО отправили нас туда, где мы это самое ЭДО и приобрели. Ничего другого мы не ожидали, никто не будет помогать разбираться с продуктом конкурентов.
Снова звонок в СБИС, еще одна обходительная и приятная дама, минут двадцать мы с ней выгружали-загружали сертификаты, сравнивали новый сертификат со старым, проверяли настройки, но безуспешно. В итоге она сказала, что может нам только посочувствовать, мол подпись сделана не у них и, следовательно, они бессильны, а в качестве решения проблемы предложила приобрести еще одно ЭЦП, теперь уже от СБИС.
Вариант рабочий, но ведь до этого все работало, да и вгонять заказчика в дополнительные расходы – это не наш метод. Будем разбираться далее. Логика подсказывает: закрытый ключ на Рутокен ЭЦП 2.0 неизвлекаемый, следовательно, сертификат должен работать с токеном, но почему старый сертификат это может, а новый нет? Дополнительная подсказка таится в этом же старом сертификате, который СБИС настойчиво предлагает импортировать, хотя нигде в системе его нет. Тогда откуда? Логично предположить, что из токена, но Панель управления Рутокен никаких дополнительных сертификатов не показывает. Тем не менее они есть!
На помощь здесь придет ресурс cvs.sbis.ru, для работы с ним вам потребуется установленный СБИС Плагин. Перейдем в Криптооперации – Установка сертификата и нажмём в вверху кнопку Заполнить, а затем выберем найденный контейнер. Затем загрузим в него выгруженный на предыдущем шаге сертификат кнопкой Выбрать файл и установим, нажав на Установить.
После выполнения данной операции вернемся в СБИС и выполним импорт подписи, для этого перейдите в раздел Подписи – Другие операции – Зарегистрировать имеющуюся, теперь вместо старой подписи вам предложат импортировать новую.
Для дополнительной проверки вернитесь в Подписи, выберите импортированную подпись в самой правой колонке внизу вы должны увидеть надпись Рутокен ЭЦП 2.0 Rutoken ECP, это означает что контейнер закрытого ключа на токене привязан к данному сертификату и будет использоваться при криптографических операциях.
Проверяем ЭДО – все должно работать. Просто? Да. Почему об этом не знают в поддержке СБИС? Хороший вопрос, но мы оставим его без ответа. Надеемся, что данный материал окажется вам полезен.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Настраиваем ipsec
С настройкой ipsec для l2tp я залип на некоторое время. В сети много инструкций, но все они устарели. Как оказалось, в последних версиях прошивок, запустить ipsec в дефолтных настройках не просто, а очень просто. Для этого надо всего лишь в свойствах l2tp сервера указать Use IPsec – yes и задать пароль.
Все необходимые настройки ipsec будут созданы автоматически. На агенте сделать то же самое – включить ipsec шифрование и указать пароль.
После подключения l2tp клиента увидите в логе похожие строки:
19:17:00 l2tp,ppp,info l2tp-out1: initializing... 19:17:00 l2tp,ppp,info l2tp-out1: connecting... 19:17:03 ipsec,info initiate new phase 1 (Identity Protection): 192.168.13.197[500]<=>192.168.13.1[500] 19:17:04 ipsec,info ISAKMP-SA established 192.168.13.197[500]-192.168.13.1[500] spi:407844c0ceb5d2ab:46ce7ffb25495efd 19:17:07 l2tp,ppp,info l2tp-out1: authenticated 19:17:07 l2tp,ppp,info l2tp-out1: connected
Для того, чтобы убедиться, что шифрование ipsec работает, можно зайти в раздел IP -> Ipsec -> Installed SAs и посмотреть на счетчик зашифрованных пакетов. Если он растет, значит все в порядке, трафик шифруется.
Там же в разделе Remote Peers можно посмотреть список удаленных клиентов, для которых работает ipsec шифрование, посмотреть используемые алгоритмы. Все дефолтные настройки ipsec живут в этом разделе. Вы можете посмотреть их, изменить или добавить новые профили.
Проведем тесты скорость vpn соединения l2tp ipsec.
У меня получилось вот так – 26 мбит/сек в среднем. При этом загрузка процессора 100%. Не густо. Данные железки для шифрованных каналов пригодны очень слабо. В данных тестах они ничем, кроме непосредственно теста не нагружены. В реальных условиях скорость будет еще ниже.
С настройками vpn на базе l2tp ipsec закончили. Продолжим настройку остальных vpn туннелей и сравним их скорость.
Настройка eoip tunnel ipsec
Настроим vpn сеть на базе EOIP в Mikrotik. Тут нужно понимать одно важное отличие от всех предыдущих настроек, которые мы делали ранее. EOIP туннель работает на уровне l2, то есть оба сегмента сети будут считать, что находятся в одной физической сети.
Создаем EOIP туннель на m-server. Идем в Interface list -> EoIP Tunnel и добавляем новый.
Из настроек достаточно указать только удаленный адрес второго микротика. Новый EoIP интерфейс необходимо добавить в локальный бридж вместе с физическими интерфейсами.
Идем на удаленный микротик и там делаем все то же самое, только Remote Address указываем другой.
Этого достаточно, чтобы EoIP туннель сразу же заработал. Его состояние будет RS.
На втором микротике EoIP интерфейс так же нужно добавить в локальный бридж с остальными интерфейсами.
Проще всего проверить, что все в порядке, это запросить по dhcp на m-slave ip адрес для интерфейса bridge. Он должен получить ip адрес от dhcp сервера на m-server, при условии, что в сети больше нет других dhcp серверов. То же самое будет и с локальными машинами в сети за m-slave. Они будут получать ip адреса от dhcp сервера на m-server.
Проверим теперь быстродействие такого vpn туннеля на основе EoIP.
Показываю максимальный результат, который у меня получился – 836 мбит/сек. По какой-то причине в разных тестах скорость плавала в интервале между 600-850 мбит/сек. Для того, чтобы скорость изменилась, необходимо было отключить и заново включить EoIP интерфейс.
Скорость впечатляет. При этом, процессор не загружен на 100%. То есть узкое место не он. Похоже я уперся в производительность сети. Напомню, что тут нет никакого шифрования и маршрутизации трафика. Прямой l2 канал между двумя микротиками через EoIP vpn.
Добавим в EoIP туннель шифрование Ipsec и посмотрим на скорость. Для этого меняем настройки каналов на обоих микротиках. Добавляем пароль Ipsec и локальные адреса, отключаем Fast Path.
Измеряем скорость соединения.
У меня получилась скорость vpn при использовании EoIP Ipsec в среднем 27 мбит/сек. Скорость сопоставима с шифрованными туннелями L2tp и Openvpn. В этом плане никаких приятных сюрпризов не получилось. Шифрование очень тяжело дается этой железке. Можно сказать она для него не предназначена практически совсем.
Настройка ipsec ikev2 туннеля
Как известно сообществу специалистов по RouterOS, компания MikroTik существенно перекроила IPsec и начиная с прошивки 6.44 принцип настройки изменился.Будьте внимательны. Большинство мануалов в интернете написаны для предыдущего типа конфигурирования!!!Я придерживаюсь использования Long-term прошивок и данная статья написана с использованием прошивки 6.45.8
IPsec характерен тем, что умеет работать через NAT провайдера(NAT-T), имеет отличное шифрование, да и в целом более защищен. Но есть одна проблема…
Кол-во настроек в IPsec отбивают всякое желание, что либо на нем делать. Потому, далеко не многие дошли до корректной настройки при которой все бы работало согласно их ожиданиям или даже не начинали пробовать разбираться.
Данная статья позиционируется, как «Вводная», поэтому я применил стандартный Example от MikroTik для того, чтобы показать, как это можно настроить.IPsec#Road_Warrior_setup_using_IKEv2_with_RSA_authentication
IPsec IKEv2 использует сертификаты для взаимодействия(RSA), вместо простой аутентификации.Поэтому перед настройкой создадим сертификаты. К сертификатам предъявляется ряд требований:
- Поле «Common name» должно содержать IP или DNS адрес публичного IP серверной стороны
- Поле «SAN» (subject alternative name) должно содержать IP или DNS адрес публичного IP серверной стороны
- Требуются «EKU» (extended key usage) для сертификатов. Серверный tls-server, клиентский tls-client
Убедитесь, что дата и время на роутерах настроена корректно. Например включите NTP синхронизацию.Т.к. механизм работы SSL сильно зависит от точного времени.
Настройка openvpn сервера
Начнем с создания пула адресов для выдачи OpenVPN клиентам, так как назначать адреса вручную во втором десятилетии 21 века – дурной тон. Для этого перейдем в IP – Pool и создадим новый пул: Name – ovpn_pool0 – произвольное имя пула, Addresses – 10.8.8.100-10.8.8.199 – диапазон адресов для выдачи клиентов, также можете выбрать по собственному усмотрению.
Эти же действия в консоли:
/ip pool
add name=ovpn_pool0 ranges=10.8.8.100-10.8.8.199
Теперь перейдем в PPP – Profiles и создадим новый профиль. Укажем его имя Name – ovpn, локальный и удаленный адреса: Local Address – 10.8.8.1, Remote Address – ovpn_pool0. На всякий случай напомним, что локальный адрес должен принадлежать той-же /24 сети, что и диапазон пула адресов.
Быстро создать профиль в терминале:
/ppp profile
add local-address=10.8.8.1 name=ovpn remote-address=ovpn_pool0
Затем перейдем в PPP – Secrets и убедимся, что включена аутентификация по пользователю. Для этого нажмем PPP Authentication&Accounting, где должен стоять флаг Accounting:
/ppp aaa
set accounting=yes
Здесь же создадим учетные записи для клиентов. Особенностью реализации OpenVPN в RouterOS 6 является обязательное использование аутентификации по имени и паролю. При создании учетной записи указываем ее имя – Name, рекомендуем дать ей то же самое имя, которое вы использовали при создании сертификата, чтобы избежать путаницы.
Password – пароль, так как основная аутентификация производится по сертификату особых требований к нему нет. Service – какие службы могут использовать данную учетную запись – ограничиваем только OpenVPN выбрав ovpn, затем указываем созданный нами профиль Profile – ovpn.
В терминале для создания учетной записи выполните:
/ppp secret
add name=mikrotik password=123 profile=ovpn service=ovpn
В данном случае мы создали запись для пользователя mikrotik с паролем 123.
После создания пользователей перейдем в PPP – Interface и нажмем на кнопку OVPN Server, в открывшемся окне включим службу установив флаг Enabled, Default Profile – ovpn, в поле Certificate укажем созданный нами сертификат сервера.
Для дополнительной безопасности включим Require Client Certificate, в этом случае сервер будет проверять сертификат клиента на принадлежность к цепочке сертификатов локального CA. Затем укажем параметры шифрования: Auth – безальтернативно sha1, Cipher – здесь есть возможность выбора, для роутеров с аппаратной поддержкой AES следует выбирать шифры только из этого семейства, однако чем сильнее шифр – тем больше он нагружает оборудование.
В терминале эти же действия выполняются командами:
/interface ovpn-server server
set auth=sha1 certificate=ovpn-server cipher=aes256 default-profile=ovpn enabled=yes require-client-certificate=yes
Также не забудьте разрешить входящие подключения к вашему OpenVPN серверу. Откроем IP – Firewall и добавим правило: Chain – input, Protocol – tcp, Dst. Port – 1194. Действие можно не указывать, так как по умолчанию применяется accept.
В терминале выполните:
/ip firewall filter
add action=accept chain=input dst-port=1194 protocol=tcp
Данное правило должно располагаться выше запрещающего в цепочке INPUT.
На этом настройка OpenVPN сервера на базе роутера Mikrotik закончена.
Настройка rb750gr3(hex) — ipsec client
Переносим каким-либо образом клиенсткий сертификат на hEX и импортируем его.Я просто перетаскиваю через Winbox.
/certificate
import file-name=cert_export_rw-client1.p12 passphrase=1234567890
Далее мы повторяем большинство пунктов проделанных на стороне IPsec сервера с некоторыми изменениями.
Создаем отдельный
Profile
для Phase_1(для IKEv2 это IKE_SA_INIT) и
Proposal
для Phase_2(для IKEv2 это IKE_AUTH)
/ip ipsec profile
add name=ike2-rw
/ip ipsec proposal
add name=ike2-rw pfs-group=none
Для отделения новой конфигурации от конфигурации по умолчанию создаем отдельный шаблон политик
Policies
и группу
Group
/ip ipsec policy group
add name=ike2-rw
/ip ipsec policy
add group=ike2-rw proposal=ike2-rw template=yes
Создаем конфигурацию
Mode Config
с responder=no для получения параметров от сервера
/ip ipsec mode-config
add name=ike2-rw responder=no
Наконец, создаем конфигурации пира
Peer
и идентификатора
Identity
/ip ipsec peer
add address=2.2.2.2/32 exchange-mode=ike2 name=ike2-rw-client profile=ike2-rw
/ip ipsec identity
add auth-method=digital-signature certificate=cert_export_rw-client1.p12_0 generate-policy=port-strict mode-config=ike2-rw peer=ike2-rw-client policy-template-group=ike2-rw
В логах двух роутеров вы должны увидеть записи процесса установления связи.Например на hEX S:
new ike2 SA (R): 2.2.2.2[4500]-35.17.2.78[4500] spi:2d3453dd0ffda81a:a6a4ca7bhhha8098
peer authorized: 2.2.2.2[4500]-35.17.2.78[4500] spi:2d3453dd0ffda81a:a6a4ca7bhhha8098
acquired 172.20.0.2 address for 35.17.2.78, rw-client1
Ну или ошибки, если что-то не так 🙂
Проверяем установилось ли IPsec соединение
/ip ipsec active-peers print
/ip ipsec installed-sa print
Для топологий, где необходимо связывать различные подсети, нужно больше настроек, в том числе применять Firewall! Но это тема для отдельной статьи.
Настройка rb760igs(hex s) — ipsec server
Для примера я возьму публичный IP адрес 2.2.2.2
Создаем основной сертификат, сертификат сервера и сразу сертификат клиента.
/certificate
add common-name=ipsec-ca name=ipsec-ca
/certificate
sign ipsec-ca ca-crl-host=2.2.2.2
/certificate
add common-name=2.2.2.2 subject-alt-name=IP:2.2.2.2 key-usage=tls-server name=ipsec-server
/certificate
sign ipsec-server ca=ipsec-ca
/certificate
add common-name=rw-client1 name=rw-client1 key-usage=tls-client
/certificate
sign rw-client1 ca=ipsec-ca
Добавляем
Profile
для Phase_1(для IKEv2 это IKE_SA_INIT) и
Proposal
для Phase_2(для IKEv2 это IKE_AUTH)
/ip ipsec profile
add name=ike2
/ip ipsec proposal
add name=ike2 pfs-group=none
Создадим IP пул адресов для IPsec. И используем
Mode Config
для раздачи IP адресов из пула.
/ip pool
add name=ipsec-pool ranges=172.20.0.2-172.20.0.254
/ip ipsec mode-config
add address-pool=ipsec-pool address-prefix-length=32 name=ike2-conf split-include=172.20.0.1 system-dns=no
Создаем отдельную группу
Group
и шаблон политик
Policies
для нашей конфигурации.
/ip ipsec policy group
add name=ike2-policies
/ip ipsec policy
add dst-address=172.20.0.0/24 group=ike2-policies proposal=ike2 src-address=172.20.0.1/32 template=yes
Создаем новый IPsec
Peer
, который будет слушать все входящие запросы IKEv2
/ip ipsec peer
add exchange-mode=ike2 name=ike2 passive=yes profile=ike2
Создаем идентификатор
Identity
по умолчанию для сопоставления конкретных удаленных одноранговых узлов.
Она будет обрабатывать все пиры, но будет проверять идентичность пира с помощью его сертификата.
/ip ipsec identity
add auth-method=digital-signature certificate=ipsec-server generate-policy=port-strict mode-config=ike2-conf peer=ike2 policy-template-group=ike2-policies
Добавляем loopback интерфейс т.к. у IPsec нет своего интерфейса для привязки IP адреса.
Таким интерфейсом будет служить обычный пустой Bridge, которому мы назначим IP адрес 172.20.0.1
/interface bridge
add name=IPsec-Bridge comment="IPsec"
/ip address
add address=172.20.0.1 interface=IPsec-Bridge
Настройку IPsec на принимающей стороне закончили. Перед переходом к клиенту, необходимо выгрузить его сертификат из hEX S и загрузить в hEX
Экспортируем клиентсткий сертификат из hEX S
Выгружать будем в формате PKCS12. Пароль(export-passphrase) указывать обязательно!
/certificate
export-certificate rw-client1 export-passphrase=1234567890 type=pkcs12
PKCS12 это набор сертификатов, основной CA и клиенсткий. Поэтому при импорте мы получим сразу оба.Сертификат будет лежать в файловой системе роутера.
Создание ключей и сертификатов
Некоторые руководства в сети предполагают создание ключей и сертификатов при помощи сторонних утилит, например, Easy-RSA, мы же будем использовать собственные средства Mikrotik. Перейдем в System – Certificate и создадим новый корневой сертификат нашего центра сертификации (CA).
Обязательные поля отмечены нами красным, это Name и Common Name – ca, размер ключа – Key Size – 2048, и срок действия – Days Valid – 3650 или 10 лет, для локального центра сертификации это вполне оправдано. Выделенные зеленым поля содержат информацию о владельце сертификата и к заполнению не обязательны, но их заполнение является правилом хорошего тона и при наличии большого количества сертификатов позволяет быстро понять, что это за сертификат и кому он принадлежит.
Затем перейдем на закладку Key Usage и укажем только crl sign и key cert. sign и нажмем кнопку Apply, теперь подпишем сертификат нажав Sign. В появившемся окне заполним поле CA CRL Host адресом локальной петли – 127.0.0.1, после чего нажимаем Start и дожидаемся окончания подписи сертификата.
Эти же действия в консоли:
/certificate
add name=ca country="RU" state="31" locality="BEL" organization="Interface LLC" unit="IT" common-name="ca" key-size=2048 days-valid=3650 key-usage=crl-sign,key-cert-sign
sign ca ca-crl-host=127.0.0.1
Следующим создадим сертификат и закрытый ключ сервера. Закладка General нового сертификата заполняется аналогично, только в полях Name и Common Name указываем ovpn-server (можете выбрать на собственное усмотрение).
На вкладке Key Usage укажите digital-signature, key-encipherment и tls-server. Затем подпишем сертификат ключом нашего CA, для этого в поле CA выберите только что созданный нами сертификат ca.
/certificate
add name=ovpn-server country="RU" state="31" locality="BEL" organization="Interface LLC" unit="IT" common-name="ovpn-server" key-size=2048 days-valid=3650 key-usage=digital-signature,key-encipherment,tls-server
sign ovpn-server ca="ca"
Теперь создадим клиентские сертификаты, в полях Name и Common Name на закладке General указываем имя сертификата, его следует давать осмысленно, чтобы всегда можно было определить какому клиенту принадлежит сертификат.
Также следует подумать над сроком действия сертификата, если клиентом будет роутер в удаленном офисе, то можно также выпустить сертификат на 10 лет, а вот если клиентом будет ноутбук сотрудника на испытательном сроке, то лучше выдать его на срок испытательного срока.
На вкладке Key Usage указываем только tls-client и также подписываем сертификат ключом нашего CA. Можно сразу выпустить все необходимые клиентские сертификаты, можно создавать из по мере необходимости.
Получение клиентского сертификата в консоли:
/certificate
add name=mikrotik country="RU" state="31" locality="BEL" organization="Interface LLC" unit="IT" common-name="mikrotik" key-size=2048 days-valid=365 key-usage=tls-client
sign mikrotik ca="ca"
Обратите внимание, в данном случае мы выпустили сертификат со сроком действия в 1 год: days-valid=365.
Если все сделано правильно, то у вас будут следующие сертификаты, обратите внимание, что корневой сертификат должен иметь флаги KLAT, остальные KI:
Для использования на клиента нам необходимо экспортировать закрытый ключ и сертификат клиента, а также корневой сертификат центра сертификации. Удобнее всего использовать для этого формат PKCS12, который содержит все необходимые компоненты в одном файле (сертификат, ключ и сертификат CA).
Для этого щелкните на нужном сертификате правой кнопкой и выберите Export, в открывшемся окне укажите формат Type – PKCS12 и парольную фразу для экспорта (минимум 8 символов) в поле Export Passphrase. Без указания пароля закрытые ключи выгружены не будут, и вы не сможете использовать такой сертификат для клиента.
Либо используйте команды:
/certificate
export-certificate mikrotik type=pkcs12 export-passphrase=12345678
Сравнение скорости l2tp, pptp, eoip, gre и openvpn туннелей
Сведу все данные измерений в единую таблицу для наглядного и удобного анализа и сравнения скоростей всех упомянутых vpn соединений в Mikrotik.
VPN Туннель | Шифрование | Скорость (Мбит/c) |
l2tp | нет | 194 |
l2tp | IPsec AES-128 CBC | 26 |
pptp | нет | 194 |
pptp | MPPE128 | 71 |
openvpn | BF-128-CBC | 24 |
eoip | нет | 836 |
eoip | IPsec AES-128 CBC | 27 |
gre | нет | 247 |
gre | IPsec AES-128 CBC | 29,7 |
Приведенная таблица наглядно показывает разницу в различных методах шифрования. С помощью нее можно быстро оценить, к каким потерям производительности может привести шифрование. Сейчас все по-умолчанию все шифруют, но если разобраться, очень часто это не требуется.
Можно пойти на некий компромис и использовать pptp сервер, который хоть и не обеспечивает 100% безопасное шифрование, но тем не менее скрывает трафик от просто любопытных глаз и имеет неплохое быстродействие. В любом случае трафик просто так не прочитать, надо целенаправленно приложить усилия для дешифровки. В некоторых случаях такой защиты будет достаточно.
Заключение
По итогу мы получили интересную картину с улучшенными скоростными характеристиками, но несколько более сложной настройкой.
Не могу сказать, что это сложно. Просто требуется чуть больше времени, чтобы разобраться и научиться. Хотя параметров у IPsec существенно больше.
Главное помнить, что IPsec сам по себе не VPN, а всего лишь набор протоколов для обеспечения защиты передаваемых данных и обеспечения связности между несколькими узлами.
А уже непосредственно VPN, строится на базе установленной IPsec связи.