Preguntas más frecuentes sobre Virtual WAN

Artículo
03/27/2024

¿Qué es Azure Virtual WAN en GA?

Sí, Azure Virtual WAN está disponible con carácter general (GA). Sin embargo, Virtual WAN consta de varias características y escenarios. Hay características o escenarios dentro de Virtual WAN en los que Microsoft aplica la etiqueta de versión preliminar. En esos casos, la característica específica o el propio escenario se encuentra en versión preliminar. Si no usa una característica específica en vista previa, se aplica la compatibilidad GA normal. Para más información sobre la compatibilidad de la versión preliminar, consulte Términos de uso complementarios de las versiones preliminares de Microsoft Azure.

¿Qué ubicaciones y regiones están disponibles?

Para obtener información, consulte Ubicaciones y regiones disponibles.

¿El usuario necesita disponer de una topología radial con los dispositivos SD-WAN/VPN para usar Azure Virtual WAN?

Virtual WAN proporciona muchas funcionalidades integradas en un único panel, como la conectividad VPN de sitio a sitio, la conectividad de usuario y P2S, la conectividad de ExpressRoute, la conectividad de Virtual Network, la interconectividad de ExpressRoute de VPN, la conectividad transitiva de red virtual a red virtual, el enrutamiento centralizado, Azure Firewall y la seguridad de Firewall Manager, la supervisión, el cifrado de ExpressRoute y muchas otras funcionalidades. No es necesario disponer de todos estos casos de uso para empezar a usar Virtual WAN. Puede empezar a trabajar con uno solo de estos.

La arquitectura de Virtual WAN es una arquitectura "hub and spoke" con escalado y rendimiento integrados, donde las ramas (dispositivos VPN/SD-WAN), los usuarios (clientes de VPN de Azure, openVPN o IKEv2), los circuitos ExpressRoute y las instancias de Virtual Network sirven como radios para los centros de conectividad virtuales. Todos los centros de conectividad están conectados en una malla completa en una red WAN virtual estándar, lo que facilita al usuario el uso de la red troncal de Microsoft para la conectividad de cualquier tipo (cualquier radio). En el caso de la topología radial de los dispositivos SD-WAN/VPN, los usuarios pueden configurarla manualmente en el portal de Azure Virtual WAN o usar el CPE del asociado de Virtual WAN (SD-WAN/VPN) para configurar la conectividad con Azure.

Los asociados de Virtual WAN proporcionan automatización de la conectividad, que es la capacidad de exportar la información del dispositivo a Azure, descargar la configuración de Azure y establecer la conectividad con el centro de conectividad de Azure Virtual WAN. Para la conectividad de punto a sitio/VPN de usuario, se admiten el cliente de VPN de Azure, OpenVPN o IKEv2.

¿Se pueden deshabilitar los centros de conectividad totalmente en malla en una instancia de Virtual WAN?

Virtual WAN se ofrece en dos variedades: Básico y Estándar. En la instancia de Virtual WAN básica, los centros de conectividad no están en malla. En una instancia de Virtual WAN estándar, los centros de conectividad están en malla y se conectan automáticamente cuando la instancia se configura por primera vez. No es necesario que el usuario haga nada específico. El usuario tampoco tiene que deshabilitar ni habilitar la funcionalidad para obtener concentradores en malla. Virtual WAN ofrece muchas opciones de enrutamiento para dirigir el tráfico entre radios cualesquiera (VNet, VPN o ExpressRoute). Proporciona la facilidad de los centros de conectividad totalmente en malla, así como la flexibilidad de enrutar el tráfico según sus necesidades.

¿Cómo se administran Availability Zones y la resistencia en Virtual WAN?

Virtual WAN es una colección de centros de conectividad y servicios que están disponibles en el centro de conectividad. El usuario puede tener tantas instancias de Virtual WAN como necesite. En un centro de Virtual WAN hay varios servicios, como VPN, ExpressRoute, etc. Cada uno de estos servicios se implementa automáticamente en Availability Zones (excepto Azure Firewall), siempre y cuando la región admita Availability Zones. Si una región se convierte en una zona de disponibilidad después de la implementación inicial en el centro de conectividad, el usuario puede volver a crear las puertas de enlace, lo que desencadenará una implementación de Availability Zones. Todas las puertas de enlace se aprovisionan en un centro de conectividad como activo-activo, lo que implica que hay resistencia integrada dentro de un centro de conectividad. Los usuarios pueden conectarse a varios centros de conectividad si desean resistencia entre regiones.

Actualmente, Azure Firewall se puede implementar de modo que admita Availability Zones mediante el portal de Azure Firewall Manager, PowerShell o la CLI. De momento no hay forma de configurar un firewall existente para implementarlo en zonas de disponibilidad. Tiene que eliminar y volver a implementar la instancia de Azure Firewall.

Aunque el concepto de Virtual WAN es global, el recurso de Virtual WAN real se basa en Resource Manager y se implementa de forma regional. En caso de que la propia región de Virtual WAN tenga un problema, todos los centros de conectividad de esa instancia de Virtual WAN seguirán funcionando tal cual, pero el usuario no podrá crear nuevos centros de conectividad hasta que la región de Virtual WAN esté disponible.

No, cada instancia de centro virtual de Azure debe tener su propio firewall. Se producirá un error en la implementación de rutas personalizadas para que apunten al firewall de otro centro protegido y no se completará correctamente. Considere la posibilidad de convertir esos centros en centros protegidos con sus propios firewalls.

¿Qué cliente admite la red privada virtual de usuario (de punto a sitio) de Azure Virtual WAN?

Virtual WAN admite el cliente de VPN de Azure, el cliente de OpenVPN o cualquier cliente de IKEv2. La autenticación de Microsoft Entra se admite con el cliente de VPN de Azure. Como mínimo, se requiere la versión 17763.0 o superior del sistema operativo de cliente de Windows 10. Los clientes de OpenVPN pueden admitir la autenticación basada en certificados. Una vez que se haya seleccionado la autenticación basada en certificados en la puerta de enlace, verá el archivo .ovpn* que se va a descargar en el dispositivo. IKEv2 admite la autenticación basada en certificados y RADIUS.

En el caso de la red privada virtual de usuario (de punto a sitio), ¿por qué el grupo de clientes de P2S se divide en dos rutas?

Cada puerta de enlace tiene dos instancias. La división se produce para que cada instancia de la puerta de enlace pueda asignar de forma independiente las direcciones IP de cliente para los clientes conectados, y el tráfico de la red virtual se redirija a la instancia de puerta de enlace correcta para evitar el salto de instancias entre puertas de enlace.

¿Cómo puedo agregar servidores DNS para los clientes de P2S?

Hay dos opciones para agregar servidores DNS para los clientes de P2S. Se prefiere el primer método porque agrega los servidores DNS personalizados a la puerta de enlace en lugar del cliente.

Use el siguiente script de PowerShell para agregar los servidores DNS personalizados. Reemplace los valores por los de su entorno.

// Define variables
$rgName = "testRG1"
$virtualHubName = "virtualHub1"
$P2SvpnGatewayName = "testP2SVpnGateway1"
$vpnClientAddressSpaces = 
$vpnServerConfiguration1Name = "vpnServerConfig1"
$vpnClientAddressSpaces = New-Object string[] 2
$vpnClientAddressSpaces[0] = "192.168.2.0/24"
$vpnClientAddressSpaces[1] = "192.168.3.0/24"
$customDnsServers = New-Object string[] 2
$customDnsServers[0] = "7.7.7.7"
$customDnsServers[1] = "8.8.8.8"
$virtualHub = $virtualHub = Get-AzVirtualHub -ResourceGroupName $rgName -Name $virtualHubName
$vpnServerConfig1 = Get-AzVpnServerConfiguration -ResourceGroupName $rgName -Name $vpnServerConfiguration1Name

// Specify custom dns servers for P2SVpnGateway VirtualHub while creating gateway
createdP2SVpnGateway = New-AzP2sVpnGateway -ResourceGroupName $rgname -Name $P2SvpnGatewayName -VirtualHub $virtualHub -VpnGatewayScaleUnit 1 -VpnClientAddressPool $vpnClientAddressSpaces -VpnServerConfiguration $vpnServerConfig1 -CustomDnsServer $customDnsServers

// Specify custom dns servers for P2SVpnGateway VirtualHub while updating existing gateway
$P2SVpnGateway = Get-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName
$updatedP2SVpnGateway = Update-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName -CustomDnsServer $customDnsServers 

// Re-generate Vpn profile either from PS/Portal for Vpn clients to have the specified dns servers

O bien, si usa el cliente de VPN de Azure para Windows 10, puede modificar el archivo XML de perfil descargado y agregar las etiquetas <dnsservers><dnsserver></dnsserver></dnsservers> antes de importarlo.

   <azvpnprofile>
   <clientconfig>

       <dnsservers>
           <dnsserver>x.x.x.x</dnsserver>
           <dnsserver>y.y.y.y</dnsserver>
       </dnsservers>

   </clientconfig>
   </azvpnprofile>

En el caso de la red privada virtual de usuario (de punto a sitio), ¿cuántos clientes se admiten?

En la tabla siguiente se describe el número de conexiones simultáneas y el rendimiento agregado de la puerta de enlace de VPN de punto a sitio admitido en diferentes unidades de escalado.

Unidad de escalado	Instancias de puerta de enlace	Conexiones simultáneas que se admiten	Rendimiento agregado
1	2	500	0,5 Gbps
2	2	500	1 Gbps
3	2	500	1,5 Gbps
4	2	1000	2 Gbps
5	2	1000	2,5 Gbps
6	2	1000	3 Gbps
7	2	5000	3,5 Gbps
8	2	5000	4 Gbps
9	2	5000	4,5 Gbps
10	2	5000	5 Gbps
11	2	10000	5,5 Gbps
12	2	10000	6 Gbps
13	2	10000	6,5 Gbps
14	2	10000	7 Gbps
15	2	10000	7,5 Gbps
16	2	10000	8 Gbps
17	2	10000	8,5 Gbps
18	2	10000	9 Gbps
19	2	10000	9,5 Gbps
20	2	10000	10 Gbps
40	4	20000	20 Gbps
60	6	30000	30 Gbps
80	8	40000	40 Gbps
100	10	50000	50 Gbps
120	12	60000	60 Gbps
140	14	70000	70 Gbps
160	16	80000	80 Gbps
180	18	90000	90 Gbps
200	20	100000	100 Gbps

Como ejemplo, supongamos que el usuario elige 1 unidad de escalado. Cada unidad de escalado implica una puerta de enlace activo-activo implementada, y cada una de las instancias (2, en este caso) admitiría hasta 500 conexiones. Dado que puede obtener 500 conexiones x 2 por puerta de enlace, no significa que tenga previstas 1000 en lugar de 500 para esta unidad de escalado. Es posible que se deban atender las instancias en que la conectividad de las 500 conexiones adicionales pueda sufrir interrupciones si supera el recuento de conexiones recomendado.

En el caso de las puertas de enlace con unidades de escalado superiores a 20, se implementan pares adicionales de instancias de puerta de enlace con gran disponibilidad para proporcionar capacidad adicional para conectar a los usuarios. Cada uno de estos pares de instancias admite hasta 10 000 usuarios adicionales. Por ejemplo, si implementa una puerta de enlace con 100 unidades de escalado, se implementan 5 pares de puertas de enlace (10 instancias en total) y se pueden conectar hasta 50 000 usuarios (10 000 x 5 pares de puertas de enlace) a la vez.

Además, asegúrese de planear el tiempo de inactividad en caso de que decida escalar o reducir verticalmente en la unidad de escalado o cambiar la configuración de punto a sitio en VPN Gateway.

¿Qué son las unidades de escalado de puerta de enlace de Virtual WAN?

Una unidad de escalado es una unidad definida para obtener un rendimiento agregado de una puerta de enlace de un centro de conectividad virtual. 1 unidad de escalado de VPN = 500 Mbps. 1 unidad de escalado de ExpressRoute = 2 Gbps. Ejemplo: 10 unidades de escalado de VPN significarían 500 Mbps * 10 = 5 Gbps.

¿Cuál es la diferencia entre una puerta de enlace de Azure Virtual Network (VPN Gateway) y una instancia de VPN Gateway de Azure Virtual WAN?

Virtual WAN proporciona conectividad de sitio a sitio y a gran escala, y se ha creado para mejorar el rendimiento, la escalabilidad y la facilidad de uso. Cuando se conecta un sitio a una instancia de VPN Gateway de Virtual WAN, no es lo mismo que una puerta de enlace de red virtual normal que usa un tipo de puerta de enlace "VPN de sitio a sitio". Si quiere conectar usuarios remotos a Virtual WAN, use un tipo de puerta de enlace "VPN de punto a sitio". Las puertas de enlace de VPN de punto a sitio y de sitio a sitio son entidades independientes en el centro de Virtual WAN y deben implementarse individualmente. Del mismo modo, cuando se conecta un circuito ExpressRoute a un centro de conectividad de Virtual WAN, se usa un recurso para la puerta de enlace de ExpressRoute que es distinto al de la puerta de enlace de red virtual normal que usa el tipo de puerta de enlace "ExpressRoute".

Virtual WAN admite un rendimiento agregado de hasta 20 Gbps para VPN y ExpressRoute. Virtual WAN también tiene automatización para la conectividad con un ecosistema de asociados de dispositivos de la rama CPE. Los dispositivos de la rama CPE tienen una automatización integrada que se aprovisiona automáticamente y se conecta a Azure Virtual WAN. Estos dispositivos están disponibles en un creciente ecosistema de asociados de VPN y SD-WAN. Consulte la lista de asociados preferidos.

¿En qué difiere Virtual WAN de una puerta de enlace de Azure Virtual Network?

Una VPN de puerta de enlace de red virtual se limita a 100 túneles. En las conexiones, debe usar Virtual WAN para VPN a gran escala. Puede conectar hasta 1000 conexiones de rama por centro virtual con agregados de 20 Gbps por centro. Una conexión es un túnel de activo a activo del dispositivo VPN local al concentrador virtual. También puede tener varios centros virtuales por región, lo que significa que puede conectar más de 1000 ramas a una única región de Azure mediante la implementación de varios centros de conectividad de Virtual WAN en esa región de Azure, cada uno con su propia puerta de enlace de VPN de sitio a sitio.

¿Cuál es el algoritmo recomendado y los paquetes por segundo por instancia de sitio a sitio en el centro de conectividad de Virtual WAN? ¿Cuántos túneles se admiten por instancia? ¿Cuál es el rendimiento máximo admitido en un solo túnel?

Virtual WAN admite dos instancias de VPN Gateway activas de sitio a sitio en un centro virtual. Esto significa que hay dos instancias de VPN Gateway establecidas en modo activo-activo en un centro virtual. Durante las operaciones de mantenimiento, cada instancia se actualiza de una en una, por lo que un usuario puede experimentar una breve disminución en el rendimiento agregado de una instancia de puerta de enlace de VPN.

Aunque la VPN de Virtual WAN admite muchos algoritmos, nuestra recomendación es GCMAES256 para el cifrado IPSEC y la integridad para un rendimiento óptimo. AES256 y SHA256 se consideran menos avanzados y, por tanto, se puede esperar una degradación del rendimiento como la latencia y la caída de paquetes para tipos de algoritmo similares.

Los paquetes por segundo (o PPS) son un factor del número total de paquetes y el rendimiento admitido por instancia. Esto se explica mejor con un ejemplo. Supongamos que se implementa en un centro de conectividad de Virtual WAN una instancia de VPN Gateway de sitio a sitio de 500 Mbps de una unidad de escalado. Suponiendo un tamaño de paquete de 1400, el valor de PPS que se espera para esa instancia de VPN Gateway es como máximo = [(500 Mbps * 1024 * 1024) /8/1400] ~ 47000.

Virtual WAN incluye conceptos de conexión VPN, conexión de vínculo y túneles. Una única conexión VPN consta de conexiones de vínculo. Virtual WAN admite hasta cuatro conexiones de vínculo en una conexión VPN. Cada conexión de vínculo consta de dos túneles IPsec que finalizan en dos instancias de una puerta de enlace VPN activo-activo implementada en un centro virtual. El número total de túneles que pueden finalizar en una única instancia activa es 1000, lo que también implica que el rendimiento de una instancia estará disponible agregado en todos los túneles que se conectan a esa instancia. Cada túnel tiene también ciertos valores de rendimiento. En los casos de varios túneles conectados a una puerta de enlace de unidad de escalado de menor valor, es mejor evaluar la necesidad por túnel y planear una puerta de enlace de VPN que sea un valor agregado para el rendimiento en todos los túneles que terminan en la instancia de VPN.

Valores de varias unidades de escalado admitidas en Virtual WAN

Unidad de escalado	Rendimiento máximo por túnel (Mbps)	Número máximo de PPS por túnel	Rendimiento máximo por instancia (Mbps)	Número máximo de PPS por instancia
1	500	47 000	500	47 000
2	1000	94 000	1000	94 000
3	1.500	140 000	1.500	140 000
4	1.500	140 000	2000	187 000
5	1.500	140 000	2.500	234 000
6	1.500	140 000	3000	281 000
7	2300	215 000	3500	328 000
8	2300	215 000	4000	374 000
9	2300	215 000	4500	421 000
10	2300	215 000	5000	468 000
11	2300	215 000	5500	515 000
12	2300	215 000	6000	562 000
13	2300	215 000	6500	609 000
14	2300	215 000	7000	655 000
15	2300	215 000	7500	702 000
16	2300	215 000	8000	749 000
17	2300	215 000	8500	796 000
18	2300	215 000	9000	843 000
19	2300	215 000	9500	889 000
20	2300	215 000	10000	936 000

Nota

Todos los números se basan en el algoritmo de GCM.

¿Qué proveedores de dispositivos (asociados de Virtual WAN) se admiten?

En este momento, muchos asociados admiten la experiencia de Virtual WAN totalmente automatizada. Para más información, consulte Asociados de Virtual WAN.

¿Cuáles son los pasos de automatización de asociados de Virtual WAN?

Para conocer estos pasos, consulte Automatización de asociados de Virtual WAN.

¿Debo usar un dispositivo de asociado preferido?

No. Puede usar cualquier dispositivo compatible con VPN que cumpla los requisitos de Azure para la compatibilidad con IPsec de IKEv1 o IKEv2. Virtual WAN también tiene soluciones de asociado de CPE que automatizan la conectividad con Azure Virtual WAN, lo que facilita la configuración de conexiones VPN de IPsec a escala.

¿Cómo automatizan la conectividad con Azure Virtual WAN los asociados de Virtual WAN?

Las soluciones de conectividad definidas por software suelen administrar sus dispositivos de rama con un controlador o un centro de aprovisionamiento de dispositivos. El controlador puede usar las API de Azure para automatizar la conectividad a Azure Virtual WAN. La automatización incluye la carga de información de la rama, la descarga de la configuración de Azure, la configuración de túneles IPsec en los centros de conectividad virtuales de Azure y la configuración automática de la conectividad desde el dispositivo de rama a Azure Virtual WAN. Cuando tiene cientos de ramas, la conexión mediante asociados de CPE de Virtual WAN es fácil ya que la experiencia de incorporación elimina la necesidad de configurar y administrar la conectividad de IPsec a gran escala. Para más información, consulte Automatización de asociados de Virtual WAN.

¿Qué ocurre si el dispositivo que uso no está en la lista de asociados de Virtual WAN? ¿Lo puedo usar a pesar de todo para conectarme a una VPN de Azure Virtual WAN?

Sí, siempre que el dispositivo admita IPsec IKEv1 o IKEv2. Los asociados de Virtual WAN automatizan la conectividad desde el dispositivo hasta los puntos de conexión de VPN de Azure. Esto supone automatizar pasos como "carga de información de la rama", "IPsec y configuración" y "conectividad". Dado que el dispositivo no es del ecosistema de un asociado de Virtual WAN, tendrá que realizar el pesado trabajo de configurar manualmente Azure y actualizar el dispositivo para configurar la conectividad de IPsec.

¿Cómo consiguen los nuevos asociados que no aparecen en la lista de asociados de partida ser incluidos en ella?

Todas las API de WAN virtual son OpenAPI. Puede consultar la documentación de Automatización de asociados de Virtual WAN para valorar la viabilidad técnica. Un asociado ideal es aquel que tiene un dispositivo que se puede aprovisionar para la conectividad IPsec de IKEv1 o IKEv2. Una vez que la compañía haya completado el trabajo de automatización para su dispositivo CPE según las instrucciones de automatización proporcionadas anteriormente, puede ponerse en contacto con azurevirtualwan@microsoft.com para que se muestre en azurevirtualwan@microsoft.com. Si es un cliente que desea que una determinada solución de la empresa aparezca como un asociado de Virtual WAN, haga que la empresa se ponga en contacto con Virtual WAN mediante el envío de un correo electrónico a azurevirtualwan@microsoft.com.

¿Cómo es que Virtual WAN admite dispositivos SD-WAN?

Los asociados de Virtual WAN automatizan la conectividad IPsec a los puntos de conexión de VPN de Azure. Si el asociado de Virtual WAN es un proveedor de SD-WAN, se supone que el controlador de SD-WAN administra la automatización y la conectividad IPsec a los puntos de conexión de VPN de Azure. Si el dispositivo SD-WAN necesita su propio punto de conexión en lugar de la VPN de Azure para obtener funcionalidad de SD-WAN propietaria, puede implementar el punto de conexión de SD-WAN en una red virtual de Azure y coexistir con Azure Virtual WAN.

Virtual WAN admite el emparejamiento de BGP y también tiene la capacidad de implementar aplicaciones virtuales de red en un centro de conectividad de Virtual WAN.

¿Cuántos dispositivos VPN pueden conectarse a un único centro?

Se admiten hasta 1000 conexiones por concentrador virtual. Cada conexión consta de cuatro vínculos y cada conexión de vínculo admite dos túneles que están en una configuración activo-activo. Los túneles terminan en un elemento VPN Gateway del centro de conectividad virtual de Azure. Los vínculos representan el vínculo del ISP físico en la sucursal o el dispositivo VPN.

¿Qué es una conexión de rama a Azure Virtual WAN?

Una conexión desde una rama o un dispositivo VPN a Azure Virtual WAN es una conexión VPN que se conecta de forma virtual al sitio VPN y a Azure VPN Gateway en un centro de conectividad virtual.

¿Qué ocurre si el dispositivo VPN local solo tiene un túnel a una puerta de enlace de VPN de Azure Virtual WAN?

Una conexión de Azure Virtual WAN se compone de dos túneles. Una puerta de enlace de VPN de Virtual WAN se implementa en un centro de conectividad virtual en modo activo-activo, lo que significa que hay distintos túneles desde dispositivos locales que terminan en distintas instancias. Esta es la recomendación para todos los usuarios. Sin embargo, si, por algún motivo, el usuario decide tener solo un túnel a una de las instancias de puerta de enlace de VPN de Virtual WAN (mantenimiento, revisiones, etc.), la instancia de puerta de enlace se desconectará, el túnel se moverá a la instancia activa secundaria y el usuario podría experimentar una reconexión. Las sesiones de BGP no se moverán entre las instancias.

¿Qué ocurre durante un restablecimiento de puerta de enlace en una instancia de VPN Gateway de Virtual WAN?

El botón Restablecimiento de puerta de enlace debe usarse si todos los dispositivos locales funcionan según lo previsto, pero la conexión VPN de sitio a sitio en Azure está en estado desconectado. VPN Gateway de Virtual WAN siempre se implementa en un estado Activo-Activo de alta disponibilidad. Esto significa que siempre hay más de una instancia implementada en una instancia de VPN Gateway en cualquier momento. Cuando se usa el botón Restablecimiento de puerta de enlace, reinicia las instancias de VPN Gateway de forma secuencial, por lo que las conexiones no se interrumpen. Habrá un breve intervalo a medida que las conexiones se muevan de una instancia a otra, pero este intervalo debe ser inferior a un minuto. Además, tenga en cuenta que el restablecimiento de las puertas de enlace no cambiará las IP públicas.

Este escenario solo se aplica a las conexiones S2S.

¿Se puede conectar el dispositivo VPN local a varios centros de conectividad?

Sí. Al principio, el flujo de tráfico sería del dispositivo local al perímetro de red de Microsoft más cercano y, luego, al centro de conectividad virtual.

¿Hay disponibles nuevos recursos de Resource Manager para Virtual WAN?

Sí, Virtual WAN presenta nuevos recursos de Resource Manager. Para más información, consulte la introducción.

¿Puedo implementar y usar mi aplicación virtual de red favorita (en una red virtual de NVA) con Azure Virtual WAN?

Sí, puede conectar la red virtual de su aplicación virtual de red (NVA) favorita a Azure Virtual WAN.

¿Puedo crear una aplicación virtual de red dentro del centro de conectividad virtual?

Las aplicaciones virtuales de red (NVA) se pueden implementar en un centro de conectividad virtual. Para conocer los pasos necesarios para hacerlo, consulte Acerca de las aplicaciones virtuales de red en un centro de Virtual WAN.

¿Puede una red virtual de radio tener una puerta de enlace de red virtual?

No. La red virtual de radio no puede tener una puerta de enlace de red virtual si está conectada al centro de conectividad virtual.

¿Puede una red virtual de radio tener una instancia de Azure Route Server?

No. La red virtual de radio no puede tener un servidor de rutas si está conectada al centro virtual WAN.

¿Existe compatibilidad con BGP en la conectividad VPN?

Sí, BGP se admite. Al crear una VPN de sitio, puede proporcionar en ella los parámetros de BGP. Como resultado, las conexiones creadas en Azure para ese sitio estarán habilitadas para BGP.

¿Hay información de precios o licencias para Virtual WAN?

Sí. Consulte la página Precios.

¿Es posible construir Azure Virtual WAN con una plantilla de Resource Manager?

Se puede crear una configuración simple de una instancia de Virtual WAN con un centro y un sitio VPN mediante una plantilla de inicio rápido. Virtual WAN es principalmente un servicio REST o basado en el portal.

¿Pueden las redes virtuales radiales conectadas a un centro virtual comunicarse entre sí (tránsito V2V)?

Sí. Virtual WAN estándar admite la conectividad transitiva entre redes virtuales mediante el centro de conectividad de Virtual WAN al que están conectadas las redes virtuales. En la terminología de Virtual WAN, llamamos a estas rutas de acceso "tránsito local de red virtual de Virtual WAN" en el caso de las redes virtuales conectadas a un centro de conectividad de Virtual WAN dentro de una única región, y "tránsito global de red virtual de Virtual WAN" en el caso de las redes virtuales conectadas mediante varios centros de conectividad de Virtual WAN en dos o más regiones.

En algunos escenarios, además del tránsito local o global de red virtual de Virtual WAN, las redes virtuales de radio también se pueden emparejar directamente entre sí mediante el emparejamiento de red virtual. En este caso, el emparejamiento de red virtual tiene prioridad sobre la conexión transitiva del centro de conectividad de Virtual WAN.

¿Se permite la conectividad de rama a rama en Virtual WAN?

Sí, este tipo de conectividad está disponible en Virtual WAN. La rama se aplica conceptualmente a sitios VPN, circuitos ExpressRoute o usuarios de VPN de punto a sitio o de usuario. La conectividad de rama a rama está habilitada de forma predeterminada y se puede encontrar en la opción Configuración de WAN. De esta forma, los usuarios o ramas VPN se pueden conectar a otras ramas VPN y la conectividad de tránsito también se puede habilitar entre los usuarios de VPN y ExpressRoute.

¿Atraviesa el tráfico de rama a rama Azure Virtual WAN?

Sí. El tráfico de rama a rama atraviesa Azure Virtual WAN.

¿La instancia de Virtual WAN requiere ExpressRoute desde cada sitio?

No. Virtual WAN no requiere ExpressRoute desde cada sitio. Los sitios pueden estar conectados a una red de proveedor mediante un circuito de ExpressRoute. En el caso de los sitios conectados mediante ExpressRoute a un centro de conectividad virtual, así como a la VPN de IPsec en el mismo centro de conectividad, el centro de conectividad virtual proporciona conectividad de tránsito entre el usuario de VPN y el de ExpressRoute.

¿Hay un límite en el rendimiento o la conexión de la red al utilizar Azure Virtual WAN?

El rendimiento de red es por servicio en un centro de conectividad de Virtual WAN. En cada centro de conectividad, el rendimiento agregado de VPN es de hasta 20 Gbps, el rendimiento agregado de ExpressRoute es de hasta 20 Gbps y el rendimiento agregado de VPN de punto a sitio o VPN de usuario es de hasta 200 Gbps. El enrutador del centro de conectividad virtual admite hasta 50 Gbps con los flujos de tráfico de red virtual a red virtual y supone una carga de trabajo total de 2000 máquinas virtuales en todas las redes virtuales conectadas a un solo centro de conectividad virtual.

Para proteger la capacidad inicial sin tener que esperar a que el centro de conectividad virtual se escale horizontalmente cuando se necesite más rendimiento, puede establecer la capacidad mínima o modificarla según sea necesario. Consulte Acerca de la configuración del centro de conectividad virtual: capacidad del centro de conectividad. Para conocer las consecuencias en cuanto al costo, consulte el costo de una unidad de infraestructura de enrutamiento en la página Precios de Azure Virtual WAN.

Cuando los sitios VPN se conectan a un centro de conectividad, lo hacen con conexiones. Virtual WAN admite hasta 1000 conexiones o 2000 túneles IPsec por centro de conectividad virtual. Cuando los usuarios remotos se conectan a un centro de conectividad virtual, se conectan a la instancia de VPN Gateway P2S, que admite hasta 100 000 usuarios, en función de la unidad de escalado (ancho de banda) elegida para la instancia de VPN Gateway P2S en el centro de conectividad virtual.

¿Puedo usar NAT-T en las conexiones VPN?

Sí, se admite NAT traversal (NAT-T). VPN Gateway de Virtual WAN NO llevará a cabo ninguna funcionalidad similar a la de NAT en los paquetes internos hacia y desde los túneles de IPsec. En esta configuración, asegúrese de que el dispositivo local inicie el túnel IPsec.

¿Cómo se puede configurar una unidad de escalado en un valor concreto, como por ejemplo 20 Gbps?

Vaya a la puerta de enlace de VPN en un centro de conectividad del portal y haga clic en la unidad de escalado para cambiarla por el valor apropiado.

¿Azure Virtual WAN permite al dispositivo local usar varias ISP en paralelo o es siempre un solo túnel VPN?

Las soluciones en dispositivos locales pueden aplicar directivas de tráfico para dirigir el tráfico entre varios túneles en el centro de conectividad de Azure Virtual WAN (VPN Gateway en el centro de conectividad virtual).

¿Qué es la arquitectura de tránsito global?

Para obtener más información, vea Arquitectura de red de tránsito global y Virtual WAN.

¿Cómo se enruta el tráfico en la red troncal de Azure?

El tráfico sigue el patrón: dispositivo de rama ->ISP->perímetro de red de Microsoft->controlador de dominio de Microsoft (red virtual de centro)->perímetro de red de Microsoft->ISP->dispositivo de rama.

En este modelo, ¿qué es necesario en cada sitio? ¿Solo una conexión a Internet?

Sí. Una conexión a Internet y un dispositivo físico que admita IPsec, preferiblemente de nuestros asociados de Virtual WAN integrados. De forma opcional, puede administrar manualmente la configuración y la conectividad a Azure desde su dispositivo preferido.

¿Cómo habilito la ruta predeterminada (0.0.0.0/0) de una conexión (VPN, ExpressRoute o de red virtual)?

Un centro de conectividad virtual puede propagar una ruta predeterminada aprendida en una red virtual, una VPN de sitio a sitio y una conexión ExpressRoute si la marca está "habilitada" en la conexión. Esta marca está visible cuando el usuario edita una conexión de red virtual, una conexión VPN o una conexión ExpressRoute. De forma predeterminada, esta marca está deshabilitada cuando un sitio o circuito de ExpressRoute se conecta a un centro. Está habilitada de forma predeterminada cuando se agrega una conexión de red virtual para conectar una red virtual a un centro de conectividad virtual.

La ruta predeterminada no se origina en el centro de conectividad de Virtual WAN; la ruta se propaga si ya la ha aprendido el centro de Virtual WAN como resultado de la implementación de un firewall en el centro o en caso de que otro sitio conectado tenga habilitada la tunelización forzada. Las rutas predeterminadas no se propagan entre los centros (entre centros).

¿Es posible crear varios centros de conectividad de Virtual WAN en la misma región?

Sí. Los clientes ahora pueden crear más de un centro de conectividad en la misma región para la misma instancia de Azure Virtual WAN.

¿Cómo selecciona el centro de conectividad virtual de una instancia de Virtual WAN la mejor ruta desde varios centros?

Para obtener información, consulte la página Preferencias de enrutamiento del centro de conectividad virtual.

¿El centro de conectividad de Virtual WAN permite la conectividad entre circuitos ExpressRoute?

El tránsito entre ER y ER siempre se realiza a través de Global Reach. Las puertas de enlace de centro de conectividad virtual se implementan en las regiones de Azure o del controlador de dominio. Cuando dos circuitos ExpressRoute se conectan a través de Global Reach, no es necesario que el tráfico llegue desde los enrutadores perimetrales hasta el controlador de dominio del centro de conectividad.

¿Existe un concepto de peso en los circuitos ExpressRoute de Azure Virtual WAN o en las conexiones VPN?

Cuando varios circuitos ExpressRoute están conectados a un centro de conectividad virtual, el peso del enrutamiento en la conexión proporciona un mecanismo para que ExpressRoute en el centro de conectividad virtual prefiera un circuito antes que el otro. No hay ningún mecanismo para establecer un peso en una conexión VPN. Azure siempre prefiere una conexión ExpressRoute antes que una conexión VPN en un solo centro de conectividad.

¿Virtual WAN prefiere ExpressRoute antes que una VPN para el tráfico que sale de Azure?

Sí. ¿Virtual WAN prefiere ExpressRoute antes que una VPN para el tráfico que sale de Azure? Sin embargo, se puede configurar la preferencia de enrutamiento del centro virtual para cambiar la preferencia predeterminada. Para conocer los pasos necesarios para hacerlo, consulte Configuración de preferencia de enrutamiento de centro de conectividad virtual.

Cuando un centro de conectividad de Virtual WAN tiene un circuito ExpressRoute y un sitio VPN conectados a él, ¿qué haría que una ruta de conexión VPN se prefiriera por encima de ExpressRoute?

Cuando un circuito ExpressRoute se conecta a un centro de conectividad virtual, los enrutadores de Microsoft Edge son el primer nodo para la comunicación entre el entorno local y Azure. Estos enrutadores perimetrales se comunican con las puertas de enlace de ExpressRoute de Virtual WAN que, a su vez, aprenden las rutas del enrutador del centro de conectividad virtual que controla todas las rutas entre todas las puertas de enlace de Virtual WAN. Los enrutadores de Microsoft Edge procesan las rutas de ExpressRoute del centro de conectividad virtual con una preferencia más alta que las rutas aprendidas del entorno local.

Por algún motivo, si la conexión VPN se convierte en el medio principal por el que el centro de conectividad virtual aprende las rutas (por ejemplo, escenarios de conmutación por error entre ExpressRoute y VPN), a menos que el sitio de VPN tenga una longitud de ruta AS mayor, el centro de conectividad virtual seguirá compartiendo las rutas de VPN aprendidas con la puerta de enlace de ExpressRoute. Esto hace que los enrutadores de Microsoft Edge prefieran las rutas VPN antes que las rutas locales.

Cuando dos centros de conectividad (1 y 2) están conectados y hay un circuito ExpressRoute conectado como un lazo para ambos centros de conectividad, ¿cuál es la ruta de acceso de una red virtual conectada al centro de conectividad 1 para llegar a una red virtual conectada en el centro de conectividad 2?

El comportamiento actual es preferir la ruta de acceso del circuito ExpressRoute frente a una conexión entre centros para la conectividad de red virtual a red virtual. Sin embargo, esto no se recomienda en una configuración de Virtual WAN. Para resolver esto, puede realizar una de estas dos acciones:

Configure varios circuitos ExpressRoute (proveedores distintos) para que se conecten a un centro de conectividad y usen la conectividad entre centros de conectividad que proporciona Virtual WAN para los flujos de tráfico entre regiones.
Configure la ruta de acceso AS como preferencia de enrutamiento del centro virtual. Esto garantiza que el tráfico entre los dos centros atraviese el enrutador de centro virtual en cada centro y use la ruta de acceso de centro a centro en lugar de la ruta de acceso de ExpressRoute (que atraviesa los enrutadores de Microsoft Edge). Consulte Configure la preferencia de enrutamiento del centro de conectividad virtual para más información.

Cuando hay un circuito ExpressRoute conectado como lazo a un centro de Virtual WAN y a una red virtual independiente, ¿cuál es la ruta de acceso para que la red virtual autónoma llegue al centro de conectividad de Virtual WAN?

En el caso de las nuevas implementaciones, esta conectividad está bloqueada de forma predeterminada. Para permitir esta conectividad, puede habilitar estas alternancias de puerta de enlace de ExpressRoute en la hoja "Editar centro virtual" y en la hoja "Puerta de enlace de red virtual" del portal. Sin embargo, se recomienda mantener deshabilitadas estas alternancias y, en su lugar, crear una conexión de Virtual Network para conectar directamente redes virtuales independientes a un centro de Virtual WAN. Después, el tráfico de red virtual a red virtual atravesará el enrutador del concentrador de Virtual WAN, que ofrece un mejor rendimiento que la ruta de acceso de ExpressRoute. La ruta de acceso de ExpressRoute incluye la puerta de enlace de ExpressRoute, que tiene límites de ancho de banda inferiores al enrutador del concentrador, así como los enrutadores o MSEE de Microsoft Enterprise Edge, que es un salto adicional en la ruta de acceso de datos.

En el diagrama siguiente, ambas alternancias deben habilitarse para permitir la conectividad entre la red virtual independiente 4 y las redes virtuales conectadas directamente al centro 2 (red virtual 2 y red virtual 3): Permitir el tráfico desde redes de Virtual WAN remotas para la puerta de enlace de red virtual y Permitir el tráfico desde redes que no son de Virtual WAN para la puerta de enlace de ExpressRoute del centro virtual. Si se implementa una instancia de Azure Route Server en la VNet 4 independiente, y Route Server tiene habilitada rama a rama, se bloqueará la conectividad entre la VNet 1 y la VNet 4 independiente.

Habilitar o deshabilitar el botón de alternancia solo afectará al siguiente flujo de tráfico: el tráfico que fluye entre el centro de Virtual WAN y las redes virtuales independientes por el circuito ExpressRoute. Habilitar o deshabilitar el botón de alternancia no incurrirá en tiempo de inactividad para los demás flujos de tráfico (por ejemplo: el sitio local a la red virtual de radio 2 no se verá afectado, la red virtual 2 a la red virtual 3 no se verá afectada, etc.).

¿Se pueden crear concentradores en grupos de recursos diferente en Virtual WAN?

Sí. Actualmente, esta opción solo está disponible a través de PowerShell. En el portal de Virtual WAN es necesario que los centros de conectividad estén en el mismo grupo de recursos que el propio recurso de Virtual WAN.

¿Cuál es el espacio de direcciones de centro de conectividad recomendado durante la creación del centro?

El valor recomendado del espacio de direcciones de un centro de conectividad de Virtual WAN es /23. El centro de conectividad de Virtual WAN asigna subredes a varias puertas de enlace, como ExpressRoute, VPN de sitio a sitio, VPN de punto a sitio, Azure Firewall o un enrutador del centro de conectividad virtual. En los escenarios en los que se implementan aplicaciones virtuales de red (NVA) dentro de un centro de conectividad virtual, normalmente se crea una subred /28 para las instancias de NVA. Pero si el usuario tuviera que aprovisionar varias NVA, se podría asignar una subred /27. Por tanto, de cara a una arquitectura futura, mientras los centros de conectividad de Virtual WAN se implementan con un tamaño mínimo de /24, el espacio de direcciones de centro de conectividad recomendado en el momento de creación para que el usuario lo introduzca es /23.

¿Hay compatibilidad con IPv6 en un Virtual WAN?

IPv6 no se admite en el centro de conectividad de Virtual WAN y sus puertas de enlace. Si tiene una red virtual que tiene compatibilidad con IPv4 e IPv6 y desea conectar la red virtual a Virtual WAN, este escenario no se admite actualmente.

En el escenario de VPN de usuario de punto a sitio con salida de Internet a través de Azure Firewall, probablemente tendrá que desactivar la conectividad IPv6 en el dispositivo cliente para forzar el tráfico al centro de conectividad de Virtual WAN. Esto se debe a que, de forma predeterminada, los dispositivos modernos usan direcciones IPv6.

¿Cuál es la versión de API recomendada para utilizar en los scripts que automatizan varias funcionalidades de Virtual WAN?

Se requiere una versión mínima de 05-01-2022 (1 de mayo de 2022).

¿Hay algún límite de Virtual WAN?

Consulte la sección Límites de Virtual WAN en la página de límites de suscripciones y servicios.

¿Cuáles son las diferencias entre los tipos de instancias de Virtual WAN (básico y estándar)?

Consulte Redes WAN virtuales de tipo Básico y Estándar. Para ver los precios, consulte la página de precios.

¿Virtual WAN almacena datos de clientes?

No. Virtual WAN no almacena datos de clientes.

¿Hay proveedores de servicios administrados que pueden administrar Virtual WAN para usuarios como servicio?

Sí. Para obtener una lista de soluciones de proveedores de servicios administrados (MSP) habilitadas a través de Azure Marketplace, consulte el apartado Ofertas de Azure Marketplace de proveedores de servicios administrados de redes de Azure asociados.

¿En qué se diferencia el enrutamiento del centro de conectividad de Virtual WAN de Azure Route Server en una red virtual?

Tanto el centro de conectividad de Azure Virtual WAN como Azure Route Server proporcionan funcionalidades de emparejamiento de Protocolo de puerta de enlace de borde (BGP) que pueden usar las aplicaciones virtuales de red (NVA) para anunciar direcciones IP desde la NVA a las redes virtuales de Azure del usuario. Las opciones de implementación difieren en el sentido de que Azure Route Server suele implementarse mediante una red virtual de Customer Hub autogestionada, mientras que Azure Virtual WAN proporciona un servicio de concentrador completamente en malla sin intervención del usuario al que los clientes conectan sus distintos puntos de conexión de radio (red virtual de Azure, ramas locales con VPN de sitio a sitio o SDWAN, usuarios remotos con VPN de usuario remoto o de punto a sitio y conexiones privadas con ExpressRoute) y ofrecen el emparejamiento BGP para NVA implementadas en la red virtual radial junto con otras funcionalidades de VWAN, como la conectividad de tránsito entre redes virtuales, la conectividad de tránsito entre VPN y ExpressRoute, el enrutamiento personalizado o avanzado, la asociación y propagación de rutas personalizadas, intención o directivas de enrutamiento para una seguridad entre regiones sin problemas, centro seguro o Azure Firewall, etc. Para obtener más información sobre el emparejamiento BGP de Virtual WAN, consulte Emparejamiento BGP con un centro virtual.

Si uso un proveedor de seguridad de terceros (Zscaler, iBoss o Checkpoint) para proteger el tráfico de Internet, ¿por qué no veo el sitio de VPN asociado a él en Azure Portal?

Cuando decide implementar un proveedor de seguridad asociado para proteger el acceso a Internet para sus usuarios, el proveedor de seguridad de terceros crea un sitio VPN en su nombre. Este sitio de VPN no aparece en Azure Portal porque el proveedor crea automáticamente el proveedor de seguridad de terceros y no es un sitio VPN creado por el usuario.

Para obtener más información sobre las opciones disponibles de proveedores de seguridad de terceros y cómo configurarlas, consulte Implementación de un proveedor de seguridad asociado.

¿Se conservarán las comunidades BGP generadas por el entorno local en Virtual WAN?

Sí, las comunidades BGP generadas por el entorno local se conservarán en Virtual WAN. Se pueden usar los ASN públicos propios o los ASN privados para las redes locales. No se pueden usar los rangos reservados por Azure o IANA.

ASN reservados por Azure:
- ASN públicos: 8074, 8075, 12076
- ASN privados: 65515, 65517, 65518, 65519, 65520
- ASN reservados por IANA: 23456, 64496-64511, 65535-65551

¿Hay alguna manera de cambiar el ASN de una puerta de enlace de VPN?

No. Virtual WAN no admite cambios de ASN para puertas de enlace de VPN.

En Virtual WAN, ¿cuáles son los rendimientos estimados de la SKU de puerta de enlace de ExpressRoute?

Unidad de escalado	Conexiones por segundo	Megabits por segundo	Paquetes por segundo
1 unidad de escalado	14 000	2\.000	200 000
2 unidades de escalado	28 000	4\.000	400.000
3 unidades de escalado	42 000	6,000	600 000
4 unidades de escalado	56 000	8,000	800 000
5 unidades de escalado	70 000	10 000	1 000 000
6 unidades de escalado	84 000	12,000	1 200 000
7 unidades de escalado	98 000	14 000	1 400 000
8 unidades de escalado	112 000	16 000	1 600 000
9 unidades de escalado	126 000	18 000	1 800 000
10 unidades de escalado	140 000	20.000	2 000 000

*Las unidades de escalado de 2 a 10, durante las operaciones de mantenimiento, mantienen el rendimiento agregado. Sin embargo, la unidad de escalado 1, durante una operación de mantenimiento, puede ver una ligera variación en los números de rendimiento.

Si conecto un circuito local de ExpressRoute a un centro de conectividad de Virtual WAN, ¿podré acceder únicamente a las regiones en la misma área metropolitana que el circuito local?

Los circuitos locales solo se pueden conectar a puertas de enlace de ExpressRoute en su región de Azure correspondiente. Sin embargo, no hay ninguna limitación para enrutar el tráfico a redes virtuales radiales de otras regiones.

¿Por qué veo un mensaje y un botón denominado "Actualizar enrutador a la versión de software más reciente" en el portal?

Nota:

A partir de enero de 2024, el equipo de Virtual WAN ha empezado a actualizar los centros virtuales a la versión más reciente. Si no ha actualizado el centro, pero ahora observe que la versión del enrutador del centro indica "más reciente", el equipo de Virtual WAN actualizó el centro.

La infraestructura basada en Cloud Services para todo Azure está en desuso. Como resultado, el equipo de Virtual WAN ha estado trabajando en la actualización de enrutadores virtuales desde su infraestructura de Cloud Services actual a implementaciones basadas en Virtual Machine Scale Sets. Todos los centros virtuales recién creados se implementarán automáticamente en la infraestructura basada en Virtual Machine Scale Sets más reciente. Si navega al recurso del centro de conectividad de Virtual WAN y ve este mensaje y el botón, puede actualizar el enrutador a la versión más reciente haciendo clic en el botón. Si desea aprovechar las nuevas características de Virtual WAN, como el emparejamiento BGP con el centro, tendrá que actualizar el enrutador del centro virtual mediante Azure Portal. Si el botón no fuera visible, abra un caso de soporte técnico.

Solo podrá actualizar el enrutador del centro de conectividad virtual si todos los recursos (puertas de enlace, tablas de rutas o conexiones de red virtual) del centro de conectividad se encuentran en un estado correcto. Asegúrese de que todas las redes virtuales radiales estén en suscripciones activas o habilitadas y de que dichas redes no se eliminen. Además, como esta operación requiere la implementación de nuevos enrutadores de centro virtual basados en conjuntos de escalado de máquinas virtuales, se encontrará con un tiempo de inactividad esperado de 1 a 2 minutos para el tráfico de red virtual a red virtual a través del mismo centro y de 5 a 7 minutos para todos los demás flujos de tráfico a través del centro. Dentro de un único recurso de Virtual WAN, los centros de conectividad deben actualizarse de uno en uno en lugar de actualizar varios al mismo tiempo. Cuando la versión del enrutador dice "Más reciente", el centro de conectividad se actualiza. No habrá ningún cambio de comportamiento en el enrutamiento después de esta actualización.

Hay varias cosas a tener en cuenta con la actualización del enrutador del centro de conectividad virtual:

Si ya ha configurado el emparejamiento BGP entre el centro de Virtual WAN y una instancia de NVA en una red virtual radial, tendrá que eliminar y volver a crear el par BGP. Dado que las direcciones IP del enrutador del concentrador virtual cambian después de la actualización, también tendrá que volver a configurar la NVA para emparejarse con las nuevas direcciones IP del enrutador del centro virtual. Estas direcciones IP se representan como el campo "virtualRouterIps" en el JSON del recurso del centro virtual.
Si tiene una aplicación virtual de red (NVA) en el centro de conectividad virtual, tendrá que trabajar con el asociado de NVA para obtener instrucciones sobre cómo actualizar el centro de Virtual WAN.
Si el centro de conectividad virtual está configurado con más de 15 unidades de infraestructura de enrutamiento, escale el centro virtual a dos unidades de infraestructura de enrutamiento antes de intentar actualizar. Puede escalar horizontalmente el centro de conectividad a más de 15 unidades de infraestructura de enrutamiento después de actualizar dicho centro.

Si se produce un error en la actualización por cualquier motivo, el centro se recuperará automáticamente en la versión anterior para asegurarse de que todavía haya una configuración en funcionamiento.

Aspectos adicionales a tener en cuenta:

El usuario tendrá que tener un rol de propietario o colaborador para ver un estado preciso de la versión del enrutador del centro virtual. Si se asigna un rol de lector a un usuario en el recurso y la suscripción de Virtual WAN, Azure Portal muestra a ese usuario que el enrutador del centro de conectividad debe actualizarse a la versión más reciente, incluso si el centro ya está en la versión más reciente.
Si cambia su estado de suscripción de la red virtual de radio de deshabilitado a habilitado y, a continuación, actualiza el centro virtual, deberá actualizar la conexión de red virtual después de la actualización del centro virtual (por ejemplo, puede configurar la conexión de red virtual para propagarse a una etiqueta ficticia).
Si el centro está conectado a un gran número de redes virtuales de radio (60 o más), es posible que observe que 1 o más emparejamientos de red virtual radial entrarán en un estado con errores después de la actualización. Para restaurar estos emparejamientos de red virtual a un estado correcto después de la actualización, puede configurar las conexiones de red virtual para propagarse a una etiqueta ficticia, o bien puede eliminar y volver a crear estas conexiones de red virtual respectivas.

¿Hay un límite de ruta para los clientes de OpenVPN que se conectan a una puerta de enlace de VPN P2S de Azure?

El límite de ruta para los clientes de OpenVPN es 1000.

¿Cómo se calcula el contrato de nivel de servicio de Virtual WAN ?

Virtual WAN es una plataforma de red como servicio que tiene un contrato de nivel de servicio del 99,95 %. Sin embargo, Virtual WAN combina muchos componentes diferentes, como Azure Firewall, VPN de sitio a sitio, ExpressRoute, VPN de punto a sitio y aplicaciones virtuales de red integrada o de concentrador de Virtual WAN.

El contrato de nivel de servicio para cada componente se calcula individualmente. Por ejemplo, si ExpressRoute tiene un tiempo de inactividad de 10 minutos, la disponibilidad de ExpressRoute se calcularía como (Máximo de minutos disponibles - tiempo de inactividad) / Máximo de minutos disponibles * 100.

¿Puede cambiar el espacio de direcciones de la red virtual en una red virtual radial conectada al centro?

Sí, esto se puede hacer automáticamente sin necesidad de actualizar o restablecer la conexión de emparejamiento. Puede encontrar más información sobre cómo cambiar el espacio de direcciones de la red virtual aquí.

Mantenimiento de puerta de enlace controlada por el cliente de Virtual WAN

¿Qué servicios se incluyen en el ámbito de configuración de mantenimiento de las puertas de enlace de red?

Para Virtual WAN, puede configurar ventanas de mantenimiento para puertas de enlace de VPN de sitio a sitio y puertas de enlace de ExpressRoute.

¿Qué mantenimiento es compatible o no compatible con el mantenimiento controlado por el cliente?

Los servicios de Azure pasan por actualizaciones de mantenimiento periódicas para mejorar la funcionalidad, la confiabilidad, el rendimiento y la seguridad. Una vez configurada una ventana de mantenimiento para los recursos, el mantenimiento del sistema operativo invitado y el servicio se realizan durante esa ventana. Estas actualizaciones representan la mayoría de los elementos de mantenimiento que preocupan a clientes.

Las actualizaciones subyacentes de hardware de host y infraestructura del centro de datos no están cubiertas por el mantenimiento controlado por el cliente. Además, si hay un problema de seguridad de alta gravedad que podría poner en peligro a nuestros clientes, Azure podría necesitar invalidar el control del cliente de la ventana de mantenimiento e implementar el cambio. Estas son raras apariciones que solo se usarían en casos extremos.

¿Puedo recibir una notificación avanzada de mantenimiento?

En este momento, no se puede habilitar la notificación avanzada para el mantenimiento de los recursos de puerta de enlace de red.

¿Puedo configurar una ventana de mantenimiento inferior a cinco horas?

En este momento, debe configurar un mínimo de una ventana de cinco horas en la zona horaria preferida.

¿Puedo configurar una programación de mantenimiento que no se repita diariamente?

En este momento, debe configurar una ventana de mantenimiento diaria.

¿Los recursos de configuración de mantenimiento deben estar en la misma región que el recurso de puerta de enlace?

Sí.

¿Es necesario implementar una unidad de escalado de puerta de enlace mínima para que sea apta para el mantenimiento controlado por el cliente?

No.

¿Cuánto tiempo tarda la directiva de configuración de mantenimiento en ser efectiva después de asignarla al recurso de puerta de enlace?

Las puertas de enlace de red pueden tardar hasta 24 horas en seguir la programación de mantenimiento después de que la directiva de mantenimiento esté asociada al recurso de puerta de enlace.

¿Cómo debo planear las ventanas de mantenimiento al usar VPN y ExpressRoute en un escenario de coexistencia?

Al trabajar con VPN y ExpressRoute en un escenario de coexistencia o siempre que tenga recursos que actúen como copias de seguridad, se recomienda configurar ventanas de mantenimiento independientes. Este enfoque garantiza que el mantenimiento no afecte a los recursos de copia de seguridad al mismo tiempo.

He programado una ventana de mantenimiento para una fecha futura para uno de mis recursos. ¿Se pausarán las actividades de mantenimiento en este recurso hasta entonces?

No, las actividades de mantenimiento no se pausarán en el recurso durante el período anterior a la ventana de mantenimiento programada. Durante los días no cubiertos en la programación de mantenimiento, el mantenimiento continúa como de costumbre en el recurso.

Pasos siguientes

Para obtener más información sobre Virtual WAN, consulte el artículo acerca de Virtual WAN.