Rutas personalizadas y aplicaciones virtuales de red en Azure: UDR, BGP y reenvío de IP

radio_button_uncheckedshort_text1. Enrute el tráfico por una inspección en vez de confiar en el camino predeterminado

Una empresa minorista sufrió una brecha que expuso nombres, direcciones y datos de pago. El plan de corrección incorpora aplicaciones virtuales de red para inspeccionar el tráfico antes de que llegue a sistemas sensibles. El equipo de infraestructura debe hacer que Azure seleccione este recorrido de forma coherente e impedir que la comunicación directa entre subredes eluda el control.

Este capítulo construye la solución desde la tabla de rutas. Distinguirá rutas del sistema, opcionales, BGP y definidas por el usuario; elegirá un próximo salto; implementará una NVA Ubuntu sencilla; habilitará reenvío en dos planos diferentes y demostrará el camino asimétrico mediante traceroute.

• Identificar las capacidades de enrutamiento de Azure Virtual Network y su comportamiento predeterminado.
• Configurar tablas y rutas definidas por el usuario (UDR).
• Implementar una aplicación virtual de red básica y explicar su función de seguridad.
• Habilitar reenvío de IP en la NIC de Azure y en el sistema operativo invitado.
• Dirigir el tráfico de la subred pública por la NVA y validar cada salto.

Se requieren conocimientos de subredes, direccionamiento IP, Azure Virtual Network, CLI de Azure y SSH, además de una suscripción autorizada para los laboratorios opcionales.

radio_button_uncheckedshort_text2. Azure enruta automáticamente el tráfico que sale de una subred

Cada subred de Azure tiene una tabla de rutas efectivas. Azure crea las rutas iniciales, las combina con rutas opcionales de la plataforma, rutas propagadas por la puerta de enlace y UDR asociadas y evalúa la IP de destino de cada paquete saliente. Por ello, las VM de una VNet pueden comunicarse entre subredes sin un enrutador administrado por el cliente.

Las rutas del sistema no se crean ni eliminan manualmente. Algunas se pueden invalidar mediante una ruta más específica o personalizada con mayor prioridad. Toda ruta contiene prefijo de destino y tipo de próximo salto; una ruta de aplicación virtual también incluye la IP privada de dicho salto.

radio_button_uncheckedshort_text3. Las rutas predeterminadas definen tráfico local, Internet y descarte

Si un intervalo privado reservado se asigna a la VNet, Azure cambia la ruta aplicable a Red virtual. El próximo salto Ninguno descarta el paquete en el enrutamiento; no es una denegación de NSG.

radio_button_uncheckedshort_text4. Las capacidades de Azure agregan rutas opcionales

Un punto de conexión extiende la identidad de subred a un servicio admitido y crea rutas optimizadas. No convierte VirtualNetworkServiceEndpoint en una opción seleccionable para una UDR.

radio_button_uncheckedshort_text5. Una tabla de rutas vincula la directiva a una subred

La tabla de rutas es un recurso de Azure Resource Manager que contiene UDR y la configuración de propagación de rutas de la puerta de enlace. Una tabla puede asociarse con varias subredes, pero una subred solo admite una tabla. Sus UDR se combinan con las rutas del sistema y propagadas.

• Asocie la tabla con la subred de origen cuyas decisiones salientes quiere cambiar.
• No coloque la NVA en la misma subred cuya UDR apunta a ella, porque puede crear un bucle.
• No deshabilite propagación de puerta de enlace en GatewaySubnet; la puerta podría dejar de funcionar.
• Use las rutas efectivas de una NIC para ver el resultado final y los estados Activo o No válido.

radio_button_uncheckedshort_text6. Las rutas personalizadas proceden de UDR o BGP

Una UDR es una ruta estática definida por el administrador y almacenada en una tabla de Azure. BGP es un protocolo dinámico que intercambia prefijos entre una puerta local y la puerta de red virtual de Azure. Ambos orígenes pueden invalidar el comportamiento predeterminado, pero su propiedad y ciclo de vida difieren.

radio_button_uncheckedshort_text7. Los tipos de próximo salto expresan la acción de la UDR

Emparejamiento y VirtualNetworkServiceEndpoint son tipos generados por la plataforma, no valores de UDR. VirtualAppliance requiere una IP directamente conectada; un próximo salto incorrecto o inactivo interrumpe el flujo.

radio_button_uncheckedshort_text8. Las etiquetas de servicio reducen el mantenimiento

El prefijo de una UDR puede ser una etiqueta de servicio en lugar de un CIDR literal. Microsoft mantiene los prefijos de etiquetas como Storage, sus variantes regionales y AzureCloud. Así se reducen rutas y cambios manuales cuando el servicio modifica direcciones.

Siguen existiendo límites y precedencia. Una tabla admite un número limitado de rutas con etiquetas; una ruta IP explícita vence a una etiqueta en una coincidencia exacta. Entre etiquetas coincidentes, las regionales más específicas se evalúan antes que sus categorías amplias.

radio_button_uncheckedshort_text9. BGP propaga el conocimiento de red híbrida

BGP intercambia información de enrutamiento entre sistemas autónomos. ExpressRoute exige BGP entre el extremo local y Microsoft; Azure VPN Gateway puede usarlo opcionalmente en conexiones sitio a sitio. Cada prefijo anunciado aparece en subredes aptas con Puerta de enlace de red virtual como origen y próximo salto.

La retirada dinámica permite seleccionar otro camino tras una avería. Resuma rutas locales para anunciar menos prefijos. Una tabla puede deshabilitar propagación en subredes concretas, pero nunca lo haga en GatewaySubnet.

radio_button_uncheckedshort_text10. El prefijo más largo se evalúa antes que la prioridad del origen

Azure elige primero la ruta cuyo prefijo contiene el destino con mayor especificidad. Para 10.0.0.2, una ruta /24 vence a una /16 sin importar el orden visual. Un prefijo más largo contiene menos direcciones y expresa una intención más precisa.

Solo con prefijos iguales se aplica el orden general: UDR, BGP y ruta del sistema. Las rutas preferidas de VNet, emparejamiento y puntos de servicio tienen tratamiento especial; la de punto de servicio no se invalida. Una tabla no admite dos UDR con el mismo prefijo.

radio_button_uncheckedshort_text11. Corrección actual: una ruta Internet no es un diseño de salida

La ruta 0.0.0.0/0 con próximo salto Internet sigue apareciendo. Sin embargo, enrutamiento y NAT de origen son distintos. Para APIs publicadas después del 31 de marzo de 2026, las VNet nuevas usan subredes privadas de forma predeterminada y requieren un método explícito para llegar a endpoints públicos.

• Use Azure NAT Gateway para salida predecible, escalable y solo saliente.
• Asocie una IP pública explícita cuando una VM realmente la necesite.
• Use reglas salientes de Standard Load Balancer cuando formen parte del diseño.
• Use UDR con NVA o firewall solo si el dispositivo también proporciona proxy/NAT y camino de retorno.
• No use una UDR Internet en una subred privada para recuperar salida; la plataforma actual bloquea ese camino.

Una UDR 0.0.0.0/0 a una NVA implementa tunelización forzada. También puede desviar destinos públicos de servicios Azure si no hay una ruta de punto de servicio más larga; evalúe activación, actualizaciones, DNS y administración antes del despliegue.

radio_button_uncheckedshort_text12. Una NVA es una VM que ejecuta funciones de red

Una aplicación virtual de red es una máquina virtual o imagen de appliance que controla tráfico mediante enrutamiento y una aplicación de red. Puede realizar firewall, optimización WAN, entrega de aplicaciones, enrutamiento, equilibrio de carga, IDS/IPS y proxy.

Azure Marketplace ofrece imágenes de Cisco, Check Point, Barracuda, Sophos, WatchGuard y SonicWall. También puede crear una NVA didáctica con Windows o Linux, pero soporte, parches, rendimiento, licencias y alta disponibilidad de producción deben diseñarse expresamente.

radio_button_uncheckedshort_text13. Microsegmentación y NIC definen el camino de datos

Un diseño sencillo coloca la NVA en una subred perimetral/DMZ y dirige por ella subredes seleccionadas. La microsegmentación separa web, negocio, datos, administración e inspección para controlar tráfico este-oeste. Los dispositivos de capa 4 razonan sobre direcciones, protocolos y puertos; los que comprenden aplicaciones también inspeccionan capa 7.

Algunas NVA usan una NIC de administración y otras para el plano de datos. La arquitectura del proveedor decide qué interfaz recibe, inspecciona y reenvía. Las UDR deben apuntar al frontend privado compatible y el regreso debe respetar el estado del dispositivo.

radio_button_uncheckedshort_text14. Una NVA en la ruta se convierte en dependencia crítica

Si todo flujo permitido depende del appliance, su fallo causa una interrupción de red. Producción necesita el patrón de alta disponibilidad del proveedor: varias instancias en zonas o conjuntos, sondeos de estado, selección resiliente de próximo salto, sincronización de estado cuando corresponda y recuperación automatizada.

La IP privada de un equilibrador interno puede ser próximo salto VirtualAppliance en diseños admitidos. Azure Route Server, Gateway Load Balancer u otros patrones pueden adaptarse a ciertos proveedores. El laboratorio usa una sola VM y no representa producción.

radio_button_uncheckedshort_text15. Topología del laboratorio: tres subredes e inspección en un sentido

Los laboratorios crean la VNet vnet con 10.0.0.0/16. publicsubnet usa 10.0.0.0/24, privatesubnet 10.0.1.0/24 y dmzsubnet 10.0.2.0/24. La NVA usa 10.0.2.4. La ruta productionsubnet envía destinos 10.0.1.0/24 al appliance y la tabla solo se asocia con publicsubnet.

radio_button_uncheckedshort_text16. Laboratorio 1: cree la tabla y la UDR

Ejecútelo solo en una suscripción autorizada. Use un grupo dedicado, sustituya myResourceGroupName, verifique la suscripción activa en Azure Cloud Shell y limpie al terminar. La antigua instrucción de usar el modo “Classic” refleja la interfaz exportada, no un requisito de enrutamiento.

az network route-table create \
  --name publictable \
  --resource-group "myResourceGroupName" \
  --disable-bgp-route-propagation false

az network route-table route create \
  --route-table-name publictable \
  --resource-group "myResourceGroupName" \
  --name productionsubnet \
  --address-prefix 10.0.1.0/24 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.2.4

El primer comando conserva propagación de puerta. El segundo cambia solo destinos de privatesubnet; no envía todo el tráfico de publicsubnet por la NVA.

radio_button_uncheckedshort_text17. Laboratorio 1: cree red, subredes y asociación

az network vnet create \
  --name vnet --resource-group "myResourceGroupName" \
  --address-prefixes 10.0.0.0/16 \
  --subnet-name publicsubnet --subnet-prefixes 10.0.0.0/24

az network vnet subnet create \
  --name privatesubnet --vnet-name vnet \
  --resource-group "myResourceGroupName" \
  --address-prefixes 10.0.1.0/24

az network vnet subnet create \
  --name dmzsubnet --vnet-name vnet \
  --resource-group "myResourceGroupName" \
  --address-prefixes 10.0.2.0/24

az network vnet subnet list \
  --resource-group "myResourceGroupName" \
  --vnet-name vnet --output table

az network vnet subnet update \
  --name publicsubnet --vnet-name vnet \
  --resource-group "myResourceGroupName" \
  --route-table publictable

La lista confirma los CIDR antes de asociar. El update aplica publictable a publicsubnet; privatesubnet conserva rutas del sistema y opcionales, lo que explica la prueba de regreso.

radio_button_uncheckedshort_text18. Laboratorio 2: implemente la NVA Ubuntu

El ejercicio implementa Ubuntu 22.04 LTS en dmzsubnet con azureuser y una contraseña de ejemplo. En un entorno real, prefiera claves SSH, restrinja el origen de administración, no exponga la gestión del appliance directamente a Internet y siga el endurecimiento del proveedor.

az vm create \
  --resource-group "myResourceGroupName" \
  --name nva --vnet-name vnet --subnet dmzsubnet \
  --image Ubuntu2204 --admin-username azureuser \
  --admin-password <password>

radio_button_uncheckedshort_text19. El reenvío debe habilitarse en Azure y en el invitado

La opción de NIC indica a Azure que acepte paquetes cuyo origen o destino no sea la propia NVA. La configuración del sistema hace que Linux actúe como enrutador. Habilitar solo una no basta.

NICID=$(az vm nic list \
  --resource-group "myResourceGroupName" --vm-name nva \
  --query "[].{id:id}" --output tsv)

NICNAME=$(az vm nic show \
  --resource-group "myResourceGroupName" --vm-name nva \
  --nic $NICID --query "{name:name}" --output tsv)

az network nic update --name $NICNAME \
  --resource-group "myResourceGroupName" \
  --ip-forwarding true

NVAIP="$(az vm list-ip-addresses \
  --resource-group "myResourceGroupName" --name nva \
  --query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
  --output tsv)"

ssh -t -o StrictHostKeyChecking=no azureuser@$NVAIP \
  'sudo sysctl -w net.ipv4.ip_forward=1; exit;'

El cambio `sysctl -w` dura hasta reiniciar salvo que se persista. Deshabilitar la comprobación de clave del host es cómodo en un laboratorio desechable, pero no debe copiarse a automatización de producción.

radio_button_uncheckedshort_text20. Laboratorio 3: implemente VM con traceroute

Cree cloud-init.txt para instalar inetutils-traceroute en las dos VM. El ejercicio asigna IP pública para SSH; es una comodidad temporal de aprendizaje, no el diseño recomendado para una capa privada.

cat > cloud-init.txt <<'EOF'
#cloud-config
package_upgrade: true
packages:
  - inetutils-traceroute
EOF

az vm create \
  --resource-group "myResourceGroupName" --name public \
  --vnet-name vnet --subnet publicsubnet --image Ubuntu2204 \
  --admin-username azureuser --no-wait \
  --custom-data cloud-init.txt --admin-password <password>

az vm create \
  --resource-group "myResourceGroupName" --name private \
  --vnet-name vnet --subnet privatesubnet --image Ubuntu2204 \
  --admin-username azureuser --no-wait \
  --custom-data cloud-init.txt --admin-password <password>

watch -d -n 5 "az vm list \
  --resource-group 'myResourceGroupName' --show-details \
  --query '[*].{Name:name,ProvisioningState:provisioningState,PowerState:powerState}' \
  --output table"

Continúe cuando todas indiquen Succeeded y VM running; cierre watch con Ctrl+C. Si traceroute aún no está disponible, cloud-init puede seguir instalándolo: espere y repita.

radio_button_uncheckedshort_text21. Laboratorio 3: trace ambos sentidos y explique la asimetría

PUBLICIP="$(az vm list-ip-addresses \
  --resource-group "myResourceGroupName" --name public \
  --query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
  --output tsv)"

PRIVATEIP="$(az vm list-ip-addresses \
  --resource-group "myResourceGroupName" --name private \
  --query "[].virtualMachine.network.publicIpAddresses[*].ipAddress" \
  --output tsv)"

ssh -t -o StrictHostKeyChecking=no azureuser@$PUBLICIP \
  'traceroute private --type=icmp; exit'

ssh -t -o StrictHostKeyChecking=no azureuser@$PRIVATEIP \
  'traceroute public --type=icmp; exit'

Public-hacia-private muestra 10.0.2.4, la NVA, como primer salto y 10.0.1.4 como segundo. Private-hacia-public va directamente a 10.0.0.4 porque privatesubnet no tiene UDR asociada. Esto demuestra que la tabla actúa en la subred de origen y que el enrutamiento puede ser asimétrico.

Los firewalls con estado suelen exigir simetría. Agregue la UDR inversa apropiada o un diseño simétrico y altamente disponible admitido; de otro modo, el retorno puede eludir el appliance y romper la sesión.

radio_button_uncheckedshort_text22. Respuestas de las comprobaciones de conocimientos

radio_button_uncheckedshort_text23. Diagnóstico y comprobaciones de diseño actuales

• Confirme que la tabla está asociada a la subred de origen y no solo creada.
• Inspeccione rutas efectivas y compruebe que la UDR está Activa y gana por prefijo más largo.
• Confirme que la IP VirtualAppliance es directamente alcanzable y pertenece al frontend admitido.
• Habilite reenvío en las NIC implicadas y en el sistema o configuración del appliance.
• Revise NSG, firewall invitado, política y salud de la NVA, sondeos y rutas de retorno.
• Compruebe que la NVA no está en la misma subred cuya UDR apunta a ella.
• Trate inspección 0.0.0.0/0, salida pública y NAT como requisitos separados.
• Prefiera claves SSH, Azure Bastion o red confiable y NVA altamente disponibles en producción.
• Use próximo salto, diagnóstico de conexión, rutas efectivas y captura de Azure Network Watcher.

radio_button_uncheckedshort_text24. Repaso compacto, recuperación activa y recursos oficiales

Preguntas de recuperación activa

• Reconstruya la tabla de rutas del sistema sin consultarla.
• Elija próximo salto para inspección, descarte, VPN, VNet local e Internet explícita.
• Resuelva un ejemplo con prefijos UDR, BGP y del sistema superpuestos.
• Explique por qué reenvío de NIC no convierte por sí solo Ubuntu en enrutador.
• Prediga ambos traceroute antes de ejecutar el laboratorio.
• Convierta la NVA única en un diseño seguro, simétrico y altamente disponible.

Documentación oficial

• Enrutamiento del tráfico de redes virtuales de Azure
• Tutorial de enrutamiento con una tabla de rutas
• Acceso saliente predeterminado en Azure
• Implementar aplicaciones virtuales de red de alta disponibilidad
• Diagnóstico de próximo salto con Azure Network Watcher