Para ilustrar los conceptos de enrutamiento en Azure (Rutas predeterminadas, opcionales, UDR .. etc) mostramos el siguiente escenario con los siguientes requisitos.
- Dos redes virtuales (Virtual-Network-1 y 2) en la misma región de Azure y habilitado los recursos necesarios para la comunicación entre ellas, en este caso el peering (Emparejamiento).
- Una red local que comunica de forma segura con ambas redes virtuales mediante un túnel VPN a través de Internet.
- Para una subred (Subred-1) de una red virtual (Virtual-Network-1):
- Enrute todo el tráfico saliente desde la subred a través de una aplicación virtual de red (NVA) para la inspección y el registro. Excluyendo el tráfico a Azure Storage 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.
- Elimine todo el tráfico saliente destinado a la otra red virtual.
- Habilite el tráfico saliente a Azure Storage para que fluya directamente al almacenamiento, sin hacerle pasar por una aplicación virtual de red.
- Permitir todo el tráfico entre las restantes subredes y las redes virtuales.
Diagrama
En el diagrama siguiente se muestra la 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.
Tabla de ruta «RT-1» de la subred «subred-1»
ID | Source | State | Prefijos | Tipo de next-hop | IP Next-hop |
---|---|---|---|---|---|
1 | Defecto | No válido | 10.0.0.0/16 | Virtual network | |
2 | Usuario | Activo | 10.0.0.0/16 | Aplicación virtual | 10.0.100.4 |
3 | Usuario | Activo | 10.0.0.0/24 | Virtual network | |
4 | Defecto | No válido | 10.1.0.0/16 | Emparejamiento de redes virtuales de Azure | |
5 | Defecto | No válido | 10.2.0.0/16 | Emparejamiento de redes virtuales de Azure | |
6 | Usuario | Activo | 10.1.0.0/16 | None | |
7 | Usuario | Activo | 10.2.0.0/16 | None | |
8 | Defecto | 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 |
10 | Defecto | Activo | [X.X.X.X] | VirtualNetworkServiceEndpoint | |
11 | Defecto | No válido | 0.0.0.0/0 | Internet | |
12 | Usuario | Activo | 0.0.0.0/0 | Aplicación virtual | 10.0.100.4 |
Esta es una explicación de cada identificador de ruta:
- ID 1: Azure agregó automáticamente esta ruta a todas las tablas de rutas de las subredes de Virtual-network-1, ya que 10.0.0.0/16 es el único intervalo de direcciones definido en el espacio de direcciones de la red virtual Virtual-Network-1. Si no se crea ninguna UDR con un prefijo igual al espacio de direcciones, 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 y mas exacto 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ó una UDR en la tabla de rutas «RT-1» que tiene el mismo prefijo que la ruta predeterminada (ID 2), recordemos las UDR invalidan las rutas predeterminadas. El estado de esta ruta seguirá Activo para la subred «Subred-2» porque la tabla de rutas «RT-2» no tiene ninguna UDR con prefijo igual a la ruta predetermina y «Subred-2» no esta asociada a «RT-1». - ID 2: Azure agregó esta ruta cuando el la tabla de rutas «RT-1» que esta asociado a la subred «Subred-1» en la red virtual de virtual-network-1, se incluyo un UDR tipo «Virtual appliance» para el prefijo de dirección 10.0.0.0/16. La UDR especifica a 10.0.100.4 como dirección IP del «Virtual appliance», porque la dirección es la dirección IP privada asignada a la máquina virtual de la aplicación virtual (NVA). La tabla de rutas en la que existe esta ruta no está asociada a «Subred-2«, por lo que la ruta no aparece en la tabla de rutas «RT-2» para Subred-2.
Esta ruta reemplaza la ruta predeterminada del prefijo 10.0.0.0/16 (ID 1), 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 «Virtual Network». Esta ruta existe para cumplir con el requisito 3 del escenario mostrado arriba, que es forzar todo el tráfico saliente a través de una aplicación virtual. - ID 3: Azure agregó esta ruta cuando en la tabla de rutas «RT-1» que esta asociado a la subred «subred-1» se incluyo una UDR para el prefijo de red 10.0.0.0/24. 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 (ID 2), porque tiene un prefijo más largo o mas exacto que la ruta incluida en «ID 2«. La tabla de rutas «RT-1» no estaba asociada a la subred «Subred-2«, por lo que la ruta no aparece en la tabla de rutas «RT-2» de la subred «Subred-2″. Esta ruta reemplaza eficazmente la ruta agregada en «ID 2» para el tráfico de la subred «Subred-1″. Esta ruta existe para cumplir el requisito 3 del escenario mostrado.
- ID 4: Azure agregó automáticamente las rutas de los identificadores 4 y 5 para todas las subredes de la red virtual «Virtual-Network-1«, cuando esta red virtual se emparejó con «Virtual-Network-2«. La red virtual «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 a cada intervalo. Si no se creará las UDRs en la tabla de rutas «RT-1» especificados en los ID de ruta 6 y 7, el tráfico enviado desde la subred «Subred-1» de la red virtual «Virtual-Network-1» a cualquier dirección entre 10.1.0.1-10.1.255.254 y 10.2.0.1-10.2.255.254 se enrutaria a la red virtual del mismo nivel. ósea la red virtual «Virtual-Network-2», 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.
Cuando se agregó las rutas en los «ID 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 la subred «Subred-2″ porque la tabla de rutas «RT-1» en la que están las UDR de los identificadores 6 y 7 no están asociadas a la subred «Subred-2″. Se ha creado un emparejamiento de red virtual para cumplir el requisito 1 del escenario del ejemplo. - ID 5: la misma explicación que para ID 4.
- ID 6: Azure agregó esta ruta y la ruta en la ID 7 cuando en la tabla de rutas «RT-1» que esta asociado a la subred «subred-1» se incluyo las UDR para los prefijos de dirección 10.1.0.0/16 y 10.2.0.0/16. Azure anula el tráfico destinado a las 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 UDRs reemplazan a las rutas predeterminadas. Las rutas no están asociadas a la subred «Subnet-2″, por lo que no aparecen en la tabla de rutas «RT-2» de la subred «Subred-2″. Las rutas reemplazan las rutas de ID 4 e ID 5 en el caso del tráfico que sale de la rubred «Subred-1″. Las rutas ID 6 y ID 7 existen para satisfacer el punto 3 del escenario, «eliminación del tráfico destinado a la otra red virtual».
- ID 7: la misma explicación que para ID 6.
- ID 8: Azure agregó automáticamente esta ruta para todas las subredes de la red virtual «Virtual-Network-1» cuando se creó una puerta de enlace de red virtual de tipo VPN en la red virtual «Virtual-Network-1». Azure agregó la dirección IP pública de la puerta de enlace de red virtual a la tabla 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, mas exacto 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 del escenario del ejemplo.
- ID 9: Azure agregó esta ruta cuando en la tabla de rutas «RT-1» que esta asociado a la subred «subred-1» se agregó una UDR para el prefijo de dirección 10.10.0.0/16 a la tabla de rutas asociada a la subred «Subred-1″. Esta ruta reemplaza la entrada en ID 8. La ruta envía todo el tráfico destinado a la red local a una aplicación virtual de red (NVA) para su inspección, en lugar de enrutar el tráfico directamente a el entorno local. Esta ruta se ha creado para cumplir el requisito 3 del escenario del ejemplo.
- ID 10: Azure agregó automáticamente esta ruta a la subred «Subred-1» cuando un punto de conexión de servicio a un servicio de Azure (Microsoft.Storage) se habilitó 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, mas exacto 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 para el escenario del ejemplo, con el fin de habilitar que el tráfico destinado a Azure Storage que fluya directamente a dicho servicio.
- ID 11: Azure agregó automáticamente esta ruta a la tabla de rutas de todas las subredes de Virtual-Network-1 y Virtual-Network-2. El prefijo de dirección 0.0.0.0/0 es el más corto. Todo el tráfico enviado a direcciones de un prefijo de dirección más largo o mas exacto 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 ha cambiado automáticamente el estado de Activo a No válido para la subred «Subred-1» cuando se agrega en la tabla de rutas «RT-1″ asociada a a»Subred-1» una UDR para el prefijo de dirección 0.0.0.0/0 (ID 12). El estado de esta ruta sigue siendo Activo para las restantes subredes de ambas redes virtuales, ya que la ruta no está asociada a otras subredes de otras redes virtuales.
- ID 12: Azure agregó esta ruta cuando en la tabla de rutas «RT-1» que esta asociado a la subred «subred-1» se agregó una UDR para el prefijo de red 0.0.0.0/0. La UDR especifica 10.0.100.4 como dirección IP de la aplicación virtual (NVA). Esta ruta no está asociada a la subred «Subred-2″, por lo que no aparece en la tabla de rutas de la subred «Subred-2″. 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 ha cambiado el estado de la ruta predeterminada para el prefijo de dirección 0.0.0.0/0 (ID 11) de Activo a No válido para Subred-1, porque una UDR reemplaza a una ruta predeterminada. Esta ruta existe para cumplir el requisito 3 para el escenario del ejemplo.
Tabla de ruta «RT-2» de la subred «subred-2»
La tabla de rutas de Subnet2 del diagrama anterior contiene las rutas siguientes:
Source | State | Prefijos de dirección | Tipo de próximo salto | Dirección IP de siguiente salto |
---|---|---|---|---|
Defecto | Active | 10.0.0.0/16 | Virtual network | |
Defecto | Active | 10.1.0.0/16 | Emparejamiento de redes virtuales de Azure | |
Defecto | Active | 10.2.0.0/16 | Emparejamiento de redes virtuales de Azure | |
Defecto | Active | 10.10.0.0/16 | Puerta de enlace de red virtual | [X.X.X.X] |
Defecto | Active | 0.0.0.0/0 | Internet | |
Defecto | Activo | 10.0.0.0/8 | None | |
Defecto | Active | 100.64.0.0/10 | None | |
Defecto | Activo | 192.168.0.0/16 | None |
La tabla de rutas «RT-2» de la subred «Subred-2″ 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 «RT-1» de la subred «Subred-1″ cuando la UDR del prefijo de dirección 0.0.0.0/0 se ha agregado a Subred-1.