Azure Virtual Network o Red Virtual (vNet) es un servicio que proporciona el bloque de compilación fundamental para su red privada en Azure. Una instancia del servicio (una red virtual) permite que muchos tipos de recursos de Azure se comuniquen, de forma segura entre sí, a Internet y a redes locales. Estos recursos de Azure incluyen máquinas virtuales (VM), Base de datos, …, etc.
Una red virtual (vNet) es similar a una red tradicional con la que trabajaría en su propio centro de datos. Pero aporta ventajas adicionales de la infraestructura Azure, como escalado, disponibilidad y aislamiento.
Conceptos básicos de red virtual (Virtual Network)
- Espacio de direcciones (Address space): El espacio de direcciones esta ligado directamente a la red virtual, no es posible crear una red virtual sin un espacio de direcciones, por ello al momento de crear una red virtual tiene que especificar como mínimo un espacio de direcciones IP privadas personalizado (RFC 1918).
- Subredes (Subnet): Las subredes le permiten segmentar la red virtual en una o varias subredes y asignar una parte del espacio de direcciones de la red virtual para cada subred. Los recursos de Azure en todos los casos se implementan en una subred específica (propósito especifico) si es que necesita una IP del espacio de direcciones, mas nunca en la red virtual directamente. Al igual que en una red tradicional, las subredes permiten segmentar el espacio de direcciones de red virtual en segmentos que sean adecuados para la red interna de la organización. La segmentación mejora la eficacia de la asignación de direcciones. Puede proteger los recursos dentro de las subredes mediante grupos de seguridad de red (NSG).
Propósitos específicos de las subredes:- Default: Es el mas usado, se usa por lo general para la conexión de maquinas virtuales y/o otros recursos de Azure que no necesitan unas características especiales en lo que a subred se refiere. Si no se especifica el propósito de la subred se refiere a este propósito. El nombre de esta subred puede ser personalizado.
- AzureBastionSubnet: El propósito de esta subred es para implementar el servicio Azure Bastion, servicio de gestión remota de recursos de Azure.
- AzureFirewallSubnet: El propósito de esta subred es para implementar el servicio Azure Firewall gestionado por Azure.
- AzureFirewallManagementSubnet: El propósito de esta subred es para implementar el servicio Azure Firewall gestionado por Azure con la NIC de administración de firewall habilitada y así forzar la tunelización del trafico.
- GatewaySubnet: El propósito de esta subred es para implementar el servicio Virtual Network Gateway.
- RouteServerSubnet: El propósito de esta subred es para implementar el servicio de Route Server.
Relación entre subscripción, región, red virtual, y zonas de disponibilidad
De acuerdo con la imagen de abajo y la arquitectura jerárquica de niveles de administracion de Microsoft Azure, una cuenta en Azure (Tenant) en lo que respecta a segmentación de cargas de trabajo (Workloads) estaba basado en las subscripciones (Subscriptions), así un Tenant puede estar compuesta por múltiples subscription (Este puede estar ligado a un entorno individual como Producción, Preproducción, Desarrollo, una aplicación critica, …, etc.) extendidas en todas las regiones (Punto de presencia de Azure en un país determinado con mas de un centros de datos físico) de Azure, y una Subscription puede estar compuesto por múltiples redes virtuales (vNets) en múltiples regiones. Las redes virtuales (vNet) esta compuesto por uno o mas subredes (Subnets) y abarcan todas las zonas de disponibilidad (Centro de datos fiscos en un país/región) de una región. La subnet, no es necesario dividirlas por zonas de disponibilidad para dar cabida a los recursos de zona. Por ejemplo, si configura una máquina virtual de zona, no tiene que tener en cuenta la subnet al seleccionar la zona de disponibilidad de la máquina virtual. Lo mismo sucede con otros recursos de zona.
Entre los escenarios clave que puede lograr con una red virtual (vNet) se incluyen:
- Comunicación de los recursos Azure con Internet: De manera predeterminada, todos los recursos de una red virtual pueden comunicarse con Internet. También puede utilizar una dirección IP pública, una puerta de enlace NAT o un equilibrador de carga pública para administrar sus conexiones salientes. Puede comunicarse de entrada con un recurso asignándole una dirección IP pública o un equilibrador de carga pública.
Si está utilizando únicamente un equilibrador de carga estándar interno, la conectividad saliente no estará disponible hasta que defina cómo desea que funcionen las conexiones salientes con una dirección IP pública a nivel de instancia o un equilibrador de carga público. - Comunicación entre los recursos de Azure: Los recursos de Azure se comunican de manera segura entre sí de una de las maneras siguientes:
- Red virtual: puede implementar VM y otros tipos de recursos de Azure en una red virtual. Algunos ejemplos de recursos son App Service Environments, Azure Kubernetes Service (AKS) y Azure Virtual Machine Scale Sets.
- Punto de conexión de servicio de red virtual: puede ampliar el espacio de direcciones privado de su red virtual y la identidad de su red virtual a los recursos de servicio Azure a través de una conexión directa. Algunos ejemplos de recursos son las cuentas Azure Storage y Azure SQL Database. Los puntos de conexión de los servicios permiten proteger los recursos críticos de los servicios de Azure únicamente en una red virtual.
- Emparejamiento de red virtual: puede conectar redes virtuales entre sí mediante el emparejamiento de redes virtuales. Los recursos de ambas redes virtuales pueden comunicarse entre sí. Las redes virtuales que conecte pueden estar en la misma región de Azure o en regiones diferente.
- Comunicación con recursos locales: Puede conectar los equipos y redes locales a una red virtual usando cualquiera de las siguientes opciones:
- Red privada virtual (VPN) de punto a sitio: se establece entre una red virtual y un único equipo de la red. Cada equipo que desea establecer conectividad con una red virtual debe configurar su conexión. Este tipo de conexión es muy útil si está empezando a utilizar Azure, o para desarrolladores, dado que requiere pocos o ningún cambio en una red existente. La comunicación entre el equipo y una red virtual se envía mediante un túnel cifrado a través de internet.
- VPN de sitio a sitio: Se establece entre su dispositivo VPN local y una puerta de enlace VPN de Azure desplegada en una red virtual. Este tipo de conexión permite que cualquier recurso local que autorice acceda a una red virtual. La comunicación entre un dispositivo VPN local y una puerta de enlace de VPN de Azure se envía mediante un túnel cifrado a través de internet.
- Azure ExpressRoute: se establece entre la red y Azure, mediante un asociado de ExpressRoute. Esta conexión es privada. El tráfico no pasa por Internet.
- Filtrado del tráfico de red: Puede filtrar el tráfico de red entre subredes mediante una o ambas de las siguientes opciones:
- Grupos de seguridad de red: los grupos de seguridad de red y los grupos de seguridad de aplicaciones pueden contener varias reglas de seguridad de entrada y de salida. Estas reglas permiten filtrar el tráfico desde y hacia los recursos por dirección IP de origen y destino, puerto y protocolo.
- Aplicaciones virtuales de red: una aplicación virtual de red es una máquina virtual que realiza una función de red, como un firewall o la optimización de una WAN.
- Enrutamiento del tráfico de red: De forma predeterminada Azure enruta el tráfico entre subredes, redes virtuales conectadas, redes locales e Internet. Puede implementar una o ambas de las siguientes opciones para invalidar las rutas predeterminadas que crea Azure:
- Tablas de enrutamiento: puede crear tablas de enrutamiento (route tables) personalizadas que controlen hacia dónde se enruta el tráfico de cada subred.
- Rutas del protocolo de puerta de enlace de borde (BGP): si conecta una red virtual a una red local mediante una puerta de enlace de Azure VPN o ExpressRoute, puede propagar las rutas BGP locales a sus redes virtuales.
- Integración con servicios de Azure: La integración de servicios de Azure en una red virtual de Azure permite el acceso privado al servicio desde las máquinas virtuales o los recursos de proceso de la red virtual. Puede usar las siguientes opciones para esta integración:
- Implementar instancias dedicadas del servicio en una red virtual. Luego se puede acceder de forma privada a los servicios dentro de la red virtual y desde redes locales.
- Use Azure Private Link para acceder de forma privada a una instancia específica del servicio desde su red virtual y desde redes locales.
- Acceder al servicio a través de puntos de conexión públicos extendiendo una red virtual al servicio, a través de puntos de conexión de servicio. Los puntos de conexión de servicio permiten que los recursos de servicio se protejan en la red virtual.
Emparejamiento de redes virtuales de Azure
Al igual que ocurre en las redes tradicionales virtualizadas a nivel 3 (vrf), donde una vrf que es una red privada (una empresa puede tener multipes vrfs) que no tienen conexión directa con otra vrf de la empresa aunque comparten el mismo hardware de red, necesita un elemento de red para lograr la conexión entre vrfs (Leaking). En azure las redes virtuales (vNet) necesitan de un elemento de red para poder conectar con otra red virtual de la empresa ya sea en la misma subscripción o en otra distinta. Este elemento de red o servicio es el emparejamiento (peering). A efectos de conectividad las redes virtuales aparecen como una sola. El tráfico entre las máquinas virtuales de la red virtual emparejada usa la infraestructura de la red troncal de Microsoft. Al igual que el tráfico entre las máquinas virtuales de la misma red, el tráfico solo se enruta a través de la red privada de Microsoft.
La directiva admite los siguientes tipos de emparejamiento:
- Emparejamiento de red virtual: conecte redes virtuales que se encuentren en la misma región de Azure.
- Emparejamiento global de redes virtuales: conexión de redes virtuales en distintas regiones de Azure.
Las ventajas del uso del emparejamiento de redes virtuales, ya sean locales o globales, son las siguientes:
- Baja latencia, conexión de gran ancho de banda entre los recursos de redes virtuales diferentes.
- La capacidad de los recursos de una red virtual para comunicarse con los de otra red virtual.
- La capacidad de transferir datos entre redes virtuales de distintas suscripciones de Azure, inquilinos de Microsoft Entra, modelos de implementación y regiones de Azure.
- La capacidad de emparejar redes virtuales creadas mediante Azure Resource Manager.
- La capacidad de emparejar una red virtual creada mediante Resource Manager con otra creada mediante el modelo de implementación clásica.
- No tienen tiempo de inactividad ni los recursos de la red virtual al crear el emparejamiento, o después.
El tráfico de red entre redes virtuales emparejadas es privado. El tráfico entre las redes virtuales se mantiene en la red troncal de Microsoft. No se requiere ninguna red pública de Internet, puertas de enlace ni cifrado en la comunicación entre las redes virtuales.
Conectividad
En el caso de las redes virtuales emparejadas, los recursos de cualquiera de ellas se pueden conectar directamente con los de la red virtual emparejada.
La latencia de red entre las máquinas virtuales de redes virtuales emparejadas en la misma región es la misma que la de una única red virtual. El rendimiento de la red se basa en el ancho de banda que se permite para la máquina virtual, en proporción a su tamaño. No hay restricciones adicionales con respecto al ancho de banda en el emparejamiento.
El tráfico entre las máquinas virtuales de redes virtuales emparejadas se enruta directamente a través de la infraestructura de red troncal de Microsoft, y no a través de una puerta de enlace o de una red Internet pública.
En cualquier red virtual, se pueden aplicar grupos de seguridad de red para bloquear el acceso a otras redes o subredes virtuales. Al configurar el emparejamiento de red virtual, abra o cierre las reglas del grupo de seguridad de red entre las redes virtuales. Si abre la conectividad completa entre redes virtuales emparejadas, puede aplicar grupos de seguridad de red a subredes o máquinas virtuales concretas para bloquear o denegar el acceso específico. La opción predeterminada es la conectividad total.
Encadenamiento de servicio
El encadenamiento de servicios permite dirigir el tráfico de una red virtual a una aplicación virtual o puerta de enlace de una red emparejada a través de rutas definidas por el usuario (UDR).
Para habilitar el encadenamiento de servicios, configure las UDR que apuntan a máquinas virtuales de redes virtuales emparejadas como la dirección IP del próximo salto. Las UDR también pueden apuntar a puertas de enlace de redes virtuales para habilitar el encadenamiento de servicios.
Puede implementar redes radiales (Spokes), en las que la red virtual del concentrador (HUB) hospeda componentes de la infraestructura, como una aplicación virtual de red o una puerta de enlace de VPN. Todas las redes virtuales de radio se pueden emparejar con la red virtual de concentrador. El tráfico fluye por las aplicaciones virtuales de red o las puertas de enlace de VPN de la red virtual del concentrador.
El emparejamiento de red virtual permite que el próximo salto de una UDR sea la dirección IP de una máquina virtual de la red virtual emparejada o en una puerta de enlace de VPN. No puede realizar el enrutamiento entre redes virtuales con una UDR que especifique una puerta de enlace de Azure ExpressRoute como del tipo de próximo salto.
Puertas de enlace y conectividad local
Cada red virtual, incluidas las redes virtuales emparejadas, puede tener su propia puerta de enlace. Las redes virtuales pueden usar su puerta de enlace para conectarse a una red local. También puede configurar conexiones entre redes virtuales mediante puertas de enlace, incluso para redes virtuales emparejadas.
Cuando se configuran las dos opciones para la interconectividad de redes virtuales, el tráfico entre las redes virtuales se propaga a través de la configuración del emparejamiento. El tráfico usa la red troncal de Azure.
La puerta de enlace de la red virtual emparejada también se puede configurar como un punto de tránsito a una red local. En ese caso, la red virtual que usa una puerta de enlace remota no puede tener su propia puerta de enlace. Una red virtual no puede tener más de una puerta de enlace. En la red virtual emparejada, la puerta de enlace debe ser local o remota, como se muestra en el diagrama siguiente.
Tanto el emparejamiento de red virtual como el emparejamiento de red virtual global admiten el tránsito de puerta de enlace.
Se admite el tránsito de puerta de enlace entre redes virtuales creadas mediante diferentes modelos de implementación. La puerta de enlace debe estar en la red virtual del modelo de Azure Resource Manager.
Si se emparejan redes virtuales que comparten la misma conexión de ExpressRoute, el tráfico entre ellas pasa por la relación de emparejamiento. Ese tráfico usa la red troncal de Azure. Puede seguir usando las puertas de enlace locales de cada red virtual para conectarse al circuito local. De lo contrario, puede utilizar una puerta de enlace compartida y configurar el tránsito para una conectividad local.
Enrutamiento del tráfico de la red virtual en Azure
Al igual que en las redes tradicionales donde el enrutamiento esta basado en rutas obtenidas de la conexion y de forma estáticas y dinámicas almacenadas en una tablas de rutas. En las redes virtuales (vNets) ocurre lo mismo, el enrutamiento esta en base a rutas que serán creadas por el sistema, dinámicamente o incluidas manualmente de acuerdo a conveniencia y están almacenado en una tabla de ruta.
Rutas predefinidas
Al crear una red virtual en Azure, este crea automáticamente una tabla de rutas para cada subred de dicha red virtual y agrega las rutas predeterminadas del sistema (Default) a dicha tabla. No se puede quitar rutas predeterminadas de sistema, pero si se puede invalidar algunas con rutas personalizadas agregadas a demanda.
Cada ruta contiene un prefijo de dirección y el tipo de próximo salto. Cuando el tráfico que sale de una subred se envía a una dirección IP que está dentro del prefijo de la dirección de ruta, la ruta que contiene el prefijo es la que utiliza Azure.
Source | Prefijos de dirección | Tipo del próximo salto |
---|---|---|
Default | Único para la red virtual | Virtual network |
Default | 0.0.0.0/0 | Internet |
Default | 10.0.0.0/8 | None |
Defaut | 172.16.0.0/12 | None |
Default | 192.168.0.0/16 | None |
Default | 100.64.0.0/10 | None |
Como en las tablas de rutas de la red tradicional se maneja el termino de «próximo salto«, el las tablas de rutas del las redes virtuales son lo mismo aunque tiene nombres preestablecidos. Y son las siguientes:
- Red virtual (Virtual network): Enruta el tráfico entre los intervalos de direcciones del espacio de direcciones de una red virtual (vNet). Azure crea una ruta con un prefijo de dirección que corresponde a cada intervalo de direcciones definido en el espacio de direcciones de una red virtual. Si el espacio de direcciones de la red virtual tiene varios intervalos de direcciones definidos, Azure crea una ruta individual para cada intervalo de direcciones. De forma predeterminada, Azure enruta el tráfico entre subredes. No es necesario definir tablas de rutas ni puertas de enlace de Azure para enrutar el tráfico entre subredes. Azure no crea rutas predeterminadas para intervalos de direcciones de subred. Cada intervalo de direcciones de subred está dentro de un intervalo de direcciones del espacio de direcciones de la red virtual.
- Internet: enruta a Internet el tráfico que especifica el prefijo de dirección. La ruta predeterminada del sistema especifica el prefijo de dirección 0.0.0.0/0. Si no se invalidan las rutas predeterminadas de Azure, Azure enruta a Internet el tráfico de todas las direcciones que no se hayan especificado en un intervalo de direcciones dentro de una red virtual. Hay una excepción a este enrutamiento. Si la dirección de destino es para un servicio de Azure, Azure enruta el tráfico directamente al servicio a través de la red troncal de Azure en lugar de enrutar el tráfico a Internet. El tráfico entre los servicios de Azure no atraviesa Internet. No importa en qué región de Azure exista la red virtual o en qué región de Azure se implementa una instancia del servicio de Azure. Puede reemplazar la ruta del sistema predeterminada de Azure predeterminado para el prefijo de dirección 0.0.0.0/0 por una ruta personalizada.
- None: el tráfico que se enruta al tipo de próximo salto None se elimina, en lugar de enrutarlo fuera de la subred. Azure crea automáticamente las rutas predeterminadas para los siguientes prefijos de dirección:
- 10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16: reservadas para el uso privado en el RFC 1918.
- 100.64.0.0/10: reservada en RFC 6598.
Rutas predeterminadas opcionales
Azure agrega más rutas del sistema predeterminadas para diferentes funcionalidades de Azure, pero solo si se habilitan las funcionalidades. . En función de la funcionalidad, Azure agrega las rutas predeterminadas opcionales a subredes concretas de la red virtual o a todas las subredes de una red virtual. En la tabla siguiente se enumeran las otras rutas del sistema y los tipos de próximo salto que Azure podría agregar al habilitar diferentes funcionalidades.
Source | Prefijos de dirección | Tipo del próximo sato | La subred de red virtual a la qu agrega la ruta |
---|---|---|---|
Default | Único para la red virtual, por ejemplo: 10.1.0.0/16 | Virtual network peering | All |
Virtual network gateway | Prefijos anunciados desde el entorno local a través del Protocolo BGP o configurados en la puerta de enlace de red local | Virtual network gateway | All |
Default | Multiple | VirtualNetworkServiceEndpoint | Solo la subred para la que se habilita un punto de conexión de servicio |
- Emparejamiento de red virtual (Virtual network peering): al crear un emparejamiento de red virtual entre dos redes virtuales, el sistema agrega una ruta para cada intervalo de direcciones en el espacio de direcciones de cada red virtual para la que se crea un emparejamiento.
- Puerta de enlace de red virtual (Virtual network gateway): cuando una puerta de enlace de red virtual se agrega a una red virtual, se agregan también una o varias rutas en las que Puerta de enlace de red virtual aparece como el tipo de próximo salto. El origen es también una puerta de enlace de red virtual, ya que la puerta de enlace agrega las rutas a la subred. Si la puerta de enlace de red local intercambia rutas BGP con una puerta de enlace de red virtual, el sistema agrega una ruta para cada ruta. Estas rutas se propagan desde la puerta de enlace de red local. Se recomienda resumir las rutas locales al intervalo de direcciones más grande posible para propagar el menor número de rutas a una puerta de enlace de red virtual de Azure. Hay límites en el número de rutas que se pueden propagar a una puerta de enlace de red virtual de Azure.
VirtualNetworkServiceEndpoint
: Azure agrega las direcciones IP públicas de determinados servicios a la tabla de rutas cuando se habilita un punto de conexión para el servicio. Los puntos de conexión de servicio están habilitados para subredes individuales dentro de una red virtual, por lo que la ruta solo se agrega a la tabla de rutas de una subred para la que está habilitado un punto de conexión de servicio. Las direcciones IP públicas de los servicios de Azure cambian periódicamente. Azure administra automáticamente las direcciones en la tabla de rutas cuando cambian.
Rutas personalizadas
Para crear rutas personalizadas, cree rutas definidas por el usuario (UDR) o intercambiar rutas BGP entre la puerta de enlace de red local y una puerta de enlace de red virtual de Azure.
Rutas definidas por el usuario (UDR)
Para personalizar las rutas de tráfico, no se debe modificar las rutas predeterminadas. Debe crear rutas personalizadas o definidas por el usuario (estáticas), que invalidan las rutas del sistema predeterminadas de Azure. En Azure, crea una tabla de rutas y la asocia a cero o más subredes de red virtual. Cada subred puede tener cero o una tabla de rutas asociada.
De forma predeterminada, una tabla de rutas puede contener hasta 400 UDR. Con la configuración de enrutamiento de Azure Virtual Network Manager, este número puede ampliarse a 1.000 UDR por tabla de rutas. Este mayor límite admite configuraciones de enrutamiento más avanzadas. Un ejemplo es dirigir el tráfico desde centros de datos locales a través de un firewall a cada red virtual spoke en una topología en estrella tipo hub-and-spoke cuando tiene un mayor número de redes virtuales radiales.
Si crea una tabla de rutas y la asocia 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 UDR invalidan las rutas predeterminadas.
Puede especificar los siguientes tipos de próximo salto al crear una UDR:
- Aplicación virtual (Virtual appliance): una aplicación virtual es una máquina virtual que ejecuta normalmente una aplicación de red como, por ejemplo, un firewall. Al crear una ruta con el tipo de salto de aplicación virtual, especifique también una dirección IP del próximo salto. La dirección IP puede ser:
- La 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íe el tráfico de red a una dirección que no sea la suya propia debe tener la opción Habilitar reenvío de IP habilitada. La configuración deshabilita la comprobación del origen y el destino de una interfaz de red por parte de Azure. Habilitar el reenvío IP es una configuración de Azure.
Es posible que 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 redirigir mediante proxy el tráfico o realizar la traducción de direcciones de red (NAT) desde la dirección IP privada del origen hasta su propia dirección IP privada. Después, Azure realiza la NAT en una dirección IP pública antes de enviar el tráfico a Internet.
Nota: Implemente una aplicación virtual en una subred diferente en la que se encuentran los recursos que enrutan a través de la aplicación virtual. La implementación de la aplicación virtual en la misma subred y la posterior aplicación de una tabla de rutas en la subred que enruta el tráfico a través de la aplicación virtual pueden provocar bucles de enrutamiento, en los que el tráfico nunca sale de la subred. Una dirección IP privada del próximo salto debe tener conectividad directa sin tener que enrutar a través de una puerta de enlace de Azure ExpressRoute o a través de Azure Virtual WAN. Si se establece el próximo salto en una dirección IP sin conectividad directa, se produce una configuración UDR no válida. - La dirección IP privada de un equilibrador de carga interno de Azure. A menudo se usa un equilibrador de carga como parte de una estrategia de alta disponibilidad para aplicaciones virtuales de red.
- La 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íe el tráfico de red a una dirección que no sea la suya propia debe tener la opción Habilitar reenvío de IP habilitada. La configuración deshabilita la comprobación del origen y el destino de una interfaz de red por parte de Azure. Habilitar el reenvío IP es una configuración de Azure.
- Puerta de enlace de red virtual (Virtual network gateway): se especifica cuando se 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 el tipo ExpressRoute en una UDR porque con ExpressRoute, debe usar BGP para rutas personalizadas. Tampoco puede especificar puertas de enlace de red virtual si tiene conexiones coexistentes de red privada virtual (VPN) y ExpressRoute. Puede definir una ruta que dirige el tráfico destinado al prefijo de dirección 0.0.0.0/0 a una puerta de enlace de red virtual basada en ruta.
En un entorno local, puede tener un dispositivo que compruebe el tráfico y determine si se reenvía o se elimina. En lugar de configurar una UDR 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 el BGP para una puerta de enlace de red virtual VPN está habilitado. - None: se especifica cuando se desea colocar tráfico en un prefijo de dirección, en lugar de reenviar el tráfico a un destino. Azure puede mostrar None para algunas de las rutas del sistema opcionales si no está configurada una funcionalidad.
- Red virtual (Virtual network): especifique la opción de red virtual si desea reemplazar el enrutamiento predeterminado en 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 úselo si quiere que el tráfico destinado a los servicios de Azure con direcciones IP públicas se mantenga dentro de la red troncal de Azure.
No se puede especificar emparejamiento de red virtual o VirtualNetworkServiceEndpoint
como el tipo de próximo salto en UDR. Azure crea rutas con emparejamiento de red virtual o tipos de próximo salto VirtualNetworkServiceEndpoint
solo cuando se configura 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 un UDR en lugar de un intervalo IP explícito. Una etiqueta de servicio representa un grupo de prefijos de dirección 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. Así se minimiza la complejidad de las actualizaciones frecuentes de las rutas definidas por el usuario y se reduce el número de rutas que hay que 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.
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 de IP explícito y una ruta con una etiqueta de servicio. Cuando varias rutas con etiquetas de servicio tienen prefijos de IP que coinciden, las rutas se evalúan en el orden siguiente:
- Etiquetas regionales (por ejemplo,
Storage.EastUS
oAppService.AustraliaCentral
) - Etiquetas de nivel superior (por ejemplo,
Storage
oAppService
) - Etiquetas regionales
AzureCloud
(por ejemplo,AzureCloud.canadacentral
oAzureCloud.eastasia
) - Etiqueta
AzureCloud
Ejemplo de creación de una ruta con Azure CLI usando una etiqueta de servicio «Storage».
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
Border Gateway Protocol
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. No puede crear una 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.
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 las conexiones VPN se logra mediante rutas personalizadas con un próximo salto de tipo Puerta de enlace de red virtual.
Nota: La propagación de rutas no debe deshabilitarse en GatewaySubnet
. La puerta de enlace no funcionará si esta configuración está deshabilitada.
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:
- Ruta definida por el usuario
- Ruta BGP
- Ruta del sistema
Nota: Las rutas de sistema para el tráfico relacionado con la red virtual, los emparejamientos de la red virtual o los puntos de conexión de servicio de red virtual son las rutas preferidas. Se prefieren, incluso si las rutas BGP son más específicas. Las rutas con un punto de conexión de servicio de red virtual como el tipo de próximo salto no se pueden invalidar, incluso cuando se usa una tabla de rutas.
Por ejemplo, una tabla de rutas contiene las rutas siguientes:
Source | Prefijo de dirección | Tipo de próximo salto |
---|---|---|
Default | 0.0.0.0/0 | Internet |
User | 0.0.0.0/0 | Virtual network gateway |
Cuando el destino del tráfico es una dirección IP que está fuera de los prefijos de dirección de las otras rutas de la tabla de rutas, Azure selecciona la ruta con el origen Usuario. Azure elige esta opción porque las UDR son una prioridad más alta que las rutas predeterminadas del sistema.