Windows Server 2012 R2 Remote Access - Настраиваем VPN сервер с двухфакторной аутентификацией на базе L2TP/IPsec и авторизацией через RADIUS

imageВ этой заметке будет рассмотрен пример настройки VPN-сервиса на базе Windows Server 2012 R2 с ролью Remote Access. Для повышения доступности VPN-сервиса в рассматриваемой далее конфигурации будет использоваться два виртуальных сервера (на базе Hyper-V) объединённых в NLB-кластер. Для повышения гибкости правил предоставления доступа к разным ресурсам локальной сети для VPN-клиентов на стороне VPN-серверов будет выполнена привязка схемы аутентификации к расположенным в локальной сети RADIUS серверам (на базе Network Policy Server). Для повышения безопасности VPN-соединений в качестве основного протокола будет использоваться L2TP/Ipsec с использованием цифровых сертификатов. Двухфакторная аутентификация будет основана на проверке сертификата и доменной учетной записи пользователя

Среда исполнения

В рассматриваемом примере будет создан Windows NLB кластер из двух виртуальных серверов одинаковой конфигурации на базе Hyper-V из Windows Server 2012 R2 Datacenter EN. На виртуальных серверах устанавливается Windows Server 2012 R2 Standard EN.

Каждый из виртуальных серверов будет иметь по два сетевых интерфейса, настройка которых будет рассмотрена далее.

Серверам присвоены имена – KOM-AD01-VPN01 и KOM-AD01-VPN02.

Создаваемый в процессе описания NLB-кластер будет использовать имя KOM-AD01-VPNCL.

В качестве поставщика аутентификации будут использоваться два отдельных сервера внутри локальной сети с заранее установленной и настроенной ролью Network Policy and Access Services (RADIUS) с именами KOM-AD01-NPS01 и KOM-AD01-NPS02.

Аутентификация для протокола L2TP/IPsec с использованием сертификатов потребует наличия Доменного или Автономного Центра сертификации (ЦС) для создания цифровых сертификатов для VPN-клиентов. В рассматриваемой конфигурации а качестве Автономного ЦС будет использоваться отдельный сервер внутри локальной сети с именем KOM-AD01-CA01  

Упрощённая схема взаимодействия компонент конфигурации будет выглядеть следующим образом:

image

Данная конфигурация построена по принципу избыточности основных функциональных компонент. Если потребности в наличии такой избыточности нет, то описанную ниже конфигурацию вполне можно реализовать в рамках одного виртуального сервера, совместив соответствующие серверные роли на нём.

Так как планируемая конфигурация получается многокомпонентной, то во избежание лишних сложностей, мы не будем пытаться настроить весь функционал сразу. Вместо этого мы сначала настроим базовый функционал PPTP VPN и протестируем его. Если на этом этапе проблем выявлено не будет, следующим этапом приступим к связке сервера VPN c RADIUS, и снова проверим результат. В случае успешной проверки авторизации через RADIUS перейдём к настройке VPN-сервера и VPN-клиентов для поддержки протокола L2TP/IPsec. Снова проверим результат, и в случае успеха перейдём к окончательному этапу – созданию второго VPN-сервера аналогичной конфигурации и построению NLB-кластера из двух VPN-серверов. Таким образом, план развёртывания конфигурации будет следующим:

1. Настройка первого VPN-сервера (KOM-AD01-VPN01)
1.1. Настройка виртуальной машины
1.2. Установка роли Remote Access
1.3. Настройка службы Routing and Remote Access
1.4. Настройка правил Windows Firewall
2. Проверка подключения по протоколу PPTP
3. Создание доменных групп доступа
4. Работа с серверами NPS/RADIUS
4.1. Создание основной сетевой политики на сервере NPS
4.2. Создание дополнительной сетевой политики NPS для PPTP-подключений
4.3. Добавление информации о VPN-сервере на сервер RADIUS
5. Привязка VPN-сервера к серверам RADIUS
6. Проверка подключения по протоколу PPTP с использованием RADIUS
7. Работа с сертификатами
7.1. Установка корневого сертификата ЦС на VPN-сервере и клиенте.
7.2. Создание сертификата VPN-сервера
7.3. Создание сертификата VPN-клиента
8. Проверка подключения VPN-клиента из Интернет по протоколу L2TP/IPSec
9. Настройка второго VPN-сервера (KOM-AD01-VPN02)
10. Создание NLB-кластера из двух VPN-серверов
11. Проверка работы NLB-кластера
12. Разработка инструкций для пользователей.

 

1. Настройка первого VPN-сервера (KOM-AD01-VPN01)
1.1 Настройка виртуальной машины

Устанавливаем на виртуальный сервер ОС Windows Server 2012 R2 Standard EN и все последние обновления Windows Update.

Виртуальный сервер имеет два сетевых контроллера. В ОС условно назовём относящиеся к этим контроллерам сетевые интерфейсы - LAN и WAN. Интерфейс LAN будет смотреть в локальную сеть (либо в DMZ) и настроен следующим образом:image

Шлюз по умолчанию на интерфейсе LAN не указываем.

Интерфейс WAN будет направлен в Интернет. В свойствах интерфейса желательно выключить все компоненты кроме TCP/IPv4. Шлюз по умолчанию задан. 

image

Чтобы при такой конфигурации сетевых интерфейсов сервер был доступен из локальной сети, создадим в системе постоянный маршрут в локальную сеть через интерфейс LAN:

route -p ADD 10.0.0.0 MASK 255.0.0.0 10.160.20.1
route PRINT

 

1.2. Установка роли Remote Access

Открываем оснастку Server Manager, выбираем область настроек Local Server, в верхнем меню выбираем Manage > Add Roles and Features. В мастере добавления ролей выбираем тип установки на основе ролей - Role-based or feature-based installation

image

Далее выбираем сервер из пула серверов…

image

На шаге выбора ролей включаем роль Remote Access

image

Шаг Features пропускаем без внесения изменений.
На шаге выбора служб включаемой роли выберем службу DirectAccess and VPN (RAS)

image

При этом откроется окно добавления дополнительных компонент связанных с выбранной службой. Согласимся с их установкой нажав Add Features

image

Роль Web Server Role (IIS) будет при этом добавлена в мастер добавления ролей. Соответствующий появившийся шаг мастера  Web Server Role (IIS) и зависимые опции Role Services пропускаем с предложенными по умолчанию настройками и запускаем процесс установки, по окончании которого будет доступна ссылка на мастер первоначальной настройки служб Remote Access – Open the Getting Started Wizard

image

Можно вызвать мастер настройки RAS щёлкнув по соответствующей ссылке здесь, либо позже из оснастки Server Manager:

image

Так как настройка DirectAccess в контексте нашей задачи не нужна, в окне мастера выбираем вариант конфигурирования только VPN – Deploy VPN only

image

 

1.3. Настройка службы Routing and Remote Access

Из Панели управления открываем оснастку Administrative Tools \ Routing and Remote Access, выбираем в дереве навигации имя сервера и открываем контекстное меню. Выбираем пункт Configure and Enable Routing and Remote Access

image

Откроется окно мастера Routing and Remote Access Server Setup Wizard, в котором мы выбираем пункт Custom configuration 

image

На следующем экране мастера включаем службу VPN access.

image

На следующем экране нажимаем кнопку Finish и соглашаемся с предложением запуска службы – нажимаем кнопку Start service

image

После этого в консоли Routing and Remote Access снова выбираем наш сервер и, открыв контекстное меню, выбираем пункт Properties

image

В открывшемся окне свойств на закладке General убеждаемся в том, что включена маршрутизация IPv4 RouterLAN and demand-dial routing, а также активен функционал сервера удалённого доступа – IPv4 Remote access server  

image

Переключимся на закладку Security и посмотрим настройки аутентификации по умолчанию. Не будем их пока менять (вернёмся к ним позже). Использование провайдера аутентификации Windows Authentication в доменной среде подразумевает то, что к серверу удалённого доступа смогут подключиться любые доменные пользователи, у которых в свойствах учетной записи включено право удалённого доступа (проверить это можно в оснастке Active Directory - Users and Computers для учетной записи доменного пользователя на закладке Dial-In параметр Network Access Permission должен быть определён как Allow access)

image

Далее переключимся на закладку IPv4 и включим опцию пересылки трафика – Enable IPv4 Forwarding, чтобы наш VPN-сервер смог пересылать трафик VPN-клиентов в локальную сеть и обратно.

В свойстве назначения IP адресов подключающимся VPN-клиентам выберем использование статического пула - Static address pool (это рекомендуемая конфигурация в случае если мы планируем использовать несколько VPN-серверов в кластере NLB). Выделим для VPN-клиентов отдельную подсеть класса “C”, например 10.160.50.0/24. Так как мы планируем использовать два VPN-сервера, разделим эту подсеть на две непересекающихся части. Первую половину сети пропишем на этом VPN-сервере, вторую в дальнейшем на втором VPN-сервере.

Отключим опцию Enable broadcast name resolution, чтобы отбросить широковещательные запросы VPN-клиентов. В нижнем параметре Adapter (сетевой интерфейс, с которого клиентам будут выдаваться настройки DNS) выберем интерфейс LAN.

image

При этом также не стоит забывать и о том, что для успешной маршрутизации трафика из указанного диапазона сети VPN-клиентов в локальную сеть и обратно, на маршрутизирующем сетевом оборудовании в локальной сети необходимо создать статический маршрут, типа:

Весть трафик предназначенный для сети 10.160.50.0/25 отправлять на хост 10.160.20.11

Как уже сказано, если VPN-серверов планируется несколько, то назначаемые статические сегменты для VPN-клиентов не должны пересекаться друг с другом на разных VPN-серверах. И для каждого из выделенных диапазонов IP адресов на маршрутизирующем оборудовании локальной сети нужно будет аналогичным образом создать соответствующие маршруты.

Сохраним сделанные настройки. При сохранении получим предупреждение о том, что для вступления новых настроек в силу, потребуется выполнить перезапуск служб маршрутизации и удаленного доступа…

image

Вернёмся в консоль, выберем узел Ports и в контекстном меню выберем Properties. Здесь мы сможем выполнить настройку допустимого количества портов, на которые смогут подключаться VPN-клиенты для каждого отдельно взятого протокола.

image

Как видим, в конфигурации по умолчанию создано множество портов для разных VPN-протоколов. В нашем примере будет использоваться только 2 протокола – PPTP и L2TP. Основным протоколом для VPN-соединений будет L2TP с количеством портов не более, чем количество ранее выделенных в статическом пуле IP адресов. Вспомогательным протоколом будет PPTP с ограниченным количеством портов, например от 1 до 3. Протокол PPTP будет использоваться исключительно для разовых кратковременных соединений, необходимых VPN-клиентам для подключения к серверу Центра сертификации и получения сертификата компьютера, необходимого для дальнейшей настройки L2TP/Ipsec подключения. Для начала настроим протокол PPTP, выбрав его из списка и нажав кнопку Configure    image

В открывшемся окне в параметре Maximum ports введём ограниченное количество портов.

image

По аналогии настроим порты для протокола L2TP указав максимально возможное количество  клиентских подключений, например 125, исходя из того, что на данный сервер ранее нами выделена половина сети класса “C”. Для всех других протоколов, которые мы не планируем настраивать и использовать, например SSTP или IKEv2, лучше вообще обнулить значение количества портов.

image

В конечном итоге мы получим примерно такую настройку портов:

image

Сохраняем настройки и убеждаемся в том, что в консоли в разделе Ports информация обновилась, и теперь там отображается именно то количество портов, которое мы назначили.

 

1.4. Настройка правил Windows Firewall

Так как в нашем случае сервер имеет прямое подключение к сети Интернет, очень важно выполнить максимально строгую настройку правил Windows Firewall. Выключаем бОльшую массу правил включённых по умолчанию. Оставляем включёнными лишь правила относящиеся к службам RAS по портам, которые будут нами использоваться. Правила удалённого доступа к серверу по таким протоколам как WinRM и RDP ограничиваем профилем Domain и диапазоном локальной сети, из которого разрешается удалённый доступ к серверу.

image

Описание правил фаервола необходимых для работы того или иного VPN-трафика можно найти в документе Configure a Firewall for VPN Traffic, а также в блоге  Routing and Remote Access Blog -  Which ports to unblock for VPN traffic to pass-through?. Согласно этим документам, к представленным по умолчанию в системе правилам, которые появляются после установки роли Remote Access, нам нужно ещё дополнительно открыть порты UDP 500 и 4500. Добавим два разрешающих правила для фаервола с помощью PowerShell:

New-NetFirewallRule -DisplayName "Routing and Remote Access (Allows IKE traffic to the VPN server)" -Direction "Inbound" -Protocol "UDP" -Action "Allow" -LocalPort "500"

New-NetFirewallRule -DisplayName "Routing and Remote Access (Allows IPsec NAT-T traffic from the VPN client to the VPN server.)" -Direction "Inbound" -Protocol "UDP" -Action "Allow" -LocalPort "4500"

 

2. Проверка подключения VPN-клиента по протоколу PPTP

На данном этапе первоначальная настройка первого VPN-сервера выполнена и он уже готов принимать клиентские подключения. Поэтому теперь можно проверить подключение по протоколу PPTP. Согласно описанной нами конфигурации, сделать это можно в том числе и с клиентского компьютера внутри локальной сети. Пошаговое описание процесса создания VPN-подключения на клиенте под управлением Windows можно найти в п.12 данной статьи. После того как на клиентском компьютере VPN-подключение создано, откроем его свойства и на закладке “Безопасность” выберем тип VPN – PPTP 

image

На закладке “Сеть” выберем протокол TCP/IPv4 и откроем его “Свойства

image

В окне свойств нажмём кнопку “Дополнительно” и отключим опцию “Использовать основной шлюз в удалённой сети”. Это нужно сделать для того, чтобы при подключении с клиента локальной сети у нас не возникло проблем с уже работающими сетевыми приложениями на клиентском компьютере во время проведения теста подключения.

image

Сохраним изменения и попробуем выполнить подключение к VPN-серверу.

Если проверка подключения из локальной сети прошла успешно, можно протестировать подключение с внешнего VPN-клиента из Интернет также по протоколу PPTP. Таким образом мы убедимся в том, что правила Windows Firewall на VPN-сервере настроены правильно и служба RAS успешно выполняет подключение VPN-клиентов, выдаёт им при этом правильные настройки IP, и корректно маршрутизирует трафик от VPN-клиента в локальную сеть и обратно. Если все указанные проверки прошли успешно, можно продолжить работу по плану и перейти к настройке интеграции VPN-сервера с сервером RADIUS.

 

3. Создание доменных групп доступа

Для дальнейшей настройки аутентификации VPN-клиентов через RADIUS нам потребуется создать в домене Active Directory (AD) группу безопасности, в которую будут включены учетные записи пользователей, которым мы хотим предоставить доступ к VPN. В нашем примере это будет доменная локальная группа безопасности KOM-AD01-SRV-NPS-VPN-Users 

image

В дальнейшем, для предоставления какому-либо пользователю домена доступа к VPN, его учетную запись будет достаточно включить в эту группу безопасности. При этом мы настроим сервер RADIUS таким образом, что пользователь сможет подключаться к VPN вне зависимости от того, каким образом выставлены ранее упомянутые настройки в свойствах его учетной записи в AD на закладке Dial-In.

 

4. Работа с серверами NPS/RADIUS

Как уже отмечалось в самом начале, мы будем использовать возможности служб Network Policy Server (NPS) для того, чтобы более гибко управлять параметрами подключения VPN-клиентов. Для этой цели на каждом RADIUS-сервере мы создадим по две сетевые политики (Network Policy). Первая политика будет использоваться как основная для всех клиентов. Вторая политика будет применяться к клиентам в том случае, если они используют подключение по протоколу PPTP и будет иметь ряд настроек, которые будут жёстко ограничивать VPN-сессии такого рода. Далее мы рассмотрим соответствующую настройку RADUS сервера на примере сервера KOM-AD01-NPS01. На втором сервере KOM-AD01-NPS02 вся настройка должна быть выполнена абсолютно также как и на первом.

4.1. Создание основной сетевой политики на сервере NPS

На сервере KOM-AD01-NPS01 открываем оснастку Administrative Tools \ Network Policy Server. В дереве навигации оснастки выбираем пункты NPSPolicies > Network Policies. Открываем контекстное меню (либо меню действий Action в главном меню) и выбираем пункт New.

image
Откроется мастер создания новой сетевой политики New Network Policy

Вводим имя политики, например KOM-AD01-SRV-NPS-VPN-Users Policy, и выбираем тип соединения Type of network access server - Remote Access Server (VPN-Dial up)

image

 

На следующем шаге мастера Specify Conditions нажимаем Add, чтобы добавить новое условие для применения политики. В открывшемся окне выбора условий найдём User Groups и нажмём Add.

image

Затем нажмём Add Groups и введём имя доменной группы безопасности, которую мы создали ранее в п.3 (KOM\KOM-AD01-SRV-NPS-VPN-Users). image

Перейдём к следующему шагу мастера Specify Access Permission где определим, что данная политика является разрешающей доступ, выбрав пункт Access grantedimage

Параметр Access is determined by User Dial-in properties (which override NPS policy) оставим без изменений, так как работает он в этом мастере как-то не совсем вменяемо. Заметил это не только я один, но есть тому и другие свидетельства, например NPS new Network Policy wizard incorrectly sets "Ignore User Dial-In Properties". После создания политики мы вернёмся в её свойства и выполним дополнительную соответствующую настройку.

На следующем шаге Configure Authentication Methods обозначим методы аутентификации доступные для подключающихся VPN-клиентов, подпадающих под правила обозначенные ранее (в нашем случае это пока только членство в доменной группе безопасности).

Убедимся в том, что включён метод MS-CHAP-v2 и отключим прочие устаревшие и менее безопасные методы аутентификации, такие как MS-CHAP

image

На следующем шаге мастера Configure Constraints при необходимости можно настроить ограничения для подключений, такие как например ограничение простоя сессии или общий таймаут сессии. В данном случае эти ограничения нам не нужны и поэтому настройки на этом шаге мы оставляем без изменений.

image

На следующем шаге мастера Configure Settings в разделе настроек Encryption оставим включенным шифрование MPPE 128-bit и MPPE 56-bit (при необходимости). В большинстве случаев рекомендуется оставлять включённым только шифрование максимально возможной силы (MPPE 128-bit), но если будут проблемы с подключением каких-то устаревших клиентов, то возможно потребуется включить и менее слабые методы шифрования. Например, если планируется подключение клиентов на базе Windows XP, то при использовании протокола L2TP/Ipsec возможно потребуется включение поддержки 56-битного шифрования. Практические эксперименты с VPN-клиентом на базе Windows XP, настроенным в конфигурации по умолчанию подтвердили это.

image
На финальном шаге Completing New Network Policy ещё раз проверим все настройки, которые будут включены в создаваемую политику, и нажмём Finish

image

Открываем свойства только что созданной политики и на первой закладке Overview включим опцию Ignore user account dial-in properties

image

Таким образом, возможность удалённого подключения будет регулироваться условиями данной политики NPS, даже несмотря на то, как настроены параметры удалённого входа в свойствах учётной записи пользователя в AD на закладке Dial-in

image

То есть, в данном примере, пользователь Петя Резинкин сможет подключиться в VPN, даже не смотря на то, что в свойствах его доменной учетной записи выбрана опция Deny access, при условии, что эта учетная запись включена в ранее указанную в политике доменную группу безопасности KOM\KOM-AD01-SRV-NPS-VPN-Users.

***

Если у нас более одного сервера RADIUS, дублируем созданную политику с идентичными настройками на дополнительных серверах.

 

4.2. Создание дополнительной сетевой политики NPS для PPTP-подключений

Созданная ранее сетевая политика будет использоваться как основная политика “по умолчанию” для всех подключающихся VPN клиентов. Как уже было сказано ранее, наша конфигурация подразумевает то, что VPN-клиенты в качестве основного протокола будут использовать L2TP/Ipsec, а для его первоначальной настройки каждому клиенту хотя бы один раз потребуется кратковременная PPTP-сессия. PPTP-сессия в нашем случае нужна для того, чтобы подключиться клиенту к одному единственному ресурсу локальной сети – Центру сертификации для получения сертификата для клиентского компьютера. Так как протокол PPTP является более устаревшим и менее защищённым чем L2TP/Ipsec, нам нужно на сервере NPS (RADIUS) создать ещё одну сетевую политику, с помощью которой будут заданы жёсткие ограничения для PPTP соединений. То есть, в рамках нашей задачи, любая PPTP-сессия будет разрешать трафик исключительно до нескольких хостов локальной сети (Сервер ЦС и DNS-серверы) и будет при этом ограничена по времени, которого достаточно для того, чтобы сформировать запрос на получение сертификата в ЦС и получение автоматически выданного цифрового сертификата клиентского компьютера.

Итак, создадим дополнительную сетевую политику и присвоим ей имя, например KOM-AD01-SRV-NPS-VPN-Users Policy (PPTP). При создании политики в качестве дополнительного условия на шаге мастера Specify Conditions добавим условие по типу туннеля Tunnel Type равное значению Point-to-Point Tunneling Protocol (PPTP).

image

На шаге мастера Configure Constraints в разделе Session Timeout включим признак разрыва сессии по истечении определённого времени - Disconnect after the following maximum time. Укажем значение, например, в 30 минут. Этого времени более чем достаточно для получения сертификата из ЦС.image

Далее, на следующем шаге мастера Configure Settings в разделе настроек IP Filters нажмём кнопку Input Filters, чтобы настроить фильтрацию трафика поступающего от VPN-клиента в сторону локальной сети

image

В открывшемся окне создадим правила, согласно которых мы разрешаем доступ VPN-клиента по всем портам к серверу ЦС (для запроса и получения сертификата), а также трафик по протоколу UDP и порту 53 к DNS-серверам локальной сети (для работы механизма разрешения имён хостов локальной сети).

image

После того, как политика создана, настроим приоритет обработки политик таким образом, чтобы только что созданная политика для PPTP соединений (KOM-AD01-SRV-NPS-VPN-Users Policy (PPTP)) имела более высокий приоритет, то есть обрабатывалась бы RADIUS-сервером раньше, чем основная политика для VPN-клиентов по умолчанию (KOM-AD01-SRV-NPS-VPN-Users Policy).

image

Таким образом, если любой VPN-клиент подключится по протоколу PPTP, то его сессия будет иметь выше-обозначенные ограничения и будет пригодна только для процедуры получения цифрового сертификата, необходимого для последующих полноценных L2TP/Ipsec подключений.

 

4.3. Добавление информации о VPN-сервере на сервер RADIUS

Политики сетевого доступа для VPN-клиентов на сервере NPS созданы, но для того, чтобы VPN-серверы могли обращаться к серверам RADIUS как поставщику аутентификации и обрабатываться созданными политиками, нам необходимо прописать эти VPN-серверы в качестве клиентов RADUIS. Для этого в консоли Network Policy Server в дереве навигации откроем узел NPSRADIUS Clients and Servers > RADIUS Clients. В меню действий выберем New.

image

В окне добавления нового клиента RADIUS на закладке Settings укажем полное доменное имя нашего VPN-сервера (тут же проверим, что оно успешно разрешается в IP с помощью кнопки Verify) и в ручную укажем пароль Shared secret для установления безопасного соединения между клиентом и сервером RADIUS. Запомним этот пароль, так как он понадобиться нам на следующем этапе настройки VPN-сервера.

image

На закладке Advanced оставим настройки предложенные по умолчанию.

image

 

Аналогичный образом создадим на RADIUS сервере запись о втором VPN-сервере…

image

Если у нас более одного сервера RADIUS, дублируем информацию о клиентах RADIUS (VPN-серверах) с идентичными настройками на дополнительных серверах.

 

5. Привязка VPN-сервера к серверам RADIUS

Теперь нам нужно выполнить настройку наших VPN-серверов для использования RADIUS аутентификации выполнив привязку к ранее настроенным RADIUS-серверам. Возвращаемся на VPN-сервер в консоль Routing and Remote Access, снова выбираем наш сервер и, открыв контекстное меню, выбираем пункт Properties. На закладке Security меняем поставщиков Authentication provider и Accounting provider на RADIUS Authentication и RADIUS Accounting соответственно. Чтобы задать параметры соединения с серверами RADIUS нажимаем кнопку Configure

image

Добавляем информацию о серверах RADIUS. Как минимум, указываем для каждого из них имя Server name и Shared secret заданным нами ранее в п.4.3

image

Закрываем все окна сохранив изменения.

 

6. Проверка подключения по протоколу PPTP с использованием RADIUS

На данном этапе можно проверить подключение VPN-клиента по протоколу PPTP, но теперь уже с  использованием аутентификации и авторизации на сервере RADIUS. Информацию о событиях подключения VPN-клиентов теперь можно будет увидеть в event-log серверов RADIUS. Если подключение и аутентификация VPN-клиента проходит успешно, переходим к следующему этапу.

 

7. Работа с сертификатами

Следующим этапом настройки мы приступим к подготовке нашего VPN-сервера и VPN-клиентов к использованию протокола L2TP/IPSec. Создадим цифровые сертификаты, которые будут использоваться для установления безопасного шифрованного соединения между клиентом и сервером. Как на VPN-сервер, так и на VPN-клиента нам нужно будет установить сертификат компьютера, выпущенный одним и тем же доверенным Центром сертификации. В нашем случае будет использоваться автономный (Standalone) Центр сертификации.

 

7.1. Установка корневого сертификата ЦС на VPN-сервере и VPN-клиенте

Если это ещё не сделано ранее, например для доменных компьютеров с помощью групповой политики, то сделаем это сейчас. Все описываемые в дальнейшем манипуляции с сертификатами можно выполнять как через инструменты графической оболочки, так и с помощью утилит командной строки. Для упрощения и ускорения основные примеры будем выполнять с использованием утилит командной строки, дополнительно учитывая то обстоятельство, что это будет нам полезно в последующем для разных процедур автоматизации. 

Скачиваем файл корневого сертификата ЦС во временный каталог на текущий компьютер (VPN-клиент или VPN-сервер):

certutil -f -config "kom-ad01-ca01.holding.com\KOMI Root CA" -ca.cert "C:\Temp\CertificateRootCA.cer"

В ответ мы должны получить содержимое сертификата примерно в следующем виде:

Сертификат ЦС[1]: 3 -- Действителен
Сертификат ЦС[1]:
-----BEGIN CERTIFICATE-----
MIIERzCCAy+gAwIBAgQEy0HgbIqB4Z5XG5qXCjlcDANBgkqhkiG9w0BAQUFADBh
...
jxwM6bUY8kB3SvzBxQX1FZiPb+n219qJwq3gWeu6MysXrfShENeqFpgfyCaSpFy
UdGgqkXUdNZ1R/rc3g8KowOYfWFn8928QuQo2Up7KneEIsZZne6k5Mqjg==
-----END CERTIFICATE-----

CertUtil: -ca.cert — команда успешно выполнена.

Устанавливаем загруженный файл корневого сертификата в хранилище Доверенные корневые центра сертификации (Trusted Root Certification Authorities) хранилища Локальный компьютер (эту операцию нужно выполнять с правами администратора):

certutil -addstore Root  "C:\Temp\CertificateRootCA.cer"

В ответ мы должны получить информацию об успешной установке сертификата ЦС

Root "Доверенные корневые центры сертификации"
Подпись соответствует открытому ключу
Сертификат "KOMI Root CA" добавлен в хранилище.
CertUtil: -addstore — команда успешно выполнена.

Запускаем консоль mmc.exe, и загружаем оснастку управления сертификатами. Для этого выбираем в меню File > Add/Remove Snap-In. В списке оснасток выбираем Certificates > нажимаем Add > выбираем Computer account > выбираем Local computerimage

Убеждаемся в том, что в контейнере Trusted Root Certification Authorities\Certificates отображается корневой сертификат нашего ЦС.

image

 

 

7.2. Создание сертификата VPN-сервера

Сертификат, который мы будем создавать для каждого VPN-сервера, должен содержать в расширениях «Улучшенный ключ» цели «Проверка подлинности сервера» (OID — 1.3.6.1.5.5.7.3.1) и «Проверка подлинности клиента» (OID — 1.3.6.1.5.5.7.3.2)

Нижеописанные манипуляции нужно проводить непосредственно с сервера VPN.

Для генерации запроса на получение сертификата от ЦС, создаём во временном каталоге, например C:\Temp, конфигурационный файл RequestConfigVPNServer.inf со следующим содержимым:

[Version]
Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=KOM-AD01-VPNCL.holding.com"
Exportable = TRUE; Private key is exportable
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xf0; Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment
MachineKeySet = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
RequestType = PKCS10

[EnhancedKeyUsageExtension] 
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication
OID=1.3.6.1.5.5.8.2.2 ; IP Security IKE intermediate
  
[RequestAttributes] 
SAN  = "dns=KOM-AD01-VPNCL.holding.com&" 
_continue_ = "dns=KOM-AD01-VPN01.holding.com&" 
_continue_ = "dns=KOM-AD01-VPN02.holding.com&"  

Параметр Exportable = TRUE определяет то, что для генерируемого сертификата возможен будет экспорт закрытого ключа. В таком виде этот параметр стоит использовать лишь в том случае, если вы хотите использовать один сертификат на нескольких VPN-серверах, во всех остальных случаях желательно использовать значение вида Exportable = FALSE

Генерируем файл запроса на основе конфигурационного файла:

certreq -new -f "C:\Temp\RequestConfigVPNServer.inf" "C:\Temp\RequestBinaryVPNServer.req"

Получаем ответ, что запрос создан и сразу отправляем этот запрос в ЦС. В зависимости от того, как настроен ЦС на автоматическое одобрение, можно использовать один из описанных далее вариантов отправки в ЦС запроса и получения сертификата…

***

Вариант А (в случае если автоматическая выдача сертификатов в ЦС выключена)

Выполняем отправку запроса сертификата в ЦС:

certreq –submit –f -config "kom-ad01-ca01.holding.com\KOMI Root CA" "C:\Temp\RequestBinaryVPNServer.req"

В ответ мы получим примерно следующее:

Код запроса (RequestId): 31
Код запроса: "31"
Запрос сертификата в ожидании: Taken Under Submission (0)

Как видим, RequestId выведен нам на консоль с сообщением, означающим то, что наш запрос переведён в ожидание одобрения администратором ЦС. Запомним номер RequestId.
На этом этапе администратор ЦС выполняет одобрение на генерацию сертификата по полученному запросу. После этого мы можем выполнить загрузку сертификата из ЦС (31 в данном примере это и есть RequestID):

certreq -retrieve -f -config "kom-ad01-ca01.holding.com\KOMI Root CA" 31 "C:\Temp\CertificateVPNServer.cer"

В ответ мы должны получить сообщение об успешной загрузке сертификата:

Код запроса (RequestId): 31
Код запроса: "31"
Получен сертификат(Выдан) Issued  Resubmitted by KOM\adm-artur

***

Вариант Б (в случае если автоматическая выдача сертификатов в ЦС включена)

Выполняем отправку запроса сертификата в ЦС и сразу указываем куда будет сохранён автоматически полученный готовый сертификат:

certreq –submit –f -config "kom-ad01-ca01.holding.com\KOMI Root CA" "C:\Temp\RequestBinaryVPNServer.req" "C:\Temp\CertificateVPNServer.cer"

В ответ мы получим примерно следующее сообщение говорящее об успешной автоматической выдаче сертификата:

Код запроса (RequestId): 31
Код запроса: "31"
Получен сертификат(Выдан) Issued

Как видим, с включённым механизмом автоматической выдачи сертификатов в ЦС процесс намного проще.

***

После того, как сертификат загружен (любым из перечисленных выше способов) выполняем его установку:

certreq -accept "C:\Temp\CertificateVPNServer.cer"

После успешной установки сертификата не забываем удалить из временного каталога все файлы, которые были созданы в процессе запроса, получения и установки сертификата. Дополнительно проверить наличие установленного сертификата можно в оснастке управления сертификатами в хранилище Локальный компьютер

image

 

7.3. Создание сертификата VPN-клиента

Сертификат компьютера, который мы будем создавать для каждого VPN-клиента, как минимум, должен содержать в расширениях «Улучшенный ключ» цель «Проверка подлинности клиента» (OID — 1.3.6.1.5.5.7.3.2)

[Version]
Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=KOM-AD01-WS001.holding.com" ; 
Exportable = FALSE; Private key is not exportable 
KeyLength = 2048
KeySpec = 1
KeyUsage = 0xf0; Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment 
MachineKeySet = TRUE 
ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
RequestType = PKCS10

[EnhancedKeyUsageExtension] 
OID=1.3.6.1.5.5.7.3.2 ; Client Authentication

Параметр определяющий возможность экспорта закрытого ключа для всех VPN-клиентов - выключаем. Этим самым мы ограничим возможность “утечки” сертификата с закрытым ключом с клиентского компьютера. Команды запроса и установки сертификата на VPN-клиенте в ручном режиме аналогичны п.7.2. В результате подобного запроса к ЦС, будет выдан соответствующий сертификат клиента, который после установки на клиентский компьютер должен говорить нам о наличии закрытого ключа.

image

Учитывая то обстоятельство, что в качестве VPN-клиентов чаще всего выступают домашние компьютеры пользователей, а настройку подключения эти пользователи делают самостоятельно, нам нужно постараться максимально автоматизировать вышеописанные процедуры связанные с запросом, получением и установкой сертификата компьютера. Поэтому, весьма желательно, чтобы у пользователя на руках была пошаговая инструкция по настройке VPN-подключения (п.12), а все манипуляции связанные с установкой сертификата выполнялись в пакетном режиме. Для этого создадим командный файл, в котором будет выполняться генерация запроса к ЦС, получение сертификата (ЦС должен быть настроен на автоматически ответ) и установка этого сертификата на клиентский компьютер.

Пример командного файла Install Certificate.cmd:

set vSubject=%COMPUTERNAME%
set vCAPath="kom-ad01-ca01.holding.com\KOMI Root CA"

set vTempPath=%SystemDrive%\TempVPNCertFiles
set vRequestInf=%vTempPath%\RequestConfigVPNClient.inf
set vRequestBin=%vTempPath%\RequestBinaryVPNClient.req
set vCert=%vTempPath%\CertificateVPNClient.cer

mkdir %vTempPath%

rem Get the CA's cert
certutil -f -config %vCAPath% -ca.cert %vTempPath%\CertificateRootCA.cer

rem Move the CA's cert to the "Trusted Root Authorities" store
certutil -f -addstore Root  %vTempPath%\CertificateRootCA.cer

rem Create an INF request file
del %vRequestInf%
echo [Version]                    > %vRequestInf%
echo Signature="$Windows NT$"    >> %vRequestInf%
echo [NewRequest]                >> %vRequestInf% 
echo Subject="CN=%vSubject%"     >> %vRequestInf% 
echo Exportable=FALSE            >> %vRequestInf%
echo KeyLength=2048              >> %vRequestInf%
echo KeySpec=1                   >> %vRequestInf%
echo KeyUsage=0xf0               >> %vRequestInf%
echo MachineKeySet=TRUE          >> %vRequestInf%
echo ProviderName="Microsoft RSA SChannel Cryptographic Provider" >> %vRequestInf%
echo RequestType=PKCS10          >> %vRequestInf%
echo [EnhancedKeyUsageExtension] >> %vRequestInf% 
echo OID=1.3.6.1.5.5.7.3.2       >> %vRequestInf%

rem Create a binary request file from the INF
del %vRequestBin%
certreq -new -f %vRequestInf% %vRequestBin%

rem Submit the request to our CA and save the certificate
certreq -submit -f -config %vCAPath% %vRequestBin% %vCert%

rem This step needed to import the private key.  Also puts the certificate in the local computer personal store.
certreq -accept %vCert%

rem Clear files
rmdir /s /q %vTempPath%

В качестве предварительных условий для работы командного файла должно быть соблюдено, как минимум, два условия:
1) Перед запуском командного файла пользователь должен установить VPN-соединение по протоколу PPTP (для доступности ЦС из локальной сети);
2) Командный файл нужно выполнять на клиентском компьютере с правами администратора (для возможности добавления сертификата в хранилище “Локальный компьютер”)

Работа приведённого примера командного файла без дополнительных условий может использоваться (была проверена) на Windows 8/8.1, Windows 7 SP1, Windows Vista SP2.

Для клиентов же Windows XP, как всегда, всё несколько сложнее. В частности, для Windows XP SP3, согласно статьи KB934576 - Auto-enrollment is not triggered when you try to use Certutil.exe on a Windows XP-based computer, для успешной работы командного файла потребуется наличие трёх дополнительных файлов из состава Windows Server 2003 Administration Pack: certutil.exe, certreq.exe и certadm.dll , так как этих файлов нет в базовом составе ОС.

Помимо этого, на сервере выполняющем роль ЦС, если он работает под управлением Windows Server 2012/2012 R2, согласно документа, потребуется понизить уровень безопасности для обработки процедуры запросов на выдачу для клиентов на Windows XP. Описание того, как это можно сделать, можно найти в одной из прошлых заметок.

Дополнительно для Windows XP потребуется убрать из командного файла строчку

echo ProviderName="Microsoft RSA SChannel Cryptographic Provider" >> %vRequestInf%

В конечном итоге, можно либо дальше расширять логику командного файла для разного алгоритма работы на различных версиях Windows, либо попросту создать готовые командные файлы под каждую версию клиентской ОС Windows. Например, для пользователей, у которых на домашнем компьютере установлена Windows XP должен поставляться  следующий набор файлов:image

А, например, для пользователей, у которых на домашнем компьютере установлена Windows 8/8.1 будет другой набор файлов, состоящий фактически только из соответствующего командного файла и пошаговой инструкции для пользователя по настройке VPN подключения:

image

 

8. Проверка подключения VPN-клиента из Интернет по протоколу L2TP/IPSec

Меняем настройки VPN-подключения на клиентском компьютере на использование протокола L2TP/Ipsec и проверяем подключение из Интернет.image

В случае проблем с подключением, изучаем event-логи на VPN-сервере, а также на сервере RADIUS, так как теперь все события связанные с процедурами аутентификации и авторизации фиксируются именно там.

Если подключение к первому настроенному VPN-серверу по протоколу l2TP/Ipsec прошло успешно, то можно приступить к следующему этапу расширения конфигурации. 

 

9. Настройка второго VPN-сервера (KOM-AD01-VPN02)

Настройку второго VPN-сервера с именем KOM-AD01-VPN02 выполняем по аналогии с первым VPN-сервером.

При желании использовать на втором VPN-сервере тот же сертификат, который был создан для первого VPN-сервера, экспортируем сертификат сервера с закрытым ключом с первого сервера и импортируем на второй сервер.

Не забываем прописать данные второго VPN-сервера на серверах RADIUS и отдельно протестировать возможность подключения к этому VPN-серверу сначала по протоколу PPTP, затем по протоколу L2TP/Ipsec. Если в итоге мы смогли убедиться в том, что VPN-подключения успешно работают для обоих VPN-серверов по отдельности, то настало время собрать их в кластер.

 

10. Создание NLB-кластера из двух VPN-серверов

Отправной документ для построения кластера здесь: Deploy Remote Access in a Cluster
Планирование описано в документе Plan a Remote Access Cluster Deployment
Конфигурирование кластера описано в документе
Configure a Remote Access Cluster

***

Первым делом обратим внимание на то, что в свойствах виртуальных машин Hyper-V, в которых работают наши VPN-серверы, которые мы хотим сделать членами NLB кластера, для сетевого адаптера WAN необходимо разрешить спуфинг МАС адресов (Enable spoofing of MAC addresses). Именно этот сетевой адаптер мы будем делать членом NLB-кластера.image

***

Затем создаём во внешней зоне DNS статическую А-запись для будущего NLB кластера:

image

 

***

Далее, с помощью PowerShell установим на оба VPN-сервера исполняемые компоненты NLB

Import-Module "ServerManager" 
Add-WindowsFeature "NLB" -IncludeManagementTools

***

После добавления роли NLB в Windows Firewall добавляется ряд правил связанных с этой ролью. Нам нужно будет откорректировать эти правила, в частности свести к минимуму возможность контакта к интерфейсам управления NLB из Интернет, отключить правила для IPv6, если этот протокол не используется, ограничить правила меж-узлового обмена и т.п. В конечном итоге, из включённых и настроенных правил, касающихся NLB, у меня получилась такая картина на первом VPN-сервере:image

На втором VPN-сервере:

image

***

Теперь приступим к процессу создания NLB-кластера.

На первом сервере RAS (KOM-AD01-VPN01) открываем консоль Network Load Balancing Manager (nlbmgr.exe). Выбираем пункт меню Cluster > New Cluster

image

Вводим имя первого узла, который хотим добавить в NLB, кнопкой Connect подключаемся к нему, и получив с него набор доступных интерфейсов, выбираем тот, который хотим сделать участником кластера:

image

На странице параметров хоста (Host Parameters) оставляем настройки по умолчанию:

image

В следующем окне мастера создания кластера добавляем IP адрес NLB кластера, на который мы ранее зарегистрировали А-запись во внешней зоне DNS.

image

Далее указываем FQDN кластера NLB (по той самой A-записи), а также режим его работы. В нашем примере выбран режим одноадресной рассылки – Unicast.

image

На странице правил портов (Port rules) удаляем имеющееся по умолчанию правило и добавляем необходимые нам правила. При добавлении правила портов убираем флажок All и указываем конкретный интерфейс NLB и диапазон портов, который хотим добавить в кластер NLB.

Отдельное замечание по допустимым режимам фильтрации (Filtering Mode), касающееся построения NLB для VPN можно найти в документе Create a new Network Load Balancing Port Rule:

When using NLB to load balance virtual private network (VPN) traffic (such as PPTP/GRE and IPSEC/L2TP), you must configure the port rules that govern the ports handling the VPN traffic (TCP port 1723 for PPTP and UDP port 500 for IPSEC) to use either Single or Network affinity.

image

В общей сложности, в нашем примере балансировке в NLB кластере мы будем подвергать следующие порты:

TCP 1723 – Routing and Remote Access (PPTP-In);
UDP 1701 – Routing and Remote Access (L2TP-In);
UDP 500 – Routing and Remote Access (Allows IKE traffic to the VPN server);
UDP 4500 – Routing and Remote Access (Allows IPsec NAT-T traffic from the VPN client to the VPN server.);

image

Все необходимые параметры кластера заданы, создаем его по нажатию кнопки Finish и после первоначальной инициализации, если в конфигурации не допущены ошибки, NLB кластер запуститься в конфигурации с одним узлом

image

Далее, переходим на имя NLB кластера и пунктом меню Add Host to Cluster вызываем мастер добавления второго сервера в кластер.

image

Вводим имя второго VPN-сервера, подключаемся к нему кнопкой Connect и после появления информации о сетевых интерфейсах сервера выбираем WAN-интерфейс, который хотим включить в NLB кластер.

image

Все прочие настройки при добавлении узла кластера можно оставить по умолчанию.

После добавления второго узла мы получим работоспособный Windows NLB кластер

image

 

11. Проверка работы NLB-кластера

После того как NLB-кластер настроен, с помощью VPN-клиента проверяем из Интернет доступность кластерного интерфейса предварительно по очереди выключая узлы кластера, чтобы убедиться в том, что VPN-подключения к кластерному интерфейсу устанавливаются успешно в случае неполной работоспособности узлов кластера.

 

12. Инструкции для пользователей

Как уже отмечалось ранее, для пользователей выполняющих подключение к корпоративным VPN-серверам из Интернет необходимо разработать чёткие пошаговые инструкции. Мне удалось протестировать (и параллельно разработать пошаговые инструкции для пользователей) VPN-подключения в составе следующих операционных систем:

  • Windows XP 32-bit RU SP3
  • Windows Vista Business 32-bit RU SP2
  • Windows 7 Pro 32-bit RU SP1
  • Windows 8.1 Pro 64-bit RU
  • Ubuntu Desktop Linux 14.04.1 64-bit

Архив с инструкциями (а также нужными исполняемыми файлами), которые, при желании, вы можете адаптировать под своё окружение можно скачать по ссылке.

Если потребуется заниматься настройкой VPN-подключения по протоколу L2TP/Ipsec на других дистрибутивах Linux, возможно, будет полезен документ L2TP over IPsec VPN Manager User Guide

С настройкой подключения на Android у меня, к сожалению так ничего и не вышло. Задачи такой в общем-то и не стояло, просто было интересно попробовать. Перепробовал несколько разных бесплатных приложений доступных на Google Play, все довольно сносно работали по PPTP, но ничего не получалось при этом с L2TP/Ipsec. Встречались интересные приложения, но все они были либо платные, либо заточены под старые версии Android, например тот же OneVpn. Параллельно познакомился с таким “зверем”, как эмулятор Android - Android-x86. Пару полезных ссылок на тему того, как это дело завести в среде Hyper-V:

 

Дополнительные источники информации

Всего комментариев: 67 Комментировать

  1. Alex /

    Спасибо за ваш труд, у вас всегда хорошие публикации.

  2. Eugene Leitan /

    Данная статья тянет на 10 ++ или еще больше :)
    Еще и инструкции для пользователей по ссылке ! :)

    Спасибо, Алексей!

  3. Андрей /

    Алексей Иванович таки запилил кошерный ВПН))

  4. Aleksey Maksimov /

    Из Андроида удалось подключиться к MS RRAS по протоколу L2TP, только тогда когда "выставил" RRAS напрямую в интернет...

  5. nick /

    отличная статья! во многом разобрался.

  6. Алексей Максимов / Автор записи

    Появилась дополнительная инструкция подключения для пользователей OS X. Если кому надо - обращайтесь.

  7. имя /

    Запускаем консоль mmc.exe, и загружаем оснастку управления сертификатами. Для этого выбираем в меню File > Add/Remove Snap-In. В списке оснасток выбираем Certificates > нажимаем Add > выбираем Computer account > выбираем Local computer
    ========================
    замечание: если проверить это ДО импорта Root CA, то увидите, что он уже там есть.
    где почитать про OS X ? пока без SSL работаем. спасибо.

    1. Алексей Максимов / Автор записи

      "если проверить это ДО импорта Root CA, то увидите, что он уже там есть." Ну это значит только то, что ваш корневой сертификат был распространён ранее. Сам по себе он там вырасти не мог.

      1. имя /

        он появился там после установки CA. Собственно, СА и должен был добавить сам себе этот сертификат после установки CA. Так же появился персональный сертифкат у Контроллера домена (он же СА). у других серверов и клиентов ничего не появилось. Никаких настроек в GPO не делал.

      2. имя /

        есть 300 пк, каждый пк имеет на рабочем столе батничек такого рода:
        rasdial "vpn" login password
        в сетевых подключениях есть подключение "vpn". pptp протокол.
        конект происходит на сервер , который в данный момент работает под линуксом. волею судеб нужно чтоб сервер был под виндой. причем таким образом, чтоб не трогать эти 300 пк(вообще не трогать, они даже знать не должны таких изменений).
        сама сеть устроена так - что эти 300пк разбиты на несколько групп, члены каждой группы видят в сети только участников их группы.
        реально ли, и как организовать такую вещь под серверной windows?

    2. имя /

      так где почитать про подключение OS X ?

      1. Алексей Максимов / Автор записи

        Обновил архив с инструкциями. Добавлена инструкция настройки OS X Yosemite.

  8. имя /

    во время создания запроса в ЦС получаю ошибку шаблона:
    RequestId: 3
    RequestId: "3"
    Certificate not issued (Denied) Denied by Policy Module 0x80094801, The request does not contain a certificate template extension or the CertificateTemplate request attribute.
    The request contains no certificate template information. 0x80094801 (-2146875391 CERTSRV_E_NO_CERT_TYPE)
    Certificate Request Processor: The request contains no certificate template information. 0x80094801 (-2146875391 CERTSRV_E_NO_CERT_TYPE)
    Denied by Policy Module 0x80094801, The request does not contain a certificate template extension or the CertificateTemplate request attribute.

    1. Алексей Максимов / Автор записи

      В статье рассматривается пример использования выделенного ЦС, где шаблоны сертификатов не учитываются, так как для Standalone CA они попросту не поддерживаются. Вы используете доменный ЦС, для которого нужно указывать шаблон сертификата. Меняйте скрипт запроса под свои условия.

      1. имя /

        а почему вы используете недоменный ЦС ?
        а что именно менять в скрипте? попытался в GUI сделать запрос, где можно выбрать шаблон, а мне другая ошибка: шаблон не поддерживается:
        Certificate not issued (Denied) Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Active Directory Certificate Services policy: IPSECIntermediateOffline.
        The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)
        Certificate Request Processor: The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)
        Denied by Policy Module 0x80094800, The request was for a certificate template that is not supported by the Active Directory Certificate Services policy: IPSECIntermediateOffline.

        Спасибо!

        1. имя /

          вот что я сделал: я просто выпустил Компьютер сертификат и для VPN сервера и для клиента - всё работает. Но правильно ли использовать шаблон по умолчанию "Компьютер" ?

          1. имя /

            создал сертифкат для OS X, но почему-то он выдался не на имя компа, а на имя запросившего пользователя (

  9. Обратная ссылка: System Center 2012 R2 App Controller Hight Availability на базе узлов кластера Virtual Machine Manager | Блог IT-KB /

  10. Максим Васильевич /

    очень даже хорошая инструкция, автору спасибо!
    только у меня при такой настройке не проходит проверка соединения по PPTP(((
    При попытке подключения подвисает на проверке логина и пароля и выкидывает с ошибкой 806, ссылаясь на закрытые порты протокола GRE. Прописал в фаерволе(стоит каспер и в нем фаервол) разрешение в обе стороны а результат тот же. Что именно не так не могу понять, где ошибка закралась или что мешает?

  11. Александр /

    Доброго дня
    А Вы не пробовали прикрутить SCOM для мониторинга за Windows Server 2012 R2 Remote Access имеется ввиду не за самой Windows Server, а будет ли показывать SCOM какие клиенты подключались по VPN?
    Спасибо.

    1. Алексей Максимов / Автор записи

      Работает у меня такой MP на SCOM. Но ведь он для того, чтобы следить за работоспособностью служб роли Remote Access. А "показывать SCOM какие клиенты подключались по VPN" это уже из другой оперы. Это уже больше задача аудита безопасности. Если Вам нужен такой аудит - делайте собственный MP, настроенный для сбора событий из евент-логов.

    2. Евгений Лейтан /

      Согласен с Алексеем.
      Если хочется быстро получить результат какие клиенты подключались по VPN, используйте Securiry Event ID 4648 (в SCOM - событие работоспособности) и 6272 (в SCOM - событие неработоспособности) на сервере NPS (RAs).

      http://blog.it-kb.ru/2011/09/29/install-radius-windows-network-policy-server-for-authentication-on-apc-ups-web-snmp-management-card/
      "Помимо этого на нашем NPS сервере RADIUS в системном журнале Security будут зарегистрированы события прохождения авторизации с соответствующими кодами, например:
      6278 —Network Policy Server granted full access to a user because the host met the defined health policy
      6272 — Network Policy Server granted access to a user
      6273 — Network Policy Server denied access to a user "

  12. Алексей /

    Добрый день!
    У меня на одном сервере 2012 установлены роль Remote Access и служба NPS, и при настройке VPN сервера для использования RADIUS аутентификации во вкладке Безопасность нет возможности выбрать Authentication provider и Accounting provider, такой комментарий: "Т.к. установлен сервер NPS необходимо использовать его для настройки проверки подлинности поставщиков учетных записей. Для этого создайте или измените политики запросов на подключение." Что именно и где нужно создать? Спасибо.

  13. Максим /

    Я столкнулся с аналогичной проблемой...
    Никак побороть не могу. Уже и ставил-переустанавливал... Гугл молчит.

    1. Алексей Максимов / Автор записи

      Попробуйте создать политику для VPN подключений в Оснастке NPS > Policies > Connection Request Policies

      1. Максим /

        Пробовал. Изменений не последовало. Спасибо.

  14. Максим /

    Такая проблема возникает при установке на один сервер и RRAS и NPS.
    Развернул NPS на контроллере домена и удалил NPS на RRAS - проблема ушла.

  15. Андрей /

    У меня не получается настроить L2TP/IPSEC на VPN сервере под Windows Server 2012 R2. Сервер находится за NAT. Порты 1701, 4500, 500 открыл на маршрутизаторе и брандмауэре. Соединяться пытаюсь с Windows 8.1 Pro. А SSTP очень даже хорошо настроил через авторизацию клиента по пользовательскому сертификату. Спасибо за статью! Очень хочется настроить L2TP/IPSEC на Windows Server 2012 R2.

    1. Алексей Максимов / Автор записи

      В SSTP в чистом виде нет такого понятия как клиентский сертификат, там сертификат предоставляется именно VPN-сервером. Это более простой сценарий чем с L2TP/Ipsec. Мы сейчас сами будем переводить своих клиентов выше WinXP на SSTP, и об этом я уже готовлю отдельную заметку.

      1. Андрей /

        Алексей, а L2TP/IPSEC все же можно настроить на VPN сервере под Windows Server 2012 R2 за NAT (клиенты тоже за NAT) ?

        1. Алексей Максимов / Автор записи

          Думаю можно. Попробуйте поиграться с параметром AssumeUDPEncapsulationContextOnSendRule
          Вот для наводки:
          https://support.microsoft.com/en-us/kb/926179
          https://support.microsoft.com/en-us/kb/885407
          https://support.microsoft.com/en-us/kb/885348

          1. Андрей /

            Получилось подключиться поправив реестр по первой ссылке через Windows 8.1 Pro по L2TP/IPSEC. А вот XP никак не хочет.

  16. Алексей Максимов / Автор записи

    Вторая ссылка как раз-таки про XP. Насколько я понимаю система должна иметь как минимум SP2, а ещё лучше SP3. Плюс на практике ещё встречалось такое, что у каких-то клиентов VPN-подключение работало, а у каких-то нет при прочих равных условиях но через разных Интернет-провайдеров. В итоге выяснялось что у одного провайдера весь трафик пропускается, а у другого блокируются некоторые нужные порты. Было даже такое, что у одного и того же провайдера в разных районах города сетевое оборудование было настроено по разному и поэтому в одном месте трафик ходил без проблем, а в другом ни в какую. В таких случаях можно взять и попробовать с проблемного клиента подключиться к какому-нибудь публичному L2TP/IPsec серверу и если проблема подключения будет на лицо, то решать вопрос уже с провайдером. Других вариантов тут нет.

  17. Андрей /

    Сегодня столкнулся с проблемой с отзывом сертификатов. На клиенте VPN при попытке соединения по SSTP выдает ошибку, что сертификат был отозван. Но в CA сертификат не отозван и certutil -f –urlfetch -verify, certutil -url - это подтверждают. То же самое всех клиентах. CRL доступен по http. Кто-нибудь сталкивался с проблемой?

    1. Алексей Максимов / Автор записи

      Не сталкивались. Только пока перебираемся на SSTP. Сертификат используем публичный. Полёт пока нормальный. А у Вас получается SSTP работало, а потом друг резко перестало? Если так, то интересно почему такое может произойти. Не забудьте нам потом об это рассказать :)

      1. Андрей /

        Да, сегодня не проходит проверка отзыва сертификата. Пришлось установить NoCertRevocationCheck. Пока не понял в чем проблема.

      2. Андрей /

        Оказалось, что проблема была в том, что был отозван сертификат сервера с ролью Remote Access. Все из-за невнимательности при отзыве сертификатов (тех, что были на этапе тестирования).

  18. Алексей Максимов / Автор записи

    Ну вот, как всё банально. Зато проверили и убедились в том, что отзыв сертификата сервера приводит к остановке работы сервиса :)

  19. Обратная ссылка: Windows Server 2012 R2 Remote Access — Настраиваем VPN сервер на использование протокола SSTP | Блог IT-KB /

  20. Олег /

    Прежде всего, хочу поблагодарить автора за столь подробную инструкцию!
    У меня один вопрос. В ней не описана настройка политики запросов на подключение (Connection Request Policy), без которой ничего работать не будет. Вы, вероятно, преднастраивали её прежде, а потом просто забыли здесь о ней упомянуть.

    1. Алексей Максимов / Автор записи

      Ничего про это не написано только потому, что ничего в этом плане специально и не делалось. В RADIUS есть включённая по умолчанию политика "Use Windows authentication for all users". Её наличия вполне достаточно (без внесения изменений), чтобы всё работало.

      1. Олег /

        Видимо, мне не повезло, так как в моём случае этого оказалось недостаточно.
        Дело в том, что при использовании мастера настройки NPS именно для VPN-соединений политика запроса на подключение для VPN NAS прописывается на автомате. Вероятно, она для чего-то нужна, раз так задумал Microsoft. И без неё при наличии только лишь политики "Use Windows authentification for all users" я железно получаю ошибку 812.
        Я описал свою проблему и её решение у себя в блоге:

        http://linux.bolden.ru/vpn-error-812/

        Возможно, кому-то пригодится.

        1. Олег /

          Алексей, к сожалению я заблуждался насчёт того, что смог решить свою проблему. Оказывается настройки аутентификации через Radius в опциях VPN-сервера у меня просто слетели и всё вернулось на круги своя - на аворизацию Microsoft. Совсем случайно это сегодня заметил.
          Удалите, пожалуйста, ветку которую я начал.
          Никак не пойму, почему не удаётся настроить Radius-авторизацию и где ошибка.

          1. Александр /

            Сначала не дочитал комментарии, решается ошибка 812 путем изменения политики "Политики запросов на подключения"--"Политика служб маршрутизации и удаленного доступа", ставим параметры -переопределить параметры проверки подлинности и проверка подлинности ставим этот сервер, это настройка на одном компе...

        2. Александр /

          Добрый день Олег, подскажите как вы исправили ошибку 812, ссылка не работает.

  21. Алексей добрый день,
    перечитал пачку статей - ваша одна из самых информативных, и все же:
    Дано:
    2012 с ВПН сервером, и выпущенным сертификатом(в точности ваш совет)
    Win7(сертификат выпущен в домене, сам клиент не доменный)- рутовый сертификат в трастед, сертификат для машины - в personal и на сервере в personal.

    И тем не менее - при авторизации - пресловутая, информативная ошибка 13806. Подскажите, будьте добры, что еще можно проверить.

    1. exonix /

      если у Вас NAT - то проверьте ключ реестра:
      [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent]
      "AssumeUDPEncapsulationContextOnSendRule"=dword:00000002
      после смены на 2 - перезагрузите систему
      если у Вас VPN IKEv2 - на 2012 он не работает.

  22. Оба сертификата - выпущены со всеми нужными EKU и сабджектами.

  23. exonix /

    если кому интересно - сбор логов VPN сервера в базу mysql: http://exonix.ru/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D0%B8/Windows_Server/PowerShell/%D0%9C%D0%BE%D0%BD%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D0%BD%D0%B3_VPN/

  24. exonix /

    Я прочитал ещё раз статью, и не могу понять - зачем создавать сертификат для VPN-клиента, если он нигде не используется?

    1. Александр /

      Как же не используется? когда выбираешь тип подключение по L2TP/IPsek он без сертификата или ключа не подключиться, смотря как сервер настроен...

      1. exonix /

        значит я что-то не так сделал. спасибо

  25. exonix /

    всё таки у меня касяк какой-то с сертификатами.
    как делал:
    inf файл (сюда добавил только CertificateTemplate, ибо без него ругалось):
    [Version]
    Signature="$Windows NT$"

    [NewRequest]
    Subject = "CN=test.имя.моего.домена" ;
    Exportable = FALSE; Private key is not exportable
    KeyLength = 2048
    KeySpec = 1
    KeyUsage = 0xf0; Digital Signature, Non-Repudiation, Key Encipherment, Data Encipherment
    MachineKeySet = TRUE
    ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
    RequestType = PKCS10

    [EnhancedKeyUsageExtension]
    OID=1.3.6.1.5.5.7.3.2 ; Client Authentication

    [RequestAttributes]
    CertificateTemplate= L2TPComputer

    затем выполнил запрос на сервере CA и получил сертификат:
    C:\>certreq -new -f "cert.inf" "RequestBinaryVPNServer.req"
    Active Directory Enrollment Policy
    {517E8E44-130E-44A7-AC43-B35A548258E7}
    ldap:

    CertReq: Request Created

    C:\>certreq -submit -f -config "dc1.имя.моего.домена\имя.центра.сертификации" "RequestBinaryVPNServer.req" "CertificateVPNServer.cer"
    RequestId: 7
    RequestId: "7"
    Certificate retrieved(Issued) Issued

    вроде всё, положил сертификат в общую папку (для теста), скопировал пользователю на компьютер - импорторировал, а не работает... При этом в свойствах сертификата НЕТ "у вас есть приватный ключ, соответствующий данному сертификату"

    Что я упустил?

    1. exonix /

      PS.: Шаблон L2TPComputer сделан на основе Шаблона Computers. Если сертификат запрашивать на клиенте через оснастку MMC - Certifikates - всё работает...

      1. exonix /

        решил. добавил в inf файл это:
        [Extensions]
        2.5.29.17 = "{text}"
        _continue_ = "UPN="имя.моего.домена"
        Critical = 2.5.29.17

  26. Александр /

    Добрый день!
    проверка на соответствие клиента ведется по SHV. Параметров довольно таки мало. Может кто нибудь делал дополнительные параметры мониторинга (к примеру наличие установленного софта или значение ключа реестра)? Может есть реализации такого функционала с помощью другого софта?

    1. exonix /

      VPN тут при чём?

      1. Александр /

        Хочется реализовать проверку клиентов подключающихся к сети (как пример, соответствие определенных ключей реестра определенным параметрам и отслеживание этих параметров в течении всей VPN сессии)

        1. exonix /

          здесь обсуждается настройка VPN. Мониторинг клиентов - это уже отдельные приложения.

  27. Дмитрий /

    certutil -f -config "имя_сервера\Имя_CA" -ca.cert "C:\Temp\CertificateRootCA.cer"
    выдается ошибка
    Expected no more than 1 args, received 2
    certutil: Too many arguments

    и в какую сторону копать - непонятно. у меня тестовый стенд, AD и CA размещены на 1м сервере. команду выполняю на VPN.

    1. Алексей Максимов / Автор записи

      Проверяйте ключи, которые поддерживает ваша версия certutil (команда certutil -?).
      Попробуйте переписать команду полностью руками, если откуда-то копировали.
      Обратите внимание на кавычки. Похоже на простую синтаксическую ошибку.

      1. Дмитрий /

        Вообще если начинать разбирать аргументы команды то получается что затык происходит на 1м же аргументе... certutil -config «имя_сервера\Имя_CA»
        unexpected "-config" option

        и в кавычках и без кавычек (имя CA у меня слитное)

        certreq с -config «имя_сервера\Имя_CA» срабатывает спокойно. там вообще от регистра может быть зависимость?!

  28. Serega /

    Добрый день,
    Подскажите пожалуйста с проблемой на клиенте при запросе сертификата через cmd.
    В запросе отсутствует информация о шаблоне сертификата.
    ЦС Enterprise.

    1. Serega /

      Спасибо exonic за подсказку
      [RequestAttributes]
      CertificateTemplate= L2TPComputer
      Все заработало.
      Статья супер.
      Отдельное спасибо автору.

      1. exonix /

        я ниже написал как можно гораздо проще выпускать сертификаты для сервера. "6 секунд" и всё )

  29. Павел /

    Здравствуйте, всё замечательно настроилось по инструкции, только настраивал L2TP c Preshred Key. В свойствах сервера, в security - authentication methods отключаем chap, оставив только ms-chap v2 и андроиды начинают подключаться по vpn.

  30. exonix /

    если кому интересно, есть намного простой способ выпускать сертификаты и для сервера и клиента. для этого надо настроить соответствующие шаблоны в CA, а затем:
    Set-Location 'Cert:\LocalMachine\My'
    Get-Certificate -Template SSTP-VPN -Url ldap:///CN=dc1.domain.com -DnsName VPN4.DOMAIN.COM -CertStoreLocation Cert:\LocalMachine\My

Добавить комментарий