Службе sstp не удалось прочитать из реестра хеш сертификата sha256
Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор - официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.
SSTP, как технологию удаленного доступа следует рассматривать в первую очередь для тех клиентов, которые могут работать из самых различных мест и должны всегда иметь возможность быстро подключиться к корпоративной сети соблюдая высокие требования безопасности. К недостаткам следует отнести повышенные накладные расходы и связанную с этим невысокую производительность, но это общий недостаток всех VPN-протоколов поверх TCP.
В случае использования оборудования Mikrotik встает вопрос высокой нагрузки на процессор для моделей без аппаратной поддержки AES. При этом вне зависимости от аппаратной поддержки шифрования скорость канала для недорогих моделей вряд-ли превысит 20-25 МБит/с , вне зависимости от доступной ширины канала. Более подробно об этом можете прочитать в нашей статье Производительность младших моделей Mikrotik hEX и hAP. Экспресс-тестирование. Поэтому мы не советуем использовать SSTP для каналов, предполагающих высокую загрузку, но можем рекомендовать как надежное и безопасное средство удаленного доступа для сотрудников, часто работающих вне стационарных рабочих мест.
Создание центра сертификации и выпуск сертификатов
Перед тем, как приступить к созданию центра сертификации убедитесь, что на роутере правильно настроено текущее время и часовой пояс, а также включена синхронизация времени через NTP.
Сначала выпустим корневой сертификат, для этого перейдем в System - Certificate и создадим новый сертификат заполнив поля как указано на рисунке, красным обозначены обязательные к заполнению.
Name - видимое имя сертификата, Common Name - имя субъекта, которому выдан сертификат, в каждом из них указываем CA (т.е. Certification authority). Вообще там можно написать все что угодно, но правила хорошего тона требуют давать сертификатам понятные имена. Key Size - размер ключа, оставляем по умолчанию 2048, Days Valid - срок действия сертификата в днях, имеет смысл указать достаточно продолжительный срок, в нашем случае 10 лет.
Перейдем на вкладку Key Usage и оставим только crl sign и key cert. sign, затем сохраним сертификат нажав Apply, и подпишем его кнопкой Sign, в открывшемся окне следует указать CA CRL Host, для которого можно использовать один из IP-адресов роутера, в нашем случае это localhost. Если же при помощи данного CA вы собираетесь выпускать сертификаты для других серверов, то следует указать доступный для них адрес, внутренний или внешний.
В терминале все это можно быстро сделать командами:
Затем выпустим сертификат сервера. При этом надо определиться каким образом вы будете подключаться к серверу по IP-адресу или FQDN (доменному имени), второй вариант более предпочтителен, так как при смене адреса вам придется перевыпустить сертификат сервера и изменить настройки всех клиентских подключений.
Заполнение полей практически ничем не отличается от предыдущего сертификата, за исключением Common Name и Subject Alt. Name, в них указываем FQDN или IP-адрес сервера, для поля Subject Alt. Name также указываем тип: DNS - для доменного имени или IP для адреса. Срок действия сертификата также имеет смысл сделать достаточно большим, в нашем случае 10 лет.
На закладке Key Usage устанавливаем digital-signature, key-encipherment и tls-server и подписываем сертификат сервера, для этого в поле CA выберите ранее выпущенный корневой сертификат.
В терминале:
При подключении через SSTP клиент прежде всего устанавливает с сервером защищенное соединения, а для этого ему нужно проверить сертификат и убедиться в его подлинности, в противном случае продолжение соединения будет невозможным. Чтобы клиентские системы доверяли нашим сертификатам нам нужно будет установить на них корневой сертификат нашего CA.
Для этого выберем корневой сертификат в System - Certificate, щелкнем на нем правой кнопкой мыши и нажмем Export, в поле Type ставим PEM, пароль не указываем, так как нам нужен только сертификат, без закрытого ключа. Закрытый ключ центра сертификации является секретным и никогда не должен покидать пределы роутера.
В терминале сертификат можно экспортировать командой:
Найти и скачать выгруженный сертификат можно в разделе Files.
Настройка SSTP VPN-сервера
Перед тем как браться за настройку сервера следует определиться со схемой доступа к сети, существуют два основных варианта: Proxy ARP, когда адреса удаленным клиентам выдаются из диапазона основной сети и они получают доступ без дополнительных настроек, и маршрутизация, когда диапазон адресов для VPN-клиентов не пересекается с основной сетью, а для доступа в нее будет необходимо указать маршруты, этот процесс можно автоматизировать с помощью PowerShell.
После этого перейдем в IP - Pool и создадим новый пул адресов для выдачи VPN-сервером, количество адресов в пуле не должно быть меньше предполагаемого количества клиентов.
В терминале:
Затем перейдем в PPP - Profiles и создадим новый профиль, в поле Local Address введем локальный адрес VPN-сервера, он должен относиться к тому же диапазону что и выделенный выше пул адресов, который следует указать в поле Remote Address, остальные настройки оставляем по умолчанию.
Или выполним команду:
Затем переместимся в PPP - Secrets и создадим учетные записи пользователей, указываем имя пользователя, пароль, в поле Service выбираем sstp, что ограничит действие учетной записи только SSTP-сервером, если оставить any, то учетка сможет подключаться к любому сервису. В поле Profile указываем созданный нами профиль.
Эти же действия в командной строке:
Теперь, когда все готово, настроим сам сервер. Для этого перейдем в PPP - Interface и нажмем кнопку SSTP Server. Включим его, установив флаг Enabled, в поле Default Profile выберем созданный нами профиль, в разделе Authentication оставим только mschap2, в поле Certificate указываем сертификат сервера. Дальнейшие настройки отвечают за повышение уровня безопасности: TLS Version - only-1.2 не разрешает использование устаревших версий TLS, Force AES - заставляет принудительно использовать алгоритм шифрования AES256, PFS включает совершенную прямую секретность (Perfect forward secrecy), которая формирует уникальный сессионный ключ для каждого подключения, что делает невозможным расшифровку сессии даже при наличии закрытого ключа.
В терминале для включения и настройки сервера выполните:
На этом настройка закончена, сервер готов принимать подключения.
Настройка подключения клиента в Windows
Как мы уже говорили, для того чтобы клиент мог проверить подлинность сервера нам необходимо импортировать корневой сертификат, переместим его на клиента и установим в Расположение хранилища - Локальный компьютер:
Хранилище сертификатов - Доверенные корневые центры сертификации:
Затем создаем подключение, в котором указываем Тип VPN - Протокол SSTP и Тип данных для входа - Имя пользователя и пароль, здесь же вводим адрес сервера и учетные данные.
После чего в свойствах подключения на закладке Безопасность убедимся, что в разделе Проверка подлинности указан только протокол MS-CHAP v2.
Настройка клиента закончена, можно подключаться.
Настройка подключения клиента в Linux
В используемых нами дистрибутивах Linux нет штатного SSTP-клиента, однако есть сторонняя разработка, которой мы и воспользуемся. Все нижесказанное будет справедливо для дистрибутивов основанных на Debian и Ubuntu, если у вас иная система обратитесь на страницу проекта.
Проще всего владельцам Ubuntu, им достаточно просто подключить PPA, ниже приведен пример для Ubuntu 18.04, для других систем просто измените кодовое название дистрибутива:
В Debian процесс немного более сложный, сначала получим и установим ключ репозитория проекта:
Затем создадим файл с указанием источников пакетов:
И внесем в него следующие строки:
Обновим список пакетов и установим клиент:
После чего появится возможность создать SSTP-соединение штатными средствами Network Manager. Настройки несложные: указываем адрес сервера, учетные данные и сертификат CA, у которого предварительно следует изменить расширение на PEM.
Если вы все сделали правильно, то соединение будет установлено.
Освоить MikroTik вы можете с помощью онлайн-курса «Настройка оборудования MikroTik». В курсе изучаются все темы из официальной программы MTCNA. Автор - официальный тренер MikroTik. Материал подходит и тем, кто уже давно работает с оборудованием MikroTik, и тем, кто еще не держал его в руках. В состав входят 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект.
Добрый день.
Проблема очень похожа, только у меня стоит на реальном железе. Роли сервера терминалов (удалённых рабочих столов) нет, но, возможно, что была (как узнать?). Стоит MS SQL Server2008.
Возможно, проблема появилась после установки/удаления OpenVPN.
Вывод ipconfig /all
*
Настройка протокола IP для Windows
Имя компьютера . . . . . . . . . : NADIN_SERVER
Основной DNS-суффикс . . . . . . :
Тип узла. . . . . . . . . . . . . : Гибридный
IP-маршрутизация включена . . . . : Нет
WINS-прокси включен . . . . . . . : Нет
Ethernet adapter Подключение по локальной сети 2:
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connection
Физический адрес. . . . . . . . . : 4C-72-B9-26-63-DD
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
IPv4-адрес. . . . . . . . . . . . : 192.168.0.2(Основной)
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз. . . . . . . . . : 192.168.0.1
DNS-серверы. . . . . . . . . . . : 77.88.8.88
77.88.8.2
NetBios через TCP/IP. . . . . . . . : Включен
Ethernet adapter Подключение по локальной сети:
Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
Туннельный адаптер Teredo Tunneling Pseudo-Interface:
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
IPv6-адрес. . . . . . . . . . . . : 2001:0:9d38:6ab8:2c1d:2979:3f57:fffd(Основной)
Локальный IPv6-адрес канала . . . : fe80::2c1d:2979:3f57:fffd%15(Основной)
Основной шлюз. . . . . . . . . : ::
NetBios через TCP/IP. . . . . . . . : Отключен
Вывод netstat -ano
Имя Локальный адрес Внешний адрес Состояние PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 712
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:1433 0.0.0.0:0 LISTENING 1284
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING 320
TCP 0.0.0.0:5555 0.0.0.0:0 LISTENING 1092
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING 428
TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING 804
TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING 856
TCP 0.0.0.0:49155 0.0.0.0:0 LISTENING 532
TCP 0.0.0.0:49158 0.0.0.0:0 LISTENING 524
TCP 0.0.0.0:49159 0.0.0.0:0 LISTENING 1412
TCP 127.0.0.1:1434 0.0.0.0:0 LISTENING 1284
TCP 127.0.0.1:37483 0.0.0.0:0 LISTENING 3020
TCP 127.0.0.1:49169 127.0.0.1:49170 ESTABLISHED 3020
TCP 127.0.0.1:49170 127.0.0.1:49169 ESTABLISHED 3020
TCP 192.168.0.2:139 0.0.0.0:0 LISTENING 4
TCP 192.168.0.2:445 192.168.0.101:58710 ESTABLISHED 4
TCP 192.168.0.2:445 192.168.0.101:58744 ESTABLISHED 4
TCP 192.168.0.2:445 192.168.0.101:59907 ESTABLISHED 4
TCP 192.168.0.2:445 192.168.0.101:60198 ESTABLISHED 4
TCP 192.168.0.2:445 192.168.0.101:60203 ESTABLISHED 4
TCP 192.168.0.2:1433 192.168.0.101:58745 ESTABLISHED 1284
TCP 192.168.0.2:1433 192.168.0.101:59909 ESTABLISHED 1284
TCP 192.168.0.2:1433 192.168.0.101:59910 ESTABLISHED 1284
TCP 192.168.0.2:49161 178.255.87.3:443 CLOSE_WAIT 532
TCP 192.168.0.2:49162 178.255.87.3:443 CLOSE_WAIT 1848
TCP 192.168.0.2:49171 74.125.205.125:5222 ESTABLISHED 3020
TCP 192.168.0.2:49260 173.194.32.166:443 CLOSE_WAIT 2748
TCP 192.168.0.2:49265 173.194.32.161:443 CLOSE_WAIT 3752
TCP 192.168.0.2:49269 178.255.87.3:443 CLOSE_WAIT 1544
TCP 192.168.0.2:49669 173.194.112.19:80 ESTABLISHED 1544
TCP 192.168.0.2:49673 173.194.112.19:443 ESTABLISHED 1544
TCP 192.168.0.2:49677 69.57.168.148:80 TIME_WAIT 0
TCP 192.168.0.2:49682 69.57.168.156:80 TIME_WAIT 0
TCP 192.168.0.2:49686 74.125.230.100:443 ESTABLISHED 1544
TCP 192.168.0.2:49688 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49689 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49692 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49693 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49695 213.186.33.2:80 TIME_WAIT 0
TCP 192.168.0.2:49696 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49697 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49698 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49699 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49700 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49701 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49702 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49703 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49704 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49705 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49706 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49707 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49708 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49709 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49710 64.233.164.117:443 TIME_WAIT 0
TCP 192.168.0.2:49711 64.233.164.117:443 ESTABLISHED 3020
TCP [::]:135 [::]:0 LISTENING 712
TCP [::]:445 [::]:0 LISTENING 4
TCP [::]:1433 [::]:0 LISTENING 1284
TCP [::]:3389 [::]:0 LISTENING 320
TCP [::]:47001 [::]:0 LISTENING 4
TCP [::]:49152 [::]:0 LISTENING 428
TCP [::]:49153 [::]:0 LISTENING 804
TCP [::]:49154 [::]:0 LISTENING 856
TCP [::]:49155 [::]:0 LISTENING 532
TCP [::]:49158 [::]:0 LISTENING 524
TCP [::]:49159 [::]:0 LISTENING 1412
TCP [::1]:1434 [::]:0 LISTENING 1284
UDP 0.0.0.0:123 *:* 912
UDP 0.0.0.0:500 *:* 856
UDP 0.0.0.0:1434 *:* 1360
UDP 0.0.0.0:4500 *:* 856
UDP 0.0.0.0:5355 *:* 1004
UDP 192.168.0.2:137 *:* 4
UDP 192.168.0.2:138 *:* 4
UDP [::]:123 *:* 912
UDP [::]:500 *:* 856
UDP [::]:1434 *:* 1360
UDP [::]:4500 *:* 856
"Серверу лицензирования служб терминалов не удается выдать клиенту клиентскую лицензию служб терминалов (TS CAL) из-за следующей ошибки: Не удалось добавить сертификат в хранилище, ошибка c0010020."
Как выяснилось причина была в деактивации лицензий (вроде как файл поврежден)
При попытке повторной активации (правой кнопкой по свойствам сервера, для выбора типа активации - прямая, через веб или по телефону) выдает ошибку:
при работе мастера активации сервера возникла внутренняя ошибка на сервере лицензирования 0xc0110011
Аналогичную ошибку выдает при попытке активации без выбора способа активации (ранее в настройках стояла прямая через интернет).
Подскажите пожалуйста как решить проблему?
Ответы
Вообщем не дождавшись детального отчета о проделанных действиях, проделал процедуру самостоятельно, т.к. сервер перестал пускать терминально. Сделал то, что описано во второй части предложенной статьи, тк. номера ошибок совпадали с моими:
- Остановил службу лицензирования и переименовал папку LServer в \Windows\System32
- Далее у роли "Служба терминалов" деинсталировал компонент "Лицензирование служб терминалов" (удалялось почти час)
- Перегрузил сервер, и у роли "Служба термиалов" добавил компонент "Лицензирование служб терминалов" (устанавливался почти час). В \Windows\System32 создалась новая папка LServer.
- Далее в "Диспетчер служб лицензирования терминалов" произвел активацию лицензий терминального доступа.
Вообщем-то и все. Спасибо за ссылку на сайт с описанием исправления ошибки Никите Панову.
Все ответы
я боюсь столкнуться с проблемой как и в недавней теме: после переустановки сервера лицензирования совсем невозможно будет установить лицензии из-за ошибки "при работе мастера активации сервера возникла внутренняя ошибка на сервере лицензирования 0xc0110011"
на данный момент как я понимаю действует льготный 120-дневный период и пользователи еще пока могут работать.
Копии к сожалению не снималось, сервер запустили примерно месяц назад.
В журнале событий наблюдаю следующие ошибки:
системы:
1. Серверу лицензирования служб терминалов не удается выдать клиенту клиентскую лицензию служб терминалов (TS CAL) из-за следующей ошибки: Не удалось добавить сертификат в хранилище, ошибка c0010020. (ну это понятно)
3. Не удается инициализировать пакет безопасности Kerberos для проверки подлинности на стороне сервера. Поле данных содержит код ошибки.
Приложений:
1. Сбойное приложение spoolsv.exe, версия 6.0.6001.18000, штамп времени 0x4791956c, сбойный модуль ntdll.dll, версия 6.0.6001.18000, штамп времени 0x4791a7a6, код исключения 0xc0000374, смещение ошибки 0x000b015d, ИД процесса 0xfd4, время запуска приложения 0x01cac0e368f5e788.
2. Операционная система обнаружила, что файл реестра используется другими приложениями или службами. Файл будет сейчас выгружен. Приложения или службы, которые используют файл реестра, могут впоследствии работать неправильно.
Условная схема пакета с данными
Условно стек протоколов при передаче данных выглядит так (показаны только заголовки, относящиеся к VPN, без подлежащих уровней):
Структура собственно SSTP пакета:
Флаг C = 0 если пакет с данными, и C = 1, если пакет управляющий.
Немного слов об используемой криптографии
SSTP устроен довольно просто за счёт того, что он использует функционал других криптографических протоколов. Собственно, единственная криптографическая функция, реализуемая самим SSTP – это «cryptographic binding», о котором говорится ниже.
Всё шифрование данных осуществляется протоколом SSL. Все пакеты протоколов SSTP, PPP и выше передаются только в зашифрованном виде.
Авторизация проходит сразу по трём протоколам: SSL, PPP и, собственно, сам SSTP.
При установлении SSL соединения проходит авторизация сервера клиентом по SSL сертификату. Аутентификация клиента сервером допускается, однако не поддерживается ни одной из серверных Windows.
На уровне PPP происходит авторизация клиента сервером, и дополнительно может происходить аутентификация сервера. Windows Server поддерживают аутентификацию клиента на уровне PPP с помощью MS-CHAPv2, EAP-TLS, PEAP-MSCHAPv2, PEAP-TLS. Также поддерживаются Password Authentication Protocol (PAP – не шифрованный пароль) и CHAP, однако их использование не рекомендуется, т. к. они не предусматривают обмена ключевой информацией, которая необходима для «cryptographic binding». Собственно, тут те же методы аутентификации, что и в PPTP. Отличие от PPTP в том, что обмен происходит внутри уже созданного шифрованного канала SSL.
Теперь о том, что же такое этот «cryptographic binding». Из-за того, что аутентификация клиента и сервера происходит на разных уровнях, возможна атака человек посередине, когда нарушитель устанавливает SSL соединение с сервером и незащищённое PPP соединение с клиентом.
Порядок установления соединения
Обрыв соединения
Что бы отличить простой канала от разрыва связи стороны «пингуют» друг друга. Если в течение 60 секунд обмена пакетами не было, посылается Echo Request (управляющий пакет протокола SSTP). Если в течение следующих 60 секунд нет ответа, соединение разрывается.
Завершение соединения
Прошло уже более года, после того как мы начали работу с VPN соединениями на базе протокола L2TP/IPsec и авторизацией через RADIUS . Накопился некоторый опыт использования описанной конфигурации, были выявлены её плюсы и минусы, сделаны определённые выводы. Опираясь на эти выводы, в данной заметке мы продолжим развитие темы настройки безопасных VPN соединений и рассмотрим шаги, необходимые для организации возможности работы по протоколу SSTP (Secure Socket Tunneling Protocol).
Опыт использования L2TP/IPsec VPN показал, что при наличии внятной пошаговой инструкции по подключению, большинство пользователей способны без особых проблем настроить такое VPN-подключение самостоятельно. Но всё-таки всегда остаются индивидуумы, которые умудряются наделать ошибок даже в таких условиях, и поэтому мысль о необходимости упрощения процесса создания VPN-подключения всегда мелькала где-то на заднем фоне. К тому же в ряде ситуаций мы столкнулись с проблемой блокировки некоторых портов, необходимых для L2TP/IPsec VPN, обнаруженной на уровне интернет-провайдеров. Причём иногда дело доходило до абсурда, когда у одного и того-же интернет-провайдера трафик L2TP/IPsec в одном конце города транслировался беспрепятственно, а в другом конце города блокировался. Мы уже даже мысленно поделили для себя зоны разных интернет-провайдеров на сегменты, где L2TP/IPsec VPN будет работать без нареканий, и на зоны, где точно будут проблемы и нам потребуется подумать об альтернативных вариантах доступа к ресурсам локальной корпоративной сети. Помимо этого, были и случаи, когда командированные пользователи и "отпускники", удалённо пытающиеся подключиться через "гостиничный интернет", испытывали проблемы в силу всё тех же проблем с блокировкой нужных портов. Разумеется перед внедрением L2TP/IPsec VPN мы понимали все эти риски и в подавляющем большинстве проблемных ситуаций находилось какое-то обходное решение, но "осадочек" от каждой такой ситуации оставался неприятный.
Я начал вспоминать, почему же ранее мой выбор пал именно на L2TP/IPsec. Определяющих факторов было два – приемлемый уровень безопасности и поддержка более широкого круга клиентских ОС. Помню, что в то время меня заинтересовал протокол SSTP, но было пару факторов, которые заставили меня отстраниться от данной технологии. Во первых, на то время у нас было ещё достаточное количество клиентов на базе Microsoft Windows XP, а в этой ОС протокол SSTP, как известно, не поддерживается. Во вторых, у меня не было возможности использовать публичный сертификат с корпоративными доменными именами для защиты SSTP соединений, а заменять его на сертификат внутреннего выделенного ЦС не было желания, так как это влекло за собой проблемы связанные с распространением его корневого сертификата на интернет-клиентов и публикации списка отзыва сертификатов (Certificate Revocation List – CRL) в Интернет.
Но прошло время, клиентов с Windows XP стало на порядок меньше (усиление корпоративной политики ИБ и агрессивные рекламные компании Microsoft по обновлению ОС сделали своё дело), а у меня появилась возможность работы с публичным сертификатом. К тому же на глаза мне попалась информация о том, что на таких OC, как Linux и Apple Mac OS X, клиентское ПО для поддержки SSTP подключений уже давно вполне успешно эксплуатируется, несмотря на то, что в своё время этому протоколу пророчили "Win-изоляцию" в силу его проприетарности.
Основные требования к клиентам и их настройка
Если речь вести о клиентских системах на базе ОС Microsoft Windows, то нужно учесть, что SSTP работает на системах начиная с Windows Vista SP1 и более поздних. Для клиентских систем ниже Windows Vista SP1, в том числе и для ещё "живых мамонтов" в виде Windows XP, как и ранее, предполагается использование протокола L2TP/IPsec со всеми вытекающими обстоятельствами, о которых я говорил выше. От использования протокола PPTP, как уже давно скомпрометированного, предлагается отказаться вовсе. Ссылки на обновлённые инструкции по настройке SSTP соединения на клиентских ОС Windows можно найти в конце этой статьи.
Для клиентских систем на базе ОС Linux вполне жизнеспособным себя показывает проект с открытым исходным кодом SSTP-Client. Мной уже подготовлены пошаговые инструкции для не особо искушённых пользователей Linux-систем на примере настройки в Ubuntu Linux 14.04 и 15.04/15.10 .
По поводу клиентских систем на базе ОС Apple Mac OS внятного пока ничего сказать не могу, так как под руками их у меня попросту нет. По имеющейся поверхностной информации можно использовать SSTP-Client (в качестве консольного варианта), а можно использовать созданный на его основе пакет iSSTP с управлением через графический интерфейс. Надеюсь, что в ближайшее время Виталий Якоб нас порадует соответствующей инструкцией пользователя.
Общее для все клиентов требование - клиент SSTP VPN должен иметь возможность проверять списки отзыва сертификатов (CRL) для подтверждения того, что сертификат предоставляемый VPN-сервером не был отозван. Такого рода проверка может быть отключена на стороне клиента, но это не самое лучшее решение с точки зрения безопасности, и его имеет смысл использовать лишь в крайних случаях.
Основные требования к VPN-серверу и его настройка
Серверную часть VPN-соединения в нашем случае будет представлять собой расширение к созданной ранее конфигурации VPN-сервера на базе Windows Server 2012 R2 с ролью Remote Access.
Из основных требований к VPN-серверу, как уже наверно понятно из всего вышесказанного, является наличие на нём установленного сертификата. Получить такой сертификат можно из публичных ЦС и, как правило, такие сертификаты стоят немалых денег. Но есть и бесплатные варианты, например WoSign Free SSL Certificates . Сам я пока опыта общения с таким ЦС не имел, и поэтому будет интересно выслушать Ваши комментарии по этому поводу.
Требования к сертификату VPN-сервера
Важным для SSTP является то, что при генерации запроса на получение сертификата от стороннего публичного ЦС нужно помнить про то, что в запрашиваемом сертификате должна присутствовать политика применения (Extended Key Usage, EKU) - Server Authentication (1.3.6.1.5.5.7.3.1). Само собой для такого сертификата должен быть разрешён экспорт закрытого ключа, так как возможно нам потребуется установка сертификата на несколько VPN-серверов в случае, если, например, используется кластерная конфигурация.
Обязательным требованием к получаемому сертификату является также то, что список отзыва сертификатов (CRL) указанный в сертификате обязательно должен быть доступен в Интернете, так как в самом начале создания SSTP соединения клиентский компьютер будет пытаться проверить не является ли предоставленный VPN-сервером сертификат отозванным. Не будет доступного CRL – не будет SSTP соединения.
Полученный сертификат устанавливается на VPN-сервере в хранилище сертификатов Local Computer\Personal и должен иметь привязку к закрытому ключу этого сертификата.
Также разумеется, что ЦС выдавшему сертификат должны доверять не только наши VPN-серверы, но и все наши внешние Интернет-клиенты, которые будут подключаться к этим серверам по протоколу SSTP. То есть корневой сертификат (их может быть и несколько) должен присутствовать на всех компьютерах в хранилище сертификатов Local Computer\Trusted Root Certification Authorities. Информацию об этих требованиях можно найти в статье TechNet Library - Configure RRAS with a Computer Authentication Certificate . В большинстве современных клиентских ОС коллекция публичных корневых сертификатов обновляется автоматически при наличии постоянного подключения к Интернет.
Настройка роли Remote Access
После того, как на VPN-сервере установлен сертификат, откроем оснастку Routing and Remote Access и в свойствах сервера VPN на вкладке Security выберем этот сертификат для SSTP в разделе SSL Certificate Binding
Изменение этой опции выведет предложение об автоматическом перезапуске служб RRAS. Соглашаемся с перезапуском служб.
Далее в разделе Ports добавим порты SSTP. В нашем примере под SSTP соединения отдаётся большая часть портов и небольшая часть портов выделяется для клиентов без поддержки SSTP, например Windows XP. Возможность же подключения по протоколу PPTP отключаем совсем.
Информацию о том, как правильно отключить возможность подключения по протоколу PPTP, можно найти в статье Routing How To. Add PPTP or L2TP ports . Пример на скриншоте:
После сделанных изменений проверим TCP прослушиватели (TCP Listener) работающие на нашем VPN-сервере. Среди них должен появиться прослушиватель для 443 порта, на который VPN-сервером будут приниматься клиентские подключения по протоколу SSTP:
Не забываем настроить брандмауэр, включив уже имеющееся после установки и настройки роли Remote Access правило Secure Socket Tunneling Protocol (SSTP-In)
Поимо этого можно отключить разрешающее правило для входящих PPTP-подключений на порт TCP 1723 (в конфигурации по умолчанию это правило называется "Routing and Remote Access (PPTP-In)")
Так как наш VPN-сервер является членом NLB-кластера, нам потребуется дополнительно создать правило разрешающее балансировку порта TCP 443.
Сделанных настроек вполне достаточно для того чтоб наш VPN-сервер смог успешно принимать SSTP подключения.
Проверяем подключение VPN-клиента
На клиентской машине имеющей прямой доступ в интернет по 443 порту настраиваем проверочное VPN-соединение и выполняем подключение…
На стороне сервера при этом убеждаемся в том, что клиент использует один из свободных созданных нами ранее SSTP портов…
Инструкции для пользователей
Как уже отмечалось ранее, для пользователей выполняющих подключение к корпоративным VPN-серверам из Интернет необходимо разработать чёткие пошаговые инструкции. Мне удалось протестировать (и параллельно разработать пошаговые инструкции для пользователей) VPN-подключения в составе следующих операционных систем:
- Windows XP 32-bit RU SP3
(Инструкция переписана с учётом использования L2TP/IPsec, но при отсутствии работающего PPTP. Запрос и установка сертификата делаются в два этапа разными скриптами) - Windows VistaBusiness 32-bit RU SP2 (SSTP)
- Windows 7Pro 32-bit RU SP1 (SSTP)
- Windows 8.1 Pro 64-bit RU (SSTP)
- Ubuntu Desktop Linux14.04 64-bit (SSTP)
- Ubuntu Desktop Linux15.04 64-bit (SSTP)
- Ubuntu Desktop Linux14.10 64-bit (SSTP)
Инструкции в формате DOCX (а также нужными исполняемыми файлами), которые, при желании, вы можете адаптировать под своё окружение можно скачать по ссылке . Часть инструкций доступна для онлайн просмотра и обсуждения на нашем Вики .
Читайте также: