Настройка SSTP на MikroTik для объединения офисов с аутентификацией с помощью сертификатов
Введение
Статья содержит пошаговое руководство по настройке протокола SSTP на MikroTik RouterOS v7 для объединения двух офисов (site-to-site VPN). Также описана настройка маршрутизации и брандмауэра, приведены типичные проблемы и способы проверки полученных результатов. Все операции демонстрируются как через графический интерфейс WinBox 3 и WinBox 4, так и через командную строку (CLI).
Протокол SSTP работает по клиент-серверной модели, т.е. один маршрутизатор должен быть SSTP-сервером, принимающим подключения, а второй – SSTP-клиентом, инициирующим подключения. Для возможности установления соединения через Интернет внешний интерфейс маршрутизатора, на котором будет настроен SSTP-сервер, должен иметь маршрутизируемый в Интернете (публичный, «белый») IP-адрес. Если такие адреса есть на обоих маршрутизаторах, то чаще всего SSTP-сервер располагают в головном офисе. Если же такой IP-адрес есть только в одном из офисов, то SSTP-сервер располагают именно в нем.
| Рисунок 1. Схема сети |
| Параметр маршрутизатора | Офис 1 | Офис 2 |
|---|---|---|
| Имя | R1 | R2 |
| Тип VPN-интерфейса | SSTP-сервер | SSTP-клиент |
| Адрес VPN-интерфейса | 172.16.1.1/32 | 172.16.1.2/32 |
| Адрес внешнего (WAN) интерфейса | 100.64.111.1/24 | 100.64.222.1/24 |
| Адрес внутреннего (LAN) интерфейса | 10.11.11.1/24 | 10.22.22.1/24 |
| Адрес внутренней (LAN) сети | 10.11.11.0/24 | 10.22.22.0/24 |
Углубленный курс «Администрирование сетевых устройств MikroTik» Онлайн-курс по MikroTik с дипломом государственного образца РФ. Много лабораторных работ с проверкой официальным тренером MikroTik. С нуля и до уровня MTCNA. ИП Скоромнов Дмитрий Анатольевич, ИНН 331403723315
На Telegram-канале Mikrotik-сэнсей можно получить доступ к закрытой информации от официального тренера MikroTik. Подписывайтесь ИП Скоромнов Дмитрий Анатольевич, ИНН 331403723315
Настройка центра сертификации
Общее описание
В статье описана настройка на MikroTik самоподписанных сертификатов для SSTP-подключения site-to-site. Все настройки выполняются на R1. Для этого надо выполнить следующие шаги:
- активировать список отзыва сертификатов,
- создать сертификаты,
- подписать сертификаты,
- экспортировать сертификаты.
Активация списка отзывов сертификатов
Список отзывов сертификатов на английском языке называется Certificate Revocation List (CRL). На устройствах MikroTik за активацию CRL отвечает параметр Use CRL, который находится в System → Ceritificates → вкладка Certificates → кнопка Settings. Если не использовать CRL, то сервер не сможет проверять отозваны ли сертификаты SSTP-клиентов и запрещать подключения в случае отзыва. Если же сертификаты клиентов не отзывать, а удалять сертификаты из хранилища сертификатов, то клиенты все-равно смогут подключиться. В рамках данной статьи SSTP-сервер будет проверять не отозваны ли сертификаты клиентов. Настройка проверки клиентами сервера значительно усложнила бы данную статью и поэтому находится за ее рамками.
Настройка через графический интерфейс
Через WinBox 3
| Рисунок 2. Включение на R1 проверки списка отзывов сертификатов |
Через WinBox 4
| Рисунок 3. Включение на R1 проверки списка отзывов сертификатов |
Настройка через командную строку
/certificate/settings set crl-use=yes
Создание сертификатов
На этом шаге на R1 необходимо создать следующие сертификаты:
- сертификат удостоверяющего центра (корневой сертификат), расположенного на R1,
- сертификат SSTP-сервера, расположенного на R1,
- сертификат SSTP-клиента, расположенного на R2.
При создании сертификатов надо заполнить следующие поля:
- Поле Name является обязательным для всех сертификатов и позволяет идентифицировать сертификат в хранилище сертификатов RouterOS. Значение поля можно изменять и после подписания сертификата.
- Поля Country, State, Locality, Organization и Unit не являются обязательными для всех сертификатов, но хотя бы одно из них должно быть заполнено, иначе система не даст подписать сертификат.
- Поле Common Name (CN), не является обязательным, устарело и практически не используется по исходному назначению в современных реализациях TLS-клиента и TLS-сервера. Раньше в нем указывался или IP-адрес или доменное имя хоста. В настоящее время поле чаще всего используется в качестве понятного для человека идентификатора сертификата.
- Поле Subject Alt. Name (SAN) является обязательным для сертификата SSTP-сервера и SSTP-клиента и не является обязательным для сертификата удостоверяющего центра. Таких полей может быть более одного. Значение поля должно полностью совпадать с параметром подключения к серверу. Если клиент подключается по IP-адресу, то должен быть указан именно IP-адрес (тип Subject Alt. Name: IP). Если клиент подключается по доменному имени, то должно быть указано именно доменное имя (тип Subject Alt. Name: DNS). Либо можно указать оба этих параметра, в т.ч. каждое по несколько раз. Это позволит подключаться и по IP-адресу и по доменному имени на выбор. Если на стороне SSTP-клиента нет постоянного IP-адреса или доменного имени, то надо использовать тип Subject Alt. Name: Email, в котором необходимо указать произвольные данные в формате почтового адреса. Пример: sotrudnik1@r1.vpn.
- Чек-бокс trusted указывает на то является ли сертификат доверенным. Если сертификат удостоверяющего центра (УЦ, CA, Certificate Authority) не будет доверенным, то все сертификаты, выданные этим УЦ также будут считаться недоверенными и с ними не получится установить соединение.
- Поле Day Usage является обязательным для всех сертификатов. В поле указывается срок службы сертификата, который по умолчанию равен 365 дней. В статье указано значение 3650 дней.
- Чек-боксы в блоке Key Usage:
- для корневого сертификата нужно указать: key cert. sign и crl sign,
- для сертификата сервера нужно указать tls server,
- для клиента нужно указать параметр tls client.
Настройка через графический интерфейс
Через WinBox 3
| Рисунок 4-1. Создание на R1 сертификата удостоверяющего центра |
| Рисунок 4-2. Создание на R1 сертификата удостоверяющего центра |
| Рисунок 5-1. Создание на R1 сертификата SSTP-сервера |
| Рисунок 5-2. Создание на R1 сертификата SSTP-сервера |
| Рисунок 6-1. Создание на R1 сертификата SSTP-клиента |
| Рисунок 6-2. Создание на R1 сертификата SSTP-клиента |
Через WinBox 4
| Рисунок 7-1. Создание на R1 сертификата удостоверяющего центра |
| Рисунок 7-2. Создание на R1 сертификата удостоверяющего центра |
| Рисунок 8-1. Создание на R1 сертификата SSTP-сервера |
| Рисунок 8-2. Создание на R1 сертификата SSTP-сервера |
| Рисунок 9-1. Создание на R1 сертификата SSTP-клиента |
| Рисунок 9-2. Создание на R1 сертификата SSTP-клиента |
Настройка через командную строку
/certificate add name=CA country=RU unit=R1 key-usage=key-cert-sign,crl-sign days-valid=3650 add name="TLS Server" country=RU unit=R1 key-usage=tls-server common-name=Server subject-alt-name=IP:100.64.111.1 days-valid=3650 add name=R2 country=RU unit=R2 key-usage=tls-client common-name=R2 subject-alt-name=IP:100.64.222.1 days-valid=3650
Подписание сертификатов
Далее необходимо подписать:
- Сертификат удостоверяющего центра. Это подписание обязательно должно быть первым. В поле CA CRL Host необходимо указать IP-адрес 127.0.0.1.
- Сертификат SSTP-сервера. В поле CA необходимо указать сертификат удостоверяющего центра.
- Сертификат SSTP-клиента. В поле CA необходимо указать сертификат удостоверяющего центра.
Через графический интерфейс
Через WinBox 3
| Рисунок 10. Подписание на R1 сертификата удостоверяющего центра |
| Рисунок 11. Подписание на R1 сертификата SSTP-сервера |
| Рисунок 12. Подписание на R1 сертификата SSTP-клиента |
Через WinBox 4
| Рисунок 13. Подписание на R1 сертификата удостоверяющего центра |
| Рисунок 14. Подписание на R1 сертификата SSTP-сервера |
| Рисунок 15. Подписание на R1 сертификата SSTP-клиента |
Через командную строку
/certificate sign CA ca-crl-host=127.0.0.1 sign "TLS Server" ca=CA sign R2 ca=CA
Экспорт сертификатов
Далее необходимо экспортировать:
- Сертификат УЦ в формате PEM без указания пароля (passphrase). В итоге в файловом хранилище появится файл с расширением .crt.
- Сертификат SSTP-клиента в формате PEM с указанием пароля (passphrase). В итоге в файловом хранилище появится файл с расширениями .crt (открытый ключ) и файл с расширением .key (закрытый ключ).
Настройка через графический интерфейс
Через WinBox 3
| Рисунок 16. Экспорт на R1 открытого ключа удостоверяющего центра |
| Рисунок 17. Экспорт на R1 открытого и закрытого ключей SSTP-клиента |
Через WinBox 4
| Рисунок 18. Экспорт на R1 открытого ключа удостоверяющего центра |
| Рисунок 19. Экспорт на R1 открытого и закрытого ключей SSTP-клиента |
Настройка через командную строку
/certificate export-certificate CA type=pem export-certificate R2 export-passphrase=12345678 type=pem
Настройка SSTP-соединения
Настройка SSTP-сервера
Общее описание
SSTP-сервер расположен на маршрутизаторе R1. Для его настройки необходимо выполнить следующие действия:
Включить SSTP-сервер. Аутентификация (проверка подлинности учетных данных клиента) выполняется силами протокола SSTP. Необходимо применять только аутентификацию MS-CHAPv2 как наиболее безопасную.
Создать учетную запись. Чтобы упростить работу с учетными записями в будущем, рекомендуется использовать названия, которые сразу будут указывать на конкретный офис (например, «office-samara» или «office-novosibirsk») вместо абстрактных «office-1», «office-2» и т. д. Это позволит избежать путаницы при большом количестве подобных записей.
Создать статическую запись SSTP-сервера. Наличие такой записи не является обязательным, т.к. и без нее необходимый виртуальный интерфейс будет создаваться динамически при каждом новом подключении. Однако, что динамический интерфейс исчезнет после разрыва соединения и, даже если после восстановления соединения заново появится с тем же самым именем, то уже не отобразится в правилах, в которых ранее мог быть использован. Таким образом это может нарушить работу правил Firewall, Mangle, NAT и других блоков. А при наличии статической записи SSTP-сервера такой проблемы не возникает.
Настройка через графический интерфейс
| Рисунок 20. Настройка на R1 SSTP-сервера |
| Рисунок 21. Настройка на R1 SSTP-сервера |
| Рисунок 22. Создание на R1 учетной записи на SSTP-сервере |
| Рисунок 23. Создание на R1 учетной записи на SSTP-сервере |
| Рисунок 24. Создание на R1 статического интерфейса на SSTP-сервере |
| Рисунок 25. Создание на R1 статического интерфейса на SSTP-сервере |
Настройка через командную строку
/interface/sstp-server/server set authentication=mschap2 certificate="TLS Server" enabled=yes verify-client-certificate=yes /ppp/secret add local-address=172.16.1.1 name=office-2 password=office-2_password profile=default-encryption remote-address=172.16.1.2 service=sstp /interface/sstp-server add name="SSTP Server for office-2" user=office-2
Настройка SSTP-клиента
Общее описание
SSTP-клиент расположен на маршрутизаторе R2. Для его настройки необходимо выполнить два действия:
Перенести на R2 сертификаты, ранее экспортированные на R1, и импортировать их
- Сертификат УЦ с расширением .crt (открытый ключ).
- Сертификаты SSTP-клиента с расширением .crt (открытый ключ) и с расширением .key (закрытый ключ).
Создать SSTP-интерфейс. На этом этапе необязательно настраивать аутентификацию только с помощью MSCHAPv2, т.к. сервер все равно будет разрешать подключения только с этим способом аутентификации.
Настройка через графический интерфейс
| Рисунок 26-1. Импорт сертификатов на R2 |
| Рисунок 26-2. Импорт сертификатов на R2 |
| Рисунок 26-3. Импорт сертификатов на R2 |
| Рисунок 27-1. Импорт сертификатов на R2 |
| Рисунок 27-2. Импорт сертификатов на R2 |
| Рисунок 27-3. Импорт сертификатов на R2 |
| Рисунок 28-1. Настройка на R2 SSTP-клиента |
| Рисунок 28-2. Настройка на R2 SSTP-клиента |
| Рисунок 29-1. Настройка на R2 SSTP-клиента |
| Рисунок 29-2. Настройка на R2 SSTP-клиента |
Настройка через командную строку
/certificate import file-name=cert_export_CA.crt name="CA R1" import file-name=cert_export_R2.crt name=R2 import file-name=cert_export_R2.key passphrase=12345678 /interface/sstp-client add certificate=R2 connect-to=100.64.111.1 disabled=no name="SSTP office-1 connection" password=office-2_password profile=default-encryption user=office-2 verify-server-certificate=yes
Чек-лист по настройке MikroTik Проверьте свою конфигурацию по 28-ми пунктам. Подходит для RouterOS v6 и v7. Дата публикации: октябрь 2025.
Проверка SSTP-соединения
Общее описание
И на SSTP-сервере, и на SSTP-клиенте при успешном установлении соединения рядом с интерфейсом должен появиться флаг «R», что значит running, т. е. «запущено».
Проверка на SSTP-сервере
Проверка через графический интерфейс
| Рисунок 30. Проверка на R1 работоспособности туннеля на SSTP-сервере |
| Рисунок 31. Проверка на R1 работоспособности туннеля на SSTP-сервере |
Проверка через командную строку
В результате выполнения команды
/interface/sstp-server print
должен появиться следующий результат:
[admin@R1] > /interface/sstp-server print Flags: R - RUNNING Columns: NAME, USER, MTU, CLIENT-ADDRESS, UPTIME, ENCODING # NAME USER MTU CLIENT-ADDRESS UPTIME ENCODING 0 R SSTP Server for office-2 office-2 1500 100.64.222.1 1m45s AES256-CBC
Проверка на SSTP-клиенте
Проверка через графический интерфейс
| Рисунок 32. Проверка на R2 работоспособности туннеля на SSTP-клиенте |
| Рисунок 33. Проверка на R2 работоспособности туннеля на SSTP-клиенте |
Проверка через командную строку
В результате выполнения команды
/interface/sstp-client print
должен появиться следующий результат:
[admin@R2] > /interface/sstp-client print
Flags: X - disabled; R - running; H - hw-crypto
0 R name="SSTP office-1 connection" max-mtu=1500 max-mru=1500 mrru=disabled
connect-to=100.64.111.1 port=443 http-proxy=:: proxy-port=443
certificate=R2 verify-server-certificate=yes
verify-server-address-from-certificate=yes user="office-2"
password="office-2_password" profile=default-encryption
keepalive-timeout=60 add-default-route=no dial-on-demand=no
authentication=pap,chap,mschap1,mschap2 pfs=no tls-version=any
ciphers=aes256-sha add-sni=no
Настройка маршрутизации
Для передачи данных между двумя сетями недостаточно наличия VPN-соединения. Чтобы она стала возможной, на каждом устройстве нужно добавить маршрут к внутренней сети другого офиса через IP-адрес VPN-интерфейса противоположного маршрутизатора. Для этого необходимо:
- на маршрутизаторе R1 создать маршрут до внутренней сети офиса 2 (10.22.22.0/24) через VPN-интерфейс маршрутизатора R2 (172.16.1.2);
- на маршрутизаторе R2 создать маршрут до внутренней сети офиса 1 (10.11.11.0/24) через VPN-интерфейс маршрутизатора R1 (172.16.1.1).
Для такой настройки понадобятся два параметра:
- Dst. Address (dst-address), в котором нужно указать IP-адрес удаленной сети;
- Gateway (gateway), в котором нужно указать IP-адрес VPN-интерфейса противоположного маршрутизатора.
Маршрут к внутренней сети другого офиса в некоторых случаях можно настраивать не через IP-адрес VPN-интерфейса противоположной стороны, а через интерфейс, из которого будут исходить пакеты. Но такую возможность следует использовать только в некоторых случаях, и ее надо использовать с пониманием, зачем это делается.
Настройка маршрутизации на маршрутизаторе R1 (офис 1)
Настройка через графический интерфейс
| Рисунок 34. Настройка на R1 маршрутизации |
| Рисунок 35. Настройка на R1 маршрутизации |
Настройка через командную строку
/ip/route add dst-address=10.22.22.0/24 gateway=172.16.1.2
Настройка маршрутизации на маршрутизаторе R2 (офис 2)
Настройка через графический интерфейс
| Рисунок 36. Настройка на R2 маршрутизации |
| Рисунок 37. Настройка на R2 маршрутизации |
Настройка через командную строку
/ip/route add dst-address=10.11.11.0/24 gateway=172.16.1.1
Проверка маршрутизации
Проверка в головном офисе и в филиале
Если маршрутизация была правильно настроена, то данные между двумя сетями должны начать передаваться. Чтобы проверить корректность настройки, можно выполнить команду ping с компьютера в одной сети до компьютера в другой сети. Но здесь возможны нюансы. Некоторые антивирусы блокируют ICMP-запросы, и поэтому ping'и могут не проходить. Более того, некоторые антивирусы, например антивирус Касперского, умеют блокировать ICMP-запросы из других сетей и при этом не блокировать такие же запросы из своей сети. Поэтому если ping'и с компьютера на компьютер не проходят, то рекомендуется проверить прохождение ICMP-запросов с компьютера в локальной сети до внутреннего интерфейса маршрутизатора в другой сети. Для этого необходимо:
- при проверке из офиса 1 запустить ping до IP-адреса 10.22.22.1;
- при проверке из офиса 2 запустить ping до IP-адреса 10.11.11.1.
Если такие ping'и проходят, то с вероятностью 100 % VPN-соединение и маршрутизация с обеих сторон настроены корректно и с вероятностью 99 % проблему нужно искать не на маршрутизаторах. При этом существует 1-процентная вероятность того, что причиной невозможности передачи данных являются какие-то другие неверные настройки.
Потенциальные проблемы при маршрутизации
Если маршрутизация между двумя маршрутизаторами MikroTik не выполняется, необходимо проверить следующее:
- Настройки маршрутизации на обоих маршрутизаторах.
- Настройки брандмауэра на компьютере, который пингуется. Для надежности можно временно отключить встроенный брандмауэр и антивирус, чтобы исключить их влияние на ICMP-запросы.
Распространенной ошибкой является использование технологии NAT для данных, маршрутизируемых между удаленными сетями. Это действительно может потребоваться, но только в некоторых частных случаях. Например, если нет возможности внести изменения в таблицу маршрутизации на одном из маршрутизаторов. Если же такая возможность есть, но при этом данные начинают маршрутизироваться только при использовании NAT, то с вероятностью 99 % имеется ошибка в настройках маршрутизации.
Причины низкой скорости
Если скорость передачи данных между офисами значительно ниже скорости самого медленного интернет-канала, то необходимо проверить следующее:
- Хватает ли ресурсов процессора.
- Нет ли проблем с MTU. Проблема чаще всего наблюдается при использовании множества вложенных туннелей. Например, если SSTP-туннель передается через PPPoE-туннель от интернет-провайдера.
Полезные ссылки
Онлайн-курсы по MikroTik
- Администрирование сетевых устройств MikroTik
- Файрвол и приоритизация трафика на MikroTik
- Маршрутизация на MikroTik
- Коммутация на MikroTik
Онлайн-курсы по сетям
- Математика и физика в сетевых технологиях
- Архитектура современных компьютерных сетей
- Устройство, проектирование и диагностика беспроводных сетей IEEE 802.11 (Wi-Fi)
Telegram-каналы
Telegram-чат
Прочее













































