В этой статье приведены некоторые советы по устранению неполадок подключения VPN-шлюза между локальной сетью и Azure. Общие сведения об устранении распространенных ошибок, связанных с VPN, см. в разделе Устранение распространенных ошибок, связанных с VPN,.
Проверка правильности работы VPN-устройства
Следующие рекомендации полезны для определения правильности работы локального VPN-устройства.
Проверьте все файлы журнала, созданные VPN-устройством, для ошибок или сбоев. Это поможет определить, работает ли VPN-устройство правильно. Расположение этих сведений зависит от вашего устройства. Например, если вы используете RRAS в Windows Server, можно использовать следующую команду PowerShell для отображения сведений о событии ошибки для службы RRAS:
Get-EventLog -LogName System -EntryType Error -Source RemoteAccess | Format-List -Property *
Свойство сообщения каждой записи содержит описание ошибки. Ниже приведены некоторые распространенные примеры.
Невозможность подключения, возможно, из-за неправильного IP-адреса, указанного для VPN-шлюза Azure в конфигурации сетевого интерфейса RRAS.
EventID : 20111 MachineName : on-premises-vm Data : {41, 3, 0, 0} Index : 14231 Category : (0) CategoryNumber : 0 EntryType : Error Message : RoutingDomainID- {00000000-0000-0000-0000-000000000000}: A demand dial connection to the remote interface AzureGateway on port VPN2-4 was successfully initiated but failed to complete successfully because of the following error: The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (for example, firewalls, NAT, routers, and so on) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem. Source : RemoteAccess ReplacementStrings : {{00000000-0000-0000-0000-000000000000}, AzureGateway, VPN2-4, The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (for example, firewalls, NAT, routers, and so on) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem.} InstanceId : 20111 TimeGenerated : 3/18/2024 1:26:02 PM TimeWritten : 3/18/2024 1:26:02 PM UserName : Site : Container :
Неправильный общий ключ, указанный в конфигурации сетевого интерфейса RRAS VPN.
EventID : 20111 MachineName : on-premises-vm Data : {233, 53, 0, 0} Index : 14245 Category : (0) CategoryNumber : 0 EntryType : Error Message : RoutingDomainID- {00000000-0000-0000-0000-000000000000}: A demand dial connection to the remote interface AzureGateway on port VPN2-4 was successfully initiated but failed to complete successfully because of the following error: Internet key exchange (IKE) authentication credentials are unacceptable. Source : RemoteAccess ReplacementStrings : {{00000000-0000-0000-0000-000000000000}, AzureGateway, VPN2-4, IKE authentication credentials are unacceptable. } InstanceId : 20111 TimeGenerated : 3/18/2024 1:34:22 PM TimeWritten : 3/18/2024 1:34:22 PM UserName : Site : Container :
Вы также можете получить сведения о попытках подключения через службу RRAS с помощью следующей команды PowerShell:
Get-EventLog -LogName Application -Source RasClient | Format-List -Property *
В случае сбоя подключения этот журнал будет содержать ошибки, которые выглядят следующим образом:
EventID : 20227
MachineName : on-premises-vm
Data : {}
Index : 4203
Category : (0)
CategoryNumber : 0
EntryType : Error
Message : CoId={B4000371-A67F-452F-AA4C-3125AA9CFC78}: The user SYSTEM dialed a connection named
AzureGateway that has failed. The error code returned on failure is 809.
Source : RasClient
ReplacementStrings : {{B4000371-A67F-452F-AA4C-3125AA9CFC78}, SYSTEM, AzureGateway, 809}
InstanceId : 20227
TimeGenerated : 3/18/2024 1:29:21 PM
TimeWritten : 3/18/2024 1:29:21 PM
UserName :
Site :
Container :
Проверка подключения
Проверьте подключение и маршрутизацию через VPN-шлюз. VPN-устройство может быть неправильно маршрутизацией трафика через VPN-шлюз Azure. Используйте средство, например PsPing для проверки подключения и маршрутизации через VPN-шлюз. Например, чтобы проверить подключение с локального компьютера к веб-серверу, расположенному в виртуальной сети, выполните следующую команду (заменив <<web-server-address>>
адресом веб-сервера):
PsPing -t <<web-server-address>>:80
Если локальный компьютер может направлять трафик на веб-сервер, вы увидите выходные данные, аналогичные следующим:
D:\PSTools> psping -t 10.20.0.5:80
PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP connect to 10.20.0.5:80:
Infinite iterations (warmup 1) connecting test:
Connecting to 10.20.0.5:80 (warmup): 6.21ms
Connecting to 10.20.0.5:80: 3.79ms
Connecting to 10.20.0.5:80: 3.44ms
Connecting to 10.20.0.5:80: 4.81ms
Sent = 3, Received = 3, Lost = 0 (0% loss),
Minimum = 3.44ms, Maximum = 4.81ms, Average = 4.01ms
Если локальный компьютер не может взаимодействовать с указанным назначением, вы увидите следующие сообщения:
D:\PSTools>psping -t 10.20.1.6:80
PsPing v2.01 - PsPing - ping, latency, bandwidth measurement utility
Copyright (C) 2012-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
TCP connect to 10.20.1.6:80:
Infinite iterations (warmup 1) connecting test:
Connecting to 10.20.1.6:80 (warmup): This operation returned because the timeout period expired.
Connecting to 10.20.1.6:80: This operation returned because the timeout period expired.
Connecting to 10.20.1.6:80: This operation returned because the timeout period expired.
Connecting to 10.20.1.6:80: This operation returned because the timeout period expired.
Connecting to 10.20.1.6:80:
Sent = 3, Received = 0, Lost = 3 (100% loss),
Minimum = 0.00ms, Maximum = 0.00ms, Average = 0.00ms
Убедитесь, что локальный брандмауэр разрешает передачу VPN-трафика и открывает правильные порты.
Убедитесь, что локальное VPN-устройство использует метод шифрования, совместимый с VPN-шлюзом Azure. Для маршрутизации на основе политик VPN-шлюз Azure поддерживает алгоритмы шифрования AES256, AES128 и 3DES. Шлюзы на основе маршрутов поддерживают AES256 и 3DES. Дополнительные сведения см. в разделе О VPN-устройствах и параметрах IPsec/IKE для подключений VPN-шлюза типа "сеть — сеть".
Проверка проблем с VPN-шлюзом Azure
Следующие рекомендации полезны для определения проблемы с VPN-шлюзом Azure:
Проверьте журналы диагностики VPN-шлюза Azure для потенциальных проблем. Дополнительные сведения см. в пошаговые инструкции. Сбор журналов диагностики шлюза виртуальных сетей Azure Resource Manager.
Убедитесь, что VPN-шлюз Azure и локальное VPN-устройство настроены с тем же общим ключом проверки подлинности. Вы можете просмотреть общий ключ, хранящийся VPN-шлюзом Azure, с помощью следующей команды Azure CLI:
azure network vpn-connection shared-key show <<resource-group>> <<vpn-connection-name>>
Используйте команду, соответствующую локальному VPN-устройству, чтобы отобразить общий ключ, настроенный для этого устройства.
Убедитесь, что подсеть шлюза GatewaySubnet с VPN-шлюзом Azure не связана с NSG.
Сведения о подсети можно просмотреть с помощью следующей команды Azure CLI:
azure network vnet subnet show -g <<resource-group>> -e <<vnet-name>> -n GatewaySubnet
Убедитесь, что поле данных с именем идентификатор группы безопасности сети. В следующем примере показаны результаты для экземпляра GatewaySubnet, имеющего назначенную группу безопасности сети (vpn-шлюза). Это может предотвратить правильную работу шлюза, если для этой группы безопасности сети определены какие-либо правила.
C:\>azure network vnet subnet show -g profx-prod-rg -e profx-vnet -n GatewaySubnet
info: Executing command network vnet subnet show
+ Looking up virtual network "profx-vnet"
+ Looking up the subnet "GatewaySubnet"
data: Id : /subscriptions/########-####-####-####-############/resourceGroups/profx-prod-rg/providers/Microsoft.Network/virtualNetworks/profx-vnet/subnets/GatewaySubnet
data: Name : GatewaySubnet
data: Provisioning state : Succeeded
data: Address prefix : 10.20.3.0/27
data: Network Security Group id : /subscriptions/########-####-####-####-############/resourceGroups/profx-prod-rg/providers/Microsoft.Network/networkSecurityGroups/VPN-Gateway-Group
info: network vnet subnet show command OK
Убедитесь, что виртуальные машины в виртуальной сети Azure настроены, чтобы разрешить трафик, поступающий извне виртуальной сети. Проверьте все правила NSG, связанные с подсетями, содержащими эти виртуальные машины. Все правила NSG можно просмотреть с помощью следующей команды Azure CLI:
azure network nsg show -g <<resource-group>> -n <<nsg-name>>
Убедитесь, что VPN-шлюз Azure подключен. Для проверки текущего состояния VPN-подключения Azure можно использовать следующую команду Azure PowerShell. Параметр <<connection-name>>
— это имя VPN-подключения Azure, которое связывает шлюз виртуальной сети и локальный шлюз.
Get-AzureRmVirtualNetworkGatewayConnection -Name <<connection-name>> - ResourceGroupName <<resource-group>>
Следующие фрагменты кода выделяют выходные данные, созданные, если шлюз подключен (первый пример) и отключен (второй пример):
PS C:\> Get-AzureRmVirtualNetworkGatewayConnection -Name profx-gateway-connection -ResourceGroupName profx-prod-rg
AuthorizationKey :
VirtualNetworkGateway1 : Microsoft.Azure.Commands.Network.Models.PSVirtualNetworkGateway
VirtualNetworkGateway2 :
LocalNetworkGateway2 : Microsoft.Azure.Commands.Network.Models.PSLocalNetworkGateway
Peer :
ConnectionType : IPsec
RoutingWeight : 0
SharedKey : ####################################
ConnectionStatus : Connected
EgressBytesTransferred : 55254803
IngressBytesTransferred : 32227221
ProvisioningState : Succeeded
...
PS C:\> Get-AzureRmVirtualNetworkGatewayConnection -Name profx-gateway-connection2 -ResourceGroupName profx-prod-rg
AuthorizationKey :
VirtualNetworkGateway1 : Microsoft.Azure.Commands.Network.Models.PSVirtualNetworkGateway
VirtualNetworkGateway2 :
LocalNetworkGateway2 : Microsoft.Azure.Commands.Network.Models.PSLocalNetworkGateway
Peer :
ConnectionType : IPsec
RoutingWeight : 0
SharedKey : ####################################
ConnectionStatus : NotConnected
EgressBytesTransferred : 0
IngressBytesTransferred : 0
ProvisioningState : Succeeded
...
Другие проблемы
Следующие рекомендации помогают определить, возникает ли проблема с конфигурацией виртуальной машины узла, использованием пропускной способности сети или производительностью приложения.
Проверьте конфигурацию брандмауэра. Убедитесь, что брандмауэр в гостевой операционной системе, работающей на виртуальных машинах Azure в подсети, настроен правильно, чтобы разрешить разрешенный трафик из локальных диапазонов IP-адресов.
Убедитесь, что объем трафика не близок к ограничению пропускной способности, доступной VPN-шлюзу Azure. Как проверить это, зависит от VPN-устройства, работающего локально. Например, если вы используете RRAS в Windows Server, вы можете использовать монитор производительности для отслеживания объема полученных и передаваемых данных через VPN-подключение. Используя объект RAS Total, выберите счетчики байтов,полученных/с и байтов, передаваемых/с:
счетчики производительности
Результаты следует сравнить с пропускной способностью, доступной для VPN-шлюза (от 100 Мбит/с для номера SKU уровня "Базовый" до 1,25 Гбит/с для SKU VPNGw3):
Убедитесь, что вы развернули правильное количество и размер виртуальных машин для загрузки приложения. Определите, выполняются ли виртуальные машины в виртуальной сети Azure медленно. Если это так, они могут быть перегружены, может быть слишком мало для обработки нагрузки или подсистемы балансировки нагрузки могут быть неправильно настроены. Чтобы определить это, записывать и анализировать диагностические сведения. Вы можете изучить результаты с помощью портала Azure, но многие сторонние средства также доступны, которые могут предоставить подробные сведения о данных о производительности.
Защиту от вредоносных ресурсов можно использовать для защиты от исчерпания вредоносных ресурсов. защиты от атак DDoS Azure, в сочетании с рекомендациями по проектированию приложений, предоставляет расширенные функции защиты от атак DDoS. Вы должны включить защиту от атак DDOS Azure в любой виртуальной сети периметра.
Убедитесь, что приложение эффективно использует облачные ресурсы. Инструментирование кода приложения, выполняемого на каждой виртуальной машине, чтобы определить, являются ли приложения наиболее подходящими для использования ресурсов. Вы можете использовать такие средства, как Application Insights.
Дальнейшие действия
Документация по продукту:
- виртуальные машины Linux в Azure
- Что такое Azure PowerShell?
- Что такое виртуальная сеть Azure?
- Что такое Azure CLI?
- Что такое VPN-шлюз?
- виртуальные машины Windows в Azure
Модули Microsoft Learn:
- Настройка ресурсов Azure с помощью средств
- Настройка VPN-шлюза
- создание виртуальной машины Linux в Azure
- Создание виртуальной машины Windows в Azure