Общий ключ vpn не был указан что это

VPN для защищенного соединения офисов (Site-to-Site VPN)

[u]text[/u] — Подчеркнутый текст.

[i]text[/i] — Курсивный текст.

[s]text[/s] — ~~Зачеркнутый~~ текст.

[color=green]text[/color] — Цветной текст.

[url=kbpublisher.com]text[/url] — text

[quote]text[/quote] — Цитируемый текст

[h1]text[/h1] — Заголовок.

[code]text[/code] — Код text

[list]
[*] пункт1
[*] пункт2
[/list]

пункт 1
пункт 2

[ulist]
[*] пункт1
[*] пункт2
[/ulist]

пункт 1
пункт 2

Documentation:
Version: 5.x, 6.1.9, 7.0.1

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

Настройка сервера, выполняющего роль VPN-сервера для объединения офисов:

Шаг 1. Создать локального пользователя для авторизации сервера, выступающего в роли VPN-клиента.

В разделе Пользователи и устройства ➜ Пользователи создать пользователей для каждого из удаленных UserGate-серверов, выступающих в роли VPN-клиентов, задать пароли. Рекомендуется поместить всех созданных пользователей в группу, которой будет дан доступ для подключения по VPN. По умолчанию для этой цели в UserGate создана группа VPN servers.

Шаг 2. Разрешить сервис VPN на зоне, к которой будут подключаться VPN-клиенты.

В разделе Сеть ➜ Зоны отредактировать параметры контроля доступа для той зоны, к которой будут подключаться VPN-клиенты, разрешить сервис VPN. Как правило, это зона Untrusted.

Шаг 3. Создать зону, в которую будут помещены подключаемые по VPN серверы.

В разделе Сеть ➜ Зоны создать зону, в которую будут помещены подключаемые по VPN серверы. Эту зону в дальнейшем можно будет использовать в политиках безопасности.

Рекомендуется использовать уже существующую по умолчанию зону VPN for Site-to-Site.

Шаг 4. Создать разрешающее правило межсетевого экрана для трафика из созданной зоны.

В разделе Политики сети ➜ Межсетевой экран создать правило межсетевого экрана, разрешающее трафик из созданной зоны в другие зоны.

По умолчанию в UserGate создано правило межсетевого экрана VPN for Site-to-Site to Trusted and Untrusted, разрешающее весь трафик из зоны VPN for Site-to-Site в Trusted и Untrusted зоны. Правило выключено по умолчанию.

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

Шаг 5. Создать профиль авторизации.

В разделе Пользователи и устройства ➜ Профили авторизации создать профиль авторизации для пользователей VPN. Допускается использовать тот же профиль авторизации, что используется для авторизации пользователей с целью получения доступа к сети интернет. Следует учесть, что для авторизации VPN нельзя использовать методы прозрачной авторизации, такие как Kerberos, NTLM, SAML IDP.

Подробно о профилях авторизации смотрите в разделе данного руководства Профили авторизации.

Шаг 6. Создать профиль безопасности VPN.

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

Для создания профиля безопасности необходимо перейти в раздел VPN ➜ Профили безопасности, нажать кнопку Добавить и заполнить следующие поля:

Название — название профиля безопасности.
Описание — описание профиля.
Версия протокола IKE (Internet Key Exchange). Протокол IKE используется для создания защищённого канала связи между двумя сетями. В UserGate используется IKEv1.

Режим IKE: Основной или Агрессивный. Разница между режимами: в агрессивном режиме используется меньшее количество пакетов, что позволяет достичь более быстрого установления соединения. Агрессивный режим не передает некоторые параметры согласования, что требует предварительной идентичной настройки их на точках подключения.

Основной режим. В основном режиме происходит обмен шестью сообщениями. Во время первого обмена (сообщения 1 и 2) происходит согласование алгоритмов шифрования и аутентификации. Второй обмен (сообщения 3 и 4) предназначен для обмена ключами Диффи-Хеллмана (DH). После второго обмена служба IKE на каждом из устройств создаёт основной ключ, который будет использоваться для защиты проверки подлинности. Третий обмен (сообщения 5 и 6) предусматривает аутентификацию инициатора соединения и получателя (проверка подлинности); информация защищена алгоритмом шифрования, установленным ранее.
Агрессивный режим. В агрессивном режиме происходит 2 обмена, всего 3 сообщения. В первом сообщении инициатор передаёт информацию, соответствующую сообщениям 1 и 3 основного режима, т.е. информацию об алгоритмах шифрования и аутентификации и ключ DH. Второе сообщение предназначено для передачи получателем информации, соответствующей сообщениям 2 и 4 основного режима, а также аутентификации получателя. Третье сообщение аутентифицирует инициатора и подтверждает обмен.

Далее необходимо задать параметры первой и второй фаз согласования.

Во время первой фазы происходит согласование защиты IKE. Аутентификация происходит на основе общего ключа в режиме, выбранном ранее. Необходимо указать следующие параметры:

Время жизни ключа. По истечению данного времени происходят повторные аутентификация и согласование настроек первой фазы.
Интервал проверки dead peer detection — для проверки состояния и доступности соседних устройств используется механизм Dead Peer Detection (DPD). DPD периодически отправляет сообщения R-U-THERE для проверки доступности IPsec-соседа. Минимальный интервал: 10 секунд; значение 0 отключает проверку.
Неудачных попыток — максимальное количество запросов обнаружения недоступных IPsec-соседей, которое необходимо отправить до того, как IPsec-сосед будет признан недоступным.
Diffie-Hellman группы: выбор группы Диффи-Хеллмана, которая будет использоваться для обмена ключами. Сам ключ не передаётся, а передаются общие сведения, необходимые алгоритму определения ключа DH для создания общего секретного ключа. Чем больше номер группы Диффи-Хеллмана, тем больше бит используется для обеспечения надёжности ключа.
Алгоритмы авторизации и шифрования. Алгоритмы используются в порядке, в котором они отображены. Для изменения порядка перетащите необходимую пару вверх/вниз или используйте кнопки Выше/Ниже.

Во второй фазе осуществляется выбор способа защиты IPsec подключения. Необходимо указать:

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

По умолчанию в UserGate создан профиль безопасности Site-to-Site VPN profile, задающий необходимые настройки. Если вы собираетесь использовать этот профиль, необходимо изменить общий ключ шифрования.

Для упрощения настройки соединения с устройствами других вендоров по умолчанию созданы дополнительные профили безопасности (Cisco compatible VPN profile — для работы с устройствами Cisco и Fortinet compatible VPN profile — для работы с устройствами Fortinet).

Шаг 7. Создать VPN-интерфейс .

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

Внимание! Редактирование кластерного интерфейса возможно только для узла кластера cluster(даже если кластер не собран и узел всего один).

В разделе Сеть ➜ Интерфейсы нажмите кнопку Добавить и выберите Добавить VPN. Задайте следующие параметры:

Название — название интерфейса, должно быть в виде tunnelN, где N — это порядковый номер VPN-интерфейса.
Описание — описание интерфейса.
Зона — зона, к которой будет относится данный интерфейс. Все клиенты, подключившиеся по VPN к серверу UserGate, будут также помещены в эту зону. Укажите зону, созданную на шаге 3.
Профиль Netflow — профиль Netflow, используемый для данного интерфейса. Не обязательный параметр.
Режим — тип присвоения IP-адреса — без адреса, статический IP-адрес или динамический IP-адрес , полученный по DHCP . Если интерфейс предполагается использовать для приема VPN-подключений (Site-2-Site VPN или Remote access VPN, то необходимо использовать статический IP-адрес .
MTU — размер MTU для выбранного интерфейса.

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

Шаг 8. Создать сеть VPN.

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

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

Название — название сети.
Описание — описание сети.
Диапазон IP-адресов, которые будут использованы клиентами и сервером. Исключите из диапазона адреса, которые назначены VPN-интерфейсу, используемому совместно с данной сетью. Не указывайте здесь адреса сети и широковещательный адрес.
Укажите DNS-серверы, которые будут переданы клиенту, или отметьте чекбокс Использовать системные DNS , в этом случае клиенту будут назначены DNS-серверы, которые использует UserGate. Важно! Можно указать не более двух DNS-серверов.
Укажите маршруты, передаваемые клиенту в виде бесклассовой адресации (CIDR).

В UserGate создана сеть Site-to-Site VPN network с настройками по умолчанию. Для использования этой сети в ней необходимо добавить маршруты, передаваемые на сервер-клиент.

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

Шаг 9. Создать серверное правило VPN.

Создать серверное правило VPN, используя в нем созданные ранее сеть и профиль VPN. Для создания правила необходимо перейти в раздел VPN ➜ Серверные правила, нажать кнопку Добавить и заполнить следующие поля:

Название — название правила.
Описание — описание правила.
Профиль безопасности — профиль безопасности VPN, созданный ранее.
Сеть VPN — сеть VPN, созданная ранее.
Профиль авторизации — профиль авторизации, созданный ранее.

Источник — зоны и адреса, с которых разрешено принимать подключения к VPN. Как правило, клиенты находятся в сети интернет, следовательно, следует указать зону Untrusted. Важно! Обработка трафика происходит по следующей логике:

условия объединяются по ИЛИ, если указаны несколько списков IP-адресов и/или доменов;
условия объединяются по И, если указаны GeoIP и списки IP-адресов и/или доменов.

По умолчанию в UserGate создано серверное правило Site-to-Site VPN rule, в котором используются необходимые настройки для Site-to-Site VPN, а доступ к VPN разрешен членам локальной группе VPN servers.

Важно! Для применения различных серверных правил к разным клиентам необходимо использовать параметры Исходная зона и Адрес источника. Параметр Пользователь не является условием выбора серверного правила, проверка пользователя происходит уже после установления соединения VPN.

Для настройки сервера, выступающего в роли VPN-клиента, необходимо выполнить следующие шаги:

Шаг 1. Создать зону, в которую будут помещен интерфейс, используемый для подключения по VPN.

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

Рекомендуется использовать уже существующую по умолчанию зону VPN for Site-to-Site.

Шаг 2. Создать разрешающее правило межсетевого экрана для трафика в созданную зону.

Создать разрешающее правило межсетевого экрана в разделе Политики сети ➜ Межсетевой экран.

По умолчанию в UserGate создано правило межсетевого экрана VPN for Site-to-Site to Trusted and Untrusted, разрешающее весь трафик между зонами VPN for Site-to-Site, Trusted и Untrusted.

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

Шаг 3. Создать профиль безопасности VPN.

Для создания профиля необходимо перейти в раздел VPN ➜ Профили безопасности VPN, нажать кнопку Добавить и заполнить следующие поля:

Название — название профиля безопасности.
Описание — описание профиля.
Версия протокола IKE (Internet Key Exchange). Протокол IKE используется для создания защищённого канала связи между двумя сетями. В UserGate используется IKEv1.

Основной режим. В основном режиме происходит обмен шестью сообщениями. Во время первого обмена (сообщения 1 и 2) происходит согласование алгоритмов шифрования и аутентификации. Второй обмен (сообщения 3 и 4) предназначен для обмена ключами Диффи-Хеллмана (DH). После второго обмена служба IKE на каждом из устройств создаёт основной ключ, который будет использоваться для защиты проверки подлинности. Третий обмен (сообщения 5 и 6) предусматривает аутентификацию инициатора соединения и получателя (проверка подлинности); информация защищена алгоритмом шифрования, установленным ранее.
Агрессивный режим. В агрессивном режиме происходит 2 обмена, всего 3 сообщения. В первом сообщении инициатор передаёт информацию, соответствующую сообщениям 1 и 3 основного режима, т.е. информацию об алгоритмах шифрования и аутентификации и ключ DH. Второе сообщение предназначено для передачи получателем информации, соответствующей сообщениям 2 и 4 основного режима, а также аутентификации получателя. Третье сообщение аутентифицирует инициатора и подтверждает обмен.

Далее необходимо задать параметры первой и второй фаз согласования.

Время жизни ключа. По истечению данного времени происходят повторные аутентификация и согласование настроек первой фазы.
Интервал проверки dead peer detection — для проверки состояния и доступности соседних устройств используется механизм Dead Peer Detection (DPD). DPD периодически отправляет сообщения R-U-THERE для проверки доступности IPsec-соседа. Минимальный интервал: 10 секунд; значение 0 отключает проверку.
Неудачных попыток — максимальное количество запросов обнаружения недоступных IPsec-соседей, которое необходимо отправить до того, как IPsec-сосед будет признан недоступным.
Diffie-Hellman группы: выбор группы Диффи-Хеллмана, которая будет использоваться для обмена ключами. Сам ключ не передаётся, а передаются общие сведения, необходимые алгоритму определения ключа DH для создания общего секретного ключа. Чем больше номер группы Диффи-Хеллмана, тем больше бит используется для обеспечения надёжности ключа.
Алгоритмы авторизации и шифрования. Алгоритмы используются в порядке, в котором они отображены. Для изменения порядка перетащите необходимую пару вверх/вниз или используйте кнопки Выше/Ниже.

Во второй фазе осуществляется выбор способа защиты IPsec подключения. Необходимо указать:

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

По умолчанию в UserGate создан профиль Client VPN profile, задающий необходимые настройки. Если вы собираетесь использовать этот профиль, то необходимо изменить общий ключ шифрования.

Шаг 4. Создать VPN-интерфейс .

Название — название интерфейса, должно быть в виде tunnelN, где N — это порядковый номер VPN-интерфейса.
Описание — описание интерфейса.
Зона — зона, к которой будет относится данный интерфейс. Все клиенты, подключившиеся по VPN к серверу UserGate, будут также помещены в эту зону. Укажите зону, созданную на шаге 1.
Профиль Netflow — профиль Netflow, используемый для данного интерфейса. Не обязательный параметр.
Режим — тип присвоения IP-адреса — без адреса, статический IP-адрес или динамический IP-адрес , полученный по DHCP . Для использования интерфейса в качестве клиентского VPN, необходимо использовать режим получения адреса — Динамический.
MTU — размер MTU для выбранного интерфейса.

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

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

Шаг 5. Создать клиентское правило VPN.

Создать клиентское правило VPN, которое будет инициировать подключение к VPN-серверу. Для создания правила необходимо перейти в раздел VPN ➜ Клиентские правила, нажать кнопку Добавить и заполнить следующие поля:

Включено — включение/отключение данного правила.
Название — название правила.
Описание — описание правила.
Профиль безопасности VPN — созданный ранее профиль безопасности VPN.
Интерфейс — созданный ранее VPN-интерфейс .
Адрес сервера — IP-адрес VPN-сервера, куда подключается данный VPN-клиент. Как правило, это IP-адрес интерфейса в зоне Untrusted на сервере UserGate, выполняющего роль VPN-сервера.
Протокол VPN — Возможно выбрать вариант L2TP (для подключения к VPN-серверу UserGate) или IPSec туннель для подключения к VPN-серверу Cisco.
Подсети для Cisco VPN — IP адрес сети, которая будет доступна для клиентов со стороны UserGate (разрешенные подсети со стороны Cisco) и со стороны VPN-сервера Cisco (разрешенные подсети со стороны UserGate).
Имя пользователя и пароль (только для протокола L2TP) — имя и пароль пользователя, созданного на шаге 1 при подготовке VPN-сервера.

После завершения настройки VPN-сервера и VPN-клиента клиент инициирует соединение на сервер, и в случае корректности настроек, поднимается VPN-туннель. Для отключения туннеля выключите клиентское (на клиенте) или серверное правило VPN (на сервере).

Гайд: Свой собственный L2TP VPN

Покопавшись по просторам интернета в поисках софта для построения своего собственного VPN, постоянно натываешься на кучу гайдов связанных с неудобным в настройке и использовании OpenVPN, требующим проприетарного клиента Wireguard, только один SoftEther из всего этого цирка отличается адекватной реализацией. Но мы расскажем, так сказать, о нативной для Windows реализации VPN – Routing And Remote Access (RRAS).

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

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

1. Устанавливаем службы

Сначала, нам понадобится Windows Server Desktop Experience. Установка Core нам не подойдет, ибо отсутствует компонент NPA. Если компьютер будет членом домена, можно остановиться и на Server Core, в таком случае все это дело можно уложить в гигабайт ОЗУ.

Нам нужно установить RRAS и NPA (Network Policy Server). Первый нам понадобится для создания туннеля, а второй нужен в случае если сервер не является членом домена.

В выборе компонентов RRAS выбираем Direct access and VPN и Routing.

2. Настраиваем RRAS

После того, как мы установили все компоненты и перезагрузили машину, нужно приступить к настройке. Как на картинке, в пуске, находим диспетчер RRAS.

Через эту оснастку мы можем управлять серверами с установленным RRAS. Жмем правой кнопкой мыши, выбираем настройку и переходим.

Пропустив первую страницу переходим к выбору конфигурации, выбираем свою.

На следующей странице нам предлагается выбрать компоненты, выбираем VPN и NAT.

Далее, далее. Готово.

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

Первым делом вводим свой пароль для l2TP ipsec.

На вкладке IPv4 обязательно нужно установить выдаваемый клиентам диапазон ip адресов. Без этого NAT не заработает.

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

На интерфейсе (тот который не Internal) включаем NAT.

3. Разрешаем правила в брандмауэре

Тут все просто. Нужно найти группу правил Routing and Remote Access и включить их всех.

4. Настраиваем NPS

Ищем в пуске Network Policy Server.

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

5. Подключаемся по VPN

Для демонстрационных целей выберем Windows 10. В меню пуск ищем VPN.

Жмем на кнопку добавления подключения и переходим в настройки.

Имя подключения задавайте какое вам хочется.
IP адрес – это адрес вашего VPN сервера.
Тип VPN – l2TP с предварительным ключом.
Общий ключ – vpn (для нашего образа в маркетплейсе.)
А логин и пароль — это логин и пароль от локального пользователя, то есть от администратора.

Жмем на подключение и готово. Вот и ваш собственный VPN готов.

Надеемся, наш гайд даст еще одну опцию тем, кто хочет сделать свой собственный VPN не связываясь с Linux или просто хочет добавить шлюз в свою AD.

VPN-шлюз: вопросы и ответы

Да. Ограничений по регионам нет. Одна виртуальная сеть может подключаться к другой в том же или другом регионе Azure.

Можно ли подключать виртуальные сети в разных подписках?

Можно ли указать частные DNS-серверы в моей виртуальной сети при настройке VPN-шлюза?

Если вы указали DNS-сервер или серверы при создании виртуальной сети, VPN-шлюз использует указанные DNS-серверы. Указывая DNS-сервер, убедитесь, что он может разрешать доменные имена, необходимые для Azure.

Можно ли подключаться к нескольким сайтам из одной виртуальной сети?

Вы можете подключиться к нескольким сайтам с помощью Windows PowerShell и интерфейсов REST API Azure. См. раздел этой статьи Возможности подключения нескольких сайтов и подключения между виртуальными сетями.

Взимается ли дополнительная плата за настройку VPN-шлюза в режиме «активный — активный»?

№ Однако плата за любые дополнительные общедоступные IP-адреса будет взиматься соответствующим образом. См . цены на IP-адреса.

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

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

Сеть — сеть. VPN-подключение по протоколу IPsec (протоколы IKEv1 и IKEv2). Для этого типа подключения требуется VPN-устройство или RRAS. Дополнительные сведения см. в статье Настройка подключения «сеть — сеть».
Точка — сеть. VPN-подключение по протоколу SSTP (Secure Socket Tunneling Protocol) или IKEv2. Для этого подключения не требуется VPN-устройство. Дополнительные сведения см. в статье Настройка подключения «точка — сеть».
Виртуальная сеть — виртуальная сеть. Этот тип подключения аналогичен конфигурации «сеть — сеть». Конфигурация «Виртуальная сеть — виртуальная сеть» — это VPN-подключение по протоколу IPsec (протоколы IK v1 и IKE v2). Для этого подключения не требуется VPN-устройство. Дополнительные сведения см. в статье Настройка подключения между виртуальными сетями на портале Azure.
ExpressRoute. ExpressRoute — это прямое подключение к Azure из глобальной сети, а не VPN-подключение через общедоступный Интернет. Дополнительные сведения см. в статьях Технический обзор ExpressRoute и Вопросы и ответы по ExpressRoute.

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

Чем отличаются подключения «сеть — сеть» и «точка — сеть»?

Конфигурация сеть — сеть — это подключение между локальным расположением и Azure (через VPN-туннель IPsec/IKE). Такая конфигурация позволяет подключать любые компьютеры, находящиеся в локальной среде, к любой виртуальной машине или экземпляру роли в виртуальной сети в зависимости от настроек маршрутизации и разрешений. Это отличный вариант для всегда доступного распределенного подключения, а также для гибридных конфигураций. Для этого типа подключения требуется устройство VPN с поддержкой IPsec (аппаратное устройство или программное обеспечение), которое необходимо развернуть на границе сети. Для создания этого типа подключения необходим внешний адрес IPv4.

Конфигурация точка — сеть (VPN-подключение по протоколу SSTP) позволяет подключаться с одного компьютера, который может находиться где угодно, к любому расположению в виртуальной сети. Для этого подключения используется VPN-клиент, поставляемый с Windows. В рамках конфигурации «точка — сеть» устанавливается сертификат и пакет конфигурации VPN-клиента, который содержит параметры, позволяющие компьютеру подключаться к любой виртуальной машине или экземпляру роли в виртуальной сети. Эта конфигурация идеально подходит для подключения к виртуальной сети, если вы не находитесь в локальной. Этот вариант удобно использовать при отсутствии доступа к оборудованию VPN или внешнего адреса IPv4, которые необходимы для подключения «сеть — сеть».

Вы можете настроить виртуальную сеть на параллельное использование подключений «сеть — сеть» и «точка — сеть» при условии, что вы создаете подключение «сеть — сеть» с помощью типа VPN, основанного на маршрутизации, для своего шлюза. В классической модели развертывания типы VPN на основе маршрутов называются динамическими шлюзами.

Конфиденциальность

Хранит и обрабатывает ли служба VPN данные клиентов?

Шлюзы виртуальной сети

Является ли VPN-шлюз виртуальным сетевым шлюзом?

VPN-шлюз — это тип шлюза виртуальной сети. Он передает зашифрованный трафик между виртуальной сетью и локальным расположением через общедоступное подключение. VPN-шлюз можно также использовать для передачи трафика между виртуальными сетями. При создании VPN-шлюза для параметра GatewayType используется значение Vpn. Дополнительные сведения см. в статье Сведения о параметрах VPN-шлюза.

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

По состоянию на 1 октября 2023 г. vpn-шлюз на основе политик нельзя создать через портал Azure. Все новые VPN-шлюзы будут автоматически созданы в качестве маршрутов. Если у вас уже есть шлюз на основе политик, вам не нужно обновлять шлюз до маршрутизации. Powershell/CLI можно использовать для создания шлюзов на основе политик.

Ранее старые номера SKU шлюза не поддерживали IKEv1 для шлюзов на основе маршрутов. Теперь большинство текущих номеров SKU шлюза поддерживают IKEv1 и IKEv2.

Тип VPN шлюза.	Gateway SKU	Поддерживаемые версии IKE
Шлюз на основе политик	Базовая	IKEv1
Шлюз на основе маршрутов	Базовая	IKEv2
Шлюз на основе маршрутов	VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5	IKEv1 и IKEv2
Шлюз на основе маршрутов	VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ	IKEv1 и IKEv2

Можно ли поменять тип VPN-шлюза со шлюза на основе политик на шлюз на основе маршрутов?

№ Тип шлюза на основе политик нельзя изменить на шлюз на основе маршрутов и наоборот. Единственный способ изменить тип шлюза — удалить его и создать заново. Этот процесс занимает примерно 60 минут. При создании нового шлюза невозможно сохранить IP-адрес исходного шлюза.

Удалите все подключения, связанные со шлюзом.
Удалите шлюз, выполнив инструкции приведенные в одной из следующих статей:
- Портал Azure
- Azure PowerShell
- Azure PowerShell (классическая модель)
Создайте новый шлюз, используя необходимый тип, а затем завершите настройку VPN. Пошаговые инструкции см. в статье Руководство по настройке подключения «сеть — сеть».

Можно ли указать собственные селекторы трафика на основе политик?

Да, селекторы трафика можно определить с помощью атрибута trafficSelectorPolicies в подключении, используя команду PowerShell New-AzIpsecTrafficSelectorPolicy. Чтобы указанный селектор трафика вступил в силу, нужно включить параметр Use Policy Based Traffic Selectors (Использовать селекторы трафика на основе политики).

Настраиваемые селекторы трафика будут предложены только в том случае, если подключение инициирует VPN-шлюз Azure. VPN-шлюз принимает любые селекторы трафика, предлагаемые удаленным шлюзом (локальным VPN-устройством). Так происходит во всех режимах подключения (по умолчанию, InitiatorOnly и ResponderOnly).

Требуется ли параметр GatewaySubnet?

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

При создании подсети шлюза указывается количество IP-адресов, которое содержит подсеть. IP-адреса в подсети шлюза выделяются службе шлюза. В некоторых конфигурациях службам шлюза требуется выделить больше IP-адресов. Необходимо убедиться, что подсеть шлюза содержит достаточно IP-адресов с учетом будущего роста и возможных дополнительных конфигураций подключения. Хотя можно создать подсеть шлюза всего лишь с размером /29, мы советуем создавать подсети с размером /27 или больше (/27, /26, /25 и т. д.). Просмотрите требования для конфигурации, которую требуется создать, и убедитесь, что подсеть шлюза соответствует этим требованиям.

Могу ли я развернуть виртуальные машины или экземпляры ролей в моей подсети шлюза?

Можно ли получить IP-адрес своего VPN-шлюза до его создания?

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

Можно ли запросить статический общедоступный IP-адрес для VPN-шлюза?

Рекомендуется использовать общедоступный IP-адрес SKU уровня «Стандартный» для VPN-шлюза. Ресурсы общедоступного IP-адреса SKU уровня «Стандартный» используют статический метод выделения. Хотя мы поддерживаем динамическое назначение IP-адресов для определенных номеров SKU шлюза (SKU шлюза, которые не имеют az in name), рекомендуется использовать общедоступный IP-адрес SKU уровня «Стандартный» для всех шлюзов виртуальной сети, кроме шлюзов с использованием SKU шлюза «Базовый». Номер SKU шлюза «Базовый» в настоящее время поддерживает только общедоступные IP-адреса SKU уровня «Базовый». В ближайшее время мы добавим поддержку общедоступных IP-адресов SKU уровня «Стандартный» для SKU шлюза «Базовый».

Для незонизбыточного и незонального шлюза (SKU шлюза, не имеющих az in name), поддерживается динамическое назначение IP-адресов, но отменяется. При использовании динамического IP-адреса IP-адрес не изменяется после его назначения VPN-шлюзу. IP-адрес VPN-шлюза изменяется только после его удаления и повторного создания. Общедоступный IP-адрес VPN-шлюза не изменяется при изменении размера, сбросе или завершении другого внутреннего обслуживания и обновлений VPN-шлюза.

Как использование общедоступного IP-адреса уровня SKU уровня «Базовый» влияет на vpn-шлюзы?

Мы принимаем меры для обеспечения непрерывной работы развернутых VPN-шлюзов, использующих общедоступные IP-адреса SKU уровня «Базовый». Если у вас уже есть VPN-шлюзы с общедоступными IP-адресами SKU уровня «Базовый», вам не нужно предпринимать никаких действий.

Однако важно отметить, что общедоступные IP-адреса SKU уровня «Базовый» прекращены. При создании новых VPN-шлюзов настоятельно рекомендуется использовать общедоступные IP-адреса SKU уровня «Стандартный». Дополнительные сведения об выходе общедоступных IP-адресов SKU уровня «Базовый» см . здесь.

Как проверить подлинность моего VPN-туннеля?

VPN Azure использует проверку подлинности с помощью общего ключа (PSK). Во время создания VPN-туннеля генерируется общий ключ (PSK). Вы можете заменить автоматически созданный PSK собственным. Для этого используйте PowerShell или API REST для задания общего ключа.

Можно ли использовать API для задания общего ключа для настройки VPN-шлюза со статической маршрутизацией (на основе политик)?

Да, API и командлет PowerShell для задания общего ключа можно использовать для настройки VPN Azure со статической (на основе политик) и динамической (на основе маршрутов) маршрутизацией.

Можно ли использовать другие способы проверки подлинности

Для проверки подлинности можно использовать только общие ключи (PSK).

Как установить, какой именно трафик проходит через VPN-шлюз?

Модель развертывания Resource Manager

PowerShell: используйте параметр AddressPrefix, чтобы указать трафик для шлюза локальной сети.
Портал Azure: перейдите к шлюзу локальной сети > «Конфигурация» > «Адресное пространство».

Классическая модель развертывания

Портал Azure: перейдите к классической виртуальной сети и последовательно выберите > «VPN-подключения» > «VPN-подключения типа «сеть — сеть» > Local site name (Имя локального сайта) > «Локальный сайт» > Client address space (Адресное пространство клиента).

Можно ли использовать NAT-T для моих VPN-подключений?

Да, обход NAT (NAT-T) поддерживается. VPN-шлюз Azure НЕ будет выполнять никаких функций, подобных NAT, для внутренних пакетов, поступающих в туннели IPsec и из них. В этой конфигурации убедитесь, что локальное устройство инициирует использование туннеля IPsec.

Можно ли настроить собственный VPN-сервер в Azure и использовать его для подключения к локальной сети?

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

Почему на моем шлюзе виртуальной сети открыты определенные порты?

Они необходимы для обмена данными в рамках инфраструктуры Azure. Они защищены (заблокированы) с использованием сертификатов Azure. Без подходящих сертификатов внешние сущности, включая клиентов этих шлюзов, не смогут как-либо повлиять на эти конечные точки.

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

Можно ли создать VPN-шлюз с номером SKU шлюза «Базовый» на портале?

№ Номер SKU «Базовый» недоступен на портале. Vpn-шлюз SKU уровня «Базовый» можно создать с помощью Azure CLI или PowerShell.

Где можно найти сведения о типах шлюза, требованиях и пропускной способности?

См. следующие статьи:

Сведения о параметрах конфигурации VPN-шлюз
Сведения об номерах SKU шлюза

Отмена номера SKU для устаревших номеров SKU

Номера SKU уровня «Стандартный» и «Высокий уровень производительности» будут устарели 30 сентября 2025 г. Вы можете просмотреть объявление здесь. Группа разработчиков предложит способ миграции для этих категорий к 30 ноября 2024 года. Дополнительные сведения см. в статье VPN-шлюз устаревших номеров SKU. В настоящее время нет никаких действий, которые вам нужно предпринять.

Можно ли создать номер SKU уровня «Стандартный» или «Высокий уровень производительности» после объявления об отмене 30 ноября 2023 г.?

№ Начиная с 1 декабря 2023 г. нельзя создавать новые шлюзы с номерами SKU уровня «Стандартный» или «Высокий уровень производительности». Вы можете создать новые шлюзы с помощью VpnGw1 и VpnGw2 для той же цены, что и номера SKU уровня «Стандартный» и «Высокая производительность», указанные соответственно на нашей странице цен.

Сколько времени будут поддерживаться существующие шлюзы на номерах SKU уровня «Стандартный» или «Высокий уровень производительности»?

Все существующие шлюзы, использующие номера SKU уровня «Стандартный» или «Высокий уровень производительности», будут поддерживаться до 30 сентября 2025 г.

Нужно ли перенести номера SKU шлюза уровня «Стандартный» или «Высокий уровень производительности» прямо сейчас?

Нет, сейчас никаких действий не требуется. Вы сможете перенести номера SKU с декабря 2024 года. Мы отправим связь с подробной документацией по шагам миграции.

Какой номер SKU можно перенести в шлюз?

Когда миграция SKU шлюза становится доступной, номера SKU можно перенести следующим образом:

Standard —> VpnGw1
Высокая производительность —> VpnGw2

Что делать, если я хочу перейти на SKU AZ?

Вы не можете перенести устаревший номер SKU в AZ SKU. Однако обратите внимание, что все шлюзы, которые по-прежнему используют номера SKU уровня «Стандартный» или «Высокий уровень производительности» после 30 сентября 2025 г. будут перенесены и обновлены автоматически до следующих номеров SKU:

Standard —> VpnGw1AZ
Высокая производительность —> VpnGw2AZ

Эту стратегию можно использовать для автоматической миграции и обновления номеров SKU AZ. При необходимости вы можете изменить размер номера SKU в пределах этого семейства SKU. См. нашу страницу цен на AZ SKU. Сведения о пропускной способности по номеру SKU см. в разделе «Сведения о номерах SKU шлюза».

Будет ли разница в ценах на шлюзы после миграции?

Если вы переносите номера SKU к 30 сентября 2025 г., разница в ценах не будет. Номера SKU VpnGw1 и VpnGw2 предоставляются по той же цене, что и номера SKU уровня «Стандартный» и «Высокая производительность» соответственно. Если вы не переносите по этой дате, номера SKU автоматически будут перенесены и обновлены до номеров SKU AZ. В этом случае разница в ценах.

Будет ли влияние на производительность шлюзов с этой миграцией?

Да, вы получаете лучшую производительность с помощью VpnGw1 и VpnGw2. В настоящее время VpnGw1 на 650 Мбит/с предоставляет 6,5x и VpnGw2 на 1 Гбит/с обеспечивает повышение производительности 5x по той же цене, что и устаревшие шлюзы уровня «Стандартный» и «Высокая производительность» соответственно. Дополнительные сведения о пропускной способности SKU см. в разделе «Сведения о номерах SKU шлюза».

Что произойдет, если я не переносю номера SKU к 30 сентября 2025 г.?

Все шлюзы, которые по-прежнему используют номера SKU уровня «Стандартный» или «Высокая производительность», будут перенесены автоматически и обновлены до следующих номеров SKU AZ:

Standard —> VpnGw1AZ
Высокая производительность —> VpnGw2AZ

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

Кроме того, VPN-шлюз базовом номере SKU?

Нет, базовый номер SKU здесь, чтобы остаться. В ближайшее время мы добавим поддержку стандартного IP-адреса в номер SKU «Базовый», так как в настоящее время он поддерживает только базовый IP-адрес (который находится на пути выхода на пенсию). В настоящее время вы можете создать номер SKU уровня «Базовый» с помощью Powershell/CLI и после добавления поддержки стандартного IP-адреса, портал также должен поддерживать создание номера SKU уровня «Базовый».

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

Что следует учесть при выборе VPN-устройства?

Для подключения «сеть — сеть» мы утвердили набор стандартных VPN-устройств в сотрудничестве с поставщиками устройств. Дополнительные сведения о списке известных совместимых устройств VPN, соответствующих инструкциях по настройке или образцах конфигураций, а также о спецификации устройств см. в статье VPN-устройства и параметры IPsec/IKE для подключений типа «сеть — сеть» через VPN-шлюз. Все устройства, перечисленные в семействах устройств как совместимые, должны работать с виртуальной сетью. Чтобы настроить VPN-устройство, см. образец конфигурации устройства или перейдите по ссылке, которая соответствует семейству устройств.

Где можно найти параметры конфигурации VPN-устройств?

Скачивание скриптов конфигурации VPN-устройства:

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

Дополнительные сведения о конфигурации см. по следующим ссылкам:

См. дополнительные сведения о совместимых VPN-устройствах.
Прежде чем настраивать VPN-устройство, которое вы хотите использовать, проверьте его на наличие известных проблем совместимости устройств.
См. дополнительные сведения о проверенных VPN-устройствах. Ссылки на инструкции по настройке устройств будут предоставляться по мере возможности. Актуальные сведения о конфигурации всегда лучше проверять у производителей устройств. В списке перечислены протестированные нами версии. Если вашей ОС нет в этом списке, эта версия все равно может быть совместимой. Обратитесь к изготовителю устройства, чтобы проверить совместимость версии ОС с вашим VPN-устройством.
Общие сведения о конфигурации устройства VPN см. в статье Обзор конфигураций партнерских VPN-устройств.
См. дополнительные сведения о примерах изменения конфигурации устройств.
См. дополнительные сведения о требованиях к шифрованию и VPN-шлюзах Azure.
См. дополнительные сведения о VPN-устройствах и параметрах IPsec/IKE для подключений типа «сеть — сеть» через VPN-шлюз. По этой ссылке отображаются сведения о версии IKE, группе Диффи-Хелмана, способе аутентификации, алгоритмах шифрования и хэширования, времени существования SA, PFS, DPD, а также другие сведения о параметрах, необходимых для завершения настройки.
См. инструкции по настройке политики IPsec/IKE для VPN-подключений типа «сеть — сеть» или «виртуальная сеть — виртуальная сеть».
Сведения о подключении нескольких VPN-устройств на основе политик см. в статье Подключение VPN-шлюзов Azure к нескольким локальным VPN-устройствам на основе политики с помощью PowerShell.

Как изменить примеры конфигурации VPN-устройства?

Где найти параметры IPsec и IKE?

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

Это ожидаемое поведение для шлюзов VPN на основе политики. Такое поведение также называют «статическая маршрутизация». Когда трафик через туннель неактивен более 5 минут, туннель удаляется. Когда трафик начинается в любом направлении, туннель восстанавливается немедленно.

Можно ли использовать сети VPN для подключения к Azure?

Мы поддерживаем серверы маршрутизации и удаленного доступа Windows Server 2012 (RRAS) для межсайтовой конфигурации.

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

Можно ли подключиться к VPN-шлюзу с помощью подключения «точка — сеть» при активном подключении «сеть — сеть»?

Да, но общедоступные IP-адреса клиента типа «точка — сеть» должны отличаться от общедоступных IP-адресов, используемых VPN-устройством типа «сеть — сеть», или подключение типа «точка — сеть» не будет работать. Подключения «точка — сеть» с IKEv2 не могут инициироваться с того же общедоступного IP-адреса, на котором настроено VPN-подключение «сеть — сеть» на том же VPN-шлюзе Azure.

Подключения «точка — сеть» и проверка подлинности на основе сертификата

Этот раздел посвящен модели развертывания с помощью Resource Manager.

Сколько конечных точек VPN-клиента можно использовать в конфигурации типа «точка — сеть»?

Это зависит от SKU шлюза. Дополнительные сведения о количестве поддерживаемых подключений см. в разделе SKU шлюзов.

Какие клиентские операционные системы можно использовать для подключения типа «точка — сеть»?

Поддерживаются следующие клиентские операционные системы:

Windows Server 2008 R2 (только 64-разрядная версия)
Windows 8.1 (32-разрядная и 64-разрядная версии)
Windows Server 2012 (только 64-разрядная версия)
Windows Server 2012 R2 (только 64-разрядная версия)
Windows Server 2016 (только 64-разрядная версия)
Windows Server 2019 (только 64-разрядная версия)
Windows Server 2022 (только 64-разрядная версия)
Windows 10
Windows 11
macOS версии 10.11 или более поздней
Linux (StrongSwan)
iOS

Можно ли проходить через прокси-серверы и брандмауэры с помощью возможностей «точка — сеть»?

Azure поддерживает три варианта VPN-подключения типа «точка — сеть»:

По протоколу SSTP (Secure Sockets Tunneling Protocol). SSTP — это разработанное корпорацией Майкрософт решение на основе SSL, которое позволяет проходить через брандмауэры, так как большинство брандмауэров открывают для SSL исходящий TCP-порт 443.
OpenVPN. OpenVPN — это решение на основе SSL, которое позволяет проходить через брандмауэры, так как большинство брандмауэров открывают для SSL исходящий TCP-порт 443.
По протоколу IKEv2 для VPN. IKEv2 для VPN — это стандартное решение для VPN-подключения IPsec, которое использует исходящие порты UDP 500 и 4500, а также протокол IP 50. Эти порты не всегда открываются в брандмауэре, поэтому есть вероятность, что IKEv2 для VPN не сможет пройти через прокси-серверы и брандмауэры.

Если перезапустить клиентский компьютер, настроенный для типа «точка — сеть», vpn автоматически будет повторно подключаться?

Автоматическое переподключение — это функция используемого клиента. В Windows автоматическое переподключение поддерживается с помощью функции клиента Always On VPN.

Поддерживает ли подключение «точка — сеть» DDNS для VPN-клиентов?

Сейчас DDNS не поддерживается в VPN-подключениях «точка — сеть».

Могут ли сосуществовать в одной виртуальной сети конфигурации «сеть — сеть» и «точка — сеть»?

Да. Для модели развертывания с помощью Resource Manager требуется VPN-шлюз с маршрутизацией на основе маршрутов. В классической модели развертывания требуется динамический шлюз. Подключения типа «точка — сеть» для VPN-шлюзов со статической маршрутизацией или маршрутизацией на основе политик не поддерживаются.

Можно ли настроить клиент «точка — сеть» для подключения к нескольким шлюзам виртуальных сетей одновременно?

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

Можно ли настроить клиент типа «точка — сеть» для подключения к нескольким виртуальным сетям одновременно?

Да, клиентские подключения «точка — сеть» к шлюзу виртуальной сети, развернутому в сети с пиринговым подключением к другим виртуальным сетям, могут иметь доступ к другим одноранговым виртуальным сетям. Если одноранговые виртуальные сети используют функции UseRemoteGateway или AllowGatewayTransit, клиенты с подключением «точка — сеть» смогут подключаться к этим сетям. Дополнительные сведения см. в статье Сведения о маршрутизации «точка — сеть».

На какую пропускную способность можно рассчитывать в конфигурациях подключения «сеть — сеть» и «точка — сеть»?

Сложно поддерживать конкретную пропускную способность для туннелей VPN. IPsec и SSTP — это надежно зашифрованные протоколы VPN. Пропускная способность также зависит от задержки и пропускной способности между локальной сетью и Интернетом. Для VPN-шлюза, который используется только для VPN-подключений типа «точка — сеть» по протоколу IKEv2, общая пропускная способность зависит от номера SKU шлюза. Дополнительные сведения о пропускной способности см. в статье о номерах SKU шлюзов.

Можно ли использовать для подключения «точка — сеть» любой программный VPN-клиент, поддерживающий SSTP и (или) IKEv2?

№ Вы можете использовать только собственный VPN-клиент для SSTP в Windows и собственный VPN-клиент для IKEv2 в Mac. Но для подключения по протоколу OpenVPN можно использовать клиент OpenVPN на любой платформе. См. список поддерживаемых клиентских операционных систем.

Можно ли изменить тип проверки подлинности для подключений «точка — сеть»?

Да. На портале перейдите на страницу VPN-шлюз -> Конфигурация «точка — сеть». В поле Тип проверки подлинности выберите нужные типы проверки подлинности. После внесения изменений в тип проверки подлинности у текущих клиентов могут возникать проблемы с подключением, пока для каждого VPN-клиента не будет создан, загружен и применен новый профиль конфигурации VPN-клиента.

Azure поддерживает протокол IKEv2 для VPN в Windows?

IKEv2 поддерживается в Windows 10 и Server 2016. Однако для использования IKEv2 в некоторых версиях операционных систем необходимо установить обновления и задать значение раздела реестра локально. Версии операционной системы до Windows 10 не поддерживаются и могут использовать только протокол SSTP или OpenVPN®.

Эти действия не нужно выполнять в сборках ОС Windows новее, чем Windows 10 версии 1709 и Windows Server 2016 версии 1607.

Чтобы подготовить Windows 10 или Server 2016 IKEv2:

Версия ОС	Date	Номер или ссылка
Windows Server 2016 Windows 10 версии 1607	17 января 2018 г.	KB4057142
Windows 10 версии 1703	17 января 2018 г.	KB4057144
Windows 10 версии 1709	22 марта 2018 г.	KB4089848

Каков ограничение селектора трафика IKEv2 для подключений «точка — сеть»?

Для Windows 10 версии 2004 (выпущено в сентябре 2021 г.) ограничение селектора трафика увеличено до 255. В предыдущих версиях Windows ограничение селектора трафика составляет 25.

Ограничение селекторов трафика в Windows определяет максимальное количество адресных пространств в виртуальной сети и максимальную сумму локальных сетей, подключений между виртуальными сетями и одноранговых виртуальных сетей, подключенных к шлюзу. Клиенты с подключением типа «точка — сеть» на базе Windows не смогут подключиться через IKEv2, если они превысят это ограничение.

Что произойдет, если настроить и SSTP, и IKEv2 для подключений VPN типа «точка — сеть»?

При настройке SSTP и IKEv2 в смешанной среде (состоящей из устройств Windows и Mac) VPN-клиент Windows будет сначала пытаться подключиться к туннелю IKEv2, но если не удастся установить подключение IKEv2, подключится к SSTP. MacOSX подключится только через IKEv2.

Если в шлюзе включен единый протокол SSTP и IKEv2, пул адресов типа «точка — сеть» будет статически разделен между этими двумя, поэтому клиенты, использующие разные протоколы, будут назначены IP-адреса из любого под диапазона. Обратите внимание, что максимальное количество клиентов SSTP всегда равно 128, даже если диапазон адресов больше /24, что приводит к большему количеству адресов, доступных для клиентов IKEv2. Для небольших диапазонов пул будет равным наполовину. Селекторы трафика, используемые шлюзом, могут не включать ciDR диапазона адресов «Точка — сеть», но два под-диапазона CIDR.

Какие еще платформы, кроме Windows и Mac, Azure поддерживает для VPN-подключений типа «точка — сеть»?

Azure поддерживает VPN-подключения «точка — сеть» в Windows, Mac и Linux.

У меня уже развернут VPN-шлюз Azure. Можно ли включить на нем RADIUS и/или IKEv2 для VPN?

Да, если используемый номер SKU шлюза поддерживает RADIUS и (или) IKEv2, эти новые функции можно включить для уже развернутых шлюзов с помощью PowerShell или портала Azure. Ценовая категория «Базовый» не поддерживает ни RADIUS, ни IKEv2.

Как удалить конфигурацию подключения «точка — сеть»?

Эту конфигурацию можно удалить с помощью Azure CLI и PowerShell, используя следующие команды:

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name ` $gw.VPNClientConfiguration = $null` Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

Azure CLI

az network vnet-gateway update --name --resource-group --remove "vpnClientConfiguration"

Что делать, если при подключении с использованием проверки подлинности сертификата обнаружено несоответствие сертификата?

Отмените проверка «Проверьте удостоверение сервера, проверяя сертификат», или добавьте полное доменное имя сервера вместе с сертификатом при создании профиля вручную. Это можно сделать, выполнив команду rasphone в командной строке. Затем нужно выбрать профиль в раскрывающемся списке.

Обход проверки удостоверения сервера в целом не рекомендуется, но при проверке подлинности на основе сертификата Azure для проверки сервера в протоколе туннелирования VPN (IKEv2/SSTP) и протоколе EAP используется один и тот же сертификат. Так как сертификат сервера и полное доменное имя уже проверяются протоколом туннелирования VPN, это избыточно для проверки того же времени в EAP.

point-to-site auth

Можно ли с помощью корневого ЦС собственной внутренней системы PKI создать сертификаты для подключения «точка — сеть»?

Да. Раньше поддерживались только самозаверяющие корневые сертификаты. Вы по-прежнему можете загружать до 20 корневых сертификатов.

Можно ли использовать сертификаты из Azure Key Vault?

Какие инструменты можно использовать для создания сертификатов?

Можно использовать решение Enterprise PKI (внутренняя инфраструктура открытых ключей), Azure PowerShell, MakeCert и OpenSSL.

Есть ли инструкции по выбору параметров сертификата?

Внутренняя инфраструктура открытых ключей и решение Enterprise PKI: см. инструкции по созданию сертификатов.
Azure PowerShell: см. инструкции по работе с Azure PowerShell.
MakeCert: см. инструкции по работе с MakeCert.

OpenSSL:

При экспорте сертификатов преобразуйте корневой сертификат в кодировку Base64.

Для сертификата клиента:

При создании закрытого ключа укажите длину 4096.
При создании сертификата для параметра -extensions укажите значение usr_cert.

Подключения «точка — сеть» и проверка подлинности RADIUS

Этот раздел посвящен модели развертывания с помощью Resource Manager.

Сколько конечных точек VPN-клиента можно использовать в конфигурации типа «точка — сеть»?

Какие клиентские операционные системы можно использовать для подключения типа «точка — сеть»?

Поддерживаются следующие клиентские операционные системы:

Windows Server 2008 R2 (только 64-разрядная версия)
Windows 8.1 (32-разрядная и 64-разрядная версии)
Windows Server 2012 (только 64-разрядная версия)
Windows Server 2012 R2 (только 64-разрядная версия)
Windows Server 2016 (только 64-разрядная версия)
Windows Server 2019 (только 64-разрядная версия)
Windows Server 2022 (только 64-разрядная версия)
Windows 10
Windows 11
macOS версии 10.11 или более поздней
Linux (StrongSwan)
iOS

Можно ли проходить через прокси-серверы и брандмауэры с помощью возможностей «точка — сеть»?

Azure поддерживает три варианта VPN-подключения типа «точка — сеть»:

По протоколу SSTP (Secure Sockets Tunneling Protocol). SSTP — это разработанное корпорацией Майкрософт решение на основе SSL, которое позволяет проходить через брандмауэры, так как большинство брандмауэров открывают для SSL исходящий TCP-порт 443.
OpenVPN. OpenVPN — это решение на основе SSL, которое позволяет проходить через брандмауэры, так как большинство брандмауэров открывают для SSL исходящий TCP-порт 443.
По протоколу IKEv2 для VPN. IKEv2 для VPN — это стандартное решение для VPN-подключения IPsec, которое использует исходящие порты UDP 500 и 4500, а также протокол IP 50. Эти порты не всегда открываются в брандмауэре, поэтому есть вероятность, что IKEv2 для VPN не сможет пройти через прокси-серверы и брандмауэры.

Если перезапустить клиентский компьютер, настроенный для типа «точка — сеть», vpn автоматически будет повторно подключаться?

Поддерживает ли подключение «точка — сеть» DDNS для VPN-клиентов?

Сейчас DDNS не поддерживается в VPN-подключениях «точка — сеть».

Могут ли сосуществовать в одной виртуальной сети конфигурации «сеть — сеть» и «точка — сеть»?

Можно ли настроить клиент «точка — сеть» для подключения к нескольким шлюзам виртуальных сетей одновременно?

Можно ли настроить клиент типа «точка — сеть» для подключения к нескольким виртуальным сетям одновременно?

На какую пропускную способность можно рассчитывать в конфигурациях подключения «сеть — сеть» и «точка — сеть»?

Можно ли использовать для подключения «точка — сеть» любой программный VPN-клиент, поддерживающий SSTP и (или) IKEv2?

Можно ли изменить тип проверки подлинности для подключений «точка — сеть»?

Azure поддерживает протокол IKEv2 для VPN в Windows?

Эти действия не нужно выполнять в сборках ОС Windows новее, чем Windows 10 версии 1709 и Windows Server 2016 версии 1607.

Чтобы подготовить Windows 10 или Server 2016 IKEv2:

Версия ОС	Date	Номер или ссылка
Windows Server 2016 Windows 10 версии 1607	17 января 2018 г.	KB4057142
Windows 10 версии 1703	17 января 2018 г.	KB4057144
Windows 10 версии 1709	22 марта 2018 г.	KB4089848

Каков ограничение селектора трафика IKEv2 для подключений «точка — сеть»?

Что произойдет, если настроить и SSTP, и IKEv2 для подключений VPN типа «точка — сеть»?

Какие еще платформы, кроме Windows и Mac, Azure поддерживает для VPN-подключений типа «точка — сеть»?

Azure поддерживает VPN-подключения «точка — сеть» в Windows, Mac и Linux.

У меня уже развернут VPN-шлюз Azure. Можно ли включить на нем RADIUS и/или IKEv2 для VPN?

Как удалить конфигурацию подключения «точка — сеть»?

Эту конфигурацию можно удалить с помощью Azure CLI и PowerShell, используя следующие команды:

Azure PowerShell

$gw=Get-AzVirtualNetworkGateway -name ` $gw.VPNClientConfiguration = $null` Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

Azure CLI

az network vnet-gateway update --name --resource-group --remove "vpnClientConfiguration"

Поддерживается ли аутентификация RADIUS во всех номерах SKU VPN-шлюзов Azure?

Проверка подлинности RADIUS поддерживается для всех номеров SKU, кроме номера SKU «Базовый».

Из устаревших ценовых категорий проверка подлинности RADIUS поддерживается только для категорий «Стандартный» и «Высокопроизводительный». Она не поддерживается для шлюзов с ценовой категорией «Базовый».

Поддерживается ли аутентификация RADIUS в классической модели развертывания?

№ Проверка подлинности RADIUS не поддерживается в классической модели развертывания.

Каков период ожидания запросов RADIUS, отправляемых на сервер RADIUS?

Для запросов RADIUS устанавливается время ожидания 30 секунд. В настоящее время настройка времени ожидания пользователем не поддерживается.

Поддерживаются ли сторонние серверы RADIUS?

Да, сторонние серверы RADIUS поддерживаются.

Какие требования к подключению необходимо выполнить, чтобы обеспечить шлюзу Azure доступ к локальному серверу RADIUS?

Требуется VPN-подключение «сеть — сеть» к локальному сайту с правильно настроенными маршрутами.

Может ли трафик направляться на локальный сервер RADIUS (из VPN-шлюза Azure) через подключение ExpressRoute?

№ Он может направляться только через подключение «сеть — сеть».

Изменилось ли количество поддерживаемых SSTP-подключений с аутентификацией RADIUS? Каково максимальное количество поддерживаемых SSTP- и IKEv2-подключений?

Нет изменений в максимальном количестве подключений SSTP, поддерживаемых в шлюзе с проверкой подлинности RADIUS. По-прежнему доступно 128 подключений по протоколу SSTP, но их количество зависит от SKU шлюза для IKEv2. Дополнительные сведения о количестве поддерживаемых подключений см. в разделе SKU шлюзов.

В чем разница между проверкой подлинности на основе сертификата с использованием сервера RADIUS и собственной проверкой подлинности Azure на основе сертификата (путем передачи доверенного сертификата в Azure)?

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

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

Работает ли аутентификация RADIUS с IKEv2 и SSTP для VPN?

Да, аутентификация RADIUS поддерживается для IKEv2 и SSTP для VPN.

Работает ли аутентификация RADIUS с клиентом OpenVPN?

Протокол OpenVPN поддерживает аутентификацию RADIUS.

Подключения типа «виртуальная сеть — виртуальная сеть» и многосайтовые подключения

Сведения из раздела «Часто задаваемые вопросы о подключениях типа «виртуальная сеть – виртуальная сеть» применяются к соединениям VPN-шлюза. Подробнее о пиринге виртуальной сети см. в разделе Пиринг виртуальной сети.

Взимает ли Azure плату за трафик между виртуальными сетями?

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

Трафик между виртуальными сетями проходит через Интернет?

№ Трафик между виртуальными сетями проходит через магистральную сеть Microsoft Azure, а не через Интернет.

Можно ли установить подключение между виртуальными сетями в клиентах Microsoft Entra?

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

Защищен ли трафик между двумя виртуальными сетями?

Да. Он защищен шифрованием IPsec/IKE.

Требуется ли VPN-устройство для подключения виртуальных сетей друг к другу?

№ Для подключения нескольких виртуальных сетей Azure друг к другу не нужно VPN-устройство, если только не требуется распределенное подключение.

Должны ли мои виртуальные сети находиться в одном регионе?

№ Виртуальные сети могут быть в одном или разных регионах (расположениях) Azure.

Если виртуальные сети находятся в разных подписках, нужно ли связывать подписки с одним клиентом Active Directory?

Можно ли использовать подключение между виртуальными сетями для виртуальных сетей в разных экземплярах Azure?

№ Подключения между виртуальными сетями поддерживаются только в пределах одного экземпляра Azure. Например, невозможно создать подключение между общедоступным облаком Azure и экземплярами Azure для государственных организаций Китая, Германии или США. В этих сценариях рекомендуется использовать VPN-подключение типа «сеть – сеть».

Можно ли одновременно использовать подключение типа «виртуальная сеть — виртуальная сеть» и многосайтовые подключения?

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

К какому количеству локальных сайтов и виртуальных сетей может подключаться одна виртуальная сеть?

Можно ли использовать подключение типа «виртуальная сеть — виртуальная сеть» для подключения виртуальных машин или облачных служб за пределами виртуальной сети?

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

Может ли облачная служба или конечная точка балансировки нагрузки охватывать несколько виртуальных сетей?

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

Можно ли использовать VPN типа PolicyBased для подключений типа «виртуальная сеть – виртуальная сеть» и многосайтовых подключений?

№ Для подключений типа «виртуальная сеть – виртуальная сеть» и многосайтовых подключений необходимы VPN-шлюзы Azure с VPN типа RouteBased (этот тип раньше назывался динамической маршрутизацией).

Могу ли я подключить виртуальную сеть с типом VPN RouteBased к другой виртуальной сети с типом VPN PolicyBased?

Нет, обе виртуальные сети ДОЛЖНЫ использовать VPN-шлюзы на основе маршрутов (этот тип раньше назывался динамической маршрутизацией).

Используют ли VPN-туннели пропускную способность совместно?

Да. Все туннели VPN виртуальной сети совместно используют доступную пропускную способность VPN-шлюза Azure и одно соглашение об уровне обслуживания VPN-шлюзов в Azure.

Поддерживаются ли избыточные туннели?

Если один шлюз виртуальной сети работает в режиме «активный — активный», между парой виртуальных сетей поддерживаются избыточные туннели.

Могут ли перекрываться адресные пространства для конфигураций типа «виртуальная сеть — виртуальная сеть»?

№ Нельзя, чтобы диапазоны IP-адресов перекрывались.

Существуют ли пересекающиеся адресные пространства между подключенными виртуальными сетями и локальными сайтами?

№ Нельзя, чтобы диапазоны IP-адресов перекрывались.

Как включить маршрутизацию между VPN-подключением типа «сеть — сеть» и ExpressRoute?

Если вы хотите включить маршрутизацию между ветвью, подключенной к ExpressRoute, и ветвью, подключенной к VPN типа «сеть — сеть», вам необходимо настроить Azure Route Server.

Можно ли использовать шлюз VPN Azure для передачи трафика между локальными сайтами или в другую виртуальную сеть?

Модель развертывания Resource Manager
Да. Дополнительные сведения см. в разделе, посвященном BGP.

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

Создает ли Azure один общий ключ IPsec/IKE для всех VPN-подключений для той же виртуальной сети?

Нет. По умолчанию Azure создает разные общие ключи для разных VPN-подключений. Но можно использовать командлет Set VPN Gateway Key API REST или PowerShell, чтобы задать ключ VPN-шлюза и установить собственное значение ключа. Ключ ДОЛЖЕН содержать только печатные символы ASCII, за исключением пробела, дефиса (-) и тильды (~).

Смогу ли я увеличить пропускную способность, если вместо одной виртуальной сети буду использовать VPN «точка — сеть»?

Нет. Все VPN-туннели, включая VPN «точка — сеть», используют один шлюз VPN Azure и доступную пропускную способность.

Можно ли настроить несколько туннелей между виртуальной сетью и локальным сайтом с помощью VPN с несколькими сайтами?

Да, но необходимо настроить BGP для обоих туннелей к тому же расположению.

Учитывает ли VPN-шлюз Azure путь AS, добавляемый в начало, чтобы повлиять на принятие решений о маршрутизации между несколькими подключениями к моим локальным сайтам?

Да, VPN-шлюз Azure учитывает предустановку пути AS, чтобы помочь принимать решения о маршрутизации при включении BGP. Более короткий путь AS предпочтителен в выборе пути BGP.

Можно ли использовать свойство RoutingWeight при создании нового VPN-подключения VirtualNetworkGateway?

Нет, такой параметр зарезервирован для подключений шлюза ExpressRoute. Если вы хотите повлиять на принятие решений о маршрутизации между несколькими подключениями, необходимо использовать атрибут AS Path.

Можно ли использовать VPN «точка — сеть» с виртуальной сетью с несколькими VPN-туннелями?

Да. VPN «точка — сеть» (P2S) можно использовать с VPN-шлюзами, подключающимися к нескольким локальным сайтам и другим виртуальным сетям.

Можно ли подключить виртуальную сеть с VPN IPsec к каналу ExpressRoute?

Политика IPsec/протокол IKE

Поддерживается ли политика IPsec/IKE во всех номерах SKU VPN-шлюзов Azure?

Пользовательская политика IPsec/IKE поддерживается во всех SKU Azure, за исключением SKU «Базовый».

Сколько политик можно указать для подключения?

Можно указать только одну комбинацию политик для каждого подключения.

Можно ли указать частичную политику для подключения (например, только алгоритмы IKE без IPsec)?

Нет, следует указать все алгоритмы и параметры для IKE (основной режим) и IPsec (быстрый режим). Указать частичную спецификацию политики невозможно.

Какие алгоритмы и уровни стойкости ключей поддерживает настраиваемая политика?

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

IPsec/IKEv2	Options (Параметры)
Шифрование IKEv2	GCMAES256, GCMAES128, AES256, AES192, AES128, DES3, DES
Проверка целостности IKEv2	GCMAES256, GCMAES128, SHA384, SHA256, SHA1, MD5
Группа DH	DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, нет
Шифрование IPsec	GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, нет
Целостность IPsec	GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Группа PFS	PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, нет
Время существования QM SA	(Необязательно — используются значения по умолчанию, если не заданы другие значения.) Секунды (целое число, минимум 300, по умолчанию — 27 000 с) Килобайты (целое число, минимум 1024, по умолчанию — 102 400 000 КБ)
Селектор трафика	UsePolicyBasedTrafficSelectors ($True/$False; необязательно** — по умолчанию используется значение $False, если не задано другое значение.)
Время ожидания обнаружения неиспользуемых одноранговых узлов (DPD)	Секунды (целое число, минимум — 9; максимум — 3600, по умолчанию — 45 секунд)

Ваша конфигурация локальных VPN-устройств должна совпадать со следующими алгоритмами и параметрами, указанными в политике Azure IPsec/IKE, или содержать их.

алгоритм шифрования IKE (основной режим или фаза 1);
алгоритм обеспечения целостности IKE (основной режим или фаза 1);
группа DH (основной режим или фаза 1);
алгоритм шифрования IKE (основной режим или фаза 2);
алгоритм обеспечения целостности IPsec (быстрый режим или фаза 2);
группа PFS (быстрый режим или фаза 2);
селектор трафика (если используется UsePolicyBasedTrafficSelectors).
Время существования SA — это только локальные спецификации, и не нужно соответствовать.

IKE соответствует главному режиму или этапу 1.
IPsec соответствует быстрому режиму или фазе 2;
Группа DH указывает группу Diffie-Hellman, используемую в главном режиме или на этапе 1.
Группа PFS указала группу Diffie-Hellman, используемую в быстром режиме или на этапе 2.

10.1.0.0/16 192.168.0.0/16
10.1.0.0/16 172.16.0.0/16
10.2.0.0/16 192.168.0.0/16
10.2.0.0/16 172.16.0.0/16

Поддерживаемые группы Диффи-Хелмана

В следующей таблице перечислены соответствующие группы Diffie-Hellman, поддерживаемые пользовательской политикой:

Группа Диффи-Хелмана	DHGroup	PFSGroup	Длина ключа
1	DHGroup1	PFS1	MODP (768 бит)
2	DHGroup2	PFS2	MODP (1024 бит)
14	DHGroup14 DHGroup2048	PFS2048	MODP (2048 бит)
19	ECP256	ECP256	ECP (256 бит)
20	ECP384	ECP384	ECP (384 бит)
24	DHGroup24	PFS24	MODP (2048 бит)

Дополнительные сведения см. в статье о группе RFC3526 и RFC5114.

Заменяет ли настраиваемая политика стандартные наборы политик IPsec/IKE для VPN-шлюзов Azure?

Да, когда настраиваемая политика будет указана для подключения, VPN-шлюз Azure будет использовать только политику для подключения как инициатор IKE и отвечающее устройство IKE.

Если удалить настраиваемую политику IPsec/IKE, подключение становится незащищенным?

Нет, подключение будет по-прежнему защищено с помощью IPsec/IKE. После удаления настраиваемой политики из подключения VPN-шлюз Azure вернется к списку предложений IPsec/IKE по умолчанию и возобновит подтверждение IKE для локального VPN-устройства.

Прерывается ли VPN-подключение при добавлении или обновлении политики IPsec/IKE?

Да, это может привести к небольшому прерыванию работы (на несколько секунд), так как VPN-шлюз Azure будет прерывать существующее подключение и повторно запускать подтверждение IKE, чтобы повторно настроить туннель IPsec с новыми алгоритмами и параметрами шифрования. Чтобы минимизировать длительность прерывания, настройте для локального VPN-устройства совпадающие алгоритмы и уровни стойкости ключей.

Можно ли использовать разные политики для разных подключений?

Да. Настраиваемая политика применяется на уровне подключения. Можно создавать и применять разные политики IPsec/IKE для разных подключений. Можно также применять настраиваемые политики к подмножеству подключений. Оставшиеся подключения используют стандартные наборы политик IPsec/IKE Azure.

Можно ли также использовать настраиваемую политику для подключения между виртуальными сетями?

Да, настраиваемую политику можно применять для подключений IPsec между локальными или виртуальными сетями.

Нужно ли указывать одну и ту же политику для обоих ресурсов при подключении между виртуальными сетями?

Да. Туннель подключения между виртуальными сетями состоит из двух ресурсов Azure: для каждого направления используется один ресурс. Обоим ресурсам подключения следует назначить одну и ту же политику, иначе подключение между виртуальными сетями не будет установлено.

Какое значение времени ожидания DPD по умолчанию? Можно ли указать другое время ожидания DPD?

Время ожидания DPD по умолчанию составляет 45 секунд. Можно указать другое значение времени ожидания DPD для каждого подключения IPsec или виртуальной сети к виртуальной сети от 9 до 3600 секунд.

Значение по умолчанию — 45 секунд в VPN-шлюзах Azure. Установка более короткого времени ожидания приведет к более агрессивному переназначению ключей IKE, в результате чего в некоторых экземплярах может наблюдаться разрыв подключения. Это может быть не желательно, если локальные расположения находятся далеко от региона Azure, где находится VPN-шлюз, или когда физическое условие связи может привести к потере пакетов. Общая рекомендация — задать время ожидания от 30 до 45 секунд.

Работает ли настраиваемая политика IPsec/IKE для подключения ExpressRoute?

№ Политика IPsec/IKE работает только для VPN-подключений типа «сеть — сеть» или «виртуальная сеть — виртуальная сеть» через VPN-шлюзы Azure.

Как создавать подключения с типом протокола IKEv1 или IKEv2?

Подключения IKEv1 можно создавать во всех SKU с VPN типа RouteBased, кроме SKU уровня «Базовый» и «Стандартный» и других устаревших SKU. При создании подключения можно указать тип протокола IKEv1 или IKEv2. Если тип протокола не указан, по умолчанию используется тип IKEv2 (там, где это применимо). Дополнительные сведения см. в документации по командлетам PowerShell. Сведения о типах SKU и поддержке протоколов IKEv1 и IKEv2 см. в статье о подключении шлюзов к VPN-устройствам на базе политик.

Можно ли перейти с подключения IKEv1 на IKEv2 и обратно?

Да. Переход между типами подключений IKEv1 и IKEv2 поддерживается.

Можно ли использовать межсайтовые подключения IKEv1 на SKU категории «Базовый» с VPN типа RouteBased?

№ Ценовая категория «Базовый» не поддерживает эту возможность.

Можно ли сменить тип протокола после создания подключения (с IKEv1 на IKEv2 или обратно)?

№ Изменить тип протокола IKEv1 или IKEv2 после создания подключения невозможно. Вам потребуется удалить и снова создать подключение с протоколом нужного типа.

Почему подключение IKEv1 часто теряется и восстанавливается?

Если подключение IKEv1 со статической маршрутизацией или на основе маршрутов отключается через регулярные интервалы, это может быть связано с тем, что VPN-шлюзы не поддерживают переназначение ключей без отключения. Когда выполняется переназначение ключей для основного режима, туннели IKEv1 будут отключены и подключены снова, что может потребовать до 5 секунд. Значение времени ожидания в режиме основного режима определяет частоту повторного использования. Чтобы предотвратить такие повторные подключения, переключитесь на использование протокола IKEv2, который поддерживает переназначение ключей без отключения.

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

Где можно найти сведения о конфигурации и шаги?

Дополнительные сведения и действия по настройке см. в следующих статьях.

Настройка политики IPsec/IKE для подключений S2S или виртуальной сети к виртуальной сети — портал Azure
Настройка политики IPsec/IKE для подключений S2S или виртуальной сети к виртуальной сети — Azure PowerShell

BGP и маршрутизация

VPN-шлюзы Azure поддерживают BGP для всех классов SKU?

Протокол BGP поддерживается для всех SKU VPN-шлюза Azure, за исключением SKU уровня «Базовый».

Можно ли использовать BGP с VPN-шлюзами на основе Политики Azure?

Нет, BGP поддерживает только VPN-шлюзы с управлением на основе маршрута.

Какие номера ASN можно использовать?

Вы можете использовать собственные общедоступные или частные ASN как для локальных сетей, так и для виртуальных сетей Azure. Диапазоны, зарезервированные Azure или IANA, использовать нельзя.

Следующие номера ASN зарезервированы для Azure и IANA.

Номера ASN, зарезервированные для Azure:
- Общедоступные ASN: 8074, 8075, 12076.
- Частные ASN: 65515, 65517, 65518, 65519, 65520.
- 23456, 64496-64511, 65535-65551 и 429496729.
При подключении к VPN-шлюзам Azure эти номера ASN нельзя указывать для локальных VPN-устройств.

Можно ли использовать 32-разрядный (4-байтовый) номер ASN?

Да, VPN-шлюз теперь поддерживает 32-разрядный (4-байтовый) номер ASN. Чтобы выполнить настройку с помощью ASN в десятичном формате, используйте PowerShell, Azure CLI или пакет Azure SDK.

Какие частные ASN можно использовать?

Доступные диапазоны частных ASN:
- 64512–65514 и 65521–65534
Эти ASN не зарезервированы для использования IANA или Azure, поэтому их можно назначить VPN-шлюзу Azure.

Какой адрес VPN-шлюз использует в качестве IP-адреса узла BGP?

По умолчанию VPN-шлюз выделяет из диапазона GatewaySubnet один IP-адрес для VPN-шлюзов в режиме «активный — резервный» или два IP-адреса для VPN-шлюзов в режиме «активный — активный». Эти адреса выделяются автоматически при создании VPN-шлюза. Вы можете получить фактический выделенный IP-адрес BGP с помощью PowerShell или на портале Azure. В PowerShell используйте Get-AzVirtualNetworkGateway и найдите свойство bgpPeeringAddress. На портале Azure на странице Конфигурация шлюза просмотрите свойство Настройка BGP ASN.

Если локальные маршрутизаторы VPN используют IP-адреса APIPA (169.254.x.x) в качестве IP-адресов BGP, необходимо указать один или более IP-адресов BGP APIPA Azure на VPN-шлюзе Azure. VPN-шлюз Azure выберет адреса APIPA для использования с локальным узлом BGP APIPA, указанным в шлюзе локальной сети, или частным IP-адресом для локального узла BGP, не связанного с APIPA. См. статью Настройка BGP на VPN-шлюзах Azure.

Каковы требования к IP-адресам узла BGP на VPN-устройстве?

Локальный узел BGP не должен иметь общедоступный IP-адрес VPN-устройства или входить в диапазон IP-адресов виртуальной сети VPN-шлюза. Используйте в качестве IP-адреса узла BGP другой IP-адрес VPN-устройства. Это может быть адрес, назначенный интерфейсу внутреннего замыкания на устройстве (обычный IP-адрес или адрес APIPA). Если устройство использует для BGP адрес APIPA, необходимо указать один или несколько IP-адресов BGP APIPA на VPN-шлюзе Azure, как описано в статье Настройка BGP. Укажите эти адреса на локальном сетевом шлюзе, который представляет это расположение.

Что нужно указать в качестве префикса адреса локального сетевого шлюза, если используется BGP?

Это изменение из задокументированного ранее требования. При использовании BGP для подключения следует оставить поле Адресное пространство пустым для соответствующего ресурса шлюза локальной сети. VPN-шлюз Azure добавит маршрут узла в IP-адрес локального узла BGP через туннель IPsec. Не добавляйте маршрут /32 в поле Диапазон адресов. Он является избыточным. Если вы используете адрес APIPA в качестве IP-адреса BGP VPN-устройства, его нельзя добавлять в это поле. Другие префиксы будут добавлены в поле Диапазон адресов как статические маршруты на VPN-шлюзе Azure, наряду с маршрутами, полученными через BGP.

Можно ли использовать один номер ASN одновременно для локальных VPN-сетей и виртуальных сетей Azure?

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

Какие префиксы адресов будут объявлять для меня VPN-шлюзы Azure?

VPN-шлюз объявляет следующие маршруты для локальных устройств BGP:
- префиксы адресов виртуальной сети;
- префиксы адресов от каждого из локальных сетевых шлюзов, подключенных к VPN-шлюзу Azure;
- маршруты, полученные от сеансов пиринга BGP с другими устройствами, подключенными к VPN-шлюзу Azure, за исключением маршрута по умолчанию и маршрутов, пересекающихся с префиксами любой виртуальной сети.
Сколько префиксов можно объявлять VPN-шлюзу Azure?

VPN-шлюз Azure поддерживает до 4000 префиксов. Если количество префиксов превысит лимит, сеанс BGP будет сброшен.

Можно ли объявить маршрут по умолчанию (0.0.0.0/0) к VPN-шлюзам Azure?

Да. Обратите внимание, что в результате весь исходящий трафик виртуальной сети будет направлен на локальный сайт. Кроме того, виртуальные машины в виртуальной сети не смогут принимать общедоступный трафик из Интернета напрямую, например RDP или SSH из Интернета на виртуальные машины.

Можно ли объявить точно такие же префиксы, как в моей виртуальной сети?

Нет. Azure будет блокировать или фильтровать объявление таких же префиксов, как префиксы адреса виртуальной сети. Тем нее менее вы можете объявить префикс, который представляет собой супермножество адресов внутри виртуальной сети.

Например, если ваша виртуальная сеть использует адресное пространство 10.0.0.0/16, вы можете объявить 10.0.0.0/8. При этом нельзя объявлять 10.0.0.0/16 или 10.0.0.0/24.

Можно ли использовать BGP с подключениями между виртуальными сетями?

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

Можно ли сочетать подключения с BGP и подключения без BGP на VPN-шлюзах Azure?

Да, вы можете использовать подключения с BGP и без BGP на одном VPN-шлюзе Azure.

Поддерживает ли VPN-шлюз Azure транзитную маршрутизацию BGP?

Да, транзитная маршрутизация BGP поддерживается, но с одним исключением: VPN-шлюзы Azure не будут объявлять маршруты по умолчанию для других узлов BGP. Чтобы включить транзитную маршрутизацию между несколькими VPN-шлюзами Azure, необходимо включить BGP на всех промежуточных подключениях между виртуальными сетями. Дополнительные сведения см. в статье Обзор использования BGP с VPN-шлюзами Azure.

Можно ли создать несколько туннелей между VPN-шлюзом Azure и локальной сетью?

Да, вы можете создать несколько VPN-туннелей типа «сеть – сеть» (S2S) между VPN-шлюзом Azure и локальной сетью. Обратите внимание, что все эти туннели будут учитываться в общем числе туннелей на ваших VPN-шлюзах Azure. Кроме того, вы должны включить BGP для обоих туннелей.

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

Можно ли создать несколько туннелей между двумя виртуальными сетями Azure с использованием BGP?

Да, но хотя бы один из шлюзов виртуальной сети должен быть в конфигурации «активный — активный».

Можно ли использовать BGP для S2S VPN в конфигурации сосуществования ExpressRoute и S2S VPN?

Что следует добавить в настройки локального VPN-устройства для сеансов пиринга BGP?

Добавьте маршрут узла для IP-адреса узла BGP Azure на VPN-устройство. Этот маршрут указывает на туннель S2S VPN IPsec. Например если IP-адрес VPN-узла Azure имеет значение 10.12.255.30, добавьте для адреса 10.12.255.30 узловой маршрут, в котором интерфейсом следующего прыжка будет соответствующий интерфейс туннелирования IPsec на VPN-устройстве.

Поддерживает ли шлюз виртуальной сети BFD для подключений S2S с BGP?

№ Двухнаправленное обнаружение перенаправления (BFD) — это протокол, который можно использовать с BGP для определения времени простоя в соседних странах быстрее, чем при использовании стандартной проверки активности BGP («keepalives»). BFD использует таймеры с точностью измерения до доли секунды, предназначенные для работы в среде LAN, но не с подключениями через общедоступный Интернет или глобальную сеть.

Для подключений через общедоступный Интернет задержка отправки или даже удаление определенных пакетов не является необычным, поэтому внедрение этих агрессивных таймеров приведет к нестабильной работе. Такая нестабильность может привести к подавлению маршрутов протоколом BGP. В качестве альтернативы можно настроить локальное устройство с таймерами с частотой проверки активности менее 60 секунд и таймером удержания на 180 секунд. Это приводит к ускоренной конвергенции. Тем не менее таймеры ниже интервала хранения по умолчанию 60 секунд или ниже таймера хранения по умолчанию 180 секунд не являются надежными. Рекомендуется хранить таймеры в значениях по умолчанию или выше.

Инициируют ли VPN-шлюзы Azure сеансы пиринга или подключения BGP?

Шлюз инициирует сеансы пиринга BGP к локальным IP-адресам однорангового узла BGP, указанным в ресурсах шлюза локальной сети, используя частные IP-адреса vpn-шлюзов. Это не зависит от того, находятся ли локальные IP-адреса BGP в диапазоне APIPA или являются обычными частными IP-адресами. Если ваши локальные VPN-устройства используют адреса APIPA в качестве IP-адресов BGP, для инициирования подключений вам нужно настроить узел BGP.

Можно ли настроить принудительное туннелирование?

NAT

VPN-шлюзы Azure поддерживают NAT для всех классов SKU?

NAT поддерживается на VpnGw2~5 и VpnGw2AZ~5AZ.

Можно ли использовать NAT при подключении между виртуальными сетями или P2S?

Нет, NAT поддерживается только для распределенных подключений IPsec.

Сколько правил NAT можно использовать на VPN-шлюзе?

На VPN-шлюзе можно создать до 100 правил NAT (сочетание правил для входящего и исходящего трафика).

Можно ли использовать /в имени правила NAT?

№ Вы получите сообщение об ошибке.

Применяется ли NAT ко всем подключениям на VPN-шлюзе?

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

Какие типы NAT поддерживаются на VPN-шлюзах Azure?

Поддерживаются только статическое преобразование NAT 1:1 и динамическое преобразование NAT. NAT64 НЕ поддерживается.

Работает ли NAT на VPN-шлюзах «активный — активный»?

Да. NAT работает как в режиме «активный — активный», так и на VPN-шлюзах в режиме «в сети». Каждое правило NAT применяется к одному экземпляру VPN-шлюза. В шлюзах active-active создайте отдельное правило NAT для каждого экземпляра шлюза с помощью поля «Идентификатор конфигурации IP».

Работает ли NAT с подключениями BGP?

Да, можно использовать NAT для подключений BGP. Ниже приведены некоторые важные сведения.
- Выберите Включить преобразование маршрутов BGP на странице «Конфигурация правил NAT», чтобы полученные маршруты и объявляемые маршруты преобразовывались в префиксы адресов после NAT (внешние сопоставления) на основе правил NAT, связанных с соединениями. Необходимо убедиться, что локальные маршрутизаторы BGP объявляют точные префиксы, как определено в правилах IngressSNAT.
- Если локальный VPN-маршрутизатор использует обычный, не APIPA-адрес и сталкивается с адресным пространством виртуальной сети или другими локальными сетевыми пространствами, убедитесь, что правило IngressSNAT преобразует ОДНОранговый IP-адрес BGP в уникальный, не перекрывающийся адрес и помещает адрес после NAT в поле IP-адреса однорангового ip-адреса BGP шлюза локальной сети.
- NAT не поддерживается с адресами APIPA BGP.
Нужно ли создавать правила DNAT, соответствующие правилу SNAT?

№ Одно правило SNAT определяет преобразование для обоих направлений в конкретной сети.
- Правило IngressSNAT определяет преобразование исходных IP-адресов, поступающих в VPN-шлюз Azure из локальной сети. Он также обрабатывает перевод конечных IP-адресов, покидающих виртуальную сеть в ту же локальную сеть.
- Правило EgresSNAT определяет преобразование IP-адресов источника виртуальной сети, оставляя VPN-шлюз Azure в локальные сети. Он также обрабатывает преобразование конечных IP-адресов для пакетов, поступающих в виртуальную сеть через эти подключения с правилом EgressSNAT.
- Ни в одном из этих случаев правила DNAT не требуются.
Что делать, если адресное пространство для виртуальной сети или шлюза локальных сетей имеет два или более префикса? Можно ли применить NAT ко всем ним? Или только к подмножеству?

Необходимо создать по одному правилу NAT для каждого префикса, который требуется для преобразования сетевых адресов (NAT), так как каждое правило NAT может включать только один префикс адреса для NAT. Например, если адресное пространство шлюза локальной сети состоит из 10.0.1.0/24 и 10.0.2.0/25, можно создать два правила, как показано ниже.
- Правило IngressSNAT 1: сопоставление 10.0.1.0/24 и 100.0.1.0/24
- Правило IngressSNAT 2: сопоставление 10.0.2.0/25 и 100.0.2.0/25
Эти два правила должны соответствовать длинам префиксов соответствующих адресов. Это же относится к правилам EgresSNAT для адресного пространства виртуальной сети.

Если привязать к указанному выше подключению только одно правило, второе адресное пространство НЕ будет преобразовано.

Какие диапазоны IP-адресов можно использовать для внешнего сопоставления?

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

Можно ли использовать различные правила EgressSNAT для преобразования адресного пространства виртуальной сети в разные префиксы для разных локальных сетей?

Да, можно создать несколько правил EgressSNAT для одного адресного пространства виртуальной сети и применять правила EgressSNAT к разным подключениям.

Можно ли использовать одно правило IngressSNAT для разных подключений?

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

Нужно ли создавать для подключения NAT правила как для входящего, так и исходящего трафика?

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

Что нужно выбрать в качестве идентификатора IP-конфигурации?

«Идентификатор IP-конфигурации» — это просто имя объекта IP-конфигурации, который будет использоваться правилом NAT. С помощью этого параметра вы просто выбираете, какой общедоступный IP-адрес шлюза применяется к правилу NAT. Если вы не указали пользовательское имя во время создания шлюза, основной IP-адрес шлюза назначается IPconfiguration по умолчанию, а дополнительный IP-адрес назначается IPconfiguration «activeActive».

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

Если моя виртуальная машина находится в виртуальной сети с распределенным подключением, как следует подключаться к виртуальной машине?

Есть несколько вариантов. Если вы включили протокол удаленного рабочего стола для виртуальной машины, вы можете подключиться к виртуальной машине с помощью частного IP-адреса. В этом случае нужно указать частный IP-адрес и порт, к которому вы хотите подключиться (обычно 3389). Необходимо настроить на виртуальной машине порт для трафика.

Можно также подключиться к виртуальной машине с помощью частного IP-адреса с другой виртуальной машины, расположенной в той же виртуальной сети. Подключиться к виртуальной машине по протоколу удаленного рабочего стола, используя частный IP-адрес, если вы подключаетесь из расположения за пределами вашей виртуальной сети,невозможно. Например, если у вас настроена виртуальная сеть «точка — сеть», но подключение с вашего компьютера не установлено, вы не сможете подключиться к виртуальной машине с помощью частного IP-адреса.

Если виртуальная машина находится в виртуальной сети с распределенным подключением, проходит ли весь трафик с моей виртуальной машины через это подключение?

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

Устранение неполадок подключения к виртуальной машине через протокол удаленного рабочего стола

Если у вас возникли проблемы с подключением к виртуальной машине через VPN-подключение, проверка следующие элементы:
- Убедитесь, что вы используете активное VPN-подключение.
- Убедитесь, что подключаетесь к частному IP-адресу виртуальной машины.
- Если вы можете подключиться к виртуальной машине с помощью частного IP-адреса, но не имени компьютера, проверьте, правильно ли настроено имя DNS. Дополнительные сведения о том, как работает разрешение имен для виртуальных машин, см. в статье Разрешение имен для ВМ и экземпляров ролей.
При подключении типа «точка — сеть» проверьте следующие дополнительные элементы.
- Используйте ipconfig, чтобы проверить IPv4-адрес, назначенный Ethernet-адаптеру на компьютере, с которого выполняется подключение. Если IP-адрес находится в диапазоне адресов виртуальной сети, к которому вы подключаетесь, или в диапазоне адресов VPNClientAddressPool, это называется перекрывающимся адресным пространством. В таком случае сетевой трафик не достигает Azure и остается в локальной сети.
- Убедитесь, что пакет конфигурации VPN-клиента был создан после указания IP-адресов DNS-сервера для виртуальной сети. Если вы обновили IP-адреса DNS-сервера, создайте и установите новый пакет конфигурации VPN-клиента.
Дополнительные сведения об устранении неполадок при подключении RDP см. в статье Устранение неполадок с подключением к виртуальной машине Azure через удаленный рабочий стол.

Обслуживание шлюза, управляемого клиентом

Какие службы включены в конфигурацию обслуживания область сетевых шлюзов?

Сетевые шлюзы область включают ресурсы шлюза в сетевых службах. В сетевых шлюзах область четыре типа ресурсов:
- Шлюз виртуальной сети в службе ExpressRoute.
- Шлюз виртуальной сети в службе VPN-шлюз.
- VPN-шлюз (сеть — сеть) в службе Виртуальная глобальная сеть.
- Шлюз ExpressRoute в службе Виртуальная глобальная сеть.
Какое обслуживание поддерживается или не поддерживается управляемым клиентом обслуживанием?

Службы Azure проходят периодические обновления обслуживания для улучшения функциональности, надежности, производительности и безопасности. После настройки периода обслуживания для ресурсов в этом окне выполняется обслуживание гостевой ОС и службы. Обновления узлов, помимо обновлений узла (TOR, Power и т. д.) и критически важных обновлений системы безопасности, не охватываются обслуживанием, контролируемым клиентом.

Можно ли получить расширенное уведомление об обслуживании?

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

Можно ли настроить период обслуживания менее пяти часов?

В настоящее время необходимо настроить как минимум пять часового периода в предпочтительном часовом поясе.

Можно ли настроить период обслуживания, отличный от ежедневного расписания?

В настоящее время необходимо настроить период ежедневного обслуживания.

Существуют ли случаи, когда не удается контролировать определенные обновления?

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

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

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

Какие номера SKU шлюза можно настроить для использования обслуживания, управляемого клиентом?

Все номера SKU шлюза (кроме номера SKU basic для VPN-шлюз) можно настроить для использования обслуживания, управляемого клиентом.

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

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

Существуют ли ограничения на использование управляемого клиентом обслуживания на основе общедоступного IP-адреса SKU уровня «Базовый»?

Да. Ресурсы шлюза, использующие общедоступный IP-адрес SKU уровня «Базовый», смогут обновлять службы только после расписания обслуживания, управляемого клиентом. Для этих шлюзов обслуживание гостевой ОС не соответствует расписанию обслуживания, управляемому клиентом, из-за ограничений инфраструктуры.

Как запланировать периоды обслуживания при использовании VPN и ExpressRoute в сценарии сосуществования?

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

Я запланировал период обслуживания для следующей даты для одного из моих ресурсов. Будут ли действия по обслуживанию приостановлены на этом ресурсе до тех пор?

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

Разделы справки узнать больше о обслуживании шлюза, управляемом клиентом?

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

Следующие шаги
- Дополнительные сведения о VPN-шлюзах см. в этой статье.
- Дополнительные сведения о параметрах конфигурации VPN-шлюза см. в этой статье.
OpenVPN является товарным знаком OpenVPN Inc.

Настраиваем VPN на Mikrotik CHR

Ранее мы писали про установку и базовую настройку Mikrotik CHR на виртуальные серверы. В этой статье мы выполним настройку VPN-сервера на базе Cloud Hosted Router и подключим клиентские устройства к настроенному VPN. При написании данной статьи использовался облачный сервер со следующими характеристиками: 1 vCPU; 512 МБ RAM; 5 ГБ быстрый диск. Операционной системой выбрана актуальная […]

Ранее мы писали про установку и базовую настройку Mikrotik CHR на виртуальные серверы. В этой статье мы выполним настройку VPN-сервера на базе Cloud Hosted Router и подключим клиентские устройства к настроенному VPN.

При написании данной статьи использовался облачный сервер со следующими характеристиками:
- 1 vCPU;
- 512 МБ RAM;
- 5 ГБ быстрый диск.
Операционной системой выбрана актуальная на момент написания статьи Stable-версия RouterOS: 6.47.6. Мы предполагаем, что читатель уже установил MikroTik CHR и провел первичную настройку.

Несмотря на то, что в статье описана настройка на Cloud Hosted Router, эта инструкция может использоваться и для физических маршрутизаторов с RouterOS.

Общие настройки

Создание пула IP-адресов

При подключении к VPN клиент «входит» в локальную сеть с VPN-сервером. Это требует серой подсети и списка доступных для клиента адресов, называемых пул. Создать пул можно следующей командой:
```
/ip pool add name= ranges=
```
Мы выделили 253 адресов в подсети 172.24.0.0/24 и назвали ее vpn-pool.
```
/ip pool add name=vpn-pool ranges=172.24.0.1-172.24.0.253
```
Обратите внимание, что адрес 172.24.0.254 не входит в пул адресов, так как этот адрес будет принадлежать VPN-серверу и не должен быть выделен клиенту.

Создание PPP-профиля

«Связать» пул адресов для клиентов и адрес VPN-сервера можно с помощью PPP-профиля. Используем следующую команду:
```
/ppp profile add name=vpn-profile local-address=172.24.0.254 remote-address=vpn-pool use-mpls=no use-compression=yes use-encryption=yes only-one=no
```
Рассмотрим параметры команды:
- name=vpn-profile — задаем имя профиля;
- local-address=172.24.0.254 — задаем адрес VPN-сервера;
- remote-address=vpn-pool — указываем использовать пул vpn-pool для выдачи адресов клиентам;
- use-mpls=no — не используем MultiProtocol Label Switching;
- use-compression=yes — включаем сжатие трафика;
- use-encryption=yes — включаем шифрование;
- only-one=no — разрешаем более одного одновременного подключения для пользователя.
Настройка NAT

Создать локальную сеть между VPN-сервером и VPN-клиентом — это половина проблемы. Далее необходимо разрешить клиенту выходить в интернет через VPN-подключение. Для этого необходимо настроить NAT. Сделать это можно следующей командой:
```
/ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade
```
Создание пользователя

Далее создаем пользователя. Сделать это можно следующей командой:
```
/ppp secret add name= password= service=
```
Параметр service определяет, какие сервисы доступны пользователю. Мы планируем использовать пользователя для демонстрации четырех протоколов VPN, поэтому установим значение any. Создаем пользователя vpn-user с паролем vpn-password с доступом к любому сервису:
```
/ppp secret add name=vpn-user password=vpn-password service=any
```
Пользователь создан. Однако, некоторые VPN-протоколы требуют сертификатов.

Генерация сертификатов сервера

Если вы планируете использовать OpenVPN или SSTP, то со стороны сервера требуются два сертификата: CA (Certification authority, Центр Сертификации) и серверный (server). Первый сертификат является «неоспоримым» и им можно подтверждать самоподписанные сертификаты, созданные для сервера и для клиентов.

Сперва выберем Common Name (CN) для центра сертификации. Здесь нет специфических требований, поэтому допустимо использовать любое имя. Мы используем имя хоста в качестве CN. В параметре ca-crl-host необходимо указать IP-адрес или домен VPN-сервера.
```
/certificate add name=ca-template common-name="MikroTik" days-valid=3650 key-usage=crl-sign,key-cert-sign /certificate sign ca-template ca-crl-host=185.X.X.83 name="MikroTik"
```
Далее создаем сертификат для VPN-сервера и подписываем его только созданным CA-сертификатом. Обратите внимание, что CN для сертификата сервера должен быть строго доменом или IP-адресом.
```
/certificate add name=server-template common-name=185.X.X.83 days-valid=3650 key-usage=digital-signature,key-encipherment,tls-server /certificate sign server-template ca="MikroTik" name="server@MikroTik"
```
Для протокола SSTP значение поля CN является критичным. Если CN является IP-адресом, то VPN-клиенту нужно подключаться именно по IP-адресу. При подключении по домену произойдет ошибка.

Сертификат CA необходимо экспортировать, чтобы клиент доверял сертификату сервера. Файл:
```
/certificate export-certificate "MikroTik" export-passphrase=""
```
После экспорта на вкладке Files в веб-интерфейсе можно будет скачать файл cert_export_MikroTik.crt. Сохраните его, он потребуется далее.

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

Мы рассмотрим четыре протокола для организации VPN:

Каждый из протоколов обладает своими плюсами и минусами. Рассмотрим протоколы поближе.

PPTP

Начнем с самого легкого в настройке протокола Point-to-Point Tunneling Protocol (PPTP). Данный протокол не требует большого количества вычислительных ресурсов и поддерживается «из коробки» множеством операционных систем. Среди минусов — наличие серьезных уязвимостей в протоколах аутентификации.

Запустить VPN-сервер можно в одну команду:
```
/interface pptp-server server set enabled=yes default-profile=vpn-profile authentication=mschap2
```
В качестве клиента возьмем смартфон под управлением ОС Android 8.0.0.

Подключение по PPTP не требует дополнительного программного обеспечения и не доставляет проблем. Однако, если хочется чуть больше безопасности, то следует посмотреть в сторону протоколов L2TP/IPsec.

L2TP/IPSec

Как и PPTP, протоколы L2TP/IPsec поддерживаются большим количеством операционных систем. Более того, используемый в IPsec алгоритм шифрования AES на данный момент не имеет серьезных уязвимостей, что гарантирует относительную безопасность и конфиденциальность при использовании L2TP/IPsec.

Настройка L2TP/IPsec VPN-сервера похожа на настройку PPTP-сервера:
```
/interface l2tp-server server set enabled=yes default-profile=vpn-profile authentication=mschap2 use-ipsec=required ipsec-secret=super-secret
```
Обратите внимание на параметр ipsec-secret. Этот параметр — общий ключ IPsec. Так как мы используем аутентификацию по паре логин/пароль без сертификата, то в настройках клиента необходимо выбирать L2TP/IPsec PSK или L2TP/IPsec с общим ключом.

Хотя L2TP/IPsec является хорошим компромиссом, стоит оценить и OpenVPN.

OpenVPN

OpenVPN — современная технология с открытым исходным кодом. Данное решение предоставляет безопасность, высокую скорость работы и умение маскироваться под HTTPS-трафик. К сожалению, для использования OpenVPN необходимо устанавливать дополнительное программное обеспечение, например, официальный OpenVPN Connect, а также работать с сертификатами и конфигурационными файлами ovpn.

Включаем OpenVPN-сервер с указанием серверного сертификата, который сгенерировали ранее:
```
/interface ovpn-server server set auth=sha1 certificate="server@MikroTik" cipher=aes128,aes192,aes256 default-profile=vpn-profile enabled=yes require-client-certificate=yes
```
Создаем шаблон клиентского сертификата:
```
/certificate add name=client-template common-name="client" days-valid=3650 key-usage=tls-client
```
Генерируем сертификат для пользователя vpn-user на основе шаблона:
```
/certificate add name=client-vpn-user copy-from=client-template common-name="vpn-user@MikroTik" /certificate sign client-vpn-user ca="MikroTik" name="vpn-user@MikroTik"
```
Экспортируем сертификат и ключ. Обратите внимание, что пароль во время экспортирования указан пароль super-secret-password, который необходимо будет ввести при импорте в VPN-клиенте.
```
/certificate export-certificate "vpn-user@MikroTik" export-passphrase="super-secret-password"
```
В веб-интерфейсе на вкладке Files можно найти следующие файлы:
- cert_export_vpn-user@MikroTik.crt;
- cert_export_vpn-user@MikroTik.key.
Скачиваем указанные файлы и составляем конфигурационный файл ovpn:
```
client dev tun proto tcp-client remote 1194 nobind persist-key persist-tun cipher AES-128-CBC auth SHA1 pull verb 2 mute 3 auth-user-pass # Добавляем эту строчку, чтобы отправлять все запросы через VPN redirect-gateway def1 # Вставляем содержимое cert_export_MikroTik.crt # Вставляем содержимое cert_export_vpn-user@MikroTik.crt # Вставляем содержимое cert_export_vpn-user@MikroTik.key 
```
Передаем ovpn-файл на смартфон и импортируем его через OpenVPN Connector.

В качестве Private Key Password используем пароль, указанный при экспортировании. Данные пользователя для подключения остались неизменными.

SSTP

SSTP — это проприетарный протокол от Microsoft, обладающий достоинствами OpenVPN. Данный протокол поддерживается ОС Microsoft Windows, начиная с Vista SP1, а на других ОС требует установки дополнительного ПО.

Для запуска сервера достаточно выполнить одну команду:
```
/interface sstp-server server set enabled=yes certificate=server@MikroTik default-profile=vpn-profile
```
Так как данный протокол поддерживается Windows, то проверим работу сервера на Windows 10. В первую очередь необходимо установить центр сертификации. Скачиваем cert_export_MikroTik.crt и открываем двойным кликом.

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

Открываем Параметры Windows — Сеть и Интернет — VPN и добавляем VPN-подключение, вводим имя или адрес сервера как было указано в сертификате сервера и вводим свои логин-пароль. VPN-подключение установлено.

Заключение

Мы рассмотрели настройку VPN-серверов на четырех разных протоколах. Надеемся, что эта инструкция поможет вам создать собственный виртуальный маршрутизатор на базе Mikrotik CHR.
Похожие публикации: