Planeamiento e implementación de las rutas definidas por el usuario

Puede crear rutas personalizadas o definidas por el usuario (estáticas) en Azure para invalidar las rutas predeterminadas del sistema de Azure o para agregar más rutas a la tabla de rutas de una subred. En Azure, creará una tabla de rutas y, a continuación, asociará la tabla de rutas a cero o más subredes de red virtual. Cada subred puede tener cero o una tabla de rutas asociada. Para obtener información sobre el número máximo de rutas que puede agregar a una tabla de rutas y el número máximo de tablas de rutas definidas por el usuario que puede crear por suscripción de Azure, consulte límites de Azure. Al crear una tabla de rutas y asociarla a una subred, las rutas de la tabla se combinan con las rutas predeterminadas de la subred. Si hay asignaciones de rutas en conflicto, las rutas definidas por el usuario invalidan las rutas predeterminadas.

Puede especificar los siguientes tipos de próximo salto al crear una ruta definida por el usuario:

• Aplicación virtual: una aplicación virtual es una máquina virtual que normalmente ejecuta una aplicación de red, como un firewall. Para obtener información sobre varias aplicaciones virtuales de red preconfiguradas que puede implementar en una red virtual, consulte el Azure Marketplace. Al crear una ruta con el tipo de salto de aplicación virtual, también se especifica una dirección IP del próximo salto. La dirección IP puede ser:

  • Dirección IP privada de una interfaz de red conectada a una máquina virtual. Cualquier interfaz de red conectada a una máquina virtual que reenvía el tráfico de red a una dirección distinta de la suya propia debe tener habilitada la opción De reenvío IP de Azure Enable para ella. La configuración deshabilita la comprobación de Azure del origen y el destino de una interfaz de red. Obtenga más información acerca de cómo habilitar el reenvío IP en una interfaz de red. Aunque habilitar el reenvío IP es una configuración de Azure, es posible que también tenga que habilitar el reenvío IP dentro del sistema operativo de la máquina virtual para que el dispositivo reenvíe el tráfico entre direcciones IP privadas asignadas a interfaces de red de Azure. Si el dispositivo necesita enrutar el tráfico a una dirección IP pública, debe proxy el tráfico o realizar la traducción de direcciones de red (NAT) desde la dirección IP privada del origen a su propia dirección IP privada. A continuación, Azure realiza NAT en una dirección IP pública antes de enviar el tráfico a Internet. Para determinar la configuración necesaria dentro de la máquina virtual, consulte la documentación de la aplicación de red o del sistema operativo. Para comprender las conexiones salientes en Azure, consulte Descripción de las conexiones salientes.
    
  • Dirección IP privada de un equilibrador de carga interno de Azure. A menudo, un equilibrador de carga se usa como parte de una estrategia de alta disponibilidad para las aplicaciones virtuales de red.

Puede definir una ruta con 0.0.0.0/0 como prefijo de dirección y un tipo de aplicación virtual como próximo salto. Esta configuración permite al dispositivo inspeccionar el tráfico y determinar si reenviar o quitar el tráfico. Si tiene intención de crear una definida por el usuario que contenga el prefijo de dirección 0.0.0.0/0, consulte antes el apartado prefijo de dirección 0.0.0.0/0.

• Puerta de enlace de red virtual: especifique cuándo desea que el tráfico destinado a prefijos de dirección específicos se enrute a una puerta de enlace de red virtual. La puerta de enlace de red virtual debe crearse con el tipo VPN. No se puede especificar una puerta de enlace de red virtual creada como tipo ExpressRoute en una ruta definida por el usuario porque con ExpressRoute, debe usar BGP para rutas personalizadas. Tampoco puede especificar puertas de enlace de red virtual si tiene conexiones coexistentes de VPN y ExpressRoute. Puede definir una ruta que dirija el tráfico destinado al prefijo de dirección 0.0.0.0/0 a una puerta de enlace de red virtual basada en rutas. En un entorno local, puede tener un dispositivo que compruebe el tráfico y determine si se reenvía o se elimina. Si piensa crear una ruta definida por el usuario para el prefijo de dirección 0.0.0.0/0, lea primero el prefijo de dirección 0.0.0.0/0. En lugar de configurar una ruta definida por el usuario para el prefijo de dirección 0.0.0.0/0, puede anunciar una ruta con el prefijo 0.0.0.0/0 a través de BGP, si ha habilitado BGP para una puerta de enlace de red virtual VPN.
• Ninguna: se especifica cuando se desea colocar tráfico en un prefijo de dirección, en lugar de reenviar el tráfico a un destino. Si no ha configurado completamente una funcionalidad, Azure puede enumerar No para algunas de las rutas de opcional del sistema. Por ejemplo, si ve No en Dirección IP del próximo salto con un Tipo de próximo salto de Puerta de enlace de red virtual o Aplicación virtual, puede deberse a que el dispositivo no funciona o no está completamente configurado. Azure crea rutas predeterminadas del sistema para prefijos de direcciones reservadas con None como tipo de próximo salto.
  
• Red virtual: especifique la opción Red virtual cuando desee invalidar el enrutamiento predeterminado dentro de una red virtual.
  
• Internet: especifique la opción Internet cuando desee enrutar explícitamente el tráfico destinado a un prefijo de dirección a Internet, o si desea que el tráfico destinado a los servicios de Azure con direcciones IP públicas se mantenga dentro de la red troncal de Azure. Consulte el ejemplo de enrutamiento , para ver un ejemplo de por qué podría crear una ruta con el tipo de salto de red virtual.
  

En las rutas definidas por el usuario, no se puede especificar el emparejamiento de red virtual o VirtualNetworkServiceEndpoint como tipo de próximo salto. Las rutas con los tipos de próximo salto Emparejamiento de red virtual o VirtualNetworkServiceEndpoint solo las crea Azure, al configurar un emparejamiento de red virtual o un punto de conexión de servicio.

Etiquetas de servicio para rutas definidas por el usuario

Ahora puede especificar una etiqueta de servicio como prefijo de dirección para una ruta definida por el usuario en lugar de un intervalo IP explícito. Una etiqueta de servicio representa un grupo de prefijos de direcciones IP de un servicio de Azure determinado. Microsoft administra los prefijos de direcciones que la etiqueta de servicio incluye y actualiza automáticamente dicha etiqueta a medida que las direcciones cambian. Por lo tanto, se minimiza la complejidad de las actualizaciones frecuentes de las rutas definidas por el usuario y se reduce el número de rutas que necesita crear. Actualmente, puede crear 25 o menos rutas con etiquetas de servicio en cada tabla de rutas. Con esta versión, también se admite el uso de etiquetas de servicio en escenarios de enrutamiento para contenedores.

Coincidencia exacta

El sistema da preferencia a la ruta con el prefijo explícito cuando hay una coincidencia exacta de prefijo entre una ruta con un prefijo IP explícito y una ruta con una etiqueta de servicio. Cuando varias rutas con etiquetas de servicio tienen prefijos IP coincidentes, las rutas se evalúan en el orden siguiente:

1. Etiquetas regionales (por ejemplo, Storage.EastUS, AppService.AustraliaCentral)
   
2. Etiquetas de nivel superior (por ejemplo, Storage, AppService)
   
3. Etiquetas regionales de AzureCloud (por ejemplo, AzureCloud.canadacentral, AzureCloud.eastasia)
   
4. La etiqueta AzureCloud
   

Para usar esta característica, especifique un nombre de etiqueta de servicio para el parámetro de prefijo de dirección en los comandos de la tabla de rutas. Por ejemplo, en PowerShell puede crear una nueva ruta para dirigir el tráfico enviado a un prefijo IP de Azure Storage a una aplicación virtual mediante:

$param = @{ Name = 'StorageRoute' AddressPrefix = 'Storage' NextHopType = 'VirtualAppliance' NextHopIpAddress = '10.0.100.4' } New-AzRouteConfig @param

El mismo comando para la CLI de Azure es:

az network route-table route create \ --resource-group MyResourceGroup \ --route-table-name MyRouteTable \ --name StorageRoute \ --address-prefix Storage \ --next-hop-type VirtualAppliance \ --next-hop-ip-address 10.0.100.4

Tipos de próximo salto en las herramientas de Azure

El nombre que se muestra y al que hace referencia en los tipos de próximo salto es diferente entre Azure Portal y las herramientas de línea de comandos y los modelos de implementación clásico y mediante Resource Manager. En la siguiente tabla se enumeran los nombres que se usan para hacer referencia a cada tipo de próximo salto con las diferentes herramientas y los modelos de implementación.

Expandir tabla

Tipo del próximo salto	CLI de Azure y PowerShell (Resource Manager)	CLI clásica de Azure y PowerShell (clásico)
Puerta de enlace de red virtual	VirtualNetworkGateway	Puerta de enlace VPN
Red de área virtual	VNetLocal	VNETLocal (no disponible en la CLI clásica en el modo de modelo de implementación clásica)
Internet	Internet	Internet (no disponible en la CLI clásica en el modo de modelo de implementación clásica)
Aplicación virtual	VirtualAppliance	VirtualAppliance
Ninguno	Ninguno	Null (no disponible en la CLI clásica en el modo de modelo de implementación clásica)
Emparejamiento de redes virtuales de Azure	Emparejamiento de redes virtuales de Azure	No aplicable
Puntos de conexión de servicio de red virtual	VirtualNetworkServiceEndpoint	No aplicable

Protocolo de puerta de enlace de frontera

Una puerta de enlace de red local puede intercambiar rutas con una puerta de enlace de red virtual de Azure mediante BGP. El uso del BGP con una puerta de enlace de red virtual de Azure depende del tipo seleccionado al crear la puerta de enlace:

• ExpressRoute: debe usar BGP para anunciar rutas locales para el enrutador perimetral de Microsoft Edge. No puede crear UDR para forzar el tráfico a la puerta de enlace de red virtual de ExpressRoute si implementa una puerta de enlace de red virtual implementada como el tipo ExpressRoute. Puede usar UDR para forzar el tráfico desde la ruta rápida a, por ejemplo, una aplicación virtual de red.
• VPN: opcionalmente, puede usar BGP. Para obtener más información, consulte BGP con conexiones VPN de sitio a sitio.

Al intercambiar rutas con Azure mediante BGP, se agrega una ruta independiente a la tabla de rutas de todas las subredes de una red virtual para cada prefijo anunciado. La ruta se agrega con Puerta de enlace de red virtual como origen y tipo de próximo salto.

Puede deshabilitar la propagación de rutas de ExpressRoute y Azure VPN Gateway en una subred mediante una propiedad en una tabla de rutas. Al deshabilitar la propagación de rutas, el sistema no agrega rutas a la tabla de rutas de todas las subredes que tengan la propagación de rutas de puerta de enlace de red virtual deshabilitada. Este proceso se aplica tanto a rutas estáticas como a rutas de BGP. La conectividad con conexiones VPN se logra mediante rutas personalizadas con un tipo de próximo salto de puerta de enlace de red virtual. Para más información, consulte Deshabilitación de la propagación de rutas de puerta de enlace de red virtual.

Selección de rutas por parte de Azure

Cuando se envía tráfico saliente desde una subred, Azure selecciona una ruta en función de la dirección IP de destino y se usa el algoritmo de coincidencia de prefijo más largo. Por ejemplo, una tabla de rutas tiene dos rutas. Una ruta especifica el prefijo de dirección 10.0.0.0/24, y la otra ruta especifica el prefijo de dirección 10.0.0.0/16.

Azure dirige el tráfico destinado a 10.0.0.5 al tipo de próximo salto especificado en la ruta con el prefijo de dirección 10.0.0.0/24. Este proceso se produce porque 10.0.0.0/24 es un prefijo más largo que 10.0.0.0/16, aunque 10.0.0.5 se encuentre dentro de ambos prefijos de dirección.

Azure dirige el tráfico destinado a 10.0.1.5 al tipo de próximo salto especificado en la ruta con el prefijo de dirección 10.0.0.0/16. Este proceso se produce porque 10.0.1.5 no se incluye en el prefijo de dirección 10.0.0.0/24, lo que hace que la ruta con el prefijo de dirección 10.0.0.0/16 sea el prefijo coincidente más largo.

Si varias rutas contienen el mismo prefijo de dirección, Azure selecciona el tipo de ruta, en función de la siguiente prioridad:

1. Ruta definida por el usuario
2. Ruta BGP
3. Ruta del sistema

Por ejemplo, una tabla de rutas contiene las rutas siguientes:

Expandir tabla

Fuente	Prefijos de dirección	Tipo del próximo salto
Predeterminado	0.0.0.0/0	Internet
Usuario	0.0.0.0/0	Puerta de enlace de red virtual

Cuando el tráfico está destinado a una dirección IP fuera de los prefijos de dirección de cualquier otra ruta de la tabla de rutas, Azure selecciona la ruta con el origen de usuario. Azure elige esta opción porque las UDR son una prioridad más alta que las rutas predeterminadas del sistema.

Para obtener una tabla de enrutamiento completa con explicaciones de las rutas de la tabla, consulte ejemplo de enrutamiento.

Prefijo de dirección 0.0.0.0/0

Una ruta con el prefijo de dirección 0.0.0.0/0 proporciona instrucciones a Azure. Azure usa estas instrucciones para enrutar el tráfico destinado a una dirección IP que no está dentro del prefijo de dirección de ninguna otra ruta en una tabla de rutas de una subred. Cuando se crea una subred, Azure crea un ruta predeterminada para el prefijo de dirección 0.0.0.0/0, con el tipo de próximo salto Internet. Si no reemplaza esta ruta, Azure enruta a Internet todo el tráfico destinado a direcciones IP no incluidas en el prefijo de dirección de otra ruta.

La excepción es que el tráfico dirigido a las direcciones IP públicas de los servicios de Azure permanece en la red troncal de Azure y no se enruta a Internet. Al invalidar esta ruta con una ruta personalizada, se dirige el tráfico destinado a direcciones que no están dentro de los prefijos de dirección de cualquier otra ruta de la tabla de rutas. El destino depende de si especifica una aplicación virtual de red o una puerta de enlace de red virtual en la ruta personalizada.

Al invalidar el prefijo de dirección 0.0.0.0/0, el tráfico saliente de la subred fluye a través de la puerta de enlace de red virtual o la aplicación virtual. Los siguientes cambios también se producen con el enrutamiento predeterminado de Azure:

• Azure envía todo el tráfico al tipo de próximo salto especificado en la ruta, lo que incluye el tráfico destinado a las direcciones IP públicas de los servicios de Azure.

  Cuando el tipo de próximo salto de la ruta con el prefijo de dirección 0.0.0.0/0 es Internet, el tráfico de la subred destinada a las direcciones IP públicas de los servicios de Azure nunca deja la red troncal de Azure, independientemente de la región de Azure en la que exista la red virtual o el recurso de servicio de Azure.

  Al crear una ruta UDR o BGP con una puerta de enlace de red virtual o un tipo de próximo salto de aplicación virtual, todo el tráfico se envía al tipo de próximo salto especificado en la ruta. Esto incluye el tráfico enviado a direcciones IP públicas de los servicios de Azure para los que no ha habilitado puntos de conexión de servicio.

  Al habilitar un punto de conexión de servicio para un servicio, Azure crea una ruta con prefijos de dirección para el servicio. El tráfico al servicio no enruta al tipo de próximo salto en una ruta con el prefijo de dirección 0.0.0.0/0. Los prefijos de dirección para el servicio son más largos que 0.0.0.0/0.

• Ya no puede acceder directamente a los recursos de la subred desde Internet. Puede acceder a los recursos de la subred desde Internet indirectamente. El dispositivo especificado por el tipo de próximo salto para una ruta con el prefijo de dirección 0.0.0.0/0 debe procesar el tráfico entrante. Una vez que el tráfico atraviesa el dispositivo, el tráfico llega al recurso de la red virtual. Si la ruta contiene los siguientes valores del tipo de salto próximo:

  • Aplicación virtual: el dispositivo debe:

    • Ser accesible desde Internet.
    • Tener una dirección IP pública asignada.
    • No tener una regla del grupo de seguridad de red asociada a él que impide la comunicación con el dispositivo.
    • No denegar la comunicación.
    • Poder traducir y reenviar direcciones de red, o desviar el tráfico a través de un servidor proxy al recurso de destino de la subred y devolver el tráfico a Internet.

  • Puerta de enlace de red virtual: si la puerta de enlace es una puerta de enlace de red virtual de ExpressRoute, un dispositivo local conectado a Internet puede realizar traducción de dirección de red y reenviar, o actuar como proxy para el tráfico hacia el recurso de destino en la subred, a través del emparejamiento privado de ExpressRoute.

Si la red virtual está conectada a una instancia de Azure VPN Gateway, no asocie una tabla de rutas a la subred de puerta de enlace que incluya una ruta con un destino 0.0.0.0/0. Si lo hace, puede que la puerta de enlace no funcione correctamente. Para más información, consulte ¿Por qué se abren determinados puertos en mi puerta de enlace de VPN?

Para obtener detalles de implementación cuando se utilizan pasarelas de red virtuales entre Internet y Azure, consulte DMZ entre Azure y su centro de datos local.

Ejemplo de enrutamiento

Para ilustrar los conceptos de este artículo, en las siguientes secciones se describen:

• Un escenario con requisitos.
• Las rutas personalizadas necesarias para cumplir los requisitos.
• Las tabla de rutas que existe para una subred que incluye las rutas predeterminadas y personalizadas necesarias para cumplir los requisitos.

Requisitos

1. Implementar dos redes virtuales en la misma región de Azure y habilitar los recursos necesarios para la comunicación entre las redes virtuales.

2. Habilitar una red local para comunicarse de forma segura con ambas redes virtuales mediante un túnel VPN a través de Internet. Alternativamente, puede usar una conexión ExpressRoute, pero en este ejemplo se usa una conexión VPN.

3. Para una subred de una red virtual:

   • Enrute todo el tráfico saliente desde la subred a través de una aplicación virtual de red para la inspección y el registro. Excluya el tráfico a Azure Storage y dentro de la subred de este enrutamiento.
   • No inspeccione el tráfico entre direcciones IP privadas dentro de la subred. Permitir que el tráfico fluya directamente entre todos los recursos.
   • Eliminar todo el tráfico saliente destinado a la otra red virtual.
   • Habilitar el tráfico saliente a Azure Storage para que fluya directamente al almacenamiento, sin hacerle pasar por una aplicación virtual de red.

4. Permitir todo el tráfico entre las restantes subredes y las redes virtuales.

Implementación

En el diagrama siguiente se muestra una implementación a través del modelo de implementación de Resource Manager que cumple los requisitos anteriores.

Tablas de rutas

Estas son las tablas de rutas del ejemplo de enrutamiento anterior.

Subnet1

La tabla de rutas de Subnet1 del diagrama anterior contiene las rutas siguientes:

Expandir tabla

ID	Fuente	Estado	Prefijos de dirección	Tipo del próximo salto	Dirección IP del próximo salto	Nombre udR
1	Predeterminado	No válido	10.0.0.0/16	Red de área virtual
2	Usuario	Activo	10.0.0.0/16	Aplicación virtual	10.0.100.4	Within-VNet1
3	Usuario	Activo	10.0.0.0/24	Red de área virtual		Within-Subnet1
4	Predeterminado	No válido	10.1.0.0/16	Emparejamiento de redes virtuales de Azure
5	Predeterminado	No válido	10.2.0.0/16	Emparejamiento de redes virtuales de Azure
6	Usuario	Activo	10.1.0.0/16	Ninguno		ToVNet2-1-Drop
7	Usuario	Activo	10.2.0.0/16	Ninguno		ToVNet2-2-Drop
8	Predeterminado	No válido	10.10.0.0/16	Puerta de enlace de red virtual	[X.X.X.X]
9	Usuario	Activo	10.10.0.0/16	Aplicación virtual	10.0.100.4	To-On-Prem
10	Predeterminado	Activo	[X.X.X.X]	VirtualNetworkServiceEndpoint
11	Predeterminado	No válido	0.0.0.0/0	Internet
12	Usuario	Activo	0.0.0.0/0	Aplicación virtual	10.0.100.4	Default-NVA

Esta es una explicación de cada identificador de ruta:

• ID1: Azure agregó automáticamente esta ruta para todas las subredes de Virtual-network-1 porque 10.0.0.0/16 es el único intervalo de direcciones definido en el espacio de direcciones de la red virtual. Si no crea la UDR en la ruta ID2, el tráfico enviado a cualquier dirección entre 10.0.0.1 y 10.0.255.254 se enruta dentro de la red virtual. Este proceso se produce porque el prefijo es mayor que 0.0.0.0/0 y no se encuentra dentro de los prefijos de dirección de ninguna otra ruta.

  Azure cambió automáticamente el estado de Activo a No válido, cuando se agregó ID2, una UDR. Tiene el mismo prefijo que la ruta predeterminada y las UDR invalidan las rutas predeterminadas. El estado de esta ruta sigue activo para Subnet2 porque la tabla de rutas en la que está la UDR, ID2, no está asociada a Subnet2.

• ID2: Azure agregó esta ruta cuando un UDR para el prefijo de dirección 10.0.0.0/16 estaba asociado a la subred Subnet1 de la red virtual Virtual-network-1 . La UDR especifica 10.0.100.4 como dirección IP de la aplicación virtual, porque la dirección es la dirección IP privada asignada a la máquina virtual de la aplicación virtual. La tabla de rutas en la que existe esta ruta no está asociada a Subnet2, por lo que la ruta no aparece en la tabla de rutas para Subnet2.

  Esta ruta reemplaza la ruta predeterminada del prefijo 10.0.0.0/16 (ID1), que enruta automáticamente el tráfico dirigido a 10.0.0.1 y 10.0.255.254 dentro de la red virtual a través del tipo de próximo salto de la red virtual. Esta ruta existe para cumplir el requisito 3, que es forzar todo el tráfico saliente a través de una aplicación virtual.

• ID3: Azure agregó esta ruta cuando un UDR para el prefijo de dirección 10.0.0.0/24 estaba asociado a la subred Subnet1 . El tráfico destinado a direcciones entre 10.0.0.1 y 10.0.0.254 permanece dentro de la subred. El tráfico no se enruta a la aplicación virtual especificada en la regla anterior (ID2), porque tiene un prefijo más largo que la ruta ID2.

  La tabla de rutas no estaba asociada a Subnet2, por lo que la ruta no aparece en la tabla de rutas de Subnet2. Esta ruta reemplaza eficazmente la ruta ID2 para el tráfico de Subnet1. Esta ruta existe para cumplir el requisito 3.

• ID4: Azure agregó automáticamente las rutas en identificadores 4 y 5 para todas las subredes de Virtual-network-1 cuando la red virtual se emparejaba con Virtual-network-2.Virtual-network-2 tiene dos intervalos de direcciones en su espacio de direcciones, 10.1.0.0/16 y 10.2.0.0/16, por lo que Azure agregó una ruta para cada intervalo. Si no crea UDR en los ID de ruta 6 y 7, el tráfico enviado a cualquier dirección entre 10.1.0.1-10.1.255.254 y 10.2.0.1-10.2.255.254 se enruta a la red virtual del mismo nivel. Este proceso se produce porque el prefijo es mayor que 0.0.0.0/0 y no se encuentra dentro de los prefijos de dirección de ninguna otra ruta.

  Al agregar las rutas en los identificadores 6 y 7, Azure cambió automáticamente el estado de Activo a No válido. Este proceso se produce porque tienen los mismos prefijos que las rutas en los identificadores 4 y 5, y las UDR invalidan las rutas predeterminadas. El estado de las rutas de los identificadores 4 y 5 sigue activo para Subnet2 porque la tabla de rutas en la que las UDR de los identificadores 6 y 7 no están asociadas a Subnet2. Se ha creado un emparejamiento de red virtual para cumplir el requisito 1.

• ID5: misma explicación que ID4.

• ID6: Azure agregó esta ruta y la ruta en ID7 cuando las UDR para los prefijos de dirección 10.1.0.0/16 y 10.2.0.0/16 estaban asociados a la subred Subnet1 . Azure anula el tráfico destinado a direcciones entre 10.1.0.1-10.1.255.254 y 10.2.0.1-10.2.255.254, en lugar de enrutarlas a la red virtual emparejada, porque las UDR reemplazan a las rutas predeterminadas. Las rutas no están asociadas a Subnet2, por lo que no aparecen en la tabla de rutas de Subnet2. Las rutas reemplazan las rutas ID4 y ID5 en el caso del tráfico que sale del Subnet1. Las rutas ID6 y ID7 existen para satisfacer el requisito 3 de eliminación del tráfico destinado a la otra red virtual.

• ID7: misma explicación que ID6.

• ID8: Azure agregó automáticamente esta ruta para todas las subredes de Virtual-network-1 cuando se creó una puerta de enlace de red virtual de tipo VPN dentro de la red virtual. Azure agregó la dirección IP pública de la puerta de enlace de red virtual a la raba de rutas. El tráfico enviado a cualquier dirección entre 10.10.0.1 y 10.10.255.254 se enruta a la puerta de enlace de red virtual. El prefijo es más largo que 0.0.0.0/0 y no está dentro de los prefijos de dirección de las restantes rutas. Se ha creado una puerta de enlace de red virtual para cumplir el requisito 2.

• ID9: Azure agregó esta ruta cuando se agregó un UDR para el prefijo de dirección 10.10.0.0/16 a la tabla de rutas asociada a Subnet1. Esta ruta reemplaza ID8. La ruta envía todo el tráfico destinado a la red local a una aplicación virtual de red para su inspección, en lugar de enrutar el tráfico directamente en el entorno local. Esta ruta se ha creado para cumplir el requisito 3.

• ID10: Azure agregó automáticamente esta ruta a la subred cuando se ha habilitado un punto de conexión de servicio a un servicio de Azure para la subred. Azure enruta el tráfico de la subred a una dirección IP pública del servicio, a través de la red de la infraestructura de Azure. El prefijo es más largo que 0.0.0.0/0 y no está dentro de los prefijos de dirección de las restantes rutas. Se ha creado un punto de conexión de servicio para cumplir el requisito 3, con el fin de habilitar que el tráfico destinado a Azure Storage que fluya directamente a dicho servicio.

• ID11: Azure agregó automáticamente esta ruta a la tabla de rutas de todas las subredes en Virtual-network-1 y Virtual-network-2. El prefijo de dirección 0.0.0.0/0 es el prefijo más corto. Todo el tráfico enviado a direcciones de un prefijo de dirección más largo se enrutan en función de otras rutas.

  De forma predeterminada, Azure enruta todo el tráfico destinado a aquellas direcciones que no sean las especificadas en una de las otras rutas a Internet. Azure cambió automáticamente el estado de Activo a No válido para la subred Subnet1 cuando un UDR para el prefijo de dirección 0.0.0.0/0 (ID12) estaba asociado a la subred. El estado de esta ruta sigue activo para todas las demás subredes dentro de ambas redes virtuales porque la ruta no está asociada a ninguna otra subred dentro de ninguna otra red virtual.

• ID12: Azure agregó esta ruta cuando un UDR para el prefijo de dirección 0.0.0.0/0 estaba asociado a la subred Subnet1 . La UDR especifica 10.0.100.4 como dirección IP de la aplicación virtual. Esta ruta no está asociada a Subnet2, por lo que no aparece en la tabla de rutas de Subnet2. Todo el tráfico de cualquier dirección no incluida en los prefijos de dirección de cualquiera de las otras rutas se envía a la aplicación virtual.

  La adición de esta ruta cambió el estado de la ruta predeterminada para el prefijo de dirección 0.0.0.0/0 (ID11) de Activo a No válido para Subnet1 porque una UDR invalida una ruta predeterminada. Esta ruta existe para cumplir el requisito 3.

Subnet2

La tabla de rutas de Subnet2 del diagrama anterior contiene las rutas siguientes:

Expandir tabla

Fuente	Estado	Prefijos de dirección	Tipo del próximo salto	Dirección IP del próximo salto
Predeterminado	Activo	10.0.0.0/16	Red de área virtual
Predeterminado	Activo	10.1.0.0/16	Emparejamiento de redes virtuales de Azure
Predeterminado	Activo	10.2.0.0/16	Emparejamiento de redes virtuales de Azure
Predeterminado	Activo	10.10.0.0/16	Puerta de enlace de red virtual	[X.X.X.X]
Predeterminado	Activo	0.0.0.0/0	Internet
Predeterminado	Activo	10.0.0.0/8	Ninguno
Predeterminado	Activo	100.64.0.0/10	Ninguno
Predeterminado	Activo	192.168.0.0/16	Ninguno

La tabla de rutas de Subnet2 contiene todas las rutas predeterminadas creadas por Azure y el emparejamiento de red virtual opcional y las rutas opcionales de la puerta de enlace de red virtual. Azure ha agregado las rutas opcionales a todas las subredes de la red virtual cuando tanto la puerta de enlace como el emparejamiento se han agregado a la red virtual.

Azure ha quitado las rutas de los prefijos de dirección 10.0.0.0/8, 192.168.0.0/16 y 100.64.0.0/10 de la tabla de rutas de Subnet1 cuando la UDR del prefijo de dirección 0.0.0.0/0 se ha agregado a Subnet1.