Требования к шифрованию и VPN-шлюзы Azure
В этой статье рассказывается, как можно настроить VPN-шлюзы Azure для удовлетворения требований к шифрованию для распределенных VPN-туннелей S2S и подключений между виртуальными сетями в Azure.
Сведения о IKEv1 и IKEv2 для VPN-подключений Azure
Обычно мы разрешаем подключения по протоколу IKEv1 только для SKU уровня "Базовый", а подключения по протоколу IKEv2 — для всех SKU VPN-шлюзов, кроме SKU уровня "Базовый". SKU уровня "Базовый" допускают только 1 подключение, а также имеют другие ограничения, такие как ограниченная производительность; также с ограниченными возможностями сталкиваются клиенты, использующие устаревшие устройства, которые поддерживают только протоколы IKEv1. Чтобы улучшить взаимодействие с клиентами с помощью протоколов IKEv1, теперь мы разрешаем подключения IKEv1 для всех номеров SKU VPN-шлюза, кроме номера SKU "Базовый". Дополнительные сведения см. в разделе SKU VPN-шлюзов. Обратите внимание, что VPN-шлюзы с протоколом IKEv1 могут столкнуться с повторным подключением туннеля во время операций переназначения ключа для основного режима.
Когда подключения IKEv1 и IKEv2 применяются к одному VPN-шлюзу, транзит между этими двумя подключениями автоматически задается.
Параметры политики IPsec и IKE для VPN-шлюзов Azure
Стандарт протоколов IPsec и IKE поддерживает широкий набор алгоритмов шифрования в различных сочетаниях. Если не запросить конкретную комбинацию алгоритмов шифрования и параметров, VPN-шлюзы Azure используют набор предложений по умолчанию. Наборы политик по умолчанию были выбраны, чтобы обеспечить максимально эффективное взаимодействие с широким диапазоном VPN-устройств сторонних производителей в конфигурациях по умолчанию. Соответственно, такие политики и количество предложений не могут охватывать все возможные сочетания доступных алгоритмов шифрования и значений длины ключа.
Политика по умолчанию
Набор политик по умолчанию для VPN-шлюза Azure приведен в статье: VPN-устройства и параметры IPsec/IKE для подключений типа "сеть-сеть" через VPN-шлюз.
Требования к шифрованию
Для операций обмена данными, требующих определенные алгоритмы шифрования или параметры (обычно из-за требований к соответствию или к безопасности), вы теперь можете настроить для своих VPN-шлюзов Azure использование настраиваемой политики IPsec/IKE с конкретными алгоритмами шифрования и значениями длины ключа, вместо выбора наборов политик Azure по умолчанию.
Например, политики основного режима IKEv2 для VPN-шлюзов Azure используют только группу Диффи-Хелмана 2 (1024 бит), тогда как вам может потребоваться указать более надежные группы для использования в IKE, такие как группа 14 (2048 бит), группа 24 (группа MODP 2048 бит) или ECP (группы на основе эллиптических кривых) 256 и 384 бит (группы 19 и 20, соответственно). Аналогичные требования также применяются к политикам быстрого режима IPsec.
Пользовательская политика IPsec/IKE с VPN-шлюзами Azure
VPN-шлюзы Azure теперь поддерживают настраиваемые политики IPsec/IKE, задаваемые для отдельных подключений. Для подключения типа "сеть — сеть" или "виртуальная сеть — виртуальная сеть" вы можете выбрать определенное сочетание алгоритмов шифрования IPsec и IKE с требуемой надежностью ключа, как показано в примере ниже:
Можно создать политику IPsec/IKE и применить ее к существующему или новому подключению.
Рабочий процесс
- Создайте виртуальные сети, VPN-шлюзы или шлюзы локальной сети для топологии подключения, как описано в других документах.
- Создайте политику IPsec/IKE.
- Политику можно применить при создании подключения S2S или виртуальной сети к виртуальной сети.
- Если подключение уже создано, можно применить или обновить политику для существующего подключения.
Часто задаваемые вопросы о политике IPsec/IKE
Поддерживается ли настраиваемая политика IPsec/IKE для всех номеров SKU VPN-шлюз Azure?
Настраиваемая политика IPsec/IKE поддерживается во всех SKU Azure VPN-шлюз, кроме номера SKU "Базовый".
Сколько политик можно указать для подключения?
Для подключения можно указать только одну комбинацию политик.
Можно ли указать частичную политику подключения (например, только алгоритмы IKE, но не IPsec)?
Нет, следует указать все алгоритмы и параметры для IKE (основной режим) и IPsec (быстрый режим). Указать частичную спецификацию политики невозможно.
Какие алгоритмы и ключевые преимущества поддерживают пользовательскую политику?
В следующей таблице перечислены поддерживаемые алгоритмы шифрования и преимущества ключей, которые можно настроить. Необходимо выбрать один вариант для каждого поля.
| IPsec/IKEv2 | Параметры |
|---|---|
| Шифрование IKEv2 | GCMAES256, GCMAES128, AES256, AES192, AES128 |
| Целостность IKEv2 | 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, нет |
| Время существования SA в режиме быстрого режима | (Необязательно; значения по умолчанию, если они не указаны) Секунды (целое число; минимум 300, по умолчанию 27 000) Килобайты (целое число; минимум 1024, по умолчанию 10 2400 000) |
| Селектор трафика | UsePolicyBasedTrafficSelectors ($True или $False, но необязательно; значение по умолчанию $False , если не указано) |
| Время ожидания обнаружения неиспользуемых одноранговых узлов (DPD) | Секунды (целое число; минимум 9, максимум 3600, по умолчанию 45) |
Конфигурация локального VPN-устройства должна соответствовать или содержать следующие алгоритмы и параметры, указанные в политике Azure IPsec или IKE:
- Алгоритм шифрования IKE (основной режим, этап 1)
- Алгоритм целостности IKE (основной режим, этап 1)
- Группа DH (основной режим, этап 1)
- Алгоритм шифрования IPsec (быстрый режим, этап 2)
- Алгоритм целостности IPsec (быстрый режим, этап 2)
- Группа PFS (быстрый режим, этап 2)
- Селектор трафика (при использовании
UsePolicyBasedTrafficSelectors) - Время существования SA (локальные спецификации, которые не должны соответствовать)
При использовании GCMAES для алгоритма шифрования IPsec необходимо выбрать тот же алгоритм GCMAES и длину ключа для целостности IPsec. Например, используйте GCMAES128 для обоих.
В таблице алгоритмов и ключей:
- IKE соответствует главному режиму или этапу 1.
- IPsec соответствует быстрому режиму или фазе 2;
- Группа DH указывает группу Diffie-Hellman, используемую в главном режиме или на этапе 1.
- Группа PFS указывает группу Diffie-Hellman, используемую в быстром режиме или на этапе 2.
Время существования SA основного режима IKE составляет 28 800 секунд на VPN-шлюзах Azure.
UsePolicyBasedTrafficSelectors— необязательный параметр подключения. Если настроеноUsePolicyBasedTrafficSelectors$Trueподключение, он настраивает VPN-шлюз для подключения к локальному VPN-брандмауэру на основе политик.Если вы включите
UsePolicyBasedTrafficSelectors, убедитесь, что VPN-устройство имеет соответствующие селекторы трафика, определенные со всеми сочетаниями префиксов локальной сети (шлюза локальной сети) в префиксы виртуальной сети Azure или из префиксов виртуальной сети Azure, а не любого типа. VPN-шлюз принимает любой селектор трафика, который предлагает удаленный VPN-шлюз независимо от того, что настроено в VPN-шлюзе.Например, если префиксы локальной сети — 10.1.0.0/16 и 10.2.0.0/16, а префиксы виртуальной сети — 192.168.0.0/16 и 172.16.0.0/16, необходимо указать следующие селекторы трафика:
- 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
Дополнительные сведения о селекторах трафика на основе политик см. в статье "Подключение VPN-шлюза к нескольким локальным VPN-устройствам на основе политик".
Установка времени ожидания на более короткие периоды приводит к повторному использованию IKE. После этого подключение может быть отключено в некоторых случаях. Эта ситуация может оказаться нежелательной, если локальные расположения находятся далеко от региона Azure, где находится VPN-шлюз, или если физическое условие связи может привести к потере пакета. Обычно рекомендуется задать время ожидания в диапазоне от 30 до 45 секунд.
Дополнительные сведения см. в статье "Подключение VPN-шлюза к нескольким локальным VPN-устройствам на основе политик".
Какие группы Diffie-Hellman поддерживают настраиваемую политику?
В следующей таблице перечислены соответствующие группы Diffie-Hellman, поддерживаемые пользовательской политикой:
| Группа 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-шлюз использует только эту политику в подключении, как инициатор IKE, так и ответитель IKE.
Если удалить настраиваемую политику IPsec/IKE, подключение становится незащищенным?
Нет, IPsec/IKE по-прежнему помогает защитить подключение. После удаления настраиваемой политики из подключения VPN-шлюз возвращается к списку предложений IPsec/IKE по умолчанию и перезапускает подтверждение IKE с локальным VPN-устройством.
Прерывается ли VPN-подключение при добавлении или обновлении политики IPsec/IKE?
Да. Это может привести к небольшим сбоям (через несколько секунд), так как VPN-шлюз разрывает существующее подключение и перезапускает подтверждение IKE, чтобы восстановить туннель IPsec с новыми криптографическими алгоритмами и параметрами. Убедитесь, что локальное VPN-устройство также настроено с соответствующими алгоритмами и ключевыми преимуществами, чтобы свести к минимуму нарушения.
Можно ли использовать разные политики для разных подключений?
Да. Настраиваемая политика применяется на основе каждого подключения. Можно создавать и применять разные политики IPsec/IKE для разных подключений.
Можно также применять настраиваемые политики к подмножеству подключений. Оставшиеся подключения используют стандартные наборы политик IPsec/IKE Azure.
Можно ли использовать настраиваемую политику для подключений между виртуальными сетями?
Да. Вы можете применить настраиваемую политику как к локальным подключениям IPsec, так и к подключениям между виртуальными сетями.
Нужно ли указывать одну и ту же политику для обоих ресурсов при подключении между виртуальными сетями?
Да. Туннель подключения между виртуальными сетями состоит из двух ресурсов Azure: для каждого направления используется один ресурс. Убедитесь, что оба ресурса подключения имеют одну и ту же политику. В противном случае подключение виртуальной сети к виртуальной сети не будет установлено.
Какое значение времени ожидания DPD по умолчанию? Можно ли указать другое время ожидания DPD?
Время ожидания DPD по умолчанию составляет 45 секунд для VPN-шлюзов. Можно указать другое значение времени ожидания DPD для каждого подключения IPsec или виртуальной сети от 9 секунд до 3600 секунд.
Примечание.
Установка времени ожидания на более короткие периоды приводит к повторному использованию IKE. После этого подключение может быть отключено в некоторых случаях. Эта ситуация может оказаться нежелательной, если локальные расположения находятся далеко от региона Azure, где находится VPN-шлюз, или если физическое условие связи может привести к потере пакета. Обычно рекомендуется задать время ожидания в диапазоне от 30 до 45 секунд.
Работает ли настраиваемая политика IPsec/IKE на подключениях ExpressRoute?
№ Политика IPsec/IKE работает только на VPN-подключениях типа "сеть — виртуальная сеть" и "сеть — виртуальная сеть" через VPN-шлюзы.
Разделы справки создавать подключения с типом протокола IKEv1 или IKEv2?
Вы можете создавать подключения IKEv1 на всех номерах SKU типа VPN на основе маршрутов, кроме номера SKU уровня "Базовый", "Стандартный" и других более ранних номеров SKU.
При создании подключения можно указать тип протокола IKEv1 или IKEv2. Если тип протокола не указан, по умолчанию используется тип IKEv2 (там, где это применимо). Дополнительные сведения см. в документации по командлетам Azure PowerShell.
Сведения о типах SKU и поддержке IKEv1 и IKEv2 см. в статье "Подключение VPN-шлюза к нескольким локальным VPN-устройствам на основе политик".
Можно ли перейти с подключения IKEv1 на IKEv2 и обратно?
Да.
Можно ли использовать подключения типа VPN на основе маршрутов IKEv1 на уровне "Базовый" для типа VPN на основе маршрутов?
№ Номер SKU "Базовый" не поддерживает эту конфигурацию.
Можно ли сменить тип протокола после создания подключения (с IKEv1 на IKEv2 или обратно)?
№ После создания подключения невозможно изменить протоколы IKEv1 и IKEv2. Необходимо удалить и повторно создать новое соединение с нужным типом протокола.
Почему подключение IKEv1 часто теряется и восстанавливается?
Если подключение IKEv1 на основе статической маршрутизации или маршрутизации отключается через стандартные интервалы, скорее всего, так как VPN-шлюзы не поддерживают ключи на месте. При повторном подключении к главному режиму туннель IKEv1 отключается и занимает до 5 секунд. Значение времени ожидания переговоров в главном режиме определяет частоту повторного использования. Чтобы предотвратить такие повторные подключения, переключитесь на использование протокола IKEv2, который поддерживает переназначение ключей без отключения.
Если подключение повторно подключается в случайное время, следуйте руководству по устранению неполадок.
Где можно найти дополнительные сведения и шаги по настройке?
См. следующие статьи:
- Настройка настраиваемых политик подключения IPsec/IKE для VPN-подключения S2S и виртуальной сети: портал Azure
- Настройка пользовательской политики подключения IPsec/IKE для VPN-подключений типа «сеть — сеть» и «виртуальная сеть — виртуальная сеть»: PowerShell
Следующие шаги
Пошаговые инструкции по настройке пользовательской политики IPsec/IKE для подключения см. в статье о настройке политики IPsec/IKE.
Дополнительные сведения о параметре UsePolicyBasedTrafficSelectors см. в статье Connect multiple policy-based VPN devices (Подключение нескольких VPN-устройств на основе политик).