Windows server ipsec rules — Ваш верный помощник с OS Windows

Настройка и подключение IPSec в Windows

Настройка IPSec на Windows включает в себя создание правил безопасности и фильтров для защиты сетевого трафика. Ниже — пошаговое руководство.

Включение службы IPSec

Перед настройкой убедитесь, что служба IPSec Policy Agent запущена:

Нажмите Win + R, введите services.msc и нажмите Enter.
Найдите IPsec Policy Agent.
Если она не работает, нажмите ПКМ → Свойства.
Установите Тип запуска: Автоматически, затем нажмите Запустить.

Настройка политики IPSec через «Локальную политику безопасности»

Нажмите Win + R, введите secpol.msc, нажмите Enter.
Перейдите в Политики IP-безопасности в локальном компьютере.
В правом окне нажмите Создать политику IP-безопасности → Далее.
Укажите имя политики (например, «IPSec VPN»), снимите флажок Активировать правило по умолчанию, нажмите Далее.
Нажмите Добавить, чтобы создать правило.
Транспортный или туннельный режим:
- Если IPSec для защищенной локальной сети – выберите Транспортный режим.
- Если IPSec для VPN – выберите Туннельный режим и укажите IP-адрес удаленного шлюза.
Фильтры трафика:
- Нажмите Добавить, укажите источник и назначение (IP-адреса или подсети).
- Выберите протокол (TCP, UDP или весь трафик).
Методы аутентификации:
- Предварительно разделенный ключ (PSK) – задайте общий секретный ключ.
- Сертификат – используйте PKI.
Алгоритмы шифрования и аутентификации:
- Выберите SHA-256 или выше (аутентификация).
- Выберите AES-128/256 или 3DES (шифрование).
Сохраните политику и примените её.

Применение политики IPSec

В окне Политики IP-безопасности найдите созданную политику.
Щелкните по ней ПКМ → Назначить.
Перезапустите службу IPsec Policy Agent.

Проверка работы IPSec

Откройте Командную строку (Win + R → cmd).
Выполните:
Для диагностики используйте:

После выполнения этих шагов IPSec должен быть настроен и защищать соединения. Если настраиваете VPN, не забудьте проверить параметры маршрутизации и NAT.

Подключение к серверу через IPSec-клиент в Windows

Если ваш сервер использует IPSec VPN, например L2TP/IPSec, IKEv2 или другой IPSec-режим, вам нужно настроить VPN-подключение в Windows.

Перед началом убедитесь, что служба IPsec Policy Agent работает:

Нажмите Win + R, введите services.msc и нажмите Enter.
Найдите IPsec Policy Agent.
Если служба отключена, нажмите ПКМ → Свойства, установите Тип запуска: Автоматически, затем нажмите Запустить.

Настройка VPN-подключения с IPSec (L2TP/IPSec)

Если сервер использует L2TP/IPSec, настройка выполняется через параметры Windows:

Шаг 1: Создание VPN-подключения

Откройте Параметры Windows (Win + I) → Сеть и Интернет → VPN.
Нажмите Добавить VPN-подключение.
Заполните параметры:
- Поставщик VPN → Встроенный в Windows
- Имя подключения → Любое название (например, «VPN IPSec»)
- Имя сервера или адрес → Введите IP-адрес или доменное имя сервера
- Тип VPN → L2TP/IPsec с предварительно заданным ключом (или «L2TP/IPsec с сертификатом», если используется PKI)
- Ключ предварительной аутентификации → Введите общий секретный ключ (PSK)
- Тип данных для входа → Имя пользователя и пароль
- Введите имя пользователя и пароль VPN, если они нужны.
Нажмите Сохранить.

Шаг 2: Настройка параметров безопасности

В окне Сеть и Интернет → VPN выберите созданное подключение → Дополнительные параметры → Изменить параметры адаптера.
Найдите свое VPN-подключение (VPN IPSec), нажмите ПКМ → Свойства.
Перейдите на вкладку Безопасность:
- Тип VPN → L2TP/IPSec
- Нажмите Дополнительно, введите предварительный ключ (PSK).
- Шифрование данных → Требуется (шифрованное соединение).
- Аутентификация → Выберите MS-CHAP v2.
Перейдите на вкладку Сеть:
- Убедитесь, что включен IP версии 4 (TCP/IPv4).
- Нажмите Свойства → Дополнительно, отключите Использовать основной шлюз в удаленной сети, если не хотите, чтобы весь трафик шел через VPN.
Нажмите ОК.

Подключение к серверу

В Параметры → Сеть и Интернет → VPN выберите созданное подключение.
Нажмите Подключиться.
Если требуется, введите логин и пароль.

Проверка подключения

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

Откройте Командную строку (Win + R → cmd) и выполните:
Должен появиться новый VPN-адаптер с выделенным IP.
Для проверки IPSec выполните:
Попробуйте пропинговать сервер:

Дополнительно: Подключение через IKEv2/IPSec

Если сервер поддерживает IKEv2/IPSec, выполните те же шаги, но в поле Тип VPN выберите IKEv2.

Если VPN не подключается, проверьте:

Открыты ли порты UDP 500, UDP 4500 на сервере и маршрутизаторе.
Запущены ли службы IKE и AuthIP IPsec Keying Modules (services.msc).
Верны ли учетные данные и предварительный ключ.

После успешного подключения ваш трафик будет защищен IPSec-шифрованием. 🚀

Служба «IPsec Policy Agent» в Windows

Что делает служба IPsec Policy Agent?

Служба IPsec Policy Agent управляет политиками безопасности для протокола IPSec (Internet Protocol Security). Она отвечает за применение и поддержку правил шифрования, аутентификации и целостности данных для защищенного обмена информацией между устройствами в сети.

Основные функции службы:

✅ Загружает политики IPSec из локального реестра или Active Directory.
✅ Управляет ключами шифрования и аутентификации (IKEv1/IKEv2).
✅ Контролирует фильтрацию трафика по IP, протоколам и портам.
✅ Инициирует и поддерживает безопасные соединения по IPSec.

Для чего работает IPsec Policy Agent?

IPSec Policy Agent обеспечивает безопасность сетевого трафика, используя политики шифрования и проверки подлинности. Он нужен для:

🔹 Безопасного VPN-подключения (L2TP/IPSec, IKEv2).
🔹 Шифрования данных при передаче между компьютерами.
🔹 Фильтрации трафика (например, запрет трафика без шифрования).
🔹 Аутентификации устройств перед установкой соединения.
🔹 Защиты от атак «человек посередине» (MitM), изменяющих передаваемые данные.

Архитектура службы IPsec Policy Agent

IPSec в Windows основан на двух уровнях:
1️⃣ Политики безопасности (Security Policies) → Определяют правила шифрования, фильтрации, аутентификации.
2️⃣ Механизм шифрования (Security Associations — SA) → Реализует установленные политики и защищает данные.

Компоненты службы:

🔹 IPSec Policy Agent – отвечает за загрузку и применение политик безопасности.
🔹 IKE (Internet Key Exchange) – устанавливает и управляет ключами шифрования.
🔹 Windows Filtering Platform (WFP) – фильтрует сетевой трафик и применяет IPSec.
🔹 Kernel Mode IPSec Driver – обрабатывает пакеты на уровне ядра, обеспечивая шифрование.

Схема работы:

1️⃣ Клиент или сервер загружает политики IPSec через IPsec Policy Agent.
2️⃣ При установке соединения система проверяет, подпадает ли трафик под IPSec-правила.
3️⃣ Если политика требует защиты, инициируется IKE для обмена ключами.
4️⃣ Создается Security Association (SA) – зашифрованное соединение.
5️⃣ Windows WFP передает трафик через IPSec Driver, где он шифруется или дешифруется.

Как управлять службой IPsec Policy Agent?

📌 Проверка состояния службы powershell:

📌 Запуск службы:

📌 Остановка службы:

📌 Автозапуск службы при старте системы:

Когда нужно отключать службу IPsec Policy Agent?

🚫 Отключать службу НЕ рекомендуется, если:
❌ Вы используете VPN с IPSec.
❌ В сети есть IPSec-фильтрация или шифрование трафика.
❌ Компьютер работает в доменной сети с Group Policy для IPSec.

✅ Отключить можно, если вы не используете VPN/IPSec, и система работает в доверенной локальной сети.

IPsec Policy Agent – это ключевая служба безопасности в Windows, управляющая политиками IPSec для защиты трафика. Она обеспечивает аутентификацию, шифрование и контроль доступа на уровне сети. Если вам нужен VPN, защита данных или фильтрация трафика, служба должна быть включена. 🚀

Источник

Windows-Server-2022-IPsec-RDP-Security-Guide

Step-by-step guide to configure IPsec Policies and secure Remote Desktop (RDP) on Windows Server. Includes IPsec setup, custom RDP port configuration, and best security practices.

Configuring IPsec Policies Between Windows Server 2022 and Windows 11

This guide provides a step-by-step process to configure IP Security (IPsec) Policies for secure communication between a Windows Server 2022 machine and a Windows 11 client. IPsec policies allow granular control over encrypted communication.

Step 1: Configure IPsec Policy on Windows Server 2022
Step 2: Import the IPsec Policy on Windows 11
Step 3: Assign Policies
Verification
How to Change the RDP Port on Windows Server or Windows 11
Security Tips for RDP
Notes

Step 1: Configure IPsec Policy on Windows Server 2022

1. Open Group Policy Management or Local Security Policy

Press Win + R to open the Run dialog.
Type secpol.msc and press Enter.

This opens the Local Security Policy.

2. Navigate to IP Security Policies

Go to: IP Security Policies on Local Computer.

3. Create a New IP Security Policy

Right-click IP Security Policies on Local Computer > Select Create IP Security Policy.

Follow the wizard:
- Provide a name for the policy.

3. 1. Authentication Method:

Choose either Pre-shared key (less secure) or Certificates (recommended for production).
- Action:
  - choose Certificate from this CA, check Enable certificate to account mapping and then click on Browse.

In the pop-pup that is going to open, just click on OK.

Ensure Activate the default response rule is checked.

4. Manage IP Filter Lists and Filter Actions

After creating the policy:
- Right-click the new policy and select Manage IP filter lists and filter actions.

5. Create IP Filters

Define the IP addresses for both machines:
- Source: IP of Windows Server 2022.
- Destination: IP of Windows 11.

Apply the filters to the policy.

Action:
— Set to Require Secure Communication or Encrypt.

6. Set Authentication and Action(Optional if not set in 3. 1)

Right-click the configured filter and set the following:
- Authentication Method:
  - Choose either Pre-shared key (less secure) or Certificates (recommended for production).
Action:
- Set to Require Secure Communication or Encrypt.

Step 2: Import the IPsec Policy on Windows 11

1. Open Local Security Policy

Press Win + R, type secpol.msc, and press Enter.

2. Import or Recreate the Policy

Navigate to IP Security Policies.
Right-click IP Security Policies:
- Import the policy exported from the Windows Server.
- Alternatively, recreate the policy using the same steps outlined in Step 1.

Step 3: Assign Policies

Assign Policies on Both Machines

On Windows Server 2022 and Windows 11:
- Right-click the IPsec policy and select Assign.

Verify Policy Assignment

Open Command Prompt as Administrator.
Run the following command to verify the active IPsec policy:
```
netsh ipsec static show policy all 
```

Verification

To confirm that IPsec is securing communication between the machines, follow these steps:

Open Command Prompt on both machines as Administrator.
Run the following command to view active IPsec connections:
```
netsh ipsec dynamic show all
```

Ensure that IPsec-secured packets are being transmitted.

How to Change the RDP Port on Windows Server or Windows 11

Key Points:

Port Type: TCP (default).
Default RDP Port: 3389.
Customizing the Port: You can change this port for security reasons (obscurity) by modifying the registry.

Steps to Change the RDP Port

Open the Registry Editor:
- Press Win + R, type regedit, and press Enter.

Navigate to the Registry Key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Find and Modify the Port:
- Locate the PortNumber (DWORD) value.
- Double-click PortNumber.
- Select Decimal and enter the new port number (e.g., 1443).

Restart the RDP Service or Reboot the Machine:
Run the following command in Command Prompt as Administrator:
1. Stop the service

Start the service

Update Firewall Settings:
- In Windows Firewall, create a new inbound rule to allow traffic through the custom RDP port.

Accessing RDP with a Custom Port:
- When connecting to the server using the Remote Desktop Client, specify the custom port:
```
<IP Address>:<Port>
Your username  
```

Provide your password and follow the wizard.

Congratulation, you now successfully login.

Security Tips for RDP

Change the Default Port:
- Changing from 3389 helps reduce exposure to automated attacks.
Enable Network Level Authentication (NLA):
- NLA ensures only authenticated users can establish an RDP session.
Restrict RDP Access:
- Use Windows Firewall to restrict RDP access to specific IP addresses.
Implement Multi-Factor Authentication (MFA):
- MFA adds an additional layer of security for remote access.
Monitor Logs:
- Regularly check logs for suspicious login attempts or failed RDP connections.

Notes

Pre-shared Key:
- Easy to configure but less secure. Use certificates in production environments.
IPsec Rule Matching:
- The rules must match exactly on both machines for communication to work.
Firewall Troubleshooting:
- If IPsec fails to work, temporarily disable the firewall to isolate issues.

Conclusion

By following this guide:

You can configure IPsec policies for secure communication.
Learn how to customize the RDP port to enhance security.

If you encounter any issues, open an issue in this repository.

Источник

Configuring connection security rules

After you configure the IPsec defaults for the computer, you can
then create connection security rules. As explained at the start of
this lesson, a connection security rule is a set of criteria that
specifies how IPsec will be used to secure traffic between the local
computer and other computers on the network. They can be used to
specify whether a network connection between two computers must first
be authenticated before data can be exchanged between them and to make
sure any data exchanged between the computers is encrypted to protect
against eavesdropping or modification.

Types of connection security rules

Connection security rules can be created using the New
Connection Security Rule Wizard. As Figure 7 shows, Windows
Firewall with Advanced Security supports five types of connection
security rules:

Isolation This type of
connection security rule can be used to isolate computers from
other computers. For example, you can use isolation rules to
protect computers that are joined to your domain from computers
that are outside your domain.
Authentication Exemption
This type of connection security rule can be used to specify
computers that should be exempted from being required to
authenticate, regardless of any other connection security rules
that have been configured. For example, you can use
authentication exemption rules to allow access to domain
controllers and other infrastructure servers that the computer
needs to communicate with before authentication can be
performed.
Server-to-Server This type
of connection security rule can be used to protect
communications between two computers, two groups of computers,
two subnets, or some combination of these, such as between a
computer and a subnet. For example, you can use server-to-server
rules to protect communications between a database server and a
front-end web server.
Tunnel This type of
connection security rule can be used to protect communications
between two computers using IPsec tunnel mode instead of IPsec
transport mode. For example, you can use tunnel rules to specify
a gateway computer that routes traffic to a private
network.
Custom This type of
connection security rule can be used to configure custom rules
using criteria from other rule types except tunnel rules.

Figure 7. Types of connection security rules.

To create new connection security rules using the New
Connection Security Rule Wizard, right-click on the Connection
Security Rules node in the Windows Firewall with Advanced Security
snap-in, select New Rule, and follow the steps of the wizard. The
sections that follow explain more regarding the steps involved in
creating each of these different types of connection security
rules.

Creating an isolation rule

The following steps can be used to create a new isolation rule
using the Windows Firewall with Advanced Security snap-in:

Launch the New Connection Security Rule Wizard, and choose
Isolation on the Rule Type page.
On the Requirements page, specify whether to request or
require authentication for inbound connections, outbound
connections, or both by selecting one of the following
options:
- Request Authentication For
  Inbound And Outbound Connections This option is
  typically used in low-security environments or where
  computers are unable to use the IPsec authentication methods
  available with Windows Firewall with Advanced Security. You
  can also use it for computers in the boundary zone in a
  server and in a domain isolation scenario.
- Require Authentication For
  Inbound Connections And Request Authentication For Outbound
  Connections This option is typically used in
  environments where computers are able use the IPsec
  authentication methods available with Windows Firewall with
  Advanced Security. You can also use it for computers in the
  main isolation zone in a server and in a domain isolation
  scenario.
- Require Authentication For
  Inbound And Outbound Connections This option is
  typically used in environments where network traffic must be
  controlled and secured. You can also use it for computers in
  the main isolation zone in a server and in a domain
  isolation scenario.
On the Authentication Method page, specify whether to use
the default authentication methods or to specify a different
method or list of methods:
On the Profile page, select which firewall profiles the
new rule should apply to. By default, new connection security
rules apply to all three profiles (domain, private, and
public).
On the Name page, specify a name and optional description
for the new rule.

Note

Enabled by default

When you create a new connection security rule using the New
Connection Security Rule Wizard, the new rule is automatically
enabled by default.

Источник

В этой заметке будет рассмотрен пример настройки 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 (KOM\KOM-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, при условии, что эта учетная запись включена в ранее указанную в политике доменную группу безопасности 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).

На шаге мастера 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.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 computer

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

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"

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

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.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 должен поставляться следующий набор файлов:

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

Источник

In this article I’d like to show how administrators can use IPSec to protect the most valuable “assets” in their networks – for example, servers that runs HR or financial databases. Lots of articles on msdn/technet offer one of the following methods to secure the traffic – domain isolation or/and server isolation. The first one is supposed to restrict traffic flow only to the domain members while the latter is often regarded as the extra security layer to the domain isolation that further restricts access to some host(s) only to member of certain computer or user groups. My point is that sometimes we may deploy some form of server isolation by not restricting already established security policies (domain isolation) with the additional computer/user checking but simply by applying the connection security rules to the respective organizational units (OUs).

Consider the following task: only specific clients (say HR department users) should have access to the host with HR database. The easiest way to achieve this is to create a server GPO with the connection security rules which would require IPSec protection for all inbound traffic (and only request the protection for outbound traffic) and a client GPO which would request protection for both inbound and outbound traffic. Applying the server GPO to the OU containing the server computer account (or accounts) and the client GPO to the OU with the needed client computer accounts will result in the required server isolation – in this case grouping the server and client computer accounts into specific OUs will serve the same purpose as resticting access based on the computer/use group membership.

Suppose the server that hosts the database with sensitive information is SQL1 –

so the first step is to create a new OU – Devices\SECURE – and move the server into it:

SecureSERVER is a new GPO for which we’ll create the new connection security rule that will require authentication for the inbound connections.

Now let’s create the new rule:

On the Rule Type page choose the type of the rule – Isolation and Require authentication for inbound connections and request authentication for outbound connections on the Requirements page:

Since the new rule will use Kerberos authentication there’s no need to choose anything except Domain here.

Again, since the target for this policy (and the rule) is defined by applying this GPO only to the specific OU, I won’t configure any endpoints for this rule.

After running gpupdate /force on SQL1:

The server-side policy is created – the next step is to create a GPO for users that should be able to connect to the SQL1 and create the client GPO – I’ll create the SecureCONNECTIONS GPO and link it to the Tier2\Devices OU. It means any (client) computer which has its computer account placed in this GPO will be allowed to access the secure server (SQL1). In the production network it may be an OU at the deeper level but currently there’s only one client computer account in my test network so I’ll keep using this OU.

The new client connection security rule differs from the server one just in the Requirements tab (not speaking of the Name tab):

Clients should not require inbound connections to be authenticated – they just must be able to initiate a secure outbound connections (servers that require inbound authentication will respond with ipsec while all other hosts will reply as usually), so we select the first option here:

Here’s the client rule:

After running gpupdate /force on Client1:

Now let’s test it: computers in the Tier2\Devices (currently only Client1) should have access to SQL1 while any computers that are not in the Tier2\Devices OU should NOT. All connection attempts will be traced in Network Monitor.

Test 1: Connecting to SQL1 from Tier1\Devices\SQL2

1.1 Pinging SQL1 (the ip of SQL2 – 10.1.1.23):

The result: ping failed as expected – please note the trace does not contain the SQL1’s authentication requests (AuthIP).

2.2 Connecting to SQL1 in SSMS

The result: the connection failed as expected and the trace does contain the SQL1’s authentication requests (AuthIP) coming from SQL1 to SQL2. As SQL2 does not have any connection security rules applied it can’t respond to the authentication requests that result in the failed connection.

Test 2: Connecting to SQL1 from Tier2\Devices\Client1

2.1 Pinging SQL1

Please note the first packet’s response time – it’s due to the ipsec negotiation phase:

The trace:

The result: ping succeeds as expected. Please note that the host with the connection security rule applied makes the second connection using AuthIP protocol right after the first unsuccessful echo request. After successful ipsec authentication we can see icmp request/reply packets.

2.2 Connecting to SQL1 in SSMS

The trace:

The result: connection succeeded – once ipsec authentication is completed SSMS establishes TDS session with the database server.

You may have already noted that both succeeded secure connections still display all their network-related information in the network parser – that’s because by default no encryption is applied to the packets:

Here’s how the default IPSec settings correlate with the connection security rules applied (I’ll move on to the IPSec defaults right after this screenshot).

By default the “Require encryption…” checkbox is not checked so no encryption algorithms apply.

What if you want to disclose as little information as possible? It means ESP encryption must be enabled – this can be done either in the Windows Firewall’s IPSec defaults – and thus all connections that satisfy the ipsec rules on this host will be encrypted – or create the main mode rules with different encryption settings using netsh advfirewall mainmode add rule command. In this article I will enable encryption using Windows Firewall.

You can enable encryption in any GPO – server, client, or both (the best option, I think) – for example, I’ll edit the SecureSERVER gpo – navigate to Secure Settings\Windows Defender Firewall with Advanced Security, right-click it and select Properties:

Change to the IPsec Settings and click Customize in the IPsec defaults section:

It is the Quick Mode settings that define whether the encryption is enabled and if yes which encryption (as well as integrity) algorithms are to be used:

After setting the Quick mode to the Advanced configuration depicted above we can repeat Test 2 (after gpupdate /force on SQL1, of course) and see how network connections will be displayed in Network Monitor with ESP in place:

2.1 Pinging SQL1 from Client1

The trace:

2.2 Connecting to SQL1 in SSMS from Client1

As you see enabling ESP encryption helps disclose only ip-related information, hiding the higher-level packet information from potential network sniffer user.

And the last test: how will the traffic from a secure client to a non-secure host look like?

Test 3: Connecting to Exch1 from Client1

The trace:

The result: Client1 first tries authenticated connection and then falls back to the plain session.

In part 2 we’ll see how we can further restrict access to the secure servers.

Источник

Настройка и подключение IPSec в Windows

Включение службы IPSec

Настройка политики IPSec через «Локальную политику безопасности»

Применение политики IPSec

Проверка работы IPSec

Подключение к серверу через IPSec-клиент в Windows

Настройка VPN-подключения с IPSec (L2TP/IPSec)

Шаг 1: Создание VPN-подключения

Шаг 2: Настройка параметров безопасности

Подключение к серверу

Проверка подключения

Дополнительно: Подключение через IKEv2/IPSec

Служба «IPsec Policy Agent» в Windows

Что делает служба IPsec Policy Agent?

Основные функции службы:

Для чего работает IPsec Policy Agent?

Архитектура службы IPsec Policy Agent

Компоненты службы:

Схема работы:

Как управлять службой IPsec Policy Agent?

Когда нужно отключать службу IPsec Policy Agent?

Windows-Server-2022-IPsec-RDP-Security-Guide

Configuring IPsec Policies Between Windows Server 2022 and Windows 11

Table of Contents

Step 1: Configure IPsec Policy on Windows Server 2022

1. Open Group Policy Management or Local Security Policy

2. Navigate to IP Security Policies

3. Create a New IP Security Policy

3. 1. Authentication Method:

4. Manage IP Filter Lists and Filter Actions

5. Create IP Filters

6. Set Authentication and Action(Optional if not set in 3. 1)

Step 2: Import the IPsec Policy on Windows 11

1. Open Local Security Policy

2. Import or Recreate the Policy

Step 3: Assign Policies

Assign Policies on Both Machines

Verify Policy Assignment

Verification

How to Change the RDP Port on Windows Server or Windows 11

Key Points:

Steps to Change the RDP Port

Security Tips for RDP

Notes

Conclusion

Configuring connection security rules

Types of connection security rules

Creating an isolation rule

Note

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

1. Настройка первого VPN-сервера (KOM-AD01-VPN01)

1.1 Настройка виртуальной машины

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

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

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

2. Проверка подключения VPN-клиента по протоколу 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-сервере и VPN-клиенте

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

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

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

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

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

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

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

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

Test 1: Connecting to SQL1 from Tier1\Devices\SQL2