Preguntas más frecuentes sobre Virtual WAN

¿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 obtener más información sobre la compatibilidad con la versión preliminar, consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure.

¿Qué ubicaciones y regiones están disponibles?

Para ver las regiones disponibles para Virtual WAN, consulte Productos disponibles por región. Especifique Virtual WAN como nombre del producto.

¿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 solo panel de vidrio. Esto incluye:

• Conectividad VPN de sitio a sitio
• Conectividad de usuario/P2S
• Conectividad de ExpressRoute
• Conectividad de red virtual
• Interconectividad de VPN ExpressRoute
• Conectividad transitiva de red virtual a red virtual
• Enrutamiento centralizado
• Seguridad de Azure Firewall y Firewall Manager
• Monitoring
• Cifrado de ExpressRoute y
• Muchas otras funcionalidades

No es necesario tener todos estos casos de uso para empezar a utilizar 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 para la conectividad. 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 Azure Virtual WAN. Para la conectividad VPN de punto a sitio o usuario, se admite el cliente VPN de Azure, OpenVPN o el cliente IKEv2.

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

Virtual WAN viene en dos tipos: 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.

¿Por qué veo un error sobre el ámbito y la autorización no válidos para realizar operaciones en recursos de Virtual WAN?

Si ve un error en el formato siguiente, asegúrese de que tiene los permisos siguientes configurados: Roles y permisos de Virtual WAN.

Formato del mensaje de error: "El cliente con el identificador de objeto {} no tiene autorización para realizar la acción {} en el ámbito {} o el ámbito no es válido". Para más información sobre los permisos necesarios, visite {}. Si se concedió el acceso recientemente, actualice las credenciales".

¿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), si la región admite 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 como activo-activo, lo que implica que hay resistencia integrada dentro de un centro. Los usuarios pueden conectarse a varios centros de conectividad si desean resistencia entre regiones.

Actualmente, Azure Firewall se puede implementar para admitir zonas de disponibilidad mediante el portal de Azure Firewall Manager, PowerShell o la CLI. Actualmente no hay ninguna manera de configurar un firewall existente para que se implemente en zonas de disponibilidad. Debe eliminar y volver a implementar 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. Si la propia región de virtual WAN tiene un problema, todos los centros de esa WAN virtual siguen funcionando. Sin embargo, el usuario no puede crear nuevos centros hasta que la región de virtual WAN esté disponible.

¿Cómo se eliminan o limpian mis recursos de Virtual WAN?

Cuando ya no necesite los recursos que ha creado, elimínelos. Algunos de los recursos de Virtual WAN deben eliminarse en un orden determinado debido a las dependencias. La eliminación puede tardar unos 30 minutos.

1. Abra la WAN virtual que ha creado.

2. Seleccione un centro virtual asociado a la WAN virtual para abrir la página del centro.

3. Elimine todas las entidades de puerta de enlace siguiendo el orden siguiente para cada tipo de puerta de enlace. Esto puede tardar 30 minutos en completarse.

   VPN:

   • Desconectar sitios VPN
   • Eliminación de conexiones VPN
   • Eliminación de puertas de enlace de VPN

   ExpressRoute:

   • Eliminación de conexiones de ExpressRoute
   • Eliminación de puertas de enlace de ExpressRoute

4. Repita el proceso para todos los centros asociados a la WAN virtual.

5. Puede eliminar los centros en este momento o más adelante, cuando elimine el grupo de recursos.

6. Vaya al grupo de recursos en el portal de Azure.

7. Seleccione Eliminar grupo de recursos. Esto elimina los demás recursos del grupo de recursos, incluidos los centros de conectividad y la WAN virtual.

¿Es posible compartir el firewall en un centro protegido con otros centros?

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 VPN de Azure, el cliente OpenVPN o cualquier cliente IKEv2. La autenticación de Microsoft Entra se admite con el cliente VPN de Azure. Se requiere un mínimo del sistema operativo cliente de Windows 10 versión 17763.0 o superior. 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.

1. 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
   

2. O bien, si usa el cliente VPN de Azure para Windows 10, puede modificar el archivo XML del 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 VPN de punto a sitio compatible con diferentes unidades de escalado.

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.

Para VPN de usuario (punto a sitio), ¿se admite la aplicación registrada de Microsoft en Entra Id Authentication?

Sí, la aplicación registrada por Microsoft se admite en Virtual WAN. Puede migrar la VPN de usuario de una aplicación registrada manualmente a una aplicación registrada por Microsoft para una conectividad más segura.

¿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.

Escale o reduzca verticalmente la unidad de escalado de la puerta de enlace según sus necesidades. Consulte Acerca de la configuración de puerta de enlace de Virtual WAN para más información sobre la configuración de la puerta de enlace.

Para obtener más información sobre los límites de soporte para las unidades de escala del gateway, consulte:

• En Virtual WAN, ¿cuáles son los rendimientos estimados de la SKU de puerta de enlace de ExpressRoute? para las puertas de enlace de ExpressRoute
• ¿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? para puertas de enlace de VPN de sitio a sitio
• Para VPN de usuario (punto a sitio): ¿cuántos clientes se admiten? para pasarelas de VPN de usuario (punto a sitio)

¿Cuál es el impacto de modificar las unidades de escala de la puerta de enlace de red para una puerta de enlace ExpressRoute de Virtual WAN?

Al cambiar las unidades de escala del gateway, tenga en cuenta las siguientes consideraciones:

• Capacidad de tráfico: Asegúrese de que las unidades de escala aprovisionadas sean capaces de admitir los requisitos de tráfico.

• Reconexiones TCP: Puede experimentar reconexiones TCP durante el cambio de unidad de escalamiento, lo que puede provocar interrupciones menores.

• Impacto en los puntos de conexión privados: los cambios de unidad de escalado pueden afectar a la conectividad de los puntos de conexión privados. Revise la implementación y siga los procedimientos recomendados descritos en Uso de Private Link en Virtual WAN.

Para más información sobre las unidades de escala de puerta de enlace y la planificación de la capacidad, consulte Acerca de la configuración de puerta de enlace de Virtual WAN.

¿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. Consulta la lista de partners 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. Esto significa que puede conectar más de 1000 ramas a una sola región de Azure mediante la implementación de varios centros 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, los PPS esperados para esa instancia de puerta de enlace VPN en un máximo = [(500 Mbps * 1024 * 1024) / 8 / 1400] ~ 47000.

Virtual WAN tiene conceptos de conexión VPN, conexión de enlace 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 sola instancia activa es de 1000. Esto también implica que el rendimiento de una instancia está 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

¿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 los pasos de automatización de asociados, 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 procede de un ecosistema de asociados de Virtual WAN, debe realizar el trabajo pesado de tomar manualmente la configuración de 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 automatización de asociados de Virtual WAN para evaluar 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 empresa complete el trabajo de automatización para su dispositivo CPE en función de las directrices de automatización compartidas anteriores proporcionadas, puede ponerse en contacto con azurevirtualwan@microsoft.com para que se muestre aquí Conectividad a través de asociados. 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 BGP y también tiene la capacidad de implementar NVAs en un hub de la 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 el usuario decide tener solo 1 túnel a una de las instancias de puerta de enlace de VPN de Virtual WAN, si por algún motivo (mantenimiento, revisiones, etc.), la instancia de puerta de enlace se desconecta, el túnel se mueve a la instancia activa secundaria y el usuario podría experimentar una reconexión. Las sesiones de BGP no se mueven entre 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, restablecer las puertas de enlace no cambia las direcciones IP públicas.

Este escenario solo se aplica a las conexiones S2S.

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

Yes. 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 obtener más información, consulte La información general.

¿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.

¿Puedo conectar una red virtual a un centro virtual en un inquilino diferente?

Yes. Siga la guía en Conectar redes virtuales entre inquilinos a un hub 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 radial tener un servidor de Azure Route Server?

No. La red virtual radial no puede tener un servidor de rutas si está conectado al centro de conectividad de 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. Esto implica que todas las conexiones creadas en Azure para ese sitio están habilitadas para BGP.

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

Yes. Consulte la página Precios .

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

Se puede crear una configuración sencilla de una instancia de Virtual WAN con un centro de conectividad 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)?

Yes. 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, nos referimos a estas rutas de acceso como "tránsito de red virtual de Virtual WAN local" para las redes virtuales conectadas a un centro de Virtual WAN dentro de una sola región. El "Tránsito global de red virtual de Virtual WAN" es para redes virtuales conectadas a través de varios centros de Virtual WAN en dos o más regiones.

En algunos escenarios, las redes virtuales de radio también pueden conectarse directamente entre sí utilizando el emparejamiento de redes virtuales, además del tránsito de redes virtuales de Azure Virtual WAN locales o globales. 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 habilitación de la rama a rama está habilitada de forma predeterminada y se puede encontrar en la 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?

Yes. 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 esperar a que el centro virtual se escale horizontalmente cuando se necesite más rendimiento, puede establecer la capacidad mínima o modificar según sea necesario. Consulte Acerca de la configuración del centro virtual: capacidad del concentrador. Para obtener información sobre el costo, consulte el costo de la 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 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 dentro de un nodo central en el portal y, a continuación, seleccione la unidad de escalamiento para ajustarla a la configuración adecuada.

¿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 más información, consulte 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?

Yes. Una conexión a Internet y un dispositivo físico que admita IPsec, preferiblemente de nuestros asociados integrados de Virtual WAN. 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 predeterminada se propaga si el hub de Virtual WAN ya lo ha aprendido como resultado de la implementación de un firewall en el hub, o si otro sitio conectado tiene el túnel forzado habilitado.

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?

Yes. 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 transporte público entre urgencias y urgencias está disponible 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.

Routing Intent también se puede usar con directivas de enrutamiento de tráfico privado para habilitar la conectividad de tránsito de ExpressRoute a través de una aplicación de seguridad implementada en el centro virtual.

Para más información, consulte Acerca de Global Reach de Virtual WAN.

¿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?

Yes. ¿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, consulte Configuración de la preferencia de enrutamiento del centro 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 cualquier motivo, si la conexión VPN se convierte en el medio principal del centro de conectividad virtual para aprender rutas de (por ejemplo, escenarios de conmutación por error entre ExpressRoute y VPN), a menos que el sitio VPN tenga una longitud de ruta de acceso AS más larga, el centro virtual seguirá compartiendo las rutas aprendidas de VPN con la puerta de enlace de ExpressRoute. Esto hace que los enrutadores de Microsoft Edge prefieran las rutas VPN antes que las rutas locales.

¿ExpressRoute admite el Enrutamiento multidireccional de igual costo (ECMP) en Virtual WAN?

Cuando 1 o más circuitos de ExpressRoute están conectados a un centro de Virtual WAN, ECMP permite que el tráfico de las redes virtuales radiales a un entorno local a través de ExpressRoute se distribuya a través de 2 circuitos de ExpressRoute (correspondientes a hasta 4 vínculos de ExpressRoute) que anuncian las mismas rutas locales. ECMP no está habilitado actualmente de forma predeterminada para centros de Virtual WAN. Para habilitar ECMP para su entorno, puede crear un mapa de rutas para el centro virtual. Al crear un mapa de rutas, el centro virtual se actualiza automáticamente a la versión de software más reciente que admite ECMP, independientemente de si este mapa de rutas se aplica en cualquier conexión. Como resultado, solo tiene que seguir los pasos del 1 al 7 en Configuración de mapas de rutas. Si no tiene previsto usar el mapa de rutas, puede eliminar el mapa de rutas una vez completado el paso 7, ya que los centros con un mapa de rutas incurrirán en costos adicionales. Se recomienda crear un mapa de rutas en el entorno de prueba y validar el enrutamiento y la conectividad antes de crear un mapa de rutas en el entorno de producción.

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). Para obtener más información, consulte Configuración de la preferencia de enrutamiento del centro de conectividad virtual.

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 estos conmutadores de puerta de enlace de ExpressRoute en el panel "Editar centro virtual" y en el panel "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 a los del enrutador del concentrador
• y los enrutadores de Microsoft Enterprise Edge/MSEE, 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 (VNet 2 y VNet 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 Azure Route Server en la red virtual independiente 4 y el Route Server tiene habilitada la conexión de sitio a sitio, la conectividad se bloqueará entre la red virtual 1 y la red virtual independiente 4.

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.).

Cuando actualizo una conexión de ExpressRoute, ¿esto afectará a la conectividad de mis otras conexiones de ExpressRoute?

Al realizar una operación de creación, actualización o eliminación en una conexión de ExpressRoute, las demás conexiones de ExpressRoute aparecerán en un estado de "actualización" en el portal. Sin embargo, la conectividad a través de estas conexiones expressRoute no se verá afectada.

¿Por qué la conectividad no funciona cuando anuncio rutas con un ASN de 0 en la ruta de acceso del sistema autónomo (AS)?

El centro de conectividad de Virtual WAN quita las rutas con un ASN de 0 en la ruta de acceso del sistema autónomo (AS). Para asegurarse de que estas rutas se anuncian correctamente en Azure, la ruta de acceso del sistema autónomo (AS) no debe incluir 0.

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

Yes. 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 espacio de direcciones recomendado para un centro de Virtual WAN es /23 o superior. Es importante tener en cuenta que el espacio de direcciones del centro no se puede modificar después de crear el centro. Para cambiar el espacio de direcciones del hub, debe reimplementar el hub virtual, lo que puede provocar tiempo de inactividad.

El centro de Conectividad de Virtual WAN asigna automáticamente subredes del espacio de direcciones especificado a varios servicios de Azure, entre los que se incluyen:

• Enrutador del centro de conectividad virtual
• ExpressRoute
• VPN de sitio a sitio
• VPN de punto a sitio
• Azure Firewall

En escenarios en los que las aplicaciones virtuales de red (NVA) se implementan dentro del centro virtual, se asigna una subred adicional para las instancias de NVA. Normalmente, se asigna una subred /28 para un número reducido de NVA. Pero si se aprovisionan varias NVA, se podría asignar una subred /27.

Para dar cabida a las necesidades futuras de escalabilidad y arquitectura, mientras que el espacio de direcciones mínimo para un centro de Virtual WAN es /24, se recomienda especificar un espacio de direcciones /23 o mayor durante la creación del centro.

¿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 conecta una red virtual radial con un intervalo de direcciones IPv6 al centro de conectividad de Virtual WAN, solo funcionará la conectividad IPv4 con esta red virtual radial. No es compatible la conectividad IPv6 con esta red virtual spoke.

Si anuncia prefijos IPv6 desde el entorno local, esto interrumpe la conectividad IPv4 para los recursos de Azure.

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 Límites de suscripción y servicio.

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

Consulte WAN virtuales básicas y estándar. Para obtener los precios, consulte la página 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?

Yes. Para obtener una lista de las soluciones del proveedor de servicios administrados (MSP) habilitadas a través de Azure Marketplace, consulte Ofertas de Azure Marketplace por asociados de MSP de redes de Azure.

¿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 ser implementado por una red virtual de concentrador autoadministrada por el cliente, mientras que Azure Virtual WAN ofrece un servicio de concentrador completamente mallado y sin intervención, al cual los clientes conectan sus diversos puntos terminales tipo spoke (redes virtuales de Azure, sucursales locales mediante VPN sitio a sitio o SD-WAN, usuarios remotos mediante VPN punto a sitio/usuario remoto y conexiones privadas con ExpressRoute). Además, permite el emparejamiento BGP para NVAs implementadas en redes virtuales tipo spoke, junto con otras funcionalidades de Virtual WAN como conectividad de tránsito entre redes virtuales, conectividad de tránsito entre VPN y ExpressRoute, enrutamiento personalizado/avanzado, asociación y propagación de rutas personalizadas, intención/directivas de enrutamiento para una seguridad entre regiones sin complicaciones, concentrador seguro, firewall de Azure, entre otras. Para más detalles sobre el emparejamiento BGP de la WAN virtual, consulte Cómo emparejar BGP con un concentrador 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 configurarlo, consulte Despliegue de un proveedor de socios de seguridad.

¿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 conservarán las comunidades de BGP generadas por pares de BGP (en una red virtual adjunta) en Virtual WAN?

Sí, las comunidades de BGP generadas por pares de BGP se conservarán en Virtual WAN. Las comunidades se conservan en el mismo centro y en las conexiones entre centros. Esto también se aplica a escenarios de Virtual WAN mediante directivas de intención de enrutamiento.

¿Qué números de ASN se admiten para redes locales adjuntas de forma remota que ejecuten el Protocolo de puerta de enlace de borde?

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 los ASN en Virtual WAN?

No. Virtual WAN no admite cambios de ASN para centros virtuales ni puertas de enlace.

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

Es importante tener en cuenta los siguientes puntos:

• Durante las operaciones de mantenimiento, las unidades de escalado de 2 a 10 mantienen su rendimiento agregado. Sin embargo, la unidad de escalado 1 puede experimentar pequeñas variaciones en el rendimiento durante estas operaciones.
• Independientemente del número de unidades de escalado implementadas, si un único flujo TCP supera los 1,5 Gbps, el rendimiento del tráfico puede degradarse.

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é el enrutador del centro virtual requiere una dirección IP pública con puertos abiertos?

Estos puntos de conexión públicos son necesarios para que la plataforma de administración y SDN subyacente de Azure se comuniquen con el enrutador del centro virtual. Dado que el enrutador del centro virtual se considera parte de la red privada del cliente, la plataforma subyacente de Azure no puede acceder directamente al enrutador del centro ni administrarlo a través de sus puntos de conexión privados debido a los requisitos de cumplimiento. La conectividad a los puntos de conexión públicos del enrutador del centro se autentica a través de certificados y Azure realiza auditorías de seguridad rutinarias de estos puntos de conexión públicos. Como resultado, no constituyen una exposición de seguridad del centro virtual.

¿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. Tenga en cuenta lo siguiente:

• No es necesario hacer clic en el botón "Sincronizar" debajo de la hoja Emparejamiento. Una vez que se cambia el espacio de direcciones de la red virtual, el emparejamiento de red virtual se sincroniza automáticamente con la red virtual del centro virtual.
• Asegúrese de que el espacio de direcciones actualizado no se superpone con el espacio de direcciones de las redes virtuales de radio existentes en la red virtual WAN.

Puede encontrar más información sobre cómo cambiar el espacio de direcciones de la red virtual en Crear, cambiar o eliminar una red virtual.

¿Cuál es el número máximo de direcciones de red virtual de radio admitidas para centros configurados con intención de enrutamiento?

El número máximo de espacios de direcciones en todas las redes virtuales conectadas directamente a un único centro de Virtual WAN es 600. Este límite se aplica individualmente a cada centro de Virtual WAN en una implementación de Virtual WAN. Los espacios de direcciones de red virtual conectados a centros remotos (otros centros de conectividad de Virtual WAN en la misma instancia de Virtual WAN) no se cuentan hacia este límite.

Para obtener más información sobre el límite y scripts de ejemplo para determinar el número de espacios de direcciones entre redes virtuales conectadas a un centro de Virtual WAN, consulte Enrutamiento de límites de espacio de direcciones de red virtual.

¿Puedo usar Azure Bastion con Virtual WAN?

Sí, pero hay limitaciones. Consulte las preguntas más frecuentes sobre Azure Bastion para más información.

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, puertas de enlace de VPN de punto a sitio y puertas de enlace de ExpressRoute.

Esta característica también se admite para Azure Firewalls en centros seguros de Virtual WAN.

¿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 su 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?

Actualmente, debe configurar una ventana de cinco horas como mínimo en la zona horaria preferida.

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

Actualmente, 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?

Yes.

¿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 uno de mis recursos en una fecha futura. ¿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 incluidos en la programación de mantenimiento, el mantenimiento continúa como de costumbre en el recurso.

¿Hay límites en el número de rutas que puedo anunciar?

Sí, hay límites. ExpressRoute admite hasta 4000 prefijos para el emparejamiento privado y 200 prefijos para el emparejamiento de Microsoft. Con ExpressRoute Premium, puede aumentar el límite a 10 000 rutas para el emparejamiento privado. El número máximo de rutas anunciadas desde el emparejamiento privado de Azure a través de una puerta de enlace de ExpressRoute a través de un circuito ExpressRoute es de 1000, que es la misma para los circuitos ExpressRoute estándar y premium. Para más información, puede revisar los límites de ruta de los circuitos ExpressRoute en la página Límites de rutas y límites de suscripción de Azure . Tenga en cuenta que los anuncios de rutas IPv6 no se admiten actualmente con Virtual WAN.

¿Existen restricciones en los intervalos IP que puedo anunciar durante la sesión BGP?

Sí, hay restricciones. Los prefijos privados (RFC1918) no se aceptan para la sesión BGP de emparejamiento de Microsoft. Sin embargo, cualquier tamaño de prefijo hasta un prefijo /32 se acepta en el emparejamiento privado y de Microsoft.

¿Qué ocurre si se supera el límite de rutas de BGP?

Si se supera el límite de rutas BGP, las sesiones de BGP se desconectarán. Las sesiones se restauran una vez que el número de prefijos se reduce por debajo del límite. Para obtener más información, consulte los límites de rutas de circuitos de ExpressRoute en la página de límites y cuotas de suscripción de Azure.

¿Puedo supervisar el número de rutas anunciadas o recibidas a través de un circuito ExpressRoute?

Sí, puede hacerlo. Para conocer los procedimientos recomendados y la configuración de la supervisión de alertas basadas en métricas, consulte los procedimientos recomendados de supervisión de Azure.

¿Cuál es la recomendación para reducir el número de prefijos IP?

Se recomienda agregar los prefijos antes de anunciarlos a través de ExpressRoute o la puerta de enlace VPN. Además, puede usar Route-Maps para resumir las rutas anunciadas desde o hacia Virtual WAN.

¿Puedo usar tablas de rutas definidas por el usuario en redes virtuales radiales conectadas al centro de Virtual WAN?

Yes. Las rutas que el centro de conectividad de Virtual WAN anuncia a los recursos implementados en redes virtuales radiales conectadas son rutas de tipo Protocolo de puerta de enlace de borde (BGP). Si una tabla de rutas definida por el usuario está asociada a una subred conectada a Virtual WAN, la configuración "Propagar rutas de puerta de enlace" debe establecerse en "Sí" para que Virtual WAN anuncie los recursos implementados en esa subred. La plataforma de red definida por software subyacente de Azure usa el siguiente algoritmo para seleccionar rutas en función del algoritmo de selección de rutas de Azure.

¿Por qué tengo problemas de conectividad después de volver a anunciar las rutas de Azure en Azure?

Si tiene previsto quitar las comunidades de Azure BGP de las rutas de red virtual y UDR, no anuncie estas rutas de nuevo en Azure, ya que esto provoca problemas de enrutamiento. No se recomienda volver a anunciar rutas de Azure en el entorno de Azure.

Pasos siguientes

Para más información sobre Virtual WAN, consulte Acerca de Virtual WAN.