Подключение локальных сетей к Azure с помощью VPN-шлюзов "сеть —сеть"
Виртуальная частная сеть (VPN) — это тип взаимосвязанной частной сети. Эта частная сеть использует зашифрованный туннель внутри другой сети. Обычно VPN развертываются для установки подключения между двумя или более надежными частными сетями через ненадежную сеть (обычно это общедоступный Интернет). Передаваемый по ненадежной сети трафик шифруется во избежание прослушивания или действия других атак.
Для поставщика медицинских услуг в нашем сценарии VPN позволяют сотрудникам здравоохранения совместно использовать конфиденциальную информацию между расположениями. Например, пациенту может потребоваться операция в специализированном учреждении. Хирургам нужна возможность просматривать сведения из истории болезни пациента. Эти медицинские данные хранятся в системе внутри Azure. Использование VPN для подключения учреждения к Azure позволяет медикам получить безопасный доступ к этим сведениям.
VPN-шлюзы Azure
VPN-шлюз — это тип шлюза виртуальной сети. VPN-шлюзы развертываются в виртуальных сетях Azure и предоставляют следующие возможности подключения:
- Подключение локальных центров обработки данных к виртуальным сетям Azure через подключения сеть —сеть.
- Подключение отдельных устройств к виртуальным сетям Azure через подключения точка —сеть.
- Подключение виртуальных сетей Azure к виртуальным сетям Azure через подключения сеть —сеть.
Все передаваемые данные шифруются в закрытом туннеле, который проходит через Интернет. Можно развернуть только один VPN-шлюз в каждой виртуальной сети, при этом один шлюз можно использовать для подключения к нескольким площадкам, включая другие виртуальные сети Azure или локальные центры обработки данных.
При развертывании VPN-шлюза вам нужно указать тип VPN: на основе политик или на основе маршрутов. Основное различие между этими двумя типами VPN заключается в том, как указан зашифрованный трафик.
VPN на основе политик
VPN-шлюзы на основе политик определяют статические IP-адреса пакетов, которые должны быть зашифрованы при прохождении через каждый туннель. Устройство этого типа оценивает каждый пакет данных на соответствие этим наборам IP-адресов, чтобы выбрать туннель, через который будет отправляться пакет. VPN-шлюзы на основе политик имеют ограниченную поддержку функций и подключений. Ключевые возможности VPN-шлюзов на основе политик в Azure:
- Поддержка только IKEv1.
- Использование статической маршрутизации, где комбинации префиксов адресов из обеих сетей управляют тем, как трафик, проходящий через туннель VPN, шифруется и расшифровывается. Источники и назначения туннельных сетей объявляются в политике. Их необязательно объявлять в таблицах маршрутизации.
- VPN на основе политик необходимо использовать в определенных сценариях, требующих, например, обеспечения совместимости с устаревшим локальным VPN-устройством.
VPN на основе маршрутов
Если определить, какие IP-адреса находятся за каждым туннелем, слишком громоздким для вашей ситуации. Кроме того, вам нужны функции и подключения, которые шлюзы на основе политик не поддерживаются. Следует использовать шлюзы на основе маршрутов. При использовании шлюзов на основе маршрутов туннели IPSec моделируются как сетевой интерфейс или VTI (интерфейс виртуального туннеля). Ip-маршрутизация (статические маршруты или динамические протоколы маршрутизации) определяет, какой из интерфейсов туннеля отправляет каждый пакет между собой. Vpn на основе маршрутов — это предпочтительный метод подключения для локальных устройств, так как они более устойчивы к изменениям топологии, таким как создание новых подсетей, например. Если вам нужны какие-либо из следующих типов подключения, используйте VPN-шлюз на основе маршрутов:
- подключение между виртуальными сетями;
- подключения типа "точка — сеть";
- многосайтовые VPN-подключения;
- сосуществование со шлюзом Azure ExpressRoute.
Ключевые возможности VPN-шлюзов на основе маршрутов в Azure:
- Поддержка IKEv2.
- Использование селекторов трафика "любой к любому" (подстановочный знак).
- Использование протоколов динамической маршрутизации, где таблицы пересылки и маршрутизации позволяют направлять трафик в разные IPsec-туннели. В этом случае исходная и конечная сети не определяются статически, так как они находятся в VPN на основе политик или даже в VPN на основе маршрутов со статической маршрутизацией. Вместо этого пакеты данных шифруются на основе таблиц маршрутизации сети, которые создаются динамически с помощью протоколов маршрутизации, таких как BGP (протокол пограничного шлюза).
Оба типа VPN-шлюзов (на основе маршрутов и политик) в Azure используют предварительный ключ в качестве единственного метода проверки подлинности. Оба типа также полагаются на протокол Internet Key Exchange (IKE) в версии 1 или версии 2 и Internet Protocol Security (IPSec). IKE используется для настройки сопоставления безопасности (соглашение шифрования) между двумя конечными точками. Это сопоставление затем передается в набор IPSec, который шифрует и расшифровывает пакеты данных, инкапсулированные в VPN-туннель.
Размеры VPN-шлюзов
Номер SKU или размер, который вы развертываете, определяет возможности VPN-шлюза. В этой таблице показан пример некоторых номеров SKU шлюза. Числа в этой таблице могут изменяться в любое время. Последние сведения см. в разделе Номера SKU шлюза в документации по VPN-шлюзу Azure. SKU шлюза уровня "Базовый" следует использовать только для рабочих нагрузок разработки и тестирования. Кроме того, он не будет поддерживаться позднее при миграции с SKU уровня "Базовый" на SKU VpnGw#/Az без необходимости его удаления и повторного развертывания.
| VPN Шлюз Поколение |
SKU | Подключение "сеть — сеть" или "виртуальная сеть — виртуальная сеть" Туннели |
Подключение "точка — сеть" Подключения SSTP |
Подключение "точка — сеть" Подключения IKEv2/OpenVPN |
Агрегат Тест пропускной способности |
BGP | Избыточность между зонами | Поддерживаемая численность виртуальных машин в виртуальная сеть |
|---|---|---|---|---|---|---|---|---|
| Поколение1 | Базовая | Макс. 10 | Макс. 128 | Не поддерживается | 100 Мбит/с | Не поддерживается | No | 200 |
| Поколение1 | VpnGw1 | Макс. 30 | Макс. 128 | Макс. 250 | 650 Мбит/с | Поддерживается | No | 450 |
| Поколение1 | VpnGw2 | Макс. 30 | Макс. 128 | Макс. 500 | 1 Гбит/с | Поддерживается | No | 1300 |
| Поколение1 | VpnGw3 | Макс. 30 | Макс. 128 | Макс. 1000 | 1,25 Гбит/с | Поддерживается | No | 4000 |
| Поколение1 | VpnGw1AZ | Макс. 30 | Макс. 128 | Макс. 250 | 650 Мбит/с | Поддерживается | Да | 1000 |
| Поколение1 | VpnGw2AZ | Макс. 30 | Макс. 128 | Макс. 500 | 1 Гбит/с | Поддерживается | Да | 2000 |
| Поколение1 | VpnGw3AZ | Макс. 30 | Макс. 128 | Макс. 1000 | 1,25 Гбит/с | Поддерживается | Да | 5000 |
| Поколение2 | VpnGw2 | Макс. 30 | Макс. 128 | Макс. 500 | 1,25 Гбит/с | Поддерживается | No | 685 |
| Поколение2 | VpnGw3 | Макс. 30 | Макс. 128 | Макс. 1000 | 2,5 Гбит/с | Поддерживается | No | 2240 |
| Поколение2 | VpnGw4 | Макс. 100* | Макс. 128 | Макс. 5000 | 5 Гбит/с | Поддерживается | No | 5300 |
| Поколение2 | VpnGw5 | Макс. 100* | Макс. 128 | Макс. 10000 | 10 Гбит/с | Поддерживается | No | 6700 |
| Поколение2 | VpnGw2AZ | Макс. 30 | Макс. 128 | Макс. 500 | 1,25 Гбит/с | Поддерживается | Да | 2000 |
| Поколение2 | VpnGw3AZ | Макс. 30 | Макс. 128 | Макс. 1000 | 2,5 Гбит/с | Поддерживается | Да | 3300 |
| Поколение2 | VpnGw4AZ | Макс. 100* | Макс. 128 | Макс. 5000 | 5 Гбит/с | Поддерживается | Да | 4400 |
| Поколение2 | VpnGw5AZ | Макс. 100* | Макс. 128 | Макс. 10000 | 10 Гбит/с | Поддерживается | Да | 9000 |
Развертывание VPN-шлюзов
Прежде чем развернуть VPN-шлюз, вам потребуется несколько ресурсов Azure и локальных ресурсов.
Требуемые ресурсы Azure
Прежде чем развернуть операционный VPN-шлюз, вам потребуются следующие ресурсы Azure:
- Виртуальная сеть. Разверните виртуальную сеть Azure с достаточным адресным пространством для дополнительной подсети, необходимой для VPN-шлюза. Адресное пространство для этой виртуальной сети не должно перекрываться с локальной сетью, к к которому вы подключаетесь. Помните, что можно развернуть только один VPN-шлюз в виртуальной сети.
- GatewaySubnet. Разверните подсеть с именем
GatewaySubnetдля VPN-шлюза. Используйте по меньшей мере маску адресов /27, чтобы предоставить достаточно IP-адресов в подсети для будущего расширения. Эту подсеть невозможно использовать для других служб. - Общедоступный IP-адрес. В случае использования шлюза, не учитывающего зоны, создайте динамический общедоступный IP-адрес с SKU уровня "Базовый". Этот адрес предоставляет общедоступный маршрутизируемый IP-адрес в качестве цели для локального VPN-устройства. Этот IP-адрес является динамическим, но он не изменяется, если вы не удалите и повторно создадите VPN-шлюз.
- Шлюз локальной сети. Создайте шлюз локальной сети для определения конфигурации локальной сети. В частности, где VPN-шлюз подключается и к чему он подключается. Эта конфигурация включает общедоступный IPv4-адрес локального VPN-устройства и маршрутизацию для локальных сетей. Эта информация используется VPN-шлюзом для маршрутизации пакетов, предназначенных для локальных сетей, через IPSec-туннель.
- Шлюз виртуальной сети. Создайте шлюз виртуальной сети для маршрутизации трафика между виртуальной сетью и локальным центром обработки данных или другими виртуальными сетями. Шлюз виртуальной сети может быть настроен как VPN-шлюз или шлюз ExpressRoute, но этот модуль касается только VPN-шлюзов виртуальной сети.
- Подключение. Создайте ресурс подключения, чтобы создать логическое соединение между VPN-шлюзом и шлюзом локальной сети. К одному шлюзу можно создать несколько подключений.
- Соединение создается с IPv4-адресом локального VPN-устройства, определенным на локальном сетевом шлюзе.
- Подключение создается от шлюза виртуальной сети и связанного с ним общедоступного IP-адреса.
На следующей схеме показано такое сочетание ресурсов и их отношений, чтобы помочь лучше понять, что необходимо для развертывания VPN-шлюза.
Требования к локальным ресурсам
Чтобы подключить центр обработки данных к VPN-шлюзу, вам потребуются следующие локальные ресурсы:
- VPN-устройство, которое поддерживает VPN-шлюзы на основе политик или на основе маршрутов.
- Общедоступный (интернет-маршрутизируемый) IPv4-адрес.
Сценарии с высоким уровнем доступности
Существует несколько вариантов, чтобы убедиться, что у вас отказоустойчивая конфигурация.
Активный — резервный
По умолчанию VPN-шлюзы развертываются в конфигурации из двух экземпляров (активного и резервного), даже если в Azure доступен только один ресурс VPN-шлюза. При плановом обслуживании или незапланированном простое, влияющем на активный экземпляр, ожидающий экземпляр автоматически принимает ответственность за соединения (вмешательство пользователя не требуется). Во время такой отработки отказа подключения прерываются, но обычно восстанавливаются через несколько секунд в ходе планового обслуживания и в течение 90 секунд в случае непредвиденных повреждений.
Активный и активный
С появлением поддержки протокола маршрутизации BGP можно развертывать VPN-шлюзы в конфигурации активный —активный. В этой конфигурации можно назначить уникальный общедоступный IP-адрес для каждого экземпляра. После этого можно создать отдельные туннели с локального устройства до каждого IP-адреса. Вы можете расширить высокий уровень доступности, развернув другое VPN-устройство локально.
Отработка отказа для ExpressRoute
Другой вариант высокого уровня доступности — настройка VPN-шлюза как защищенного пути отработки отказа для подключений ExpressRoute. Каналы ExpressRoute обладают встроенной устойчивостью, но не защищены от банальных физических проблем, затрагивающих кабели, или сбоев, влияющих на все расположение ExpressRoute. В сценариях высокой доступности, когда возникает риск сбоя канала ExpressRoute, можно также настроить VPN-шлюз, использующий Интернет в качестве альтернативного метода подключения, таким образом обеспечивая постоянное подключение к виртуальным сетям Azure.
Шлюзы, избыточные между зонами
В регионах, поддерживающих зоны доступности, шлюзы VPN и ExpressRoute можно развертывать в конфигурации с избыточностью в пределах зоны. Такая конфигурация обеспечивает шлюзам виртуальной сети более высокие уровни устойчивости, масштабируемости и доступности. При развертывании в зонах доступности Azure происходит физическое и логическое разделение шлюзов в пределах региона с одновременной защитой локального сетевого подключения к Azure от сбоев на уровне зоны. Для них требуются разные номера SKU шлюзов и используются общедоступные IP-адреса категории "Стандартный" вместо общедоступных IP-адресов категории "Базовый".