Автоматизация шлюза виртуальной сети Azure с помощью инфраструктуры как кода

В этой статье мы покажем, как использовать преимущества инфраструктуры как кода (IaC) для развертывания и обслуживания шлюза виртуальной сети в Azure. Даже если ваша сетевая команда не знакома с IaC, мы предоставим им простой процесс создания VPN-подключения всего за несколько шагов, не требующих специальных знаний в области сетей.
В предлагаемом сценарии заказчик не хочет, чтобы его драгоценный сетевой инженер тратил время на создание VPN-подключения, устранение неполадок и другие трудоемкие задачи. Текущий процесс заключается в создании одного файла, содержащего документацию для этого партнера, и обновлении файла. Вот и все! Эту же концепцию можно использовать для любых других приложений/служб, которые вы развернули или планируете предоставить ресурсы в Microsoft Azure.
Обзор
При настройке виртуального сетевого шлюза в Microsoft Azure мы представляем клиента/партнера с локальным сетевым шлюзом и объектом подключения.
Шлюз локальной сети будет иметь общедоступный IP-адрес (элемент 1) и внутренний диапазон IP-адресов данного клиента/партнера (элемент 2), как показано на рисунке ниже.
Соединение является связующим звеном между шлюзом виртуальной сети и шлюзом локальной сети. Если мы посмотрим на любое данное соединение, мы увидим общий ключ (элемент 1), который является ключом, согласованным между обоими партнерами и необходимым для установления соединения.
Мы также видим все части головоломки вместе с правой стороны (элемент 2). Шлюз виртуальной сети, виртуальная сеть и шлюз локальной сети связаны друг с другом для установления соединения.
Пока у нас есть партнер на другой стороне, указывающий свой VPN-канон на тот же адрес, и они используют один и тот же общий ключ, мы в игре и готовы к работе!

Предлагаемый сценарий для нашей статьи изображен на диаграмме ниже. У нас будет последовательный процесс для создания новых клиентов, которые будут подключаться к нашему шлюзу виртуальной сети.
С левой стороны (репозиторий) у нас будет шаблон руки для каждой части инфраструктуры (виртуальной сети, VPN и VPN-клиента). VPN-клиент будет отвечать за предоставление шлюза локальной сети и подключения.
Файлы параметров будут учитывать особенности создания ресурсов. Наиболее важным для нашего мыслительного процесса является наличие отдельного файла параметров для каждого клиента/партнера, который будет подключаться. Это будет использоваться, чтобы сохранить модульность конфигурации и в то же время сохранить документацию наших VPN в чистоте для проверки и аудита.
Другая функция, которую мы будем использовать, — это Azure DevOps, использующая конвейер в качестве кода. Любой новый клиент/партнер будет новой задачей в конвейере, что позволит облачному администратору внести несколько изменений в репозиторий, а затем вернуться, чтобы наблюдать за волнами на пляже, пока процесс позаботится о себе.
Создание шлюза виртуальной сети Azure
Следующий код можно использовать для подготовки виртуального сетевого шлюза. Идея заключается в том, что администратор облака предоставляет несколько параметров: имя VPN-шлюза, виртуальную сеть (которая была создана на предыдущем шаге), количество ресурсов общедоступных IP-адресов и SKU.
Мы используем параметр defaultValue для автоматического заполнения, если облачный администратор пропустит файлы параметров.
{ "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "vpnGateway ":{ "type": "string", "defaultValue": "VPN-CaC-Corp" }, "virtualNetwork":{ "type": "string", "defaultValue": "VNET-CaC-Corp" }, "PIP":{ "type": "array", "defaultValue": ["VPN-CaC-Corp-PIP-Primary","VPN-CaC-Corp-PIP-Secondary"] }, "sku":{ " type": "string", "defaultValue": "VpnGw3" } }, "variables": {}, "resources": [ { "type": "Microsoft.Network/publicIPAddresses", "apiVersion": "2020-05 -01", "имя": "[параметры('пип')[copyIndex()]]", "местоположение": "[группа ресурсов().местоположение]", "артикул": { "имя": "Основное" }, "properties": { "publicIPAllocationMethod": "Dynamic" }, "copy": { "name": "Copy-PublicIP", "count":"[length(parameters('pip'))]" } }, { "type": "Microsoft.Network/virtualNetworkGateways", "apiVersion": "2020-05-01", "name": "[parameters('vpnGateway')]", "location": "[resourcegroup().location]", "dependsOn": [ "[resourceId('Microsoft.Net work/publicIPAddresses', параметры('PIP')[0])]", "[resourceId('Microsoft.Network/publicIPAddresses', параметры('PIP')[1])]" ], "properties": { " enablePrivateIpAddress": false, "ipConfigurations": [ { "name": "default", "properties": { "privateIPAllocationMethod": "Dynamic", "publicIPAddress": { "id": "[resourceId('Microsoft.Network/ publicIPAddresses', parameters('PIP')[0])]" }, "subnet": { "id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', параметры('virtualNetwork'), 'GatewaySubnet' )]" } } }, { "name": "activeActive", "properties": { "privateIPAllocationMethod": "Dynamic", "publicIPAddress": { "id": "[resourceId('Microsoft.Network/publicIPAddresses', параметры('PIP')[1])]" }, "subnet": { "id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', параметры('virtualNetwork'), 'GatewaySubnet')]" } } } ], "sku": { "name": "[параметры('sku')]", "tier": "[параметры('sku')]" }, "gatewayType": "Vpn", " vpnType": "RouteBased", "enableBgp": false, "activeActive": true, " vpnGatewayGeneration": "Поколение2" } } ] }
Создание шлюза локальной сети и подключение через код
Вот интересная часть (во всяком случае, одна из них!). Файл шаблона требует несколько параметров, и мы используем defaultValue для устранения неполадок. Если администратор облака/администраторы сети пропустят настройки в файле параметров, будут введены эти значения по умолчанию. Если мы видим эти странные значения, мы сразу понимаем, что нам нужно обновить файл параметров.
{ "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "partner_name ":{ "type": "string", "defaultValue": "PartnerName" }, "partner_destination":{ "type": "string", "defaultValue": "1.1.1.1" }, "partner_network":{ " type": "array", "defaultValue": "['2.2.2.2']" }, "partner_shared":{ "type": "string", "defaultValue": "PartnerSharedSecret" }, "vpnGateway":{ " type": "string" } }, "variables": {}, "resources": [ { "type": "Microsoft.Network/localNetworkGateways", "apiVersion": "2020-05-01", "name": "[parameters('partner_name')]", "location": "[resourcegroup().location]", "properties": { "localNetworkAddressSpace": { "addressPrefixes": "[parameters('partner_network')]" }, "gatewayIpAddress": "[parameters('partner_destination')]" } }, { "type": "Microsoft.Network/connections", "apiVersion": "2020-05-01", "name": "[parameters ('partner_name')]", "location": "[resourcegroup().location]", "dependsOn": [ "[resource ceid('Microsoft.Network/localNetworkGateways',parameters('partner_name'))]" ], "properties": { "virtualNetworkGateway1": { "id": "[resourceId('Microsoft.Network/virtualNetworkGateways',parameters(' vpnGateway'))]" }, "localNetworkGateway2": { "id": "[resourceId('Microsoft.Network/localNetworkGateways',parameters('partner_name'))]" }, "connectionType": "IPsec", "connectionProtocol ": "IKEv2", "routingWeight": 0, "sharedKey": "[parameters('partner_shared')]", "enableBgp": ложь, "useLocalAzureIpAddress": ложь, "usePolicyBasedTrafficSelectors": ложь, "expressRouteGatewayBypass": ложь, "dpdTimeoutSeconds": 0 } } ] }
Вот файл параметров для конкретного клиента/партнера. Нам нужно создать копии этого файла, пометить файл как vpnclient.customer.json и поместить его в репозиторий.
{ "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#", "contentVersion": "1.0.0.0", "parameters": { "partner_name ":{ "value": "ConnectionName" }, "partner_destination":{ "value": "yyyy" }, "partner_network":{ "value": ["xxxx/24"] }, "partner_shared":{ " значение": "Добавить" }, "vpnGateway":{ "значение": "VPN-CaC-Corp" } } }
Настройка конвейера Azure
Последняя часть — указание сетевой группе/администратору облака добавить новую задачу в Azure Pipeline. По сути, только две области выделены жирным шрифтом в приведенном ниже коде. Как только мы зафиксируем ветку master, она активирует конвейер Azure, который будет обрабатывать новый файл, который мы только что создали на предыдущем шаге.
- задача: [email protected] displayName: VPNClient_customerName inputs: deploymentScope: «Группа ресурсов» azureResourceManagerConnection: «AzureDevOps.SvcConnection» идентификатор подписки: ${{ parameters.p_subscriptionId }} действие: «Создать или обновить группу ресурсов» resourceGroupName: ${{ параметры.p_resourcegroupName }} location: ${{ parameters.p_location }} templateLocation: 'Связанный артефакт' csmFile: '$(System.DefaultWorkingDirectory)/vpnclient.json' csmParametersFile: '$(System.DefaultWorkingDirectory)/vpnclient.customerName.json' развертываниеMode: «Инкрементальный»
Инфраструктура как код и ресурсы Azure: общая картина!
Прежде чем отправиться проверять волны на пляже (в конце концов, нам не нужно тратить время на создание VPN-подключений), давайте сделаем краткий обзор файлов, к которым мы прикоснулись, чтобы воплотить эту статью в жизнь.
JSON в оранжевом цвете — это файлы шаблонов, а красные — в файлах параметров. Мы можем расширить нашу структуру для поддержки нескольких сред, создав новые файлы параметров и создав соединения клиентов/партнеров, создав новые файлы (VPNClient.Name.json).
Гораздо проще, чем раньше!
В этой статье мы рассмотрели процесс автоматизации простой задачи по созданию VPN-соединений, для которой в прошлом требовались знания в области сетевого оборудования и специальные разрешения для входа на устройства. Мы использовали программно-определяемую сеть из Azure, чтобы выполнить задачу, просто изменив репозиторий, в котором хранится служба/рабочая нагрузка.
Кроме того, у нас есть историческая информация об изменениях, документация наших партнеров и резервное копирование, чего не так просто добиться, используя только сетевое оборудование и дорогостоящие часы сетевого SME.