Долго говорить о самом SSTP Server нет необходимости, информацию о нем можно найти очень много в Интернете. Основное для понимания SSTP — это инкапсулируемый в HTTPs туннельный протокол и соответственно работает на порту 443. Это делает его достаточно доступным из любых сетей передачи данных. Сегодня сложно встретить сети с заблокированным HTTPs.
SSTP — это разработка Microsoft и данный протокол был представлен на Windows Server 2008 и Vista начиная с SP1.
Для шифрования используется SSL, для аутентификации — SSL и PPP. SSL соединение авторизует клиент сервер по SSL сертификату, а сервер клиента по PPP (MS-CHAP, EAP, PEAP). Примерный путь прохождения SSTP соединения:
Сервер SSTP на MikroTik
Перед началом работ сделаем резервную копию:
Создадим пул для адресов VPN клиентов:
Создаем профиль SSTP Сервера:
Поднимаем сервер сертификации (CA):
Далее Key Usage:
Это головной сертификат нашего CA и его роль только подписывать сертификаты выданные им самим. Оставляем только этот функционал: выдача приватных и публичных ключей.
Нажимаем Apply далее Sign:
Создаем сертификат SSTP сервера:
Нажимаем Apply далее Sign и подписываем сертификатом нашего CA:
Запускаем сервер VPN SSTP:
Сервер SSTP готов.
Убедимся что 443 порт открыт на файерволе. Если нет, открываем:Подробно останавливаться не буду. Команда через консоль:
Экспортируем сертификат центра сертификации:
Забираем файл сертификата из FILES и устанавливаем на компьютер клиента.
Сертификат должен быть помещен в контейнер: Trusted Root Certification Authorities. Можно установить командой:
certutil -addstore Root C:Path_toCA.crt
Далее создаем VPN подключение:
Клиент готов. На этом все.
Продолжая тему VPN для удаленного доступа, сегодня мы хотим рассмотреть настройку SSTP-сервера на базе оборудования Mikrotik. Это не самый распространенный и популярный протокол, но имеющий ряд особенностей и преимуществ, главное из которых — использование стандартного протокола HTTPS для установления соединения, что делает SSTP-трафик неотличимым от обычного и дает возможность работать из любой точки, где есть интернет, проходя через NAT, брандмауэры и даже прокси-сервера. При этом его достаточно просто настроить и использовать, о чем мы расскажем в данной статье.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Практически все из рассмотренных нами ранее протоколов VPN имеют те или иные ограничения, которые могут помешать установить соединение в условиях ограниченного доступа к сети интернет. Особенно это актуально для публичных и гостиничных сетей, где может быть заблокировано практически все, кроме обычного HTTP/HTTPS. Именно в таких сценариях раскрываются сильные стороны протокола SSTP и отходят на второй план слабые. Как мы уже говорили раньше — нет универсального VPN-решения, каждое из них имеет свои особенности и недостатки, поэтому для каждой задачи надо выбирать именно то, что поможет решить ее наилучшим образом.
SSTP, как технологию удаленного доступа следует рассматривать в первую очередь для тех клиентов, которые могут работать из самых различных мест и должны всегда иметь возможность быстро подключиться к корпоративной сети соблюдая высокие требования безопасности. К недостаткам следует отнести повышенные накладные расходы и связанную с этим невысокую производительность, но это общий недостаток всех VPN-протоколов поверх TCP.
В случае использования оборудования Mikrotik встает вопрос высокой нагрузки на процессор для моделей без аппаратной поддержки AES. При этом вне зависимости от аппаратной поддержки шифрования скорость канала для недорогих моделей вряд-ли превысит 20-25 МБит/с , вне зависимости от доступной ширины канала. Более подробно об этом можете прочитать в нашей статье Производительность младших моделей Mikrotik hEX и hAP. Экспресс-тестирование. Поэтому мы не советуем использовать SSTP для каналов, предполагающих высокую загрузку, но можем рекомендовать как надежное и безопасное средство удаленного доступа для сотрудников, часто работающих вне стационарных рабочих мест.
Создание центра сертификации и выпуск сертификатов
Так как SSTP использует HTTPS для установления защищенного соединения нам понадобится сертификат сервера, поэтому создадим собственный центр сертификации (CA) и выпустим необходимый сертификат. Если в вашей сети уже имеется развернутая инфраструктура PKI, то можете выпустить сертификат с ее помощью, мы же рассмотрим использование для этих целей собственных возможностей RouterOS.
Перед тем, как приступить к созданию центра сертификации убедитесь, что на роутере правильно настроено текущее время и часовой пояс, а также включена синхронизация времени через NTP.
Сначала выпустим корневой сертификат, для этого перейдем в System — Certificate и создадим новый сертификат заполнив поля как указано на рисунке, красным обозначены обязательные к заполнению.
В терминале все это можно быстро сделать командами:
/certificate add name=CA country=»RU» state=»31″ locality=»BEL» organization=»Interface LLC» 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
На закладке Key Usage устанавливаем digital-signature, key-encipherment и tls-server и подписываем сертификат сервера, для этого в поле CA выберите ранее выпущенный корневой сертификат.
/certificate add name=sstp.interface31.lab country=»RU» state=»31″ locality=»BEL» organization=»Interface LLC» common-name=»sstp.interface31.lab» subject-alt-name=DNS:»sstp.interface31.lab» key-size=2048 days-valid=3650 key-usage=sign sstp.interface31.lab ca=»CA»
При подключении через SSTP клиент прежде всего устанавливает с сервером защищенное соединения, а для этого ему нужно проверить сертификат и убедиться в его подлинности, в противном случае продолжение соединения будет невозможным. Чтобы клиентские системы доверяли нашим сертификатам нам нужно будет установить на них корневой сертификат нашего CA.
Для этого выберем корневой сертификат в System — Certificate, щелкнем на нем правой кнопкой мыши и нажмем Export, в поле Type ставим PEM, пароль не указываем, так как нам нужен только сертификат, без закрытого ключа. Закрытый ключ центра сертификации является секретным и никогда не должен покидать пределы роутера.
В терминале сертификат можно экспортировать командой:
Настройка SSTP VPN-сервера
Перед тем как браться за настройку сервера следует определиться со схемой доступа к сети, существуют два основных варианта: Proxy ARP, когда адреса удаленным клиентам выдаются из диапазона основной сети и они получают доступ без дополнительных настроек, и маршрутизация, когда диапазон адресов для VPN-клиентов не пересекается с основной сетью, а для доступа в нее будет необходимо указать маршруты, этот процесс можно автоматизировать с помощью PowerShell.
После этого перейдем в IP — Pool и создадим новый пул адресов для выдачи VPN-сервером, количество адресов в пуле не должно быть меньше предполагаемого количества клиентов.
/ip pooladd name=sstp_pool ranges=10.20.0.100-10.20.0.199
Затем перейдем в PPP — Profiles и создадим новый профиль, в поле Local Address введем локальный адрес VPN-сервера, он должен относиться к тому же диапазону что и выделенный выше пул адресов, который следует указать в поле Remote Address, остальные настройки оставляем по умолчанию.
Или выполним команду:
/ppp profileadd local-address=10.20.0.1 name=SSTP-profile remote-address=sstp-pool
Затем переместимся в PPP — Secrets и создадим учетные записи пользователей, указываем имя пользователя, пароль, в поле Service выбираем sstp, что ограничит действие учетной записи только SSTP-сервером, если оставить any, то учетка сможет подключаться к любому сервису. В поле Profile указываем созданный нами профиль.
Эти же действия в командной строке:
/ppp secretadd name=Ivanov password=Pa$$word profile=SSTP-profile service=sstp
Теперь, когда все готово, настроим сам сервер. Для этого перейдем в PPP — Interface и нажмем кнопку SSTP Server. Включим его, установив флаг Enabled, в поле Default Profile выберем созданный нами профиль, в разделе Authentication оставим только mschap2, в поле Certificate указываем сертификат сервера. Дальнейшие настройки отвечают за повышение уровня безопасности: TLS Version — only-1.2 не разрешает использование устаревших версий TLS, Force AES — заставляет принудительно использовать алгоритм шифрования AES256, PFS включает совершенную прямую секретность (Perfect forward secrecy), которая формирует уникальный сессионный ключ для каждого подключения, что делает невозможным расшифровку сессии даже при наличии закрытого ключа.
В терминале для включения и настройки сервера выполните:
/interface sstp-server serverset authentication=mschap2 certificate=sstp.interface31.lab default-profile=SSTP-profile enabled=yes force-aes=yes pfs=yes tls-version=only-1.2
На этом настройка закончена, сервер готов принимать подключения.
Настройка подключения клиента в Windows
Как мы уже говорили, для того чтобы клиент мог проверить подлинность сервера нам необходимо импортировать корневой сертификат, переместим его на клиента и установим в Расположение хранилища — Локальный компьютер:
Затем создаем подключение, в котором указываем Тип VPN — Протокол SSTP и Тип данных для входа — Имя пользователя и пароль, здесь же вводим адрес сервера и учетные данные.
После чего в свойствах подключения на закладке Безопасность убедимся, что в разделе Проверка подлинности указан только протокол MS-CHAP v2.
Настройка клиента закончена, можно подключаться.
Настройка подключения клиента в Linux
В используемых нами дистрибутивах Linux нет штатного SSTP-клиента, однако есть сторонняя разработка, которой мы и воспользуемся. Все нижесказанное будет справедливо для дистрибутивов основанных на Debian и Ubuntu, если у вас иная система обратитесь на страницу проекта.
Проще всего владельцам Ubuntu, им достаточно просто подключить PPA, ниже приведен пример для Ubuntu 18.04, для других систем просто измените кодовое название дистрибутива:
deb http://ppa.launchpad.net/eivnaes/network-manager-sstp/ubuntu bionic main deb-src http://ppa.launchpad.net/eivnaes/network-manager-sstp/ubuntu bionic main
В Debian процесс немного более сложный, сначала получим и установим ключ репозитория проекта:
apt-key adv —keyserver keyserver.ubuntu.com —recv-keys 61FF9694161CE595
Затем создадим файл с указанием источников пакетов:
И внесем в него следующие строки:
deb http://ppa.launchpad.net/eivnaes/network-manager-sstp/ubuntu eoan main deb-src http://ppa.launchpad.net/eivnaes/network-manager-sstp/ubuntu eoan main
Обновим список пакетов и установим клиент:
apt updateapt install network-manager-sstp
После чего появится возможность создать SSTP-соединение штатными средствами Network Manager. Настройки несложные: указываем адрес сервера, учетные данные и сертификат CA, у которого предварительно следует изменить расширение на PEM.
Если вы все сделали правильно, то соединение будет установлено.
Сейчас, когда многие настраивают VPN для работы удаленных сотрудников, выбор протокола становится как никогда актуальным. С одной стороны стоят поддерживаемые современными ОС протоколы PPTP и L2TP, которые имеют ряд существенных недостатков и ограничений, с другой OpenVPN, который всем хорош, но требует установки стороннего ПО. При этом как-то забывают о быстром и безопасном IKEv2, основанном на IPsec новом протоколе, также поддерживаемом всеми современными ОС.
Почему именно IKEv2? Данный протокол входит в группу протоколов IPsec и обеспечивает высокий уровень безопасности, включая аутентификацию клиента с использованием сертификата, а также проверку подлинности сервера клиентом, что исключает атаки типа «человек посередине». При поддержке аппаратного ускорения IPsec со стороны оборудования показывает хорошую скорость соединения относительно других типов VPN в RouterOS и весьма прост в настройке с клиентской стороны, не требует добавления маршрутов.
К недостаткам можно отнести достаточную сложность настройки серверной части, которая требует выполнения определенных условий и наличия базового объема знаний о работе IPsec. В данной статье мы не будем углубляться в теорию, сделав упор на практическую сторону вопроса, ограничившись краткими пояснениями необходимости тех или иных настроек.
Когда мы говорим об использовании сертификатов для аутентификации, то подразумеваем наличие инфраструктуры открытых ключей (PKI), образующей область доверия, за счет чего появляется возможность проверки подлинности любого субъекта инфраструктуры без привлечения третьих служб и списков пользователей. В основе PKI лежит центр сертификации — CA, выпускающий сертификаты и дающий возможность убедиться в их подлинности при помощи корневого публичного сертификата.
В нашем случае центр сертификации будет создан средствами RouterOS прямо на маршрутизаторе. Для этого перейдем в System — Certificate и выпустим корневой сертификат нашего CA.
Красным указаны обязательные к заполнению поля. Name — видимое имя сертификата и Common Name — имя субъекта, которому выдан сертификат, в нашем случае это ca. Key Size — размер ключа, ключи размером менее 2048 байт не считаются безопасными, Days Valid — время действия сертификата, в нашем случае 10 лет.
Выделенный зеленым блок не является обязательным, но мы советуем его заполнять, дабы в дальнейшем не пришлось угадывать, что это за сертификат и кому и кем он выдан.
В терминале эти же действия можно выполнить командой:
/certificate add name=ca country=»RU» state=»31″ locality=»BEL» organization=»Interface LLC» common-name=»ca» key-size=2048 days-valid=3650 key-usage=crl-sign,key-cert-sign sign ca ca-crl-host=192.168.103.1
Следующим шагом выпустим сертификат сервера. Обратите внимание, что сервер обязательно должен иметь выделенный IP адрес и, желательно, доменное имя. Последнее условие не является обязательным, но предпочтительно, так как позволит отвязаться от использования адреса и в случае изменения IP вам не придется перевыпускать сертификаты и менять настройки клиентских подключений.
На закладке Key Usage укажем единственное значение tls server и подпишем наш сертификат закрытым ключом центра сертификации CA.
Эти же действия в терминале:
/certificate add name=vpn.interface31.lab country=»RU» state=»31″ locality=»BEL» organization=»Interface LLC» common-name=»vpn.interface31.lab» subject-alt-name=DNS:»vpn.interface31.lab» key-size=2048 days-valid=3650 key-usage=tls-server sign vpn.interface31.lab ca=»ca»
Теперь можно выпускать клиентские сертификаты, это можно сделать как сразу, так и потом. Никаких особых требований здесь нет, в качестве имени указывайте максимально понятное значение, скажем, ФИО сотрудника или наименование офиса. Потому как понять кому принадлежит сертификат с CN IvanovIA не составит особого труда, в отличие от какого-нибудь безликого client3. Также обратите внимание на опцию Days Valid, не следует выдавать клиентские сертификаты на большой срок.
Команды для терминала:
/certificate add name=SmirnovaMV country=»RU» state=»31″ locality=»BEL» organization=»Interface LLC» common-name=»SmirnovaMV» key-size=2048 days-valid=365 key-usage=tls-client sign SmirnovaMV ca=»ca»
Для использования на клиентских устройствах сертификаты следует экспортировать, наиболее удобно использовать для этого формат PKCS12, который в одном файле содержит закрытый ключ клиента, его сертификат и корневой сертификат CA. Для этого выберите сертификат в списке и в меню правой кнопки мыши укажите действие Export. В поле Type укажите PKCS12, а в Export Passphrase следует указать пароль (не менее 8 символов), в противном случае закрытый ключ выгружен не будет.
Это же можно сделать командой:
/certificateexport-certificate SmirnovaMV type=pkcs12 export-passphrase=0123456789
Настройка IKEv2 VPN-сервера
Здесь мы вступаем в достаточно сложную область настройки IPsec, объем статьи не позволяет подробно останавливаться на назначении каждой настройки, поэтому если вы не уверены в своих действиях, то мы не рекомендуем отклоняться от указанных ниже настроек.
Перейдем в IP — IPsec — Profiles и создадим новый профиль, который задает параметры для установления соединения. Все параметры оставляем по умолчанию, кроме наименования, которому следует дать осмысленное имя.
Либо выполните команду в терминале:
/ip ipsec profileadd name=IKEv2
Затем перейдем на закладку Proposals — предложения, который содержит параметры криптографии предлагаемые для соглассования подключающимся клиентам. Создадим новое предложение, которое сформировано с учетом используемых современными ОС алгоритмов и изменение его состава может либо ослабить безопасность, либо сделать подключение некоторых клиентов невозможным.
Параметры по умолчанию нам не подойдут, поэтому в блоке Encr. Algorithms убираем 3des и добавляем aes-128-cbc, aes-192-cbc, aes-256-cbc.
В терминале достаточно простой команды:
/ip ipsec proposaladd name=IKEv2 pfs-group=none
Здесь мы сталкиваемся с одной особенностью: создаваемые через терминал и Winbox предложения содержат различный набор параметров. То, что создается в терминале полностью соответствует приведенным выше на скриншоте требованиям.
Для выдачи VPN-клиентам нам потребуется отдельный диапазон адресов, перейдем в IP — Pool и создадим новый пул, в нашем случае будет использован диапазон адресов 10.20.0.100 — 10.20.0.199:
Это же действие в терминале:
/ip ipsec mode-configadd address-pool=ikev2-pool address-prefix-length=32 name=IKEv2-cfg split-include=192.168.111.0/24
Если же вам нужно, чтобы клиенты использовали внутренние сервера имен, например, в Active Directory, то флаг System DNS также следует снять и указать адреса требуемых DNS-серверов.
Команда для терминала будет выглядеть так:
/ip ipsec mode-configadd address-pool=ikev2-pool address-prefix-length=32 name=IKEv2-cfg split-include=192.168.111.0/24 static-dns=192.168.111.101,192.168.111.201 system-dns=no
На закладке Groups создадим новую группу, никаких настроек здесь нет, просто укажите уникальное имя:
/ip ipsec policy groupadd name=ikev2-policies
Затем на закладке Policices создадим шаблон политики, которая будет указывать какой именно трафик будет подвергаться обработке IPsec и отправляться в туннель. В поле Src. Address оставляем 0.0.0.0/0, в поле Dst. Address указываем выделенный для VPN-сети диапазон: 10.20.0.0/24, устанавливаем флаг Template и указываем созданную нами ранее группу в поле Group.
На закладке Action в поле Proposal укажите созданный нами ранее набор предложений.
/ip ipsec policyadd dst-address=10.20.0.0/24 group=ikev2-policies proposal=IKEv2 src-address=0.0.0.0/0 template=yes
После чего перейдем в IP — IPsec — Peers создадим новый пир для приема подключений. Сразу установим флаг Passive, в поле Address указываем 0.0.0.0/0 (разрешаем подключаться из любого места), в поле Profile указываем созданный нами профиль, а в поле Exchange Mode укажем протокол обмена ключами — IKE2.
В терминале для получения аналогичного результата выполните:
/ip ipsec peeradd exchange-mode=ike2 name=IKEv2-peer passive=yes profile=IKEv2
На закладке Identities создадим новую настройку идентификации подключающихся клиентов. Здесь много настраиваемых полей и нужно быть предельно внимательными, чтобы ничего не упустить и не перепутать. В поле Peer — указываем созданный нами пир, Auth. Method — способ аутентификации — digital signature, Certificate — сертификат сервера. Policy Template Group — группа шаблонов политик — выбираем созданную нами группу, Mode Configuration — указываем созданную нами конфигурацию для клиентов, Generate Policy — port strict.
Команда для терминала:
/ip ipsec identityadd auth-method=digital-signature certificate=vpn.interface31.lab generate-policy=port-strict mode-config=IKEv2-cfg peer=IKEv2-peer policy-template-group=ikev2-policies
На этом настройка сервера завершена, осталось лишь добавить правила брандмауэра, разрешающие работу с ним. Для того, чтобы клиенты могли подключаться к серверу перейдем в IP — Firewall — Filter Rules и добавим правило: Chain — input, Protocol — udp, Dst. Port — 500, 4500, In. Interface — ваш внешний интерфейс (в нашем случае это ether1). Действие не указываем, так как по умолчанию применяется accept.
Для добавления правила в терминале:
/ip firewall filteradd action=accept chain=input dst-port=500,4500 in-interface=ether1 protocol=udp
Но это еще не все, чтобы VPN-клиенты могли получить доступ к внутренней сети, следует добавить еще одно правило. На закладке General укажите Chain — forward и Interface — внешний интерфейс, затем на Advanced: IPsec Policy — in:ipsec.
/ip firewall filteradd action=accept chain=forward in-interface=ether1 ipsec-policy=in,ipsec
Оба правила следует расположить выше, чем запрещающие в каждой из цепочек.
Прежде всего импортируем сертификат, для этого можно просто выполнить двойной клик на файле сертификата, в открывшемся Мастере импорта в качестве Расположения хранилища укажите Локальный компьютер, остальные параметры принимаются по умолчанию.
Затем создадим новое подключение штатными инструментами. А качестве Типа VPN укажем IKEv2, а в качестве Типа данных для входа — Сертификат. Также обратите внимание, что в строка Имя или адрес сервера должно совпадать с Common Name сертификата сервера, в противном случае подключение установить не удастся.
После чего откроем свойства созданного подключения и перейдем на закладку Безопасность, где установим переключатель Проверка подлинности в положение Использовать сертификаты компьютеров.
Теперь можно подключаться, если все сделано правильно — подключение будет успешно. Проверим таблицу маршрутов:
Как видим, маршрут к нашей внутренней сети 192.168.111.0/24 был добавлен автоматически и никаких ручных настроек клиента не требуется.
Точно также начнем с сертификата, но в данном случае нам потребуется немного больше действий. Будем считать, что сертификат находится в корневой директории пользователя, для которого мы настраиваем подключение. Все последующие команды также следует выполнять от его имени.
Перейдем в домашнюю директорию и создадим скрытую папку для хранения ключей и сертификатов:
cd ~mkdir .ikev2
Теперь нам нужно экспортировать из PKCS12 файла корневой сертификат CA, а также ключ и сертификат пользователя. Начнем с корневого сертификата:
openssl pkcs12 -in cert_export_SmirnovaMV.p12 -out .ikev2/IKEv2_CA.crt -nodes -nokeys -cacerts
Затем экспортируем сертификат клиента:
openssl pkcs12 -in cert_export_SmirnovaMV.p12 -out .ikev2/SmirnovaMV.crt -nodes -nokeys
И его закрытый ключ. При экспорте закрытого ключа нас попросят установить для него пароль, минимальная длинна пароля 8 символов. Пропустить этот шаг нельзя.
openssl pkcs12 -in cert_export_SmirnovaMV.p12 -out .ikev2/SmirnovaMV.pass.key -nocerts
На каждом из этих этапов нам нужно будет вводить парольную фразу, указанную при экспорте сертификата пользователя на роутере.
И наконец уберем пароль с закрытого ключа пользователя:
openssl rsa -in .ikev2/SmirnovaMV.pass.key -out .ikev2/SmirnovaMV.key
Во время этого действия вы должны будете ввести пароль, который указали при создании ключа.
Для того, чтобы иметь возможность создавать VPN-подключения в графическом интерфейсе установим необходимый плагин для Network Manager:
sudo apt install network-manager-strongswan
После чего вам станут доступны настройки VPN IKEv2 соединения.
Настройки соединения достаточно просты. В секции Gateway указываем адрес сервера и путь к корневому сертификату CA. В секции Client устанавливаем Authentication: Certificate/private key и указываем пути к сертификату и закрытому ключу клиента. И в секции Option обязательно устанавливаем флаг Request an inner IP address. На этом настройка соединения окончена, можно подключаться.
Если мы после подключения проверим таблицу маршрутизации, то не обнаружим маршрута к офисной сети, но при этом она будет доступна:
Но никакой ошибки здесь нет. Просто Linux в данной ситуации поступает более правильно, вместо маршрута в системе создается соответствующая политика IPsec, которая направляет трафик к внутренней сети в туннель согласно тому, что мы указали в конфигурации клиента (Mode Configs) на роутере.
С ростом значения интернета в нашей повседневной жизни все более востребованными становятся различные сетевые технологии. Если раньше VPN был преимущественно уделом крупных организаций, то сегодня он используется чуть ли не в каждой сети, действительно, сотрудники стали мобильными и удаленный доступ к ресурсам сети уже не блажь, а насущная необходимость. Настройка роутера Mikrotik как VPN-клиента вопрос, на первый взгляд, простой, но есть некоторые не очевидные моменты, которые мы разберем в данной статье.
В прошлых материалах мы уже коротко рассматривали типы VPN и обращали внимание на неоднозначность используемой терминологии, традиционно термином VPN называют клиент-серверные соединения, где кроме туннельного протокола применяются вспомогательные технологии для установления соединения и контроля его состояния, аутентификации пользователя, согласования параметров подключения и т.д. и т.п. Одним из таких протоколов является PPP.
В рамках данной статьи мы будем рассматривать варианты настройки Mikrotik именно в качестве клиента для поддерживаемых типов VPN-серверов, оставив за кадром туннельные подключения (GRE, IP-IP, EoIP и т.д.). Для работы с этим типом соединений используется специальный раздел PPP, на закладке Interfaces которого можно добавить сетевой интерфейс для нужного типа VPN-клиента. Поддерживаются PPTP, L2TP, SSTP и OpenVPN подключения. Также в списке присутствуют устаревший PPP и PPPoE, который используется для организации доступа в интернет, в данном контексте эти протоколы интереса не представляют.
Также аналогичные действия можно выполнить и в разделе Interfaces, никакой разницы откуда вы будете добавлять сетевой интерфейс нет. Но не будем спешить и перейдем на закладку Profiles, где находятся профили используемые при коммутируемых подключениях. По умолчанию созданы два профиля: default и default-encryption, в которых содержатся некоторые настройки для подключения. Почему некоторые? Потому что большинство опций подключения задаются сервером и клиент должен применять именно их, иначе подключение будет невозможным. Поэтому если вы заглянете в эти профили, то увидите, что большинство настроек там не активно.
Единственным различием двух профилей является опция Use Encryption, которая в default-encryption установлена в положение yes и требует обязательного шифрования подключения. Данная опция игнорируется протоколами SSTP и OpenVPN, которые всегда используют шифрованные подключения.
Означает ли это, что если мы выберем профиль default, то ваше соединение не будет шифроваться? Нет, если сервер использует шифрование и не допускает небезопасных подключений, то ваше соединение также будет зашифровано. Но вот если сервер разрешает небезопасные подключения, то клиент вполне может подключиться без шифрования, таким образом можно осуществить атаку с подменой сервера, когда вы получите незашифрованное подключение и не будете знать об этом. Поэтому если вам явно требуется шифрование канала всегда выбирайте профиль default-encryption.
Мы не советуем менять настройки в стандартных профилях, если вам нужно явно задать иные настройки подключения, то создайте собственный профиль. Также учтите, что опция Use Compression игнорируется для OpenVPN соединений, которые в реализации от Mikrotik не могут использовать сжатие трафика.
PPTP-клиент
Пожалуй, это самый простой в настройке тип соединений. Несмотря на то, что используемое в PPTP шифрование не является надежным, этот протокол продолжает широко использоваться благодаря низким накладным расходам и высокой скорости работы, например, для доступа в интернет.
Для настройки PPTP клиента добавьте интерфейс типа PPTP Client и перейдите на закладку Dial Out, где расположены сетевые настройки.
Опция Keepalive Timeout указывает время переподключения соединения в случае обрыва связи. Бытует мнение, что лучше делать это значение поменьше, мол быстрее будет переподключаться туннель. Но это не так, во-первых, при неполадках на сервере вы будете активно забивать канал и нагружать сервер служебным трафиком, а во-вторых, при кратковременных перебоях связи короткое время будет вызывать переподключение с обрывом всех соединений в канале, а большее значение позволит сохранить туннель. Особенно это актуально для мобильного интернета или беспроводных каналов.
Опция Add Default Route создаст маршрут по умолчанию через туннель, т.е. направит туда весь исходящий трафик, указывайте ее только в том случае, если данный туннель основной способ доступа в интернет.
Никаких иных особенностей и подводных камней здесь нет и если вы правильно указали настройки, то клиент должен будет без проблем подключиться к серверу.
L2TP-клиент
Говоря про L2TP, обычно подразумевают L2TP/IPsec, потому как без шифрования данный протокол в корпоративной среде не используется. Но есть и исключения, некоторые провайдеры, например, Билайн, используют чистый L2TP без шифрования. В этом случае настройки подключения будут выглядеть так:
Обратите внимание на используемый профиль — default, так как соединение не зашифрованное, с профилем default-encryption вы не сможете подключиться к серверу провайдера. Add Default Route ставим только если это основное соединение с интернет. Также имеет смысл использовать опцию Allow Fast Path, для разгрузки CPU, особенно на младших моделях, но учтите, что с данной опцией соединение может работать неустойчиво, в таком случае ее придется отключить.
Для работы с L2TP/IPsec настройки будут немного иные, во-первых, используем профиль default-encryption и включаем использование IPsec установкой флага Use IPsec, при этом становится активным поле IPsec Secret, куда вводим предварительный ключ.
Опция Allow Fast Path при использовании IPsec игнорируется и в ее установке нет никакого смысла, так же не забывайте про опцию Add Default Route, в большинстве корпоративных сценариев устанавливать ее не следует.
Вроде бы тоже ничего сложного в настройках L2TP/IPsec нет, но если вы попытаетесь подключиться к Windows Server, то у вас ничего не получится. В чем же дело? А дело в настройках IPsес, перейдем в IP — IPsec — Proposal и откроем настройку по умолчанию. Proposal или предложение IPsec содержит список алгоритмов защиты канала, которые устройство предлагает для установления соединения. Понятно, что для успешного установления канала поддерживаемые методы защиты должны совпадать.
В предложении IPsec по умолчанию обращаем внимание на опцию PFS Group, она отвечает за применение технологии совершенной прямой секретности (Perfect forward secrecy, PFS), которая предусматривает создание уникальных сессионных ключей по алгоритму Диффи-Хеллмана, что делает невозможным расшифровку перехваченного IPsec трафика даже при наличии долговременных ключей (в данном случае предварительного ключа).
Windows Server по умолчанию не поддерживает совершенную прямую секретность, поэтому PFS Group нужно выставить в состояние none, после чего соединение успешно установится.
Обратите внимание, что в данном случае мы изменили настройку по умолчанию, но в данном случае это оправдано. Настройки IPsec достаточно сложны и вряд-ли человек не имеющий опыта работы с данной технологией сможет все правильно настроить с первого раза. Но это изменение следует учитывать при создании других соединений, использующих IPsec и приводить настройки с обоих сторон к общему виду.
Хотя более правильным является создание своего предложения (Proposal) и политики (Police) для каждого соединения, но эта тема далеко выходит за рамки статьи.
SSTP-клиент
Мы не будем останавливаться на уже описанных нами опциях, которые общие для всех видов коммутируемых подключений, а сосредоточимся на новых, свойственных именно этому типу VPN. SSTP относится к отдельной подгруппе SSL VPN, которые используют трафик практически не отличимый от HTTPS, что серьезно затрудняет выявление и блокирование таких туннелей.
На что следует обратить внимание при настройке? Давайте сначала посмотрим на окно настроек:
Как видим, появилась опция Port, где мы можем указать порт подключения, по умолчанию это 443, но можно использовать и любой иной, если 443 порт занят, например, веб-сервером. Также SSTP может прекрасно работать через прокси, в этом случае вам потребуется указать адрес прокси-сервера и используемый им порт в опциях Proxy и Proxy Port.
Также вспоминаем, что SSTP всегда использует шифрование канала, поэтому оно будет работать вне зависимости от выбранного профиля, в данном случае default и default-encryption будут работать одинаково.
Теперь перейдем к специфичным для протокола настройкам, которые мы обвели зеленой рамкой. Поле Certificate используется для указания клиентского сертификата в том случае, если сервер использует аутентификацию по сертификатам, в этом случае его потребуется загрузить на устройство и импортировать в разделе System — Certificates. Во всех остальных случаях в поле должно стоять none.
TLS Version указывает на допустимые к использованию версии TLS, однако это определяется сервером, но следует стараться использовать только протокол TLS 1.2, что позволяет исключить атаки с понижением протокола.
Опция Verify Server Certificate не является обязательной, но позволяет проверить подлинность сервера, исключая атаки типа человек посередине, для этого потребуется импортировать на Mikrotik сертификат центра сертификации (СА) выдавшего сертификат серверу.
Установка флага в поле PFS включает совершенную прямую секретность, но эта опция должна поддерживаться со стороны сервера.
OpenVPN-клиент
Реализация OpenVPN в Mikrotik вызывает много нареканий, так как сводит на нет все сильные стороны данной технологии и делает ощутимыми слабые. OVPN-клиент не поддерживает сжатие данных и работу по протоколу UDP, если первое не столь значимо на современных каналах, то OpenVPN поверх TCP имеет очень большие накладные расходы и вызывает как повышенную нагрузку на оборудование, так и плохую утилизацию канала. Поэтому от использования OpenVPN на Mikrotik по возможности следует отказаться.
Обычно комплект для подключения OpenVPN клиента составляют сертификат СA, сертификат и закрытый ключ клиента, конфигурационный файл. Нам понадобятся только сертификат и ключ клиента, а если мы хотим проверять подлинность сервера, то еще и сертификат CA, но он не является обязательным для настройки подключения.
Прежде всего загрузим сертификаты и ключи на Mikrotik, затем перейдем в System — Certificates и импортируем сертификат клиента. Он появится в списке сертификатов и напротив него будет буква T, что обозначает trusted, т.е. устройство доверяет этому сертификату. Затем импортируем ключ, здесь важно соблюдать именно эту последовательность, сначала сертификат, потом ключ.
После успешного импорта ключа флаги сменятся на KT, где буква K обозначает наличие закрытого ключа для сертификата. Затем аналогичным образом импортируем сертификат CA сервера, импорт ключа для данного сертификата не нужен. Закрытый ключ CA является самой большой тайной и должен хранится с соблюдением всех мер предосторожности и не при каких обстоятельствах не должен покидать узел СA (центра сертификации).
Теперь рассмотрим поближе окно настроек подключения, адрес подключения и порт не должны вызвать затруднений, а вот остальные опции нуждаются в пояснении, значимые мы выделили зеленой рамкой.
Mode задает режим работы канала, в терминах OpenVPN ip — это tun (L3), а ethernet — это tap (L2), следует помнить, что режим работы определяется сервером. В поле Certificate укажите импортированный сертификат клиента. Опции Auth и Cipher указывают на используемые сервером криптографические алгоритмы для аутентификации и шифрования, если вы укажете отличные от указанных в конфигурации сервера — то соединение установить не удастся. Если алгоритм аутентификации явно не указан в конфигурации сервера, то по умолчанию используется SHA1.
При настройке OpenVPN клиента на Mikrotik следует помнить, что сервер должен поддерживать соединения по протоколу TCP, без сжатия и TLS-аутентификации, в противном случае подключиться к серверу не удастся.
Опция Verify Server Certificate позволяет проверить подлинность сертификата сервера, что защищает от атак типа человек посередине, но требует импорта сертификата CA сервера.
Маршрутизация
Если VPN соединение используется для доступа к корпоративной сети или предназначено для связи сетей, то вам потребуется указать маршруты для правильной пересылки пакетов. Так если мы хотим получить доступ к сети за VPN-севером, то нам потребуется создать маршрут к этой сети, указав в качестве шлюза интерфейс нашего VPN-клиента, например так:
В данном примере мы отправляем все пакеты к сети 192.168.200.0/24 через L2TP-подключение l2tp-out1. Если вы понимаете основы маршрутизации, то указание правильных маршрутов для вас не составит труда.
Отдельного внимания заслуживает опция Pref. Source, которая не является обязательной, но ее следует указывать, если роутер обслуживает несколько сетей, в ней указывается адрес, с которого роутер будет посылать пакеты по указанному маршруту. Без ее указания доступ роутера к ресурсам удаленных сетей может оказаться невозможным (как и удаленных сетей к нему), на работу клиентов в сетях это не влияет. В качестве значения следует указать адрес, принадлежащий той сети, к которой имеется маршрут с противоположной стороны (т.е. сети за сервером).
Настройка site-to-site VPN между Kerio и MikrotikДобрый день! Есть задача — настроить VPN-соединение между офисами. В удаленном — Kerio Control.
VPN site to site, Kerio MikrotikЗдравствуйте. Не могу настроить VPN тунель. На данном этапе пытаюсь только создать само.
Site to Site IPSec VPN CISCO891-K9 & Cisco RV120W Wireless-N VPN FirewallДобрый день. Есть роутер CISCO891-K9 на котором есть один site to site vpn туннель с таким же.
Не могу создать vpn site to site на cisco asa 5506-xРебята нужна помощь в создании vpn на firewall cisco asa 5506-x, в гугле нет ничего обэтом.
vpn между миктотиками или микротиком и ПК?
на виндовс столкнулся с такой-же проблемой, там нужно как-то по особенному импортировать сертификат, сейчас уже не помню, но тоже намучился, плюнул, поставил сертификат letsencrypt и забыл
Сегодня поговорим о том как настроить SSTP Server на MikroTik. Расшифровывается аббревиатура как Secure Socket Tunneling Protocol – PPP туннель аутентифицирует через TLS канал. Использует TCP порт 443 и фактически проходит через все фаерволы и прокси сервера. Впервые был представлен в Windows Vista SP1. С того момента прошло много времени, но не зря, т.к. все поняли очевидные его плюсы, а именно:
- Безопасный, используются алгоритмы AES;
- Хорошо проходим, тесты показывают установку соединения из Тайландского WiFi в отеле и обычного Украинского провайдера;
- Полностью поддерживается MS Windows.
- работает на одном ядре;
- уязвим перед некоторыми атаками MITM (скорее фантастика).
В сегодняшней статье мы рассмотрим настройку SSTP сервера на роутере микротик с версией 6.46.4 и клиента на операционной системе Windows 10 Pro 1909. Идеальное решение для предоставления пользовательского подключения к корпоративной сети и не только. Прикрутив коммерческий сертификат, вы снимаете с себя ручное добавление его в машинах Windows. Но в качестве демонстрации, мы будем использовать само подписанный. Так же возможно настроить Site to Site туннель между двумя Mikrotik, причем без них, что крайне не рекомендую.
Схема сети
- Сервер SSTP имеет адрес 192.168.100.2;
- Клиентский ПК получает из пула 192.168.1.0/24;
- Маршрутизируемая сеть между удаленными площадками.
Если вы хотите углубить свои знания по работе с роутерами MikroTik, то наша команда рекомендует пройти курсы которые сделаны на основе MikroTik Certified Network Associate и расширены автором на основе опыта . Подробно читайте ниже.
Настройка сервера SSTP
Конфигурация устройства проста. Имеем RouterBoard с настроенным выходом в интернет. Подключение будет происходить по сертификату, в котором вместо имени указан IP адрес. Первым делом нужно создать сертификат центра сертификации. Переходим в System – Certificates и создаем новый.
В поле Name указываем понятное имя, отображаемое в списке;
Вы так же можете указать длину ключа и срок действия.
Далее переходим в Key Usage. Снимаем галки со всего, оставляя только на crl sign и key cert. sign.
Жмем Apply и Sign. В новом открывшемся окне подписания, стартуем процесс подписи кнопкой Start.
По завершении увидим в Progress состояние done и аббревиатуру KAT возле CA.
Далее создаем сертификат самого сервера SSTP, который будет указан в качестве основного на интерфейсе. Жмем плюс и заполняем все поля аналогично предыдущему, за исключением понятного имени.
На вкладке Key Usage добавляем галочки tls client и tls server.
Жмем Apply и Sign. В открывшимся окне подписи в поле CA выбираем корневой сертификат и стартуем процесс.
Далее создадим профиль подключения для клиентов. PPP – Profiles. Указываем понятное имя профиля;
- адрес в туннеле;
- разрешаем TCP MSS;
- запрещаем UPnP.
- Use MPLS – запретить;
- Use Compression – разрешить;
- Use Encryption – разрешить;
В Limits выставляем Only One в no.
Создадим пользователя в Secrets.
- Name – имя пользователя, регистр имеет значение;
- Password – пароль;
- Service – SSTP;
- Profile – созданный выше;
- Remote Address – адрес в туннеле.
Сохраняем и переходим в PPP – interfaces. Нас интересует вкладка SSTP Server.
Открыв ее, указываем следующие значения:
- Enable – ставим галочку;
- Default Profile – ранее созданный;
- Authentication – mschapv2;
- Certificate – Server;
- Force AES, PFS – включаем.
Если страшно, то можно выставить TLS Version в only 1.2. Двигаемся дальше к фаерволу. Просто одно правило. Разрешить входящий трафик на 443 порт – все.
Настройка SSTP клиента на Микротик
Для дальнейшей конфигурации нам нужен сертификат центра сертификации добавить в доверенные компьютера. Иначе начнется песня со списком отзывов и в этом роде. Конечно, таких проблем не будет, используя коммерческий. Но его нужно сначала выгрузить. Открываем System – Certificates, выбираем CA и жмем Export.
В Files должен появится экспорт. Передаем его любым удобным способом на клиентскую машину.
Далее вы можете вручную его добавить в доверенные ПК, но я предпочитаю это делать скриптом. Сохраняем в формате .bat
Создаем на рабочем столе папу CA, копируем туда CA.crt и запускаем из-под администратора батник.
Проверяем что все хорошо.
Далее переходим в Центра управления сетями и общим доступом – Создание и настройка нового подключения или сети.
Подключение к рабочему месту.
Использовать мое подключение к Интернету.
Указываем адрес и имя будущего интерфейса.
Сохраняем и пытаемся подключиться.
На момент написания статьи у меня вышла такая ошибка.
Это было связанно со временем. Т.к. в виртуальных машинах оно идет по-другому. Открыв свойства сертификата, заметил, что срок, с которого действителен еще не наступило. Исправив время на правильное, все заработало. Вывод, не используйте само подписанные. Проверим подключение на клиенте и сервере.
На этом пожалуй все, в этой статье мы показали как можно легко создать SSTP сервер на роутере Микротик и подключить к нему клиента Windows 10. Спасибо за внимание и до новых встреч.
89 вопросов по настройке MikroTik
Есть задача подключиться к удаленной сети по VPN SSTP. Скорее всего, в роли VPN-сервера выступает Windows server 2008, точно не известно.
Для подключения, администратор удаленной сети, выдал
Настроил VPN на рабочей станции (Windows 7) — все заработало. Есть доступ к удаленной сети, хосты отвечают на пинги, по RDP можно подключится.
Попытался настроить на маршрутизаторе Mikrotik c RouterOS v.6.34.3:
Как я понял, подключение инициализируется, сервер отвечает, и на стадии проверки сертификата соединение обрывается.
Не могу понять, где я ошибся или что не настроил.
Ответы (2 шт)
no key for certificate found
Требует файл с ключом. *.key. Сам сталкивался с этой проблемой, т.е. одного корневого сертификата мало микротику, не смотря на то, что настраивается только клиент. Как это обойти-настроить не нашел, просто вставил ключ, благо я и был администратором.
Секреты настройкифайрвола через
Обнаружена блокировка рекламы: Наш сайт существует благодаря показу онлайн-рекламы нашим посетителям. Пожалуйста, подумайте о поддержке нас, отключив блокировщик рекламы на нашем веб-сайте.
VPN-SSTP ошибка 0х80090326. + Изменился отпечаток сертификата.
VPN: клиент-сервер. Сервер RB2011UAS, v6.42.6.
Показалось странным, что выпущенный на Mikrotik сертификат и сертификат, экспортированный из Mikrotik и установленный в хранилище Win7, имеют разный отпечаток. К сожалению, в работающем варианте отпечатки не сравнивались. Что посоветуете?