Настройка подключения с проверкой подлинности по сертификату для шлюза VPN типа S2S — Azure CLI

В этой статье показано, как использовать Azure CLI для создания VPN-соединения site-to-site (S2S) между вашей локальной сетью и виртуальной сетью Azure с помощью аутентификации на основе сертификатов X.509. Проверка подлинности сертификата обеспечивает более надежную безопасность по сравнению с предварительными ключами (PSK) для VPN-подключений.

Проверка подлинности сертификата типа "сеть — сеть" зависит от входящих и исходящих сертификатов для установления безопасных VPN-туннелей. Сертификаты безопасно хранятся в Azure Key Vault, и каждый VPN шлюз использует свои сертификаты через управляемое удостоверение пользователя. Дополнительные сведения о сертификатах и о том, как работает поток сертификатов, см. в разделе "Сведения о VPN-подключениях типа "сеть — сеть" с проверкой подлинности сертификата.

В этой статье вы генерируете необходимые сертификаты, создаёте необходимые ресурсы Azure и настраиваете VPN-соединение между сайтами с помощью Azure CLI.

Перед тем как начать

Чтобы выполнить действия, описанные в этой статье, убедитесь, что у вас есть следующие предварительные требования:

• Учетная запись Azure с активной подпиской. Если у вас ее нет, создайте подписку бесплатно.
• Azure CLI устанавливается локально или Azure Cloud Shell. Дополнительные сведения см. в статье Установка Azure CLI.
• Знакомство с диапазонами IP-адресов в локальной конфигурации сети.
• Совместимое VPN-устройство и пользователь, который может его настроить. Дополнительные сведения о совместимых VPN-устройствах см. в разделе "Сведения о VPN-устройствах".
• Внешний общедоступный IPv4-адрес для локального VPN-устройства.
• Убедитесь, что подсети локальной сети не перекрываются с подсетями виртуальной сети, к которым вы хотите подключиться.

Создание цифровых сертификатов

Сначала сгенерируйте самоподписанные корневые сертификаты CA и листовые сертификаты, необходимые для аутентификация VPN. Сертификат корневого ЦС устанавливает цепочку доверия и используется для подписывания листовых сертификатов.

У вас есть два варианта:

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

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

Создание самозаверяющего корневого сертификата ЦС

Используйте OpenSSL для создания самоподписанных корневых сертификатов. Следующий пример создаёт самоподписанный корневой сертификат с именем VPNRootCA1, который автоматически хранится в локальной папке certs.

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

# Define the root certificate subject for Azure VPN
azureRootcertSubject1='VPNRootCA1'

# Define the local folder to store the digital certificates
pathFiles="$(pwd)"
certPath="$pathFiles/certs/"
echo "folder to store digital certificates: $certPath"

# Create a local folder ./certs/
mkdir -p "$certPath"

# Generate the private key for the Azure VPN gateway root certificate
openssl genrsa -out "$certPath${azureRootcertSubject1}.key" 2048

# Generate the self-signed root certificate for the Azure VPN gateway
openssl req -x509 -new -nodes \
    -key "$certPath${azureRootcertSubject1}.key" \
    -sha256 \
    -days 3650 \
    -out "$certPath${azureRootcertSubject1}.cer" \
    -subj "/CN=$azureRootcertSubject1" \
    -extensions v3_ca \
    -config <(cat <<EOF
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_ca
[req_distinguished_name]
[v3_ca]
basicConstraints = critical, CA:TRUE, pathlen:4
keyUsage = critical, keyCertSign, cRLSign
EOF
)

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

# Define the root certificate subject for the on-premises VPN device
onpremRootcertSubject1='VPNRootCA2'
echo "Creating Root Certificate: $onpremRootcertSubject1"

# Generate the private key for the on-premises root certificate
openssl genrsa -out "$certPath${onpremRootcertSubject1}.key" 2048

# Generate the self-signed root certificate for the on-premises VPN device
openssl req -x509 -new -nodes \
    -key "$certPath${onpremRootcertSubject1}.key" \
    -sha256 \
    -days 3650 \
    -out "$certPath${onpremRootcertSubject1}.cer" \
    -subj "/CN=$onpremRootcertSubject1" \
    -extensions v3_ca \
    -config <(cat <<EOF
[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_ca
[req_distinguished_name]
[v3_ca]
basicConstraints = critical, CA:TRUE, pathlen:4
keyUsage = critical, keyCertSign, cRLSign
EOF
)
echo "Root certificate $onpremRootcertSubject1 created"

Чтобы сгенерировать листовые сертификаты, оставьте bash-терминал открытым и переходите к следующим шагам.

Генерация конечных сертификатов, подписанных корневыми сертификатами УЦ

Создайте листовые сертификаты, подписанные корневыми сертификатами. Используйте эти сертификаты для аутентификации VPN между сайтами. Следующие примеры используют OpenSSL для генерации исходящих и входящих листовых сертификатов. При создании сертификатов процесс автоматически сохраняет их в ./certs на вашем компьютере под управлением Linux.

Создание исходящего сертификата для VPN-шлюза

azureLeafcertSubject1='s2s-cert1'
echo "$(date) - start creation leaf cert: $azureLeafcertSubject1"

# Generate the private key
openssl genrsa -out "$certPath${azureLeafcertSubject1}.key" 2048

# Generate the certificate signing request (CSR)
openssl req -new \
    -key "$certPath${azureLeafcertSubject1}.key" \
    -out "$certPath${azureLeafcertSubject1}.csr" \
    -subj "/CN=$azureLeafcertSubject1"

# Sign the leaf certificate for the Azure VPN gateway with Root CA 1
openssl x509 -req \
    -in "$certPath${azureLeafcertSubject1}.csr" \
    -CA "$certPath${azureRootcertSubject1}.cer" \
    -CAkey "$certPath${azureRootcertSubject1}.key" \
    -CAcreateserial \
    -out "$certPath${azureLeafcertSubject1}.cer" \
    -days 3650 \
    -sha256 \
    -extfile <(cat <<EOF
extendedKeyUsage = clientAuth, serverAuth
EOF
)
echo "$(date) - Leaf cert: $azureLeafcertSubject1 created"

Создание исходящего сертификата для локального устройства

onpremLeafcertSubject1='s2s-cert2'

# Generate the private key
openssl genrsa -out "$certPath${onpremLeafcertSubject1}.key" 2048

# Generate the certificate signing request (CSR)
openssl req -new \
   -key "$certPath${onpremLeafcertSubject1}.key" \
   -out "$certPath${onpremLeafcertSubject1}.csr" \
   -subj "/CN=$onpremLeafcertSubject1"

# Sign the leaf certificate with Root CA 2, used for the on-premises VPN device
openssl x509 -req \
   -in "$certPath${onpremLeafcertSubject1}.csr" \
   -CA "$certPath${onpremRootcertSubject1}.cer" \
   -CAkey "$certPath${onpremRootcertSubject1}.key" \
   -CAcreateserial \
   -out "$certPath${onpremLeafcertSubject1}.cer" \
   -days 3650 \
   -sha256 \
   -extfile <(cat <<EOF
extendedKeyUsage = clientAuth, serverAuth
EOF
)

Экспорт сертификатов

Экспорт корневых сертификатов в формате Base64 (.cer) и конечных сертификатов в формате PKCS#12 (PFX).

pathFiles="$(pwd)"
certPath="$pathFiles/certs/"
certPassword="12345"

# Export the Azure leaf certificate and its private key to a .pfx file
openssl pkcs12 -export \
    -out "$certPath${azureLeafcertSubject1}.pfx" \
    -inkey "$certPath${azureLeafcertSubject1}.key" \
    -in "$certPath${azureLeafcertSubject1}.cer" \
    -certfile "$certPath${azureRootcertSubject1}.cer" \
    -passout "pass:$certPassword"

Объявление переменных среды Azure

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

# Resource group name and location for the deployment of Azure resources
rgName="s2s-cert-azcli"
location='eastus'

# Variables for the virtual network
vnet1Name='vnet1'
vnet1Address='10.1.0.0/16'
gw1SubnetAddress='10.1.0.0/24'

# VPN gateway name
gw1Name='gw1'
gw1ConfigName='gw1-config'

Создайте виртуальные сети и шлюзовые подсети

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

# Create a resource group
az group create --name "$rgName" --location "$location"

# Add tags for organization (optional)
az group update --name "$rgName" --tags usage="s2s-digitalcertificates" --output none

Создайте виртуальную сеть с подсетью шлюза. Подсеть шлюза должна быть названа GatewaySubnet и должна быть /27 или больше.

# Create the virtual network
az network vnet create \
    --resource-group "$rgName" \
    --name "$vnet1Name" \
    --address-prefix "$vnet1Address" \
    --location "$location"

# Add the GatewaySubnet
az network vnet subnet create \
    --resource-group "$rgName" \
    --vnet-name "$vnet1Name" \
    --name "GatewaySubnet" \
    --address-prefix "$gw1SubnetAddress"

Создайте управляемую идентичность, назначаемую пользователем

Для этой конфигурации требуется управляемое удостоверение. VPN-шлюзы используют управляемые удостоверения, назначаемые пользователем, для безопасного доступа к сертификатам, хранящимся в Azure Key Vault. Дополнительные сведения об управляемых удостоверениях см. в статье "Что такое управляемые удостоверения для ресурсов Azure".

При создании управляемого имени идентичности используйте что-то интуитивное, например gw1-s2s-kv или vpngwy-managed. Вам потребуется имя для действий по настройке Key Vault. Группа ресурсов не должна совпадать с группой ресурсов, используемой для VPN-шлюза.

# Create a user-assigned managed identity for the VPN gateway to access the Azure Key Vault
gw1UserIdentityName='gw1-s2s-kv'
az identity create --resource-group "$rgName" --name "$gw1UserIdentityName" --location "$location"

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

Создайте Key Vault и настраивайте разрешения RBAC

Для этой конфигурации требуется Azure Key Vault. Создайте Key Vault для хранения сертификатов и настройте разрешения RBAC для безопасного доступа. Дополнительные сведения о Azure Key Vault см. в статье "Сведения о Azure Key Vault".

# Generate a globally unique Azure Key Vault name.
# Key Vault names must be unique across all Azure regions and must not exceed 24 characters.
suffix="ALFANUMERIC_VALUE"
keyVault1Name="kv-$suffix"

# Delete the Key Vault if it's in the soft-deleted state, to avoid failure
az keyvault purge --name "$keyVault1Name" --location "$location"

# Create the Key Vault - Azure RBAC is the default access control model for newly created vaults
az keyvault create --name "$keyVault1Name" --resource-group "$rgName" --location "$location"

Назначение ролей RBAC управляемым удостоверениям

Предоставить управляемым идентичностям необходимые права на доступ к сертификатам в Key Vault с помощью Azure RBAC.

# Define the RBAC role IDs
secretsUserRoleId="4633458b-17de-408a-b874-0445c86b69e6"    # built-in role "Key Vault Secrets User"
certUserRoleId="db79e9a7-68ee-4b58-9aeb-b90e7c24fcba"       # built-in role "Key Vault Certificate User"
certOfficerRoleId="a4417e6f-fecd-4de8-b567-7b0420556985"    # built-in role "Key Vault Certificates Officer" (for full certificate management)

keyVaultResourceId=$(az keyvault show --name "$keyVault1Name" --resource-group "$rgName" --query id -o tsv)

# Get the Microsoft Entra service principal object ID of the managed identity
gw1UserIdentityPrincipalId=$(az identity show --resource-group "$rgName" --name "$gw1UserIdentityName" --query principalId -o tsv)

# Assign RBAC roles to the user-assigned managed identity to access the Key Vault
az role assignment create --assignee-object-id "$gw1UserIdentityPrincipalId" \
    --assignee-principal-type ServicePrincipal \
    --role "$certUserRoleId" \
    --scope "$keyVaultResourceId"

az role assignment create --assignee-object-id "$gw1UserIdentityPrincipalId" \
    --assignee-principal-type ServicePrincipal \
    --role "$secretsUserRoleId" \
    --scope "$keyVaultResourceId"

# Assign the Key Vault Certificates Officer role to the current user (required to import certificates)
currentUser=$(az account show --query user.name -o tsv)
currentUserObjectId=$(az ad user show --id "$currentUser" --query id -o tsv)

az role assignment create --assignee-object-id "$currentUserObjectId" \
    --assignee-principal-type User \
    --role "$certOfficerRoleId" \
    --scope "$keyVaultResourceId"

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

Импорт сертификатов в Key Vault

Загрузите внешний конечный сертификат (с закрытым ключом) в Azure Key Vault. Файл сертификата должен быть в формате PFX.

pathFiles="$(pwd)"
certPath="$pathFiles/certs/"
azureLeafcertSubject1='s2s-cert1'
cert1FilePath="$certPath${azureLeafcertSubject1}.pfx"
certPassword="12345"

# Name assigned to the certificate object stored in Azure Key Vault for the VPN gateway
gw1OutboundCertName='gw1-cert'

az keyvault certificate import \
    --vault-name "$keyVault1Name" \
    --name "$gw1OutboundCertName" \
    --file "$cert1FilePath" \
    --password "$certPassword"

Создайте публичные IP-адреса для VPN-шлюза

Создайте отказоустойчивые между зонами публичные IP-адреса SKU Standard для шлюза VPN. VPN-шлюз настроен в активно-активном режиме, поэтому требуется два публичных IP-адреса.

# Create public IP 1 for Gateway 1
gw1pubIP1Name="${gw1Name}pip1"
az network public-ip create \
    --resource-group "$rgName" \
    --name "$gw1pubIP1Name" \
    --location "$location" \
    --allocation-method Static \
    --sku Standard \
    --tier Regional \
    --zone 1 2 3

# Create public IP 2 for Gateway 1
gw1pubIP2Name="${gw1Name}pip2"
az network public-ip create \
    --resource-group "$rgName" \
    --name "$gw1pubIP2Name" \
    --location "$location" \
    --allocation-method Static \
    --sku Standard \
    --tier Regional \
    --zone 1 2 3

Создание VPN-шлюза

Создайте VPN-шлюз, используя управляемую идентификацию, назначенную пользователем для доступа к Key Vault.

# Create the Azure VPN gateway in active-active mode
az network vnet-gateway create \
    --resource-group "$rgName" \
    --name "$gw1Name" \
    --location "$location" \
    --public-ip-address "$gw1pubIP1Name" "$gw1pubIP2Name" \
    --vnet "$vnet1Name" \
    --gateway-type Vpn \
    --vpn-type RouteBased \
    --sku VpnGw2AZ \
    --vpn-gateway-generation Generation2

# Get the user-assigned managed identity created earlier
gw1UserIdentityId=$(az identity show \
  --resource-group "$rgName" \
  --name "$gw1UserIdentityName" \
  --query id -o tsv)

# Attach the user-assigned managed identity to the existing Azure VPN gateway
echo "$(date) - updating vpn gateway with managed identity"
az network vnet-gateway identity assign \
    --resource-group "$rgName" \
    --name "$gw1Name" \
    --user-assigned "$gw1UserIdentityId"

# Verify the user-assigned managed identity is associated with the VPN gateway
az network vnet-gateway identity show \
  --resource-group "$rgName" \
  --name "$gw1Name" \
  --query userAssignedIdentities \
  -o json

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

az network vnet-gateway show \
  --resource-group "$rgName" \
  --name "$gw1Name" \
  --query provisioningState \
  -o tsv

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

Создание шлюзов локальной сети

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

Рекомендации по конфигурации:

• Поддержка полного доменного имени (FQDN): Если у вас есть динамический общедоступный IP-адрес, можно использовать постоянное DNS-имя с сервисом Dynamic DNS, чтобы указать текущий общедоступный IP-адрес. VPN-шлюз Azure разрешает полное доменное имя (FQDN) для определения общедоступного IP-адреса для подключения.
• Один IP-адрес: VPN-шлюз поддерживает только один IPv4-адрес для каждого полного доменного имени. Если доменное имя разрешается на несколько IP-адресов, VPN-шлюз использует первый IP-адрес, возвращаемый DNS-серверами. Корпорация Майкрософт рекомендует, чтобы ваше полное доменное имя всегда резолвилось в одному IPv4 адресу. IPv6 не поддерживается.
• Кэш DNS: VPN-шлюз поддерживает кэш DNS, обновляемый каждые 5 минут. Шлюз пытается определить полные доменные имена только для неподключенных туннелей. Сброс шлюза также активирует разрешение FQDN.
• Несколько подключений: Хотя VPN-шлюз поддерживает несколько подключений к различным шлюзам локальной сети с разными полными доменными именами, все полные доменные имена должны быть разрешены в разные IP-адреса.

Создайте шлюзы локальной сети для представления локального сетевого сайта. Каждый шлюз локальной сети задает общедоступный IP-адрес и префиксы адресов удаленного локального сайта.

# Public IP addresses of the on-premises VPN device
site1publicIP1="PUBLIC_IP_ADDRESS_1_ON_PREMISES_DEVICE"
site1publicIP2="PUBLIC_IP_ADDRESS_2_ON_PREMISES_DEVICE"
onpremAddressPrefix="10.2.0.0/16"

# Create the local network gateway for Site1
# The remote peer is the first on-premises public IP: $site1publicIP1
localNetGwSite11Name='localNetSite11'
az network local-gateway create \
    --resource-group "$rgName" \
    --name "$localNetGwSite11Name" \
    --location "$location" \
    --local-address-prefixes "$onpremAddressPrefix" \
    --gateway-ip-address "$site1publicIP1"

# Create the local network gateway for Site1
# The remote peer is the second on-premises public IP: $site1publicIP2
localNetGwSite12Name='localNetSite12'
az network local-gateway create \
    --resource-group "$rgName" \
    --name "$localNetGwSite12Name" \
    --location "$location" \
    --local-address-prefixes "$onpremAddressPrefix" \
    --gateway-ip-address "$site1publicIP2"

Настройка локального VPN-устройства

Для подключения "сеть — сеть" к локальной сети требуется VPN-устройство. При настройке VPN-устройства вам потребуется следующее:

• Сертификат: Вам нужны данные сертификата, используемые для проверки подлинности. Этот сертификат также используется в качестве входящего сертификата при создании VPN-подключения.
• Значения общедоступных IP-адресов для вашего виртуального сетевого шлюза: Чтобы найти общедоступный IP-адрес экземпляра виртуальной машины VPN-шлюза с помощью портала Azure, перейдите к виртуальному сетевому шлюзу и в разделе Параметры>Свойства. Если у вас есть шлюз активно-активного режима (рекомендуется), обязательно настройте туннели для каждого экземпляра VPN-шлюза. Оба туннеля являются частью одного подключения. VPN-шлюзы в активном-активном режиме имеют два общедоступных IP-адреса, по одному для каждого экземпляра виртуальной машины шлюза.

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

Создание VPN-подключений с проверкой подлинности сертификата

Создайте VPN-подключения с помощью проверки подлинности сертификата. Каждое подключение использует исходящий сертификат из Azure Key Vault и проверяет входящие подключения к корневой цепочке сертификатов удаленного сайта.

Подготовьте информацию об аутентификации исходящих сертификатов для VPN-шлюза

Используйте следующие команды, чтобы получить ссылку на исходящий сертификат, хранящийся в Azure Key Vault.

# Get outbound certificate information from Key Vault for the Azure VPN gateway connections
gw1OutboundCertUrl=$(az keyvault certificate show --vault-name "$keyVault1Name" \
  --name "$gw1OutboundCertName" --query id -o tsv)

Переменная gw1OutboundCertUrl содержит путь к исходящему сертификату в Azure Key Vault. Чтобы проверить значение, используйте следующую команду.

echo $gw1OutboundCertUrl

Путь зависит от сертификата и выглядит следующим образом: https://your-keyvault.vault.azure.net/certificates/certificate-name/<certificate-value>

Подготовьте сведения о входном сертификате для VPN-шлюза

Следующие шаги предполагают, что вы экспортируете корневой сертификат и храните его на локальном компьютере в папке, указанной переменной certPath , с именем VPNRootCA2.cer (кодированным в Base64). Это локальный корневой сертификат, созданный ранее в разделе Создание самозаверяющих корневых сертификатов центра сертификации. Используйте информацию о сертификате для проверки входящего сертификата в VPN-шлюзе. В нём нет приватных ключей.

pathFiles="$(pwd)"
certPath="$pathFiles/certs"

onpremLeafcertSubject1=$(openssl x509 -in "$certPath/s2s-cert2.cer" -noout -subject | sed -E 's/^subject= ?CN=//')

# Read the inbound certificate chain file for the Azure VPN gateway.
# This is the Root CA certificate in Base64 format for the on-premises VPN device.
inboundCert2Path="$certPath/VPNRootCA2.cer"
inboundCert2Base64=$(grep -v "BEGIN CERTIFICATE" "$inboundCert2Path" | grep -v "END CERTIFICATE" | tr -d '\n\r')

При использовании промежуточных ЦС в разделе входящих сертификатов всегда должно быть по крайней мере два сертификата.

На этом этапе считайте, что вы уже создали конечный сертификат локального устройства и можете получить имя субъекта сертификата. На локальном устройстве извлеките общее имя (CN) из исходящего листового сертификата. В примере процесса CN — onprem-s2s-1, но вам следует проверить значение CN, используемое в вашей среде.

Не включайте CN= префикс в значение переменной.

Создание объектов проверки подлинности сертификата

# Create the certificate authentication object in JSON format for the Azure VPN gateway
# Gateway 1 uses its own certificate for outbound, and trusts Root CA 2 for inbound
certAuthJson="{\"outboundAuthCertificate\":\"$gw1OutboundCertUrl\",\"inboundAuthCertificateChain\":[\"$inboundCert2Base64\"],\"inboundAuthCertificateSubjectName\":\"$onpremLeafcertSubject1\"}"

Создание VPN-подключений

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

# Create connection 1 from Gateway1 to site1
gw1Connection11Name='Connection11'
az network vpn-connection create \
    --resource-group "$rgName" \
    --name "$gw1Connection11Name" \
    --location "$location" \
    --vnet-gateway1 "$gw1Name" \
    --local-gateway2 "$localNetGwSite11Name" \
    --auth-type Certificate \
    --cert-auth "$certAuthJson" \
    --routing-weight 3

# Create connection 2 from Gateway1 to site1
gw1Connection12Name='Connection12'
az network vpn-connection create \
    --resource-group "$rgName" \
    --name "$gw1Connection12Name" \
    --location "$location" \
    --vnet-gateway1 "$gw1Name" \
    --local-gateway2 "$localNetGwSite12Name" \
    --auth-type Certificate \
    --cert-auth "$certAuthJson" \
    --routing-weight 3

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

После создания соединений проверьте настройки VPN-шлюза.

echo "$(date) - checking vpn connection: $gw1Connection11Name"
vpnConnection11=$(az network vpn-connection show --resource-group "$rgName" --name "$gw1Connection11Name")
echo "$gw1Name - connection name......: $(echo "$vpnConnection11" | jq -r '.name')"
echo "$gw1Name - connection type......: $(echo "$vpnConnection11" | jq -r '.connectionType')"
echo "$gw1Name - authentication type..: $(echo "$vpnConnection11" | jq -r '.authenticationType')"
echo "$gw1Name - connection status....: $(echo "$vpnConnection11" | jq -r '.connectionStatus')"

echo "$(date) - checking vpn connection: $gw1Connection12Name"
vpnConnection12=$(az network vpn-connection show --resource-group "$rgName" --name "$gw1Connection12Name")
echo "$gw1Name - connection name......: $(echo "$vpnConnection12" | jq -r '.name')"
echo "$gw1Name - connection type......: $(echo "$vpnConnection12" | jq -r '.connectionType')"
echo "$gw1Name - authentication type..: $(echo "$vpnConnection12" | jq -r '.authenticationType')"
echo "$gw1Name - connection status....: $(echo "$vpnConnection12" | jq -r '.connectionStatus')"

После успешного установления VPN-туннелей статус соединения отображается как «Подключено».

Вы также можете проверить подключение на портале Azure:

1. Перейдите к шлюзу виртуальной сети на портале.
2. Выберите "Подключения" в левой области.
3. Убедитесь, что в поле состояния подключения отображается значение Подключено.

Дальнейшие действия

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

• Сведения о параметрах конфигурации VPN-шлюз
• Настройка BGP для VPN-шлюза
• Сведения о подключениях VPN-шлюза высокой доступности
• Сведения о Key Vault
• Руководство по RBAC в Azure Key Vault

Связанные материалы

• Учебник: создание межсетевого VPN-подключения на портале Azure
• О криптографических требованиях и шлюзах Azure VPN
• Настройте аутентификационное соединение с сертификатом S2S VPN-шлюз — PowerShell
• Генерируйте и экспортируйте сертификаты для point-to-site с помощью PowerShell