Как поднять vpn сервер на windows server 2012 r2

В этой статье мы покажем, как установить и настроить простейший VPN сервер на базе Windows Server 2012 R2, который можно эксплуатировать в небольшой организации или в случае использования отдельно-стоящего сервера (т.н. hosted-сценариях).

Примечание. Данный мануал не рекомендуется использовать в качестве справочника для организации VPN сервера в крупной корпоративной сети. В качестве enterprise-решения предпочтительнее развернуть Direct Access и использовать его для удаленного доступа (который, кстати говоря, настроить теперь намного проще, чем в Windows 2008 R2).

В первую очередь необходимо установить роль “Remote Access”. Сделать это можно через консоль Server Manager или PowerShell (немого ниже).

В роли Remote Access нас интересует служба “DirectAccess and VPN (RAS)” . Установим ее (установка службы тривиальна, на последующих шагах все настройки можно оставить по-умолчанию. Будут установлены веб сервер IIS, компоненты внутренней базы Windows — WID).

После окончания работы мастера нажмите ссылку “Open the Getting Started Wizard“, в результате чего запустится мастера настройки RAS-сервера.

Службу RAS с помощью Powershell можно установить командой:

Install-WindowsFeatures RemoteAccess -IncludeManagementTools

Так как нам не требуется разворачивать службу DirectAccess, укажем, что нам нужно установить только сервер VPN (пункт “Deploy VPN only“).

После чего откроется знакомая MMC консоль Routing and Remote Access. В консоли щелкните правой кнопкой по имени сервера и выберите пункт “Configure and Enable Routing and Remote Access“.

Запустится мастер настройки RAS-сервера. В окне мастера выберем пункт “Custom configuration“, а затем отметим опцию “VPN Access”.

После окончания работы мастера система предложит запустить службу Routing and Remote Access. Сделайте это.

В том случае, если между вашим VPN сервером и внешней сетью, откуда будут подключаться клиенты (обычно это Интернет), есть файервол, необходимо открыть следующие порты и перенаправить трафик на эти порты к вашему VPN серверу на базе Windows Server 2012 R2:

• Для PPTP: TCP — 1723 и Protocol 47 GRE (также называется PPTP Pass-through)
• Для SSTP: TCP 443
• Для L2TP over IPSEC: TCP 1701 и UDP 500

После установки сервера, необходимо в свойствах пользователя разрешить VPN доступ. Если сервер включен в домен Active Directory, сделать это нужно в свойствах пользователя в консоли ADUC, если же сервер локальный – в свойствах пользователя в консоли Computer Management (Network Access Permission – Allow access).

Если вы не используете сторонний DHCP сервер, который раздает vpn-клиентам IP адреса, необходимо в свойствах VPN сервера на вкладке IPv4 включить “Static address pool” и указать диапазон раздаваемых адресов.

Примечание. Раздаваемые сервером IP адреса в целях корректной маршрутизации не должны пересекаться с ip адресацией на стороне VPN клиента.

Осталось настроить VPN клиент и протестировать (как настроить vpn-клиент в Windows 8).

В этой заметке будет рассмотрен пример настройки 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  

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

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

Так как планируемая конфигурация получается многокомпонентной, то во избежание лишних сложностей, мы не будем пытаться настроить весь функционал сразу. Вместо этого мы сначала настроим базовый функционал 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) и настроен следующим образом:

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

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

Чтобы при такой конфигурации сетевых интерфейсов сервер был доступен из локальной сети, создадим в системе постоянный маршрут в локальную сеть через интерфейс 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее переключимся на закладку 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.

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

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

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

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

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

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

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

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

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

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

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

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

Описание правил фаервола необходимых для работы того или иного 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 

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

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

Сохраним изменения и попробуем выполнить подключение к 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 

В дальнейшем, для предоставления какому-либо пользователю домена доступа к 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. В дереве навигации оснастки выбираем пункты NPS >  Policies > Network Policies. Открываем контекстное меню (либо меню действий Action в главном меню) и выбираем пункт New.

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

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

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

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

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

Параметр 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

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

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

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

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

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

То есть, в данном примере, пользователь Петя Резинкин сможет подключиться в VPN, даже не смотря на то, что в свойствах его доменной учетной записи выбрана опция Deny access, при условии, что эта учетная запись включена в ранее указанную в политике доменную группу безопасности KOMKOM-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).

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

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

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

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

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

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

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

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

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

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

Если у нас более одного сервера 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

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

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

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.comKOMI Root CA" -ca.cert "C:TempCertificateRootCA.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:TempCertificateRootCA.cer"

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

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

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

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

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:TempRequestConfigVPNServer.inf" "C:TempRequestBinaryVPNServer.req"

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

***

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

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

certreq –submit –f -config "kom-ad01-ca01.holding.comKOMI Root CA" "C:TempRequestBinaryVPNServer.req"

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

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

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

certreq -retrieve -f -config "kom-ad01-ca01.holding.comKOMI Root CA" 31 "C:TempCertificateVPNServer.cer"

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

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

***

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

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

certreq –submit –f -config "kom-ad01-ca01.holding.comKOMI Root CA" "C:TempRequestBinaryVPNServer.req" "C:TempCertificateVPNServer.cer"

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

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

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

***

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

certreq -accept "C:TempCertificateVPNServer.cer"

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

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. В результате подобного запроса к ЦС, будет выдан соответствующий сертификат клиента, который после установки на клиентский компьютер должен говорить нам о наличии закрытого ключа.

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

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

set vSubject=%COMPUTERNAME%
set vCAPath="kom-ad01-ca01.holding.comKOMI 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 должен поставляться  следующий набор файлов:

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

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

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

В случае проблем с подключением, изучаем 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-кластера.

***

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

<

p align=»center»>***
Далее, с помощью PowerShell установим на оба VPN-сервера исполняемые компоненты NLB

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

<

p align=»center»>***

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

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

<

p align=»center»>***

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

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

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

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

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

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

На странице правил портов (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.

В общей сложности, в нашем примере балансировке в 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.);

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

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

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

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

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

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:

• STH — Installing Android-x86 on Hyper-V with Windows 8.1 in under 5 minutes
• Luisrato Blog — How to Install Android x86 4.4 RC2 on Hyper-V – Part 1: Install
• Luisrato Blog — How to Install Android x86 4.4 RC2 on Hyper-V – Part 2: Configuration, Screen resolution and Network

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

• TechNet Library — Step-by-Step Guide for Setting Up VPN-based Remote Access in a Test Lab
• TechNet Library — Configure a Remote Access Network Policy
• TechNet Library — IPsec Algorithms and Methods Supported in Windows
• TechNet Library — Certificate Requirements for PEAP and EAP
• TechNet Library — Certreq.exe Syntax
• Windows PKI blog — Firewall Rules for Active Directory Certificate Services
• MSDN Library — Сертификаты и проверка подлинности доступа к сети
• TechNet Library — Troubleshooting Network Load Balancing Clusters
• KB926179 — How to configure an L2TP/IPsec server behind a NAT-T device in Windows Vista and in Windows Server 2008 
• KB885407 — The default behavior of IPsec NAT traversal (NAT-T) is changed in Windows XP SP2      
  
• Routing and Remote Access Blog — Remote Access Design Guidelines – Part 3: Tunnel selection, Authentication, Authorization and Accounting
• Routing and Remote Access Blog —  Remote Access Deployment – Part 3: Configuring RADIUS Server for remote access
• Routing and Remote Access Blog — Troubleshooting common VPN related errors
• Routing and Remote Access Blog — What type of certificate to install on the VPN server

Если вы хотите установить и использовать VPN-сервер на базе семейства ОС Windows, то нужно понимать, что пользовательские версии для этой цели не подойдут. То есть «поднять» VPN-сервер на платформе Windows XP, Windows 7 или Windows 10 не получится. Для этой цели необходимо использовать серверные версии ОС: Windows Server 2003, Windows Server 2008 или же Windows 2012. Рассмотрим установку VPN-сервера на примере Windows 2012.

Как поднять vpn сервер на windows server 2012 r2

Для начала необходимо иметь сервер с лицензионной Windows 2012 и доступом к нему через удаленный рабочий стол – ведь хорошая практика размещать сервера в серверной стойке и соответственном помещении – потому и нужен удаленный доступ. Вводим в командную строку “mstsc”, и в открывшемся окне ip-адрес сервера:

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

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

В открывшемся Диспетчере серверов через меню «Управление» выбираем «Добавить роли и компоненты».

Потом три раза нажимаем кнопку «Далее» (предложит выбрать текущий сервер) и в открывшихся ролях сервера ставим галочку напротив «Удаленный доступ», добавляя компоненты нажатием кнопки:

Еще два раза жмем кнопку «Далее», пока не появится выбор служб ролей, где галочкой отмечаем как показано на скриншоте:

Устанавливаем выбранные компоненты нажатием на кнопку и дожидаемся окончания процесса:

windows 2012 r2: настройка vpn сервера

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

Выбирать нужно пункт «Развернуть только VPN» – DirectAccess нам не нужен. Откроется окно маршрутизации и удаленного доступа, где нужно указать текущий сервер и правой кнопкой мыши выбрать пункт, указанный на скриншоте:

Запустится мастер установки. Здесь один нюанс: если ваш сервер имеет только один сетевой интерфейс, в мастере нужно выбрать «Особая конфигурация»; если же более одного – то достаточно выбрать «Удаленный доступ» (VPN или модем):

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

Выбираем сетевой интерфейс сервера, который подключен к интернету (или же является uplink’ом для доступа в интернет):

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

В противном случае лучше настроить вручную, чтобы не было пересечения с уже существующими подсетями.

Отказываемся от использования RADIUS-сервера и завершаем настройку сервера:

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

• для протокола PPTP это tcp 1723 и протокол 47 GRE.

• для L2TP через IPSEC это tcp 1701 и udp 500

• для SSTP это tcp 443

Теперь вы можете из любого места, используя интернет, и зная внешний ip-адрес вашего VPN-сервера, подключиться по vpn в локальную сеть вашей организации. Например, для клиента с Windows 8 это делается с помощью создания нового сетевого подключения с указанными параметрами из «Центра управления сетями и общим доступом»

Данная статья представляет из себя ″Quick guide″ по настройке VPN сервера на базе Windows. Все описанные в статье действия производились на Windows Server 2012 R2, но инструкция подходит для любой более менее актуальной (на данный момент) серверной операционной системы Windows, начиная с Windows Server 2008 R2 и заканчивая Windows Server 2016.

Итак начнем. Первое, что нам необходимо сделать — это установить роль удаленного доступа. Для этого в оснастке Server Manager запускаем мастер добавления ролей и выбираем роль «Remote Access» со всеми дополнительными фичами.

И затем в списке сервисов для данной роли выбираем «DirectAccess and VPN (RAS)».

Кроме роли удаленного доступа и инструментов управления будут дополнительно установлены web-сервер IIS и внутренняя база данных Windows. Полный список устанавливаемых компонентов можно просмотреть в финальном окне мастера, перед подтверждением запуска установки.

Все то же самое, только гораздо быстрее, можно проделать с помощью PowerShell. Для этого надо открыть консоль и выполнить команду:

Install-WindowsFeature -Name Direct-Access-VPN -IncludeAllSubFeature -IncludeManagementTools

После установки роли нам потребуется включить и настроить службу с помощью оснастки «Routing and Remote Access». Для ее открытия жмем Win+R и вводим команду rrasmgmt.msc.

В оснастке выбираем имя сервера, жмем правой клавишей мыши и в открывшемся меню выбираем пункт «Configure and Enable Routing and Remote Access».

В окне мастера настройки выбираем пункт «Custom configuration».

И отмечаем сервис «VPN access».

В завершение настройки стартуем сервис удаленного доступа.

Сервис VPN установлен и включен, теперь необходимо сконфигурировать его нужным нам образом. Опять открываем меню и выбираем пункт «Properties».

Переходим на вкладку IPv4. Если у вас в сети нет DHCP сервера, то здесь надо задать диапазон IP адресов, которые будут получать клиенты при подключении к серверу.

Дополнительно на вкладке «Security» можно настроить параметры безопасности  — выбрать тип аутентификации, задать предварительный ключ (preshared key) для L2TP или выбрать сертификат для SSTP.

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

Во первых, необходимо выбрать пользователей, которые имеют разрешения подключаться к данному серверу. Для отдельно стоящего сервера настройка производится локально, в оснастке «Computer Management». Для запуска оснастки надо выполнить команду compmgmt.msc, после чего перейти в раздел «Local Users and Groups». Затем надо выбрать пользователя, открыть его свойства и на вкладке «Dial-In» отметить пункт «Allow access». Если же компьютер является членом домена Active Directory, то эти же настройки можно произвести из консоли «Active Directory Users and Computers».

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

На этом все. Теперь VPN сервер настроен и к нему можно подключаться.

First published on TechNet on May 19, 2014

[This post comes to us courtesy of Md. Sabir Chandwale and Rituraj Choudhary from Global Business Support]

In this post we will discuss about Virtual Private Network feature on Windows Server 2012 R2 Essentials.

Virtual Private Network can be straightforwardly installed and configured on a Windows Server 2012 R2 Essentials by running the

Set up Anywhere Access

wizard and selecting

Virtual Private Network (VPN)

option on the following screen.

If you want to know about Remote Web Access, or run through the sequential screens of Anywhere Access wizard, please visit

this post

.

When you choose to enable VPN using this wizard, the following roles/features get installed on the Essentials Server:

Remote Access, DirectAccess and VPN (RAS), IP and Domain Restrictions, IIS Management Scripts and Tools, Network Policy and Access Services Tools, and Windows Internal Database.

You can also enable these roles/features from the Server Manager or PowerShell command-lets, however on Windows Server Essentials we recommend enabling it using the

Set up Anywhere Access

wizard.

It’s noteworthy that Windows Server 2012 R2 Essentials allows client machines to join their server without having to be inside the company network using a feature called

Remote Domain Join

. So, if VPN is enabled on Server Essentials, you may connect a remote client to the local network via VPN, run the Connect wizard from http://

<servername>

/connect or http://<

domainname

>.remotewebaccess.com/connect URL and

join

the remote client to the server. The process is very simple and straightforward.

As a prologue to discuss some common issues with VPN on Windows Server 2012 R2 Essentials, let us first glance through the default Routing and Remote Access (RRAS) settings. You may also find the specifics about these settings on

TechNet

.

Note:

Server Essentials automatically manages the routing for VPN, and therefore Routing and Remote Access (RRAS) UI is hidden on the server to prevent tampering of RRAS settings. As a result, to view, change or troubleshoot the Remote Access settings, you need to install

Remote Access GUI and Command-Line Tools

using

Server Manager

or the following PowerShell command:

Add-WindowsFeature RSAT-RemoteAccess-Mgmt

This feature enables

Routing and Remote Access

console and respective command-line tools to manage VPN and DirectAccess. Note that

this role may not be required on the server unless you need to change the settings for VPN or DirectAccess.

Default Settings of VPN on Windows Server 2012 R2 Essentials

To check the default settings for the VPN, open Routing and Remote Access Manager. Right click


server name


, and select

Properties

.

On the

General

tab, IPv4 must be enabled:

The

Security

tab consists of the

Authentication Methods…

and

SSL Certificate Binding

:

The

Authentication Methods

should have

Extensible authentication protocol (EAP)

and

Microsoft encrypted authentication version 2 (MS-CHAP v2)

enabled. You can confirm it by clicking the

Authentication Methods…

button on the

Security

tab.

The

SSL Certificate Binding

section on the

Security

tab displays the certificate active for VPN. This also indicates that we enable VPN on SSL and that you do not have to allow any port other than port 443.

Let’s move on to the

IPv4

tab. By default the VPN clients are set to receive IP from DHCP, but you may require to change it to a Static address pool for troubleshooting purposes.

On the

IPv6

tab, the options

Enable IPv6 Forwarding

and

Enable Default Route Advertisement

are selected by default.

The

IKEv2

tab consists of the default options to control the IKEv2 client connections and Security Association expiration.

The

PPP

tab contains the settings for Point-to-Point protocol and are as follows:

The

Logging

tab on the server properties page contains the level of logging enabled for Routing and Remote Access.

To enable additional logging for the Routing and Remote Access, select the option

Log additional Routing and Remote Access information

. Once this option is selected additional log files are created in the

%windir%Tracing

directory that provide deeper insight to troubleshoot RRAS issues. Make sure to disable the additional logging once the troubleshooting is complete.

You may also gather and modify information for Remote Access from an elevated Windows PowerShell terminal. Here are some common commands:

Command	Purpose
Get-Command -Module RemoteAccess	Displays a list of commands available with RemoteAccess module
Get-RemoteAccess	Displays the configuration of VPN and DirectAccess (DA)
Get-VpnAuthProtocol	Displays authentication protocols and parameters set on the VPN
Get-VPNServerConfiguration	Displays VPN server properties

Here is a sample output:

You can look at the help file of each of these commands for a detailed description. Better yet, you can use the following command to insert the help contents of each of these commands for the module RemoteAccess to a text file as:

$(foreach ($command in (Get-Command -Module RemoteAccess)) {Get-Help $command.Name} ) | Out-File HELP.txt

We will discuss some

common issues with VPN

on another post in future.

Настройка VPN на виртуальной машине ничем принципиально не отличается от настройки на обычном сервере. Тестирование настройки производилось на виртуальной машине Windows Server 2012 R2.

• Перед настройкой необходимо установить роль сервера удаленного доступа. Для этого запускаем Server Manager и выбираем «Add Roles and Features». Из списка ролей выбираем роль «Remote Access», соглашаемся с установкой дополнительных компонентов.

  

• Далее из списка компонентов роли выбираем «Direct Access and VPN (RAS)«.

  

• В результате кроме самой роли будут установлены Web-сервер IIS и внутренняя база Windows, а также оснастки управления и модуль PowerShell. Просмотреть полный список устанавливаемых компонентов можно перед установкой.

  

• После установки роли надо открыть оснастку «Routing and Remote Access» командой rrasmgmt.msc.

  

• В оснастке встаем на имя сервера правой клавишей мыши и выбираем пункт «Configure and Enable Routing and Remote Access».

  

• В мастере выбираем пункт «Custom configuration».

  

• Затем отмечаем чекбокс «VPN access».

  

• Далее жмем Next -> Finish и стартуем сервис удаленного доступа.

  

• Сервис запущен и работает, его остается настроить. Для этого в контекстном меню выбираем «Properties» и переходим к свойствам сервера.

  

• На вкладке IPV4 необходимо выбрать, каким образом клиент будет получать IP адрес. Можно оставить DHCP (если есть DHCP сервер), либо задать статический пул адресов. Раздаваемые сервером IP адреса в целях корректной маршрутизации не должны пересекаться с адресами на стороне VPN клиента.

  

• На вкладке «Security» настраиваются параметры безопасности для VPN подключений. Здесь можно указать ключ для L2TP или сертификат для SSTP, а также выбрать способ аутентификации и механизмы шифрования.

  

• Затем необходимо в свойствах пользователя разрешить подключение. Для локальной учетной записи надо открыть оснастку «Local Users and Groups» командой lusrmgr.msc и в свойствах нужного пользователя на вкладке Dial-In в поле «Network Access Permission» установить переключатель в положение «Allow access». Для доменного пользователя – то же самое, но в оснастке «Active Directory Users and Computers».

  

• И в завершение надо проверить, включены ли необходимые правила на файерволле.

  

• На этом настройка VPN-сервера завершена, можно подключаться. Для обеспечения безопасности рекомендуется подключаться по L2TP или SSTP.

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

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

Меня зовут Севостьянов Антон и в данном видео давайте рассмотрим процесс настройки VPN сервера на базе Windows Server 2016. И делать мы это будем на арендованном виртуальном сервере от компании NeoServer.

Несмотря на то, что я буду выполнять все действия в Windows Server 2016, аналогичным образом все можно настроить на 2008 и 2012 серверах. 

Как я и говорил, весь процесс настройки у нас будет проходить на арендованном виртуальном сервере. Поэтому первым делом нам нужно создать виртуальный сервер, для этого переходим на сайт neoserver.ru Войти Виртуальные сервера.

Если вы никогда не работали с сервисом NeoServer, то на эту тему у меня есть более подробное видео «Настройка виртуального VPS VDS сервера Windows», в котором я рассказываю все от процесса регистрации до конфигурации сервера.

Соберем сервер, у меня он будет состоять из следующих характеристик: Windows Server 2016 ru, 2Гб ОЗУ, все остальное по умолчанию.

Я буду работать через RDP подключение, так как для меня этот способ наиболее удобен.

Пуск Диспетчер серверов Управление Добавить роли и компоненты Далее Далее Далее Удаленный доступ Далее Далее DirectAccesss и VPN Добавить компоненты Далее Далее Установить.

Настройка VPN сервера

Мы можем запустить процесс настройки либо сразу из окна мастера добавления ролей и компонентов, либо через оснастку «Маршрутизация и удаленный доступ» (Средства Маршрутизация и удаленный доступ Выбираем наш сервер ПКМ Настроить и включить маршрутизацию и удаленный доступ Далее Особая конфигурация Далее Доступ к виртуальной частной сети (VPN) Далее Готово Запустить службу)

Отлично, службу мы запустили, остается выполнить более тонкие настройки (Имя сервера Свойства IPv4 Сервер может назначать адреса используя статический пул адресов, так как у нас в сети нет DHCP, то выбираем эту настройку, если у вас DHCP есть, то оставляем, по умолчанию 192.168.0.10-192.168.0.20 Безопасность Разрешить пользовательские политики Вводим ключ безопасности Применить Перезапускаем службу Маршрутизации и удаленного доступа Диспетчер задач Службы Маршрутизация и удаленный доступ Перезапустить)

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

(Пуск Управление компьютером Пользователи Администратор Входящие звонки Разрешить доступ)

Настраиваем VPN подключение на клиентском компьютере (Центр управления сетями и общим доступом Создание и настройка нового подключения Подключение к рабочему месту Использовать мое подключение к интернету (VPN) IP адрес Свойства подключения Безопасность Протокол L2TP Дополнительные параметры Для проверки подлинности использовать общей ключ вводим ключ Шифрование данных Обязательное, отключить если нет шифрования)

Чтобы на клиенте не пропадал интернет при подключении к VPN, переходим в (Свойства сетевого VPN подключения Сеть IPv4 Свойства Дополнительно Использовать основной шлюз в удаленной сети Убираем галочку ОК)

Подключаемся к виртуальной сети VPN

Выбираем сетевое подключение Подключиться Вводим имя пользователи и пароль Все

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

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

Список временных меток:

• Создание виртуального сервера VPS/VDS на сервисе NeoServer
• Подключение к виртуальному серверу 
• Установка роли VPN сервера
• Настройка VPN сервера
• Настройка доступа к VPN серверу
• Создание VPN соединения на клиентском компьютере
• Проверка работы сети через VPN подключение

VPN provides secure access to organizations’ internal data and applications to clients and devices that are using the Internet.

To properly implement and support a VPN environment within your organization, you must understand how to select a suitable tunnelling protocol, configure VPN authentication, and configure the server role to support your chosen configuration.

As in previous versions of Windows Server, there are two types of VPN connection available in Windows Server 2012 R2 :
• Remote access
• Site-to-site

Remote Access VPN Connections

Remote access VPN connections enable your users who are working offsite, such as at home, at a customer site, or from a public wireless access point, to access a server on your organization’s private network by using the infrastructure that a public network, such as the Internet, provides.

Site-to-Site VPN Connections

Site-to-site VPN connections, which are also known as router-to-router VPN connections, enable your organization to establish routed connections between separate offices or with other organizations over a public network while helping to maintain secure communications. A routed VPN connection across the Internet logically operates as a dedicated wide area network (WAN) link. When networks connect over the Internet, a router forwards packets to another router across a VPN connection. To the routers, the VPN
connection operates as a data-link layer link.

So in my post this time, lets go through a simple step how you can implement VPN in your infrastructure and for this demo purposes, i will continue using the same VM that i had for my DirectAccess implementation.

Please do refer to my previous DirectAccess post on what kind of VM’s that i use to implement this VPN.

Step by Step : Implementing Basic DirectAccess in Windows Server 2012 R2

For more information about VPN / Remote Access, please do log in to : http://technet.microsoft.com/en-us/library/dn383589.aspx

Lets get started with our VPN configuration.

1st, lets review some of the Routing & Remote Access settings and do dome some changes on the RRAS.

1 – Log in to LON-RTR server, open Server Manager, click Tools and then click Remote Access Management Console…

2 – In the Remote Access Management Console, click DirectAccess and VPN, and from the Actions pane, under the VPN section, click Enable VPN…

3 – In the Enable VPN box, click OK…

4 – Verify that the configuration was applied successfully and then click Close…

5 – Next, switch to Server Manager, click Tools and then click Routing and Remote Access…

6 – Next, in the Routing and Remote Access console, expand LON-RTR, right-click ports, click Properties…

7 – Verify that 128 ports exist for SSTP, IKEv2, PPTP, and L2TP, then double-click WAN Miniport (SSTP)…

8 – In the Maximum ports box, type 5, and then click OK…

9 – In the Routing and Remote Access message box, click Yes…

10 – Repeat the same step no.8 & 9 for IKEv2, PPTP, and L2TP,  then click OK…

11 – Next, right-click LON-RTR (local), click Properties…

12 – In the General tab, verify that IPv4 Remote access server is selected…

13 – Next, click Security, and then verify that Certificate 131.107.0.10 is selected for SSL Certificate Binding, and then click Authentication Methods…

14 – In the Authentication Methods box, verify that EAP is selected as the authentication protocol and then click OK…

15 – Next, click the IPv4 tab, and then verify that the VPN server is configured to assign IPv4 addressing by using Dynamic Host Configuration Protocol (DHCP), click OK to close the Properties interface…

2nd, before we proceed, please make sure that you verify the certificate requirements for IKEv2 and SSTP in LON-RTR Server…

1 – In LON-RTR Server, open MMC, click File and then click Add/Remove Snap-in…

2 – In the Add/Remove Snap-in interface, click Certificates, click Add, select Computer account, and then click Next…

3 – Click Local computer and then click Finish…

4 – To close the Add or Remove Snap-in, click OK…

5 – Next, expand Certificates (Local Computer), expand Personal, and then click Certificates.

— Notice that certificate 131.107.0.10, this certificate is for Server Authentication (this is required for Secure Socket Tunneling Protocol (SSTP) and Internet Key Exchange version 2 (IKEv2) VPN connectivity).

3rd, its time now for us to configure the Remote Access Server…

1 – Still in the  LON-RTR server, open Server Manager, on the Tools menu, click Network Policy Server. ..

2 – In the Network Policy Server console, expand Policies, and then click Network Policies.

– Right-click the policy at the top & bottom of the list, and then click Disable…

3 – Next, in the navigation pane, right-click Network Policies, and then click New…

4 – In the New Network Policy wizard, in the Policy name box, type Adatum VPN Policy, then in the Type of network access server list, click Remote Access Server(VPN-Dial up), and then click Next…

5 – On the Specify Conditions interface, click Add…

6 – In the Select condition interface, click Windows Groups, and then click Add…

7 – In the Windows Groups interface, click Add Groups…

8 – Type IT, and then click OK (you can choose your own group that you prefer)…

9 – In the Windows Groups interface, verify that ADATUMIT is listed, and then click OK…

10 – In the Specify Conditions interface, click Next…

11 – In the Specify Access Permission interface, click Access granted, and then click Next…

12 – On the Configure Authentication Methods interface, make sure that you clear the Microsoft Encrypted Authentication (MSCHAP)
check box, and then to add EAP Types, click Add…

13 – On the Add EAP Types interface, select Microsoft Secured password (EAP-MSCHAP v2), and then click OK…

14 – repeat the same step above but this time choose Microsoft: Smart Card or other certificate, then click Next…

15 – On the Configure Constraints interface, click Next…

16 – On the Configure Settings interface, click Next…

17 – On the Completing New Network Policy interface, click Finish…

Till this step, we’ve successful modified the remote access server configuration to provide VPN connectivity.

4th, so now lets verify our VPN connectivity in our Windows 8.1 client…

1 – On the Windows 8.1 client PC, open Network and Sharing Center, then click Set up a new connection or network…

2 – Next, on the Choose a connection option interface, click Connect to a workplace, and then click Next…

3 – On the How do you want to connect? interface, click Use my Internet connection (VPN)…

4 – On the Connect to a Workplace interface, click I’ll set up an Internet connection later…

5 – In the Internet address box, type 131.107.0.10 (LON-RTR IP Address)…

— In the Destination name box, type HQ VPN, select Allow other people to use this connection checkbox, and then click Create…

6 – Next, right-click HQ VPN connection and select Properties…

7 – In the HQ VPN Properties, click the Security tab, select Allow these protocols, ensure that Microsoft CHAP version 2 (MSCHAP
v2) is selected, and then click OK…

8 – Next, right click HQ VPN, and then click Connect…

9 – In the Network list, under HQ VPN, click connect…

10 – In the sign-in dialog box, type the domain user from IT department and then click OK…

11 – Verify that you are connected to Adatum by using a PPTP connection, right click HQ VPN and then click Status…

Orait, that all for now, we’ve connected to HQ VPN successfully…

box, type Pa$$w0rd, and then click OK.