En este artículo se proporcionan algunas sugerencias para solucionar problemas de una conexión vpn Gateway entre una red local y Azure. Para obtener información general sobre cómo solucionar errores comunes relacionados con vpn, consulte Solución de problemas de errores comunes relacionados con vpn.
Comprobación de que el dispositivo VPN funciona correctamente
Las siguientes recomendaciones son útiles para determinar si el dispositivo VPN local funciona correctamente.
Compruebe los archivos de registro generados por el dispositivo VPN para ver si hay errores o errores. Esto le ayudará a determinar si el dispositivo VPN funciona correctamente. La ubicación de esta información variará según el dispositivo. Por ejemplo, si usa RRAS en Windows Server, puede usar el siguiente comando de PowerShell para mostrar la información del evento de error para el servicio RRAS:
Get-EventLog -LogName System -EntryType Error -Source RemoteAccess | Format-List -Property *
La propiedad Message de cada entrada proporciona una descripción del error. Algunos ejemplos comunes son:
Incapacidad de conectarse, posiblemente debido a una dirección IP incorrecta especificada para la puerta de enlace de VPN de Azure en la configuración de la interfaz de red VPN 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 :La clave compartida incorrecta que se especifica en la configuración de la interfaz de red VPN de RRAS.
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 :
También puede obtener información del registro de eventos sobre los intentos de conexión a través del servicio RRAS mediante el siguiente comando de PowerShell:
Get-EventLog -LogName Application -Source RasClient | Format-List -Property *
En caso de error de conexión, este registro contendrá errores similares a los siguientes:
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 :
Comprobación de la conectividad
Compruebe la conectividad y el enrutamiento en la puerta de enlace de VPN. Es posible que el dispositivo VPN no enrute correctamente el tráfico a través de Azure VPN Gateway. Use una herramienta como PsPing para comprobar la conectividad y el enrutamiento a través de la puerta de enlace de VPN. Por ejemplo, para probar la conectividad desde una máquina local a un servidor web ubicado en la red virtual, ejecute el siguiente comando (reemplazando <<web-server-address>> por la dirección del servidor web):
PsPing -t <<web-server-address>>:80
Si la máquina local puede enrutar el tráfico al servidor web, debería ver una salida similar a la siguiente:
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
Si el equipo local no puede comunicarse con el destino especificado, verá mensajes como este:
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
Compruebe que el firewall local permite que el tráfico VPN pase y que se abran los puertos correctos.
Compruebe que el dispositivo VPN local usa un método de cifrado compatible con Azure VPN Gateway. Para el enrutamiento basado en directivas, Azure VPN Gateway admite los algoritmos de cifrado AES256, AES128 y 3DES. Las puertas de enlace basadas en rutas admiten AES256 y 3DES. Para obtener más información, consulte Acerca de los dispositivos VPN e parámetros de IPsec/IKE para conexiones vpn Gateway de sitio a sitio.
Comprobación de problemas con Azure VPN Gateway
Las siguientes recomendaciones son útiles para determinar si hay un problema con Azure VPN Gateway:
Examine los registros de diagnóstico de Azure VPN Gateway para detectar posibles problemas. Para más información, paso a paso: Capturar registros de diagnóstico de puerta de enlace de red virtual de Azure Resource Manager.
Compruebe que la puerta de enlace de VPN de Azure y el dispositivo VPN local están configurados con la misma clave de autenticación compartida. Puede ver la clave compartida almacenada por la puerta de enlace de VPN de Azure mediante el siguiente comando de la CLI de Azure:
azure network vpn-connection shared-key show <<resource-group>> <<vpn-connection-name>>
Use el comando adecuado para el dispositivo VPN local para mostrar la clave compartida configurada para ese dispositivo.
Compruebe que la GatewaySubnet subred que contiene la puerta de enlace de VPN de Azure no está asociada a un grupo de seguridad de red.
Puede ver los detalles de la subred mediante el siguiente comando de la CLI de Azure:
azure network vnet subnet show -g <<resource-group>> -e <<vnet-name>> -n GatewaySubnet
Asegúrese de que no hay ningún campo de datos denominado id. de grupo de seguridad de red. En el ejemplo siguiente se muestran los resultados de una instancia de GatewaySubnet que tiene un grupo de seguridad de red asignado (VPN-Gateway-Group). Esto puede impedir que la puerta de enlace funcione correctamente si hay reglas definidas para este grupo de seguridad de red.
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
Compruebe que las máquinas virtuales de la red virtual de Azure están configuradas para permitir el tráfico procedente de fuera de la red virtual. Compruebe las reglas de NSG asociadas a subredes que contengan estas máquinas virtuales. Puede ver todas las reglas de NSG mediante el siguiente comando de la CLI de Azure:
azure network nsg show -g <<resource-group>> -n <<nsg-name>>
Compruebe que la puerta de enlace de VPN de Azure está conectada. Puede usar el siguiente comando de Azure PowerShell para comprobar el estado actual de la conexión VPN de Azure. El parámetro <<connection-name>> es el nombre de la conexión VPN de Azure que vincula la puerta de enlace de red virtual y la puerta de enlace local.
Get-AzureRmVirtualNetworkGatewayConnection -Name <<connection-name>> - ResourceGroupName <<resource-group>>
Los fragmentos de código siguientes resaltan la salida generada si la puerta de enlace está conectada (el primer ejemplo) y desconectada (el segundo ejemplo):
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
...
Varios problemas
Las siguientes recomendaciones son útiles para determinar si hay un problema con la configuración de la máquina virtual host, el uso del ancho de banda de red o el rendimiento de la aplicación:
Compruebe la configuración del firewall. Compruebe que el firewall del sistema operativo invitado que se ejecuta en las máquinas virtuales de Azure de la subred está configurado correctamente para permitir el tráfico permitido desde los intervalos IP locales.
Compruebe que el volumen de tráfico no está cerca del límite del ancho de banda disponible para la puerta de enlace de VPN de Azure. Cómo comprobar esto depende del dispositivo VPN que se ejecuta en el entorno local. Por ejemplo, si usa RRAS en Windows Server, puede usar el Monitor de rendimiento para realizar un seguimiento del volumen de datos que se reciben y transmiten a través de la conexión VPN. Con el objeto total de RAS de, seleccione los contadores de bytes recibidos por segundo bytes y bytes transmitidos por segundo:
Debe comparar los resultados con el ancho de banda disponible para la puerta de enlace de VPN (de 100 Mbps para la SKU básica a 1,25 Gbps para la SKU vpnGw3):
Compruebe que ha implementado el número correcto y el tamaño de las máquinas virtuales para la carga de la aplicación. Determine si alguna de las máquinas virtuales de la red virtual de Azure se está ejecutando lentamente. Si es así, pueden sobrecargarse, puede haber demasiados para controlar la carga o es posible que los equilibradores de carga no estén configurados correctamente. Para determinar esto, capturar y analizar información de diagnóstico. Puede examinar los resultados mediante Azure Portal, pero muchas herramientas de terceros también están disponibles que pueden proporcionar información detallada sobre los datos de rendimiento.
Puede usar Azure DDoS Protection para ayudar a protegerse contra el agotamiento de recursos malintencionados. Azure DDoS Protection, combinado con los procedimientos recomendados de diseño de aplicaciones, proporciona características mejoradas de mitigación de DDoS para proporcionar más defensa contra ataques DDoS. Debe habilitar azure DDOS Protection en cualquier red virtual perimetral.
Compruebe que la aplicación está haciendo un uso eficaz de los recursos en la nube. Instrumente el código de aplicación que se ejecuta en cada máquina virtual para determinar si las aplicaciones están haciendo el mejor uso de los recursos. Puede usar herramientas como Application Insights.
Pasos siguientes
Documentación del producto:
- máquinas virtuales Linux en Azure
- ¿Qué es Azure PowerShell?
- ¿Qué es Azure Virtual Network?
- ¿Qué es la CLI de Azure?
- ¿Qué es VPN Gateway?
- máquinas virtuales Windows en Azure
Módulos de Microsoft Learn:
- Configuración de recursos de Azure con herramientas
- Configuración del de VPN Gateway
- Creación de una máquina virtual Linux en Azure
- Creación de una máquina virtual Windows en Azure