Ref. Examen AZ-700 Diseño e Implementación de Soluciones de Red de Microsoft Azure

Ref.
examen AZ-700 Diseño e

implementación de soluciones de red de
Microsoft Azure
Carlos Pluta
Ref. examen AZ-700 Diseño e implementación de soluciones de red de Microsoft Azure
Publicado con la autorización de Microsoft Corporation por:
Pearson Educación, Inc.
Copyright © 2022 por Pearson Education, Inc.
Reservados todos los derechos. Esta publicación está protegida por derechos de autor, y se
debe obtener el permiso del editor antes de cualquier reproducción, almacenamiento en un
sistema de recuperación o transmisión prohibida en cualquier forma o por cualquier medio,
ya sea electrónico, mecánico, fotocopiado, grabación o similar. Para obtener información
sobre permisos, formularios de solicitud y los contactos apropiados dentro del
Departamento de Permisos y Derechos Globales de Pearson Education,
visite www.pearson.com/permissions .
No se asume ninguna responsabilidad de patente con respecto al uso de la información

contenida en este documento. Aunque se han tomado todas las precauciones en la
preparación de este libro, el editor y el autor no asumen ninguna responsabilidad por
errores u omisiones. Tampoco se asume ninguna responsabilidad por los daños que resulten
del uso de la información aquí contenida.
ISBN-13: 978-0-13-768277-5
ISBN-10: 0-13-768277-8
Número de control de la Biblioteca del Congreso: 2022933634
ScoutAutomatedPrintCode
MARCAS
Microsoft y las marcas comerciales enumeradas en http://www.microsoft.com en la página

web "Marcas comerciales" son marcas comerciales del grupo de empresas Microsoft. Todas
las demás marcas son propiedad de sus respectivos dueños.
ADVERTENCIA Y DESCARGO DE RESPONSABILIDAD
Se ha hecho todo lo posible para que este libro sea lo más completo y preciso posible, pero
no se implica ninguna garantía o idoneidad. La información proporcionada es "tal cual". El
autor, el editor y Microsoft Corporation no tendrán obligación ni responsabilidad ante
ninguna persona o entidad con respecto a cualquier pérdida o daño que surja de la
información contenida en este libro o del uso de los programas que lo acompañan.
VENTAS ESPECIALES
Para obtener información sobre la compra de este título en grandes cantidades o para
oportunidades de ventas especiales (que pueden incluir versiones electrónicas, diseños de
portada personalizados y contenido específico para su negocio, objetivos de capacitación,
enfoque de marketing o intereses de marca), comuníquese con nuestro departamento de
ventas corporativas. en corpsales@pearsoned.com o (800) 382-3419.
Para consultas de ventas gubernamentales, comuníquese con
gobiernosventas@pearsoned.com .
Si tiene preguntas sobre las ventas fuera de los EE. UU., comuníquese con
intlcs@pearson.com .
CRÉDITOS
EDITOR EN JEFE
Brett Bartow
EDITOR EJECUTIVO
Loretta Yates
EDITOR PATROCINADOR
Charvi Arora
REDACTOR DE DESARROLLO
Songlin Qiu
JEFE DE REDACCIÓN
Sandra Schroeder
EDITOR DE PROYECTOS SÉNIOR
Tracey Croom
EDITOR DE COPIA
fiesta de exploradores
INDEXADOR
timoteo wright
CORRECTOR DE PRUEBAS
Servicios editoriales Gill
REDACTOR TÉCNICO
Tomas Palathra
ASISTENTE EDITORIAL
Cindy se tambalea
DISEÑADOR DE LA PORTADA
Torsión creativa, Seattle
COMPOSITOR
códigoMantra
Compromiso de Pearson con la diversidad, la equidad y la inclusión
Pearson se dedica a crear contenido libre de prejuicios que refleje la diversidad de todos los
estudiantes. Aceptamos las muchas dimensiones de la diversidad, incluidas, entre otras, la
raza, el origen étnico, el género, el nivel socioeconómico, la capacidad, la edad, la
orientación sexual y las creencias religiosas o políticas.
La educación es una fuerza poderosa para la equidad y el cambio en nuestro mundo. Tiene
el potencial de brindar oportunidades que mejoran vidas y permiten la movilidad
económica. A medida que trabajamos con autores para crear contenido para cada producto
y servicio, reconocemos nuestra responsabilidad de demostrar inclusión e incorporar
estudios diversos para que todos puedan alcanzar su potencial a través del
aprendizaje. Como empresa de aprendizaje líder en el mundo, tenemos el deber de ayudar a
impulsar el cambio y estar a la altura de nuestro propósito de ayudar a más personas a crear
una vida mejor para sí mismos y crear un mundo mejor.
Nuestra ambición es contribuir decididamente a un mundo donde:
 Todos tienen una oportunidad equitativa y de por vida de tener éxito a través
del aprendizaje.
 Nuestros productos y servicios educativos son inclusivos y representan la
rica diversidad de estudiantes.
 Nuestro contenido educativo refleja con precisión las historias y
experiencias de los estudiantes a los que servimos.
 Nuestro contenido educativo genera debates más profundos con los alumnos
y los motiva a expandir su propio aprendizaje (y visión del mundo).
Si bien trabajamos arduamente para presentar contenido imparcial, queremos escuchar sus
inquietudes o necesidades con respecto a este producto de Pearson para que podamos
investigarlas y abordarlas.
 Comuníquese con nosotros si tiene inquietudes sobre cualquier posible sesgo

en https://www.pearson.com/report-bias.html .
Contenido de un vistazo
Introducción
CAPÍTULO 1 Diseño, implementación y gestión de redes híbridas
CAPÍTULO 2 Diseñar e implementar la infraestructura de red central
CAPÍTULO 3 Diseño e implementación de enrutamiento
CAPÍTULO 4 Redes seguras y monitoreadas
CAPÍTULO 5 Diseñar e implementar el acceso privado a los servicios de Azure

Índice
Contenido
Introducción
Organización de este libro
certificaciones de microsoft
Errata, actualizaciones y soporte de libros
Mantente en contacto
Capítulo 1 Diseñar, implementar y administrar redes híbridas
Habilidad 1.1: Diseñar, implementar y administrar una conexión VPN de sitio a sitio
Diseñe una conexión VPN de sitio a sitio para alta disponibilidad
Seleccione una SKU de puerta de enlace de red virtual adecuada
Identifique cuándo usar una VPN basada en políticas versus una VPN basada en rutas
Crear y configurar una puerta de enlace de red local
Crear y configurar una puerta de enlace de red virtual
Crear y configurar una política IPsec/IKE
Diagnosticar y resolver problemas de conectividad de puerta de enlace VPN
Habilidad 1.2: Diseñar, implementar y administrar una conexión VPN de punto a sitio
Planificar y configurar la autenticación RADIUS
Planificar y configurar la autenticación basada en certificados
Planificar y configurar la autenticación de Azure Active Directory (Azure AD)
Implementar un archivo de configuración de cliente VPN

Diagnosticar y resolver problemas de autenticación y del lado del cliente
Habilidad 1.3: Diseñar, implementar y administrar Azure ExpressRoute
Elija entre proveedor y modelo directo (ExpressRoute Direct)
Diseñe e implemente la conectividad entre regiones de Azure entre varias ubicaciones de

ExpressRoute
Seleccione una SKU y un nivel de ExpressRoute apropiados
Diseñar e implementar ExpressRoute Global Reach
Diseñar e implementar ExpressRoute FastPath
Elija entre emparejamiento privado solo, emparejamiento de Microsoft solo o ambos
Configurar emparejamiento privado
Configurar emparejamiento de Microsoft
Crear y configurar una puerta de enlace de ExpressRoute
Conectar una red virtual a un circuito ExpressRoute
Recomendar una configuración de anuncio de ruta
Configurar el cifrado a través de ExpressRoute
Implementar detección de reenvío bidireccional
Diagnosticar y resolver problemas de conexión de ExpressRoute
Resumen del capítulo
Experimento mental
Respuestas del experimento mental
Capítulo 2 Diseñar e implementar la infraestructura de red central
Habilidad 2.1: Diseñar e implementar direccionamiento IP privado para redes virtuales
Crear una red virtual
Planificar y configurar subredes para servicios

Planificar y configurar la delegación de subredes
Planificar y configurar subredes para Azure Route Server
Habilidad 2.2: Diseñar e implementar la resolución de nombres
Diseñar zonas DNS públicas
Diseñar zonas DNS privadas
Resolución de nombres de diseño dentro de una red virtual
Configurar una zona DNS pública o privada
Vincular una zona DNS privada a una red virtual
Habilidad 2.3: Diseñar e implementar conectividad entre redes virtuales
Implementar emparejamiento de red virtual
Encadenamiento de servicios de diseño, incluido el tránsito de puerta de enlace
Diseñar conectividad VPN entre redes virtuales
Habilidad 2.4: Diseñar e implementar una arquitectura Azure Virtual WAN
Diseñe una arquitectura de Azure Virtual WAN, incluida la selección de SKU y servicios
Crear un concentrador en Virtual WAN
Conectar una puerta de enlace de red virtual a Azure Virtual WAN
Crear un dispositivo virtual de red en un centro virtual
Configurar el enrutamiento del centro virtual
Experimento mental
Capítulo 3 Diseño e implementación de enrutamiento
Habilidad 3.1: Diseñar, implementar y administrar el enrutamiento de redes virtuales

Diseñar e implementar rutas definidas por el usuario
Asociar una tabla de rutas con una subred
Configurar tunelización forzada
Diagnosticar y resolver problemas de enrutamiento
Habilidad 3.2: Diseñar e implementar un equilibrador de carga de Azure
Elija una SKU de Azure Load Balancer
Elige entre público e interno
Crear y configurar un equilibrador de carga de Azure
Implementar una regla de equilibrio de carga
Crear y configurar reglas de NAT de entrada
Crear reglas de salida explícitas para un balanceador de carga
Habilidad 3.3: Diseñar e implementar Azure Application Gateway
Recomendar opciones de implementación de Azure Application Gateway
Elija entre escala manual y automática
Crear un grupo de back-end
Configurar los ajustes de HTTP
Configurar sondeos de estado
Configurar oyentes
Configurar reglas de enrutamiento
Configurar la seguridad de la capa de transporte (TLS)
Configurar políticas de reescritura
Habilidad 3.4: Implementar Azure Front Door
Elija un SKU de Azure Front Door

Configurar la terminación SSL y el cifrado SSL de extremo a extremo
Configurar escuchas multisitio y configurar objetivos de back-end
Habilidad 3.5: Implementar un perfil de Azure Traffic Manager
Configurar un método de enrutamiento
Configurar puntos finales
Crear configuraciones HTTP
Habilidad 3.6: Diseñar e implementar una NAT de Azure Virtual Network
Elija cuándo usar una NAT de red virtual
Asignar direcciones IP públicas para una puerta de enlace NAT
Asociar una red virtual NAT con una subred
Experimento mental
Capítulo 4 Proteger y monitorear redes
Habilidad 4.1: Diseñar, implementar y administrar una implementación de Azure Firewall
Diseñar una implementación de Azure Firewall
Crear e implementar una implementación de Azure Firewall
Configurar reglas de Azure Firewall
Crear e implementar políticas de Azure Firewall Manager
Cree un centro seguro implementando Azure Firewall dentro de un centro de Azure Virtual
WAN
Habilidad 4.2: Implementar y administrar grupos de seguridad de red (NSG)

Crear un grupo de seguridad de red
Asociar un NSG a un recurso
Crear un grupo de seguridad de aplicaciones (ASG)
Asociar un ASG a una NIC
Crear y configurar reglas de NSG
Interpretar y validar registros de flujo de NSG
Verificar el flujo de IP
Habilidad 4.3: Implementar una implementación de Firewall de aplicaciones web (WAF)
Implementar una política WAF
Asociar una política WAF
Habilidad 4.4: Monitorear redes
Configure las alertas de estado de la red y el registro mediante Azure Monitor
Crear y configurar una instancia de Monitor de conexión
Configurar y usar análisis de tráfico
Habilitar y configurar el registro de diagnóstico
Configurar Azure Network Watcher
Experimento mental
Capítulo 5 Diseño e implementación del acceso privado a los servicios de Azure
Habilidad 5.1: Diseñar e implementar el servicio Azure Private Link y puntos de conexión
privados
Crear un servicio de enlace privado
Planificar y crear puntos finales privados

Integrar enlace privado con DNS
Integrar un servicio de Private Link con clientes locales
Habilidad 5.2: Diseñar e implementar puntos finales de servicio
Crear puntos finales de servicio
Configurar políticas de punto final de servicio
Configurar etiquetas de servicio
Habilidad 5.3: Configurar la integración de VNet para servicios de plataforma como servicio
(PaaS) dedicados
Configurar App Service para la integración de VNet regional
Configurar Azure Kubernetes Service (AKS) para la integración de redes virtuales

regionales
Configurar clientes para acceder al entorno de App Service
Experimento mental
Índice
Expresiones de gratitud
Quisiera agradecer a mi esposa, Jennifer, por apoyarme y aguantar las horas extrañas para
terminar este libro. A Elias Mereb y Brian Svidergol, gracias por los años de amistad,
conferencias, cenas y todo lo demás. Y a mis amigos y colegas Ed Gale, Joshua Waddell y
Aaron Lines, gracias por su amistad, tutoría y consejos durante los últimos años. A todos
los profesionales de la nube y lectores de este libro, gracias por tomarse el tiempo de leer,
explorar, aprender, probar y “jugar” con estas tecnologías mientras aprenden. ¡Sigue así, y
buena suerte!
Sobre el Autor
CHARLES PLUTA es consultor técnico y Microsoft Certified Trainer, autor de varios

exámenes de certificación, guías de laboratorio y guías de aprendizaje para varios
proveedores de tecnología. Como consultor técnico, Charles ha ayudado a organizaciones
pequeñas, medianas y grandes a implementar y mantener su infraestructura de TI. También
es orador, miembro del personal o capacitador en varias conferencias importantes de la
industria cada año. Charles tiene una licenciatura en redes informáticas y posee más de 25
certificaciones de la industria. Se asegura de salir de los Estados Unidos para viajar a un
país diferente una vez al año. Cuando no está entrenando o viajando, juega billar en
Augusta, Georgia.
Introducción
Este libro adopta un enfoque de alto nivel de la lista de temas y habilidades que se miden en
el examen Diseño e implementación de soluciones de red de Microsoft Azure (AZ-700),
que se requiere para obtener la certificación Microsoft Certified: Azure Network Engineer
Associate. Este examen se enfoca en temas de redes en Microsoft Azure, pero requiere un
conocimiento adicional del Portal de Azure y los servicios relacionados, como máquinas
virtuales, cuentas de almacenamiento, herramientas de monitoreo y más. Si aún no está
familiarizado con los servicios generales de Azure, le sugiero que comience con Azure
Fundamentals (AZ-900) o Azure Administrator (AZ-104) antes de concentrarse en este
examen.
Este libro proporciona ejemplos paso a paso de la configuración de los servicios de

Azure que se describen en la lista de temas mediante Azure Portal. Sin embargo, el examen
de certificación también podría hacerle preguntas sobre los comandos de PowerShell o CLI
que realizan las mismas acciones que los del portal. Debe usar este libro como
complemento a su viaje de aprendizaje y practicar otros métodos para configurar estos
servicios además de lo que se describe en el libro.
Este libro cubre todas las áreas temáticas principales que se encuentran en el examen,
pero no cubre todas las preguntas del examen. Solo el equipo de examen de Microsoft tiene
acceso a las preguntas del examen, y Microsoft agrega regularmente nuevas preguntas al
examen, lo que hace imposible cubrir preguntas específicas. Debe considerar este libro
como un complemento a su experiencia relevante del mundo real y otros materiales de
estudio. Si encuentra un tema en este libro con el que no se siente completamente cómodo,
use la opción "¿Necesita más revisión?" enlaces que encontrará en el texto para encontrar
más información, y tómese el tiempo para investigar y estudiar el tema. Hay excelente
información disponible en MSDN, en TechNet y en blogs y foros.
Organización de este libro
Este libro está organizado por la lista de "Habilidades medidas" publicada para el
examen. La lista de "Habilidades medidas" está disponible para cada examen en el sitio
web de Microsoft Learn: http://aka.ms/examlist . Cada capítulo de este libro corresponde a
un área temática importante de la lista, y las tareas técnicas de cada área temática
determinan la organización de un capítulo. Si un examen cubre seis áreas temáticas
principales, por ejemplo, el libro contendrá seis capítulos.
certificaciones de microsoft
Las certificaciones de Microsoft lo distinguen al demostrar su dominio de un amplio

conjunto de habilidades y experiencia con los productos y tecnologías actuales de
Microsoft. Los exámenes y las certificaciones correspondientes se desarrollan para validar
su dominio de las competencias críticas a medida que diseñay desarrollar, o implementar y
brindar soporte, soluciones con productos y tecnologías de Microsoft tanto en las
instalaciones como en la nube. La certificación trae una variedad de beneficios para el
individuo y para los empleadores y organizaciones.
¿NECESITA MÁS REVISIÓN? TODAS

LAS CERTIFICACIONES DE
MICROSOFT
Para obtener información sobre las certificaciones de Microsoft, incluida una lista completa
de las certificaciones disponibles, visite http://www.microsoft.com/learn .
¡Vuelve a menudo para ver qué hay de nuevo!
Errata, actualizaciones y soporte de libros
Hemos hecho todo lo posible para garantizar la precisión de este libro y el contenido que lo
acompaña. Puede acceder a las actualizaciones de este libro, en forma de una lista de
erratas enviadas y sus correcciones relacionadas, en:
MicrosoftPressStore.com/ExamRefAZ700/errata
Si descubre un error que no figura en la lista, envíenoslo en la misma página.
Para obtener ayuda e información adicional sobre libros, visite
MicrosoftPressStore.com/Support
Tenga en cuenta que el soporte de productos para software y hardware de Microsoft no

se ofrece a través de las direcciones anteriores. Para obtener ayuda con el software o el
hardware de Microsoft, vaya a http://support.microsoft.com .
Mantente en contacto
¡Sigamos con la conversación! Estamos en Twitter: http://twitter.com/MicrosoftPress .

Capítulo 1
Diseñar, implementar y administrar redes híbridas
En este capítulo se presentan los recursos y las herramientas que puede usar para
implementar redes híbridas con Azure. Esto gira principalmente en torno a puertas de
enlace de red virtual para VPN de sitio a sitio y de punto a sitio, y ExpressRoute para
conectividad privada y dedicada desde su ubicación local a una región de Azure.
Habilidades en este capítulo:
 Habilidad 1.1: Diseñar, implementar y administrar una conexión VPN de

sitio a sitio
 Habilidad 1.2: Diseñar, implementar y administrar una conexión VPN de
punto a sitio
 Habilidad 1.3: Diseñar, implementar y administrar Azure ExpressRoute
Habilidad 1.1: Diseñar, implementar y administrar una conexión VPN de sitio a sitio
Las redes privadas virtuales (VPN) han sido durante mucho tiempo una forma de
proporcionar conectividad segura a través de Internet entre dos ubicaciones. La
conectividad híbrida mediante una VPN se puede lograr mediante una puerta de enlace de
red virtual en su suscripción de Azure. El uso de una puerta de enlace de red virtual
también requiere que configure una puerta de enlace de red local. Los diversos tipos de
conexión y la configuración de estas puertas de enlace se analizan en esta sección de
habilidades.
ESTA HABILIDAD CUBRE CÓMO:

 Diseñe una conexión VPN de sitio a sitio para alta disponibilidad
 Seleccione una SKU de puerta de enlace de red virtual adecuada
 Identifique cuándo usar una VPN basada en políticas versus una VPN
basada en rutas
 Crear y configurar una puerta de enlace de red local
 Crear y configurar una puerta de enlace de red virtual
 Crear y configurar una política IPsec/IKE
 Diagnosticar y resolver problemas de conectividad de puerta de enlace VPN
Diseñe una conexión VPN de sitio a sitio para alta disponibilidad
De forma predeterminada, cuando implementa una puerta de enlace de VPN de Azure, hay
dos instancias de la puerta de enlace configuradas en una configuración activa/en
espera. Esta instancia en espera proporciona cierta redundancia, pero no tiene una alta
disponibilidad, ya que la segunda instancia puede tardar unos minutos en conectarse y
volver a conectarse al destino de la VPN. Para este nivel más bajo de redundancia, puede
elegir si la VPN tiene redundancia regional o redundancia de zona. Si elige usar una
dirección IP pública básica , la VPN que configure solo puede tener redundancia
regional. Si necesita una configuración con redundancia de zona, debe usar una dirección
IP pública estándar con la puerta de enlace VPN. Figura 1-1muestra una implementación
simple con una sola puerta de enlace de VPN de Azure implementada, lo que da como
resultado una instancia en espera en la misma región.
FIGURA 1-1 Una puerta de enlace VPN conectada a un dispositivo de puerta de enlace
local
Si prefiere que la puerta de enlace de VPN en la región de Azure tenga redundancia de

zona, cuando la configure con una dirección IP pública estándar, también tendrá la opción
de elegir las zonas en las que desea implementar la instancia. a. La Figura 1-2 muestra el
diseño de una configuración con redundancia de zona. Como alternativa, también puede
optar por implementar ambas instancias en la misma zona para una configuración de puerta
de enlace zonal (zona única).
FIGURA 1-2 Una puerta de enlace VPN con redundancia de zona conectada a un
dispositivo de puerta de enlace local
Si bien los escenarios anteriores pueden proporcionar cierta redundancia, no se

considerarían de alta disponibilidad. Habría una cierta cantidad de tiempo de inactividad en
minutos para que las puertas de enlace de VPN de Azure conmutaran por error entre las
instancias activa y en espera. También hay un único punto de falla con los únicos
dispositivos de puerta de enlace locales para ese lado de la conexión. La Figura 1-3 mejora
esta configuración al agregar dos dispositivos de puerta de enlace para la red local. Sin
embargo, el lado de Azure solo tiene redundancia en lugar de alta disponibilidad.
FIGURA 1-3 Una puerta de enlace VPN conectada a dos dispositivos de puerta de enlace
locales
NOTA ESCENARIOS PRESENTADOS

Los escenarios y los pasos que se enfocan en las instalaciones como el destino objetivo
en este capítulo no son las únicas formas de configurar una VPN. Se puede usar una
VPN para conectar dos redes virtuales, una red virtual a una ubicación local, una red
virtual a otra nube pública o una organización de proveedor/socio.
En esta configuración, el tráfico de red es a través de ambas conexiones activas

simultáneamente. Si bien el beneficio principal es la redundancia, también puede ver un
pequeño aumento en el rendimiento al crear un túnel adicional para que el tráfico
atraviese. Al introducir dos conexiones activas, hay otras consideraciones y requisitos que
se deben cumplir para que esto se implemente correctamente. Estos requisitos incluyen:
 La puerta de enlace de VPN de Azure debe tener dos conexiones

independientes definidas como parte de la configuración mediante la misma puerta
de enlace de red local que representa la red local. Las puertas de enlace de la red
local se analizarán con más detalle más adelante en esta sección de habilidades.
 Las puertas de enlace de la red local asociadas con las puertas de enlace de
VPN de Azure deben tener direcciones IP públicas únicas para la
propiedad GatewayIpAddress , así como una dirección IP del mismo nivel BGP
única para la propiedad BgpPeerIpAddress .
 Las rutas anunciadas por los pares BGP deben usar los mismos prefijos de
dirección para las redes locales, con el tráfico reenviado a través de cada túnel
simultáneamente.
 El método de enrutamiento entre sitios debe configurarse como rutas
múltiples de igual costo (ECMP).
 Cada conexión definida en Azure VPN Gateway cuenta para la cantidad
máxima de túneles admitidos por la SKU que seleccione. Los SKU de puerta de
enlace VPN se analizan en el siguiente tema de esta sección de habilidades.
Lo mejor de ambos mundos sería configurar la redundancia en ambos lados de la

VPN. En este caso, sería implementar dos dispositivos de puerta de enlace en las
instalaciones, así como dos instancias de puerta de enlace VPN de Azure en su región de
Azure. Los requisitos anteriores también se aplican a esta configuración. Con dos instancias
activas cada una con dos conexiones, habrá cuatro túneles VPN en total entre los
sitios. Debido a que se requiere ECMP, el tráfico de red se distribuirá entre las cuatro
conexiones activas. La Figura 1-4 muestra esta configuración activo/activo. Cuando se
combina como una configuración con redundancia de zona, da como resultado la mejor
configuración de alta disponibilidad para una única región de Azure.
FIGURA 1-4 Dos puertas de enlace VPN conectadas a dos dispositivos de puerta de enlace
locales
¿NECESITA MÁS REVISIÓN? VPN DE

ALTA DISPONIBILIDAD
Para obtener más información sobre la implementación de VPN de alta
disponibilidad, visite https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-
gateway-highlydisponible .
Cuando implementa una puerta de enlace de VPN de Azure, una de las opciones necesarias
es seleccionar la SKU de la puerta de enlace. Este SKU determina la cantidad máxima de
túneles, conexiones, rendimiento de la red y si se admiten BGP y redundancia de
zona. Dependiendo de si selecciona una configuración activa/en espera o activa/activa, eso
puede limitar qué SKU puede implementar para implementar esa configuración. La Tabla
1-1 enumera los diversos SKU entre las generaciones de VPN con las métricas compatibles
relevantes al momento de escribir este artículo.
TABLA 1-1 SKU de puerta de enlace de red virtual

Número
máximo Punto de
Implementación
de referencia Soporte
Generación SKU con redundancia
túneles de BGP
de zona
de sitio rendimiento
a sitio
Generación1 Básico 10 100Mbps No No
Generación1 VpnGw1 30 650Mbps Sí No
Generación1 VpnGw2 30 1 Gbps Sí No
Generación1 VpnGw3 30 1,25 Gbps Sí No
Generación1 VpnGw1AZ 30 650Mbps Sí Sí
Generación1 VpnGw2AZ 30 1 Gbps Sí Sí
Generación1 VpnGw3AZ 30 1,25 Gbps Sí Sí
Generación2 VpnGw4 30 5 Gbps Sí No
Generación2 VpnGw5 30 10 Gb/s Sí No
Generación2 VpnGw4AZ 30 5 Gbps Sí Sí
Generación2 VpnGw5AZ 30 10 Gb/s Sí Sí

CONSEJO DE EXAMEN
Las preguntas del examen generalmente no evalúan la memorización o la comparación
entre SKU. Sin embargo, las diferencias fundamentales entre generaciones o los mínimos y
máximos admitidos pueden ser preguntas frecuentes en los exámenes.
Tenga en cuenta que, en general, la diferencia entre generaciones es que Generation1

tiene un rendimiento máximo de 1,25 Gbps y Generation2 ofrece al menos 1,25 Gbps de
rendimiento. BGP es compatible con todos los SKU, excepto Básico. La cantidad máxima
de conexiones por puerta de enlace VPN está limitada a 30. Si necesita configurar más de
30 conexiones separadas, debe usar Virtual WAN. La WAN virtual se analiza con más
detalle en la sección de habilidades 2.4 . Finalmente, puede cambiar el tamaño a un SKU
diferente, siempre que sea dentro de la misma generación.
¿NECESITA MÁS REVISIÓN? SKU DE

VPN
Para obtener más información sobre cada SKU de puerta de enlace de VPN,
visite https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-
highlydisponible .
Identifique cuándo usar una VPN basada en políticas versus una VPN basada en rutas
El principal punto a tener en cuenta para elegir una opción basada en directivas o basada en
rutas es simplemente el proveedor, el tipo de dispositivo y la versión del sistema operativo
del dispositivo remoto que planea conectar a la puerta de enlace de VPN de Azure.
La diferencia básica entre los dos tipos de configuración es que la política utiliza rutas
estáticas basadas en prefijos de direcciones. Por lo tanto, cada subred debe incluirse en la
configuración de VPN. Las VPN basadas en rutas utilizan una tabla de rutas para dirigir los
paquetes de red a la conexión de túnel adecuada. La interfaz individual luego realiza el
cifrado o descifrado utilizando comodines como selector de tráfico.
¿NECESITA MÁS
REVISIÓN? DISPOSITIVOS VPN
VALIDADOS
Para obtener más información sobre la implementación de VPN de alta
disponibilidad, visite https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-
gateway-about-vpn-devices .
Crear y configurar una puerta de enlace de red local
Una puerta de enlace de red local puede ser confusa según el nombre. Debido a que está
realizando la configuración desde Azure, puede parecer que la puerta de enlace de la red
local representa su red de Azure de alguna manera. Sin embargo, la puerta de enlace de la
red local es un recurso que crea en Azure, pero es un objeto lógico que representa la red
local a la que se conecta.
Para crear una puerta de enlace de red local en su suscripción de Azure, siga estos pasos:
1. Inicie sesión en Azure Portal en https://portal.azure.com .

2. En la barra de búsqueda, busque puertas de enlace de red local y, a
continuación, seleccione el resultado Puertas de enlace de red local .
3. En la página de puertas de enlace de la red local, haga clic en Crear .
4. En el campo Nombre, proporcione un nombre para mostrar para la puerta de
enlace VPN, como onprem_network .
5. Para alternar el punto final, seleccione si especificará una dirección IP o un
nombre de dominio completo (FQDN) para la conexión local. Esto representará la
IP pública o el nombre de su dispositivo local. Para este ejemplo, dejaremos
seleccionado el punto final predeterminado, la dirección IP .
6. En el campo de dirección IP, ingrese la dirección IP pública del dispositivo
local al que planea conectarse.
7. En el campo Espacio de direcciones, ingrese los rangos de direcciones que
representan el esquema de direcciones IP internas del entorno local.
8. Si es necesario, seleccione Configurar ajustes de BGP y proporcione el ID
de par de BGP. Esto es necesario si planea implementar una implementación de alta
disponibilidad con varias puertas de enlace de VPN. Para este ejemplo, dejaremos el
valor predeterminado de borrado .
9. En el menú desplegable Suscripción, seleccione la suscripción a la que se
asociará el recurso.
10. En el menú desplegable Grupo de recursos, seleccione o cree un grupo de
recursos para que se asigne la puerta de enlace de la red local.
11. En el menú desplegable Ubicación, seleccione la región de Azure con la que
asociar la puerta de enlace de la red local. Una recomendación de mejores prácticas
es colocar esto en la misma región que su red virtual y puerta de enlace VPN, pero
esto no es obligatorio. Para este ejemplo, seleccione Este de EE. UU .
12. Haz clic en Crear .
La Figura 1-5 muestra la configuración completa de la puerta de enlace de la red

local. Si elige FQDN en lugar de usar una dirección IP, Azure actualmente requiere que el
nombre se resuelva en una dirección IPv4; IPv6 no es compatible. Además, si DNS
devuelve varias direcciones IP, Azure VPN Gateway intentará conectarse solo a la primera
dirección IP que se devuelva. No puede crear una conexión redundante a varias direcciones
IP mediante DNS.
FIGURA 1-5 Configuración de la puerta de enlace de la red local
Crear y configurar una puerta de enlace de red virtual
La puerta de enlace de red virtual es el principal recurso de Azure que crea para
comunicarse con el destino. El recurso de puerta de enlace usa la puerta de enlace de la red
local de la sección anterior y se asocia con una red virtual en Azure. Combinado con la
política IPsec/IKE que se analiza en la siguiente sección, esto define las características de la
VPN.
Como parte de la creación de la puerta de enlace de red virtual, debe seleccionar una red
virtual con la que asociar la puerta de enlace. Esta red virtual debe tener espacio de
direcciones disponible para crear una subred adicional y dedicada específicamente para la
puerta de enlace, denominada GatewaySubnet .
Para crear un recurso de puerta de enlace de red virtual, siga estos pasos:

2. En la barra de búsqueda, busque puertas de enlace de red virtual y, a
continuación, seleccione el resultado Puertas de enlace de red virtual .
4. En el menú desplegable Suscripción, seleccione la suscripción con la que
asociar la puerta de enlace.
5. En el campo Nombre, ingrese un nombre para mostrar para el recurso de la
puerta de enlace, como vpn_to_onprem .
6. En el menú desplegable Región, seleccione la misma región que su red
virtual. Para este ejemplo, seleccione Este de EE. UU .
7. Para el tipo de puerta de enlace, seleccione VPN .
8. Para el tipo de VPN, seleccione Basado en ruta .
9. Para SKU, seleccione un SKU apropiado para su escenario. En este ejemplo,
seleccione VpnGw2 .
10. Para Generación, seleccione Generación2 .
11. Para Red virtual, seleccione una red virtual que esté definida en su
suscripción de Azure o cree una nueva.
12. Para el rango de direcciones de la subred de la puerta de enlace, ingrese un
rango de direcciones en notación CIDR que esté disponible en la red virtual que
seleccionó o creó. Por ejemplo, ingrese 10.0.255.0/24 . Este rango se usará para
crear GatewaySubnet en la red virtual.
13. Para la dirección IP pública, seleccione Crear nuevo y luego ingrese un
nombre como vpn_pip para el nombre.
14. Si planea usar el modo activo/activo y/o BGP, habilítelos aquí. Para este
ejemplo, acepte el valor predeterminado de Disabled .
15. Haga clic en Revisar y crear y, a continuación, haga clic en Crear . La
Figura 1-6 muestra una pantalla de creación completa basada en la configuración
utilizada en estos pasos.
FIGURA 1-6 Configuración de puerta de enlace de red virtual
La creación del recurso de puerta de enlace en sí no es el único paso necesario para crear
la conexión VPN al entorno local. Una vez implementada la puerta de enlace, también debe
configurar una conexión que esté asociada con la puerta de enlace de la red local.
Para crear una conexión, siga estos pasos:

1. Si es necesario, inicie sesión en Azure Portal en https://portal.azure.com y
navegue hasta el recurso de puerta de enlace que implementó.
2. En la puerta de enlace de red virtual, haga clic en la hoja Conexiones .
3. En la página Conexiones, haga clic en Agregar .
4. En el campo Nombre, proporcione un nombre para la conexión. Para este
ejemplo, use azure_to_onprem .
5. En el menú desplegable Tipo de conexión, seleccione Sitio a sitio (IPsec) .
6. Para Puerta de enlace de red virtual, seleccione la puerta de enlace que
configuró anteriormente. Siguiendo estos pasos, y si solo tienes una puerta de
enlace, la selección se realizará automáticamente.
7. Para Puerta de enlace de red local, haga clic en el campo y luego seleccione
la puerta de enlace de red local vpn_to_onprem que se configuró en la sección
anterior. La Figura 1-7 muestra la puerta de enlace de la red local creada
anteriormente.
FIGURA 1-7 Selección de la puerta de enlace de la red local
8. En el campo Clave compartida (PSK), ingrese una cadena de caracteres para

asegurar el túnel. Ambos extremos del túnel VPN deben usar la misma clave. Para
este ejemplo, use abcd1234 .
9. Deje el valor predeterminado deshabilitado para Usar la dirección IP
privada de Azure y Habilitar BGP.
10. Para el protocolo IKE, deje el valor predeterminado de IKEv2 .
11. Haga clic en Aceptar para crear la conexión. La Figura 1-8 muestra la
configuración de conexión completa.
FIGURA 1-8 Configuración de la conexión de la puerta de enlace
Inicialmente, la conexión puede mostrar un estado de No conectado hasta que configure

el lado de destino de la VPN o personalice la política que se usa para completar el
túnel. Ambos temas se tratan en las siguientes secciones de esta sección de habilidades. La
Figura 1-9 muestra la puerta de enlace VPN configurada, pero no conectada.
Tenga en cuenta que cuando está configurando la conexión, hay un menú desplegable
Tipo de conexión que tiene tres opciones para configurar una conexión:
 Red virtual a red virtual

 Sitio a sitio (IPsec)
 ExpressRoute
La misma puerta de enlace de red virtual se puede usar para crear varios tipos de
conexión, incluido el punto a sitio. El punto a sitio se cubre en detalle en la sección de
habilidades 1.2 .
Se usa una puerta de enlace de red virtual a red virtual cuando el emparejamiento de red
no es posible o no se desea para los requisitos de cifrado. La misma puerta de enlace de red
virtual también se usa para configurar un circuito ExpressRoute, que proporciona una
conexión dedicada a un entorno local. ExpressRoute se trata en la sección de habilidades
1.3 .
FIGURA 1-9 Conexiones VPN configuradas
Crear y configurar una política IPsec/IKE
Si completó los pasos para configurar una puerta de enlace de red local, una puerta de
enlace de red virtual y una conexión, es posible que haya esperado tener que configurar los
parámetros IKE como parte de la conexión del túnel VPN. Sin embargo, Azure usa un
conjunto predeterminado de parámetros IKE, dependiendo de si configuró un tipo de puerta
de enlace basada en políticas o en rutas. La tabla 1-2 contiene los parámetros
predeterminados de la fase 1 para el protocolo de enlace IKE.
TABLA 1-2 Parámetros predeterminados de la fase 1 de IKE
Propiedad Basado en políticas basado en ruta
versión IKE IKEv1 IKEv1 o IKEv2
Grupo Diffie-Hellman Grupo 2 (1024 bits) Grupo 2 (1024 bits)

(DH)
Método de autentificación Clave precompartida Clave precompartida
Algoritmos de cifrado y  AES256,  AES256,

hash SHA256 SHA1
 AES256,  AES256,
SHA1 SHA256
 AES128,  AES128,
SHA1 SHA1
 3DES,  AES128,
SHA1 SHA256
 3DES,
SHA1
 3DES,
SHA256
Duración de la asociación 28.800 segundos 28.800 segundos

de seguridad (SA)
La tabla 1-3 contiene los parámetros predeterminados de la fase 2 para el protocolo de

enlace IKE.
TABLA 1-3 Parámetros predeterminados de la fase 2 de IKE
Propiedad Basado en políticas basado en ruta
versión IKE IKEv1 IKEv1 o IKEv2
Algoritmos de  AES256, Varía según si Azure Gateway es el

cifrado y hash SHA256 iniciador o el que responde
 AES256,
SHA1
 AES128,
SHA1
 3DES,
SHA1
Vida útil de SA 3600 segundos 27.000 segundos

(Tiempo)
Vida útil de SA 102.400.000 KB 102.400.000 KB

(bytes)
Perfect Forward No Solo si Azure Gateway es el

Secrecy (PFS) respondedor; luego varía según el
método de encriptación
Detección de No Sí
pares muertos
(DPD)
Si necesita personalizar alguna de estas configuraciones para el protocolo de enlace

IKE, debe crear una política IKE personalizada. La Tabla 1-4 contiene los parámetros
admitidos para configurar la política IKE de la VPN.
TABLA 1-4 Parámetros admitidos para la política IKE
Parámetro Opciones admitidas
Cifrado IKE AES256, AES192, AES128, 3DES, DES

integridad IKE SHA384, SHA256, SHA1, MD5
Grupo DH DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048,

DHGroup2, DHGroup1, Ninguno
Cifrado IPsec GCMAES256 * , GCMAES192 * , GCMAES128 * , AES256,

AES192, AES128, 3DES, DES, Ninguno
Integridad IPsec GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Grupo PFS PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, Ninguno
Vida útil QM SA Opcional: se utilizan valores predeterminados si no se especifican
Segundos mínimo 300, predeterminado 27000
KBytes mínimo 1024, predeterminado 102400000
Selector de Verdadero Falso

tráfico
Falso es predeterminado si no se especifica
tiempo de espera Segundos, 9-3600, predeterminado 45

DPD
* Si selecciona GCMAES para el cifrado de IPsec, debe seleccionar el mismo algoritmo

GMCAES y la misma longitud de clave para la integridad de IPsec.
Se puede crear una política IKE personalizada para cada conexión que defina para una
puerta de enlace de red virtual. Para crear una política personalizada, siga estos pasos:

2. En la puerta de enlace de red virtual, haga clic en la hoja Conexiones .
3. Haga clic en el nombre de la conexión que se creó anteriormente. Por
ejemplo, haga clic en azure_to_onprem .
4. Desde la conexión, haga clic en la hoja Configuración .
5. En la política IPsec/IKE, cambie el botón a Personalizado .
6. Utilice los campos desplegables y de entrada para completar la política
personalizada, seleccionando las opciones admitidas que se encuentran en la Tabla
1-4 y luego haga clic en Guardar .
La Figura 1-10 muestra una configuración personalizada de la política IKE.
FIGURA 1-10 Política IKE personalizada

Diagnosticar y resolver problemas de conectividad de puerta de enlace VPN
Cuando está solucionando problemas de conectividad, los primeros pasos son verificar la
configuración existente y asegurarse de que coincida con la configuración del dispositivo
local o de destino. Los desajustes más comunes podrían ser:
 Clave precompartida
 Direcciones IP de pares
 Coincidencia de subredes, si se usa basado en políticas
 Política de IKE
Además de las opciones de configuración, debe verificar que la instancia de puerta de

enlace de red virtual de Azure esté en funcionamiento. La forma más fácil de verificar esto
es comprobando el sondeo de estado de la puerta de enlace de red virtual. Para comprobar
el sondeo de estado, vaya a https://<VirtualNetworkGatewayPublicIP>:8081/healthprobe .
Si la instancia está en funcionamiento, debe devolver una línea de XML con los detalles
de la instancia y el número de versión. Según la configuración de su navegador, es posible
que deba aceptar la advertencia del certificado antes de que se muestre el sondeo de
estado. La figura 1-11 muestra los resultados de una puerta de enlace de red virtual en buen
estado.
FIGURA 1-11 Sonda de estado de puerta de enlace de red virtual
También puede solucionar el estado de una conexión mediante las funciones de registro
de la puerta de enlace de red virtual. Esto requiere que el proveedor de recursos
de Microsoft.Insights esté registrado con la suscripción. Para registrar el proveedor, siga
estos pasos:
1. Si es necesario, inicie sesión en Azure Portal en https://portal.azure.com .

2. En la barra de búsqueda, busque suscripciones y luego seleccione el
resultado Suscripciones .
3. En la página Suscripciones, seleccione la suscripción en la que desea
registrar el proveedor.
4. En la página de suscripción individual, haga clic en la hoja Proveedores de
recursos .
5. Busque y seleccione el proveedor de Microsoft.Insights y luego haga clic
en Registrarse . Esto puede tardar de 5 a 10 minutos en completarse. La Figura 1-
12 muestra el resultado antes de hacer clic en Registrar.
FIGURA 1-12 Proveedor de recursos Microsoft.Insights

Una vez registrado el proveedor, necesitará un espacio de trabajo de análisis de registros
para usar las herramientas de consulta integradas para buscar en los registros. Para crear un
espacio de trabajo de análisis de registros, siga estos pasos:
1. Si es necesario, inicie sesión en Azure Portal en https://portal.azure.com .

2. En la barra de búsqueda, busque el área de trabajo de Log Analytics y
luego seleccione el resultado Áreas de trabajo de Log Analytics .
3. En la página de áreas de trabajo de Log Analytics, haga clic en Crear .
4. Seleccione la suscripción y el grupo de recursos adecuados para crear el
recurso.
5. Para el campo Nombre, ingrese un nombre para el recurso, como LA-
workspace01 .
6. Seleccione la región deseada, idealmente la misma que los otros recursos
que ha implementado. Para este ejemplo, seleccione Este de EE. UU .
7. Haga clic en Revisar + Crear y, a continuación, haga clic en Crear . La
Figura 1-13 muestra la pantalla de revisión con los ajustes configurados.
FIGURA 1-13 Implementación del área de trabajo de Log Analytics
Después de implementar Log Analytics, puede usar la función de consulta para buscar
en los registros de diagnóstico de puerta de enlace de red virtual. Los datos del registro de
diagnóstico se capturan y almacenan en el área de trabajo de Log Analytics como un
repositorio y luego se consultan mediante el lenguaje de consulta de Kusto (KQL). Para
habilitar el registro de diagnóstico y utilizar la herramienta de consulta KQL, siga estos
pasos:

2. En la puerta de enlace de red virtual, haga clic en la hoja Registro de
actividad .
3. En la página Registro de actividad, haga clic en Configuración de
diagnóstico , como se muestra en la Figura 1-14 .
FIGURA 1-14 Registro de actividad de puerta de enlace de red virtual
4. En la página Configuración de diagnóstico, haga clic en Agregar

configuración de diagnóstico .
5. Proporcione un nombre para la configuración de diagnóstico,
como LogCapture .
6. Para seleccionar las categorías que desea capturar para el registro, seleccione
la casilla de verificación junto al nombre de la categoría,
como ServiceHealth , Alert , Policy y ResourceHealth .
7. Seleccione la casilla de verificación junto a Enviar al área de trabajo de
Log Analytics y luego seleccione el área de trabajo que implementó
anteriormente. La Figura 1-15 muestra la configuración completa.
FIGURA 1-15 Diagnóstico de puerta de enlace de red virtual
8. Haga clic en Guardar .

9. Vuelva a navegar a la puerta de enlace de la red virtual y luego seleccione
la hoja Registros .
10. En el selector de consultas, ubique una consulta de KQL deseada para
ejecutarla con los datos de diagnóstico recopilados. Por ejemplo, en VPN Gateway,
seleccione Cargar en el editor para los eventos de conexión/desconexión del túnel
S2S.
11. El siguiente KQL se completará automáticamente en el editor. Si conectó
correctamente una VPN, haga clic en Ejecutar .
Haga clic aquí para ver la imagen del código
AzureDiagnósticos
donde TimeGenerated > ago(24h)
donde Categoría == "TunnelDiagnosticLog" y (status_s == "Conectado" o
status_s ==
"Desconectado")
proyecto TimeGenerated, Resource, status_s, remoteIP_s,
stateChangeReason_s
Otra forma de solucionar problemas de conectividad de una VPN es utilizar la

herramienta de resolución de problemas de VPN de Network Watcher. Esto requiere que se
cree una cuenta de almacenamiento para almacenar los registros mientras se ejecuta el
solucionador de problemas. Para configurar y utilizar la herramienta de solución de
problemas de VPN, siga estos pasos:

2. En la puerta de enlace de red virtual, haga clic en la hoja de solución
de problemas de VPN .
3. En la página de solución de problemas de VPN, haga clic en Seleccionar
cuenta de almacenamiento .
4. Seleccione una cuenta de almacenamiento existente o use el botón + Cuenta
de almacenamiento para crear una nueva.
5. En la cuenta de almacenamiento, cree o seleccione un contenedor de blobs
existente para almacenar los datos de solución de problemas.
6. Después de seleccionar la cuenta de almacenamiento y el contenedor,
seleccione la casilla de verificación junto a la conexión que necesita solucionar y
luego haga clic en Iniciar solución de problemas . La Figura 1-16 muestra la
configuración deseada. (Este proceso puede tardar unos minutos en ejecutarse para
recopilar los datos relevantes de la conexión).
FIGURA 1-16 Solución de problemas de VPN
7. Desde Azure Portal, vaya a la cuenta de almacenamiento que seleccionó

para los datos de solución de problemas.
8. Desde la cuenta de almacenamiento, haga clic en Explorador de
almacenamiento (versión preliminar) .
9. En Storage Explorer, expanda Contenedores de blobs y luego expanda el
nombre del contenedor que seleccionó.
10. Cuando la herramienta de solución de problemas se haya completado, un
archivo ZIP comprimido estará disponible a través de la estructura de carpetas para
descargarlo desde el contenedor de blobs. Seleccione el archivo y luego haga clic
en Descargar y haga clic en la flecha de descarga. Consulte la Figura 1-17 .
FIGURA 1-17 Solución de problemas de descarga de archivos
11. Abra el archivo ConnectionStats.txt dentro de la carpeta comprimida para

ver una descripción general del estado. El siguiente es un extracto del archivo que
muestra el error general.
Estado de conectividad: no conectado

Paquetes de ingreso descartados debido a una discrepancia en el
selector de tráfico (desde la última conexión): 0
Paquetes
Paquetes de salida descartados debido a una discrepancia en el
selector de tráfico (desde la última conexión): 0
Paquetes
12. El mensaje de error "cayó debido a una discrepancia del selector de tráfico"
indicaría una discrepancia de configuración en al menos un lado de la conexión
VPN.
Habilidad 1.2: Diseñar, implementar y administrar una conexión VPN de punto a sitio
Las puertas de enlace de red virtual se pueden usar para conectar ubicaciones de sitio a sitio
con IPsec, así como conexiones distribuidas que usan una variedad de tipos de conexión y
métodos de autenticación. Estas conexiones distribuidas son conexiones de punto a sitio
que permiten que varios dispositivos cliente accedan de forma segura a los recursos de
Azure a través de una VPN. En esta sección de habilidades, analizamos las diversas
opciones para los tipos de conexión y los métodos de autenticación que están disponibles
con las puertas de enlace de red virtual y las configuraciones de punto a sitio.
 Seleccione una SKU de puerta de enlace de red virtual adecuada
 Planificar y configurar la autenticación RADIUS
 Planificar y configurar la autenticación basada en certificados
 Planificar y configurar la autenticación de Azure Active Directory (Azure
AD)
 Implementar un archivo de configuración de cliente VPN
 Diagnosticar y resolver problemas de autenticación y del lado del cliente
NOTA LISTA DE OBJETIVOS

El dominio objetivo para el examen también menciona "Planificar y configurar la
autenticación OpenVPN". Sin embargo, OpenVPN es un tipo de conexión, no un
método de autenticación. Los ejemplos de este capítulo usan OpenVPN. Sin embargo,
tenga en cuenta otros tipos de conexión y métodos de autenticación definidos en la
lista de objetivos.
Cuando planea implementar una puerta de enlace de VPN de Azure para conexiones de
punto a sitio, usa la misma puerta de enlace de red virtual que se implementa cuando planea
una VPN de sitio a sitio. La Tabla 1-5 se parece mucho a la Tabla 1-1 anterior en este
capítulo, pero se enfoca en los máximos de conexión de punto a sitio. Tenga en cuenta que
el rendimiento comparativo es una cantidad combinada en el escenario en el que usa
métodos de conexión de punto a sitio y de sitio a sitio con la misma puerta de enlace de red
virtual.
TABLA 1-5 Máximos de puerta de enlace de red virtual
Máximo de Máximo de Punto de

Generación SKU conexiones conexiones P2S referencia de
P2S SSTP IKEv2/OpenVPN rendimiento
Generación1 Básico 128 No soportado 100Mbps
Generación1 VpnGw1 128 250 650Mbps
Generación1 VpnGw2 128 500 1 Gbps
Generación1 VpnGw3 128 1,000 1,25 Gbps

Máximo de Máximo de Punto de
Generación SKU conexiones conexiones P2S referencia de
P2S SSTP IKEv2/OpenVPN rendimiento
Generación1 VpnGw1AZ 128 250 650Mbps
Generación1 VpnGw2AZ 128 500 1 Gbps
Generación1 VpnGw3AZ 128 1,000 1,25 Gbps
Generación2 VpnGw2 128 500 1,25 Gbps
Generación2 VpnGw3 128 1,000 2,5 Gbps
Generación2 VpnGw4 128 5,000 5 Gbps
Generación2 VpnGw5 128 10,000 10 Gb/s
Generación2 VpnGw2AZ 128 500 1,25 Gbps
Generación2 VpnGw3AZ 128 1,000 2,5 Gbps
Generación2 VpnGw4AZ 128 5,000 5 Gbps
Generación2 VpnGw5AZ 128 10,000 10 Gb/s
La columna de redundancia de zona se excluyó deliberadamente de esta tabla y es

idéntica a las opciones que se encuentran en la Tabla 1-1 anteriormente en este
capítulo. Los encabezados de la tabla muestran los tres tipos de conexión admitidos para las
VPN de punto a sitio:
 Protocolo de túnel de sockets seguros (SSTP)

 OpenVPN
 IKEv2
SSTP es un túnel VPN que usa TLS 1.2 y solo es compatible con clientes del sistema
operativo Windows. Sin embargo, como muestra la Tabla 1-5 , la escalabilidad está
limitada a 128 conexiones por puerta de enlace. OpenVPN también usa TLS, pero tiene
más soporte de conexión, según el SKU de la puerta de enlace, y un soporte de sistema
operativo más amplio que incluye:
 Androide
 iOS de Apple
 ventanas
 linux
 macOS 10.13 y superior
La VPN IKEv2 de punto a sitio utiliza una VPN IPsec y es compatible con macOS
10.11 y dispositivos con sistemas operativos superiores. Las siguientes secciones analizan
los diversos tipos de autenticación que puede usar con las puertas de enlace.
Planificar y configurar la autenticación RADIUS
Si planea usar un servidor RADIUS para la autenticación, puede elegir si el servidor

RADIUS se implementa localmente o en una red virtual de Azure. Si el servidor RADIUS
está ubicado en las instalaciones, la conexión existente debe ser una VPN de sitio a sitio
IPsec. No se admite el uso de ExpressRoute con una VPN de punto a sitio RADIUS. La
Figura 1-18 muestra un diseño de muestra de una implementación de RADIUS local.
FIGURA 1-18 Implementación de RADIUS local
La adición de una conexión de punto a sitio se puede configurar después de implementar

una puerta de enlace de red virtual. Si necesita implementar la puerta de enlace, siga los
pasos del tema Crear y configurar una puerta de enlace de red virtual en la sección de
habilidades 1.1 . Para configurar el punto a sitio con RADIUS, siga estos pasos:
2. En la puerta de enlace de red virtual, haga clic en la hoja Configuración de
punto a sitio .
3. En la página de configuración de Punto a sitio, haga clic en Configurar
ahora .
4. En el campo del grupo de direcciones, proporcione un rango de direcciones
IP para las conexiones VPN del cliente, como 192.168.1.0/24 .
5. En Tipo de túnel, seleccione los tipos de conexión deseados para usar con el
túnel. Seleccione OpenVPN (SSL) , pero otras opciones disponibles incluyen:
1. VPN abierta (SSL)
2. SSTP (SSL)
3. IKEv2
4. IKEv2 y OpenVPN (SSL)
5. IKEv2 y SSTP (SSL)
6. En el menú desplegable Tipo de autenticación, seleccione Autenticación
RADIUS .
7. En el campo Dirección IP del servidor principal, ingrese la dirección IP del
servidor RADIUS. Por ejemplo, ingrese 172.16.1.5 .
8. En el campo Secreto del servidor principal, ingrese el secreto compartido
que también se configuró en el servidor RADIUS. Por ejemplo, ingrese a1b2c3 .
9. Haga clic en Guardar . La Figura 1-19 muestra la configuración de muestra.
FIGURA 1-19 Punto a sitio con autenticación RADIUS
10. Después de hacer clic en Guardar, haga clic en el botón Descargar cliente
VPN para ayudar con la configuración del cliente.
¿NECESITA MÁS REVISIÓN? PUNTO A

SITIO CON AUTENTICACIÓN RADIUS
Para obtener más información sobre las VPN de punto a sitio con autenticación
RADIUS, visite https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-
how-to-radius-ps .
Planificar y configurar la autenticación basada en certificados
Otra opción de autenticación para las VPN de punto a sitio es utilizar la autenticación
basada en certificación. Para usar la autenticación de certificación, necesitará la clave
pública (archivo .CER) para el certificado raíz. Como parte del proceso de configuración,
deberá especificar la clave pública. Después de cargar el certificado raíz, la puerta de enlace
generará un certificado de cliente que se usa con la configuración del cliente VPN.
Para crear una configuración de VPN de punto a sitio mediante la autenticación basada
en certificados, siga estos pasos:

2. En la puerta de enlace de red virtual, haga clic en la hoja Configuración de
punto a sitio .
3. En la página de configuración de Punto a sitio, haga clic en Configurar
ahora .
4. En el campo del grupo de direcciones, proporcione un rango de direcciones
IP para las conexiones VPN del cliente. Por ejemplo, ingrese 192.168.1.0/24 .
5. En el menú desplegable Tipo de túnel, seleccione el túnel deseado. Para este
ejemplo, seleccione OpenVPN (SSL) .
6. En el menú desplegable Tipo de autenticación, seleccione Certificado de
Azure .
7. En el campo Nombre de certificados raíz, proporcione un nombre para el
certificado, como RootCert .
8. En el campo Certificados raíz Datos del certificado público, pegue el valor
del certificado público.
9. Haga clic en Guardar . La Figura 1-20 muestra una configuración
completa.
FIGURA 1-20 Punto a sitio con autenticación de certificado
¿NECESITA MÁS REVISIÓN? PUNTO A

SITIO CON AUTENTICACIÓN DE
CERTIFICADO
Para obtener más información sobre las VPN de punto a sitio con autenticación de
certificado, visite https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-
howto-point-to-site-resource-manager -portal .
Planificar y configurar la autenticación de Azure Active Directory (Azure AD)
Si planea usar Azure AD como método de autenticación con una VPN de punto a sitio,
debe usar el tipo de conexión OpenVPN. Esta configuración también requiere el uso del
cliente VPN de Azure y no es compatible con el sistema operativo integrado ni con clientes
VPN de terceros.
Para configurar la autenticación de Azure AD, siga estos pasos:
1. Si es necesario, inicie sesión en Azure Portal como administrador global

en https://portal.azure.com .
2. Desde Azure Portal, busque y seleccione Azure Active Directory .
3. Desde Azure AD, haga clic en la hoja Propiedades .
4. En la hoja Información general, copie el ID de arrendatario y guárdelo en un
editor de texto para usarlo más adelante en estos pasos. La Figura 1-21 muestra el
ID de arrendatario de nuestro directorio de muestra.
FIGURA 1-21 ID de arrendatario de Azure Active Directory
5. Navegue hasta la puerta de enlace de red virtual que implementó

anteriormente.
6. Desde la puerta de enlace, haga clic en la hoja Configuración de punto a
sitio .
7. En el campo Conjunto de direcciones, ingrese un rango de direcciones en
notación CIDR para las conexiones del cliente. Por ejemplo,
ingrese 192.168.1.0/24 .
8. En el menú desplegable Tipo de túnel, seleccione OpenVPN (SSL) .
9. En el menú desplegable Tipo de autenticación, seleccione Azure Active
Directory .
10. En el campo Inquilino de Azure AD, ingrese la siguiente URL,
reemplazando el identificador de inquilino con el identificador de inquilino que
copió anteriormente en estos pasos: https://login.microsoftonline.com/tenantID/
11. En el campo Audiencia, ingrese una de las siguientes cadenas, según la nube
de Azure que esté utilizando:
1. Ingrese 41b23e61-6c1e-4545-b367-cd054e0ed4b4 para Azure Public
2. Ingrese 51bb15d4-3a4f-4ebf-9dca-40096fe32426 para Azure Government
3. Introduzca 538ee9e6-310a-468d-afef-ea97365856a9 para Azure Alemania
4. Ingrese 49f817b6-84ae-4cc0-928c-73f27289b3aa para Azure China 21Vianet
12. En el campo Emisor, ingrese la siguiente URL, reemplazando el ID
de inquilino con el ID que copió anteriormente: https://sts.windows.net/tenantID/
13. Haga clic en Guardar . La Figura 1-22 muestra la configuración completa.
FIGURA 1-22 Autenticación P2S de Azure Active Directory
14. Después de guardar la configuración, aparecerá un vínculo para otorgar el

consentimiento del administrador para la aplicación cliente de VPN de
Azure debajo de los detalles de su configuración. Haga clic en este enlace y luego
inicie sesión con la cuenta de administrador global de su arrendatario.
15. Seleccione la casilla de verificación junto a Consentimiento en nombre de
su organización y luego haga clic en Aceptar, como se muestra en la Figura 1-23 .
FIGURA 1-23 Concesión de permiso de VPN
Implementar un archivo de configuración de cliente VPN
Una vez que haya configurado una configuración de punto a sitio con el tipo de conexión y
el método de autenticación deseados, puede descargar el archivo de configuración del
cliente desde la página de configuración de punto a sitio. Vuelva a consultar la Figura 1-
22 para ver el botón Descargar cliente VPN que está disponible en la página.
Para usar el cliente VPN de Azure, que se requiere para la autenticación de Azure AD,
siga estos pasos:
1. Descargue el cliente VPN de Azure del sitio web de Microsoft

en https://go.microsoft.com/fwlink/?linkid=2117554 . Siga los pasos para obtener e
instalar el cliente desde la tienda de Microsoft.
2. Descargue la información del cliente VPN desde la hoja de configuración de
punto a sitio. El archivo descargado será una carpeta comprimida .ZIP.
3. Extraiga la carpeta a una ubicación conocida, como el escritorio.
4. Inicie el cliente VPN de Azure. En la página principal, haga clic en
el ícono + y luego en Importar para agregar una conexión, como se muestra en
la Figura 1-24 .
FIGURA 1-24 Cliente VPN de Azure: configuración de importación
5. Busque la ubicación de los archivos del cliente VPN extraídos, abra la

carpeta AzureVPN y luego seleccione el archivo azurevpnconfig.xml .
El cliente VPN de Azure leerá y mostrará la información de configuración definida

en el archivo, como se muestra en la Figura 1-25 .
FIGURA 1-25 Cliente VPN de Azure: configuración importada
6. Establezca el menú desplegable Tipo de autenticación en Nombre de

usuario/Contraseña. Especifique un nombre de usuario y una contraseña válidos en
el arrendatario de Azure.
8. Para conectarse a la VPN, haga clic en Conectar .
Diagnosticar y resolver problemas de autenticación y del lado del cliente
La mayoría de los problemas del lado del cliente que podría necesitar solucionar
dependerán del tipo de método de autenticación que haya configurado. Por ejemplo, si
planea usar la autenticación basada en certificados con el cliente VPN de Azure, los
archivos de certificado AzureClient.pfx y AzureRoot.cer deben importarse a la ubicación
correcta en el dispositivo cliente. La Tabla 1-6 muestra la ubicación correcta de cada
archivo.
TABLA 1-6 Rutas de archivo de certificado
Certificado Ruta de ubicación

AzureClient.pfx Usuario actual\Personal\Certificados
AzureRoot.cer Equipo local\Entidades de certificación raíz de

confianza
AzureGateway- Equipo local\Entidades de certificación raíz de

GUID.cloudapp.net confianza
Azuregateway- Usuario actual\Autoridades de certificación raíz de

GUID.cloudapp.net confianza
Si planea usar un tipo de conexión IKEv2 con Windows 10 o Server 2016, es posible
que también deba instalar una actualización y establecer un valor de registro para usar
IKEv2 específicamente. La Tabla 1-7 muestra la versión del sistema operativo y la
actualización de la base de conocimiento para instalar.
TABLA 1-7 Actualizaciones de IKEv2
versión del sistema operativo Artículo de la base de conocimiento
Servidor Windows 2016 KB4057142
Windows 10, versión 1607 KB4057142
Además de la actualización correspondiente, debe establecer la siguiente clave

REG_DWORD en el registro en 1 .
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\IKEv2\Disable
CertReqPayload
¿NECESITA MÁS
REVISIÓN? SOLUCIÓN DE
PROBLEMAS DE PUNTO A SITIO
Para obtener más información sobre cómo solucionar problemas de VPN de punto a
sitio, visite https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-
troubleshoot-vpn-point-to-site-connection-problems .
Habilidad 1.3: Diseñar, implementar y administrar Azure ExpressRoute
Azure ExpressRoute proporciona una conectividad híbrida en su entorno local y una región
de Azure mediante el uso de un circuito dedicado a través de un proveedor de
telecomunicaciones externo. Los circuitos ExpressRoute se suelen comparar con los
circuitos MPLS, aunque funcionan de forma ligeramente diferente. Sin embargo, el
concepto general es el mismo: un proveedor de telecomunicaciones finaliza la conectividad
(por lo general, fibra pero podría ser Ethernet) en su ubicación local. Después de configurar
la conexión definida por software en su suscripción de Azure, tiene un circuito privado
dedicado de la red virtual que asocia con la configuración y su red local.
ExpressRoute depende del proveedor de telecomunicaciones para la conectividad física

entre su ubicación local y la región de Azure a la que planea conectarse. Por lo tanto, las
diferentes regiones de Azure admiten diferentes proveedores de telecomunicaciones y
varían según la región y la geografía de Azure.

 Elija entre proveedor y modelo directo (ExpressRoute Direct)
 Diseñe e implemente la conectividad entre regiones de Azure entre varias
ubicaciones de ExpressRoute
 Seleccione una SKU y un nivel de ExpressRoute apropiados
 Diseñar e implementar ExpressRoute Global Reach
 Diseñar e implementar ExpressRoute FastPath
 Elija entre emparejamiento privado solo, emparejamiento de Microsoft solo
o ambos
 Configurar emparejamiento privado
 Configurar emparejamiento de Microsoft
 Crear y configurar una puerta de enlace de ExpressRoute
 Conectar una red virtual a un circuito ExpressRoute
 Recomendar una configuración de anuncio de ruta
 Configurar el cifrado a través de ExpressRoute
 Implementar detección de reenvío bidireccional
 Diagnosticar y resolver problemas de conexión de ExpressRoute
Elija entre proveedor y modelo directo (ExpressRoute Direct)
La elección entre un circuito ExpressRoute "regular" y un circuito ExpressRoute Direct se

basa principalmente en dos puntos de decisión:
 ¿Tiene un requisito de ancho de banda de más de 10 Gbps?

 En caso afirmativo, ¿tiene o puede adquirir el hardware necesario para usar
un circuito ExpressRoute Direct?
Para comparar las opciones de ExpressRoute, un circuito normal proporciona hasta 10

Gbps de conectividad a través del proveedor de servicios y se puede terminar localmente
con opciones de conexión Ethernet o MPLS. Un circuito ExpressRoute Direct puede
proporcionar conectividad de hasta 100 Gbps, pero requiere terminaciones de fibra
monomodo con un par de enrutadores en la ubicación local. Los requisitos completos de
ExpressRoute Direct para el hardware de enrutamiento incluyen:
 Puertos duales de 10 Gigabit o 100 Gigabit Ethernet solo en el par de

enrutadores
 Conectividad de fibra monomodo de largo alcance (LR)
 IPv4 e IPv6
 Tamaño de transmisión de 1500 bytes
Hay requisitos en la capa de conmutación, que incluyen:
 Encapsulación de una etiqueta 802.1Q o dos etiquetas 802.1Q (QinQ)

 Si usa QinQ, debe poder configurar una etiqueta de ID de VLAN
especificada por Microsoft
 Ethertype debe ser 0x8100
 Debe admitir varias sesiones BGP (VLAN) por puerto y dispositivo
 Conectividad IPv4 e IPv6
 Para IPv6, no se creará ninguna subinterfaz adicional. Se agregará
una dirección IPv6 a la subinterfaz existente.
Opcionalmente, también puede configurar la compatibilidad con la detección de reenvío

bidireccional (BFD), que está configurada de manera predeterminada en todos los
emparejamientos privados en los circuitos ExpressRoute. Hablaremos de BFD más adelante
en esta sección de habilidades.
Otra consideración entre las dos opciones sería el precio. Con la calculadora de precios
de Azure ( https://aka.ms/pricing ), un circuito premium de ExpressRoute regular en los
Estados Unidos a 10 Gbps y 100 TB de transferencia de datos por mes costaría
aproximadamente $9000 por mes. Actualizar el circuito a ExpressRoute Direct con
conectividad de 100 Gbps aumenta el precio a más de $55,000 por mes. Tenga en cuenta
que estas estimaciones de costos son ejemplos y varían según la geografía, el tipo de
suscripción y el uso real de datos.
Diseñe e implemente la conectividad entre regiones de Azure entre varias ubicaciones de
ExpressRoute
El diseño de la conectividad entre regiones con ExpressRoute parece un proceso complejo

y difícil. Sin embargo, es fácil porque un circuito ExpressRoute se puede asociar y conectar
a varias redes virtuales, según la SKU de ExpressRoute que implemente, incluso si las
redes virtuales están en dos regiones o suscripciones diferentes. La Figura 1-26 muestra el
estado de conectividad deseado.
FIGURA 1-26 Diseño de ExpressRoute entre regiones
El desafío que presenta este escenario tiene que ver con el enrutamiento de la red. Cada
conexión de ExpressRoute tiene una configuración de peso de enrutamiento, que especifica
el costo lógico de usar la ruta. Personalice el peso de la conexión para aplicar rutas de
enrutamiento específicas entre las oficinas y las regiones de Azure. Además, puede
anunciar las redes disponibles a través de los mismos números del Sistema Autónomo (AS)
BGP.
Seleccione una SKU y un nivel de ExpressRoute apropiados
Determinar qué SKU de ExpressRoute usar depende de la carga de trabajo y los objetivos
del diseño. Las siguientes SKU están disponibles para las puertas de enlace de
ExpressRoute:
 Estándar
 Alto rendimiento
 Ultra rendimiento
 ERGW1AZ
 ERGW2AZ
 ERGW3AZ
La Tabla 1-8 muestra el soporte de características para los distintos tipos de SKU.
TABLA 1-8 Compatibilidad con SKU de puerta de enlace de ExpressRoute
SKU Soporte Número máximo de conexiones de

FastPath circuito
Estándar / ERGW1AZ No 4
Alto rendimiento / No 8
ERGW2AZ
Ultra rendimiento / Sí dieciséis

ERGW3AZ
Tenga en cuenta que en la Tabla 1-8 , no hay diferencia de características para FastPath
o soporte de conexión de circuito para SKU estándar y SKU ERGW1AZ. La diferencia
entre estos dos SKU es que el SKU AZ admite zonas de disponibilidad si la región en la
que implementa la puerta de enlace también admite zonas de disponibilidad. Si necesita
soporte para FastPath, que se analiza más adelante en esta sección de habilidades, sus
únicas opciones son las SKU de rendimiento Ultra o ERGW3AZ. De lo contrario, su
selección de los cuatro restantes dependerá del rendimiento deseado. La Tabla 1-9 muestra
el rendimiento probado para cada SKU.
TABLA 1-9 Rendimiento de la SKU de ExpressRoute
SKU Conexiones MB/s paquetes por Número admitido de

por segundo segundo máquinas virtuales en
la red virtual
Estándar / 7,000 1,000 100,000 2,000

ERGW1AZ
Alto rendimiento 14,000 2,000 250.000 4500

/ ERGW2AZ
Ultra 16,000 10,000 1,000,000 11,000
rendimiento /
ERGW3AZ
Para cada SKU, también puede habilitar el complemento Premium, que amplía los
límites de conectividad, aumenta los límites de enlaces de red, aumenta el límite de la tabla
de enrutamiento y proporciona conectividad a Microsoft 365. La Tabla 1-10 enumera la
cantidad máxima de enlaces de red virtual con De primera calidad. El estándar
ExpressRoute está limitado a 10 enlaces de red virtual, independientemente del tamaño del
circuito.
TABLA 1-10 Número máximo de redes virtuales vinculadas con ExpressRoute Premium
Tamaño del circuito Enlaces de red virtual
50Mbps 20
100Mbps 25
200Mbps 25
500Mbps 40
1 Gbps 50
2 Gb/s 60
5 Gbps 75
10 Gb/s 100
40 Gbps * 100
100 Gbps * 100
* Requiere ExpressRoute directo

Diseñar e implementar ExpressRoute Global Reach
De manera predeterminada, cuando configura ExpressRoute con un diseño entre regiones,

sus oficinas locales pueden comunicarse con las regiones que están conectadas al
circuito. Sin embargo, sin Global Reach, no puede usar el circuito ExpressRoute para
comunicarse directamente entre ubicaciones locales. Por ejemplo, volviendo a la Figura 1-
26 , la oficina de Los Ángeles y la oficina de Nueva York no podrían comunicarse de forma
predeterminada.
Si desea utilizar los circuitos ExpressRoute para habilitar la comunicación entre Los
Ángeles y Nueva York a través de ExpressRoute, Global Reach lo habilitará. Sin embargo,
si las dos ubicaciones de oficina que intenta conectar se encuentran en regiones
geopolíticas, entonces debe usar el complemento Premium para el circuito
ExpressRoute. Por ejemplo, esto podría ser entre oficinas en los Estados Unidos y Canadá.
Para configurar Global Reach, básicamente crea una red de pares privada entre los dos
circuitos ExpressRoute. La red privada del mismo nivel debe tener una longitud de red de
/29.
Para agregar Global Reach a un circuito ExpressRoute existente, siga estos pasos:

2. En la barra de búsqueda, busque ExpressRoute, luego seleccione el resultado
de circuitos de ExpressRoute .
3. Seleccione un circuito que ya haya configurado y desee habilitar Global
Reach.
4. Desde el circuito, haga clic en la hoja Peerings .
5. Seleccione el par privado de Azure que se ha aprovisionado. La Figura 1-
27 muestra el emparejamiento aprovisionado en la hoja de emparejamientos.
FIGURA 1-27 Emparejamientos de ExpressRoute

6. En la página de emparejamiento privado de Azure, haga clic en Agregar
alcance global .
7. En la página flotante Agregar alcance global, proporcione un nombre,
seleccione un segundo circuito y proporcione una subred IPv4 /29 para usar con el
par privado. La Figura 1-28 muestra una configuración parcial.
FIGURA 1-28 Configuración de alcance global de ExpressRoute

Diseñar e implementar ExpressRoute FastPath
ExpressRoute FastPath es una función de mejora del rendimiento que solo está disponible
en las SKU de primer nivel: rendimiento ultra y ERGW3AZ. Además, si planea usar IPv6,
solo puede usar el SKU ERGW3AZ.
En todas las configuraciones de ExpressRoute, el circuito termina en una puerta de

enlace de red virtual en la suscripción de Azure. Este salto adicional aumenta la latencia de
cualquier tráfico de red a las máquinas virtuales que se encuentran en una red
virtual. ExpressRoute FastPath optimiza el enrutamiento de la red para que el tráfico
destinado a las máquinas virtuales se entregue directamente y omita la puerta de enlace de
la red virtual, lo que reduce la latencia general.
Para configurar ExpressRoute FastPath, vincula una red virtual a un circuito

ExpressRoute. Los circuitos estándar admiten hasta 10 enlaces de red virtual,
independientemente del SKU. Los circuitos premium dependen del tamaño del circuito en
Mbps. Consulte la Tabla 1-10 anterior en esta sección de habilidades para conocer los
límites específicos.
Para habilitar FastPath en un circuito ExpressRoute existente, siga estos pasos:

3. Seleccione un circuito que ya haya configurado y desee habilitar FastPath.
4. Haga clic en la hoja Conexiones y luego haga clic en la conexión
existente.
5. En la conexión específica, haga clic en la hoja Configuración .
6. Seleccione la casilla de verificación junto a FastPath y luego haga clic
en Guardar . La Figura 1-29 muestra la ubicación de la casilla de verificación
FastPath.
FIGURA 1-29 Configuración de ExpressRoute FastPath
También puede habilitar FastPath al agregar una conexión desde la puerta de enlace
de red virtual. La Figura 1-30 muestra las opciones Agregar conexión de la puerta
de enlace, incluida la opción para habilitar FastPath. Para conocer los pasos
detallados para agregar una conexión, consulte la sección de habilidades 1.1 .
FIGURA 1-30 Agregar conexión desde una puerta de enlace de red virtual
Elija entre emparejamiento privado solo, emparejamiento de Microsoft solo o ambos
Como parte de la configuración de ExpressRoute, tiene la opción de configurar el

emparejamiento privado de Azure, el emparejamiento de Microsoft o ambos. El
emparejamiento privado de Azure proporciona conectividad desde su entorno local a las
suscripciones y recursos de Azure a los que vincula el circuito.
En circunstancias excepcionales, es posible que también desee que los servicios de

Microsoft 365, como Microsoft Exchange Online y Microsoft SharePoint Online, sean
accesibles a través del circuito ExpressRoute. Este escenario usa emparejamiento de
Microsoft, pero Microsoft no lo recomienda y debe usarse solo si su organización tiene
requisitos estrictos para el tráfico de red. microsoft 365fue diseñado para acceder de forma
segura a través de la Internet pública y aún requiere acceso público a la Internet para ciertos
servicios, incluso si se configura la interconexión de Microsoft a través de
ExpressRoute. La Tabla 1-11 compara los requisitos técnicos para configurar el
emparejamiento privado de Azure y el emparejamiento de Microsoft.
TABLA 1-11 Comparación de pares
Emparejamiento privado de Emparejamiento de

Azure Microsoft
Prefijos de dirección Estándar: 4.000 200

máximos admitidos
Prima: 10,000
Rangos de direcciones IP Cualquier dirección IP Solo direcciones IP

compatibles válida públicas
Requisitos del número AS Números AS privados y Números AS privados y

públicos públicos
Protocolos IP compatibles IPv4 IPv4 e IPv6
IPv6 (vista previa, a partir

de este escrito)
Direcciones IP de la interfaz Direcciones IP públicas o Solo direcciones IP

de enrutamiento privadas públicas
Compatibilidad con hash Sí Sí

MD5
Si elige usar emparejamiento privado de Azure y Microsoft, cada tipo de
emparejamiento requiere un BGP independiente para proporcionar alta disponibilidad en
ambas conexiones.
Configurar emparejamiento privado
Para configurar el emparejamiento privado de Azure, el estado del proveedor del circuito
ExpressRoute debe mostrar Provisioned . Como parte de este aprovisionamiento, algunos
proveedores de ExpressRoute administrarán el enrutamiento como parte del circuito y estos
pasos no serán necesarios. Si el proveedor no administra el enrutamiento, deberá seguir
estos pasos:

3. Seleccione un circuito que ya haya configurado y desee configurar el
intercambio de tráfico privado.
4. Haga clic en la hoja Emparejamientos y, a continuación, haga clic
en Privado de Azure .
5. En la página Emparejamiento privado, configure el ASN del mismo nivel, el
protocolo, las subredes y el ID de VLAN. En la Figura 1-31 se muestra una
configuración de ejemplo .
FIGURA 1-31 Configuración de emparejamiento privado

Configurar emparejamiento de Microsoft
Para configurar el emparejamiento de Microsoft, el estado del proveedor del circuito

ExpressRoute debe mostrar Provisioned . Tenga en cuenta que el emparejamiento de
Microsoft requiere el uso de direcciones IP públicas, pero puede usar números AS públicos
o privados. Para configurar el emparejamiento de Microsoft, siga estos pasos:

4. Haga clic en la hoja Emparejamientos y, a continuación, haga clic en
Emparejamiento de Microsoft .
5. En la página de intercambio de tráfico de Microsoft, configure el ASN de
intercambio de tráfico, el protocolo, las subredes, los prefijos anunciados y el ID de
VLAN. En la Figura 1-32 se muestra una configuración de ejemplo .
FIGURA 1-32 Configuración de emparejamiento de Microsoft

Crear y configurar una puerta de enlace de ExpressRoute
Una puerta de enlace de ExpressRoute sigue siendo una puerta de enlace de red virtual, solo
que con diferentes opciones seleccionadas. Para crear una puerta de enlace de red virtual
para ExpressRoute, siga estos pasos:

2. En la barra de búsqueda, busque puertas de enlace de red virtual y, a
continuación, seleccione el resultado Puertas de enlace de red virtual .
4. En el menú desplegable de suscripción, seleccione la suscripción con la que
asociar la puerta de enlace.
5. En el campo Nombre, ingrese un nombre para mostrar para el recurso de
puerta de enlace. Por ejemplo, ingrese ER_to_onprem.
6. En el menú desplegable Región, seleccione la misma región que su red
virtual. Para este ejemplo, seleccione Este de EE. UU .
7. Para el tipo de puerta de enlace, seleccione ExpressRoute .
8. En el campo desplegable SKU, seleccione el SKU deseado. Para este
ejemplo, seleccione Estándar .
9. En el menú desplegable Red virtual, seleccione la red virtual que incluye
una subred llamada GatewaySubnet para usar con ExpressRoute.
10. En el campo Nombre de la dirección IP pública, ingrese ERPIP . La Figura
1-33 muestra la configuración final completa.
FIGURA 1-33 Puerta de enlace de red virtual de ExpressRoute
11. Haga clic en Revisar y crear y, a continuación, haga clic en Crear .

Conectar una red virtual a un circuito ExpressRoute
De forma similar a la creación de una VPN, la creación de la puerta de enlace de red virtual
como puerta de enlace de ExpressRoute no crea la conexión para el circuito de
ExpressRoute. Después de crear la puerta de enlace, también debe crear una conexión para
vincular el circuito a una red virtual.
Para crear una conexión en un circuito ExpressRoute existente, siga estos pasos:

3. Selecciona un circuito que ya hayas creado.
4. Haga clic en la hoja Conexiones y luego haga clic en Agregar .
5. En el campo Nombre, proporcione un nombre para la conexión,
como L3_onprem .
6. En el menú desplegable Tipo de conexión, seleccione ExpressRoute .
7. Seleccione circuito ExpressRoute y seleccione el circuito configurado. La
Figura 1-34 muestra una configuración parcial de la conexión.
FIGURA 1-34 ExpressRoute Agregar conexión
8. Haga clic en Aceptar para crear la conexión.
Recomendar una configuración de anuncio de ruta
Algunas empresas de telecomunicaciones que ofrecen servicios ExpressRoute también

ofrecen un servicio de enrutamiento administrado como parte de la implementación. Si este
es el caso, entonces no necesita hacer nada adicional para configurar los anuncios de
ruta. Sin embargo, si necesita o planea configurar el anuncio de ruta manualmente, debe
cumplir con los siguientes requisitos. Para IPv4, los requisitos incluyen:
 Una sola subred /29 o dos /30 para las interfaces

 Si usa un /29, se separa en un /30 de todos modos
 El primer /30 es para el enlace principal
 El segundo /30 es para el enlace secundario.
 La primera dirección IP disponible debe usarse en su hardware
 Azure usará la segunda dirección IP disponible
 Para el emparejamiento privado de Azure, las direcciones utilizadas pueden
ser públicas o privadas.
 Estos rangos no deben entrar en conflicto con ninguna red virtual en Azure a
la que planee conectarse.
Existen requisitos similares si planea usar IPv6, que incluyen:
 Una sola subred /125 o dos subredes /126 para las interfaces
 Si usa un /125, se divide en dos subredes /126
 La primera dirección IP disponible debe usarse en su hardware
 Azure usará la segunda dirección IP disponible
 Para el emparejamiento privado de Azure, las direcciones utilizadas pueden
ser públicas o privadas.
 Estos rangos no deben entrar en conflicto con ninguna red virtual en Azure a
la que planee conectarse.
Si planea usar el emparejamiento de Microsoft, debe usar direcciones IP públicas, lo

cual es necesario para las sesiones de BGP. También debe poder verificar la propiedad de
las direcciones a través del Registro de enrutamiento de Internet. Los mismos requisitos
anteriores se aplican al emparejamiento de Microsoft, pero solo se admiten con direcciones
IP públicas.
Después de determinar qué tipo de emparejamiento y protocolo usará, puede planificar

la agregación de rutas y las rutas predeterminadas. El emparejamiento privado de Azure
ExpressRoute admite hasta 4000 prefijos de IPv6 individuales y 100 prefijos de IPv6 que se
anunciarán. Si habilita la SKU premium, puede aumentar el límite de IPv4 hasta 10,000
prefijos.
También puede configurar el circuito ExpressRoute para que sea la ruta predeterminada
para las redes virtuales de Azure. Esto garantizará que todo el tráfico de Azure fluya a
través de ExpressRoute a su hardware local antes de enrutarse a Internet.
Para los números BGP y AS, Microsoft usa el número AS 12076 para su número
AS. Puede conectarse a comunidades individuales para varios servicios dentro de la región
en la que configura el circuito ExpressRoute.
¿NECESITA MÁS
REVISIÓN? COMUNIDADES BGP
Para obtener más información sobre las comunidades BGP disponibles para las
regiones de Azure, visite https://docs.microsoft.com/en-
us/azure/expressroute/expressroute-routing#bgp .
Configurar el cifrado a través de ExpressRoute
ExpressRoute por sí solo es una conexión privada y dedicada a través de su proveedor de

telecomunicaciones seleccionado a una región de Azure. Sin embargo, eso no significa que
el tráfico esté encriptado. Tiene dos opciones para configurar el cifrado en ExpressRoute:
 Una VPN de sitio a sitio mediante una puerta de enlace de red virtual
 Una VPN de sitio a sitio con Azure Virtual WAN
La configuración de la VPN de sitio a sitio mediante una puerta de enlace de red virtual
no es diferente de la configuración que se analizó en la sección de habilidades 1.1 . Si
planea usar una puerta de enlace de red virtual, debe implementarse como una puerta de
enlace con redundancia de zona. Azure Virtual WAN se analiza en un capítulo posterior.
Implementar detección de reenvío bidireccional
La detección de reenvío bidireccional (BFD) es útil para acelerar la detección de que uno
de los enlaces de ExpressRoute ha fallado. El tiempo de mantenimiento de BGP
generalmente se configura en 60 segundos y el tiempo de espera se configura en 180
segundos. Esto significa que el servicio puede tardar hasta tres minutos en darse cuenta de
que uno de los vínculos de ExpressRoute ha fallado. Con BFD, puede reducir los tiempos
de mantenimiento hasta 300 milisegundos, lo que permite que se produzcan conmutaciones
por error en menos de un segundo.
BFD está configurado de manera predeterminada para todas las nuevas conexiones
privadas de pares de ExpressRoute. Después de realizar el cambio de configuración en el
hardware local, solo necesita restablecer la conexión del mismo nivel privado de
ExpressRoute para renegociar la conexión con BFD. Para restablecer una conexión
existente, siga estos pasos.
4. Haga clic en la hoja Emparejamientos y, a continuación, haga clic
en Privado de Azure .
5. En la página Emparejamiento privado, borre la casilla de verificación junto
a Habilitar emparejamiento IPv4 , como se muestra en la Figura 1-35 .
FIGURA 1-35 Restablecimiento de la conexión de emparejamiento privado

7. Seleccione la casilla de verificación junto a Habilitar emparejamiento
IPv4 y luego haga clic en Guardar .
Diagnosticar y resolver problemas de conexión de ExpressRoute
La solución de problemas de una conexión ExpressRoute puede llevar mucho tiempo

debido a la cantidad de factores involucrados en su red, la red del proveedor de
telecomunicaciones y la configuración de Azure. El primer lugar para comenzar la solución
de problemas es la página de información general del circuito ExpressRoute. Como se
muestra en la Figura 1-36 , el estado del circuito debe mostrar Habilitado y el estado del
Proveedor debe mostrar Aprovisionado. Todo lo que no sea estos indicadores de estado
puede requerir asistencia adicional del proveedor.
FIGURA 1-36 Descripción general de ExpressRoute
Si las etiquetas de estado muestran Habilitado y Aprovisionado, un problema común con

ExpressRoute es el enrutamiento. Verifique que tenga los prefijos de dirección correctos
definidos en ambos lados de la configuración y pruebe el enrutamiento con una herramienta
como tracert .
Si los problemas que encuentra están relacionados con el rendimiento o la latencia,

puede usar Azure Connectivity Toolkit (AzureCT) para ayudar con la solución de
problemas. AzureCT es una herramienta de PowerShell que prueba la conectividad de red
básica entre dos hosts. El módulo AzureCT PowerShell está disponible para descargar
en https://aka.ms/AzureCT .
¿NECESITA MÁS
REVISIÓN? SOLUCIÓN DE
PROBLEMAS DE EXPRESSROUTE
Para obtener más información sobre la solución de problemas de ExpressRoute,
visite https://docs.microsoft.com/en-us/azure/expressroute/expressroute-
troubleshooting-network-performance .
 Las puertas de enlace de red virtual se pueden implementar en

configuraciones zonales o con redundancia de zona.
 Para puertas de enlace de red virtual con redundancia de zona, debe usar una
dirección IP pública de SKU estándar.
 La SKU de puerta de enlace de red virtual determina el rendimiento y la
cantidad máxima de túneles de sitio a sitio.
 Las VPN basadas en políticas usan rutas estáticas basadas en prefijos de
rango de direcciones.
 Las VPN basadas en rutas utilizan una tabla de rutas para dirigir los
paquetes.
 Al configurar una puerta de enlace de red virtual, la red virtual debe tener
una subred llamada GatewaySubnet .
 Una puerta de enlace de red local es un recurso de Azure que representa el
intervalo de direcciones de destino.
 Las VPN de punto a sitio admiten los tipos de conexión SSTP, OpenVPN o
IKEv2.
 La SKU de puerta de enlace de red virtual determina el rendimiento y la
cantidad máxima de conexiones de punto a sitio.
 Los túneles VPN de punto a sitio pueden usar RADIUS, certificado o Azure
AD para la autenticación.
 Al usar Azure AD para la autenticación, debe usar el cliente VPN de Azure.
 ExpressRoute proporciona una conexión privada y directa desde su entorno
local a Azure.
 La SKU de ExpressRoute determina el ancho de banda y el límite de
conexión para el circuito.
 ExpressRoute Global Reach requiere el complemento Premium y
proporciona conectividad a varias regiones de Azure a través de un circuito
ExpressRoute y está configurado en el par privado.
 ExpressRoute FastPath omite la puerta de enlace de la red virtual y se
comunica directamente con las máquinas virtuales y se configura en la conexión del
circuito.
 El emparejamiento privado proporciona acceso desde su red local a Azure.
 El emparejamiento de Microsoft proporciona acceso desde su red local a los
servicios de Microsoft 365, pero no se recomienda.
 El anuncio de ruta de ExpressRoute se configura mediante BGP.
Experimento mental
En este experimento mental, demuestre sus habilidades y conocimiento de los temas

tratados en este capítulo. Puede encontrar las respuestas en la sección siguiente.
Contoso Mortgage es una empresa de servicios financieros que tiene dos centros de
datos principales en Chicago y Nueva York. Los centros de datos tienen una conexión
redundante de 5 Gbps entre ellos. La empresa también tiene sucursales más pequeñas con
túneles VPN de sitio a sitio desde la sucursal hasta cada centro de datos. El personal
ejecutivo y de TI tiene VPN definidas por software en dispositivos móviles para la
conectividad remota a cada centro de datos.
Contoso planea trasladar su aplicación principal de los centros de datos locales a la nube
de Azure. La red debe admitir la migración y la conectividad continua de manera similar al
diseño local actual. En el caso de que una región o un proveedor de conectividad sufra una
interrupción grave, el centro de datos local aún debe poder comunicarse con Azure. La
Figura 1-37 muestra el diseño local existente.
FIGURA 1-37 Diseño de red existente de Contoso Mortgage
Su objetivo es diseñar la infraestructura de red para el nuevo entorno de Azure. Para

cada objetivo, identifique el servicio de Azure que se usará e incorpórelo a la arquitectura
existente.
1. 1 . ¿Qué debe usar para proporcionar conectividad híbrida a cada centro de datos?
2. 2 . ¿Qué debe usar para proporcionar conectividad híbrida a cada sucursal?
3. 3 . ¿Cómo se deben implementar los servicios para garantizar una conectividad de
alta disponibilidad?
4. 4 . ¿Qué debe usar el personal ejecutivo y de TI para conectarse a Azure de forma
remota?
Esta sección contiene la solución al experimento mental. Cada respuesta explica por qué la
opción de respuesta es correcta.
El diseño deseado basado en los requisitos de Contoso Mortgage incluiría conexiones

ExpressRoute desde ambos centros de datos locales a dos regiones de Azure para la
redundancia deseada. En este escenario, podemos seleccionar Este de EE. UU. 2 y Centro
de EE. UU. como las regiones de destino. Debido al requisito de comunicarse entre
regiones a través de cualquiera de los circuitos ExpressRoute, se debe configurar Global
Reach en los circuitos. Esto también significa que los circuitos deben ser ExpressRoute con
el complemento Premium. Finalmente, para abordar cualquier posible interrupción grave
entre los proveedores, los circuitos de ExpressRoute deben ser dos proveedores de
conectividad diferentes para cada región.
Las sucursales pueden seguir conectándose a los centros de datos locales mediante VPN
de sitio a sitio. Puede configurar VPN adicionales para cada sucursal si necesitan la
conectividad a Azure o cuando lo necesiten.
1. 1 . ¿Qué debe usar para proporcionar conectividad híbrida a cada centro de datos?
Cada centro de datos debe tener un circuito Azure ExpressRoute con alcance global
para cumplir con los requisitos de diseño.
2. 2 . ¿Qué debe usar para proporcionar conectividad híbrida a cada sucursal?
Cada sucursal debe tener una VPN de sitio a sitio definida para cada región de
Azure.
3. 3 . ¿Cómo se deben implementar los servicios para garantizar una conectividad de

alta disponibilidad?
Cada sucursal debe tener una VPN de sitio a sitio independiente para cada región de
Azure. Cada circuito de ExpressRoute debe tener Global Reach habilitado para la
conectividad entre regiones.
4. 4 . ¿Qué debe usar el personal ejecutivo y de TI para conectarse a Azure de forma

remota?
Las regiones de Azure deben tener una puerta de enlace de red virtual con
conectividad de punto a sitio configurada para que el personal ejecutivo y de TI se
conecte de forma remota con sus dispositivos móviles.
La Figura 1-38 muestra el diseño final previsto.

FIGURA 1-38 Diseño de red propuesto por Contoso Mortgage
Capitulo 2
Diseñar e implementar la infraestructura de red central
En este capítulo, analizamos los componentes principales de una infraestructura de red en

Azure, que comienza con las redes virtuales. La red virtual proporciona conectividad a las
máquinas virtuales que se implementan en cada región de Azure, así como conectividad
privada a través del servicio y puntos de conexión privados. La mayoría de las aplicaciones
(y las personas) prefieren usar nombres en lugar de direcciones IP, por lo que la capacidad
de convertir nombres en direcciones IP se convierte en un componente fundamental de la
red central. A medida que el entorno crece con redes virtuales adicionales, la necesidad de
facilitar la comunicación entre redes se vuelve importante y puede abordarse con
peering. Finalmente, para una solución híbrida administrada, puede usar Virtual WAN para
tener conectividad transitiva entre sitios a través de un servicio en la nube.
 Habilidad 2.1: Diseñar e implementar direccionamiento IP privado para

redes virtuales
 Habilidad 2.2: Diseñar e implementar la resolución de nombres
 Habilidad 2.3: Diseñar e implementar conectividad entre redes virtuales
 Habilidad 2.4: Diseñar e implementar una arquitectura Azure Virtual WAN
Habilidad 2.1: Diseñar e implementar direccionamiento IP privado para redes virtuales
La infraestructura de red central en Azure gira en torno a las redes virtuales. Las redes
virtuales definen el espacio de direcciones para las redes IPv4 e IPv6 que usará con sus
servicios de Azure. Las redes virtuales son necesarias para máquinas virtuales, firewalls,
gateways de aplicaciones, gateways de redes virtuales y más. Esta sección de habilidades se
centra en la conectividad privada proporcionada por las redes virtuales y cómo integrar la
red con otros servicios de Azure.

 Crear una red virtual
 Planifique y configure la división en subredes de los servicios, incluidas las
puertas de enlace de VNet, los puntos de conexión privados, los firewalls, las
puertas de enlace de aplicaciones y los servicios de plataforma integrados en VNet.
 Planificar y configurar la delegación de subredes
 Planificar y configurar subredes para Azure Route Server
Crear una red virtual
Una red virtual es uno de los servicios fundamentales que se implementa en una suscripción
para facilitar la comunicación de las máquinas virtuales, la conectividad híbrida y la
comunicación privada con los recursos de plataforma como servicio (PaaS). Cuando crea
una red virtual, debe especificar la región de Azure en la que implementar la red
virtual. Las redes virtuales individuales abarcan solo la única región en la que las
implementa. Si planea tener una implementación de alta disponibilidad en varias regiones,
deberá implementar al menos una red virtual en cada región. Para implementaciones a
mayor escala, incluso puede implementar varias redes virtuales en una sola región para
modelos de diseño tipo hub-and-spoke.
El proceso de creación de una red virtual es relativamente fácil. Sin embargo, la

planificación y el diseño que conducen a su creación son mucho más complejos. Algunos
servicios de Azure, como las puertas de enlace de red virtual y Azure Bastion, requieren
subredes dedicadas. Hablaremos sobre la división en subredes para servicios específicos en
la siguiente sección.
Cuando crea una red virtual, las dos piezas principales de planificación que le pedirá el
asistente de creación son el espacio de direcciones y la primera subred. El espacio de
direcciones es al menos un rango de IPv4 y también puede incluir múltiples rangos de
IPv6. Los intervalos de direcciones que especifique se pueden usar para crear subredes
dentro de la red virtual. Una práctica recomendada es no superponer los espacios de
direcciones cuando planee implementar varias redes virtuales, incluso en otras
suscripciones. Las redes virtuales que tienen espacios de direcciones IP superpuestos no
se pueden emparejar.
El segundo componente de una red virtual que se define cuando la crea es la primera
subred.
Para crear una red virtual, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Redes virtuales .
3. En la página Redes virtuales, haga clic en Crear .
4. En el menú desplegable Suscripción, seleccione la suscripción en la que se
debe crear la red virtual.
5. En el menú desplegable Grupo de recursos, cree un grupo de recursos nuevo
o seleccione uno existente para la red virtual.
6. En el campo Nombre, proporcione un nombre para la red, como hub-vnet-
eus-01 .
7. En el menú desplegable Región, seleccione la región donde se usará la red
virtual con otros recursos. Para este ejemplo, seleccione Este de EE. UU .
8. Haga clic en Siguiente: Direcciones IP .
9. Tenga en cuenta que el espacio de direcciones IPv4 ya está poblado con un
espacio de direcciones predeterminado de 10.0.0.0/16. Puede modificar o agregar
espacios de direcciones si es necesario para la red virtual. También hay una subred
denominada "predeterminada" que utiliza el primer espacio de direcciones
/24. Acepte el valor predeterminado, como se muestra en la Figura 2-1 , y luego
haga clic en Siguiente: Seguridad .
FIGURA 2-1 Direcciones IP de red virtual
CONSEJO DE EXAMEN
Esta referencia de examen y el examen asumen que ya está familiarizado con los
fundamentos de las redes, incluidas las subredes, la notación CIDR, TCP/IP y
más. Si estos son conceptos nuevos, debe dedicar más tiempo a prepararse con el
módulo Fundamentos de redes informáticas en Microsoft Learn
en https://docs.microsoft.com/en-us/learn/modules/network-fundamentals/ .
10. La pestaña Seguridad de la página Crear red virtual muestra los servicios de
seguridad disponibles que puede implementar y configurar al mismo tiempo que la
red virtual: BastionHost, DDoS Protection Standard y Firewall. Todos están
configurados en Deshabilitar de forma predeterminada y se pueden configurar
después de crear la red virtual. Acceda a los valores predeterminados y haga clic
en Revisar + Crear .
Planificar y configurar subredes para servicios
El nombre completo del objetivo en la aptitud es Planificar y configurar subredes para

servicios, incluidas puertas de enlace de red virtual, puntos de conexión privados,
firewalls, puertas de enlace de aplicaciones y servicios de plataforma integrada en red
virtual . Acortamos el título de esta sección y veremos los diversos servicios de Azure que
requieren integración a subredes o requieren una subred dedicada.
Puertas de enlace de red virtual
El Capítulo 1 trata las puertas de enlace de red virtual, las VPN y ExpressRoute con más
detalle. Desde la perspectiva de una red virtual, una puerta de enlace de red virtual requiere
que se configure una subred dedicada denominada específicamente GatewaySubnet . Como
mínimo, el tamaño de GatewaySubnet debe ser al menos /29 en notación CIDR, por
ejemplo, 10.0.100.0/29. Sin embargo, una pequeña subred como /29 es útil solo para una
única VPN de sitio a sitio. Para la planificación futura, se recomienda asignar un espacio de
direcciones más grande, como /27, a GatewaySubnet.
La razón por la que el intervalo mínimo de direcciones es /29 para GatewaySubnet se

debe a cómo las redes virtuales asignan las direcciones IP por subred. Cada subred tiene
cinco direcciones reservadas que los recursos de su suscripción no pueden usar:
 Identificador de red
 Dirección de Difusión
 Tres servicios específicos de Azure
El identificador de red y la dirección de transmisión son funciones estándar de TCP/IP

que ocurren en cualquier tipo de escenario de división en subredes. Los tres servicios
específicos de Azure son los que habilitan la red virtual definida por software y facilitan los
servicios de enrutamiento y DNS dentro de la subred.
Usando el mismo ejemplo 10.0.100.0/29 anterior, esto daría como resultado solo tres
direcciones utilizables:
 10.0.100.0 – Identificador de red, no utilizable

 10.0.100.1 – 10.0.100.3 – Servicios específicos de Azure, no utilizable
 10.0.100.4 – 10.0.100.6 – Direcciones IP utilizables
 10.0.100.7 – Dirección de transmisión, no utilizable
Cuando hace clic en + Subred de puerta de enlace desde la red virtual, el campo Nombre
de la subred se rellena automáticamente con el nombre GatewaySubnet y no se puede
cambiar. La Figura 2-2 muestra la subred de la puerta de enlace con la configuración de
ejemplo.
FIGURA 2-2 Configuración de GatewaySubnet
cortafuegos
Azure Firewalls son firewalls PaaS administrados que puede asociar con una red virtual
para proteger los recursos de la red. El servicio Azure Firewall se analiza con más detalle
en el Capítulo 4 , pero es otro servicio que requiere una subred dedicada, específicamente
llamada AzureFirewallSubnet .
El tamaño recomendado de AzureFirewallSubnet es /26 en notación CIDR. Azure

Firewalls se puede configurar para escalar automáticamente según el porcentaje de CPU o
el rendimiento, y cada instancia requiere una dirección IP interna adicional en
AzureFirewallSubnet. Un /26 garantiza que haya suficientes direcciones IP en la subred
para cualquier posible acción de escalado que realice el servicio.
Si intenta crear un firewall mediante una red virtual existente, Azure Portal requerirá
que se cree AzureFirewallSubnet antes de poder crear el firewall. La figura 2-3 muestra la
pantalla Crear un firewall con un error que indica que la red virtual existente debe tener una
subred llamada AzureFirewallSubnet.
FIGURA 2-3 Falta una subred de Azure Firewall
Además, si crea AzureFirewallSubnet con un tamaño de subred inferior a /26, recibirá

un error. La figura 2-4 muestra el uso de una red virtual existente que contiene una subred
llamada AzureFirewallSubnet, pero la subred no tiene un tamaño suficiente. El error puede
ser confuso, ya que dice que el prefijo debe ser menor o igual a 26; lo que significa que el
número entero real utilizado para el prefijo debe ser más bajo, por ejemplo, /25, lo que da
como resultado una subred más grande.
Pasarelas de aplicaciones
Azure Application Gateway es otro recurso de PaaS que está asociado con sus redes
virtuales para proteger los recursos y se analiza más en el Capítulo 3 . Las puertas de enlace
de aplicaciones requieren una subred dedicada dentro de la red virtual, pero la subred no
necesita tener un nombre específico. Sin embargo, la subred debe estar vacía y no contener
máquinas virtuales u otros recursos de Azure. El tamaño recomendado de la subred
depende de la SKU de la puerta de enlace de aplicaciones que utilice.
Los gateways de aplicaciones vienen en dos versiones de SKU, por

ejemplo, Standard y Standard_v2 . Los gateways de aplicaciones de primera generación
pueden escalar hasta 32 instancias; por lo tanto, un /26 es el tamaño de subred
recomendado. Las puertas de enlace de aplicaciones con la SKU v2 pueden escalar hasta
125 instancias, por lo que se recomienda un tamaño de subred mínimo de /24. A diferencia
de Azure Firewalls, Azure Portal no le dará un error si crea una subred más pequeña que la
recomendada. Esto evitaría que el servicio escale más allá de las direcciones IP disponibles
en la subred.
FIGURA 2-4 Tamaño de subred incorrecto de Azure Firewall

Puede reutilizar la misma subred para puertas de enlace de aplicaciones adicionales. Sin
embargo, las puertas de enlace de la subred deben tener la misma versión de SKU. Por
ejemplo, puede tener dos implementaciones de puerta de enlace de aplicaciones diferentes
con la SKU Standard_v2. Pero no puede tener dos puertas de enlace de aplicaciones en la
misma subred: una con Standard y la otra con Standard_v2. La figura 2-5 muestra la
pantalla Crear puerta de enlace de aplicaciones con una red virtual y una subred existentes
seleccionadas.
FIGURA 2-5 Puerta de enlace de aplicaciones con red existente seleccionada
Bastión
Azure Bastion no se menciona específicamente en ninguno de los objetivos del examen,

pero podría clasificarse como un "servicio de plataforma integrada de red virtual". Bastion
es un servicio PaaS que proporciona conectividad de gestión segura, ya sea RDP o SSH, a
máquinas virtuales en una red virtual. Este acceso seguro se proporciona al abrir el puerto
HTTPS 443 al servicio Bastion, pero no requiere ningún puerto o dirección IP abierta a
Internet desde máquinas virtuales individuales.
Bastion requiere una subred dedicada en la red virtual con el nombre específico
de AzureBastionSubnet , con un prefijo de subred de al menos /27. La figura 2-6 muestra el
error de Azure Portal si intenta usar una red virtual existente que no tiene la subred
predefinida.
FIGURA 2-6 Servicio de bastión sin AzureBastionSubnet
Al igual que con Azure Firewalls, si crea AzureBastionSubnet manualmente con un

rango de direcciones que es demasiado pequeño, Azure Portal le dará un error que indica
que el prefijo debe ser al menos /27. La figura 2-7 muestra el mensaje de error del portal
cuando AzureBastionSubnet existe pero está mal configurado.
FIGURA 2-7 Servicio bastión con una subred demasiado pequeña
Puntos finales privados
Los puntos de conexión privados ofrecen un método para usar los servicios de PaaS de
Azure, que suelen ser puntos de conexión públicos, y asignar a ese servicio una dirección
IP privada en una subred dentro de una red virtual. Por ejemplo, en una configuración
predeterminada, si una máquina virtual se conecta a una cuenta de almacenamiento de
Azure para un archivo de blob, la máquina virtual se comunicaría con
storageaccount.blob.core.windows.net y el nombre DNS se resolvería en una dirección IP
pública.
Si configura un punto de conexión privado con la cuenta de almacenamiento, puede

asociar esa cuenta de almacenamiento con una subred. Luego, las máquinas virtuales en la
misma red virtual resolverían y se conectarían a la cuenta de almacenamiento mediante la
dirección IP privada asignada. Las máquinas virtuales o los servicios fuera de la red virtual
aún se resolverían y se conectarían a la dirección IP pública. Los puntos finales privados y
de servicio se analizan con más detalle en el Capítulo 5 .
Planificar y configurar la delegación de subredes
Los recursos de Azure, incluidas las redes virtuales, se administran mediante el control de
acceso basado en roles (RBAC). Como propietario de un recurso, si necesita permitir que
otros administradores realicen acciones de administración en el recurso, debe asignar una
función al usuario o grupo. Si necesita asignar permisos al recurso a otro servicio de Azure,
puede delegar esa administración, lo que permite la integración de los servicios de Azure
con una subred.
Delegar una subred es similar a asignar un rol a un usuario que tiene permisos para
cambiar el recurso. Al delegar la subred a otro servicio de Azure, ese servicio puede
modificar la configuración de la subred para proporcionar una configuración administrada y
recomendada.
La delegación de subred se puede configurar durante la creación de la subred o después

de que se haya creado la subred. La función Colaborador de la red es la función de nivel
más bajo que tiene los permisos adecuados para delegar la subred a un servicio. La Figura
2-8 muestra el menú desplegable Delegar subred a un servicio de una subred existente.
FIGURA 2-8 Delegación de subred
Planificar y configurar subredes para Azure Route Server
Azure Route Server es un servicio que simplifica el enrutamiento para la conectividad

híbrida. Desde la perspectiva de una red virtual, es similar a los otros servicios discutidos
en esta sección de habilidades en que requiere una subred dedicada con un nombre
específico: RouteServerSubnet . Además, el tamaño mínimo de la subred es /27. La red
virtual que contiene esta subred debe estar en la misma región de Azure que el servidor de
ruta que planea implementar.
Habilidad 2.2: Diseñar e implementar la resolución de nombres
La resolución de nombres es una parte crítica de cualquier diseño de infraestructura, y

quizás más en un entorno de nube. En un entorno local, los nombres prevalecen y se usan
comúnmente, perose asignan a direcciones IP estáticas muchas veces y, por lo tanto, no
cambian con frecuencia. Sin embargo, en la nube, cada vez más direcciones y servicios
utilizan direcciones IP dinámicas, lo que hace que el DNS sea mucho más
importante. Azure tiene dos soluciones DNS principales, zonas DNS públicas y privadas,
que se analizan en esta sección de habilidades.

 Diseñar zonas DNS públicas
 Diseñar zonas DNS privadas
 Resolución de nombres de diseño dentro de una red virtual
 Configurar una zona DNS pública o privada
 Vincular una zona DNS privada a una red virtual
Diseñar zonas DNS públicas
Azure DNS es un servicio PaaS que proporciona un servicio de DNS autorizado para un
nombre de dominio en su entorno. El nombre de dominio debe ser un dominio público para
el que pueda configurar los servidores de nombres. Después de crear la zona DNS pública,
debe cambiar los servidores de nombres con el registrador de dominios para que los
registros que cree funcionen correctamente. Esto tendrá un impacto en cualquier
configuración de DNS existente.
Para crear una zona DNS pública, siga estos pasos:

2. En la barra de búsqueda, busca y selecciona Zonas DNS .
3. En la página de zonas DNS, haga clic en Crear .
4. En el menú desplegable Suscripción, seleccione la suscripción para crear la
zona.
5. En el menú desplegable Grupo de recursos, cree o seleccione un grupo de
recursos para organizar lógicamente el recurso.
6. En el campo Nombre, proporcione un nombre de dominio válido de su
propiedad, por ejemplo, az700examref.com .
Figura 2-9 muestra la configuración completa.
FIGURA 2-9 Crear zona DNS
Después de crear la zona DNS, tome nota de los servidores de nombres proporcionados
por el servicio de Azure. Estos servidores de nombres deben configurarse con el dominio
para que los registros que cree se resuelvan correctamente. Cada registrador tiene sus
propios pasos y métodos para actualizar los servidores de nombres para sus nombres de
dominio. La Figura 2-10 muestra los servidores de nombres asignados a la nueva zona
az700examref.com.
FIGURA 2-10 Servidores de nombres asignados
Una vez que haya realizado el cambio del servidor de nombres con el registrador de
dominios, puede verificar que el cambio se propague con precisión en Internet
utilizando nslookup . La Figura 2-11 muestra la utilidad nslookup que se usa para consultar
los servidores de nombres para el dominio az700examref.com.
FIGURA 2-11 utilidad nslookup
Diseñar zonas DNS privadas
Las zonas DNS privadas son similares a las zonas públicas en el sentido de que todavía
contienen registros de recursos e incluso pueden ser nombres de dominio público. Sin
embargo, con una zona privada, no necesita modificar los servidores de nombres
públicos. En su lugar, vincula la zona DNS privada a las redes virtuales en las que desea
que funcione la resolución de nombres. La resolución solo ocurrirá desde dentro de la red
virtual, y no de forma externa o pública. Esto significa que el nombre de dominio ni
siquiera necesita ser un dominio válido o enrutable.
Para crear una zona DNS privada, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Zonas DNS privadas .
3. En la página Zonas DNS privadas, haga clic en Crear .
4. En el menú desplegable Suscripción, seleccione la suscripción para crear la
zona.
5. En el menú desplegable Grupo de recursos, cree o seleccione un grupo de
recursos para organizar lógicamente el recurso.
6. En el campo Nombre, proporcione un nombre de dominio válido de su
propiedad, por ejemplo, az700examref.private .
FIGURA 2-12 Creación de zona DNS privada
NOTA USO DE DOMINIOS DE NIVEL

SUPERIOR ALTERNATIVOS
Aunque estamos usando un nombre de dominio de nivel superior (TLD) .private en
este escenario para mostrar que el servicio lo admite, no se recomienda usar TLD
alternativos porque no todos los sistemas operativos los admiten.
Una vez que se crea una zona DNS privada y se vincula a una red virtual, la resolución
de nombres se produce dentro de la red virtual. El diagrama de la Figura 2-13 muestra los
tres pasos para que la VM1 resuelva la dirección IP de la VM2:
FIGURA 2-13 Pasos de DNS privado
1. VM1 desea conectarse a VM2.az700examref.private pero no conoce la

dirección IP y la solicita al servidor DNS de la red virtual.
2. La zona DNS privada tiene un registro para VM2 y responde a la solicitud
de DNS con una dirección IP de 10.0.0.4.
3. Luego, la VM se conecta directamente a la VM2 mediante la dirección IP
10.0.0.4.
Resolución de nombres de diseño dentro de una red virtual
Determinar si usar zonas DNS públicas, zonas DNS privadas o una combinación de las dos
es el factor principal para diseñar cómo funciona la resolución de nombres en el
entorno. Las zonas privadas le brindan la flexibilidad de usar una solución de nombres
deseada dentro de su red virtual sin modificar los registros DNS públicos externos. Las
zonas privadas también le brindan la capacidad de configurar DNS de "horizonte dividido"
donde el mismo nombre completo, como app1.contoso.com, se resuelve en un servicio
internamente y otro servicio externamente. Otros beneficios de usar zonas privadas
incluyen:
 Gestión automática de nombres de host

 Resolución de nombres de host entre redes virtuales
 Búsquedas inversas de DNS, pero solo dentro de la red virtual
Las zonas DNS privadas también tienen limitaciones. Cuando se utiliza el registro
automático de nombres de host, la red virtual solo se puede vincular a una zona DNS
privada. La zona DNS aún puede tener varias redes virtuales vinculadas. Otra limitación es
que el reenvío condicional no tiene soporte nativo y requiere una configuración adicional
para resolver nombres locales.
Tanto las zonas de DNS públicas como las privadas de Azure usan la misma dirección
IP dedicada para las consultas de DNS: 168.63.129.16. Esta es una dirección IP estática y
no cambia por zona, suscripción o arrendatario.
Configurar una zona DNS pública o privada
Tanto las zonas DNS públicas como las privadas admiten los tipos de registros DNS
comunes:
 A
 AAAA
 CNOMBRE
 MX
 PTR
 SRV
 TXT
Para crear un nuevo registro, siga estos pasos:

3. Haz clic en el nombre de la zona privada que has creado previamente.
4. En la zona privada, haga clic en + Conjunto de registros .
5. En el campo Nombre, proporcione un nombre para el registro como parte
del nombre de dominio completo, como app1 .
6. En el menú desplegable Tipo, seleccione el tipo de registro deseado. En este
ejemplo, seleccione CNAME .
7. Deje el valor predeterminado de TTL, que es la cantidad de tiempo que el
registro DNS se almacenará en caché antes de volver a buscarlo.
8. Proporcione un alias para el registro CNAME, que es a donde DNS
redirigirá la solicitud de conexión. En este ejemplo, utilice www.microsoft.com .
9. Haga clic en Aceptar . La Figura 2-14 muestra la configuración completa.
FIGURA 2-14 Agregar conjunto de registros
El proceso para crear un conjunto de registros para una zona DNS pública es el
mismo. Con las zonas DNS públicas, también tiene la capacidad de crear tipos de registros
CAA y NS. De lo contrario, los pasos son similares para agregar un registro en una zona
DNS pública o privada.
Vincular una zona DNS privada a una red virtual
Para que una zona DNS privada devuelva consultas, debe estar vinculada a una red
virtual. La creación de una zona DNS privada y la adición de entradas de registro no hacen
la asociación con una red virtual. Para vincular una zona DNS privada a una red virtual,
siga estos pasos:

3. Haz clic en el nombre de la zona privada que has creado previamente.
4. Haga clic en la hoja Vínculos de red virtual .
5. Haga clic en + Agregar .
6. Proporcione un nombre para la asociación porque la zona DNS privada se
puede vincular con varias redes virtuales. En este ejemplo, use eus-vnet01 .
7. En el menú desplegable Suscripción, seleccione la suscripción donde se
encuentra la red virtual.
8. En el menú desplegable Red virtual, seleccione la red virtual con la que
desea realizar la asociación. Si no tiene acceso directo a la red virtual y la red virtual
está en una suscripción diferente que no administra, seleccione la casilla de
verificación Sé el ID de recurso de la red virtual y obtenga la ruta completa del
otro propietario de la suscripción.
9. Si desea el registro automático de recursos en la red virtual con la zona DNS
privada, seleccione la casilla de verificación. Sin embargo, esto evitará que la red
virtual se vincule a cualquier otra zona DNS privada.
FIGURA 2-15 Agregar enlace de red virtual
Habilidad 2.3: Diseñar e implementar conectividad entre redes virtuales
Cuando está diseñando una zona de aterrizaje de tamaño mediano o empresarial, lo más
probable es que tenga varias suscripciones y, por lo tanto, varias redes. Sin embargo, el
hecho de que las aplicaciones estén segmentadas por suscripción no significa que dos
aplicaciones nunca se comunicarán. Además, cuando tiene recursos híbridos con VPN o
conectividad ExpressRoute en una suscripción compartida, es posible que la aplicación
necesite usar estas conexiones. Esta sección de habilidades se centra en la conexión de
redes mediante el emparejamiento de redes virtuales y las puertas de enlace de redes
virtuales.

 Implementar emparejamiento de red virtual
 Encadenamiento de servicios de diseño, incluido el tránsito de puerta de
enlace
 Diseñar conectividad VPN entre redes virtuales
Implementar emparejamiento de red virtual
Si bien una sola red es escalable y puede admitir miles de máquinas y servicios virtuales,
no se recomienda tener una sola red virtual. La arquitectura de referencia para una zona de
aterrizaje a escala empresarial, e incluso para implementaciones medianas, incluye una
arquitectura hub-and-spoke. Creamos esta arquitectura en Azure mediante el uso de una red
virtual como red central, que puede contener otros recursos de conectividad, como VPN y
ExpressRoute (discutidos en el Capítulo 1 ). Luego, cada aplicación podría estar
representada por una red radial, pero sería una red virtual separada que incluso podría estar
en una suscripción diferente.
¿NECESITA MÁS REVISIÓN? ZONA DE

ATERRIZAJE A ESCALA
EMPRESARIAL
Para obtener más información sobre una zona de aterrizaje a escala empresarial,
visite https://docs.microsoft.com/en-us/azure/cloud-adoption-
framework/ready/enterprise-scale/architecture .
La red central contiene no solo la conectividad adicional, sino también probablemente

otros recursos de supervisión o cumplimiento. El siguiente paso es determinar cómo la red
radial puede comunicarse con la red central. El método más sencillo para facilitar esta
conectividad es utilizar el emparejamiento de redes virtuales. El requisito principal para
usar el emparejamiento de redes virtuales es que los dos espacios de direcciones de redes
virtuales no se puedan superponer.
La configuración del emparejamiento entre dos redes virtuales básicamente amplía la

red mediante la red troncal de Azure. La comunicación de red es la conectividad privada
entre las dos redes. La figura 2-16 muestra una configuración de ejemplo de una conexión
de emparejamiento entre las regiones Este de EE. UU. y Reino Unido Sur de Azure.
FIGURA 2-16 Emparejamiento de red virtual
El diagrama de la figura 2-16 también implica un par de cosas más que debe saber sobre
el emparejamiento de redes virtuales:
 Admite tanto unidireccional como bidireccional.

 Las redes virtuales pueden estar en la misma o en diferentes regiones de
Azure.
 Las redes virtuales pueden estar en las mismas o diferentes suscripciones.
En este escenario, VM1 y VM2 podrían comunicarse entre sí a través de cualquier

puerto y protocolo a través de las redes virtuales sin ninguna configuración
adicional. Cuando crea una conexión de emparejamiento desde el portal, proporciona las
opciones para una conexión bidireccional. Cada opción se presenta dos veces en la interfaz:
una para esta red virtual al remoto. Luego, al revés: de la red virtual remota
a esta red. Esta red es la red desde la que está realizando la configuración. La Tabla 2-
1 describe las opciones de configuración que están disponibles al configurar el intercambio
de tráfico.
TABLA 2-1 Opciones de interconexión de redes virtuales
Ajuste esta red virtual red virtual remota
Nombre del enlace de Nombre para mostrar Nombre para mostrar

emparejamiento
Tráfico a la red virtual remota Permitir Permitir
(predeterminado) (predeterminado)
Bloquear Bloquear
Tráfico reenviado desde una Permitir Permitir

red virtual remota (predeterminado) (predeterminado)
Bloquear Bloquear
Puerta de enlace de red virtual Usar la puerta de enlace Usar la puerta de enlace
o servidor de ruta de esta red de esta red
Usar la puerta de enlace Usar la puerta de enlace

remota remota
Ninguno Ninguno
(predeterminado) (predeterminado)
Para crear una interconexión utilizando dos redes virtuales que ya se crearon, siga estos
pasos:

3. Haga clic en el nombre de una de las redes virtuales en las que desea
configurar el intercambio de tráfico. En este ejemplo, configuraremos desde la red
radial hasta la red central.
4. Haga clic en la hoja Peerings .
5. Haga clic en + Agregar .
6. En el campo Nombre del vínculo de intercambio de tráfico para esta red
virtual, proporcione un nombre para la conexión. Por ejemplo, ingrese Spoke-to-
Hub , ya que estamos configurando desde Spoke.
7. Para el tráfico a la red virtual remota y el tráfico reenviado desde
la configuración de la red virtual remota, acepte el valor predeterminado Permitir .
8. En la configuración Puerta de enlace de red virtual o Servidor de ruta, acepte
el valor predeterminado Ninguno .
9. En el campo Nombre del enlace de intercambio de tráfico para la red virtual
remota, proporcione un nombre como hub-to-spoke .
10. Si la red virtual está en la misma suscripción, seleccione la suscripción y la
red virtual adecuadas de cada lista desplegable. Si no tiene acceso a la suscripción,
seleccione la casilla de verificación Conozco mi ID de recurso y obtenga la ID del
propietario de la suscripción remota.
11. Para el tráfico a la red virtual remota y el tráfico reenviado desde
la configuración de la red virtual remota, acepte el valor predeterminado Permitir .
12. En la configuración Puerta de enlace de red virtual o Servidor de ruta, acepte
el valor predeterminado Ninguno .
13. Haga clic en Agregar . La Figura 2-17 muestra una parte de la
configuración completa.
FIGURA 2-17 Agregar emparejamiento
Después de completar la interconexión, el par con el estado se mostrará en la hoja

Intercambios de ambas redes virtuales y debería tener el estado Conectado . La Figura 2-
18 muestra la hoja Peerings después de una conexión exitosa.
FIGURA 2-18 Compañero conectado
Encadenamiento de servicios de diseño, incluido el tránsito de puerta de enlace
Cuando conecta dos redes virtuales con intercambio de tráfico, de forma predeterminada
existe una comunicación completa entre las dos redes. Una forma de pensar en esta
conexión es que es esencialmente una ruta estática desde el espacio de direcciones de una
red al espacio de direcciones de la segunda red. Luego, para fines de enrutamiento, estas
rutas estáticas no se anuncian a ninguna otra red virtual.
Debido a que esta ruta no se anuncia, cuando tiene dos (o más) redes radiales conectadas
a un concentrador, no significa que los radios puedan comunicarse entre sí. Por ejemplo,
en la Figura 2-19 , hay dos redes radiales, Spoke1 y Spoke2, conectadas con intercambio de
tráfico a una red central.
FIGURA 2-19 Emparejamiento con múltiples radios
En el escenario que se presenta en la Figura 2-19 , aunque ambas redes radiales están
conectadas con interconexión con el concentrador, las dos redes radiales no pueden
comunicarse de forma predeterminada. La conexión está ahí, pero debido a la falta de
anuncios de ruta, la red 10.2.0.0 en Spoke2 no sabe cómo ni a dónde enviar el tráfico que
podría estar destinado a la red 10.1.0.0 en Spoke1.
Existen dos opciones para facilitar esta comunicación:
 Tabla de ruteo
 Puerta de enlace de red virtual (u otro servidor de ruta)
La más simple y rudimentaria de estas opciones es una tabla de rutas. Puede crear una
tabla de enrutamiento, asociarla con las subredes en la red virtual Spoke2 y enumerar una
dirección IP de siguiente salto en la red central que luego puede enrutar el tráfico a
Spoke1. Si bien esta es una configuración válida, la sobrecarga administrativa puede
volverse inmanejable a medida que escala. Las tablas de rutas se analizan con más detalle
en el Capítulo 3 .
La solución escalable es utilizar una puerta de enlace de red virtual u otro servidor de
rutas para facilitar el enrutamiento. Volviendo a la Figura 2-17 , cuando crea una conexión
de emparejamiento, tiene la opción de usar una puerta de enlace en una o ambas redes
virtuales. Esta asociación luego permite que la red virtual emparejada se comunique con
otro entorno local o del mismo nivel a través de una VPN o ExpressRoute que se define
como parte de la puerta de enlace de la red virtual.
Diseñar conectividad VPN entre redes virtuales
El emparejamiento de redes virtuales no siempre ha sido el método disponible para

conectar dos redes virtuales. La opción heredada para conectar dos redes virtuales es
simplemente establecer una conexión VPN entre ellas. Esto no es diferente de las
conexiones VPN de sitio a sitio que se discutieron en el Capítulo 1 .
Si bien podría considerarse un método heredado de implementación, hay un par de

escenarios en los que podría preferir usar una VPN en lugar de usar la interconexión. De
forma predeterminada, el intercambio de tráfico permite la comunicación completa entre las
dos redes que se intercambian, pero no es una conexión cifrada. Si utiliza un protocolo sin
cifrar, como HTTP o FTP, el tráfico entre redes virtuales, aunque sea privado en la red de
Microsoft, sigue siendo técnicamente sin cifrar. Si tiene casos de uso o escenarios de
cumplimiento en los que todo el tráfico debe cifrarse y se ve obligado a utilizar protocolos
no cifrados, debe considerar el uso de una VPN.
La posible desventaja de usar una VPN es que introduce otra dirección IP pública para
administrar en la puerta de enlace de la red virtual, y tiene limitaciones de ancho de banda
según el SKU de la puerta de enlace que seleccione, que se analiza en detalle en el Capítulo
1.
El escenario más probable es que probablemente utilice tanto la interconexión como las
VPN en su diseño. Para las aplicaciones que requieren niveles adicionales de encriptación,
cumplimiento o conexiones a proveedores externos, las VPN pueden ser más
adecuadas. Para las conexiones internas que ya usan conexiones TLS, la interconexión
podría ser más adecuada.
Habilidad 2.4: Diseñar e implementar una arquitectura Azure Virtual WAN
En esta sección, presentamos y analizamos Azure Virtual WAN, que proporciona un

servicio de nube administrado que facilita la conectividad transitiva entre sitios a través de
VPN, ExpressRoute y redes virtuales. En el escenario en el que existen varias ubicaciones
locales, y cada una requiere una VPN más conexiones de clientes individuales que utilizan
VPN de punto a sitio, la conectividad híbrida puede continuar aumentando la sobrecarga de
administración. Virtual WAN simplifica la configuración al llevar todos los servicios a una
ubicación, y luego brinda la capacidad de que las diversas conexiones se comuniquen entre
sí a través del concentrador en Virtual WAN.
 Diseñe una arquitectura de Azure Virtual WAN, incluida la selección de
SKU y servicios
 Crear un concentrador en Virtual WAN
 Conectar una puerta de enlace de red virtual a Azure Virtual WAN
 Crear un dispositivo virtual de red en un centro virtual
 Configurar el enrutamiento del centro virtual
Diseñe una arquitectura de Azure Virtual WAN, incluida la selección de SKU y servicios
Hasta ahora, en los capítulos 1 y 2 , hemos discutido los métodos de conectividad híbrida
con VPN y ExpressRoute, y la conectividad nativa de Azure con redes virtuales. En un
entorno en el que puede haber varias conexiones VPN de punto a sitio y de sitio a sitio,
ExpressRoute y conexiones de red virtual a red virtual, la administración de los distintos
tipos de conexión puede convertirse en una carga administrativa. Azure Virtual WAN es
una solución de administración y conectividad para unir estas conexiones. Hay dos SKU de
Virtual WAN:
 Básico
 Estándar
El tipo de SKU básico solo admite conexiones VPN de sitio a sitio. El SKU estándar
puede admitir varios tipos de conexión:
 VPN de sitio a sitio

 VPN de punto a sitio
 ExpressRoute
 Conectividad entre centros
 cortafuegos azul
 Dispositivos virtuales de red
La WAN virtual actúa como un concentrador central para estos diversos tipos de
conexión en un modelo concentrador y radial. Utilice Virtual WAN para centralizar estas
conexiones y proporcionar conectividad transitiva entre los diferentes tipos de
conexiones. La Figura 2-20 muestra una implementación de Virtual WAN en una sola
región con varios tipos de conexión.
FIGURA 2-20 WAN virtual de región única
Para crear una WAN virtual de Azure, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione WAN virtuales .
3. En la página WAN virtuales, haga clic en Crear .
4. En el menú desplegable Suscripción, seleccione la suscripción deseada para
agregar la WAN virtual.
5. En el menú desplegable Grupo de recursos, seleccione un grupo de recursos
para organizar el recurso. Para este ejemplo, cree o seleccione un grupo
llamado Redes .
6. En la ubicación del grupo de recursos, seleccione la ubicación donde se debe
implementar el recurso. Para este ejemplo, seleccione Este de EE. UU .
7. En el campo Nombre, proporcione un nombre para el recurso,
como VWAN-EUS .
8. En el menú desplegable Tipo, seleccione la SKU deseada de Virtual WAN,
como Estándar . La Figura 2-21 muestra los campos completados.
FIGURA 2-21 Crear una WAN virtual
9. Haga clic en Revisar + Crear y, a continuación, haga clic en Crear .
A medida que planifica el diseño de un modelo de conectividad híbrida, puede

considerar el uso de dispositivos de terceros para el lado local de la conectividad. Virtual
WAN tiene una lista de socios aprobados con guías prácticas de implementación a partir de
este escrito:
 Barracuda Redes
 punto de control
 cisco meraki
 Citrix
 Cloudgenix
 Fortinet
 HPE Aruba
 NetFoundry
 Nuage/Nokia
 Sistemas abiertos
 Redes de Palo Alto
 Tecnología de lecho de río
 pico plateado
 SD-WAN de VMware
 viceversa
¿NECESITA MÁS REVISIÓN? GUÍAS DE

IMPLEMENTACIÓN DE SOCIOS
Para obtener más información sobre los socios de dispositivos aprobados y las guías
prácticas, visite https://docs.microsoft.com/en-us/azure/virtual-wan/virtual-wan-
locations-partners .
Crear un concentrador en Virtual WAN
La primera parte de la WAN virtual que se requiere es un concentrador. El concentrador es

una red virtual que crea "dentro" de la WAN virtual. Esta red central es la red transitiva que
proporcionará conectividad a los demás servicios que conecte a su WAN virtual.
Cuando crea un concentrador, hay un par de requisitos que el concentrador debe cumplir
para poder conectar los diversos servicios. En primer lugar, ningún espacio de direcciones
de red virtual o local no se puede superponer, incluido el espacio de direcciones privado
que especifica al crear la WAN virtual. En segundo lugar, ninguna red virtual existente
puede tener una puerta de enlace de red virtual asociada con la red virtual. Si la red virtual
tiene una puerta de enlace, debe eliminarse antes de conectarla al concentrador.
Para crear un concentrador en una WAN virtual existente, siga estos pasos:

3. En la página Virtual WAN, seleccione el recurso de Virtual WAN existente.
4. En el recurso de Virtual WAN, haga clic en la hoja Hubs .
5. En la hoja Hubs, haga clic en + New Hub .
6. En el menú desplegable Región, seleccione la región de Azure para
implementar el concentrador, como Este de EE. UU .
7. En el campo Nombre, proporcione un nombre para el concentrador,
como vwan-eus-hub .
8. En el campo Espacio de direcciones privadas del concentrador, proporcione
un espacio de direcciones para el concentrador, como 10.10.0.0/16 . Recuerde que
este espacio de direcciones no puede superponerse con ninguna red virtual o entorno
local que se conecte a él. La Figura 2-22 muestra la pestaña Conceptos básicos de la
página Crear centro virtual.
FIGURA 2-22 Conceptos básicos del centro virtual
9. Las pestañas Sitio a sitio, Punto a sitio y ExpressRoute le permiten crear

estas conexiones al mismo tiempo que el concentrador, pero no son necesarias en
este momento. Haga clic en Revisar + Crear y, a continuación, haga clic
en Crear .
Conectar una puerta de enlace de red virtual a Azure Virtual WAN
Como sugiere el título de esta sección, la lista de objetivos de este examen hace referencia a
la conexión de una puerta de enlace de red virtual a una WAN virtual. Sin embargo, los
sitios de VPN que define en una WAN virtual están separados de las puertas de enlace de la
red virtual y las VPN que crea allí. No necesita crear una puerta de enlace de red virtual y
luego asociar la VPN a la WAN virtual.
En su lugar, crea un sitio VPN dentro de la WAN virtual. El sitio VPN puede tener
múltiples enlaces al sitio físico al que se está conectando. Además, puede configurar el
escalado de la solución WAN virtual como parte del sitio.
Para crear un sitio VPN en una WAN virtual, siga estos pasos:

4. En el recurso de Virtual WAN, haga clic en la hoja Sitios de VPN .
5. En la hoja de sitios de VPN, haga clic en Crear sitio .
6. En el menú desplegable Región, seleccione una región para el sitio VPN,
como Este de EE. UU .
7. En el campo Nombre, especifique un nombre para el sitio VPN,
como branch1-vpn .
8. En el campo Proveedor del dispositivo, especifique el nombre del proveedor
del dispositivo remoto, como Barracuda .
9. En el campo Espacio de direcciones privado, especifique el espacio de
direcciones de la ubicación local (o remota), como 192.168.0.0/24 . La Figura 2-
23 muestra la configuración completa.
FIGURA 2-23 Crear sitio VPN
10. Haga clic en Siguiente: Enlaces .

11. Complete los campos de enlace utilizando la siguiente información, que
también se muestra en la Figura 2-24 :
FIGURA 2-24 Vínculos de sitios VPN
1. Nombre del enlace: Branch1-Link

2. Velocidad de enlace: 50
3. Nombre del proveedor del enlace: Nivel 3
4. Dirección IP del vínculo/FQDN: vpnlink.contoso.com
5. Enlace dirección BGP: en blanco
6. Enlace ASN: en blanco
12. Haga clic en Siguiente: Revisar + crear y luego haga clic en Crear .
Puede agregar hasta cuatro enlaces por sitio VPN, lo que permite una conexión multi-
homed a través de diferentes proveedores. El valor de la velocidad del enlace se define en
Mbps y debe representar la velocidad disponible en la sucursal que utiliza la dirección IP o
el FQDN que defina.
Después de crear el sitio VPN, debe asociar el sitio con el concentrador que creó
anteriormente. Pero para hacer eso, primero necesita una puerta de enlace VPN asociada
con el concentrador. Para crear una puerta de enlace VPN en Virtual WAN, siga estos
pasos:

5. En el menú desplegable Unidades de escala de puerta de enlace, seleccione
la escala y el rendimiento deseados. Por ejemplo, seleccione 1 unidad de escala:
500 Mbps x 2 . La Figura 2-25 muestra la configuración de creación de puerta de
enlace.
FIGURA 2-25 Crear puerta de enlace VPN
Tenga en cuenta que la interfaz Create VPN Gateway no le permite editar el número de
AS para el dispositivo; está configurado en 65515. También toma alrededor de 30 minutos
para que la puerta de enlace se implemente y se asocie con el concentrador. No puede
conectarse a un sitio VPN hasta que se haya creado la puerta de enlace.
Una vez que la puerta de enlace termine de implementarse, puede conectar el sitio VPN
que se creó anteriormente al concentrador. Esto también es cuando define la configuración
de VPN, como el protocolo, la política IPSec y el enrutamiento.
Para conectar el sitio VPN al concentrador, siga estos pasos:

5. Seleccione el nombre del concentrador que creó anteriormente, como vwan-
eus-hub .
6. En la página central, haga clic en la hoja VPN (sitio a sitio) .
7. En la hoja de VPN, haga clic en borrar todos los filtros para mostrar el
concentrador.
8. Seleccione la casilla de verificación junto al concentrador que se creó
anteriormente y luego haga clic en Conectar sitios VPN , como se muestra en
la Figura 2-26 .
FIGURA 2-26 Conectar sitios VPN
9. En el campo Clave precompartida, ingrese el secreto que coincida con la

configuración remota.
10. Deje los campos restantes configurados con sus valores predeterminados y
haga clic en Conectar , como se muestra en la Figura 2-27 .
FIGURA 2-27 Sitios de conexión
Si selecciona Personalizado para el protocolo IPsec, puede modificar la vida útil de

SA, la fase 1 de IKE y la configuración de la fase 2 de IKE para el túnel
VPN. Cuando haga clic en Conectar, asociará la conexión de la sucursal (VPN) al
centro virtual, creando el primer radio en la arquitectura de centro y radio.
Crear un dispositivo virtual de red en un centro virtual
Al momento de escribir este artículo, hay tres proveedores externos para dispositivos
virtuales de red (NVA) en un entorno de WAN virtual:
 Barracuda CloudGen WAN

 Cisco Cloud OnRamp para múltiples nubes
 SD-WAN de VMware
Estos NVA están destinados a conectarse al equipo local correspondiente para

proporcionar una WAN integral definida por software (SD-WAN). Cuando implementa un
NVA en un concentrador en Virtual WAN, implementa la oferta correspondiente del
proveedor externo del mercado de Azure.
Para crear un NVA en un concentrador, siga estos pasos:

eus-hub .
6. En la página central, haga clic en la hoja Dispositivo virtual de red .
7. Haga clic en Crear dispositivo virtual de red .
8. En el menú desplegable Dispositivo virtual de red, seleccione el dispositivo
del proveedor deseado. Por ejemplo, seleccione baracudasdwanrelease , como se
muestra en la Figura 2-28 .
FIGURA 2-28 Dispositivo virtual de red

10. Será redirigido a Azure Marketplace, donde podrá implementar el
dispositivo del proveedor. Haga clic en Get It Now , como se muestra en la Figura
2-29 .
FIGURA 2-29 Azure Marketplace NVA
Después de hacer clic en Obtenerlo ahora, se le pedirá que proporcione sus datos de
contacto, que se compartirán con el proveedor antes de que pueda implementar el
dispositivo.
Configurar el enrutamiento del centro virtual
El centro virtual de Virtual WAN es el punto de conexión central para todas las VPN de
sitio a sitio, VPN de punto a sitio, ExpressRoute y redes virtuales. Uno de los beneficios del
centro virtual es la conectividad transitiva entre estas diversas conexiones, que puede
proporcionar hasta 50 Gbps de rendimiento agregado.
Cuando crea un centro virtual, se crean dos tablas de enrutamiento,
denominadas Ninguna y Predeterminada, dentro del centro. Todos los tipos de conexión se
asocian inicialmente con la tabla de enrutamiento predeterminada para permitir la
conectividad transitiva entre las diversas conexiones. Cada conexión que agrega al
concentrador agrega el prefijo de enrutamiento a la tabla de rutas. La tabla de rutas se
propaga a las distintas conexiones mediante el Protocolo de puerta de enlace fronteriza
(BGP). Si necesita evitar que las rutas se propaguen a otras conexiones, puede asociar la
conexión con la tabla de rutas Ninguna.
Puede controlar qué conexiones reciben propagación de rutas configurando tablas de

rutas adicionales y personalizando las asociaciones entre la conexión y las distintas tablas
de rutas. Una forma de facilitar esto es crear etiquetas para identificar la asociación entre la
conexión y la tabla de rutas.
Para crear una tabla de rutas en un centro virtual, siga estos pasos:

eus-hub .
6. En la página central, haga clic en la hoja Enrutamiento .
7. Haga clic en Crear tabla de rutas .
8. Proporcione un nombre para la tabla de rutas, como Branch2Branch .
9. En la tabla de rutas, especifique un nombre para la ruta, como Branch1 .
10. En el menú desplegable Tipo de destino, seleccione CIDR .
11. En el campo Prefijo de destino, proporcione el intervalo de direcciones para
el destino, como 172.16.0.0/16 .
12. En el menú desplegable Siguiente salto, seleccione el salto por el que se
debe reenviar el tráfico. La Figura 2-30 muestra la pestaña Conceptos básicos de la
pantalla Crear tabla de rutas.
FIGURA 2-30 Conceptos básicos de la creación de una tabla de rutas
13. Haga clic en Siguiente: Etiquetas .

14. En el campo Nombre de etiquetas, proporcione una etiqueta para la tabla de
rutas, como Sucursales . La Figura 2-31 muestra la pestaña Etiquetas.
FIGURA 2-31 Crear etiquetas de tabla de rutas
15. Haga clic en Siguiente: Asociaciones . Si necesita administrar la asociación

entre la tabla de rutas y varias conexiones, puede configurarlas aquí.
16. Haga clic en Siguiente: Propagaciones .
17. Establezca "¿Propagar rutas desde conexiones a esta tabla de
rutas?" a Sí . También puede configurar la propagación desde otras tablas de rutas y
redes virtuales aquí. La figura 2-32 muestra una parte de la configuración.
FIGURA 2-32 Crear propagaciones de tabla de rutas
 Las redes virtuales son la infraestructura de comunicación central para una

suscripción y recursos de Azure.
 Las redes virtuales tienen un espacio de direcciones definido en notación
CIDR, a partir del cual se crean las subredes.
 Varios servicios de Azure requieren subredes dedicadas, a veces con
nombres específicos, para cada servicio, incluidas puertas de enlace de red virtual,
firewalls, puertas de enlace de aplicaciones y Bastion.
 La delegación de subred permite que otros recursos administren la red
automáticamente.
 Las zonas DNS públicas proporcionan una resolución de nombres autorizada
para nombres de dominio personalizados en Internet.
 Las zonas DNS privadas proporcionan resolución de nombres para recursos
internos dentro de la suscripción de Azure.
 Las redes virtuales se pueden vincular a zonas DNS privadas para facilitar la
resolución de nombres dentro de la red virtual automáticamente.
 Las redes virtuales se pueden conectar mediante emparejamiento, pero sus
espacios de direcciones no se pueden superponer.
 Los espacios de direcciones en una red virtual no se anuncian ni se propagan
con el emparejamiento y requieren tablas de rutas adicionales o puertas de enlace de
red virtual para crear una cadena de servicios.
 Peering no es un túnel encriptado; para escenarios que requieren
conectividad IPsec, se debe configurar una VPN entre redes virtuales.
 En una implementación híbrida a gran escala, Virtual WAN proporciona una
arquitectura de concentrador y radio en conexiones de punto a sitio, de sitio a sitio y
ExpressRoute.
 Un concentrador virtual en Virtual WAN facilita el modelo de concentrador
para las diversas conexiones.
 Una WAN virtual puede usar dispositivos virtuales de red de terceros para
conectarse a soluciones locales.
 La propagación de rutas se puede controlar con Virtual WAN mediante la
creación de tablas de rutas adicionales.
Experimento mental

Una organización está migrando una aplicación desde una ubicación conjunta local a
Azure. La infraestructura local actual admite múltiples aplicaciones y permanecerá en su
lugar después de la migración. La organización necesita una infraestructura de red híbrida
configurada entre su oficina principal, la ubicación compartida y la región de Azure
seleccionada.
La organización tiene una suscripción existente con recursos que se ejecutan en la

región Sur de Azure del Reino Unido. Después de la migración, los recursos existentes
deberán comunicarse con la aplicación migrada.
El diseño de la aplicación incluye el uso de una puerta de enlace de aplicaciones para el

tráfico de entrada a la aplicación y un Firewall de Azure para el tráfico de salida de la red
virtual. La aplicación también requiere un dominio personalizado dedicado para el tráfico
interno. La mayoría de los usuarios se conectarán desde Canadá y la organización ha
decidido implementar la aplicación en la región de Canadá este de Azure.
1. 1 . ¿Qué recurso debería crearse en Canada East?

2. 2 . ¿Cuál es la cantidad mínima de subredes que se requerirán? ¿Alguna subred
requiere una configuración específica?
3. 3 . ¿Qué se debe usar para facilitar la comunicación entre las dos regiones de
Azure?
4. 4 . ¿Qué se debe implementar para el dominio personalizado de la aplicación?
5. 5 . ¿Qué se debe implementar para facilitar la conectividad híbrida requerida?
Con la información anterior, ¿qué debe implementar la organización y cómo debe

configurarse?
1. 1 . La organización usa una región de Azure diferente para la nueva migración y,

por lo tanto, necesita una nueva red virtual que se implemente en el este de Canadá.
2. 2 . La red virtual necesitaría al menos tres subredes definidas: una para la puerta de
enlace de aplicaciones, otra para Azure Firewall y al menos una para la aplicación.
3. 3 . Para facilitar la comunicación entre el este de Canadá y el sur del Reino Unido,
las dos redes virtuales se pueden emparejar. Sin embargo, los espacios de
direcciones de las dos redes virtuales no se pueden superponer.
4. 4 . La región Este de Canadá necesitará una zona DNS privada para cumplir con el
requisito de que la aplicación debe tener una resolución de dominio personalizada
dedicada para el tráfico interno.
5. 5 . Para abordar los requisitos de conectividad híbrida, podemos considerar el uso
de varias puertas de enlace de red virtual con tablas de enrutamiento
personalizadas; o la organización puede implementar WAN virtual y conectar cada
sitio a través de un centro virtual. Sin detalles adicionales sobre planes futuros, la
WAN virtual podría no ser necesaria para una configuración de dos sitios. Sin
embargo, si la organización planea escalar a regiones adicionales, esto podría
facilitar mejor una arquitectura hub-and-spoke a través de las VPN.
Capítulo 3
Diseñar e implementar enrutamiento
El enrutamiento del tráfico es un componente central de cualquier tipo de implementación

de aplicaciones en su entorno de Azure. Este puede ser un tipo de tráfico "este-oeste"
dentro de la suscripción, de una red virtual a otra red o servicio. O puede ser un tipo de
tráfico "norte-sur" que fluye dentro y fuera de la aplicación.
El flujo de tráfico en su red virtual se puede manipular mediante rutas definidas por el
usuario (UDR). Luego, según el escenario, el tráfico entrante se puede distribuir entre
varios recursos de back-end mediante equilibradores de carga, puertas de enlace de
aplicaciones, Azure Front Door o Azure Traffic Manager. Para el tráfico saliente, puede
representar varias máquinas virtuales con una sola IP pública mediante una puerta de enlace
NAT. Todos estos servicios serán discutidos en este capítulo.
 Habilidad 3.1: Diseñar, implementar y administrar el enrutamiento de redes

virtuales
 Habilidad 3.2: Diseñar e implementar un equilibrador de carga de Azure
 Habilidad 3.3: Diseñar e implementar Azure Application Gateway
 Habilidad 3.4: Implementar Azure Front Door
 Habilidad 3.5: Implementar un perfil de Azure Traffic Manager
 Habilidad 3.6: Diseñar e implementar una NAT de Azure Virtual Network
Habilidad 3.1: Diseñar, implementar y administrar el enrutamiento de redes virtuales
El enrutamiento es uno de los componentes principales de la infraestructura de la red que

define cómo el tráfico sale del punto A y llega al punto B. Cuando crea una máquina virtual
en Azure, de forma predeterminada, puede comunicarse de forma saliente a Internet. En la
mayoría de las organizaciones, existen políticas de seguridad o cumplimiento que requieren
que este tráfico sea inspeccionado o auditado antes de salir a Internet. En estos escenarios,
se requiere crear tablas de rutas personalizadas para modificar el flujo de tráfico según el
destino. En esta sección de habilidades, analizamos la creación de estas UDR y cómo
configurar el enrutamiento personalizado para una red virtual.

 Diseñar e implementar rutas definidas por el usuario
 Asociar una tabla de rutas con una subred
 Configurar tunelización forzada
 Diagnosticar y resolver problemas de enrutamiento
Diseñar e implementar rutas definidas por el usuario
Cuando crea una red virtual, hay rutas de sistema predeterminadas que definen cómo los
recursos conectados a la red virtual pueden comunicarse con los servicios de Azure e
Internet. La Tabla 3-1 describe las rutas del sistema predeterminadas para una red virtual.
TABLA 3-1 Rutas predeterminadas de red virtual
Rango de direcciones de destino Siguiente salto

Espacio de direcciones de la red. red virtual
0.0.0.0/0 Internet
10.0.0.0/8 Ninguna
192.168.0.0/16 Ninguna
100.64.0.0/10 Ninguna
La primera ruta predeterminada está determinada por el espacio de direcciones que se ha

configurado para la red virtual. A continuación, siempre que el tráfico no esté destinado a
una red reservada de RFC 1918 o RFC 6598, el tráfico se envía a Internet. Si agrega rangos
de direcciones que están configurados de forma predeterminada en Ninguno a la red virtual,
entonces cambiará el próximo salto a la red virtual .
Si agrega emparejamiento de red virtual o una puerta de enlace de red virtual o

configura puntos finales de servicio, las rutas predeterminadas se modifican para incluir el
servicio que configura. Cuando configura el emparejamiento de redes virtuales, se agrega
una ruta predeterminada para el espacio de direcciones de la red virtual emparejada, que es
la razón subyacente por la que las redes virtuales emparejadas no pueden tener espacios de
direcciones superpuestos. La figura 3-1 describe la comunicación bidireccional con
emparejamiento de red virtual.
FIGURA 3-1 Comunicación bidireccional con emparejamiento de red virtual
Supongamos que en la Figura 3-1 , VM1 tiene una dirección IP de 10.0.0.4 y VM2 tiene
una dirección IP de 10.1.0.4. El flujo de tráfico se parecería a esta ruta:
1. Los paquetes salen de VM1 con destino a VM2 a través de la puerta de
enlace predeterminada de 10.0.0.1.
2. La puerta de enlace tiene una ruta a 10.1.0.0/16 mediante peering y reenvía
el paquete a 10.1.0.1.
3. La red virtual en 10.1.0.0/16 reconoce que el paquete está destinado a VM2
y lo reenvía en consecuencia.
4. VM2 recibe el paquete de VM1.
De forma predeterminada, cuando implementa una máquina virtual, puede y se

comunicará con Internet saliente a través de una dirección IP de Azure, incluso si la red
virtual no tiene un firewall asociado o si la VM no tiene asignada una dirección IP
pública. La dirección IP que la VM mostraría a los servicios de Internet variaría según la
región.
Hay varios escenarios en los que una organización querrá cambiar este flujo de tráfico y
no permitir que las máquinas virtuales se comuniquen directamente con Internet. O, incluso
si decide emparejar dos redes virtuales, en lugar de permitir todas las comunicaciones
predeterminadas, el tráfico primero se reenvía a través de un firewall u otro tipo de
dispositivo virtual de red. El mecanismo de invalidación para estos escenarios se denomina
UDR, que se configura mediante una tabla de rutas de Azure.
Para crear una tabla de rutas, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Tablas de ruta .
3. En la página Tablas de rutas, haga clic en Crear .
4. En el menú desplegable Suscripción, seleccione la suscripción para asociarla
con la tabla de rutas. Esta debe ser la misma suscripción que la red virtual.
para asociarlo con el recurso, como Redes .
6. En la lista desplegable Región, seleccione la región para asociarla con la
tabla de rutas. Esta también debe ser la misma ubicación que la red virtual. En este
ejemplo, seleccione Este de EE. UU .
7. En el campo Nombre, proporcione un nombre para la tabla de rutas,
como OutgoingProxy .
8. Deje el valor predeterminado Sí seleccionado para Propagar rutas de puerta
de enlace.
FIGURA 3-2 Crear tabla de rutas
Esto crea un objeto de tabla de rutas en la suscripción y la región especificadas. Según el

nombre que proporcionamos para la tabla de rutas, OutgoingProxy, usaremos el escenario
de dos máquinas virtuales en diferentes redes virtuales y forzaremos el tráfico saliente a
través de un dispositivo virtual de red.
Después de crear la tabla de rutas, hay dos pasos más para lograr el efecto deseado de
cambiar el flujo de tráfico: crear una ruta dentro de la tabla de rutas y asociar la tabla con
una subred. Para crear una ruta dentro de la tabla, siga estos pasos:

3. Seleccione la tabla de rutas OutgoingProxy que se creó anteriormente.
4. En la tabla, haga clic en la hoja Rutas .
5. En la hoja Rutas, haga clic en Agregar .
6. En el campo Nombre de la ruta, nombre la ruta ToNVA .
7. En el campo Prefijo de dirección, ingrese el prefijo de destino para el que
desea modificar el flujo de tráfico. Por ejemplo, para forzar todo el tráfico a través
de una NVA, especifique 0.0.0.0/0 .
8. En el menú desplegable Tipo de salto siguiente, seleccione Dispositivo
virtual .
9. En el campo Dirección del próximo salto, especifique la dirección IP de la
NVA que actuará como proxy. Por ejemplo, ingrese 10.0.0.250 .
10. Haga clic en Aceptar . La Figura 3-3 muestra la entrada de la ruta completa.
FIGURA 3-3 Agregar entrada de ruta
Asociar una tabla de rutas con una subred
Después de crear la tabla de rutas y agregar una entrada de ruta a la tabla, el paso final para
cambiar el flujo de tráfico es asociar la tabla con las subredes desde las que desea cambiar
el flujo de tráfico.
Para asociar la tabla con una subred, siga estos pasos:

3. Seleccione la tabla de rutas OutgoingProxy que se creó anteriormente.
4. En la tabla, haga clic en la hoja Subredes .
5. En la hoja Subredes, haga clic en Asociar .
6. En el menú desplegable Red virtual, seleccione la red con la subred para
asociar con la tabla; por ejemplo, seleccione hub-vnet-eus-01 .
7. En el menú desplegable Subred, seleccione la subred para asociarla con la
tabla de rutas y modificar el flujo de tráfico, como app1 .
FIGURA 3-4 Subred asociada
En el escenario en el que el tráfico de VM1 necesita fluir a través de NVA antes de

comunicarse con VM2, hemos realizado la entrada y asociación de la tabla de rutas si VM1
está en la subred app1. La Tabla 3-2 describe la dirección IP de las máquinas virtuales en
la Figura 3-5 .
TABLA 3-2 Direcciones IP
máquina virtual dirección IP
VM1 10.0.0.4
NVA 10.0.0.250
VM2 10.1.0.4
FIGURA 3-5 Diagrama proxy NVA
Con la asociación de la tabla de rutas a la subred app1, suponiendo que VM1 está en la
subred app1, cualquier tráfico destinado a VM2 fluirá a través de NVA. Este NVA podría
ser un proxy, un firewall o cualquier dispositivo de terceros de Azure Marketplace.
Configurar tunelización forzada
La tunelización forzada es un concepto similar al uso de un dispositivo virtual de red para

enrutar todo el tráfico como un proxy, pero incorpora una VPN de sitio a sitio o
ExpressRoute para enrutar cualquier tráfico de red virtual de regreso a las instalaciones. Por
lo general, esto se diseña en entornos regulados o de alta seguridad donde usar la
infraestructura existente es más conveniente a corto plazo que duplicar los requisitos en la
nube.
Para un diseño de tunelización forzada, la entrada de la tabla de rutas es similar al uso

de un NVA. Cambia la dirección IP del siguiente salto a la dirección local a la que se puede
acceder a través del túnel VPN. La figura 3-6 representa el diseño de tunelización forzada
en las instalaciones.
FIGURA 3-6 Diagrama de tunelización forzada
Si usa ExpressRoute, además de una VPN o en lugar de ella, el concepto es el mismo,

excepto que la ruta predeterminada debe anunciarse como parte de las sesiones de
intercambio de tráfico de BGP. Esto no requiere ninguna entrada de ruta adicional en una
tabla de rutas.
Diagnosticar y resolver problemas de enrutamiento
Las rutas en Azure se procesan en el orden de coincidencia de prefijo más largo para
cualquier destino que se haya definido. Si una ruta tiene más de una coincidencia, la
prioridad de procesamiento es:
1. Rutas definidas por el usuario

2. rutas BGP
3. Rutas del sistema
Si necesita solucionar problemas de enrutamiento desde la perspectiva de una máquina

virtual, hay dos herramientas integradas en Azure Portal que pueden ayudarlo. Desde una
VM, puede ver las rutas efectivas que se aplican a la VM según la subred a la que está
asociada la NIC.
Para ver las rutas efectivas, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Máquinas virtuales .
3. Seleccione una máquina virtual que haya implementado, por
ejemplo, VM1 .
4. Desde la máquina virtual, haga clic en la hoja Redes .
5. En la hoja Redes, haga clic en el nombre de la interfaz de red adjunta a la
máquina virtual. La Figura 3-7 muestra un ejemplo de una NIC llamada vm1623 .
FIGURA 3-7 Redes de máquinas virtuales

6. Desde la interfaz de red, haga clic en la hoja Rutas efectivas . La Figura 3-
8 muestra las rutas efectivas para la interfaz de red.
FIGURA 3-8 Rutas efectivas
La hoja Rutas efectivas en la tarjeta de interfaz de red es una herramienta útil para
obtener una descripción general de las rutas asociadas con la subred a la que está asociada
la NIC. Otro método para solucionar problemas de enrutamiento desde una VM es usar
Network Watcher.
Network Watcher es un recurso de supervisión de Azure integrado en Azure Portal y es

un conjunto de herramientas que se pueden usar para solucionar problemas. Una de estas
herramientas, llamada Next hop, le permite seleccionar una VM e identificar el siguiente
salto para una dirección específica.
Para utilizar la herramienta Siguiente salto, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Network Watcher .
3. En Network Watcher, seleccione la hoja Siguiente salto .
4. Complete los campos para seleccionar la máquina virtual deseada y la tarjeta
de interfaz de red.
5. En el campo Dirección IP de destino, especifique la dirección IP que desea
probar para identificar cuál sería el siguiente salto configurado. Por ejemplo,
especifique 8.8.8.8 .
6. Haga clic en Siguiente salto . La Figura 3-9 muestra el formulario
completado y que el siguiente tipo de salto es Internet según las rutas efectivas.
FIGURA 3-9 Siguiente salto
La Figura 3-9 muestra que desde la tarjeta de interfaz de red vm1623, que tiene una
dirección IP de origen de 10.0.0.4 en la subred de administración, si la VM se comunicara
con la dirección IP de destino 8.8.8.8, el tráfico se reenviaría a la Internet.
Habilidad 3.2: Diseñar e implementar un equilibrador de carga de Azure
Hay algunas opciones en Azure si necesita distribuir el tráfico entrante a un grupo de

recursos de back-end. Estas opciones incluyen Azure Load Balancer, Azure Application
Gateway y Azure Front Door. Cada servicio tiene su propio conjunto de características y
funcionalidades que lo diferencian. Azure Load Balancer es la más simple de las tres
opciones; proporciona funcionalidad de equilibrio de carga de nivel 4 central para
escenarios públicos e internos.

 Elija una SKU de Azure Load Balancer
 Elige entre público e interno
 Crear y configurar un equilibrador de carga de Azure
 Implementar una regla de equilibrio de carga
 Crear y configurar reglas de NAT de entrada
 Crear reglas de salida explícitas para un balanceador de carga
Elija una SKU de Azure Load Balancer
Como está diseñando una solución que incluye un equilibrador de carga de Azure, hay dos
opciones de SKU para seleccionar: Básico y Estándar. En general, la mejor práctica es usar
un balanceador de carga de SKU estándar para cualquier implementación de
producción. Después de implementar un balanceador de carga, no puede cambiar el SKU y
debe implementar un nuevo recurso. La Tabla 3-3 describe las diferencias de características
entre los SKU.
TABLA 3-3 SKU del balanceador de carga
Rasgo Equilibrador de carga Equilibrador de carga básico

estándar
Tamaño del grupo de Hasta 1000 instancias Hasta 300 instancias

back-end
Tipo de grupo de back- Máquinas virtuales, Conjuntos de disponibilidad o
end conjuntos de escalado de conjuntos de escalado
VM
Protocolos de sondeo de TCP, HTTP, HTTPS TCP, HTTP

salud
Comportamiento de Las conexiones TCP Las fallas de una sola instancia

falla de la sonda de existentes se mantienen permanecen vivas, todas las
estado activas fallas de instancia se eliminan
Zonas de disponibilidad Se pueden configurar No disponible

front-end zonales y con
redundancia de zona
Diagnóstico monitor azul No disponible
Puertos HA Con direcciones IP No disponible

internas
valores predeterminados Cerrado por defecto Abrir por defecto

de seguridad
Reglas de salida NAT saliente No disponible
Restablecimiento de Configurado en reglas No disponible

TCP en inactivo
Múltiples front-ends Entrante y saliente Solo entrante
ANS 99,99% Ninguna
Emparejamiento de Compatible con dirección No disponible

redes virtuales globales IP interna
De las diferencias de características descritas en la Tabla 3-3 , las más destacadas serían
la cantidad de instancias, HTTPS como sondeo de estado y el SLA para la SKU
estándar. Para entornos más pequeños de desarrollo, prueba, control de calidad u otros tipos
que no sean de producción, una SKU básica podría ser aceptable.
Elige entre público e interno
Determinar si un balanceador de carga es público o interno es una decisión de arquitectura

con respecto a dónde se coloca el balanceador de carga como parte de la solución. Tanto los
balanceadores de carga básicos como los estándar admiten direcciones IP públicas e
internas, por lo que no hay restricciones de ubicación según el SKU que seleccione. Ambos
tipos de SKU de balanceador de carga admiten ambos escenarios, interno o público. Si
selecciona interno o público, determina de qué tipo de tráfico puede aceptar el balanceador
de carga. Los balanceadores de carga internos solo pueden aceptar tráfico de direcciones IP
privadas, mientras que los balanceadores de carga públicos solo pueden aceptar tráfico de
direcciones IP públicas.
Un escenario probable para los balanceadores de carga públicos es realizar también

NAT de salida para las máquinas virtuales del grupo de back-end. Sin embargo, solo el
balanceador de carga de SKU estándar admite la configuración de reglas de NAT de
salida. Por lo tanto, la mayoría de los escenarios de balanceador de carga público
requerirían un balanceador de carga de SKU estándar.
Aparte de las diferencias de características proporcionadas por los dos tipos de SKU, no
hay ninguna ventaja o restricción de rendimiento al elegir configurar un balanceador de
carga con una dirección IP pública o privada.
Crear y configurar un equilibrador de carga de Azure
Después de elegir qué SKU usar y si su balanceador de carga será interno o público, estará
listo para crear el balanceador de carga. Para completar la configuración, también
necesitará máquinas virtuales para el grupo de back-end. Hay algunos componentes de
configuración que conforman una configuración completa del balanceador de carga:
 Dirección IP de interfaz
 Grupo de back-end
 Sondeos de salud
 Reglas del equilibrador de carga
En esta sección, nos enfocamos en configurar la dirección IP del front-end y los grupos
de back-end a medida que creamos el balanceador de carga. Nos centraremos en las reglas
y sondas de estado del equilibrador de carga en la siguiente sección. Para crear un
equilibrador de carga de Azure, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Load Balancers .
3. En la página Load Balancer, haga clic en Crear .
4. En el menú desplegable Grupo de recursos, seleccione el grupo de recursos
deseado, como Redes .
5. En el campo Nombre, proporcione un nombre para el balanceador de carga,
como lb-eus-app1 .
6. En el menú desplegable Región, seleccione la región de Azure deseada,
como Este de EE. UU .
7. Para la selección de SKU, seleccione Estándar .
8. Para la selección Tipo, seleccione Público .
9. Para la selección de Nivel, seleccione Regional .
10. Haga clic en Siguiente: Configuración de IP de interfaz . La Figura 3-
10 muestra la configuración completa en la pestaña Conceptos básicos.
FIGURA 3-10 Conceptos básicos del equilibrador de carga
11. En la pestaña Configuración de IP de frontend, haga clic en Agregar una

configuración de IP de frontend .
12. En el campo Nombre, especifique un nombre para la dirección IP de la
interfaz, como fe-app1 .
13. Para la versión IP, seleccione IPv4 .
14. Para el tipo de IP, seleccione la dirección IP .
15. Para la dirección IP pública, haga clic en Crear nuevo .
16. En el campo Nombre, proporcione un nombre para la dirección IP,
como pip-fe-app1 .
17. Haga clic en Aceptar y luego en Agregar . La Figura 3-11 muestra la
configuración de ejemplo.
FIGURA 3-11 Configuración de IP de interfaz de usuario del equilibrador de carga

18. Haga clic en Siguiente: Grupos de back-end .
NOTA IMPLEMENTACIÓN
INFORMÁTICA
Estos pasos suponen que ya ha implementado el proceso, ya sea máquinas
virtuales individuales o un conjunto de escalado de máquinas virtuales. La
implementación de opciones de cómputo no está en el esquema del examen y no
se trata en este libro.
19. En la pestaña Grupos de back-end, haga clic en Agregar un grupo de back-

end .
20. En el campo Nombre, proporcione un nombre para el grupo, como bep-
vmss-app1 .
21. En el menú desplegable Red virtual, seleccione la red virtual a la que está
conectado el grupo de backend, como Compute-vnet .
22. Para la configuración del grupo de back-end, seleccione NIC .
23. Para la versión de IP, seleccione IPv4 .
24. Seleccione el proceso de back-end en el que se ejecuta la aplicación, ya sean
máquinas virtuales individuales o un conjunto de escalado de máquinas
virtuales. En este ejemplo, seleccione un conjunto de escalado de máquinas
virtuales denominado vmss-app1 . La Figura 3-12 muestra la página Agregar grupo
de back-end completada.
FIGURA 3-12 Grupo de back-end del equilibrador de carga
25. Haga clic en Agregar .

Agregar al menos una dirección IP de front-end y un grupo de back-end son los

requisitos mínimos para crear un balanceador de carga. Para que el balanceador de carga
sea funcional, también necesitará reglas creadas.
Implementar una regla de equilibrio de carga
Las reglas del equilibrador de carga son la configuración que une la dirección IP del front-
end, el grupo de back-end, el sondeo de estado, el protocolo y el número de puerto en el
que desea aceptar y distribuir el tráfico. Los balanceadores de carga de SKU básicos
pueden tener hasta 250 reglas configuradas, y los balanceadores de carga de SKU estándar
pueden tener hasta 1500 reglas.
Las reglas también le permiten configurar la traducción de direcciones de puertos. Por

ejemplo, si necesita permitir las conexiones del puerto 443 (HTTPS) externamente, pero
necesita traducirlo a un puerto personalizado, 8443, internamente, la regla del balanceador
de carga se puede configurar para realizar esta traducción.
Para crear una regla de equilibrador de carga, debe tener un sondeo de estado que
verifique el estado del grupo de back-end. Para crear un sondeo de estado para un
balanceador de carga existente, siga estos pasos:

3. En la página Load Balancer, seleccione un balanceador de carga existente,
por ejemplo lb-eus-app1 .
4. En el equilibrador de carga seleccionado, haga clic en la hoja Sondeos de
estado.
5. En la hoja Sondeos de estado, haga clic en Agregar .
6. En el campo Nombre, proporcione un nombre como hp-app1 .
7. Deje los campos restantes establecidos en los valores predeterminados:
1. Protocolo: TCP
2. Puerto: 80
3. Intervalo: 5
4. Umbral no saludable: 2
FIGURA 3-13 Agregar sonda de estado
La sonda de estado configurada en la Figura 3-13 se comunicará con el número de

puerto definido, TCP 80, cada cinco segundos. El grupo de back-end al que está asociada la
sonda de estado a través de la regla del equilibrador de carga se considerará "bueno"
siempre que se pueda acceder al número de puerto. Si se agota el tiempo de comunicación o
si no se puede acceder a él durante dos intentos consecutivos, o en este caso ~10 segundos,
el recurso en el grupo de back-end se marcaría como "Incorrecto" y las conexiones no se
reenviarían a ese recurso.
Para crear una regla que asocie estos componentes para un balanceador de carga
existente, siga estos pasos:

4. En el equilibrador de carga seleccionado, haga clic en la hoja Reglas de
equilibrio de carga .
5. En la página Reglas de equilibrio de carga, haga clic en Agregar .
6. En el campo Nombre, proporcione un nombre para la regla, por
ejemplo app1-https .
7. En el campo Versión de IP, deje seleccionado el IPv4 predeterminado .
8. En el menú desplegable Dirección IP de frontend, seleccione la dirección IP
deseada para aceptar conexiones. Por ejemplo, seleccione fe-app1 .
9. En el campo Protocolo, deje seleccionado el valor predeterminado de TCP .
10. En el campo Puerto, especifique el número de puerto externo para aceptar
conexiones. Por ejemplo, especifique 80 .
11. En el campo Puerto de back-end, especifique el número de puerto interno o
traducido para reenviar la conexión en el grupo de back-end. Por ejemplo,
especifique 8080 .
12. En el menú desplegable Grupo de back-end, seleccione el grupo de back-end
deseado. Por ejemplo, seleccione bep-vmss-app1 .
13. En el menú desplegable Sonda de estado, seleccione la sonda de estado
creada anteriormente. Por ejemplo, seleccione hp-app1 .
14. Deje los campos restantes establecidos en sus valores predeterminados:
1. Tiempo de espera inactivo: 4 minutos
2. Restablecimiento de TCP: Deshabilitado
3. IP flotante: deshabilitado
4. NAT de origen de salida: (recomendado) use reglas de salida para proporcionar
acceso a Internet a los miembros del grupo de back-end.
15. Haga clic en Agregar . La Figura 3-14 muestra la configuración completa.
FIGURA 3-14 Agregar regla de equilibrio de carga
La configuración que se muestra en la Figura 3-14 crea una regla que reúne los
componentes individuales del equilibrador de carga:
 Grupo de back-end
 Sondeo de salud
Junto con estos componentes, se definen el protocolo, el número de puerto externo y el

número de puerto interno. Esto distribuirá de forma eficaz el tráfico entrante en la dirección
IP pública 20.115.107.149 en el puerto TCP 80 al conjunto de escalado de máquinas
virtuales interno denominado bep-vmss-app1, internamente en el puerto 8080.
Los equilibradores de carga de Azure también ofrecen una opción

denominada persistencia de sesión , que no debe confundirse con afinidad de sesión . La
persistencia de sesión tiene tres opciones de configuración:
 Ninguna
 IP del cliente
 IP del cliente y protocolo
La opción predeterminada, Ninguno, utiliza un algoritmo basado en hash que permite

que las solicitudes sucesivas del mismo usuario final se reenvíen a cualquier máquina
virtual en el grupo de back-end. Client IP realiza un seguimiento de la dirección IP del
usuario final para garantizar que las solicitudes sucesivas de esa dirección IP se reenvíen a
la misma máquina virtual en el grupo de back-end, independientemente del protocolo. La
IP y el protocolo del cliente toman tanto la dirección IP del usuario final como el protocolo
que se está utilizando y, si son iguales, las solicitudes sucesivas se enviarán a la misma
máquina virtual en el grupo de back-end.
La opción de tiempo de espera inactivo define el período de tiempo antes de que se

considere interrumpida una conexión. El período de tiempo de espera predeterminado es de
4 minutos, pero se puede configurar hasta 30 minutos para las reglas del balanceador de
carga. De forma predeterminada, cuando se agota el tiempo de espera de una conexión, no
hay comunicación con el grupo de back-end. Si la aplicación tiene su propio período de
tiempo de espera, puede o no liberar la conexión. Si prefiere que el balanceador de carga
envíe específicamente un paquete de restablecimiento de TCP cuando se agote el tiempo de
espera, puede habilitar esta configuración.
Las direcciones IP flotantes le permiten reutilizar el mismo número de puerto en el

grupo de back-end con varias reglas de equilibrador de carga. Algunas aplicaciones o
arquitecturas específicas pueden requerir esto, incluyendo:
 Clúster de alta disponibilidad

 Dispositivos virtuales de red
 Múltiples puntos finales de TLS sin volver a cifrar
Para la traducción de direcciones de red (SNAT) de origen de salida, la opción

predeterminada es la configuración recomendada de usar reglas de salida. Esto le permite
configurar direcciones IP adicionales para usar como puertos SNAT. Esto evita agotar la
cantidad de puertos disponibles, lo que puede suceder con la opción Usar regla de salida
implícita . Las reglas de salida se analizan más adelante en esta sección de habilidades.
Crear y configurar reglas de NAT de entrada
Una regla de NAT entrante es similar a las reglas del balanceador de carga, ya que tiene
muchas de las mismas propiedades de configuración:
 Protocolo
 Puerto
 Tiempo de inactividad
 Restablecimiento de TCP
La diferencia es que, en lugar de equilibrar la carga entre varios recursos en un grupo de

back-end, una regla de NAT de entrada consiste en realizar la traducción de direcciones
para una máquina virtual individual. Esto es útil si tiene un portal administrativo o un
número de puerto personalizado para solucionar problemas de su aplicación o servicio en
un número de puerto diferente. Esto le brinda la posibilidad de conectarse directamente a
una sola VM en su grupo de back-end a través del balanceador de carga.
Para crear una regla de NAT entrante, siga estos pasos:

NAT de entrada.
5. En la hoja Reglas de NAT de entrada, haga clic en Agregar .
6. En el campo Nombre, especifique un nombre como app1-vm1 .
deseada. Por ejemplo, seleccione fe-app1 .
8. En los siguientes cuatro campos, deje la configuración predeterminada:
1. Servicio: Personalizado
2. Protocolo: TCP
3. Tiempo de espera inactivo: 4 minutos
4. Restablecimiento de TCP: Habilitado
9. En el campo Puerto, especifique un número de puerto para traducir. Por
ejemplo, especifique 8891 .
10. En el menú desplegable Máquina virtual de destino, seleccione una máquina
virtual que se haya implementado. Por ejemplo, seleccione VM1 . Tenga en cuenta
que la máquina virtual no puede tener una dirección IP pública asociada.
11. En el menú desplegable Configuración de IP de red, seleccione la
configuración de IP de la NIC asociada con la máquina virtual. Por ejemplo,
seleccione ipconfig1 .
12. En el campo Asignación de puertos, seleccione Personalizado .
13. Deje la opción de IP flotante establecida en el valor predeterminado
de Deshabilitado .
14. En el campo Puerto de destino, especifique el número de puerto interno en la
máquina virtual. Por ejemplo, especifique 8080 .
FIGURA 3-15 Agregar regla NAT de entrada
Como puede ver en la configuración, en lugar de especificar un grupo de back-end de

varios recursos, selecciona una sola máquina virtual de destino. Esta es la principal
diferencia entre las reglas de equilibrio de carga y las reglas de NAT de entrada. En la
configuración que se muestra en la Figura 3-15 , cualquier comunicación en el puerto 8891
dirigida a la dirección IP de interfaz 20.115.107.149 se reenviaría directamente a la
dirección IP privada de VM1 de 10.0.0.4 pero se traduciría al puerto 8080.
Crear reglas de salida explícitas para un balanceador de carga
Las reglas de salida le permiten configurar la traducción de direcciones de red (NAT) para
todas las máquinas virtuales definidas en los grupos de back-end. Las reglas de salida solo
están disponibles con los balanceadores de carga de SKU estándar que tienen una dirección
IP de interfaz pública.
Para configurar una regla de salida, siga estos pasos:

salida .
5. En la hoja Reglas de salida, haga clic en Agregar .
6. En el campo Nombre, proporcione un nombre para la regla. Por ejemplo,
ingrese ob-rule1 .
7. En el campo Versión de IP, deje seleccionado el IPv4 predeterminado .
configurada previamente. Por ejemplo, seleccione fe-app1 .
9. En el campo Protocolo, deje el valor predeterminado Todo seleccionado.
10. En el campo Tiempo de espera inactivo, deje la configuración
predeterminada de 4 .
11. En el campo Restablecer TCP, deje la configuración predeterminada
de Habilitado .
12. En el menú desplegable Grupo de back-end, seleccione el grupo de back-end
configurado anteriormente. Por ejemplo, seleccione bep-vmss-app1 .
13. En el menú desplegable Asignación de puertos, seleccione Elegir
manualmente el número de puertos de salida .
14. En el campo Elegir por, seleccione Número máximo de instancias de
back-end .
15. En el campo Número máximo de instancias de back-end, especifique el
número máximo de instancias al que podría aumentar el conjunto de escalado de
VM. Por ejemplo, especifique 20 .
FIGURA 3-16 Agregar regla de salida
Una regla de salida configura la traducción de la dirección de red de origen para los
recursos definidos en el grupo de back-end para comunicarse de forma saliente a través del
equilibrador de carga. Los puertos frontend disponibles están determinados por la cantidad
de direcciones IP frontend que seleccione. Estos puertos de front-end disponibles se
distribuyen a través de las máquinas virtuales en el grupo de back-end. En la configuración
anterior, los 63 984 puertos front-end posibles en un máximo de 20 máquinas virtuales
darían como resultado aproximadamente 3192 puertos por instancia.
Habilidad 3.3: Diseñar e implementar Azure Application Gateway
Los gateways de aplicaciones son la opción de equilibrio de carga basada en regiones que
se centra en la capa 7 del modelo OSI. Al operar en la capa 7, una puerta de enlace de
aplicaciones proporciona muchas más funciones que un balanceador de carga
tradicional. Puede realizar la funcionalidad básica de distribuir el tráfico a través de un
grupo de recursos de back-end, pero también tiene la capacidad de redirigir a ciertos grupos
de back-end en función de la URL o los encabezados de una solicitud
entrante. Opcionalmente, puede habilitar una aplicación webFirewall (WAF), realice la
terminación TLS y habilite el cifrado TLS de extremo a extremo. Esta sección de
habilidades presenta la puerta de enlace de aplicaciones y cómo configurar los diversos
componentes.

 Recomendar opciones de implementación de Azure Application Gateway
 Elija entre escala manual y automática
 Crear un grupo de back-end
 Configurar los ajustes de HTTP
 Configurar sondeos de estado
 Configurar oyentes
 Configurar reglas de enrutamiento
 Configurar la seguridad de la capa de transporte (TLS)
 Configurar políticas de reescritura
Recomendar opciones de implementación de Azure Application Gateway
Las puertas de enlace de aplicaciones de Azure funcionan en la capa 7 del modelo OSI, en
comparación con la capa 4 de los equilibradores de carga tradicionales y de Azure. Al
operar en la capa 7, hay características adicionales que tiene una puerta de enlace de
aplicaciones en comparación con un balanceador de carga tradicional:
 Terminación SSL
 Autoescalado
 Cortafuegos de aplicaciones web (WAF)
 Controlador de entrada para Azure Kubernetes Service (AKS)
 Enrutamiento basado en URL
 Alojamiento de múltiples sitios
 Afinidad de sesión
 Drenaje de conexión
 Páginas de error personalizadas
 Encabezado HTTP y reescrituras de URL
Las puertas de enlace de aplicaciones se implementan en una región de Azure y se

pueden implementar para que tengan redundancia de zona. Esto es importante cuando se
consideran las opciones de implementación que están disponibles con Azure Front Door,
que se analiza con más detalle en la siguiente sección de habilidades. Para las aplicaciones
que se implementarán en una o dos regiones y requieren terminación SSL o cualquiera de
las otras características enumeradas anteriormente, una puerta de enlace de aplicaciones es
una buena opción para recomendar. Si la aplicación seráresiden en más de dos regiones o
requieren algunas de las otras características descritas con Azure Front Door, como una red
de entrega de contenido (CDN), entonces Azure Front Door podría ser una mejor opción.
Después de decidir que una puerta de enlace de aplicaciones es el punto de entrada

recomendado para una aplicación, hay algunas SKU para decidir. Primero, puede decidir si
desea un SKU v1 o v2. Los SKU v1 tienen tres tamaños de configuración preestablecidos:
 Pequeña
 Medio
 Largo
Los SKU v1 no proporcionan ajuste de escala automático y deben configurarse

manualmente en uno de los tamaños predefinidos. Los SKU v2 incluyen estas
características que las puertas de enlace v1 no incluyen:
 Autoescalado
 redundancia de zona
 IP virtuales estáticas
 Controlador de entrada de AKS
 Integración de Azure Key Vault
 Reescrituras de encabezado HTTPS
 Reglas personalizadas de WAF
Después de decidir si implementar una SKU v1 o v2, ambas opciones tienen una SKU
separada para habilitar un WAF. Por ejemplo, está WAF v1, tamaño mediano; o WAF v2
con ajuste de escala automático disponible.
Elija entre escala manual y automática
El primer factor a la hora de elegir entre escalado manual y automático es el SKU que
decida implementar. Si elige implementar una SKU v1, el ajuste de escala automático no
está disponible y debe elegir uno de los tamaños predeterminados y configurar el recuento
de instancias manualmente, hasta 32 instancias.
Si elige implementar una SKU v2, también tiene la opción de usar recuentos de
instancias manuales o ajuste de escala automático. En cualquier escala, puede escalar hasta
125 instancias con un SKU v2. Cuando elige usar el ajuste de escala automático, también
establece medidas de seguridad mínimas y máximas. Si sabe que para su aplicación
necesita al menos dos instancias en un momento dado, puede establecer el mínimo en
dos. Si para la administración de costos y presupuesto, no espera que el tráfico pico supere
la necesidad de 10 instancias, puede establecer el máximo en 10.
Ya sea que decida usar escalado manual o automático, cada instancia de escalado
representa aproximadamente 10 unidades de cómputo . Las unidades de cómputo definen la
cantidad de cómputo detrás de Application Gateway cuando decide usar un tipo de SKU v2
en lugar de los tamaños preestablecidos Pequeño, Mediano o Grande. Cada unidad de
cómputo puede aceptar aproximadamente 50 conexiones simultáneas por segundo sin WAF
habilitado, o 10 conexiones simultáneas por segundo cuando se usa WAF.
Las unidades de cómputo también son un componente de la unidad de

capacidad general . Una unidad de capacidad define la computación, el rendimiento y las
conexiones coherentes que admite una instancia. Una SKU v2 puede procesar
aproximadamente 2,2 Mbps de rendimiento con cada unidad de capacidad y un total de
2500 conexiones persistentes. Para computación, rendimiento o conexiones adicionales, se
requieren instancias adicionales.
Para crear una puerta de enlace de aplicaciones, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Application Gateways .
3. En la página de Application Gateway, haga clic en Crear .
4. En el menú desplegable Suscripción, seleccione la suscripción que tiene los
recursos frente a los que le gustaría colocar la puerta de enlace de aplicaciones.
para colocar la puerta de enlace de aplicaciones. Por ejemplo, seleccione Redes .
6. En el campo Nombre de la puerta de enlace de la aplicación, proporcione un
nombre para la puerta de enlace. Por ejemplo, ingrese appgw-eus-01 .
7. En el menú desplegable Región, seleccione la región de Azure para
implementar la puerta de enlace. Debe ser el mismo que los recursos que agregará al
grupo de back-end. Por ejemplo, seleccione Este de EE. UU .
8. En el menú desplegable Nivel, seleccione WAF V2 .
9. En el campo Habilitar ajuste de escala automático, establezca el valor en Sí .
10. En el campo Recuento mínimo de instancias, establezca el valor en 2 .
11. En el campo Recuento máximo de instancias, establezca el valor en 5 .
12. Deje los siguientes campos en sus valores predeterminados:
Estado del cortafuegos: Habilitado
Modo de cortafuegos: Detección
Zona de disponibilidad: Ninguna
HTTP2: deshabilitado
13. En el menú desplegable Red virtual, seleccione la red virtual con la que
asociar la puerta de enlace de aplicaciones. Por ejemplo, seleccione hub-vnet-eus-
01 .
14. En el campo Subred, seleccione una subred disponible que no tenga recursos
conectados. Por ejemplo, seleccione una subred dedicada llamada AppGW . La
Figura 3-17 muestra la configuración completa en la pestaña Conceptos básicos.
FIGURA 3-17 Aspectos básicos de la creación de la puerta de enlace de

aplicaciones
15. Haga clic en Siguiente: Frontends .
16. Deje el tipo de dirección IP de frontend en el valor predeterminado, Public .
17. En el campo Dirección IP pública, haga clic en Agregar nuevo .
18. Aparecerá la ventana Agregar una IP pública. En el campo Nombre, asigne
un nombre al objeto de dirección IP pública. Por ejemplo, ingrese appgw-
pip1 . Debido a que la dirección IP se asocia con una puerta de enlace de
aplicaciones, la SKU de IP debe ser estándar con una asignación estática. Estos
valores no están disponibles para configurar.
19. Haga clic en Aceptar . La Figura 3-18 muestra la ventana emergente
Agregar una IP pública.
FIGURA 3-18 Agregar una IP pública
20. Haga clic en Siguiente: Backends .

21. En la pestaña Grupo de back-end, haga clic en Agregar un grupo de back-
end .
22. En la ventana Agregar un grupo de back-end, proporcione un nombre para el
grupo de back-end. Por ejemplo, ingrese appgw-bep1 .
23. Establezca el campo Agregar grupo de back-end sin objetivos en Sí . Los
grupos de back-end se analizan más en la siguiente sección.
24. Haga clic en Agregar . La Figura 3-19 muestra la página Agregar un grupo
de back-end completada.
FIGURA 3-19 Agregar un grupo de back-end
25. Haga clic en Siguiente: Configuración .

26. En la pestaña Configuración, haga clic en Agregar una regla de
enrutamiento .
27. En el campo Nombre de regla, especifique un nombre para la regla de
enrutamiento. Por ejemplo, especifique public-to-bep1 .
28. En el campo Nombre del oyente, ingrese un nombre para el oyente. Por
ejemplo, ingrese listener-app1 . Los oyentes se analizan con más detalle más
adelante en esta sección de habilidades.
29. En el menú desplegable IP de frontend, seleccione Pública .
30. Deje los valores restantes establecidos en sus valores predeterminados:
Protocolo: HTTP
Puerto: 80
Tipo de oyente: Básico
URL de la página de error: No
31. La Figura 3-20 muestra la pestaña Listener completa. Haga clic en

la pestaña Destinos de back-end.
FIGURA 3-20 Agregar una regla de enrutamiento: pestaña Escucha
32. En la pestaña Destinos de back-end, deje el tipo de destino predeterminado

como Grupo de back-end .
33. En el menú desplegable Destino de back-end, seleccione el grupo de back-
end configurado anteriormente. Por ejemplo, seleccione appgw-bep1 .
34. En el campo de configuración de HTTP, haga clic en Agregar nuevo .
35. En la página Agregar una configuración de HTTP, proporcione un nombre
para la configuración. Por ejemplo, ingrese app1-settings . La configuración de
HTTP se analiza con más detalle más adelante en esta sección de habilidades.
36. Deje todos los demás campos establecidos en los valores predeterminados y
haga clic en Agregar . La Figura 3-21 muestra los ajustes de HTTP configurados.
FIGURA 3-21 Agregar una configuración de HTTP
37. En la página Agregar una regla de enrutamiento, el campo de configuración

de HTTP debe mostrar la nueva configuración de app1. Haga clic en Agregar . La
Figura 3-22 muestra la pestaña Destinos de backend.
FIGURA 3-22 Agregar una regla de enrutamiento: pestaña Destinos de back-end
38. Haga clic en Siguiente: Etiquetas .

39. Haga clic en Siguiente: Revisar + Crear .
Estos pasos implementan una puerta de enlace de aplicaciones simple con los requisitos
mínimos para poner en funcionamiento la primera instancia. Una puerta de enlace de
aplicaciones admite varios grupos de back-end, sondeos de estado, agentes de escucha,
reglas de enrutamiento y más. Todo esto se discute en las siguientes secciones.
Crear un grupo de back-end
Cuando implementa una puerta de enlace de aplicaciones, hay una serie de componentes
necesarios durante la implementación y más que puede configurar después de la
implementación, incluidos los grupos de back-end. Los grupos de back-end son los
recursos "detrás" de la puerta de enlace de aplicaciones en una topología de red o diseño de
arquitectura. Los servicios admitidos para un grupo de back-end en una puerta de enlace de
aplicaciones incluyen:
 Direcciones IP o nombres de dominio completos

 Maquinas virtuales
 Conjuntos de escalado de máquinas virtuales
 servicios de aplicaciones
Básicamente, siempre que la puerta de enlace de aplicaciones pueda comunicarse con el

recurso, se puede agregar como grupo de back-end. Esto es cierto incluso si el recurso está
en otra región de Azure, localmente o en otra nube. Una vez que haya creado un objeto de
grupo de back-end que identifique estos recursos, asocie el grupo con un agente de escucha
mediante una regla de enrutamiento. Los oyentes y las reglas de enrutamiento se analizan
en una sección posterior.
Para crear un nuevo grupo de back-end para una puerta de enlace de aplicaciones

3. En la página de Application Gateway, seleccione la puerta de enlace de
aplicaciones que se creó anteriormente, por ejemplo , appgw-eus-01 .
4. En la página de Application Gateway, haga clic en la hoja Grupos de back-
end.
5. En la hoja Grupos de back-end, haga clic en Agregar . Tenga en cuenta que
ya existe un grupo de back-end cuando creó la puerta de enlace de aplicaciones,
pero se pueden crear grupos de back-end adicionales.
6. En la pantalla Agregar grupo de back-end, proporcione un nombre para el
grupo de back-end. Por ejemplo, ingrese bep-as-app1 .
7. En el menú desplegable Tipo de destino, seleccione Servicios de
aplicaciones .
8. En el menú desplegable Destino, seleccione un servicio de aplicaciones que
haya implementado. Por ejemplo, seleccione az700demoapp1 . Tenga en cuenta
que esto requiere que se cree un servicio de aplicación por adelantado. Los servicios
de aplicaciones no están cubiertos en el AZ-700 y los pasos para crear uno no se
describen aquí. Si desea utilizar un tipo de destino diferente, selecciónelo y
configúrelo aquí.
9. Haga clic en Agregar . La Figura 3-23 muestra la página del grupo de back-
end completado.
FIGURA 3-23 Agregar grupo de back-end
Un grupo de back-end es realmente solo una definición de objeto del recurso al que la
puerta de enlace de aplicaciones necesita dirigir el tráfico. Sin embargo, el grupo de back-
end es solo la definición del objeto. Para poder reenviar las solicitudes que recibe
Application Gateway, también se deben configurar sondas de estado, agentes de escucha y
reglas de enrutamiento.
Configurar los ajustes de HTTP
Una puerta de enlace de aplicaciones se basa en la configuración de HTTP que configura

para comprender los detalles del reenvío de tráfico al grupo de back-end. La configuración
de HTTP es necesaria para configurar los sondeos de estado y las reglas de enrutamiento.
La configuración de HTTP es esencialmente una definición del protocolo y el número

de puerto que debe usarse para comunicarse con un grupo de back-end. La configuración de
HTTP también es donde puede configurar la afinidad de la sesión basada en cookies, así
como el drenaje de la conexión si desconecta un recurso.
Para agregar una configuración HTTP a una puerta de enlace de aplicaciones, siga estos
pasos:

4. En la página de Application Gateway, haga clic en la hoja de configuración
de HTTP .
5. En la hoja de configuración de HTTP, haga clic en Agregar .
6. En la página Agregar configuración HTTP, en el campo Nombre
proporcione un nombre para la colección de configuraciones. Por ejemplo,
ingrese settings-as-app1 .
7. En los campos Protocolo backend y Puerto, deje los valores predeterminados
de HTTP y 80 .
8. En el campo Afinidad basada en cookies, seleccione Habilitar y luego deje
el nombre de la cookie en el valor predeterminado.
9. Deje las configuraciones restantes en sus valores predeterminados y haga
clic en Guardar . La Figura 3-24 muestra la configuración completa.
FIGURA 3-24 Agregar configuración de HTTP
Las puertas de enlace de aplicaciones supervisan automáticamente los recursos definidos en

el grupo de back-end para asegurarse de que estén en buen estado antes de enviar
solicitudes de conexión y tráfico a ese recurso. En caso de que un recurso deje de estar
disponible, los sondeos de estado se configuran con un umbral de error para indicar a la
puerta de enlace de aplicaciones que el recurso no está disponible. Si todos los recursos
dejan de estar disponibles, la puerta de enlace de aplicaciones presentará errores HTTP 502
(Puerta de enlace incorrecta) a las conexiones del cliente.
Por ejemplo, si el recurso no responde a tres solicitudes consecutivas en intervalos de 30

segundos, se considerará en mal estado. Los valores predeterminados de un sondeo de
estado son probar la conexión cada 30 segundos, con un tiempo de espera de 30 segundos,
y marcar el recurso como en mal estado en tres solicitudes consecutivas.
También puede configurar sondeos de estado personalizados para usar con

configuraciones y reglas de HTTP para que pueda personalizar el nombre de host, el
número de puerto, el intervalo, el período de tiempo de espera o el umbral de mal
estado. Las sondas de estado requieren que se configure la siguiente información:
 Nombre
 host de back-end
 Ruta del directorio virtual
 Intervalo
 Se acabó el tiempo
 Umbral no saludable
Para configurar un sondeo de estado en una puerta de enlace de aplicaciones existente,

siga estos pasos:

4. En la página de Application Gateway, haga clic en la hoja Sondeos de
estado.
5. En la hoja Sondeos de estado, haga clic en Agregar .
6. En la página Agregar sonda de salud, en el campo Nombre, proporcione un
nombre para la sonda de salud. Por ejemplo, ingrese hp-as-app1 .
7. En el campo Protocolo, deje seleccionado el valor predeterminado
de HTTP .
8. En el campo Host, ingrese la dirección IP o el nombre de dominio completo
del host a monitorear. Por ejemplo, ingrese az700demoapp1.azurewebsites.net .
9. Deje la configuración Seleccionar nombre de host y Seleccionar puerto de
en sus valores predeterminados.
10. En el campo Ruta, especifique la ruta del host a monitorear. Por ejemplo,
para monitorear la raíz de la ruta, ingrese / . Puede especificar la ruta completa si
hay ciertos directorios virtuales de su aplicación para monitorear.
11. En el campo Intervalo (segundos), establezca el intervalo deseado para
verificar con el recurso. Por ejemplo, configúrelo en 15 .
12. En el campo Tiempo de espera (segundos), establezca el valor de tiempo de
espera deseado. Por ejemplo, configúrelo en 10 .
13. En el campo Umbral incorrecto, establezca los intentos fallidos consecutivos
deseados antes de marcar el recurso como incorrecto. Por ejemplo, configúrelo
en 2 . En general, esta configuración marcaría un recurso como no saludable más
rápido que la configuración predeterminada.
14. En el menú desplegable de configuración de HTTP, seleccione la
configuración que creó anteriormente. Por ejemplo, seleccione settings-as-app1 .
15. Haga clic en Prueba . La Figura 3-25 muestra la configuración
completa. En este punto, si ha seguido los pasos del libro, recibirá un mensaje de
que la configuración HTTP que se seleccionó no está asociada con un grupo de
back-end. Esto se debe a que la configuración de HTTP también debe configurarse
con la regla de enrutamiento, que luego crea la asociación del grupo de back-end.
FIGURA 3-25 Agregar sonda de estado
16. Desmarque la casilla de verificación junto a Quiero probar el estado del

back-end antes de agregar el sondeo de estado y luego haga clic en Agregar .
Configurar oyentes
Un agente de escucha es el componente que "escucha" la dirección IP de interfaz de la

puerta de enlace de aplicaciones para las conexiones entrantes. El agente de escucha define
el protocolo, el número de puerto, el nombre de host y la dirección IP a la que intenta
conectarse una solicitud entrante y la compara con la configuración que ha definido. Una
puerta de enlace de aplicaciones puede tener múltiples escuchas para diferentes nombres de
host, rutas de directorio virtual, diferentes grupos de back-end y muchos otros escenarios.
A medida que los oyentes identifican el tráfico entrante y las solicitudes de conexión,
los oyentes admiten cuatro protocolos:
 HTTP
 HTTPS
 HTTP/2
 WebSocket
Cuando configura el agente de escucha, puede seleccionar HTTP o HTTPS. La

compatibilidad con WebSocket está habilitada de manera predeterminada y no tiene una
configuración configurable. Para crear un agente de escucha en una puerta de enlace de
aplicaciones existente, siga estos pasos:

4. En la página de Application Gateway, haga clic en la hoja Agentes
de escucha .
5. En la hoja Sondeos de estado, haga clic en Agregar agente de escucha .
6. En la pantalla Agregar agente de escucha, proporcione un nombre para el
agente de escucha. Por ejemplo, ingrese listener-as-app1 .
7. En el menú desplegable IP de front-end, seleccione la dirección IP de front-
end que configuró cuando implementó la puerta de enlace de aplicaciones. Por
ejemplo, seleccione Público .
8. En el campo Puerto, ingrese un número de puerto en el que el oyente debe
esperar tráfico entrante. Por ejemplo, ingrese 8080 .
9. En los campos restantes, deje los valores predeterminados:
1. Protocolo: HTTP
2. Tipo de oyente: Básico
3. URL de la página de error: No
FIGURA 3-26 Agregar oyente
Las reglas de enrutamiento son el pegamento que mantiene unido el oyente, el grupo de
back-end y la configuración de HTTP que ha creado. Hay dos tipos de reglas de
enrutamiento:
 Básico
 Multi-sitio
Las reglas de enrutamiento básicas asignan un solo nombre de dominio completo

(FQDN) a un grupo de back-end que se ha configurado. Un agente de escucha multisitio le
permite definir varios FQDN en un grupo de back-end. Al momento de escribir este
artículo, hay una función de vista previa que también permite que los comodines se usen
como parte de los nombres de dominio o como partes de los nombres de subdominio.
Para crear una nueva regla de enrutamiento, siga estos pasos:

4. En la página de Application Gateway, haga clic en la hoja Reglas .
5. En la hoja Reglas, haga clic en Solicitar regla de enrutamiento .
6. En la página Agregar una regla de enrutamiento, en el campo Nombre de la
regla, proporcione un nombre para la regla. Por ejemplo, ingresa public-to-as-
app1 .
7. En el menú desplegable Listener, seleccione el listener que creó
anteriormente. Por ejemplo, seleccione listener-as-app1 . La Figura 3-27 muestra la
pestaña Listener completa.
FIGURA 3-27 Adición de una regla de enrutamiento: agente de escucha
8. Haga clic en la pestaña Destinos de back-end.

9. En Tipo de destino, deje el valor predeterminado, Grupo de back-end .
10. En el menú desplegable Destino de backend, seleccione el destino de
backend deseado. Por ejemplo, seleccione bep-as-app1 .
11. En el menú desplegable Configuración de HTTP, seleccione la
configuración de HTTP que creó anteriormente. Por ejemplo, seleccione settings-
as-app1 .
12. Haga clic en Agregar . La Figura 3-28 muestra la pestaña de objetivos de
back-end completada.
FIGURA 3-28 Agregar una regla de enrutamiento: objetivos de back-end
Los pasos anteriores crearán la regla que asocia la dirección IP de front-end de la puerta
de enlace de aplicaciones, a través del agente de escucha, con el grupo de back-end y la
configuración de HTTP. La Figura 3-29 describe los diversos componentes de Application
Gateway que se han configurado y cómo se asocian.
FIGURA 3-29 Diagrama de puerta de enlace de aplicaciones
Configurar la seguridad de la capa de transporte (TLS)
Todos los ejemplos y pasos que se han configurado hasta ahora con Application Gateway
han usado HTTP. Las puertas de enlace de aplicaciones también pueden usar TLS/SSL en
dos escenarios:
 terminación TLS
 Cifrado TLS de extremo a extremo
La terminación de TLS es donde la puerta de enlace de aplicaciones presenta un

certificado al cliente a través del agente de escucha. Esto permite que Application Gateway
descifre el tráfico entrante y proporcione una respuesta cifrada al cliente. Por lo tanto,
cuando configure el certificado TLS, debe ser un archivo de certificado de Intercambio de
información personal (PFX) que tenga claves públicas y privadas. Para la terminación de
TLS, el certificado requiere que se cargue la cadena de plena confianza, incluido el
certificado raíz de la CA, cualquier intermedio y el certificado de hoja. Application
Gateway puede usar los siguientes tipos de certificados:
 Autoridad certificada
 Validación extendida
 Comodín
 Autofirmado
Permitir que la puerta de enlace de aplicaciones finalice la conexión TLS generalmente

proporciona un mejor rendimiento de los recursos de back-end. Esto es especialmente
cierto cuando se usan tamaños de clave más grandes para los certificados. Al descifrar el
tráfico en la puerta de enlace de la aplicación, puede ver el contenido de la solicitud y
realizar el enrutamiento basado en la ruta o la URL a los diversos grupos de back-end que
puede definir.
Si tiene un archivo de certificado PFX para cargar en una puerta de enlace de

aplicaciones, siga estos pasos para agregar un nuevo agente de escucha que use HTTPS:

4. En la página de Application Gateway, haga clic en la hoja Agentes
de escucha .
5. En la hoja Agentes de escucha, haga clic en Agregar agente de escucha .
6. En la pantalla Agregar agente de escucha, proporcione un nombre para el
agente de escucha. Por ejemplo, ingrese listener-as-app2 .
7. En el menú desplegable IP de front-end, seleccione la dirección IP de front-
end que configuró cuando implementó la puerta de enlace de aplicaciones. Por
ejemplo, seleccione Público .
8. En el campo Protocolo, seleccione HTTPS . Esto establecerá
automáticamente el número de puerto en 443 .
9. Aparecerán campos adicionales para la configuración de HTTPS. En el
campo Elegir un certificado, deje el valor predeterminado de Cargar un
certificado .
10. En el campo Nombre del certificado, proporcione un nombre para el
certificado. Por ejemplo, ingrese HugeLab .
11. En el campo del archivo de certificado PFX, busque y seleccione su archivo
de certificado PFX.
12. En el campo Contraseña, proporcione la contraseña para el archivo de
certificado PFX.
13. En los campos restantes, deje los valores predeterminados:
1. Tipo de oyente: Básico
2. URL de la página de error: No
FIGURA 3-30 Agregar oyente
Algunos requisitos de seguridad o políticas de cumplimiento pueden requerir que se

cifre toda la comunicación en el proceso de extremo a extremo. El proceso para esto
funciona de manera similar a la terminación de TLS, excepto que la puerta de enlace de
aplicaciones realizará una conexión cifrada con el grupo de back-end. La puerta de enlace
de aplicaciones aún descifra la sesión cuando llega para identificar la ruta y cualquier otra
característica que pueda estar habilitada, como la afinidad de sesión basada en cookies,
reescrituras de encabezados y más.
Para que una puerta de enlace de aplicaciones pueda establecer una nueva sesión TLS
con un grupo de back-end, la configuración del host debe coincidir con el nombre común
en el certificado que se usa. Si el grupo de back-end usa un certificado autofirmado, el
certificado debe proporcionarse a la puerta de enlace de aplicaciones. El certificado debe
estar definido en la configuración HTTP que la regla de enrutamiento está configurada para
usar.
Para configurar los ajustes que usan HTTPS, siga estos pasos.

4. En la página de Application Gateway, haga clic en la hoja de configuración
de HTTP .
5. En la hoja de configuración de HTTP, haga clic en Agregar .
6. En la página Agregar configuración HTTP, en el campo Nombre
proporcione un nombre para la colección de configuraciones. Por ejemplo,
ingrese settings-as-app2 .
7. En los campos Protocolo backend y Puerto, seleccione HTTPS . El puerto
backend se ajustará automáticamente a 443 .
8. En el campo del certificado CER, busque y seleccione su archivo de
certificado para comunicarse con el grupo de back-end.
9. En el campo Nombre del certificado, proporcione un nombre para el
certificado. Por ejemplo, ingrese HugeLab .
10. En el campo Afinidad basada en cookies, seleccione Habilitar y luego deje
el nombre de la cookie en el valor predeterminado.
11. Haga clic en +Agregar certificado .
12. Deje las configuraciones restantes en sus valores predeterminados y haga
clic en Guardar . La Figura 3-31 muestra la configuración completa.
FIGURA 3-31 Agregar configuración de HTTP
Configurar políticas de reescritura
Con una SKU V2 de Application Gateway, puede crear conjuntos de reescritura de

encabezados para agregar, actualizar o quitar varios encabezados HTTP y variables de
servidor. Cuando crea un conjunto de reescrituras, basa las reescrituras en reglas,
condiciones y acciones basadas en acciones, condiciones o variables. Todos los
encabezados de las solicitudes y respuestas de conexión se pueden modificar, excepto los
encabezados de conexión y actualización .
Cada regla que crea tiene un número de secuencia de regla que determina el orden en
que se procesan las reglas. Las reglas con el número de secuencia más bajo se procesan
primero. Si configura dos reglas con el mismo número de secuencia, no existe un método
predefinido para garantizar qué regla se procesa primero.
Las condiciones en un conjunto de reescritura son simplemente declaraciones if-then
que identifican el tipo de variable a verificar, ya sea encabezado HTTP o variable de
servidor, y luego el valor dentro de eso que podría necesitar agregarse o modificarse. Las
condiciones se pueden configurar opcionalmente para distinguir entre mayúsculas y
minúsculas y buscar patrones específicos que coincidan en el encabezado. No es necesario
configurar las condiciones como parte de un conjunto de reescritura si desea que la regla
inspeccione o modifique todo el tráfico.
Después de identificar el componente que necesita cambiar, ya sean todos los paquetes o
solo los paquetes que cumplen la condición, la acción define qué cambiar dentro de los
encabezados. El conjunto de reescritura puede establecer o eliminar un encabezado de
solicitud o un encabezado de respuesta, o modificar la URL. Estos conjuntos de reescritura
se asocian con una regla de enrutamiento cuando se crean.
Los escenarios comunes para usar reescrituras de encabezados incluyen:
 Eliminación de la información del puerto del encabezado X-Forwarded-For

 Modificar una URL de redirección
 Implementación de encabezados HTTP de seguridad
 Eliminación de encabezados no deseados
 Selección de ruta basada en parámetros
Para crear un conjunto de reescritura que establezca un encabezado HTTP de seguridad,

siga estos pasos:

4. En la página de Application Gateway, haga clic en la hoja Reescrituras .
5. En la hoja Reescrituras, haga clic en + Conjunto de reescrituras .
6. En la página Crear conjunto de reescritura, en el campo Nombre proporcione
un nombre para el conjunto. Por ejemplo, ingresa rewrite-app1 .
7. En las Reglas de enrutamiento | En la sección Rutas, seleccione una regla de
enrutamiento creada previamente para asociar el conjunto de reescritura. Por
ejemplo, seleccione public-to-as-app1 .
8. Haga clic en Siguiente . La Figura 3-32 muestra la pestaña Nombre y
asociación completada.
FIGURA 3-32 Crear conjunto de reescritura
9. En la pestaña Configuración de la regla de reescritura, haga clic en Agregar

regla de reescritura .
10. En el campo de nombre de la regla de reescritura, proporcione un nombre
para la nueva regla. Por ejemplo, ingrese SetTransportSecurity . Deje el valor de
Secuencia de reglas en el valor predeterminado, 100 . La Figura 3-33 muestra la
parte relevante de la página Crear conjunto de reescritura.
FIGURA 3-33 Configuración de la regla de reescritura
11. En la sección Hacer, seleccione Haga clic para corregir la configuración

de esta acción .
12. La sección Hacer se expandirá. En el campo desplegable Tipo de reescritura,
seleccione Encabezado de respuesta .
13. En el campo desplegable Tipo de acción, deje el valor predeterminado
de Establecer .
14. En el campo Nombre del encabezado, deje seleccionado el valor
predeterminado de encabezado común .
15. En el campo desplegable del encabezado Común, seleccione Strict-
Transport-Security .
16. En el campo Valor del encabezado, proporcione un valor para el
encabezado. Por ejemplo, ingrese max-age=31536000 .
17. Haga clic en Aceptar . La Figura 3-34 muestra la sección Hacer completa.
FIGURA 3-34 Acción de regla de reescritura
Habilidad 3.4: Implementar Azure Front Door
Azure Front Door ofrece una combinación de servicios de Azure en una única solución, que
incluye balanceo de carga de capa 7, firewall de aplicaciones web, informes de seguridad y
entrega y optimización de contenido. A diferencia de la mayoría de los demás servicios de
Azure, Front Door se considera un servicio global que no se implementa en una región
específica de Azure. En cambio, cuando crea un punto de conexión de Front Door, se puede
acceder a él desde todas las regiones, ubicaciones de borde y puntos de presencia (POP) de
Azure en todo el mundo.
En el momento de escribir este artículo, Azure Front Door es el producto de

disponibilidad general. Una nueva opción de implementación denominada Azure Front
Door Standard/Premium se encuentra actualmente en versión preliminar pública y separa
algunas de las características y funciones del producto principal en dos versiones. La lista
de objetivos incluye la elección de un SKU adecuado, por lo que, aunque todavía se
encuentra en versión preliminar pública, esta sección de habilidades se centra en las
versiones preliminares.

 Elija un SKU de Azure Front Door
 Configurar sondeos de estado
 Configurar la terminación SSL y el cifrado SSL de extremo a extremo
 Configurar escuchas multisitio y configurar objetivos de back-end
 Configurar reglas de enrutamiento
Elija un SKU de Azure Front Door
Hay dos SKU de Azure Front Door: Estándar y Premium. La SKU estándar ofrece una
entrega de contenido optimizada en todo el mundo, no solo en una sola región de
Azure. Ambas SKU de Azure Front Door se consideran un equilibrador de carga global,
que usa direcciones IP anycast para ubicar elel punto de presencia (POP) de Microsoft más
cercano para acceder a la red troncal de Azure. La Tabla 3-4 describe la diferencia de
características entre las dos opciones de SKU.
TABLA 3-4 Comparación de SKU de Azure Front Door
Rasgo Estándar De primera calidad
Dominio personalizado Sí Sí
Descarga SSL Sí Sí
almacenamiento en caché Sí Sí
Compresión Sí Sí
Equilibrio de carga global Sí Sí
Enrutamiento de capa 7 Sí Sí
reescrituras de URL Sí Sí
motor de reglas Sí Sí
Enlace privado No Sí
WAF Solo reglas personalizadas Sí
Protección contra bots No Sí
Métricas y monitoreo mejorados Sí Sí
Informe de tráfico Sí Sí
Reporte de seguridad No Sí
Como se describe en la Tabla 3-4 , la SKU Premium tiene todas las características de la
SKU Estándar, además agrega más opciones de reglas para WAF, protección contra bots,
integración con Microsoft Threat Intelligence y análisis de seguridad con informes e
integración con Azure Private Link. Para implementar una puerta frontal de Azure con su
elección de SKU, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Front Doors
Standard/Premium .
3. En la página Front Doors Standard/Premium, haga clic en Crear .
4. En la pantalla Comparar ofertas, acepte el valor predeterminado para
implementar un Quick create Azure front door Standard/Premium y haga clic en
Continuar para crear un front door .
implementar la puerta principal.
6. En el menú desplegable Grupo de recursos, seleccione el grupo de
recursos. Por ejemplo, seleccione Redes .
7. En el campo Nombre, proporcione un nombre para la puerta principal. Por
ejemplo, ingrese fd-app1 .
8. En el campo Nivel, seleccione el SKU deseado. Por ejemplo,
seleccione Estándar .
9. En el campo Nombre de punto final, proporcione un nombre global único
para la URL de la puerta de entrada. Por ejemplo, ingrese az700fdapp .
10. En el menú desplegable Tipo de origen, seleccione el componente de
origen. Por ejemplo, seleccione Servicios de aplicaciones .
11. En el menú desplegable Nombre de host de origen, seleccione el servicio de
aplicaciones que creó anteriormente. Por ejemplo,
seleccione az700demoapp1.azurewebsites.net .
12. Deje los campos restantes en sus valores predeterminados en blanco y haga
clic en Revisar y crear . La Figura 3-35 muestra la configuración completa.
FIGURA 3-35 Crear un perfil de puerta delantera
Los sondeos de estado están asociados con el grupo de origen que contiene los recursos
(orígenes) a los que Front Door enviará las conexiones de cliente. Cuando cree el perfil de
la puerta principal, habilitará automáticamente el sondeo de estado para el origen
seleccionado.
Con Front Door, las sondas de estado realizan dos funciones principales. Lo primero es
verificar que el recurso de back-end esté en línea y en buen estado. En segundo lugar, el
sondeo de estado ayuda a Front Door a determinar el mejor recurso de back-end para enviar
las solicitudes de los clientes. Front Door también depende de los POP, y puede haber
muchos sondeos de estado que generen tráfico de red adicional. La frecuencia de sondeo de
estado predeterminada es de 30 segundos, lo que puede generar aproximadamente 200
solicitudes de sondeo de estado por minuto, por fuente de back-end.
¿NECESITA MÁS REVISIÓN? PUNTOS

DE PRESENCIA DE AZURE
Para obtener más información sobre las regiones de Azure, las ubicaciones de borde y
los puntos de presencia, visite https://infrastructuremap.microsoft.com/ .
Los sondeos de estado en Front Door tienen dos posibles métodos de sondeo: GET y
HEAD. El uso de una sonda GET recupera información del recurso de back-end, incluido el
cuerpo del mensaje. Esto puede generar más costos y rendimiento con cada verificación de
estado. Una solicitud HEAD es el valor predeterminado y requiere que el recurso de
backend no incluya un cuerpo de mensaje en la respuesta.
Cuando un recurso de back-end responde a una sonda, las solicitudes GET y HEAD
deben generar un código de estado HTTP 200 (OK). Cualquier otro tipo de respuesta
contará como un intento fallido. El tiempo de respuesta en latencia también se mide para
ayudar al servicio Front Door a elegir el recurso de back-end con mayor capacidad de
respuesta.
Para modificar la configuración de un sondeo de estado asociado con un grupo de

origen, siga estos pasos:

Standard/Premium .
3. En la página Front Doors Standard/Premium, seleccione la instancia de
Front Door que creó anteriormente. Por ejemplo, seleccione fd-app1 .
4. Haga clic en la hoja Grupos de origen .
5. En la hoja Grupos de origen, haga clic en el grupo de origen
predeterminado .
6. En la pantalla Actualizar grupo de origen, desplácese hacia abajo hasta la
sección Sondeos de estado.
7. Verifique que la casilla de verificación Habilitar sondeos de estado ya esté
seleccionada y que la ruta esté establecida en / .
8. En el campo Protocolo, seleccione HTTPS .
9. En el campo Intervalo, establezca el tiempo en 30 segundos.
10. Haga clic en Actualizar . La Figura 3-36 muestra la sección Sondeos de
estado actualizada.
FIGURA 3-36 Sondeos de salud del grupo de origen
Configurar la terminación SSL y el cifrado SSL de extremo a extremo
De forma predeterminada y sin ninguna configuración adicional, Azure Front Door admite
el uso de HTTPS en el nombre de host predeterminado que configura cuando implementa el
servicio por primera vez. Este es el dominio azurefd.net que personaliza cuando crea el
servicio. No se requiere configuración adicional si está utilizando este dominio para
acceder al servicio.
Si planea usar un dominio personalizado con su propio certificado, se requiere una

configuración adicional. En el momento de escribir este artículo, Front Door solo admite el
uso de un certificado que se encuentra en un Azure Key Vault en la misma
suscripción. Azure Key Vault es un requisito y actualmente no se admite estar en una
suscripción diferente al servicio Front Door. Además, el certificado debe tener una cadena
de certificados completa y la CA raíz enumerada debe estar en la lista de CA de confianza
de Microsoft. Por último, el certificado que utiliza no puede utilizar un algoritmo
criptográfico de curva elíptica (EC).
Los pasos generales para permitir que el servicio Front Door acceda a un certificado de
Key Vault son:
1. Registre una entidad de servicio en Azure Active Directory asociada con

Azure Front Door.
2. Otorgue el permiso Obtener a la entidad de servicio para secretos y
certificados en Azure Key Vault.
3. Seleccione el certificado de Front Door y asócielo con un dominio
personalizado.
Registrar una entidad de servicio
El identificador de la aplicación para Azure Front Door es ad0e1c7e-6d38-4ba4-9efd-

0bc77ba9f037 . Puede ejecutar este comando de PowerShell desde Azure Cloud Shell para
crear una entidad de servicio asociada con el identificador de la aplicación Front Door. La
identidad del usuario que ejecuta este comando debe ser un administrador global en el
entorno de Azure Active Directory.
Nuevo-AzADServicePrincipal-ApplicationId "205478c0-bd83-4e1b-a9d6-
db63a3e1e1c8"
Si ejecuta el comando desde Azure Cloud Shell, debería recibir información sobre la
entidad de servicio recién creada. Tenga en cuenta que DisplayName
es Microsoft.Azure.FrontDoor-Cdn .
Nombres principales de servicio: {205478c0-bd83-4e1b-a9d6-db63a3e1e1c8,

https://microsoft.onmicrosoft.com/033ce1c9-f832-4658-b024-
ef1cbea108b8}
Id. de aplicación: 205478c0-bd83-4e1b-a9d6-db63a3e1e1c8
Tipo de objeto: ServicePrincipal
Nombre para mostrar: Microsoft.AzureFrontDoor-Cdn
Identificación: a1d4a221-de6f-4b32-aa0d-d9873deeebd4
Tipo: ServicePrincipal
Permisos de Azure Key Vault
Después de crear la entidad de servicio, el objeto necesita permiso en Azure Key Vault para
acceder al certificado que carga. Para usar una política de acceso de Key Vault para asignar
los permisos, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Key Vault .
3. Seleccione un almacén de claves existente que haya implementado.
4. En la página del Almacén de claves, haga clic en la hoja Políticas de acceso
.
5. En la página Políticas de acceso, haga clic en Agregar política de acceso .
6. En el menú desplegable Permisos clave, seleccione Obtener .
7. En el menú desplegable Permiso secreto, seleccione Obtener .
8. En el campo Seleccionar principal, haga clic en Ninguno seleccionado .
9. Aparecerá la pantalla principal. Busque el identificador de la
aplicación, 205478c0-bd83-4e1b-a9d6-db63a3e1e1c8 y
seleccione Microsoft.Azure.FrontDoor-Cdn .
10. Haga clic en Seleccionar . La Figura 3-37 muestra la parte de búsqueda de
la pantalla Principal.
FIGURA 3-37 Seleccione un principal
11. En la pantalla Agregar política de acceso, haga clic en Agregar . La Figura

3-38 muestra la configuración completa.
FIGURA 3-38 Agregar política de acceso
12. En la página Políticas de acceso, haga clic en Guardar .
Agregar dominio personalizado al punto final
Una vez que haya cargado el certificado en Azure Key Vault y tenga la entidad de servicio
de Front Door con la política de acceso adecuada, puede configurar el dominio
personalizado en su punto de conexión de Front Door. Para agregar el dominio
personalizado al punto final con su propio certificado, siga estos pasos:

Standard/Premium .
3. En la página Puertas delanteras Estándar/Premium, seleccione la instancia de
puerta delantera que creó anteriormente. Por ejemplo, seleccione fd-app1 .
4. Haga clic en la hoja Secretos .
5. En la hoja Secretos, haga clic en Agregar certificado .
6. En la pantalla Agregar certificado, expanda el almacén de claves con su
certificado, luego seleccione la casilla de verificación junto al nombre del
certificado.
7. Haga clic en Agregar . La Figura 3-39 muestra el certificado seleccionado.
FIGURA 3-39 Agregar certificado
8. Haga clic en la hoja Administrador de puntos finales.

9. En la pantalla Administrador de terminales, haga clic en Editar
terminal para el terminal en el que desea configurar el dominio personalizado.
10. En la sección Dominios, haga clic en Agregar .
11. En el campo Agregar un dominio, seleccione Agregar un nuevo dominio .
12. En el campo de administración de DNS, seleccione la opción de DNS
adecuada para su dominio. Por ejemplo, seleccione Todos los demás servicios
DNS .
13. En el campo Dominio personalizado, ingrese el FQDN de su dominio. Por
ejemplo, ingrese fd.hugelab.net .
14. En el campo HTTPS, seleccione Traiga su propio certificado (BYOC) .
15. En el menú desplegable Secreto, seleccione el certificado que agregó a Front
Door desde Key Vault. La Figura 3-40 muestra la pantalla Agregar un dominio
completada.
FIGURA 3-40 Agregar un dominio con un certificado
16. Haga clic en Agregar .
Al completar estos pasos, se agregará el certificado para el dominio que especificó a la

configuración de Front Door. También se requiere un registro CNAME en el proveedor de
DNS para reenviar solicitudes para el dominio personalizado que agregó, por
ejemplo, fd.hugelab.net . Esto tendría que ser redirigido al punto final azurefd.net . Esto
proporciona una terminación TLS en el extremo de la puerta frontal.
Encriptado de fin a fin
Después de configurar la terminación de HTTPS en el punto final, el siguiente paso para su

implementación podría ser garantizar el cifrado de un extremo a otro. En una
implementación de Azure Front Door Standard o Premium, el protocolo de reenvío se
configura en la regla de enrutamiento. De forma predeterminada, el punto final aceptará
solicitudes HTTP y HTTPS y luego reenviará la solicitud utilizando el mismo protocolo
entrante.
Para forzar el cifrado de extremo a extremo y usar solo HTTPS, debe modificar la regla
de enrutamiento. Para modificar la regla de enrutamiento, siga estos pasos:

Standard/Premium .
6. En la sección Rutas, haga clic en el nombre de la ruta a modificar. Por
ejemplo, haga clic en ruta predeterminada.
7. En la pantalla Actualizar ruta, busque el menú desplegable Protocolos
aceptados y seleccione Solo HTTPS .
8. En el campo Protocolo de reenvío, seleccione Solo HTTPS .
9. Haga clic en Actualizar . La Figura 3-41 muestra la configuración
actualizada.
FIGURA 3-41 Actualizar ruta
Configurar escuchas multisitio y configurar objetivos de back-end
Con Azure Front Door Standard y Premium, los nombres de los componentes que se
configuran son diferentes de las puertas de enlace de aplicaciones y el servicio Front Door
original. La figura 3-42 describe cómo se conectan los componentes nombrados.
FIGURA 3-42 Componentes estándar/premium de Azure Front Door
Puede configurar varios puntos de conexión por instancia de Azure Front Door. Cada
extremo tendría su propio azurefd.net FQDN. Cada extremo puede tener uno o más
dominios asociados. Esto sería el equivalente a un agente de escucha multisitio en una
puerta de enlace de aplicaciones.
Cada dominio que agregue debe verificarse si la zona DNS no está administrada en su
suscripción de Azure. El proceso de verificación consiste en agregar un registro TXT con la
cadena de confirmación. Luego, los dominios se asocian con grupos de origen, así como
con políticas WAF.
Los grupos de origen son el equivalente del grupo de back-end para las puertas de
enlace de aplicaciones. En un grupo de origen, crea orígenes individuales, que son los
recursos con los que desea poder comunicarse a través de Front Door. Estos pueden ser
recursos de Azure como App Services o Traffic Manager, o direcciones IP públicas para
aplicaciones locales u otras aplicaciones alojadas en otros proveedores de la nube.
Las rutas especifican cómo se asocian los dominios con los grupos de origen. Puede
especificar patrones específicos para que coincidan en la URL de la solicitud entrante para
restringir a qué URL responde Front Door. De forma predeterminada, la primera ruta
aceptará solicitudes en /* , que sería cualquier directorio en el punto final. Las rutas
también son donde puede establecer si usar HTTP, HTTPS o ambos protocolos en la
conexión entrante y el reenvío al origen.
Para configurar las reglas de enrutamiento para una instancia de puerta principal

Standard/Premium .
6. En la sección Rutas, haga clic en el nombre de la ruta a modificar. Por
ejemplo, haga clic en ruta predeterminada .
7. En la pantalla Actualizar ruta, localice el campo "Patterns to match" y haga
clic en el icono de la papelera para eliminar la entrada de /* .
8. En el campo Patrones para coincidir, ingresa /app1 .
9. Haga clic en Actualizar . La Figura 3-43 muestra la configuración
actualizada.
FIGURA 3-43 Actualizar ruta
Hacer el cambio en el campo Patrones para coincidir requerirá que el tráfico entrante
incluya /app1 en la solicitud entrante al punto final. Si el patrón coincide, el tráfico se
reenviará al grupo de origen mediante HTTPS.
Habilidad 3.5: Implementar un perfil de Azure Traffic Manager
Traffic Manager cae en la discusión del balanceador de carga porque proporciona una
forma de distribuir el tráfico entre varios recursos de back-end, ya sean recursos de Azure
en una sola región, en varias regiones o incluso alojados fuera de Azure. Sin embargo, en
lugar de equilibrar la carga en la capa 4 o la capa 7, Traffic Manager equilibra la carga
mediante el uso de DNS.
Cuando un cliente inicia una conexión que utiliza Traffic Manager, el método de
enrutamiento que configura determina a qué recurso de back-end debe conectarse el
cliente. Pero en lugar de facilitar la conexión como lo hace una puerta de enlace de
aplicaciones o Front Door, Traffic Manager proporciona al cliente el nombre DNS del
recurso al que conectarse y el cliente se conecta directamente al recurso. Por lo tanto,
Traffic Manager es simplemente un equilibrador de carga basado en DNS.

 Configurar un método de enrutamiento
 Configurar puntos finales
 Crear configuraciones HTTP
Configurar un método de enrutamiento
Se requiere un método de enrutamiento cuando configura un perfil de Traffic Manager y

determina cómo se selecciona un recurso de back-end, denominado punto final en Traffic
Manager, para la conexión del cliente. Hay seis métodos de enrutamiento disponibles y
debe seleccionar uno para el perfil de Traffic Manager. Los métodos de enrutamiento son:
 Actuación. El rendimiento depende de la latencia hasta el extremo para

proporcionar a la conexión del cliente la conexión de latencia más baja posible en
ese momento. Traffic Manager realiza un seguimiento de la latencia de cada
extremo mediante el uso de una tabla de latencia de Internet interna para realizar un
seguimiento del tiempo de ida y vuelta.
 Ponderado. Ponderado le permite distribuir el tráfico entre múltiples puntos
finales en la proporción que especifique. Si proporciona el mismo peso a todos los
puntos finales, el tráfico se distribuirá de manera uniforme.
 Prioridad. Prioridad le permite establecer una prioridad para cada punto
final para permitir tipos de configuraciones activas/pasivas. El punto final que tiene
el entero más bajo se considera como el de mayor prioridad.
 Geográfico. Geográfica se basa en la geografía de la conexión del cliente
para dirigir a los usuarios a puntos finales específicos. Esto es útil en escenarios de
cumplimiento o soberanía de datos donde la ubicación del usuario final puede
determinar a qué punto final conectarse.
 multivalor. MultiValue permite que el servicio responda con múltiples
puntos finales con una consulta de DNS. MultiValue solo se puede usar con
extremos externos que son direcciones IPv4 o IPv6, no FQDN.
 subred. El enrutamiento de subred le permite asignar rangos de IP a ciertos
puntos finales. Luego, si se recibe una solicitud de conexión de una IP en ese rango,
Traffic Manager responde con el extremo que haya configurado. Si necesita un
punto final para ciertos rangos de IP y un punto final diferente para otros rangos,
este método de enrutamiento es útil.
Para configurar un perfil de Traffic Manager en una configuración activa/pasiva, siga

estos pasos:

2. En la barra de búsqueda, busque y seleccione perfiles de Traffic Manager .
3. En la página de Traffic Manager, haga clic en Crear .
4. En el campo Nombre, proporcione un nombre para el perfil de Traffic
Manager. El nombre debe ser globalmente único, ya que crea un nombre
de dominio .trafficmanager.net . Por ejemplo, nombre el perfil az700tm .
5. En el menú desplegable Método de enrutamiento, seleccione Prioridad .
el recurso de Traffic Manager. Esto no tiene que estar en la misma suscripción que
los puntos finales.
7. En el campo Grupo de recursos, seleccione un grupo de recursos
adecuado. Por ejemplo, seleccione Redes .
8. Haz clic en Crear . La Figura 3-44 muestra la configuración completa.
FIGURA 3-44 Crear perfil de Traffic Manager
Estos pasos crean el perfil de Traffic Manager con el método de enrutamiento

prioritario. Entonces, esto requeriría que se definan al menos dos puntos finales en el perfil
con valores de prioridad agregados para cada punto final. El punto de enlace con el valor
entero más bajo recibiría todo el tráfico, siempre que el sondeo de estado muestre que el
punto de enlace está en buen estado.
Para cambiar el método de enrutamiento de un perfil de Traffic Manager existente, siga

estos pasos.

3. En la página de Traffic Manager, seleccione el perfil creado
anteriormente, az700tm .
4. En la página de perfil de Traffic Manager, haga clic en
la hoja Configuración .
5. En el menú desplegable Método de enrutamiento, seleccione el método de
enrutamiento deseado. Por ejemplo, seleccione Rendimiento .
6. Haga clic en Guardar . La Figura 3-45 muestra una parte de la hoja
Configuración.
FIGURA 3-45 Configuración de Traffic Manager
Configurar puntos finales
Los perfiles de Traffic Manager requieren puntos finales como los recursos de back-end a
los que los clientes se conectan directamente. Traffic Manager actúa como un servicio de
DNS recursivo que responde con un punto final basado en el método de enrutamiento. Los
pasos generales para este proceso son:
1. Un cliente envía una solicitud para conectarse a una aplicación, como un

sitio web en app1.contoso.com .
2. La configuración de IP del cliente solicita al servidor DNS configurado la
dirección IP de app1.contoso.com.
3. Este FQDN es un CNAME que apunta a un perfil de Traffic Manager. El
perfil maneja la solicitud de DNS y responde al servidor DNS con un punto final,
según el método de enrutamiento.
4. El servidor DNS proporciona la información del punto final al cliente como
respuesta DNS.
5. El cliente se conecta directamente al extremo y almacena en caché la
consulta de DNS para el TTL configurado en Traffic Manager.
La Figura 3-46 diagrama el proceso para cada uno de estos pasos.

FIGURA 3-46 Diagrama de DNS de Traffic Manager
Hay tres tipos de extremos que puede configurar en un perfil de Traffic Manager:
 Punto final de Azure. Estos son recursos que ha implementado en su

entorno de Azure.
 Punto final externo. Esta es una dirección IP pública o FQDN fuera de su
entorno de Azure.
 Punto final anidado. Esto es para implementaciones de alta disponibilidad
en las que un extremo es otro perfil de Traffic Manager en una región diferente para
la conmutación por error.
Para crear un servicio de aplicaciones como punto de conexión de Azure, siga estos
pasos:

4. En la página de perfil de Traffic Manager, haga clic en la hoja Endpoints .
5. En la hoja Endpoints, haga clic en Agregar .
6. Asegúrese de que el menú desplegable Tipo esté establecido en Punto de
conexión de Azure .
7. En el campo Nombre, proporcione un nombre para el punto final. Por
ejemplo, ingrese as-eus-app1 .
8. En el campo desplegable Tipo de recurso de destino, seleccione App
Service .
9. En el campo desplegable Recurso de destino, seleccione un servicio de
aplicaciones que haya implementado anteriormente. Por ejemplo,
seleccione az700demoapp1 .
10. En el campo Prioridad, establezca una prioridad para el recurso de
destino. Cuanto menor sea el número entero, mayor será la prioridad del
recurso. Por ejemplo, establezca esto en 50 .
11. Deje los campos restantes configurados como predeterminados y haga clic
en Agregar . La Figura 3-47 muestra la configuración completa.
FIGURA 3-47 Agregar punto final
Si navega a la URL del perfil de Traffic Manager, ahora será redirigido al servicio de la
aplicación porque es el único punto final que se ha agregado. Repita estos pasos tantas
veces como sea necesario para agregar los recursos de back-end al perfil de Traffic
Manager. Tenga en cuenta que no puede mezclar puntos de conexión de Azure y puntos de
conexión externos en la misma configuración de perfil.
Crear configuraciones HTTP
El objetivo "Crear configuración de HTTP" es interesante porque, como comentamos en

esta sección de habilidades, Traffic Manager es un servicio de DNS recursivo que no
maneja el tráfico de aplicaciones (HTTP/HTTPS). Los únicos ajustes que puede configurar
en un perfil de Traffic Manager que contienen HTTP son el sondeo de estado y los
encabezados personalizados que se pueden agregar. Puede agregar hasta ocho pares de
encabezados y valores personalizados al campo de configuración de encabezado
personalizado.
Para personalizar la configuración de la sonda de estado, siga estos pasos:

4. En la página de perfil de Traffic Manager, haga clic en
la hoja Configuración .
5. En el campo Configuración de encabezado personalizado, ingrese cualquier
encabezado para agregar a la sonda de estado en el formato de encabezado: valor .
6. En el campo Rangos de códigos de estado esperados, especifique códigos de
estado HTTP adicionales para que los acepte la sonda de estado. Por ejemplo,
ingrese 200-202 .
7. Haga clic en Guardar . La Figura 3-48 muestra la configuración
actualizada.
FIGURA 3-48 Configuración de Traffic Manager
Habilidad 3.6: Diseñar e implementar una NAT de Azure Virtual Network
Cuando implementa máquinas virtuales, asocia la tarjeta de interfaz de red de esa VM a una
subred. La subred es entonces parte de una red virtual más amplia. Si ha leído el capítulo
que incluye los grupos de seguridad de la red, quizás recuerde que todo el tráfico saliente
está permitido de manera predeterminada desde una máquina virtual. De forma
predeterminada, si la máquina virtual no tiene una dirección IP pública asignada a la NIC,
se conecta a Internet mediante una dirección IP aleatoria asignada a esa región de Azure.
 Elija cuándo usar una NAT de red virtual
 Asignar IP pública o prefijos de IP pública para una puerta de enlace NAT
 Asociar un NAT de red virtual con una subred
Elija cuándo usar una NAT de red virtual
Tener una dirección IP saliente aleatoria podría ser problemático si la VM necesita

conectarse a servicios externos específicos que requieren una regla de firewall o conocer la
IP de origen de su VM. Puede lograr esto mediante el uso de una puerta de enlace
NAT. Una puerta de enlace NAT es un recurso que se configura con una dirección IPv4
pública o un rango de direcciones IPv4 públicas y se asocia con una red virtual. Luego,
cualquier VM dentro de la red virtual usará una dirección IP que configure cuando se
comunique con Internet. La Figura 3-49 muestra el diseño básico del uso de una puerta de
enlace NAT.
FIGURA 3-49 Diseño de puerta de enlace NAT
Asignar direcciones IP públicas para una puerta de enlace NAT
Cuando crea una puerta de enlace NAT, necesita al menos una dirección IP pública para la
puerta de enlace. Esta es la dirección IP que se colocará en el encabezado del paquete
saliente desde cualquier máquina virtual en la red virtual.
Para crear una puerta de enlace NAT, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione puertas de enlace NAT .
3. En la página de puertas de enlace NAT, haga clic en Crear .
la puerta de enlace NAT. Esta debe ser la misma que la red virtual con la que planea
asociar la puerta de enlace NAT.
5. En el menú desplegable Grupo de recursos, seleccione el grupo de recursos
deseado. Por ejemplo, seleccione Redes .
6. En el campo de nombre de la puerta de enlace NAT, proporcione un nombre
para la puerta de enlace. Por ejemplo, ingrese nat-vnet1 .
7. En el menú desplegable Región, seleccione la región de Azure deseada. Esta
debe ser la misma región que su red virtual. Por ejemplo, seleccione Este de EE.
UU .
8. Deje los campos restantes establecidos en sus valores predeterminados y
haga clic en Siguiente: IP saliente . La Figura 3-50 muestra la pestaña Conceptos
básicos completada.
FIGURA 3-50 Aspectos básicos de la creación de una puerta de enlace NAT
9. En la pestaña IP saliente, haga clic en Crear una nueva dirección IP

pública .
10. En el campo Agregar una dirección IP pública, nombre la nueva dirección IP
pública nat-pip1 .
11. Haga clic en Aceptar . La Figura 3-51 muestra la pantalla Agregar una
dirección IP pública.
FIGURA 3-51 Agregar una dirección IP pública
12. Haga clic en Siguiente: Subred .

13. En el menú desplegable Red virtual, seleccione la red virtual deseada para
asociar la puerta de enlace NAT. Por ejemplo, seleccione hub-vnet-eus-01 .
14. Las subredes disponibles se mostrarán debajo de la selección. Seleccione las
casillas de verificación junto a las subredes deseadas para incluir con la puerta de
enlace NAT.
15. Haz clic en Revisar y crear . La Figura 3-52 muestra la pestaña Subred
completa.
FIGURA 3-52 Crear puerta de enlace NAT: subredes
Asociar una red virtual NAT con una subred
Cuando crea la puerta de enlace NAT, puede seleccionar las subredes que existen en ese
momento para asociar la puerta de enlace NAT. Sin embargo, si agrega subredes a la
misma red virtual, no se asocian con la puerta de enlace NAT de forma predeterminada.
Puede realizar la asociación desde la página de subredes dentro de la red virtual o desde
la puerta de enlace NAT. Para asociar la subred con la puerta de enlace NAT desde la
página de subred, siga estos pasos:

3. En la página de la red virtual, seleccione la red virtual asociada
anteriormente. Por ejemplo, seleccione hub-vnet-eus-01 .
4. En la hoja de red virtual seleccionada, seleccione la hoja Subredes .
5. En la página Subredes, haga clic en la subred recién creada. Por ejemplo,
haga clic en app2 .
6. En el menú desplegable de la puerta de enlace NAT, seleccione la puerta de
enlace NAT. Por ejemplo, seleccione nat-vnet1 .
7. Haga clic en Guardar . Nota: Al momento de escribir este artículo, hay un
error en la interfaz de usuario que le impide guardar la configuración con este
método.
Si desea realizar la asociación desde la puerta de enlace NAT, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione puertas de enlace NAT .
3. En la página de puertas de enlace NAT, seleccione la puerta de enlace NAT
existente. Por ejemplo, seleccione nat-vnet1 .
4. En la puerta de enlace NAT, haga clic en la hoja Subredes .
5. Seleccione la casilla de verificación junto a la subred recién creada. Por
ejemplo, seleccione app2 .
6. Haga clic en Guardar . La Figura 3-53 muestra la asociación de subred
actualizada.
FIGURA 3-53 Subredes de puerta de enlace NAT
 Las rutas integradas del sistema permiten el tráfico saliente desde las
máquinas virtuales en una red virtual a Internet.
 Las subredes dentro de una red virtual pueden comunicarse entre sí sin
requisitos de enrutamiento adicionales.
 Las rutas definidas por el usuario pueden manipular el flujo de tráfico para
desviarse del enrutamiento predeterminado.
 Cuando crea rutas definidas por el usuario para reenviar el tráfico a través de
un firewall local, el concepto se denomina tunelización forzada.
 Los equilibradores de carga de Azure están disponibles en las SKU básicas y
estándar.
 Los balanceadores de carga proporcionan balanceo de carga de capa 4 en el
grupo de back-end que especifique.
 Los balanceadores de carga pueden ser internos, con una dirección IP
privada, o externos, con una dirección IP pública.
 Load Balancer Basic SKU es un servicio de balanceador de carga gratuito,
pero tiene opciones limitadas de grupo de back-end y no tiene alta disponibilidad.
 Los balanceadores de carga tienen una dirección IP de front-end, un grupo
de back-end, sondeos de estado y reglas que definen cómo se reenvía el tráfico.
 Los balanceadores de carga pueden incluir reglas NAT para traducir
direcciones entrantes y números de puerto.
 Las puertas de enlace de aplicaciones de Azure proporcionan equilibrio de
carga de capa 7 en el grupo de back-end que especifique.
 Las puertas de enlace de aplicaciones se pueden escalar a varias instancias
de forma manual o con reglas de escalado automático.
 Las puertas de enlace de aplicaciones proporcionan enrutamiento basado en
dominios y rutas a recursos de back-end específicos.
 Las puertas de enlace de aplicaciones incluyen direcciones IP de front-end,
grupos de back-end, agentes de escucha, sondeos de estado y reglas que definen
cómo se reenvía el tráfico.
 Las puertas de enlace de aplicaciones pueden reescribir los encabezados
antes de reenviarlos a un grupo de back-end.
 Las puertas de enlace de aplicaciones pueden realizar la terminación TLS y
el cifrado TLS de extremo a extremo.
 Azure Front Door combina equilibrio de carga de capa 7, seguridad, entrega
de contenido y optimización de contenido en un solo servicio.
 Front Door es un servicio global que no se implementa en una sola región.
 Front Door se implementa como un extremo que puede tener asociados
dominios personalizados.
 Front Door tiene grupos de origen que contienen orígenes o recursos de
back-end a los que se conectan los clientes.
 Azure Traffic Manager es un servicio de enrutamiento basado en DNS que
usa DNS recursivo para apuntar las conexiones de los clientes a un recurso de back-
end.
 Traffic Manager usa métodos de enrutamiento para determinar cómo
seleccionar un punto de conexión o un recurso de back-end para el cliente.
 Al usar Traffic Manager, los clientes se conectan directamente al punto final
y solo usan Traffic Manager para DNS.
 Las puertas de enlace NAT proporcionan una forma para que las máquinas
virtuales compartan una dirección IP saliente.
 Las puertas de enlace NAT están asociadas con una red virtual y subredes
seleccionables dentro de esa red virtual.
 Las puertas de enlace NAT solo admiten direcciones IP públicas IPv4.
Experimento mental

Una organización planea implementar una nueva suscripción de Azure para una
aplicación de tres niveles. El primer nivel, el nivel web, será la interfaz de una aplicación
web hospedada en Azure App Services. El servicio de aplicaciones se comunica con una
API personalizada en un nivel lógico que se hospedará en un conjunto de escalado de
máquinas virtuales (VMSS). El tercer nivel es el nivel de datos, que se hospedará en Azure
SQL Managed Instances.
El VMSS se comunicará con un software de informes de terceros. El proveedor externo

tiene el requisito de que todo el tráfico entrante debe provenir de la misma dirección
IP. Todo el tráfico saliente de las máquinas virtuales debe usar la misma dirección IP
pública
La organización planea implementar esta aplicación en cuatro regiones de Azure en

América del Norte y Europa. A medida que los usuarios se conectan a la aplicación web,
deben ser dirigidos a la instancia más cercana de la aplicación según su ubicación
geográfica. La solución de ingreso debe proporcionar la capacidad de realizar el cifrado
TLS de extremo a extremo y proporcionar informes de seguridad.
1. 1 . ¿Qué debe usar la organización como solución de ingreso?

2. 2 . ¿Qué debe implementar la organización para que los servicios de la aplicación se
comuniquen con el VMSS?
3. 3 . ¿Qué debe implementar la organización para que el VMSS se comunique con el
proveedor externo?
1. 1 . ¿Qué debe usar la organización como solución de ingreso?
Según el escenario general, podría parecer que una puerta de enlace de aplicaciones
o Azure Front Door funcionarían como una solución de ingreso. Sin embargo, el
requisito de informes de seguridad apunta la solución hacia Azure Front
Door. Además, debido a que la organización usa al menos cuatro regiones de Azure,
Front Door probablemente sería una mejor opción de costo que implementar puertas
de enlace de aplicaciones en cada región, lo que probablemente costaría más.
2. 2 . ¿Qué debe implementar la organización para que los servicios de la aplicación se

comuniquen con el VMSS?
Como solución de entrada al VMSS, un equilibrador de carga de Azure sería
suficiente para distribuir el tráfico desde los servicios de la aplicación al VMSS.
3. 3 . ¿Qué debe implementar la organización para que el VMSS se comunique con el

proveedor externo?
La red virtual a la que está asociado el VMSS debe configurarse con una puerta de
enlace NAT. La puerta de enlace NAT puede tener una sola dirección IP pública
asociada, que representará el VMSS a medida que se comunica de forma
saliente. Esta dirección IP se puede proporcionar al proveedor externo para que se
incluya en la lista de permitidos en su firewall.
¿NECESITA MÁS
REVISIÓN? APLICACIÓN WEB
ESCALABLE
Para obtener más información sobre una arquitectura de referencia para una
aplicación web escalable, visite https://docs.microsoft.com/en-
us/azure/architecture/reference-architectures/app-service-web-app/scalable-web-app .
Capítulo 4
Asegure y monitoree las redes
Este capítulo presenta soluciones adicionales de seguridad y monitoreo para redes virtuales
y los recursos que se conectarán. Esto comienza con el servicio Azure Firewall, que se
asocia con una red virtual. Todo el tráfico entrante y saliente puede atravesar el
cortafuegos. Luego, dentro de la red virtual, puede configurar grupos de seguridad de red
para filtrar el tráfico de una subred a otra. Además, las políticas de Web Application
Firewall se pueden usar con Azure Front Door o Azure Application Gateway para
administrar conjuntos de reglas. Finalmente, hay varias herramientas en Network Watcher
para ayudar con el monitoreo de la red virtual y los recursos.
 Habilidad 4.1: Diseñar, implementar y administrar una implementación de

Azure Firewall
 Habilidad 4.2: Implementar y administrar grupos de seguridad de red (NSG)
 Habilidad 4.3: Implementar una implementación de Firewall de aplicaciones
web (WAF)
 Habilidad 4.4: Monitorear redes
Habilidad 4.1: Diseñar, implementar y administrar una implementación de Azure Firewall
Azure Firewalls proporciona filtrado de paquetes e inspección de paquetes con estado. Eso
significa que puede filtrar en el nivel de capa 3 en función de la dirección IP, el puerto y el
protocolo de origen o destino. También puede proteger los recursos en el nivel de capa 7
haciendo que el firewall inspeccione los encabezados en busca del nombre de dominio
completo (FQDN) o la etiqueta de servicio de Azure con la que el paquete podría estar
intentando comunicarse. En esta sección de habilidades, analizamos dónde se incluye
Azure Firewall en un diseño y cómo implementar y configurar el firewall.

 Diseñar una implementación de Azure Firewall
 Crear e implementar una implementación de Azure Firewall
 Configurar reglas de Azure Firewall
 Crear e implementar políticas de Azure Firewall Manager
 Cree un centro seguro implementando Azure Firewall dentro de un centro de
Azure Virtual WAN
Diseñar una implementación de Azure Firewall
Un Azure Firewall es un firewall con estado administrado que puede implementar para
inspeccionar el tráfico en los modelos de implementación este-oeste y norte-sur. Azure
Firewalls puede realizar el filtrado y la inspección de paquetes desde las capas 3 a 7 del
modelo OSI. Hay dos SKU de Azure Firewall: Estándar y Premium . El SKU estándar
incluye las siguientes características:
 Alta disponibilidad, incluidas las zonas de disponibilidad

 Escalabilidad sin restricciones
 Reglas de filtrado de FQDN de la aplicación
 Reglas de filtrado de tráfico de red
 etiquetas FQDN
 Etiquetas de servicio
 Inteligencia de amenazas con inspección de paquetes
 servidor proxy DNS
 DNS personalizado
 Modo de túnel forzado
 Compatibilidad con SNAT saliente
 Soporte de DNAT entrante
 Múltiples direcciones IP públicas
 Registro de Azure Monitor
 Filtrado de categorías web
 Certificaciones de la industria
Si elige implementar el SKU Premium, recibe todas las funciones estándar y obtiene
estas funciones adicionales:
 Inspección TLS
 Detección y prevención de intrusiones
 Filtrado de URL
 Filtrado avanzado de categorías web
El SKU Premium requiere que use las políticas de Firewall Manager para configurar las
características del firewall. El SKU estándar tiene la capacidad de usar Firewall Manager o
configurar reglas individuales en un solo firewall.
El SLA que puede admitir su diseño está determinado por cómo decide implementar
Azure Firewall. Si implementa un firewall en una región que no admite zonas, o
implementa solo en una zona, el SLA del firewall es del 99,95 %. Si implementa un
firewall en al menos dos zonas, el SLA aumenta al 99,99 %.
Cuando implementa un firewall, debe estar asociado con una única red virtual. El
firewall actuará como una puerta para cualquier tráfico que entre o salga de la red
virtual. Puede combinar esto con conexiones de emparejamiento a otras redes virtuales y
rutas definidas por el usuario para forzar el tráfico de este a oeste a través del firewall antes
de abandonar la región. La Figura 4-1 muestra una arquitectura de muestra con una
conexión VPN local y dos redes radiales que se emparejan con una red central.
FIGURA 4-1 Conexión híbrida con Azure Firewall
Las reglas de filtrado que configura le permiten permitir o denegar específicamente el

tráfico de red en función de la dirección IP de origen y destino, el número de puerto, el
protocolo o el FQDN. El filtro FQDN se considera filtrado de aplicaciones y las opciones
restantes se consideran filtrado de red.
Crear e implementar una implementación de Azure Firewall
Cuando crea un Azure Firewall, existen los requisitos de recursos básicos: una suscripción,
un grupo de recursos y una región. Azure Firewall debe implementarse en la misma región
que la red virtual. La red virtual no puede tener otro firewall ya implementado o asociado
con la red virtual.
Para implementar un Firewall de Azure, siga estos pasos:

2. En la barra de búsqueda, busca y selecciona Firewalls .
3. En la página Cortafuegos, haga clic en Crear .
4. En el menú desplegable Suscripción, seleccione la suscripción que contiene
la red virtual con la que desea asociar el firewall.
5. En el campo Grupo de recursos, seleccione o cree un grupo de recursos para
agrupar el cortafuegos. Por ejemplo, seleccione Redes .
6. En el campo Nombre, proporcione un nombre para el cortafuegos. Por
ejemplo, ingrese fw-eus-vnet1 .
7. En el menú desplegable Región, seleccione una región de Azure para
implementar el firewall. Esta debe ser la misma que la red virtual. Por ejemplo,
seleccione Este de EE. UU .
8. En el campo Zona de disponibilidad, deje el valor
predeterminado Ninguno .
9. Para la opción de nivel de Firewall, deje el valor predeterminado Estándar .
10. En el campo Administración de firewall, seleccione Usar reglas de firewall
(clásico) para administrar este firewall . Comenzaremos con esta configuración y
veremos las políticas de Firewall Manager más adelante en esta sección de
habilidades.
11. En el campo Elegir una red virtual, seleccione Usar existente . También
tiene la capacidad de crear una nueva red virtual si aún no ha creado una.
12. En el menú desplegable Red virtual, seleccione la red virtual deseada. Por
ejemplo, seleccione hub-vnet-eus-01 . La red virtual ya debe tener una subred
denominada AzureFirewallSubnet ; no puede crear la subred desde la página Crear
un firewall.
13. En el campo Dirección IP pública, haga clic en Agregar nuevo .
14. Nombre la dirección IP pública pip-fw01 y luego haga clic en Aceptar .
15. Haga clic en Revisar y crear y, a continuación, haga clic en Crear . La
Figura 4-2 muestra la pantalla Crear un firewall completada.
FIGURA 4-2 Conexión híbrida con Azure Firewall
Configurar reglas de Azure Firewall
Las reglas de Azure Firewall se pueden administrar desde dos lugares, según cómo haya
implementado el firewall. Al usar la configuración "Reglas de firewall (clásico)" durante la
implementación, puede crear y configurar reglas directamente en el firewall. Si elige usar
Firewall Manager, puede crear políticas, que luego pueden contener reglas (y otras
configuraciones) que se pueden aplicar a múltiples firewalls. Las políticas se discutirán más
en la siguiente sección.
Las reglas de firewall clásicas se pueden crear en tres categorías:
 Colecciones de reglas NAT

 Colecciones de reglas de red
 Colecciones de reglas de aplicación
Las reglas de la red y la aplicación se pueden configurar para permitir o denegar la
acción a realizar en los paquetes. La colección de reglas NAT es simplemente una
traducción de la dirección y los números de puerto de la dirección IP pública a una
dirección interna. Cada colección también tiene un valor de prioridad que usted configura,
que es un número entero entre 100 y 65 000. Al igual que con otras listas de prioridad en
Azure, cuanto menor sea el número entero, mayor será la precedencia de la regla.
Para crear una colección de reglas NAT, siga estos pasos:

3. En la página Firewalls, seleccione el firewall que creó anteriormente. Por
ejemplo, seleccione fw-eus-vnet1 .
4. En la página del cortafuegos, haga clic en la hoja Reglas (clásicas) .
5. En la página Reglas (clásica), asegúrese de estar en la pestaña de
recopilación de reglas NAT. Haga clic en Agregar colección de reglas NAT .
6. En el campo Nombre, proporcione un nombre para la primera colección de
reglas. Por ejemplo, ingrese NAT-Externo-HTTPS .
7. En el campo Prioridad, proporcione una prioridad para la regla. Por ejemplo,
ingrese 500 .
8. En el campo Reglas, utilice la siguiente información para crear la regla:
1. Nombre: 8443HTTPS
2. Protocolo: TCP
3. Tipo de fuente: dirección IP
4. Fuente: *
5. Dirección de destino: <Su dirección IP pública>
6. Puertos de Destino: 8443
7. Dirección traducida: 10.0.1.4
8. Puerto traducido: 443
9. Haga clic en Agregar . La Figura 4-3 muestra la colección de reglas NAT completa.
FIGURA 4-3 Adición de una colección de reglas NAT
La colección de reglas completa buscará el tráfico TCP destinado a la dirección IP

pública del cortafuegos y lo traducirá a una dirección interna con un puerto de destino de
8443. El cortafuegos modificará el paquete y traducirá el puerto de destino a 443. Esto le
permitiría para usar un número de puerto personalizado para una aplicación y ocultar el
puerto real que se usa internamente.
La adición de colecciones de reglas de red y aplicación es similar, pero le permite

seleccionar si se permite o deniega el tráfico de red. Las colecciones de reglas de red se
pueden basar en direcciones IP, etiquetas de servicio o FQDN. Las etiquetas de servicio son
categorías predefinidas de servicios de Azure que puede elegir como un servicio global o
para cada región específica. Por ejemplo, si desea que un rango de IP pueda comunicarse
con Azure Storage en el Este de EE. UU. pero no en el Oeste de EE. UU., puede permitir la
etiqueta de servicio de almacenamiento para el Este de EE. UU. y luego denegar la etiqueta
de servicio de almacenamiento para el Oeste de EE. UU.
Para crear una colección de reglas de red usando este ejemplo, siga estos pasos:

5. En la página Reglas (clásica), haga clic en la pestaña Colección de reglas de
red .
6. En la página Colección de reglas de red, haga clic en Agregar colección de
reglas de red .
7. En el campo Nombre, proporcione un nombre para la colección de
reglas. Por ejemplo, ingrese Allow-Azure-Storage-Subnet1 .
8. En el campo Prioridad, ingrese una prioridad para la regla. Por ejemplo,
ingrese 500 .
9. En el menú desplegable Acción, deje la configuración predeterminada
de Permitir .
10. En la sección Etiquetas de servicio, use la siguiente información para
completar la configuración:
1. Nombre: Permitir almacenamiento
2. Protocolo: Cualquiera
4. Fuente: 10.0.1.0/24
5. Etiquetas de servicio: Storage.EastUS
6. Puertos de destino: *
FIGURA 4-4 Adición de una colección de reglas de red
El ejemplo anterior asume que la subred1 tiene un rango de direcciones de 10.0.1.0/24,

como se identifica en el campo Fuente. En este escenario, si el tráfico está destinado a
Azure Storage en la región Este de EE. UU., se permitirá, suponiendo que no haya otra
regla con una prioridad de prioridad más alta que pueda denegarlo.
Las colecciones de reglas de aplicación son similares, pero en su lugar se configuran en

función de etiquetas FQDN o FQDN de destino. Por ejemplo, si necesita bloquear el acceso
a contoso.com , puede bloquear el dominio según el protocolo o los números de puerto.
Para crear una colección de reglas de aplicación usando este ejemplo, siga estos pasos:

5. En la página Reglas (clásica), haga clic en la pestaña Colección de reglas de
aplicación .
6. En la pestaña Colección de reglas de aplicación , haga clic en Agregar
colección de reglas de aplicación .
7. En el campo Nombre, proporcione un nombre para la colección de
reglas. Por ejemplo, ingrese Deny-Contoso .
8. En el campo Prioridad, ingrese un valor para la prioridad. Por ejemplo,
ingrese 500 .
9. En el menú desplegable Acción, seleccione Denegar .
10. En la sección Target FQDN, use la siguiente información para configurar la
regla:
1. Nombre: Contoso
3. Fuente: 10.0.1.0/24
4. Protocolo:Puerto: HTTP, HTTPS
5. FQDN de destino: www.contoso.com
FIGURA 4-5 Adición de una colección de reglas de aplicación
Crear e implementar políticas de Azure Firewall Manager
En una empresa en la que puede realizar implementaciones en varias regiones de Azure y

necesita varios firewalls, la administración de reglas en cada firewall puede convertirse en
una pesadilla administrativa. Por lo tanto, se recomienda usar políticas con Firewall
Manager y luego asociar las políticas con los firewalls. Esto le brinda una manera fácil de
administrar las reglas para todos los firewalls en una sola ubicación.
Para crear una política mediante Firewall Manager, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Firewall Manager .
3. En la página Firewalls, seleccione la hoja Políticas de Azure Firewall .
4. En la página Políticas de Azure Firewall, haga clic en Crear política de
Azure Firewall .
Azure Firewall.
agrupar la política. Por ejemplo, seleccione Redes .
ejemplo, ingrese fwpolicy-eus-01 .
8. En el menú desplegable Región, seleccione la región para la política. Por
ejemplo, ingrese Este de EE. UU . A diferencia de otros recursos, la política puede
estar en cualquier región y aplicarse a firewalls que se encuentran en diferentes
regiones.
9. En el campo Nivel de política, seleccione Estándar . Esto coincide con el
SKU del firewall que se implementó anteriormente en esta sección de habilidades.
10. Haga clic en Siguiente: Configuración de DNS . La Figura 4-6 muestra la
pestaña Conceptos básicos completada.
FIGURA 4-6 Conceptos básicos de la política de firewall
11. En la pestaña Configuración de DNS, establezca la política en Activada y

deje la configuración predeterminada.
12. Haga clic en Siguiente: Inspección TLS . La Figura 4-7 muestra la pestaña
Configuración de DNS configurada.
FIGURA 4-7 Configuración de DNS de la política de firewall
13. En la página de inspección de TLS, observe que las opciones no están

disponibles. Esto se debe a que se seleccionó la política Estándar en la pestaña
Conceptos básicos. Haga clic en Siguiente: Reglas .
14. En la pestaña Reglas, haga clic en Importar reglas desde un Firewall de
Azure .
15. Seleccione el firewall que se implementó y configuró previamente con
reglas en la sección anterior y luego haga clic en Importar .
16. Haga clic en Siguiente: IDPS . La Figura 4-8 muestra las reglas importadas.
FIGURA 4-8 Reglas de política de firewall
17. En la página de IDPS, observe que las opciones no están disponibles. Esto se
debe a que se seleccionó la política Estándar en la pestaña Conceptos básicos. Haga
clic en Siguiente: Inteligencia de amenazas .
18. En la pestaña Inteligencia de amenazas, deje el modo predeterminado
establecido en Solo alerta .
Cree un centro seguro implementando Azure Firewall dentro de un centro de Azure Virtual WAN
También puede usar un Firewall de Azure para filtrar y proteger el tráfico en una WAN
virtual de Azure. Las WAN virtuales se analizaron en el Capítulo 2 , pero brindan
conectividad híbrida en varios tipos de conexión: redes virtuales, VPN y ExpressRoute. Si
ya tiene un centro de Azure Virtual WAN, puede asociar un firewall y una política de
firewall al centro existente, o puede crear un nuevo centro virtual.
Para crear un centro seguro, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Firewall Manager .
3. En la página Firewalls, seleccione la hoja Virtual Hubs .
4. En la hoja Centros virtuales, haga clic en Crear nuevo centro virtual
seguro .
Azure Firewall.
agrupar la política. Por ejemplo, seleccione Redes .
ejemplo, ingrese shub-eus-01 .
8. En el menú desplegable Región, seleccione la región para la política. Por
ejemplo, seleccione Este de EE. UU .
9. En el campo Espacio de direcciones del concentrador, proporcione un rango
de direcciones para el concentrador. Este rango no puede superponerse con otros
rangos en Virtual WAN. Por ejemplo, ingrese 172.16.0.0/16 .
10. En el campo Elija una vWAN existente o cree una nueva, seleccione la
configuración deseada si tiene una WAN virtual existente. Para este ejemplo,
seleccione Nueva vWAN .
11. En el campo Nombre de WAN virtual, proporcione un nombre para la WAN
virtual. Por ejemplo, ingrese vwan-eus-01 .
12. Deje los campos restantes con los valores predeterminados y haga clic
en Siguiente: Azure Firewall . La Figura 4-9 muestra la pestaña Conceptos básicos
completada.
FIGURA 4-9 Conceptos básicos del nuevo centro virtual seguro
13. En la pestaña Azure Firewall, revise los valores predeterminados como se

muestra en la Figura 4-10 . Estos valores son apropiados para este ejemplo; haga
clic en Siguiente: Proveedor de socios de seguridad .
14. En la pestaña Proveedor de socios de seguridad, revise los proveedores de
seguridad de terceros disponibles. Si decide que desea utilizar uno de estos
proveedores, también debe implementar una puerta de enlace de red virtual para
conectarse al dispositivo de terceros. Deje el campo Proveedor de socios de
seguridad establecido en Deshabilitado y luego haga clic en Siguiente: Revisar +
Crear .
Cuando crea un concentrador seguro con Virtual WAN, se le presenta la opción de

integrarse con un proveedor externo. En el momento de escribir este artículo, hay tres
proveedores externos compatibles con centros virtuales seguros:
 punto de control
 iboss
 Escalador Z
Si elige integrarse con uno de estos proveedores, también debe implementar una puerta
de enlace de red virtual para establecer una conexión segura (VPN) con el dispositivo.
FIGURA 4-10 Nuevo centro virtual seguro Azure Firewall
Habilidad 4.2: Implementar y administrar grupos de seguridad de red (NSG)
Los grupos de seguridad de red (NSG) proporcionan filtrado de paquetes en la capa de

tarjeta de interfaz de red o subred. En comparación con el hardware local, es posible que
esté familiarizado con este tipo de reglas por otro nombre: listas de control de acceso
(ACL) . Si ha configurado ACL anteriormente, los NSG funcionan de manera muy
similar. Los NSG observan el encabezado de un paquete y validan el paquete con las reglas
configuradas para determinar si el paquete debe permitirse o denegarse. Los NSG son un
concepto de seguridad fundamental dentro de una red virtual, ya que, de forma
predeterminada, se permite la comunicación de subred a subred en todos los puertos y
protocolos.

 Crear un grupo de seguridad de red
 Asociar un NSG a un recurso
 Crear un grupo de seguridad de aplicaciones (ASG)
 Asociar un ASG a una NIC
 Crear y configurar reglas de NSG
 Interpretar y validar registros de flujo de NSG
 Verificar el flujo de IP
Crear un grupo de seguridad de red
Un NSG proporciona filtrado de paquetes en el nivel de interfaz de red de máquina virtual o

subred. Tenga en cuenta la distinción entre el filtrado de paquetes y la inspección de
paquetes . Un NSG no analiza la carga útil del paquete para identificar un nombre de
dominio completo. El NSG solo mira el encabezado del paquete y proporciona un filtrado
basado en los encabezados: dirección IP de origen y destino, puerto y protocolo. Esto
significa que puede permitir o denegar el tráfico que ingresa (entrante) o sale (saliente) del
recurso con el que asocia el NSG. Los NSG se pueden asociar tanto con subredes como con
tarjetas de interfaz de red (NIC).
Cuando crea una red virtual o una NIC, de forma predeterminada no hay un NSG
asociado con los recursos. Desde la perspectiva de la NIC, esto significa que se permitiría
cualquier tráfico entrante y saliente desde la máquina virtual a la que está conectado. Esto
también es cierto en el nivel de subred, por lo que la comunicación de subred a subred está
abierta de forma predeterminada en una red virtual.
Un NSG por sí solo es un recurso independiente de las NIC, las redes virtuales y las
subredes. Un NSG se puede asociar con varias NIC o subredes. Sin embargo, cada NIC o
subred se puede asociar con un solo NSG. También puede crear un NSG que no esté
asociado con ninguno de los recursos para su uso posterior.
Para crear un NSG, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Grupos de seguridad de red .
3. En la página Grupos de seguridad de red, haga clic en Crear .
4. En el menú desplegable Suscripción, seleccione la suscripción en la que
colocar el NSG.
agrupar el NSG. Por ejemplo, seleccione Redes .
6. En el campo Nombre, proporcione un nombre para el NSG. Por ejemplo,
ingrese nsg-eus-app1 .
7. En el menú desplegable Región, seleccione una región de Azure para
implementar el firewall. Esta debe ser la misma que la red virtual. Por ejemplo,
seleccione Este de EE. UU .
8. Haz clic en Revisar y crear . La Figura 4-11 muestra la configuración
completa.
FIGURA 4-11 Crear grupo de seguridad de red

Asociar un NSG a un recurso
Los NSG se pueden asociar con tarjetas de interfaz de red o subredes en una red
virtual. Puede configurar esta asociación desde el NSG o desde el recurso al que la está
vinculando.
Para vincular un NSG a un recurso del NSG, siga estos pasos:

3. En la página Grupos de seguridad de la red, seleccione el NSG que creó
anteriormente, nsg-eus-app1 .
4. En la página NSG, seleccione la hoja deseada para el tipo de recurso con el
que planea asociarse, ya sea interfaces de red o subredes. Para este ejemplo,
seleccione la hoja de interfaces red .
5. En la página de interfaces de red, haga clic en Asociar .
6. En el campo Asociaciones de interfaz de red, seleccione la NIC deseada. Por
ejemplo, seleccione nic-eus-vm1 .
FIGURA 4-12 Interfaz de red asociada
También puede configurar la asociación desde el recurso. Para asociar el NSG con una
subred de la red virtual, siga estos pasos:

3. En la lista de redes, seleccione una red virtual existente. Por ejemplo,
seleccione hub-vnet-eus-01 .
4. Desde la red virtual, seleccione la hoja Subredes .
5. En la lista de subredes, seleccione una subred que se haya creado
previamente. Por ejemplo, seleccione app1 .
6. En la página de la subred app1, en el menú desplegable del grupo de
seguridad de la red, seleccione el NSG deseado. Por ejemplo, seleccione nsg-eus-
app1 .
FIGURA 4-13 Asociación de NSG de subred
Crear un grupo de seguridad de aplicaciones (ASG)
Los grupos de seguridad de aplicaciones (ASG) le permiten agrupar NIC para usarlos con
reglas de NSG. Por ejemplo, puede tener 20 servidores web para los que necesita permitir
el puerto 443, pero luego denegar cualquier otro tráfico en otros números de puerto. Tiene
algunas opciones con cantidades variables de gastos generales administrativos:
 Cree una regla para toda la subred. Esto podría ser lo más fácil desde una
perspectiva administrativa, pero requeriría que la subred solo se use para los
servidores web. De lo contrario, el puerto 443 estaría abierto para cualquier otra
máquina virtual que coloque en la misma subred.
 Cree reglas para cada máquina virtual. Este sería el mayor dolor de
cabeza desde una perspectiva administrativa. No solo tendría que crear 20 reglas,
sino que cualquier cambio de dirección IP o la adición de máquinas virtuales
requeriría cambios de reglas. Funcionaría, pero no es recomendable.
 Cree un ASG para las NIC de VM. De manera similar al uso de grupos
para administrar los permisos de usuario, puede crear un ASG que represente las
NIC individuales de las máquinas virtuales web como un grupo. Luego crea una
regla que hace referencia al ASG. Independientemente de las direcciones IP que se
asignen a las NIC, se permitiría el tráfico. Cualquier máquina virtual nueva solo
debe agregarse al ASG.
Los ASG son similares a los otros recursos que se han discutido. El ASG se crea como
un caparazón de un objeto y luego se asocia con otro recurso, en este caso, las NIC.
Para crear un grupo de seguridad de aplicaciones, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Grupos de seguridad de
aplicaciones .
3. En la página Grupos de seguridad de aplicaciones, haga clic en Crear .
4. En el menú desplegable Suscripción, seleccione la suscripción en la que
colocar el NSG.
agrupar el NSG. Por ejemplo, seleccione Redes .
6. En el campo Nombre, proporcione un nombre para el NSG. Por ejemplo,
ingrese asg-eus-web1 .
7. Haz clic en Revisar y crear . La Figura 4-14 muestra la configuración
completa.
FIGURA 4-14 Crear un grupo de seguridad de aplicaciones

Asociar un ASG a una NIC
Después de crear el ASG, debe asociar las NIC que desea agrupar. Los ASG son
altamente escalables y permiten hasta 4000 configuraciones de IP por ASG. Luego puede
tener hasta 3000 ASG en una suscripción. Para asociar una NIC con un ASG, la NIC ya
debe estar asociada con una máquina virtual (VM). Todos los recursos (VM, NIC y ASG)
deben estar en la misma región de Azure.
Para asociar una NIC con un ASG existente, siga estos pasos:

3. En la lista de máquinas virtuales, seleccione la máquina virtual que tiene
configurada la NIC que desea asociar con un ASG.
4. En la página de la máquina virtual, seleccione la hoja Redes .
5. En la hoja Redes, seleccione la pestaña Grupos de seguridad de
aplicaciones .
6. En la pestaña Grupos de seguridad de la aplicación, haga clic en Configurar
los grupos de seguridad de la aplicación . La Figura 4-15 muestra la ubicación de
esta pestaña y botón.
FIGURA 4-15 Hoja de redes de VM
7. En la página Configurar los grupos de seguridad de la aplicación, en el menú

desplegable Grupos de seguridad de la aplicación, seleccione el ASG que creó
anteriormente. Por ejemplo, seleccione asg-eus-web1 .
FIGURA 4-16 Configurar el ASG
Crear y configurar reglas de NSG
Las reglas de NSG son lo que le gustaría filtrar los paquetes entrantes o salientes. Tanto las
reglas de entrada como las de salida se procesan de la misma manera, dependiendo de si ese
paquete específico ingresa o sale de la subred o NIC.
Cada regla que configure tiene varias propiedades:
 Fuente. Esta es la fuente que aparece en el encabezado del paquete. Las

fuentes pueden ser una de cuatro opciones:
 Ningún
 Direcciones IP
 Etiqueta de servicio
 grupo de seguridad de aplicaciones
 Intervalos de puertos de origen. El puerto de origen que
aparece en el encabezado del paquete.
 Destino. El destino al que el paquete intenta llegar. Esta
también puede ser una de cuatro opciones:
 Ningún
 Direcciones IP
 Etiqueta de servicio
 grupo de seguridad de aplicaciones
 Servicio. Le permite especificar un número de puerto de
destino seleccionando el nombre del servicio en lugar de memorizar
el número de puerto. Por ejemplo, seleccionar RDP automáticamente
llena y bloquea el campo de rango de puertos de destino con 3389.
La opción predeterminada es Personalizada .
 Intervalos de puertos de destino. Los puertos de destino a
los que el paquete intenta llegar.
 Protocolo. El protocolo que utiliza el paquete para
comunicarse, que tiene cuatro opciones disponibles:
 Ningún
 TCP
 UDP
 ICMP
 Acción. La acción a realizar si un paquete coincide con la
configuración, ya sea Permitir o Denegar .
 Prioridad. Un número entero entre 100 y 4096 que
especifica el orden en el que se debe procesar la regla. Las reglas con
un número entero más bajo, 100 por ejemplo, se procesan primero.
 Nombre. El nombre para mostrar de la regla en el NSG.
 Descripción. La descripción es el único campo opcional en la
configuración y se puede utilizar para notas administrativas.
A medida que crece una red virtual, también lo hace la cantidad de reglas en un NSG. El
diseño de las reglas, en particular la Prioridad que se asigna a cada regla, se vuelve
crítico. Un NSG procesa las reglas desde el número entero más bajo (100) hasta el número
entero más alto (4096). Tan pronto como un paquete coincide con una regla, esa regla se
procesa independientemente de si es una regla Permitir o Denegar . La tabla 4-1 muestra
un conjunto simple de reglas para un NSG.
TABLA 4-1 Reglas del grupo de seguridad de la red
IP de Puerto de IP de destino Puerto de Prioridad Acción

origen origen destino
Ningún Ningún 192.168.0.0/24 443 500 Negar
Ningún Ningún 192.168.0.4/32 443 600 Permitir
En la Tabla 4-1 , hay dos reglas que están configuradas con propiedades
similares. Independientemente de la fuente, ambas reglas están configuradas para el puerto
de destino 443, señalando un servidor web. Sin embargo, la primera regla, que hace
referencia a toda la subred, 192.168.0.0/24 , es una regla Deny con una prioridad
de 500 . Esto significa que se denegará cualquier tráfico destinado a esta subred en el
puerto 443 y no se revisarán ni procesarán las reglas futuras con una prioridad más baja
(entero más alto). Esto hace que la segunda regla de la tabla sea inútil porque tiene la
prioridad más baja ( 600). Si necesita permitir 443 a 192.168.0.4 específicamente y denegar
el acceso a todos los demás recursos en la subred, entonces las prioridades de la regla
deberán intercambiarse.
Para crear una regla de NSG que permita el tráfico HTTPS a un ASG que contiene las
máquinas virtuales web, siga estos pasos:

3. En la página Grupos de seguridad de la red, seleccione el NSG creado
anteriormente.
4. En el NSG, haga clic en la hoja Reglas de seguridad de entrada.
5. En la hoja Reglas de seguridad de entrada, haga clic en Agregar .
6. Utilice la siguiente información para completar la regla NSG:
1. Fuente: Cualquiera
2. Intervalos de puertos de origen: *
3. Destino: grupo de seguridad de la aplicación
4. Destino ASG: asg-eus-web1
5. Servicio: HTTPS
6. Acción: Permitir
7. Prioridad: 300
8. Nombre: web1-HTTPS
FIGURA 4-17 Agregar regla de seguridad de entrada
Interpretar y validar registros de flujo de NSG
Los registros de flujo de NSG son una herramienta de monitoreo integrada en los NSG para
ayudar a monitorear el tráfico de red para la validación, el cumplimiento y la detección de
intrusiones. Con los registros de flujo de NSG, captura el tráfico de red y almacena los
registros en una cuenta de almacenamiento de Azure. Al usar una cuenta de
almacenamiento de uso general v2, también puede mantener la retención y eliminar
automáticamente los registros hasta un año después de su creación.
Los registros de flujo capturan el tráfico de red en la capa 4 para el tráfico entrante y
saliente. La información capturada incluye tráfico permitido y denegado, así como
información de rendimiento en bytes y paquetes por flujo. La información guardada por los
registros de flujo incluye, pero no se limita a:
 marca de tiempo
 Dirección IP de origen y destino
 Número de puerto de origen y destino
 Protocolo
 Dirección del tráfico
 Decisión del GSN
 Estado de flujo
 Paquetes
 bytes
Los registros de flujo guardan esta información en formato JSON en la cuenta de

almacenamiento que especifique. Para crear un registro de flujo de NSG, siga estos pasos:

3. En la página Grupos de seguridad de la red, seleccione el NSG creado
anteriormente.
4. En el NSG, haga clic en la hoja de registros de flujo del NSG .
5. En la hoja de registros de flujo de NSG, haga clic en Crear .
6. En el menú desplegable Suscripción, seleccione la suscripción para colocar
el registro de flujo.
7. En el campo Nombre del registro de flujo, proporcione un nombre para el
registro de flujo. Por ejemplo, ingrese flow-nsg-app1 .
8. Deje los campos restantes con sus valores predeterminados y haga clic
en Revisar y crear . La Figura 4-18 muestra la configuración completa.
FIGURA 4-18 Crear un registro de flujo
Después de completar estos pasos, deberá asegurarse de generar tráfico en los recursos a
los que el NSG permite o bloquea el tráfico. Esto podría ser tan simple como acceder a un
sitio web de muestra en una VM en la red virtual.
Después de generar tráfico, el registro de flujo de NSG aparecerá en la cuenta de

almacenamiento que usó durante la configuración. La cuenta de almacenamiento tendrá un
contenedor de blobs denominado insights-log-networksecuritygroupflowevent y luego un
árbol de subcontenedores que hacen referencia a la suscripción, el proveedor de recursos, el
NSG, la fecha y la dirección MAC. La siguiente ubicación es la ruta completa de la muestra
en la cuenta de almacenamiento.
Ubicación: insights-logs-
networksecuritygroupflowevent/resourceId=/SUSCRIPCIONES/
7F66A7F2-8827-4019-85AA-167B8E3D219F / GRUPOS DE RECURSOS / REDES /
PROVEEDORES /
MICROSOFT.NETWORK / GRUPOS DE SEGURIDAD DE RED / NSG-EUS-APP1 / y=2021 /
m=11 / d=26 /
h=04 / m=00 / macAddress=002842262CD2
Dentro de esta ubicación hay un archivo PT1H.json que contiene el flujo de tráfico para
la fecha, la hora y la dirección MAC de la solicitud. A continuación se muestra una porción
de muestra del archivo JSON.
{"registros":[{"hora":"2021-11-
26T04:24:06.9762336Z","systemId":"c55b1f21-c587-4ed3-baf5-
ed8ddf971399","macAddress":"002248266FC9","category":"NetworkSecurityGrou
pFlowEvent",
"resourceId":"/SUSCRIPCIONES/7F66A7F2-8827-4019-85AA-167B8E3D219F /GRUPOS
DE RECURSO/
REDES/PROVEEDORES/MICROSOFT.NETWORK/NETWORKSECURITYGROUPS/NSG-EUS-APP1",
"operationName":"NetworkSecurityGroupFlowEvents","properties":{"Versión":
2,
"flujos":[{"regla":"DefaultRule_AllowInternetOutBound","flujos":[{"mac":"
002842262CD2",
"flowTuples":["1637900636,10.0.2.4,52.239.247.228,41926,443,T,O,A,B,,,,",
"1637900641,10.0.2.4,52.239.247.228,41926,443,T,O,A,E,8,1508,13,12663"]}]
},
Cuando tiene una cantidad de tráfico de producción a través del NSG, abrir y leer los
registros de flujo por su cuenta sería un gran desafío. En su lugar, puede asociar el registro
de flujo con Traffic Analytics como parte de un área de trabajo de Log Analytics para poder
buscar y visualizar los datos que se capturan. Como alternativa, puede capturar estos datos
con otras herramientas de ingesta de registros de terceros, como Splunk.
Verificar el flujo de IP
Una herramienta de solución de problemas útil con los NSG es la herramienta de

verificación de flujo de IP que forma parte de Network Watcher. Network Watcher es una
colección de herramientas de monitoreo y solución de problemas para su red y recursos
virtuales; más de sus herramientas se discuten en la sección de habilidades 4.4 .
La verificación de flujo de IP le permite seleccionar la NIC de una máquina virtual y

luego probar la conexión IP a una dirección IP remota. Esta prueba de conexión puede ser
entrante o saliente, utilizando TCP o UDP y cualquier combinación de puertos que
especifique.
Para probar el flujo de IP a una máquina virtual, siga estos pasos:

3. En Network Watcher, haga clic en la hoja de verificación de flujo de IP .
4. Según la cantidad de máquinas virtuales que tenga, es posible que se
seleccione automáticamente una máquina virtual. De lo contrario, configure los
menús desplegables para seleccionar una máquina virtual y una interfaz de red.
5. Asegúrese de que el campo Protocolo esté configurado en TCP y el campo
Dirección esté configurado en Entrante .
6. El campo Dirección IP local debería haberse llenado automáticamente
cuando seleccionó la NIC. Por ejemplo, podría decir 10.0.2.4 . En el campo Puerto
local, ingrese el número de puerto que permitió en la regla NSG. Por ejemplo,
ingrese 443 .
7. En el campo Dirección IP remota, proporcione una dirección IP pública. Por
ejemplo, ingrese 8.8.8.8 .
8. En el campo Puerto remoto, especifique un puerto remoto aleatorio. Por
ejemplo, ingrese 50000 .
9. Haga clic en Comprobar . Si permitió la entrada 443 desde cualquier
dirección IP de origen (remota), entonces el resultado debería ser "Acceso
permitido" con el nombre del NSG y la regla que permite este acceso. La Figura 4-
19 muestra la configuración exitosa.
FIGURA 4-19 Verificación de flujo de IP
Tenga en cuenta que las reglas de verificación de flujo de IP y NSG solo verifican que la
red virtual y los NSG no estén bloqueando el tráfico. La VM todavía necesitaría cualquier
firewall de software para aceptar conexiones en el número de puerto especificado y
necesitaría que el servicio esté configurado en la VM.
Habilidad 4.3: Implementar una implementación de Firewall de aplicaciones web (WAF)
Las políticas de Web Application Firewall son una combinación de conjuntos de reglas
administradas y reglas personalizadas que puede aplicar en varios dispositivos. Existen
diferentes conjuntos de políticas para Azure Front Door, Application Gateway y Azure
CDN.
Si compara esta sección con el dominio objetivo, existe cierta superposición entre los
servicios de Azure Front Door y Azure Application Gateway que se analizaron en
el Capítulo 3 . Para la configuración de esos servicios, consulte esas secciones. Esta sección
de habilidades se enfoca en crear y asociar una política de firewall de aplicaciones web
(WAF), que incluye si la política está en modo de detección o prevención.

 Implementar una política WAF
 Asociar una política WAF
Implementar una política WAF
Una política WAF puede ayudar a proteger sus recursos de la inyección SQL, las
secuencias de comandos entre sitios y otros ataques maliciosos.
Puede crear una política WAF para los siguientes recursos:
 Puerta principal azul. Este es el servicio global de Front Door que

protegerá los recursos en todas las regiones donde se utilice Front Door.
 Puerta de enlace de aplicaciones de Azure. Este es un servicio regional y
requiere una puerta de enlace de aplicaciones en cada región en la que implemente.
 Azure CDN (versión preliminar). Esto es para una red de entrega de
contenido. En el momento de escribir este artículo, esta función se encuentra en
versión preliminar y no se trata en esta sección de habilidades.
Cada política que crea tiene las siguientes propiedades:
 Modo de política
 Reglas administradas
 Configuración de políticas
 Reglas personalizadas
 Asociaciones
Configurar el modo de detección o prevención
Independientemente del recurso para el que cree la política, el modo de política le permite
establecer la política en modo de detección o prevención . Los nombres son explícitos en lo
que proporcionan. El modo de detección detecta cualquier posible actividad maliciosa, pero
no toma medidas adicionales para bloquear esa actividad. El recurso necesitará registros de
diagnóstico habilitados, donde la actividad se registrará y estará disponible para que usted
pueda generar informes. El modo de prevención bloquea la actividad y la conexión cuando
se detecta.
Conjuntos de reglas de Azure Front Door
Una política de WAF con Azure Front Door proporciona un conjunto preconfigurado de
reglas comunes de las categorías y grupos de reglas del Proyecto de seguridad de
aplicaciones web abiertas (OWASP). Estos grupos de reglas incluyen:
 Ataque de protocolo
 Archivo local incluido (LFI)
 Archivo remoto incluido (RFI)
 Ejecución remota de código (RCE)
 PHP
 Script entre sitios (XSS)
 Inyección SQL
 fijación de sesión
 Protección Java
Para las directivas WAF de Azure Front Door, hay tres conjuntos de reglas
predeterminados que puede configurar:
 DefaultRuleSet_preview-0.1
 DefaultRuleSet_1.0
 Microsoft_DefaultRuleSet_1.1
Además de las reglas predeterminadas proporcionadas por Microsoft y OWASP, puede

crear reglas personalizadas que busquen una coincidencia según las siguientes condiciones:
 Geolocalización
 dirección IP
 Tamaño
 Cuerda
Si el tráfico coincide con lo que configura, entonces puede elegir una acción para
realizar en el tráfico. Las acciones disponibles son:
 Permitir tráfico
 Denegar el tráfico
 Registrar solo tráfico
 Redirigir el tráfico
Conjuntos de reglas de Azure Application Gateway
Las políticas de WAF para las puertas de enlace de aplicaciones son similares a las de
Front Door, pero tienen diferentes conjuntos de reglas administradas y opciones de
configuración ligeramente diferentes para las reglas personalizadas. Los conjuntos de reglas
administradas disponibles para una puerta de enlace de aplicaciones son:
 Microsoft_BotManagerRuleSet_0.1
 OWASP_2.2.9
 OWASP_3.0
 OWASP_3.1
 OWASP_3.2
Puede seleccionar uno o más de estos conjuntos de reglas para que se incluyan en la
política de WAF para las puertas de enlace de aplicaciones. Si necesita crear reglas
personalizadas para una puerta de enlace de aplicaciones, las opciones son ligeramente
diferentes:
 dirección IP
 Número
 Cuerda
 Geolocalización
La acción que se debe realizar cuando el tráfico coincide con una condición también es
ligeramente diferente para una puerta de enlace de aplicaciones, ya que no existe la opción
de redireccionamiento. Las acciones disponibles son:
 Permitir tráfico
 Denegar el tráfico
 Registrar solo tráfico
Para crear una política de WAF para una puerta de Azure Front, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Políticas de firewall de
aplicaciones web .
3. En la página de políticas de WAF, haga clic en Crear .
4. En la pestaña Conceptos básicos, en el menú desplegable Política para,
seleccione Global WAF (Puerta principal).
5. En el menú desplegable SKU de puerta frontal, seleccione el SKU apropiado
para el tipo de recurso de puerta frontal que ha implementado. Para este ejemplo,
deje el valor predeterminado, Front Door .
6. En el campo Nombre de la política, proporcione un nombre para la
política. Por ejemplo, ingresa wafapp1 .
7. Para los campos Estado de política y Modo de política, deje los valores
predeterminados de Habilitado y Detección .
8. Haga clic en Siguiente: Reglas administradas . La Figura 4-20 muestra la
FIGURA 4-20 Conceptos básicos de la política WAF
9. En la pestaña Reglas administradas, en el campo Conjunto de reglas

predeterminado, seleccione Microsoft_DefaultRuleSet_1.1 .
10. Haz clic en Revisar y crear . La Figura 4-21 muestra la parte relevante de la
pestaña Reglas administradas.
FIGURA 4-21 Reglas administradas de política WAF
Como demuestra el tutorial, Azure Portal le permitirá crear una política WAF sin
asociarla a un recurso. Este es un comportamiento similar al de los NSG, NIC y otros
recursos demostrados. La asociación de la directiva WAF con el recurso, en este caso Front
Door, se trata en la siguiente sección.
Asociar una política WAF
Para que las reglas que configure en la política se apliquen al recurso, debe asociar la
política con el recurso. Puede reutilizar una política en varios recursos si desea que se
aplique el mismo conjunto de reglas. Esto puede ser especialmente útil cuando usa puertas
de enlace de aplicaciones y tiene varias regiones implementadas. En lugar de administrar
cada puerta de enlace de aplicaciones individualmente, puede crear una política compartida
que se use en todas las regiones.
Para asociar una política WAF existente con un recurso, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Políticas de firewall de
aplicaciones web .
3. En la página de políticas de WAF, seleccione la política creada
anteriormente.
4. En la página de políticas, haga clic en la hoja Asociaciones .
5. En la hoja Asociaciones, haga clic en Agregar host de interfaz .
6. En la página Agregar host front-end, en el menú desplegable Frontdoor,
seleccione Azure Front Door que implementó anteriormente. Por ejemplo,
seleccione contosoapp1 .
7. En el menú desplegable Host de frontend, seleccione el host configurado en
la puerta principal. Por ejemplo, seleccione contosoapp1.azurefd.net .
FIGURA 4-22 Agregar host frontend
Habilidad 4.4: Monitorear redes
Azure tiene varias herramientas integradas que le permiten monitorear y alertar sobre las
métricas, los registros y los flujos de IP que son importantes para su red en general. Esto
podría ser por razones de auditoría, seguridad o cumplimiento con la industria u otra
regulación. Network Watcher es una de las principales herramientas de Azure que
proporciona una variedad de herramientas para monitorear el entorno. Esta sección de
habilidades describe y proporciona tutoriales para algunas de esas herramientas.

 Configure las alertas de estado de la red y el registro mediante Azure
Monitor
 Crear y configurar una instancia de Monitor de conexión
 Configurar y usar análisis de tráfico
 Habilitar y configurar el registro de diagnóstico
 Configurar Azure Network Watcher
Configure las alertas de estado de la red y el registro mediante Azure Monitor
Azure Monitor es el sistema de monitoreo predeterminado e “incluido” con los servicios de

Azure. Compare esto con Azure Log Analytics y Azure Sentinel, que también son servicios
de supervisión de Azure pero que no están necesariamente "incluidos" con los servicios que
implementa. Estos otros servicios requieren configuración adicional y dinero para
configurar y usar. Sin embargo, Azure Monitor como herramienta de supervisión es gratuita
y los costos asociados son una cuenta de almacenamiento para el almacenamiento a largo
plazo y un análisis continuo de métricas para alertas.
El tipo de recurso que está monitoreando determina el tipo de métricas que están
disponibles para mirar. Por ejemplo, las métricas de máquinas virtuales son diferentes de
las métricas de servicios de aplicaciones. Específicamente para las máquinas virtuales, hay
diagnósticos de invitados adicionales que puede habilitar para obtener más información
sobre Azure Monitor.
Para cada métrica, puede crear una alerta basada en las condiciones de la métrica. Las
alertas tienen tres componentes:
 Alcance. El recurso de Azure que desea supervisar y evaluar.

 Condición. Lo que se debe evaluar con la métrica para desencadenar la
acción.
 Acción. La notificación o automatización a realizar cuando se cumple la
condición.
Cuando está configurando la condición, hay opciones para configurar para el operador y
los datos con los que se compara la evaluación. Los operadores integrados son:
 Mas grande que

 Mayor qué o igual a
 Menos que
 Menos que o igual a
Luego, según el tipo de métrica que haya seleccionado, configuraría la condición con
uno de estos tipos de agregación:
 Promedio
 Contar
 Máximo
 Mínimo
 Total
Una métrica común para monitorear máquinas virtuales podría ser si la

métrica Porcentaje de CPU tiene un Promedio mayor al 75 %. Pero, ¿durante cuánto
tiempo podría ser necesario que el promedio sea superior al 75 % para que se active la
alerta? Ahí es donde entran en juego la granularidad de agregación y la frecuencia de
evaluación. Puede establecer la granularidad de 1 minuto a 24 horas, con la frecuencia (o
resolución) de cada minuto a cada hora.
Después de decidir la condición de una alerta, configure las acciones para notificar o
realizar algún tipo de automatización cuando se active la alerta. Hay muchas opciones
integradas para las alertas:
 Notificaciones
 Rol de administrador de recursos de Azure de correo electrónico
 Dirección de correo electrónico
 mensaje de texto
 Notificación de inserción
 Mensaje de voz
 Comportamiento
 Runbook de automatización
 función azul
 Centro de eventos
 conector ITSM
 Aplicación lógica
 Webhook seguro
 Webhook
Para crear una alerta basada en la métrica Porcentaje de CPU para una máquina virtual
que envía un correo electrónico, siga estos pasos:

3. En la lista de máquinas virtuales, seleccione una máquina virtual existente.
4. En la máquina virtual, haga clic en la hoja Alertas .
5. En la hoja Alertas, haga clic en Crear y luego en Regla de alertas .
6. Tenga en cuenta que Scope ya está configurado para la VM porque desde
ahí creamos la regla. En la sección Condiciones, haga clic en Agregar condición .
7. En el campo Seleccionar una señal, busque y seleccione Porcentaje de
CPU .
8. Tenga en cuenta que el valor predeterminado de Operador es Mayor que y
Agregación es Promedio . En el campo Valor de umbral , ingrese 75 .
9. Verifique que la granularidad de Agregación esté configurada en 5
minutos y que la frecuencia de evaluación esté configurada en Cada 1 minuto .
10. Haga clic en Listo . La Figura 4-23 muestra la configuración completa.
FIGURA 4-23 Configurar lógica de señal
11. Después de hacer clic en Listo, volverá a la página Crear regla de alerta. En
la sección Acciones, haga clic en Agregar grupo de acciones .
12. En la página Agregar grupos de acciones, haga clic en Crear grupo de
acciones .
13. En la pestaña Conceptos básicos del grupo de acciones, en el campo Nombre
del grupo de acciones, proporcione un nombre para el grupo. Por ejemplo,
ingrese email-vms . Deje todos los demás campos en sus valores predeterminados.
14. Haga clic en Siguiente: Notificaciones . La Figura 4-24 muestra la pestaña
Conceptos básicos completada.
FIGURA 4-24 Conceptos básicos de creación de grupos de acción
15. En el menú desplegable Tipo de notificación, seleccione Correo

electrónico/Mensaje SMS/Push/Voz .
16. En el menú emergente Correo electrónico/Mensaje SMS/Push/Voz,
seleccione la casilla de verificación junto a Correo electrónico .
17. En el campo Correo electrónico, proporcione una dirección de correo
electrónico. Por ejemplo, ingrese az700examref@outlook.com .
FIGURA 4-25 Configuración de correo electrónico del grupo de acción
19. En el campo Nombre, nombre el administrador del correo electrónico de

notificación .
21. Volverá a la página Crear regla de alerta, donde ahora tiene configurado un
alcance, una condición y una acción. En el campo Nombre de regla de alerta,
proporcione un nombre para la regla de alerta. Por ejemplo, ingrese VM-email-
admin .
22. Haga clic en Crear regla de alerta . La Figura 4-26 muestra la
configuración final.
FIGURA 4-26 Crear regla de alerta
Crear y configurar una instancia de Monitor de conexión
Otra herramienta de Network Watcher es Connection Monitor, que le permite monitorear la

conectividad en un entorno de red híbrida. Connection Monitor envía datos a un área de
trabajo de Log Analytics.
Connection Monitor usa grupos de prueba para definir los recursos externos y de Azure
para monitorear la conectividad. El grupo de prueba tiene una configuración de prueba que
especifica cómo deben poder conectarse estos recursos. Opcionalmente, también puede
habilitar alertas para la conexión utilizando el mismo proceso de alerta descrito en la
sección anterior.
Para crear una instancia de Monitor de conexión, siga estos pasos:

3. Desde Network Watcher, haga clic en la hoja Monitor de conexión . No
utilice la hoja del monitor de conexión (clásico) .
4. En la hoja del monitor de conexión, haga clic en Crear .
5. En la pestaña Conceptos básicos de la página Crear monitor de conexión,
proporcione un nombre para el monitor. Por ejemplo, ingrese App1Monitoring .
6. Deje los campos restantes en su valor predeterminado y haga clic
en Siguiente: Grupos de prueba . La Figura 4-27 muestra la pestaña Conceptos
básicos completada.
FIGURA 4-27 Conceptos básicos del monitor de conexión

7. En el campo Nombre del grupo de prueba, proporcione un nombre para el
grupo. Por ejemplo, ingrese AppGroup1 .
8. En el campo Fuentes, haga clic en Agregar fuentes .
9. En la página Agregar orígenes, seleccione la casilla de verificación junto a la
red virtual que creó anteriormente. Tenga en cuenta que las máquinas virtuales en la
red virtual deben tener agregada la extensión Network Watcher.
10. Haga clic en Agregar puntos finales . La Figura 4-28 muestra la
configuración Agregar fuentes.
FIGURA 4-28 Fuentes adicionales del monitor de conexión
11. Volverá a la página Agregar detalles del grupo de prueba. Haga clic en
Agregar configuración de prueba .
12. En el campo Nombre de configuración de prueba, proporcione un nombre
para la prueba. Por ejemplo, ingresa app1-http-test .
13. Deje los valores restantes en los valores predeterminados y haga clic
en Agregar configuración de prueba .
14. Volverá a la página Agregar detalles del grupo de prueba. Haga clic en
Agregar destinos .
15. En la página Agregar destinos, haga clic en la pestaña Direcciones externas
.
16. En la página Direcciones externas, seleccione la casilla de verificación junto
a una opción de Office 365 y luego haga clic en Agregar puntos finales . La Figura
4-29 muestra la configuración completa.
FIGURA 4-29 Agregar destinos al monitor de conexión
17. Volverá a la página Agregar detalles del grupo de prueba. Revise y confirme
la configuración y luego haga clic en Agregar grupo de prueba . La Figura 4-
30 muestra la configuración final.
FIGURA 4-30 Agregar detalles del grupo de prueba
Configurar y usar análisis de tráfico
Network Watcher también contiene una herramienta denominada Traffic Analytics, que le
permite analizar los registros de flujo de NSG para varias regiones, redes virtuales y
subredes de Azure con una sola herramienta. Esta herramienta ayuda a mantener el
cumplimiento y auditar el tráfico de red del entorno. Para obtener más información sobre
los registros de flujo de NSG, consulte la sección 4.2 de habilidades .
Para configurar Traffic Analytics con un NSG que ya está configurado para registros de
flujo, siga estos pasos:

3. Desde Network Watcher, haga clic en la hoja Traffic Analytics . La Figura
4-31 muestra los datos recopilados por el registro de flujo y visualizados en Traffic
Analytics.
FIGURA 4-31 Análisis de tráfico

Habilitar y configurar el registro de diagnóstico
Hay algunos recursos en Azure de los que puede recopilar información adicional si habilita
el registro de diagnóstico. Esto debe estar habilitado porque debe tener un repositorio
configurado para guardar los datos, lo que significa que hay un costo asociado con habilitar
el registro. Para la configuración de diagnóstico de NSG, los destinos admitidos incluyen:
 Área de trabajo de Log Analytics

 Cuenta de almacenamiento de Azure
 Centro de eventos
 Solución de terceros
Para el registro de NSG, puede habilitar allLogs o seleccionar entre dos

categorías: Network SecurityGroupEvent y NetworkSecurityGroupRuleCounter .
Para configurar los ajustes de diagnóstico para un NSG, siga estos pasos:

3. En la página Grupos de seguridad de la red, seleccione el NSG que creó
anteriormente: nsg-eus-app1 .
4. En el NSG, haga clic en la hoja Configuración de diagnóstico .
5. En la página Configuración de diagnóstico, haga clic en Agregar
configuración de diagnóstico .
6. En el campo Nombre de la configuración de diagnóstico, proporcione un
nombre para la configuración. Por ejemplo, ingrese nsg-app1-alllogs .
7. En la sección Registros, seleccione la casilla de verificación junto a todos
los registros .
8. En la sección Detalles del destino, seleccione la casilla de verificación junto
a Archivar en una cuenta de almacenamiento .
9. En los menús desplegables Suscripción y Cuenta de almacenamiento,
seleccione una cuenta de almacenamiento adecuada.
FIGURA 4-32 Configuración de diagnóstico de NSG
Configurar Azure Network Watcher
Network Watcher es una colección de herramientas que puede usar para solucionar
problemas y monitorear los recursos que ha implementado en sus suscripciones. No hay
mucho que configurar para Network Watcher, ya que cada herramienta funciona de forma
independiente.
Las otras herramientas que no se mencionaron específicamente en la lista de objetivos

para el examen incluyen:
 Topología. Un mapa de red de los recursos que ha implementado en una

suscripción.
 Diagnóstico NSG. Proporciona una forma de probar los NSG en un flujo de
tráfico para determinar qué NSG podría estar permitiendo o bloqueando el tráfico de
forma inesperada.
 Siguiente salto. Verifica la ruta del próximo salto desde una dirección IP
cuando se utilizan rutas definidas por el usuario.
 Reglas de seguridad efectivas. Muestra el resultado final de las reglas de
NSG cuando se pueden configurar varios NSG o se han definido varias reglas de
prioridad.
 Solucionar problemas de VPN. Una herramienta de solución de problemas
para puertas de enlace de red virtual y establecimiento de conexiones VPN.
 Captura de paquetes. Una herramienta de captura de paquetes que guarda
la información de rastreo de paquetes en un archivo .CAP que puede descargar y
analizar sin conexión.
 Azure Firewalls proporciona protección de capa 3 a capa 7 para redes

virtuales de Azure.
 Azure Firewalls se implementa y asocia con una única red virtual de Azure.
 Los firewalls de Azure están configurados con reglas de red, aplicación y
NAT.
 Las reglas de red en Azure Firewalls se basan en la información del
encabezado del paquete, como la dirección IP de origen y destino, el protocolo y el
número de puerto.
 Las reglas de aplicación en Azure Firewalls se basan en etiquetas de servicio
o nombres de dominio completos.
 Las reglas de NAT en Azure Firewall le permiten realizar la traducción de
redes y puertos.
 Los firewalls se pueden combinar con Azure Virtual WAN para crear
centros seguros.
 Los grupos de seguridad de red (NSG) proporcionan filtrado de paquetes en
función de la información del encabezado del paquete.
 Los NSG se pueden asociar tanto con subredes como con tarjetas de interfaz
de red.
 Los grupos de seguridad de aplicaciones actúan como un grupo de interfaces
de red para simplificar las reglas de NSG.
 Las reglas de NSG definen si se debe permitir o denegar un paquete, ya sea
entrante o saliente desde el recurso al que está asociado.
 La prioridad de NSG es crítica en el diseño de reglas con varios niveles de
restricciones.
 Los registros de flujo de NSG capturan el flujo de tráfico y las decisiones
tomadas por un NSG en una cuenta de almacenamiento.
 La herramienta de flujo de IP en Network Watcher lo ayuda a garantizar que
el tráfico de IP pueda comunicarse a través de los NSG.
 Las directivas WAF se pueden usar con Azure Front Door, Azure
Application Gateway y Azure CDN.
 Las políticas de WAF proporcionan conjuntos de reglas administradas y
personalizadas para proteger los recursos.
 Los conjuntos de reglas administrados por WAF se basan en reglas OWASP
predefinidas.
 Azure Monitor muestra métricas de los recursos que ha implementado.
 Las métricas capturadas con Azure Monitor se pueden usar para crear una
regla de alerta.
 Las reglas de alerta tienen ámbitos, condiciones y grupos de acciones.
 Las condiciones de alerta miden la métrica que se está monitoreando para
que se active.
 Los grupos de acciones son las notificaciones o acciones realizadas cuando
se activa una alerta.
 Connection Monitor usa una configuración de prueba para monitorear la
conectividad entre los recursos.
 Traffic Analytics se usa en combinación con los registros de flujo de NSG
para visualizar y resumir los datos que se han recopilado.
 Los registros de diagnóstico del NSG capturan información adicional sobre
el NSG y se almacenan en Log Analytics, Azure Storage Accounts, Event Hub o
proveedores de terceros.
 Network Watcher es una colección de herramientas de solución de
problemas y supervisión de redes que se pueden usar en su entorno de Azure.
Experimento mental

Contoso tiene una aplicación de tres niveles que consta de un nivel web, un nivel de API
y un nivel de base de datos. Contoso también tiene una red virtual con una subred dedicada
para cada nivel de la aplicación. La red virtual también tiene subredes para administración
y una puerta de enlace de red virtual. La puerta de enlace es una VPN de sitio a sitio para su
centro de datos local. Todos estos recursos están actualmente implementados en una región
de Azure. La organización planea implementar en una segunda región en un futuro cercano
y necesita poder replicar el entorno actual con la menor cantidad de gastos generales
administrativos.
El nivel web de la aplicación acepta solicitudes HTTPS y se ejecuta en un conjunto de

escalado de máquinas virtuales. El nivel de API acepta conexiones del nivel web y luego se
comunica con la base de datos. La organización debe asegurarse de que el tráfico de la
subred esté restringido solo a lo que requiere la aplicación y que se deniegue cualquier otra
combinación. La red de administración debe ser la única red que pueda comunicarse con las
demás subredes. El tráfico saliente debe tener una inspección de paquetes con estado al
salir de la red.
La organización tiene un requisito de cumplimiento para poder identificar las

conexiones y el filtrado que se produce en el nivel web. Los datos que se capturan deben
poder conservarse durante un año.
Con la información anterior, responda estas preguntas para Contoso:

1. 1 . ¿Qué servicio se debe implementar para proteger el tráfico saliente de las
máquinas virtuales?
2. 2 . ¿Qué servicio se debe implementar para proteger el tráfico HTTPS entrante y
cómo se debe configurar?
3. 3 . ¿Qué se debe usar para restringir el tráfico de cada subred y cómo se debe
configurar?
4. 4 . ¿Qué se debe usar para cumplir con el requisito de cumplimiento?
5. 5 . ¿Qué se debe usar para minimizar la sobrecarga de implementación en la
segunda región de Azure?
1. 1 . ¿Qué servicio se debe implementar para proteger el tráfico saliente de las

máquinas virtuales?
Se debe implementar un Azure Firewall con la red virtual. Cuando asocia un

firewall con una red virtual, todo el tráfico saliente de la red se atravesará a través
del firewall.
2. 2 . ¿Qué servicio se debe implementar para proteger el tráfico HTTPS entrante y

cómo se debe configurar?
El tráfico HTTPS entrante debe tener una puerta de enlace de aplicaciones con
reglas OWASP habilitadas.
3. 3 . ¿Qué se debe usar para restringir el tráfico de cada subred y cómo se debe
configurar?
El filtrado del tráfico de red a nivel de subred lo realizan los grupos de seguridad de
red. Los grupos de seguridad de red deben tener al menos dos reglas de entrada para
cada subred: una de entrada para la conexión adecuada y otra para la subred de
administración. Por ejemplo, el nivel de API solo debe permitir conexiones desde el
nivel web. El nivel de la base de datos solo debe aceptar conexiones del nivel de la
API.
4. 4 . ¿Qué se debe usar para cumplir con el requisito de cumplimiento?
El requisito de cumplimiento de monitorear el tráfico web y retener datos durante

un año se puede lograr mediante el uso de registros de flujo de NSG. Los registros
de flujo se pueden almacenar en cuentas de almacenamiento de Azure con políticas
de retención configuradas.
5. 5 . ¿Qué se debe usar para minimizar la sobrecarga de implementación en la
segunda región de Azure?
Debe usar una política WAF para configurar los conjuntos de reglas de Application
Gateway. Esto minimizará la sobrecarga administrativa de implementar una puerta
de enlace de aplicaciones en la segunda región.
Capítulo 5
Diseñar e implementar el acceso privado a los servicios de Azure
La mayoría de los servicios en Azure son puntos finales públicos y accesibles públicamente
de forma predeterminada. Para algunos requisitos de seguridad o problemas de eficiencia
de enrutamiento, eso no siempre es necesariamente lo que una organización quiere para sus
servicios. Por ejemplo, la mayoría de las organizaciones no desean que las bases de datos
de Azure SQL sean accesibles a través de Internet.
Este capítulo presenta Private Link, que le permite publicar sus propias aplicaciones y
hacerlas accesibles de forma privada. Luego, los puntos de conexión privados se pueden
usar para consumir esos servicios, así como los servicios de Azure.
Los puntos finales de servicio presentan cómo optimizar cualquier posible ineficiencia
de enrutamiento que puedan presentar las VPN de sitio a sitio o ExpressRoute. Las
etiquetas de servicio se pueden usar con grupos de seguridad de red y Azure Firewall para
filtrar servicios específicos de Azure.
Finalmente, analizamos la integración de servicios de plataforma como servicio (PaaS)

con redes virtuales para servicios de aplicaciones, Kubernetes y entornos de servicios de
aplicaciones.
 Habilidad 5.1: Diseñar e implementar el servicio Azure Private Link y

puntos de conexión privados
 Habilidad 5.2: Diseñar e implementar puntos finales de servicio
 Habilidad 5.3: Configurar la integración de VNet para servicios de
plataforma como servicio (PaaS) dedicados
Habilidad 5.1: Diseñar e implementar el servicio Azure Private Link y puntos de conexión
privados
Azure Private Link es el nombre más amplio de dos componentes: servicios de Private Link
y puntos de conexión privados. Puede ser fácil confundir los dos servicios, pero son los dos
componentes de un servicio de Consumidor y Proveedor. Los puntos de conexión privados
son del lado del consumidor, que se conecta a los servicios de Azure o las aplicaciones
publicadas. Los servicios o aplicaciones de Azure que publica son del lado del proveedor,
mediante un servicio de Azure Private Link.
El uso de Private Link garantiza que todas las comunicaciones del cliente final se
conecten al servicio mediante direcciones IP privadas a través de una red virtual. Luego,
esto se puede integrar con DNS y combinar con redes virtuales o ExpressRoute.

 Crear un servicio de enlace privado
 Planificar y crear puntos finales privados
 Integrar enlace privado con DNS
 Integrar un servicio de Private Link con clientes locales
Crear un servicio de enlace privado
Los servicios de Azure Private Link permiten el acceso privado a su aplicación mediante el
uso de conectividad privada a través de la red de Microsoft. Para usar los servicios de
Private Link, su aplicación debe ejecutarse detrás de una SKU estándar de Azure Load
Balancer. El servicio Private Link utiliza un flujo de trabajo de proveedor de servicios y
consumidor de servicios.
Cuando crea un servicio de Private Link, Azure asignará un nombre único global,
llamado alias, para su servicio. Puede compartir el alias o el URI de recurso de su
aplicación con sus clientes para que se conecten de forma privada. Cuando un cliente
intenta conectarse a la aplicación por primera vez, el proveedor de servicios puede aceptar
o rechazar la solicitud.
Los pasos generales para completar ambos lados del servicio Private Link incluyen:
1. Cree y configure su aplicación con una SKU estándar de Azure Load

Balancer.
2. Cree el servicio Private Link y asócielo con la dirección IP de interfaz del
balanceador de carga.
3. Comparte el alias generado del servicio Private Link con tus clientes.
4. A medida que los clientes configuran sus puntos finales privados, acepte o
rechace las solicitudes de conexión.
Como proveedor, el servicio Private Link, el equilibrador de carga y la red virtual deben
estar todos en la misma región de Azure. Sin embargo, los consumidores del servicio
pueden acceder al servicio desde cualquier región de Azure mediante la red de Microsoft.
Para crear un servicio de Private Link, siga estos pasos:

2. En la barra de búsqueda, busca y selecciona Private Link .
3. En el centro de Private Link, haga clic en la hoja Servicios de Private Link
.
4. En la hoja Servicios de Private Link, haga clic en Agregar .
5. Seleccione la suscripción y el grupo de recursos deseados para implementar
el servicio.
6. En el campo Nombre, proporcione un nombre para el servicio. Por ejemplo,
ingrese pls-eus-app1 .
debe ser la misma región que el balanceador de carga y la red virtual con la que
planea asociar el servicio. Por ejemplo, seleccione Este de EE. UU .
8. Haga clic en Siguiente: Configuración de salida . La Figura 5-1 muestra la
FIGURA 5-1 Conceptos básicos del servicio Private Link
9. En el menú desplegable Equilibrador de carga, seleccione el equilibrador de

carga que se usa con su aplicación. Por ejemplo, seleccione lb-eus-app1 .
10. En el menú desplegable Dirección IP del frontend del equilibrador de carga,
seleccione la dirección IP del frontend que se usa con su aplicación. Por ejemplo,
seleccione pip-lb-app1 .
11. En el menú desplegable Subred NAT de origen, seleccione la subred donde
reside su aplicación. Por ejemplo, seleccione hub-vnet-eus-01/app1 .
12. Deje los campos restantes configurados con sus valores predeterminados y
haga clic en Siguiente: Seguridad de acceso . La Figura 5-2 muestra la pestaña
Configuración de salida completada.
FIGURA 5-2 Configuración de salida del servicio Private Link
13. En el campo Quién puede solicitar acceso a su servicio, seleccione el nivel

de seguridad de acceso deseado. Por ejemplo, seleccione Cualquiera con su alias .
14. Haga clic en Siguiente: Etiquetas. La Figura 5-3 muestra la pestaña
Seguridad de acceso.
FIGURA 5-3 Seguridad de acceso al servicio Private Link
Tenga en cuenta que en la pantalla de seguridad de acceso tiene tres opciones para
elegir:
 Solo control de acceso basado en roles

 Restringido por suscripción
 Cualquiera con tu alias
La opción predeterminada y más restrictiva es Solo control de acceso basado en

roles . Esto requiere que cualquier persona que se conecte al servicio ya tenga un permiso
definido a través de RBAC para conectarse a su servicio. Seleccionar Restringido por
suscripción o Cualquiera con su alias permite que otros soliciten acceso a su servicio, pero
no los aprueba automáticamente de forma predeterminada. Puede configurar suscripciones
específicas para aprobar solicitudes automáticamente.
Planificar y crear puntos finales privados
Los puntos de conexión privados son el lado del consumidor del escenario de Private Link
y admiten conexiones de clientes desde una subred a varios servicios de Azure o un
servicio que se ha publicado a través de los servicios de Private Link.
Por ejemplo, puede configurar puntos de conexión privados en una subred que contiene
máquinas virtuales que necesitan acceso a una cuenta de almacenamiento de Azure. De
forma predeterminada, se accede a las cuentas de almacenamiento mediante direcciones IP
públicas. Con puntos finales privados, puede configurar la cuenta de almacenamiento para
que sea accesible mediante una dirección IP privada en la misma red virtual que sus
máquinas virtuales. Esto garantiza la conectividad privada de las máquinas virtuales al
servicio que configure mediante el uso de direcciones IP privadas no enrutables. Esta puede
ser una configuración requerida en muchos entornos de cumplimiento o de alta seguridad.
Para crear un punto final privado para un servicio PaaS, como una cuenta de
almacenamiento, siga estos pasos:

2. En la barra de búsqueda, busca y selecciona Private Link .
3. En el centro de Private Link, haga clic en la hoja Puntos finales privados .
4. En la hoja Puntos finales privados, haga clic en Agregar .
el servicio.
6. En el campo Nombre, proporcione un nombre para el servicio. Por ejemplo,
ingrese ple-eus-storage .
8. Haga clic en Siguiente: Recurso. La Figura 5-4 muestra la pestaña
Conceptos básicos completada.
FIGURA 5-4 Conceptos básicos de punto final privado
9. En el campo Método de conexión, asegúrese de que esté seleccionado el

valor predeterminado Conectarse a un recurso de Azure en mi directorio .
10. En el menú desplegable Suscripción, asegúrese de que su suscripción esté
seleccionada.
11. En el menú desplegable Tipo de recurso, seleccione un recurso de Azure al
que conectarse. Por ejemplo, seleccione Microsoft.Storage/storageAccounts .
12. En el menú desplegable Recurso, seleccione el recurso de Azure
implementado en su suscripción. Por ejemplo, seleccione la cuenta de
almacenamiento denominada az700app1 .
13. En el menú desplegable de subrecursos de destino, seleccione el tipo de
almacenamiento utilizado para su aplicación. Por ejemplo, seleccione blob .
14. Haga clic en Siguiente: Configuración . La Figura 5-5 muestra la pestaña
Recurso completada.
FIGURA 5-5 Recurso de punto final privado
15. En el menú desplegable Red virtual, seleccione la red virtual donde se

conectará a los recursos. Por ejemplo, seleccione hub-vnet-eus-01 .
16. En el menú desplegable Subred, seleccione la subred que tiene el rango de
direcciones en el que desea que se asigne la dirección al recurso. Por ejemplo,
seleccione hub-vnet-eus-01/app1 .
17. En la sección Integración de DNS privado, deje la configuración
predeterminada y haga clic en Siguiente: Etiquetas . La Figura 5-6 muestra la
pestaña Configuración completa.
FIGURA 5-6 Configuración de punto final privado
19. Una vez completada la implementación, haga clic en Ir al recurso .
20. En la pestaña Descripción general del nuevo recurso, localice y haga clic en
el nombre en el campo Interfaz de red. El nombre de la NIC comenzará con el
nombre del extremo. Por ejemplo, haga clic en ple-eus-storage.nic.bab72045-
96c3-43ec-b2ea-faaeff062c5a . La Figura 5-7 muestra la parte relevante de la hoja
Descripción general.
FIGURA 5-7 Descripción general del punto final privado
21. En la hoja Descripción general de la interfaz de red, localice el campo

Dirección IP privada. Esta es la dirección IP que se asigna a la NIC asociada con el
extremo privado y cómo puede conectarse a la cuenta de almacenamiento desde la
misma red virtual. La Figura 5-8 muestra la parte relevante de la hoja de descripción
general de la NIC.
FIGURA 5-8 Descripción general de la NIC
Al completar estos pasos, agregó un punto de conexión privado para una cuenta de
almacenamiento denominada az700app1 y asociada con la subred app1 de la red virtual. El
rango de direcciones de la subred app1 es 10.0.2.0/24, y al punto final privado se le asigna
una dirección de este rango: 10.0.2.6.
Con la seguridad predeterminada en una red virtual, cualquier recurso en cualquiera de
las subredes de la red virtual hub-vnet-eus-01 podría comunicarse con la cuenta de
almacenamiento mediante la dirección IP privada del extremo.
Integrar enlace privado con DNS
Un componente crítico de Private Link es el DNS. Usando el ejemplo de la sección

anterior, cuando crea un punto final y lo asocia con una subred, ese punto final tiene una
NIC con una dirección IP privada. La razón por la que esto es fundamental es la forma en
que los servicios PaaS de Azure funcionan de forma predeterminada: con direcciones IP
públicas. Usando la misma cuenta de almacenamiento que en la sección anterior, este es el
resultado al intentar acceder al almacenamiento de blobs de la cuenta. Para esta prueba,
haremos ping al servicio de blob:
ping az700app1.blob.core.windows.net
Hacer ping a blob.blz22prdstr06a.store.core.windows.net [52.239.169.132]

con 32 bytes de
datos:
Los resultados del ping no son lo relevante. Lo que revela el comando ping es que el
nombre DNS que se probó, az700app1.blob.core.windows.net , se traduce a otro
nombre, blob.blz22prdstr06a.store.core.windows.net , que luego se resuelve en una
dirección IP pública: 52.239.169.132 .
Si el extremo privado se configuró y tiene la dirección IP 10.0.2.6, ¿por qué no se

devuelve la dirección IP privada? Cuando crea un punto final privado, la configuración
predeterminada también crea una zona DNS privada. Para el ejemplo de la cuenta de
almacenamiento, la zona DNS se llama privatelink.blob.core.windows.net y la zona tiene
un registro A que se resuelve en la dirección IP privada de la NIC. Esta zona de DNS
privado se asocia con la red virtual que configuró.
Cada vez que intenta resolver el DNS del almacenamiento de blobs fuera de la red
virtual, aún se resuelve en la dirección IP pública. Solo cuando resuelva el nombre desde
dentro de la red virtual, debido a la zona DNS privada asociada, se devolverá la dirección
IP privada. Si ejecutamos la misma prueba de ping desde la máquina vm-web01 que está en
la red virtual, estos son los resultados:
ping az700app1.blob.core.windows.net

Haciendo ping az700app1.privatelink.blob.core.windows.net [10.0.2.6] con
32 bytes de datos:
Tenga en cuenta que el nombre traducido no solo es diferente para representar el vínculo
privado, sino que devuelve la dirección IP privada asignada a la cuenta de almacenamiento:
10.0.2.6.
Integrar un servicio de Private Link con clientes locales
Según la información presentada en la última sección, la dirección IP privada que se asigna

a un servicio con un punto de conexión de Private Link solo se devuelve si la solicitud de
DNS se produce dentro de la red virtual. Por lo tanto, la única manera de integrarse con
clientes locales, o incluso con clientesque están en otras suscripciones, es con un reenviador
DNS en el entorno adicional y un servidor DNS en la red virtual.
CONSEJO DE EXAMEN
Tenga en cuenta los escenarios que combinan temas que podrían cubrirse en el examen. Por
ejemplo, los clientes locales con Private Link podrían combinarse con ciertos requisitos de
enrutamiento o VPN de sitio a sitio.
El servidor DNS de la red virtual debe aceptar las solicitudes de DNS reenviadas y
luego usar el servidor DNS de Azure, 168.63.129.16, como su servidor DNS. En cualquier
ubicación que necesite usar la dirección IP privada, como en las instalaciones, se debe
configurar un servidor DNS como reenviador condicional para los nombres DNS de los
servicios que usará en Azure. Por ejemplo, el reenviador local debe configurarse para el
FQDN blob.core.windows.net .
El flujo de red de una solicitud local seguiría estos pasos:
1. Un cliente local realiza una solicitud al servidor DNS local para

az700app1.blob.core.windows.net.
2. El servidor DNS local, configurado con un reenviador condicional para
blob.core.windows.net, reenvía la solicitud a un servidor DNS en la red virtual.
3. El servidor DNS de la red virtual está configurado con Azure DNS,
168.63.129.16, y reenvía la solicitud.
4. Azure DNS responde con la dirección privada configurada con el punto de
conexión privado, 10.0.2.6.
5. El cliente se conecta directamente al recurso de Azure mediante la dirección
IP privada. La Figura 5-9 describe estos cinco pasos para resolver el DNS desde las
instalaciones.
FIGURA 5-9 Configuración de DNS local
¿NECESITA MÁS
REVISIÓN? CONFIGURACIÓN DE DNS
DE PUNTO DE CONEXIÓN PRIVADO
DE AZURE
Para obtener más información sobre los servicios de Azure y las configuraciones de la
zona DNS, visite https://docs.microsoft.com/en-us/azure/private-link/private-
endpoint-dns .
Habilidad 5.2: Diseñar e implementar puntos finales de servicio
Los puntos de conexión de servicio le permiten optimizar el enrutamiento a los servicios de

Azure, especialmente en el caso de que haya configurado rutas definidas por el usuario que
puedan afectar la forma en que una máquina virtual accede a un servicio. Los puntos finales
de servicio están asociados con subredes dentro de una red virtual para brindarle un control
granular sobre las posibilidades de enrutamiento. Los puntos finales de servicio también
pueden tener políticas para restringir recursos específicos aún más y se pueden usar en
combinación con grupos de seguridad de red, Azure Firewall y etiquetas de servicio para
proporcionar un nivel de control de acceso de grano fino.

 Crear puntos finales de servicio
 Configurar políticas de punto final de servicio
 Configurar etiquetas de servicio
Crear puntos finales de servicio
Los puntos de conexión de servicio, que no deben confundirse con los puntos de conexión
privados, se usan para optimizar el enrutamiento entre su red virtual y los servicios PaaS de
Azure, como almacenamiento, bases de datos, servicios de aplicaciones y más. Esto es
particularmente útil cuando ha configurado rutas definidas por el usuario que enrutan
primero el tráfico vinculado a Internet a través de un dispositivo virtual de red o en las
instalaciones. Un beneficio adicional de los puntos de conexión de servicio es que los
recursos de la red virtual no necesitan una dirección IP pública para poder acceder a los
servicios de Azure PaaS.
Tome un ejemplo de una implementación de una sola región en el este de EE. UU. que
tiene:
 Maquinas virtuales
 Cuentas de almacenamiento
 Bases de datos Azure SQL
 Almacén de claves de Azure
 ExpressRoute
Si la conexión de ExpressRoute tiene una ruta definida por el usuario para enviar todo el
tráfico destinado a Internet a través de la conexión de ExpressRoute, eso incluiría el tráfico
a los puntos de conexión públicos de los servicios de Azure enumerados. Esto significa que
el tráfico de una máquina virtual a una base de datos SQL de Azure atravesaría la red de
ExpressRoute y luego pasaría por la Internet pública desde la ubicación local hasta el punto
de conexión público del este de EE. UU.
Esta configuración no solo agrega una latencia innecesaria para la conexión de la base
de datos, sino que también la envía a través de la Internet pública. Los puntos finales de
servicio priorizan el enrutamiento desde la red virtual al servicio de Azure mediante la red
troncal de Microsoft. Esto también elimina la necesidad de realizar cualquier dirección IP
pública o traducción de direcciones de red (NAT) en la subred de origen. Cualquier tráfico
de las VM a Azure SQL Database en este ejemplo mostrará una dirección IP de origen de la
dirección privada de la VM.
Para crear un punto final de servicio para una subred existente, siga estos pasos:
3. En la lista de redes virtuales, seleccione una red implementada
previamente. Por ejemplo, seleccione hub-vnet-eus-01 .
4. Desde la red virtual, haga clic en la hoja Subredes .
5. En la página Subredes, seleccione la subred para crear un punto final de
servicio. Por ejemplo, seleccione app1 .
6. En la sección Puntos finales de servicio de la subred, haga clic en el menú
desplegable y seleccione la casilla de verificación junto al servicio deseado. Por
ejemplo, seleccione Microsoft.Sql .
FIGURA 5-10 Crear punto final de servicio
Al completar la configuración, cualquier tráfico de la subred app1 que esté destinado a

una base de datos SQL de Azure tendrá un enrutamiento optimizado desde la red virtual al
servicio. Además, el campo de la dirección IP de origen será del rango 10.0.2.0/24.
Al realizar el cambio de configuración en una subred existente, asegúrese de que no se

estén ejecutando servicios críticos durante el cambio. Se crea una nueva ruta con los
prefijos de dirección del servicio con un tipo de próximo salto
de VirtualNetworkServiceEndpoint y es posible que se desconecten todas las conexiones
existentes.
CONSEJO DE EXAMEN
Puede ser fácil confundir puntos finales de servicio y puntos finales privados. Asegúrese de
leer los escenarios específicamente y elija el servicio apropiado para lo que se proporciona.
Configurar políticas de punto final de servicio
La creación de un extremo de servicio solo cambia el enrutamiento de la red virtual al

servicio de destino. Por defecto, no realiza ningún filtrado de IP ni control de acceso desde
la red al servicio. Las políticas de punto final de servicio le permiten configurar un control
de acceso granular a recursos de servicio específicos. Combine estas políticas con grupos
de seguridad de red para garantizar que solo los recursos específicos de una subred puedan
acceder a recursos específicos de PaaS.
Cuando crea una política, especifica una definición que contiene el recurso de destino
del servicio. La política permite solo el tráfico a los servicios especificados; se negará el
acceso a todos los demás recursos para ese servicio.
En el momento de escribir este artículo, solo el proveedor de recursos Microsoft.Storage

está disponible para configurar las políticas de punto final de servicio. Opcionalmente,
puede configurar alias de recursos, que actualmente están limitados a:
 /servicios/Azure
 /servicios/Azure/Lote
 /servicios/Azure/DataFactory
 /servicios/Azure/Aprendizaje automático
 /servicios/Azure/Instancia administrada
 /servicios/Azure/WebAPI
Para crear una política de punto final de servicio, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione Política de punto final de
servicio .
3. En la página Políticas de punto final de servicio, haga clic en Crear .
el servicio.
5. En el campo Nombre, proporcione un nombre para la política. Por ejemplo,
ingrese enter sep-eus-policy1 .
7. Haga clic en Siguiente: Definiciones de políticas . La Figura 5-11 muestra
la pestaña Conceptos básicos completada.
FIGURA 5-11 Conceptos básicos de la creación de políticas de punto final de
servicio
8. En la pestaña Definiciones de políticas, haga clic en Agregar un recurso .

9. En el panel Agregar un recurso, complete el formulario con esta
configuración para permitir el acceso solo a una cuenta de almacenamiento de
Azure creada anteriormente, az700app1.
1. Servicio: Microsoft.Almacenamiento
2. Alcance: cuenta única
3. Suscripción: Su suscripción
4. Grupo de recursos: App1
5. Recurso: az700app1
10. Haga clic en Agregar . La Figura 5-12 muestra el panel Agregar un recurso
completado.
FIGURA 5-12 Política de extremo de servicio para agregar un recurso
11. Haga clic en Revisar + Crear y, a continuación, haga clic en Crear .

12. Después de implementar el recurso, haga clic en Ir al recurso .
13. En la política recién creada, haga clic en la hoja Subredes asociadas .
14. En la hoja Subredes asociadas, haga clic en Editar asociación de
subred . La Figura 5-13 muestra la nueva política y opción de menú.
FIGURA 5-13 Subredes asociadas a la política de punto final de servicio
15. En el menú desplegable Red virtual, seleccione la red virtual que contiene
una subred con un punto final de servicio definido. Por ejemplo, seleccione hub-
vnet-eus-01 .
16. Se mostrará la subred con un extremo de servicio que se configuró
previamente. Seleccione la casilla de verificación junto al nombre de la subred.
17. Haga clic en Aplicar . La Figura 5-14 muestra la configuración completa.
FIGURA 5-14 Asociación de edición de políticas de punto final de servicio
Configurar etiquetas de servicio
El nombre del objetivo que figura en el examen es "configurar etiquetas de servicio"; sin
embargo, los administradores de Azure no pueden configurar las propias etiquetas de
servicio. Las etiquetas de servicio representan el grupo de docenas, si no cientos, de
direcciones IP que podrían usarse para acceder a un servicio de Azure determinado en una
región o en la infraestructura global de Azure. Por ejemplo, para las cuentas de
almacenamiento hay una etiqueta de servicio de almacenamiento que representa cualquier
dirección IP asociada con Azure. O está Storage.EastUS, que representa solo las
direcciones IP de almacenamiento para la región Este de EE. UU.
Las etiquetas de servicio se pueden usar tanto con grupos de seguridad de red como con
Azure Firewall para filtrar y restringir el tráfico hacia y desde recursos específicos en
regiones específicas. Esto es útil en entornos que tienen regulaciones de cumplimiento en
ciertos países o requisitos de soberanía de datos basados en la ubicación de implementación
de la aplicación. La configuración de un grupo de seguridad de red se analizó en el Capítulo
4 , sección de habilidades 4.2 .
Habilidad 5.3: Configurar la integración de VNet para servicios de plataforma como servicio
(PaaS) dedicados
Una red virtual generalmente se asocia con la infraestructura y los recursos de IaaS, como
las máquinas virtuales. Sin embargo, debido a que las redes virtuales también pueden ser el
punto central de las VPN, ExpressRoute, las conexiones entre pares y más, puede ser
importante integrar los servicios de PaaS con las redes virtuales.
Azure App Services es un servicio PaaS clave que proporciona integración directamente
con redes virtuales. Con la integración de VNet, puede permitir la comunicación saliente
desde un Servicio de aplicaciones a otros recursos que están conectados a la red
virtual. Escenarios similares también se dan con Azure Kubernetes Service (AKS) y App
Service Environment (ASE).

 Configurar App Service para la integración de VNet regional
 Configurar Azure Kubernetes Service (AKS) para la integración de redes
virtuales regionales
 Configurar clientes para acceder al entorno de App Service
Configurar App Service para la integración de VNet regional
La integración de red virtual, o integración de red virtual, proporciona conectividad saliente

desde un servicio de aplicaciones a la red virtual que configure. Tenga en cuenta que esta es
la dirección inversa que proporciona un punto final privado. Cuando configura la
integración de red virtual por su cuenta, no permite la comunicación entrante a un servicio
de aplicaciones a través de la red virtual.
La configuración de la integración de red virtual se admite en las SKU de App Service

básicas, estándar, premium, premium v2 y premium v3. Los entornos de App Service se
implementan directamente en una red virtual y no necesitan una configuración adicional
para integrarse en una red virtual.
Al configurar la integración de VNet, el código que se ejecuta en App Service tiene

conectividad de red con los recursos de la red virtual. Para la integración de la red virtual
regional, debe haber una subred dedicada en la red virtual para la integración. La subred no
necesita un nombre específico, pero requiere que la subred tenga un tamaño mínimo según
la cantidad de instancias de escala que podría usar el plan de App Service. La Tabla 5-
1 describe las direcciones disponibles y las instancias de escala máxima.
TABLA 5-1 Requisitos de subred de integración de red virtual
Tamaño de subred Direcciones máximas disponibles Instancias de escala máxima

/28 11 5
/27 27 13
/26 59 29
De manera predeterminada, cuando habilita la integración de red virtual, se habilita una

configuración de enrutar todo. Cuando Route All está habilitado, todo el tráfico que sale de
App Service está sujeto a los NSG y UDR que están asociados con la subred
integrada. Combine esta configuración con puntos de conexión de servicio o privados, y
puede configurar la comunicación privada desde un Servicio de aplicaciones a una gran
cantidad de servicios PaaS de Azure.
Para integrar una instancia de App Service existente en una red virtual, siga estos pasos:

2. En la barra de búsqueda, busque y seleccione App Services .
3. En la página Servicios de aplicaciones, haga clic en la hoja Redes .
4. En la hoja Redes, en la sección Tráfico saliente, haga clic en Integración de
red virtual . La Figura 5-15 muestra la hoja Redes.
FIGURA 5-15 Redes de servicios de aplicaciones
5. En la página Integración de red virtual, haga clic en Agregar red virtual .

6. En el menú desplegable Red virtual, seleccione el nombre de una red virtual
para asociarla con App Service. Por ejemplo, seleccione hub-vnet-eus-01 .
7. En el campo Subred, seleccione Crear nueva subred .
8. En el campo Nombre de subred, proporcione un nombre para la nueva
subred. Por ejemplo, ingrese ASIntegration .
9. En el menú desplegable Bloque de direcciones de red virtual, seleccione el
espacio de direcciones apropiado para agregar la subred. Por ejemplo,
seleccione 10.0.0.0/16 .
10. En el campo Bloque de direcciones de subred, proporcione un nuevo rango
de IP para la subred que está disponible en el espacio de direcciones existente. Por
ejemplo, especifique 10.0.5.0/24 .
FIGURA 5-16 Agregar integración de red virtual

Configurar Azure Kubernetes Service (AKS) para la integración de redes virtuales regionales
A diferencia de App Service, no hay un menú específico ni una opción de configuración

para integrar una red virtual con Azure Kubernetes Service (AKS). Esto podría estar abierto
a la interpretación en el sentido de implementar un clúster de AKS privado o usar la opción
de red de kubenet al implementar el clúster.
Con los clústeres de AKS privados, el plano de control (API) del clúster tiene una
dirección IP interna privada que se usa para el tráfico de red entre el servidor de la API y
los grupos de nodos. Con AKS, usted administra el plano de control y el servidor de
API. Puede configurar la comunicación entre estos dos servicios mediante Azure Private
Link. Un clúster de AKS privado también usa unzona DNS privada. Los nodos de agente
tienen registros A creados en la zona privada que se resuelve en su dirección IP privada.
¿NECESITA MÁS
REVISIÓN? CLÚSTERES PRIVADOS
DE AZURE KUBERNETES SERVICE
Para obtener más información sobre los clústeres privados de AKS,
visite https://docs.microsoft.com/en-us/azure/aks/private-clusters .
Cuando implementa un clúster de AKS mediante kubenet, los nodos reciben una
dirección IP en la red virtual. Los pods adicionales no pueden comunicarse entre sí
directamente y requieren enrutamiento adicional y reenvío de IP para la conectividad entre
pods. El servicio AKS mantiene y configura estas UDR y el reenvío de IP. Sin embargo,
puede implementar una solución de balanceo de carga con una tabla de rutas personalizada
para una administración personalizada.
¿NECESITA MÁS REVISIÓN? REDES

VIRTUALES DEL SERVICIO AZURE
KUBERNETES
Para obtener más información sobre los conceptos de red virtual de AKS,
visite https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-virtual-
networks .
Configurar clientes para acceder al entorno de App Service
En el momento de escribir este artículo, existen tres versiones de App Service Environment
(ASE). Para esta sección, nos centraremos únicamente en ASEv3, la última versión
disponible. Los entornos de App Service se usan normalmente cuando los requisitos de
escala son más de 30 instancias individuales o cuando hay otros requisitos de seguridad
para un sistema de un solo inquilino o un alojamiento de red aislado.
Cuando implementa una aplicación en un ASE que usa una sola subred, la aplicación
usa la dirección de entrada asignada al ASE. Si el ASE tiene una IP virtual interna (VIP), la
dirección de entrada será la VIP para todas las aplicaciones que se
implementen. Finalmente, si el ASE tiene un VIP externo, la dirección de entrada a la
aplicación será la IP pública y se registrará en el DNS público.
La cantidad de direcciones que necesita en un ASE variará según la cantidad de

instancias y el tráfico que tengan las aplicaciones. El tamaño recomendado para un ASE es
un prefijo de dirección CIDR /24, por ejemplo, 10.0.5.0/24. El espacio mínimo de
direcciones de un ASE es un prefijo de dirección /27. Si elige implementar una subred más
pequeña, es posible que las direcciones en la subred se agoten y el ASE no se escale.
Cuando configura un ASE, hay algunos componentes de red para definir:
 Red virtual ASE. La red virtual en la que se implementa el ASE.

 subred ASE. La subred en la que se implementa el ASE.
 Sufijo de dominio. El sufijo de dominio utilizado por las aplicaciones en el
ASE.
 IP virtual. Una dirección IP virtual interna o externa.
 Dirección de entrada. El VIP que elijas y cómo se establece la conectividad
entrante.
 Dirección de salida predeterminada. La dirección IP utilizada cuando el
ASE realiza conexiones salientes.
Para que el ASE acepte conexiones entrantes, cualquier NSG debe aceptar tráfico en los
puertos 80 y 443 para el tráfico web. También puede abrir los puertos 4022, 4024 y 4026
para el tráfico de depuración remota de Visual Studio y el puerto 8172 para el servicio Web
Deploy.
Si planea usar su propio DNS para que los clientes se conecten al ASE, entonces se debe
crear una zona para el ASE usando el dominio asename.appserviceenvironment.net. Puede
usar zonas DNS públicas y privadas dependiendo de dónde se conectarán los clientes.
 Private Link tiene dos componentes: servicios privados y puntos finales

privados.
 Los servicios privados le permiten publicar su propia aplicación como
proveedor para que otras suscripciones accedan a la aplicación como consumidor.
 Los puntos finales privados son el lado del consumidor de Private Link y
establecen la NIC virtual que se conecta a un servicio privado.
 Para los servicios de Azure, el DNS es un componente fundamental de
Private Link. Externamente, los servicios aún se resuelven con direcciones IP
públicas. Solo la red virtual desde la que se configura el extremo privado devuelve
una dirección IP privada.
 Para configurar entornos híbridos con puntos finales privados, debe
configurar servicios DNS adicionales con reenvío condicional.
 Los puntos de conexión de servicio proporcionan un enrutamiento
optimizado a los servicios de PaaS de Azure, pero siguen usando una dirección IP
pública para el servicio.
 Los puntos de conexión de servicio no requieren que las direcciones IP
públicas estén en los recursos de Azure que implementa y administra.
 Las políticas de punto final de servicio le permiten configurar restricciones
de acceso granular para los puntos finales de servicio.
 Las etiquetas de servicio representan los prefijos de dirección que utiliza
Azure para un servicio determinado.
 Las etiquetas de servicio pueden ser una etiqueta global o estar definidas por
servicio por región.
 App Service admite puntos de conexión privados y la integración de red
virtual. Los puntos finales privados admiten conexiones entrantes a App Service. La
integración de VNet admite conexiones salientes desde App Service.
 La integración de VNet requiere una subred dedicada en la red virtual a la
que se asociará.
 AKS se puede integrar con redes virtuales a través de un clúster privado o
con kubenet.
 ASEv3 están asociados con una red virtual y se pueden implementar en una
sola subred.
 El tamaño de subred recomendado para la integración de ASE es un rango
de direcciones de /24.
 El tamaño mínimo de subred para la integración de ASE es un rango de
direcciones de /27.
 El NSG para la subred que usa el ASE debe aceptar tráfico 80 y 443.
 Se pueden abrir otros puertos para el tráfico de depuración de Visual Studio
(4022, 4024, 4026) y el tráfico de Web Deploy (8172).
 ASE usa el dominio appserviceenvironment.net para DNS.
Experimento mental

Una organización tiene una aplicación que pretende vender a sus clientes. Espera que
sus clientes accedan al servicio desde sus propias suscripciones. Algunos de los clientes de
la organización tienen el requisito de acceder al servicio mediante el uso de direcciones IP
privadas. Parte de la aplicación para la organización usará Azure SQL Databases. La
organización también quiere usar un rango de direcciones IP privadas para comunicarse
desde sus servicios a la base de datos.
Además, la organización tiene una red virtual de alta seguridad con requisitos de
cumplimiento de transacciones financieras. Uno de los requisitos es que todo el tráfico debe
fluir a través de un firewall. Actualmente, la organización envía todo el tráfico desde la red
virtual dedicada a su firewall local. El tráfico de red en el entorno de alta seguridad no debe
pasar por la Internet pública al acceder a los servicios de Azure. Además, los servicios se
implementarán en solo dos regiones de Azure. Se debe bloquear el tráfico que intenta llegar
a los servicios de Azure en otras regiones.
Finalmente, la organización ha decidido utilizar App Service Environments para una de

sus aplicaciones. Debe planificar cómo configurar Web Deploy y la depuración remota de
Visual Studio con la aplicación. La aplicación debe crecer a más de 30 instancias y debe
poder escalar sin límites de red.
1. 1 . ¿Cómo debe la organización publicar el acceso a su aplicación?

2. 2 . ¿Cómo debe la organización acceder al servicio de Azure SQL Database?
3. 3 . ¿Cómo puede la organización cumplir con los objetivos de cumplimiento en el
entorno de alta seguridad?
4. 4 . ¿Qué puede usar la organización para bloquear el tráfico a otras regiones de
Azure?
5. 5 . ¿Qué debe hacer la organización para usar Web Deploy y la depuración remota
de Visual Studio?
6. 6 _ ¿En qué tamaño de subred se debe implementar el ASE?
1. 1 . ¿Cómo debe la organización publicar el acceso a su aplicación?
La organización debería considerar el uso de los servicios de Azure Private Link

para publicar la aplicación. Esto permitirá a sus clientes crear puntos finales
privados y conectarse a la aplicación utilizando direcciones IP privadas.
2. 2 . ¿Cómo debe la organización acceder al servicio de Azure SQL Database?
La organización debe usar un punto de conexión privado para acceder a la instancia

de Azure SQL Database. Esto permitirá a la organización crear una NIC virtual en
la subred que desea configurar y permitir que se utilicen direcciones IP privadas
para acceder a la base de datos.
3. 3 . ¿Cómo puede la organización cumplir con los objetivos de cumplimiento en el

entorno de alta seguridad?
Para cumplir con los requisitos de cumplimiento, la organización debe considerar el
uso de puntos finales de servicio. Esto optimizará el tráfico de red para los servicios
de Azure y garantizará que no pasen por la Internet pública.
4. 4 . ¿Qué puede usar la organización para bloquear el tráfico a otras regiones de

Azure?
La organización puede usar etiquetas de servicio con grupos de seguridad de red

para bloquear el tráfico a regiones que no se están usando.
5. 5 . ¿Qué debe hacer la organización para usar Web Deploy y la depuración remota
de Visual Studio?
El NSG que está asociado con la subred en la que se implementa el ASE debe tener
los siguientes puertos abiertos: 4022, 4024, 4026 y 8172.
6. 6 _ ¿En qué tamaño de subred se debe implementar el ASE?
Para proporcionar la cantidad máxima de escala, la subred debe proporcionar un

rango de direcciones /24.
Índice
A
ACL (listas de control de acceso), 171 . Consulte también NSG (grupos de seguridad de red)
alertas, Azure Monitor, 190
alias, 204
puertas de enlace de aplicaciones
grupo de servidores, creación, 120 – 121
creando, 116 – 120
sondas de salud, 123 – 125
Ajustes de HTTP, configuración, 122
oyentes, configuración, 125 – 126
políticas de reescritura, configuración, 131 – 133
reglas de enrutamiento, configuración, 126 – 128

división en subredes, 56 – 57
Seguridad de la capa de transporte, configuración, 128 – 131
colección de reglas de aplicación, Azure Firewall, 165 – 166
arquitectura, Azure Virtual WAN, 75 – 77
ASE (Entorno de servicio de aplicaciones), configuración, 221 – 222
ASG (grupo de seguridad de aplicaciones)
asociarse con un NIC, 176 – 177
creando, 175
asociando
ASG con NIC, 176 – 177
NSG con un recurso, 173 – 174
Pólizas WAF con un recurso, 188 – 189
autenticación
Azure AD
Cliente VPN Azure, 28 – 29
configurar, 26 – 28
basado en certificados, configuración, 24 – 26
VPN de punto a sitio, resolución de problemas, 30 – 31
RADIUS, configuración de VPN de punto a sitio, 22 – 24
Azure AD (Directorio Activo)
Cliente VPN Azure, 28 – 29
configuración de VPN de punto a sitio, 26 – 28
Azure App Services, integración de red virtual, 218 – 220

Azure Application Gateway, 113 – 114
elegir un SKU, 115 – 116
creando, 116 – 120
opciones de implementación, 114 – 115
Ajustes de HTTP, configuración, 122
oyentes, configuración, 125 – 126
políticas de reescritura, configuración, 131 – 133
reglas de enrutamiento, configuración, 126 – 128
Seguridad de la capa de transporte, configuración, 128 – 131
Políticas WAF, 186 – 188
Azure Bastion, división en subredes, 58 – 59
Azure ExpressRoute, 31
BFD (detección de reenvío bidireccional), 33 , 45
configurar una puerta de enlace, 41
configurar el cifrado terminado, 44 – 45
conectar un circuito a una red virtual, 42 – 43
diseñar conectividad interregional entre ubicaciones, 33 – 34
FastPath, 37 – 38
Alcance mundial, 35 – 36
mirando, 38 – 39
Microsoft, 40 – 41
privado, 39
requisitos de anuncios de ruta, 43 – 44
seleccionando entre circuito regular y Directo, 32 – 33
SKU
máximo de redes virtuales vinculadas, 35
rendimiento, 34 – 35
solución de problemas de conectividad, 46
Sitio VPN, conexión al concentrador, 81 – 83
cortafuegos azul
despliegue
crear e implementar, 161 – 162
diseño, 160 – 161
dentro de un centro virtual, 169 – 170
políticas, creación, 166 – 169
SKU premium, 160
colecciones de reglas
aplicación, 165 – 166
NAT, 163 – 164
red, 164 – 165
reglas, 163
ANS, 160
SKU estándar, 160
Puerta delantera azul, 134 , 138

sondeos de estado, configuración, 137 – 138
Acceso al certificado de Key Vault, configuración, 138
agregar dominio personalizado al punto final, 140 – 141
cifrado de extremo a extremo, 142
permisos, 139
registrar un principal de servicio, 138 – 139
escuchas multisitio y destinos de back-end, configuración, 143
reglas de enrutamiento, 143 – 144
Políticas WAF, 185 – 186
Almacén de claves de Azure. Véase también cifrado
Acceso Front Door a certificados, configuración, 138 – 142
permisos, 139
Azure Kubernetes Service, integración de red virtual, 220 – 221
Equilibrador de carga de Azure, 100
implementación informática, 104 – 106
configurar reglas de salida explícitas, 112
creando, 102 – 106
implementar reglas de equilibrio de carga, 106 – 109
Reglas NAT, 110 – 111
público, 102
persistencia de sesión, 109

Monitor azul, 190
alertas, 190
acciones, 191
condiciones, 190
creando, 191 – 194
Enlace privado de Azure, 203 . Ver también puntos finales de servicio
creación de un servicio Private Link, 204 – 207
integrando
con DNS, 211
con clientes locales, 211 – 212
puntos finales privados, creación, 207 – 211
opciones de seguridad, 207
puntos finales de servicio, 213
Azure Route Server, división en subredes, 60
Administrador de tráfico de Azure, 145
configurar un método de enrutamiento, 145 – 147
puntos finales, 147 – 149
Configuración HTTP, 149 – 150
WAN virtual de Azure, 74
conectarse a una puerta de enlace de red virtual, 78 – 83
creando, 75 – 77
diseñar la arquitectura, 75 – 77
tipos de SKU, 75
centro virtual
configurar enrutamiento en, 85 – 88
creando, 77 – 78
creación de un dispositivo virtual de red en, 83 – 85
implementación de Azure Firewall en, 169 – 170
sitio VPN
asociar con el concentrador, 80
creando, 79 – 80
AzureCT (Kit de herramientas de conectividad de Azure), 46
objetivos de back-end, Azure Front Door, 143
BFD (detección de reenvío bidireccional), 33 , 45
almacenamiento de blobs, resolución de DNS y, 211
certificados, rutas de archivos, 30
archivo de configuración del cliente, implementación para VPN de punto a sitio, 28 – 29
comandos, ping, 211
configurando
puertas de enlace de aplicaciones
Configuración de HTTP, 122

oyentes, 125 – 126
reescribir políticas, 131 – 133
TLS (Seguridad de la capa de transporte), 128 – 131
ASE (Entorno de servicio de aplicaciones), 221 – 222
Azure AD (Directorio Activo), 26 – 28
Azure ExpressRoute
BFD (detección de reenvío bidireccional), 45
cifrado, 44 – 45
FastPath, 37 – 38
puerta de entrada, 41
Alcance mundial, 35 – 36
Emparejamiento de Microsoft, 40 – 41
emparejamiento privado, 39
anuncio de ruta, 43 – 44
Puerta principal azul
acceso a certificados de Key Vault, 138 – 142
oyentes multisitio y objetivos de back-end, 143
Administrador de tráfico de Azure
puntos finales, 147 – 149
Configuración HTTP, 149 – 150

método de enrutamiento, 145 – 147
tunelización forzada, 97
puerta de enlace de red local, 6 – 7
resolución de nombres, zonas DNS públicas o privadas, 66
VPN de punto a sitio
autenticación basada en certificados, 24 – 26
Autenticación RADIUS, 22 – 24
etiquetas de servicio, 218
enrutamiento de centro virtual, 85 – 88
puerta de enlace de red virtual, 7 – 10
Monitor de conexión, 194 – 197
conectividad
configuración entre ubicaciones de Azure ExpressRoute, 33 – 34
implementación de emparejamiento de redes virtuales, 69 – 72
encadenamiento de servicios, 72 – 73
solución de problemas
Azure ExpressRoute, 46
consulta de datos de registro de diagnóstico, 16 – 18
Herramienta de solución de problemas de VPN, 18 – 20
vpn, 74
creando
puertas de enlace de aplicaciones, 116 – 120
ASG (grupo de seguridad de aplicaciones), 175

Equilibrador de carga de Azure, 102 – 106
WAN virtual de Azure, 75 – 78
grupo de back-end, 120 – 121
conexiones en un circuito ExpressRoute, 42 – 43
registros de flujo, 181
puerta de enlace de red local, 6 – 7
Área de trabajo de Log Analytics, 15 – 16
NSG (grupos de seguridad de red), 172
políticas, Administrador de cortafuegos, 166 – 169
Servicio de enlace privado, 204 – 207
tablas de rutas, 86 – 88 , 93
puntos finales de servicio, 213 – 215
puerta de enlace de red virtual, 7 – 10
redes virtuales, 52 – 53
Sitio VPN, 79 – 80
delegación de subredes, 59 – 60
Regla de denegación, 179
despliegue
Puerta de enlace de aplicaciones de Azure, 114 – 115
cortafuegos azul
crear e implementar, 161 – 162
diseño, 160 – 161

dentro de un centro virtual, 169 – 170
diseño
Arquitectura de Azure Virtual WAN, 75 – 77
Zonas DNS, públicas, 61 – 63
VPN de sitio a sitio, 2 – 4
Conectividad VPN entre redes virtuales, 74
Circuito directo, Azure ExpressRoute, 32 – 33
DNS
almacenamiento de blobs y, 211
integración con Private Link, 211
configuración local, 211 – 212
zonas
privado, diseño, 63 – 65
público, diseño, 61 – 63
mi
cifrado, configuración sobre Azure ExpressRoute, 44 – 45
puntos finales
Administrador de tráfico de Azure, 147 – 149
privado, 203
creando, 207 – 211
división en subredes, 59
servicio, 213
creando, 213 – 215

políticas, 215 – 217
FastPath, configuración para Azure ExpressRoute, 37 – 38
Firewall Manager, creación de políticas, 166 – 169
cortafuegos, división en subredes, 55 – 56
registros de flujo
insights-log-networksecuritygroupflowevent, 182
NSG (grupo de seguridad de red), 180 – 181
tunelización forzada, configuración, 97
GH
puerta de enlace, configuración para Azure ExpressRoute, 41
Alcance global, configuración para Azure ExpressRoute, 35 – 36
sondeos de estado, configuración
en la puerta de enlace de aplicaciones, 123 – 125
en Azure Front Door, 137 – 138
HTTP (Protocolo de transferencia de hipertexto)
configurar en puerta de enlace de aplicaciones, 122
Configuración de Traffic Manager, 149 – 150
yo
como
parámetros por defecto fase 1, 11
parámetros de política admitidos, 12

actualizaciones de la versión 2, 31
balanceadores de carga internos, 102
Direccionamiento IP, resolución de nombres, 60 – 61
dentro de una red virtual, 65
vincular una red virtual a una zona DNS privada, 67 – 68
zonas DNS privadas, configurar, 66
zonas DNS privadas, diseño, 63 – 65
zonas DNS publicas, configurar, 66
zonas DNS públicas, diseño, 61 – 63
JKL
vinculación, zona DNS privada a una red virtual, 67 – 68
oyentes
configurar en la puerta de enlace de aplicaciones, 125 – 126
multisitio, 143
balanceadores de carga
configurar reglas de salida explícitas, 112
implementar reglas de equilibrio de carga, 106 – 109
interno, 102
Reglas NAT, 110 – 111
público, 102

pasarela de red local, creación y configuración, 6 – 7
Área de trabajo de Log Analytics, creación, 15 – 16
METRO
Emparejamiento de Microsoft, configuración para Azure ExpressRoute, 40 – 41
Microsoft.Insights, registro del proveedor de recursos, 14 – 15
agentes de escucha multisitio, Azure Front Door, 143
norte
resolución de nombres, 60 – 61
registro DNS, creación, 66
dentro de una red virtual, 65
zonas DNS privadas
configurar, 66
diseño, 63 – 65
vinculación a una red virtual, 67 – 68
zonas DNS públicas
configurar, 66
diseño, 61 – 63
NAT
asignación de direcciones IP públicas para una puerta de enlace, 151 – 153
asociarse con una subred, 153 – 154
elegir cuándo usar, 150 – 151
configurar en Azure Load Balancer, 110 – 111
creación de una colección de reglas de Azure Firewall, 163 – 164

colección de reglas de red, Azure Firewall, 164 – 165
Vigilante de la red, 189 , 199 – 200 . Consulte también solución de problemas
Monitor azul, 190
acciones, 191
alertas, 190
condiciones, 190
Monitor de conexión, 194 – 197
Herramienta de verificación de flujo IP, 182 – 184
Herramienta de salto siguiente, 99 – 100
Análisis de tráfico, 197 – 198
Herramienta de salto siguiente, 99 – 100
NIC (tarjeta de interfaz de red)
ASG (grupo de seguridad de aplicaciones)
asociando, 176 – 177
creando, 175
NSG (grupo de seguridad de red)
asociar con un recurso, 173 – 174
creando, 172
registro de diagnóstico, 198 – 199
NSG (grupo de seguridad de red), 171 . Véase también ASG (grupo de seguridad de
aplicaciones)
creando, 172
Regla de denegación, 179
registro de diagnóstico, 198 – 199
registros de flujo, 180 – 181
creando, 181
reglas, 177 – 180
verificación del flujo de IP, 182 – 184
OP
reglas de salida, configuración en Azure Load Balancer, 112
OWASP (Proyecto de Seguridad de Aplicaciones Web Abiertas), 185
PaaS (plataforma como servicio), 52 , 61 , 203
puntos finales privados, creación, 207 – 211
puntos finales de servicio
creando, 213 – 215
Integración de red virtual
Servicios de aplicaciones de Azure, 218 – 220
Servicio Azure Kubernetes, 220 – 221
filtrado de paquetes, inspección de paquetes y, 172
mirando
implementar en redes virtuales, 69 – 72
Microsoft, 40 – 41
opciones, 70
privado, 39
seleccionando para Azure ExpressRoute, 38 – 39
permisos, Azure Key Vault, 139
comando de ping, 211
VPN de punto a sitio, 20
Azure AD, configuración, 26 – 28
autenticación basada en certificados, configuración, 24 – 26
implementar un archivo de configuración de cliente VPN, 28 – 29
autenticación RADIUS, configuración, 22 – 24
seleccione una SKU de puerta de enlace de red virtual adecuada, 21 – 22
SSTP (Protocolo de tunelización de sockets seguros), 22
solución de problemas del lado del cliente, 30 – 31
políticas
Administrador de cortafuegos, 166 – 169
reescribir, 131 – 133
punto final de servicio, 215 – 217
WAF (cortafuegos de aplicaciones web), 184
asociarse con un recurso, 188 – 189
Conjuntos de reglas de Azure Application Gateway, 186 – 188
Conjuntos de reglas de Azure Front Door, 185 – 186
implementar, 184 – 185
modo, configuración, 185
VPN basadas en políticas, 5

clientes locales, integración con Private Link, 211 – 212
precios, circuitos Azure ExpressRoute, 33
zonas DNS privadas
diseño, 63 – 65
vinculación a una red virtual, 67 – 68
puntos finales privados, 203
creando, 207 – 211
Servicio de enlace privado. Véase también Azure Private Link ; puntos finales de servicio
alias, 204
creando, 204 – 207
integración con DNS, 211
integración con clientes locales, 211 – 212
opciones de seguridad, 207
puntos finales de servicio, 213
emparejamiento privado, configuración para Azure ExpressRoute, 39
propiedades, reglas NSG, 177 – 178
equilibradores de carga pública, 102
código QR
consultas, datos de registro de diagnóstico, 16 – 18
RADIUS, configuración de VPN de punto a sitio, 22 – 24
redundancia
regionales, 2
zona, 2 – 3
redundancia regional, VPN de sitio a sitio, 2
registro, proveedor de recursos Microsoft.Insights, 14 – 15
circuito regular, Azure ExpressRoute, 32 – 33
recursos
asociarse con una póliza WAF, 188 – 189
asociarse con un NSG, 173 – 174
políticas de reescritura, configuración en la puerta de enlace de aplicaciones, 131 – 133
anuncio de ruta, requisitos para Azure ExpressRoute, 43 – 44
tablas de rutas, 73
creando, 93
crear en un hub virtual, 86 – 88
VPN basadas en rutas, 5
enrutamiento, 91
reglas, 143 – 144
resolución de problemas, 97 – 100
definido por el usuario, 92 – 95
normas
ACL (listas de control de acceso), 171
Cortafuegos azul, 163
aplicación, 165 – 166

NAT, 163 – 164
red, 164 – 165
política, 168
Puerta principal azul, 185 – 186
equilibrio de carga, 106 – 109
NSG (grupo de seguridad de red), 177 – 180
saliente, 112
enrutamiento, 143 – 144
puntos finales de servicio, 213 . Ver también puntos finales privados
creando, 213 – 215
etiquetas de servicio, 203 , 218
VPN de sitio a sitio
crear y configurar una puerta de enlace de red local, 6 – 7
diseño, 2 – 4
como
crear una política personalizada, 13
parámetros de política admitidos, 12

basado en políticas, 5
redundante regionalmente, 2
basado en rutas, 5
solución de problemas de conectividad, 14 – 20
puerta de enlace de red virtual, 7
configurar la conexión, 9 – 10
creando un recurso, 7 – 8
con redundancia de zona, 2 – 3
SKU
Azure Application Gateway, 115 – 116
Azure ExpressRoute, 34 – 35
Cortafuegos azul, 160
Puerta delantera azul, 134 – 136
Equilibrador de carga de Azure, 101 – 102
WAN virtual de Azure, 75
generaciones, 5
seleccionando
para VPN de punto a sitio, 21 – 22
para una puerta de enlace de red virtual, 4 – 5
SLA, cortafuegos de Azure, 160

división en subredes Véase también Direccionamiento IP
Servidor de ruta Azure, 60
delegación de, 59 – 60
NAT y, 153 – 154
NSG (grupo de seguridad de red)
creando, 172
tablas de rutas y, 95 – 97
redes virtuales, 54
pasarelas de aplicaciones, 56 – 57
Bastión Azul, 58 – 59
cortafuegos, 55 – 56
puertas de enlace de red virtual, 54 – 55
TLS (Seguridad de la capa de transporte), configuración en la puerta de enlace de

aplicaciones, 128 – 131
Análisis de tráfico, 197 – 198
solución de problemas
Problemas de conectividad de Azure ExpressRoute, 46
Herramienta de verificación de flujo IP, 182 – 184
VPN de punto a sitio, problemas de autenticación y del lado del cliente, 30 – 31
enrutamiento, 97 – 100
Problemas de conectividad VPN
ultravioleta
rutas definidas por el usuario, 92 – 95 , 213 – 214
verificación, flujo de IP a una máquina virtual, 182 – 184
centro virtual
asociarse con un sitio VPN, 80
configurar enrutamiento en, 85 – 88
conectarse al sitio VPN, 81 – 83
creación de un dispositivo virtual de red en, 83 – 85
crear en una WAN virtual de Azure, 77 – 78
implementación de Azure Firewall en, 169 – 170
red(es) virtual(es), 51 , 203
creando, 52 – 53
diseño de conectividad VPN entre, 74
puerta de enlace, conexión a Azure Virtual WAN, 78 – 83
vinculación a una zona DNS privada, 67 – 68
resolución de nombres, diseño, 65
NAT
asignar direcciones IP públicas para una puerta de enlace, 151 – 153
elegir cuándo usar, 150 – 151

mirando, 69 – 72
enrutamiento, 91
división en subredes y, 95 – 97
resolución de problemas, 97 – 100
definido por el usuario, 92 – 95
pasarelas de aplicaciones, 56 – 57
Bastión Azul, 58 – 59
Servidor de ruta Azure, 60
configurar delegación de, 59 – 60
cortafuegos, 55 – 56
puertas de enlace de red virtual, 54 – 55
WAN virtuales. Ver WAN virtual de Azure
VM (máquinas virtuales)
solución de problemas de enrutamiento en, 98 – 99
verificación del flujo de IP, 182 – 184
Integración de red virtual. Ver también red(es) virtual(es)
Servicios de aplicaciones de Azure y, 218 – 220
Servicio Azure Kubernetes y, 220 – 221
VPN (redes privadas virtuales)

diseño de conectividad entre redes virtuales, 74
punto a sitio, 20
implementar un archivo de configuración de cliente VPN, 28 – 29
planificar y configurar Azure AD, 26 – 28
planificar y configurar la autenticación basada en certificados, 24 – 26
planificar y configurar la autenticación RADIUS, 22 – 24
solución de problemas del lado del cliente, 30 – 31
Sitio a Sitio
crear y configurar una puerta de enlace de red local, 6 – 7
crear y configurar una puerta de enlace de red virtual, 7 – 10
crear una política IKE personalizada, 13
diseño, 2 – 4
Parámetros predeterminados de la fase 1 de IKE, 11
Parámetros predeterminados de la fase 2 de IKE, 12
basado en políticas, 5
redundante regionalmente, 2
basado en rutas, 5
parámetros de política IKE admitidos, 12
solución de problemas de conectividad, 14 – 20
con redundancia de zona, 2 – 3

W
WAF (cortafuegos de aplicaciones web), 184
políticas
asociarse con un recurso, 188 – 189
Conjuntos de reglas de Azure Application Gateway, 186 – 188
Conjuntos de reglas de Azure Front Door, 185 – 186
implementar, 184 – 185
modo, configuración, 185
XYZ
redundancia de zona, VPN de sitio a sitio, 2 – 3

Ref. examen AZ-700 Diseño e implementación de soluciones de red de Microsoft
Azure
Lista de URL
Capítulo 1: Diseñar, implementar y administrar redes híbridas
https://portal.azure.com
https://<IP pública de puerta de enlace de red virtual>:8081/healthprobe

https://login.microsoftonline.com/tenantID/
https://sts.windows.net/tenantID/
https://go.microsoft.com/fwlink/?linkid=2117554
https://aka.ms/precios
https://aka.ms/AzureCT
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-altamente disponible
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-vpn-devices
https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-how-to-radius-ps
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-
resource-manager-portal
https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-troubleshoot-vpn-point-to-
site-connection-problems
https://docs.microsoft.com/en-us/azure/expressroute/expressroute-routing#bgp
https://docs.microsoft.com/en-us/azure/expressroute/expressroute-troubleshooting-network-
rendimiento
Capítulo 2: Diseñar e implementar la infraestructura de red central
https://docs.microsoft.com/en-us/learn/modules/network-fundamentals/
www.microsoft.com
https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/enterprise-
scale/architecture
https://docs.microsoft.com/en-us/azure/virtual-wan/virtual-wan-ubicaciones-partners
Capítulo 3: Diseño e implementación de enrutamiento
https://microsoft.onmicrosoft.com/033ce1c9-f832-4658-b024-ef1cbea108b8
https://infrastructuremap.microsoft.com/
https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-
app/scalable-web-app
Capítulo 4: Proteger y monitorear redes
www.contoso.com
Capítulo 5: Diseñar e implementar el acceso privado a
servicios azules
https://docs.microsoft.com/en-us/azure/private-link/private-endpoint-dns
https://docs.microsoft.com/en-us/azure/aks/private-clusters
https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-virtual-networks
Fragmentos de código
Muchos títulos incluyen código de programación o ejemplos de configuración. Para

optimizar la presentación de estos elementos, vea el libro electrónico en modo horizontal de
una sola columna y ajuste el tamaño de fuente al mínimo. Además de presentar el código y
las configuraciones en formato de texto ajustable, hemos incluido imágenes del código que
imitan la presentación que se encuentra en el libro impreso; por lo tanto, cuando el formato
ajustable pueda comprometer la presentación de la lista de códigos, verá un enlace "Haga
clic aquí para ver la imagen del código". Haga clic en el enlace para ver la imagen del
código de fidelidad de impresión. Para volver a la página anterior, haga clic en el botón
Atrás en su dispositivo o aplicación.

Ref. Examen AZ-700 Diseño e Implementación de Soluciones de Red de Microsoft Azure

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ref. Examen AZ-700 Diseño e Implementación de Soluciones de Red de Microsoft Azure

Cargado por

Copyright:

Formatos disponibles

Ref.

examen AZ-700 Diseño e

Ref. examen AZ-700 Diseño e implementación de soluciones de red de Microsoft Azure

Publicado con la autorización de Microsoft Corporation por:

Pearson Educación, Inc.

Copyright © 2022 por Pearson Education, Inc.

No se asume ninguna responsabilidad de patente con respecto al uso de la información

Número de control de la Biblioteca del Congreso: 2022933634

Microsoft y las marcas comerciales enumeradas en http://www.microsoft.com en la página

Para consultas de ventas gubernamentales, comuníquese con

Servicios editoriales Gill

Torsión creativa, Seattle

Compromiso de Pearson con la diversidad, la equidad y la inclusión

Nuestra ambición es contribuir decididamente a un mundo donde:

 Comuníquese con nosotros si tiene inquietudes sobre cualquier posible sesgo

CAPÍTULO 1 Diseño, implementación y gestión de redes híbridas

CAPÍTULO 2 Diseñar e implementar la infraestructura de red central

CAPÍTULO 3 Diseño e implementación de enrutamiento

CAPÍTULO 4 Redes seguras y monitoreadas

CAPÍTULO 5 Diseñar e implementar el acceso privado a los servicios de Azure

Organización de este libro

Errata, actualizaciones y soporte de libros

Capítulo 1 Diseñar, implementar y administrar redes híbridas

Diseñe una conexión VPN de sitio a sitio para alta disponibilidad

Seleccione una SKU de puerta de enlace de red virtual adecuada

Crear y configurar una puerta de enlace de red local

Crear y configurar una puerta de enlace de red virtual

Crear y configurar una política IPsec/IKE

Diagnosticar y resolver problemas de conectividad de puerta de enlace VPN

Seleccione una SKU de puerta de enlace de red virtual adecuada

Planificar y configurar la autenticación RADIUS

Planificar y configurar la autenticación basada en certificados

Planificar y configurar la autenticación de Azure Active Directory (Azure AD)

Implementar un archivo de configuración de cliente VPN

Habilidad 1.3: Diseñar, implementar y administrar Azure ExpressRoute

Elija entre proveedor y modelo directo (ExpressRoute Direct)

Diseñe e implemente la conectividad entre regiones de Azure entre varias ubicaciones de

Seleccione una SKU y un nivel de ExpressRoute apropiados

Diseñar e implementar ExpressRoute Global Reach

Diseñar e implementar ExpressRoute FastPath

Elija entre emparejamiento privado solo, emparejamiento de Microsoft solo o ambos

Configurar emparejamiento privado

Configurar emparejamiento de Microsoft

Crear y configurar una puerta de enlace de ExpressRoute

Conectar una red virtual a un circuito ExpressRoute

Recomendar una configuración de anuncio de ruta

Configurar el cifrado a través de ExpressRoute

Implementar detección de reenvío bidireccional

Diagnosticar y resolver problemas de conexión de ExpressRoute

Resumen del capítulo

Respuestas del experimento mental

Capítulo 2 Diseñar e implementar la infraestructura de red central

Habilidad 2.1: Diseñar e implementar direccionamiento IP privado para redes virtuales

Crear una red virtual

Planificar y configurar subredes para servicios

Planificar y configurar subredes para Azure Route Server

Habilidad 2.2: Diseñar e implementar la resolución de nombres

Diseñar zonas DNS públicas

Diseñar zonas DNS privadas

Resolución de nombres de diseño dentro de una red virtual

Configurar una zona DNS pública o privada

Vincular una zona DNS privada a una red virtual

Habilidad 2.3: Diseñar e implementar conectividad entre redes virtuales