Contents

Documentación de Virtual Network

Información general
Acerca de Virtual Network
Guías de inicio rápido
Creación de red virtual: Portal
Creación de red virtual: PowerShell
Creación de red virtual: CLI de Azure
Creación de red virtual: plantilla de Resource Manager
Tutoriales
Filtrado del tráfico de red
Enrutado del tráfico de red
Restricción del acceso de la red a recursos
Conexión de redes virtuales
Creación de una instancia de NAT Gateway
Creación y validación de una instancia de NAT Gateway
Ejemplos
CLI de Azure
Azure PowerShell
Plantillas de Resource Manager
Conceptos
Continuidad empresarial
Conectividad
NAT
Información general
Resource
Métricas y alertas
Solución de problemas
Enrutamiento
Interoperabilidad de conectividad de back-end
 Preparación y configuración de la prueba
Configuración de la prueba
Análisis del plano de control
Análisis del plano de datos
Redes de contenedores
Conectividad entre redes
Emparejamiento
Integración de servicios de Azure
Puntos de conexión del servicio
Implementación de un servicio dedicado
Servicios de IP
Direcciones IP públicas
Direcciones IP privadas
Prefijo de IP pública
IPv6 para la red virtual de Azure
Prefijo de dirección IPv6 pública
Preferencia de enrutamiento
Línea de base de seguridad de IP pública
Seguridad
Grupos de seguridad de red
Información general
Funcionamiento
Grupos de seguridad de aplicaciones
Etiquetas de servicio
Directivas de puntos de conexión de servicio
Directivas de red de Kubernetes
Protección contra DDOS
TAP de red virtual
Controles de seguridad de Azure Policy
Subredes
Extensión de subred
Delegación de subred
 Implementación clásica
Guías paso a paso
Planificación y configuración
Planear redes virtuales
Resolución de nombres para las máquinas virtuales y servicios en la nube
Uso de DNS dinámico con su propio servidor DNS
Optimización del rendimiento de la red
Visión y modificación de nombres de host
Registros
Conectividad
Enrutado del tráfico de red
Azure Portal
Azure PowerShell
Azure CLI
Ansible
Administración de tablas de rutas
Administración de NIC
Administración de red virtual
Administración de subredes
Administración de delegación de subred
Creación de emparejamiento de VNet
Mismo modelo de implementación, misma suscripción
Azure PowerShell
Azure CLI
Mismo modelo de implementación, diferentes suscripciones
Diferentes modelos de implementación, misma suscripción
Diferentes modelos de implementación, diferentes suscripciones
Administración del emparejamiento de VNet
Escenarios de conectividad
De red virtual a red virtual
De red virtual (Resource Manager) a red virtual (clásica)
De red virtual a red local (VPN)
 De red virtual a red local (ExpressRoute)
Arquitectura de red híbrida de alta disponibilidad
Configuración de un punto de acceso de terminal de una red virtual
Implementación de redes de contenedores
Servicios de IP
IPv6 para VNet
Adición de IPv6 a la aplicación IPv4
Azure PowerShell
Azure CLI
Equilibrador de carga público básico
Azure PowerShell
CLI de Azure
Plantilla de Resource Manager
Equilibrador de carga público básico
Azure PowerShell
CLI de Azure
Plantilla de Resource Manager
Equilibrador de carga público estándar
Conjunto de escalado de máquinas virtuales con IPv6
Prefijo de dirección IPv6 pública
Direcciones IP
Creación de direcciones IP públicas: Azure Portal
Creación de direcciones IP públicas: PowerShell
Creación de direcciones IP públicas: CLI de Azure
Administración de direcciones IP públicas
Administración de un prefijo de IP pública
Incorporación o eliminación de direcciones IP de tarjetas de interfaz de red
Preferencia de enrutamiento
Creación de una dirección IP pública
Azure portal
Azure PowerShell
Azure CLI
 Configuración de una máquina virtual con preferencia de enrutamiento de
Internet
Azure portal
Azure PowerShell
Azure CLI
Seguridad
Filtrado del tráfico de red
Azure portal
Azure PowerShell
Azure CLI
Aislamiento de red
Uso de puntos de conexión privados
Azure portal
Azure PowerShell
Azure CLI
Uso de puntos de conexión de servicio
Azure portal
Azure PowerShell
Azure CLI
Uso de directivas de punto de conexión de servicio
Azure portal
Azure PowerShell
Azure CLI
Administración de protección contra DDoS
Incorporación de asociados a DDoS Protection Standard
Administración de grupos de seguridad de red
Escenarios de seguridad
Protección de redes con aplicaciones virtuales
Red perimetral entre Internet y Azure
Redes de máquinas virtuales
Creación de una máquina virtual: IP pública estática
Azure portal
Azure PowerShell
 Azure CLI
Incorporación de una dirección IP pública a una máquina virtual existente
Desasociar dirección IP pública de una máquina virtual
Creación de una máquina virtual: IP privada estática
Azure portal
Azure PowerShell
Azure CLI
Creación de máquina virtual: Dirección IP privada estática (clásica)
Azure portal
Azure PowerShell
Creación de una máquina virtual: varias IP
Azure Portal
Azure PowerShell
Azure CLI
Adición o eliminación de interfaces de red
Creación de una máquina virtual: varias NIC
Azure PowerShell
Azure CLI
Creación de una máquina virtual: redes aceleradas
Azure PowerShell
Azure CLI
Configuración de DPDK
Optimización del rendimiento de TCP/IP para máquinas virtuales de Azure
Rendimiento de red de máquinas virtuales
Traslado entre regiones
Grupos de seguridad de red: Portal
Grupos de seguridad de red: PowerShell
Redes virtuales: Portal
Redes virtuales: PowerShell
IP públicas: Portal
IP públicas: PowerShell
NAT
 Creación de una instancia de NAT Gateway: PowerShell
Creación de una instancia de NAT Gateway: CLI
Creación de una instancia de NAT Gateway: Plantilla de Resource Manager
Creación y validación de una instancia de NAT Gateway: PowerShell
Creación y validación de una instancia de NAT Gateway: CLI
Solución de problemas
Solución de problemas de emparejamiento de redes virtuales
Configuración y validación de las conexiones de red virtual o VPN
Grupos de seguridad de red
Rutas
Pruebas de rendimiento
Comprobación de la latencia de red de VM
No se pueden eliminar redes virtuales
Problemas de conectividad entre máquinas virtuales
Configuración de PTR para comprobación de banners de SMTP
Lista de comprobación de solución de problemas de aplicaciones virtuales
Solución de problemas de conectividad SMTP de salida
Acerca de la dirección IP [Link]
Solución de problemas de conectividad de máquinas virtuales de Azure
Implementación clásica
Referencia
CLI de Azure
Azure PowerShell
.NET
Java
[Link]
Python
REST
Plantilla de Resource Manager
Ejemplos de código
Elementos integrados de Azure Policy
Recursos
Desarrollo de aptitudes con Microsoft Learn
Desarrollo de aptitudes con Microsoft Learn
Azure Roadmap
Blog de redes
Página de preguntas y respuestas de Microsoft para Redes
Comentarios de redes
Precios
Calculadora de precios
Stack Overflow
Preguntas más frecuentes
 ¿Qué es Azure Virtual Network?
23/09/2020 • 14 minutes to read • Edit Online

Azure Virtual Network (VNet) es el bloque de creación fundamental de una red privada en Azure. VNet permite
muchos tipos de recursos de Azure, como Azure Virtual Machines (máquinas virtuales), para comunicarse de
forma segura entre usuarios, con Internet y con las redes locales. VNet es similar a una red tradicional que
funcionaría en su propio centro de datos, pero aporta las ventajas adicionales de la infraestructura de Azure,
como la escala, la disponibilidad y el aislamiento.

Conceptos de VNet
Espacio de direcciones : Al crear una instancia de VNet tiene que especificar un espacio de direcciones IP
privado personalizado mediante direcciones públicas y privadas (RFC 1918). Azure asigna a los recursos de
una red virtual una dirección IP privada desde el espacio de direcciones que asigne. Por ejemplo, si
implementa una máquina virtual en una red virtual con el espacio de direcciones, [Link]/16, la máquina
virtual se asignará a una dirección IP privada como [Link].
Subredes: Las subredes le permiten segmentar la red virtual en una o varias subredes y asignar una parte
del espacio de direcciones de la red virtual para cada subred. A continuación, puede implementar los recursos
de Azure en una subred específica. Al igual que en una red tradicional, las subredes permiten segmentar el
espacio de direcciones de red virtual en segmentos que sean adecuados para la red interna de la
organización. Esto también mejora la eficacia de la asignación de dirección. Puede proteger los recursos
dentro de las subredes mediante grupos de seguridad de red. Para más información, consulteGrupo de
seguridad de red.
Regiones : El ámbito de VNet es una sola región o ubicación; sin embargo, se pueden conectar entre sí varias
redes virtuales de diferentes regiones mediante el emparejamiento de red virtual.
Subscription (Suscripción): VNet limita su ámbito a una suscripción. Puede implementar varias redes
virtuales dentro de cada suscripción y región de Azure.

Procedimientos recomendados
Al crear la red en Azure, es importante tener en cuenta los siguientes principios universales de diseño:
Asegúrese de que los espacios de dirección no se superponen. Asegúrese de que el espacio de direcciones
(bloque CIDR) de red virtual no se superponen con otros intervalos de red de la organización.
Las subredes no deben cubrir el espacio de direcciones completo de la red virtual. Planee con antelación y
reserve algún espacio de direcciones para el futuro.
Se recomienda que tenga menos redes virtuales de gran tamaño, en lugar de varias redes virtuales
pequeñas. Esto impedirá la sobrecarga de administración.
Asegure las redes virtual mediante la asignación de grupos de seguridad de red (NSG) a sus subredes.

Comunicación con internet

De manera predeterminada, todos los recursos de una red virtual tienen comunicación de salida hacia Internet.
Para comunicarse con un recurso entrante, asígnele una dirección IP pública o un equilibrador de carga público.
También puede usar la dirección IP pública o el equilibrador de carga público para administrar las conexiones
salientes. Para más información sobre las conexiones salientes en Azure, consulte Conexiones salientes,
Direcciones IP públicas y Equilibrador de carga.
 NOTE
Cuando se usa solo una instancia interna de Standard Load Balancer, la conectividad de salida no está disponible hasta
que define cómo desea que las conexiones salientes trabajen con una dirección IP pública o un equilibrador de carga
público en el nivel de instancia.

Comunicación entre recursos de Azure

Los recursos de Azure se comunican de manera segura entre sí de una de las maneras siguientes:
Mediante una red vir tual : tanto las máquinas virtuales como otros tipos de recursos de Azure se pueden
implementar en una red virtual, como Azure App Service Environment, Azure Kubernetes Service (AKS) y
Azure Virtual Machine Scale Sets. Para ver una lista completa de los recursos de Azure que puede
implementar en una red virtual, consulte Integración de red virtual para los servicios de Azure.
Mediante un punto de conexión de ser vicio de red vir tual : extienda el espacio de direcciones privadas
de la red virtual y la identidad de la red virtual a los recursos del servicio de Azure, como cuentas de Azure
Storage y Azure SQL Database, mediante una conexión directa. Los puntos de conexión de los servicios
permiten proteger los recursos críticos de los servicios de Azure únicamente en una red virtual. Para más
información, consulte Puntos de conexión de servicio de red virtual.
Mediante emparejamiento de VNet : Las redes virtuales se pueden conectar entre sí, lo que permite que
los recursos de cualquiera de ellas se comuniquen entre sí mediante el emparejamiento de red virtual. Las
redes virtuales que conecte pueden estar en la misma región de Azure o en regiones distintas. Para más
información, consulte Emparejamiento de redes virtuales de Azure.

Comunicación con recursos locales

Puede conectar sus equipos y redes local a una red virtual mediante cualquier combinación de las siguientes
opciones:
Red privada vir tual (VPN) de punto a sitio : se establece entre una red virtual y un equipo individual de
la red. Cada equipo que desea establecer conectividad con una red virtual debe configurar su conexión. Este
tipo de conexión es muy útil cuando se está comenzando con Azure, o para los desarrolladores, porque
requiere poco o ningún cambio en la red existente. La comunicación entre el equipo y una red virtual se envía
mediante un túnel cifrado a través de internet. Para más información, consulte VPN de punto a sitio.
VPN de sitio a sitio : se establece entre un dispositivo VPN local y una instancia de Azure VPN Gateway que
está implementada en una red virtual. Este tipo de conexión permite que cualquier recurso local que autorice
acceda a una red virtual. La comunicación entre un dispositivo VPN local y una puerta de enlace de VPN de
Azure se envía mediante un túnel cifrado a través de internet. Para más información, consulte VPN de sitio a
sitio.
Azure ExpressRoute: se establece entre la red y Azure, mediante un asociado de ExpressRoute. Esta
conexión es privada. El tráfico no pasa por Internet. Para más información, consulte ExpressRoute.

Filtrado del tráfico de red

Puede filtrar el tráfico de red entre subredes mediante una o ambas de las siguientes opciones:
Grupos de seguridad de red: los grupos de seguridad de red y los grupos de seguridad de aplicaciones
pueden contener varias reglas de seguridad de entrada y salida que le permiten filtrar el tráfico que llega y
sale de los recursos por dirección IP, puerto y protocolo de origen y destino. Para más información, vea
grupos de seguridad de red y grupos de seguridad de aplicaciones.
Aplicaciones vir tuales de red : una aplicación de red virtual es una máquina virtual que ejecuta una
función de red, como un firewall, la optimización de WAN u otra función de red. Para ver una lista de las
 aplicaciones virtuales de red que se pueden implementar en una red virtual, consulte Azure Marketplace.

Enrutado del tráfico de red

De forma predeterminada Azure enruta el tráfico entre subredes, redes virtuales conectadas, redes locales e
Internet. Puede implementar una o ambas de las siguientes opciones para reemplazar las rutas predeterminadas
que crea Azure:
Tablas de ruta : puede crear tablas de ruta personalizadas con las rutas que controlan a dónde se enruta el
tráfico para cada subred. Más información sobre las tablas de rutas.
Rutas de Protocolo de puer ta de enlace de borde (BGP) : si conecta la red virtual a su red local
mediante una conexión de Azure VPN Gateway o ExpressRoute, puede propagar las rutas BGP locales a sus
redes virtuales. Más información sobre el uso de BGP con Azure VPN Gateway y ExpressRoute.

Integración de red virtual para los servicios de Azure

La integración de servicios de Azure en una red virtual de Azure permite el acceso privado al servicio desde las
máquinas virtuales o los recursos de proceso de la red virtual. Puede integrar los servicios de Azure en la red
virtual con las siguientes opciones:
Implementación de instancias dedicadas del servicio en una red virtual. Luego se puede acceder de forma
privada a los servicios dentro de la red virtual y desde redes locales.
Usando Private Link para acceder de forma privada a una instancia específica del servicio desde la red virtual
y desde las redes locales.
También puede acceder al servicio mediante puntos de conexión públicos si amplía una red virtual al servicio
a través de los puntos de conexión de servicio. Los puntos de conexión de servicio permiten que los recursos
de servicio se protejan en la red virtual.

Límites de Azure VNet

Hay ciertos límites en torno al número de recursos de Azure que puede implementar. La mayoría de los límites
de redes de Azure están en los valores máximos. Sin embargo, puede aumentar ciertos límites de red como se
especifica en la página de límites de red virtual.

Precios
No hay ningún cargo por usar Azure VNet, es libre de costo. Los cargos estándar son aplicables para recursos
como Virtual Machines (máquinas virtuales) y otros productos. Para más información, consulte Precios de
Virtual Network y la Calculadora de precios de Azure.

Pasos siguientes
Para empezar a usar una red virtual, créela, implemente en ella varias máquinas virtuales y establezca
comunicación entre las máquinas virtuales. Para aprender a hacerlo, consulte la guía de inicio rápido Creación de
una red virtual.
 Inicio rápido: Creación de una red virtual mediante
el Portal de Azure
23/09/2020 • 10 minutes to read • Edit Online

En esta guía de inicio rápido aprenderá a crear una red virtual mediante Azure Portal. Va a implementar dos
máquinas virtuales. Después, debe comunicarse de forma segura entre las máquinas virtuales y conectarse a las
máquinas virtuales desde Internet. Una red virtual es el bloque de creación básico de una red privada en Azure.
Permite que los recursos de Azure, como las máquinas virtuales, se comuniquen de manera segura entre sí y con
Internet.

Requisitos previos
Una cuenta de Azure con una suscripción activa. cree una de forma gratuita.

Inicio de sesión en Azure

Inicie sesión en Azure Portal.

Creación de una red virtual

1. En el menú de Azure Portal, seleccione Crear un recurso . En Azure Marketplace, seleccione Redes > Red
vir tual .
2. En Creación de una red vir tual , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Suscripción Seleccione su suscripción.

Resource group Seleccione Crear nuevo , escriba myResourceGroup y,

después, seleccione Aceptar .

Nombre Escriba myVirtualNetwork.

Location Seleccione Este de EE. UU .

3. Seleccione Siguiente: Direcciones IP y, para el espacio de direcciones IPv4 , escriba [Link]/16.

4. Seleccione Agregar subred y, a continuación, escriba myVirtualSubnet para el nombre de subred y
[Link]/24paraInter valo de direcciones de subred .
5. Seleccione Agregar y, después, Revisar y crear . Deje el resto tal como está y seleccione Crear .
6. En Crear red vir tual , seleccione Crear .

Creación de máquinas virtuales

Cree dos máquinas virtuales en la red virtual:
Creación de la primera máquina virtual
1. En el menú de Azure Portal, seleccione Crear un recurso .
2. En Azure Marketplace, seleccione Proceso > Windows Ser ver 2019 Datacenter . Seleccione Crear .
3. En Creación de una máquina vir tual: conceptos básicos , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Detalles del proyecto

Suscripción Seleccione su suscripción.

Resource group Seleccione myResourceGroup . Ha creado este grupo de

recursos en la sección anterior.

Detalles de instancia

Nombre de la máquina virtual Escriba myVm1.

Region Seleccione Este de EE. UU .

Opciones de disponibilidad El valor predeterminado es No se requiere

redundancia de la infraestructura .

Imagen El valor predeterminado es Windows Ser ver 2019

Datacenter .

Size El valor predeterminado es Estándar DS1 v2 .

Cuenta de administrador

Nombre de usuario Escriba un nombre de usuario de su elección.

Contraseña Escriba una contraseña de su elección. La contraseña

debe tener al menos 12 caracteres de largo y cumplir con
los requisitos de complejidad definidos.

Confirm Password Vuelva a escribir la contraseña.

Reglas de puer to de entrada

Puertos de entrada públicos Seleccione Permitir los puer tos seleccionados .

Selección de puertos de entrada Escriba HTTP (80) y RDP (3389) .

Ahorre dinero

¿Ya tiene una licencia de Windows? El valor predeterminado es No .

4. Seleccione Siguiente: Discos .

5. En Creación de una máquina vir tual: Discos , deje los valores predeterminados y seleccione
Siguiente: Redes .
6. En Creación de una máquina vir tual: Redes , escriba o seleccione esta información:
 C O N F IGURA C IÓ N VA L UE

Virtual network El valor predeterminado es myVir tualNetwork .

Subnet El valor predeterminado es myVir tualSubnet

([Link]/24) .

Dirección IP pública El valor predeterminado es (nuevo) myVm-IP .

Grupo de seguridad de red de NIC El valor predeterminado es Básico .

Puertos de entrada públicos El valor predeterminado es Permitir los puer tos

seleccionados .

Selección de puertos de entrada El valor predeterminado es HTTP y RDP .

7. Seleccione Siguiente: Administración .

8. En Creación de una máquina vir tual: Administración , para Cuenta de almacenamiento de
diagnóstico , seleccione Crear nuevo .
9. En Crear cuenta de almacenamiento , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Nombre Escriba myvmstorageaccount. Si el nombre ya existe, cree

uno único.

Tipo de cuenta El valor predeterminado es Storage (Uso general v1) .

Rendimiento El valor predeterminado es Estándar .

Replicación El valor predeterminado es Almacenamiento con

redundancia local (LRS) .

10. Seleccione Aceptar y, después, Revisar y crear . Se le remitirá a la página Revisar y crear , donde Azure
validará la configuración.
11. Cuando reciba el mensaje Validación superada , seleccione Crear .
Creación de la segunda máquina virtual
Repita el procedimiento de la sección anterior para crear otra máquina virtual.

IMPORTANT
En el nombre de la máquina vir tual, escriba myVm2.
En Cuenta de almacenamiento de diagnóstico , asegúrese de seleccionar myvmstorageaccount , en lugar de crear
una.

Conexión a una máquina virtual desde Internet

Después de crear myVm1, conéctese a Internet.
1. En Azure Portal, busque y seleccione myVm1.
2. Seleccione Conectar y, después, RDP .

Se abre la página Conectar .

3. Seleccione Descargar archivo RDP . Azure crea un archivo de Protocolo de Escritorio remoto ( .rdp) y lo
descarga en su equipo.
4. Abra el archivo RDP. Cuando se le pida, seleccione Conectar .
5. Escriba el nombre de usuario y la contraseña que especificó al crear la VM.

NOTE
Es posible que tenga que seleccionar Más opciones > Usar otra cuenta para especificar las credenciales que
escribió al crear la máquina virtual.

6. Seleccione Aceptar .
7. Puede que reciba una advertencia de certificado cuando inicie sesión. Si recibe una advertencia de
certificado, seleccione Sí o Continuar .
8. Una vez que aparezca el escritorio de la máquina virtual, minimícelo para volver a su escritorio local.

Comunicarse entre máquinas virtuales

1. En el Escritorio remoto de myVm1, abra PowerShell.
2. Escriba ping myVm2 .
Recibirá un mensaje similar a esta salida:

Pinging [Link]
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for [Link]:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Se produce un error de ping , porque ping usa el Protocolo de mensajes de control de Internet (ICMP).
De manera predeterminada, el protocolo ICMP no puede atravesar el Firewall de Windows.
3. Para permitir que myVm2 haga ping a myVm1 en un paso posterior, escriba este comando:
 New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4

Ese comando permite una conexión entrante de ICMP a través del Firewall de Windows:
4. Cierre la conexión de Escritorio remoto a myVm1.
5. Vuelva a realizar los pasos de Conexión a una máquina virtual desde Internet, pero conéctese a myVm2.
6. Desde un símbolo del sistema, escriba ping myvm1 .
Obtendrá un mensaje similar al siguiente:

Pinging [Link] [[Link]] with 32 bytes of data:

Reply from [Link]: bytes=32 time=1ms TTL=128
Reply from [Link]: bytes=32 time<1ms TTL=128
Reply from [Link]: bytes=32 time<1ms TTL=128
Reply from [Link]: bytes=32 time<1ms TTL=128

Ping statistics for [Link]:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 1ms, Average = 0ms

Recibe respuestas de myVm1 porque permitió ICMP a través del Firewall de Windows en la VM myVm1 en
el paso 3.
7. Cierre la conexión de Escritorio remoto a myVm2.

Limpieza de recursos
En esta guía de inicio rápido, ha creado una red virtual predeterminada y dos máquinas virtuales. Se ha
conectado a una VM desde Internet y se ha comunicado de forma segura entre las dos VM.
Cuando haya terminado de usar la red virtual y las VM, elimine el grupo de recursos y todos los recursos que
contiene:
1. Busque y seleccione myResourceGroup.
2. Seleccione Eliminar grupo de recursos .
3. Escriba myResourceGroup para ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS y seleccione
Eliminar .

Pasos siguientes
Para más información sobre la configuración de red virtual, consulte Crear, cambiar o eliminar una red virtual.
De forma predeterminada, Azure permite una comunicación segura entre las máquinas virtuales. Azure solo
permite conexiones de Escritorio remoto entrantes a las máquinas virtuales Windows desde Internet. Para más
información sobre los tipos de comunicaciones de red de máquinas virtuales, consulte el artículo sobre el filtrado
del tráfico de red.

NOTE
Los servicios de Azure cuestan dinero. Azure Cost Management le ayuda a establecer presupuestos y a configurar alertas
para mantener el gasto bajo control. Analice, administre y optimice sus costos de Azure con Cost Management. Para
obtener más información, consulte el inicio rápido sobre el análisis de los costos.
 Inicio rápido: Creación de una red virtual mediante
PowerShell
23/09/2020 • 11 minutes to read • Edit Online

Una red virtual permite que los recursos de Azure, como las máquinas virtuales (VM), se comuniquen entre sí de
forma privada y con Internet. En esta guía de inicio rápido aprenderá a crear una red virtual. Después de crear una
red virtual, implementará dos máquinas virtuales en la red virtual. Luego, conéctese a las máquinas virtuales desde
Internet y, de manera privada, comuníquese a través de la red virtual.

Requisitos previos
Si no tiene una suscripción a Azure, cree una cuenta gratuita ahora.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide en su lugar instalar y usar PowerShell de manera local, este inicio rápido necesita que use la versión 1.0.0.
o posterior del módulo de Azure PowerShell. Ejecute Get-Module -ListAvailable Az para ver cuál es la versión
instalada. Consulte Instalación del módulo de Azure PowerShell para ver información sobre la instalación y la
actualización.
Por último, si ejecuta PowerShell de manera local, también deberá ejecutar Connect-AzAccount . Ese comando crea
una conexión con Azure.
Creación de un grupo de recursos y una red virtual
Debe llevar a cabo una serie de pasos para configurar el grupo de recursos y la red virtual.
Creación del grupo de recursos
Para poder crear una red virtual, debe crear un grupo de recursos que hospede la red virtual. Cree un grupo de
recursos con New-AzResourceGroup. En este ejemplo, se crea un grupo de recursos denominado
myResourceGroup en la ubicación eastus:

New-AzResourceGroup -Name myResourceGroup -Location EastUS

Crear la red virtual

Cree una red virtual con New-AzVirtualNetwork. En este ejemplo, se crea una red virtual predeterminada
denominada myVirtualNetwork en la ubicación EastUS :

$virtualNetwork = New-AzVirtualNetwork `
-ResourceGroupName myResourceGroup `
-Location EastUS `
-Name myVirtualNetwork `
-AddressPrefix [Link]/16

Incorporación de una subred

Azure implementa recursos en una subred dentro de una red virtual, por lo que es necesario crear una subred.
Cree una configuración de subred denominada default con Add-AzVirtualNetworkSubnetConfig:

$subnetConfig = Add-AzVirtualNetworkSubnetConfig `
-Name default `
-AddressPrefix [Link]/24 `
-VirtualNetwork $virtualNetwork

Asociación de la subred a la red virtual

Puede escribir la configuración de la subred en la red virtual con Set-AzVirtualNetwork. Este comando crea la
subred:

$virtualNetwork | Set-AzVirtualNetwork

Creación de máquinas virtuales

Cree dos máquinas virtuales en la red virtual.
Creación de la primera máquina virtual
Cree la primera máquina virtual con New-AzVM. Cuando ejecute el comando siguiente, se le pedirán las
credenciales. Escriba un nombre de usuario y una contraseña para la máquina virtual:

New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Location "East US" `
-VirtualNetworkName "myVirtualNetwork" `
-SubnetName "default" `
-Name "myVm1" `
-AsJob
La opción -AsJob crea la máquina virtual en segundo plano. Puede continuar al paso siguiente.
Cuando Azure empieza a crear la máquina virtual en segundo plano, verá algo como esto:

Id Name PSJobTypeName State HasMoreData Location Command

-- ---- ------------- ----- ----------- -------- -------
1 Long Running... AzureLongRun... Running True localhost New-AzVM

Creación de la segunda máquina virtual

Cree la segunda máquina virtual con este comando:

New-AzVm `
-ResourceGroupName "myResourceGroup" `
-VirtualNetworkName "myVirtualNetwork" `
-SubnetName "default" `
-Name "myVm2"

Tendrá que crear otro usuario y otra contraseña. Azure tarda unos minutos en crear la máquina virtual.

IMPORTANT
No vaya al próximo paso hasta que Azure haya terminado. Sabrá que terminó cuando devuelva la salida a PowerShell.

Conexión a una máquina virtual desde Internet

Use Get-AzPublicIpAddress para devolver la dirección IP pública de una máquina virtual. Este ejemplo devuelve la
dirección IP pública de la máquina virtual myVm1:

Get-AzPublicIpAddress `
-Name myVm1 `
-ResourceGroupName myResourceGroup `
| Select IpAddress

Abra un símbolo del sistema en el equipo local. Ejecute el comando mstsc . Reemplace <publicIpAddress> por la
dirección IP pública que se devolvió en el último paso:

NOTE
Si ejecutó estos comandos desde un símbolo del sistema de PowerShell en el equipo local y usa la versión 1.0 o posterior del
módulo Az de PowerShell, puede seguir en esa interfaz.

mstsc /v:<publicIpAddress>

1. Cuando se le pida, seleccione Conectar .

2. Escriba el nombre de usuario y la contraseña que especificó al crear la máquina virtual.

NOTE
Es posible que tenga que seleccionar Más opciones > Usar otra cuenta para especificar las credenciales que
escribió al crear la máquina virtual.
3. Seleccione Aceptar .
4. Puede que reciba una advertencia de certificado. Si la recibe, seleccione Sí o Continuar .

Comunicarse entre máquinas virtuales

1. En el Escritorio remoto de myVm1, abra PowerShell.
2. Escriba ping myVm2 .
Verá algo similar a lo siguiente:

PS C:\Users\myVm1> ping myVm2

Pinging [Link]
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for [Link]:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Se produce un error de ping, porque usa el Protocolo de mensajes de control de Internet (ICMP). De manera
predeterminada, el protocolo ICMP no puede atravesar el Firewall de Windows.
3. Para permitir que myVm2 haga ping a myVm1 en un paso posterior, escriba este comando:

New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4

Ese comando permite una conexión entrante de ICMP a través del Firewall de Windows.
4. Cierre la conexión de Escritorio remoto a myVm1.
5. Repita los pasos que aparecen en Conexión a una máquina virtual desde Internet. Esta vez, conéctese a
myVm2.
6. En un símbolo del sistema de la máquina virtual myVm2, escriba ping myvm1 .
Verá algo similar a lo siguiente:

C:\windows\system32>ping myVm1

Pinging [Link] [[Link]] with 32 bytes of data:

Reply from [Link]: bytes=32 time=2ms TTL=128
Reply from [Link]: bytes=32 time<1ms TTL=128
Reply from [Link]: bytes=32 time<1ms TTL=128
Reply from [Link]: bytes=32 time<1ms TTL=128

Ping statistics for [Link]:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 2ms, Average = 0ms

Recibe respuestas de myVm1, porque permitió ICMP a través del Firewall de Windows en la máquina virtual
myVm1 en un paso anterior.
7. Cierre la conexión de Escritorio remoto a myVm2.
Limpieza de recursos
Cuando haya terminado con la red virtual y las máquinas virtuales, use Remove-AzResourceGroup para quitar el
grupo de recursos y todos los recursos que tiene:

Remove-AzResourceGroup -Name myResourceGroup -Force

Pasos siguientes
En esta guía de inicio rápido, ha creado una red virtual predeterminada y dos máquinas virtuales. Se ha conectado
a una máquina virtual desde Internet y se ha comunicado de forma privada entre las dos máquinas virtuales. Azure
permite que haya comunicación privada sin restricciones entre las máquinas virtuales. De manera predeterminada,
Azure solo permite conexiones de Escritorio remoto entrantes a las máquinas virtuales Windows desde Internet.
Para más información sobre cómo configurar distintos tipos de comunicaciones de red de VM, vaya al siguiente
artículo:
Filtrado del tráfico de red
 Inicio rápido: Creación de una red virtual mediante la
CLI de Azure
23/09/2020 • 7 minutes to read • Edit Online

Una red virtual permite que los recursos de Azure, como las máquinas virtuales, se comuniquen de manera
privada entre sí y con Internet. En esta guía de inicio rápido aprenderá a crear una red virtual. Después de crear
una red virtual, implementará dos máquinas virtuales en la red virtual. Luego, conéctese a las máquinas virtuales
desde Internet y, de manera privada, comuníquese a través de la red virtual nueva.

Requisitos previos
Si no tiene una suscripción a Azure, cree una cuenta gratuita ahora.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si, en su lugar, decide instalar y usar la CLI de Azure en un entorno local, para esta guía de inicio rápido se necesita
la versión 2.0.28 de la CLI de Azure o una versión posterior. Ejecute az --version para buscar la versión instalada.
Consulte Instalación de la CLI de Azure para obtener información sobre la instalación o actualización.

Creación de un grupo de recursos y una red virtual

Para poder crear una red virtual, debe crear un grupo de recursos que hospede la red virtual. Cree un grupo de
recursos con az group create. En este ejemplo, se crea un grupo de recursos denominado myResourceGroup en la
ubicación eastus:

az group create --name myResourceGroup --location eastus

Cree la red virtual con el comando az network vnet create. En este ejemplo se crea una red virtual predeterminada
denominada myVirtualNetwork con una subred denominada default:

az network vnet create \

--name myVirtualNetwork \
--resource-group myResourceGroup \
--subnet-name default

Creación de máquinas virtuales

Cree dos máquinas virtuales en la red virtual.
Creación de la primera máquina virtual
Cree la máquina virtual con az vm create. Si las claves SSH no existen en la ubicación de claves predeterminada, el
comando las crea. Para utilizar un conjunto específico de claves, utilice la opción --ssh-key-value . La opción
--no-wait crea la máquina virtual en segundo plano, así que puede continuar con el siguiente paso. En este
ejemplo se crea una máquina virtual llamada myVm1:

az vm create \
--resource-group myResourceGroup \
--name myVm1 \
--image UbuntuLTS \
--generate-ssh-keys \
--no-wait

Creación de la segunda máquina virtual

Como usó la opción --no-wait en el paso anterior, puede avanzar y crear la segunda máquina virtual denominada
myVm2.

az vm create \
--resource-group myResourceGroup \
--name myVm2 \
--image UbuntuLTS \
--generate-ssh-keys

Mensaje de salida de la CLI de Azure

Las máquinas virtuales tardan unos minutos en crearse. Una vez que Azure crea las máquinas virtuales, la CLI de
Azure devuelve una salida similar a la siguiente:
 {
"fqdns": "",
"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/virtualMachines/myVm2",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "[Link]",
"publicIpAddress": "[Link]",
"resourceGroup": "myResourceGroup"
"zones": ""
}

Anote el valor de publicIpAddress . Usará esta dirección para conectarse a la máquina virtual desde Internet en el
paso siguiente.

Conexión a una máquina virtual desde Internet

En este comando, reemplace <publicIpAddress> por la dirección IP pública de la máquina virtual myVm2:

ssh <publicIpAddress>

Comunicarse entre máquinas virtuales

Para confirmar la comunicación privada entre las máquinas virtuales myVm2 y myVm1, escriba este comando:

ping myVm1 -c 4

Recibirá cuatro respuestas de [Link].

Cierre la sesión SSH con la máquina virtual myVm2.

Limpieza de recursos
Cuando ya no se necesiten, puede utilizar az group delete para eliminar el grupo de recursos y todos los recursos
que contiene:

az group delete --name myResourceGroup --yes

Pasos siguientes
En esta guía de inicio rápido, ha creado una red virtual predeterminada y dos máquinas virtuales. Se ha conectado
a una máquina virtual desde Internet y se ha comunicado de forma privada entre las dos máquinas virtuales.
Azure permite que haya comunicación privada sin restricciones entre las máquinas virtuales. De manera
predeterminada, Azure solo permite conexiones de Escritorio remoto entrantes a las máquinas virtuales Windows
desde Internet. Para más información sobre cómo configurar distintos tipos de comunicaciones de red de VM, vaya
al siguiente artículo:
Filtrado del tráfico de red
 Inicio rápido: Creación de una red virtual: plantilla de
Resource Manager
23/09/2020 • 4 minutes to read • Edit Online

En este inicio rápido aprenderá a crear una red virtual con dos subredes mediante la plantilla de Resource Manager.
Una red virtual es el bloque de creación básico de una red privada en Azure. Permite que los recursos de Azure,
como las máquinas virtuales, se comuniquen de manera segura entre sí y con Internet.
Una plantilla de Resource Manager es un archivo de notación de objetos JavaScript (JSON) que define la
infraestructura y la configuración del proyecto. La plantilla usa sintaxis declarativa, lo que permite establecer lo que
pretende implementar sin tener que escribir la secuencia de comandos de programación para crearla.
También se puede completar este inicio rápido mediante Azure Portal, Azure PowerShell o la CLI de Azure.

Requisitos previos
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Revisión de la plantilla
La plantilla usada en este inicio rápido forma parte de las plantillas de inicio rápido de Azure.

{
"$schema": "[Link]
"contentVersion": "[Link]",
"parameters": {
"vnetName": {
"type": "string",
"defaultValue": "VNet1",
"metadata": {
"description": "VNet name"
}
},
"vnetAddressPrefix": {
"type": "string",
"defaultValue": "[Link]/16",
"metadata": {
"description": "Address prefix"
}
},
"subnet1Prefix": {
"type": "string",
"defaultValue": "[Link]/24",
"metadata": {
"description": "Subnet 1 Prefix"
}
},
"subnet1Name": {
"type": "string",
"defaultValue": "Subnet1",
"metadata": {
"description": "Subnet 1 Name"
}
},
"subnet2Prefix": {
"type": "string",
"defaultValue": "[Link]/24",
"metadata": {
 "metadata": {
"description": "Subnet 2 Prefix"
}
},
"subnet2Name": {
"type": "string",
"defaultValue": "Subnet2",
"metadata": {
"description": "Subnet 2 Name"
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
}
},
"variables": {},
"resources": [
{
"type": "[Link]/virtualNetworks",
"apiVersion": "2020-05-01",
"name": "[parameters('vnetName')]",
"location": "[parameters('location')]",
"properties": {
"addressSpace": {
"addressPrefixes": [
"[parameters('vnetAddressPrefix')]"
]
}
},
"resources": [
{
"type": "subnets",
"apiVersion": "2020-05-01",
"location": "[parameters('location')]",
"name": "[parameters('subnet1Name')]",
"dependsOn": [
"[parameters('vnetName')]"
],
"properties": {
"addressPrefix": "[parameters('subnet1Prefix')]"
}
},
{
"type": "subnets",
"apiVersion": "2020-05-01",
"location": "[parameters('location')]",
"name": "[parameters('subnet2Name')]",
"dependsOn": [
"[parameters('vnetName')]",
"[parameters('subnet1Name')]"
],
"properties": {
"addressPrefix": "[parameters('subnet2Prefix')]"
}
}
]
}

En la plantilla se han definido los siguientes recursos de Azure:

[Link]/vir tualNetworks : cree una red virtual de Azure.
[Link]/vir tualNetworks/subnets : cree una subred.
Implementación de la plantilla
Implementación de la plantilla de Resource Manager en Azure:
1. Seleccione Implementar en Azure para iniciar sesión en Azure y abrir la plantilla. La plantilla crea una red
virtual con dos subredes.

2. En el portal, en la página Create a Vir tual Network with two Subnets (Crear una red virtual con dos
subredes), escriba o seleccione los valores siguientes:
Grupo de recursos : seleccione Crear nuevo , escriba un nombre para el grupo de recursos y seleccione
Aceptar .
Nombre de la red vir tual : escriba el nombre de la nueva red virtual.
3. Seleccione Revisar y crear y, luego, Crear .

Revisión de los recursos implementados

Explore los recursos que se crearon con la red virtual.
Para obtener información sobre la sintaxis y las propiedades de JSON de una red virtual en una plantilla, consulte
[Link]/virtualNetworks.

Limpieza de recursos
Cuando ya no necesite los recursos que ha creado con la red virtual, elimine el grupo de recursos. Así se quitan
tanto la red virtual como todos los recursos relacionados.
Para eliminar el grupo de recursos, llame al cmdlet Remove-AzResourceGroup :

Remove-AzResourceGroup -Name <your resource group name>

Pasos siguientes
En este inicio rápido, ha implementado una red virtual de Azure con dos subredes. Para más información sobre las
redes virtuales de Azure, pase al tutorial de redes virtuales.
Filtrado del tráfico de red
 Tutorial: Filtrado del tráfico de red con un grupo de
seguridad de red mediante Azure Portal
23/09/2020 • 15 minutes to read • Edit Online

Puede filtrar el tráfico de red entrante y saliente de una subred de una red virtual con un grupo de seguridad de
red. Los grupos de seguridad de red contienen reglas de seguridad que filtran el tráfico de red por dirección IP,
puerto y protocolo. Las reglas de seguridad se aplican a los recursos implementados en una subred. En este tutorial,
aprenderá a:
Crear un grupo de seguridad de red y reglas de seguridad
Crear una red virtual y asociar un grupo de seguridad de red a una subred
Implementar máquinas virtuales (VM) en una subred
Probar los filtros de tráfico
Si lo prefiere, puede completar este tutorial con la CLI de Azure o Azure PowerShell.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Inicio de sesión en Azure

Inicie sesión en Azure Portal en [Link]

Creación de una red virtual

1. En el menú de Azure Portal o en la página principal , seleccione Crear un recurso .
2. Seleccione Redes y Red vir tual .
3. Escriba o seleccione la siguiente información, acepte los valores predeterminados para el resto de la
configuración y luego seleccione Crear :

C O N F IGURA C IÓ N VA L UE

Nombre myVirtualNetwork

Espacio de direcciones [Link]/16

Subscription Seleccione su suscripción.

Resource group Haga clic en Crear nuevo y escriba myResourceGroup.

Location Seleccione Este de EE. UU .

Nombre de subred mySubnet

Subred: intervalo de direcciones [Link]/24

Creación de grupos de seguridad de aplicaciones

Un grupo de seguridad de aplicaciones permite agrupar servidores con funciones similares, como servidores web.
1. En el menú de Azure Portal o en la página principal , seleccione Crear un recurso .
2. En el cuadro Buscar en Marketplace , escriba Grupo de seguridad de aplicaciones. Cuando Grupo de
seguridad de aplicaciones aparezca en los resultados de la búsqueda, selecciónelo, vuelva a seleccionar
Grupo de seguridad de aplicaciones en Todo y, después, haga clic en Crear .
3. Especifique o seleccione los siguientes datos y haga clic en Crear :

C O N F IGURA C IÓ N VA L UE

Nombre myAsgWebServers

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y después seleccione

myResourceGroup .

Location Este de EE. UU.

4. Complete el paso 3 de nuevo, especificando los valores siguientes:

C O N F IGURA C IÓ N VA L UE

Nombre myAsgMgmtServers

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y después seleccione

myResourceGroup .

Location Este de EE. UU.

Crear un grupo de seguridad de red

1. En el menú de Azure Portal o en la página principal , seleccione Crear un recurso .
2. Seleccione Redes y Grupo de seguridad de red .
3. Especifique o seleccione los siguientes datos y haga clic en Crear :

C O N F IGURA C IÓ N VA L UE

Nombre myNsg

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y después seleccione

myResourceGroup.

Location Este de EE. UU.

Asociación del grupo de seguridad de red a la subred

1. En el cuadro Search resources, services, and docs (Buscar en recursos, servicios y documentos) en la parte
superior del portal, comience a escribir myNsg. Cuando myNsg aparezca en los resultados de búsqueda,
 selecciónelo.
2. En CONFIGURACIÓN , seleccione Subredes y, luego, + Asociar , como se muestra en la imagen siguiente:

3. En Asociar subred , seleccione Red vir tual y myVir tualNetwork . Seleccione Subred , MySubnet y, a
continuación, Aceptar .

Creación de reglas de seguridad

1. Seleccione CONFIGURACIÓN , Reglas de seguridad de entrada y, después, + Agregar , tal como se
muestra en la imagen siguiente:

2. Cree una regla de seguridad que permita a los puertos 80 y 443 para el grupo de seguridad de la aplicación
myAsgWebSer vers . En Agregar regla de seguridad de entrada , escriba o seleccione los valores
siguientes, acepte el resto de valores predeterminados y, después, seleccione Agregar :

C O N F IGURA C IÓ N VA L UE
 C O N F IGURA C IÓ N VA L UE

Destination Seleccione Grupo de seguridad de la aplicación y, a

continuación, seleccione myAsgWebSer vers para Grupo
de seguridad de la aplicación .

Intervalos de puertos de destino Escriba 80,443

Protocolo Selección de TCP

Nombre Allow-Web-All

3. Repita el paso 2 de nuevo, utilizando los siguientes valores:

C O N F IGURA C IÓ N VA L UE

Destination Seleccione Grupo de seguridad de la aplicación y, a

continuación, seleccione myAsgMgmtSer vers para
Grupo de seguridad de la aplicación .

Intervalos de puertos de destino Escriba 3389

Protocolo Selección de TCP

Priority Escriba 110

Nombre Allow-RDP-All (Permitir-RDP-Todo)

En este tutorial, se expone RDP (puerto 3389) a Internet para la máquina virtual que se asigna al grupo de
seguridad de la aplicación myAsgMgmtServers. En entornos de producción, en lugar de exponer el puerto
3389 a Internet, se recomienda conectarse a los recursos de Azure que desee administrar mediante una VPN
o una conexión de red privada.
Una vez completados los pasos 1 a 3, revise las reglas creadas. La lista debe ser similar a la que aparece en la
siguiente imagen:

Creación de máquinas virtuales

Cree dos máquinas virtuales en la red virtual.
Creación de la primera máquina virtual
1. En el menú de Azure Portal o en la página principal , seleccione Crear un recurso .
2. Seleccione Compute y, después, seleccione Windows Ser ver 2016 Datacenter .
3. Escriba o seleccione la siguiente información y acepte los valores predeterminados para el resto de la
configuración:

C O N F IGURA C IÓ N VA L UE

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y, a continuación,

myResourceGroup .

Nombre myVmWeb

Location Seleccione Este de EE. UU .

Nombre de usuario Escriba un nombre de usuario de su elección.

Contraseña Escriba una contraseña de su elección. La contraseña debe

tener al menos 12 caracteres de largo y cumplir con los
requisitos de complejidad definidos.

4. Seleccione un tamaño para la máquina virtual y luego Seleccionar .

5. En Redes , seleccione los valores siguientes y acepte los valores predeterminados restantes:

C O N F IGURA C IÓ N VA L UE

Virtual network Seleccione myVir tualNetwork .

Grupo de seguridad de red de NIC Seleccione Ninguno .

6. Seleccione Revisar y crear en la esquina inferior izquierda y seleccione Crear para iniciar la
implementación de la máquina virtual.
Creación de la segunda máquina virtual
Complete de nuevo los pasos 1 a 6, pero recuerde que, en el paso 3, debe nombrar la máquina virtual myVmMgmt.
La maquina virtual tarda unos minutos en implementarse. No continúe con el paso siguiente hasta que se
implemente la máquina virtual.

Asociación de interfaces de red a un ASG

Cuando el portal creó las máquinas virtuales, se creó también una interfaz de red para cada una y la interfaz de red
se asoció a la máquina virtual. Agregue la interfaz de red para cada máquina virtual a uno de los grupos de
seguridad de la aplicación que creó anteriormente:
1. En el cuadro Search resources, services, and docs (Buscar en recursos, servicios y documentos) en la parte
superior del portal, comience a escribir myVmWeb. Cuando la máquina virtual myVmWeb aparezca en los
resultados de búsqueda, selecciónela.
2. En CONFIGURACIÓN , seleccione Redes . Seleccione Configure the application security groups
(Configurar los grupos de seguridad de la aplicación), seleccione myAsgWebSer vers para Grupos de
seguridad de la aplicación y, a continuación, seleccione Guardar , tal y como se muestra en la siguiente
imagen:
3. Complete los pasos 1 y 2 de nuevo, buscando la máquina virtual myVmMgmt y seleccionando el ASG
myAsgMgmtSer vers .

Probar los filtros de tráfico

1. Conéctese a la máquina virtual myVmMgmt. Escriba myVmMgmt en el cuadro de búsqueda que se
encuentra en la parte superior del portal. Seleccione myVmMgmt cuando aparezca en los resultados de la
búsqueda. Seleccione el botón Conectar .
2. Seleccione Descargar archivo RDP .
3. Abra el archivo RDP descargado y seleccione Conectar . Escriba el nombre de usuario y la contraseña que
especificó al crear la máquina virtual. Puede que deba seleccionar More choices (Más opciones) y, luego,
Use a different account (Usar una cuenta diferente), para especificar las credenciales que escribió al crear
la máquina virtual.
4. Seleccione Aceptar .
5. Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Si recibe la advertencia,
seleccione Sí o Continuar para continuar con la conexión.
La conexión se realiza correctamente porque el puerto 3389 tiene permitida la entrada desde Internet al
grupo de seguridad de aplicaciones myAsgMgmtServers en el que se encuentra la interfaz de red conectada
a la máquina virtual myVmMgmt.
6. Para conectarse a la máquina virtual myVmWeb desde la máquina virtual myVmMgmt, escriba el siguiente
comando en una sesión de PowerShell:

mstsc /v:myVmWeb

Es posible conectarse a la máquina virtual myVmWeb desde la máquina virtual myVmMgmt porque las
máquinas virtuales de la misma red virtual pueden comunicarse entre sí a través de cualquier puerto, de
forma predeterminada. Sin embargo, no es posible crear una conexión de escritorio remoto con la máquina
virtual myVmWeb desde Internet porque la regla de seguridad para myAsgWebServers no permite el puerto
3389 de entrada desde Internet y, de forma predeterminada, al tráfico de entrada desde Internet se le
deniegan todos los recursos.
7. Para instalar Microsoft IIS en la máquina virtual myVmWeb use el siguiente comando desde una sesión de
PowerShell en la máquina virtual myVmWeb:

Install-WindowsFeature -name Web-Server -IncludeManagementTools

8. Una vez completada la instalación de IIS, desconecte la sesión de la máquina virtual myVmWeb, lo que le
deja en la conexión de escritorio remoto de la máquina virtual myVmMgmt.
 9. Desconéctese de la máquina virtual myVmMgmt.
10. En el cuadro Search resources, services, and docs (Buscar recursos, servicios y documentos) en la parte
superior de Azure Portal, comience a escribir myVmWeb desde su equipo. Cuando aparezca myVmWeb en
los resultados de búsqueda, selecciónelo. Anote la Dirección IP pública de la máquina virtual. La dirección
que aparece en la siguiente imagen es [Link], pero su dirección es diferente:

11. Para confirmar que tiene acceso al servidor web myVmWeb desde Internet, abra un explorador de Internet
en el equipo y vaya a [Link] . Ve la pantalla de bienvenida de IIS,
porque el puerto 80 tiene permitida la entrada desde Internet al grupo de seguridad de aplicaciones
myAsgWebServers en el que se encuentra la interfaz de red conectada a la máquina virtual myVmWeb.

Limpieza de recursos
Cuando ya no sea necesario, elimine el grupo de recursos y todos los recursos que contiene:
1. Escriba myResourceGroup en el cuadro Buscar que se encuentra en la parte superior del portal. Seleccione
myResourceGroup cuando lo vea en los resultados de la búsqueda.
2. Seleccione Eliminar grupo de recursos .
3. Escriba myResourceGroup para ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS: y seleccione Eliminar .

Pasos siguientes
En este tutorial, ha creado un grupo de seguridad de red y lo ha asociado a una subred de una red virtual. Para más
información acerca de los grupos de seguridad de red, consulte Introducción a los grupos de seguridad de red y
Administración de un grupo de seguridad de red.
De forma predeterminada, Azure enruta el tráfico entre subredes. En su lugar, puede elegir enrutar el tráfico entre
subredes a través de una máquina virtual, que actúa como un firewall, por ejemplo. Para aprender a crear una tabla
de rutas, avance al siguiente tutorial.
Creación de una tabla de rutas
 Tutorial: Enrutamiento del tráfico de red con una
tabla de rutas mediante Azure Portal
23/09/2020 • 20 minutes to read • Edit Online

De forma predeterminada, Azure enruta el tráfico entre todas las subredes de una red virtual. Sin embargo, puede
crear sus propias rutas para invalidar las predeterminadas de Azure. Las rutas personalizadas resultan de utilidad si,
por ejemplo, quiere enrutar el tráfico entre subredes por medio de una aplicación virtual de red (NVA). En este
tutorial, aprenderá a:
Creación de una aplicación virtual de red para enrutar el tráfico
Creación de una tabla de rutas
Creación de una ruta
Asociación de una tabla de rutas a una subred
Implementación de máquinas virtuales (VM) en subredes diferentes
Enrutamiento del tráfico desde una subred a otra a través de una aplicación virtual de red
Este tutorial usa Azure Portal. También puede usar la CLI de Azure o Azure PowerShell.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Creación de una aplicación virtual de red

Las aplicaciones virtuales de red (NVA) son máquinas virtuales que ayudan con las funciones de red, como la
optimización del enrutamiento y del firewall. En este tutorial se supone que está utilizando Windows Ser ver
2016 Datacenter . Si lo desea puede seleccionar un sistema operativo diferente.
1. En el menú Azure Portal o en la página Inicio , seleccione Crear un recurso .
2. Elija Seguridad > Windows Ser ver 2016 Datacenter .
3. En la página Creación de una máquina vir tual , en Conceptos básicos , escriba o seleccione esta
información:

SEC C IÓ N C O N F IGURA C IÓ N A C C IÓ N

Detalles del proyecto Suscripción Elija su suscripción.

Resource group Seleccione Crear nuevo , escriba

myResourceGroup y seleccione
Aceptar .

Detalles de instancia Nombre de la máquina virtual Escriba myVmNva.

Region Elija (EE. UU.) Este de EE. UU. .

Opciones de disponibilidad Elija No se requiere redundancia

de la infraestructura .

Imagen Elija Windows Ser ver 2016

Datacenter .

Size Deje el valor predeterminado

Estándar DS1 v2 .
SEC C IÓ N C O N F IGURA C IÓ N A C C IÓ N

Cuenta de administrador Nombre de usuario Escriba un nombre de usuario de su

elección.

Contraseña Introduzca una contraseña de su

elección, que debe tener al menos
12 caracteres y cumplir con los
requisitos de complejidad definidos.

Confirm Password Vuelva a escribir la contraseña.

Reglas de puer to de entrada Puertos de entrada públicos Elija Ninguno .

Ahorrar dinero ¿Ya tiene una licencia de Elija No .

Windows Server?
 Después, seleccione Siguiente: Discos > .
4. En Discos , seleccione la configuración adecuada para sus necesidades y, después, seleccione Siguiente:
Redes > .
5. En Redes :
a. En Red vir tual , seleccione Crear nuevo .
b. En el cuadro de diálogo Crear red vir tual , en Nombre , introduzca myVirtualNetwork.
c. En Espacio de direcciones , reemplace el intervalo de direcciones existente por [Link]/16.
d. En Subredes , seleccione el icono Eliminar para eliminar la subred existente y, a continuación,
especifique las siguientes combinaciones de nombre de subred e inter valo de direcciones .
Cuando se especifica un nombre y un intervalo válidos, aparece una nueva fila vacía debajo de él.
 N O M B RE DE SUB RED IN T ERVA LO DE DIREC C IO N ES

Pública [Link]/24

Privada [Link]/24

DMZ [Link]/24

e. Seleccione Aceptar para salir del cuadro de diálogo.

f. En Subred , seleccione DMZ ([Link]/24) .
g. En IP pública , elija Ninguno , ya que esta máquina virtual no se conectará a través de Internet.
h. Seleccione Siguiente: Administración > .
6. En Administración :
a. En Cuenta de almacenamiento de diagnóstico , seleccione Crear nuevo .
b. En el cuadro de diálogo Crear cuenta de almacenamiento , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Nombre mynvastorageaccount

Tipo de cuenta Storage (de uso general v1)

Rendimiento Estándar

Replicación Almacenamiento con redundancia local (LRS).

c. Seleccione Aceptar para salir del cuadro de diálogo.

d. Seleccione Revisar + crear . Se le remite a la página Revisar y crear y Azure valida la configuración.
7. Cuando reciba el mensaje Validación superada , seleccione Crear .
La máquina virtual tarda en crearse unos minutos. Espere hasta que Azure termine de crear la máquina
virtual. La página La implementación está en curso le mostrará los detalles de la implementación.
8. Cuando la máquina virtual esté lista, seleccione Ir al recurso .

Creación de una tabla de rutas

1. En el menú Azure Portal o en la página Inicio , seleccione Crear un recurso .
2. En el cuadro de búsqueda, escriba Tabla de enrutamiento. Cuando Tabla de enrutamiento aparezca en los
resultados de la búsqueda, selecciónelo.
3. En la página Tabla de enrutamiento , seleccione Crear .
4. En Crear tabla de rutas , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Nombre myRouteTablePublic
 C O N F IGURA C IÓ N VA L UE

Suscripción Su suscripción

Resource group myResourceGroup

Location (EE. UU.) Este de EE. UU.

Propagación de rutas de puerta de enlace de red virtual Enabled

5. Seleccione Crear .

Creación de una ruta

1. Vaya a Azure Portal para administrar la tabla de rutas. Busque y seleccione Tablas de rutas .
2. Seleccione el nombre de la tabla de rutas (myRouteTablePublic ).
3. Elija Rutas > Agregar .
4. En Agregar ruta , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Nombre de ruta ToPrivateSubnet

Prefijo de dirección [Link]/24 (el intervalo de direcciones de la subred

Privada creada anteriormente)

Tipo de próximo salto Aplicación vir tual

Siguiente dirección de salto [Link] (una dirección dentro del intervalo de direcciones
de la subred perimetral)

5. Seleccione Aceptar .

Asociación de una tabla de rutas a una subred

1. Vaya a Azure Portal para administrar la red virtual. Busque y seleccione Redes vir tuales .
2. Elija el nombre de la red virtual (myVir tualNetwork ).
3. En la barra de menús de la red virtual, elija Subredes .
4. En la lista de subredes de la red virtual, elija Público .
5. En Tabla de rutas , elija la tabla de rutas que creó (myRouteTablePublic ) y, a continuación, seleccione
Guardar para asociar la tabla de rutas a la subred Pública.

Habilitación del reenvío IP

A continuación, active el reenvío IP para la nueva máquina virtual NVA, myVmNva. Cuando Azure envía tráfico de
red a myVmNva, si el tráfico se destina a una dirección IP diferente, el reenvío IP envía el tráfico a la ubicación
correcta.
1. Vaya a Azure Portal para administrar la máquina virtual. Busque y seleccione Máquinas vir tuales .
2. Elija el nombre de la máquina virtual (myVmNva ).
3. En la barra de menús de la máquina virtual NVA, seleccione Redes .
4. Seleccione myvmnva123 . Esta es la interfaz de red que Azure creó para la máquina virtual. Azure agrega
números para asegurar un nombre único.
5. En la barra de menús de la interfaz de red, seleccione Configuraciones de IP .
6. En la página Configuraciones de IP , establezca Reenvío IP en Habilitado y seleccione Guardar .
Creación de máquinas virtuales públicas y privadas
Cree una máquina virtual pública y una máquina virtual privada en la red virtual. Más adelante, las usará para ver
que Azure enruta el tráfico de subred Público a la subred Privada mediante la aplicación virtual de red.
Para crear la máquina virtual pública y la máquina virtual privada, siga los pasos de Creación de una aplicación
virtual de red anteriormente. No es necesario esperar a que finalice la implementación o ir al recurso de la máquina
virtual. Usará la mayoría de los valores, excepto como se describe a continuación.
Antes de seleccionar Crear para crear la máquina virtual pública o privada, vaya a las dos subsecciones siguientes
(Máquina virtual pública y Máquina virtual privada), que muestran los valores que deben ser diferentes. Puede
continuar con la siguiente sección (Enrutamiento del tráfico desde una subred a otra a través de una aplicación
virtual de red) después de que Azure termine de implementar ambas máquinas virtuales.
Máquina virtual pública
P ESTA Ñ A C O N F IGURA C IÓ N VA L UE

Aspectos básicos Resource group myResourceGroup

Nombre de la máquina virtual myVmPublic

Puertos de entrada públicos Permitir los puer tos seleccionados

Selección de puertos de entrada RDP

Redes Virtual network myVir tualNetwork

Subnet Público ([Link]/24)

 P ESTA Ñ A C O N F IGURA C IÓ N VA L UE

Dirección IP pública El valor predeterminado

Administración Cuenta de almacenamiento de mynvastorageaccount

diagnóstico

Máquina virtual privada

P ESTA Ñ A C O N F IGURA C IÓ N VA L UE

Aspectos básicos Resource group myResourceGroup

Nombre de la máquina virtual myVmPrivate

Puertos de entrada públicos Permitir los puer tos seleccionados

Selección de puertos de entrada RDP

Redes Virtual network myVir tualNetwork

Subnet Privado ([Link]/24)

Dirección IP pública El valor predeterminado

Administración Cuenta de almacenamiento de mynvastorageaccount

diagnóstico

Enrutamiento del tráfico a través de una aplicación virtual de red

Inicio de sesión en myVmPrivate a través de Escritorio remoto
1. Vaya a Azure Portal para administrar la máquina virtual privada. Busque y seleccione Máquinas vir tuales .
2. Seleccione el nombre de la máquina virtual privada (myVmPrivate ).
3. En la barra de menú de la máquina virtual, seleccione Conectar para crear una conexión al Escritorio remoto
para la máquina virtual privada.
4. En la página Conectar con RDP , seleccione Descargar archivo RDP . Azure crea un archivo de Protocolo
de Escritorio remoto ( .rdp) y lo descarga en su equipo.
5. Abra el archivo .rdp descargado. Cuando se le pida, seleccione Conectar . Seleccione Más opciones > Usar
otra cuenta y, después, escriba el nombre de usuario y la contraseña que especificó al crear la máquina
virtual privada.
6. Seleccione Aceptar .
7. Si recibe una advertencia de certificado durante el proceso de inicio de sesión, seleccione Sí para conectar la
máquina virtual.
Habilite ICMP mediante el firewall de Windows
En un paso posterior, usará la herramienta trace route para probar el enrutamiento. Trace route usa el Protocolo de
mensajes de control de Internet (ICMP), que el Firewall de Windows deniega de manera predeterminada. Habilite
ICMP a través del Firewall de Windows.
1. En el escritorio remoto de myVmPrivate, abra PowerShell.
2. Escriba este comando:

New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4

Estará usando el comando trace route para probar el enrutamiento en este tutorial. Para entornos de
producción, no se recomienda permitir ICMP a través del Firewall de Windows.
Activación del reenvío IP en myVmNva
Ha activado el reenvío IP para la interfaz de red de la máquina virtual con Azure. El sistema operativo de la máquina
virtual también tiene que reenviar el tráfico de red. Active el reenvío IP para el sistema operativo de máquina virtual
myVmNva con estos comandos.
1. Desde un símbolo del sistema en la máquina virtual myVmPrivate, abra un Escritorio remoto en la máquina
virtual myVmNva:

mstsc /v:myvmnva

2. En PowerShell, en la máquina virtual myVmNva, escriba este comando para activar el reenvío IP:

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name IpEnableRouter -

Value 1

3. Reinicie la máquina virtual myVmNva. En la barra de tareas, seleccione Inicio > Encendido , Otros
(planeados) > Continuar .
Esto también desconecta la sesión de Escritorio remoto.
4. Una vez que se reinicie la máquina virtual myVmNva, cree una sesión de Escritorio remoto en la máquina
virtual myVmPublic. Mientras sigue conectado a la máquina virtual myVmPrivate, abra un símbolo del
sistema y ejecute este comando:

mstsc /v:myVmPublic

5. En el Escritorio remoto de myVmPublic, abra PowerShell.

6. Habilite ICMP mediante el Firewall de Windows con el comando siguiente:

New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4

Prueba del enrutamiento del tráfico de red

En primer lugar, vamos a probar el enrutamiento del tráfico de red desde la máquina virtual myVmPublic a la
máquina virtual myVmPrivate.
1. En PowerShell, en la máquina virtual myVmPublic, escriba este comando:

tracert myVmPrivate

La respuesta es similar a este ejemplo:

 Tracing route to [Link] [[Link]]
over a maximum of 30 hops:

1 <1 ms * 1 ms [Link]
2 1 ms 1 ms 1 ms [Link]

Trace complete.

Puede ver que el primer salto es [Link], que es la dirección IP privada de la aplicación virtual de red. El
segundo salto es a la dirección IP privada de la máquina virtual myVmPrivate: [Link]. Anteriormente,
agregó la ruta a la tabla de rutas myRouteTablePublic y la asoció a la subred Pública. Como resultado, Azure
envió el tráfico a través de la aplicación virtual de red y no directamente a la subred Privada.
2. Cierre la sesión de Escritorio remoto a la máquina virtual myVmPublic, que aún le deja conectado a la
máquina virtual myVmPrivate.
3. Desde un símbolo del sistema de la máquina virtual myVmPrivate, escriba este comando:

tracert myVmPublic

Este comando prueba el enrutamiento del tráfico de red desde la máquina virtual myVmPrivate a la máquina
virtual myVmPublic. La respuesta es similar a este ejemplo:

Tracing route to [Link] [[Link]]

over a maximum of 30 hops:

1 1 ms 1 ms 1 ms [Link]

Trace complete.

Puede ver que Azure enruta el tráfico directamente desde la máquina virtual myVmPrivate a la máquina
virtual myVmPublic. De forma predeterminada, Azure enruta el tráfico directamente entre subredes.
4. Cierre la sesión de Escritorio remoto a la máquina virtual myVmPrivate.

Limpieza de recursos
Cuando el grupo de recursos ya no sea necesario, elimine myResourceGroup y todos los recursos que contiene:
1. Vaya a Azure Portal para administrar el grupo de recursos. Busque y seleccione Grupos de recursos .
2. Asigne un nombre al grupo de recursos (myResourceGroup ).
3. Seleccione Eliminar grupo de recursos .
4. En el cuadro de diálogo de confirmación, escriba myResourceGroup en ESCRIBA EL NOMBRE DEL
GRUPO DE RECURSOS y, después, seleccione Eliminar . Azure elimina el grupo de recursos
myResourceGroup y todos los recursos vinculados a ese grupo de recursos, incluidas las tablas de rutas, las
cuentas de almacenamiento, las redes virtuales, las interfaces de red y las direcciones IP públicas.

Pasos siguientes
En este artículo, ha creado una tabla de rutas y la ha asociado a una subred. Creó una aplicación virtual de red
sencilla que enrutó el tráfico desde una subred pública hasta una subred privada. Ahora puede implementar
diferentes aplicaciones virtuales de red preconfiguradas desde Azure Marketplace, que proporcionan muchas
funciones de red útiles. Para más información acerca del enrutamiento, consulte Introducción al enrutamiento y
Administración de una tabla de rutas.
Aunque puede implementar muchos recursos de Azure en una red virtual, Azure no puede implementar recursos
para algunos servicios de PaaS en una red virtual. Es posible restringir el acceso a los recursos de algunos servicios
de PaaS de Azure, aunque la restricción solo debe ser el tráfico de una subred de red virtual. Para aprender a
restringir el acceso de red a los recursos de PaaS de Azure, consulte el siguiente tutorial.
Restringir el acceso de red a los recursos de PaaS

NOTE
Los servicios de Azure cuestan dinero. Azure Cost Management le ayuda a establecer presupuestos y a configurar alertas
para mantener el gasto bajo control. Analice, administre y optimice sus costos de Azure con Cost Management. Para obtener
más información, consulte el inicio rápido sobre el análisis de los costos.
 Tutorial: Restricción del acceso de la red a los recursos
de PaaS mediante puntos de conexión de servicio de
red virtual mediante Azure Portal.
23/09/2020 • 21 minutes to read • Edit Online

Los puntos de conexión de servicio de red virtual permiten que el acceso de la red a algunos recursos de servicio
de Azure esté restringido a una subred de la red virtual. También se puede quitar el acceso de Internet a los
recursos. Los puntos de conexión de servicio proporcionan a la red virtual conexión directa con los servicios de
Azure compatibles, de modo que se puede usar el espacio de direcciones privadas de la red virtual para acceder a
los servicios de Azure. El tráfico destinado a los recursos de Azure a través de los puntos de conexión de servicio
siempre se mantiene en la red troncal de Microsoft Azure. En este tutorial, aprenderá a:
Crear una red virtual con una subred
Agregar una subred y habilitar un punto de conexión de servicio
Crear un recurso de Azure y permitir que la red solo pueda acceder a él desde una subred
Implementar una máquina virtual en cada subred
Confirmar el acceso a un recurso desde una subred
Confirmar que se ha denegado el acceso a un recurso desde una subred e Internet
Si lo prefiere, puede completar este tutorial con la CLI de Azure o Azure PowerShell.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Inicio de sesión en Azure

Inicie sesión en Azure Portal en [Link]

Creación de una red virtual

1. Seleccione + Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Redes y Red vir tual .
3. Especifique o seleccione los siguientes datos y haga clic en Crear :

C O N F IGURA C IÓ N VA L UE

Nombre myVirtualNetwork

Espacio de direcciones [Link]/16

Subscription Seleccione su suscripción.

Resource group Haga clic en Crear nuevo y escriba myResourceGroup.

Location Seleccione Este de EE. UU .

Nombre de subred Público

 C O N F IGURA C IÓ N VA L UE

Intervalo de direcciones de subred [Link]/24

Protección contra DDOS Básica

Puntos de conexión del servicio Disabled

Firewall Disabled

Habilitación de un punto de conexión de servicio

Los punto de conexión de servicio están habilitados por servicio, por subred. Cree una subred y habilite un punto
de conexión de servicio para ella.
1. En el cuadro Search resources, ser vices, and docs (Buscar recursos, servicios y documentos) que
encontrará en la parte superior del portal, escriba myVirtualNetwork. Cuando aparezca la opción
myVir tualNetwork en los resultados de la búsqueda, selecciónela.
2. Agregue una subred a la red virtual. En Configuración , seleccione Subredes y + Subred , tal y como se
muestra en la imagen siguiente:
3. En Agregar subred , escriba o seleccione los siguientes datos y haga clic en Aceptar :

C O N F IGURA C IÓ N VA L UE

Nombre Privada

Intervalo de direcciones [Link]/24

Puntos de conexión del servicio Seleccione [Link] en Ser vicios .

Cau t i on

Antes de habilitar un punto de conexión de servicio para una subred existente que tenga recursos, consulte
Modificación de la configuración de subred.

Restricción del acceso de la red para una subred

De forma predeterminada, todas las máquinas virtuales de una subred pueden comunicarse con todos los recursos.
Puede limitar la comunicación hacia y desde todos los recursos de una subred mediante la creación de un grupo de
seguridad de red y su asociación a la subred.
1. Seleccione + Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Redes y Grupo de seguridad de red .
3. En Create a network security group (Crear un grupo de seguridad de red), especifique o seleccione los
datos siguientes y haga clic en Crear :

C O N F IGURA C IÓ N VA L UE

Nombre myNsgPrivate

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y, a continuación,

myResourceGroup.
 C O N F IGURA C IÓ N VA L UE

Location Seleccione Este de EE. UU .

4. Cuando haya creado el grupo de seguridad de red, escriba myNsgPrivate en el cuadro Search resources,
ser vices, and docs (Buscar recursos, servicios y documentos) situado en la parte superior del portal.
Cuando aparezca myNsgPrivate en los resultados de búsqueda, selecciónelo.
5. En Configuración , seleccione Reglas de seguridad de salida .
6. Seleccione +Agregar .
7. Cree una regla que permita la comunicación saliente con el servicio Azure Storage. Especifique o seleccione
los siguientes datos y haga clic en Agregar :

C O N F IGURA C IÓ N VA L UE

Source Seleccione Vir tualNetwork

Source port ranges *

Destination Seleccione Ser vice Tag (Etiqueta de servicio)

Etiqueta de servicio de destino Seleccione Storage (Almacenamiento)

Intervalos de puertos de destino *

Protocolo Any

Acción Allow

Priority 100

Nombre Allow-Storage-All (Permitir-almacenar-todo)

8. Cree otra regla de seguridad de salida que deniegue la comunicación a Internet. Esta regla invalida una regla
predeterminada en todos los grupos de seguridad de red que permite la comunicación saliente de Internet.
Repita los pasos 5 a 7 de nuevo, utilizando los siguientes valores:

C O N F IGURA C IÓ N VA L UE

Source Seleccione Vir tualNetwork

Source port ranges *

Destination Seleccione Ser vice Tag (Etiqueta de servicio)

Etiqueta de servicio de destino Seleccione Internet

Intervalos de puertos de destino *

Protocolo Any
 C O N F IGURA C IÓ N VA L UE

Acción Denegar

Priority 110

Nombre Deny-Internet-All

9. En Configuración , seleccione Reglas de seguridad de entrada .

10. Seleccione +Agregar .
11. Cree una regla de seguridad de entrada que permita que el tráfico de Protocolo de escritorio remoto (RDP) a
la subred desde cualquier lugar. La regla invalidará cualquier regla de seguridad predeterminada que
deniegue todo el tráfico de entrada procedente de Internet. Las conexiones entre Escritorio remoto y la
subred están permitidas, por lo que dicha conectividad podrá probarse en un paso posterior. Seleccione
CONFIGURACIÓN , Reglas de seguridad de entrada y, después, + Agregar . Escriba los siguientes
valores y, a continuación, seleccione Agregar :

C O N F IGURA C IÓ N VA L UE

Source Any

Source port ranges *

Destination Seleccione Vir tualNetwork

Intervalos de puertos de destino 3389

Protocolo Any

Acción Allow

Priority 120

Nombre Allow-RDP-All (Permitir-RDP-Todo)

12. En CONFIGURACIÓN , seleccione Subredes .

13. Seleccione + Asociar
14. En Asociar subred , seleccione Red vir tual y, en Elegir red vir tual , seleccione myVir tualNetwork .
15. En Elegir subred , seleccione Privada y después Aceptar .

Restricción del acceso de la red a un recurso

Los pasos que deben seguirse para restringir el acceso de la red a los recursos creados con servicios de Azure
habilitados para puntos de conexión de servicio varían en función del servicio. Consulte en la documentación de
cada servicio concreto los pasos necesarios para dicho servicio. Como ejemplo, de aquí en adelante se explican los
pasos necesarios para restringir el acceso de red en una cuenta de Azure Storage.
Crear una cuenta de almacenamiento
1. Seleccione + Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Almacenamiento y, a continuación, seleccione Cuenta de almacenamiento: blob, archivo,
tabla, cola .
3. Escriba o seleccione la siguiente información, acepte los valores predeterminados restantes y haga clic en
Crear :

C O N F IGURA C IÓ N VA L UE

Nombre Especifique un nombre que sea único en todas las

ubicaciones de Azure, que tenga entre 3 y 24 caracteres de
longitud y que esté compuesto exclusivamente de
números y letras en minúscula.

Tipo de cuenta StorageV2 (uso general v2)

Location Seleccione Este de EE. UU .

Replicación Almacenamiento con redundancia local (LRS)

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y, a continuación,

myResourceGroup.

Creación de un recurso compartido de archivos en la cuenta de almacenamiento

1. Cuando haya creado la cuenta de almacenamiento, especifique su nombre en el cuadro Buscar recursos,
ser vicios y documentos , situado en la parte superior del portal. Cuando el nombre de la cuenta de
almacenamiento aparezca en los resultados de búsqueda, selecciónelo.
2. Seleccione Archivos , tal y como se muestra en la siguiente ilustración:

3. Seleccione + Recurso compar tido de archivos .

4. Escriba my-file-share en Nombre y seleccione Aceptar .
5. Cierre el cuadro Ser vicio Archivo .
Restricción del acceso de la red a una subred
De forma predeterminada, las cuentas de almacenamiento aceptan conexiones de red procedentes de clientes de
cualquier red, incluido Internet. Deniegue el acceso a la red desde Internet y a todas las demás subredes de todas
las redes virtuales, excepto a la subred Private de la red virtual myVirtualNetwork.
1. En la opción Configuración de la cuenta de almacenamiento, seleccione Firewalls and vir tual networks
(Firewalls y redes virtuales).
2. Seleccione Redes seleccionadas .
3. Seleccione +Agregar red vir tual existente .
4. En Agregar redes , seleccione los siguientes valores y haga clic en Agregar :

C O N F IGURA C IÓ N VA L UE

Subscription Seleccione su suscripción.

Redes virtuales Seleccione myVir tualNetwork en Redes vir tuales

Subredes Seleccione Privada en Subredes

5. Seleccione Guardar .
6. Cierre el cuadro Firewalls and vir tual networks (Firewalls y redes virtuales).
7. En la opción Configuración de la cuenta de almacenamiento, seleccione Claves de acceso , tal y como se
muestra en la siguiente ilustración:
8. Anote el valor del campo Clave , ya que tendrá que escribirlo manualmente más adelante, cuando asigne el
recurso compartido de archivos a una letra de unidad de una máquina virtual.

Creación de máquinas virtuales

Para probar el acceso de la red a una cuenta de almacenamiento, implemente una máquina virtual en cada subred.
Creación de la primera máquina virtual
1. Seleccione + Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Compute y, después, seleccione Windows Ser ver 2016 Datacenter .
3. Especifique o seleccione los siguientes datos y haga clic en Aceptar :

C O N F IGURA C IÓ N VA L UE

Nombre myVmPublic

Nombre de usuario Escriba un nombre de usuario de su elección.

Contraseña Escriba una contraseña de su elección. La contraseña debe

tener al menos 12 caracteres de largo y cumplir con los
requisitos de complejidad definidos.

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y, a continuación,

myResourceGroup .

Location Seleccione Este de EE. UU .

4. Seleccione un tamaño para la máquina virtual y luego Seleccionar .
5. En Configuración , seleccione Red y haga clic en myVir tualNetwork . Seleccione Subred y Público , tal y
como se muestra en la ilustración siguiente:
6. En Grupo de seguridad de red , seleccione Avanzado . El portal crea automáticamente un grupo de
seguridad de red que permite el puerto 3389, que debe estar abierto para conectarse a la máquina virtual en
un paso posterior. Seleccione Aceptar en la página Configuración .
7. En la página Resumen , seleccione Crear para iniciar la implementación de la máquina virtual. La máquina
virtual tarda unos minutos en implementarse, pero puede continuar con el paso siguiente mientras se crea.
Creación de la segunda máquina virtual
Repita los pasos 1 a 7, pero, en el paso 3, llame a la máquina virtual myVmPrivate y, en el paso 5, seleccione la
subred Privada .
La maquina virtual tarda unos minutos en implementarse. No avance al paso siguiente hasta que finalice el proceso
y la configuración se abra en el portal.

Confirmación del acceso a la cuenta de almacenamiento

1. Cuando la máquina virtual myVmPrivate termine de crearse, Azure abrirá sus opciones de configuración.
Conéctese a la máquina virtual seleccionando el botón Conectar , tal y como se muestra en la imagen
siguiente:
2. Cuando seleccione el botón Conectar , se creará un archivo de Protocolo de Escritorio remoto (.rdp) y se
descargará en el equipo.
3. Abra el archivo .rdp descargado. Cuando se le pida, seleccione Conectar . Escriba el nombre de usuario y la
contraseña que especificó al crear la máquina virtual. Puede que deba seleccionar More choices (Más
opciones) y, luego, Use a different account (Usar una cuenta diferente), para especificar las credenciales
que escribió al crear la máquina virtual.
4. Seleccione Aceptar .
5. Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Si recibe la advertencia,
seleccione Sí o Continuar para continuar con la conexión.
6. En la máquina virtual myVmPrivate, asigne el recurso compartido de archivos de Azure a la unidad Z con
PowerShell. Antes de ejecutar los comandos que siguen, reemplace <storage-account-key> y
<storage-account-name> por los valores que proporcionó y recuperó en Creación de una cuenta de
almacenamiento.

$acctKey = ConvertTo-SecureString -String "<storage-account-key>" -AsPlainText -Force

$credential = New-Object [Link] -ArgumentList "Azure\<storage-
account-name>", $acctKey
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storage-account-name>.[Link]\my-
file-share" -Credential $credential

PowerShell devuelve una salida similar a la del ejemplo siguiente:

Name Used (GB) Free (GB) Provider Root

---- --------- --------- -------- ----
Z FileSystem \\[Link]\my-f...

El recurso compartido de archivos de Azure se ha asignado correctamente a la unidad Z.

7. Confirme que la máquina virtual no tiene conectividad de salida a Internet desde un símbolo del sistema:

ping [Link]

Dado que el grupo de seguridad de red asociado a la subred Private no permite el acceso de salida a Internet,
no recibirá ninguna respuesta.
8. Cierre la sesión de Escritorio remoto a la máquina virtual myVmPrivate.

Confirmación de la denegación del acceso a la cuenta de

almacenamiento
1. En el cuadro Search resources, services, and docs (Buscar recursos, servicios y documentos) que encontrará
en la parte superior del portal, escriba myVmPublic .
2. Cuando aparezca myVmPublic en los resultados de búsqueda, selecciónelo.
3. Siga los pasos 1 a 6 que se indican en Confirmación del acceso a la cuenta de almacenamiento con la
máquina virtual myVmPublic.
Tras una breve espera, recibirá un error New-PSDrive : Access is denied . El acceso se deniega porque la
máquina virtual myVmPublic está implementada en la subred Public. La subred Public no tiene un punto de
conexión de servicio habilitado para Azure Storage. La cuenta de almacenamiento solo permite el acceso a la
red desde la subred Private, no desde la subred Public.
4. Cierre la sesión de Escritorio remoto a la máquina virtual myVmPublic.
5. En el equipo, vaya a Azure Portal.
6. Escriba el nombre de la cuenta de almacenamiento que creó en el cuadro Search resources, ser vices,
and docs (Buscar recursos, servicios y documentos). Cuando el nombre de la cuenta de almacenamiento
aparezca en los resultados de búsqueda, selecciónelo.
7. Seleccione Archivos .
8. Aparecerá el error que se muestra en la siguiente ilustración:

El acceso se deniega porque el equipo no se encuentra en la subred Privada de la red virtual

MyVirtualNetwork.

Limpieza de recursos
Cuando ya no sea necesario, elimine el grupo de recursos y todos los recursos que contiene:
1. Escriba myResourceGroup en el cuadro Buscar que se encuentra en la parte superior del portal. Seleccione
myResourceGroup cuando lo vea en los resultados de la búsqueda.
2. Seleccione Eliminar grupo de recursos .
3. Escriba myResourceGroup para ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS: y seleccione Eliminar .

Pasos siguientes
En este tutorial, ha habilitado un punto de conexión de servicio en una subred de la red virtual. Ha aprendido que
puede habilitar puntos de conexión de servicio para los recursos implementados desde varios servicios de Azure.
Ha creado una cuenta de Azure Storage y ha restringido el acceso de la red a la cuenta de almacenamiento que se
encuentra en una subred de la red virtual. Para más información acerca de los puntos de conexión de servicio,
consulte Introducción a los puntos de conexión de un servicio y Administración de subredes.
Si tiene varias redes virtuales en la cuenta, es posible que desee conectar dos de ellas para que los recursos que
están dentro de cada red virtual puedan comunicarse entre sí. Para aprender a conectar redes virtuales, pase al
siguiente tutorial.
Conexión de redes virtuales
 Tutorial: Conexión de redes virtuales con
emparejamiento de redes virtuales usando Azure
Portal
23/09/2020 • 11 minutes to read • Edit Online

Puede conectar redes virtuales entre sí con el emparejamiento de redes virtuales. Estas redes virtuales pueden
estar en la misma región o en regiones diferentes (también conocidas como emparejamiento de VNET global).
Una vez que las redes virtuales están emparejadas, los recursos de ambas se pueden comunicar entre sí con el
mismo ancho de banda y la misma latencia que si estuvieran en la misma red virtual. En este tutorial, aprenderá a:
Crear dos redes virtuales
Conectar dos redes virtuales con el emparejamiento de redes virtuales
Implementar una máquina virtual (VM) en cada red virtual
Comunicarse entre máquinas virtuales
Si lo prefiere, puede completar este tutorial con la CLI de Azure o Azure PowerShell.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Inicio de sesión en Azure

Inicie sesión en Azure Portal en [Link]

Creación de redes virtuales

1. En Azure Portal, seleccione Crear un recurso .
2. Seleccione Redes y Red vir tual .
3. En la pestaña Fundamentos , escriba o seleccione la siguiente información y acepte los valores
predeterminados en las siguientes opciones:

C O N F IGURA C IÓ N VA L UE

Subscription Seleccione su suscripción.

Resource group Haga clic en Crear nuevo y escriba myResourceGroup.

Region Seleccione Este de EE. UU .

Nombre myVirtualNetwork1

4. En la pestaña Direcciones IP , escriba [Link]/16 en el campo Espacio de direcciones . Haga clic en el

botón Agregar subred que aparece a continuación y escriba Subnet1 en Nombre de subred y
[Link]/24 en Inter valo de direcciones de subred .
5. Seleccione Revisar y crear y, luego, Crear .
6. Complete de nuevo los pasos del 1 al 5, con los cambios siguientes:
 C O N F IGURA C IÓ N VA L UE

Nombre myVirtualNetwork2

Espacio de direcciones [Link]/16

Resource group Seleccione Usar existente y después seleccione

myResourceGroup .

Nombre de subred Subnet2

Intervalo de direcciones de subred [Link]/24

Emparejamiento de redes virtuales

1. En el cuadro Búsqueda que se encuentra en la parte superior de Azure Portal, escriba MyVirtualNetwork1.
Cuando la opción myVir tualNetwork1 aparezca en los resultados de la búsqueda, selecciónela.
2. Seleccione Emparejamientos , seleccione Configuración y, luego, seleccione Agregar , como se muestra
en la imagen siguiente:

3. Escriba o seleccione la siguiente información, acepte los valores predeterminados para el resto de la
configuración y luego seleccione Aceptar .

C O N F IGURA C IÓ N VA L UE

Nombre del emparejamiento de myVirtualNetwork1 a la myVirtualNetwork1-myVirtualNetwork2: la primera vez

red virtual remota que se cargue la página, verá aquí la frase "remote virtual
network" (red virtual remota). Después de elegir la red
virtual remota, la frase "remote virtual network" (red
virtual remota) se reemplazará por el nombre de la red
virtual remota.

Subscription Seleccione su suscripción.

Virtual network myVirtualNetwork2: para seleccionar la red virtual

myVirtualNetwork2, seleccione Red vir tual y, después,
myVir tualNetwork2 (myResourceGroup) . Puede
seleccionar una red virtuales de la misma región o de
otra.
 C O N F IGURA C IÓ N VA L UE

Nombre del emparejamiento de myVirtualNetwork2 con myVirtualNetwork2-myVirtualNetwork1

myVirtualNetwork1

El ESTADO DE EMPAREJAMIENTO es Conectado, como se muestra en la siguiente imagen:

Si no ve el estado, actualice el explorador.

Creación de máquinas virtuales

Cree una máquina virtual en cada red virtual para que puedan comunicarse entre ellas en un paso posterior.
Creación de la primera máquina virtual
1. En Azure Portal, seleccione Crear un recurso .
2. Seleccione Compute y, después, seleccione Windows Ser ver 2016 Datacenter . Puede seleccionar otro
sistema operativo, pero en los pasos restantes se supone que seleccionó Windows Ser ver 2016
Datacenter .
3. Escriba o seleccione la siguiente información para Aspectos básicos , acepte los valores predeterminados
para el resto de la configuración y luego seleccione Crear :

C O N F IGURA C IÓ N VA L UE

Resource group Seleccione Usar existente y después seleccione

myResourceGroup .

Nombre myVm1
 C O N F IGURA C IÓ N VA L UE

Location Seleccione Este de EE. UU .

Nombre de usuario Escriba un nombre de usuario de su elección.

Contraseña Escriba una contraseña de su elección. La contraseña debe

tener al menos 12 caracteres de largo y cumplir con los
requisitos de complejidad definidos.

4. Seleccione un tamaño de máquina virtual para la opción Tamaño .

5. Seleccione los valores siguientes en Redes :

C O N F IGURA C IÓ N VA L UE

Virtual network myVirtualNetwork1: si no está ya seleccionado, seleccione

Red vir tual y, luego, myVir tualNetwork1 .

Subnet Subnet1: si aún no está seleccionado, seleccione Subred

y, después, Subnet1 .

6. Seleccionar Redes . Elija Permitir los puer tos seleccionados en la opción Puer tos de entrada
públicos . Elija RDP para la opción Seleccionar puer tos de entrada debajo de esto.
7. Seleccione el botón Revisar y crear en la esquina inferior izquierda para iniciar la implementación de la
máquina virtual.
Creación de la segunda máquina virtual
Complete de nuevo los pasos del 1 al 6, con los cambios siguientes:

C O N F IGURA C IÓ N VA L UE

Nombre myVm2

Virtual network myVirtualNetwork2

Las máquinas virtuales tardan unos minutos en crearse. No siga con los pasos restantes hasta que se creen ambas
máquinas virtuales.

Comunicarse entre máquinas virtuales

1. En el cuadro Búsqueda que se encuentra en la parte superior del portal, escriba myVm1. Seleccione
MyVm1 cuando aparezca en los resultados de búsqueda.
2. Cree una conexión a Escritorio remoto a la máquina virtual myVm1 seleccionando Conectar , tal como se
indica en la imagen siguiente:
3. Para conectarse a la máquina virtual, abra el archivo RDP descargado. Cuando se le pida, seleccione
Conectar .
4. Escriba el nombre de usuario y la contraseña que especificó al crear la máquina virtual (puede que deba
seleccionar Más opciones y luego Usar una cuenta diferente , para especificar las credenciales que
escribió cuando creó la máquina virtual). A continuación, seleccione Aceptar .
5. Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Seleccione Sí para
continuar con la conexión.
6. En un paso posterior, se usa ping para comunicarse con la máquina virtual myVm2 desde la máquina
virtual myVm1. Ping usa el Protocolo de mensajes de control de Internet (ICMP) que, de forma
predeterminada, se deniega a través del Firewall de Windows. En la máquina virtual myVm1, habilite IMCP
a través del Firewall de Windows para que pueda hacer ping en esta máquina virtual desde myVm2 en un
paso posterior, mediante PowerShell:

New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4

Aunque en este tutorial se usa ping para comunicarse entre máquinas virtuales, no se recomienda permitir
que ICMP atraviese el Firewall de Windows en implementaciones de producción.
7. Para conectar con la máquina virtual myVm2, escriba el siguiente comando desde el símbolo del sistema
en la máquina virtual myVm1:

mstsc /v:[Link]

8. Puesto que ha habilitado ping en myVm1, ahora puede hacer ping a él por dirección IP:

ping [Link]

9. Desconecte las sesiones RDP para ambos myVm1 y myVm2.

Limpieza de recursos
Cuando ya no sea necesario, elimine el grupo de recursos y todos los recursos que contiene:
1. Escriba myResourceGroup en el cuadro Buscar que se encuentra en la parte superior del portal. Seleccione
myResourceGroup cuando lo vea en los resultados de la búsqueda.
2. Seleccione Eliminar grupo de recursos .
3. Escriba myResourceGroup para ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS: y seleccione Eliminar .
Pasos siguientes
En este tutorial, ha aprendido a conectar dos redes de la misma región de Azure con el emparejamiento de redes
virtuales. También puede emparejar redes virtuales de distintas regiones compatibles y en distintas suscripciones
de Azure, además de crear diseños de red de concentrador y radio con emparejamiento. Para más información
sobre el emparejamiento de redes virtuales, consulte los artículos sobre el emparejamiento de redes virtuales y la
administración de emparejamientos de redes virtuales.
Para conectar su propio equipo con una red virtual a través de una VPN e interactuar con recursos en una red
virtual, o en redes virtuales emparejadas, consulte Conexión de un equipo a una red virtual.
 Tutorial: Creación de una puerta de enlace de NAT
mediante Azure Portal
23/09/2020 • 12 minutes to read • Edit Online

En este tutorial se muestra cómo usar el servicio Azure Virtual Network NAT. Creará una puerta de enlace de NAT
para proporcionar conectividad saliente para una máquina virtual en Azure.
Si lo prefiere, puede seguir estos pasos con la CLI de Azure, Azure PowerShell o implemente una plantilla ARM en
lugar del portal.

Inicio de sesión en Azure

Inicie sesión en Azure Portal.

Red virtual y parámetros

Antes de implementar una máquina virtual y usar la puerta de enlace de NAT, es necesario crear el grupo de
recursos y la red virtual.
En los pasos de esta sección, tendrá que reemplazar los siguientes parámetros por la siguiente información:

PA RÁ M ET RO VA L UE

<resource-group-name> myResourceGroupNAT

<vir tual-network-name> myVNet

<region-name> Este de EE. UU. 2

<IPv4-address-space> [Link]\16

<subnet-name> mySubnet

<subnet-address-range> [Link]\24

Crear la red virtual

En esta sección, creará una red virtual y una subred.
1. En la parte superior izquierda de la pantalla, seleccione Crear un recurso > Redes > Red vir tual o
busque Red vir tual en el cuadro de búsqueda.
2. En Crear red vir tual , escriba o seleccione esta información en la pestaña Conceptos básicos :

C O N F IGURA C IÓ N VA LO R

Detalles del proyecto

Suscripción Selección de su suscripción a Azure

 C O N F IGURA C IÓ N VA LO R

Grupo de recursos Seleccione Crear nuevo , escriba <resource-group-

name> , seleccione Aceptar o seleccione un <resource-
group-name> existente basado en parámetros.

Detalles de instancia

Nombre Escriba <vir tual-network-name>

Region Selección de <region-name>

3. Seleccione la pestaña Direcciones IP o el botón Siguiente: Direcciones IP situado en la parte inferior

de la página.
4. En la pestaña Direcciones IP , especifique esta información:

C O N F IGURA C IÓ N VA L UE

Espacio de direcciones IPv4 Escriba <IPv4-address-space>

5. En Nombre de subred , seleccione la palabra predeterminada .

6. En Editar subred , especifique esta información:

C O N F IGURA C IÓ N VA L UE

Nombre de subred Escriba <subnet-name>

Intervalo de direcciones de subred Escriba <subnet-address-range>

7. Seleccione Guardar .
8. Seleccione la pestaña Revisar y crear o el botón Revisar y crear .
9. Seleccione Crear .

Creación de una máquina virtual para usar la puerta de enlace de NAT

Ahora se va a crear una máquina virtual para usar el servicio NAT. Esta máquina virtual tiene una dirección IP
pública en el nivel de instancia que le permite el acceso a la máquina virtual. El servicio NAT tiene en cuenta la
dirección del flujo y reemplazará el destino predeterminado de Internet en la subred. La dirección IP pública de la
máquina virtual no se usará para las conexiones salientes.
1. En la parte superior izquierda del portal, seleccione Crear un recurso > Proceso > Ubuntu
Ser ver 18.04 LTS , o busque Ubuntu Ser ver 18.04 LTS en el cuadro de búsqueda de Marketplace.
2. En Crear una máquina vir tual , escriba o seleccione los valores siguientes en la pestaña Básico :
Suscripción > Grupo de recursos : Seleccione myResourceGroupNAT .
Detalles de instancia > Nombre de máquina vir tual : Escriba myVM .
Detalles de instancia > Región > seleccione Este de EE. UU. 2 .
Cuenta de administrador > Tipo de autenticación : Seleccione Contraseña .
Cuenta de administrador > escriba la información de Nombre de usuario , Contraseña y
Confirmar contraseña .
 Reglas de puer to de entrada > Puer tos de entrada públicos : Seleccione Permitir los puer tos
seleccionados .
Reglas de puer to de entrada > Seleccionar puer tos de entrada : Seleccione SSH (22) .
Seleccione la pestaña Redes o seleccione Siguiente: Discos y, después, Siguiente: Redes .
3. En la pestaña Redes , asegúrese de que está seleccionado lo siguiente:
Red vir tual : myVnet
Subred : mySubnet
Dirección IP pública > seleccione Crear nueva . En la ventana Crear dirección IP pública , escriba
myPublicIPVM en el campo Nombre y elija Estándar para la SKU . Haga clic en OK .
Grupo de seguridad de red de NIC : Seleccione Básica .
Puer tos de entrada públicos : Seleccione Permitir los puer tos seleccionados .
Seleccionar puer tos de entrada : Confirme que SSH está seleccionado.
4. En la pestaña Administración , en Super visión , establezca Diagnósticos de arranque en
Desactivado .
5. Seleccione Revisar + crear .
6. Revise la configuración y haga clic en Crear .

Creación de la puerta de enlace de NAT

Puede usar uno o varios recursos de dirección IP pública, prefijos de dirección IP pública, o ambos. Se agregará
un recurso de dirección IP pública, un prefijo de dirección IP pública y un recurso de puerta de enlace de NAT.
En esta sección se detalla cómo crear y configurar los componentes siguientes del servicio NAT mediante el
recurso de puerta de enlace de NAT:
Un grupo de direcciones IP públicas y un prefijo de dirección IP pública que se usarán en los flujos salientes
traducidos por el recurso de puerta de enlace de NAT.
Cambie el tiempo de espera de inactividad de 4 (el valor predeterminado) a 10 minutos.
Crear una dirección IP pública
1. En la parte superior izquierda del portal, seleccione Crear un recurso > Redes > Dirección IP pública ,
o busque Dirección IP pública en el cuadro de búsqueda de Marketplace.
2. En Crear dirección IP pública , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Versión de la dirección IP Seleccione IPv4 .

SKU Seleccione Estándar .

Nombre Escriba myPublicIP .

Suscripción Seleccione su suscripción.

Resource group Seleccione myResourceGroupNAT .

Location Seleccione Este de EE. UU. 2 .

3. Deje el resto de valores predeterminados y seleccione Crear .

Creación de un prefijo de dirección IP pública
1. En la parte superior izquierda del portal, seleccione Crear un recurso > Redes > Prefijo de dirección
IP pública , o busque Prefijo de dirección IP pública en el cuadro de búsqueda de Marketplace.
2. En Crear un prefijo de dirección IP pública , escriba o seleccione los valores siguientes en la pestaña
Aspectos básicos :
Suscripción > Grupo de recursos : Selección de myResourceGroupNAT >
Detalles de instancia > Nombre : Escriba myPublicIPprefix .
Detalles de instancia > Región : Seleccione Este de EE. UU. 2 .
Detalles de instancia > Tamaño del prefijo : seleccione /31 (2 direcciones) .
3. Deje el resto de valores predeterminados y seleccione Revisar y crear .
4. Revise la configuración y, a continuación, seleccione Crear .
Creación de un recurso de puerta de enlace de NAT
1. En la parte superior izquierda del portal, seleccione Crear un recurso > Redes > puer ta de enlace de
NAT , o busque puer ta de enlace de NAT en el cuadro de búsqueda de Marketplace.
2. En Crear puer ta de enlace de traducción de direcciones de red (NAT) , escriba o seleccione los
valores siguientes en la pestaña Aspectos básicos :
Suscripción > Grupo de recursos : Seleccione myResourceGroupNAT .
Detalles de instancia > Nombre de puer ta de enlace de NAT : Escriba myNATgateway .
Detalles de instancia > Región : Seleccione Este de EE. UU. 2 .
Detalles de instancia > Tiempo de espera de inactividad (minutos) : escriba 10 .
Seleccione la pestaña IP pública o seleccione Siguiente: IP pública .
3. En la pestaña IP pública , escriba o seleccione los valores siguientes:
Direcciones IP públicas : seleccione myPublicIP .
Prefijos de direcciones IP públicas : seleccione myPublicIPprefix .
Seleccione la pestaña Subred o seleccione Siguiente: Subred .
4. En la pestaña Subred , escriba o seleccione los siguientes valores:
Red vir tual : seleccione myResourceGroupNAT > myVnet .
Nombre de subred : active la casilla junto a mySubnet .
5. Seleccione Revisar + crear .
6. Revise la configuración y, a continuación, seleccione Crear .

Detección de la dirección IP de la máquina virtual

1. En el lado izquierdo del portal, seleccione Grupos de recursos .
2. Seleccione myResourceGroupNAT .
3. Seleccione myVM .
4. En Información general , copie el valor de Dirección IP pública y péguelo en el Bloc de notas para que
pueda usarlo para acceder a la máquina virtual.

IMPORTANT
Copie la dirección IP pública y, luego, péguela en un bloc de notas para que pueda usarla para acceder a la máquina virtual.

Inicio de sesión en la máquina virtual

Abra Azure Cloud Shell en el explorador. Use la dirección IP recuperada en el paso anterior para conectarse a la
máquina virtual mediante SSH.

ssh <username>@<ip-address-destination>

Ahora está listo para usar el servicio NAT.

Limpieza de recursos
Cuando ya no los necesite, elimine el grupo de recursos, la puerta de enlace de NAT y todos los recursos
relacionados. Seleccione el grupo de recursos myResourceGroupNAT que contiene la puerta de enlace de NAT
y, luego, seleccione Eliminar .

Pasos siguientes
En este tutorial, ha creado una puerta de enlace de NAT y una máquina virtual para usarla.
Revise las métricas de Azure Monitor para ver el funcionamiento del servicio NAT. Diagnostique problemas como
el agotamiento de recursos de los puertos SNAT disponibles. El agotamiento de recursos de los puertos SNAT se
soluciona agregando recursos de dirección IP pública o recursos de prefijo de dirección IP pública adicionales (o
ambos).
Obtenga más información sobre Azure Virtual Network NAT.
Más información sobre recursos de puerta de enlace de NAT.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con la CLI de Azure.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con PowerShell.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con Azure Portal.
 Tutorial: Creación de una puerta de enlace de NAT
mediante Azure Portal y prueba del servicio NAT
23/09/2020 • 24 minutes to read • Edit Online

En este tutorial, creará una puerta de enlace de NAT para proporcionar conectividad saliente a las máquinas
virtuales de Azure. Para probar la puerta de enlace de NAT, implemente una máquina virtual de origen y destino. La
prueba de la puerta de enlace de NAT se realizará mediante conexiones salientes a una dirección IP pública desde la
máquina virtual de origen a la de destino. Para simplificar las cosas, en este tutorial se implementan el origen y el
destino en dos redes virtuales diferentes del mismo grupo de recursos.
Si lo prefiere, puede seguir estos pasos con la CLI de Azure o Azure PowerShell en lugar del portal.

Inicio de sesión en Azure

Inicie sesión en Azure Portal.

Preparación del origen para el tráfico saliente

Le guiaremos a través de la configuración de un entorno de prueba completo y la ejecución de las pruebas en los
siguientes pasos. Comenzaremos con el origen, que usará el recurso de la puerta de enlace de NAT que se creará
posteriormente.

Red virtual y parámetros

Antes de implementar una máquina virtual y usar la puerta de enlace de NAT, es necesario crear el grupo de
recursos y la red virtual.
En los pasos de esta sección, tendrá que reemplazar los siguientes parámetros por la siguiente información:

PA RÁ M ET RO VA L UE

<resource-group-name> myResourceGroupNAT

<vir tual-network-name> myVNetsource

<region-name> Este de EE. UU. 2

<IPv4-address-space> [Link]/16

<subnet-name> mySubnetsource

<subnet-address-range> [Link]/24

Crear la red virtual

En esta sección, creará una red virtual y una subred.
1. En la parte superior izquierda de la pantalla, seleccione Crear un recurso > Redes > Red vir tual o
busque Red vir tual en el cuadro de búsqueda.
2. En Crear red vir tual , escriba o seleccione esta información en la pestaña Conceptos básicos :

C O N F IGURA C IÓ N VA LO R

Detalles del proyecto

Suscripción Selección de su suscripción a Azure

Grupo de recursos Seleccione Crear nuevo , escriba <resource-group-

name> , seleccione Aceptar o seleccione un <resource-
group-name> existente basado en parámetros.

Detalles de instancia

Nombre Escriba <vir tual-network-name>

Region Selección de <region-name>

3. Seleccione la pestaña Direcciones IP o el botón Siguiente: Direcciones IP situado en la parte inferior de

la página.
4. En la pestaña Direcciones IP , especifique esta información:

C O N F IGURA C IÓ N VA L UE

Espacio de direcciones IPv4 Escriba <IPv4-address-space>

5. En Nombre de subred , seleccione la palabra predeterminada .

6. En Editar subred , especifique esta información:

C O N F IGURA C IÓ N VA L UE

Nombre de subred Escriba <subnet-name>

Intervalo de direcciones de subred Escriba <subnet-address-range>

7. Seleccione Guardar .
8. Seleccione la pestaña Revisar y crear o el botón Revisar y crear .
9. Seleccione Crear .

Creación de la máquina virtual de origen

Ahora se va a crear una máquina virtual para usar el servicio NAT. Esta máquina virtual tiene una dirección IP
pública en el nivel de instancia que le permite el acceso a la máquina virtual. El servicio NAT tiene en cuenta la
dirección del flujo y reemplazará el destino predeterminado de Internet en la subred. La dirección IP pública de la
máquina virtual no se usará para las conexiones salientes.
Para probar la puerta de enlace de NAT, asignaremos un recurso de dirección IP pública como una IP pública de
nivel de instancia para acceder a esta máquina virtual desde el exterior. Esta dirección solo se usa para el acceso de
prueba. Se va a demostrar cómo el servicio NAT tiene prioridad sobre otras opciones de salida.
Como ejercicio, también puede crear esta máquina virtual sin una dirección IP pública y crear otra máquina virtual
para usarla como Jumpbox sin una dirección IP pública.
1. En la parte superior izquierda del portal, seleccione Crear un recurso > Proceso > Ubuntu
Ser ver 18.04 LTS , o busque Ubuntu Ser ver 18.04 LTS en el cuadro de búsqueda de Marketplace.
2. En Crear una máquina vir tual , escriba o seleccione los valores siguientes en la pestaña Básico :
Suscripción > Grupo de recursos : Seleccione myResourceGroupNAT .
Detalles de instancia > Nombre de máquina vir tual : escriba myVMsource .
Detalles de instancia > Región > seleccione Este de EE. UU. 2 .
Cuenta de administrador > Autenticación : Seleccione Contraseña .
Cuenta de administrador > escriba la información de Nombre de usuario , Contraseña y
Confirmar contraseña .
Reglas de puer to de entrada > Puer tos de entrada públicos : Seleccione Permitir los puer tos
seleccionados .
Reglas de puer to de entrada > Seleccionar puer tos de entrada : Seleccione SSH (22) .
Seleccione la pestaña Redes o seleccione Siguiente: Discos y, después, Siguiente: Redes .
3. En la pestaña Redes , asegúrese de que está seleccionado lo siguiente:
Red vir tual : myVnetsource
Subred : mySubnetsource
Dirección IP pública > seleccione Crear nueva . En la ventana Crear dirección IP pública , escriba
myPublicIPsourceVM en el campo Nombre . Seleccione Estándar para la SKU . Deje el resto de
valores predeterminados y haga clic en Aceptar .
Grupo de seguridad de red de NIC : Seleccione Básica .
Puer tos de entrada públicos : Seleccione Permitir los puer tos seleccionados .
Seleccionar puer tos de entrada : Confirme que SSH está seleccionado.
4. En la pestaña Administración , en Super visión , establezca Diagnósticos de arranque en Desactivado .
5. Seleccione Revisar + crear .
6. Revise la configuración y haga clic en Crear .

Creación de la puerta de enlace de NAT

Puede usar uno o varios recursos de dirección IP pública o prefijos de IP pública (o ambos) con la puerta de enlace
de NAT. Se agregará un recurso de IP pública, un prefijo de dirección IP pública y un recurso de puerta de enlace de
NAT.
En esta sección se detalla cómo crear y configurar los componentes siguientes del servicio NAT mediante el recurso
de puerta de enlace de NAT:
Un grupo de direcciones IP públicas y un prefijo de dirección IP pública que se usarán en los flujos salientes
traducidos por el recurso de puerta de enlace de NAT.
Cambie el tiempo de espera de inactividad de 4 (el valor predeterminado) a 10 minutos.
Crear una dirección IP pública
1. En la parte superior izquierda del portal, seleccione Crear un recurso > Redes > Dirección IP pública , o
busque Dirección IP pública en el cuadro de búsqueda de Marketplace.
2. En Crear dirección IP pública , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Versión de la dirección IP Seleccione IPv4 .

 C O N F IGURA C IÓ N VA L UE

SKU Seleccione Estándar .

Nombre Escriba myPublicIPsource .

Suscripción Seleccione su suscripción.

Resource group Seleccione myResourceGroupNAT .

Location Seleccione Este de EE. UU. 2 .

3. Deje el resto de valores predeterminados y seleccione Crear .

Creación de un prefijo de dirección IP pública
1. En la parte superior izquierda del portal, seleccione Crear un recurso > Redes > Prefijo de dirección IP
pública , o busque Prefijo de dirección IP pública en el cuadro de búsqueda de Marketplace.
2. En Crear un prefijo de dirección IP pública , escriba o seleccione los valores siguientes en la pestaña
Básico :
Suscripción > Grupo de recursos : Seleccione myResourceGroupNAT >.
Detalles de instancia > Nombre : escriba myPublicIPprefixsource .
Detalles de instancia > Región : Seleccione Este de EE. UU. 2 .
Detalles de instancia > Tamaño del prefijo : seleccione /31 (2 direcciones) .
3. Deje el resto de valores predeterminados y seleccione Revisar y crear .
4. Revise la configuración y, a continuación, seleccione Crear .
Creación de un recurso de puerta de enlace de NAT
1. En la parte superior izquierda del portal, seleccione Crear un recurso > Redes > puer ta de enlace de
NAT , o busque puer ta de enlace de NAT en el cuadro de búsqueda de Marketplace.
2. En Crear puer ta de enlace de traducción de direcciones de red (NAT) , escriba o seleccione los
siguientes valores en la pestaña Básico :
Suscripción > Grupo de recursos : Seleccione myResourceGroupNAT .
Detalles de instancia > Nombre de puer ta de enlace de NAT : escriba myNATgateway .
Detalles de instancia > Región : Seleccione Este de EE. UU. 2 .
Detalles de instancia > Tiempo de espera de inactividad (minutos) : escriba 10 .
Seleccione la pestaña IP pública o seleccione Siguiente: IP pública .
3. En la pestaña IP pública , escriba o seleccione los siguientes valores:
Direcciones IP públicas : Seleccione myPublicIPsource .
Prefijos de direcciones IP públicas : Seleccione myPublicIPprefixsource .
Seleccione la pestaña Subred o seleccione Siguiente: Subred .
4. En la pestaña Subred , escriba o seleccione los siguientes valores:
Red vir tual : Seleccione myResourceGroupNAT > myVnetsource .
Nombre de subred : Active la casilla situada junto a mySubnetsource .
5. Seleccione Revisar + crear .
6. Revise la configuración y, a continuación, seleccione Crear .
Todo el tráfico saliente a destinos de Internet usa ahora el servicio NAT. No es necesario configurar una UDR.

Preparación del destino para el tráfico saliente

Ahora se va a crear un destino para el tráfico saliente traducido por el servicio NAT para que pueda probarlo.

Red virtual y parámetros para el destino

Antes de implementar una máquina virtual como destino, es necesario crear una red virtual donde pueda residir
esta máquina. Los siguientes pasos son los mismos que para la máquina virtual de origen con algunos pequeños
cambios para exponer el punto de conexión de destino.
En los pasos de esta sección, tendrá que reemplazar los siguientes parámetros por la siguiente información:

PA RÁ M ET RO VA L UE

<resource-group-name> myResourceGroupNAT

<vir tual-network-name> myVNetdestination

<region-name> Este de EE. UU. 2

<IPv4-address-space> [Link]/16

<subnet-name> mySubnetdestination

<subnet-address-range> [Link]/24

Crear la red virtual

En esta sección, creará una red virtual y una subred.
1. En la parte superior izquierda de la pantalla, seleccione Crear un recurso > Redes > Red vir tual o
busque Red vir tual en el cuadro de búsqueda.
2. En Crear red vir tual , escriba o seleccione esta información en la pestaña Conceptos básicos :

C O N F IGURA C IÓ N VA LO R

Detalles del proyecto

Suscripción Selección de su suscripción a Azure

Grupo de recursos Seleccione Crear nuevo , escriba <resource-group-

name> , seleccione Aceptar o seleccione un <resource-
group-name> existente basado en parámetros.

Detalles de instancia

Nombre Escriba <vir tual-network-name>

Region Selección de <region-name>

3. Seleccione la pestaña Direcciones IP o el botón Siguiente: Direcciones IP situado en la parte inferior de

la página.
4. En la pestaña Direcciones IP , especifique esta información:

C O N F IGURA C IÓ N VA L UE

Espacio de direcciones IPv4 Escriba <IPv4-address-space>

5. En Nombre de subred , seleccione la palabra predeterminada .

6. En Editar subred , especifique esta información:

C O N F IGURA C IÓ N VA L UE

Nombre de subred Escriba <subnet-name>

Intervalo de direcciones de subred Escriba <subnet-address-range>

7. Seleccione Guardar .
8. Seleccione la pestaña Revisar y crear o el botón Revisar y crear .
9. Seleccione Crear .

Creación de la máquina virtual de destino

1. En la parte superior izquierda del portal, seleccione Crear un recurso > Proceso > Ubuntu
Ser ver 18.04 LTS , o busque Ubuntu Ser ver 18.04 LTS en el cuadro de búsqueda de Marketplace.
2. En Crear una máquina vir tual , escriba o seleccione los valores siguientes en la pestaña Básico :
Suscripción > Grupo de recursos : Seleccione myResourceGroupNAT .
Detalles de instancia > Nombre de máquina vir tual : escriba myVMdestination .
Detalles de instancia > Región > seleccione Este de EE. UU. 2 .
Cuenta de administrador > Autenticación : Seleccione Contraseña .
Cuenta de administrador > escriba la información de Nombre de usuario , Contraseña y
Confirmar contraseña .
Reglas de puer to de entrada > Puer tos de entrada públicos : Seleccione Permitir los puer tos
seleccionados .
Reglas de puer to de entrada > Seleccionar puer tos de entrada : Seleccione SSH (22) y HTTP
(80) .
Seleccione la pestaña Redes o seleccione Siguiente: Discos y, después, Siguiente: Redes .
3. En la pestaña Redes , asegúrese de que está seleccionado lo siguiente:
Red vir tual : myVnetdestination
Subred : mySubnetdestination
Dirección IP pública > seleccione Crear nueva . En la ventana Crear dirección IP pública , escriba
myPublicIPdestinationVM en el campo Nombre . Seleccione Estándar para la SKU . Deje el resto de
valores predeterminados y haga clic en Aceptar .
Grupo de seguridad de red de NIC : Seleccione Básica .
Puer tos de entrada públicos : Seleccione Permitir los puer tos seleccionados .
Seleccionar puer tos de entrada : Confirme que SSH y HTTP está seleccionado.
4. En la pestaña Administración , en Super visión , establezca Diagnósticos de arranque en Desactivado .
5. Seleccione Revisar + crear .
6. Revise la configuración y, a continuación, seleccione Crear .

Preparación de un servidor web y prueba de la carga en la máquina

virtual de destino
En primer lugar, es necesario detectar la dirección IP de la máquina virtual de destino.
1. En el lado izquierdo del portal, seleccione Grupos de recursos .
2. Seleccione myResourceGroupNAT .
3. Seleccione myVMdestination .
4. En Información general , copie el valor de Dirección IP pública y péguelo en el Bloc de notas para que
pueda usarlo para acceder a la máquina virtual.

IMPORTANT
Copie la dirección IP pública y, luego, péguela en un bloc de notas para que pueda usarla en pasos posteriores. Indique que
esta es la máquina virtual de destino.

Inicio de sesión en la máquina virtual de destino

Abra Azure Cloud Shell en el explorador. Use la dirección IP recuperada en el paso anterior para conectarse a la
máquina virtual mediante SSH.

ssh <username>@<ip-address-destination>

Una vez que haya iniciado sesión, copie y pegue los siguientes comandos.

sudo apt-get -y update && \

sudo apt-get -y upgrade && \
sudo apt-get -y dist-upgrade && \
sudo apt-get -y autoremove && \
sudo apt-get -y autoclean && \
sudo apt-get -y install nginx && \
sudo ln -sf /dev/null /var/log/nginx/[Link] && \
sudo touch /var/www/html/[Link] && \
sudo rm /var/www/html/[Link] && \
sudo dd if=/dev/zero of=/var/www/html/100k bs=1024 count=100

Estos comandos actualizarán la máquina virtual, instalarán Nginx y crearán un archivo de 100 Kbytes. Este archivo
se recuperará de la máquina virtual de origen mediante el servicio NAT.
Cierre la sesión SSH con la máquina virtual de destino.

Preparación de la prueba en la máquina virtual de origen

En primer lugar, es necesario detectar la dirección IP de la máquina virtual de origen.
1. En el lado izquierdo del portal, seleccione Grupos de recursos .
2. Seleccione myResourceGroupNAT .
3. Seleccione myVMsource .
4. En Información general , copie el valor de Dirección IP pública y péguelo en el Bloc de notas para que
pueda usarlo para acceder a la máquina virtual.
 IMPORTANT
Copie la dirección IP pública y, luego, péguela en un bloc de notas para que pueda usarla en pasos posteriores. Indique que
esta es la máquina virtual de origen.

Inicio de sesión en la máquina virtual de origen

Abra una nueva pestaña de Azure Cloud Shell en el explorador. Use la dirección IP recuperada en el paso anterior
para conectarse a la máquina virtual mediante SSH.

ssh <username>@<ip-address-source>

Copie y pegue los siguientes comandos para preparar la prueba del servicio NAT.

sudo apt-get -y update && \

sudo apt-get -y upgrade && \
sudo apt-get -y dist-upgrade && \
sudo apt-get -y autoremove && \
sudo apt-get -y autoclean && \
sudo apt-get install -y nload golang && \
echo 'export GOPATH=${HOME}/go' >> .bashrc && \
echo 'export PATH=${PATH}:${GOPATH}/bin' >> .bashrc && \
. ~/.bashrc &&
go get -u [Link]/rakyll/hey

Este comando actualizará la máquina virtual, instalará Go, instalará Hey de GitHub y actualizará el entorno de Shell.
Ahora está listo para probar el servicio NAT.

Validación del servicio NAT

Mientras ha iniciado sesión en la máquina virtual de origen, puede usar cURL y Hey para generar solicitudes a la
dirección IP de destino.
Use cURL para recuperar el archivo de 100 Kbytes. Reemplace <ip-address-destination> en el ejemplo siguiente
por la dirección IP de destino que copió anteriormente. El parámetro --output indica que se descartará el archivo
recuperado.

curl [Link] --output /dev/null

También puede generar una serie de solicitudes mediante Hey . Una vez más, reemplace <ip-address-
destination> por la dirección IP de destino que copió anteriormente.

hey -n 100 -c 10 -t 30 --disable-keepalive [Link]

Este comando generará 100 solicitudes, 10 de ellas a vez, con un tiempo de espera de 30 segundos y sin volver a
utilizar la conexión TCP. Cada solicitud recuperará 100 Kbytes. Al final de la ejecución, Hey notificará algunas
estadísticas sobre el rendimiento del servicio NAT.

Limpieza de recursos
Cuando ya no los necesite, elimine el grupo de recursos, la puerta de enlace de NAT y todos los recursos
relacionados. Seleccione el grupo de recursos myResourceGroupNAT que contiene la puerta de enlace de NAT y,
luego, seleccione Eliminar .

Pasos siguientes
En este tutorial, ha creado una puerta de enlace de NAT y una máquina virtual de origen y destino y, luego, ha
probado la puerta de enlace de NAT.
Revise las métricas de Azure Monitor para ver el funcionamiento del servicio NAT. Diagnostique problemas, como
el agotamiento de recursos de los puertos SNAT disponibles. El agotamiento de los recursos de los puertos SNAT se
soluciona fácilmente agregando recursos de dirección IP pública o recursos de prefijo de dirección IP pública
adicionales (o ambos).
Obtenga más información sobre Virtual Network NAT.
Obtenga más información sobre recursos de puerta de enlace de NAT.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con la CLI de Azure.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con PowerShell.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con Azure Portal.
 Ejemplos de CLI de Azure para redes virtuales
23/09/2020 • 2 minutes to read • Edit Online

En la tabla siguiente se incluyen vínculos a scripts de Bash con comandos de CLI de Azure:

SC RIP T DESC RIP C IÓ N

Creación de una red virtual para aplicaciones de niveles Creación de una red virtual con subredes de front-end y
múltiples back-end. El tráfico a la subred de front-end está limitado a
HTTP y SSH, mientras que el tráfico a la subred de back-end
está limitado a MySQL, al puerto 3306.

Emparejamiento de dos redes virtuales Creación y conexión de dos redes virtuales en la misma
región.

Enrutamiento del tráfico por una aplicación virtual de red Creación de una red virtual con subredes de front-end y
back-end y una máquina virtual que pueda enrutar el tráfico
entre dos subredes.

Filtrado del tráfico de red entrante y saliente de máquina Creación de una red virtual con subredes de front-end y
virtual back-end. El tráfico de red entrante a la subred de front-end
está limitado a HTTP, HTTPS y SSH. No se permite el tráfico
saliente a Internet desde la subred de back-end.

Configuración de una red virtual de doble pila de IPv4 + IPv6 Implementa la red virtual de doble pila (IPv4 + IPv6) con dos
con Basic Load Balancer máquinas virtuales y una instancia de Azure Basic Load
Balancer con las direcciones IP públicas IPv4 e IPv6.

Configuración de una red virtual de doble pila de IPv4 + IPv6 Implementa la red virtual de doble pila (IPv4 + IPv6) con dos
con Standard Load Balancer máquinas virtuales y una instancia de Azure Standard Load
Balancer con las direcciones IP públicas IPv4 e IPv6.

Tutorial: Creación y prueba de una puerta de enlace de NAT: Cree y valide una puerta de enlace NAT mediante una
CLI de Azure máquina virtual de origen y de destino.
 Ejemplos de Azure PowerShell para red virtual
23/09/2020 • 2 minutes to read • Edit Online

En la tabla siguiente se incluyen vínculos a scripts de Azure PowerShell:

SC RIP T DESC RIP C IÓ N

Creación de una red virtual para aplicaciones de niveles Creación de una red virtual con subredes de front-end y
múltiples back-end. El tráfico a la subred de front-end está limitado a
HTTP, mientras que el tráfico a la subred de back-end está
limitado a SQL, al puerto 1433.

Emparejamiento de dos redes virtuales Creación y conexión de dos redes virtuales en la misma
región.

Enrutamiento del tráfico por una aplicación virtual de red Creación de una red virtual con subredes de front-end y
back-end y una máquina virtual que pueda enrutar el tráfico
entre dos subredes.

Filtrado del tráfico de red entrante y saliente de máquina Creación de una red virtual con subredes de front-end y
virtual back-end. El tráfico de red entrante a la subred de front-end
está limitado a HTTP y HTTPS. No se permite el tráfico
saliente a Internet desde la subred de back-end.

Configuración de una red virtual de doble pila de IPv4 + IPv6 Implementa la red virtual de doble pila (IPv4 + IPv6) con dos
con Basic Load Balancer máquinas virtuales y una instancia de Azure Basic Load
Balancer con las direcciones IP públicas IPv4 e IPv6.

Configuración de una red virtual de doble pila de IPv4 + IPv6 Implementa la red virtual de doble pila (IPv4 + IPv6) con dos
con Standard Load Balancer máquinas virtuales y una instancia de Azure Standard Load
Balancer con las direcciones IP públicas IPv4 e IPv6.
 Ejemplos de plantilla de Azure Resource Manager
para una red virtual
23/09/2020 • 2 minutes to read • Edit Online

En la tabla siguiente se incluyen vínculos a ejemplos de plantilla de Azure Resource Manager. Las plantillas se
pueden implementar mediante Azure Portal, la CLI de Azure o Azure PowerShell. Para aprender a crear sus
propias plantillas, consulte Creación e implementación de la primera plantilla de Azure Resource Manager y
Nociones sobre la estructura y la sintaxis de las plantillas de Azure Resource Manager.
Para la sintaxis y las propiedades de JSON que se usan en una plantilla, consulte Tipos de recursos de
[Link].

TA REA DESC RIP C IÓ N

Creación de una red virtual con dos subredes Crea una red virtual con dos subredes.

Enrutamiento del tráfico por una aplicación virtual de red Crea una red virtual con tres subredes. Implementa una
máquina virtual en cada una de las subredes. Crea una tabla
de rutas que contiene las rutas para dirigir el tráfico de una
subred a otra a través de la máquina virtual de la tercera
subred. Asocia la tabla de rutas a una de las subredes.

Creación de un punto de conexión de servicio de red virtual Crea una nueva red virtual con dos subredes y una interfaz
para Azure Storage de red en cada subred. Habilita un punto de conexión de
servicio en Azure Storage para una de las subredes y protege
una nueva cuenta de almacenamiento en dicha subred.

Conexión de dos redes virtuales Crea dos redes virtuales y un emparejamiento de redes
virtuales entre ellas.

Creación de una máquina virtual con varias direcciones IP Crea una máquina virtual Windows o Linux con varias
direcciones IP.

Configuración de una red virtual de doble pila de IPv4 + Implementa la red virtual de doble pila (IPv4 + IPv6) con dos
IPv6 máquinas virtuales y una instancia de Azure Basic Load
Balancer con las direcciones IP públicas IPv4 e IPv6.
 Virtual Network: continuidad del negocio
23/09/2020 • 5 minutes to read • Edit Online

Información general
Una red virtual (VNet) es una representación lógica de su red en la nube. Permite definir su propio espacio de
direcciones IP privadas y segmentar la red en subredes. Las redes virtuales actúan como un límite de confianza
para hospedar los recursos de proceso, como Máquinas virtuales y Cloud Services (roles web y de trabajo) de
Azure. Una red virtual permite la comunicación IP privada directa entre los recursos hospedados en ella. Puede
vincular una red virtual a una red local mediante una instancia de VPN Gateway o por medio de ExpressRoute.
Una red virtual se crea dentro del ámbito de una región. Puede crear redes virtuales con el mismo espacio de
direcciones en dos regiones diferentes (por ejemplo, Este de EE. UU. y Oeste de EE. UU.), pero no se pueden
conectar entre sí porque tienen el mismo espacio de dirección.

Continuidad empresarial
La aplicación puede sufrir diferentes formas de interrupción. Por ejemplo, es posible que el servicio se corte por
completo en una región determinada como consecuencia de un desastre natural o que se produzca un desastre
parcial debido a un error en varios dispositivos o servicios. La repercusión en el servicio de red virtual es diferente
en cada una de estas situaciones.
P: ¿Qué se puede hacer si se produce una interrupción en una región entera? Por ejemplo, ¿y si
debido a un desastre natural el ser vicio se ha cor tado por completo en una región? ¿Qué ocurre con
las redes vir tuales hospedadas en la región?
A. La red virtual y los recursos de la región afectada permanecen inaccesibles durante el tiempo que dure la
interrupción del servicio.

P: ¿Qué se puede hacer para volver a crear la misma red vir tual en una región distinta?
A. Las redes virtuales son recursos bastante ligeros. Puede invocar las API de Azure para crear una red virtual con el
mismo espacio de direcciones en una región distinta. Para volver a crear el mismo entorno que estaba presente en
la región afectada, tendrá que realizar llamadas API para volver a implementar los roles web y de trabajo de Cloud
Services y las máquinas virtuales que tenía. Si tiene conectividad local, como una implementación híbrida, tendrá
que implementar una nueva instancia de VPN Gateway y conectarse a su red local.
Para crear una red virtual, consulte Creación de una red virtual.
P: ¿Es posible volver a crear una réplica de una red vir tual de una región determinada en otra región
de antemano?
A. Sí, puede crear dos redes virtuales con el mismo espacio de direcciones IP privadas y los recursos en dos
regiones diferentes antes de que suceda algo. Si hospedaba servicios orientados a Internet en la red virtual, podría
haber configurado Traffic Manager para distribuir geográficamente el tráfico en la región que está activa. Sin
embargo, dos redes virtuales que tengan el mismo espacio de direcciones no se pueden conectar con la red local,
ya que se producirían problemas de enrutamiento. Si se produjera un desastre y la pérdida de una red virtual en
una región, podría conectar la otra red virtual de la región disponible, con el espacio de direcciones coincidente con
la red local.
Para crear una red virtual, consulte Creación de una red virtual.
 ¿Qué es NAT de Virtual Network?
23/09/2020 • 9 minutes to read • Edit Online

La NAT (traducción de direcciones de red) de Virtual Network simplifica la conectividad a Internet de solo
salida para redes virtuales. Cuando se configura en una subred, todas las conexiones salientes usan las
direcciones IP públicas estáticas que se hayan especificado. La conectividad saliente es posible sin que el
equilibrador de carga ni las direcciones IP públicas estén conectados directamente a máquinas virtuales. La
NAT está totalmente administrada y es muy resistente.

Ilustración: Virtual Network NAT

Direcciones IP estáticas de solo salida

Se puede definir la conectividad de salida para todas las subredes con NAT. Distintas subredes dentro de la
misma red virtual pueden tener diferentes NAT. Para configurar una subred, es preciso especificar qué recurso
de puerta de enlace de NAT se debe usar. Los flujos de salida UDP y TCP de todas las instancias de máquina
virtual usarán NAT.
NAT es compatible con los recursos de dirección IP pública o los recursos de prefijos IP públicos, o una
combinación de ambos de una SKU estándar. Puede usar un prefijo de IP pública directamente o distribuir las
direcciones IP públicas del prefijo entre varios recursos de puerta de enlace de NAT. NAT limpiará todo el
tráfico hacia el intervalo de direcciones IP del prefijo. Ahora es fácil crear listas blancas de IP de las
implementaciones.
Todo el tráfico de salida para la subred lo procesa NAT automáticamente sin que el cliente tenga que configurar
nada. No se necesitan rutas definidas por el usuario. NAT tiene prioridad sobre otros escenarios de salida y
reemplaza el destino de Internet predeterminado de una subred.

SNAT a petición con varias direcciones IP para el escalado

NAT usa la "traducción de direcciones de red de puertos" (PNAT o PAT) y se recomienda para la mayoría de
cargas de trabajo. Las cargas de trabajo divergentes o dinámicas se pueden acomodar fácilmente con la
asignación de flujos de salida a petición. Se evita un exceso de planeamiento y asignación previas, y en último
término, el sobreaprovisionamiento de recursos de salida. Los recursos de los puertos SNAT se comparten, por
lo que están disponibles en todas las subredes que usen algún recurso de puerta de enlace de NAT concreto y
se proporcionan cuando se necesitan.
Una dirección IP pública conectada a NAT proporciona hasta 64 000 flujos concurrentes para UDP y TCP. Puede
empezar con una sola dirección IP y escalar verticalmente hasta 16 direcciones IP públicas.
NAT permite crear flujos desde la red virtual a Internet. El tráfico de retorno de Internet solo se permite en
respuesta a un flujo activo.
A diferencia del SNAT de salida del equilibrador de carga, NAT no tiene restricciones sobre cuál de las IP
privadas de una instancia de máquina virtual puede realizar conexiones de salida. Las configuraciones de IP
secundarias pueden crear una conexión a Internet de salida con NAT.

Coexistencia de entrada y salida

NAT es compatible con los siguientes recursos de SKU estándar:
 Equilibrador de carga
Dirección IP pública
Prefijo de IP pública
Si se usan junto con NAT, estos recursos proporcionan conectividad de Internet entrante a sus subredes. NAT
proporciona toda la conectividad de Internet que sale desde sus subredes.
Tanto NAT como las características compatibles de la SKU estándar conocen la dirección en que se inició el
flujo. Los escenarios de entrada y salida pueden coexistir. Estos escenarios recibirán las traducciones de
direcciones de red correctas porque estas características conocen la dirección del flujo.

Ilustración: Dirección del flujo de Virtual Network NAT

Totalmente administrado y muy resistente

NAT se escala de forma horizontal completamente desde el principio. No se precisa ninguna operación de
aumento ni de escalabilidad horizontal. Azure administra automáticamente la operación de NAT. NAT siempre
tiene varios dominios de error y puede soportar varios errores sin que se interrumpa el servicio.

TCP Reset para flujos no reconocidos

El lado privado de NAT envía paquetes de TCP Reset para realizar intentos de comunicación sobre una
conexión TCP que no existe. Un ejemplo son las conexiones que han alcanzado el tiempo de espera de
inactividad. El siguiente paquete recibido devolverá un TCP Reset a la dirección IP privada para señalar y forzar
el cierre de la conexión.
El lado público de NAT no genera paquetes de TCP Reset ni ningún otro tipo de tráfico. Solo se emite el tráfico
generado por la red virtual del cliente.

Tiempo de espera de inactividad de TCP configurable

Se usa un tiempo de espera de inactividad de TCP predeterminado de 4 minutos que se puede aumentar hasta
120. Cualquier actividad de un flujo puede restablecer también el temporizador de actividad, lo que incluye
mensajes TCP Keepalive.

Aislamiento regional o por zona con zonas de disponibilidad

De manera predeterminada, NAT tiene un ámbito regional. Al crear escenarios de zonas de disponibilidad, se
puede aislar en una zona específica (implementación zonal).

Ilustración: Virtual Network NAT con zonas de disponibilidad

Métricas multidimensionales que favorecen la observación

La operación de la NAT se puede supervisar a través de métricas multidimensionales que se exponen en Azure
Monitor. Estas métricas se pueden usar no solo para observar el uso, sino también para solucionar problemas.
Los recursos de la puerta de enlace de NAT exponen las siguientes métricas:
Bytes
Paquetes
Paquetes descartados
Total de conexiones SNAT
 Transiciones de estado de conexiones SNAT por intervalo.

Contrato de nivel de servicio

En disponibilidad general, la disponibilidad mínima de la ruta de datos de NAT es del 99,9 %.

Precios
Para obtener información detallada sobre los precios, consulte Precios de Virtual Network.

Disponibilidad
Virtual Network NAT y el recurso de puerta de enlace NAT están disponibles en todas las regiones de las nubes
de Azure.

Sugerencias
Queremos saber cómo podemos mejorar el servicio. Proponga lo que debemos crear después (y vote por ello)
en UserVoice para NAT.

Limitaciones
NAT es compatible con la dirección IP pública de la SKU estándar, el prefijo de IP pública y los recursos del
equilibrador de carga. Ni los recursos básicos (por ejemplo, el equilibrador de carga básico) ni los
productos derivados de ellos son compatibles con NAT. Los recursos básicos se deben colocar en una subred
que no esté configurada con NAT.
Se admite la familia de direcciones IPv4. NAT no interactúa con la familia de direcciones IPv6. NAT no se
puede implementar en una subred con un prefijo IPv6.
NAT no puede abarcar varias redes virtuales.

Pasos siguientes
Obtenga más información sobre recursos de puerta de enlace de NAT.
Indíquenos qué crear a continuación para Virtual Network NAT en UserVoice.
 Diseño de redes virtuales con recursos de puertas
de enlace de NAT
23/09/2020 • 34 minutes to read • Edit Online

Los recursos de puerta de enlace de NAT forman parte de Virtual Network NAT y proporcionan conectividad
saliente a Internet para una o varias subredes de una red virtual. La subred de la red virtual indica qué puerta
de enlace de NAT se usará. NAT proporciona traducción de direcciones de red de origen (SNAT) para una
subred. Los recursos de puerta de enlace de NAT especifican las direcciones IP estáticas que usan las máquinas
virtuales al crear flujos de salida. Las direcciones IP estáticas proceden de recursos de direcciones IP públicas,
recursos de prefijos IP públicos, o ambos. Si se usa un recurso de prefijo de dirección IP pública, un recurso de
puerta de enlace NAT consume todas las direcciones IP de todos los recursos con prefijo de dirección IP pública.
Un recurso de puerta de enlace de NAT puede usar un máximo de 16 direcciones IP desde cualquiera de ellas.

Ilustración: Virtual Network NAT para la salida a Internet

Implementación de NAT
La configuración y el uso de la puerta de enlace de NAT se ha hecho sencilla a propósito:
Recurso de puerta de enlace de NAT:
Cree un recurso de puerta de enlace de NAT regional o con aislamiento de zona.
Asigne direcciones IP.
Si es necesario, modifique el tiempo de espera de inactividad de TCP (opcional). Revise los temporizadores
antes de cambiar el valor predeterminado.
Red virtual:
Configure una subred de red virtual para que use una puerta de enlace de NAT.
No se necesitan rutas definidas por el usuario.

Recurso
El recurso se ha diseñado para que sea muy sencillo, como se puede ver en el siguiente ejemplo de Azure
Resource Manager en un formato de tipo plantilla. Este formato se muestra aquí para ilustrar los conceptos y la
estructura. Modifique el ejemplo para adecuarlo a sus necesidades. No se pretende que este documento sea un
tutorial.
En el siguiente diagrama se muestran las referencias en cuanto a lo que se puede escribir entre los distintos
recursos de Azure Resource Manager. La flecha indica la dirección de la referencia y parte del lugar desde el que
se puede escribir. Revisar

Ilustración: Modelo de objetos de Virtual Network NAT

NAT se recomienda para la mayoría de las cargas de trabajo, salvo que se tenga una dependencia concreta de la
conectividad de salida de Load Balancer basada en grupos.
Puede migrar desde escenarios del equilibrador de carga estándar, incluidas las reglas salientes, a una puerta
de enlace de NAT. Para realizar la migración, mueva los recursos de IP pública y de prefijo de IP pública desde
los servidores front-end de Load Balancer a la puerta de enlace de NAT. No se requieren direcciones IP nuevas
para la puerta de enlace de NAT. Se pueden reutilizar tanto los recursos de la dirección IP pública como el
recurso del prefijo de la dirección IP pública, siempre que el total no supere las 16 direcciones IP. Planee la
migración y tenga en cuenta la interrupción del servicio durante la transición. Si el proceso se automatiza, el
periodo de interrupción se reduce considerablemente. Pruebe la migración en un entorno de ensayo primero.
Durante la transición, los flujos de entrada originados no resultan afectados.
El siguiente ejemplo es un fragmento de código de una plantilla de Azure Resource Manager. Esta plantilla
implementa varios recursos, incluida una puerta de enlace NAT. La plantilla tiene los parámetros siguientes en
este ejemplo:
natgatewayname : nombre de la puerta de enlace NAT.
location : región de Azure donde se encuentra el recurso.
publicipname : nombre de la dirección IP pública saliente asociada a la puerta de enlace NAT.
vnetname : nombre de la red virtual.
subnetname : nombre de la subred asociada a la puerta de enlace NAT.
El número total de direcciones IP proporcionado por todas las direcciones IP y recursos de prefijo no pueden
superar un total de 16 direcciones IP. Se permite cualquier número de direcciones IP entre 1 y 16.

{
"type": "[Link]/natGateways",
"apiVersion": "2019-11-01",
"name": "[parameters('natgatewayname')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('[Link]/publicIPAddresses', variables('publicipname'))]"
],
"sku": {
"name": "Standard"
},
"properties": {
"idleTimeoutInMinutes": 4,
"publicIpAddresses": "[if(not(empty(parameters('publicipdns'))), variables('publicIpAddresses'),
json('null'))]"
}
},

Cuando se haya creado el recurso de puerta de enlace de NAT, se puede usar en una o varias subredes de una
red virtual. Especifique qué subredes usan este recurso de puerta de enlace de NAT. Una puerta de enlace de
NAT no puede abarcar más de una red virtual. No es preciso asignar la misma puerta de enlace de NAT a todas
las subredes de una red virtual. Se pueden configurar subredes individuales con diferentes recursos de puerta
de enlace de NAT.
Los escenarios que no usen zonas de disponibilidad serán regionales (sin zona especificada). Si usa zonas de
disponibilidad, puede especificar una de ellas para aislar NAT en una zona concreta. No se admite la
redundancia de zonas. Examine las zonas de disponibilidad de NAT.

{
"$schema": "[Link]
"contentVersion": "[Link]",
"parameters": {
"vnetname": {
"defaultValue": "myVnet",
"type": "String",
"metadata": {
"description": "Name of the virtual network"
}
 },
"subnetname": {
"defaultValue": "mySubnet",
"type": "String",
"metadata": {
"description": "Name of the subnet for virtual network"
}
},
"vnetaddressspace": {
"defaultValue": "[Link]/16",
"type": "String",
"metadata": {
"description": "Address space for virtual network"
}
},
"vnetsubnetprefix": {
"defaultValue": "[Link]/24",
"type": "String",
"metadata": {
"description": "Subnet prefix for virtual network"
}
},
"natgatewayname": {
"defaultValue": "myNATgateway",
"type": "String",
"metadata": {
"description": "Name of the NAT gateway resource"
}
},
"publicipdns": {
"defaultValue": "[concat('gw-', uniqueString(resourceGroup().id))]",
"type": "String",
"metadata": {
"description": "dns of the public ip address, leave blank for no dns"
}
},
"location": {
"defaultValue": "[resourceGroup().location]",
"type": "String",
"metadata": {
"description": "Location of resources"
}
}
},
"variables": {
"publicIpName": "[concat(parameters('natgatewayname'), 'ip')]",
"publicIpAddresses": [
{
"id": "[resourceId('[Link]/publicIPAddresses', variables('publicipname'))]"
}
]
},
"resources": [
{
"type": "[Link]/publicIPAddresses",
"apiVersion": "2019-11-01",
"name": "[variables('publicIpName')]",
"location": "[parameters('location')]",
"sku": {
"name": "Standard"
},
"properties": {
"publicIPAddressVersion": "IPv4",
"publicIPAllocationMethod": "Static",
"idleTimeoutInMinutes": 4,
"dnsSettings": {
"domainNameLabel": "[parameters('publicipdns')]"
}
}
 },
{
"type": "[Link]/natGateways",
"apiVersion": "2019-11-01",
"name": "[parameters('natgatewayname')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('[Link]/publicIPAddresses', variables('publicipname'))]"
],
"sku": {
"name": "Standard"
},
"properties": {
"idleTimeoutInMinutes": 4,
"publicIpAddresses": "[if(not(empty(parameters('publicipdns'))), variables('publicIpAddresses'),
json('null'))]"
}
},
{
"type": "[Link]/virtualNetworks",
"apiVersion": "2019-11-01",
"name": "[parameters('vnetname')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('[Link]/natGateways', parameters('natgatewayname'))]"
],
"properties": {
"addressSpace": {
"addressPrefixes": [
"[parameters('vnetaddressspace')]"
]
},
"subnets": [
{
"name": "[parameters('subnetname')]",
"properties": {
"addressPrefix": "[parameters('vnetsubnetprefix')]",
"natGateway": {
"id": "[resourceId('[Link]/natGateways', parameters('natgatewayname'))]"
},
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
}
],
"enableDdosProtection": false,
"enableVmProtection": false
}
},
{
"type": "[Link]/virtualNetworks/subnets",
"apiVersion": "2019-11-01",
"name": "[concat(parameters('vnetname'), '/mySubnet')]",
"dependsOn": [
"[resourceId('[Link]/virtualNetworks', parameters('vnetname'))]",
"[resourceId('[Link]/natGateways', parameters('natgatewayname'))]"
],
"properties": {
"addressPrefix": "[parameters('vnetsubnetprefix')]",
"natGateway": {
"id": "[resourceId('[Link]/natGateways', parameters('natgatewayname'))]"
},
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
}
]
}
Las puertas de enlace de NAT se definen con una propiedad en una subred de una red virtual. Los flujos que
creen las máquinas virtuales en la subred subnetname de la red virtual vnetname usarán la puerta de enlace
NAT. Toda la conectividad de salida usará las direcciones IP asociadas con natgatewayname como dirección IP
de origen.
Para más información sobre la plantilla de Azure Resource Manager usada en este ejemplo, consulte:
Inicio rápido: Creación de una puerta de enlace NAT: plantilla de Resource Manager
Virtual Network NAT

Guía de diseño
Lea esta sección para familiarizarse con las consideraciones para diseñar redes virtuales con NAT.
1. Optimización de costos
2. Coexistencia de entrada y salida
3. Administración de recursos básicos
4. Zonas de disponibilidad
Optimización de costos
Los puntos de conexión de servicio y el vínculo privado son opciones que deben tenerse en cuenta para
optimizar el costo. No es necesario NAT para estos servicios. La NAT de la red virtual no procesa el tráfico
dirigido a los puntos de conexión de servicio o a un vínculo privado.
Los puntos de conexión de servicio enlazan los recursos de servicio de Azure a su red virtual y controlan el
acceso a los recursos de servicio de Azure. Por ejemplo, cuando se accede a Azure Storage, se usa un punto de
conexión de servicio para almacenamiento, con el fin de evitar los cargos de NAT de datos procesados. Los
puntos de conexión de servicio con gratuitos.
Un vínculo privado expone el servicio PaaS de Azure (o cualquier otro servicio hospedado con vínculo privado)
como punto de conexión privado dentro de una red virtual. Un vínculo privado se factura en función de la
duración y de los datos procesados.
Evalúe si alguno de estos dos métodos (o ambos) se adapta bien a su escenario y úselo según sea necesario.
Coexistencia de entrada y salida
La puerta de enlace de NAT es compatible con:
Equilibrador de carga estándar
IP pública estándar
Prefijo de IP pública estándar
Cuando desarrolle una implementación nueva, comience con SKU estándar.

Ilustración: Virtual Network NAT para la salida a Internet

El escenario de solo salida a Internet que proporciona la puerta de enlace de NAT se puede expandir con la
funcionalidad de entrada desde Internet. Todos los recursos saben la dirección en que se origina un flujo. En una
subred con una puerta de enlace de NAT, esta sustituye todos los escenarios de salida a Internet. Por su parte,
los escenarios de entrada desde Internet los proporciona el recurso respectivo.
NAT y máquina virtual con IP pública de nivel de instancia

Ilustración: Virtual Network NAT y máquina virtual con IP pública de nivel de instancia
 DIREC C IÓ N REC URSO

Entrada Máquina virtual con IP pública de nivel de instancia

Salida NAT Gateway

La máquina virtual usará una puerta de enlace de NAT para la salida. La entrada originada no resulta afectada.
NAT y máquina virtual con equilibrador de carga público

Ilustración: Virtual Network NAT y máquina virtual con equilibrador de carga público

DIREC C IÓ N REC URSO

Entrada Equilibrador de carga público

Salida NAT Gateway

La puerta de enlace de NAT sustituye la configuración de salida de una regla de equilibrio de carga o las reglas
de salida. La entrada originada no resulta afectada.
NAT y máquina virtual con IP pública de nivel de instancia y equilibrador de carga pública

Ilustración: Virtual Network NAT y máquina virtual con IP pública de nivel de instancia y equilibrador de carga
pública

DIREC C IÓ N REC URSO

Entrada Máquina virtual con IP pública de nivel de instancia y

equilibrador de carga pública

Salida NAT Gateway

La puerta de enlace de NAT sustituye la configuración de salida de una regla de equilibrio de carga o las reglas
de salida. La máquina virtual también usará una puerta de enlace de NAT para la salida. La entrada originada no
resulta afectada.
Administración de recursos básicos
El equilibrador de carga estándar, la IP pública y el prefijo de IP pública son compatibles con la puerta de enlace
de NAT. Las puertas de enlace de NAT operan en el ámbito de una subred. La SKU básica de estos servicios se
debe implementar en una subred sin una puerta de enlace de NAT. Esta separación permite que las dos
variantes de SKU coexistan en la misma red virtual.
Las puertas de enlace de NAT tienen prioridad sobre los escenarios de salida de la subred. El equilibrador de
carga básico o la IP pública (y todos los servicios administrados integrados con ellos) no pueden ajustarse con
las traducciones correctas. La puerta de enlace de NAT toma el control sobre el tráfico de salida a Internet en
una subred. El tráfico de entrada al equilibrador de carga básico y a la IP pública no está disponible. El tráfico de
entrada a un equilibrador de carga básico o a una IP pública configurada en una máquina virtual no estará
disponible.
Zonas de disponibilidad
Aislamiento de zona con pilas de zonas
Ilustración: Virtual Network NAT con aislamiento de zona, creación de "pilas de zonas"
Incluso sin zonas de disponibilidad, NAT es resistente y puede sobrevivir a los errores de varios componentes
de la infraestructura. Las zonas de disponibilidad se basan en esta resistencia con escenarios de aislamiento de
zona para NAT.
Las redes virtuales y sus subredes son construcciones regionales. Las subredes no están restringidas a una zona.
Existe un compromiso de aislamiento de zona cuando una instancia de máquina virtual que usa un recurso de
puerta de enlace NAT está en la misma zona que el recurso de puerta de enlace NAT y sus direcciones IP
públicas. El patrón que quiere usar para el aislamiento de zona crea una "pila de zona" por zona de
disponibilidad. Esta "pila de zona" se compone de instancias de máquina virtual, recursos de puerta de enlace
NAT, dirección IP pública o recursos de prefijo en una subred que se supone que atiende solo a la misma zona.
Las operaciones del plano de control y el plano de datos están restringidos a la zona especificada.
Se espera que los errores que se produzcan en una zona que no sea aquella en la que existe el escenario no
tengan ningún impacto en NAT. El tráfico de salida de las máquinas virtuales de la misma zona generará un
error debido al aislamiento de la zona.
Integración de puntos de conexión de entrada
Si su escenario requiere puntos de conexión de entrada, tiene dos opciones:

O P C IÓ N PAT RÓ N E JEM P LO P RO S C O N T RA S

(1) Alinee los puntos de Cree de un Mismo modelo de Es posible que sea
conexión de entrada equilibrador de carga estado y el modo de necesario enmascarar
con las pilas de estándar con el error para entrada y las direcciones IP
zona front-end de zona. salida. Más sencillo individuales por zona
correspondientes de operar. con un nombre DNS
que está creando común.
para salida.

(2) Superponga las Cree un equilibrador Dirección IP única Modelo de estado

pilas de zona con un de carga estándar para el punto de variable y modos de
punto de conexión con redundancia de conexión de entrada. error de entrada y
de entrada entre zona en el front-end. salida. Más complejo
zonas . de operar.

NOTE
Una puerta de enlace de NAT con una zona aislada requiere que las direcciones IP coincidan con la zona de la puerta de
enlace de NAT. No se admiten recursos de la puerta de enlace de NAT con direcciones IP de otra zona o que no tengan
ninguna zona.

No se admiten escenarios de salida entre zonas

Ilustración: Virtual Network NAT no es compatible con la subred que abarca varias zonas
No se puede lograr un compromiso de aislamiento de zona con recursos de puerta de enlace NAT cuando las
instancias de máquina virtual se implementan en varias zonas dentro de la misma subred. E incluso si había
varias puertas de enlace NAT de zona conectadas a una subred, la instancia de máquina virtual no sabría qué
recurso de puerta de enlace NAT seleccionar.
No existe un compromiso de aislamiento de zona cuando a) la zona de una instancia de máquina virtual y las
zonas de una puerta de enlace NAT de zona no están alineadas, o b) se usa un recurso de puerta de enlace NAT
regional con instancias de máquina virtual de zona.
Aunque parece que el escenario funciona, su modelo de estado y modo de error no están definidos desde el
punto de vista de la zona de disponibilidad. Considere la posibilidad de trabajar con pilas de zonas o todas
regionales en su lugar.

NOTE
La propiedad de zonas de un recurso de puerta de enlace NAT no es mutable. Vuelva a implementar el recurso de la
puerta de enlace de NAT con la preferencia regional o de zona pretendida.

NOTE
Las direcciones IP en sí no tienen redundancia de zona si no se especifica ninguna zona. El servidor front-end de un
equilibrador de carga estándar tiene redundancia de zona si una dirección IP no se crea en una zona concreta. Esto no se
aplica a la NAT. Solo se admite el aislamiento regional o de zona.

Rendimiento
Cada recurso de puerta de enlace NAT puede proporcionar hasta 50 Gbps de rendimiento. Puede dividir las
implementaciones en varias subredes y asignar a cada subred o grupos de subredes una puerta de enlace NAT
para realizar escalar horizontalmente.
Cada puerta de enlace NAT puede admitir 64 000 conexiones por dirección IP de salida asignada. Revise la
siguiente sección sobre la traducción de direcciones de red de origen (SNAT) para más información, así como el
artículo de solución de problemas para obtener instrucciones específicas sobre la resolución de problemas.

Traducción de direcciones de red de origen

La traducción de direcciones de red de origen (SNAT) reescribe el origen de un flujo para que parta de otra
dirección IP. Los recursos de la puerta de enlace de NAT usan una variante de SNAT que habitualmente se
denomina traducción de direcciones de puertos (PAT). PAT reescribe la dirección de origen y el puerto de origen.
Con SNAT, no hay una relación fija entre el número de direcciones privadas y sus direcciones públicas
traducidas.
Aspectos básicos
Examinemos un ejemplo de cuatro flujos que explican el concepto básico. La puerta de enlace de NAT utiliza el
recurso de dirección IP pública [Link].

F L UJO T UP L A DE O RIGEN T UP L A DE DEST IN O

1 [Link]:4283 [Link]:80

2 [Link]:4284 [Link]:80

3 [Link].5768 [Link]:80

4 [Link]:4285 [Link]:80

Estos flujos pueden tener el siguiente aspecto después de que se haya producido la traducción de puertos de
origen:
 T UP L A DE O RIGEN C O N
F L UJO T UP L A DE O RIGEN SN AT T UP L A DE DEST IN O

1 [Link]:4283 [Link]:234 [Link]:80

2 [Link]:4284 [Link]:235 [Link]:80

3 [Link].5768 [Link]:236 [Link]:80

4 [Link]:4285 [Link]:237 [Link]:80

El destino verá el origen del flujo como [Link] (tupla de origen con SNAT) con el puerto asignado que se
muestra. PAT como se muestra en la tabla anterior también se denomina SNAT de enmascaramiento de puertos.
Varios orígenes privados se enmascaran detrás de una IP y un puerto.
No asuma una dependencia de la forma concreta en que se asignan los puertos de origen. Lo anterior es una
ilustración solo del concepto fundamental.
El SNAT que proporciona NAT es diferente del equilibrador de carga en varios aspectos.
A petición
NAT proporciona puertos SNAT a petición para nuevos flujos de tráfico de salida. Todos los puertos SNAT
disponibles en el inventario los usa la máquina virtual en las subredes configuradas con NAT.

Ilustración: SNAT de salida a petición de Virtual Network NAT

Todas las configuraciones de IP de una máquina virtual pueden crear flujos de salida a petición si fuera
necesario. No es necesario realizar un planeamiento de cada instancia previo a la asignación, ni siquiera el
sobreaprovisionamiento por instancia para el caso más desfavorable.

Ilustración: Diferencias en escenarios de agotamiento

Una vez que se libera un puerto SNAT, este está disponible para que lo use cualquier máquina virtual de las
subredes configuradas con NAT. La asignación a petición permite que las cargas de trabajo dinámicas y
divergentes en subredes usen los puertos SNAT a medida que se necesiten. Mientras haya un inventario de
puertos SNAT disponible, los flujos de SNAT funcionarán correctamente. Las zonas activas de los puertos SNAT
se benefician de que el inventario sea mayor. Los puertos SNAT se quedan sin usar en las máquinas virtuales
que no los necesiten de forma activa.
Ampliación
El escalado de NAT es primordialmente una función de la administración del inventario de puertos SNAT
compartidos disponibles. NAT necesita inventario de puertos SNAT suficiente para afrontar el flujo máximo de
salida previsto en todas las subredes conectadas a un recurso de puerta de enlace de NAT. Puede usar recursos
de direcciones IP públicas, recursos de prefijos IP públicos, o ambos para crear un inventario de puertos SNAT.

NOTE
Si va a asignar un recurso de prefijo de dirección IP pública, se usará todo el prefijo de dirección IP pública. No se puede
asignar un recurso de prefijo de dirección IP pública y, después, descomponer las direcciones IP individuales para
asignarlas a otros recursos. Si desea asignar direcciones IP individuales de un prefijo de dirección IP pública a varios
recursos, debe crear direcciones IP públicas individuales desde el recurso de prefijo de dirección IP pública y asignarlas
según sea necesario en lugar del propio recurso de prefijo de dirección IP pública.
SNAT asigna direcciones privadas a una o varias direcciones IP públicas y reescribe la dirección de origen y el
puerto de origen en los procesos. Un recurso de puerta de enlace de NAT usará 64 000 puertos (puertos SNAT)
por dirección IP pública para esta traducción. Los recursos de puerta de enlace de NAT se pueden escalar
verticalmente hasta un máximo de 16 direcciones IP y un millón de puertos SNAT. Si se proporciona un recurso
de prefijo de dirección IP pública, cada dirección IP dentro del prefijo proporciona un inventario de puertos
SNAT. Y agregar más direcciones IP públicas aumenta los puertos SNAT del inventario disponibles. TCP y UDP
son inventarios de puertos SNAT independientes y no están relacionados.
Los recursos de puerta de enlace de NAT reutilizan los puertos de origen. Antes de realizar el escalado debe
asumir que cada flujo requiere un nuevo puerto SNAT y escalar el número total de direcciones IP disponibles
para el tráfico de salida.
Protocolos
Los recursos de puerta de enlace de NAT interactúan con la IP y los encabezados de transporte de IP de los
flujos UDP y TCP, y son independientes de las cargas de la capa de aplicaciones. No se admiten otros protocolos
de IP.
Temporizadores

IMPORTANT
Un temporizador de inactividad prolongado puede aumentar innecesariamente la probabilidad de agotamiento de SNAT.
Cuanto mayor sea el temporizador que especifique, más tiempo retendrá la NAT los puertos SNAT hasta que finalmente
se agote el tiempo de espera. Si los flujos están inactivos, producirán un error en este momento y consumirán
innecesariamente el inventario de puertos SNAT. Los flujos que producen un error a las dos horas también lo habrían
producido al valor predeterminado de cuatro minutos. Aumentar el tiempo de espera de inactividad es una opción de
último recurso que debe usarse con moderación. Si un flujo nunca está inactivo, no se verá afectado por el temporizador
de inactividad.

El tiempo de espera de inactividad de TCP se puede ajustar de cuatro minutos (valor predeterminado) a 120
minutos (dos horas) para todos los flujos. Además, puede restablecer el temporizador inactivo con tráfico del
flujo. Un patrón recomendado para actualizar las largas conexiones inactivas y para detectar la ejecución de
puntos de conexión es usar mensajes TCP Keepalive. Estos mensajes aparecen como ACK duplicados en los
puntos de conexión, tienen una sobrecarga baja y son invisibles para la capa de aplicaciones.
Para la liberación de los puertos SNAT se usan los siguientes temporizadores:

T IM ER VA L UE

TCP FIN 60 segundos

TCP RST 10 segundos

TCP semiabierto 30 segundos

Los puertos SNAT están disponibles para volver a usarlos con la misma dirección IP y puerto de destino a los 5
segundos.

NOTE
Esta configuración del temporizador está sujeta a cambios. Los valores se proporcionan como ayuda para la solución de
problemas y no se debe asumir una dependencia de temporizadores concretos en este momento.

Limitaciones
 NAT es compatible con la dirección IP pública de la SKU estándar, el prefijo de IP pública y los recursos del
equilibrador de carga. Ni los recursos básicos (por ejemplo, el equilibrador de carga básico) ni los productos
derivados de ellos son compatibles con NAT. Los recursos básicos se deben colocar en una subred que no
esté configurada con NAT.
Se admite la familia de direcciones IPv4. NAT no interactúa con la familia de direcciones IPv6. NAT no se
puede implementar en una subred con un prefijo IPv6.
NAT no puede abarcar varias redes virtuales.

Sugerencias
Queremos saber cómo podemos mejorar el servicio. ¿Falta una funcionalidad? Proponga lo que debemos crear
después en UserVoice para NAT.

Pasos siguientes
Obtenga información sobre Virtual Network NAT.
Obtenga información acerca de las métricas y alertas de los recursos de puerta de enlace NAT.
Obtenga información sobre la solución de los problemas de los recursos de la puerta de enlace de NAT.
Tutorial para validar una puerta de enlace de NAT
CLI de Azure
PowerShell
Portal
Inicio rápido para implementar recursos de puerta de enlace de NAT
CLI de Azure
PowerShell
Portal
Plantilla
Información acerca de la API de recursos de la puerta de enlace de NAT
REST API
CLI de Azure
PowerShell
Información acerca de las zonas de disponibilidad.
Información acerca del equilibrador de carga estándar.
Información sobre las zonas de disponibilidad y el equilibrador de carga estándar.
Indíquenos qué crear a continuación para Virtual Network NAT en UserVoice.
 Métricas de Azure Virtual Network NAT
23/09/2020 • 2 minutes to read • Edit Online

Los recursos de puerta de enlace de Azure Virtual Network NAT proporcionan métricas multidimensionales. Estas
métricas se pueden usar para observar la operación y para la solución de problemas. Se pueden configurar alertas
para problemas críticos, como el agotamiento de SNAT.

Ilustración: Virtual Network NAT para la salida a Internet

Métricas
Los recursos de puerta de enlace de NAT proporcionan las siguientes métricas multidimensionales en Azure
Monitor:

A GREGA C IÓ N
M ÉT RIC A DESC RIP C IÓ N REC O M EN DA DA DIM EN SIO N S

Bytes Bytes procesados de Sum Dirección (entrada; salida),

entrada y de salida protocolo (6 TCP; 17 UDP)

Paquetes Paquetes procesados de Sum Dirección (entrada; salida),

entrada y de salida protocolo (6 TCP; 17 UDP)

Paquetes descartados Paquetes descartados por la Sum /

puerta de enlace de NAT

Recuento de conexiones Transiciones de estado por Sum Estado de conexión,

SNAT intervalo protocolo (6 TCP; 17 UDP)

Recuento de conexiones Conexiones SNAT activas Sum Protocolo (6 TCP; 17 UDP)

SNAT totales actuales (número
aproximado de puertos
SNAT en uso)

Alertas
En Azure Monitor se pueden configurar alertas para cada una de las métricas anteriores.

Limitaciones
Resource Health no es compatible.

Pasos siguientes
Obtenga más información sobre Virtual Network NAT.
Obtenga información sobre los recursos de puerta de enlace de NAT
Obtenga información acerca de Azure Monitor
Obtenga información sobre la solución de los problemas de los recursos de la puerta de enlace de NAT.
Indíquenos qué crear a continuación para Virtual Network NAT en UserVoice.
 Solución de problemas de conectividad de Azure
Virtual Network NAT
23/09/2020 • 24 minutes to read • Edit Online

En este artículo se ayuda a los administradores a diagnosticar y resolver problemas de conectividad cuando se
usa Virtual Network NAT.

Problemas
Agotamiento de SNAT
Error en el ping de ICMP
Errores de conectividad
Coexistencia de IPv6
La conexión no parte de las direcciones IP de puerta de enlace NAT
Para resolver estos problemas, siga los pasos de la siguiente sección.

Solución
Agotamiento de la arquitectura de redes de sistemas
Un solo recurso de puerta de enlace de NAT admite entre 64 000 y 1 millón de flujos simultáneos. Cada dirección
IP proporciona 64 000 puertos de SNAT al inventario disponible. Se pueden usar un máximo de 16 direcciones IP
por recurso de puerta de enlace de NAT. El mecanismo de la arquitectura de redes de sistemas se describe aquí de
forma más detallada.
Con frecuencia, la causa principal del agotamiento de SNAT es un antipatrón de cómo se establece y administra la
conectividad de salida o cómo se cambian los temporizadores configurables de sus valores predeterminados.
Consulte detenidamente esta sección.
Pasos
1. Compruebe si ha modificado el tiempo de espera de inactividad predeterminado en un valor superior a cuatro
minutos.
2. Investigue la forma en que la aplicación crea conectividad saliente (por ejemplo la revisión del código o la
captura de paquetes).
3. Determine si esta actividad es el comportamiento esperado o si la aplicación no se comporta correctamente.
Use métricas en Azure Monitor para apoyar sus conclusiones. Use la categoría "Error" para la métrica de las
conexiones SNAT.
4. Evalúe si se siguen los patrones adecuados.
5. Evalúe si el agotamiento de puertos de SNAT debe mitigarse con la asignación de más direcciones IP a un
recurso de puerta de enlace de NAT.
Patrones de diseño
Aproveche la reutilización de las conexiones y la agrupación de conexiones siempre que sea posible. Estos
patrones evitarán problemas de agotamiento de los recursos y el resultado será un comportamiento predecible.
Las primitivas de estos patrones se pueden encontrar en muchas bibliotecas y marcos de desarrollo.
Solución: Uso de patrones y procedimientos recomendados apropiados
Los recursos de puerta de enlace NAT tienen un tiempo de espera de inactividad de TCP predeterminado de
 cuatro minutos. Si esta configuración cambia a un valor superior, NAT retendrá los flujos por más tiempo y
puede causar una presión innecesaria en el inventario de puertos SNAT.
Las solicitudes atómicas (una solicitud por conexión) son una mala opción de diseño. Estos límites de
antipatrón escalan, reducen el rendimiento y disminuyen la confiabilidad. En su lugar, reutilice las conexiones
HTTP/S para reducir el número de conexiones y los puertos SNAT asociados. El escalado de la aplicación
aumentará y mejorará el rendimiento debido a la reducción de los protocolos de enlace, a la sobrecarga y al
costo de la operación criptográfica al usar TLS.
DNS puede introducir muchos flujos individuales en el volumen cuando el cliente no almacena en caché el
resultado de la resolución DNS. Use el almacenamiento en caché.
Los flujos UDP (por ejemplo, las búsquedas de DNS) asignan puertos SNAT mientras dure el tiempo de espera
de inactividad. Cuanto mayor sea el tiempo de espera de inactividad, mayor será la presión sobre los puertos
SNAT. Use un tiempo de espera de inactividad corto (por ejemplo, 4 minutos).
Use los grupos de conexiones para dar forma al volumen de la conexión.
Nunca abandone de forma silenciosa un flujo TCP y confíe en temporizadores TCP para limpiar el flujo. Si no
permite que TCP cierre explícitamente la conexión, el estado permanecerá asignado en los sistemas y puntos
de conexión intermedios y hará que los puertos de SNAT no estén disponibles para otras conexiones. Este
patrón puede desencadenar errores en la aplicación y el agotamiento de SNAT.
No cambie los valores del temporizador relacionado con el cierre de TCP de nivel de sistema operativo sin el
conocimiento experto de impacto. Aunque la pila de TCP se recuperará, el rendimiento de la aplicación puede
verse afectado negativamente si los puntos de conexión de una conexión tienen expectativas no coincidentes.
El deseo de cambiar los temporizadores suele ser un signo de un problema de diseño subyacente. Revise las
siguientes recomendaciones.
El agotamiento de SNAT también se puede amplificar con otros antipatrones en la aplicación subyacente. Revise
estos patrones y procedimientos recomendados adicionales para mejorar la escala y la confiabilidad del servicio.
Explore el impacto de reducir el tiempo de espera de inactividad de TCP a valores inferiores, incluido el tiempo
de espera predeterminado de inactividad de cuatro minutos para liberar antes el inventario de puertos SNAT.
Considere la posibilidad de usar patrones de sondeo asincrónicos para las operaciones de ejecución
prolongada, con el fin de liberar recursos de conexión para otras operaciones.
Los flujos de larga duración (como las conexiones TCP reutilizadas) deberían usar paquetes keepalive de TCP o
de la capa de la aplicación para evitar que los sistemas intermedios superen el tiempo de espera. Aumentar el
tiempo de espera de inactividad es un último recurso y es posible que no resuelva la causa principal. Un
tiempo de espera prolongado puede causar errores de baja tasa cuando expira el tiempo de espera e
introducir retrasos y errores innecesarios.
Se deben usar patrones de reintento correctos para evitar reintentos o ráfagas agresivos durante un error
transitorio o la recuperación de un error. La creación de una conexión TCP para cada operación HTTP (también
conocidas como "conexiones atómicas") es un antipatrón. Las conexiones atómicas evitarán que su aplicación
se escale de forma correcta y malgastarán recursos. Canalice siempre varias operaciones a la misma conexión.
Su aplicación aumentará la velocidad de las transacciones y reducirá los costos de los recursos. Cuando la
aplicación usa un cifrado de la capa de transporte (por ejemplo, TLS), se produce un considerable costo
asociado con el procesamiento de nuevas conexiones. Para conocer otros patrones de procedimientos
recomendados, consulte Patrones de diseño en la nube de Azure.
Posibles mitigaciones adicionales
Solución: Escale la conectividad saliente como se indica a continuación:

ESC EN A RIO EVIDEN C IA M IT IGA C IÓ N

 ESC EN A RIO EVIDEN C IA M IT IGA C IÓ N

Percibe una contención de los puertos La categoría "Error" para la métrica de Determine si puede agregar recursos
SNAT y un agotamiento de estos en Conexiones SNAT en Azure Monitor con direcciones IP públicas o recursos
periodos de mucho uso. muestra los errores transitorios o con prefijos IP públicos. Esta
persistentes a lo largo del tiempo y un incorporación permitirá que haya un
volumen de conexión elevado. máximo de 16 direcciones IP en la
puerta de enlace de NAT. También
proporcionará más inventario para los
puertos SNAT disponibles (64 000 por
dirección IP) y le permitirá escalar aún
más su escenario.

Ya se le han proporcionado 16 Error al intentar agregar una Distribuya el entorno de aplicaciones

direcciones IP y sigue sufriendo un dirección IP adicional. El número total entre varias subredes y proporcione un
agotamiento de puertos SNAT. de direcciones IP de los recursos de recurso de puerta de enlace de NAT
dirección IP pública o de prefijo de IP para cada subred. Vuelva a evaluar los
pública supera un total de 16. patrones de diseño para optimizar
según la guía anterior.

NOTE
Es importante saber por qué se produce el agotamiento de SNAT. Asegúrese de que usa los patrones correctos para
escenarios escalables y confiables. La incorporación de más puertos SNAT a un escenario sin conocer la causa de la demanda
sería el último recurso. Si desconoce los motivos por los que su escenario supone una mayor presión para el inventario de
puertos SNAT, la incorporación de más puertos SNAT al inventario mediante la adición de más direcciones IP lo único que
hará será retrasar el error de agotamiento cuando la aplicación escale. Es posible que esté ocultando otras ineficacias y
antipatrones.

Error en el ping de ICMP

Virtual Network NAT admite los protocolos UDP y TCP de IPv4. ICMP no se admite, por lo que cabe esperar que se
produzca un error.
Solución: En su lugar, use pruebas de conexión TCP (por ejemplo, "ping de TCP") y pruebas de la capa de la
aplicación específicas de UDP para asegurar la conectividad de un extremo a otro.
La siguiente tabla se puede usar como punto de partida para saber qué herramientas se deben usar para iniciar
las pruebas.

P RUEB A DE C O N EXIÓ N TC P P RUEB A DE L A C A PA DE L A

SIST EM A O P ERAT IVO GEN ÉRIC A A P L IC A C IÓ N DE TC P UDP

Linux nc (prueba de conexión curl (prueba de la capa de la específica de la aplicación

genérica) aplicación de TCP)

Windows PsPing Invoke-WebRequest de específica de la aplicación

PowerShell

Errores de conectividad
Los problemas de conectividad con Virtual Network NAT pueden estar causados por varios motivos:
problemas permanentes debidos a errores de configuración.
El agotamiento de SNAT transitorio o persistente de la puerta de enlace NAT
Errores transitorios en la infraestructura de Azure
Errores transitorios en la ruta de acceso entre Azure y el destino público de Internet
Errores transitorios o persistentes en el destino de Internet público.
Use herramientas como la siguiente para la validación de la conectividad. No se admite el ping de ICMP.

P RUEB A DE C O N EXIÓ N TC P P RUEB A DE L A C A PA DE L A

SIST EM A O P ERAT IVO GEN ÉRIC A A P L IC A C IÓ N DE TC P UDP

Linux nc (prueba de conexión curl (prueba de la capa de la específica de la aplicación

genérica) aplicación de TCP)

Windows PsPing Invoke-WebRequest de específica de la aplicación

PowerShell

Configuración
Compruebe la configuración:
1. ¿El recurso de puerta de enlace NAT tiene al menos un recurso de IP pública o un recurso de prefijo de
dirección IP pública? Debe tener al menos una dirección IP asociada a la puerta de enlace NAT para que pueda
proporcionar conectividad de salida.
2. ¿La subred de la red virtual está configurada para usar la puerta de enlace NAT?
3. ¿Está usando UDR (ruta definida por el usuario) y está reemplazando el destino? Los recursos de puerta de
enlace NAT se convierten en la ruta predeterminada (0/0) en subredes configuradas.
Agotamiento de la arquitectura de redes de sistemas
Revise la sección sobre el agotamiento de SNAT en este artículo.
Infraestructura de Azure
Azure supervisa y opera su infraestructura con gran cuidado. Se pueden producir errores transitorios y no hay
ninguna garantía de que las transmisiones sean sin pérdida. Utilice patrones de diseño que permitan las
retransmisiones SYN para las aplicaciones TCP. Use tiempos de espera de conexión lo bastante prolongados como
para permitir la retransmisión TCP SYN a fin de reducir los efectos transitorios causados por la pérdida de un
paquete SYN.
Solución:
Compruebe el agotamiento de SNAT.
El parámetro de configuración de una pila TCP que controla el comportamiento de la retransmisión de SYN se
denomina RTO (tiempo de espera de la retransmisión). El valor de RTO es ajustable, pero normalmente es de
1 segundo o más, de forma predeterminada, con retroceso exponencial. Si el tiempo de espera de la conexión
de la aplicación es demasiado corto (por ejemplo, 1 segundo), es posible que vea tiempos de espera de
conexión esporádicos. Aumente el tiempo de espera de conexión de la aplicación.
Si observa tiempos de espera más largos e inesperados con comportamientos de aplicación predeterminados,
abra un caso de soporte técnico para solucionar el problema.
No se recomienda reducir artificialmente el tiempo de espera de la conexión TCP ni ajustar el parámetro RTO.
Tránsito público por Internet
Las posibilidades de errores transitorios aumentan con una ruta de acceso más larga al destino y más sistemas
intermedios. Se espera que los errores transitorios puedan aumentar la frecuencia en la infraestructura de Azure.
Siga las mismas instrucciones que en la sección Infraestructura de Azure.
Punto de conexión de Internet
Se aplican las secciones anteriores, junto con el punto de conexión de Internet con el que se establece la
comunicación. Otros factores que pueden afectar al éxito de la conectividad son:
Administración del tráfico en el lado de destino, incluido
Limitación de la tasa de API impuesta por el lado de destino
Formas de tráfico de la capa de transporte o de mitigación de DDoS volumétricas
 Firewall u otros componentes en el destino
Normalmente, se necesitan capturas de paquetes en el origen y en el destino (si está disponible) para determinar
lo que está teniendo lugar.
Solución:
Compruebe el agotamiento de SNAT.
Valide la conectividad a un punto de conexión en la misma región o en otra parte para la comparación.
Si va a crear pruebas de gran volumen o de tasa de transacciones, explore si la reducción de la velocidad
reduce la aparición de errores.
Si la tasa de cambio afecta a la tasa de errores, compruebe si es posible que se haya alcanzado el límite de
velocidad de la API u otras restricciones en el lado de destino.
Si la investigación no es concluyente, abra un caso de soporte técnico para solucionar el problema.
Restablecimientos TCP recibidos
La puerta de enlace NAT genera restablecimientos TCP en la máquina virtual de origen para el tráfico que no se
reconoce como en curso.
Una posible razón es que la conexión TCP haya agotado el tiempo de espera. Puede ajustar el tiempo de espera de
inactividad entre 4 minutos y un máximo de 120 minutos.
Los restablecimientos TCP no se generan en el lado público de los recursos de puerta de enlace NAT. Los
restablecimientos TCP en el destino los genera la máquina virtual de origen, no el recurso de puerta de enlace
NAT.
Solución:
Revise las recomendaciones de patrones de diseño.
Abra un caso de soporte técnico para solucionar el problema si es necesario.
Coexistencia de IPv6
Virtual Network NAT admite los protocolos UDP y TCP de IPv4, y la implementación en una subred con un prefijo
IPv6 no es compatible.
Solución: Implemente la puerta de enlace NAT en una subred sin prefijo IPv6.
Puede indicar el interés en funcionalidades adicionales mediante UserVoice de Virtual Network NAT.
La conexión no parte de las direcciones IP de puerta de enlace NAT
Configure la puerta de enlace NAT, las direcciones IP que se van a usar y qué subred debería usar un recurso de
puerta de enlace NAT. Sin embargo, las conexiones de las instancias de máquina virtual que existían antes de que
se implementara la puerta de enlace NAT no usan las direcciones IP. Parece que utilizan direcciones IP que no se
usan con el recurso de puerta de enlace NAT.
Solución:
Virtual Network NAT reemplaza la conectividad saliente de la subred en que está configurada. Al realizar la
transición desde el SNAT predeterminado o el SNAT de salida del equilibrador de carga al uso de puertas de
enlace NAT, las nuevas conexiones comenzarán inmediatamente a usar las direcciones IP asociadas con el recurso
de puerta de enlace NAT. Sin embargo, si una máquina virtual todavía tiene una conexión establecida durante el
cambio a un recurso de puerta de enlace NAT, la conexión seguirá usando la dirección IP SNAT antigua que se
asignó cuando se estableció la conexión. Asegúrese de que realmente establece una nueva conexión, en lugar de
reutilizar una que ya existía porque el sistema operativo o el explorador estaban almacenando en la caché las
conexiones en un grupo de conexiones. Por ejemplo, al usar curl en PowerShell, asegúrese de especificar el
parámetro -DisableKeepalive para forzar una conexión nueva. Si usa un explorador, es posible que las conexiones
estén agrupadas.
No es necesario reiniciar una máquina virtual configurando una subred para un recurso de puerta de enlace NAT.
Sin embargo, si se reinicia una máquina virtual, el estado de la conexión se vacía. Cuando el estado de la conexión
se ha vaciado, todas las conexiones empezarán a usar las direcciones IP del recurso de puerta de enlace NAT. Sin
embargo, esto es un efecto secundario de la máquina virtual que se reinicia, no un indicador de que se requiere
un reinicio.
Si sigue teniendo problemas, abra un caso de soporte técnico para solucionar el problema.
Tiempo de configuración de conexión
Como las reglas de salida de Load Balancer asigna de manera estática grupos de puertos SNAT a máquinas
virtuales específicas, la creación de flujos de salida nuevos es más rápida que usar Virtual Network NAT. Por lo
tanto, al cambiar de las reglas de salida de Load Balancer, puede que vea una mayor latencia al crear una conexión
de salida nueva. Como se explicó anteriormente, para maximizar el rendimiento de la aplicación, debe usar flujos
de larga duración (por ejemplo, conexiones TCP reutilizadas).
Solución:
Si está interesado principalmente en la latencia de configuración de instalación mínima, use las reglas de salida de
Load Balancer.

Pasos siguientes
Obtenga más información sobre Virtual Network NAT.
Obtenga información sobre los recursos de puerta de enlace de NAT
Obtenga información acerca de las métricas y alertas de los recursos de puerta de enlace NAT.
Indíquenos qué crear a continuación para Virtual Network NAT en UserVoice.
 Enrutamiento del tráfico de redes virtuales
23/09/2020 • 54 minutes to read • Edit Online

Aprenda la forma en que Azure enruta el tráfico entre los recursos locales y de Internet de Azure. Azure crea
automáticamente una tabla de rutas para cada subred de una red virtual de Azure y agrega las rutas
predeterminadas del sistema a la tabla. Para más información acerca de las redes y subredes virtuales,
consulte Red virtual. Puede reemplazar algunas de las rutas del sistema de Azure por rutas personalizadas y
agregar rutas personalizadas adicionales a las tablas de rutas. Azure enruta el tráfico saliente desde una
subred en función de las rutas de la tabla de rutas de una subred.

Rutas del sistema

Azure crea automáticamente rutas del sistema y las asigna a todas las subredes de una red virtual. No
puede crear ni eliminar rutas del sistema, pero puede reemplazar algunas de ellas por rutas personalizadas.
Azure crea rutas del sistema predeterminadas para cada subred y agrega rutas predeterminadas opcionales
adicionales a determinadas subredes, o a todas las subredes, al usar funcionalidades específicas de Azure.
Valor predeterminado
Cada ruta contiene un prefijo de dirección y el tipo de próximo salto. Cuando el tráfico que sale de una
subred se envía a una dirección IP que está dentro del prefijo de la dirección de ruta, la ruta que contiene el
prefijo es la que utiliza Azure. Obtenga más información acerca de la selección de rutas por parte de Azure
cuando varias rutas contienen los mismos prefijos o cuando los prefijos se solapan. Cuando se crea una red
virtual, Azure crea automáticamente los siguientes rutas del sistema predeterminadas para cada subred de
la red virtual:

SO URC E P REF IJO S DE DIREC C IÓ N T IP O DE P RÓ XIM O SA LTO

Valor predeterminado Único para la red virtual Virtual network

Valor predeterminado [Link]/0 Internet

Valor predeterminado [Link]/8 None

Valor predeterminado [Link]/16 None

Valor predeterminado [Link]/10 None

Los tipos de próximo salto enumerados en la tabla anterior representan la forma en que Azure enruta el
tráfico destinado al prefijo de dirección enumerado. Estas son las explicaciones de los tipos de próximo
salto:
Red vir tual : enruta el tráfico entre los intervalos de direcciones del espacio de direcciones de una
red virtual. Azure crea una ruta con un prefijo de dirección que corresponde a cada intervalo de
direcciones definido en el espacio de direcciones de una red virtual. Si el espacio de direcciones de la
red virtual tiene varios intervalos de direcciones definidos, Azure crea una ruta individual para cada
intervalo de direcciones. Azure automáticamente enruta el tráfico entre subredes mediante las rutas
que se crea para cada intervalo de direcciones. No es preciso definir las puertas de enlace de Azure
para enrutar el tráfico entre subredes. Aunque una red virtual contiene subredes y cada una de ellas
tiene un intervalo de direcciones definido, Azure no crea rutas predeterminadas para los intervalos
de direcciones de la subred, ya que cada uno de ellos se encuentra dentro de un intervalo de
 direcciones del espacio de direcciones de una red virtual.
Internet : enruta a Internet el tráfico que especifica el prefijo de dirección. La ruta predeterminada del
sistema especifica el prefijo de dirección [Link]/0. Si no se invalidan las rutas predeterminadas de
Azure, Azure enruta a Internet el tráfico de todas las direcciones que no se haya especificada un
intervalo de direcciones en una red virtual, con una excepción. Si la dirección de destino es para uno
de los servicios de Azure, este enruta el tráfico directamente al servicio a través de la red troncal de
Azure, en lugar de enrutarlo a Internet. El tráfico entre los servicios de Azure no atraviesa Internet,
independientemente de la región de Azure en que exista la red virtual o de la región de Azure en que
se implementa una instancia del servicio de Azure. Puede reemplazar la ruta del sistema
predeterminada de Azure predeterminado para el prefijo de dirección [Link]/0 por un ruta
personalizada.
Ninguna : el tráfico que se enruta al tipo de próximo salto Ninguno se elimina, en lugar de
enrutarlo fuera de la subred. Azure crea automáticamente las rutas predeterminadas para los
siguientes prefijos de dirección:
[Link]/8 y [Link]/16 : reservadas para el uso privado en el RFC 1918.
[Link]/10 : reservada en RFC 6598.
Si asigna cualquiera de los intervalos de direcciones anteriores del espacio de direcciones de una red
virtual, Azure cambia automáticamente el tipo de próximo salto de la ruta de No a Red vir tual . Si
asigna un intervalo de direcciones al espacio de direcciones de una red virtual que incluya uno de los
cuatro prefijos de direcciones reservadas, pero no es lo mismo que ellas, Azure quita la ruta del
prefijo y agrega una ruta para el prefijo de dirección que agregó, con Vir tual red como el tipo de
próximo salto.
Rutas predeterminadas opcionales
Azure agrega rutas del sistema predeterminadas adicionales de sistema para diferentes funcionalidades de
Azure, pero solo si se habilitan dichas funcionalidades. En función de la funcionalidad, Azure agrega las
rutas predeterminadas opcionales a subredes concretas de la red virtual o a todas las subredes de una red
virtual. Estos son las rutas del sistema adicionales y los tipos de próximo salto que Azure puede agregar al
habilitar diferentes funcionalidades:

L A SUB RED DE RED

VIRT UA L A L A Q UE SE
SO URC E P REF IJO S DE DIREC C IÓ N T IP O DE P RÓ XIM O SA LTO A GREGA L A RUTA

Valor predeterminado Único para la red virtual, Emparejamiento de VNET All

por ejemplo: [Link]/16

Puerta de enlace de red Prefijos anunciados desde Puerta de enlace de red All
virtual el entorno local a través virtual
de BGP, o bien
configurados en la puerta
de enlace de red local

Valor predeterminado Múltiple VirtualNetworkServiceEnd Solo la subred para la que

point se habilita un punto de
conexión de servicio.

Emparejamiento de red vir tual (VNet) : al crear un emparejamiento entre dos redes virtuales, se
agrega una ruta para cada intervalo de direcciones en el espacio de direcciones de cada red virtual
para la que se crea un emparejamiento. Más información acerca del emparejamiento de red virtual.
Puer ta de enlace de red vir tual : cuando una puerta de enlace de red virtual se agrega a una red
virtual, se agregan también una o varias rutas en las que Puerta de enlace de red virtual aparece
 como el tipo de próximo salto. El origen es también una puerta de enlace de red virtual, ya que la
puerta de enlace agrega las rutas a la subred. Si la puerta de enlace de red local intercambia las rutas
del protocolo Border Gateway Protocol (BGP) con una puerta de enlace de red virtual de Azure, se
agrega una ruta por cada ruta que se propaga desde la puerta de enlace de red local. Se recomienda
resumir las rutas locales en los intervalos de direcciones mayores posibles, con el fin de que se
propague el menor número de rutas a una puerta de enlace de red virtual de Azure. Hay límites en el
número de rutas que se pueden propagar a una puerta de enlace de red virtual de Azure. Para más
información, consulte el artículo acerca de los límites de Azure.
Vir tualNetworkSer viceEndpoint : Azure agrega las direcciones IP públicas de determinados
servicios a la tabla de rutas cuando se habilita un punto de conexión para el servicio. Los puntos de
conexión de servicio se habilitan para las subredes individuales de una red virtual, por lo que la ruta
solo se agrega a la tabla de rutas de una subred para la que haya algún punto de conexión de
servicio habilitado. Las direcciones IP públicas de los servicios de Azure cambian periódicamente.
Azure administra automáticamente las direcciones en la tabla de rutas cuando cambian. Obtenga
más información acerca de los puntos de conexión de servicio de red virtual y los servicios para los
que se pueden crear puntos de conexión de servicio.

NOTE
El tipos de próximo salto Emparejamiento de VNet y Vir tualNetworkSer viceEndpoint solo se agregan
a las tablas de rutas de las subredes de las redes virtuales creadas a través del modelo de implementación de
Azure Resource Manager. Los tipos de próximo salto no se agregan a las tablas de rutas asociadas a las
subredes de redes virtuales creadas mediante el modelo de implementación clásica. Obtenga más
información acerca de los modelos de implementación de Azure.

Rutas personalizadas
Para crear rutas personalizadas, cree rutas definidas por el usuario o intercambie rutas del protocolo Border
Gateway Protocol (BGP) entre su puerta de enlace de red local y una puerta de enlace de red virtual de
Azure.
Definidas por el usuario
En Azure se pueden crear rutas personalizadas o definidas por el usuario (estáticas) para reemplazar las
rutas del sistema predeterminadas o para agregar rutas adicionales a una tabla de rutas de una subred. En
Azure, cree una tabla de rutas y asóciela a cero o más subredes de red virtual. Cada subred puede tener
cero o una ruta de tablas de ruta asociada. Para obtener información acerca del número máximo de rutas
que puede agregar a una tabla de rutas y del número máximo de tablas de rutas definidas por el usuario
que se pueden crear por suscripción de Azure, consulte el artículo acerca de los límites de Azure. Si crea una
tabla de rutas y la asocia a una subred, las rutas que contiene se combinan con las rutas predeterminadas
que Azure agrega a una subred de forma predeterminada, o bien las reemplazan.
Puede especificar los siguientes tipos de próximo salto al crear una ruta definida por el usuario:
Aplicación vir tual : una aplicación virtual es una máquina virtual que ejecuta normalmente una
aplicación de red como, por ejemplo, un firewall. Para más información acerca de las aplicaciones
virtuales de red preconfiguradas que se pueden implementar en una red, consulte Azure
Marketplace. Al crear una ruta con el tipo de salto de aplicación vir tual , especifique también una
dirección IP del próximo salto. La dirección IP puede ser:
La dirección IP privada de una interfaz de red conectada a una máquina virtual. Cualquier
interfaz de red conectada a una máquina virtual que reenvíe el tráfico de red a una dirección
que no sea la suya propia debe tener la opción Habilitar reenvío de IP habilitada. El valor
deshabilita la comprobación que realiza Azure del origen y destino en una interfaz de red.
 Obtenga más información acerca de cómo habilitar el reenvío IP en una interfaz de red.
Aunque Habilitar reenvío de IP es un valor de Azure, es posible que también necesite habilitar
el reenvío IP en el sistema operativo de la máquina virtual para que el dispositivo desvíe el
tráfico entre las direcciones IP privadas asignadas a interfaces de red de Azure. Si el
dispositivo debe enrutar el tráfico a una dirección IP pública, debe hacer de proxy ante el
tráfico o traducir la dirección IP privada del origen a su propia dirección IP privada y Azure la
traducirá a una dirección IP pública antes de enviar el tráfico a Internet. Para determinar la
configuración necesaria en la máquina virtual, consulte la documentación del sistema
operativo o la aplicación de red. Para obtener información acerca de las conexiones salientes
en Azure, consulte Información acerca de las conexiones salientes.

NOTE
Implemente una aplicación virtual en una subred diferente la que se encuentran los recursos que
enrutan a través de la aplicación virtual. La implementación de la aplicación virtual en la misma
subred y la posterior aplicación de una tabla de rutas en la subred que enruta el tráfico a través de la
aplicación virtual pueden provocar bucles de enrutamiento, en los que el tráfico nunca sale de la
subred.

La dirección IP privada de un equilibrador de carga interno de Azure. A menudo se usa un

equilibrador de carga como parte de una estrategia de alta disponibilidad para aplicaciones
virtuales de red.
Puede definir una ruta con [Link]/0 como prefijo de dirección y un tipo de próximo salto de la
aplicación virtual, lo que permite a la aplicación inspeccionar el tráfico y determinar si el tráfico se
debe reenviar o eliminar. Si tiene intención de crear una definida por el usuario que contenga el
prefijo de dirección [Link]/0, consulte antes el apartado [Link]/0 address prefix (Prefijo de dirección
[Link]/0).
Puer ta de enlace de red vir tual : se especifica cuando se desea que el tráfico destinado a prefijos
de dirección específicos se enrute a una puerta de enlace de red virtual. La puerta de enlace de red
virtual debe crearse con el tipo VPN . No se puede especificar una puerta de enlace de red virtual
creada como el tipo ExpressRoute en una ruta definida por el usuario, ya que con ExpressRoute es
preciso usar BGP para las rutas personalizadas. Puede definir una ruta que dirige el tráfico destinado
al prefijo de dirección [Link]/0 a una puerta de enlace de red virtual basada en ruta. En un entorno
local, puede tener un dispositivo que compruebe el tráfico y determine si se reenvía o se elimina. Si
tiene intención de crear una definida por el usuario para el prefijo de dirección [Link]/0, consulte
antes el apartado [Link]/0 address prefix (Prefijo de dirección [Link]/0). En lugar de configurar una
ruta definida por el usuario para el prefijo de dirección [Link]/0, es posible anunciar una ruta con el
prefijo [Link]/0 a través de BGP, si ha habilitado BGP para una puerta de enlace de red virtual de
VPN.
Ninguna : se especifica cuando se desea colocar tráfico en un prefijo de dirección, en lugar de
reenviar el tráfico a un destino. Si no ha configurado completamente una funcionalidad, Azure puede
enumerar No para algunas de las rutas de opcional del sistema. Por ejemplo, si ve No en Dirección
IP del próximo salto con un Tipo de próximo salto de Puerta de enlace de red virtual o
Aplicación virtual, puede deberse a que el dispositivo no funciona o no está completamente
configurado. Azure crea rutas predeterminadas del sistema para los prefijos de direcciones
reservados con No como tipo de próximo salto.
Red vir tual : se especifica cuando se desea reemplazar el enrutamiento predeterminado en una red
virtual. Consulte Ejemplo de enrutamiento, para ver un ejemplo de por qué puede crear una ruta con
el tipo de salto Red vir tual .
 Internet : se especifica cuando se desea enrutar explícitamente a Internet el tráfico destinado a un
prefijo de dirección, o si se desea que el tráfico destinado a los servicios de Azure con direcciones IP
públicas se conserve dentro de la red troncal de Azure.
En las rutas definidas por el usuario, no se pueden especificar Emparejamiento de VNet o
Vir tualNetworkSer viceEndpoint como tipo de próximo salto. Las rutas con los tipos de próximo salto
Emparejamiento de VNet o Vir tualNetworkSer viceEndpoint solo las crea Azure, al configurar un
emparejamiento de red virtual o un punto de conexión de servicio.

Tipos de próximo salto en las herramientas de Azure

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

C L I DE A Z URE Y P O W ERSH EL L C L I C L Á SIC A DE A Z URE Y

T IP O DE P RÓ XIM O SA LTO ( RESO URC E M A N A GER) P O W ERSH EL L ( C L Á SIC O )

Puerta de enlace de red virtual VirtualNetworkGateway VPNGateway

Virtual network VNetLocal VNETLocal (no disponible en la CLI

clásica en modo asm)

Internet Internet Internet (no disponible en la CLI

clásica en modo asm)

Aplicación virtual VirtualAppliance VirtualAppliance

None None Null (no disponible en la CLI clásica

en modo asm)

Emparejamiento de redes virtuales Emparejamiento de VNET No aplicable

de Azure

Puntos de conexión de servicio de VirtualNetworkServiceEndpoint No aplicable

red virtual

Border Gateway Protocol

Una puerta de enlace de red local puede intercambiar rutas con una puerta de enlace de red virtual de
Azure mediante el protocolo Border Gateway Protocol (BGP). El uso de BGP con una puerta de enlace de red
virtual de Azure depende del tipo seleccionado al crear la puerta de enlace. Si el tipo seleccionado fue:
ExpressRoute : debe usar BGP para anunciar rutas locales para el enrutador de Microsoft Edge. No
puede crear rutas definidas por el usuario para forzar el tráfico a la puerta de enlace de red virtual
ExpressRoute si implementa una puerta de enlace de red virtual como de tipo: ExpressRoute. Puede usar
las rutas definidas por el usuario para forzar el tráfico de Express Route a, por ejemplo, una aplicación
virtual de red.
VPN : opcionalmente, puede usar BGP. Para más información, consulte Información general de BGP con
puertas de enlace de VPN de Azure.
Al intercambiar rutas con Azure mediante BGP, se agrega una ruta independiente a la tabla de rutas de
todas las subredes de una red virtual para cada prefijo anunciado. La ruta se agrega con Puerta de enlace
de red virtual como origen y tipo de próximo salto.
La propagación del enrutamiento de ER y VPN Gateway se puede deshabilitar en una subred mediante una
propiedad en una tabla de rutas. Cuando intercambia rutas con Azure mediante BGP, las rutas no se
agregan a la tabla de rutas de todas las subredes con la propagación de la ruta de la puerta de enlace de
red virtual deshabilitada. La conectividad con las conexiones VPN se logra mediante rutas personalizadas
con un próximo salto de tipo Puerta de enlace de red virtual. La propagación de rutas no debe
deshabilitarse en GatewaySubnet. La puer ta de enlace no funcionará con esta opción
deshabilitada. Para más información, consulte How to disable Virtual network gateway route propagation
(Deshabilitar la propagación de rutas de la puerta de enlace de red virtual).

Selección de rutas por parte de Azure

Cuando se envía tráfico saliente desde una subred, Azure selecciona una ruta en función de la dirección IP
de destino y se usa el algoritmo de coincidencia de prefijo más largo. Por ejemplo, una tabla de rutas tiene
dos rutas: una ruta especifica el prefijo de dirección [Link]/24, mientras que la otra ruta especifica el
prefijo de dirección [Link]/16. Azure enruta el tráfico destinado a [Link], al tipo de próximo salto
especificado en la ruta con el prefijo de dirección [Link]/24, porque [Link]/24 es un prefijo más largo
que [Link]/16, aunque [Link] esté dentro de ambos prefijos. Azure enruta el tráfico destinado a [Link],
al tipo de próximo salto especificado en la ruta con el prefijo de dirección [Link]/16, porque [Link] no
está incluido en el prefijo de dirección [Link]/24, por consiguiente, la ruta con el prefijo de dirección
[Link]/16 es el prefijo más largo que coincide.
Si varias rutas contienen el mismo prefijo de dirección, Azure selecciona el tipo de ruta, en función de la
siguiente prioridad:
1. Ruta definida por el usuario
2. Ruta BGP
3. Ruta del sistema

NOTE
Las rutas de sistema para el tráfico relacionado con la red virtual, los emparejamientos de la red virtual o los puntos
de conexión de servicio de red virtual son las rutas preferidas, aunque las rutas BGP sean más específicas.

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

SO URC E P REF IJO S DE DIREC C IÓ N T IP O DE P RÓ XIM O SA LTO

Valor predeterminado [Link]/0 Internet

Usuario [Link]/0 Puerta de enlace de red virtual

Cuando el destino del tráfico es una dirección IP que está fuera de los prefijos de dirección de las otras rutas
de la tabla de rutas, Azure selecciona la ruta con el origen Usuario , porque las rutas definidas por el
usuario tienen mayor prioridad que las rutas predeterminadas del sistema.
Para ver una tabla de enrutamiento completa con explicaciones de las rutas, consulte el ejemplo de
enrutamiento.

Prefijo de dirección [Link]/0

Una ruta con el prefijo de dirección [Link]/0 indica a Azure cómo enrutar el tráfico destinado a una
dirección IP que no está dentro del prefijo de dirección de cualquier otra ruta en la tabla de rutas de una
subred. Cuando se crea una subred, Azure crea un ruta predeterminada para el prefijo de dirección
[Link]/0, con el tipo de próximo salto Internet . Si no reemplaza esta ruta, Azure enruta a Internet todo el
tráfico destinado a direcciones IP no incluidas en el prefijo de dirección de otra ruta. La excepción es que el
tráfico dirigido a las direcciones IP públicas de los servicios de Azure permanece en la red troncal de Azure
y no se enruta a Internet. Si reemplaza esta ruta por una ruta personalizado, el tráfico cuyo destino sean
direcciones que no estén dentro de los prefijos de dirección de cualquier otra ruta de la tabla de rutas se
envía a una aplicación virtual de red o a una puerta de enlace de red virtual, en función de lo que se
especifique en una ruta personalizada.
Si se reemplaza el prefijo de dirección [Link]/0, además del tráfico de salida de la subred que fluye a través
de la puerta de enlace de red virtual o de la aplicación virtual, se producen los siguientes cambios en el
enrutamiento predeterminado de Azure:
Azure envía todo el tráfico al tipo de próximo salto especificado en la ruta, lo que incluye el tráfico
destinado a las direcciones IP públicas de los servicios de Azure. Cuando el tipo de próximo salto de
la ruta con el prefijo de dirección [Link]/0 es Internet , el tráfico de la subred destinado a las
direcciones IP públicas de los servicios de Azure no sale de la red troncal de Azure,
independientemente de la región de Azure en que existan la red virtual o un recurso de servicio de
Azure. Sin embargo, cuando se crea una ruta BGP o definida por el usuario con un tipo de próximo
salto de puer ta de enlace de red vir tual o aplicación vir tual , todo el tráfico, lo que incluye el
tráfico enviado a las direcciones IP públicas de los servicios de Azure en el que no se hayan
habilitado puntos de conexión de servicio, se envía al tipo de próximo salto especificado en la ruta. Si
ha habilitado un punto de conexión para un servicio, el tráfico dirigido a dicho servicio no se enruta
al tipo de próximo salto en una ruta con el prefijo de dirección [Link]/0, porque los prefijos de
dirección del servicio se especifican en la ruta que Azure crea cuando se habilita el punto de
conexión de servicio y los prefijos de dirección del servicio son mayores que [Link]/0.
No puede acceder directamente a los recursos de la subred desde Internet. Puede acceder
indirectamente a los recursos de la subred desde Internet si el tráfico entrante pasa por el dispositivo
especificado por el tipo de próximo salto para una ruta con el prefijo de dirección [Link]/0 antes de
llegar al recurso en la red virtual. Si la ruta contiene los siguientes valores del tipo de salto próximo:
Aplicación vir tual : la aplicación debe:
Ser accesible desde Internet.
Tener una dirección IP pública asignada.
No tener una regla del grupo de seguridad de red asociada a él que impide la
comunicación con el dispositivo.
No denegar la comunicación.
Poder traducir y reenviar direcciones de red, o desviar el tráfico a través de un servidor
proxy al recurso de destino de la subred y devolver el tráfico a Internet.
Puer ta de enlace de red vir tual : si la puerta de enlace es una puerta de enlace de red
virtual ExpressRoute, un dispositivo local conectado a Internet puede traducir y reenviar
direcciones de red, o bien desviar el tráfico a través de un servidor proxy al recurso de destino
de la subred mediante emparejamiento privado de ExpressRoute.
Si la red virtual está conectada a una instancia de Azure VPN Gateway, no asocie una tabla de rutas a la
subred de la puerta de enlace que incluya una ruta con un destino [Link]/0. Si lo hace, puede que la puerta
de enlace no funcione correctamente. Para más información, consulte la pregunta ¿Por qué hay algunos
puertos abiertos en mi puerta de enlace de VPN? en las Preguntas más frecuentes sobre VPN Gateway.
Para obtener información sobre la implementación al usar puertas de enlace de redes virtuales entre
Internet y Azure, consulte Red perimetral entre Azure y un centro de datos local.

Ejemplo de enrutamiento
Para ilustrar los conceptos de este artículo, en las siguientes secciones se describen:
Un escenario con requisitos.
Las rutas personalizadas necesarias para cumplir los requisitos.
La tabla de rutas que existe para una subred que incluye las rutas predeterminadas y personalizadas
necesarias para cumplir los requisitos.

NOTE
Este ejemplo no pretende ser una implementación recomendada ni unas prácticas recomendadas. Más bien se
proporciona únicamente para ilustrar los conceptos de este artículo.

Requisitos
1. Implementar dos redes virtuales en la misma región de Azure y habilitar los recursos necesarios
para la comunicación entre las redes virtuales.
2. Habilitar una red local para comunicarse de forma segura con ambas redes virtuales mediante un
túnel VPN a través de Internet. Como alternativa, puede utilizarse una conexión ExpressRoute, pero
en este ejemplo se usa una conexión VPN.
3. Para una subred de una red virtual:
Forzar que todo el tráfico saliente de la subred, excepto el que va a Azure Storage y el de dentro
de la subred, fluya a través de una aplicación virtual de red, para su inspección y registro.
No inspeccionar el tráfico entre las direcciones IP privadas de la subred; permitir que el tráfico
fluya directamente entre todos los recursos.
Eliminar todo el tráfico saliente destinado a la otra red virtual.
Habilitar el tráfico saliente a Azure Storage para que fluya directamente al almacenamiento, sin
hacerle pasar por una aplicación virtual de red.
4. Permitir todo el tráfico entre las restantes subredes y las redes virtuales.
Implementación
La siguiente imagen muestra una implementación a través del modelo de implementación de Azure
Resource Manager que cumple los requisitos anteriores:
Las flechas muestran el flujo de tráfico.
Tablas de ruta
Subnet1
La tabla de rutas de Subnet1 en la imagen contiene las rutas siguientes:

N O M B RE DE
DIREC C IÓ N RUTA
T IP O DE IP DE DEF IN IDA
P REF IJO S DE P RÓ XIM O SIGUIEN T E P O R EL
ID SO URC E STAT E DIREC C IÓ N SA LTO SA LTO USUA RIO

1 Valor No válida [Link]/16 Virtual

predetermina network
do

2 Usuario Active [Link]/16 Aplicación [Link] Within-

virtual VNet1

3 Usuario Active [Link]/24 Virtual Within-

network Subnet1

4 Valor No válida [Link]/16 Emparejamie

predetermina nto de VNET
do

5 Valor No válida [Link]/16 Emparejamie

predetermina nto de VNET
do

6 Usuario Active [Link]/16 None ToVNet2-1-

Drop
 N O M B RE DE
DIREC C IÓ N RUTA
T IP O DE IP DE DEF IN IDA
P REF IJO S DE P RÓ XIM O SIGUIEN T E P O R EL
ID SO URC E STAT E DIREC C IÓ N SA LTO SA LTO USUA RIO

7 Usuario Active [Link]/16 None ToVNet2-2-

Drop

8 Valor No válida [Link]/16 Puerta de [X.X.X.X]

predetermina enlace de red
do virtual

9 Usuario Active [Link]/16 Aplicación [Link] To-On-Prem

virtual

10 Valor Active [X.X.X.X] VirtualNetwo

predetermina rkServiceEnd
do point

11 Valor No válida [Link]/0 Internet

predetermina
do

12 Usuario Active [Link]/0 Aplicación [Link] Default-NVA

virtual

A continuación encontrará una explicación de cada identificador de ruta:

1. Azure ha agregado automáticamente esta ruta a todas las subredes de Virtual-network-1, ya que
[Link]/16 es el único intervalo de direcciones definido en el espacio de direcciones de la red virtual. Si
la ruta definida por el usuario en la ruta ID2 no se ha creado, el tráfico enviado a cualquier dirección
entre [Link] y [Link] se enrutarían en la red virtual, ya que el prefijo es mayor que [Link]/0 y no
se encuentra dentro de los prefijos de direcciones de cualquiera de las otras rutas. Azure ha cambiado
automáticamente el estado de Activo a No válido, cuando se ha agregado ID2, una ruta definida por el
usuario, puesto que tiene el mismo prefijo que la ruta predeterminada y las rutas definidas por el
usuario reemplazan a las rutas predeterminadas. El estado de esta ruta sigue siendo Activo en Subnet2,
ya que la tabla de rutas en la que se encuentra la ruta definida por el usuario, ID2, no está asociada a
Subnet2.
2. Azure agregó esta ruta cuando una ruta definida por el usuario para el prefijo de red [Link]/16 se
asoció a la subred Subnet1 de la red virtual Virtual-network-1. La ruta definida por el usuario especifica
[Link] como dirección IP de la aplicación virtual, porque la dirección es la dirección IP privada
asignada a la máquina virtual de la aplicación virtual. La tabla de rutas en la que existe esta ruta no está
asociada a Subnet2, por lo que no aparece en la tabla de rutas de Subnet2. Esta ruta reemplaza la ruta
predeterminada del prefijo [Link]/16 (ID1), que enruta automáticamente el tráfico dirigido a [Link] y
[Link] dentro de la red virtual a través del tipo de próximo salto de la red virtual. Esta ruta existe
para cumplir el requisito 3, para forzar que todo el tráfico de salida pase por una aplicación virtual.
3. Azure agregó esta ruta cuando una ruta definida por el usuario para el prefijo de red [Link]/24 se
asoció a la subred Subnet1. El tráfico destinado a las direcciones entre [Link] y [Link] permanece
dentro de la subred, en lugar de enrutarse a la aplicación virtual especificada en la regla anterior (ID2),
ya que su prefijo es más largo que la ruta ID2. La tabla de rutas no estaba asociada a Subnet2, por lo que
no aparece en la tabla de rutas de Subnet2. Esta ruta reemplaza eficazmente la ruta ID2 para el tráfico de
Subnet1. Esta ruta existe para cumplir el requisito 3.
4. Azure agregó automáticamente de los ID 4 y 5 para todas las subredes de Virtual-network-1, cuando la
red virtual se emparejó con Virtual-network-2. Virtual-network-2 tiene dos intervalos de direcciones en
 su espacio de direcciones: [Link]/16 y [Link]/16, por lo que Azure agregó una ruta para cada uno. Si
no se crearon las rutas definidas por el usuario en los ID 6 y 7 de la ruta, el tráfico enviado a cualquier
dirección entre [Link]-[Link] y [Link]-[Link] se enrutaría a la red virtual emparejada, ya
que el prefijo es mayor que [Link]/0 y no se encuentra dentro de los prefijos de direcciones de las otras
rutas. Azure ha cambiado automáticamente el estado de Activo a No válido, cuando se han agregado las
rutas de los ID 6 y 7, ya que tienen el mismo prefijo que las rutas de los ID 4 y 5, y las rutas definidas por
el usuario reemplazan a las rutas predeterminadas. El estado de las rutas de los ID 4 y 5 sigue siendo
Activo en Subnet2, ya que la tabla de rutas en la que se encuentran la rutas definidas por el usuario en
los ID 6 y 7 no está asociada a Subred2. Se ha creado un emparejamiento de red virtual para cumplir el
requisito 1.
5. La misma explicación que para ID4.
6. Azure agregó esta ruta y la ruta de ID7, cuando las rutas definidas por el usuario para los prefijos de
dirección [Link]/16 y [Link]/16 se asociaron a la subred Subnet1. Azure elimina el tráfico destinado a
direcciones entre [Link]-[Link] y [Link]-[Link], en lugar de enrutarlo a la red virtual
emparejada, porque las rutas definidas por el usuario reemplazan las rutas predeterminadas. Las rutas
no están asociadas a Subnet2, por lo que no aparecen en la tabla de rutas de Subnet2. Las rutas
reemplazan las rutas ID4 y ID5 en el caso del tráfico que sale del Subnet1. Las rutas ID6 y ID7 existen
para satisfacer el requisito 3 de eliminación del tráfico destinado a la otra red virtual.
7. La misma explicación que para ID6.
8. Azure agregó automáticamente esta ruta para todas las subredes de Virtual-network-1 cuando se creó
una puerta de enlace de red virtual del tipo VPN en la red virtual. Azure agregó la dirección IP pública de
la puerta de enlace de red virtual a la raba de rutas. El tráfico enviado a cualquier dirección entre
[Link] y [Link] se enruta a la puerta de enlace de red virtual. El prefijo es más largo que
[Link]/0 y no está dentro de los prefijos de dirección de las restantes rutas. Se ha creado una puerta de
enlace de red virtual para cumplir el requisito 2.
9. Azure agregó esta ruta cuando una ruta definida por el usuario para el prefijo de red [Link]/16 se
agregó a la tabla de rutas asociada a Subnet1. Esta ruta reemplaza ID8. La ruta envía todo el tráfico
destinado a la red local a una NVA para su inspección, en lugar de enrutarlo directamente al entorno
local. Esta ruta se ha creado para cumplir el requisito 3.
10. Azure ha agregado automáticamente esta ruta a la subred cuando se ha habilitado un punto de conexión
de servicio para un servicio de Azure para la subred. Azure enruta el tráfico de la subred a una dirección
IP pública del servicio, a través de la red de la infraestructura de Azure. El prefijo es más largo que
[Link]/0 y no está dentro de los prefijos de dirección de las restantes rutas. Se ha creado un punto de
conexión de servicio para cumplir el requisito 3, con el fin de habilitar que el tráfico destinado a Azure
Storage que fluya directamente a dicho servicio.
11. Azure ha agregado automáticamente esta ruta a la tabla de rutas de todas las subredes de Virtual-
network-1 y Virtual-network-2. El prefijo de dirección [Link]/0 es el más corto. Todo el tráfico enviado a
direcciones de un prefijo de dirección más largo se enrutan en función de otras rutas. De forma
predeterminada, Azure enruta todo el tráfico destinado a aquellas direcciones que no sean las
especificadas en una de las otras rutas a Internet. Azure ha cambiado automáticamente el estado de
Activo a No válido para la subred Subnet1 cuando una ruta definida por el usuario para el prefijo de
dirección [Link]/0 (ID12) se ha asociado a la subred. El estado de esta ruta sigue siendo Activo para las
restantes subredes de ambas redes virtuales, ya que la ruta no está asociada a otras subredes de otras
redes virtuales.
12. Azure agregó esta ruta cuando una ruta definida por el usuario para el prefijo de red [Link]/0 se asoció
a la subred Subnet1. La ruta definida por el usuario especifica [Link] como dirección IP de la
aplicación virtual. Esta ruta no está asociada a Subnet2, por lo que no aparece en la tabla de rutas de
Subnet2. Todo el tráfico de cualquier dirección no incluida en los prefijos de dirección de cualquiera de
las otras rutas se envía a la aplicación virtual. La adición de esta ruta ha cambiado el estado de la ruta
predeterminada para el prefijo de dirección [Link]/0 (ID11) de Activo a No válido para Subnet1, porque
una ruta definida por el usuario reemplaza a una ruta predeterminada. Esta ruta existe para cumplir el
 tercer requisito.
Subnet2
La tabla de rutas de Subnet2 en la imagen contiene las rutas siguientes:

P REF IJO S DE T IP O DE P RÓ XIM O DIREC C IÓ N IP DE

SO URC E STAT E DIREC C IÓ N SA LTO SIGUIEN T E SA LTO

Valor Active [Link]/16 Virtual network

predeterminado

Valor Active [Link]/16 Emparejamiento de

predeterminado VNET

Valor Active [Link]/16 Emparejamiento de

predeterminado VNET

Valor Active [Link]/16 Puerta de enlace de [X.X.X.X]

predeterminado red virtual

Valor Active [Link]/0 Internet

predeterminado

Valor Active [Link]/8 None

predeterminado

Valor Active [Link]/10 None

predeterminado

Valor Active [Link]/16 None

predeterminado

La tabla de rutas de Subnet2 contiene todas las rutas predeterminadas creadas por Azure y el
emparejamiento de VNet opcional y las rutas opcionales de la puerta de enlace de red virtual. Azure ha
agregado las rutas opcionales a todas las subredes de la red virtual cuando tanto la puerta de enlace como
el emparejamiento se han agregado a la red virtual. Azure ha quitado las rutas de los prefijos de dirección
[Link]/8, [Link]/16 y [Link]/10 de la tabla de rutas de Subnet1 cuando la ruta definida por el
usuario del prefijo de dirección [Link]/0 se ha agregado a Subnet1.

Pasos siguientes
Creación de una ruta definida por el usuario - Azure Portal
Configuración de BGP para Azure VPN Gateway con PowerShell
Uso de BGP con ExpressRoute
Solución de problemas de rutas mediante Azure Portal. Las tablas de rutas definidas por el usuario solo
muestran las rutas definidas por el usuario, no las rutas predeterminada y de BGP de una subred. La
visualización de todas las rutas muestra las rutas predeterminada, de BGP y definidas por el usuario de
la subred en que se encuentra una interfaz de red.
Determine el tipo de próximo salto entre una máquina virtual y una dirección IP de destino. La
característica de próximo salto de Azure Network Watcher permite determinar si el tráfico sale de una
subred y se enruta al lugar en que cree que debería estar.
 Interoperabilidad en Azure: Prueba de configuración
23/09/2020 • 10 minutes to read • Edit Online

En este artículo se describe una configuración de prueba que permite analizar cómo los servicios de redes de Azure
interactúan en el nivel del plano de control y en el nivel del plano de datos. Echemos un vistazo a los componentes
de red de Azure:
Azure ExpressRoute : use el emparejamiento privado de Azure ExpressRoute para conectar directamente
espacios IP privados de la red local a las implementaciones de la red virtual de Azure. ExpressRoute puede
ayudarle a lograr un ancho de banda mayor y una conexión privada. Muchos asociados de ExpressRoute ofrecen
conectividad de ExpressRoute con contratos de nivel de servicio. Para más información acerca de ExpressRoute y
su configuración, consulte Información general sobre ExpressRoute.
VPN de sitio a sitio : puede usar Azure VPN Gateway como una VPN de sitio a sitio para conectar de forma
segura una red local a Azure a través de Internet o ExpressRoute. Para más información acerca de cómo
configurar una VPN de sitio a sitio para conectarse a Azure, consulte Configurar VPN Gateway.
Emparejamiento de VNET : use el emparejamiento de red virtual (VNet) para establecer conectividad entre las
redes virtuales de Azure Virtual Network. Para más información sobre el emparejamiento de VNET, consulte el
tutorial acerca del emparejamiento de redes virtuales.

Prueba de configuración
En la siguiente ilustración se muestra la configuración de prueba:

La pieza central de la configuración de prueba es la red virtual del concentrador en la región 1 de Azure. La red
virtual del concentrador se conecta a otras redes de las siguientes maneras:
La red virtual del concentrador se conecta a la red virtual de radio mediante el uso del emparejamiento de redes
virtuales. La red virtual de radio tiene acceso remoto a las dos puertas de enlace de la red virtual del
concentrador.
La red virtual del concentrador está conectada a la red virtual de sucursal mediante una VPN de sitio a sitio. La
conectividad usa EBGP para intercambiar las rutas.
 La red virtual del concentrador se conecta a la red local Ubicación 1 mediante el uso del emparejamiento
privado de ExpressRoute1 como la ruta de acceso principal. Asimismo, usa la conectividad VPN de sitio a sitio
como ruta de acceso de respaldo. En el resto de este artículo, se hará referencia a este circuito de ExpressRoute
como ExpressRoute 1. De forma predeterminada, los circuitos de ExpressRoute proporcionan conectividad
redundante para alta disponibilidad. En ExpressRoute1, la subinterfaz del enrutador perimetral del cliente (CE)
secundario que accede al Microsoft Enterprise Edge Router (MSEE) secundario está deshabilitada. Esto se indica
mediante una línea de color rojo sobre la flecha de doble línea en el diagrama anterior.
La red virtual del concentrador se conecta a la red local Ubicación 2 mediante el uso de otro emparejamiento
privado de ExpressRoute. En el resto de este artículo, se hará referencia a este segundo circuito de ExpressRoute
como ExpressRoute 2.
ExpressRoute1 también conecta la red virtual del concentrador y la red local Ubicación 1 a una red virtual
remota en la región 2 de Azure.

Uso simultáneo de ExpressRoute y la conectividad VPN de sitio a sitio

VPN de sitio a sitio con ExpressRoute
Puede configurar una VPN de sitio a sitio mediante el emparejamiento de Microsoft con ExpressRoute para
intercambiar datos de forma privada entre la red local y las redes virtuales de Azure. Esta configuración le asegura
un intercambio de datos con confidencialidad, autenticidad, integridad y antirreproducción. Para más información
acerca de cómo configurar una VPN IPsec de sitio a sitio en modo de túnel con emparejamiento de Microsoft de
ExpressRoute, consulte Configuración de una VPN de sitio a sitio a través del emparejamiento de Microsoft de
ExpressRoute.
La limitación principal de la configuración de una VPN de sitio a sitio que use el emparejamiento de Microsoft es el
rendimiento. El rendimiento a través del túnel IPsec está limitado por la capacidad de la puerta de enlace de VPN. El
rendimiento de la puerta de enlace de VPN es menor que el de ExpressRoute. En este escenario, el uso del túnel
IPsec para el tráfico de seguridad alta y con emparejamiento privado para el tráfico restante ayuda a optimizar el
uso de ancho de banda de ExpressRoute.
VPN de sitio a sitio como ruta de acceso de conmutación por error para ExpressRoute
ExpressRoute sirve como par de circuito redundante para garantizar la alta disponibilidad. Puede configurar la
conectividad de ExpressRoute con redundancia geográfica en diferentes regiones de Azure. Además, como se ha
demostrado en la configuración de prueba, dentro de una región de Azure puede usar una VPN de sitio a sitio para
crear una ruta de acceso de conmutación por error para la conectividad de ExpressRoute. Cuando se anuncian los
mismos prefijos a través de ExpressRoute y VPN de sitio a sitio, Azure da prioridad a ExpressRoute. Para evitar el
enrutamiento asimétrico entre ExpressRoute y VPN de sitio a sitio, la configuración de la red local también debe
tener prioridad mediante el uso de la conectividad ExpressRoute antes de VPN de sitio a sitio.
Para más información acerca de cómo configurar conexiones coexistentes de ExpressRoute y una VPN de sitio a
sitio, consulte el artículo sobre la coexistencia de conexiones de ExpressRoute y de sitio a sitio.

Ampliación de la conectividad de back-end a redes virtuales de radio y

ubicaciones de sucursal
Conectividad de red virtual de radio mediante el emparejamiento de redes virtuales
La arquitectura de red virtual de tipo hub-and-spoke se usa ampliamente. El centro de conectividad es una red
virtual de Azure que actúa como punto central de conectividad entre las redes virtuales de radio y la red local. Los
radios son redes virtuales que se emparejan con el centro de conectividad y sirven para aislar las cargas de trabajo.
El tráfico fluye entre el centro de datos local y el concentrador a través de una conexión de ExpressRoute o VPN.
Para más información acerca de la arquitectura, consulte Implementación de una topología de red en estrella tipo
hub-and-spoke en Azure.
En el emparejamiento de redes virtuales dentro de una región, las redes virtuales de radio pueden usar las puertas
de enlace del centro de conectividad (tanto de VPN como de ExpressRoute) para comunicarse con las redes
remotas.
Conectividad de red virtual de sucursal mediante VPN de sitio a sitio
Es posible que quiera redes virtuales en rama, que están en regiones diferentes, y redes locales para comunicarse
entre sí a través de una red virtual de centro de conectividad. La solución de Azure nativa para esta configuración
es la conectividad VPN de sitio a sitio mediante una VPN. Una alternativa es usar una aplicación virtual de red
(NVA) para el enrutamiento en el centro de conectividad.
Para más información, consulte ¿Qué es VPN Gateway? e Implementación de aplicaciones virtuales de red de alta
disponibilidad.

Pasos siguientes
Obtenga información acerca de los detalles de configuración de la topología de prueba.
Más información acerca del análisis del plano de control de la configuración de prueba y de las vistas de otras
redes virtuales y VLAN de la topología.
Obtenga información acerca del análisis del plano de datos de la configuración de prueba y de las vistas de las
características de supervisión de red de Azure.
Consulte las preguntas más frecuentes de ExpressRoute para información acerca de:
Cuántos circuitos de ExpressRoute puede conectar a una puerta de enlace de ExpressRoute.
Cuántas puertas de enlace de ExpressRoute puede conectar a un circuito de ExpressRoute.
Los límites de escala de ExpressRoute.
 Interoperabilidad de las características de
conectividad del back-end de Azure: Detalles de
configuración de prueba
23/09/2020 • 12 minutes to read • Edit Online

En este artículo se describen los detalles de la configuración de la prueba. La configuración de prueba ayuda a
analizar cómo los servicios de redes de Azure interactúan en el nivel del plano de control y en el nivel del plano de
datos.

Conectividad de red virtual de radio mediante el emparejamiento de

redes virtuales
En la siguiente ilustración se muestran los detalles del emparejamiento de redes virtuales de Azure de una red
virtual de radio. Para información sobre cómo configurar el emparejamiento entre dos redes virtuales, consulte el
artículo sobre la administración del emparejamiento de redes virtuales. Si quiere que la red virtual de radio use las
puertas de enlace conectadas a la red virtual del centro de conectividad, seleccione Usar puer tas de enlace
remotas .
En la siguiente ilustración se muestran los detalles del emparejamiento de redes virtuales del centro de
conectividad. Si quiere que la red virtual del centro permita que la red virtual de radio use las puertas de enlace del
centro, seleccione Allow gateway transit (Permitir tránsito de puerta de enlace).
Conectividad de red virtual de sucursal mediante una VPN de sitio a
sitio
Configure la conectividad VPN de sitio a sitio entre las redes virtuales del centro de conectividad y de sucursal
mediante las puertas de enlace VPN de Azure VPN Gateway. De forma predeterminada, las puertas de enlace VPN
y de Azure ExpressRoute usan el número de sistema autónomo (ASN) privado 65515 . Este valor de ASN se puede
cambiar en VPN Gateway. En la configuración de prueba, el valor ASN de la puerta de enlace VPN de red virtual de
sucursal se cambia a 65516 para habilitar el enrutamiento EBGP entre el centro de conectividad y la red virtual de
sucursal.
Conectividad local de la ubicación 1 con ExpressRoute y VPN de sitio a
sitio
Detalles de configuración de la ubicación 1 (ExpressRoute )
En la siguiente ilustración se muestra la configuración del circuito ExpressRoute en la región 1 de Azure hacia los
enrutadores del lado del cliente (CE) locales de la ubicación 1:

En la siguiente ilustración se muestra la configuración de conexión entre el circuito ExpressRoute 1 y el centro de

conectividad:
En la siguiente lista se muestra la configuración del enrutador del lado del cliente principal para la conectividad de
emparejamiento privado de ExpressRoute. (En esta configuración de prueba se utilizan enrutadores Cisco ASR1000
en el lado del cliente). Cuando los circuitos de VPN de sitio a sitio y ExpressRoute se configuran en paralelo para
conectar una red local con Azure, Azure da prioridad al circuito de ExpressRoute de forma predeterminada. Para
evitar el enrutamiento asimétrico, la red local también debe dar prioridad a la conectividad de ExpressRoute sobre
VPN de sitio a sitio. La siguiente configuración establece prioridades mediante el atributo BGP local-preference :

interface TenGigabitEthernet0/0/0.300
description Customer 30 private peering to Azure
encapsulation dot1Q 30 second-dot1q 300
ip vrf forwarding 30
ip address [Link] [Link]
!
interface TenGigabitEthernet1/0/0.30
description Customer 30 to south bound LAN switch
encapsulation dot1Q 30
ip vrf forwarding 30
ip address [Link] [Link]
ip ospf network point-to-point
!
router ospf 30 vrf 30
router-id [Link]
redistribute bgp 65021 subnets route-map BGP2OSPF
network [Link] [Link] area [Link]
default-information originate always
default-metric 10
!
router bgp 65021
!
address-family ipv4 vrf 30
network [Link] mask [Link]
neighbor [Link] remote-as 12076
neighbor [Link] activate
neighbor [Link] next-hop-self
neighbor [Link] soft-reconfiguration inbound
neighbor [Link] route-map prefer-ER-over-VPN in
neighbor [Link] prefix-list Cust30_to_Private out
exit-address-family
!
route-map prefer-ER-over-VPN permit 10
set local-preference 200
!
ip prefix-list Cust30_to_Private seq 10 permit [Link]/25
!

Detalles de configuración de VPN de sitio a sitio

En la siguiente lista se muestra la configuración del enrutador del lado del cliente principal para la conectividad
VPN de sitio a sitio:
 crypto ikev2 proposal Cust30-azure-proposal
encryption aes-cbc-256 aes-cbc-128 3des
integrity sha1
group 2
!
crypto ikev2 policy Cust30-azure-policy
match address local [Link]
proposal Cust30-azure-proposal
!
crypto ikev2 keyring Cust30-azure-keyring
peer azure
address [Link]
pre-shared-key local IamSecure123
pre-shared-key remote IamSecure123
!
crypto ikev2 profile Cust30-azure-profile
match identity remote address [Link] [Link]
identity local address [Link]
authentication local pre-share
authentication remote pre-share
keyring local Cust30-azure-keyring
!
crypto ipsec transform-set Cust30-azure-ipsec-proposal-set esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile Cust30-azure-ipsec-profile
set transform-set Cust30-azure-ipsec-proposal-set
set ikev2-profile Cust30-azure-profile
!
interface Loopback30
ip address [Link] [Link]
!
interface Tunnel30
ip vrf forwarding 30
ip address [Link] [Link]
tunnel source Loopback30
tunnel mode ipsec ipv4
tunnel destination [Link]
tunnel protection ipsec profile Cust30-azure-ipsec-profile
!
router bgp 65021
!
address-family ipv4 vrf 30
network [Link] mask [Link]
neighbor [Link] remote-as 65515
neighbor [Link] ebgp-multihop 5
neighbor [Link] update-source Tunnel30
neighbor [Link] activate
neighbor [Link] soft-reconfiguration inbound
exit-address-family
!
ip route vrf 30 [Link] [Link] Tunnel30

Conectividad local de la ubicación 2 con ExpressRoute

Un segundo circuito de ExpressRoute, más próximo a la ubicación 2 local, conecta la ubicación 2 local al centro de
conectividad. En la siguiente ilustración se muestra la segunda configuración de ExpressRoute:
En la siguiente ilustración se muestra la configuración de la conexión entre el segundo circuito de ExpressRoute y
el centro de conectividad:

ExpressRoute 1 conecta el centro de conectividad y la ubicación 1 local con una red virtual remota de otra región
de Azure:

Uso simultáneo de ExpressRoute y la conectividad VPN de sitio a sitio

VPN de sitio a sitio con ExpressRoute
Puede configurar una VPN de sitio a sitio mediante el emparejamiento de Microsoft con ExpressRoute para
intercambiar datos de forma privada entre la red local y las redes virtuales de Azure. Esta configuración le asegura
un intercambio de datos con confidencialidad, autenticidad, integridad y antirreproducción. Para más información
acerca de cómo configurar una VPN IPsec de sitio a sitio en modo de túnel con emparejamiento de Microsoft de
ExpressRoute, consulte Configuración de una VPN de sitio a sitio a través del emparejamiento de Microsoft de
ExpressRoute.
La limitación principal de la configuración de una VPN de sitio a sitio que use el emparejamiento de Microsoft es el
rendimiento. El rendimiento a través del túnel IPsec está limitado por la capacidad de la puerta de enlace de VPN.
El rendimiento de la puerta de enlace de VPN es menor que el de ExpressRoute. En este escenario, el uso del túnel
IPsec para el tráfico de seguridad alta y con emparejamiento privado para el tráfico restante ayuda a optimizar el
uso de ancho de banda de ExpressRoute.
VPN de sitio a sitio como ruta de acceso de conmutación por error para ExpressRoute
ExpressRoute sirve como par de circuito redundante para garantizar la alta disponibilidad. Puede configurar la
conectividad de ExpressRoute con redundancia geográfica en diferentes regiones de Azure. Además, como se ha
demostrado en la configuración de prueba, dentro de una región de Azure puede usar una VPN de sitio a sitio para
crear una ruta de acceso de conmutación por error para la conectividad de ExpressRoute. Cuando se anuncian los
mismos prefijos a través de ExpressRoute y VPN de sitio a sitio, Azure da prioridad a ExpressRoute. Para evitar el
enrutamiento asimétrico entre ExpressRoute y VPN de sitio a sitio, la configuración de la red local también debe
tener prioridad mediante el uso de la conectividad ExpressRoute antes de VPN de sitio a sitio.
Para más información acerca de cómo configurar conexiones coexistentes de ExpressRoute y una VPN de sitio a
sitio, consulte el artículo sobre la coexistencia de conexiones de ExpressRoute y de sitio a sitio.

Ampliación de la conectividad de back-end a redes virtuales de radio y

ubicaciones de sucursal
Conectividad de red virtual de radio mediante el emparejamiento de redes virtuales
La arquitectura de red virtual de tipo hub-and-spoke se usa ampliamente. El centro de conectividad es una red
virtual de Azure que actúa como punto central de conectividad entre las redes virtuales de radio y la red local. Los
radios son redes virtuales que se emparejan con el centro de conectividad y sirven para aislar las cargas de
trabajo. El tráfico fluye entre el centro de datos local y el concentrador a través de una conexión de ExpressRoute o
VPN. Para más información acerca de la arquitectura, consulte Implementación de una topología de red en estrella
tipo hub-and-spoke en Azure.
En el emparejamiento de redes virtuales dentro de una región, las redes virtuales de radio pueden usar las puertas
de enlace del centro de conectividad (tanto de VPN como de ExpressRoute) para comunicarse con las redes
remotas.
Conectividad de red virtual de sucursal mediante VPN de sitio a sitio
Es posible que quiera redes virtuales en rama, que están en regiones diferentes, y redes locales para comunicarse
entre sí a través de una red virtual de centro de conectividad. La solución de Azure nativa para esta configuración
es la conectividad VPN de sitio a sitio mediante una VPN. Una alternativa es usar una aplicación virtual de red
(NVA) para el enrutamiento en el centro de conectividad.
Para más información, consulte ¿Qué es VPN Gateway? e Implementación de aplicaciones virtuales de red de alta
disponibilidad.

Pasos siguientes
Más información acerca del análisis del plano de control de la configuración de prueba y de las vistas de otras
redes virtuales y VLAN de la topología.
Más información acerca del análisis del plano de datos de la configuración de prueba y de las vistas de las
características de supervisión de red de Azure.
Consulte las preguntas más frecuentes de ExpressRoute para información acerca de:
Cuántos circuitos de ExpressRoute puede conectar a una puerta de enlace de ExpressRoute.
Cuántas puertas de enlace de ExpressRoute puede conectar a un circuito de ExpressRoute.
Los límites de escala de ExpressRoute.
 Interoperabilidad en Azure: Análisis del plano de
control
23/09/2020 • 10 minutes to read • Edit Online

En este artículo se describe el análisis del plano de control de la configuración de la prueba. También puede revisar
la configuración de la prueba y el análisis del plano de control de la configuración de la prueba.
En esencia, el análisis del plano de control examina las rutas que se intercambian entre las redes dentro de una
topología. El análisis del plano de control puede ayudar a entender la forma en la que cada red ve la topología.

Perspectiva de red virtual de tipo hub-and-spoke

En la siguiente ilustración se muestra la red desde la perspectiva de un centro de conectividad y una red virtual de
radio (resaltada en azul). En la ilustración también se muestra el número de sistema autónomo (ASN) de las redes
y rutas que se intercambian entre las distintas redes:

Tenga en cuenta que el ASN de la puerta de enlace de Azure ExpressRoute de la red virtual difiere del de los
enrutadores de Microsoft Enterprise Edge (MSEE). Generalmente, la puerta de enlace de ExpressRoute usa un ASN
privado (con valor 65515 ) y los MSEE, uno público (12076 ). Al configurar el emparejamiento de ExpressRoute,
como MSEE es del mismo nivel, se usa 12076 como ASN del mismo nivel. Del lado de Azure, MSEE establece
emparejamiento de BGP externo con la puerta de enlace de ExpressRoute. El emparejamiento BGP externo dual
que el MSEE establece para cada emparejamiento de ExpressRoute es transparente en el nivel del plano de control.
Por tanto, al visualizar una tabla de enrutamiento de ExpressRoute, se ve el valor de ASN de la puerta de enlace de
ExpressRoute de la red virtual para los prefijos de esta.
En la siguiente ilustración se muestra una tabla de enrutamiento de ExpressRoute de ejemplo:
En Azure, el valor de ASN solo es significativo para el emparejamiento. De forma predeterminada, el valor de ASN
de la puerta de enlace tanto de ExpressRoute como de VPN en Azure VPN Gateway es 65515 .

Perspectiva de la ubicación 1 local y de la red virtual remota a través de

ExpressRoute 1
Tanto la ubicación 1 local como la red virtual remota están conectadas al centro de conectividad a través de
ExpressRoute 1. Comparten la misma perspectiva de la topología, como se muestra en el siguiente diagrama:

Perspectiva de la ubicación 1 local y de la red virtual remota a través de

ExpressRoute 1
Tanto la ubicación 1 local como la red virtual de la rama están conectadas a una puerta de enlace de centro de
conectividad a través de una VPN de sitio a sitio. Comparten la misma perspectiva de la topología, como se
muestra en el siguiente diagrama:
Perspectiva de la ubicación 2 local
La ubicación 2 local está conectada al centro de conectividad a través del emparejamiento privado de ExpressRoute
2:

Uso simultáneo de ExpressRoute y la conectividad VPN de sitio a sitio

VPN de sitio a sitio con ExpressRoute
Puede configurar una VPN de sitio a sitio mediante el emparejamiento de Microsoft con ExpressRoute para
intercambiar datos de forma privada entre la red local y las redes virtuales de Azure. Esta configuración le asegura
un intercambio de datos con confidencialidad, autenticidad, integridad y antirreproducción. Para más información
acerca de cómo configurar una VPN IPsec de sitio a sitio en modo de túnel con emparejamiento de Microsoft de
ExpressRoute, consulte Configuración de una VPN de sitio a sitio a través del emparejamiento de Microsoft de
ExpressRoute.
La limitación principal de la configuración de una VPN de sitio a sitio que use el emparejamiento de Microsoft es el
rendimiento. El rendimiento a través del túnel IPsec está limitado por la capacidad de la puerta de enlace de VPN.
El rendimiento de la puerta de enlace de VPN es menor que el de ExpressRoute. En este escenario, el uso del túnel
IPsec para el tráfico de seguridad alta y con emparejamiento privado para el tráfico restante ayuda a optimizar el
uso de ancho de banda de ExpressRoute.
VPN de sitio a sitio como ruta de acceso de conmutación por error para ExpressRoute
ExpressRoute sirve como par de circuito redundante para garantizar la alta disponibilidad. Puede configurar la
conectividad de ExpressRoute con redundancia geográfica en diferentes regiones de Azure. Además, como se ha
demostrado en la configuración de prueba, dentro de una región de Azure puede usar una VPN de sitio a sitio para
crear una ruta de acceso de conmutación por error para la conectividad de ExpressRoute. Cuando se anuncian los
mismos prefijos a través de ExpressRoute y VPN de sitio a sitio, Azure da prioridad a ExpressRoute. Para evitar el
enrutamiento asimétrico entre ExpressRoute y VPN de sitio a sitio, la configuración de la red local también debe
tener prioridad mediante el uso de la conectividad ExpressRoute antes de VPN de sitio a sitio.
Para más información acerca de cómo configurar conexiones coexistentes de ExpressRoute y una VPN de sitio a
sitio, consulte el artículo sobre la coexistencia de conexiones de ExpressRoute y de sitio a sitio.

Ampliación de la conectividad de back-end a redes virtuales de radio y

ubicaciones de sucursal
Conectividad de red virtual de radio mediante el emparejamiento de redes virtuales
La arquitectura de red virtual de tipo hub-and-spoke se usa ampliamente. El centro de conectividad es una red
virtual de Azure que actúa como punto central de conectividad entre las redes virtuales de radio y la red local. Los
radios son redes virtuales que se emparejan con el centro de conectividad y sirven para aislar las cargas de
trabajo. El tráfico fluye entre el centro de datos local y el concentrador a través de una conexión de ExpressRoute o
VPN. Para más información acerca de la arquitectura, consulte Implementación de una topología de red en estrella
tipo hub-and-spoke en Azure.
En el emparejamiento de redes virtuales dentro de una región, las redes virtuales de radio pueden usar las puertas
de enlace del centro de conectividad (tanto de VPN como de ExpressRoute) para comunicarse con las redes
remotas.
Conectividad de red virtual de sucursal mediante VPN de sitio a sitio
Es posible que quiera redes virtuales en rama, que están en regiones diferentes, y redes locales para comunicarse
entre sí a través de una red virtual de centro de conectividad. La solución de Azure nativa para esta configuración
es la conectividad VPN de sitio a sitio mediante una VPN. Una alternativa es usar una aplicación virtual de red
(NVA) para el enrutamiento en el centro de conectividad.
Para más información, consulte ¿Qué es VPN Gateway? e Implementación de aplicaciones virtuales de red de alta
disponibilidad.

Pasos siguientes
Más información acerca del análisis del plano de datos de la configuración de prueba y de las vistas de las
características de supervisión de red de Azure.
Consulte las preguntas más frecuentes de ExpressRoute para información acerca de:
Cuántos circuitos de ExpressRoute puede conectar a una puerta de enlace de ExpressRoute.
Cuántas puertas de enlace de ExpressRoute puede conectar a un circuito de ExpressRoute.
Los límites de escala de ExpressRoute.
 Interoperabilidad en Azure: Análisis del plano de
datos
23/09/2020 • 31 minutes to read • Edit Online

En este artículo se describe el análisis del plano de datos de la configuración de prueba. También puede revisar la
configuración de la prueba y el análisis del plano de datos de la configuración de prueba.
En el análisis del plano de datos se examina la ruta de acceso de los paquetes que se desplazan desde una red local
(LAN o red virtual) a otra dentro de una topología. Es posible que la ruta de acceso de datos entre dos redes
locales no sea necesariamente simétrica. Por tanto, en este artículo se va a analizar la ruta de reenvío desde una
red local a otra de forma independiente a la ruta de acceso inversa.

Ruta de acceso de datos desde el centro de conectividad

Ruta a la red virtual de radio
El emparejamiento de redes virtuales emula la funcionalidad de puente de red entre las dos redes virtuales
emparejadas. A continuación se muestra la salida de traceroute desde un centro de conectividad a una máquina
virtual de la red virtual de radio:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 2 ms 1 ms 1 ms [Link]

Trace complete.

En la siguiente ilustración se muestra la vista de conexión gráfica del centro de conectividad y la red virtual de
radio desde la perspectiva de Azure Network Watcher:

Ruta de acceso a la red virtual de sucursal

A continuación se muestra la salida de traceroute desde un centro de conectividad a una máquina virtual de la red
virtual de sucursal:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 1 ms 1 ms 1 ms [Link]
2 * * * Request timed out.
3 2 ms 2 ms 2 ms [Link]

Trace complete.

En este comando traceroute, el primer salto es la puerta de enlace de VPN en la instancia de Azure VPN Gateway
del centro de conectividad. El segundo salto es la puerta de enlace de VPN de la red virtual de sucursal. La
dirección IP de la puerta de enlace de VPN de la red virtual de sucursal no se anuncia en el centro de conectividad.
El tercer salto es la máquina virtual de la red virtual de sucursal.
En la siguiente ilustración se muestra la vista de conexión gráfica del centro de conectividad y la red virtual de
sucursal desde la perspectiva de Network Watcher:

Para la misma conexión, en la siguiente ilustración se muestra la vista de cuadrícula de Network Watcher:

Ruta de acceso a la ubicación 1 local

A continuación se muestra la salida de traceroute desde un centro de conectividad a una máquina virtual de la
ubicación 1 local:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 2 ms 2 ms 2 ms [Link]
2 * * * Request timed out.
3 * * * Request timed out.
4 2 ms 2 ms 2 ms [Link]

Trace complete.

En este comando traceroute, el primer salto es el punto de conexión del túnel de puerta de enlace de Azure
ExpressRoute a un enrutador de Microsoft Enterprise Edge (MSEE). El segundo y tercer salto son las direcciones IP
del enrutador del lado del cliente y la LAN de la ubicación 1 local. Estas direcciones IP no se anuncian en el centro
de conectividad. El cuarto salto es la máquina virtual de la ubicación 1 local.
Ruta de acceso a la ubicación 2 local
A continuación se muestra la salida de traceroute desde un centro de conectividad a una máquina virtual de la
ubicación 2 local:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 76 ms 75 ms 75 ms [Link]
2 * * * Request timed out.
3 * * * Request timed out.
4 75 ms 75 ms 75 ms [Link]

Trace complete.

En este comando traceroute, el primer salto es el punto de conexión del túnel de puerta de enlace de ExpressRoute
a un enrutador MSEE. El segundo y tercer salto son las direcciones IP del enrutador del lado del cliente y la LAN de
la ubicación 2 local. Estas direcciones IP no se anuncian en el centro de conectividad. El cuarto salto es la máquina
virtual de la ubicación 2 local.
Ruta de acceso a la red virtual remota
A continuación se muestra la salida de traceroute desde un centro de conectividad a una máquina virtual de la red
virtual remota:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 2 ms 2 ms 2 ms [Link]
2 * * * Request timed out.
3 69 ms 68 ms 69 ms [Link]

Trace complete.

En este comando traceroute, el primer salto es el punto de conexión del túnel de puerta de enlace de ExpressRoute
a un enrutador MSEE. El segundo salto es la dirección IP de la puerta de enlace de la red virtual remota. El intervalo
IP del segundo salto no se anuncia en el centro de conectividad. El tercer salto es la máquina virtual de la red
virtual remota.

Ruta de acceso de datos de la red virtual de radio

La red virtual de radio comparte la vista de red del centro de conectividad. Mediante el emparejamiento de redes
virtuales, la red virtual de radio usa la conectividad de puerta de enlace remota del centro de conectividad como si
estuviera conectada directamente a la red virtual de radio.
Ruta de acceso al centro de conectividad
A continuación se muestra la salida de traceroute desde una red virtual de radio a una máquina virtual del centro
de conectividad:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 <1 ms <1 ms <1 ms [Link]

Trace complete.
Ruta de acceso a la red virtual de sucursal
A continuación se muestra la salida de traceroute desde una red virtual de radio a una máquina virtual de la red
virtual de sucursal:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 1 ms <1 ms <1 ms [Link]

2 * * * Request timed out.
3 3 ms 2 ms 2 ms [Link]

Trace complete.

En este comando traceroute, el primer salto es la puerta de enlace de VPN del centro de conectividad. El segundo
salto es la puerta de enlace de VPN de la red virtual de sucursal. La dirección IP de la puerta de enlace de VPN de
la red virtual de sucursal no se anuncia en el centro de conectividad ni en la red virtual de radio. El tercer salto es la
máquina virtual de la red virtual de sucursal.
Ruta de acceso a la ubicación 1 local
A continuación se muestra la salida de traceroute desde la red virtual de radio a una máquina virtual de la
ubicación 1 local:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 24 ms 2 ms 3 ms [Link]
2 * * * Request timed out.
3 * * * Request timed out.
4 3 ms 2 ms 2 ms [Link]

Trace complete.

En este comando traceroute, el primer salto es el punto de conexión del túnel de puerta de enlace de ExpressRoute
del centro de conectividad a un enrutador MSEE. El segundo y tercer salto son las direcciones IP del enrutador del
lado del cliente y la LAN de la ubicación 1 local. Estas direcciones IP no se anuncian en el centro de conectividad ni
en la red virtual de radio. El cuarto salto es la máquina virtual de la ubicación 1 local.
Ruta de acceso a la ubicación 2 local
A continuación se muestra la salida de traceroute desde la red virtual de radio a una máquina virtual de la
ubicación 2 local:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 76 ms 75 ms 76 ms [Link]
2 * * * Request timed out.
3 * * * Request timed out.
4 75 ms 75 ms 75 ms [Link]

Trace complete.

En este comando traceroute, el primer salto es el punto de conexión del túnel de puerta de enlace de ExpressRoute
del centro de conectividad a un enrutador MSEE. El segundo y tercer salto son las direcciones IP del enrutador del
lado del cliente y la LAN de la ubicación 2 local. Estas direcciones IP no se anuncian en el centro de conectividad ni
en la red virtual de radio. El cuarto salto es la máquina virtual de la ubicación 2 local.
Ruta de acceso a la red virtual remota
A continuación se muestra la salida de traceroute desde una red virtual de radio a una máquina virtual de la red
virtual remota:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 2 ms 1 ms 1 ms [Link]
2 * * * Request timed out.
3 71 ms 70 ms 70 ms [Link]

Trace complete.

En este comando traceroute, el primer salto es el punto de conexión del túnel de puerta de enlace de ExpressRoute
del centro de conectividad a un enrutador MSEE. El segundo salto es la dirección IP de la puerta de enlace de la red
virtual remota. El intervalo IP del segundo salto no se anuncia en el centro de conectividad ni en la red virtual de
radio. El tercer salto es la máquina virtual de la red virtual remota.

Ruta de acceso de datos desde la red virtual de sucursal

Ruta de acceso al centro de conectividad
A continuación se muestra la salida de traceroute desde la red virtual de sucursal a una máquina virtual del centro
de conectividad:

C:\Windows\system32>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 <1 ms <1 ms <1 ms [Link]

2 * * * Request timed out.
3 4 ms 3 ms 3 ms [Link]

Trace complete.

En este comando traceroute, el primer salto es la puerta de enlace de VPN de la red virtual de sucursal. El segundo
salto es la puerta de enlace de VPN del centro de conectividad. La dirección IP de la puerta de enlace de VPN de
centro de conectividad no se anuncia en la red virtual remota. El tercer salto es la máquina virtual del centro de
conectividad.
Ruta a la red virtual de radio
A continuación se muestra la salida de traceroute desde una red virtual de sucursal a una máquina virtual de la red
virtual de radio:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 1 ms <1 ms 1 ms [Link]
2 * * * Request timed out.
3 4 ms 3 ms 2 ms [Link]

Trace complete.

En este comando traceroute, el primer salto es la puerta de enlace de VPN de la red virtual de sucursal. El segundo
salto es la puerta de enlace de VPN del centro de conectividad. La dirección IP de la puerta de enlace de VPN de
centro de conectividad no se anuncia en la red virtual remota. El tercer salto es la máquina virtual de la red virtual
de radio.
Ruta de acceso a la ubicación 1 local
A continuación se muestra la salida de traceroute desde la red virtual de radio a una máquina virtual de la
ubicación 1 local:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 1 ms <1 ms <1 ms [Link]

2 * * * Request timed out.
3 3 ms 2 ms 2 ms [Link]
4 * * * Request timed out.
5 3 ms 3 ms 3 ms [Link]

Trace complete.

En este comando traceroute, el primer salto es la puerta de enlace de VPN de la red virtual de sucursal. El segundo
salto es la puerta de enlace de VPN del centro de conectividad. La dirección IP de la puerta de enlace de VPN de
centro de conectividad no se anuncia en la red virtual remota. El tercer salto es el punto de terminación de túnel
VPN en el enrutador CE principal. El cuarto salto es una dirección IP interna de la ubicación 1 local. Esta dirección IP
de LAN no se anuncia fuera del enrutador del lado del cliente. El quinto salto es la máquina virtual de destino de la
ubicación 1 local.
Ruta de acceso a la ubicación 2 local y a la red virtual remota
Como se explicó al hablar del análisis del plano de control, la red virtual de sucursal no tiene visibilidad de la
ubicación 2 local ni de la red virtual remota según la configuración de red. Los siguientes resultados de ping lo
confirman:

C:\Users\rb>ping [Link]

Pinging [Link] with 32 bytes of data:

Request timed out.

...
Request timed out.

Ping statistics for [Link]:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\rb>ping [Link]

Pinging [Link] with 32 bytes of data:

Request timed out.

...
Request timed out.

Ping statistics for [Link]:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Ruta de acceso de datos desde la ubicación 1 local

Ruta de acceso al centro de conectividad
A continuación se muestra la salida de traceroute desde la ubicación 1 local a una máquina virtual del centro de
conectividad:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 <1 ms <1 ms <1 ms [Link]

2 <1 ms <1 ms <1 ms [Link]
3 <1 ms <1 ms <1 ms [Link]
4 * * * Request timed out.
5 2 ms 2 ms 2 ms [Link]

Trace complete.

En el comando traceroute, los dos primeros saltos forman parte de la red local. El tercer salto es la interfaz MSEE
principal que se expone al enrutador del lado del cliente. El cuarto salto es la puerta de enlace de ExpressRoute del
centro de conectividad. El intervalo IP de la puerta de enlace de ExpressRoute del centro de conectividad no se
anuncia en la red local. El quinto salto es la máquina virtual de destino.
Network Watcher solo proporciona una vista centrada en Azure. Para una perspectiva local se usa Azure Network
Performance Monitor. Network Performance Monitor proporciona agentes que se pueden instalar en servidores de
redes fuera de Azure para el análisis de la ruta de acceso de datos.
En la siguiente ilustración se muestra la vista de topología de la conectividad de la máquina virtual de la ubicación
1 local con la máquina virtual del centro de conectividad mediante ExpressRoute:

Como se comentó anteriormente, en la configuración de prueba se usa VPN de sitio a sitio como conectividad de
copia de seguridad para ExpressRoute entre la ubicación 1 local y el centro de conectividad. Para probar la ruta de
acceso de datos de copia de seguridad se va a inducir un error de vinculación de ExpressRoute entre el enrutador
CE principal de la ubicación 1 local y el MSEE correspondiente. Para inducir un error de vinculación de
ExpressRoute, apague la interfaz del lado del cliente que se expone al MSEE:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 <1 ms <1 ms <1 ms [Link]

2 <1 ms <1 ms <1 ms [Link]
3 3 ms 2 ms 3 ms [Link]

Trace complete.

En la siguiente ilustración se muestra la vista de topología de la conectividad de la máquina virtual en la ubicación

1 local con la máquina virtual con el centro de conectividad mediante la conectividad VPN de sitio a sitio cuando la
de ExpressRoute está inactiva:
Ruta a la red virtual de radio
A continuación se muestra la salida de traceroute desde la ubicación 1 local a una máquina virtual de la red virtual
de radio:
Volvamos a la conectividad de ExpressRoute principal para realizar el análisis de la ruta de datos hacia la red virtual
de radio:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 <1 ms <1 ms <1 ms [Link]

2 <1 ms <1 ms <1 ms [Link]
3 <1 ms <1 ms <1 ms [Link]
4 * * * Request timed out.
5 3 ms 2 ms 2 ms [Link]

Trace complete.

Recuperemos la conectividad de ExpressRoute 1 principal para el resto del análisis de la ruta acceso de datos.
Ruta de acceso a la red virtual de sucursal
A continuación se muestra la salida de traceroute desde la ubicación 1 local a una máquina virtual de la red virtual
de sucursal:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 <1 ms <1 ms <1 ms [Link]

2 <1 ms <1 ms <1 ms [Link]
3 3 ms 2 ms 2 ms [Link]

Trace complete.

Ruta de acceso a la ubicación 2 local

Como se explicó en el análisis del plano de control, la ubicación 1 local no tiene visibilidad de la ubicación 2 local
según la configuración de red. Los siguientes resultados de ping lo confirman:

C:\Users\rb>ping [Link]

Pinging [Link] with 32 bytes of data:

Request timed out.

...
Request timed out.

Ping statistics for [Link]:

Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Ruta de acceso a la red virtual remota
A continuación se muestra la salida de traceroute desde la ubicación 1 local a una máquina virtual de la red virtual
remota:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 <1 ms <1 ms <1 ms [Link]

2 2 ms 5 ms 7 ms [Link]
3 <1 ms <1 ms <1 ms [Link]
4 * * * Request timed out.
5 69 ms 70 ms 69 ms [Link]

Trace complete.

Ruta de acceso de datos desde la ubicación 2 local

Ruta de acceso al centro de conectividad
A continuación se muestra la salida de traceroute desde la ubicación 2 local a una máquina virtual del centro de
conectividad:

C:\Windows\system32>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 <1 ms <1 ms <1 ms [Link]

2 <1 ms <1 ms <1 ms [Link]
3 <1 ms <1 ms <1 ms [Link]
4 * * * Request timed out.
5 75 ms 74 ms 74 ms [Link]

Trace complete.

Ruta a la red virtual de radio

A continuación se muestra la salida de traceroute desde la ubicación 2 local a una máquina virtual de la red virtual
de radio:

C:\Windows\system32>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 <1 ms <1 ms 1 ms [Link]
2 <1 ms <1 ms <1 ms [Link]
3 <1 ms <1 ms <1 ms [Link]
4 * * * Request timed out.
5 75 ms 74 ms 74 ms [Link]

Trace complete.

Ruta de acceso a la red virtual de sucursal, la ubicación 1 local y la red virtual remota
Como se explicó en el análisis del plano de control, la ubicación 1 local no tiene visibilidad de la red virtual de
sucursal, la ubicación 1 local y la red virtual remota según la configuración de red.

Ruta de acceso de datos desde la red virtual remota

Ruta de acceso al centro de conectividad
A continuación se muestra la salida de traceroute desde la red virtual remota a una máquina virtual del centro de
conectividad:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 65 ms 65 ms 65 ms [Link]
2 * * * Request timed out.
3 69 ms 68 ms 68 ms [Link]

Trace complete.

Ruta a la red virtual de radio

A continuación se muestra la salida de traceroute desde una red virtual remota a una máquina virtual de la red
virtual de radio:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 67 ms 67 ms 67 ms [Link]
2 * * * Request timed out.
3 71 ms 69 ms 69 ms [Link]

Trace complete.

Ruta de acceso a la red virtual de sucursal y la ubicación 2 local

Como se explicó en el análisis del plano de control, la red virtual remota no tiene visibilidad de la red virtual de
sucursal ni de la ubicación 2 local según la configuración de red.
Ruta de acceso a la ubicación 1 local
A continuación se muestra la salida de traceroute desde la red virtual remota a una máquina virtual de la ubicación
1 local:

C:\Users\rb>tracert [Link]

Tracing route to [Link] over a maximum of 30 hops

1 67 ms 67 ms 67 ms [Link]
2 * * * Request timed out.
3 * * * Request timed out.
4 69 ms 69 ms 69 ms [Link]

Trace complete.

Uso simultáneo de ExpressRoute y la conectividad VPN de sitio a sitio

VPN de sitio a sitio con ExpressRoute
Puede configurar una VPN de sitio a sitio mediante el emparejamiento de Microsoft con ExpressRoute para
intercambiar datos de forma privada entre la red local y las redes virtuales de Azure. Esta configuración le asegura
un intercambio de datos con confidencialidad, autenticidad, integridad y antirreproducción. Para más información
acerca de cómo configurar una VPN IPsec de sitio a sitio en modo de túnel con emparejamiento de Microsoft de
ExpressRoute, consulte Configuración de una VPN de sitio a sitio a través del emparejamiento de Microsoft de
ExpressRoute.
La limitación principal de la configuración de una VPN de sitio a sitio que use el emparejamiento de Microsoft es el
rendimiento. El rendimiento a través del túnel IPsec está limitado por la capacidad de la puerta de enlace de VPN.
El rendimiento de la puerta de enlace de VPN es menor que el de ExpressRoute. En este escenario, el uso del túnel
IPsec para el tráfico de seguridad alta y con emparejamiento privado para el tráfico restante ayuda a optimizar el
uso de ancho de banda de ExpressRoute.
VPN de sitio a sitio como ruta de acceso de conmutación por error para ExpressRoute
ExpressRoute sirve como par de circuito redundante para garantizar la alta disponibilidad. Puede configurar la
conectividad de ExpressRoute con redundancia geográfica en diferentes regiones de Azure. Además, como se ha
demostrado en la configuración de prueba, dentro de una región de Azure puede usar una VPN de sitio a sitio para
crear una ruta de acceso de conmutación por error para la conectividad de ExpressRoute. Cuando se anuncian los
mismos prefijos a través de ExpressRoute y VPN de sitio a sitio, Azure da prioridad a ExpressRoute. Para evitar el
enrutamiento asimétrico entre ExpressRoute y VPN de sitio a sitio, la configuración de la red local también debe
tener prioridad mediante el uso de la conectividad ExpressRoute antes de VPN de sitio a sitio.
Para más información acerca de cómo configurar conexiones coexistentes de ExpressRoute y una VPN de sitio a
sitio, consulte el artículo sobre la coexistencia de conexiones de ExpressRoute y de sitio a sitio.

Ampliación de la conectividad de back-end a redes virtuales de radio y

ubicaciones de sucursal
Conectividad de red virtual de radio mediante el emparejamiento de redes virtuales
La arquitectura de red virtual de tipo hub-and-spoke se usa ampliamente. El centro de conectividad es una red
virtual de Azure que actúa como punto central de conectividad entre las redes virtuales de radio y la red local. Los
radios son redes virtuales que se emparejan con el centro de conectividad y sirven para aislar las cargas de
trabajo. El tráfico fluye entre el centro de datos local y el concentrador a través de una conexión de ExpressRoute o
VPN. Para más información acerca de la arquitectura, consulte Implementación de una topología de red en estrella
tipo hub-and-spoke en Azure.
En el emparejamiento de redes virtuales dentro de una región, las redes virtuales de radio pueden usar las puertas
de enlace del centro de conectividad (tanto de VPN como de ExpressRoute) para comunicarse con las redes
remotas.
Conectividad de red virtual de sucursal mediante VPN de sitio a sitio
Es posible que quiera redes virtuales en rama, que están en regiones diferentes, y redes locales para comunicarse
entre sí a través de una red virtual de centro de conectividad. La solución de Azure nativa para esta configuración
es la conectividad VPN de sitio a sitio mediante una VPN. Una alternativa es usar una aplicación virtual de red
(NVA) para el enrutamiento en el centro de conectividad.
Para más información, consulte ¿Qué es VPN Gateway? e Implementación de aplicaciones virtuales de red de alta
disponibilidad.

Pasos siguientes
Consulte las preguntas más frecuentes de ExpressRoute para información acerca de:
Cuántos circuitos de ExpressRoute puede conectar a una puerta de enlace de ExpressRoute.
Cuántas puertas de enlace de ExpressRoute puede conectar a un circuito de ExpressRoute.
Los límites de escala de ExpressRoute.
 Habilitación de contenedores para que usen las
funcionalidades de Azure Virtual Network
23/09/2020 • 7 minutes to read • Edit Online

Incorpore el amplio conjunto de funcionalidades de red de Azure a los contenedores mediante el uso de la misma
pila de redes que se utiliza en las máquinas virtuales. El complemento de interfaz de red de contenedores (CNI) de
Azure Virtual Network se instala en una máquina virtual de Azure. El complemento asigna direcciones IP de una
red virtual a los contenedores en la máquina virtual, adjuntándolos a dicha red y conectándolos directamente a
otros contenedores y recursos de red virtual. El complemento no se basa en las rutas o redes de superposición
para la conectividad, y proporciona el mismo rendimiento que las máquinas virtuales. En un nivel alto, el
complemento proporciona las siguientes funcionalidades:
Se asigna una dirección IP de red virtual a cada pod, que puede constar de uno o varios contenedores.
Los pods pueden conectarse a redes virtuales emparejadas y al entorno local mediante ExpressRoute o de una
VPN de sitio a sitio. Los pods también son accesibles desde redes locales y emparejadas.
Los pods pueden acceder a servicios como Azure Storage y Azure SQL Database, que están protegidos por los
puntos de conexión de servicio de red virtual.
Las rutas y los grupos de seguridad de red se pueden aplicar directamente a los pods.
Los pods se pueden colocar directamente detrás de un equilibrador de carga interno o público de Azure, igual
que las máquinas virtuales
Los pods se pueden asignar a una dirección IP pública, lo que hace que sean directamente accesibles desde
Internet. Los pods también pueden ellos mismos acceder a Internet.
Funciona perfectamente con los recursos de Kubernetes como Services, los controladores de Ingress y DNS
Kube. Un servicio de Kubernetes también se puede exponer de forma externa o interna mediante Azure Load
Balancer.
La siguiente imagen muestra cómo el complemento proporciona funcionalidades de Azure Virtual Network a los
pods:
El complemento admite las plataformas Windows y Linux.

Conexión de los pods a una red virtual

Los pods se muestran en una máquina virtual que sea parte de una red virtual. En la interfaz de red de una
máquina virtual se configuran, como direcciones secundarias, un grupo de direcciones IP para los pods. Azure CNI
configura la conectividad de red básica para los pods y administra el uso de las direcciones IP en el grupo. Cuando
un pod aparece en la máquina virtual, Azure CNI asigna una dirección IP disponible del grupo y se conecta el pod a
un puente de software en la máquina virtual. Cuando el pod finaliza, la dirección IP se vuelve a agregar al grupo.
En la siguiente imagen se muestra cómo se conectan los pod a una red virtual:
Acceso a Internet
Para habilitar los pods para que tengan acceso a Internet, el complemento configura las reglas iptables para la
traducción de direcciones de red (NAT) del tráfico ligado a Internet desde los pods. La dirección IP de origen del
paquete se traduce a la dirección IP principal en la interfaz de red de la máquina virtual. Las máquinas virtuales
Windows aplican el modo Source NAT (SNAT) automáticamente al tráfico destinado a direcciones IP fuera de la
subred a la que pertenece la máquina virtual. Normalmente, se traduce todo el tráfico destinado a una dirección IP
fuera del intervalo IP de la red virtual.

límites
El complemento admite hasta 250 pods por máquina virtual y un máximo de 16 000 Pods en una red virtual. Estos
límites son diferentes para Azure Kubernetes Service.

Uso del complemento

El complemento se puede usar de las siguientes maneras para proporcionar conexión de red virtual básica para
contenedores de Docker o Pods:
Azure Kubernetes Ser vice : el complemento está integrado en Azure Kubernetes Service (AKS) y puede
usarse eligiendo la opción de Redes avanzadas. La opción de redes avanzadas le permite implementar un
clúster de Kubernetes en una red virtual nueva o existente. Para más información acerca de la opción de redes
avanzadas y los pasos para configurarla, consulte Configuración de red en Azure Kubernetes Service (AKS).
AKS-Engine : AKS-Engine es una herramienta que genera una plantilla de Azure Resource Manager para la
implementación de un clúster de Kubernetes en Azure. Para obtener instrucciones detalladas, consulte
Implementación del complemento para un clúster de Kubernetes con AKS-Engine.
Creación de su propio clúster de Kubernetes en Azure : el complemento se puede usar para proporcionar
prestaciones de red básicas para los pods en clústeres de Kubernetes que implemente usted mismo, sin tener
que depender de AKS, o de herramientas como AKS-Engine. En este caso, el complemento se instala y habilita
en todas las máquinas virtuales en un clúster. Para instrucciones detalladas, consulte Implementación del
complemento para un clúster de Kubernetes que usted mismo haya implementado.
Conexión de una red vir tual para contenedores de Docker en Azure : el complemento se puede usar en
casos donde no quiera crear un clúster de Kubernetes y desee crear contenedores de Docker con conexión de
red virtual en máquinas virtuales. Para instrucciones detalladas, consulte Implementación del complemento
para contenedores de Docker.

Pasos siguientes
Implementación del complemento para clústeres de Kubernetes o contenedores de Docker
 Conectividad entre redes
23/09/2020 • 10 minutes to read • Edit Online

Fabrikam Inc. tiene una presencia física importante e implementación de Azure en el Este de EE. UU. Fabrikam tiene
conectividad de back-end entre sus servidores locales y las implementaciones de Azure a través de ExpressRoute.
De igual modo, Contoso Ltd. tiene presencia e implementación de Azure en el Oeste de EE. UU. Contoso tiene
conectividad de back-end entre sus servidores locales y las implementaciones de Azure a través de ExpressRoute.
Fabrikam Inc. adquiere Contoso Ltd. Después de la fusión, Fabrikam desea interconectar las redes. En la siguiente
ilustración se muestra este escenario:

Las flechas discontinuas en medio de la ilustración anterior indican las interconexiones de red deseadas. En
concreto, hay tres tipos de conexiones cruzadas deseadas: 1) Conexiones cruzadas entre las redes virtuales de
Fabrikam y Contoso, 2) Conexiones cruzadas entre redes virtuales y locales entre regiones (es decir, una conexión
entre la red local de Fabrikam y la red virtual de Contoso, y otra conexión entre la red local de Contoso y la red
virtual de Fabrikam), y 3) Conexión cruzada entre las redes locales de Fabrikam y Contoso.
En la siguiente tabla se muestra la tabla de rutas del emparejamiento privado con ExpressRoute de Contoso Ltd.
antes de la fusión.
La siguiente tabla muestra las rutas eficaces de una máquina virtual en la suscripción de Contoso, antes de la
fusión. Según la tabla, la máquina virtual en la red virtual conoce el espacio de direcciones de la red virtual y la red
local de Contoso, aparte de los valores predeterminados.

En la siguiente tabla se muestra la tabla de rutas del emparejamiento privado con ExpressRoute de Fabrikam Inc.
antes de la fusión.

La siguiente tabla muestra las rutas eficaces de una máquina virtual en la suscripción de Fabrikam, antes de la
fusión. Según la tabla, la máquina virtual en la red virtual conoce el espacio de direcciones de la red virtual y la red
local de Fabrikam, aparte de los valores predeterminados.
En este artículo, explicaremos el proceso paso a paso y discutiremos cómo lograr las conexiones cruzadas deseadas
utilizando las siguientes características de red de Azure:
Emparejamiento de redes virtuales
Conexión de red virtual con ExpressRoute
Global Reach

Conexión cruzada entre redes virtuales

El emparejamiento de redes virtuales proporciona el mejor y más óptimo rendimiento de red cuando se conectan
dos redes virtuales. El emparejamiento de redes virtuales admite el emparejamiento de dos redes virtuales en la
misma región de Azure (comúnmente denominado emparejamiento de red virtual) y en dos regiones diferentes
(comúnmente denominado emparejamiento de red virtual global).
Vamos a configurar el emparejamiento de red virtual global entre las redes virtuales en las suscripciones a Contoso
y Fabrikam. Para crear el emparejamiento de red virtual entre las dos redes virtuales, consulte el artículo Creación
de un emparejamiento de redes virtuales.
La siguiente imagen muestra la arquitectura de red después de configurar el emparejamiento de red virtual global.
La siguiente tabla muestra las rutas conocidas a la máquina virtual de la suscripción a Contoso. Preste atención a la
última entrada de la tabla. Esta entrada es el resultado de realizar una conexión cruzada entre las redes virtuales.

La siguiente tabla muestra las rutas conocidas a la máquina virtual de la suscripción a Fabrikam. Preste atención a
la última entrada de la tabla. Esta entrada es el resultado de realizar una conexión cruzada entre las redes virtuales.
El emparejamiento de red virtual vincula directamente dos redes virtuales (observe que no hay ningún próximo
salto para la entrada VNetGlobalPeering en las dos tablas anteriores).

Conexión cruzada entre las redes virtuales y las redes locales

Es posible conectar un circuito ExpressRoute a varias redes virtuales. Consulte los límites de servicio y
suscripciones para conocer el número máximo de redes virtuales que se pueden conectar a un circuito
ExpressRoute.
Vamos a conectar el circuito ExpressRoute de Fabrikam con la red virtual de la suscripción a Contoso y, de igual
modo, conectaremos el circuito ExpressRoute de Contoso a la red virtual de la suscripción a Fabrikam para habilitar
la conectividad cruzada entre redes virtuales y redes locales. Para conectar una red virtual a un circuito
ExpressRoute en una suscripción diferente, es necesario crear y utilizar una autorización. Consulte el artículo:
Conexión de una red virtual a un circuito ExpressRoute.
La siguiente imagen muestra la arquitectura de red después de configurar la conectividad cruzada de ExpressRoute
a las redes virtuales.
En la tabla siguiente se muestra la tabla de rutas del emparejamiento privado de ExpressRoute de Contoso Ltd.
después de crear una conexión cruzada entre las redes virtuales y las redes locales a través de ExpressRoute.
Observe que la tabla de rutas tiene rutas que pertenecen a ambas redes virtuales.

En la tabla siguiente se muestra la tabla de rutas del emparejamiento privado de ExpressRoute de Fabrikam Inc.
después de crear una conexión cruzada entre las redes virtuales y las redes locales a través de ExpressRoute.
Observe que la tabla de rutas tiene rutas que pertenecen a ambas redes virtuales.
La siguiente tabla muestra las rutas conocidas a la máquina virtual de la suscripción a Contoso. Preste atención a
las entradas de Virtual network gateway (Puerta de enlace de red virtual) de la tabla. La máquina virtual muestra
rutas para ambas redes locales.

La siguiente tabla muestra las rutas conocidas a la máquina virtual de la suscripción a Fabrikam. Preste atención a
las entradas de Virtual network gateway (Puerta de enlace de red virtual) de la tabla. La máquina virtual muestra
rutas para ambas redes locales.
 NOTE
En cualquiera de las suscripciones a Fabrikam y Contoso, también pueden existir redes virtuales de radio a la red virtual hub
correspondiente (no se muestra un diseño de hub y radio en los diagramas de arquitectura de este artículo). Las conexiones
cruzadas entre las puertas de enlace de red virtual de hub y ExpressRoute también permiten la comunicación entre hub y
radios de las regiones Este y Oeste.

Conexión cruzada entre redes locales

Global Reach de ExpressRoute proporciona conectividad entre redes locales que están conectadas a distintos
circuitos ExpressRoute. Vamos a configurar Global Reach entre los circuitos ExpressRoute de Contoso y Fabrikam.
Dado que los circuitos ExpressRoute se encuentran en distintas suscripciones, es necesario crear y utilizar una
autorización. Consulte el artículo Configuración de ExpressRoute Global Reach para obtener instrucciones paso a
paso.
La siguiente imagen muestra la arquitectura de red después de configurar Global Reach.
En la siguiente tabla se muestra la tabla de rutas del emparejamiento privado con ExpressRoute de Contoso Ltd.
después de configurar Global Reach. Observe que la tabla de rutas tiene rutas que pertenecen a ambas redes
locales.

En la siguiente tabla se muestra la tabla de rutas del emparejamiento privado con ExpressRoute de Fabrikam Inc.
después de configurar Global Reach. Observe que la tabla de rutas tiene rutas que pertenecen a ambas redes
locales.
Pasos siguientes
Consulte las preguntas más frecuentes de Virtual Network para resolver las dudas adicionales sobre redes virtuales
y emparejamiento de redes virtuales. Consulte P+F de ExpressRoute para resolver las dudas adicionales sobre la
conectividad de redes virtuales y ExpressRoute.
Global Reach se está dando a conocer país a país y región a región. Para ver si Global Reach está disponible en los
países o regiones que quiere, consulte Global Reach de ExpressRoute.
 Emparejamiento de redes virtuales de Azure
23/09/2020 • 15 minutes to read • Edit Online

El emparejamiento de redes virtuales permite conectar redes sin problemas en Azure Virtual Network. A
efectos de conectividad las redes virtuales aparecen como una sola. El tráfico entre máquinas virtuales usa
la infraestructura de la red troncal de Microsoft. Al igual que el tráfico entre las máquinas virtuales de la
misma red, el tráfico solo se enruta a través de la red privada de Microsoft.
La directiva admite los siguientes tipos de emparejamiento:
Emparejamiento de redes virtuales: conecte redes virtuales que se encuentren en la misma región de
Azure.
Emparejamiento global de redes virtuales: conexión de redes virtuales en distintas regiones de Azure.
Las ventajas del uso del emparejamiento de redes virtuales, ya sean locales o globales, son las siguientes:
Baja latencia, conexión de gran ancho de banda entre los recursos de redes virtuales diferentes.
La capacidad de los recursos de una red virtual para comunicarse con los de otra red virtual.
La capacidad de transferir datos entre redes virtuales de distintas suscripciones de Azure, inquilinos de
Azure Active Directory, modelos de implementación y regiones de Azure.
La capacidad de emparejar redes virtuales creadas mediante Azure Resource Manager.
La capacidad de emparejar una red virtual creada mediante Resource Manager con otra creada
mediante el modelo de implementación clásica. Para más información sobre los modelos de
implementación de Azure, consulte Descripción de los modelos de implementación de Azure.
No tienen tiempo de inactividad ni los recursos de la red virtual al crear el emparejamiento, o después.
El tráfico de red entre redes virtuales emparejadas es privado. El tráfico entre las redes virtuales se
mantiene en la red troncal de Microsoft. No se requieren ninguna red pública de Internet, puertas de enlace
o cifrado en la comunicación entre las redes virtuales.

Conectividad
En el caso de las redes virtuales emparejadas, los recursos de cualquiera de ellas se pueden conectar
directamente con los de la red virtual emparejada.
La latencia de red entre las máquinas virtuales de redes virtuales emparejadas en la misma región es la
misma que la de una única red virtual. El rendimiento de la red se basa en el ancho de banda que se
permite para la máquina virtual, en proporción a su tamaño. No hay restricciones adicionales con respecto
al ancho de banda en el emparejamiento.
El tráfico entre las máquinas virtuales en las redes virtuales emparejadas se enruta directamente a través de
la infraestructura de red troncal de Microsoft, no de una puerta de enlace ni de una red Internet pública.
En cualquier red virtual, se pueden aplicar grupos de seguridad de red para bloquear el acceso a otras redes
o subredes virtuales. Al configurar el emparejamiento de red virtual, abra o cierre las reglas del grupo de
seguridad de red entre las redes virtuales. Si abre la conectividad completa entre redes virtuales
emparejadas, puede aplicar grupos de seguridad de red a subredes o máquinas virtuales concretas para
bloquear o denegar el acceso específico. La opción predeterminada es la conectividad total. Para obtener
más información sobre los grupos de seguridad de red, consulte Grupos de seguridad.

Encadenamiento de servicios
El encadenamiento de servicios permite dirigir el tráfico de una red virtual a una aplicación virtual o puerta
de enlace de una red emparejada a través de rutas definidas por el usuario.
Para habilitar el encadenamiento de servicios, configure las rutas definidas por el usuario que apuntan a
máquinas virtuales de redes virtuales emparejadas como la dirección IP del próximo salto. Las rutas
definidas por el usuario también pueden apuntar a puertas de enlace de redes virtuales para habilitar el
encadenamiento de servicios.
Puede implementar redes del tipo de concentrador y radio, en los que la red virtual del concentrador
hospeda componentes de la infraestructura, como una aplicación virtual de red o una puerta de enlace de
VPN. Todas las redes virtuales de radio se pueden emparejar con la red virtual de concentrador. El tráfico
fluye por las aplicaciones virtuales de red o las puertas de enlace de VPN de la red virtual del concentrador.
El emparejamiento de red virtual permite que el próximo salto de una ruta definida por el usuario sea la
dirección IP de una máquina virtual de la red virtual emparejada o en una puerta de enlace de VPN. No
puede realizar el enrutamiento entre redes virtuales con una ruta definida por el usuario que especifique
una puerta de enlace de Azure ExpressRoute como del tipo de próximo salto. Para obtener más información
sobre las rutas definidas por el usuario, consulte Introducción a las rutas definidas por el usuario. Para
aprender a crear una topología de red en estrella tipo hub-and-spoke, consulte Topología en estrella tipo
hub-and-spoke en Azure.

Puertas de enlace y conectividad local

Cada red virtual, incluidas las redes virtuales emparejadas, puede tener su propia puerta de enlace. Las
redes virtuales pueden usar su puerta de enlace para conectarse a una red local. También puede configurar
conexiones entre redes virtuales mediante puertas de enlace, incluso para redes virtuales emparejadas.
Cuando se configuran las dos opciones para la interconectividad de redes virtuales, el tráfico entre las redes
virtuales se propaga a través de la configuración del emparejamiento. El tráfico usa la red troncal de Azure.
La puerta de enlace de la red virtual emparejada también se puede configurar como un punto de tránsito a
una red local. En ese caso, la red virtual que usa una puerta de enlace remota no puede tener su propia
puerta de enlace. Una red virtual no puede tener más de una puerta de enlace. En la red virtual emparejada,
la puerta de enlace puede ser local o remota, como se muestra en el diagrama siguiente:

Tanto el emparejamiento de red virtual como el emparejamiento de red virtual global admiten el tránsito de
puerta de enlace.
Se admite el tránsito de puerta de enlace entre redes virtuales creadas mediante diferentes modelos de
implementación. La red virtual debe estar en la red virtual del modelo de Resource Manager. Para más
información sobre el uso de una puerta de enlace de tránsito, consulte Configure a VPN gateway for transit
in a virtual network peering (Configuración de una puerta de enlace de VPN de tránsito en un
emparejamiento de red virtual).
Si se emparejan redes virtuales que comparten la misma conexión de Azure ExpressRoute, el tráfico entre
ellas pasa por la relación de emparejamiento. Ese tráfico usa la red troncal de Azure. Puede seguir usando
las puertas de enlace locales de cada red virtual para conectarse al circuito local. De lo contrario, puede
utilizar una puerta de enlace compartida y configurar el tránsito para una conectividad local.

Solución de problemas
Para confirmar que las redes virtuales están emparejadas, puede comprobar las rutas eficaces. Las rutas de
una interfaz de red se comprueban en cualquier subred de una red virtual. Si el emparejamiento de redes
virtuales existe, todas las subredes de la red virtual tienen rutas con próximo salto del tipo emparejamiento
de VNet, para cada espacio de direcciones en cada red virtual emparejada. Para más información, consulte
Diagnóstico de problemas de enrutamiento en una máquina virtual.
En una red virtual emparejada, los problemas de conectividad con una máquina virtual se pueden
solucionar mediante Azure Network Watcher. Una comprobación de conectividad permite ver cómo se
enruta el tráfico desde la interfaz de red de una máquina virtual de origen a la de una máquina virtual de
destino. Para más información, consulte Solución de problemas en las conexiones con Azure Network
Watcher desde Azure Portal.
También puede probar la solución de problemas de emparejamiento de red virtual.

Restricciones de las redes virtuales emparejadas

Cuando las redes virtuales están emparejadas globalmente, se aplican las siguientes restricciones:
Los recursos de una red virtual no pueden comunicarse con la dirección IP de front-end de un
equilibrador de carga interno (ILB) básico en una red virtual emparejada globalmente.
Algunos servicios que usan un equilibrador de carga básico no funcionan en el emparejamiento de red
virtual global. Para más información, consulte ¿Cuáles son las restricciones relacionadas con el
emparejamiento de red virtual global y los equilibradores de carga?.
Para más información, consulte Requisitos y restricciones. Para más información sobre el número de
emparejamientos que se admiten, consulte Límites de la red.

Permisos
Para más información sobre los permisos necesarios para crear un emparejamiento de red virtual, consulte
Permisos.

Precios
Hay un cargo nominal para el tráfico de entrada y salida que usa una conexión de emparejamiento de red
virtual. Para más información, consulte Precios de redes virtuales.
El tránsito de puerta de enlace es una propiedad del emparejamiento que permite a las redes virtuales
utilizar una puerta de enlace de VPN o ExpressRoute de una red virtual emparejada. El tránsito de puerta de
enlace funciona tanto para la conectividad entre entornos locales como para la conectividad entre redes. El
tráfico a la puerta de enlace (de entrada o salida) en la red virtual emparejada incurrirá en cargos de
emparejamiento de red virtual en la red virtual de radio (o en la red virtual que no sea de la puerta de
enlace). Para más información, consulte Precios de VPN Gateway, donde podrá ver los cargos que supone
una puerta de enlace de red privada virtual y los precios de la puerta de enlace de ExpressRoute, donde
podrá ver los costos de la puerta de enlace de ExpressRoute.

NOTE
En una versión anterior de este documento se indicaba que no se aplicarían cargos de emparejamiento de red virtual
a la red virtual de radio (o la red virtual que no sea de puerta de enlace) con el tránsito de puerta de enlace. Ahora
se refleja un precio preciso en la página de precios.

Pasos siguientes
Puede crear un emparejamiento entre dos redes virtuales. Las redes pueden pertenecer a la misma
suscripción, a diferentes modelos de implementación de la misma suscripción o a diferentes
suscripciones. Realice el tutorial para uno de los siguientes escenarios:

M O DELO DE IM P L EM EN TA C IÓ N DE A Z URE SUB SC RIP T IO N

Ambas mediante Resource Manager La misma

Diferente

Una mediante Resource Manager y la otra clásica La misma

Diferente

Para aprender a crear una topología de red en estrella tipo hub-and-spoke, consulte Topología en
estrella tipo hub-and-spoke en Azure.
Para obtener información acerca de la configuración del emparejamiento de red virtual, consulte
Creación, cambio o eliminación de un emparejamiento de red virtual.
Para conocer las respuestas a las preguntas habituales acerca del emparejamiento de red virtual y
del emparejamiento de red virtual global, consulteEmparejamiento de red virtual.
 Puntos de conexión de servicio de red virtual
23/09/2020 • 26 minutes to read • Edit Online

El punto de conexión de servicio de red virtual (VNet) proporciona conectividad directa y segura con los
servicios de Azure por medio de una ruta optimizada a través de la red troncal de Azure. Los puntos de
conexión permiten proteger los recursos de servicio de Azure críticos únicamente para las redes virtuales. Los
puntos de conexión de servicio permiten a las direcciones IP privadas de la red virtual alcanzar el punto de
conexión de un servicio de Azure sin necesidad de una dirección IP pública en la red virtual.
Esta característica está disponible para las siguientes regiones y servicios de Azure. El recurso Microsoft.* está
entre paréntesis. Habilítelo desde la subred mientras configura los puntos de conexión del servicio:
Disponibilidad general
Azure Storage ([Link]): disponibilidad general en todas las regiones de Azure.
Azure SQL Database ([Link]): disponibilidad general en todas las regiones de Azure.
Azure SQL Data Warehouse ([Link]): disponibilidad general en todas las regiones de Azure.
Ser vidor de Azure Database for PostgreSQL ([Link]): disponibilidad general en las regiones de
Azure en las que el servicio de base de datos esté disponible.
Ser vidor de Azure Database for MySQL ([Link]): disponibilidad general en las regiones de
Azure en las que el servicio de base de datos esté disponible.
Azure Database for MariaDB ([Link]): disponibilidad general en las regiones de Azure en las que
el servicio de base de datos esté disponible.
Azure Cosmos DB ([Link]): disponibilidad general en todas las regiones de Azure.
Azure Key Vault ([Link]): disponibilidad general en todas las regiones de Azure.
Azure Ser vice Bus ([Link]): disponibilidad general en todas las regiones de Azure.
Azure Event Hubs ([Link]): disponibilidad general en todas las regiones de Azure.
Azure Data Lake Store Gen 1 ([Link]): Disponible con carácter general en
todas las regiones de Azure donde ADLS Gen1 está disponible.
Azure App Ser vice ([Link]): disponible con carácter general en todas las regiones de Azure en
que App Service esté disponible.
Versión preliminar pública
Azure Container Registr y ([Link]): Hay una versión preliminar disponible en
algunas de las regiones de Azure en que está disponible Azure Container Registry.
Para conocer las notificaciones más actualizadas sobre, consulte la página Actualizaciones de Azure Virtual
Network.

Ventajas principales
Los puntos de conexión de servicio proporcionan las siguientes ventajas:
Seguridad mejorada para los recursos de ser vicio de Azure : Los espacios de direcciones
privadas de una red virtual pueden superponerse. No se pueden usar espacios superpuestos para
identificar de forma exclusiva el tráfico que parte de una red virtual. Los puntos de conexión de servicio
ofrecen la capacidad de proteger los recursos de los servicios de Azure en la red virtual mediante la
extensión de la identidad de la red virtual al servicio. Una vez que habilita puntos de conexión de
servicio en su red virtual, puede agregar una regla de red virtual para proteger los recursos de los
 servicios de Azure en la red virtual. La adición de la regla proporciona una mayor seguridad, ya que
elimina totalmente el acceso público de Internet a los recursos y solo permite el tráfico que procede de
la red virtual.
Enrutamiento óptimo para el tráfico del ser vicio de Azure desde la red vir tual : hoy, las rutas
de la red virtual que fuerzan el tráfico de Internet a las aplicaciones virtuales o locales también fuerzan
al tráfico del servicio de Azure a que realice la misma ruta que el tráfico de Internet. Los puntos de
conexión de servicio proporcionan un enrutamiento óptimo al tráfico de Azure.
Los puntos de conexión siempre toman el tráfico del servicio directamente de la red virtual al servicio
en la red troncal de Microsoft Azure. Mantener el tráfico en la red troncal de Azure permite seguir
auditando y supervisando el tráfico saliente de Internet desde las redes virtuales, a través de la
tunelización forzada, sin que afecte al tráfico del servicio. Para más información sobre las rutas
definidas por el usuario y la tunelización forzada, consulte Enrutamiento del tráfico de redes virtuales
de Azure.
Fácil de configurar con menos sobrecarga de administración : ya no necesita direcciones IP
públicas y reservadas en sus redes virtuales para proteger los recursos de Azure a través de una
dirección IP del firewall. No hay ningún dispositivo NAT (traducción de direcciones de red) o de puerta
de enlace necesario para configurar los puntos de conexión de servicio. Estos se pueden configurar con
un simple clic en una subred. El mantenimiento de los puntos de conexión no supone una sobrecarga
adicional.

Limitaciones
Esta característica solo está disponible en las redes virtuales implementadas con el modelo de
implementación de Azure Resource Manager.
Los puntos de conexión están habilitados en subredes configuradas en redes virtuales de Azure. Los
puntos de conexión no se pueden usar para el tráfico que fluye entre las instalaciones y los servicios de
Azure. Para más información, consulte Protección del acceso de servicio de Azure desde el entorno local
Para Azure SQL, un punto de conexión de servicio solo se aplica al tráfico del servicio de Azure dentro de la
región de una red virtual. En el caso de Azure Storage, los puntos de conexión también se amplían para
incluir las regiones emparejadas en las que se implementa la red virtual para admitir el tráfico del
almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) y el del almacenamiento con
redundancia geográfica (GRS). Para más información, consulte Regiones emparejadas de Azure.
En el caso de Azure Data Lake Storage (ADLS) Gen 1, la funcionalidad de integración de red virtual solo
está disponible para las redes sociales que se encuentran dentro de la misma región. Tenga también en
cuenta que la integración de la red virtual en ADLS Gen1 usa la seguridad del punto de conexión de
servicio de red virtual entre la red virtual y Azure Active Directory (Azure AD) para generar notificaciones
de seguridad adicionales en el token de acceso. Estas notificaciones se usan entonces para autenticar la red
virtual en la cuenta de Data Lake Storage Gen1 y permitir el acceso. La etiqueta
[Link] que aparece debajo de los servicios que admiten puntos de conexión de
servicios se usa solo para admitir puntos de conexión de servicios en ADLS Gen 1. Azure AD no admite
puntos de conexión de servicio de forma nativa. Para más información acerca de la integración de redes
virtuales en Azure Data Lake Store Gen 1, consulte Seguridad de red en Azure Data Lake Storage Gen1.

Protección de servicios de Azure en redes virtuales

Un punto de conexión de servicio de red virtual proporciona la identidad de la red virtual al servicio de
Azure. Una vez que habilita puntos de conexión de servicio en su red virtual, puede agregar una regla
de red virtual para proteger los recursos de los servicios de Azure en la red virtual.
Actualmente, el tráfico del servicio de Azure desde una red virtual usa direcciones IP públicas como
direcciones IP de origen. Con los puntos de conexión de servicio, el tráfico del servicio cambia para
 usar direcciones privadas de red virtual como la direcciones IP de origen al acceder al servicio de Azure
desde una red virtual. Este modificador permite acceder a los servicios sin necesidad de direcciones IP
públicas y reservadas utilizadas en los firewalls IP.

NOTE
Con los puntos de conexión de servicio, las direcciones IP de origen de las máquinas virtuales en la subred para
el tráfico de servicio pasan de utilizar direcciones IPv4 públicas a utilizar direcciones IPv4 privadas. Las reglas
existentes de firewall de servicio de Azure que utilizan direcciones IP públicas Azure dejarán de funcionar con
este cambio. Asegúrese de que las reglas de firewall del servicio de Azure permiten este cambio antes de
configurar los puntos de conexión de servicio. También es posible que experimente una interrupción temporal
del tráfico de servicio desde esta subred mientras configura los puntos de conexión de servicio.

Protección del acceso de servicio de Azure desde el entorno local

De forma predeterminada, a los recursos de los servicios de Azure protegidos en las redes virtuales no se
puede acceder desde redes locales. Si quiere permitir el tráfico desde el entorno local, también debe permitir
las direcciones IP públicas (normalmente NAT) desde el entorno local o ExpressRoute. Estas direcciones IP se
pueden agregar mediante la configuración del firewall de IP para los recursos de los servicios de Azure.
ExpressRoute: Si usa ExpressRoute para el emparejamiento público o el emparejamiento de Microsoft desde
un entorno local, tendrá que identificar las direcciones IP de NAT que va a usar. En el caso del emparejamiento
público, cada circuito ExpressRoute usa de forma predeterminada dos direcciones IP de NAT que se aplican al
tráfico del servicio de Azure cuando entra en la red troncal de Microsoft Azure. En el caso del emparejamiento
de Microsoft, las direcciones IP de NAT que se utilizan las proporcionan el cliente o el proveedor de
servicios. Para permitir el acceso a los recursos de servicio, tiene que permitir estas direcciones IP públicas en
la configuración del firewall de IP de recursos. Para encontrar las direcciones de IP de circuito de ExpressRoute
de los pares públicos, abra una incidencia de soporte técnico con ExpressRoute en Azure Portal. Para más
información sobre NAT tanto para el emparejamiento de Microsoft como para el emparejamiento público de
ExpresRoute, consulte Requisitos de NAT de ExpressRoute.
Configuración
Configure los puntos de conexión de servicio en una subred de una red virtual. Los puntos de conexión
funcionan con cualquier tipo de instancias de proceso que se ejecute en esa subred.
Puede configurar varios puntos de conexión de servicio para todos los servicios de Azure admitidos (por
ejemplo, Azure Storage o Azure SQL Database) en una subred.
Para Azure SQL Database, las redes virtuales deben estar en la misma región que el recurso de servicio de
Azure. Si se usan cuentas de Azure Storage para GRS y RA-GRS, la cuenta principal debe encontrarse en la
misma región que la red virtual. En el caso de los restantes servicios, los recursos de servicio de Azure se
pueden proteger en las redes virtuales de cualquier región.
La red virtual donde se ha configurado el punto de conexión puede estar en la misma suscripción o en otra
distinta del recurso de servicio de Azure. Para más información sobre los permisos necesarios para
configurar los puntos de conexión y proteger los servicios de Azure, consulte Aprovisionamiento.
Para los servicios compatibles, puede proteger los nuevos recursos o los recursos existentes a las redes
virtuales con puntos de conexión de servicio.
Consideraciones
Después de habilitar un punto de conexión de servicio, las direcciones IP de origen pasan de utilizar las
direcciones IPv4 públicas a usar su dirección IPv4 privada, cuando se comunican con el servicio desde
dicha subred. Las conexiones TCP abiertas existentes en el servicio se cierran durante este cambio.
Asegúrese de que no se esté ejecutando ninguna tarea crítica al habilitar o deshabilitar un punto de
conexión de servicio en un servicio para una subred. Además, asegúrese de que las aplicaciones
pueden conectarse automáticamente a los servicios de Azure después del cambio de dirección IP.
El cambio de dirección IP solo afecta el tráfico del servicio desde la red virtual. No afecta a ningún otro
tráfico entrante o saliente de las direcciones IPv4 públicas asignadas a las máquinas virtuales. Para los
 servicios de Azure, si tiene reglas de firewall existentes que usan direcciones IP públicas de Azure, estas
reglas dejan de funcionar con el cambio a las direcciones privadas de red virtual.
Con los puntos de conexión de servicio, las entradas DNS para los servicios de Azure permanecen tal
cual en la actualidad y siguen resolviendo las direcciones IP públicas asignadas al servicio de Azure.
Grupos de seguridad de red (NSG) con puntos de conexión de servicio:
De forma predeterminada, los grupos de seguridad de red no solo permiten el tráfico de Internet
saliente, sino también el tráfico de su red virtual a los servicios de Azure. Este tráfico sigue
funcionando con puntos de conexión de servicio tal cual.
Si desea denegar todo el tráfico de Internet saliente y permitir únicamente el tráfico a servicios de
Azure concretos, puede hacerlo mediante las etiquetas de servicio de sus grupos de seguridad de
red. Puede especificar los servicios de Azure compatibles como destino en las reglas de grupos de
seguridad de red y Azure también proporciona el mantenimiento de las direcciones IP subyacentes
en cada etiqueta. Para más información, consulte las etiquetas de servicio de Azure para grupos de
seguridad de red.
Escenarios
Redes vir tuales emparejadas, conectadas o múltiples : para proteger los servicios de Azure de varias
subredes dentro de una red virtual o entre varias redes virtuales, puede habilitar los puntos de conexión
de servicio en cada una de las subredes de manera independiente y proteger los recursos del servicio de
Azure a todas las subredes.
Filtrado de tráfico saliente desde una red vir tual a los ser vicios de Azure : Si desea inspeccionar
o filtrar el tráfico enviado a un servicio de Azure desde una red virtual, puede implementar una aplicación
virtual de red dentro de la red virtual. Después, puede aplicar los puntos de conexión de servicio a la
subred donde se implementa la aplicación virtual de red y se protegen los recursos de servicio de Azure
solo para esta subred. Este escenario puede resultar útil si desea usar el filtrado de la aplicación virtual de
red para restringir el acceso de los servicios de Azure desde la red virtual solo a recursos concretos de
Azure. Para más información, consulte el artículo sobre la salida con las aplicaciones de redes virtuales.
Protección de recursos de Azure con los ser vicios implementados directamente en redes
vir tuales : puede implementar directamente varios servicios de Azure en subredes concretas de una red
virtual. Puede proteger los recursos de servicio de Azure para subredes de servicio administrado mediante
la configuración de un punto de conexión de servicio en la subred de servicio administrada.
Tráfico de disco procedente de una máquina vir tual de Azure : el tráfico de disco de máquina
virtual, tanto en discos administrados como no administrados, no resulta afectado por los puntos de
conexión de servicio que enrutan los cambios en Azure Storage. Este tráfico no solo incluye la E/S de disco,
sino también el montaje y desmontaje. Puede limitar el acceso de REST a los blobs en páginas para
determinadas redes mediante puntos de conexión de servicio y reglas de red de Azure Storage.
Registro y solución de problemas
Una vez que configure los puntos de conexión de servicio en un servicio concreto, asegúrese de que la ruta
del punto de conexión de servicio está en vigor de la forma siguiente:
Valide la dirección IP de origen de todas las solicitudes de servicio en los diagnósticos del servicio. Todas
las nuevas solicitudes con puntos de conexión de servicio muestran la dirección IP de origen de la solicitud
como la dirección de red virtual privada, asignada al cliente que realiza la solicitud desde la red virtual. Sin
el punto de conexión, la dirección es una dirección IP pública de Azure.
Visualice las rutas eficaces en cualquier interfaz de red de una subred. La ruta al servicio:
Muestra una ruta predeterminada más específica a los intervalos de prefijos de la dirección de cada
servicio
Tiene una clase nextHopType de VirtualNetworkServiceEndpoint
Indica que está en vigor una conexión más directa al servicio, en comparación con cualquier ruta de
 tunelización forzada

NOTE
Las rutas del punto de conexión de servicio invalidan las rutas BGP o UDR para la coincidencia del prefijo de dirección
de un servicio de Azure. Para más información, consulte el artículo en el que se indica cómo se solucionan problemas
con redes eficaces.

Aprovisionamiento
Un usuario con acceso de escritura a una red virtual puede configurar puntos de conexión de servicio en
redes virtuales de forma independiente. Para proteger los recursos de los servicios de Azure en una red
virtual, el usuario debe tener permiso en
[Link]/virtualNetworks/subnets/joinViaServiceEndpoint/action para las subredes agregadas. Los
roles de administrador de servicios integrados incluyen este permiso de manera predeterminada. El permiso
se puede modificar mediante la creación de roles personalizados.
Para obtener más información sobre los roles integrados, consulte Roles integrados en Azure. Para obtener
más información sobre la asignación de permisos concretos a roles personalizados, consulte Roles
personalizados de Azure.
Las redes virtuales y los recursos de servicio de Azure pueden encontrarse en la misma o en diferentes
suscripciones. Si los recursos de servicio de Azure y de red virtual están en distintas suscripciones, los
recursos deben estar en el mismo inquilino de Active Directory (AD).

Precios y límites
No se realiza ningún cargo adicional por el uso de puntos de conexión de servicio. El modelo de precios
vigente para los servicios de Azure (Azure Storage, Azure SQL Database, etc.) se aplica tal cual.
No hay límite en el número total de puntos de conexión de servicio que puede tener una red virtual.
Para determinados servicios de Azure (por ejemplo, cuentas de Azure Storage), puede aplicar límites en el
número de subredes que se usan para proteger el recurso. Para más información, consulte la documentación
de varios servicios en la sección Pasos siguientes.

Directivas de punto de conexión de servicio de una red virtual

Las directivas de punto de conexión de servicio de una red virtual permiten filtrar el tráfico de la red virtual a
los servicios de Azure. Este filtro solo permite determinados recursos de servicio de Azure a través de puntos
de conexión de servicio. Las directivas de punto de conexión de servicio ofrecen un control de acceso
pormenorizado para el tráfico de red virtual a los servicios de Azure. Para más información, consulte
Directivas de punto de conexión de servicio de red virtual.

Preguntas más frecuentes

Consulte las preguntas más frecuentes acerca de los puntos de conexión de servicio de red virtual.

Pasos siguientes
Configuración de los puntos de conexión de servicio de red virtual
Protección de una cuenta de Azure Storage para una red virtual
Protección de una instancia de Azure SQL Database para una red virtual
Protección de una instancia de Azure SQL Data Warehouse para una red virtual
Integración de servicios de Azure en redes virtuales
Directivas de puntos de conexión de servicio de red virtual
Plantilla de Azure Resource Manager
 Implementación de servicios de Azure dedicados en
las redes virtuales
23/09/2020 • 4 minutes to read • Edit Online

Al implementar servicios de Azure dedicados en una red virtual, puede comunicarse con los recursos de los
servicios de forma privada mediante direcciones IP privadas.

La implementación de servicios dentro de una red virtual ofrece las siguientes funcionalidades:
Los recursos dentro de la red virtual pueden comunicarse entre sí de forma privada a través de direcciones IP
privadas. Ejemplo: transferencia directa de datos entre HDInsight y SQL Server que se ejecutan en una
máquina virtual, en la red virtual.
Los recursos locales pueden acceder a recursos de una red virtual mediante direcciones IP privadas a través
de VPN de sitio a sitio (VPN Gateway) o ExpressRoute.
Las redes virtuales pueden estar emparejadas para habilitar que los recursos de las redes virtuales se
comuniquen entre sí mediante direcciones IP privadas.
Normalmente, las instancias de servicio en una red virtual están totalmente administradas por el servicio de
Azure. Esto incluye la supervisión del estado de los recursos y el escalado con carga.
Las instancias de los servicios se implementan en una subred de una red virtual. El acceso de red entrante y
saliente para la subred se debe abrir a través de grupos de seguridad de red, siguiendo las instrucciones
proporcionadas por el servicio.
Ciertos servicios también imponen restricciones en la subred donde se implementan, los cuales limitan la
 aplicación de directivas, las rutas o la combinación de máquinas virtuales y recursos de servicio dentro de la
misma subred. Compruebe las restricciones específicas de cada servicio porque podrían cambiar con el
tiempo. Algunos ejemplos de estos servicios son Azure NetApp Files, Dedicated HSM, Azure Container
Instances y App Service.
Opcionalmente, los servicios pueden requerir una subred delegada como un identificador explícito de que
una subred puede hospedar un servicio determinado. Mediante la delegación, los servicios obtienen
permisos explícitos para crear recursos específicos del servicio en la subred delegada.
Vea un ejemplo de una respuesta de API REST en una red virtual con una subred delegada. Puede ver una
lista completa de los servicios que usan el modelo de subred delegada a través de la API de Available
Delegations.
Servicios que pueden implementarse en una red virtual
C AT EGO RY SERVIC IO SUB RED DEDIC A DA 1

Proceso Máquinas virtuales: Linux o Windows No

Conjuntos de escalado de máquinas No
virtuales No
Servicio en la nube: Solo Virtual No2
Network (clásico)
Azure Batch

Red Application Gateway - WAF Sí

VPN Gateway Sí
Azure Firewall Sí
Aplicaciones virtuales de red No

data RedisCache Sí
Instancia administrada de Azure SQL Sí

Análisis HDInsight de Azure No2

Azure Databricks No2

Identidad Azure Active Directory Domain No

Services

Contenedores Azure Kubernetes Service (AKS) No2

Instancia de Azure Container (ACI) Sí
Motor de Azure Container Service con
el complemento CNI de Azure Virtual Sin
Network Sí
Funciones de Azure

Web API Management Sí

Aplicaciones web Sí
entorno de App Service Sí
Azure Logic Apps Sí

Hospedada Azure Dedicated HSM Sí

Azure NetApp Files Sí

1 El término "dedicada" significa que en esta subred solo se pueden implementar los recursos específicos del
servicio y no se pueden combinar con VM/VMSS del cliente.
2 Se recomienda que estos servicios estén en una subred dedicada, pero no un requisito obligatorio impuesto

por el servicio.
 Direcciones IP públicas
23/09/2020 • 15 minutes to read • Edit Online

Las direcciones IP públicas permiten a los recursos de Internet la comunicación entrante a los recursos de Azure.
Permiten que los recursos de Azure se comuniquen con los servicios de Azure orientados al público e Internet.
Hasta que cancele la asignación, la dirección estará dedicada al recurso. Un recurso sin una dirección IP pública
asignada puede realizar comunicaciones salientes. Azure asigna dinámicamente una dirección IP disponible que no
está dedicada al recurso. Para más información acerca de las conexiones salientes en Azure, consulte Comprender
las conexiones salientes en Azure.
En el Administrador de recursos de Azure, una dirección IP pública es un recurso que cuenta con propiedades
específicas. Estos son algunos de los recursos con los que puede asociar un recurso de dirección IP pública:
Interfaces de red de máquinas virtuales
Equilibradores de carga accesibles desde Internet
Puertas de enlace de VPN
Puertas de enlace de aplicaciones
Azure Firewall

Versión de la dirección IP
Las direcciones IP públicas se crean con una dirección IPv4 o IPv6.

SKU
Las direcciones IP públicas se crean con una de las SKU siguientes:

IMPORTANT
En los recursos de IP pública y en el equilibrador de carga se requieren SKU coincidentes. No puede tener una combinación
de recursos de SKU básica y recursos de SKU estándar. No se pueden asociar máquinas virtuales independientes, máquinas
virtuales en un recurso de conjunto de disponibilidad o conjuntos de escalado de máquinas virtuales a ambas SKU
simultáneamente. Para los nuevos diseños, deberá considerar usar los recursos de SKU estándar. Consulte Load Balancer
Estándar para obtener más información.

Estándar
Las direcciones IP públicas de SKU estándar:
Utilice siempre el método de asignación estática.
Tiene un tiempo espera de inactividad del flujo originado de entrada ajustable de entre 4 y 30 minutos, y un
valor predeterminado de 4 minutos, y el valor predeterminado del tiempo de espera del flujo originado es de 4
minutos.
Son seguras de forma predeterminada y se cierran al tráfico de entrada. Permiten mostrar el tráfico de entrada
con un grupo de seguridad de red.
Se asignan a interfaces de red, equilibradores de carga estándar públicos o puertas de enlace de aplicaciones.
Para más información sobre Standard Load Balancer, consulte ¿Qué es Azure Load Balancer?.
Puede ser con redundancia de zona o zonal (se pueden crear zonal y garantizada en una zona de disponibilidad
específica). Para obtener más información acerca de las zonas de disponibilidad, consulte Introducción a las
zonas de disponibilidad y Standard Load Balancer and Availability Zones (Load Balancer Standard y zonas de
 disponibilidad).

NOTE
Para evitar que se produzca un error en la comunicación de entrada con el recurso SKU estándar, debe crear un grupo de
seguridad de red, asociarlo y permitir explícitamente el tráfico de entrada deseado.

NOTE
Cuando se usa el servicio de metadatos de instancia IMDS, solo hay direcciones IP públicas con SKU básica disponibles. No se
admiten las SKU estándar.

Básica
Todas las direcciones IP públicas creadas antes de la introducción de SKU son direcciones IP públicas de SKU básica.
Con la introducción de SKU, puede especificar qué SKU le gustaría que fuera la dirección IP pública.
Las direcciones de SKU básica:
Se asignan con el método de asignación estática o el de asignación dinámica.
Tiene un tiempo espera de inactividad del flujo originado de entrada ajustable de entre 4 y 30 minutos, y un
valor predeterminado de 4 minutos, y el valor predeterminado del tiempo de espera del flujo originado es de 4
minutos.
Están abiertas de forma predeterminada. Se recomienda el uso de grupos de seguridad de red, pero es opcional
para restringir el tráfico de entrada o de salida.
Se asignan a cualquier recurso de Azure al que se pueda asignar una dirección IP pública, como:
Interfaces de red
Puertas de enlace de VPN
Puertas de enlace de aplicaciones
Equilibradores de carga públicos
No admiten escenarios de zona de disponibilidad. Use la dirección IP pública de SKU estándar para los
escenarios de zona de disponibilidad. Para obtener más información acerca de las zonas de disponibilidad,
consulte Introducción a las zonas de disponibilidad y Standard Load Balancer and Availability Zones (Load
Balancer Standard y zonas de disponibilidad).

Método de asignación
Las direcciones IP públicas básicas y estándar admiten la asignación estática . Al recurso se le asigna una dirección
IP cuando aquel se crea. La dirección IP se libera cuando el recurso se elimina.
Las direcciones IP públicas de SKU básica admiten una asignación dinámica . Este es el método de asignación
predeterminado. La dirección IP no se asigna al recurso en el momento de crearse cuando se selecciona el método
dinámico.
La dirección IP se asigna cuando se asocia el recurso de dirección IP pública con una:
Máquina virtual
La primera máquina virtual está asociada con el grupo de back-end de un equilibrador de carga.
La dirección IP se libera cuando se detiene (o elimina) el recurso,
Por ejemplo, un recurso de dirección IP pública se libera de un recurso denominado Recurso A . Recurso A recibe
una dirección IP diferente en el inicio si el recurso de dirección IP pública se vuelve a asignar.
La dirección IP se libera cuando se cambia el método de asignación de estático a dinámico . Para asegurarse de
que la dirección IP para el recurso asociado siga siendo la misma, establezca explícitamente el método de
asignación en estático . Una dirección IP estática se asigna de inmediato.

NOTE
Incluso cuando se establece el método de asignación en estático , no se puede especificar la dirección IP real asignada al
recurso de dirección IP pública. Azure asigna la dirección IP desde un grupo de direcciones IP disponibles en la ubicación de
Azure cuando se crea el recurso.

Las direcciones IP públicas se suelen usar en los escenarios siguientes:

Cuando debe actualizar las reglas de firewall para comunicarse con los recursos de Azure.
La resolución de nombres DNS, en la que un cambio de dirección IP requeriría actualizar los registros D.
Los recursos de Azure se comunican con otras aplicaciones o servicios que utilizan un modelo de seguridad
basado en dirección IP.
Use certificados TLS/SSL vinculados a una dirección IP.

NOTE
Azure asigna direcciones IP públicas a partir de un rango único para cada región en cada nube de Azure. Puede descargar la
lista de intervalos (prefijos) para las nubes de Azure Pública, Gobierno de Estados Unidos, China y Alemania.

Resolución de nombres de host DNS

Seleccione la opción para especificar una etiqueta de nombre de dominio DNS para un recurso de dirección IP
pública.
Esta selección crea una asignación para domainnamelabel .location .[Link] a la dirección IP pública
en el DNS administrado por Azure.
Por ejemplo, la creación de una dirección IP pública con:
contoso como domainnamelabel
Ubicación de Azure Oeste de EE. UU.
El nombre de dominio completo (FQDN) [Link] se resuelve en la dirección IP
pública del recurso.

IMPORTANT
Cada etiqueta de nombre de dominio que se cree debe ser única dentro de su ubicación de Azure.

Recomendaciones de DNS
Si se necesita un traslado de región, no puede migrar el nombre de dominio completo de la dirección IP pública.
Puede usar el nombre de dominio completo para crear un registro CNAME personalizado que apunte a la dirección
IP pública.
Si se requiere un traslado a una dirección IP pública diferente, actualice el registro CNAME en lugar de actualizar el
FQDN.
Puede usar Azure DNS o un proveedor de DNS externo para el registro DNS.
Máquinas virtuales
Puede asociar una dirección IP pública con una máquina virtual Windows o Linux mediante la asignación a su
interfaz de red .
Elija dinámica o estática para la dirección IP pública. Más información sobre asignación de direcciones IP a
interfaces de red.

Equilibradores de carga accesibles desde Internet

Puede asociar una dirección IP pública de SKU con una instancia de Azure Load Balancer asignándola a la
configuración del front-end del equilibrador de carga. La dirección IP pública actúa como dirección IP de carga
equilibrada.
Puede asignar una dirección IP pública estática o dinámica al front-end de un equilibrador de carga. Puede asignar
varias direcciones IP públicas a un front-end de equilibrador de carga. Esta configuración habilita escenarios de
varias VIP, como un entorno de varios inquilinos con sitios web basados en TLS.
Para más información sobre las SKU de los equilibradores de carga de Azure, consulte Azure load balancer
standard SKU (SKU estándar de equilibrador de carga de Azure).

Puertas de enlace de VPN

Azure VPN Gateway conecta una red virtual de Azure a:
Redes virtuales de Azure
Redes locales.
Se asigna una dirección IP pública a la instancia de VPN Gateway para habilitar la comunicación con la red remota.
Solo puede asignar una dirección IP pública dinámica de nivel básico a una puerta de enlace de VPN.

Puertas de enlace de aplicaciones

Puede asociar una dirección IP pública con una puerta de enlace de aplicacionesde Azure asignándola a la
configuración del front-end de la puerta de enlace.
Asigne una dirección IP pública dinámica de nivel básico a una configuración front-end V1 de la puerta de
enlace de aplicaciones.
Asigne un dirección de SKU estándar estática a una configuración de front-end V2.

De un vistazo
En la siguiente tabla se muestra la propiedad a través de la cual una dirección IP pública se puede asociar a un
recurso de nivel superior y los métodos de asignación posibles.

REC URSO DE N IVEL A SO C IA C IÓ N DE DIREC C IÓ N

SUP ERIO R IP DIN Á M IC A ESTÁT IC A

Máquina virtual interfaz de red Sí Sí

Equilibrador de carga Configuración de front-end Sí Sí

accesible desde Internet

puerta de enlace de VPN Configuración de dirección Sí No

IP de puerta de enlace
 REC URSO DE N IVEL A SO C IA C IÓ N DE DIREC C IÓ N
SUP ERIO R IP DIN Á M IC A ESTÁT IC A

puerta de enlace de Configuración de front-end Sí (solo en V1) Sí (solo en V2)

aplicaciones

Límites
Los límites de una dirección IP se encuentran en el conjunto completo de límites de red de Azure.
Los límites son por región y suscripción. Póngase en contacto con el servicio de soporte técnico para aumentar los
límites predeterminados hasta alcanzar los límites máximos, según las necesidades empresariales.

Precios
Las direcciones IP públicas pueden tener un precio simbólico. Para más información sobre los precios de las
direcciones IP en Azure, revise la página Precios de las direcciones IP.

Pasos siguientes
Obtener información sobre las direcciones IP privadas en Azure
Implementar una máquina virtual con una dirección IP pública estática mediante el portal de Azure
 Direcciones IP privadas
23/09/2020 • 7 minutes to read • Edit Online

Las direcciones IP privadas permiten la comunicación entre los recursos de Azure.

Los recursos pueden:
Ser servicios de Azure, como:
Interfaces de red de máquinas virtuales
Equilibradores de carga internos (ILB)
Puertas de enlace de aplicaciones
Estar en una red virtual.
Ser una red virtual a una red local mediante una instancia de VPN Gateway o circuito de ExpressRoute.
Las IP privadas permiten la comunicación con estos recursos sin usar una dirección IP pública.

Método de asignación
Azure asigna direcciones IP privadas a recursos del intervalo de direcciones de la subred de la red virtual en la que
se encuentra el recurso.
Azure reserva las cuatro primeras direcciones en cada intervalo de direcciones de subred. No se pueden asignar
direcciones a los recursos. Por ejemplo, si el intervalo de direcciones de la subred es [Link]/16, las direcciones
[Link]-[Link] y [Link] no están disponibles. Las direcciones IP dentro del intervalo de direcciones de la
subred solo pueden asignarse a un recurso a la vez.
Hay dos métodos para proporcionar direcciones IP privadas:
Dinámica : Azure asigna la siguiente dirección IP sin asignar o no reservada disponible en el intervalo de
direcciones de la subred. Por ejemplo, Azure asigna [Link] a un nuevo recurso, si las direcciones [Link]
a [Link] ya están asignadas a otros.
Este es el método de asignación predeterminado. Una vez asignadas, las direcciones IP dinámicas solo se
liberan cuando una interfaz de red:
Deleted
Se reasigna a una subred diferente dentro de la misma red virtual.
El método de asignación se cambia a estático y se especifica una dirección IP diferente.
De forma predeterminada, cuando se cambia el método de asignación de dinámica a estática, Azure asigna
la dirección asignada dinámicamente anterior como dirección estática.
Estática : seleccione y asigne cualquier dirección IP sin asignar o no reservada en el intervalo de direcciones
de la subred.
Por ejemplo, un intervalo de direcciones de la subred es [Link]/16 y las direcciones [Link] a [Link] se
asignan a otros recursos. Puede asignar cualquier dirección entre [Link] y [Link]. Las direcciones
estáticas solo se liberan cuando se elimina la interfaz de red.
Azure asigna la dirección IP estática como dirección IP dinámica cuando se cambia el método de asignación.
La reasignación se produce incluso si la dirección no es la siguiente disponible en la subred. La dirección
cambia cuando la interfaz de red se asigna a una subred diferente.
Para asignar la interfaz de red a una subred diferente, debe cambiar el método de asignación de estático a
 dinámico. Asigne la interfaz de red a una subred diferente y, después, cambie el método de asignación a
estático nuevamente. Asigne una dirección IP del nuevo intervalo de direcciones de la subred.

Máquinas virtuales
Una o varias direcciones IP privadas se asignan a una o varias interfaces de red . Las interfaces de red se asignan
a una máquina virtual de Windows o Linux. En todas las direcciones IP privadas se puede especificar el método de
asignación como estática o dinámica.
Resolución de nombres de host DNS internos (para máquinas virtuales)
Las máquinas virtuales de Azure se configuran con servidores DNS administrados por Azure de forma
predeterminada. Puede configurar de forma explícita los servidores DNS personalizados. Estos servidores DNS
proporcionan la resolución de nombres internos para las máquinas virtuales que se encuentran en la misma red
virtual.
Se agrega a los servidores DNS administrados por Azure una asignación para el nombre de host a una dirección IP
privada de la máquina virtual.
Un nombre de host se asigna a la dirección IP principal de la interfaz de red principal cuando una máquina virtual
tiene:
Varias interfaces de red
Varias direcciones IP
Ambos
Las máquinas virtuales configuradas con DNS administrado por Azure resuelven los nombres de host dentro de la
misma red virtual. Use un servidor DNS personalizado para resolver los nombres de host de las máquinas
virtuales en redes virtuales conectadas.

Equilibradores de carga internos (ILB) y puertas de enlace de

aplicaciones
Puede asignar una dirección IP privada a la configuración de front-end de los siguientes:
Equilibrador de carga interno de Azure (ILB)
Introducción a Puerta de enlace de aplicaciones
Esta dirección IP privada funciona como punto de conexión interno. A este punto de conexión solo pueden acceder
los recursos en su red virtual y las redes remotas conectadas a dicha red virtual. Se puede asignar una dirección IP
estática o dinámica.

De un vistazo
En la tabla siguiente se muestra la propiedad a través de la cual una dirección IP privada se puede asociar a un
recurso.
También se muestran los métodos de asignación posibles que pueden usarse:
Dinámica
estática

REC URSO DE N IVEL A SO C IA C IÓ N DE DIREC C IÓ N

SUP ERIO R IP DIN Á M IC A ESTÁT IC A

Máquina virtual interfaz de red Sí Sí

 REC URSO DE N IVEL A SO C IA C IÓ N DE DIREC C IÓ N
SUP ERIO R IP DIN Á M IC A ESTÁT IC A

Equilibrador de carga Configuración de front-end Sí Sí

puerta de enlace de Configuración de front-end Sí Sí

aplicaciones

Límites
Los límites en una dirección IP se encuentran en el conjunto completo de límites de red de Azure. Los límites son
por región y suscripción. Póngase en contacto con el servicio de soporte técnico para aumentar los límites
predeterminados hasta alcanzar los límites máximos, según las necesidades empresariales.

Pasos siguientes
Obtenga más información sobre las direcciones IP públicas en Azure.
Implemente una VM con una dirección IP privada estática
 Prefijo de dirección IP pública
23/09/2020 • 10 minutes to read • Edit Online

Un prefijo de dirección IP pública es un rango reservado de direcciones IP en Azure. Azure proporciona a las
suscripciones un rango contiguo de direcciones en función de la cantidad de ellas que se especifiquen.
Si no está familiarizado con las direcciones públicas, consulte Direcciones IP públicas.
Las direcciones IP públicas se asignan desde un grupo de direcciones en cada región de Azure. Puede descargar la
lista de intervalos que Azure usa para cada región. Por ejemplo, [Link]/16 es uno de los más de 100
intervalos que Azure usa en la región Este de EE. UU. El intervalo incluye las direcciones utilizables de [Link] a
[Link].
Especifique un nombre y cuántas direcciones desea que incluya el prefijo para crear un prefijo de dirección IP
pública en una región de Azure y una suscripción.
Los rangos de direcciones IP públicas se asignan con el prefijo que elija. Si crea un prefijo de /28, Azure
proporciona16 direcciones IP de uno de sus rangos.
No se sabe qué intervalo asignará Azure hasta que se crea el intervalo, pero las direcciones son contiguas.
Los prefijos de direcciones IP públicas tienen una cuota; para más información, consulte los precios de las
direcciones IP públicas.

¿Por qué crear un prefijo de dirección IP pública?

Cuando se crean recursos de dirección IP pública, Azure asigna una dirección IP pública disponible de cualquiera
de los rangos que se usan en esa región.
Hasta que Azure asigne la dirección IP, no se conocerá la IP exacta. Este proceso puede resultar problemático
cuando se crean reglas de firewall que permiten direcciones IP concretas. Para cada dirección IP agregada, se debe
agregar una regla de firewall correspondiente.
Si se asignan direcciones a los recursos desde un prefijo de dirección IP pública, no es preciso actualizar las reglas
de firewall. Todo el rango se agrega a la regla.

Ventajas
Los recursos de dirección IP pública se crean desde un rango conocido.
Configuración de reglas de firewall con rangos que incluyen direcciones IP públicas que ya se han asignado y
direcciones que no se han asignado aún. Esta configuración elimina la necesidad de cambiar las reglas de
firewall cuando se asignan direcciones IP a los nuevos recursos.
El tamaño predeterminado de un intervalo que se puede crear es /28 o 16 direcciones IP.
No hay límites en cuanto al número de rangos que se pueden crear. Hay límites en el número máximo de
direcciones IP públicas estáticas que puede haber en una suscripción de Azure. El número de rangos que se
crean no puede abarcar más direcciones IP públicas de las que se pueden tener en una suscripción. Para más
información, consulte Límites de Azure.
Las direcciones que se crean con direcciones del prefijo se pueden asignar a cualquier recurso de Azure al que
se pueda asignar una dirección IP pública.
Puede ver fácilmente qué direcciones IP se han proporcionado y cuáles aún no se han proporcionado dentro
del rango.
Escenarios
Puede asociar los siguientes recursos a una dirección IP pública estática desde un prefijo:

RESO URC E ESC EN A RIO PA SO S

Máquinas virtuales La asociación de direcciones IP públicas Para asociar direcciones IP de un prefijo

desde un prefijo a las máquinas a la máquina virtual:
virtuales en Azure reduce la sobrecarga 1. Cree un prefijo.
de administración que se produce 2. Cree una dirección IP del prefijo.
cuando se agregan direcciones IP a una 3. Asocie la dirección IP a la interfaz de
lista de direcciones IP permitidas en el red de la máquina virtual.
firewall. Puede agregar un prefijo También puede asociar las direcciones
completo con una única regla de IP a un conjunto de escalado de
firewall. A medida que escala con máquinas virtuales.
máquinas virtuales de Azure, puede
asociar direcciones IP del mismo prefijo
para ahorrar costos, tiempo y
sobrecarga de administración.

Equilibradores de carga estándar La asociación de direcciones IP públicas Para asociar las direcciones IP de un
de un prefijo a la configuración IP de prefijo a un equilibrador de carga:
front-end o a la regla de salida de un 1. Cree un prefijo.
equilibrador de carga garantiza la 2. Cree una dirección IP del prefijo.
simplificación del espacio de direcciones 3. Al crear el equilibrador de carga,
IP públicas de Azure. Para simplificar su seleccione o actualice la dirección IP
escenario, limpie las conexiones que creó en el paso 2 como dirección IP
salientes de un rango de direcciones IP de front-end del equilibrador de carga.
contiguas.

Azure Firewall Puede usar una dirección IP pública de Para asociar una dirección IP de un
un prefijo para la conexión SNAT de prefijo a su firewall:
salida. Todo el tráfico de red virtual 1. Cree un prefijo.
saliente se traslada a la dirección IP 2. Cree una dirección IP del prefijo.
pública de Azure Firewall. 3. Cuando implemente el firewall de
Azure, no olvide seleccionar la dirección
IP que previamente proporcionó desde
el prefijo.

Application Gateway v2 Puede usar una dirección IP pública de Para asociar una dirección IP de un
un prefijo para el escalado automático y prefijo a su puerta de enlace:
Application Gateway v2 con 1. Cree un prefijo.
redundancia de zona. 2. Cree una dirección IP del prefijo.
3. Cuando implemente Application
Gateway, asegúrese de seleccionar la
dirección IP que proporcionó
previamente desde el prefijo.

Restricciones
No se pueden especificar las direcciones IP del prefijo. Azure proporciona las direcciones IP para el prefijo, en
función del tamaño que especifique.
De manera predeterminada puede crear un prefijo de hasta 16 direcciones IP o un /28. Para más información,
consulte Solicitudes de aumento de los límites de redes y Límites de Azure.
Una vez que se ha creado el prefijo no se puede cambiar el intervalo.
Solo se pueden asignar direcciones IP públicas estáticas del intervalo del prefijo creadas con la SKU Estándar.
Para más información sobre las SKU de direcciones IP públicas, consulte Direcciones IP publicas.
Las direcciones del intervalo solo se pueden asignar a recursos de Azure Resource Manager. En el modelo de
 implementación clásico no se pueden asignar direcciones a recursos.
Todas las direcciones IP públicas creadas a partir del prefijo deben existir en la misma región y suscripción de
Azure que el prefijo. Las direcciones se deben asignar a recursos de la misma región y suscripción.
No se puede eliminar un prefijo si tiene direcciones asignadas a recursos de dirección IP públicas asociados a
un recurso. En primer lugar, debe desasociar todos los recursos de dirección IP pública que tienen asignadas
direcciones IP del prefijo.

Pasos siguientes
Creación de un prefijo de dirección IP pública
 ¿Qué es IPv6 para Azure Virtual Network?
23/09/2020 • 12 minutes to read • Edit Online

IPv6 para Azure Virtual Network (VNet) le permite hospedar aplicaciones en Azure con la conectividad IPv6 e
IPv4, tanto en una red virtual como hacia y desde Internet. Debido al agotamiento de direcciones IPv4 públicas,
las nuevas redes de movilidad e Internet de las cosas (IoT) a menudo se basan en IPv6. Incluso las redes móviles
e ISP consolidadas se están transformando a IPv6. Los servicios que solo usan IPv4 pueden encontrarse en
desventaja real en los mercados existentes y emergentes. La conectividad IPv4/IPv6 de pila doble permite que
los servicios hospedados en Azure atraviesen esta brecha tecnológica con los servicios en pila doble disponibles
globalmente que se conectan fácilmente con la conectividad IPv4 existente y con estos nuevos dispositivos y
redes IPv6.
La conectividad IPv6 original de Azure permite proporcionar fácilmente conectividad a Internet (IPv4/IPv6) de
doble pila para las aplicaciones hospedadas en Azure. Permite la implementación simple de VM con
conectividad IPv6 con equilibrio de carga para las conexiones iniciadas tanto entrantes como salientes. Esta
característica todavía está disponible y se puede encontrar más información aquí. La conectividad IPv6 para
Azure Virtual Network es mucho más completa: permite implementar arquitecturas de soluciones IPv6
completas en Azure.
El siguiente diagrama representa una implementación simple de pila doble (IPv4/IPv6) en Azure:

Ventajas
Ventajas de IPv6 para la red virtual de Azure:
Ayuda a ampliar el alcance de sus aplicaciones hospedadas en Azure en los mercados móvil y de Internet de
las cosas en desarrollo.
Las VM IPv4/IPv6 con pila doble proporcionan la máxima flexibilidad de implementación del servicio. Una
sola instancia del servicio se puede conectar con clientes de Internet que admitan tanto IPv4 como IPv6.
Se basa en la consolidada y estable conectividad IPv6 de Azure Virtual Machines con Internet.
Ofrece seguridad de forma predeterminada, puesto que la conectividad IPv6 a Internet solo se establece
cuando se solicita explícitamente en la implementación.
Capacidades
IPv6 para red virtual de Azure incluye las siguientes características:
Los clientes de Azure pueden definir su propio espacio de direcciones de red virtual IPv6 para satisfacer las
necesidades de sus aplicaciones y clientes, o bien para la integración sin problemas en su espacio de IP local.
Las redes virtuales (IPv4 e IPv6) de pila doble con subredes de pila doble permiten a las aplicaciones
conectarse con recursos IPv4 e IPv6 en su red virtual o en Internet.

IMPORTANT
Las subredes para IPv6 deben tener un tamaño exactamente de /64. Esto garantiza la compatibilidad en el futuro
si habilita el enrutamiento de la subred a una red local, ya que algunos enrutadores sólo pueden aceptar rutas /64
IPv6.

Proteja los recursos con reglas de IPv6 para grupos de seguridad de red.
Y las protecciones de denegación de servicio distribuido (DDoS) de la plataforma Azure se amplían a
las IP públicas con conexión a Internet.
Personalice el enrutamiento del tráfico IPv6 en la red virtual con rutas definidas por el usuario
(especialmente al utilizar aplicaciones virtuales de red para mejorar su aplicación).
Las máquinas virtuales Linux y Windows pueden utilizar IPv6 para la red virtual de Azure.
Compatibilidad con la instancia de IPv6 pública de Standard Load Balancer para crear aplicaciones resistentes
y escalables, lo que incluye:
Sondeo de estado de IPv6 opcional para establecer qué instancias del grupo de back-end tienen un
estado correcto y, por tanto, reciben flujos nuevos.
Reglas de salida opciones que proporcionan un control declarativo completo sobre la conectividad de
salida para escalar y ajustar esta conectividad según sus necesidades específicas.
Distintas configuraciones de front-end opcionales que permiten que un único equilibrador de carga
use varias direcciones IP públicas IPv6: el mismo protocolo y puerto de front-end pueden usarse entre
las direcciones de front-end.
Los puertos IPv6 opcionales se pueden reutilizar en las instancias de back-end mediante la
característica de IP flotante de las reglas de equilibrio de carga.
Nota: El equilibrio de carga no realiza ninguna traducción de protocolo (sin NAT64).
Nota: IPv6 solo puede ser de carga equilibrada en la interfaz de red (NIC) principal en máquinas
virtuales de Azure.
Compatibilidad con la instancia de IPv6 interna de Standard Load Balancer para crear aplicaciones resistentes
de varios niveles en redes virtuales de Azure.
Compatibilidad con la instancia de IPv6 pública de Basic Load Balancer para la compatibilidad con
implementaciones heredadas.
Las direcciones IP públicas y los intervalos de direcciones IPv6 reservadas proporcionan direcciones IPv6
estables y predecibles que facilitan la inclusión en listas blancas de las aplicaciones hospedadas en Azure
para su empresa y sus clientes.
La dirección IP pública a nivel de instancia proporciona conectividad IPv6 a Internet directamente a las
máquinas virtuales individuales.
Adición de IPv6 a implementaciones de solo IPv4 existentes: esta característica permite agregar fácilmente
conectividad IPv6 a las implementaciones existentes de solo IPv4 sin necesidad de volver a crear dichas
implementaciones. El tráfico de red IPv4 no se ve afectado durante este proceso. Por ello, en función de la
aplicación y del sistema operativo, es posible que pueda agregar IPv6 incluso a servicios en directo.
Permita a los clientes de Internet acceder sin problemas a la aplicación de pila dual con el protocolo de su
elección con compatibilidad con Azure DNS para registros IPv6 (AAAA).
Cree aplicaciones de pila doble que se escalen automáticamente a su carga con conjuntos de escalado de
 máquinas virtuales con IPv6.
Emparejamiento de redes virtuales: tanto en el emparejamiento regional como global, permite conectar
redes virtuales de pila dual. Tanto los puntos de conexión de IPv4 como de IPv6 en las máquinas virtuales de
las redes emparejadas podrán comunicarse entre sí. Incluso puede emparejar pilas dobles con redes
virtuales solo de IPv4 mientras realiza la transición de las implementaciones de doble pila.
Los diagnósticos y la solución de problemas de IPv6 están disponibles con las características de alertas y
métricas del equilibrador de carga, así como con las características de Network Watcher como la captura de
paquetes, los registros de flujo de grupos de seguridad de red, la solución de problemas de conexión y la
supervisión de conexiones.

Ámbito
IPv6 para Azure Virtual Network es un conjunto de características básicas que permite a los clientes hospedar
aplicaciones de pila dual (IPv4 + IPv6) en Azure. Tenemos previsto agregar compatibilidad con IPv6 a más
características de red de Azure a lo largo del tiempo y, finalmente, ofrecer versiones de pila dual de los servicios
PaaS de Azure. No obstante, mientras tanto, se puede acceder a todos los servicios PaaS de Azure a través de los
puntos de conexión IPv4 en máquinas virtuales de pila dual.

Limitaciones
La versión actual de IPv6 para Azure Virtual Network tiene las siguientes limitaciones:
IPv6 para red virtual de Azure está disponible en todas las regiones comerciales globales de Azure y de la
Administración Pública de EE. UU. mediante todos los métodos de implementación.
Las puertas de enlace de ExpressRoute se PUEDEN usar para el tráfico de solo IPv4 en una red virtual con
IPv6 habilitado. La compatibilidad con el tráfico IPv6 está en nuestro plan de desarrollo.
Las puertas de enlace de VPN NO SE PUEDEN usar en una red virtual que tiene IPv6 habilitado, ya sea
directamente o emparejadas con "UseRemoteGateway".
La plataforma de Azure (AKS, etc.) no admite la comunicación IPv6 para los contenedores.
IPv6 solo puede ser de carga equilibrada en la interfaz de red (NIC) principal en máquinas virtuales de Azure.
No se admite el tráfico IPv6 de equilibrio de carga a NIC secundarias.
No se admiten máquinas virtuales o conjuntos de escalado de máquinas virtuales de solo IPv6; cada NIC
debe incluir al menos una configuración de IP IPv4.
Al agregar IPv6 a las implementaciones IPv4 existentes, los rangos IPv6 no se pueden agregar a una red
virtual con vínculos de navegación de recursos existentes.
El reenvío de DNS para IPv6 es compatible actualmente con DNS público de Azure, pero el DNS inverso
todavía no se admite.

Precios
El ancho de banda y los recursos de Azure de IPv6 tienen el mismo precios que para IPv4. No se aplican cargos
adicionales ni diferentes para IPv6. Puede encontrar detalles sobre precios de direcciones IP públicas, ancho de
banda de red o Load Balancer.

Pasos siguientes
Aprenda a implementar una aplicación de pila doble IPv6 con Azure PowerShell.
Aprenda a implementar una aplicación de pila doble IPv6 con la CLI de Azure.
Aprenda a implementar una aplicación de pila dual IPv6 mediante plantillas de Resource Manager (JSON).
 Prefijo de dirección IPv6 pública reservada
23/09/2020 • 4 minutes to read • Edit Online

En Azure, las máquinas virtuales (VM) y las redes virtuales (VNet) de pila dual (IPv4+IPv6) son seguras de manera
predeterminada, ya que no tienen conectividad a Internet. Puede agregar fácilmente una conectividad a Internet
IPv6 a sus máquinas virtuales e instancias de Azure Load Balancer con direcciones IPv6 públicas que obtiene de
Azure.
Todas las direcciones IP públicas que reserva están asociadas a una región de Azure de su preferencia y a su
suscripción de Azure. Puede trasladar una IP pública IPv6 (estática) reservada entre cualquiera de las instancias de
Azure Load Balancer o las máquinas virtuales de Azure de su suscripción. Puede desasociar la IP pública IPv6 por
completo y se conservará para su uso cuando esté listo.

WARNING
Tenga cuidado de no eliminar por accidente las IP públicas. La eliminación de una IP pública la quita de su suscripción y no
podrá recuperarla (ni siquiera con la ayuda del Soporte técnico de Azure).

Además de reservar direcciones IPv6 individuales, puede reservar intervalos contiguos de direcciones IPv6 de
Azure (conocidos como prefijo IP) para su uso. De manera similar a las direcciones IP individuales, los prefijos
reservados se asocian con una región de Azure de su preferencia y con su suscripción de Azure. La reserva de un
intervalo de direcciones contiguo y predecible tiene muchos usos. Por ejemplo, puede simplificar en gran medida
la lista blanca de direcciones IP de las aplicaciones hospedadas en Azure por su empresa y sus clientes, ya que los
intervalos de direcciones IP estáticas se pueden programar fácilmente en los firewalls locales. Puede crear IP
públicas individuales a partir del prefijo IP según sea necesario y, cuando elimine esas IP públicas individuales, se
devuelven al intervalo reservado para que pueda volver a usarlas más adelante. Todas las direcciones IP del prefijo
IP están reservadas para su uso exclusivo hasta que se elimine el prefijo.

Tamaños del prefijo IPv6

Están disponibles los tamaños de prefijo de IP pública siguientes:
Tamaño mínimo del prefijo IPv6: /127 = 2 direcciones
Tamaño máximo del prefijo IPv6: /124 = 16 direcciones
El tamaño del prefijo se especifica como un tamaño de máscara de enrutamiento de interdominios sin clases
(CIDR). Por ejemplo, una máscara de /128 representa una dirección IPv6 individual, ya que las direcciones IPv6
están compuestas de 128 bits.

Precios
Para los costos asociados con el uso de direcciones IP públicas de Azure, tanto direcciones IP individuales como
intervalos IP, consulte Precios de las direcciones IP públicas.

Limitaciones
IPv6 solo se admite en IP públicas básicas con asignación "dinámica", lo que significa que la dirección IPv6
cambiará si elimina y vuelve a implementar la aplicación (máquinas virtuales o equilibradores de carga) en Azure.
Las IP públicas estándar IPv6 admiten únicamente la asignación estática (reservada), aunque los equilibradores de
carga internos estándar también pueden admitir la asignación dinámica desde dentro de la subred a la que están
asignadas.
Como procedimiento recomendado, se recomienda usar IP públicas estándar e instancias de Standard Load
Balancer para las aplicaciones IPv6.

Pasos siguientes
Reserve un prefijo de dirección IPv6 pública.
Obtenga más información sobre las direcciones IPv6.
Obtenga información sobre cómo crear y usar IP públicas (tanto IPv4 como IPv6) en Azure.
 ¿Qué es la preferencia de enrutamiento (versión
preliminar)?
23/09/2020 • 11 minutes to read • Edit Online

Las preferencias de enrutamiento de Azure le permiten elegir cómo se enruta el tráfico entre Azure e Internet.
Puede optar por enrutar el tráfico a través de la red de Microsoft o a través de una red de ISP (Internet público).
Estas opciones también se conocen como enrutamiento de tipo "cold-potato" y enrutamiento de tipo "hot-potato"
respectivamente. El precio de la transferencia de datos de salida varía en función de la selección de enrutamiento.
Puede elegir la opción de enrutamiento al crear una dirección IP pública. Asimismo, la dirección IP pública se
puede asociar a recursos como máquinas virtuales, conjuntos de escalado de máquinas virtuales, equilibradores
de carga accesibles desde Internet, etc. También puede establecer la preferencia de enrutamiento para los
recursos de Azure Storage, como blobs, archivos, web y Azure Data Lake. De forma predeterminada, el tráfico se
enruta a través de la red global de Microsoft para todos los servicios de Azure.

IMPORTANT
La preferencia de enrutamiento se encuentra actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin
Acuerdo de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas
características no sean compatibles o que tengan sus funcionalidades limitadas. Para más información, consulte Términos de
uso complementarios de las Versiones Preliminares de Microsoft Azure.

Enrutamiento a través de la red global de Microsoft

Al enrutar el tráfico a través de la red global de Microsoft, este se entrega en una de las redes más grandes del
mundo que abarca más de 160.000 kilómetros de fibra con más de 165 puntos de presencia (POP) perimetral. La
red está bien aprovisionada y dispone de varias rutas de acceso de fibra redundantes para garantizar una
confiabilidad y disponibilidad excepcionalmente altas. Igualmente, la ingeniería del tráfico se administra mediante
un controlador WAN que define un software; este controlador se encarga de garantizar la selección de la ruta de
acceso de baja latencia para el tráfico y ofrece un rendimiento de red Premium.

Tráfico de entrada: el anuncio de difusión por proximidad de BGP global garantiza que el tráfico de entrada
acceda a la red de Microsoft más cercana al usuario. Por ejemplo, si un usuario de Singapur obtiene acceso a los
recursos de Azure hospedados en Chicago (EE. UU.), el tráfico accede a la red global de Microsoft en el protocolo
POP perimetral de Singapur y viaja por la red de Microsoft hasta el servicio hospedado en Chicago.
Tráfico de salida: el tráfico de salida sigue el mismo principio. El tráfico pasa la mayor parte de su recorrido en
la red global de Microsoft y sale por la más cercana al usuario. Por ejemplo, si el tráfico de Azure Chicago está
destinado a un usuario de Singapur, el tráfico viaja a través de la red de Microsoft desde Chicago a Singapur y
sale de la red de Microsoft en el protocolo POP perimetral de Singapur.
Tanto el tráfico de entrada como el de salida se mantiene la mayor parte del tiempo en la red global de Microsoft.
Esto también se conoce como enrutamiento de tipo "cold potato" .
Enrutamiento a través de la red pública de Internet (red de ISP)
La nueva opción de enrutamiento denominada enrutamiento de Internet minimiza el viaje a través de la red
global de Microsoft y utiliza la red de ISP de tránsito para enrutar el tráfico. Esta opción de enrutamiento le
permite ahorrar costos y ofrece un rendimiento de red comparable a otros proveedores de la nube.

Tráfico de entrada: la ruta de acceso de entrada usa un enrutamiento de tipo "hot potato" , lo que significa que
el tráfico entra en la red de Microsoft más cercana a la región de servicio hospedada. Por ejemplo, si un usuario
de Singapur obtiene acceso a los recursos de Azure hospedados en Chicago, el tráfico viaja a través de la red
pública de Internet y entra en la red global de Microsoft en Chicago.
Tráfico de salida: el tráfico de salida sigue el mismo principio. El tráfico sale de la red de Microsoft en la misma
región en la que se hospeda el servicio. Por ejemplo, si el tráfico del servicio en Azure Chicago está destinado a un
usuario de Singapur, el tráfico sale de la red de Microsoft en Chicago y viaja a través de la red pública de Internet
hasta el usuario en Singapur.

Servicios admitidos
La dirección IP pública con la opción de preferencia de enrutamiento "red global de Microsoft" puede asociarse a
cualquier servicio de Azure. Sin embargo, la dirección IP pública con la opción de preferencia de enrutamiento
Internet puede asociarse a los siguientes recursos de Azure:
Máquina virtual
Conjunto de escalado de máquina virtual
Azure Kubernetes Service (AKS)
Equilibrador de carga accesible desde Internet
Application Gateway
Azure Firewall
En cuanto al almacenamiento, los puntos de conexión principales siempre usan la red global de Microsoft .
Puede habilitar los puntos de conexión secundarios que prefiera con Internet para realizar el enrutamiento del
tráfico. Los servicios de almacenamiento admitidos son:
Datos BLOB
Archivos
Web
Azure Data Lake

Precios
La diferencia de precio entre ambas opciones se refleja en los precios de transferencia de datos de salida de
Internet. El precio de transferencia de datos para el enrutamiento a través de la red global de Microsoft es el
mismo que el precio de salida actual de Internet. Consulte la página de precios de ancho de banda de Azure para
obtener la información más reciente sobre los precios. El enrutamiento a través de la red pública de Internet
tiene un precio inferior, tal como se muestra en la tabla siguiente:
 REGIÓ N DE
O RIGEN DE 5 GB -
SA L IDA 0- 5 GB / M ES 10 T B / M ES 10- 50 T B / M ES 50- 150 T B / M ES 150- 500 T B / M ES

Zona 1 0 USD/GB 0,085 USD/GB 0,065 USD/GB 0,06 USD/GB 0,04 USD/GB

Zona 2 0 USD/GB 0,11 USD/GB 0,075 USD/GB 0,07 USD/GB 0,06 USD/GB

Póngase en contacto con nosotros para obtener un volumen mensual superior a 500 TB.
Zona 1: Centro de Australia, Centro de Australia 2, Centro de Canadá, Este de Canadá, Norte de Europa,
Oeste de Europa, Centro de Francia, Sur de Francia, Norte de Alemania (público), Centro-oeste de Alemania
(público), Este de Noruega, Oeste de Noruega, Norte de Suiza, Oeste de Suiza, Sur de Reino Unido, Oeste
de Reino Unido, Centro de EE. UU.,Este de EE. UU., Este de EE. UU. 2, Centro y norte de EE. UU., Centro-sur
de EE. UU., Oeste de EE. UU., Oeste de EE. UU. 2 y Centro-oeste de EE. UU.
Zona 2: Este de Asia, Sudeste de Asia, Este de Australia, Sudeste de Australia, Centro de la India, Sur de la
India, India occidental, Este de Japón, Oeste de Japón, Centro de Corea del Sur y Sur de Corea del Sur.
Zona 3: Sur de Brasil, Norte de Sudáfrica, Oeste de Sudáfrica, Centro de Emiratos Árabes Unidos y Norte
de Emiratos Árabes Unidos.

Disponibilidad
La compatibilidad con preferencias de enrutamiento está disponible en las siguientes regiones para servicios
como la máquina virtual y el equilibrador de carga accesible desde Internet que usan una dirección IP pública
para la salida de Internet: Europa del Norte, Europa Occidental, Sur de Francia, Sur de Reino Unido, Este de
EE. UU., Centro-norte de EE. UU., Centro-sur de EE. UU., Oeste de EE. UU., Centro-oeste de EE. UU., Sudeste
Asiático, Centro-oeste de Alemania, Oeste de Suiza, Este de Japón y Oeste de Japón.
La compatibilidad con preferencias de enrutamiento para la cuenta de almacenamiento está disponible en las
siguientes regiones de Azure: Centro-norte de EE. UU., Centro-oeste de EE. UU., Centro-sur de EE. UU., Este de
EE. UU., Oeste de EE. UU., Norte de Europa, Sur de Francia, Centro-oeste de Alemania, Oeste de Suiza, Sudeste de
Asia,Japón Oriental y Japón Occidental.

Limitaciones
La preferencia de enrutamiento solo es compatible con la SKU estándar de la dirección IP pública. No se
admite la SKU básica de la dirección IP pública.
Actualmente, la preferencia de enrutamiento solo admite direcciones IP públicas IPv4. No se admiten
direcciones IP públicas IPv6.
Las máquinas virtuales que tengan varias NIC solo pueden tener un tipo de preferencia de enrutamiento.

Pasos siguientes
Configuración de la preferencia de enrutamiento de una VM mediante Azure PowerShell
Configuración de la preferencia de enrutamiento de una VM mediante la CLI de Azure
 Cómo filtran el tráfico de red los grupos de seguridad
de red
23/09/2020 • 11 minutes to read • Edit Online

Puede usar el grupo de seguridad de red de Azure para filtrar el tráfico de red hacia y desde los recursos de Azure
de una red virtual de Azure. Un grupo de seguridad de red contiene reglas de seguridad que permiten o deniegan
el tráfico de red entrante o el tráfico de red saliente de varios tipos de recursos de Azure. Para cada regla, puede
especificar un origen y destino, un puerto y un protocolo.
Puede implementar recursos de varios servicios de Azure en una red virtual de Azure. Para obtener una lista
completa, consulte Servicios que se pueden implementar en una red virtual. Puede asociar cero o un grupo de
seguridad de red a cada subred e interfaz de red de la red virtual en una máquina virtual. El mismo grupo de
seguridad de red se puede asociar a tantas interfaces de red y subredes como se desee.
La siguiente imagen ilustra los diferentes escenarios de cómo se podrían implementar grupos de seguridad de red
para permitir el tráfico de red hacia y desde Internet a través del puerto TCP 80:

Observe la imagen anterior, junto con el siguiente texto, para entender cómo procesa Azure las reglas entrantes y
salientes para los grupos de seguridad de red:

Tráfico entrante
Para el tráfico entrante, Azure procesa las reglas de un grupo de seguridad de red asociadas a una subred en
primer lugar, si hay alguna y, a continuación, las reglas de un grupo de seguridad de red asociadas a la interfaz de
red, si hay alguna.
VM1 : las reglas de seguridad de NSG1 se procesan, ya que está asociado a Subnet1 y VM1 está en Subnet1. A
menos que haya creado una regla que permita el puerto 80 de entrada, la regla de seguridad predeterminada
DenyAllInbound deniega el tráfico y NSG2 nunca lo evalúa, ya que NSG2 está asociado a la interfaz de red. Si
NSG1 tiene una regla de seguridad que permite el puerto 80, NSG2 procesa el tráfico. Para permitir el puerto 80
para la máquina virtual, tanto NSG1 como NSG2 deben tener una regla que permita el puerto 80 desde
Internet.
VM2 : las reglas de NSG1 se procesan porque VM2 también está en Subnet1. Puesto que VM2 no tiene un
grupo de seguridad de red asociado a su interfaz de red, recibe todo el tráfico permitido por NSG1 o se deniega
todo el tráfico denegado por NSG1. El tráfico se permite o deniega a todos los recursos de la misma subred
cuando un grupo de seguridad de red está asociado a una subred.
VM3 : dado que no hay ningún grupo de seguridad de red asociado a Subnet2, se permite el tráfico en la subred
 y NSG2 lo procesa, porque NSG2 está asociado a la interfaz de red conectada a VM3.
VM4 : se permite el tráfico a VM4, porque no hay un grupo de seguridad de red asociado a Subnet3 ni a la
interfaz de red de la máquina virtual. Si no tienen un grupo de seguridad de red asociado, se permite todo el
tráfico de red a través de una subred y una interfaz de red.

Tráfico saliente
Para el tráfico saliente, Azure procesa las reglas de un grupo de seguridad de red asociadas a una interfaz de red en
primer lugar, si hay alguna y, a continuación, las reglas de un grupo de seguridad de red asociadas a la subred, si
hay alguna.
VM1 : se procesan las reglas de seguridad de NSG2. A menos que cree una regla de seguridad que deniegue el
puerto 80 de salida a Internet, la regla de seguridad predeterminada AllowInternetOutbound permite el tráfico
de NSG1 y NSG2. Si NSG2 tiene una regla de seguridad que deniega el puerto 80, el tráfico se deniega y NSG1
nunca lo evalúa. Para denegar el puerto 80 desde la máquina virtual, uno o ambos de los grupos de seguridad
de red deben tener una regla que deniegue el puerto 80 a Internet.
VM2 : se envía todo el tráfico a través de la interfaz de red a la subred, ya que la interfaz de red conectada a VM2
no tiene un grupo de seguridad de red asociado. Se procesan las reglas de NSG1.
VM3 : si NSG2 tiene una regla de seguridad que deniega el puerto 80, también se deniega el tráfico. Si NSG2
tiene una regla de seguridad que permite el puerto 80, dicho puerto tiene permitida la salida a Internet, ya que
no hay un grupo de seguridad de red asociado a Subnet2.
VM4 : se permite todo el tráfico de red desde VM4, porque no hay un grupo de seguridad de red asociado a la
interfaz de red conectada a la máquina virtual ni a Subnet3.

Tráfico dentro de la subred

Es importante tener en cuenta que las reglas de seguridad de un NSG asociado a una subred pueden afectar la
conectividad entre las máquinas virtuales dentro de ella. Por ejemplo, si se agrega una regla a NSG1 que deniega
todo el tráfico entrante y saliente, VM1 y VM2 ya no podrán comunicarse entre sí. Otra regla tendría que agregarse
específicamente para permitirlo.
Puede ver fácilmente las reglas agregadas que se aplican a una interfaz de red mediante la visualización de las
reglas de seguridad vigentes de una interfaz de red. También puede usar la funcionalidad Comprobación del flujo
de IP de Azure Network Watcher para determinar si se permite la comunicación hacia una interfaz de red o desde
esta. El flujo IP le indica si se permite o deniega una comunicación y qué regla de seguridad de red permite o
deniega el tráfico.

NOTE
Los grupos de seguridad de red se asocian a las subredes o a las máquinas virtuales y a los servicios en la nube que se
implementan en el modelo de implementación clásica, y en las subredes o interfaces de red del modelo de implementación de
Resource Manager. Para más información sobre los modelos de implementación de Azure, consulte Descripción de los
modelos de implementación de Azure.

TIP
A menos que tenga un motivo concreto, se recomienda que asocie un grupo de seguridad de red a una subred o a una
interfaz de red, pero no a ambas. Puesto que las reglas de un grupo de seguridad de red asociado a una subred pueden
entrar en conflicto con las reglas de un grupo de seguridad de red asociado a una interfaz de red, puede tener problemas de
comunicación inesperados que necesiten solución.

Pasos siguientes
Para obtener información acerca de qué recursos de Azure se pueden implementar en una red virtual y pueden
tener grupos de seguridad de red asociados, consulte Integración de redes virtuales para los servicios de Azure.
Si nunca ha creado un grupo de seguridad de red, puede seguir un tutorial rápido para obtener alguna
experiencia en la creación de uno.
Si está familiarizado con los grupos de seguridad de red y necesita administrarlos, consulte Administración de
un grupo de seguridad de red.
Si tiene problemas con las comunicaciones y necesita solucionar problemas de los grupos de seguridad de red,
consulte Diagnóstico de un problema de filtro de tráfico de red de una máquina virtual.
Aprenda a habilitar los registros de flujo de los grupos de seguridad de red para analizar el tráfico de red hacia y
desde los recursos que tienen un grupo de seguridad de red asociado.
 Grupos de seguridad de aplicaciones
23/09/2020 • 7 minutes to read • Edit Online

Los grupos de seguridad de aplicaciones le permiten configurar la seguridad de red como una extensión natural de
la estructura de una aplicación, lo que le permite agrupar máquinas virtuales y directivas de seguridad de red
basadas en esos grupos. Puede reutilizar la directiva de seguridad a escala sin mantenimiento manual de
direcciones IP explícitas. La plataforma controla la complejidad de las direcciones IP explícitas y de varios conjuntos
de reglas, lo que le permite centrarse en su lógica de negocios. Para entender mejor los grupos de seguridad de
aplicaciones, considere el ejemplo siguiente:

En la imagen anterior, NIC1 y NIC2 son miembros del grupo de seguridad de aplicaciones AsgWeb. NIC3 es
miembro del grupo de seguridad de aplicaciones AsgLogic. NIC4 es miembro del grupo de seguridad de
aplicaciones AsgDb. Aunque cada interfaz de red de este ejemplo solo es miembro de un grupo de seguridad de
aplicaciones, una interfaz de red puede ser miembro de varios grupos de seguridad de aplicaciones, hasta los
límites de Azure. Ninguna de las interfaces de red tiene un grupo de seguridad de red asociado. NSG1 está
asociado a ambas subredes y contiene las siguientes reglas:

Allow-HTTP-Inbound-Internet
Esta regla es necesaria para permitir el tráfico de Internet a los servidores web. Dado que la regla de seguridad
predeterminada DenyAllInbound deniega el tráfico entrante desde Internet, no es necesaria ninguna regla
adicional para los grupos de seguridad de aplicaciones AsgLogic y AsgDb.

P UERTO S DE P UERTO S DE
P RIO RIT Y SO URC E O RIGEN DEST IN AT IO N DEST IN O P ROTO C O LO A C C ESO

100 Internet * AsgWeb 80 TCP Allow

Deny-Database-All
Dado que la regla de seguridad predeterminada AllowVNetInBound permite todas las comunicaciones entre los
recursos de la misma red virtual, se necesita esta regla para denegar el tráfico desde todos los recursos.
 P UERTO S DE P UERTO S DE
P RIO RIT Y SO URC E O RIGEN DEST IN AT IO N DEST IN O P ROTO C O LO A C C ESO

120 * * AsgDb 1433 Any Denegar

Allow-Database-BusinessLogic
Esta regla permite el tráfico desde el grupo de seguridad de aplicaciones AsgLogic al grupo de seguridad de
aplicaciones AsgDb. La prioridad de esta regla es mayor que la prioridad de la regla Deny-Database-All. Como
resultado, esta regla se procesa antes que la regla Deny-Database-All, por lo que se permite el tráfico del grupo de
seguridad de aplicaciones AsgLogic, mientras que el resto del tráfico es bloqueado.

P UERTO S DE P UERTO S DE
P RIO RIT Y SO URC E O RIGEN DEST IN AT IO N DEST IN O P ROTO C O LO A C C ESO

110 AsgLogic * AsgDb 1433 TCP Allow

Las reglas que especifican un grupo de seguridad de aplicaciones como origen o destino solo se aplican a las
interfaces de red que son miembros del grupo de seguridad de aplicaciones. Si la interfaz de red no es miembro de
un grupo de seguridad de aplicaciones, la regla no se aplica a la interfaz de red aunque el grupo de seguridad de
red esté asociado a la subred.
Los grupos de seguridad de aplicaciones presentan las siguientes restricciones:
Hay límites en el número de grupos de seguridad de aplicaciones que puede tener en una suscripción, así como
otros límites relacionados con los grupos de seguridad de aplicaciones. Para más información, consulte el
artículo acerca de los límites de Azure.
Puede especificar un grupo de seguridad de aplicaciones como origen y destino en una regla de seguridad. No
puede especificar varios grupos de seguridad de aplicaciones en el origen o el destino.
Todas las interfaces de red asignadas a un grupo de seguridad de aplicaciones deben existir en la misma red
virtual en la que se encuentra la primera interfaz de red asignada a dicho grupo. Por ejemplo, si la primera
interfaz de red asignada a un grupo de seguridad de aplicaciones llamado AsgWeb está en la red virtual llamada
VNet1, todas las sucesivas interfaces de red asignadas a ASGWeb deben existir en VNet1. No se pueden agregar
interfaces de red de distintas redes virtuales al mismo grupo de seguridad de aplicaciones.
Si especifica grupos de seguridad de aplicaciones como origen y destino de una regla de seguridad, las
interfaces de red de ambos grupos de seguridad de aplicaciones deben existir en la misma red virtual. Por
ejemplo, si AsgLogic contiene interfaces de red de VNet1 y AsgDb contiene interfaces de red de VNet2, no
puede asignar AsgLogic como origen y AsgDb como destino en una regla. Todas las interfaces de red para los
grupos de seguridad de aplicaciones de origen y de destino deben existir en la misma red virtual.

TIP
Para minimizar el número de reglas de seguridad que necesita y la necesidad de cambiar las reglas, planee los grupos de
seguridad de aplicaciones que necesita y cree reglas mediante etiquetas de servicio o grupos de seguridad de aplicaciones en
lugar de direcciones IP individuales o intervalos de direcciones IP siempre que sea posible.

Pasos siguientes
Aprenda a crear un grupo de seguridad de red.
 Etiquetas de servicio de red virtual
23/09/2020 • 19 minutes to read • Edit Online

Una etiqueta de servicio representa un grupo de prefijos de direcciones IP de un servicio de Azure determinado.
Microsoft administra los prefijos de direcciones que la etiqueta de servicio incluye y actualiza automáticamente
dicha etiqueta a medida que las direcciones cambian, lo que minimiza la complejidad de las actualizaciones
frecuentes en las reglas de seguridad de red.
Puede usar etiquetas de servicio para definir controles de acceso a la red en grupos de seguridad de red o
Azure Firewall. Utilice etiquetas de servicio en lugar de direcciones IP específicas al crear reglas de seguridad. Al
especificar el nombre de la etiqueta de servicio (por ejemplo, ApiManagement ) en el campo de
origen o destino apropiado de una regla, puede permitir o denegar el tráfico para el servicio correspondiente.
Puede usar etiquetas de servicio para lograr el aislamiento de red y proteger los recursos de Azure de Internet
general mientras accede a los servicios de Azure que tienen puntos de conexión públicos. Cree reglas de grupo de
seguridad de red de entrada y salida para denegar el tráfico hacia y desde Internet y permitir el tráfico desde y
hacia AzureCloud u otras etiquetas de servicio disponibles de servicios específicos de Azure.

Etiquetas de servicio disponibles

En la tabla siguiente se incluyen todas las etiquetas de servicio disponibles que se pueden usar en reglas de grupos
de seguridad de red.
Las columnas indican si la etiqueta:
Es adecuada para reglas que cubren el tráfico entrante o saliente.
Es compatible con el ámbito regional.
Se puede usar en las reglas de Azure Firewall.
De forma predeterminada, las etiquetas de servicio reflejan los intervalos de toda la nube. Algunas etiquetas de
servicio también permiten un control más preciso, ya que restringen los intervalos de direcciones IP
correspondientes a una región especificada. Por ejemplo, la etiqueta de servicio Storage representa a Azure
Storage para toda la nube, pero [Link] limita el rango solo a los intervalos de direcciones IP de
almacenamiento de la región Oeste de EE. UU. En la tabla siguiente se indica si cada etiqueta de servicio admite
este ámbito regional.

¿SE P UEDE USA R

PA RA T RÁ F IC O
EN T RA N T E O ¿P UEDE SER ¿SE P UEDE USA R C O N
ET IQ UETA P RO P Ó SITO SA L IEN T E? REGIO N A L? A Z URE F IREWA L L?

ActionGroup Grupo de acciones. Entrada No No

 ¿SE P UEDE USA R
PA RA T RÁ F IC O
EN T RA N T E O ¿P UEDE SER ¿SE P UEDE USA R C O N
ET IQ UETA P RO P Ó SITO SA L IEN T E? REGIO N A L? A Z URE F IREWA L L?

ApiManagement Tráfico de Entrada Sí Sí

administración para
implementaciones
dedicadas de Azure
API Management.

Nota: Esta etiqueta

representa el punto
de conexión de
servicio de API
Management de
Azure para el plano
de control por región.
Esto permite a los
clientes realizar
operaciones de
administración en las
API, operaciones,
directivas, valores con
nombre configurados
en el servicio de API
Management.

ApplicationInsights Disponibilidad de Entrada No No

Availability Application Insights.

AppConfiguration App Configuration. Salida No No

AppSer vice Azure App Service. Salida Sí Sí

Esta etiqueta se
recomienda para
reglas de seguridad
de salida a front-ends
de aplicaciones web.

AppSer viceManage Tráfico de Ambos No Sí

ment administración para
las implementaciones
dedicadas a App
Service Environment.

AzureActiveDirecto Azure Active Salida No Sí

ry Directory.

AzureActiveDirecto Tráfico de Ambos No Sí

r yDomainSer vices administración para
las implementaciones
dedicadas a Azure
Active Directory
Domain Services.

AzureAdvancedThr Azure Advanced Salida No No

eatProtection Threat Protection
 ¿SE P UEDE USA R
PA RA T RÁ F IC O
EN T RA N T E O ¿P UEDE SER ¿SE P UEDE USA R C O N
ET IQ UETA P RO P Ó SITO SA L IEN T E? REGIO N A L? A Z URE F IREWA L L?

AzureBackup Azure Backup. Salida No Sí

Nota: Esta etiqueta

tiene dependencia de
las etiquetas Storage
y
AzureActiveDirecto
r y.

AzureBotSer vice Azure Bot Service. Salida No No

AzureCloud Todos las direcciones Salida Sí Sí

IP públicas del centro
de recursos.

AzureCognitiveSea Azure Cognitive Entrada No No

rch Search.

Esta etiqueta o las

direcciones IP que
cubre esta etiqueta se
pueden usar para
conceder a los
indexadores un
acceso seguro a los
orígenes de datos.
Consulte la
documentación de
conexión de
indexación para
obtener más detalles.

Nota: La dirección IP
del servicio de
búsqueda no se
incluye en la lista de
intervalos IP para esta
etiqueta de servicio y
también se debe
agregar al firewall de
IP de los orígenes de
datos.

AzureConnectors Conectores de Azure Entrada Sí Sí

Logic Apps para las
conexiones de sondeo
y back-end.

AzureContainerReg Azure Container Salida Sí Sí

istr y Registry.

AzureCosmosDB Azure Cosmos DB. Salida Sí Sí

AzureDatabricks Azure Databricks. Ambos No No

 ¿SE P UEDE USA R
PA RA T RÁ F IC O
EN T RA N T E O ¿P UEDE SER ¿SE P UEDE USA R C O N
ET IQ UETA P RO P Ó SITO SA L IEN T E? REGIO N A L? A Z URE F IREWA L L?

AzureDataExplorer Administración de Entrada No No

Management Azure Data Explorer.

AzureDataLake Azure Data Lake Salida No Sí

Storage Gen1.

AzureDevSpaces Azure Dev Spaces. Salida No No

AzureEventGrid Azure Event Grid. Ambos No No

[Link] Azure Front Door. Ambos No No

ontend
[Link]
ckend
[Link]
stPar ty

AzureInformationP Azure Information Salida No No

rotection Protection.

Nota: Esta etiqueta

presenta dependencia
con las etiquetas
AzureActiveDirecto
r y,
[Link]
ontend y
[Link]
stPar ty .

AzureIoTHub Azure IoT Hub. Salida No No

AzureKeyVault Azure Key Vault. Salida Sí Sí

Nota: Esta etiqueta

tiene dependencia en
la etiqueta
AzureActiveDirecto
r y.

AzureLoadBalancer Equilibrador de carga Ambos No No

de la infraestructura
de Azure. La etiqueta
se traduce en la
dirección IP virtual del
host ([Link])
donde se originan los
sondeos de
mantenimiento de
Azure. Esto no incluye
el tráfico al recurso de
Azure Load Balancer.
Si no usa Azure Load
Balancer, puede
reemplazar esta regla.
 ¿SE P UEDE USA R
PA RA T RÁ F IC O
EN T RA N T E O ¿P UEDE SER ¿SE P UEDE USA R C O N
ET IQ UETA P RO P Ó SITO SA L IEN T E? REGIO N A L? A Z URE F IREWA L L?

AzureMachineLear Azure Machine Ambos No Sí

ning Learning.

AzureMonitor Log Analytics, Salida No Sí

Application Insights,
AzMon y métricas
personalizadas
(puntos de conexión
GiG).

Nota: Para Log

Analytics, esta
etiqueta tiene
dependencia en la
etiqueta Storage .

AzureOpenDataset Azure Open Datasets. Salida No No

s
Nota: Esta etiqueta
tiene dependencia de
las etiquetas
[Link]
ontend y Storage .

AzurePlatformDNS El servicio DNS de Salida No No

infraestructura básica
(predeterminado).

Puede usar esta

etiqueta para
deshabilitar el DNS
predeterminado.
Tenga cuidado al usar
esta etiqueta. Se
recomienda leer las
consideraciones sobre
la plataforma Azure.
También se
recomienda realizar
pruebas antes de usar
esta etiqueta.
 ¿SE P UEDE USA R
PA RA T RÁ F IC O
EN T RA N T E O ¿P UEDE SER ¿SE P UEDE USA R C O N
ET IQ UETA P RO P Ó SITO SA L IEN T E? REGIO N A L? A Z URE F IREWA L L?

AzurePlatformIMD Azure Instance Salida No No

S Metadata Service
(IMDS), que es un
servicio de
infraestructura básico.

Puede usar esta

etiqueta para
deshabilitar el IMDS
predeterminado.
Tenga cuidado al usar
esta etiqueta. Se
recomienda leer las
consideraciones sobre
la plataforma Azure.
También se
recomienda realizar
pruebas antes de usar
esta etiqueta.

AzurePlatformLKM Servicio de Salida No No

administración de
claves o licencias de
Windows.

Puede usar esta

etiqueta para
deshabilitar los
valores
predeterminados para
licencias. Tenga
cuidado al usar esta
etiqueta. Se
recomienda leer las
consideraciones sobre
la plataforma Azure.
También se
recomienda realizar
pruebas antes de usar
esta etiqueta.

AzureResourceMan Azure Resource Salida No No

ager Manager.

AzureSignalR Azure SignalR. Salida No No

AzureSiteRecover y Azure Site Recovery. Salida No No

Nota: Esta etiqueta

presenta dependencia
con las etiquetas
AzureActiveDirecto
r y , AzureKeyVault ,
EventHub ,
GuestAndHybridM
anagement y
Storage .
 ¿SE P UEDE USA R
PA RA T RÁ F IC O
EN T RA N T E O ¿P UEDE SER ¿SE P UEDE USA R C O N
ET IQ UETA P RO P Ó SITO SA L IEN T E? REGIO N A L? A Z URE F IREWA L L?

AzureTrafficManag Direcciones IP de Entrada No Sí

er sondeo de Azure
Traffic Manager.

En Preguntas más
frecuentes sobre
Azure Traffic Manager,
puede encontrar más
información acerca de
las direcciones IP de
sondeo de Traffic
Manager.

BatchNodeManage Tráfico de Ambos No Sí

ment administración para
implementaciones
dedicadas de Azure
Batch.

CognitiveSer vices Los intervalos de Ambos No No

Management direcciones para el
tráfico para Azure
Cognitive Services.

DataFactor y Azure Data Factory Ambos No No

DataFactor yManag Tráfico de Salida No No

ement administración para
Azure Data Factory.

Dynamics365ForM Los intervalos de Salida Sí No

arketingEmail direcciones del
servicio de correo
electrónico de
marketing de
Dynamics 365.

ElasticAFD Azure Front Door Ambos No No

elástico.

EventHub Azure Event Hubs. Salida Sí Sí

GatewayManager Tráfico de Entrada No No

administración para
implementaciones
dedicadas a Azure
VPN Gateway y
Application Gateway.

GuestAndHybridM Azure Automation y Salida No Sí

anagement Configuración de
invitado

HDInsight HDInsight de Azure. Entrada Sí No

 ¿SE P UEDE USA R
PA RA T RÁ F IC O
EN T RA N T E O ¿P UEDE SER ¿SE P UEDE USA R C O N
ET IQ UETA P RO P Ó SITO SA L IEN T E? REGIO N A L? A Z URE F IREWA L L?

Internet Espacio de direcciones Ambos No No

IP que se encuentra
fuera de la red virtual
y es accesible a través
de la red pública de
Internet.

El intervalo de
direcciones incluye el
espacio de direcciones
IP públicas propiedad
de Azure.

LogicApps Logic Apps. Ambos No No

LogicAppsManage Tráfico de Entrada No No

ment administración para
Logic Apps.

MicrosoftCloudApp Microsoft Cloud App Salida No No

Security Security.

MicrosoftContainer Registro de Salida Sí Sí

Registr y contenedor para
imágenes de
contenedor de
Microsoft.

Nota: Esta etiqueta

presenta dependencia
con la etiqueta
[Link]
stPar ty .

PowerQuer yOnline Power Query Online. Ambos No No

Ser vice Bus Tráfico de Azure Salida Sí Sí

Service Bus que usa el
nivel de servicio
Premium.
 ¿SE P UEDE USA R
PA RA T RÁ F IC O
EN T RA N T E O ¿P UEDE SER ¿SE P UEDE USA R C O N
ET IQ UETA P RO P Ó SITO SA L IEN T E? REGIO N A L? A Z URE F IREWA L L?

Ser viceFabric Azure Service Fabric. Ambos No No

Nota: Esta etiqueta

representa el punto
de conexión de
servicio de Service
Fabric para el plano
de control por región.
Esto permite a los
clientes realizar
operaciones de
administración para
sus clústeres de
Service Fabric desde la
red virtual (punto de
conexión, p. ej.
https://
[Link]
[Link])

Sql Azure SQL Database, Salida Sí Sí

Azure Database for
MySQL, Azure
Database for
PostgreSQL y Azure
SQL Data Warehouse.

Nota: Esta etiqueta

representa el servicio,
no instancias
específicas del mismo.
Por ejemplo, la
etiqueta representa el
servicio Azure SQL
Database, pero no
una cuenta de un
servidor o base de
datos SQL específicos.
Esta etiqueta no se
aplica a SQL Managed
Instance.

SqlManagement Tráfico de Ambos No Sí

administración para
implementaciones
dedicadas de SQL.
 ¿SE P UEDE USA R
PA RA T RÁ F IC O
EN T RA N T E O ¿P UEDE SER ¿SE P UEDE USA R C O N
ET IQ UETA P RO P Ó SITO SA L IEN T E? REGIO N A L? A Z URE F IREWA L L?

Storage Azure Storage. Salida Sí Sí

Nota: Esta etiqueta

representa el servicio,
no instancias
específicas del mismo.
Por ejemplo, la
etiqueta representa el
servicio Azure
Storage, pero no una
cuenta de específica
de este.

StorageSyncSer vice Servicio de Ambos No No

sincronización de
almacenamiento.

WindowsVir tualDes Windows Virtual Ambos No Sí

ktop Desktop.

Vir tualNetwork El espacio de Ambos No No

direcciones de red
virtual (todos los
intervalos de
direcciones IP
definidos para la red
virtual), todos los
espacios de
direcciones locales
conectados, las redes
virtuales del mismo
nivel, las redes
virtuales conectadas a
una puerta de enlace
de red virtual, la
dirección IP virtual del
host y los prefijos de
dirección usados en
las rutas definidas por
el usuario. Esta
etiqueta también
puede contener rutas
predeterminadas.
 NOTE
En el modelo de implementación clásico (antes de Azure Resource Manager), se admite un subconjunto de las etiquetas
enumeradas en la tabla anterior. Estas etiquetas se escriben de forma diferente:

O R TO G R A F Í A C L Á S I C A E T I Q U E TA D E R E S O U R C E M A N A G E R E Q U I VA L E N T E

AZURE_LOADBALANCER AzureLoadBalancer

INTERNET Internet

VIRTUAL_NETWORK VirtualNetwork

NOTE
Las etiquetas de servicios de los servicios de Azure indican los prefijos de dirección de la nube específica que se va a usar. Por
ejemplo, los intervalos de direcciones IP subyacentes que se corresponden con el valor de la etiqueta de Sql en la nube
pública de Azure serán distintos de los intervalos subyacentes en la nube de Azure China.

NOTE
Si implementa un punto de conexión de servicio de red virtual para un servicio, como Azure Storage o Azure SQL Database,
Azure agrega una ruta a una subred de red virtual para el servicio. Los prefijos de dirección de la ruta son los mismos prefijos
de dirección, o intervalos CIDR, que los de la etiqueta de servicio correspondiente.

Etiquetas de servicio en un entorno local

Puede obtener información de intervalo y la etiqueta de servicio actual para incluirla como parte de las
configuraciones del firewall local. Esta información es la lista actual en un momento dado de los intervalos de
direcciones IP que corresponden a cada etiqueta de servicio. Puede obtener la información mediante programación
o a través de la descarga de un archivo JSON, tal y como se describe en las secciones siguientes.
Uso de Service Tag Discovery API (versión preliminar pública)
Puede recuperar mediante programación la lista actual de etiquetas de servicio, junto con los detalles del intervalo
de direcciones IP:
REST
Azure PowerShell
CLI de Azure

NOTE
Si bien se encuentra en versión preliminar pública, Discovery API podría devolver información menos actual que la
información devuelta por las descargas de JSON. (Consulte la sección siguiente).

Detección de etiquetas de servicio mediante archivos JSON descargables

Puede descargar archivos JSON que contengan la lista actual de etiquetas de servicio, junto con los detalles del
intervalo de direcciones IP. Estas listas se actualizan y publican semanalmente. Las ubicaciones de cada nube son:
Azure público
Azure US Government
 Azure en China
Azure Alemania
Los intervalos de direcciones IP de estos archivos están en notación CIDR.

NOTE
Un subconjunto de esta información se ha publicado en archivos XML para Azure público, Azure China y Azure Alemania.
Estas descargas XML dejarán de usarse en el 30 de junio de 2020 y ya no estarán disponibles después de esa fecha. Debería
migrar mediante Discovery API o las descargas de archivos JSON como se describió en las secciones anteriores.

Sugerencias
Puede detectar actualizaciones de una publicación a la siguiente si observa los valores changeNumber en
aumento en el archivo JSON. Cada subsección (por ejemplo, [Link] ) tiene su propio changeNumber
que se incrementa a medida que se producen cambios. El nivel superior de changeNumber del archivo aumenta
cuando alguna de las subsecciones ha cambiado.
Para ver ejemplos de cómo analizar la información de la etiqueta de servicio (por ejemplo, obtener todos los
intervalos de direcciones para Storage en Oeste de EE. UU.), consulte la documentación de PowerShell de
Service Tag Discovery API.

Pasos siguientes
Aprenda a crear un grupo de seguridad de red.
 Directivas de punto de conexión de servicio de red virtual
para Azure Storage
23/09/2020 • 15 minutes to read • Edit Online

Las directivas de punto de conexión de servicio de red virtual (VNet) permiten filtrar el tráfico de red virtual de salida a
cuentas de Azure Storage a través de un punto de conexión de servicio y habilitan la filtración de datos únicamente a cuentas
específicas de Azure Storage. Las directivas de punto de conexión ofrecen un control de acceso pormenorizado para el tráfico
de red virtual a Azure Storage al conectarse a través de un punto de conexión de servicio.

Esta característica está disponible con carácter general para Azure Storage en todas las regiones del mundo de Azure .

Ventajas principales
Las directivas de puntos de conexión de servicio de red virtual proporcionan las ventajas siguientes:
Seguridad mejorada para el tráfico de red vir tual a Azure Storage
Las etiquetas de servicio de Azure para grupos de seguridad de red permiten restringir el tráfico de salida de red
virtual a regiones concretas de Azure Storage. Pero esto permite el tráfico a cualquier cuenta dentro de la región de
Azure Storage seleccionada.
Las directivas de punto de conexión permiten especificar las cuentas de Azure Storage a las que se permite el acceso
de salida de red virtual y restringir el acceso a todas las demás cuentas de almacenamiento. Esto proporciona un
control de seguridad mucho más pormenorizado para proteger el filtrado de datos de la red virtual.
Directivas escalables y altamente disponibles para filtrar el tráfico del ser vicio de Azure
Las directivas de punto de conexión proporcionan una solución horizontal escalable y de alta disponibilidad para
filtrar el tráfico de servicio de Azure desde las redes virtuales, a través de los puntos de extremo de servicio. No se
requiere ninguna sobrecarga adicional para mantener los dispositivos de red central para este tráfico en las redes
virtuales.

Objeto JSON para directivas de punto de conexión de servicio

Vamos a echar un vistazo rápido al objeto de directiva de punto de conexión de servicio.
 "serviceEndpointPolicyDefinitions": [
{
"description": null,
"name": "MySEP-Definition",
"resourceGroup": "MySEPDeployment",
"service": "[Link]",
"serviceResources": [

"/subscriptions/subscriptionID/resourceGroups/MySEPDeployment/providers/[Link]/storageAccounts/mystgacc"
],
"type": "[Link]/serviceEndpointPolicies/serviceEndpointPolicyDefinitions"
}
]

Configuración
Puede configurar las directivas de punto de conexión de modo que se restrinja el tráfico de red virtual a cuentas
específicas de Azure Storage.
La directiva de puntos de conexión se configura en una subred de una red virtual. Los puntos de conexión de servicio
de Azure Storage deben estar habilitados en la subred para aplicar la directiva.
La directiva de punto de conexión permite agregar cuentas concretas de Azure Storage a una lista de permitidos
mediante el formato resourceID. Puede restringir el acceso a
todas las cuentas de almacenamiento de una suscripción
E.g. /subscriptions/subscriptionId

todas las cuentas de almacenamiento de un grupo de recursos

E.g. subscriptions/subscriptionId/resourceGroups/resourceGroupName

una cuenta de almacenamiento individual al indicar el resourceId correspondiente de Azure Resource Manager.
Esto trata el tráfico a blobs, tablas, colas, archivos y a Azure Data Lake Storage Gen2.
E.g.
/subscriptions/subscriptionId/resourceGroups/resourceGroupName/providers/[Link]/storageAccounts/storageAccountName

De forma predeterminada, si no hay directivas asociadas a una subred con puntos de conexión, puede acceder a todas
las cuentas de almacenamiento del servicio. Una vez configurada una directiva en esa subred, solo se puede acceder a
los recursos especificados en la directiva desde las instancias de proceso de esa subred. Se deniega el acceso a todas
las demás cuentas de almacenamiento.
Al aplicar directivas de punto de conexión de servicio en una subred, el ámbito del punto de conexión de servicio de
Azure Storage se actualiza de regional a global . Esto significa que todo el tráfico a Azure Storage se protege a través
del punto de conexión de servicio a partir de entonces. Las directivas de punto de conexión de servicio también se
pueden aplicar globalmente, por lo que se deniega el acceso a cualquier cuenta de almacenamiento que no se haya
permitido de forma explícita.
Puede aplicar varias directivas a una subred. Cuando hay varias directivas asociadas a la subred, se permite el tráfico
de red virtual a los recursos especificados en cualquiera de estas directivas. Se denegará el acceso a todos los demás
recursos del servicio, que no se estén especificados en ninguna de las directivas.

NOTE
Las directivas de punto de conexión de servicio son directivas de permiso , por lo que, aparte de los recursos especificados, se
restringen todos los demás recursos. Asegúrese de que todas las dependencias de recursos de servicio de las aplicaciones estén
identificadas e indicadas en la directiva.

Solo las cuentas de almacenamiento que utilizan el modelo de recursos de Azure pueden especificarse en la directiva
de punto de conexión. Las cuentas de Azure Storage clásicas no son compatibles con las directivas de punto de
conexión de servicio de Azure.
El acceso secundario a RA-GRS se permitirá automáticamente si la cuenta principal aparece en la lista.
 Las cuentas de almacenamiento pueden estar en la misma suscripción o en una diferente o en un inquilino de Azure
Active Directory que la red virtual.

Escenarios
Redes vir tuales emparejadas, conectadas o múltiples : para filtrar el tráfico en redes virtuales emparejadas, las
directivas de punto de conexión deben aplicarse individualmente a estas redes virtuales.
Filtrado del tráfico de Internet con dispositivos de red o Azure Firewall : filtre el tráfico del servicio Azure con
directivas, mediante puntos de conexión, y filtre el resto del tráfico de Internet o Azure a través de dispositivos o de Azure
Firewall.
Filtrado del tráfico en ser vicios de Azure implementados en redes vir tuales : en este momento, las directivas de
punto de conexión de servicio de Azure no son compatibles con ningún servicio administrado de Azure implementado en
la red virtual.
Filtrado del tráfico a los ser vicios de Azure desde el entorno local : las directivas de punto de conexión de
servicio solo se aplican al tráfico de las subredes asociadas a las directivas. Para permitir el acceso a recursos de servicio
específicos de Azure desde el entorno local, el tráfico debe filtrarse utilizando aplicaciones de redes virtuales o firewalls.

Registro y solución de problemas

No se dispone de un registro centralizado para las directivas de punto de conexión de servicio. Para los registros de recursos
de servicio, consulte Registro de puntos de conexión de servicio.
Escenarios de solución de problemas
Acceso denegado a las cuentas de almacenamiento que funcionaban en la versión preliminar (no en región emparejada
geográficamente)
Al actualizar Azure Storage para usar etiquetas de servicio globales, el ámbito del punto de conexión de servicio y,
por tanto, las directivas de punto de conexión de servicio, ahora es Global. Por lo tanto, todo el tráfico a Azure
Storage se cifra mediante puntos de conexión de servicio y solo se permite el acceso a las cuentas de
almacenamiento que aparecen explícitamente en la directiva.
Permita de forma explícita en la lista todas las cuentas de almacenamiento necesarias para restaurar el acceso.
Póngase en contacto con el equipo de soporte técnico de Azure.
Se niega el acceso a las cuentas enumeradas en las directivas de punto de conexión.
Los grupos de seguridad de red o el filtrado de firewall podrían estar bloqueando el acceso.
Si al quitar o volver a aplicar la directiva se produce una pérdida de conectividad:
Valide si el servicio Azure está configurado para permitir el acceso desde la red virtual a través de puntos de
conexión, o que la directiva predeterminada del recurso esté establecida en Permitir todo.
Valide que los diagnósticos de servicio muestran el tráfico sobre los puntos de conexión.
Compruebe si los registros de flujo de grupo de seguridad de red muestran el acceso y que los registros de
almacenamiento muestran el acceso, como se esperaba, a los puntos de conexión de servicio.
Póngase en contacto con el equipo de soporte técnico de Azure.
Se niega el acceso a las cuentas no enumeradas en las directivas de punto de conexión.
Valide si Azure Storage está configurado para permitir el acceso desde la red virtual a través de puntos de
conexión, o si la directiva predeterminada del recurso está establecida en Permitir todo.
Asegúrese de que las cuentas no sean cuentas de almacenamiento clásicas con directivas de punto de
conexión de servicio en la subred.
Un servicio de Azure administrado ha dejado de funcionar después de aplicar una directiva de punto de conexión de
servicio a través de la subred
Los servicios administrados no son compatibles con las directivas de punto de conexión de servicio de momento.
No pierda de vista este espacio para ver si hay actualizaciones.

Aprovisionamiento
Las directivas de punto de conexión de servicio pueden configurarse en subredes por un usuario con acceso de escritura a
una red virtual. Obtenga más información sobre los roles integrados de Azure y la asignación de permisos específicos a roles
personalizados.
Las redes virtuales y las cuentas de Azure Storage pueden encontrarse en la misma o en diferentes suscripciones, o en
inquilinos de Azure Active Directory.

Limitaciones
Solo puede implementar las directivas de punto de conexión de servicio en las redes virtuales implementadas con el
modelo de implementación de Azure Resource Manager.
Las redes virtuales deben estar en la misma región que la directiva de punto de conexión de servicio.
Solo puede aplicar la directiva de punto de conexión de servicio en una subred si los puntos de conexión de servicio están
configurados para los servicios de Azure enumerados en la directiva.
No puede utilizar las directivas de punto de conexión de servicio para el tráfico de la red local a los servicios de Azure.
Los servicios administrados de Azure no admiten actualmente directivas de punto de conexión. Esto incluye los servicios
administrados implementados en las subredes compartidas (por ejemplo, Azure HDInsight, Azure Batch, Azure AD DS,
Azure Application Gateway, Azure VPN Gateway y Azure Firewall) o en las subredes dedicadas (por ejemplo, Azure App
Service Environment, Azure Redis Cache, Azure API Management, Instancia administrada de Azure SQL y servicios
administrados clásicos).

WARNING
Los servicios de Azure implementados en la red virtual, como Azure HDInsight, acceden a otros servicios de Azure, como Azure Storage,
para saber los requisitos de infraestructura. Restringir la directiva de punto de conexión a recursos específicos podría interrumpir el
acceso a estos recursos de infraestructura para los servicios de Azure implementados en la red virtual.

no se admiten las cuentas de almacenamiento clásicas en las directivas de punto de conexión. Las directivas denegarán el
acceso a todas las cuentas de almacenamiento clásicas de forma predeterminada. Si su aplicación necesita acceso a Azure
Resource Manager y a las cuentas de almacenamiento clásicas, las directivas de punto de conexión no deben usarse para
este tráfico.

Precios y límites
No hay ningún cargo adicional para el uso de directivas de punto de conexión de servicio. El modelo de precios vigente para
los servicios de Azure (como Azure Storage) se aplica tal cual, sobre los punto de conexión de servicio.
Los límites siguientes se aplican en las directivas de punto de conexión de servicio:

RESO URC E L ÍM IT E P REDET ERM IN A DO

ServiceEndpointPoliciesPerSubscription 500

ServiceEndpointPoliciesPerSubnet 100

ServiceResourcesPerServiceEndpointPolicyDefinition 200

Pasos siguientes
Aprenda a configurar las directivas de puntos de conexión de servicio de red virtual.
Aprenda más sobre los puntos de conexión de servicio de red virtual.
 Introducción a las directivas de red de Azure
Kubernetes
23/09/2020 • 5 minutes to read • Edit Online

Las directivas de red proporcionan microsegmentación para pods del mismo modo que los grupos de seguridad de
red (NSG) proporcionan microsegmentación para máquinas virtuales. La implementación de la directiva de red de
Azure admite la especificación de directiva de red de Kubernetes estándar. Puede usar etiquetas para seleccionar un
grupo de pods y definir una lista de reglas de entrada y salida que especifican el tipo de tráfico que se permite
hacia y desde los pods. Obtenga más información sobre las directivas de red de Kubernetes en la documentación
de Kubernetes.

Las directivas de red de Azure funcionan conjuntamente con CNI de Azure, que proporciona integración con red
virtual para los contenedores. Actualmente solo se admiten nodos de Linux. Las implementaciones configuran las
reglas de la tabla de IP de Linux según las directivas definidas para aplicar el filtrado de tráfico.

Planeación de seguridad para el clúster de Kubernetes

Al implementar la seguridad para el clúster, utilice grupos de seguridad red (NSG) para filtrar el tráfico de norte a
sur, es decir, el que entra y sale de la subred del clúster, y use las directivas de red de Kubernetes para el tráfico de
este a oeste, es decir, el tráfico entre pods del clúster.

Uso de las directivas de red de Azure Kubernetes

Las directivas de red de Azure pueden usarse de las siguientes formas para proporcionar microsegmentación para
los pods.
Motor de ACS
Motor de ACS es una herramienta que genera una plantilla de Azure Resource Manager para la implementación de
un clúster de Kubernetes en Azure. La configuración del clúster se especifica en un archivo JSON que se pasa a la
herramienta al generar la plantilla. Para ver la lista completa de las configuraciones de clúster compatibles y sus
descripciones, consulte Microsoft Azure Container Service Engine - Cluster Definition (Motor de Microsoft Azure
Container Service: definición de clúster).
Para habilitar las directivas en clústeres implementados con motor de ACS, especifique el valor de la configuración
de networkPolicy en el archivo de definición del clúster como "azure".
Ejemplo de configuración
En la siguiente configuración de ejemplo JSON se crea una nueva red virtual y una subred e se implementa un
clúster de Kubernetes en ella con CNI de Azure. Se recomienda que utilice "Notepad" para editar el archivo JSON.

{
"apiVersion": "vlabs",
"properties": {
"orchestratorProfile": {
"orchestratorType": "Kubernetes",
"kubernetesConfig": {
"networkPolicy": "azure"
}
},
"masterProfile": {
"count": 1,
"dnsPrefix": "<specify a cluster name>",
"vmSize": "Standard_D2s_v3"
},
"agentPoolProfiles": [
{
"name": "agentpool",
"count": 2,
"vmSize": "Standard_D2s_v3",
"availabilityProfile": "AvailabilitySet"
}
],
"linuxProfile": {
"adminUsername": "<specify admin username>",
"ssh": {
"publicKeys": [
{
"keyData": "<cut and paste your ssh key here>"
}
]
}
},
"servicePrincipalProfile": {
"clientId": "<enter the client ID of your service principal here >",
"secret": "<enter the password of your service principal here>"
}
}
}

Creación de su propio clúster de Kubernetes en Azure

La implementación puede utilizarse para proporcionar directivas de red para los pods en clústeres de Kubernetes
que implemente usted mismo, sin necesidad de usar herramientas como el motor de ACS. En este caso, en primer
lugar debe instalar el complemento de CNI y habilitarlo en todas las máquinas virtuales de un clúster. Para
instrucciones detalladas, consulte Implementación del complemento para un clúster de Kubernetes que usted
mismo haya implementado.
Una vez implementado el clúster, ejecute el siguiente comando kubectl para descargar y aplicar la directiva de red
de Azure daemonset en el clúster.

kubectl apply -f [Link]

engine/master/parts/k8s/addons/[Link]
La solución también es de código abierto y el código está disponible en el repositorio de redes de Azure Container.

Pasos siguientes
Obtenga más información acerca de Azure Kubernetes Service.
Obtenga más información acerca de redes de contenedores.
Implemente el complemento para clústeres de Kubernetes o contenedores de Docker.
 Introducción a Protección contra DDoS de Azure
estándar
23/09/2020 • 13 minutes to read • Edit Online

Los ataques por denegación de servicio distribuido (DDoS) son uno de los problemas de seguridad y
disponibilidad más extendidos a los que se enfrentan los clientes que mueven sus aplicaciones a la nube. Un
ataque DDoS intenta agotar los recursos de una aplicación haciendo que esta no esté disponible para los usuarios
legítimos. Los ataques DDoS pueden ir dirigidos a cualquier punto de conexión que sea públicamente accesible a
través de Internet.
Azure DDoS Protection, junto con los procedimientos recomendados de diseño de aplicaciones, constituyen una
defensa frente a los ataques DDoS. La protección contra DDoS de Azure proporciona los siguientes niveles de
servicio:
Básico : habilitado de forma automática como parte de la plataforma de Azure. La supervisión continua del
tráfico y la reducción en tiempo real de los ataques a nivel de red más comunes ofrecen la misma defensa que
usan los servicios en línea de Microsoft. Puede usarse la escala completa de una red global de Azure para
distribuir y reducir el tráfico de ataques en las distintas regiones. Se proporciona protección para direcciones IP
públicas de Azure IPv4 e IPv6.
Estándar : ofrece funciones adicionales de reducción de ataques en comparación con el nivel de servicio básico,
adaptadas específicamente a los recursos de Azure Virtual Network. El servicio Protección contra DDoS
estándar es fácil de habilitar y no requiere ningún cambio en la aplicación. Las directivas de protección se
ajustan a través de la supervisión del tráfico dedicado y los algoritmos de Machine Learning. Las directivas se
aplican a direcciones IP públicas asociadas a recursos implementados en redes virtuales, como instancias de
Azure Load Balancer, Azure Application Gateway y Azure Service Fabric, pero esta protección no se aplica a las
instancias de App Service Environment. La telemetría en tiempo real está disponible a través de las vistas de
Azure Monitor durante un ataque y para el historial. En la configuración de diagnóstico, hay disponibles análisis
avanzados de mitigación de ataques. La protección del nivel de aplicación se puede agregar mediante el firewall
de aplicaciones web de Azure Application Gateway Web o instalando un firewall de terceros desde Azure
Marketplace. Se proporciona protección para direcciones IP públicas de Azure IPv4 e IPv6.

C A RA C T ERÍST IC A DDO S P ROT EC T IO N B A SIC DDO S P ROT EC T IO N STA N DA RD

Supervisión de tráfico activo y detección Sí Sí

siempre activada

Mitigaciones de ataques automáticas Sí Sí

Garantía de disponibilidad Región de Azure Application

Directivas de mitigación Optimizado para el volumen de región Optimizado para el volumen de tráfico
de tráfico de Azure de la aplicación

Métricas y alertas No Métricas de ataques y registros de

recursos en tiempo real a través de
Azure Monitor

Informes de mitigación No Informes sobre mitigación posteriores al

ataque
 C A RA C T ERÍST IC A DDO S P ROT EC T IO N B A SIC DDO S P ROT EC T IO N STA N DA RD

Registros de flujo de mitigación No Secuencia de registro NRT para la

integración de SIEM

Personalización de la directiva de No Interacción con expertos en DDos

mitigación

Soporte técnico Mejor opción Acceso a expertos en DDos durante un

ataque activo

Contrato de nivel de servicio Región de Azure Garantía de aplicación y protección de

costos

Precios Gratuito Mensual y basado en el uso

Tipos de ataques DDoS que mitiga Protección contra DDoS estándar

El servicio Protección contra DDoS estándar puede mitigar los tipos de ataque siguientes:
Ataques volumétricos : estos ataques desbordan la capa de la red con una gran cantidad de tráfico
aparentemente legítimo. Incluyen ataques de tipo "flood" de UDP, de amplificación y otros ataques de tipo
"flood" de paquetes falsificados. DDoS Protection Standard mitiga estos posibles ataques de varios gigabytes,
ya que los absorbe y los limpia automáticamente aprovechando la escala de red global de Azure.
Ataques a protocolos : estos ataques representan un destino inaccesible al aprovechar una vulnerabilidad en
la pila de protocolo en los niveles 3 y 4. Incluyen ataques de tipo "flood" de congestión del servidor de SYN,
ataques de reflejo y otros ataques de protocolo. El servicio Protección contra DDoS estándar mitiga estos
ataques al diferenciar entre el tráfico malintencionado y el legítimo. Para ello, interactúa con el cliente y bloquea
el tráfico malintencionado.
Ataques de nivel de recurso (aplicación) : estos ataques van dirigidos a paquetes de aplicaciones web y su
objetivo es interrumpir la transmisión de datos entre hosts. Incluyen las infracciones de protocolo HTTP,
inyección de código SQL, scripts de sitios y otros ataques de nivel 7. Use un firewall de aplicaciones web, por
ejemplo el firewall de aplicaciones web de Azure Application Gateway, así como DDoS Protection Standard, para
la defensa frente a estos ataques. También existen ofertas de firewall de aplicaciones web de terceros
disponibles en Azure Marketplace.
Protección contra DDoS estándar protege los recursos de las redes virtuales, incluidas las direcciones IP públicas
asociadas a máquinas virtuales, los equilibradores de carga y las puertas de enlace de aplicaciones. Cuando se
combina con el firewall de aplicaciones web de Application Gateway o un firewall de aplicaciones web de terceros
implementado en una red virtual con una dirección IP pública, DDoS Protection Standard puede proporcionar una
capacidad de mitigación completa de capa 3 a capa 7.

Características de Protección contra DDoS estándar

Entre las características de Protección contra DDoS estándar se incluyen:

 Integración de plataforma nativa: integrado de forma nativa en Azure. Incluye la configuración a través de
Azure Portal. Protección contra DDoS estándar comprende sus recursos y la configuración de recursos.
Protección llave en mano: la configuración simplificada protege de inmediato todos los recursos de una red
virtual desde el momento en que se habilita DDoS Protection Estándar. No se requiere intervención ni
definición del usuario. Protección contra DDoS estándar mitiga el ataque de forma instantánea y automática
una vez detectado.
Super visión continua del tráfico: los patrones de tráfico de la aplicación se supervisan de forma
ininterrumpida en busca de indicadores de ataques DDoS. La mitigación se realiza cuando se sobrepasan las
directivas de protección.
Ajuste adaptable: la generación de perfiles de tráfico inteligente va conociendo con el tiempo el tráfico de la
aplicación y selecciona y actualiza el perfil que resulta más adecuado para el servicio. El perfil se ajusta a
medida que el tráfico cambia con el tiempo.
Protección multicapa: proporciona protección contra DDoS de pila completa cuando se usa con un firewall
de aplicaciones web.
Escala de mitigación amplia: se pueden mitigar más de 60 tipos de ataque diferentes con capacidad global
para protegerse contra los ataques DDoS más conocidos.
Análisis de ataques: ofrece informes detallados en incrementos de cinco minutos durante un ataque y un
resumen completo después de que el ataque termine. Transmita los registros del flujo de mitigación a un
sistema de administración de eventos e información de seguridad (SIEM) sin conexión para supervisar el
sistema casi en tiempo real durante un ataque.
Métricas de ataques: con Azure Monitor se puede acceder a un resumen de métricas de cada ataque.
Aler tas de ataques: las alertas se pueden configurar en el inicio y la detención de un ataque y a lo largo de la
duración del ataque mediante métricas de ataque integradas. Las alertas se integran en el software operativo,
como los registros de Microsoft Azure Monitor, Splunk, Azure Storage, el correo electrónico y Azure Portal.
Garantía de costo: créditos para servicio de escalado horizontal de aplicaciones y transferencia de datos para
ataques de DDoS documentados.

Mitigación mediante Protección contra DDoS estándar

El servicio Protección contra DDoS estándar supervisa el uso de tráfico real y lo compara constantemente con los
umbrales definidos en la directiva de DDoS. Cuando se supera el umbral de tráfico, se inicia automáticamente la
mitigación de DDoS. Cuando el tráfico vuelve a estar por debajo del umbral, se quita la mitigación.

Durante la mitigación, el servicio Protección contra DDoS redirige el tráfico enviado al recurso protegido y realiza
varias comprobaciones, como las que se indican a continuación:
Asegurarse de que los paquetes se ajustan a las especificaciones de Internet y no tienen un formato incorrecto.
Interactúe con el cliente para determinar si el tráfico es un posible paquete falsificado (por ejemplo,
Autorización de SYN o Cookie de SYN o colocando un paquete para que el origen lo retransmita).
Limitar la velocidad de los paquetes si no se puede realizar ningún otro método de cumplimiento.
El servicio Protección contra DDoS bloquea el tráfico del ataque y reenvía el tráfico restante al destino previsto. En
un intervalo de pocos minutos tras la detección del ataque, recibe una notificación mediante las métricas de Azure
Monitor. Si configura el registro de datos de telemetría de Protección contra DDoS estándar, puede escribir los
registros en opciones disponibles para su posterior análisis. Los datos métricos de Azure Monitor para Protección
contra DDoS estándar se conservan actualmente durante 30 días.
Microsoft se ha asociado con BreakingPoint Cloud para crear una interfaz en la que pueda generar tráfico
destinado a las direcciones IP públicas que tengan habilitado el servicio DDoS Protection con fines de simulación.
La simulación de BreakPoint Cloud le permite:
Comprobar en qué medida Microsoft Azure DDoS Protection estándar protege sus recursos de Azure frente a
ataques de DDoS
Optimizar el proceso de respuesta a incidentes durante el ataque de DDoS.
Documentar el cumplimiento normativo de DDoS.
Enseñar a los equipos de seguridad de red.

Pasos siguientes
Configuración del servicio Protección contra DDoS estándar
 TAP de red virtual
23/09/2020 • 5 minutes to read • Edit Online

IMPORTANT
La versión preliminar de TAP de red virtual actualmente está en espera en todas las regiones de Azure. Puede enviarnos un
correo electrónico a azurevnettap@[Link] con su identificador de suscripción y le notificaremos las actualizaciones
futuras sobre la versión preliminar. Mientras tanto, puede usar soluciones basadas en agentes o NVA que proporcionen
funcionalidad de visibilidad de red o TAP a través de las soluciones de partners de agentes de paquetes disponibles en las
ofertas de Azure Marketplace.

Azure Virtual Network TAP (punto de acceso del terminal) permite transmitir continuamente el tráfico de red de la
máquina virtual a un recopilador de paquetes de red o a una herramienta de análisis. Un asociado de la aplicación
virtual de red proporciona el recopilador o la herramienta de análisis de la herramienta. Para ver una lista de
soluciones de asociados que estén validadas para funcionar con Virtual Network TAP, consulte las soluciones de
asociados. En la siguiente imagen se muestra cómo funciona Virtual Network TAP. Puede agregar una configuración
de TAP en una interfaz de red adjunta a una máquina virtual implementada en la red virtual. El destino es una
dirección IP de red virtual en la misma red virtual que la interfaz de red supervisada o una red virtual emparejada.
La solución del recopilador para el punto de acceso de terminal de red virtual se puede implementar detrás de un
equilibrador de carga interno de Azure para lograr alta disponibilidad.

Prerrequisitos
Antes de crear un Virtual Network TAP, debe haber recibido un correo electrónico de confirmación de su inscripción
a la versión preliminar y debe haber creado una o más máquinas virtuales usando el modelo de implementación
de Azure Resource Manager y una solución de un partner para agregar el tráfico de TAP en la misma región de
Azure. Si no tiene ninguna solución de partner en la red virtual, consulte soluciones de partners para implementar
una. Puede usar el mismo recurso de Virtual Red TAP para agregar tráfico de diferentes interfaces de red en la
misma suscripción o en suscripciones distintas. Si las interfaces de red supervisadas se encuentran en
suscripciones distintas, ambas suscripciones deben estar asociadas al mismo inquilino de Azure Active Directory.
Además, las interfaces de red supervisadas y el punto de conexión de destino para agregar tráfico del TAP pueden
estar en redes virtuales emparejadas en la misma región. Si usa este modelo de implementación, asegúrese de que
el emparejamiento de redes virtuales está habilitada antes de configurar Virtual Network TAP.

Permisos
Las cuentas que utiliza para aplicar la configuración del TAP en interfaces de red deben estar asignadas al rol de
colaborador de red o a un rol personalizado que tenga asignadas las acciones necesarias de la tabla siguiente:

A C C IÓ N N O M B RE

[Link]/virtualNetworkTaps/* Necesaria para crear, actualizar, leer y eliminar un recurso de

Virtual Network TAP

[Link]/networkInterfaces/read Necesaria para leer el recurso de la interfaz de red en que el

TAP se configurará

[Link]/tapConfigurations/* Necesaria para crear, actualizar, leer y eliminar la configuración

del TAP en una interfaz de red

Soluciones de los partners de Virtual Network TAP

Agentes de paquetes de red
GigaSECURE de Gigamon
CloudLens de Ixia
Prisms de Nubeva
Big Monitoring Fabric de Big Switch
Análisis de seguridad, administración del rendimiento de red o de la aplicación
Awake Security
Cisco Stealthwatch Cloud
Darktrace
Reveal(x) de ExtraHop
Cybersecurity de Fidelis
Flowmon
NetFort LANGuardian
vSTREAM de Netscout
Riverbed SteelCentral AppResponse
NetWitness® Platform de RSA
Cognito de Vectra

Pasos siguientes
Obtenga información sobre cómo crear un Virtual Network TAP.
 Controles de cumplimiento normativo de Azure
Policy para Azure Virtual Network
23/09/2020 • 22 minutes to read • Edit Online

Cumplimiento normativo de Azure Policy proporciona definiciones de iniciativas creadas y administradas por
Microsoft, conocidas como integraciones, para los dominios de cumplimiento y los controles de seguridad
relativos a distintos estándares de cumplimiento. En esta página se enumeran los dominios de cumplimiento y
los controles de seguridad para Azure Virtual Network. Para que los recursos de Azure sean compatibles con el
estándar específico, puede asignar las integraciones a un control de seguridad de manera individual.
El título de cada definición de directiva integrada se vincula a la definición de directiva en Azure Portal. Use el
vínculo de la columna Versión de directiva para ver el origen en el repositorio de GitHub de Azure Policy.

IMPORTANT
Cada control que se muestra a continuación está asociado a una o varias definiciones de Azure Policy. Estas directivas pueden
ayudarle a evaluar el cumplimiento mediante el control. Sin embargo, con frecuencia no hay una correspondencia completa o
exacta entre un control y una o varias directivas. Como tal, el cumplimiento con Azure Policy solo se refiere a las propias
directivas; esto no garantiza que sea totalmente compatible con todos los requisitos de un control. Además, el estándar de
cumplimiento incluye controles que no se abordan con las definiciones de Azure Policy en este momento. Por lo tanto, el
cumplimiento en Azure Policy es solo una vista parcial del estado general de cumplimiento. Las asociaciones entre los
controles y las definiciones de cumplimiento normativo de Azure Policy para estos estándares de cumplimiento pueden
cambiar con el tiempo.

Prueba comparativa de la seguridad de Azure

Azure Security Benchmark proporciona recomendaciones sobre cómo proteger las soluciones de nube en Azure.
Para ver cómo se asigna completamente este servicio a Azure Security Benchmark, consulte los archivos de
asignación de Azure Security Benchmark.
Para revisar el modo en que las integraciones de Azure Policy disponibles para todos los servicios de Azure se
asignan a este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: Azure Security
Benchmark.

VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L ( A ZURE PO RTA L) ( GIT HUB)

Seguridad de redes 1.1 Proteja los recursos Todo el tráfico de 3.0.0-preview

mediante grupos de Internet debe
seguridad de red o enrutarse mediante la
Azure Firewall en su instancia de Azure
red virtual Firewall implementada

Seguridad de redes 1.1 Proteja los recursos Las subredes deben 3.0.0
mediante grupos de estar asociadas con
seguridad de red o un grupo de
Azure Firewall en su seguridad de red.
red virtual
 VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L

Seguridad de redes 1.1 Proteja los recursos Las máquinas 1.0.0

mediante grupos de virtuales deben estar
seguridad de red o conectadas a una red
Azure Firewall en su virtual aprobada
red virtual

Seguridad de redes 1.1 Proteja los recursos Las redes virtuales 1.0.0
mediante grupos de deben usar la puerta
seguridad de red o de enlace de red
Azure Firewall en su virtual especificada
red virtual

Seguridad de redes 1.2 Supervise y registre la Network Watcher 1.0.0

configuración y el debe estar habilitado
tráfico de redes
virtuales, subredes y
NIC

Seguridad de redes 1.4 Deniegue las Todo el tráfico de 3.0.0-preview

comunicaciones con Internet debe
direcciones IP enrutarse mediante la
malintencionadas instancia de Azure
conocidas Firewall implementada

Seguridad de redes 1.4 Deniegue las Azure DDoS 2.0.0

comunicaciones con Protection Standard
direcciones IP debe estar habilitado
malintencionadas
conocidas

Seguridad de redes 1.5 Registre los paquetes Network Watcher 1.0.0

de red y registros de debe estar habilitado
flujo

CIS Microsoft Azure Foundations Benchmark

Para revisar el modo en que las integraciones de Azure Policy disponibles para todos los servicios de Azure se
corresponden a este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: CIS Microsoft
Azure Foundations Benchmark 1.1.0. Para más información sobre este estándar de cumplimiento, consulte CIS
Microsoft Azure Foundations Benchmark.

VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L ( A ZURE PO RTA L) ( GIT HUB)

Security Center 2.9 Asegúrese de que la Las subredes deben 3.0.0

configuración de la estar asociadas con
directiva un grupo de
predeterminada de seguridad de red.
ASC "Habilitar la
supervisión de
firewalls de última
generación (NGFW)"
no sea
"Deshabilitado".
 VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L

Redes 6.1 Asegúrese de que el El acceso RDP desde 2.0.0

acceso RDP está Internet debe estar
restringido desde bloqueado
Internet.

Redes 6.2 Asegúrese de que el El acceso SSH desde 2.0.0

acceso SSH está Internet debe estar
restringido desde bloqueado
Internet.

Redes 6.5 Asegúrese de que Network Watcher 1.0.0

Network Watcher está debe estar habilitado
"Habilitado".

HIPAA/HITRUST 9.2
Con el fin de revisar el modo en que las integraciones de Azure Policy disponibles para los servicios de Azure
siguen este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: HIPAA/HITRUST 9.2. Para
más información acerca de este estándar de cumplimiento, consulte HIPAA/HITRUST 9.2.

VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L ( A ZURE PO RTA L) ( GIT HUB)

Segregación en redes 0805.01m1Organizati Las puertas de enlace Las subredes de la 1.0.0

onal.12 - 01.m de seguridad de la puerta de enlace no
organización (por se deben configurar
ejemplo, los firewalls) con un grupo de
aplican las directivas seguridad de red
de seguridad y están
configuradas para
filtrar el tráfico entre
dominios, bloquean el
acceso no autorizado
y se usan para
mantener la
segregación entre
segmentos de red
cableados internos,
inalámbricos internos
y externos (por
ejemplo, Internet),
incluidas las redes
perimetrales y aplican
directivas de control
de acceso para cada
uno de los dominios.
 VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L

Segregación en redes 0805.01m1Organizati Las puertas de enlace Las subredes deben 3.0.0
onal.12 - 01.m de seguridad de la estar asociadas con
organización (por un grupo de
ejemplo, los firewalls) seguridad de red.
aplican las directivas
de seguridad y están
configuradas para
filtrar el tráfico entre
dominios, bloquean el
acceso no autorizado
y se usan para
mantener la
segregación entre
segmentos de red
cableados internos,
inalámbricos internos
y externos (por
ejemplo, Internet),
incluidas las redes
perimetrales y aplican
directivas de control
de acceso para cada
uno de los dominios.

Segregación en redes 0805.01m1Organizati Las puertas de enlace Las máquinas 1.0.0

onal.12 - 01.m de seguridad de la virtuales deben estar
organización (por conectadas a una red
ejemplo, los firewalls) virtual aprobada
aplican las directivas
de seguridad y están
configuradas para
filtrar el tráfico entre
dominios, bloquean el
acceso no autorizado
y se usan para
mantener la
segregación entre
segmentos de red
cableados internos,
inalámbricos internos
y externos (por
ejemplo, Internet),
incluidas las redes
perimetrales y aplican
directivas de control
de acceso para cada
uno de los dominios.
 VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L

Segregación en redes 0806.01m2Organizati La red de la Las subredes de la 1.0.0

onal.12356 - 01.m organización se puerta de enlace no
segmenta de manera se deben configurar
lógica y física con un con un grupo de
perímetro de seguridad de red
seguridad definido y
un conjunto
escalonado de
controles, que incluye
subredes para los
componentes del
sistema de acceso
público que están
separados
lógicamente de la red
interna, según los
requisitos de la
organización. El tráfico
se controla con
arreglo a la
funcionalidad
requerida y la
clasificación de los
datos o sistemas, de
acuerdo con una
evaluación de los
riesgos y los
correspondientes
requisitos de
seguridad.
 VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L

Segregación en redes 0806.01m2Organizati La red de la Las subredes deben 3.0.0

onal.12356 - 01.m organización se estar asociadas con
segmenta de manera un grupo de
lógica y física con un seguridad de red.
perímetro de
seguridad definido y
un conjunto
escalonado de
controles, que incluye
subredes para los
componentes del
sistema de acceso
público que están
separados
lógicamente de la red
interna, según los
requisitos de la
organización. El tráfico
se controla con
arreglo a la
funcionalidad
requerida y la
clasificación de los
datos o sistemas, de
acuerdo con una
evaluación de los
riesgos y los
correspondientes
requisitos de
seguridad.
 VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L

Segregación en redes 0806.01m2Organizati La red de la Las máquinas 1.0.0

onal.12356 - 01.m organización se virtuales deben estar
segmenta de manera conectadas a una red
lógica y física con un virtual aprobada
perímetro de
seguridad definido y
un conjunto
escalonado de
controles, que incluye
subredes para los
componentes del
sistema de acceso
público que están
separados
lógicamente de la red
interna, según los
requisitos de la
organización. El tráfico
se controla con
arreglo a la
funcionalidad
requerida y la
clasificación de los
datos o sistemas, de
acuerdo con una
evaluación de los
riesgos y los
correspondientes
requisitos de
seguridad.

Segregación en redes 0894.01m2Organizati Las redes se separan Implementar Network 1.0.0

onal.7 - 01.m de las redes de nivel Watcher al crear redes
de producción al virtuales.
migrar servidores
físicos, aplicaciones o
datos a servidores
virtualizados.

Segregación en redes 0894.01m2Organizati Las redes se separan Las subredes de la 1.0.0

onal.7 - 01.m de las redes de nivel puerta de enlace no
de producción al se deben configurar
migrar servidores con un grupo de
físicos, aplicaciones o seguridad de red
datos a servidores
virtualizados.

Segregación en redes 0894.01m2Organizati Las redes se separan Las subredes deben 3.0.0
onal.7 - 01.m de las redes de nivel estar asociadas con
de producción al un grupo de
migrar servidores seguridad de red.
físicos, aplicaciones o
datos a servidores
virtualizados.
 VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L

Segregación en redes 0894.01m2Organizati Las redes se separan Las máquinas 1.0.0

onal.7 - 01.m de las redes de nivel virtuales deben estar
de producción al conectadas a una red
migrar servidores virtual aprobada
físicos, aplicaciones o
datos a servidores
virtualizados.

Control de conexión 0809.01n2Organizati El tráfico de red se Las subredes deben 3.0.0

de red onal.1234 - 01.n regula de acuerdo con estar asociadas con
la directiva de control un grupo de
de acceso de la seguridad de red.
organización
mediante el firewall y
otras restricciones
relativas a la red para
cada punto de acceso
de red o interfaz
administrada del
servicio de
telecomunicaciones
externo.

Control de conexión 0809.01n2Organizati El tráfico de red se Las máquinas 1.0.0

de red onal.1234 - 01.n regula de acuerdo con virtuales deben estar
la directiva de control conectadas a una red
de acceso de la virtual aprobada
organización
mediante el firewall y
otras restricciones
relativas a la red para
cada punto de acceso
de red o interfaz
administrada del
servicio de
telecomunicaciones
externo.

Control de conexión 0810.01n2Organizati La información Las subredes deben 3.0.0

de red onal.5 - 01.n transmitida se estar asociadas con
protege y, como un grupo de
mínimo, se cifra para seguridad de red.
las redes públicas y
abiertas.

Control de conexión 0810.01n2Organizati La información Las máquinas 1.0.0

de red onal.5 - 01.n transmitida se virtuales deben estar
protege y, como conectadas a una red
mínimo, se cifra para virtual aprobada
las redes públicas y
abiertas.
 VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L

Control de conexión 0811.01n2Organizati Las excepciones a la Las subredes deben 3.0.0

de red onal.6 - 01.n directiva de flujo de estar asociadas con
tráfico se documentan un grupo de
con fines de respaldo seguridad de red.
o por necesidad de la
empresa, especifican
la duración de la
excepción y se revisan
al menos una vez al
año. Estas
excepciones se
eliminan cuando ya
no son necesarias
para una finalidad
específica o un
requisito empresarial.

Control de conexión 0811.01n2Organizati Las excepciones a la Las máquinas 1.0.0

de red onal.6 - 01.n directiva de flujo de virtuales deben estar
tráfico se documentan conectadas a una red
con fines de respaldo virtual aprobada
o por necesidad de la
empresa, especifican
la duración de la
excepción y se revisan
al menos una vez al
año. Estas
excepciones se
eliminan cuando ya
no son necesarias
para una finalidad
específica o un
requisito empresarial.

Control de conexión 0812.01n2Organizati Los dispositivos Las subredes deben 3.0.0

de red onal.8 - 01.n remotos que estar asociadas con
establecen conexiones un grupo de
no remotas no seguridad de red.
pueden comunicarse
con recursos externos
(remotos).

Control de conexión 0812.01n2Organizati Los dispositivos Las máquinas 1.0.0

de red onal.8 - 01.n remotos que virtuales deben estar
establecen conexiones conectadas a una red
no remotas no virtual aprobada
pueden comunicarse
con recursos externos
(remotos).
 VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L

Control de conexión 0814.01n1Organizati La capacidad de los Las subredes deben 3.0.0

de red onal.12 - 01.n usuarios para estar asociadas con
conectarse a la red un grupo de
interna está seguridad de red.
restringida mediante
una directiva
"denegar de forma
predeterminada" y
"permitir por
excepción" en las
interfaces
administradas, de
acuerdo con la
directiva de control de
acceso y los requisitos
de las aplicaciones
empresariales y de
uso clínico.

Control de conexión 0814.01n1Organizati La capacidad de los Las máquinas 1.0.0

de red onal.12 - 01.n usuarios para virtuales deben estar
conectarse a la red conectadas a una red
interna está virtual aprobada
restringida mediante
una directiva
"denegar de forma
predeterminada" y
"permitir por
excepción" en las
interfaces
administradas, de
acuerdo con la
directiva de control de
acceso y los requisitos
de las aplicaciones
empresariales y de
uso clínico.

Controles de red 0860.09m1Organizati La organización Implementar la 1.0.0

onal.9 - 09.m administra configuración de
formalmente los diagnóstico para
equipos de la red, grupos de seguridad
incluidos los equipos de red
de las áreas de
usuario.

Seguridad de Network 0837.09.n2Organizati Los contratos Network Watcher 1.0.0

Services onal.2 - 09.n formales con debe estar habilitado
proveedores de
sistemas de
información externos
especifican las
obligaciones de
seguridad y
privacidad.
 VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L

Seguridad de Network 0886.09n2Organizati La organización utiliza Network Watcher 1.0.0

Services onal.4 - 09.n y documenta debe estar habilitado
mediante un contrato
formal u otro tipo de
documento las
directivas basadas en
i) permitir todo,
denegar por
excepción, o bien en
ii) denegar todo,
permitir por excepción
(opción preferente) a
fin de permitir que
sistemas de
información
específicos se
conecten a sistemas
de información
externos.

Seguridad de Network 0888.09n2Organizati El contrato con el Network Watcher 1.0.0

Services onal.6 - 09.n proveedor de debe estar habilitado
servicios externos o
subcontratados
especifica que el
proveedor de
servicios es
responsable de
proteger la
información cubierta
que se comparta.

NIST SP 800-171 R2
Para revisar el modo en que las integraciones de Azure Policy disponibles para todos los servicios de Azure se
corresponden a este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: NIST SP 800-
171 R2. Para más información acerca de este estándar normativo, consulte NIST SP 800-171 R2.

VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L ( A ZURE PO RTA L) ( GIT HUB)

Integridad del sistema 3.14.6 Supervisa los sistemas Network Watcher 1.0.0
y de la información de la organización, debe estar habilitado
incluido el tráfico
entrante y saliente de
las comunicaciones,
para detectar ataques
e indicadores de
posibles ataques.

NIST SP 800-53 R4
Para revisar el modo en que las integraciones de Azure Policy disponibles para todos los servicios de Azure se
corresponden a este estándar de cumplimiento, consulte Cumplimiento normativo de Azure Policy: NIST SP 800-53
R4. Para más información acerca de este estándar normativo, consulte NIST SP 800-53 R4.
 VERSIÓ N DE L A
DIREC T IVA DIREC T IVA
DO M A IN ID. DE C O N T RO L T ÍT ULO DE C O N T RO L ( A ZURE PO RTA L) ( GIT HUB)

Protección del sistema SC-5 Protección ante la Azure DDoS 2.0.0

y de las denegación de Protection Standard
comunicaciones servicio debe estar habilitado

Pasos siguientes
Obtenga más información sobre el cumplimiento normativo de Azure Policy.
Los elementos integrados se pueden encontrar en el repositorio de GitHub de Azure Policy.
 Extensión de subred
23/09/2020 • 5 minutes to read • Edit Online

La migración de cargas de trabajo a la nube pública requiere una cuidadosa planeación y coordinación. Una de las
consideraciones clave puede ser la capacidad de conservar las direcciones IP. Esto puede ser importante
especialmente si las aplicaciones tienen dependencias de dirección IP o si tiene requisitos de cumplimiento para
usar direcciones IP específicas. Azure Virtual Network resuelve este problema, ya que le permite crear una red
virtual y subredes con el intervalo de direcciones IP que usted prefiera.
Las migraciones pueden llegar a ser un reto cuando el requisito anterior se combina con un requisito adicional para
mantener algunas aplicaciones en el entorno local. En tal caso, tendrá que dividir las aplicaciones entre Azure y el
entorno local, sin tener que volver a numerar las direcciones IP en ambos lados. Además, tendrá que permitir que
las aplicaciones se comuniquen como si estuvieran en la misma red.
Una solución al problema anterior es la extensión de subred. La extensión de una red permite a las aplicaciones
comunicarse en el mismo dominio de difusión cuando existen en diferentes ubicaciones físicas, lo que elimina la
necesidad de rediseñar la topología de red.
Aunque la extensión de la red no es una buena práctica en general, los casos de uso siguientes pueden hacer que
sea necesario.
Migración por fases : el escenario más común es que desee escalonar la migración. Desea llevar algunas
aplicaciones primero y, con el tiempo, migrar el resto de las aplicaciones a Azure.
Latencia : los requisitos de baja latencia pueden ser otro motivo para mantener algunas aplicaciones en el
entorno local con el fin de asegurarse de que están lo más cerca posible del centro de recursos.
Cumplimiento : otro caso de uso es que podría tener requisitos de cumplimiento para mantener algunas de sus
aplicaciones en el entorno local.

NOTE
No debe extender las subredes a menos que sea necesario. En los casos en que extienda las subredes, debe intentar que sea
un paso intermedio. Con el tiempo, debe intentar volver a numerar las aplicaciones en la red local y migrarlas a Azure.

En la siguiente sección analizaremos cómo puede extender las subredes a Azure.

Extensión de la subred a Azure

Puede extender las subredes locales a Azure con una solución basada en la red de superposición de nivel 3. La
mayoría de las soluciones usan una tecnología de superposición, como VXLAN, para extender la red de nivel 2
mediante una red de superposición de nivel 3. En el diagrama siguiente se muestra una solución generalizada. En
esta solución, la misma subred existe en ambos lados, es decir, en Azure y en el entorno local.
Las direcciones IP de la subred se asignan a las máquinas virtuales en Azure y en el entorno local. Tanto Azure
como el entorno local tienen un NVA insertado en sus redes. Cuando una máquina virtual de Azure intenta
comunicarse con una máquina virtual en una red local, el NVA de Azure captura el paquete, lo encapsula y lo envía
a través de VPN/ExpressRoute a la red local. El NVA local recibe el paquete, lo desencapsula y lo reenvía al
destinatario previsto en su red. El tráfico de retorno utiliza una ruta y lógica similares.
En el ejemplo anterior, el NVA de Azure y el NVA local se comunican y aprenden sobre las direcciones IP que tienen
detrás de ellos. Las redes más complejas también pueden tener un servicio de asignación, que mantiene la
asignación entre los NVA y las direcciones IP detrás de ellos. Cuando un NVA recibe un paquete, consulta el servicio
de asignación para averiguar la dirección del NVA que tiene la dirección IP de destino detrás de él.
En la sección siguiente, encontrará información sobre las soluciones de extensión de subred que hemos probado en
Azure.

Pasos siguientes
Amplíe su subred a Azure mediante soluciones de proveedor.
 ¿Qué es la delegación de subred?
23/09/2020 • 6 minutes to read • Edit Online

La delegación de subred permite designar una subred concreta para el servicio PaaS de Azure que se prefiera e
insertarla en una red virtual. La delegación de subred proporciona al cliente control total al cliente de la
administración de la integración de los servicios de Azure en sus redes virtuales.
Al delegar una subred en un servicio de Azure, se permite que el servicio establezca algunas reglas básicas de
configuración de red para la subred, lo que facilita que las instancias del servicio de Azure funcionen de manera
estable. Como resultado, el servicio de Azure puede establecer algunas condiciones previas o posteriores a la
implementación, como:
implementar el servicio en una subred compartida, en lugar de una dedicada.
agregar al servicio un conjunto de directivas de intenciones de red después de la implementación que se
requiere para que el servicio funcione correctamente.

Ventajas de la delegación de subred

La delegación de una subred a servicios concretos aporta las siguientes ventajas:
ayuda a designar una subred para uno o varios servicios de Azure y a administrar las instancias de la subred en
función de los requisitos. Por ejemplo, el propietario de la red virtual puede definir lo siguientes elementos para
una subred delegada, con el fin de administrar mejor los recursos y el acceso como se indica a continuación:
Directivas de tráfico de filtrado de red con grupos de seguridad de red.
Directivas de enrutamiento con rutas definidas por el usuario.
Integración de servicios con configuraciones de puntos de conexión de servicio.
Ayuda a los servicios insertados a integrarse mejor con la red virtual mediante la definición de las condiciones
previas de las implementaciones, en forma de directivas de intenciones de red. Esto garantiza que cualquier
acción que pueda afectar al funcionamiento del servicio insertado se puede bloquear en PUT.

¿Quién puede delegar?

La delegación de subred es un ejercicio que los propietarios de redes virtuales deben realizar para designar una de
las subredes para un servicio de Azure concreto. A su vez, el servicio de Azure implementa las instancias en esta
subred para que las consuman las cargas de trabajo de los clientes.

Impacto de la delegación de subred en una subred

Cada servicio de Azure define su propio modelo de implementación, en el que se puede especificar las propiedades
que admite, o no, en una subred delegada a la hora de la inserción, tal como se indica a continuación:
subred compartida con otros servicios de Azure o con un conjunto de escalado de máquinas virtuales o
máquinas virtuales que estén en la misma subred, o bien solo admite una subred dedicada que tenga
únicamente instancias de este servicio.
Admite la asociación de grupos de seguridad de red con la subred delegada.
Admite que un grupo de seguridad de red que esté asociado a la subred delegada también pueda estarlo a
cualquier otra subred.
Permite la asociación de la tabla de rutas con la subred delegada.
Permite que la tabla de rutas asociada con la subred delegada se asocie con cualquier otra subred.
Dicta el número mínimo de direcciones IP en la subred delegada.
 Dicta que el espacio de direcciones IP de la subred delegada sea del espacio de direcciones IP privadas
([Link]/8, [Link]/16, [Link]/12).
Dicta que la configuración de DNS personalizada tenga una entrada Azure DNS.
Los servicios insertados también pueden agregar sus propias directivas, como las siguientes:
Directivas de seguridad : colección de reglas de seguridad necesarias para el funcionamiento de un servicio
determinado.
Directivas de rutas : colección de rutas necesarias para el funcionamiento de un servicio dado.

Qué es lo que no hace la delegación de subred

Los servicios de Azure que se insertan en una subred delegada tienen el conjunto básico de propiedades, que está
disponible para las subredes no delegadas, como:
Los servicios de Azure pueden insertar instancias en las subredes de los clientes, pero no pueden afectar a las
cargas de trabajo existentes.
Las directivas o rutas que aplican estos servicios son flexibles y las pueden reemplazar el cliente.

Pasos siguientes
Delegación de una subred
 Planear redes virtuales
23/09/2020 • 22 minutes to read • Edit Online

Crear una red virtual con la cual experimentar es bastante sencillo, pero es probable que, con el tiempo,
implemente varias redes virtuales para satisfacer las necesidades de producción que tiene su organización. Con
cierto planeamiento, podrá implementar redes virtuales y conectar los recursos que necesita de manera más eficaz.
La información de este artículo es más útil si ya está familiarizado con las redes virtuales y tiene cierta experiencia
al trabajar con ellas. Si no está familiarizado con las redes virtuales, le recomendamos que lea la información
general sobre Virtual Network.

Nomenclatura
Todos los recursos de Azure tienen un nombre. El nombre debe ser único dentro de un ámbito, que puede variar
para cada tipo de recurso. Por ejemplo, el nombre de una red virtual debe ser único dentro de un grupo de
recursos, pero puede haber duplicados del nombre dentro de una suscripción o región de Azure. Definir una
convención de nomenclatura que pueda usar de forma consistente al asignar nombres a recursos le será de
utilidad al administrar varios recursos de red con el tiempo. Consulte Naming conventions (Convenciones de
nomenclatura) para obtener sugerencias.

Regions
Todos los recursos de Azure se crean en una suscripción y una región de Azure. Un recurso solo se puede crear en
una red virtual que exista en la misma región y suscripción de ese recurso. No obstante, puede conectar redes
virtuales que ya existan a diferentes suscripciones y regiones. Para obtener más información, consulteConectividad.
Al decidir en qué regiones implementar los recursos, debe tener en cuenta dónde se encuentran físicamente los
consumidores de esos recursos:
Los consumidores de recursos normalmente quieren obtener la latencia de red más baja para sus recursos. Para
determinar las latencias relativas entre una ubicación específica y las regiones de Azure, consulte View relative
latencies (Ver latencias relativas).
¿Debe cumplir con requisitos de residencia, soberanía, cumplimiento o resistencia de datos? Si es así, es
fundamental elegir la región que mejor se ajuste a sus requisitos. Para obtener más información, consulte Zonas
geográficas de Azure.
¿Necesita configurar la resistencia en Azure Availability Zones dentro de la misma región de Azure para los
recursos que está implementando? Puede implementar recursos como máquinas virtuales (VM) en diferentes
zonas de disponibilidad dentro de la misma red virtual. Sin embargo, no todas las regiones de Azure admiten
zonas de disponibilidad. Para obtener más información sobre las zonas de disponibilidad y las regiones que las
admiten, consulte Zonas de disponibilidad.

Suscripciones
Puede implementar tantas redes virtuales como sea necesario en cada suscripción, hasta el límite que se haya
establecido. Por ejemplo, algunas organizaciones tienen suscripciones distintas para diferentes departamentos.
Para obtener más información y detalles en torno a las suscripciones, consulte Gobernanza de suscripción.

Segmentación
Puede crear varias redes virtuales por suscripción y por región. Puede crear varias subredes en cada red virtual. Los
detalles siguientes le ayudarán a determinar cuántas redes virtuales y subredes necesita:
Redes virtuales
Una red virtual es una parte virtual y aislada de la red pública de Azure. Cada red virtual está dedicada a su
suscripción. Qué debe tener en cuenta al decidir si quiere crear una o varias redes virtuales en una suscripción:
¿Hay algún requisito de seguridad en la organización para aislar el tráfico en redes virtuales diferentes? Puede
elegir conectar la redes virtuales o no. Si conecta las redes virtuales, puede implementar una aplicación virtual
de red (como un firewall) para controlar el flujo de tráfico entre las redes virtuales. Para obtener más
información, consulte seguridad y conectividad.
¿Hay algún requisito en la organización para aislar las redes virtuales en diversas suscripciones o regiones?
Una interfaz de red permite que una máquina virtual se comunique con otros recursos. Cada interfaz de red
puede tener una o varias direcciones IP privadas asignadas. ¿Cuántas interfaces de red y direcciones IP privadas
se necesitan en una red virtual? Hay límites en el número de interfaces de red y direcciones IP privadas que se
pueden tener en una red virtual.
¿Quiere conectar la red virtual a otra red virtual o red local? Puede conectar algunas redes virtuales entre sí o a
redes locales, pero no a otras redes. Para obtener más información, consulteConectividad. Cada red virtual que
se conecta a otra red virtual o local debe tener un espacio de direcciones único. Cada red virtual tiene uno o más
intervalos de direcciones públicas o privadas asignados a su espacio de direcciones. Un intervalo de direcciones
se especifica en un formato propio del enrutamiento de interdominios sin clases (CIDR), como [Link]/16.
Obtenga más información sobre los intervalos de direcciones para redes virtuales.
¿Tiene algún requisito de administración de la organización para recursos en diferentes redes virtuales? De ser
así, puede separar los recursos en una red virtual a parte para simplificar la asignación de permisos a los
usuarios de la organización, o para asignar diferentes directivas a diferentes redes virtuales.
Cuando implementa algunos recursos del servicio de Azure en una red virtual, estos se encargan de crear su
propia red virtual. Para determinar si un servicio de Azure ha creado su propia red virtual, consulte la
información de cada servicio de Azure que se puede implementar en una red virtual.
Subredes
Una red virtual se puede segmentar en una o más subredes hasta el límite que se haya establecido. Qué debe tener
en cuenta al decidir si quiere crear una subred o varias redes virtuales en una suscripción:
Cada subred debe tener un intervalo de direcciones único, especificado en formato CIDR, en el espacio de
direcciones de la red virtual. Este intervalo de direcciones no puede superponerse con otras subredes de la red
virtual.
Si planea implementar algunos recursos del servicio de Azure en una red virtual, seguramente necesiten crear
su propia subred, por lo que debe haber suficiente espacio no asignado para que puedan hacerlo. Para
determinar si un servicio de Azure ha creado su propia subred, consulte la información de cada servicio de
Azure que se puede implementar en una red virtual. Por ejemplo, si conecta una red virtual a una red local
mediante Azure VPN Gateway, la red virtual debe tener una subred dedicada para la puerta de enlace. Obtenga
más información sobre las subredes de puerta de enlace.
De forma predeterminada, Azure enruta el tráfico de red entre todas las subredes de una red virtual. Por
ejemplo, puede invalidar el enrutamiento predeterminado de Azure para evitar el enrutamiento de Azure entre
subredes, o para enrutar el tráfico entre subredes a través de una aplicación virtual de red. Si necesita que el
tráfico entre recursos de la misma red virtual fluya a través de una aplicación virtual de red (NVA), implemente
los recursos en diferentes subredes. Obtenga más información en el apartado Seguridad.
Puede limitar el acceso a recursos de Azure como, por ejemplo, una cuenta de almacenamiento de Azure o
Azure SQL Database, a subredes específicas con un punto de conexión de servicio de red virtual. Además, puede
denegar el acceso a los recursos desde Internet. Puede crear varias subredes y habilitar un punto de conexión de
servicio para algunas subredes, pero no para otras. Obtenga más información sobre los puntos de conexión de
servicio y los recursos de Azure puede habilitar.
Puede asociar un grupo de seguridad de red o ninguno, a cada subred de una red virtual. Puede asociar el
mismo grupo de seguridad de red u otro diferente a cada subred. Cada grupo de seguridad de red contiene
reglas que permiten o niegan el paso del tráfico hacia y desde los orígenes y destinos. Más información sobre
 los grupos de seguridad de red.

Seguridad
Puede filtrar el tráfico de red hacia y desde los recursos en una red virtual mediante los grupos de seguridad de red
y las aplicaciones virtuales de red. Puede controlar la manera en que Azure enruta el tráfico de subredes. Asimismo,
también puede limitar en su organización quién puede trabajar con los recursos en redes virtuales.
Filtrado de tráfico
Puede filtrar el tráfico de red entre recursos de una red virtual mediante un grupo de seguridad de red, una NVA
que filtra el tráfico de red o ambos. Para implementar una NVA como un cortafuegos para filtrar el tráfico de
red, consulte Azure Marketplace. Al usar una NVA, también crea rutas personalizadas para enrutar el tráfico de
las subredes a la NVA. Obtenga más información acerca el enrutamiento del tráfico.
Un grupo de seguridad de red contiene varias reglas de seguridad predeterminadas que permiten o deniegan el
tráfico hacia o desde los recursos. Un grupo de seguridad de red se puede asociar a una interfaz de red, a la
subred que se encuentra en ella o a ambas. Siempre que sea posible y para simplificar la administración de
reglas de seguridad, le recomendamos que asocie un grupo de seguridad de red a las subredes individuales, en
lugar de asociarlo a las interfaces de red individuales de la subred.
Si debe aplicar reglas de seguridad a varias máquinas virtuales de una subred, puede asociar la interfaz de red
en la máquina virtual a uno o varios grupos de seguridad de aplicaciones. Una regla de seguridad puede
especificar un grupo de seguridad de aplicaciones en el origen, en el destino o en ambos. A continuación, solo se
aplica dicha regla a las interfaces de red que forman parte del grupo de seguridad de aplicaciones. Obtenga más
información sobre los grupos de seguridad de red y los grupos de seguridad de aplicaciones.
Azure crea de forma predeterminada varias reglas de seguridad en cada grupo de seguridad de red. Una regla
predeterminada permite que todo el tráfico fluya entre todos los recursos de una red virtual. Para invalidar este
comportamiento, use los grupos de seguridad de red, el enrutamiento personalizado para enrutar el tráfico a
una NVA o ambas opciones. Le recomendamos que se familiarice con todas las reglas de seguridad
predeterminadas de Azure, y con la forma de aplicar las reglas del grupo de seguridad de red a un recurso.
Puede ver los diseños de ejemplo para implementar una red perimetral (también conocida como DMZ) entre Azure
e Internet mediante NVA.
Enrutamiento del tráfico
Azure crea varias rutas predeterminadas para el tráfico saliente desde una subred. Puede invalidar el enrutamiento
predeterminado de Azure si crea una tabla de rutas y la asocia a una subred. Los motivos más comunes para
invalidar el enrutamiento predeterminado de Azure son:
Porque quiere que el tráfico entre subredes fluya a través de una NVA. Más información sobre cómo configurar
las tablas de rutas para forzar el tráfico a través de una NVA.
Porque quiere forzar todo el tráfico de Internet a través de una NVA o de forma local, a través de Azure VPN
Gateway. Forzar el tráfico de Internet de forma local para su inspección y registro a menudo se conoce como
"tunelización forzada". Obtenga más información sobre la configuración de la tunelización forzada.
Si tiene que implementar el enrutamiento personalizado, le recomendamos que se familiarice con el enrutamiento
en Azure.

Conectividad
Puede conectar una red virtual a otras redes virtuales mediante el emparejamiento de redes virtuales, o puede
conectarla a una red local mediante Azure VPN Gateway.
Emparejamiento
Al usar el emparejamiento de redes virtuales, las redes virtuales pueden estar en las mismas regiones de Azure
compatibles o en diferentes regiones. Las redes virtuales pueden estar en las mismas suscripciones de Azure
(incluso suscripciones que pertenezcan a diferentes inquilinos de Azure Active Directory), o en otras diferentes. Le
recomendamos que se familiarice con los requisitos y restricciones de emparejamiento antes de crear un
emparejamiento. El ancho de banda entre recursos de redes virtuales emparejadas en la misma región es el mismo
que si los recursos estuvieran en la misma red virtual.
puerta de enlace de VPN
Puede usar Azure VPN Gateway para conectar una red virtual a la red local mediante un VPN de sitio a sitio, o
mediante una conexión dedicada con Azure ExpressRoute.
Puede combinar el emparejamiento y una puerta de enlace de VPN para crear redes de tipo hub-and-spoke, donde
las redes virtuales denominadas "radios" (spoke) se conectan a una red virtual denominada "concentrador" (hub) y,
a su vez, ese concentrador se conecta a una red local, por ejemplo.
Resolución de nombres
Los recursos de una red virtual no pueden resolver los nombres de los recursos de una red virtual emparejada
mediante el DNS integrado de Azure. Para resolver nombres en una red virtual emparejada, despliegue su propio
servidor DNS, o use los dominios privados de Azure DNS. Recuerde que la resolución de nombres entre recursos
en una red virtual y en redes locales también requiere que implemente su propio servidor DNS.

Permisos
Azure usa el control de acceso basado en roles (RBAC) para los recursos. Se asignan permisos a un ámbito según la
siguiente jerarquía: grupo de administración, suscripción, grupo de recursos y recurso individual. Para obtener más
información acerca de la jerarquía, consulte Organización de los recursos. Para trabajar con redes virtuales de
Azure y todas sus capacidades relacionadas, como el emparejamiento, los grupos de seguridad de red, los puntos
de conexión de servicio y las tablas de rutas, puede asignar miembros de la organización a los roles integrados
Propietario, Colaborador o Colaborador de red y, a continuación, asignar uno de esos roles a un ámbito adecuado.
Si quiere asignar permisos específicos para un subconjunto de capacidades de red virtual, cree un rol
personalizado y asigne al rol los permisos específicos necesarios para redes virtuales, subredes y puntos de
conexión de servicio, interfaces de red, emparejamientos, grupos de seguridad de aplicaciones y red o tablas de
rutas.

Directiva
Azure Policy le permite crear, asignar y administrar las definiciones de directivas. Las definiciones de directivas
aplican distintas reglas en los recursos, para que estos sigan siendo compatibles con los estándares de la
organización y los contratos de nivel de servicio. Azure Policy ejecuta una evaluación de los recursos, para detectar
los que no son compatibles con las definiciones de directivas que tiene. Por ejemplo, puede definir y aplicar una
directiva que permita la creación de redes virtuales en un solo grupo de recursos o región específicos. Otra
directiva puede requerir que cada subred tenga un grupo de seguridad de red asociado a ella. Estas directivas se
evalúan al crear y actualizar los recursos.
Igualmente, las directivas se aplican según la jerarquía siguiente: grupo de administración, suscripción y grupo de
recursos. Obtenga más información sobre Azure Policy o acerca de cómo implementar algunas definiciones de
Azure Policy.

Pasos siguientes
Obtenga información acerca de todas las tareas, configuración y opciones para una red virtual, subred y punto de
conexión de servicio, interfaz de red, emparejamiento, grupo de seguridad de red y aplicaciones o una tabla de
rutas.
 Resolución de nombres de recursos en redes
virtuales de Azure
23/09/2020 • 33 minutes to read • Edit Online

Según cómo utilice Azure para hospedar soluciones híbridas, IaaS y PaaS, puede que tenga que permitir que las
máquinas virtuales (VM) y otros recursos implementados en una red virtual se comuniquen entre sí. Aunque
puede habilitar la comunicación mediante las direcciones IP, es mucho más sencillo usar nombres, ya que podrá
recordarlos con más facilidad y no cambian.
Si los recursos implementados en redes virtuales necesitan resolver nombres de dominio en direcciones IP
internas, pueden usar uno de tres métodos:
Zonas privadas de Azure DNS
Resolución de nombres de Azure
Resolución de nombres con su propio servidor DNS (que puede reenviar consultas a los servidores DNS
proporcionados por Azure)
El tipo de resolución de nombres que tenga que usar dependerá de cómo se comuniquen los recursos entre sí.
En la siguiente tabla se muestran los escenarios y las soluciones de resolución de nombre correspondientes:

NOTE
Las zonas privadas de Azure DNS son la solución preferida y proporcionan flexibilidad para la administración de los
registros y las zonas DNS. Para obtener más información, vea Uso de Azure DNS para dominios privados.

NOTE
Si usa un DNS proporcionado por Azure, el sufijo DNS adecuado se aplicará automáticamente a las máquinas virtuales.
Para todas las demás opciones, debe usar nombres de dominio completos (FQDN) o aplicar manualmente el sufijo DNS
adecuado a las máquinas virtuales.

ESC EN A RIO SO L UC IÓ N SUF IJO DN S

Resolución de nombres entre máquinas Zonas privadas de Azure DNS o Nombre de host o FQDN
virtuales ubicadas en la misma red resolución de nombres proporcionada
virtual, o instancias de rol de Azure por Azure
Cloud Services en el mismo servicio en
la nube.

Resolución de nombres entre máquinas Zonas privadas de Azure DNS o Solo FQDN
virtuales en redes virtuales diferentes o servidores DNS administrados por el
instancias de rol en diferentes servicios cliente que reenvían consultas entre
en la nube. redes virtuales para la resolución
mediante Azure (proxy DNS). Consulte
Resolución de nombres mediante su
propio servidor DNS.
 ESC EN A RIO SO L UC IÓ N SUF IJO DN S

Resolución de nombres de Azure App Servidores DNS administrados por el Solo FQDN
Service (aplicación web, función o bot) cliente que reenvían consultas entre
mediante la integración de red virtual redes virtuales para la resolución
con instancias de rol o máquinas mediante Azure (proxy DNS). Consulte
virtuales en la misma red virtual. Resolución de nombres mediante su
propio servidor DNS.

Resolución de nombres entre instancias Servidores DNS administrados por el Solo FQDN
de App Service Web Apps en máquinas cliente que reenvían consultas entre
virtuales en la misma red virtual. redes virtuales para la resolución
mediante Azure (proxy DNS). Consulte
Resolución de nombres mediante su
propio servidor DNS.

Resolución de nombres de App Service Servidores DNS administrados por el Solo FQDN
Web Apps de una máquina virtual a las cliente que reenvían consultas entre
máquinas virtuales de otra red virtual. redes virtuales para la resolución
mediante Azure (proxy DNS). Consulte
Resolución de nombres mediante su
propio servidor DNS.

Resolución de nombres de servicios y Servidores DNS administrados por el Solo FQDN

de equipos locales de máquinas cliente (controlador de dominio local,
virtuales o instancias de rol en Azure. controlador de dominio de solo lectura
local o un DNS secundario sincronizado
mediante transferencias de zona, por
ejemplo). Consulte Resolución de
nombres mediante su propio servidor
DNS.

Resolución de nombres de host de Reenvío de consultas a un servidor Solo FQDN

Azure desde equipos locales. proxy DNS administrado por el cliente
en la red virtual correspondiente: el
servidor proxy reenvía consultas a
Azure para su resolución. Consulte
Resolución de nombres mediante su
propio servidor DNS.

DNS inverso para direcciones IP Zonas privadas de Azure DNS, No aplicable

internas. resolución de nombres proporcionada
por Azure o resolución de nombres
mediante su propio servidor DNS.

Resolución de nombres entre máquinas No aplicable. La conectividad entre No aplicable

virtuales o instancias de rol ubicadas máquinas virtuales e instancias de rol
en diferentes servicios en la nube y no de servicios en la nube diferentes no es
en una red virtual. compatible fuera de una red virtual.

Resolución de nombres de Azure

La resolución de nombres proporcionada por Azure solo ofrece las funcionalidades autoritativas básicas de DNS.
Si usa esta opción, Azure administrará automáticamente los registros y nombres de las zonas DNS, y no podrá
controlar los nombres de zona DNS ni el ciclo de vida de los registros DNS. Si necesita una solución DNS
completa para sus redes virtuales, debe usar zonas privadas de Azure DNS o servidores DNS administrados por
el cliente.
Junto con la resolución de nombres DNS públicos, Azure proporciona una resolución de nombres interna para
máquinas virtuales e instancias de rol que residen dentro de la misma red virtual o servicio en la nube. Las
máquinas virtuales y las instancias en un servicio en la nube comparten el mismo sufijo DNS (por lo que el
nombre de host por sí solo es suficiente). No obstante, en las redes virtuales implementadas con el modelo de
implementación clásica, diferentes servicios en la nube tienen distintos sufijos DNS. En esta situación, es
necesario el FQDN para resolver los nombres entre diferentes servicios en la nube. En las redes virtuales
implementadas con el modelo de implementación de Azure Resource Manager, el sufijo DNS es coherente en
todas las máquinas virtuales de una red virtual, de modo que el FQDN no es necesario. Los nombres DNS se
pueden asignar a máquinas virtuales y a interfaces de red. Aunque la resolución de nombres que proporciona
Azure no necesita ningún tipo de configuración, no es la opción más adecuada para todos los escenarios de
implementación, tal y como se explicó en la tabla anterior.

NOTE
En el caso de los roles web y de trabajo de servicios en la nube, puede acceder a las direcciones IP internas de las instancias
de rol mediante la API de REST de administración de servicios de Azure. Para obtener más información, consulte la
Referencia de la API REST de administración de servicios. La dirección se basa en el nombre de rol y el número de instancia.

Características
La resolución de nombres proporcionada por Azure incluye las siguientes características:
Facilidad de uso. No se requiere ninguna configuración.
Alta disponibilidad. No es necesario crear clústeres de sus propios servidores DNS ni administrarlos.
Puede utilizar el servicio junto con sus propios servidores DNS para resolver nombres de host de Azure y
locales.
Puede usar la resolución de nombres entre las máquinas virtuales y las instancias de rol del mismo servicio
en la nube, sin necesidad de un nombre de dominio completo.
Puede usar la resolución de nombres entre las máquinas virtuales en redes virtuales que usan el modelo de
implementación de Azure Resource Manager, sin necesidad de un nombre de dominio completo. En el
modelo de implementación clásica, las redes virtuales requieren un FQDN cuando se resuelven nombres en
diferentes servicios en la nube.
Puede usar los nombres de host que describan mejor las implementaciones, en lugar de trabajar con
nombres generados automáticamente.
Consideraciones
Puntos que deben considerarse cuando se utiliza la resolución de nombres de Azure:
No se puede modificar el sufijo DNS creado por Azure.
La búsqueda de DNS está en el ámbito de una red virtual. Los nombres DNS creados para una red virtual no
se pueden resolver desde otras redes virtuales.
No se pueden registrar manualmente los registros propios.
No se admiten ni WINS ni NetBIOS. Las máquinas virtuales no se pueden ver en el Explorador de Windows.
Los nombres de host deben ser compatibles con DNS. Los nombres solamente pueden contener los
caracteres 0-9, a-z y "-", y no pueden comenzar ni terminar por "-".
El tráfico de consultas de DNS está limitado por cada máquina virtual. La limitación no debería afectar a la
mayoría de las aplicaciones. Si se observa una limitación de solicitudes, asegúrese de que está habilitado el
almacenamiento en caché del lado cliente. Para más información, consulte Configuración de cliente DNS.
En un modelo de implementación clásico, solo se registran las máquinas virtuales de los 180 primeros
servicios en la nube para cada red virtual clásica. Este límite no se aplica a las redes virtuales en Azure
Resource Manager.
La dirección IP de Azure DNS es [Link]. Es una dirección IP estática y no cambiará.
Consideraciones sobre el DNS inverso
El DNS inverso es compatible con todas las redes virtuales basadas en ARM. Puede emitir consultas de DNS
inverso (consultas PTR) para asignar las direcciones IP de las máquinas virtuales a los FQDN de las máquinas
virtuales.
Todas las consultas PTR para las direcciones IP de las máquinas virtuales devolverán FQDN con el formato
[vmname].[Link].
La búsqueda directa en FQDN con el formato [vmname].[Link] se resolverá en la dirección IP
asignada a la máquina virtual.
Si la red virtual está vinculada a una zona privada de Azure DNS como una red virtual de registro, las
consultas de DNS inverso devolverán dos registros. Un registro tiene el formato [vmname].
[privatednszonename] y el otro [vmname].[Link].
La búsqueda de DNS inverso está en el ámbito de una red virtual determinada aunque esté emparejada con
otras redes virtuales. Las consultas de DNS inverso (consultas PTR) para las direcciones IP de las máquinas
virtuales que se encuentran en redes virtuales emparejadas devolverán NXDOMAIN.
Si desea desactivar la función de DNS inverso en una red virtual, puede crear una zona de búsqueda inversa
mediante las zonas privadas de Azure DNS y vincular esta zona a la red virtual. Por ejemplo, si el espacio de
direcciones IP de la red virtual es [Link]/16, puede crear una zona DNS privada vacía [Link] y
vincularla a la red virtual. Al vincular la zona a la red virtual, debe deshabilitar el registro automático en el
vínculo. Esta zona invalidará las zonas de búsqueda inversa predeterminadas para la red virtual y, puesto que
esta zona está vacía, obtendrá NXDOMAIN para las consultas de DNS inversas. Consulte nuestra guía de
inicio rápido para más información sobre cómo crear una zona DNS privada y vincularla a una red virtual.

NOTE
Si desea que la búsqueda de DNS inverso se extienda a través de la red virtual, puede crear una zona de búsqueda inversa
([Link]) denominada zonas privadas de Azure DNS y vincularla a varias redes virtuales. Sin embargo, tendrá que
administrar manualmente los registros de DNS inverso para las máquinas virtuales.

Configuración del cliente DNS

Esta sección trata los intentos del lado cliente y el almacenamiento en caché del cliente.
Almacenamiento en caché del lado cliente
No todas las consultas DNS deben enviarse a través de la red. El almacenamiento en caché del cliente ayuda a
reducir la latencia y a mejorar la resistencia a la señalización visual de la red mediante la resolución de las
consultas DNS periódicas desde una memoria caché local. Los registros DNS contienen un mecanismo para
contabilizar el período de vida (TTL), lo que permite a la memoria caché almacenar el registro el máximo tiempo
posible sin afectar a la actualización de registros. Por ello, el almacenamiento en caché del cliente es adecuado
para la mayoría de las situaciones.
El cliente DNS de Windows predeterminado tiene una memoria caché DNS integrada. Algunas distribuciones de
Linux no incluyen el almacenamiento en caché de forma predeterminada. Si comprueba que aún no hay una
memoria caché local, agregue una memoria caché DNS a cada máquina virtual Linux.
Hay una serie de diferentes paquetes de caché DNS disponibles, como dnsmasq. Aquí se indica cómo instalar
dnsmasq en las distribuciones más habituales:
Ubuntu (usa resolvconf ) :
Instale el paquete dnsmasq con sudo apt-get install dnsmasq .
SUSE (usa netconf ) :
Instale el paquete dnsmasq con sudo zypper install dnsmasq .
Habilite el servicio dnsmasq con systemctl enable [Link] .
 Inicie el servicio dnsmasq con systemctl start [Link] .
Edite /etc/sysconfig/network/config y cambie NETCONFIG_DNS_FORWARDER="" por dnsmasq.
Actualice [Link] con netconfig update para establecer la memoria caché como la resolución DNS
local.
CentOS (usa NetworkManager) :
Instale el paquete dnsmasq con sudo yum install dnsmasq .
Habilite el servicio dnsmasq con systemctl enable [Link] .
Inicie el servicio dnsmasq con systemctl start [Link] .
Agregue prepend domain-name-servers [Link]; a /etc/[Link] .
Reinicie el servicio de red con service network restart para establecer la memoria caché como la
resolución DNS local.

NOTE
El paquete dnsmasq constituye solo una de las muchas memorias cachés DNS disponibles para Linux. Antes de usarlo,
compruebe su idoneidad para sus necesidades concretas y que no esté instalada ninguna otra memoria caché.

Reintentos del cliente

DNS es principalmente un protocolo UDP. Como el protocolo UDP no garantiza la entrega de mensajes, la lógica
de reintento se controla en el mismo protocolo DNS. Cada cliente DNS (sistema operativo) puede presentar una
lógica de reintento diferente en función de la preferencia del creador:
Los sistemas operativos Windows realizan un reintento tras un segundo y después tras otros dos, cuatro y
otros cuatro segundos.
El programa de instalación predeterminado de Linux lo intenta después de cinco segundos. Se recomienda
cambiar las especificaciones de reintento a cinco veces, en intervalos de un segundo.
Compruebe la configuración actual en una VM de Linux con cat /etc/[Link] . Mire la línea options, por
ejemplo:

options timeout:1 attempts:5

El archivo [Link] suele generarse de forma automática y no se debe editar. Los pasos específicos para
agregar la línea options varían según la distribución:
Ubuntu (usa resolvconf):
1. Agregue la línea options a /etc/resolvconf/[Link].d/tail .
2. Ejecute resolvconf -u para actualizar.
SUSE (usa netconf):
1. Agregue timeout:1 attempts:5 al parámetro NETCONFIG_DNS_RESOLVER_OPTIONS="" en
/etc/sysconfig/network/config .
2. Ejecute netconfig update para actualizar.
CentOS (usa NetworkManager):
1. Agregue echo "options timeout:1 attempts:5" a /etc/NetworkManager/dispatcher.d/11-dhclient .
2. Actualice con service network restart .

Resolución de nombres con su propio servidor DNS

En esta sección se tratan las máquinas virtuales, las instancias de rol y las aplicaciones web.
Máquinas virtuales e instancias de rol
Puede que sus necesidades de resolución de nombres superen las posibilidades de las características de Azure.
Por ejemplo, es posible que necesite utilizar dominios de Microsoft Windows Server Active Directory y resolver
nombres DNS entre redes virtuales. Para abarcar estos escenarios, Azure le ofrece la posibilidad de que use sus
propios servidores DNS.
Los servidores DNS dentro de una red virtual pueden reenviar consultas DNS a las resoluciones recursivas en
Azure. Esto le permite resolver los nombres de host dentro de esa red virtual. Por ejemplo, un controlador de
dominio (DC) que se ejecute en Azure puede responder a las consultas DNS referidas a sus dominios y reenviar
todas las demás consultas a Azure. El reenvío de consultas permite que las máquinas virtuales vean sus recursos
locales (mediante el controlador de dominio) y los nombres de host proporcionados por Azure (mediante el
reenviador). El acceso a las resoluciones recursivas de Azure se proporciona mediante la IP virtual [Link].
El reenvío de DNS también habilita la resolución de DNS entre redes virtuales y permite que los equipos locales
resuelvan nombres de host proporcionados por Azure. Para resolver el nombre de host de una máquina virtual,
la máquina virtual del servidor DNS debe residir en la misma red virtual y debe configurarse para reenviar
consultas de nombre de host a Azure. Dado que el sufijo DNS es diferente en cada red virtual, puede usar las
reglas de desvío condicional para enviar consultas de DNS a la red virtual correcta para su resolución. En la
imagen siguiente se muestran dos redes virtuales y una red local que está realizando resolución DNS entre redes
virtuales con este método. Puede encontrar un reenviador DNS de ejemplo disponible en la galería de plantillas
de inicio rápido de Azure y en GitHub.

NOTE
Una instancia de rol puede realizar la resolución de nombres de máquinas virtuales dentro de la misma red virtual. Para
ello, use el FQDN, que consta del nombre de host de la máquina virtual y el sufijo DNS [Link] . Sin
embargo, en este caso, la resolución de nombres solo es correcta si la instancia de rol tiene el nombre de máquina virtual
definido en el esquema Role (archivo .cscfg). <Role name="<role-name>" vmName="<vm-name>">
Las instancias de rol que tienen que realizar la resolución de nombres de máquinas virtuales en otra red virtual (FQDN
utilizando el sufijo [Link] ) tienen que hacerlo con el método descrito en esta sección (reenvío de
servidores DNS personalizados entre las dos redes virtuales).
Cuando se utiliza la resolución de nombres proporcionada con Azure, el Protocolo dinámico de configuración de
host (DHCP) de Azure proporciona un sufijo DNS interno ( . [Link] ) a cada máquina virtual.
Este sufijo permite la resolución de nombres de host, dado que los registros de nombre de host están en la zona
[Link] . Si usa su propia solución de resolución de nombres, no se proporciona este sufijo a las
máquinas virtuales puesto que interfiere con otras arquitecturas DNS (como es el caso de los escenarios con
unión a un dominio). En su lugar, Azure proporciona un marcador de posición no funcional
([Link]).
Si es necesario, el sufijo DNS interno se puede determinar con PowerShell o la API:
En el caso de redes virtuales en modelos de implementación de Azure Resource Manager, el sufijo está
disponible con el recurso de la API REST de interfaz de red o del cmdlet Get-AzNetworkInterface de
PowerShell y del comando de la CLI de Azure az network nic show.
En los modelos de implementación clásica, el sufijo está disponible mediante la llamada a la API de Get
Deployment o por medio del cmdlet Get-AzureVM -Debug.
Si el reenvío de consultas a Azure no satisface sus necesidades, debería proporcionar su propia solución DNS. La
solución DNS debe:
Proporcionar la resolución adecuada de nombres de host, por ejemplo, mediante DDNS. Si usa DDNS, puede
que tenga que deshabilitar la limpieza de registros DNS. Las concesiones DHCP de Azure son muy largas y la
limpieza puede eliminar registros DNS de forma prematura.
Proporcionar la resolución recursiva adecuada para permitir la resolución de nombres de dominio externos.
Estar accesible (TCP y UDP en el puerto 53) desde los clientes a los que sirve y poder acceder a Internet.
Tener protección contra el acceso desde Internet para mitigar las amenazas que suponen los agentes externos.

NOTE
Para obtener el mejor rendimiento, cuando se usan máquinas virtuales de Azure como servidores DNS, debe deshabilitarse
IPv6.
Aplicaciones web
Supongamos que necesita realizar la resolución de nombres de una aplicación web integrada con App Service y
vinculada a una red virtual, a las máquinas virtuales en la misma red virtual. Además de configurar un servidor
DNS personalizado que tenga un reenviador DNS que reenvíe las consultas a Azure (dirección IP virtual
[Link]), realice los pasos siguientes:
1. Habilite la integración de red virtual de la aplicación web, si aún no lo ha hecho, tal y como se describe en
Integración de su aplicación con una instancia de Azure Virtual Network.
2. En Azure Portal, para el plan de App Service que hospeda la aplicación web, seleccione Sincronizar red
en Redes , Integración de Vir tual Network .

Si necesita ejecutar la resolución de nombres de la aplicación web integrada mediante App Service vinculada a
una red virtual, a las máquinas virtuales que se encuentran en una red virtual diferente, debe usar servidores
DNS personalizados en las dos redes virtuales, del modo siguiente:
Configure un servidor DNS en la red virtual de destino en una máquina virtual que también pueda reenviar
consultas a la resolución recursiva de Azure (dirección IP virtual [Link]). Puede encontrar un
reenviador DNS de ejemplo disponible en la galería de plantillas de inicio rápido de Azure y en GitHub.
Configure un reenviador DNS en la red virtual de origen en una máquina virtual. Configure este reenviador
DNS para que reenvíe consultas al servidor DNS de la red virtual de destino.
Configure el servidor DNS de origen en la configuración de su red virtual de origen.
Habilite la integración de red virtual para la aplicación web para vincular a la red virtual de origen, siguiendo
las instrucciones de Integración de su aplicación con una instancia de Azure Virtual Network.
En Azure Portal, para el plan de App Service que hospeda la aplicación web, seleccione Sincronizar red en
Redes , Integración de Vir tual Network .

Especificación de los servidores DNS

Si usa sus propios servidores DNS, Azure permite especificar varios servidores DNS por cada red virtual.
También puede especificar varios servidores DNS por interfaz de red (para Azure Resource Manager) o por
servicio en la nube (para el modelo de implementación clásica). Los servidores DNS especificados para una
interfaz de red o un servicio en la nube tienen prioridad sobre los servidores DNS especificados para la red
virtual.
 NOTE
Las propiedades de conexión de red, como las direcciones IP del servidor DNS, no deben editarse directamente dentro de
las máquinas virtuales. Esto se debe a que podrían borrarse durante el servicio de reparación cuando se reemplaza el
adaptador de la red virtual. Esto se aplica a las máquinas virtuales Windows y Linux.

Si se usa el modelo de implementación de Azure Resource Manager, puede especificar servidores DNS para una
red virtual y una interfaz de red. Para obtener más información, consulte Administración de una red virtual y
Administración de una interfaz de red.

NOTE
Si opta por el servidor DNS personalizado para la red virtual, debe especificar al menos una dirección IP de servidor DNS;
en caso contrario, la red virtual omitirá la configuración y usará en su lugar el DNS proporcionado por Azure.

Cuando se usa el modelo de implementación clásica, puede especificar servidores DNS para la red virtual en
Azure Portal o en el archivo de configuración de red. En el caso de los servicios en la nube, puede especificar los
servidores DNS mediante el archivo de configuración del servicio o mediante PowerShell, con New-AzureVM.

NOTE
Si cambia la configuración de DNS de una máquina o red virtual que ya está implementada, para que la nueva
configuración de DNS surta efecto, debe realizar una renovación de la concesión de DHCP en todas las máquinas virtuales
afectadas de la red virtual. En el caso de las máquinas virtuales que ejecutan el sistema operativo Windows, puede hacerlo
escribiendo ipconfig /renew directamente en la máquina virtual. Los pasos varían en función del sistema operativo.
Consulte la documentación correspondiente para su tipo de sistema operativo.

Pasos siguientes
Modelo de implementación de Azure Resource Manager:
Administración de una red virtual
Administración de una interfaz de red
Modelo de implementación clásico:
Esquema de configuración del servicio de Azure
Esquema de configuración de Virtual Network
Configuración de Virtual Network con un archivo de configuración de red
 Uso de DNS dinámico para registrar nombres de
host en su propio servidor DNS
23/09/2020 • 6 minutes to read • Edit Online

Azure ofrece resolución de nombres para las máquinas virtuales (VM) y las instancias de rol. Sin embargo, cuando
la resolución de nombres tiene que ir más allá de lo que el servicio DNS predeterminado de Azure ofrece, puede
proporcionar sus propios servidores DNS. El uso de sus propios servidores DNS le ofrece la capacidad de
personalizar su solución DNS para satisfacer sus propias necesidades específicas. Por ejemplo, puede que necesite
acceder a los recursos locales a través del controlador de dominio de Active Directory.
Si los servidores DNS personalizados se hospedan como máquinas virtuales de Azure, puede reenviar consultas
de nombre de host de la misma red virtual a Azure para resolver los nombres de host. Si no quiere usar esta
opción, puede registrar los nombres de host de las máquinas virtuales en el servidor DNS usando para ello DNS
dinámico (DDNS). Azure no tiene las credenciales para crear directamente los registros en los servidores DNS, por
lo que a menudo se necesitan medidas alternativas. Aquí presentamos algunos escenarios comunes con
alternativas:

Clientes Windows
Los clientes Windows no unidos a dominio intentan realizar actualizaciones de DDNS no seguras cuando arrancan
o cuando su dirección IP cambia. El nombre DNS es el nombre de host más el sufijo DNS primario. Azure deja en
blanco el sufijo DNS principal, pero puede establecerlo en la VM con la interfaz de usuario o mediante PowerShell.
Los clientes Windows unidos a dominio registran sus direcciones IP con el controlador de dominio mediante
DDNS seguro. El proceso de unión a dominio establece el sufijo DNS primario en el cliente y crea y mantiene la
relación de confianza.

Clientes Linux
Por lo general, los clientes Linux no se registran con el servidor DNS al iniciarse, dado que asumen que esto lo
hace el servidor DHCP. Los servidores DHCP de Azure no tienen las credenciales para realizar registros en el
servidor DNS. Puede usar una herramienta denominada nsupdate , que se incluye en el paquete Bind, para enviar
las actualizaciones de DDNS. Dado que el protocolo DDNS está estandarizado, puede usar nsupdate aunque no
use Bind en el servidor DNS.
Puede usar los enlaces que proporciona el cliente DHCP para crear y mantener la entrada del nombre de host en el
servidor DNS. Durante el ciclo de DHCP, el cliente ejecuta los scripts que aparecen en /etc/dhcp/dhclient-exit-
hooks.d/ . Puede usar los enlaces para registrar la nueva dirección IP mediante nsupdate . Por ejemplo:
 #!/bin/sh
requireddomain=[Link]

# only execute on the primary nic

if [ "$interface" != "eth0" ]
then
return
fi

# When you have a new IP, perform nsupdate

if [ "$reason" = BOUND ] || [ "$reason" = RENEW ] ||
[ "$reason" = REBIND ] || [ "$reason" = REBOOT ]
then
host=`hostname`
nsupdatecmds=/var/tmp/nsupdatecmds
echo "update delete $host.$requireddomain a" > $nsupdatecmds
echo "update add $host.$requireddomain 3600 a $new_ip_address" >> $nsupdatecmds
echo "send" >> $nsupdatecmds

nsupdate $nsupdatecmds
fi

También puede usar el comando nsupdate para realizar actualizaciones de DDNS seguras. Por ejemplo, cuando
usa un servidor Bind DNS, se genera un par de claves pública-privada ( [Link] ). El servidor
DNS está configurado ( [Link] ) con la parte pública de la clave, de manera que
se puede comprobar la firma en la solicitud. Para proporcionar el par de claves para nsupdate , use la opción -k .
El objetivo es la firma de la solicitud de actualización DDNS.
Si usa un servidor DNS de Windows, puede usar la autenticación Kerberos con el parámetro -g en nsupdate ,
pero no está disponible en la versión de nsupdate para Windows. Para usar Kerberos, utilice kinit para cargar las
credenciales. Por ejemplo, puede cargar las credenciales de un archivo keytab y nsupdate -g extraer las
credenciales de la memoria caché.
En caso de ser necesario, puede agregar un sufijo de búsqueda DNS a las máquinas virtuales. El sufijo DNS se
especifica en el archivo /etc/[Link] . La mayoría de las distribuciones de Linux administran automáticamente el
contenido de este archivo, por lo que normalmente no se puede editar. Sin embargo, puede reemplazar el sufijo
mediante el comando supersede del cliente DHCP. Para invalidar el sufijo, agregue la línea siguiente al archivo
/etc/dhcp/[Link]:

supersede domain-name <required-dns-suffix>;

 Optimización del rendimiento de red en las máquinas
virtuales de Azure
23/09/2020 • 7 minutes to read • Edit Online

Las máquinas virtuales de Azure (VM) tienen una configuración de red predeterminada que se puede optimizar
para mejorar aún más el rendimiento de la red. En este artículo se describe cómo optimizar el rendimiento de la
red de las máquinas virtuales Windows y Linux de Microsoft Azure, incluidas las distribuciones principales como
Ubuntu, CentOS y Red Hat.

Máquina virtual de Windows

Si la máquina virtual Windows es compatible con redes aceleradas, habilite esta característica para conseguir un
rendimiento óptimo. En el caso de otras máquinas virtuales Windows, el uso de escalado en el lado de la recepción
(RSS) pueden logar un rendimiento máximo mayor que las que no lo usan. En las máquinas virtuales Windows,
RSS se puede deshabilitar de forma predeterminada. Para determinar si RSS está habilitado y para habilitarlo si no
lo está en la actualidad, complete los siguientes pasos:
1. Compruebe si RSS está habilitado para un adaptador de red con el comando Get-NetAdapterRss de
PowerShell. En la siguiente salida de ejemplo que devuelve Get-NetAdapterRss , RSS no está habilitado.

Name : Ethernet
InterfaceDescription : Microsoft Hyper-V Network Adapter
Enabled : False

2. Para habilitar RSS escriba el siguiente comando:

Get-NetAdapter | % {Enable-NetAdapterRss -Name $_.Name}

El comando anterior no tiene ninguna salida. El comando cambió la configuración de NIC, lo que ha
provocado una pérdida temporal de la conectividad durante aproximadamente un minuto. Durante la
pérdida de conectividad aparece un cuadro de diálogo de reconexión. La conectividad se suele restaurar al
tercer intento.
3. Confirme que RSS está habilitado en la máquina virtual, para lo que debe volver a escribir el comando
Get-NetAdapterRss . Si se realiza correctamente, se devuelve la siguiente salida de ejemplo:

Name : Ethernet
InterfaceDescription : Microsoft Hyper-V Network Adapter
Enabled : True

Máquina virtual de Linux

De manera predeterminada, en las máquinas virtuales Linux de Azure RSS está siempre habilitado. Los kernels de
Linux lanzados desde octubre de 2017 incluyen nuevas opciones de optimización de red que permiten que las
máquinas virtuales Linux logren un mayor rendimiento de la red.
Ubuntu para las nuevas implementaciones
El kernel de Azure de Ubuntu proporciona el mejor rendimiento de la red en Azure y ha sido el kernel
predeterminado desde el 21 de septiembre de 2017. Para obtener este kernel, primero instale la última versión
compatible de 16.04-LTS, como se describe a continuación:

"Publisher": "Canonical",
"Offer": "UbuntuServer",
"Sku": "16.04-LTS",
"Version": "latest"

Una vez que la creación finaliza, escriba los siguientes comandos para obtener el actualizaciones más recientes.
Estos pasos también funcionan en las máquinas virtuales que ejecutan actualmente el kernel de Azure de Ubuntu.

#run as root or preface with sudo

apt-get -y update
apt-get -y upgrade
apt-get -y dist-upgrade

El siguiente conjunto de comandos opcional puede ser útil para las implementaciones de Ubuntu existentes que ya
tiene el kernel de Azure, pero que no han podido realizar actualizaciones debido a errores.

#optional steps may be helpful in existing deployments with the Azure kernel
#run as root or preface with sudo
apt-get -f install
apt-get --fix-missing install
apt-get clean
apt-get -y update
apt-get -y upgrade
apt-get -y dist-upgrade

Actualización del kernel de Azure de Ubuntu para las máquinas virtuales existentes
Se puede lograr un rendimiento significativo instalando el kernel de Linux de Azure propuesto. Para comprobar si
tienen este kernel, compruebe la versión del kernel.

#Azure kernel name ends with "-azure"

uname -r

#sample output on Azure kernel:

#4.13.0-1007-azure

Si la máquina virtual no tiene el kernel de Azure, el número de versión comenzará normalmente con "4.4." Si la
máquina virtual no tiene el kernel de Azure, ejecute los comandos siguientes como raíz:

#run as root or preface with sudo

apt-get update
apt-get upgrade -y
apt-get dist-upgrade -y
apt-get install "linux-azure"
reboot

CentOS
Para obtener las optimizaciones más recientes, se recomienda crear una máquina virtual con la versión más
reciente compatible mediante la especificación de los siguientes parámetros:
 "Publisher": "OpenLogic",
"Offer": "CentOS",
"Sku": "7.4",
"Version": "latest"

Tanto las máquinas virtuales nuevas como las existentes se pueden beneficiar de la versión más reciente de Linux
Integration Services (LIS). La optimización del rendimiento es en LIS, a partir de 4.2.2-2, aunque las versiones
posteriores contienen más mejoras. Escriba los siguientes comandos para instalar el LIS más reciente:

sudo yum update

sudo reboot
sudo yum install microsoft-hyper-v

Red Hat
Para obtener las optimizaciones, se recomienda crear una máquina virtual con la versión más reciente compatible
mediante la especificación de los siguientes parámetros:

"Publisher": "RedHat"
"Offer": "RHEL"
"Sku": "7-RAW"
"Version": "latest"

Tanto las máquinas virtuales nuevas como las existentes se pueden beneficiar de la versión más reciente de Linux
Integration Services (LIS). La optimización del rendimiento se realiza en LIS a partir de la versión 4.2. Escriba los
siguientes comandos para descargar e instalar LIS:

wget [Link]
tar xvf lis
cd LISISO
sudo ./[Link] #or [Link] if prior LIS was previously installed

Para más información sobre la versión 4.2 de Linux Integration Services para Hyper-V, vea la página de descarga.

Pasos siguientes
Vea el resultado con las pruebas de ancho de banda y rendimiento de Azure VM para su escenario.
Obtenga información acerca de cómo se asigna el ancho de banda a las máquinas virtuales
Obtenga más información con las Preguntas más frecuentes (P+F) acerca de Azure Virtual Network
 Ver y modificar los nombres de host
23/09/2020 • 5 minutes to read • Edit Online

Para permitir que el nombre de host haga referencia a las instancias de rol, debe establecer el valor del nombre de
host en el archivo de configuración de servicio de cada rol. Para hacer esto, agregue el nombre de host que quiera
al atributo vmName del elemento Rol . El valor del atributo vmName se usa como base para el nombre de host de
cada instancia de rol. Por ejemplo, si el atributo vmName es webrole y hay tres instancias de ese rol, los nombres
de host de las instancias serán webrole0, webrole1 y webrole2. No es necesario especificar un nombre de host para
máquinas virtuales en el archivo de configuración, porque el nombre de host de una máquina virtual se rellena
según el nombre de esa máquina virtual. Para obtener más información sobre cómo configurar un servicio de
Microsoft Azure, consulte Esquema de configuración del servicio de Azure (archivo de .cscfg)

Ver nombres de host

Puede ver los nombres de host de máquinas virtuales e instancias de rol en un servicio en la nube mediante
cualquiera de las herramientas siguientes.
Archivo de configuración de servicio
Puede descargar en el Portal de Azure el archivo de configuración de servicio de un servicio implementado desde
la hoja Configurar del servicio. Después, puede buscar el atributo vmName del elemento Nombre de rol para
ver el nombre de host. Tenga en cuenta que ese nombre de host se usa como base para cada nombre de host de
cada instancia de rol. Por ejemplo, si el atributo vmName es webrole y hay tres instancias de ese rol, los nombres
de host de las instancias serán webrole0, webrole1 y webrole2.
Escritorio remoto
Una vez haya habilitado el Escritorio remoto (Windows), la comunicación remota de Windows PowerShell
(Windows) o las conexiones SSH (Linux y Windows) en las máquinas virtuales o instancias de rol, podrá ver el
nombre de host de una conexión del Escritorio remoto activa de varias maneras:
Escriba el nombre de host en el símbolo del sistema o en un terminal SSH.
Escriba ipconfig/all en el símbolo del sistema (sólo Windows).
Consulte el nombre del equipo en la configuración del sistema (sólo Windows).
API de REST de Administración de servicios de Azure
Desde un cliente REST, siga estas instrucciones:
1. Asegúrese de que tiene un certificado de cliente para conectarse al Portal de Azure. Para obtener un certificado
de cliente, siga los pasos que aparecen en el artículo sobre cómo descargar e importar la configuración de
publicación y la información de suscripción.
2. Establezca una entrada de encabezado denominada x-ms-version con un valor de 2013-11-01.
3. Envíe una solicitud con el siguiente formato: [Link]
id>/services/hostedservices/<service-name>?embed-detail=true
4. Busque el elemento HostName de cada elemento RoleInstance .

WARNING
Asimismo, puede ver el sufijo de dominio interno del servicio en la nube desde la respuesta a la llamada REST comprobando
el elemento InternalDnsSuffix o ejecutando ipconfig /all desde un símbolo del sistema en una sesión de Escritorio remoto
(Windows) o cat /etc/[Link] desde un terminal SSH (Linux).
Modificar un nombre de host
Puede modificar el nombre de host de cualquier máquina virtual o instancia de rol al cargar un archivo de
configuración de servicio modificado o al cambiar el nombre del equipo desde una sesión de Escritorio remoto.

Pasos siguientes
resolución de nombres DNS
Esquema de configuración del servicio de Azure (.cscfg)
Esquema de configuración de Azure Virtual Network
Especificación de la configuración de DNS usando los archivos de configuración de red
 Registro de recursos de un grupo de seguridad de
red
23/09/2020 • 16 minutes to read • Edit Online

Los grupos de seguridad de red (NSG) incluyen reglas que permiten o deniegan el tráfico a una subred de red
virtual, a una interfaz de red, o a ambas.
Al habilitar el registro para un grupo de seguridad de red, puede recopilar los siguientes tipos de información del
registro de recursos:
Evento: se registran las entradas en las que se aplican reglas de NSG a máquinas virtuales en función de la
dirección MAC.
Contador de regla: contiene entradas para el número de veces que se aplica cada regla NSG para denegar o
permitir el tráfico. El estado de estas reglas se recopila cada 300 segundos.
Los registros de diagnóstico solo están disponibles para los grupos de seguridad de red implementados con el
modelo de implementación de Azure Resource Manager. No se puede habilitar el registro de diagnóstico para los
grupos de seguridad de red implementados con el modelo de implementación clásica. Para entender mejor los dos
modelos, consulte Descripción de los modelos de implementación de Azure.
El registro de recursos se habilita por separado para cada grupo de seguridad de red para el que desee recopilar
datos. Si lo que le interesan son los registros de actividades (operaciones), consulte el registro de actividades de
Azure.

Habilitación del registro

Para habilitar el registro de recursos se pueden usar Azure Portal, PowerShell o la CLI de Azure.
Azure Portal
1. Inicie sesión en el portal.
2. Seleccione Todos los ser vicios y escriba grupos de seguridad de red. Cuando aparezca Grupos de
seguridad de red en los resultados de la búsqueda, selecciónelo.
3. Seleccione el NSG para el que desea habilitar el registro.
4. En SUPERVISIÓN , seleccione Registros de diagnósticos y, después, seleccione Turn on diagnostics
(Activar diagnóstico), como se muestra en la siguiente imagen:
5. En Configuración de diagnóstico , especifique o seleccione los siguientes datos y, después, seleccione
Guardar :

C O N F IGURA C IÓ N VA L UE

Nombre El nombre que prefiera. Por ejemplo: myNsgDiagnostics

Archivar en una cuenta de almacenamiento , Puede seleccionar tantos destinos como quiera. Para más
Transmitir en secuencias a un centro de eventos y información acerca de cada uno de ellos, consulte Destinos
Enviar a Log Analytics de registro.

REGISTRO Seleccione una de las categorías de registro, o incluso

ambas. Para más información acerca de los datos que se
registran en cada categoría, consulte Categorías de
registro.

6. Vea y analice los registros. Para más información, consulte Visualización y análisis de los registros.
PowerShell

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Puede ejecutar los comandos siguientes en Azure Cloud Shell, o mediante la ejecución de PowerShell en el equipo.
Azure Cloud Shell es un shell interactivo gratuito. Tiene las herramientas comunes de Azure preinstaladas y
configuradas para usarlas en la cuenta. Si ejecuta PowerShell desde el equipo, necesita el módulo Azure PowerShell
versión 1.0.0 o posterior. Ejecute Get-Module -ListAvailable Az en el equipo para encontrar la versión instalada. Si
necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si ejecuta PowerShell localmente,
también debe ejecutar Connect-AzAccount para iniciar sesión en Azure con una cuenta que tenga los permisos
necesarios.
Para habilitar el registro de recursos, se necesita el identificador de un grupo de seguridad de red existente. Si no
tiene ninguno, puede crearlo con New-AzNetworkSecurityGroup.
Recupere el grupo de seguridad de red para el que desea habilitar el registro de recursos con Get-
AzNetworkSecurityGroup. Por ejemplo, para recuperar un grupo de seguridad de red denominado myNsg que
existe en un grupo de recursos denominado myResourceGroup, escriba el siguiente comando:

$Nsg=Get-AzNetworkSecurityGroup `
-Name myNsg `
-ResourceGroupName myResourceGroup

Puede escribir registros de recursos para tres tipos de destino. Para más información, consulte Destinos del
registro. En este artículo, los registros se envían al destino Log Analytics, pero no es más que un ejemplo. Recupere
un área de trabajo de Log Analytics existente con Get-AzOperationalInsightsWorkspace. Por ejemplo, para
recuperar un área de trabajo denominado myWorkspace en un grupo de recursos denominado myWorkspaces,
escriba el siguiente comando:
 $Oms=Get-AzOperationalInsightsWorkspace `
-ResourceGroupName myWorkspaces `
-Name myWorkspace

Si no tiene un área de trabajo, puede crearla con New-AzOperationalInsightsWorkspace.

Existen dos categorías de registro para las que se pueden habilitar registros. Para más información, consulte
Categorías de registro. Habilite el registro de recursos para el grupo de seguridad de red con Set-
AzDiagnosticSetting. En el ejemplo siguiente se registran en el área de trabajo de un grupo de seguridad de red los
datos de la categoría tanto del evento como del contador, para lo que se usan los identificadores del grupo de
seguridad de red como del área de trabajo que recuperó antes:

Set-AzDiagnosticSetting `
-ResourceId $[Link] `
-WorkspaceId $[Link] `
-Enabled $true

Si solo desea registrar los datos en una de las dos categorías, en lugar de en ambas, agregue la opción
-Categories al comando anterior, seguida de NetworkSecurityGroupEvent o NetworkSecurityGroupRuleCounter .
Si desea realizar el registro en un destino que no sea un área de trabajo de Log Analytics, utilice los parámetros
adecuados para una cuenta de almacenamiento o un centro de eventos de Azure.
Vea y analice los registros. Para más información, consulte Visualización y análisis de los registros.
Azure CLI
Puede ejecutar los comandos siguientes en Azure Cloud Shell, o mediante la ejecución de la CLI de Azure en el
equipo. Azure Cloud Shell es un shell interactivo gratuito. Tiene las herramientas comunes de Azure preinstaladas y
configuradas para usarlas en la cuenta. Si ejecuta la CLI desde el equipo, necesita la versión 2.0.38 o posterior.
Ejecute az --version en el equipo para encontrar la versión instalada. Si debe actualizarla, consulte Instalación de
la CLI de Azure. Si ejecuta la CLI localmente, también debe ejecutar az login para iniciar sesión en Azure con una
cuenta que tenga los permisos necesarios.
Para habilitar el registro de recursos se necesita el identificador de un grupo de seguridad de red existente. Si no
tiene ninguno, puede crear uno con az network nsg create.
Recupere el grupo de seguridad de red para el que desea habilitar el registro de recursos con az network nsg show.
Por ejemplo, para recuperar un grupo de seguridad de red denominado myNsg que existe en un grupo de recursos
denominado myResourceGroup, escriba el siguiente comando:

nsgId=$(az network nsg show \

--name myNsg \
--resource-group myResourceGroup \
--query id \
--output tsv)

Puede escribir registros de recursos para tres tipos de destino. Para más información, consulte Destinos del
registro. En este artículo, los registros se envían al destino Log Analytics, pero no es más que un ejemplo. Para más
información, consulte Categorías de registro.
Habilite el registro de recursos para el grupo de seguridad de red con az monitor diagnostic-settings create. En el
ejemplo siguiente se registran los datos de categoría de eventos y de contadores en un área de trabajo
denominada myWorkspace, que se encuentra en un grupo de recursos denominado myWorkspaces, y el
identificador del grupo de seguridad de red que recuperó anteriormente:
 az monitor diagnostic-settings create \
--name myNsgDiagnostics \
--resource $nsgId \
--logs '[ { "category": "NetworkSecurityGroupEvent", "enabled": true, "retentionPolicy": { "days": 30,
"enabled": true } }, { "category": "NetworkSecurityGroupRuleCounter", "enabled": true, "retentionPolicy": {
"days": 30, "enabled": true } } ]' \
--workspace myWorkspace \
--resource-group myWorkspaces

Si no tiene ningún área de trabajo existente, puede crear una mediante Azure Portal o PowerShell. Existen dos
categorías de registro para las que se pueden habilitar registros.
Si solo desea registrar los datos de una categoría o la otra, quite la categoría para la que no desea registrar los
datos en el comando anterior. Si desea realizar el registro en un destino que no sea un área de trabajo de Log
Analytics, utilice los parámetros adecuados para una cuenta de almacenamiento o un centro de eventos de Azure.
Vea y analice los registros. Para más información, consulte Visualización y análisis de los registros.

Destinos de registro
Los datos de diagnóstico se pueden:
Escribir en una cuenta de Azure Storage, para auditarlos o para comprobarlos manualmente. El tiempo de
retención (en días) se puede especificar en la configuración del diagnóstico de recursos.
Transmitir en secuencias a un centro de eventos para que los ingiera un servicio de terceros o una solución de
análisis personalizada, como PowerBI.
Escritura en los registros de Azure Monitor.

Categorías de registro
Se escriben datos con formato JSON para las siguientes categorías de registro:
Evento
El registro de eventos contiene información acerca de las reglas de NSG que se aplican a las máquinas virtuales en
función de su dirección MAC. Los siguientes datos se registran para cada evento. En el ejemplo siguiente, los datos
se registran para una máquina virtual con la dirección IP [Link] y una dirección MAC de 00-0D-3A-92-6A-7C:
 {
"time": "[DATE-TIME]",
"systemId": "[ID]",
"category": "NetworkSecurityGroupEvent",
"resourceId": "/SUBSCRIPTIONS/[SUBSCRIPTION-ID]/RESOURCEGROUPS/[RESOURCE-GROUP-
NAME]/PROVIDERS/[Link]/NETWORKSECURITYGROUPS/[NSG-NAME]",
"operationName": "NetworkSecurityGroupEvents",
"properties": {
"vnetResourceGuid":"[ID]",
"subnetPrefix":"[Link]/24",
"macAddress":"00-0D-3A-92-6A-7C",
"primaryIPv4Address":"[Link]",
"ruleName":"[SECURITY-RULE-NAME]",
"direction":"[DIRECTION-SPECIFIED-IN-RULE]",
"priority":"[PRIORITY-SPECIFIED-IN-RULE]",
"type":"[ALLOW-OR-DENY-AS-SPECIFIED-IN-RULE]",
"conditions":{
"protocols":"[PROTOCOLS-SPECIFIED-IN-RULE]",
"destinationPortRange":"[PORT-RANGE-SPECIFIED-IN-RULE]",
"sourcePortRange":"[PORT-RANGE-SPECIFIED-IN-RULE]",
"sourceIP":"[SOURCE-IP-OR-RANGE-SPECIFIED-IN-RULE]",
"destinationIP":"[DESTINATION-IP-OR-RANGE-SPECIFIED-IN-RULE]"
}
}
}

Contador de reglas
El contador de reglas contiene información acerca de todas las reglas que se aplican a los recursos. Los datos de
ejemplo siguientes se registran cada vez que se aplica una regla. En el ejemplo siguiente, los datos se registran
para una máquina virtual con la dirección IP [Link] y una dirección MAC de 00-0D-3A-92-6A-7C:

{
"time": "[DATE-TIME]",
"systemId": "[ID]",
"category": "NetworkSecurityGroupRuleCounter",
"resourceId": "/SUBSCRIPTIONS/[SUBSCRIPTION ID]/RESOURCEGROUPS/[RESOURCE-GROUP-
NAME]/PROVIDERS/[Link]/NETWORKSECURITYGROUPS/[NSG-NAME]",
"operationName": "NetworkSecurityGroupCounters",
"properties": {
"vnetResourceGuid":"[ID]",
"subnetPrefix":"[Link]/24",
"macAddress":"00-0D-3A-92-6A-7C",
"primaryIPv4Address":"[Link]",
"ruleName":"[SECURITY-RULE-NAME]",
"direction":"[DIRECTION-SPECIFIED-IN-RULE]",
"type":"[ALLOW-OR-DENY-AS-SPECIFIED-IN-RULE]",
"matchedConnections":125
}
}

NOTE
La dirección IP de origen de la comunicación no se ha registrado. Sin embargo, puede habilitar el registro de flujo de NSG
para un NSG, lo que registra toda la información del contador de reglas, así como la dirección IP de origen que inició la
comunicación. Los datos del registro de flujos de NSG se escriben en una cuenta de Azure Storage. Puede analizar los datos
con la funcionalidad de análisis del tráfico Azure Network Watcher.

Visualización y análisis de los registros

Para aprender a ver los datos del registro de recursos, consulte Introducción a los registros de plataforma Azure. Si
envía datos de diagnóstico a:
Registros de Azure Monitor : puede usar la solución de análisis de grupos de seguridad de red para obtener
una información más detallada. La solución ofrece visualizaciones para de las reglas de NSG que permiten o
deniegan el tráfico, por dirección MAC, de la interfaz de red de una máquina virtual.
Cuenta de Azure Storage : los datos se escriben en el archivo [Link]. Puede encontrar el:
Registro de eventos en la siguiente ruta de acceso:
insights-logs-networksecuritygroupevent/resourceId=/SUBSCRIPTIONS/[ID]/RESOURCEGROUPS/[RESOURCE-GROUP-
NAME-FOR-NSG]/PROVIDERS/[Link]/NETWORKSECURITYGROUPS/[NSG NAME]/y=[YEAR]/m=[MONTH/d=
[DAY]/h=[HOUR]/m=[MINUTE]
Registro del contador de reglas en la siguiente ruta de acceso:
insights-logs-networksecuritygrouprulecounter/resourceId=/SUBSCRIPTIONS/[ID]/RESOURCEGROUPS/[RESOURCE-
GROUP-NAME-FOR-NSG]/PROVIDERS/[Link]/NETWORKSECURITYGROUPS/[NSG NAME]/y=[YEAR]/m=[MONTH/d=
[DAY]/h=[HOUR]/m=[MINUTE]

Pasos siguientes
Más información sobre el registro de actividad. El registro de actividades está habilitado de forma
predeterminada para los grupo de seguridad de red creados a través de cualquier modelo de implementación
de Azure. Para determinar qué operaciones se completaron en los NSG del registro de actividad, busque las
entradas que contengan los siguientes tipos de recursos:
[Link]/networkSecurityGroups
[Link]/networkSecurityGroups/securityRules
[Link]/networkSecurityGroups
[Link]/networkSecurityGroups/securityRules
Para aprender a registrar información de diagnóstico e incluir la dirección IP de origen para cada flujo, consulte
Registro de flujos de NSG.
 Tutorial: Enrutamiento del tráfico de red con una
tabla de rutas mediante Azure Portal
23/09/2020 • 20 minutes to read • Edit Online

De forma predeterminada, Azure enruta el tráfico entre todas las subredes de una red virtual. Sin embargo,
puede crear sus propias rutas para invalidar las predeterminadas de Azure. Las rutas personalizadas resultan de
utilidad si, por ejemplo, quiere enrutar el tráfico entre subredes por medio de una aplicación virtual de red (NVA).
En este tutorial, aprenderá a:
Creación de una aplicación virtual de red para enrutar el tráfico
Creación de una tabla de rutas
Creación de una ruta
Asociación de una tabla de rutas a una subred
Implementación de máquinas virtuales (VM) en subredes diferentes
Enrutamiento del tráfico desde una subred a otra a través de una aplicación virtual de red
Este tutorial usa Azure Portal. También puede usar la CLI de Azure o Azure PowerShell.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Creación de una aplicación virtual de red

Las aplicaciones virtuales de red (NVA) son máquinas virtuales que ayudan con las funciones de red, como la
optimización del enrutamiento y del firewall. En este tutorial se supone que está utilizando Windows Ser ver
2016 Datacenter . Si lo desea puede seleccionar un sistema operativo diferente.
1. En el menú Azure Portal o en la página Inicio , seleccione Crear un recurso .
2. Elija Seguridad > Windows Ser ver 2016 Datacenter .
3. En la página Creación de una máquina vir tual , en Conceptos básicos , escriba o seleccione esta
información:

SEC C IÓ N C O N F IGURA C IÓ N A C C IÓ N

Detalles del proyecto Suscripción Elija su suscripción.

Resource group Seleccione Crear nuevo , escriba

myResourceGroup y seleccione
Aceptar .

Detalles de instancia Nombre de la máquina virtual Escriba myVmNva.

Region Elija (EE. UU.) Este de EE. UU. .

Opciones de disponibilidad Elija No se requiere redundancia

de la infraestructura .

Imagen Elija Windows Ser ver 2016

Datacenter .

Size Deje el valor predeterminado

Estándar DS1 v2 .
SEC C IÓ N C O N F IGURA C IÓ N A C C IÓ N

Cuenta de administrador Nombre de usuario Escriba un nombre de usuario de su

elección.

Contraseña Introduzca una contraseña de su

elección, que debe tener al menos
12 caracteres y cumplir con los
requisitos de complejidad definidos.

Confirm Password Vuelva a escribir la contraseña.

Reglas de puer to de entrada Puertos de entrada públicos Elija Ninguno .

Ahorrar dinero ¿Ya tiene una licencia de Elija No .

Windows Server?
 Después, seleccione Siguiente: Discos > .
4. En Discos , seleccione la configuración adecuada para sus necesidades y, después, seleccione Siguiente:
Redes > .
5. En Redes :
a. En Red vir tual , seleccione Crear nuevo .
b. En el cuadro de diálogo Crear red vir tual , en Nombre , introduzca myVirtualNetwork.
c. En Espacio de direcciones , reemplace el intervalo de direcciones existente por [Link]/16.
d. En Subredes , seleccione el icono Eliminar para eliminar la subred existente y, a continuación,
especifique las siguientes combinaciones de nombre de subred e inter valo de direcciones .
Cuando se especifica un nombre y un intervalo válidos, aparece una nueva fila vacía debajo de él.
 N O M B RE DE SUB RED IN T ERVA LO DE DIREC C IO N ES

Pública [Link]/24

Privada [Link]/24

DMZ [Link]/24

e. Seleccione Aceptar para salir del cuadro de diálogo.

f. En Subred , seleccione DMZ ([Link]/24) .
g. En IP pública , elija Ninguno , ya que esta máquina virtual no se conectará a través de Internet.
h. Seleccione Siguiente: Administración > .
6. En Administración :
a. En Cuenta de almacenamiento de diagnóstico , seleccione Crear nuevo .
b. En el cuadro de diálogo Crear cuenta de almacenamiento , escriba o seleccione esta
información:

C O N F IGURA C IÓ N VA L UE

Nombre mynvastorageaccount

Tipo de cuenta Storage (de uso general v1)

Rendimiento Estándar

Replicación Almacenamiento con redundancia local (LRS).

c. Seleccione Aceptar para salir del cuadro de diálogo.

d. Seleccione Revisar + crear . Se le remite a la página Revisar y crear y Azure valida la
configuración.
7. Cuando reciba el mensaje Validación superada , seleccione Crear .
La máquina virtual tarda en crearse unos minutos. Espere hasta que Azure termine de crear la máquina
virtual. La página La implementación está en curso le mostrará los detalles de la implementación.
8. Cuando la máquina virtual esté lista, seleccione Ir al recurso .

Creación de una tabla de rutas

1. En el menú Azure Portal o en la página Inicio , seleccione Crear un recurso .
2. En el cuadro de búsqueda, escriba Tabla de enrutamiento. Cuando Tabla de enrutamiento aparezca en
los resultados de la búsqueda, selecciónelo.
3. En la página Tabla de enrutamiento , seleccione Crear .
4. En Crear tabla de rutas , escriba o seleccione esta información:
 C O N F IGURA C IÓ N VA L UE

Nombre myRouteTablePublic

Suscripción Su suscripción

Resource group myResourceGroup

Location (EE. UU.) Este de EE. UU.

Propagación de rutas de puerta de enlace de red virtual Enabled

5. Seleccione Crear .

Creación de una ruta

1. Vaya a Azure Portal para administrar la tabla de rutas. Busque y seleccione Tablas de rutas .
2. Seleccione el nombre de la tabla de rutas (myRouteTablePublic ).
3. Elija Rutas > Agregar .
4. En Agregar ruta , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Nombre de ruta ToPrivateSubnet

Prefijo de dirección [Link]/24 (el intervalo de direcciones de la subred

Privada creada anteriormente)

Tipo de próximo salto Aplicación vir tual

Siguiente dirección de salto [Link] (una dirección dentro del intervalo de direcciones
de la subred perimetral)

5. Seleccione Aceptar .

Asociación de una tabla de rutas a una subred

1. Vaya a Azure Portal para administrar la red virtual. Busque y seleccione Redes vir tuales .
2. Elija el nombre de la red virtual (myVir tualNetwork ).
3. En la barra de menús de la red virtual, elija Subredes .
4. En la lista de subredes de la red virtual, elija Público .
5. En Tabla de rutas , elija la tabla de rutas que creó (myRouteTablePublic ) y, a continuación, seleccione
Guardar para asociar la tabla de rutas a la subred Pública.

Habilitación del reenvío IP

A continuación, active el reenvío IP para la nueva máquina virtual NVA, myVmNva. Cuando Azure envía tráfico de
red a myVmNva, si el tráfico se destina a una dirección IP diferente, el reenvío IP envía el tráfico a la ubicación
correcta.
1. Vaya a Azure Portal para administrar la máquina virtual. Busque y seleccione Máquinas vir tuales .
2. Elija el nombre de la máquina virtual (myVmNva ).
3. En la barra de menús de la máquina virtual NVA, seleccione Redes .
4. Seleccione myvmnva123 . Esta es la interfaz de red que Azure creó para la máquina virtual. Azure agrega
números para asegurar un nombre único.
5. En la barra de menús de la interfaz de red, seleccione Configuraciones de IP .
6. En la página Configuraciones de IP , establezca Reenvío IP en Habilitado y seleccione Guardar .
Creación de máquinas virtuales públicas y privadas
Cree una máquina virtual pública y una máquina virtual privada en la red virtual. Más adelante, las usará para ver
que Azure enruta el tráfico de subred Público a la subred Privada mediante la aplicación virtual de red.
Para crear la máquina virtual pública y la máquina virtual privada, siga los pasos de Creación de una aplicación
virtual de red anteriormente. No es necesario esperar a que finalice la implementación o ir al recurso de la
máquina virtual. Usará la mayoría de los valores, excepto como se describe a continuación.
Antes de seleccionar Crear para crear la máquina virtual pública o privada, vaya a las dos subsecciones
siguientes (Máquina virtual pública y Máquina virtual privada), que muestran los valores que deben ser
diferentes. Puede continuar con la siguiente sección (Enrutamiento del tráfico desde una subred a otra a través de
una aplicación virtual de red) después de que Azure termine de implementar ambas máquinas virtuales.
Máquina virtual pública
P ESTA Ñ A C O N F IGURA C IÓ N VA L UE

Aspectos básicos Resource group myResourceGroup

Nombre de la máquina virtual myVmPublic

Puertos de entrada públicos Permitir los puer tos seleccionados

Selección de puertos de entrada RDP

Redes Virtual network myVir tualNetwork

Subnet Público ([Link]/24)

Dirección IP pública El valor predeterminado

 P ESTA Ñ A C O N F IGURA C IÓ N VA L UE

Administración Cuenta de almacenamiento de mynvastorageaccount

diagnóstico

Máquina virtual privada

P ESTA Ñ A C O N F IGURA C IÓ N VA L UE

Aspectos básicos Resource group myResourceGroup

Nombre de la máquina virtual myVmPrivate

Puertos de entrada públicos Permitir los puer tos seleccionados

Selección de puertos de entrada RDP

Redes Virtual network myVir tualNetwork

Subnet Privado ([Link]/24)

Dirección IP pública El valor predeterminado

Administración Cuenta de almacenamiento de mynvastorageaccount

diagnóstico

Enrutamiento del tráfico a través de una aplicación virtual de red

Inicio de sesión en myVmPrivate a través de Escritorio remoto
1. Vaya a Azure Portal para administrar la máquina virtual privada. Busque y seleccione Máquinas
vir tuales .
2. Seleccione el nombre de la máquina virtual privada (myVmPrivate ).
3. En la barra de menú de la máquina virtual, seleccione Conectar para crear una conexión al Escritorio
remoto para la máquina virtual privada.
4. En la página Conectar con RDP , seleccione Descargar archivo RDP . Azure crea un archivo de
Protocolo de Escritorio remoto ( .rdp) y lo descarga en su equipo.
5. Abra el archivo .rdp descargado. Cuando se le pida, seleccione Conectar . Seleccione Más opciones >
Usar otra cuenta y, después, escriba el nombre de usuario y la contraseña que especificó al crear la
máquina virtual privada.
6. Seleccione Aceptar .
7. Si recibe una advertencia de certificado durante el proceso de inicio de sesión, seleccione Sí para conectar
la máquina virtual.
Habilite ICMP mediante el firewall de Windows
En un paso posterior, usará la herramienta trace route para probar el enrutamiento. Trace route usa el Protocolo
de mensajes de control de Internet (ICMP), que el Firewall de Windows deniega de manera predeterminada.
Habilite ICMP a través del Firewall de Windows.
1. En el escritorio remoto de myVmPrivate, abra PowerShell.
2. Escriba este comando:

New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4

Estará usando el comando trace route para probar el enrutamiento en este tutorial. Para entornos de
producción, no se recomienda permitir ICMP a través del Firewall de Windows.
Activación del reenvío IP en myVmNva
Ha activado el reenvío IP para la interfaz de red de la máquina virtual con Azure. El sistema operativo de la
máquina virtual también tiene que reenviar el tráfico de red. Active el reenvío IP para el sistema operativo de
máquina virtual myVmNva con estos comandos.
1. Desde un símbolo del sistema en la máquina virtual myVmPrivate, abra un Escritorio remoto en la
máquina virtual myVmNva:

mstsc /v:myvmnva

2. En PowerShell, en la máquina virtual myVmNva, escriba este comando para activar el reenvío IP:

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name IpEnableRouter -

Value 1

3. Reinicie la máquina virtual myVmNva. En la barra de tareas, seleccione Inicio > Encendido , Otros
(planeados) > Continuar .
Esto también desconecta la sesión de Escritorio remoto.
4. Una vez que se reinicie la máquina virtual myVmNva, cree una sesión de Escritorio remoto en la máquina
virtual myVmPublic. Mientras sigue conectado a la máquina virtual myVmPrivate, abra un símbolo del
sistema y ejecute este comando:

mstsc /v:myVmPublic

5. En el Escritorio remoto de myVmPublic, abra PowerShell.

6. Habilite ICMP mediante el Firewall de Windows con el comando siguiente:

New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4

Prueba del enrutamiento del tráfico de red

En primer lugar, vamos a probar el enrutamiento del tráfico de red desde la máquina virtual myVmPublic a la
máquina virtual myVmPrivate.
1. En PowerShell, en la máquina virtual myVmPublic, escriba este comando:

tracert myVmPrivate

La respuesta es similar a este ejemplo:

 Tracing route to [Link] [[Link]]
over a maximum of 30 hops:

1 <1 ms * 1 ms [Link]
2 1 ms 1 ms 1 ms [Link]

Trace complete.

Puede ver que el primer salto es [Link], que es la dirección IP privada de la aplicación virtual de red. El
segundo salto es a la dirección IP privada de la máquina virtual myVmPrivate: [Link]. Anteriormente,
agregó la ruta a la tabla de rutas myRouteTablePublic y la asoció a la subred Pública. Como resultado,
Azure envió el tráfico a través de la aplicación virtual de red y no directamente a la subred Privada.
2. Cierre la sesión de Escritorio remoto a la máquina virtual myVmPublic, que aún le deja conectado a la
máquina virtual myVmPrivate.
3. Desde un símbolo del sistema de la máquina virtual myVmPrivate, escriba este comando:

tracert myVmPublic

Este comando prueba el enrutamiento del tráfico de red desde la máquina virtual myVmPrivate a la
máquina virtual myVmPublic. La respuesta es similar a este ejemplo:

Tracing route to [Link] [[Link]]

over a maximum of 30 hops:

1 1 ms 1 ms 1 ms [Link]

Trace complete.

Puede ver que Azure enruta el tráfico directamente desde la máquina virtual myVmPrivate a la máquina
virtual myVmPublic. De forma predeterminada, Azure enruta el tráfico directamente entre subredes.
4. Cierre la sesión de Escritorio remoto a la máquina virtual myVmPrivate.

Limpieza de recursos
Cuando el grupo de recursos ya no sea necesario, elimine myResourceGroup y todos los recursos que contiene:
1. Vaya a Azure Portal para administrar el grupo de recursos. Busque y seleccione Grupos de recursos .
2. Asigne un nombre al grupo de recursos (myResourceGroup ).
3. Seleccione Eliminar grupo de recursos .
4. En el cuadro de diálogo de confirmación, escriba myResourceGroup en ESCRIBA EL NOMBRE DEL
GRUPO DE RECURSOS y, después, seleccione Eliminar . Azure elimina el grupo de recursos
myResourceGroup y todos los recursos vinculados a ese grupo de recursos, incluidas las tablas de rutas,
las cuentas de almacenamiento, las redes virtuales, las interfaces de red y las direcciones IP públicas.

Pasos siguientes
En este artículo, ha creado una tabla de rutas y la ha asociado a una subred. Creó una aplicación virtual de red
sencilla que enrutó el tráfico desde una subred pública hasta una subred privada. Ahora puede implementar
diferentes aplicaciones virtuales de red preconfiguradas desde Azure Marketplace, que proporcionan muchas
funciones de red útiles. Para más información acerca del enrutamiento, consulte Introducción al enrutamiento y
Administración de una tabla de rutas.
Aunque puede implementar muchos recursos de Azure en una red virtual, Azure no puede implementar recursos
para algunos servicios de PaaS en una red virtual. Es posible restringir el acceso a los recursos de algunos
servicios de PaaS de Azure, aunque la restricción solo debe ser el tráfico de una subred de red virtual. Para
aprender a restringir el acceso de red a los recursos de PaaS de Azure, consulte el siguiente tutorial.
Restringir el acceso de red a los recursos de PaaS

NOTE
Los servicios de Azure cuestan dinero. Azure Cost Management le ayuda a establecer presupuestos y a configurar alertas
para mantener el gasto bajo control. Analice, administre y optimice sus costos de Azure con Cost Management. Para
obtener más información, consulte el inicio rápido sobre el análisis de los costos.
 Enrutamiento del tráfico de red con una tabla de
rutas mediante PowerShell
23/09/2020 • 17 minutes to read • Edit Online

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.

De forma predeterminada, Azure enruta automáticamente el tráfico entre todas las subredes de una red virtual.
Sin embargo, puede crear sus propias rutas para invalidar las predeterminadas de Azure. La posibilidad de crear
rutas personalizadas resulta de utilidad si, por ejemplo, quiere enrutar el tráfico entre subredes por medio de una
aplicación virtual de red (NVA). En este artículo aprenderá a:
Creación de una tabla de rutas
Creación de una ruta
Creación de una red virtual con varias subredes
Asociación de una tabla de rutas a una subred
Creación de una aplicación virtual de red para enrutar el tráfico
Implementación de máquinas virtuales (VM) en subredes diferentes
Enrutamiento del tráfico desde una subred a otra a través de una aplicación virtual de red
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar PowerShell de forma local, para realizar los pasos de este artículo necesita la versión 1.0.0
del módulo de Azure PowerShell o cualquier versión posterior. Ejecute Get-Module -ListAvailable Az para buscar
la versión instalada. Si necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se
ejecuta localmente, también debe ejecutar Connect-AzAccount para crear una conexión con Azure.

Creación de una tabla de rutas

Para poder crear una tabla de rutas, debe crear un grupo de recursos con New-AzResourceGroup. En el ejemplo
siguiente se crea un grupo de recursos denominado myResourceGroup para todos los recursos creados en este
artículo.

New-AzResourceGroup -ResourceGroupName myResourceGroup -Location EastUS

Cree una tabla de rutas con New-AzRouteTable. En el ejemplo siguiente se crea una tabla de rutas denominada
myRouteTablePublic.

$routeTablePublic = New-AzRouteTable `
-Name 'myRouteTablePublic' `
-ResourceGroupName myResourceGroup `
-location EastUS

Creación de una ruta

Cree una ruta recuperando el objeto de la tabla de rutas con Get-AzRouteTable, cree una ruta con Add-
AzRouteConfig y luego escriba la configuración de la ruta para la tabla de rutas con Set-AzRouteTable.

Get-AzRouteTable `
-ResourceGroupName "myResourceGroup" `
-Name "myRouteTablePublic" `
| Add-AzRouteConfig `
-Name "ToPrivateSubnet" `
-AddressPrefix [Link]/24 `
-NextHopType "VirtualAppliance" `
-NextHopIpAddress [Link] `
| Set-AzRouteTable

Asociación de una tabla de rutas a una subred

Para poder asociar una tabla de rutas a una subred, debe crear una red virtual y una subred. Cree una red virtual
con New-AzVirtualNetwork. En el ejemplo siguiente se crea una red virtual denominada myVirtualNetwork con el
prefijo de dirección [Link]/16.
 $virtualNetwork = New-AzVirtualNetwork `
-ResourceGroupName myResourceGroup `
-Location EastUS `
-Name myVirtualNetwork `
-AddressPrefix [Link]/16

Cree tres subredes a partir de tres configuraciones de subred con New-AzVirtualNetworkSubnetConfig. En el

ejemplo siguiente se crean tres configuraciones de subred para las subredes Pública, Privada y DMZ:

$subnetConfigPublic = Add-AzVirtualNetworkSubnetConfig `
-Name Public `
-AddressPrefix [Link]/24 `
-VirtualNetwork $virtualNetwork

$subnetConfigPrivate = Add-AzVirtualNetworkSubnetConfig `
-Name Private `
-AddressPrefix [Link]/24 `
-VirtualNetwork $virtualNetwork

$subnetConfigDmz = Add-AzVirtualNetworkSubnetConfig `
-Name DMZ `
-AddressPrefix [Link]/24 `
-VirtualNetwork $virtualNetwork

Escriba las configuraciones de subred en la red virtual con Set-AzVirtualNetwork, lo que crea las subredes en la
red virtual:

$virtualNetwork | Set-AzVirtualNetwork

Asocie la tabla de rutas myRouteTablePublic a la subred Pública con Set-AzVirtualNetworkSubnetConfig y escriba

la configuración de subred en la red virtual con Set-AzVirtualNetwork.

Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $virtualNetwork `
-Name 'Public' `
-AddressPrefix [Link]/24 `
-RouteTable $routeTablePublic | `
Set-AzVirtualNetwork

Creación de una aplicación virtual de red

Una aplicación virtual de red es una máquina virtual que realiza una función de red, como el enrutamiento, el
firewall o la optimización de la WAN.
Antes de crear una máquina virtual, cree una interfaz de red.
Crear una interfaz de red
Para poder crear una interfaz de red, tiene que recuperar el identificador de red virtual con Get AzVirtualNetwork
y el identificador de subred con Get-AzVirtualNetworkSubnetConfig. Cree una interfaz de red con New-
AzNetworkInterface en la subred DMZ con el reenvío IP habilitado:
 # Retrieve the virtual network object into a variable.
$virtualNetwork=Get-AzVirtualNetwork `
-Name myVirtualNetwork `
-ResourceGroupName myResourceGroup

# Retrieve the subnet configuration into a variable.

$subnetConfigDmz = Get-AzVirtualNetworkSubnetConfig `
-Name DMZ `
-VirtualNetwork $virtualNetwork

# Create the network interface.

$nic = New-AzNetworkInterface `
-ResourceGroupName myResourceGroup `
-Location EastUS `
-Name 'myVmNva' `
-SubnetId $[Link] `
-EnableIPForwarding

Crear una VM
Para crear una máquina virtual y asociarle una interfaz de red existente, primero debe crear una configuración de
máquina virtual con New-AzVMConfig. La configuración incluye la interfaz de red que creó en el paso anterior.
Cuando se le pida un nombre de usuario y una contraseña, seleccione el nombre de usuario y la contraseña con
los que quiere iniciar sesión en la máquina virtual.

# Create a credential object.

$cred = Get-Credential -Message "Enter a username and password for the VM."

# Create a VM configuration.
$vmConfig = New-AzVMConfig `
-VMName 'myVmNva' `
-VMSize Standard_DS2 | `
Set-AzVMOperatingSystem -Windows `
-ComputerName 'myVmNva' `
-Credential $cred | `
Set-AzVMSourceImage `
-PublisherName MicrosoftWindowsServer `
-Offer WindowsServer `
-Skus 2016-Datacenter `
-Version latest | `
Add-AzVMNetworkInterface -Id $[Link]

Cree la máquina virtual utilizando su configuración con New-AzVM. En el ejemplo siguiente se crea una máquina
virtual denominada myVmNva.

$vmNva = New-AzVM `
-ResourceGroupName myResourceGroup `
-Location EastUS `
-VM $vmConfig `
-AsJob

La opción -AsJob crea la máquina virtual en segundo plano, así que puede continuar con el siguiente paso.

Creación de máquinas virtuales

Cree dos máquinas virtuales en la red virtual para que pueda validar que el tráfico que procede de la subred
Pública se enruta a la subred Privada mediante la aplicación virtual de red de un paso posterior.
Cree una máquina virtual en la subred Pública con New-AzVM. En el ejemplo siguiente se crea una máquina
virtual llamada myVmPublic en la subred Public de la red virtual myVirtualNetwork.
 New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Location "East US" `
-VirtualNetworkName "myVirtualNetwork" `
-SubnetName "Public" `
-ImageName "Win2016Datacenter" `
-Name "myVmPublic" `
-AsJob

Cree una máquina virtual en la subred Private.

New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Location "East US" `
-VirtualNetworkName "myVirtualNetwork" `
-SubnetName "Private" `
-ImageName "Win2016Datacenter" `
-Name "myVmPrivate"

La máquina virtual tarda en crearse unos minutos. No continúe con el paso siguiente hasta que se cree la
máquina virtual y Azure devuelva la salida a PowerShell.

Enrutamiento del tráfico a través de una aplicación virtual de red

Use Get-AzPublicIpAddress para devolver la dirección IP pública de la máquina virtual myVmPrivate. En el
siguiente ejemplo se devuelve la dirección IP pública de la máquina virtual myVmPrivate:

Get-AzPublicIpAddress `
-Name myVmPrivate `
-ResourceGroupName myResourceGroup `
| Select IpAddress

Ejecute el comando siguiente en el equipo local para crear una sesión de Escritorio remoto con la máquina virtual
myVmPrivate. Reemplace <publicIpAddress> con la dirección IP que devolvió el comando anterior.

mstsc /v:<publicIpAddress>

Abra el archivo RDP descargado. Cuando se le pida, seleccione Conectar .

Escriba el nombre de usuario y la contraseña que especificó al crear la máquina virtual (puede que deba
seleccionar Más opciones y luego Usar una cuenta diferente , para especificar las credenciales que escribió
cuando creó la máquina virtual). A continuación, seleccione Aceptar . Puede recibir una advertencia de certificado
durante el proceso de inicio de sesión. Seleccione Sí para continuar con la conexión.
En el último paso, se usa el comando [Link] para probar el enrutamiento. Tracert usa el Protocolo de
mensajes de control de Internet (ICMP), que se deniega a través del Firewall de Windows. Para habilitar ICMP
mediante el Firewall de Windows, escriba el comando siguiente desde PowerShell en la máquina virtual
myVmPrivate:

New-NetFirewallRule -DisplayName "Allow ICMPv4-In" -Protocol ICMPv4

Aunque en este artículo se usa trace route para probar el enrutamiento, no es recomendable permitir el uso de
ICMP a través del Firewall de Windows en las implementaciones de producción.
El reenvío IP se habilitó dentro de Azure para la interfaz de red de la VM en Habilitación del reenvío IP. Dentro de
la máquina virtual, también el sistema operativo o una aplicación en ejecución deben poder reenviar el tráfico de
red. Habilite el reenvío IP en el sistema operativo de myVmNva.
Desde un símbolo del sistema de la máquina virtual myVmPrivate, conéctese mediante Escritorio remoto a
myVmNva:

mstsc /v:myvmnva

Para habilitar el reenvío IP dentro del sistema operativo, escriba el siguiente comando en PowerShell desde la
máquina virtual myVmNva:

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters -Name IpEnableRouter -Value 1

Reinicie la máquina virtual myVmNva, lo que desconectará también la sesión de Escritorio remoto.
Mientras sigue conectado a la máquina virtual myVmPrivate y una vez que se reinicie la máquina virtual
myVmNva, cree una sesión de Escritorio remoto en la máquina virtual myVmPublic:

mstsc /v:myVmPublic

Para permitir el uso de ICMP a través del Firewall de Windows, escriba el comando siguiente desde PowerShell en
la máquina virtual myVmPrivate:

New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4

Para probar el enrutamiento del tráfico de red desde myVmPublic hasta myVmPrivate, escriba el siguiente
comando de PowerShell en la máquina virtual myVmPublic:

tracert myVmPrivate

La respuesta es similar al siguiente ejemplo:

Tracing route to [Link] [[Link]]

over a maximum of 30 hops:

1 <1 ms * 1 ms [Link]
2 1 ms 1 ms 1 ms [Link]

Trace complete.

Puede ver que el primer salto es [Link], que es la dirección IP privada de la aplicación virtual de red. El segundo
salto es [Link], la dirección IP privada de la máquina virtual myVmPrivate. La ruta agregada a la tabla de rutas
myRouteTablePublic y asociada a la subred Pública hizo que Azure enrutara el tráfico mediante la NVA, en lugar
de a la subred Privada directamente.
Cierre la sesión de Escritorio remoto a la máquina virtual myVmPublic, que aún le deja conectado a la máquina
virtual myVmPrivate.
Para probar el enrutamiento del tráfico de red desde myVmPrivate hasta myVmPublic, escriba el siguiente
comando en un símbolo del sistema de la máquina virtual myVmPrivate:

tracert myVmPublic
La respuesta es similar al siguiente ejemplo:

Tracing route to [Link] [[Link]]

over a maximum of 30 hops:

1 1 ms 1 ms 1 ms [Link]

Trace complete.

Puede ver si el tráfico se enruta directamente de la máquina virtual myVmPrivate a la máquina virtual
myVmPublic. De forma predeterminada, Azure enruta el tráfico directamente entre subredes.
Cierre la sesión de Escritorio remoto a la máquina virtual myVmPrivate.

Limpieza de recursos
Cuando ya no lo necesite, utilice Remove-AzResourcegroup para quitar el grupo de recursos y todos los recursos
que contiene.

Remove-AzResourceGroup -Name myResourceGroup -Force

Pasos siguientes
En este artículo, creó una tabla de rutas y la asoció a una subred. Creó una aplicación virtual de red sencilla que
enrutó el tráfico desde una subred pública hasta una subred privada. Implemente una variedad de aplicaciones
virtuales de red que realicen funciones de red, como firewall y optimización de la WAN, desde Azure Marketplace.
Para más información acerca del enrutamiento, consulte Introducción al enrutamiento y Administración de una
tabla de rutas.
Aunque puede implementar muchos recursos de Azure en una red virtual, no es el caso de los recursos de
algunos servicios de PaaS de Azure. Pero puede restringir el acceso a los recursos de algunos servicios de PaaS de
Azure solo al tráfico que procede de una subred de una red virtual. Para saber cómo hacerlo, consulte Restricción
del acceso de red a los recursos de PaaS.
 Enrutamiento del tráfico de red con una tabla de
rutas mediante la CLI de Azure
23/09/2020 • 14 minutes to read • Edit Online

De forma predeterminada, Azure enruta automáticamente el tráfico entre todas las subredes de una red virtual.
Sin embargo, puede crear sus propias rutas para invalidar las predeterminadas de Azure. La posibilidad de crear
rutas personalizadas resulta de utilidad si, por ejemplo, quiere enrutar el tráfico entre subredes por medio de una
aplicación virtual de red (NVA). En este artículo aprenderá a:
Creación de una tabla de rutas
Creación de una ruta
Creación de una red virtual con varias subredes
Asociación de una tabla de rutas a una subred
Creación de una aplicación virtual de red para enrutar el tráfico
Implementación de máquinas virtuales (VM) en subredes diferentes
Enrutamiento del tráfico desde una subred a otra a través de una aplicación virtual de red
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar la CLI en un entorno local, para esta guía de inicio rápido es preciso que ejecute la versión
2.0.28 de la CLI de Azure o una versión posterior. Para encontrar la versión, ejecute az --version . Si necesita
instalarla o actualizarla, vea Instalación de la CLI de Azure.

Creación de una tabla de rutas

Antes de poder crear una tabla de rutas, debe crear un grupo de recursos con az group create para todos los
recursos creados en este artículo.

# Create a resource group.

az group create \
--name myResourceGroup \
--location eastus

Cree una tabla de rutas con az network route-table create. En el ejemplo siguiente se crea una tabla de rutas
denominada myRouteTablePublic.

# Create a route table

az network route-table create \
--resource-group myResourceGroup \
--name myRouteTablePublic

Creación de una ruta

Cree una ruta en la tabla de rutas con az network route-table route create.

az network route-table route create \

--name ToPrivateSubnet \
--resource-group myResourceGroup \
--route-table-name myRouteTablePublic \
--address-prefix [Link]/24 \
--next-hop-type VirtualAppliance \
--next-hop-ip-address [Link]

Asociación de una tabla de rutas a una subred

Para poder asociar una tabla de rutas a una subred, debe crear una red virtual y una subred. Cree una red virtual
con una subred con az network vnet create.

az network vnet create \

--name myVirtualNetwork \
--resource-group myResourceGroup \
--address-prefix [Link]/16 \
--subnet-name Public \
--subnet-prefix [Link]/24

Cree dos subredes adicionales con az network vnet subnet create.

 # Create a private subnet.
az network vnet subnet create \
--vnet-name myVirtualNetwork \
--resource-group myResourceGroup \
--name Private \
--address-prefix [Link]/24

# Create a DMZ subnet.

az network vnet subnet create \
--vnet-name myVirtualNetwork \
--resource-group myResourceGroup \
--name DMZ \
--address-prefix [Link]/24

Asocie la tabla de rutas myRouteTablePublic a la subred Pública con az network vnet subnet update.

az network vnet subnet update \

--vnet-name myVirtualNetwork \
--name Public \
--resource-group myResourceGroup \
--route-table myRouteTablePublic

Creación de una aplicación virtual de red

Una aplicación virtual de red es una máquina virtual que realiza una función de red, como el enrutamiento, el
firewall o la optimización de la WAN.
Cree una aplicación virtual de red en la subred DMZ con az vm create. Cuando se crea una máquina virtual, Azure
crea una dirección IP pública y la asigna a la máquina virtual de forma predeterminada. El parámetro
--public-ip-address "" indica a Azure que no cree ni asigne una dirección IP pública a la máquina virtual, dado
que no es necesario que esta esté conectada a Internet. Si las claves SSH no existen en la ubicación de claves
predeterminada, el comando las crea. Para utilizar un conjunto específico de claves, utilice la opción
--ssh-key-value .

az vm create \
--resource-group myResourceGroup \
--name myVmNva \
--image UbuntuLTS \
--public-ip-address "" \
--subnet DMZ \
--vnet-name myVirtualNetwork \
--generate-ssh-keys

La máquina virtual tarda en crearse unos minutos. No continúe con el paso siguiente hasta que Azure termine de
crear la máquina virtual y devuelva información sobre ella.
Para que una interfaz de red pueda reenviar el tráfico de red recibido, que no está destinado a su propia dirección
IP, debe tener habilitado el reenvío IP. Habilite el reenvío IP para la interfaz de red con az network nic update.

az network nic update \

--name myVmNvaVMNic \
--resource-group myResourceGroup \
--ip-forwarding true

Dentro de la máquina virtual, también el sistema operativo o una aplicación en ejecución deben poder reenviar el
tráfico de red. Habilite el reenvío IP en el sistema operativo de la máquina virtual con az vm extension set:
 az vm extension set \
--resource-group myResourceGroup \
--vm-name myVmNva \
--name customScript \
--publisher [Link] \
--settings '{"commandToExecute":"sudo sysctl -w net.ipv4.ip_forward=1"}'

El comando puede tardar un minuto en ejecutarse.

Creación de máquinas virtuales

Cree dos máquinas virtuales en la red virtual para poder validar que el tráfico que procede de la subred Public se
enruta a la subred Private mediante la aplicación virtual de red de un paso posterior.
Cree una máquina virtual en la subred Public con az vm create. El parámetro --no-wait permite a Azure ejecutar
el comando en segundo plano para que pueda continuar con el siguiente comando. Para simplificar los pasos de
este artículo, se usa una contraseña. Las claves se utilizan habitualmente en las implementaciones de producción.
Si usa claves, también debe configurar el reenvío del agente SSH. Para más información, consulte la
documentación del cliente SSH. Reemplace <replace-with-your-password> en el siguiente comando por una
contraseña de su elección.

adminPassword="<replace-with-your-password>"

az vm create \
--resource-group myResourceGroup \
--name myVmPublic \
--image UbuntuLTS \
--vnet-name myVirtualNetwork \
--subnet Public \
--admin-username azureuser \
--admin-password $adminPassword \
--no-wait

Cree una máquina virtual en la subred Private.

az vm create \
--resource-group myResourceGroup \
--name myVmPrivate \
--image UbuntuLTS \
--vnet-name myVirtualNetwork \
--subnet Private \
--admin-username azureuser \
--admin-password $adminPassword

La máquina virtual tarda en crearse unos minutos. Después de crear la máquina virtual, la CLI de Azure muestra
información similar a la del ejemplo siguiente:

{
"fqdns": "",
"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/virtualMachines/myVmPrivate",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "[Link]",
"publicIpAddress": "[Link]",
"resourceGroup": "myResourceGroup"
}
Anote el valor de publicIpAddress . En un paso posterior, usaremos esta dirección para obtener acceso a la
máquina virtual desde Internet.

Enrutamiento del tráfico a través de una aplicación virtual de red

Use el siguiente comando para crear una sesión de SSH con la máquina virtual myVmPrivate. Reemplace
<publicIpAddress> con la dirección IP pública de la máquina virtual. En el ejemplo anterior, la dirección IP era
[Link].

ssh azureuser@<publicIpAddress>

Cuando se le solicite una contraseña, escriba la que seleccionó en Creación de máquinas virtuales.
Use el siguiente comando para instalar traceroute en la máquina virtual myVmPrivate:

sudo apt-get install traceroute

Use el siguiente comando para probar el enrutamiento del tráfico de red a la máquina virtual myVmPublic desde
la máquina virtual myVmPrivate.

traceroute myVmPublic

La respuesta es similar al siguiente ejemplo:

traceroute to myVmPublic ([Link]), 30 hops max, 60 byte packets

1 [Link] ([Link]) 1.404 ms 1.403 ms 1.398 ms

Puede ver si el tráfico se enruta directamente de la máquina virtual myVmPrivate a la máquina virtual
myVmPublic. Las rutas predeterminadas de Azure enrutan el tráfico entre las subredes.
Use el siguiente comando para usar SSH en la máquina virtual myVmPublic desde la máquina virtual
myVmPrivate:

ssh azureuser@myVmPublic

Use el siguiente comando para instalar traceroute en la máquina virtual myVmPublic:

sudo apt-get install traceroute

Use el siguiente comando para probar el enrutamiento del tráfico de red a la máquina virtual myVmPrivate desde
la máquina virtual myVmPublic.

traceroute myVmPrivate

La respuesta es similar al siguiente ejemplo:

traceroute to myVmPrivate ([Link]), 30 hops max, 60 byte packets

1 [Link] ([Link]) 0.781 ms 0.780 ms 0.775 ms
2 [Link] ([Link]) 1.404 ms 1.403 ms 1.398 ms

Puede ver que el primer salto es [Link], que es la dirección IP privada de la aplicación virtual de red. El segundo
salto es [Link], la dirección IP privada de la máquina virtual myVmPrivate. La ruta agregada a la tabla de rutas
myRouteTablePublic y asociada a la subred Pública hizo que Azure enrutara el tráfico mediante la NVA, en lugar
de a la subred Privada directamente.
Cierre las sesiones SSH tanto de la máquina virtual myVmPublic como de myVmPrivate.

Limpieza de recursos
Cuando ya no se necesiten, use az group delete para quitar el grupo de recursos y todos los recursos que
contenga.

az group delete --name myResourceGroup --yes

Pasos siguientes
En este artículo, creó una tabla de rutas y la asoció a una subred. Creó una aplicación virtual de red sencilla que
enrutó el tráfico desde una subred pública hasta una subred privada. Puede implementar diversas aplicaciones
virtuales de red preconfiguradas que realicen funciones de red, como son la optimización de la WAN y la de
firewall, desde Azure Marketplace. Para más información acerca del enrutamiento, consulte Introducción al
enrutamiento y Administración de una tabla de rutas.
Aunque puede implementar muchos recursos de Azure en una red virtual, no es el caso de los recursos de
algunos servicios de PaaS de Azure. Pero puede restringir el acceso a los recursos de algunos servicios de PaaS de
Azure solo al tráfico que procede de una subred de una red virtual. Para saber cómo hacerlo, consulte Restricción
del acceso de red a los recursos de PaaS.
 Creación, modificación o eliminación de una tabla
de rutas
23/09/2020 • 23 minutes to read • Edit Online

Azure enruta automáticamente el tráfico entre redes locales, las redes virtuales y las subredes de Azure. Si desea
cambiar algún enrutamiento predeterminado de Azure, debe crear una tabla de rutas. Si no está familiarizado
con el enrutamiento en redes virtuales, puede obtener más información al respecto en Enrutamiento del tráfico
de redes virtuales o siguiendo un tutorial.

Antes de empezar
Si no tiene ninguna, configure una cuenta de Azure con una suscripción activa. Cree una cuenta gratuita.
Después, complete una de estas tareas antes de iniciar los pasos de cualquiera de las secciones de este artículo:
Usuarios de Por tal : Inicie sesión en Azure Portal con su cuenta de Azure.
Usuarios de PowerShell : ejecute los comandos en Azure Cloud Shell, o bien ejecute PowerShell en el
equipo. Azure Cloud Shell es un shell interactivo gratuito que puede usar para ejecutar los pasos de este
artículo. Tiene las herramientas comunes de Azure preinstaladas y configuradas para usarlas en la cuenta.
En la pestaña del explorador Azure Cloud Shell, busque la lista desplegable Seleccionar entorno y,
después, elija PowerShell si aún no está seleccionado.
Si ejecuta PowerShell en el entorno local, use la versión del módulo de Azure PowerShell 1.0.0 o una
posterior. Ejecute Get-Module -ListAvailable [Link] para buscar la versión instalada. Si necesita
actualizarla, consulte Instalación del módulo de Azure PowerShell. Ejecute también Connect-AzAccount
para crear una conexión con Azure.
Usuarios de la interfaz de la línea de comandos (CLI) de Azure : ejecute los comandos en Azure
Cloud Shell, o bien ejecute la CLI en el equipo. Use la versión 2.0.31 de la CLI de Azure o una posterior si
ejecuta la CLI de Azure en el entorno local. Ejecute az --version para buscar la versión instalada. Si
necesita instalarla o actualizarla, vea Instalación de la CLI de Azure. Ejecute también az login para crear
una conexión con Azure.
La cuenta en la que inicia sesión o con la que se conecta a Azure debe tener asignado el rol Colaborador de red o
un rol personalizado que tenga asignadas las acciones apropiadas en Permisos.

Creación de una tabla de rutas

Existe un límite en cuanto a la cantidad de tablas de rutas que se pueden crear por suscripción y ubicación de
Azure. Para más información, vea Límites de redes - Azure Resource Manager.
1. En el menú Azure Portal o en la página Inicio , seleccione Crear un recurso .
2. En el cuadro de búsqueda, escriba Tabla de enrutamiento. Cuando Tabla de enrutamiento aparezca en
los resultados de la búsqueda, selecciónelo.
3. En la página Tabla de enrutamiento , seleccione Crear .
4. En el cuadro de diálogo Crear tabla de rutas :
a. Escriba un Nombre para la tabla.
b. Elija la suscripción .
 c. Seleccione un Grupo de recursos existente o seleccione Crear nuevo para crear uno desde cero.
d. Elija una ubicación .
e. Si va a asociar la tabla de rutas a una subred de una red virtual conectada a la red local por medio de
una puerta de enlace VPN, y no quiere que las rutas locales se propaguen a las interfaces de red de la
subred, establezca Propagación de rutas de puer ta de enlace de red vir tual en Deshabilitado .
5. Seleccione Crear para crear la tabla de rutas.
Creación de una tabla de rutas: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network route-table create

PowerShell New-AzRouteTable

Vista de las tablas de rutas

Vaya a Azure Portal para administrar la red virtual. Busque y seleccione Tablas de rutas . Aparecen las tablas de
rutas que existen en la suscripción.
Vista de una tabla de rutas: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network route-table list

PowerShell Get-AzRouteTable

Vista de los detalles de una tabla de rutas

1. Vaya a Azure Portal para administrar la red virtual. Busque y seleccione Tablas de rutas .
2. En la lista de tablas de rutas, elija aquella cuyos detalles quiera ver.
3. En la página de la tabla de rutas, en Configuración , vea las Rutas de esa tabla de rutas y las subredes
con las que dicha la tabla de rutas está asociada.
Para más información sobre la configuración común de Azure, consulte la información siguiente:
Registro de actividad
Control de acceso (IAM)
Etiquetas
Bloqueos
Script de Automation
Vista de los detalles de una tabla de rutas: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network route-table show

PowerShell Get-AzRouteTable

Modificación de una tabla de rutas

1. Vaya a Azure Portal para administrar la red virtual. Busque y seleccione Tablas de rutas .
2. En la lista de tablas de rutas, elija aquella que quiera cambiar.
Los cambios más habituales son agregar rutas, quitar rutas, asociar tablas de rutas a subredes o desasociar
tablas de rutas de subredes.
Modificación de una tabla de rutas: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network route-table update

PowerShell Set-AzRouteTable

Asociación de una tabla de rutas a una subred

Opcionalmente, puede asociar una tabla de rutas a una subred. Una tabla de rutas se puede asociar a varias
subredes o a ninguna. Como las tablas de rutas no se asocian a redes virtuales, debe asociar una tabla de rutas a
cada subred con la que quiera asociarla. Azure enruta todo el tráfico que sale de la subred según las rutas que se
crearon dentro de las tablas de rutas, las rutas predeterminadas y las rutas propagadas desde una red local, si la
red virtual está conectada a una puerta de enlace de red virtual de Azure (ExpressRoute o VPN). Solo puede
asociar una tabla de rutas a las subredes de las redes virtuales que existen en la misma suscripción y ubicación
de Azure de la tabla de rutas.
1. Vaya a Azure Portal para administrar la red virtual. Busque y seleccione Redes vir tuales .
2. En la lista de redes virtuales, seleccione la red virtual que contiene la subred a la que quiera asociar una
tabla de rutas.
3. En la barra de menús de la red virtual, elija Subredes .
4. Seleccione la subred a la que desea asociar la tabla de rutas.
5. En Tabla de rutas , seleccione la tabla de rutas a la que quiera asociar la subred.
6. Seleccione Guardar .
Si la red virtual está conectada a una instancia de Azure VPN Gateway, no asocie una tabla de rutas a la subred
de la puerta de enlace que incluya una ruta con un destino [Link]/0. Si lo hace, puede que la puerta de enlace no
funcione correctamente. Para más información sobre cómo usar [Link]/0 en una ruta, vea Enrutamiento del
tráfico de redes virtuales.
Asociación de una tabla de rutas: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network vnet subnet update

PowerShell Set-AzVirtualNetworkSubnetConfig

Desasociación de una tabla de rutas de una subred

Cuando desasocia una tabla de rutas de una subred, Azure enruta el tráfico según sus rutas predeterminadas.
1. Vaya a Azure Portal para administrar la red virtual. Busque y seleccione Redes vir tuales .
2. En la lista de redes virtuales, seleccione la red virtual que contiene la subred de la que quiera desasociar
 una tabla de rutas.
3. En la barra de menús de la red virtual, elija Subredes .
4. Seleccione la subred de la que desea desasociar la tabla de rutas.
5. En Tabla de rutas , seleccione Ninguno .
6. Seleccione Guardar .
Desasociación de una tabla de rutas: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network vnet subnet update

PowerShell Set-AzVirtualNetworkSubnetConfig

Eliminación de una tabla de rutas

Una tabla de rutas que está asociada a una subred no se puede eliminar. Desasocie una tabla de rutas de todas
las subredes antes de intentar eliminarla.
1. Vaya a Azure Portal para administrar la tabla de rutas. Busque y seleccione Tablas de rutas .
2. En la lista de tablas de rutas, elija aquella que quiera eliminar.
3. Seleccione Eliminar y, después, seleccione Sí en el cuadro de diálogo de confirmación.
Eliminación de una tabla de rutas: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network route-table delete

PowerShell Remove-AzRouteTable

Creación de una ruta

Existe un límite en cuanto a la cantidad de rutas por tabla de rutas que se puede crear por suscripción y
ubicación de Azure. Para más información, vea Límites de redes - Azure Resource Manager.
1. Vaya a Azure Portal para administrar la tabla de rutas. Busque y seleccione Tablas de rutas .
2. En la lista de tablas de rutas, elija aquella a la que quiera agregar una ruta.
3. En la barra de menús de la tabla de rutas, seleccione rutas > Agregar .
4. Escriba un Nombre de ruta único para la ruta dentro de la tabla de rutas.
5. Escriba el Prefijo de dirección , en la notación de Enrutamiento de interdominios sin clases (CIDR), al
que quiera enrutar el tráfico. El prefijo no se puede duplicar en más de una ruta dentro de la tabla de
rutas, aunque puede estar dentro de otro prefijo. Por ejemplo, si definió [Link]/16 como prefijo en una
ruta, puede seguir definiendo otra ruta con el prefijo de dirección [Link]/22. Azure selecciona una ruta
para el tráfico en función de la coincidencia de prefijo más larga. Para más información, vea Selección de
rutas por parte de Azure.
6. Seleccione un Tipo del próximo salto . Para más información sobre los tipos de próximo salto, vea
Enrutamiento del tráfico de redes virtuales.
7. Si seleccionó un Tipo del próximo salto de Aplicación vir tual , escriba una dirección IP en Dirección
del próximo salto .
8. Seleccione Aceptar .
Creación de una ruta: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network route-table route create

PowerShell New-AzRouteConfig

Vista de las rutas

Una tabla de rutas puede contener varias rutas o ninguna. Para más detalles sobre la información que aparece al
ver las rutas, vea Enrutamiento del tráfico de redes virtuales.
1. Vaya a Azure Portal para administrar la tabla de rutas. Busque y seleccione Tablas de rutas .
2. En la lista de tablas de rutas, elija aquella cuyas rutas quiera ver.
3. En la barra de menús de la tabla de rutas, seleccione Rutas para ver la lista de rutas.
Vista de las rutas: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network route-table route list

PowerShell Get-AzRouteConfig

Vista de los detalles de una ruta

1. Vaya a Azure Portal para administrar la tabla de rutas. Busque y seleccione Tablas de rutas .
2. En la lista de tablas de rutas, elija aquella que contenga la ruta cuyos detalles quiera ver.
3. En la barra de menús de la tabla de rutas, seleccione Rutas para ver la lista de rutas.
4. Seleccione la ruta cuyos detalles quiere ver.
Vista de los detalles de una ruta: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network route-table route show

PowerShell Get-AzRouteConfig

Modificación de una ruta

1. Vaya a Azure Portal para administrar la tabla de rutas. Busque y seleccione Tablas de rutas .
2. En la lista de tablas de rutas, elija aquella que contenga la ruta que quiera cambiar.
3. En la barra de menús de la tabla de rutas, seleccione Rutas para ver la lista de rutas.
4. Seleccione la ruta que quiera cambiar.
5. Cambie la configuración existente a la configuración nueva y, luego, seleccione Guardar .
Modificación de una ruta: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network route-table route update

PowerShell Set-AzRouteConfig

Eliminación de una ruta

1. Vaya a Azure Portal para administrar la tabla de rutas. Busque y seleccione Tablas de rutas .
2. En la lista de tablas de rutas, elija aquella que contenga la ruta que quiera eliminar.
3. En la barra de menús de la tabla de rutas, seleccione Rutas para ver la lista de rutas.
4. Seleccione la ruta que quiera eliminar.
5. Seleccione Eliminar y, después, seleccione Sí en el cuadro de diálogo de confirmación.
Eliminación de una ruta: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network route-table route delete

PowerShell Remove-AzRouteConfig

Vista de las rutas eficaces

Las rutas eficaces de cada interfaz de red conectada a una máquina virtual son una combinación de las tablas de
rutas que creó, las rutas predeterminadas de Azure y cualquier ruta propagada desde las redes locales por
medio del Protocolo de puerta de enlace de borde (BGP) a través de una puerta de enlace de red virtual de
Azure. Conocer las rutas eficaces de una interfaz de red resulta útil para solucionar los problemas con el
enrutamiento. Puede ver las rutas eficaces de cualquier interfaz de red conectada a una máquina virtual en
ejecución.
1. Vaya a Azure Portal para administrar sus máquinas virtuales. Busque y seleccione Máquinas vir tuales .
2. En la lista de máquinas virtuales, seleccione aquella cuyas rutas efectivas quiera ver.
3. En la barra de menús de la máquina virtual, elija Redes .
4. Seleccione el nombre de una interfaz de red.
5. En la barra de menús de la interfaz de red, seleccione Rutas eficaces .
6. Revise la lista de las rutas eficaces para ver si existe la ruta correcta a la que quiere enrutar el tráfico. En
Enrutamiento del tráfico de redes virtuales encontrará más información sobre los tipos de próximo salto
que figuran en esta lista.
Vista de las rutas efectivas: comandos
 H ERRA M IEN TA GET - H EL P

Azure CLI az network nic show-effective-route-table

PowerShell Get-AzEffectiveRouteTable

Validación del enrutamiento entre dos puntos de conexión

Puede determinar el tipo de próximo paso entre una máquina virtual y la dirección IP de otro recurso de Azure,
un recurso local o un recurso de Internet. Determinar el enrutamiento de Azure resulta útil para solucionar los
problemas con el enrutamiento. Para completar esta tarea, debe haber una instancia de Network Watcher. Si no
tiene una instancia de Network Watcher, complete los pasos descritos en Creación de una instancia de Network
Watcher para crear una.
1. Vaya a Azure Portal para sus instancias de Network Watcher. Busque y seleccione Network Watcher .
2. En la barra de menús de Network Watcher, seleccione Próximo salto .
3. En la página Network Watcher | Próximo salto :
a. Seleccione su Suscripción y el Grupo de recursos de la máquina virtual de origen desde la que
quiere validar el enrutamiento.
b. Seleccione la Máquina vir tual y la Interfaz de red que está conectada a la máquina virtual.
c. Escriba una Dirección IP de origen asignada a la interfaz de red desde la que quiera validar el
enrutamiento.
d. Escriba una Dirección IP de destino hacia la que quiera validar el enrutamiento.
4. Seleccione Próximo paso .
Tras una breve espera, Azure le indica el tipo de próximo paso y el identificador de la ruta que enrutó el tráfico.
En Enrutamiento del tráfico de redes virtuales encontrará más información sobre los tipos de próximo salto que
se devuelven.
Validación del enrutamiento entre dos puntos de conexión: comandos
H ERRA M IEN TA GET - H EL P

Azure CLI az network watcher show-next-hop

PowerShell Get-AzNetworkWatcherNextHop

Permisos
Para realizar tareas en rutas y en tablas de rutas, la cuenta debe tener asignado el rol Colaborador de red o un
rol personalizado que tenga asignadas las acciones adecuadas que figuran en la siguiente tabla:

A C C IÓ N N O M B RE

[Link]/routeTables/read Lectura de una tabla de rutas

[Link]/routeTables/write Creación o actualización de una tabla de rutas

[Link]/routeTables/delete Eliminación de una tabla de rutas

 A C C IÓ N N O M B RE

[Link]/routeTables/join/action Asociación de una tabla de rutas a una subred

[Link]/routeTables/routes/read Lectura de una ruta

[Link]/routeTables/routes/write Creación o actualización de una ruta

[Link]/routeTables/routes/delete Eliminación de una ruta

[Link]/networkInterfaces/effectiveRouteTable/acti Obtención de la tabla de rutas eficaces de una interfaz de red

on

[Link]/networkWatchers/nextHop/action Obtención del próximo salto de una VM

Pasos siguientes
Crear una tabla de rutas usando scripts de ejemplo de PowerShell o de la CLI de Azure o plantillas de Azure
Resource Manager
Crear y asignar definiciones de Azure Policy para redes virtuales
 Creación, cambio o eliminación de una interfaz de
red
23/09/2020 • 46 minutes to read • Edit Online

Aprenda a crear, cambiar la configuración y eliminar una interfaz de red. Una interfaz de red permite que una
máquina virtual de Azure se comunique con los recursos de Internet, Azure y locales. Al crear una máquina
virtual desde Azure Portal, este crea una interfaz de red con la configuración predeterminada. En su lugar,
puede crear interfaces de red con una configuración personalizada y agregar una o varias interfaces de red a
una máquina virtual al crearla. También puede cambiar la configuración predeterminada de la interfaz de red en
una interfaz de red existente. En este artículo se explica cómo crear una interfaz de red con opciones
personalizadas, cambiar la configuración existente, como la asignación de filtros de red (grupo de seguridad de
red), la asignación de subredes, la configuración del servidor DNS y el reenvío IP, y, finalmente, cómo eliminar
una interfaz de red.
Si tiene que agregar, cambiar o quitar direcciones IP de una interfaz de red, consulte Administración de
direcciones IP. Si necesita agregar o quitar interfaces de red en máquinas virtuales, consulte Adición o
eliminación de interfaces de red.

Antes de empezar
NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de
AzureRM que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más
información acerca del nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure
PowerShell Az module (Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la
instalación del módulo Az, consulte Instalación de Azure PowerShell.

Complete las tareas siguientes antes de seguir los pasos de las secciones de este artículo:
Si todavía no tiene una cuenta de Azure, regístrese para obtener una cuenta de evaluación gratuita.
Si usa el portal, abra [Link] e inicie sesión con la cuenta de Azure.
Si usa comandos de PowerShell para completar las tareas de este artículo, ejecute los comandos que se
encuentran en Azure Cloud Shell o ejecute PowerShell en el equipo. Azure Cloud Shell es un shell interactivo
gratuito que puede usar para ejecutar los pasos de este artículo. Tiene las herramientas comunes de Azure
preinstaladas y configuradas para usarlas en la cuenta. Para realizar este tutorial, se necesita la versión 1.0.0
del módulo de Azure PowerShell u otra posterior. Ejecute Get-Module -ListAvailable Az para buscar la
versión instalada. Si necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si
PowerShell se ejecuta localmente, también debe ejecutar Connect-AzAccount para crear una conexión con
Azure.
Si usa la interfaz de la línea de comandos (CLI) de Azure para completar las tareas de este artículo, ejecute
los comandos que se encuentran en Azure Cloud Shell o ejecute la CLI en el equipo. Para realizar este
tutorial es necesaria la versión 2.0.28 de la CLI de Azure o una versión posterior. Ejecute az --version para
buscar la versión instalada. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure. Si ejecuta
de forma local la CLI de Azure, también debe ejecutar az login para crear una conexión con Azure.
La cuenta en la que inicia sesión o con la que se conecta a Azure debe tener asignado el rol de colaborador de
red o un rol personalizado que tenga asignadas las acciones apropiadas en Permisos.
Crear una interfaz de red
Al crear una máquina virtual desde Azure Portal, este crea una interfaz de red con la configuración
predeterminada. Si prefiere especificar toda la configuración de la interfaz de red, puede crear una interfaz de
red con una configuración personalizada y asociar la interfaz de red a una máquina virtual al crear esta última
(con PowerShell o la CLI de Azure). También puede crear una interfaz de red y agregarla a una máquina virtual
existente (con PowerShell o la CLI de Azure). Para información sobre cómo crear una máquina virtual con una
interfaz de red existente, o cómo agregar o quitar interfaces de red en máquinas virtuales existentes, consulte el
artículo Adición o eliminación de interfaces de red. En la misma ubicación y suscripción donde vaya a crear la
interfaz de red, debe tener previamente una red virtual.
1. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba
interfaces de red. Cuando aparezcan las interfaces de red en los resultados de búsqueda, selecciónelas.
2. Seleccione + Agregar en Interfaces de red .
3. Escriba o seleccione valores para las siguientes opciones y seleccione Crear :

C O N F IGURA C IÓ N ¿N EC ESA RIO ? DETA L L ES

Nombre Sí El nombre debe ser único dentro del

grupo de recursos que seleccione.
Con el tiempo, probablemente
tendrá varias interfaces de red en la
suscripción de Azure. Para recibir
sugerencias sobre la creación de
convenciones de nomenclatura para
facilitar la administración de varias
interfaces de red, consulte
Convenciones de nomenclatura. El
nombre no se puede cambiar una
vez creada la interfaz de red.

Virtual network Sí Seleccione la red virtual para la

interfaz de red. Solo se puede
asignar una interfaz de red a una
red virtual que exista en la misma
suscripción y ubicación que la
interfaz de red. Una vez creada la
interfaz de red, no se puede cambiar
la red virtual a la que está asignada.
La máquina virtual que se agrega a
la interfaz de red también debe
existir en la misma ubicación y
suscripción que la interfaz de red.

Subnet Sí Seleccione una subred dentro de la

red virtual que seleccionó. Puede
cambiar la subred a la que está
asignada la interfaz de red después
de crearla.
C O N F IGURA C IÓ N ¿N EC ESA RIO ? DETA L L ES

Asignación de la dirección IP Sí En esta configuración, va a elegir el

privada método de asignación para la
dirección IPv4. Elija entre los
siguientes métodos de asignación:
Dinámica: al seleccionar esta
opción, Azure asigna
automáticamente la siguiente
dirección disponible del espacio de
direcciones de la subred
seleccionada. Estática: al
seleccionar esta opción, debe
asignar manualmente una dirección
IP disponible del espacio de
direcciones de la subred
seleccionada. Las direcciones
estática y dinámica no cambian
hasta que usted realice algún
cambio elimine la interfaz de red.
Una vez creada la interfaz de red,
puede cambiar el método de
asignación. El servidor DHCP de
Azure asigna esta dirección a la
interfaz de red en el sistema
operativo de la máquina virtual.

Grupo de seguridad de red No Déjelo establecido en Ninguno ,

seleccione un grupo de seguridad
de red existente o cree uno. Los
grupos de seguridad de red
permiten filtrar el tráfico de red
hacia y desde una interfaz de red.
Puede aplicar un grupo de
seguridad de red, o ninguno, a una
interfaz de red. También puede
aplicar un grupo de seguridad de
red, o ninguno, a la subred a la que
está asignada la interfaz de red.
Cuando un grupo de seguridad de
red se aplica a una interfaz de red y
a la subred a la que está asignada la
interfaz de red, en ocasiones se
producen resultados inesperados.
Para solucionar problemas de los
grupos de seguridad de red
aplicados a interfaces de red y
subredes, consulte Solución de
problemas de grupos de seguridad
de red.

Subscription Sí Seleccione una de las suscripciones

de Azure. La máquina virtual
asociada a una interfaz de red y la
red virtual a la que está conectada
deben existir en la misma
suscripción.
 C O N F IGURA C IÓ N ¿N EC ESA RIO ? DETA L L ES

Dirección IP privada (IPv6) No Si activa esta casilla, se asigna una

dirección IPv6 a la interfaz de red,
además de la dirección IPv4 ya
asignada. Consulte la sección IPv6
de este artículo para obtener
información importante sobre el
uso de IPv6 con interfaces de red.
No se puede seleccionar un método
de asignación a la dirección IPv6. Si
desea asignar una dirección IPv6,
hay que asignarla con el método
dinámico.

Nombre de IPv6 (solo aparece Sí, si la casilla Dirección IP Este nombre se asigna a una
cuando la casilla Dirección IP privada (IPv6) está activada. configuración IP secundaria de la
privada (IPv6) está activada) interfaz de red. Para más
información sobre las
configuraciones de IP, consulte
Visualización de la configuración de
la interfaz de red.

Resource group Sí Seleccione un grupo de recursos

existente o cree uno. La interfaz de
red puede existir en el mismo grupo
de recursos que la máquina virtual a
la que está asociada o conectada, o
en otro.

Location Sí La máquina virtual asociada a una

interfaz de red y la red virtual a la
que está conectada deben existir en
la misma ubicación, que también se
conoce como región.

El portal no proporciona la opción de asignar una dirección IP pública a la interfaz de red al crearla, aunque el
portal crea una dirección IP pública y la asigna a una interfaz de red cuando se crea una máquina virtual
mediante el portal. Para aprender a agregar una dirección IP pública a la interfaz de red después de crearla,
consulte Administración de direcciones IP. Si desea crear una interfaz de red con una dirección IP pública, debe
utilizar la CLI o PowerShell para crearla.
El portal no proporciona la opción de asignar una interfaz de red a los grupos de seguridad de aplicaciones al
crear una interfaz de red, pero la CLI de Azure y PowerShell sí. Sin embargo, puede asignar una interfaz de red
existente a un grupo de seguridad de aplicaciones mediante el portal, siempre que la interfaz de red esté
asociada a una máquina virtual. Para aprender a asignar una interfaz de red a un grupo de seguridad de
aplicaciones, consulte Adición o eliminación de grupos de seguridad de aplicaciones.

NOTE
Azure asigna una dirección MAC a la interfaz de red solo después de asociar la interfaz de red a una máquina virtual y
que esta se inicie la primera vez. No se puede especificar la dirección MAC que Azure asigna a la interfaz de red. La
dirección MAC permanece asignada a la interfaz de red hasta que esta se elimina o se cambia la dirección IP privada
asignada a la configuración de IP principal de la interfaz de red principal. Para más información sobre las direcciones IP y
las configuraciones IP, consulte Administración de direcciones IP.

Comandos
 H ERRA M IEN TA GET - H EL P

CLI az network nic create

PowerShell New-AzNetworkInterface

Visualización de la configuración de la interfaz de red

Puede ver y cambiar la mayoría de las opciones de una interfaz de red después de crearla. El portal no muestra
el sufijo DNS ni la pertenencia a grupos de seguridad de aplicaciones para la interfaz de red. Puede usar los
comandos de PowerShell o de la CLI de Azure para ver el sufijo DNS y la pertenencia a grupos de seguridad de
aplicaciones.
1. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba interfaces de
red. Cuando aparezcan las interfaces de red en los resultados de búsqueda, selecciónelas.
2. En la lista, seleccione la interfaz de red para la que quiere ver o cambiar la configuración.
3. Se muestran los elementos siguientes para la interfaz de red seleccionada:
Información general: proporciona información acerca de la interfaz de red, como las
direcciones IP asignadas a ella, la red o subred virtual a la que está asignada la interfaz de red y la
máquina virtual a la que está asociada la interfaz de red (si está asociada a una). La siguiente
imagen muestra la configuración de información general de una interfaz de red llamada
mywebser ver256 :

Una interfaz de red se puede mover a un grupo de recursos o una suscripción diferentes; para
ello, es preciso seleccionar (cambiar ) junto a Grupo de recursos o Nombre de la
suscripción . Si mueve la interfaz de red, debe mover con ella todos sus recursos relacionados.
Por ejemplo, si la interfaz de red está asociada a una máquina virtual, también debe mover la
máquina virtual y otros recursos relacionados con ella. Para trasladar una interfaz de red, consulte
cómo mover recursos a un nuevo grupo de recursos o suscripción. En el artículo se enumeran los
requisitos previos y se indica cómo trasladar recursos mediante Azure Portal, PowerShell y la CLI
de Azure.
Configuraciones IP: las direcciones IPv4 e IPv6 públicas y privadas asignadas a las
configuraciones IP se enumeran aquí. Si se asigna una dirección IPv6 a una configuración de IP, la
dirección no se muestra. Para más información sobre las configuraciones de IP y cómo agregar y
quitar direcciones IP, consulte cómo configurar direcciones IP para una interfaz de red de Azure. El
reenvío de IP y la asignación de subred también se configuran en esta sección. Para más
información sobre estos valores de configuración, consulte Habilitación o deshabilitación del
reenvío IP y Cambio de la asignación de subred.
Ser vidores DNS: puede especificar a qué servidor DNS asignarán una interfaz de red los
servidores DHCP de Azure. La configuración de la red virtual puede heredar la configuración de la
 red virtual a la que está asignada la interfaz de red, o tener una configuración personalizada que
reemplaza la configuración de la red virtual a la que está asignada. Para modificar lo que se
muestra, consulte Cambio de los servidores DNS.
Grupo de seguridad de red (NSG): muestra el grupo de seguridad de red asociado a la
interfaz de red (en caso de haberlos). Un grupo de seguridad de red contiene reglas de entrada y
salida para filtrar el tráfico de red de la interfaz de red. Si hay un grupo de seguridad de red
asociado a la interfaz de red, se muestra el nombre del grupo de seguridad de red asociado. Para
modificar lo que se muestra, consulte Associate or dissociate a network security group (Asociar o
desasociar un grupo de seguridad de red).
Propiedades: muestra las opciones de configuración clave de la interfaz de red, incluida la
dirección MAC (en blanco si la interfaz de red no está asociada a una máquina virtual) y la
suscripción donde se encuentra.
Reglas de seguridad vigentes: las reglas de seguridad se muestran si la interfaz de red está
asociada a una máquina virtual en ejecución y hay un grupo de seguridad de red asociado a la
interfaz de red, a la subred a la que está asignada o ambas. Para obtener más información sobre
lo que se muestra, consulte Visualización de las reglas de seguridad vigentes. Para más
información sobre los grupos de seguridad de red, consulte Grupos de seguridad de red.
Rutas vigentes: las rutas se muestran si la interfaz de red está asociada a una máquina virtual
en ejecución. Las rutas son una combinación de las rutas predeterminadas de Azure, las rutas
definidas por el usuario y las rutas BGP que pueda haber en la subred a la cual está asignada la
interfaz de red. Para obtener más información sobre lo que se muestra, consulte View effective
routes (Visualización de rutas vigentes). Para obtener más información sobre las rutas
predeterminadas de Azure y las rutas definidas por el usuario, consulte Routing overview
(Información general sobre enrutamiento). Opciones comunes de Azure Resource Manager: para
más información acerca de las opciones de configuración comunes de Azure Resource Manager,
consulte Registro de actividad, Control de acceso (IAM), Etiquetas, Bloqueos y Script de
Automation.
Comandos
Si se asigna una dirección IPv6 a una interfaz de red, la salida de PowerShell devuelve el hecho de que la
dirección está asignada, pero no devuelve la dirección asignada. De forma similar, la CLI devuelve el hecho de
que la dirección está asignada, pero devuelve null en su salida para la dirección.

H ERRA M IEN TA GET - H EL P

CLI az network nic list para ver las interfaces de red en la

suscripción; az network nic show para ver la configuración
de una interfaz de red

PowerShell Get-AzNetworkInterface para ver las interfaces de red de la

suscripción o ver la configuración de una interfaz de red

Cambio de los servidores DNS

El servidor DHCP de Azure asigna el servidor DNS a la interfaz de red en el sistema operativo de la máquina
virtual. El servidor DNS asignado tiene la configuración de servidor DNS de la interfaz de red. Para más
información sobre las opciones de resolución de nombres de una interfaz de red, consulte el artículo
Resolución de nombres de máquinas virtuales. La interfaz de red puede heredar la configuración de la red
virtual o utilizar sus propias opciones que reemplacen las de la red virtual.
1. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba interfaces de
 red. Cuando aparezcan las interfaces de red en los resultados de búsqueda, selecciónelas.
2. En la lista, seleccione la interfaz de red cuyo servidor DNS quiere cambiar.
3. Seleccione Ser vidores DNS , en CONFIGURACIÓN .
4. Seleccione:
Heredar de la red vir tual : elija esta opción para heredar la configuración del servidor DNS
definida para la red virtual a la que está asignada la interfaz de red. En el nivel de red virtual, se define
un servidor DNS personalizado o el servidor DNS proporcionado por Azure. El servidor DNS
proporcionado por Azure puede resolver los nombres de host de los recursos asignados a la misma
red virtual. Para resolver los recursos asignados a otras redes virtuales, debe utilizarse FQDN.
Personalizado : puede configurar su propio servidor DNS para resolver nombres en diferentes redes
virtuales. Escriba la dirección IP del servidor que desea usar como servidor DNS. La dirección del
servidor DNS especificado se asigna solo a esta interfaz de red y reemplaza cualquier configuración
DNS de la red virtual a la que está asignada la interfaz de red.

NOTE
Si la máquina virtual usa una tarjeta de interfaz de red que forma parte de un conjunto de disponibilidad,
se heredarán todos los servidores DNS que se especifican para cada una de las máquinas virtuales de
todas las tarjetas de interfaz de red que forman parte del conjunto de disponibilidad.

5. Seleccione Guardar .
Comandos

H ERRA M IEN TA GET - H EL P

CLI az network nic update

PowerShell Set-AzNetworkInterface

Habilitación o deshabilitación del reenvío IP

El reenvío IP permite a la máquina virtual a la que está asociada la interfaz de red:
Recibir tráfico de red no destinado a una de las direcciones IP asignadas a cualquiera de las configuraciones
de IP asignadas a la interfaz de red.
Enviar tráfico de red con una dirección IP de origen diferente de la asignada a una de las configuraciones de
IP de la interfaz de red.
La configuración debe estar habilitada para cada interfaz de red que esté asociada a la máquina virtual que
recibe el tráfico y que esta debe reenviar. Una máquina virtual puede reenviar el tráfico si tiene varias interfaces
de red o una sola interfaz de red asociada a él. Aunque el reenvío IP es una configuración de Azure, la máquina
virtual también debe ejecutar una aplicación que pueda reenviar el tráfico, como aplicaciones de firewall, de
optimización de WAN o de equilibrio de carga. Cuando una máquina virtual está ejecutando aplicaciones de
red, la máquina virtual suele denominarse aplicación virtual de red. Puede ver una lista de las aplicaciones
virtuales de red listas para su implementación en Azure Marketplace. El reenvío IP normalmente se usa con
rutas definidas por el usuario. Para más información sobre las rutas definidas por el usuario, consulte Rutas
definidas por el usuario.
1. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba interfaces de
red. Cuando aparezcan las interfaces de red en los resultados de búsqueda, selecciónelas.
2. Seleccione la interfaz de red para la que quiere habilitar o deshabilitar el reenvío de IP.
3. Seleccione Configuraciones IP en la sección CONFIGURACIÓN .
4. Seleccione Habilitado o Deshabilitado (valor predeterminado) para cambiar la configuración.
5. Seleccione Guardar .
Comandos

H ERRA M IEN TA GET - H EL P

CLI az network nic update

PowerShell Set-AzNetworkInterface

Cambio de la asignación de subred

Puede cambiar la subred, pero no la red virtual, a la que está asignada una interfaz de red.
1. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba interfaces de
red. Cuando aparezcan las interfaces de red en los resultados de búsqueda, selecciónelas.
2. Seleccione la interfaz de red para la que quiere cambiar la asignación de subred.
3. Seleccione Configuraciones IP en CONFIGURACIÓN . Si junto a las direcciones IP privadas de las
configuraciones de IP que se enumeran aquí aparece (Estático) , debe seguir los pasos a continuación y así
cambiar al método dinámico de asignación de direcciones IP. Para cambiar la asignación de subred para la
interfaz de red de todas las direcciones IP privadas, es obligatorio el método dinámico de asignación. Si las
direcciones se han asignado con el método dinámico, vaya al paso cinco. Si se asignó alguna dirección IPv4
con el método estático, complete los pasos siguientes para cambiar al método de asignación dinámico:
En la lista de configuraciones de IP, seleccione la configuración de IP cuyo método de asignación de
direcciones IPv4 desea cambiar.
Seleccione Dinámico como el método de asignación de direcciones IP privadas. No se puede
asignar una dirección IPv6 con el método de asignación estático.
Seleccione Guardar .
4. En la lista desplegable Subred , seleccione la subred a la que quiere mover la interfaz de red.
5. Seleccione Guardar . Las nuevas direcciones dinámicas se asignan a partir del intervalo de direcciones de la
subred nueva. Una vez asignada la interfaz de red a una nueva subred, si lo prefiere, podrá asignar
direcciones IPv4 estáticas del nuevo intervalo de direcciones de subred. Para más información sobre cómo
agregar, cambiar y quitar direcciones IP en una interfaz de red, consulte Administración de direcciones IP.
Comandos

H ERRA M IEN TA GET - H EL P

CLI az network nic ip-config update

PowerShell Set-AzNetworkInterfaceIpConfig

Adición o eliminación de grupos de seguridad de aplicaciones

Solo puede agregar o quitar una interfaz de red de un grupo de seguridad de aplicaciones mediante el portal si
la interfaz de red está asociada a una máquina virtual. Puede usar PowerShell o la CLI de Azure para agregar o
quitar una interfaz de red de un grupo de seguridad de aplicaciones si la interfaz de red está asociada o no a
una máquina virtual. Para más información sobre los grupos de seguridad de aplicaciones, consulte el artículo
sobre cómo crear un grupo de seguridad de aplicaciones.
1. En el cuadro Buscar recursos, servicios y documentos en la parte superior del portal, comience a escribir el
 nombre de una máquina virtual que tenga una interfaz de red que desee agregar o quitar de un grupo de
seguridad de aplicaciones. Cuando el nombre de la máquina virtual aparezca en los resultados de búsqueda,
selecciónelo.
2. En CONFIGURACIÓN , seleccione Redes . Seleccione Grupos de seguridad de aplicación , después
Configurar grupos de seguridad de aplicación , seleccione los grupos de seguridad de la aplicación a
los que desee agregar la interfaz de red o anule la selección de los grupos de seguridad de la aplicación de
los que desee quitar la interfaz de red y, a continuación, seleccione Guardar . Solo las interfaces de red que
existen en la misma red virtual se pueden agregar al mismo grupo de seguridad de aplicaciones. El grupo de
seguridad de aplicaciones debe existir en la misma ubicación que la interfaz de red.
Comandos

H ERRA M IEN TA GET - H EL P

CLI az network nic update

PowerShell Set-AzNetworkInterface

Asociación o desasociación de un grupo de seguridad de red

1. En el cuadro de búsqueda que aparece en la parte superior del portal, escriba network interfaces. Cuando
aparezcan las interfaces de red en los resultados de búsqueda, selecciónelas.
2. Seleccione la interfaz de red de la lista a la que quiera asociar o de la que quiera desasociar un grupo de
seguridad.
3. Seleccione Grupo de seguridad de red en CONFIGURACIÓN .
4. Seleccione Editar .
5. Seleccione Grupo de seguridad de red y, a continuación, seleccione el grupo de seguridad de red que
quiere asociar a la interfaz de red, o bien seleccione Ninguno para desasociar un grupo de seguridad de
red.
6. Seleccione Guardar .
Comandos
CLI de Azure: az network nic update
PowerShell: Set-AzNetworkInterface

Eliminar una interfaz de red

Puede eliminar una interfaz de red siempre y cuando no esté asociada a una máquina virtual. Si una interfaz de
red está asociada a una máquina virtual, primero debe cambiar el estado de la máquina virtual a detenido
(desasignado) y, después, desasociar la interfaz de red de la máquina virtual. Para desasociar una interfaz de red
de una máquina virtual, complete los pasos que se indican en Desasociar una interfaz de red de una máquina
virtual. Sin embargo, no se puede desasociar una interfaz de red de una máquina virtual si es la única interfaz
de red asociada a la máquina virtual. Una máquina virtual debe tener siempre una interfaz de red asociada
como mínimo. Al eliminar una máquina virtual, se desasocian todas las interfaces de red asociadas a ella, pero
no se eliminan las interfaces de red.
1. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba interfaces de
red. Cuando aparezcan las interfaces de red en los resultados de búsqueda, selecciónelas.
2. Seleccione la interfaz de red en la lista que quiere eliminar.
3. En Información general , seleccione Eliminar .
4. Seleccione Sí para confirmar la eliminación de la interfaz de red.
Cuando se elimina una interfaz de red, se liberan las direcciones MAC o IP asignadas a ella.
Comandos

H ERRA M IEN TA GET - H EL P

CLI az network nic delete

PowerShell Remove-AzNetworkInterface

Resolución de problemas de conectividad

Si no puede comunicarse con o desde una máquina virtual, es posible que las reglas de seguridad del grupo de
seguridad de red o las rutas vigentes de una interfaz de red provoquen el problema. Las siguientes opciones
pueden ayudarle a resolver el problema:
Visualización de las reglas de seguridad vigentes
Las reglas de seguridad vigentes de cada interfaz de red asociada a una máquina virtual son una combinación
de las reglas que ha creado en un grupo de seguridad de red y las reglas de seguridad predeterminadas.
Comprender las reglas de seguridad vigentes de una interfaz de red puede ayudarle a determinar por qué no se
puede comunicar con o desde una máquina virtual. Puede ver las reglas vigentes de cualquier interfaz de red
asociada a una máquina virtual en ejecución.
1. En el cuadro de búsqueda que se encuentra en la parte superior del portal, escriba el nombre de una
máquina virtual cuyas reglas de seguridad vigentes quiera ver. Si no conoce el nombre de una máquina
virtual, escriba máquinas virtuales en el cuadro de búsqueda. Cuando la opción Máquinas vir tuales
aparezca en los resultados de la búsqueda, selecciónela y, después, seleccione una máquina virtual en la
lista.
2. Seleccione Redes en CONFIGURACIÓN .
3. Seleccione el nombre de una interfaz de red.
4. Seleccione Reglas de seguridad vigentes en SOPORTE TÉCNICO Y SOLUCIÓN DE PROBLEMAS .
5. Revise la lista de reglas de seguridad vigentes para determinar si existen las reglas correctas para la
comunicación necesaria entrante y saliente. Obtenga más información sobre lo que se ve en la lista en
Información general sobre el grupo de seguridad de red.
La característica de comprobación del flujo de IP de Azure Network Watcher también puede ayudarle a
determinar si las reglas de seguridad impiden la comunicación entre una máquina virtual y un punto de
conexión. Para obtener más información, consulte IP flow verify (Comprobación del flujo de IP).
Comandos
CLI de Azure: az network nic list-effective-nsg
PowerShell: Get-AzEffectiveNetworkSecurityGroup
Vista de las rutas eficaces
Las rutas vigentes de las interfaces de red asociadas a una máquina virtual son una combinación de las rutas
predeterminadas, las rutas que creó y cualquier ruta propagada desde las redes locales vía BGP a través de una
puerta de enlace de red virtual de Azure. Comprender las rutas vigentes de una interfaz de red puede ayudarle
a determinar por qué no se puede comunicar con o desde una máquina virtual. Puede ver las rutas eficaces de
cualquier interfaz de red conectada a una máquina virtual en ejecución.
1. En el cuadro de búsqueda que se encuentra en la parte superior del portal, escriba el nombre de una
máquina virtual cuyas reglas de seguridad vigentes quiera ver. Si no conoce el nombre de una máquina
virtual, escriba máquinas virtuales en el cuadro de búsqueda. Cuando la opción Máquinas vir tuales
 aparezca en los resultados de la búsqueda, selecciónela y, después, seleccione una máquina virtual en la
lista.
2. Seleccione Redes en CONFIGURACIÓN .
3. Seleccione el nombre de una interfaz de red.
4. Seleccione Rutas eficaces en SOPORTE Y SOLUCIÓN DE PROBLEMAS .
5. Revise la lista de rutas vigentes para determinar si existen las rutas correctas para la comunicación necesaria
entrante y saliente. Obtenga más información sobre lo que ve en la lista en Routing overview (Información
general sobre enrutamiento).
La característica de próximo salto de Azure Network Watcher también puede ayudarle a determinar si las rutas
impiden la comunicación entre una máquina virtual y un punto de conexión. Para obtener más información,
consulte Próximo salto.
Comandos
CLI de Azure: az network nic show-effective-route-table
PowerShell: Get-AzEffectiveRouteTable

Permisos
Para realizar tareas en interfaces virtuales, su cuenta debe estar asignada al rol de colaborador de red o a un rol
personalizado que tenga asignados los permisos adecuados que se muestran en la tabla siguiente:

A C C IÓ N N O M B RE

[Link]/networkInterfaces/read Obtener interfaz de red

[Link]/networkInterfaces/write Crear o actualizar una interfaz de red

[Link]/networkInterfaces/join/action Adjuntar una interfaz de red a una máquina virtual

[Link]/networkInterfaces/delete Eliminar la interfaz de red

[Link]/networkInterfaces/joinViaPrivateIp/action Unir un recurso a una interfaz de red a través de una

asociación de servicio

[Link]/networkInterfaces/effectiveRouteTable/act Obtener una tabla de rutas eficaces de interfaz de red

ion

[Link]/networkInterfaces/effectiveNetworkSecuri Obtener grupos de seguridad eficaces de interfaz de red

tyGroups/action

[Link]/networkInterfaces/loadBalancers/read Obtener equilibradores de carga de interfaz de red

[Link]/networkInterfaces/serviceAssociations/re Obtener una asociación de servicio

ad

[Link]/networkInterfaces/serviceAssociations/wr Crear o actualizar una asociación de servicio

ite

[Link]/networkInterfaces/serviceAssociations/de Eliminar una asociación de servicio

lete
 A C C IÓ N N O M B RE

[Link]/networkInterfaces/serviceAssociations/val Validar una asociación de servicio

idate/action

[Link]/networkInterfaces/ipconfigurations/read Obtener una configuración de dirección IP de interfaz de red

Pasos siguientes
Crear una máquina virtual con varias NIC mediante la CLI de Azure o PowerShell
Crear una sola máquina virtual NIC con varias direcciones IPv4 mediante la CLI de Azure o PowerShell
Crear una sola máquina virtual NIC con una dirección IPv6 privada (detrás de una instancia de Azure Load
Balancer) mediante la CLI de Azure, PowerShell o una plantilla de Azure Resource Manager
Crear una interfaz de red con scripts de ejemplo de PowerShell o de la CLI de Azure o con una plantilla de
Azure Resource Manager
Crear y asignar definiciones de Azure Policy para redes virtuales
 Crear, cambiar o eliminar una red virtual
23/09/2020 • 28 minutes to read • Edit Online

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca
del nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.

Aprenda a crear y eliminar una red virtual, y a cambiar ajustes de configuración, como los servidores DNS y los
espacios de direcciones IP, en una red virtual existente. Si no está familiarizado con las redes virtuales, puede
obtener más información sobre ellas en la información general sobre redes virtuales o siguiendo un tutorial.
Una red virtual contiene subredes. Para aprender a crear, cambiar y eliminar subredes, vea Incorporación,
cambio o eliminación de una subred de red virtual.

Antes de empezar
Complete las tareas siguientes antes de seguir los pasos de las secciones de este artículo:
Si todavía no tiene una cuenta de Azure, regístrese para obtener una cuenta de evaluación gratuita.
Si usa el portal, abra [Link] e inicie sesión con la cuenta de Azure.
Si usa comandos de PowerShell para completar las tareas de este artículo, ejecute los comandos que se
encuentran en Azure Cloud Shell o ejecute PowerShell en el equipo. Azure Cloud Shell es un shell interactivo
gratuito que puede usar para ejecutar los pasos de este artículo. Tiene las herramientas comunes de Azure
preinstaladas y configuradas para usarlas en la cuenta. Para realizar este tutorial, se necesita la versión 1.0.0
del módulo de Azure PowerShell u otra posterior. Ejecute Get-Module -ListAvailable Az para buscar la
versión instalada. Si necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell
se ejecuta localmente, también debe ejecutar Connect-AzAccount para crear una conexión con Azure.
Si usa la interfaz de la línea de comandos (CLI) de Azure para completar las tareas de este artículo, ejecute los
comandos que se encuentran en Azure Cloud Shell o ejecute la CLI en el equipo. Para realizar este tutorial, es
necesaria la versión 2.0.31 de la CLI de Azure o una versión posterior. Ejecute az --version para buscar la
versión instalada. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure. Si ejecuta de forma
local la CLI de Azure, también debe ejecutar az login para crear una conexión con Azure.
La cuenta en la que inicia sesión o con la que se conecta a Azure debe tener asignado el rol de colaborador de
red o un rol personalizado que tenga asignadas las acciones apropiadas en Permisos.

Creación de una red virtual

1. Seleccione + Crear un recurso > Redes > Red vir tual .
2. Escriba o seleccione valores para las siguientes opciones y seleccione Crear :
Name : tiene que ser único en el grupo de recursos dentro del que seleccione crear la red virtual.
No se puede cambiar el nombre una vez creada la red virtual. Puede crear varias redes virtuales
con el tiempo. Vea Convenciones de nomenclatura para obtener sugerencias de nombres. El uso de
una convención de nomenclatura puede facilitar la administración de varias redes virtuales.
Espacio de direcciones : el espacio de direcciones de una red virtual se compone de uno o varios
intervalos de direcciones no superpuestos que se especifican en la notación CIDR. El rango de
direcciones que defina puede ser público o privado (RFC 1918). Tanto si se define el rango de
direcciones como público o como privado, el rango de direcciones es accesible solo desde dentro
de la red virtual, desde redes virtuales conectadas entre sí y desde las redes locales que se hayan
conectado a la red virtual. No se pueden agregar los siguientes rangos de direcciones:
[Link]/4 (multidifusión)
[Link]/32 (difusión)
[Link]/8 (bucle invertido)
[Link]/16 (local de vínculo)
[Link]/32 (sondeo de estado de DNS, DHCP y Azure Load Balancer internos)
Aunque solo se puede definir un único rango de direcciones cuando se crea la red virtual en el
portal, puede agregar varios rangos de direcciones al espacio de direcciones una vez creada la red
virtual. Para obtener información sobre cómo agregar un rango de direcciones a una red virtual
existente, consulte Agregar o quitar un rango de direcciones.

WARNING
Si una red virtual tiene rangos de direcciones que se superponen con otra red virtual o red local, las dos
redes no se pueden conectar. Antes de definir un rango de direcciones, tenga en cuenta si es posible que
en el futuro quiera conectar la red virtual a otras redes virtuales o redes locales. Microsoft recomienda
configurar los rangos de direcciones de red virtual con espacio de direcciones privadas o espacio de
direcciones públicas propiedad de la organización.

Nombre de subred : El nombre de la subred debe ser único dentro de la red virtual. El
nombre de subred no se puede cambiar después de crear la subred. El portal requiere que
se defina una subred al crear una red virtual, aunque una red virtual no necesita tener
ninguna subred. En el portal, solo se puede definir una subred cuando se crea una red
virtual. Puede agregar más subredes a la red virtual más adelante, una vez creada la red
virtual. Para agregar una subred a una red virtual, consulte Administrar subredes. Puede
crear una red virtual que tenga varias subredes mediante la CLI de Azure o PowerShell.

TIP
A veces, los administradores crean diferentes subredes para filtrar o controlar el enrutamiento de
tráfico entre ellas. Antes de definir subredes, considere cómo quiere filtrar y enrutar el tráfico entre
ellas. Para obtener más información sobre el filtrado de tráfico entre subredes, vea Grupos de
seguridad de red. Azure realiza el enrutamiento de tráfico entre subredes automáticamente, pero
puede invalidar las rutas predeterminadas de Azure. Para obtener más información acerca de cómo
enruta Azure el tráfico de subredes predeterminado, consulte Introducción al enrutamiento.

Rango de direcciones de subred : el intervalo debe estar dentro del espacio de

direcciones que especificó para la red virtual. El menor intervalo que se puede especificar es
/29, lo que proporciona ocho direcciones IP de subred. De conformidad con el protocolo,
Azure reserva la primera y la última dirección de cada subred. Otras tres direcciones están
reservadas para el uso del servicio de Azure. Como resultado, una red virtual con un
intervalo de direcciones de subred de /29 tiene solo tres direcciones IP utilizables. Si planea
conectar una red virtual a una puerta de enlace VPN, debe crear una subred de puerta de
enlace. Más información sobre las consideraciones específicas del intervalo de direcciones
de las subredes de puerta de enlace. En determinadas circunstancias se puede cambiar el
intervalo de direcciones una vez creada la subred. Para obtener información sobre cómo
cambiar un rango de direcciones de subred, consulte Administrar subredes.
 Suscripción : Seleccione una suscripción. No se puede usar la misma red virtual en más de
una suscripción de Azure. Sin embargo, puede conectar la red virtual de una suscripción a
las redes virtuales de otras suscripciones mediante el emparejamiento de redes virtuales.
Cualquier recurso de Azure que se conecte a la red virtual debe estar en la misma
suscripción que la red virtual.
Grupo de recursos : Seleccione un grupo de recursos existente, o bien cree uno. Un
recurso de Azure que se conecta a la red virtual puede estar en el mismo grupo de recursos
que la red virtual o en otro diferente.
Ubicación : seleccione una ubicación de Azure, también conocida como región. Una red
virtual solo puede estar en una ubicación de Azure. Pero se puede conectar una red virtual
en una ubicación a una red virtual en otra ubicación mediante el uso de VPN Gateway.
Cualquier recurso de Azure que se conecte a la red virtual debe estar en la misma ubicación
que la red virtual.
Comandos
CLI de Azure: az network vnet create
PowerShell: New-AzVirtualNetwork

Ver las redes virtuales y su configuración

1. En el cuadro de búsqueda de la parte superior del portal, escriba redes virtuales. Cuando aparezca la opción
Redes vir tuales en los resultados de la búsqueda, selecciónela.
2. En la lista de redes virtuales, seleccione la red virtual de la cual quiera ver la configuración.
3. Los siguientes ajustes de configuración se muestran en la red virtual seleccionada:
Información general : proporciona información sobre la red virtual, incluido el espacio de
direcciones y los servidores DNS. En la siguiente captura de pantalla se muestra la configuración
de información general de una red virtual denominada MyVNet :
 Puede llevar una red virtual a una suscripción o grupo de recursos diferente si selecciona la opción
Cambiar que se encuentra junto a Grupo de recursos o Nombre de la suscripción . Para
obtener información sobre cómo mover una red virtual, vea Traslado de los recursos a un nuevo
grupo de recursos o a una nueva suscripción. En el artículo se enumeran los requisitos previos y se
indica cómo trasladar recursos mediante Azure Portal, PowerShell y la CLI de Azure. Todos los
recursos que están conectados a la red virtual se deben mover con la red virtual.
Espacio de direcciones : se enumeran los espacios de direcciones asignados a la red virtual. Para
obtener información sobre cómo agregar y quitar un rango de direcciones de un espacio de
direcciones, complete los pasos de la sección Agregar o quitar un rango de direcciones.
Dispositivos conectados : se muestran todos los recursos que están conectados a la red virtual.
En la captura de pantalla anterior, hay tres interfaces de red y un equilibrador de carga conectados
a la red virtual. Se muestran todos los nuevos recursos que se creen y conecten a la red virtual. Si
elimina un recurso que estaba conectado a la red virtual, ya no aparecerá en la lista.
Subredes : se muestra una lista de las subredes que existen dentro de la red virtual. Para obtener
información sobre cómo agregar y quitar una subred, consulte Administrar subredes.
Ser vidores DNS : puede especificar si el servidor DNS interno de Azure o un servidor DNS
personalizado proporciona resolución de nombres para los dispositivos que están conectados a la
red virtual. Al crear una red virtual mediante Azure Portal, los servidores DNS de Azure se usan
para la resolución de nombres dentro de una red virtual, de forma predeterminada. Para modificar
los servidores DNS, complete los pasos de la sección Cambiar servidores DNS de este artículo.
Emparejamientos : si hay emparejamientos existentes en la suscripción, estos aparecerán aquí.
Puede ver la configuración de emparejamientos existentes, o crear, cambiar o eliminar
emparejamientos. Para obtener más información sobre emparejamiento, vea Emparejamiento de
redes virtuales de Azure.
Propiedades : muestra la configuración de la red virtual, incluidos el identificador de recurso de la
red virtual y la suscripción de Azure en la que se encuentra.
Diagrama : el diagrama proporciona una representación visual de todos los dispositivos
conectados a la red virtual. El diagrama muestra alguna información clave sobre los dispositivos.
Para administrar un dispositivo en esta vista, vaya al diagrama y seleccione el dispositivo.
Configuración común de Azure : Para más información sobre la configuración común de Azure,
consulte la información siguiente:
Registro de actividad
Control de acceso (IAM)
Etiquetas
Bloqueos
Script de Automation
Comandos
CLI de Azure: az network vnet show
PowerShell: Get-AzVirtualNetwork

Agregar o quitar un rango de direcciones

Puede agregar y quitar rangos de direcciones de una red virtual. Un rango de direcciones tiene que especificarse
en una notación CIDR y no puede superponerse con otros rangos de direcciones dentro de la misma red virtual.
Los rangos de direcciones que defina pueden ser públicos o privados (RFC 1918). Tanto si se define el rango de
direcciones como público o como privado, el rango de direcciones es accesible solo desde dentro de la red
virtual, desde redes virtuales conectadas entre sí y desde las redes locales que se hayan conectado a la red
virtual.
Puede disminuir el intervalo de direcciones de una red virtual siempre y cuando siga incluyendo los intervalos
de las subredes asociadas. Además, puede extender el intervalo de direcciones, por ejemplo, cambiar de /16 a /8.
No se pueden agregar los siguientes rangos de direcciones:
[Link]/4 (multidifusión)
[Link]/32 (difusión)
[Link]/8 (bucle invertido)
[Link]/16 (local de vínculo)
[Link]/32 (sondeo de estado de DNS, DHCP y Azure Load Balancer internos)
Para agregar o quitar un rango de direcciones:
1. En el cuadro de búsqueda de la parte superior del portal, escriba redes virtuales. Cuando aparezca la opción
Redes vir tuales en los resultados de la búsqueda, selecciónela.
2. En la lista de redes virtuales, seleccione la red virtual para la que quiera agregar o quitar un rango de
direcciones.
3. En CONFIGURACIÓN , seleccione Espacio de direcciones .
4. Complete una de las siguientes opciones:
Agregar un inter valo de direcciones : Escriba el nuevo intervalo de direcciones. El rango de
direcciones no puede superponerse a un rango de direcciones ya existente y que esté definido para la
red virtual.
Quitar un inter valo de direcciones : a la derecha del intervalo de direcciones que quiera quitar,
seleccione ... y, a continuación, seleccione Quitar . Si existe una subred en el rango de direcciones, no
se puede quitar ese rango de direcciones. Para quitar un rango de direcciones, es necesario eliminar
primero las subredes que existen en ese rango de direcciones y todos los recursos conectados a las
subredes.
5. Seleccione Guardar .
Comandos
CLI de Azure: az network vnet update
PowerShell: Set-AzVirtualNetwork

Cambio de los servidores DNS

Todas las máquinas virtuales que están conectadas a la red virtual se registran con los servidores DNS que
especifique para la red virtual. También usan el servidor DNS especificado para la resolución de nombres. Cada
interfaz de red (NIC) en una máquina virtual puede tener su propia configuración de servidor DNS. Si una NIC
tiene su propia configuración de servidor DNS, esta invalida la configuración del servidor DNS para la red
virtual. Para obtener más información sobre la configuración de DNS de NIC, vea Configuración y tareas de la
interfaz de red. Para obtener más información sobre la resolución de nombres para las máquinas virtuales y las
instancias de rol de Azure Cloud Services, vea Resolución de nombres para las máquinas virtuales e instancias
de rol. Para agregar, cambiar o quitar un servidor DNS:
1. En el cuadro de búsqueda de la parte superior del portal, escriba redes virtuales. Cuando aparezca la opción
Redes vir tuales en los resultados de la búsqueda, selecciónela.
2. En la lista de redes virtuales, seleccione la red virtual en la cual quiera cambiar los servidores DNS.
3. Seleccione Ser vidores DNS , en CONFIGURACIÓN .
4. Seleccione una de las siguientes opciones:
 Predeterminado (proporcionado por Azure) : todos los nombres de los recursos y las direcciones
IP privadas se registran automáticamente en los servidores DNS de Azure. Puede resolver nombres
entre los recursos conectados a la misma red virtual. No se puede usar esta opción para resolver
nombres entre redes virtuales. Para resolver nombres de otras redes virtuales, tiene que usar un
servidor DNS personalizado.
Personalizado : puede agregar uno o varios servidores, hasta el límite de Azure para una red virtual.
Para obtener más información sobre los límites de servidor DNS, vea Límites de Azure. Tiene las
siguientes opciones:
Agregar una dirección : agrega el servidor a la lista de servidores DNS de la red virtual. Esta opción
también registra el servidor DNS con Azure. Si ya ha registrado un servidor DNS con Azure, puede
seleccionarlo en la lista.
Quitar una dirección : junto al servidor que quiere quitar, seleccione ... y, a continuación, Quitar .
Eliminar el servidor solo lo quita de esta lista de redes virtuales. El servidor DNS seguirá registrado en
Azure para que lo usen otras redes virtuales.
Reordenar direcciones de ser vidor DNS : es importante comprobar que se enumeran los
servidores DNS en el orden correcto para su entorno. Las listas de servidores DNS se usan en el orden
en que se especifican. No funcionan como una instalación round robin. Si se puede acceder al primer
servidor DNS de la lista, el cliente usa ese servidor DNS, con independencia de si el servidor DNS
funciona correctamente. Quite todos los servidores DNS que aparecen y vuelva a agregarlos en el
orden que desee.
Cambiar una dirección : resalte el servidor DNS en la lista y después escriba el nuevo nombre.
5. Seleccione Guardar .
6. Reinicie las máquinas virtuales conectadas a la red virtual para que se les asigne la nueva configuración de
servidor DNS. Hasta que se reinicien, las máquinas virtuales seguirán usando la configuración de DNS que
consideran actual.
Comandos
CLI de Azure: az network vnet update
PowerShell: Set-AzVirtualNetwork

Eliminar una red virtual

Solo se puede eliminar una red virtual si no tiene recursos conectados. Si hay recursos conectados a cualquier
subred dentro de la red virtual, primero tiene que eliminarlos. Los pasos necesarios para eliminar un recurso
varían según el recurso. Para obtener más información sobre cómo eliminar los recursos conectados a una
subred, lea la documentación de cada tipo de recurso que quiera eliminar. Para eliminar una red virtual:
1. En el cuadro de búsqueda de la parte superior del portal, escriba redes virtuales. Cuando aparezca la opción
Redes vir tuales en los resultados de la búsqueda, selecciónela.
2. En la lista de redes virtuales, seleccione la red virtual que quiere eliminar.
3. En CONFIGURACIÓN , seleccione Dispositivos conectados para confirmar que no haya dispositivos
conectados a la red virtual. Si hay dispositivos conectados, primero debe eliminarlos antes de poder eliminar
la red virtual. Si no hay ningún dispositivo conectado, seleccione Información general .
4. Seleccione Eliminar .
5. Para confirmar la eliminación de la red virtual, seleccione Sí .
Comandos
CLI de Azure: azure network vnet delete
PowerShell: Remove-AzVirtualNetwork
Permisos
Para realizar tareas en redes virtuales, su cuenta debe estar asignada al rol de colaborador de red o a un rol
personalizado que tenga asignadas las acciones adecuadas que se muestran en la tabla siguiente:

A C C IÓ N N O M B RE

[Link]/virtualNetworks/read Leer una red virtual

[Link]/virtualNetworks/write Crear o actualizar una red virtual

[Link]/virtualNetworks/delete Eliminar una red virtual

Pasos siguientes
Crear una red virtual con scripts de ejemplo de PowerShell o de la CLI de Azure, o bien con plantillas de
Azure Resource Manager
Crear y asignar definiciones de Azure Policy para redes virtuales
 Incorporación, cambio o eliminación de una subred
de red virtual
23/09/2020 • 18 minutes to read • Edit Online

Obtenga información sobre la incorporación, la modificación o la eliminación de una subred de red virtual.
Todos los recursos de Azure implementados en una red virtual se implementan en una subred de esa red
virtual. Si no está familiarizado con las redes virtuales, puede obtener más información sobre ellas en la
información general sobre redes virtuales o siguiendo un inicio rápido. Para obtener más información sobre la
administración de una red virtual, consulte Crear, cambiar o eliminar una red virtual.

Antes de empezar
Si no tiene ninguna, configure una cuenta de Azure con una suscripción activa. Cree una cuenta gratuita.
Después, complete una de estas tareas antes de iniciar los pasos de cualquiera de las secciones de este artículo:
Usuarios de Por tal : Inicie sesión en Azure Portal con su cuenta de Azure.
Usuarios de PowerShell : ejecute los comandos en Azure Cloud Shell, o bien ejecute PowerShell en el
equipo. Azure Cloud Shell es un shell interactivo gratuito que puede usar para ejecutar los pasos de este
artículo. Tiene las herramientas comunes de Azure preinstaladas y configuradas para usarlas en la
cuenta. En la pestaña del explorador Azure Cloud Shell, busque la lista desplegable Seleccionar
entorno y, después, elija PowerShell si aún no está seleccionado.
Si ejecuta PowerShell en el entorno local, use la versión del módulo de Azure PowerShell 1.0.0 o una
posterior. Ejecute Get-Module -ListAvailable [Link] para buscar la versión instalada. Si necesita
actualizarla, consulte Instalación del módulo de Azure PowerShell. Ejecute también Connect-AzAccount
para crear una conexión con Azure.
Usuarios de la interfaz de la línea de comandos (CLI) de Azure : ejecute los comandos en Azure
Cloud Shell, o bien ejecute la CLI en el equipo. Use la versión 2.0.31 de la CLI de Azure o una posterior si
ejecuta la CLI de Azure en el entorno local. Ejecute az --version para buscar la versión instalada. Si
necesita instalarla o actualizarla, vea Instalación de la CLI de Azure. Además, ejecute az login para crear
una conexión con Azure.
La cuenta en la que inicia sesión o con la que se conecta a Azure, debe tener asignado el rol de colaborador de
red o un rol personalizado que tenga asignadas las acciones apropiadas en Permisos.

Incorporación de una subred

1. Vaya a Azure Portal para ver las redes virtuales. Busque y seleccione Redes vir tuales .
2. Seleccione el nombre de la red virtual en la que quiera agregar una subred.
3. En Configuración , seleccione Subredes > Subred .
4. En el cuadro de diálogo Agregar subred , especifique valores para la configuración siguiente:

C O N F IGURA C IÓ N DESC RIP C IÓ N

C O N F IGURA C IÓ N DESC RIP C IÓ N

Nombre El nombre debe ser único dentro de la red virtual. Para

lograr la máxima compatibilidad con otros servicios de
Azure, se recomienda usar una letra como primer
carácter del nombre. Por ejemplo, Azure Application
Gateway no se implementará en una subred que tiene
un nombre que comienza con un número.

Inter valo de direcciones El intervalo debe ser único dentro del espacio de
direcciones de la red virtual. Este intervalo no puede
superponerse con otros intervalos de direcciones de
subred dentro de la red virtual. El espacio de
direcciones debe especificarse mediante notación de
Enrutamiento de interdominios sin clases (CIDR).
Por ejemplo, en una red virtual con el espacio de
direcciones [Link]/16, podría definir el espacio de
direcciones de subred [Link]/22. El menor
intervalo que se puede especificar es /29, lo que
proporciona ocho direcciones IP de subred. De
conformidad con el protocolo, Azure reserva la
primera y la última dirección de cada subred. Otras
tres direcciones están reservadas para el uso del
servicio de Azure. Como resultado, al definir una
subred con el intervalo de direcciones /29, se
generan tres direcciones IP utilizables en la subred.
Si planea conectar una red virtual a una puerta de
enlace VPN, debe crear una subred de puerta de
enlace. Más información sobre las consideraciones
específicas del intervalo de direcciones de las
subredes de puerta de enlace. En determinadas
circunstancias se puede cambiar el intervalo de
direcciones una vez agregada la subred. Para
información sobre cómo cambiar un intervalo de
direcciones de subred, consulte Cambio de
configuración de subred.

Grupo de seguridad de red Para filtrar el tráfico de red entrante y saliente de la

subred, puede asociar un grupo de seguridad de red
existente a una subred. El grupo de seguridad de red
debe existir en la misma suscripción y la misma
ubicación que la red virtual. Obtenga más información
sobre los grupos de seguridad de red y cómo crear un
grupo de seguridad de red.

Tabla de rutas Para controlar el enrutamiento del tráfico de red a otras

redes, puede asociar una tabla de rutas existente a una
subred. La tabla de rutas debe existir en la misma
suscripción y la misma ubicación que la red virtual.
Obtenga más información sobre el enrutamiento de
Azure y cómo crear una tabla de rutas.
 C O N F IGURA C IÓ N DESC RIP C IÓ N

Puntos de conexión de ser vicio Una subred puede tener uno o más puntos de
conexión de servicio habilitados. Para habilitar un
punto de conexión de servicio, seleccione el servicio
o los servicios para los que desea habilitar los
puntos de conexión en la lista de ser vicios . Azure
configura la ubicación automáticamente para un
punto de conexión. De forma predeterminada,
Azure configura los puntos de conexión de servicio
de la región de la red virtual. En el caso de Azure
Storage, para admitir escenarios de conmutación
por error regionales, Azure configura
automáticamente los puntos de conexión para las
regiones emparejadas de Azure.
Para quitar un punto de conexión de servicio, anule
la selección del servicio para el que desea quitar el
punto de conexión. Para obtener más información
sobre los puntos de conexión de servicio y sobre los
servicios para los que se pueden habilitar, vea
Puntos de conexión de servicio de red virtual. Una
vez que habilita un punto de conexión para un
servicio, también debe habilitar el acceso de red
para la subred de un recurso creado con el servicio.
Por ejemplo, si habilita el punto de conexión de
servicio para [Link] , también debe
habilitar el acceso de red a todas las cuentas de
Azure Storage a las que desea conceder acceso de
red. Para habilitar el acceso de red a las subredes
para las que está habilitado un punto de conexión
de servicio, consulte la documentación
correspondiente al servicio individual para el que
habilitó el punto de conexión de servicio.
Para validar que un punto de conexión de servicio
está habilitado para una subred, consulte las rutas
efectivas para cualquier interfaz de red de la subred.
Cuando configure un punto de conexión, verá una
ruta predeterminada con los prefijos de dirección del
servicio y el tipo de próximo salto
Vir tualNetworkSer viceEndpoint . Para obtener
más información sobre el enrutamiento, consulte
Enrutamiento del tráfico de redes virtuales.

Delegación de subred Una subred puede tener una o más delegaciones

habilitadas. La delegación de subred proporciona
permisos explícitos al servicio para crear los recursos
específicos del servicio en la subred con un identificador
único durante la implementación del servicio. Para
delegar a un servicio, seleccione el servicio al que desea
delegar en la lista Ser vicios .

5. Para agregar la subred a la red virtual que seleccionó, seleccione Aceptar .

Comandos:
H ERRA M IEN TA GET - H EL P

Azure CLI az network vnet subnet create

 H ERRA M IEN TA GET - H EL P

PowerShell Add-AzVirtualNetworkSubnetConfig

Modificación de la configuración de subred

1. Vaya a Azure Portal para ver las redes virtuales. Busque y seleccione Redes vir tuales .
2. Seleccione el nombre de la red virtual que contenga la subred que quiere cambiar.
3. En Configuración , seleccione Subredes .
4. En la lista de subredes, seleccione la subred para la que desea modificar la configuración.
5. En la página de subred, cambie cualquiera de las opciones de configuración siguientes:

C O N F IGURA C IÓ N DESC RIP C IÓ N

Inter valo de direcciones si no hay recursos implementados dentro de la subred,

es posible modificar el intervalo de direcciones. Si existe
algún recurso en la subred, primero deberá moverlos a
otra subred o eliminarlos. Los pasos necesarios para
mover o eliminar un recurso varían según el recurso.
Para obtener información sobre cómo mover o eliminar
los recursos que se encuentran en las subredes, lea la
documentación de cada uno de estos tipos de recursos.
Consulte cuáles son las restricciones de la configuración
Inter valo de direcciones en el paso 4 de la sección
Adición de una subred.

Usuarios puede controlar el acceso a la subred con los roles

integrados u otros personalizados. Para obtener más
información sobre la asignación de roles y usuarios para
el acceso a la subred, consulte Adición de una
asignación de roles.

Grupo de seguridad de red y Tabla de rutas Vea el paso 4 de la sección Adición de una subred.

Puntos de conexión de ser vicio Consulte los puntos de conexión de servicio del
paso 4 de la sección Adición de una subred. A la
hora de habilitar un punto de conexión de servicio
para una red existente, asegúrese de que no se esté
ejecutando ninguna tarea crítica en ningún recurso
de la subred. Los puntos de conexión de servicio
cambian las rutas en cada interfaz de red de la
subred. Los puntos de conexión de servicio pasan
de usar la ruta predeterminada con el prefijo de
dirección [Link]/0 y el tipo de próximo salto
Internet a usar una ruta nueva con los prefijos de
dirección del servicio y el tipo de próximo salto
VirtualNetworkServiceEndpoint.
Durante el cambio se puede terminar cualquier
conexión TCP que esté abierta. El punto de conexión
de servicio no se habilita hasta que los flujos de
tráfico al servicio de todas las interfaces de red se
actualicen con la nueva ruta. Para obtener más
información sobre el enrutamiento, consulte
Enrutamiento del tráfico de redes virtuales.
 C O N F IGURA C IÓ N DESC RIP C IÓ N

Delegación de subred Consulte los puntos de conexión de servicio del paso 4

de la sección Adición de una subred. La delegación de
subred se puede modificar a varias delegaciones
habilitadas para él o a ninguna. Si un recurso de un
servicio ya está implementado en la subred, la
delegación de la subred no se puede agregar ni quitar
hasta que se quiten todos los recursos del servicio. Para
delegar a otro servicio, seleccione el servicio al que
desea delegar en la lista Ser vicios .

6. Seleccione Guardar .
Comandos:
H ERRA M IEN TA GET - H EL P

Azure CLI az network vnet subnet update

PowerShell Set-AzVirtualNetworkSubnetConfig

Eliminación de una subred

Solo se puede eliminar una subred si no tiene recursos. Si hay recursos en la subred, debe eliminarlos para
poder eliminar la subred. Los pasos necesarios para eliminar un recurso varían según el recurso. Para obtener
información sobre cómo eliminar los recursos que se encuentran en las subredes, lea la documentación de
cada uno de estos tipos de recursos.
1. Vaya a Azure Portal para ver las redes virtuales. Busque y seleccione Redes vir tuales .
2. Seleccione el nombre de la red virtual que contenga la subred que quiere eliminar.
3. En Configuración , seleccione Subredes .
4. En la lista de subredes, seleccione la subred que quiere eliminar.
5. Seleccione Eliminar y, a continuación, seleccione Sí en el cuadro de diálogo de confirmación.
Comandos:
H ERRA M IEN TA GET - H EL P

Azure CLI az network vnet subnet delete

PowerShell Remove-AzVirtualNetworkSubnetConfig

Permisos
Para llevar a cabo tareas en subredes, su cuenta debe estar asignada al rol de colaborador de red o a un rol
personalizado que tenga asignadas las acciones adecuadas que se muestran en la tabla siguiente:

A C C IÓ N N O M B RE

[Link]/virtualNetworks/subnets/read Leer una subred de red virtual

 A C C IÓ N N O M B RE

[Link]/virtualNetworks/subnets/write Crear o actualizar una subred de red virtual

[Link]/virtualNetworks/subnets/delete Eliminar una subred de red virtual

[Link]/virtualNetworks/subnets/join/action Unirse a una red virtual

[Link]/virtualNetworks/subnets/joinViaServiceE Habilitar un punto de conexión de servicio para una subred

ndpoint/action

[Link]/virtualNetworks/subnets/virtualMachines Obtener las máquinas virtuales de una subred

/read

Pasos siguientes
Crear una red virtual y subredes con scripts de ejemplo de PowerShell o de la CLI de Azure o con plantillas
de Azure Resource Manager
Crear y asignar definiciones de Azure Policy para redes virtuales
 Adición o eliminación de una delegación de subred
23/09/2020 • 12 minutes to read • Edit Online

La delegación de subred proporciona permisos explícitos al servicio para crear los recursos específicos del servicio
en la subred con un identificador único al implementar el servicio. En este artículo se describe cómo agregar o
quitar una subred delegada en un servicio de Azure.

Portal
Inicio de sesión en Azure
Inicie sesión en Azure Portal en [Link]
Crear la red virtual
En esta sección, creará una red virtual y la subred que posteriormente delegará en un servicio de Azure.
1. En la parte superior izquierda de la pantalla, seleccione Crear un recurso > Redes > Red vir tual .
2. En Creación de una red vir tual , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Nombre Escriba MyVirtualNetwork.

Espacio de direcciones Escriba [Link]/16.

Subscription Seleccione su suscripción.

Resource group Seleccione Crear nuevo , escriba myResourceGroup y,

después, seleccione Aceptar .

Location Seleccione EastUS.

Subred: nombre Escriba mySubnet.

Subred: intervalo de direcciones Escriba [Link]/24.

3. Deje el resto de opciones con el valor predeterminado y seleccione Create (Crear).

Permisos
Si no ha creado la subred que desea delegar en un servicio de Azure, necesita el siguiente permiso:
[Link]/virtualNetworks/subnets/write .

El rol Colaborador de la red integrado también contiene los permisos necesarios.

Delegación de una subred a un servicio de Azure
En esta sección, delegará la subred que creó en la sección anterior en un servicio de Azure.
1. En la barra de búsqueda del portal, escriba myVirtualNetwork. Cuando aparezca la opción myVir tualNetwork
en los resultados de la búsqueda, selecciónela.
2. En los resultados de la búsqueda, seleccione myVirtualNetwork.
3. Seleccione Subredes en CONFIGURACIÓN y, después, seleccione mySubnet .
4. En la página mySubnet, en la lista Subnet delegation (Delegación de subred), seleccione uno de los servicios
enumerados en Delegate subnet to a ser vice (Delegar subred en un servicio) (por ejemplo, Microsoft.
DBforPostgreSQL/ser versv2 ).
Eliminación de la delegación de subred de un servicio de Azure
1. En la barra de búsqueda del portal, escriba myVirtualNetwork. Cuando aparezca la opción myVir tualNetwork
en los resultados de la búsqueda, selecciónela.
2. En los resultados de la búsqueda, seleccione myVirtualNetwork.
3. Seleccione Subredes en CONFIGURACIÓN y, después, seleccione mySubnet .
4. En la página mySubnet, en la lista Subnet delegation (Delegación de subred), seleccione None (Ninguno) en
los servicios enumerados en Delegate subnet to a ser vice (Delegar subred en un servicio).

Azure CLI
Uso de Azure Cloud Shell
En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si, en su lugar, decide instalar y usar la CLI de Azure en un entorno local, para este artículo se necesita la versión
2.0.28 de la CLI de Azure o una versión posterior. Ejecute az --version para buscar la versión instalada. Consulte
Instalación de la CLI de Azure para obtener información sobre la instalación o actualización.
Crear un grupo de recursos
Cree un grupo de recursos con az group create. Un grupo de recursos de Azure es un contenedor lógico en el que
se implementan y se administran los recursos de Azure.
En el ejemplo siguiente, se crea un grupo de recursos denominado myResourceGroup en la ubicación eastus :
 az group create \
--name myResourceGroup \
--location eastus

Creación de una red virtual

Cree una red virtual llamada myVnet con una subred llamada mySubnet en myResourceGroup con el
comando az network vnet create.

az network vnet create \

--resource-group myResourceGroup \
--location eastus \
--name myVnet \
--address-prefix [Link]/16 \
--subnet-name mySubnet \
--subnet-prefix [Link]/24

Permisos
Si no ha creado la subred que desea delegar en un servicio de Azure, necesita el siguiente permiso:
[Link]/virtualNetworks/subnets/write .

El rol Colaborador de la red integrado también contiene los permisos necesarios.

Delegación de una subred a un servicio de Azure
En esta sección, delegará la subred que creó en la sección anterior en un servicio de Azure.
Use az network vnet subnet update para actualizar la subred denominada mySubnet con una delegación a un
servicio de Azure. En este ejemplo , se usa [Link]/ser versv2 para la delegación de
ejemplo:

az network vnet subnet update \

--resource-group myResourceGroup \
--name mySubnet \
--vnet-name myVnet \
--delegations [Link]/serversv2

Para comprobar que la delegación se ha aplicado, use az network vnet subnet show. Compruebe que el servicio
esté delegado en la subred bajo la propiedad ser viceName :

az network vnet subnet show \

--resource-group myResourceGroup \
--name mySubnet \
--vnet-name myVnet \
--query delegations
 [
{
"actions": [
"[Link]/virtualNetworks/subnets/join/action"
],
"etag": "W/\"8a8bf16a-38cf-409f-9434-fe3b5ab9ae54\"",
"id": "/subscriptions/3bf09329-ca61-4fee-88cb-
7e30b9ee305b/resourceGroups/myResourceGroup/providers/[Link]/virtualNetworks/myVnet/subnets/mySubne
t/delegations/0",
"name": "0",
"provisioningState": "Succeeded",
"resourceGroup": "myResourceGroup",
"serviceName": "[Link]/serversv2",
"type": "[Link]/virtualNetworks/subnets/delegations"
}
]

Eliminación de la delegación de subred de un servicio de Azure

Use az network vnet subnet update para quitar la delegación de la subred denominada mySubnet :

az network vnet subnet update \

--resource-group myResourceGroup \
--name mySubnet \
--vnet-name myVnet \
--remove delegations

Para comprobar que se ha quitado la delegación, use az network vnet subnet show. Compruebe que el servicio se
ha quitado de la subred en la propiedad ser viceName :

az network vnet subnet show \

--resource-group myResourceGroup \
--name mySubnet \
--vnet-name myVnet \
--query delegations

La salida del comando es un corchete nulo:

[]

Azure PowerShell
NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Conexión con Azure

Connect-AzAccount

Crear un grupo de recursos

Cree un grupo de recursos con New-AzResourceGroup. Un grupo de recursos de Azure es un contenedor lógico en
el que se implementan y se administran los recursos de Azure.
En el ejemplo siguiente, se crea un grupo de recursos denominado myResourceGroup en la ubicación eastus:

New-AzResourceGroup -Name myResourceGroup -Location eastus

Creación de una red virtual

Cree una red virtual denominada myVnet con una subred llamada mySubnet con New-
AzVirtualNetworkSubnetConfig en myResourceGroup usando New-AzVirtualNetwork. El espacio de direcciones
IP de la red virtual es [Link]/16 . La subred en la red virtual es [Link]/24 .

$subnet = New-AzVirtualNetworkSubnetConfig -Name mySubnet -AddressPrefix "[Link]/24"

New-AzVirtualNetwork -Name myVnet -ResourceGroupName myResourceGroup -Location eastus -AddressPrefix

"[Link]/16" -Subnet $subnet

Permisos
Si no ha creado la subred que desea delegar en un servicio de Azure, necesita el siguiente permiso:
[Link]/virtualNetworks/subnets/write .

El rol Colaborador de la red integrado también contiene los permisos necesarios.

Delegación de una subred a un servicio de Azure
En esta sección, delegará la subred que creó en la sección anterior en un servicio de Azure.
Use Add-AzDelegation para actualizar la subred con el nombre mySubnet con una delegación denominada
myDelegation en un servicio de Azure. En este ejemplo , se usa [Link]/ser versv2 para la
delegación de ejemplo:

$vnet = Get-AzVirtualNetwork -Name "myVNet" -ResourceGroupName "myResourceGroup"

$subnet = Get-AzVirtualNetworkSubnetConfig -Name "mySubnet" -VirtualNetwork $vnet
$subnet = Add-AzDelegation -Name "myDelegation" -ServiceName "[Link]/serversv2" -Subnet
$subnet
Set-AzVirtualNetwork -VirtualNetwork $vnet

Use Get-AzDelegation para comprobar la delegación:

$subnet = Get-AzVirtualNetwork -Name "myVnet" -ResourceGroupName "myResourceGroup" | Get-

AzVirtualNetworkSubnetConfig -Name "mySubnet"
Get-AzDelegation -Name "myDelegation" -Subnet $subnet

ProvisioningState : Succeeded
ServiceName : [Link]/serversv2
Actions : {[Link]/virtualNetworks/subnets/join/action}
Name : myDelegation
Etag : W/"9cba4b0e-2ceb-444b-b553-454f8da07d8a"
Id : /subscriptions/3bf09329-ca61-4fee-88cb-
7e30b9ee305b/resourceGroups/myResourceGroup/providers/[Link]/virtualNetworks/myVnet/subnets/mySubne
t/delegations/myDelegation

Eliminación de la delegación de subred de un servicio de Azure

Use Remove-AzDelegation para quitar la delegación de la subred denominada mySubnet :
 $vnet = Get-AzVirtualNetwork -Name "myVnet" -ResourceGroupName "myResourceGroup"
$subnet = Get-AzVirtualNetworkSubnetConfig -Name "mySubnet" -VirtualNetwork $vnet
$subnet = Remove-AzDelegation -Name "myDelegation" -Subnet $subnet
Set-AzVirtualNetwork -VirtualNetwork $vnet

Use Get-AzDelegation para comprobar que se ha quitado la delegación:

$subnet = Get-AzVirtualNetwork -Name "myVnet" -ResourceGroupName "myResourceGroup" | Get-

AzVirtualNetworkSubnetConfig -Name "mySubnet"
Get-AzDelegation -Name "myDelegation" -Subnet $subnet

Get-AzDelegation: Sequence contains no matching element

Pasos siguientes
Aprenda a administrar subredes en Azure.
 Conexión de redes virtuales con emparejamiento de
redes virtuales usando PowerShell
23/09/2020 • 12 minutes to read • Edit Online

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Puede conectar redes virtuales entre sí con el emparejamiento de redes virtuales. Una vez que las redes virtuales
están emparejadas, los recursos de ambas se pueden comunicar entre sí con el mismo ancho de banda y la misma
latencia que si estuvieran en la misma red virtual. En este artículo aprenderá a:
Crear dos redes virtuales
Conectar dos redes virtuales con el emparejamiento de redes virtuales
Implementar una máquina virtual (VM) en cada red virtual
Comunicarse entre máquinas virtuales
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar PowerShell de forma local, para realizar los pasos de este artículo necesita la versión 1.0.0
del módulo de Azure PowerShell o cualquier versión posterior. Ejecute Get-Module -ListAvailable Az para buscar
la versión instalada. Si necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se
ejecuta localmente, también debe ejecutar Connect-AzAccount para crear una conexión con Azure.

Creación de redes virtuales

Antes de crear una red virtual, cree un grupo de recursos para ella y los demás recursos que se crearon en este
artículo. Cree un grupo de recursos con New-AzResourceGroup. En el ejemplo siguiente, se crea un grupo de
recursos denominado myResourceGroup en la ubicación eastus.

New-AzResourceGroup -ResourceGroupName myResourceGroup -Location EastUS

Cree una red virtual con New-AzVirtualNetwork. En el ejemplo siguiente se crea una red virtual denominada
myVirtualNetwork1 con el prefijo de dirección [Link]/16.

$virtualNetwork1 = New-AzVirtualNetwork `
-ResourceGroupName myResourceGroup `
-Location EastUS `
-Name myVirtualNetwork1 `
-AddressPrefix [Link]/16

Cree una configuración de subred con New-AzVirtualNetworkSubnetConfig. En el ejemplo siguiente se crea una
configuración de subred con un prefijo de dirección [Link]/24:

$subnetConfig = Add-AzVirtualNetworkSubnetConfig `
-Name Subnet1 `
-AddressPrefix [Link]/24 `
-VirtualNetwork $virtualNetwork1

Escriba la configuración de subred en la red virtual con ASet-AzVirtualNetwork, que crea la siguiente subred:

$virtualNetwork1 | Set-AzVirtualNetwork

Cree una red virtual con un prefijo de dirección [Link]/16 y una subred:
 # Create the virtual network.
$virtualNetwork2 = New-AzVirtualNetwork `
-ResourceGroupName myResourceGroup `
-Location EastUS `
-Name myVirtualNetwork2 `
-AddressPrefix [Link]/16

# Create the subnet configuration.

$subnetConfig = Add-AzVirtualNetworkSubnetConfig `
-Name Subnet1 `
-AddressPrefix [Link]/24 `
-VirtualNetwork $virtualNetwork2

# Write the subnet configuration to the virtual network.

$virtualNetwork2 | Set-AzVirtualNetwork

Emparejamiento de redes virtuales

Cree un emparejamiento con Add-AzVirtualNetworkPeering. El siguiente ejemplo empareja myVirtualNetwork1
con myVirtualNetwork2.

Add-AzVirtualNetworkPeering `
-Name myVirtualNetwork1-myVirtualNetwork2 `
-VirtualNetwork $virtualNetwork1 `
-RemoteVirtualNetworkId $[Link]

En la salida que se devuelve al ejecutarse el comando anterior, verá que PeeringState está en estado Iniciado. El
emparejamiento permanece en estado Iniciado hasta que cree el emparejamiento de myVirtualNetwork2 con
myVirtualNetwork1. Cree un emparejamiento de myVirtualNetwork2 con myVirtualNetwork1.

Add-AzVirtualNetworkPeering `
-Name myVirtualNetwork2-myVirtualNetwork1 `
-VirtualNetwork $virtualNetwork2 `
-RemoteVirtualNetworkId $[Link]

En la salida que se devuelve al ejecutarse el comando anterior, verá que PeeringState está en estado Conectado.
Azure también cambia el estado del emparejamiento myVirtualNetwork1-myVirtualNetwork2 a Conectado.
Confirme que el estado del emparejamiento myVirtualNetwork1-myVirtualNetwork2 cambia a Conectado con
Get-AzVirtualNetworkPeering.

Get-AzVirtualNetworkPeering `
-ResourceGroupName myResourceGroup `
-VirtualNetworkName myVirtualNetwork1 `
| Select PeeringState

Los recursos de una red virtual no se comunican con los de la otra hasta que el estado PeeringState de los
emparejamientos de ambas redes virtuales es Conectado.

Creación de máquinas virtuales

Cree una máquina virtual en cada red virtual para que puedan comunicarse entre ellas en un paso posterior.
Creación de la primera máquina virtual
Cree una máquina virtual con New-AzVM. En el ejemplo siguiente se crea una máquina virtual llamada myVm1 en
la red virtual myVirtualNetwork1. La opción -AsJob crea la máquina virtual en segundo plano, así que puede
continuar con el siguiente paso. Cuando se le solicite, escriba el nombre de usuario y la contraseña con los que
quiere iniciar sesión en la máquina virtual.

New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Location "East US" `
-VirtualNetworkName "myVirtualNetwork1" `
-SubnetName "Subnet1" `
-ImageName "Win2016Datacenter" `
-Name "myVm1" `
-AsJob

Creación de la segunda máquina virtual

New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Location "East US" `
-VirtualNetworkName "myVirtualNetwork2" `
-SubnetName "Subnet1" `
-ImageName "Win2016Datacenter" `
-Name "myVm2"

La máquina virtual tarda en crearse unos minutos. No continúe con los pasos siguientes hasta que Azure cree la
máquina virtual y devuelve el resultado a PowerShell.

Comunicarse entre máquinas virtuales

Puede conectarse a la dirección IP pública de una máquina virtual desde Internet. Use Get-AzPublicIpAddress para
devolver la dirección IP pública de una máquina virtual. En el siguiente ejemplo se devuelve la dirección IP pública
de la máquina virtual myVm1:

Get-AzPublicIpAddress `
-Name myVm1 `
-ResourceGroupName myResourceGroup | Select IpAddress

Ejecute el comando siguiente en el equipo local para crear una sesión de Escritorio remoto con la máquina virtual
myVm1 desde sus sistema local. Reemplace <publicIpAddress> con la dirección IP que devolvió el comando
anterior.

mstsc /v:<publicIpAddress>

A continuación se crea, se descarga y se abre en el equipo un archivo de Protocolo de Escritorio remoto (.rdp).
Escriba el nombre de usuario y la contraseña (puede que tenga que seleccionar More choices [Más opciones] y
luego Use a different account [Usar una cuenta diferente], para especificar las credenciales que escribió cuando
creó la máquina virtual). A continuación, seleccione Aceptar . Puede recibir una advertencia de certificado durante
el proceso de inicio de sesión. Haga clic en Sí o Conectar para continuar con la conexión.
En la máquina virtual myVm1, habilite el Protocolo de mensajes de control de Internet (ICMP) a través del Firewall
de Windows para que pueda hacer ping en esta máquina virtual desde myVm2 en un paso posterior, mediante
PowerShell:

New-NetFirewallRule –DisplayName "Allow ICMPv4-In" –Protocol ICMPv4

Aunque en este artículo se usa ping para comunicarse entre máquinas virtuales, no se recomienda permitir ICMP
mediante el Firewall de Windows para las implementaciones de producción.
Para conectar con la máquina virtual myVm2, escriba el siguiente comando desde el símbolo del sistema en la
máquina virtual myVm1:

mstsc /v:[Link]

Como ha habilitado ping en myVm1, ahora puede hacer ping en él mediante una dirección IP desde un símbolo
del sistema en la máquina virtual myVm2:

ping [Link]

Recibirá cuatro respuestas. Desconecte las sesiones RDP para ambos myVm1 y myVm2.

Limpieza de recursos
Cuando ya no lo necesite, utilice Remove-AzResourcegroup para quitar el grupo de recursos y todos los recursos
que contiene.

Remove-AzResourceGroup -Name myResourceGroup -Force

Pasos siguientes
En este artículo, ha aprendido a conectar dos redes, de la misma región de Azure, con el emparejamiento de redes
virtuales. También puede emparejar redes virtuales de distintas regiones compatibles y en distintas suscripciones
de Azure, además de crear diseños de red de concentrador y radio con emparejamiento. Para más información
sobre el emparejamiento de redes virtuales, consulte los artículos sobre el emparejamiento de redes virtuales y la
administración de emparejamientos de redes virtuales.
Puede conectar su equipo a una red virtual mediante VPN e interactuar con recursos en una red virtual, o en redes
virtuales emparejadas. En el caso de los scripts reutilizables para completar muchas de las tareas descritas en los
artículos sobre las redes virtuales, consulte los ejemplos de script.
 Conexión de redes virtuales con emparejamiento de
redes virtuales con la CLI de Azure
23/09/2020 • 10 minutes to read • Edit Online

Puede conectar redes virtuales entre sí con el emparejamiento de redes virtuales. Una vez que las redes virtuales
están emparejadas, los recursos de ambas se pueden comunicar entre sí con el mismo ancho de banda y la misma
latencia que si estuvieran en la misma red virtual. En este artículo aprenderá a:
Crear dos redes virtuales
Conectar dos redes virtuales con el emparejamiento de redes virtuales
Implementar una máquina virtual (VM) en cada red virtual
Comunicarse entre máquinas virtuales
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar la CLI localmente, para este artículo es preciso que ejecute la versión 2.0.28 o posterior de
la CLI de Azure. Para encontrar la versión, ejecute az --version . Si necesita instalarla o actualizarla, vea Instalación
de la CLI de Azure.
Creación de redes virtuales
Antes de crear una red virtual, cree un grupo de recursos para ella y los demás recursos que se crearon en este
artículo. Cree un grupo de recursos con az group create. En el ejemplo siguiente, se crea un grupo de recursos
denominado myResourceGroup en la ubicación eastus.

az group create --name myResourceGroup --location eastus

Cree la red virtual con el comando az network vnet create. En el ejemplo siguiente se crea una red virtual
denominada myVirtualNetwork1 con el prefijo de dirección [Link]/16.

az network vnet create \

--name myVirtualNetwork1 \
--resource-group myResourceGroup \
--address-prefixes [Link]/16 \
--subnet-name Subnet1 \
--subnet-prefix [Link]/24

Cree una red virtual denominada myVirtualNetwork2 con el prefijo de dirección [Link]/16:

az network vnet create \

--name myVirtualNetwork2 \
--resource-group myResourceGroup \
--address-prefixes [Link]/16 \
--subnet-name Subnet1 \
--subnet-prefix [Link]/24

Emparejamiento de redes virtuales

Los emparejamientos se establecen entre los identificadores de red virtual, por lo que primero debe obtener el
identificador de cada red virtual con az network vnet show y almacenarlo en una variable.

# Get the id for myVirtualNetwork1.

vNet1Id=$(az network vnet show \
--resource-group myResourceGroup \
--name myVirtualNetwork1 \
--query id --out tsv)

# Get the id for myVirtualNetwork2.

vNet2Id=$(az network vnet show \
--resource-group myResourceGroup \
--name myVirtualNetwork2 \
--query id \
--out tsv)

Cree un emparejamiento de myVirtualNetwork1 con myVirtualNetwork2 con az network vnet peering create. Si el
parámetro --allow-vnet-access no se especifica, se establece un emparejamiento, pero no fluye la comunicación.

az network vnet peering create \

--name myVirtualNetwork1-myVirtualNetwork2 \
--resource-group myResourceGroup \
--vnet-name myVirtualNetwork1 \
--remote-vnet $vNet2Id \
--allow-vnet-access

En la salida que se devuelve al ejecutarse el comando anterior, verá que peeringState está en estado iniciado. El
emparejamiento permanece en estado Iniciado hasta que cree el emparejamiento de myVirtualNetwork2 con
myVirtualNetwork1. Cree un emparejamiento de myVirtualNetwork2 con myVirtualNetwork1.

az network vnet peering create \

--name myVirtualNetwork2-myVirtualNetwork1 \
--resource-group myResourceGroup \
--vnet-name myVirtualNetwork2 \
--remote-vnet $vNet1Id \
--allow-vnet-access

En la salida que se devuelve al ejecutarse el comando anterior, verá que peeringState está en estado conectado.
Azure también cambia el estado del emparejamiento myVirtualNetwork1-myVirtualNetwork2 a Conectado.
Confirme que el estado de del emparejamiento myVirtualNetwork1-myVirtualNetwork2 cambia a conectado con
az network vnet peering show.

az network vnet peering show \

--name myVirtualNetwork1-myVirtualNetwork2 \
--resource-group myResourceGroup \
--vnet-name myVirtualNetwork1 \
--query peeringState

Los recursos de una red virtual no se comunican con los de la otra hasta que el estado peeringState de los
emparejamientos de ambas redes virtuales es conectado.

Creación de máquinas virtuales

Cree una máquina virtual en cada red virtual para que puedan comunicarse entre ellas en un paso posterior.
Creación de la primera máquina virtual
Cree la máquina virtual con az vm create. En el ejemplo siguiente se crea una máquina virtual llamada myVm1 en
la red virtual myVirtualNetwork1. Si las claves SSH no existen en la ubicación de claves predeterminada, el
comando las crea. Para utilizar un conjunto específico de claves, utilice la opción --ssh-key-value . La opción
--no-wait crea la máquina virtual en segundo plano, así que puede continuar con el siguiente paso.

az vm create \
--resource-group myResourceGroup \
--name myVm1 \
--image UbuntuLTS \
--vnet-name myVirtualNetwork1 \
--subnet Subnet1 \
--generate-ssh-keys \
--no-wait

Creación de la segunda máquina virtual

Cree una red virtual en la red virtual myVirtualNetwork2.

az vm create \
--resource-group myResourceGroup \
--name myVm2 \
--image UbuntuLTS \
--vnet-name myVirtualNetwork2 \
--subnet Subnet1 \
--generate-ssh-keys

La máquina virtual tarda en crearse unos minutos. Después de crear la máquina virtual, la CLI de Azure muestra
información similar a la del ejemplo siguiente:
 {
"fqdns": "",
"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/virtualMachines/myVm2",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "[Link]",
"publicIpAddress": "[Link]",
"resourceGroup": "myResourceGroup"
}

Anote el valor de publicIpAddress . En un paso posterior, usaremos esta dirección para obtener acceso a la
máquina virtual desde Internet.

Comunicarse entre máquinas virtuales

Use el siguiente comando para crear una sesión de SSH con la máquina virtual myVm2. Reemplace
<publicIpAddress> con la dirección IP pública de la máquina virtual. En el ejemplo anterior, la dirección IP pública
es [Link].

ssh <publicIpAddress>

Haga ping a la máquina virtual en myVirtualNetwork1.

ping [Link] -c 4

Recibirá cuatro respuestas.

Cierre la sesión de SSH en la máquina virtual myVm2.

Limpieza de recursos
Cuando ya no se necesiten, use az group delete para quitar el grupo de recursos y todos los recursos que
contenga.

az group delete --name myResourceGroup --yes

Pasos siguientes
En este artículo, ha aprendido a conectar dos redes, de la misma región de Azure, con el emparejamiento de redes
virtuales. También puede emparejar redes virtuales de distintas regiones compatibles y en distintas suscripciones
de Azure, además de crear diseños de red de concentrador y radio con emparejamiento. Para más información
sobre el emparejamiento de redes virtuales, consulte los artículos sobre el emparejamiento de redes virtuales y la
administración de emparejamientos de redes virtuales.
Puede conectar su equipo a una red virtual mediante VPN e interactuar con recursos en una red virtual, o en redes
virtuales emparejadas. En el caso de los scripts reutilizables para completar muchas de las tareas descritas en los
artículos sobre las redes virtuales, consulte los ejemplos de script.
 Creación de un emparejamiento de redes virtuales:
Resource Manager, diferentes suscripciones e
inquilinos de Azure Active Directory
23/09/2020 • 33 minutes to read • Edit Online

En este tutorial aprenderá a crear un emparejamiento de redes virtuales entre dos redes virtuales creadas
mediante Resource Manager. Las redes virtuales existen en distintas suscripciones que pueden pertenecer a
distintos inquilinos de Azure Active Directory (Azure AD). Emparejar dos redes virtuales permite que los recursos
en distintas redes virtuales se comuniquen entre sí con el mismo ancho de banda y latencia que tendrían los
recursos si estuvieran en la misma red virtual. Obtenga más información sobre el Emparejamiento de redes
virtuales.
Los pasos para crear un emparejamiento de redes virtuales cambian en función de si las redes virtuales se
encuentran en la misma suscripción o en suscripciones diferentes, y en función del modelo de implementación de
Azure con el que se han creado las redes virtuales. Para más información sobre cómo crear un emparejamiento de
redes virtuales en otros escenarios, seleccione el escenario en la tabla siguiente:

M O DELO DE IM P L EM EN TA C IÓ N DE A Z URE SUSC RIP C IÓ N DE A Z URE

Ambas mediante Resource Manager Iguales

Una mediante Resource Manager y la otra clásica Iguales

Una mediante Resource Manager y la otra clásica Diferentes

No se puede crear un emparejamiento de redes virtuales entre dos redes virtuales implementadas mediante el
modelo de implementación clásico. Si necesita conectar redes virtuales que se crearon a través del modelo de
implementación clásica, puede usar una instancia de Azure VPN Gateway para conectar las redes virtuales.
En este tutorial se emparejan redes virtuales de la misma región. También puede emparejar redes virtuales en
distintas regiones compatibles. Se recomienda que se familiarice con los requisitos y restricciones de
emparejamiento antes de emparejar redes virtuales.
Puede usar Azure Portal, Azure PowerShell, la interfaz de la línea de comandos (CLI) de Azure o la plantilla de
Azure Resource Manager para crear un emparejamiento de redes virtuales. Seleccione cualquiera de los vínculos
anteriores de herramientas para ir directamente a los pasos para crear un emparejamiento de redes virtuales con
la herramienta de su preferencia.
Si las redes virtuales están en diferentes suscripciones y las suscripciones están asociadas a diferentes inquilinos
de Azure Active Directory, complete los siguientes pasos antes de continuar:
1. Agregue el usuario de cada inquilino de Active Directory como un usuario invitado en el inquilino de Azure
Active Directory opuesto.
2. Cada usuario debe aceptar la invitación del usuario invitado del inquilino de Azure Active Directory opuesto.

Creación de emparejamiento: Azure Portal

Los pasos siguientes usan cuentas diferentes para cada suscripción. Si está usando una cuenta que tiene permisos
para ambas suscripciones puede usar la misma cuenta para todos los pasos, y omitir los pasos para cerrar sesión
 en el portal y para asignar a otro usuario permisos para las redes virtuales.
1. Inicie sesión en Azure Portal como UserA. La cuenta con la que inicie sesión debe tener todos los permisos
necesarios para crear un emparejamiento de redes virtuales. Para ver una lista de permisos, consulte
Permisos de emparejamiento de red virtual.
2. Seleccione + Crear un recurso , seleccione Redes y, luego, Red vir tual .
3. Seleccione o escriba los valores de ejemplo siguientes para las siguientes opciones y, luego, seleccione
Crear :
Nombre : myVnetA
Espacio de direcciones : [Link]/16
Nombre de subred : default
Rango de direcciones de subred : [Link]/24
Suscripción : Seleccione la suscripción A.
Grupo de recursos : seleccione Crear nuevo y escriba myResourceGroupA.
Ubicación : Este de EE. UU.
4. En el cuadro Buscar recursos en la parte superior del portal, escriba myVnetA. Seleccione myVnetA
cuando aparezca en los resultados de la búsqueda.
5. Seleccione Control de acceso (IAM) en la lista de opciones vertical que aparece a la izquierda.
6. En myVnetA: control de acceso (IAM) , seleccione + Agregar asignación de roles .
7. Seleccione Colaborador de la red en la casilla Rol .
8. En el cuadro Seleccionar , seleccione UserB o escriba la dirección de correo electrónico de UserB para
buscarlo.
9. Seleccione Guardar .
10. En myVnetA: control de acceso (IAM) , seleccione Propiedades en la lista de opciones vertical que
aparece a la izquierda. Copie el ID. DE RECURSO , ya que se usará en un paso posterior. El ID de respuesta
es similar al siguiente ejemplo:
/subscriptions/<Subscription
Id>/resourceGroups/myResourceGroupA/providers/[Link]/virtualNetworks/myVnetA
.
11. Cierre sesión en el portal como UserA e inicie sesión como UserB.
12. Complete los pasos del 2 al 3 y especifique o seleccione los valores siguientes en el paso 3:
Nombre : myVnetB
Espacio de direcciones : [Link]/16
Nombre de subred : default
Rango de direcciones de subred : [Link]/24
Suscripción : Seleccione la suscripción B.
Grupo de recursos : haga clic en Crear nuevo y escriba myResourceGroupB.
Ubicación : Este de EE. UU.
13. En el cuadro Buscar recursos en la parte superior del portal, escriba myVnetB. Seleccione myVnetB
cuando aparezca en los resultados de la búsqueda.
14. En myVnetB , seleccione Propiedades en la lista de opciones vertical que aparece a la izquierda. Copie el
ID. DE RECURSO , ya que se usará en un paso posterior. El ID de respuesta es similar al siguiente ejemplo:
/subscriptions/<Subscription
ID>/resourceGroups/myResourceGroupB/providers/[Link]/virtualNetworks/myVnetB
 .
15. Seleccione Control de acceso (IAM) en myVnetB y complete los pasos del 5 al 10 para myVnetB (en el
paso 8, escriba UserA ).
16. Cierre sesión en el portal como UserB e inicie sesión como UserA.
17. En el cuadro Buscar recursos en la parte superior del portal, escriba myVnetA. Seleccione myVnetA
cuando aparezca en los resultados de la búsqueda.
18. Seleccione myVnetA .
19. En CONFIGURACIÓN , seleccione Emparejamientos .
20. En myVnetA : emparejamientos , seleccione + Agregar .
21. En Agregar emparejamiento , escriba o seleccione las opciones siguientes y, luego, seleccione Aceptar :
Nombre : myVnetAToMyVnetB
Modelo de implementación de red vir tual : Select Administrador de recursos .
Conozco mi Id. de recurso : Active esta casilla.
Identificador de recurso : escriba el identificador de recurso del paso 14.
Permitir acceso a red vir tual : asegúrese de que está seleccionada la opción Habilitado . En este
tutorial no se usa ninguna otra configuración. Para conocer todas las configuraciones de
emparejamiento, lea Manage virtual network peerings (Administración de emparejamientos de redes
virtuales).
22. El emparejamiento que creó aparece poco después de seleccionar Aceptar en el paso anterior. El estado
Iniciado aparece en la columna ESTADO DE EMPAREJAMIENTO correspondiente al emparejamiento
myVnetAToMyVnetB que ha creado. Ha emparejado myVnetA con myVnetB, pero ahora debe emparejar
myVnetB con myVnetA. Debe crear el emparejamiento en ambas direcciones para permitir que los recursos
de las redes virtuales se comuniquen entre sí.
23. Cierre sesión en el portal como UserA e inicie sesión como UserB.
24. Complete nuevamente los pasos del 17 al 21 para MyVnetB. En el paso 21, asigne al emparejamiento el
nombre myVnetBToMyVnetA, seleccione myVnetA para Red Vir tual y escriba el identificador del paso 10
en el cuadro Id. de recurso .
25. Unos segundos después de seleccionar Aceptar para crear el emparejamiento de myVnetB, el
emparejamiento myVnetBToMyVnetA que acaba de crear aparece con el estado Conectado en la
columna ESTADO DE EMPAREJAMIENTO .
26. Cierre sesión en el portal como UserB e inicie sesión como UserA.
27. Complete nuevamente los pasos del 17 al 19. El ESTADO DE EMPAREJAMIENTO correspondiente al
emparejamiento myVnetAToVNetB ahora también aparece como Conectado . El emparejamiento se
establece correctamente una vez que ve el estado Conectado en la columna ESTADO DE
EMPAREJAMIENTO para las dos redes virtuales del emparejamiento. Los recursos de Azure que cree en
cualquiera de las redes virtuales ahora se pueden comunicar entre sí mediante sus direcciones IP. Si usa la
resolución de nombres predeterminada de Azure para las redes virtuales, los recursos de las redes virtuales
no pueden resolver nombres entre las redes virtuales. Si desea resolver nombres entre las redes virtuales
de un emparejamiento, debe crear su propio servidor DNS. Obtenga información sobre cómo configurar la
resolución de nombres mediante su propio servidor DNS.
28. Opcional : Si bien este tutorial no aborda la creación de máquinas virtuales, puede crear una máquina
virtual en cada red virtual y conectar de una máquina virtual a la otra para así validar la conectividad.
29. Opcional : para eliminar los recursos que crea en este tutorial, complete los pasos que aparecen en la
 sección Eliminación de recursos de este artículo.

Creación de emparejamiento: CLI de Azure

En este tutorial se usan cuentas diferentes para cada suscripción. Si está usando una cuenta que tiene permisos
para ambas suscripciones, puede usar la misma cuenta para todos los pasos, omitir los pasos para cerrar sesión en
Azure y quitar las líneas del script que crean las asignaciones de roles de usuario. Reemplace UserA@[Link] y
UserB@[Link] en todos los scripts siguientes por los nombres de usuario que está usando para UserA y UserB.
Los scripts siguientes:
Requiere la versión 2.0.4 o posterior de la CLI de Azure. Para encontrar la versión, ejecute az --version . Si debe
actualizarla, consulte Instalación de la CLI de Azure.
Funciona en un shell de Bash. Para ver las opciones de ejecución de scripts de la CLI de Azure en un cliente
Windows, consulte Instalación de la CLI de Azure 2.0 en Windows.
En lugar de instalar la CLI y sus dependencias, puede usar Azure Cloud Shell. Azure Cloud Shell es un shell de Bash
gratuito que se puede ejecutar directamente en Azure Portal. Tiene la CLI de Azure preinstalada y configurada para
utilizarla con la cuenta. Seleccione el botón Pruébelo en el script siguiente, que invoca un Cloud Shell en el que
puede iniciar sesión con su cuenta de Azure.
1. Abra una sesión de la CLI e inicie sesión en Azure como UserA mediante el comando azure login . La
cuenta con la que inicie sesión debe tener todos los permisos necesarios para crear un emparejamiento de
redes virtuales. Para ver una lista de permisos, consulte Permisos de emparejamiento de red virtual.
2. Copie el script siguiente en un editor de texto del equipo, reemplace <SubscriptionA-Id> por el identificador
de SubscriptionA, copie el script modificado, péguelo en la sesión de la CLI y pulse Enter . Si no conoce el
Id. de suscripción, escriba el comando az account show . El valor de id en la salida es el identificador de la
suscripción.

# Create a resource group.

az group create \
--name myResourceGroupA \
--location eastus

# Create virtual network A.

az network vnet create \
--name myVnetA \
--resource-group myResourceGroupA \
--location eastus \
--address-prefix [Link]/16

# Assign UserB permissions to virtual network A.

az role assignment create \
--assignee UserB@[Link] \
--role "Network Contributor" \
--scope /subscriptions/<SubscriptionA-
Id>/resourceGroups/myResourceGroupA/providers/[Link]/VirtualNetworks/myVnetA

3. Cierre sesión en Azure como UserA mediante el comando az logout e inicie sesión en Azure como UserB.
La cuenta con la que inicie sesión debe tener todos los permisos necesarios para crear un emparejamiento
de redes virtuales. Para ver una lista de permisos, consulte Permisos de emparejamiento de red virtual.
4. Cree myVnetB. Copie el contenido del script del paso 2 en un editor de texto del equipo. Reemplace
<SubscriptionA-Id> por el identificador de SubscriptionB. Cambie [Link]/16 a [Link]/16, y reemplace
todas las apariciones de A por B, y todas las apariciones de B por A. Copie el script modificado, péguelo en
la sesión de la CLI y pulse Enter .
 5. Cierre sesión en Azure como UserB e inicie sesión en Azure como UserA.
6. Cree un emparejamiento de redes virtuales myVnetA a myVnetB. Copie el contenido del script siguiente en
un editor de texto del equipo. Reemplace <SubscriptionB-Id> por el identificador de SubscriptionB. Para
ejecutar el script, copie el script modificado, péguelo en la sesión de la CLI y pulse ENTRAR.

# Get the id for myVnetA.

vnetAId=$(az network vnet show \
--resource-group myResourceGroupA \
--name myVnetA \
--query id --out tsv)

# Peer myVNetA to myVNetB.

az network vnet peering create \
--name myVnetAToMyVnetB \
--resource-group myResourceGroupA \
--vnet-name myVnetA \
--remote-vnet /subscriptions/<SubscriptionB-
Id>/resourceGroups/myResourceGroupB/providers/[Link]/VirtualNetworks/myVnetB \
--allow-vnet-access

7. Compruebe el estado de emparejamiento de myVnetA.

az network vnet peering list \

--resource-group myResourceGroupA \
--vnet-name myVnetA \
--output table

El estado es Iniciado . Cuando haya creado el emparejamiento a myVnetA desde myVnetB, cambiará a
Conectado .
8. Cierre sesión en Azure como UserA e inicie sesión en Azure como UserB.
9. Cree el emparejamiento de myVnetB a myVnetA. Copie el contenido del script del paso 6 en un editor de
texto del equipo. Reemplace <SubscriptionB-Id> por el identificador de SubscriptionA, todas las apariciones
de A por B, y todas las apariciones de B por A. Una vez realizados los cambios, copie el script modificado,
péguelo en la sesión de la CLI y pulse Enter .
10. Compruebe el estado de emparejamiento de myVnetB. Copie el contenido del script del paso 7 en un editor
de texto del equipo. Reemplace A por B en el nombre del grupo de recursos y de la red virtual, copie el
script, pegue el script modificado en la sesión de la CLI y pulse Enter . El estado de emparejamiento es
Conectado . El estado de emparejamiento de myVnetA cambiará a Conectado después de que haya
creado el emparejamiento de myVnetB a myVnetA. Puede volver a iniciar sesión como UserA en Azure y
realizar el paso 7 de nuevo para comprobar el estado de emparejamiento de myVnetA.

NOTE
El emparejamiento no se habrá establecido mientras el estado de emparejamiento de ambas redes virtuales no sea
Conectado .

11. Opcional : Si bien este tutorial no aborda la creación de máquinas virtuales, puede crear una máquina
virtual en cada red virtual y conectar de una máquina virtual a la otra para así validar la conectividad.
12. Opcional : para eliminar los recursos creados en este tutorial, complete los pasos de la sección Eliminar
recursos de este artículo.
Los recursos de Azure que cree en cualquiera de las redes virtuales ahora se pueden comunicar entre sí mediante
sus direcciones IP. Si usa la resolución de nombres predeterminada de Azure para las redes virtuales, los recursos
de las redes virtuales no pueden resolver nombres entre las redes virtuales. Si desea resolver nombres entre las
redes virtuales de un emparejamiento, debe crear su propio servidor DNS. Obtenga información sobre cómo
configurar la resolución de nombres mediante su propio servidor DNS.

Creación de emparejamiento: PowerShell

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

En este tutorial se usan cuentas diferentes para cada suscripción. Si está usando una cuenta que tiene permisos
para ambas suscripciones, puede usar la misma cuenta para todos los pasos, omitir los pasos para cerrar sesión en
Azure y quitar las líneas del script que crean las asignaciones de roles de usuario. Reemplace UserA@[Link] y
UserB@[Link] en todos los scripts siguientes por los nombres de usuario que está usando para UserA y UserB.
1. Confirme que tiene Azure PowerShell versión 1.0.0 o superior. Puede hacerlo mediante la ejecución de
Get-Module -Name Az . Recomendamos instalar la última versión del módulo Az de PowerShell. Si no está
familiarizado con Azure PowerShell, consulte Introducción a Azure PowerShell.
2. Inicie una sesión de PowerShell.
3. En PowerShell, inicie sesión en Azure como UserA. Para ello, escriba el comando Connect-AzAccount . La
cuenta con la que inicie sesión debe tener todos los permisos necesarios para crear un emparejamiento de
redes virtuales. Para ver una lista de permisos, consulte Permisos de emparejamiento de red virtual.
4. Cree un grupo de recursos y una red virtual A. Copie el script siguiente en un editor de texto del equipo.
Reemplace <SubscriptionA-Id> por el identificador de SubscriptionA. Si no conoce el identificador de la
suscripción, escriba el comando Get-AzSubscription para verlo. El valor de id en la salida devuelta es el
identificador de la suscripción. Para ejecutar el script, copie el script modificado, péguelo en PowerShell y
pulse Enter .

# Create a resource group.

New-AzResourceGroup `
-Name MyResourceGroupA `
-Location eastus

# Create virtual network A.

$vNetA = New-AzVirtualNetwork `
-ResourceGroupName MyResourceGroupA `
-Name 'myVnetA' `
-AddressPrefix '[Link]/16' `
-Location eastus

# Assign UserB permissions to myVnetA.

New-AzRoleAssignment `
-SignInName UserB@[Link] `
-RoleDefinitionName "Network Contributor" `
-Scope /subscriptions/<SubscriptionA-
Id>/resourceGroups/myResourceGroupA/providers/[Link]/VirtualNetworks/myVnetA

5. Cierre sesión en Azure como UserA e inicie sesión como UserB. La cuenta con la que inicie sesión debe
tener todos los permisos necesarios para crear un emparejamiento de redes virtuales. Para ver una lista de
 permisos, consulte Permisos de emparejamiento de red virtual.
6. Copie el contenido del script del paso 4 en un editor de texto del equipo. Reemplace <SubscriptionA-Id>
por el identificador de SubscriptionB. Cambie [Link]/16 a [Link]/16. Reemplace todas las apariciones de
A por B, y todas las apariciones de B por A. Para ejecutar el script, copie el script modificado, péguelo en
PowerShell y pulse Enter .
7. Cierre sesión como UserB en Azure e inicie sesión como UserA.
8. Cree el emparejamiento de myVnetA a myVnetB. Copie el script siguiente en un editor de texto del equipo.
Reemplace <SubscriptionB-Id> por el identificador de SubscriptionB. Para ejecutar el script, copie el script
modificado, péguelo en PowerShell y pulse Enter .

# Peer myVnetA to myVnetB.

$vNetA=Get-AzVirtualNetwork -Name myVnetA -ResourceGroupName myResourceGroupA
Add-AzVirtualNetworkPeering `
-Name 'myVnetAToMyVnetB' `
-VirtualNetwork $vNetA `
-RemoteVirtualNetworkId "/subscriptions/<SubscriptionB-
Id>/resourceGroups/myResourceGroupB/providers/[Link]/virtualNetworks/myVnetB"

9. Compruebe el estado de emparejamiento de myVnetA.

Get-AzVirtualNetworkPeering `
-ResourceGroupName myResourceGroupA `
-VirtualNetworkName myVnetA `
| Format-Table VirtualNetworkName, PeeringState

El estado es Iniciado . Cuando haya configurado el emparejamiento a myVnetA desde myVnetB, cambiará a
Conectado .
10. Cierre sesión en Azure como UserA e inicie sesión como UserB.
11. Cree el emparejamiento de myVnetB a myVnetA. Copie el contenido del script del paso 8 en un editor de
texto del equipo. Reemplace <SubscriptionB-Id> por el identificador de la suscripción A y cambie todas las
A por B y todas las B por A. Para ejecutar el script, copie el script modificado, péguelo en PowerShell y luego
presione Enter .
12. Compruebe el estado de emparejamiento de myVnetB. Copie el contenido del script del paso 9 en un editor
de texto del equipo. Reemplace A por B en el nombre del grupo de recursos y de la red virtual. Para ejecutar
el script, pegue el script modificado en PowerShell y pulse Enter . El estado es Conectado . El estado de
emparejamiento de myVnetA cambiará a Conectado después de que haya creado el emparejamiento de
myVnetB a myVnetA . Puede volver a iniciar sesión como UserA en Azure y realizar el paso 9 de nuevo
para comprobar el estado de emparejamiento de myVnetA.

NOTE
El emparejamiento no se habrá establecido mientras el estado de emparejamiento de ambas redes virtuales no sea
Conectado .

Los recursos de Azure que cree en cualquiera de las redes virtuales ahora se pueden comunicar entre sí
mediante sus direcciones IP. Si usa la resolución de nombres predeterminada de Azure para las redes
virtuales, los recursos de las redes virtuales no pueden resolver nombres entre las redes virtuales. Si desea
resolver nombres entre las redes virtuales de un emparejamiento, debe crear su propio servidor DNS.
Obtenga información sobre cómo configurar la resolución de nombres mediante su propio servidor DNS.
13. Opcional : Si bien este tutorial no aborda la creación de máquinas virtuales, puede crear una máquina
virtual en cada red virtual y conectar de una máquina virtual a la otra para así validar la conectividad.
14. Opcional : para eliminar los recursos creados en este tutorial, complete los pasos de la sección Eliminar
recursos de este artículo.

Creación de emparejamiento: plantilla de Resource Manager

1. Para crear una red virtual y asignar los permisos adecuados, complete los pasos que aparecen en las
secciones Portal, CLI de Azure o PowerShell de este artículo.
2. Guarde el texto que sigue a un archivo en el equipo local. Reemplace <subscription ID> por el identificador
de suscripción de UserA. Puede guardar el archivo como [Link], por ejemplo.

{
"$schema": "[Link]
"contentVersion": "[Link]",
"parameters": {
},
"variables": {
},
"resources": [
{
"apiVersion": "2016-06-01",
"type": "[Link]/virtualNetworks/virtualNetworkPeerings",
"name": "myVnetA/myVnetAToMyVnetB",
"location": "[resourceGroup().location]",
"properties": {
"allowVirtualNetworkAccess": true,
"allowForwardedTraffic": false,
"allowGatewayTransit": false,
"useRemoteGateways": false,
"remoteVirtualNetwork": {
"id": "/subscriptions/<subscription
ID>/resourceGroups/PeeringTest/providers/[Link]/virtualNetworks/myVnetB"
}
}
}
]
}

3. Inicie sesión en Azure como UserA e implemente la plantilla mediante el portal, PowerShell o la CLI de
Azure. Especifique el nombre de archivo que ha guardado en el paso 2 para el texto del archivo json de
ejemplo.
4. Copie el archivo json de ejemplo del paso 2 en un archivo del equipo y realice cambios en las líneas que
comienzan por:
name : cambie myVnetA/myVnetAToMyVnetB por myVnetB/myVnetBToMyVnetA.
id : reemplace <subscription ID> por el identificador de suscripción de UserB y cambie myVnetB por
myVnetA.
5. Vuelva a realizar el paso 3, con la sesión de Azure iniciada como UserB.
6. Opcional : Si bien este tutorial no aborda la creación de máquinas virtuales, puede crear una máquina
virtual en cada red virtual y conectar de una máquina virtual a la otra para así validar la conectividad.
7. Opcional : para eliminar los recursos que crea en este tutorial, complete los pasos que aparecen en la
sección Eliminación de recursos de este artículo, ya sea mediante Azure Portal, PowerShell o la CLI de Azure.

Eliminación de recursos
Cuando haya terminado este tutorial, es posible que quiera eliminar los recursos que creó en el tutorial, para no
incurrir en gastos de uso. Al eliminar un grupo de recursos se eliminan también todos los recursos contenidos en
el mismo.
Azure Portal
1. Inicie sesión en Azure Portal como UserA.
2. En el cuadro de búsqueda del portal, escriba myResourceGroupA . En los resultados de la búsqueda,
seleccione myResourceGroupA .
3. Seleccione Eliminar .
4. Para confirmar la eliminación, en el cuadro ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS , escriba
myResourceGroupA y, luego, seleccione Eliminar .
5. Cierre sesión en el portal como UserA e inicie sesión como UserB.
6. Complete los pasos del 2 al 4 para myResourceGroupB.
Azure CLI
1. Inicie sesión en Azure como UserA y ejecute el comando siguiente:

az group delete --name myResourceGroupA --yes

2. Cierre sesión en Azure como UserA e inicie sesión como UserB.

3. Ejecute el comando siguiente:

az group delete --name myResourceGroupB --yes

PowerShell
1. Inicie sesión en Azure como UserA y ejecute el comando siguiente:

Remove-AzResourceGroup -Name myResourceGroupA -force

2. Cierre sesión en Azure como UserA e inicie sesión como UserB.

3. Ejecute el comando siguiente:

Remove-AzResourceGroup -Name myResourceGroupB -force

Pasos siguientes
Conozca en profundidad las restricciones y comportamientos importantes del emparejamiento de redes
virtuales antes de crear un emparejamiento de redes virtuales para su uso en el entorno de producción.
Conozca toda la configuración de emparejamiento de redes virtuales.
Obtenga información sobre cómo crear una topología de red de concentrador y radio con emparejamiento de
redes virtuales.
 Creación de un emparejamiento de red virtual:
distintos modelos de implementación, la misma
suscripción
23/09/2020 • 20 minutes to read • Edit Online

En este tutorial aprenderá a crear un emparejamiento de redes virtuales entre dos redes virtuales creadas
mediante diferentes modelos de implementación. Hay redes virtuales en la misma suscripción en la misma
suscripción. Emparejar dos redes virtuales permite que los recursos en distintas redes virtuales se comuniquen
entre sí con el mismo ancho de banda y latencia que tendrían los recursos si estuvieran en la misma red virtual.
Obtenga más información sobre el Emparejamiento de redes virtuales.
Los pasos para crear un emparejamiento de redes virtuales cambian en función de si las redes virtuales se
encuentran en la misma suscripción o en suscripciones diferentes, y en función del modelo de implementación de
Azure con el que se han creado las redes virtuales. Para más información sobre cómo crear un emparejamiento de
redes virtuales en otros escenarios, haga clic en el escenario en la tabla siguiente:

M O DELO DE IM P L EM EN TA C IÓ N DE A Z URE SUSC RIP C IÓ N DE A Z URE

Ambas mediante Resource Manager Iguales

Ambas mediante Resource Manager Diferentes

Una mediante Resource Manager y la otra clásica Diferentes

No se puede crear un emparejamiento de redes virtuales entre dos redes virtuales implementadas mediante el
modelo de implementación clásico. Si necesita conectar redes virtuales que se crearon a través del modelo de
implementación clásica, puede usar una instancia de Azure VPN Gateway para conectar las redes virtuales.
En este tutorial se emparejan redes virtuales de la misma región. También puede emparejar redes virtuales en
distintas regiones compatibles. Se recomienda que se familiarice con los requisitos y restricciones de
emparejamiento antes de emparejar redes virtuales.
Puede usar Azure Portal, la interfaz de la línea de comandos (CLI) de Azure, Azure PowerShell o una plantilla de
Azure Resource Manager para crear un emparejamiento de redes virtuales. Haga clic en cualquiera de los vínculos
anteriores de herramientas para ir directamente a los pasos para crear un emparejamiento de redes virtuales con
la herramienta de su preferencia.

Creación de emparejamiento: Azure Portal

1. Inicie sesión en Azure Portal. La cuenta con la que inicie sesión debe tener todos los permisos necesarios
para crear un emparejamiento de redes virtuales. Para ver una lista de permisos, consulte Permisos de
emparejamiento de red virtual.
2. Haga clic en + Nuevo , Redes y, luego, en Red vir tual .
3. En la hoja Crear red vir tual , escriba o seleccione valores para la configuración siguiente y, luego, haga clic
en Crear :
Nombre : myVnet1
Espacio de direcciones : [Link]/16
 Nombre de subred : default
Rango de direcciones de subred : [Link]/24
Suscripción : Seleccione su suscripción.
Grupo de recursos : Seleccione Crear nuevo y escriba myResourceGroup
Ubicación : Este de EE. UU.
4. Haga clic en + Nuevo . En el campo Buscar en el Marketplace , escriba Red virtual. Haga clic en Red
vir tual cuando aparezca en los resultados de la búsqueda.
5. En la hoja Red vir tual , seleccione Clásica en el cuadro Seleccionar un modelo de implementación y
haga clic en Crear .
6. En la hoja Crear red vir tual , escriba o seleccione valores para la configuración siguiente y, luego, haga clic
en Crear :
Nombre : myVnet2
Espacio de direcciones : [Link]/16
Nombre de subred : default
Rango de direcciones de subred : [Link]/24
Suscripción : Seleccione su suscripción.
Grupo de recursos : Seleccione Usar existente y, a continuación, myResourceGroup.
Ubicación : Este de EE. UU.
7. En el cuadro Buscar recursos en la parte superior del portal, escriba myResourceGroup. Haga clic en
myResourceGroup cuando aparezca en los resultados de la búsqueda. Aparece una hoja para el grupo de
recursos myresourcegroup . El grupo de recursos contiene las dos redes virtuales que se crearon en los
pasos anteriores.
8. Haga clic en myVNet1 .
9. En la hoja myVnet1 que aparece, haga clic en Emparejamientos en la lista vertical de opciones que
aparece al lado izquierdo de la hoja.
10. En la hoja myVnet1 - Peerings (myVnet1: emparejamientos) que aparece, haga clic en + Agregar
11. En la hoja Agregar emparejamiento que aparece, escriba o seleccione las opciones siguientes y, luego,
haga clic en Aceptar :
Nombre : myVnet1ToMyVnet2
Modelo de implementación de red vir tual : Seleccione Clásico .
Suscripción : Seleccione su suscripción.
Red vir tual : haga clic en Elegir una red vir tual y, luego, en myVnet2 .
Permitir acceso a red vir tual : asegúrese de que está seleccionada la opción Habilitado . En este
tutorial no se usa ninguna otra configuración. Para conocer todas las configuraciones de
emparejamiento, lea Manage virtual network peerings (Administración de emparejamientos de redes
virtuales).
12. Una vez que hace clic en Aceptar en el paso anterior, se cierra la hoja Agregar emparejamiento y se
vuelve a mostrar la hoja myVnet1 - Peerings (myVnet1: emparejamientos). Unos segundos después, el
emparejamiento que creó aparece en la hoja. El estado Conectado aparece en la columna ESTADO DE
EMPAREJAMIENTO correspondiente al emparejamiento myVnet1ToMyVnet2 que creó.
El emparejamiento está ahora establecido. Los recursos de Azure que cree en cualquiera de las redes
virtuales ahora se pueden comunicar entre sí mediante sus direcciones IP. Si usa la resolución de nombres
predeterminada de Azure para las redes virtuales, los recursos de las redes virtuales no pueden resolver
nombres entre las redes virtuales. Si desea resolver nombres entre las redes virtuales de un
emparejamiento, debe crear su propio servidor DNS. Obtenga información sobre cómo configurar la
 resolución de nombres mediante su propio servidor DNS.
13. Opcional : Si bien este tutorial no aborda la creación de máquinas virtuales, puede crear una máquina
virtual en cada red virtual y conectar de una máquina virtual a la otra para así validar la conectividad.
14. Opcional : para eliminar los recursos que crea en este tutorial, complete los pasos que aparecen en la
sección Eliminación de recursos de este artículo.

Creación de emparejamiento: CLI de Azure

Complete los pasos siguientes mediante la CLI de Azure clásica y la CLI de Azure. Puede completar los pasos desde
Azure Cloud Shell. Para ello solo tiene que seleccionar el botón Tr y it (Pruébelo) en cualquiera de los pasos
siguientes o instalar la CLI clásica y la CLI, y ejecutar los comandos en el equipo local.
1. Si usa Cloud Shell, vaya al paso 2, ya que Cloud Shell inicia automáticamente la sesión de Azure. Abra una
sesión de comandos e inicie sesión en Azure mediante el comando azure login .
2. Ejecute la CLI en modo de administración de servicios escribiendo el comando azure config mode asm .
3. Escriba el siguiente comando para crear la red virtual (clásica):

azure network vnet create --vnet myVnet2 --address-space [Link] --cidr 16 --location "East US"

4. Ejecute el siguiente script de la CLI de Bash mediante la CLI, no la CLI clásica. Para ver las opciones de
ejecución de scripts de la CLI de Bash en un equipo Windows, consulte Instalación de la CLI de Azure en
Windows.

#!/bin/bash

# Create a resource group.

az group create \
--name myResourceGroup \
--location eastus

# Create the virtual network (Resource Manager).

az network vnet create \
--name myVnet1 \
--resource-group myResourceGroup \
--location eastus \
--address-prefix [Link]/16

5. Use la CLI para crear un emparejamiento de redes virtuales entre las dos redes virtuales creadas mediante
los diferentes modelos de implementación. Copie el script siguiente en un editor de texto del equipo.
Reemplace <subscription id> con el Id. de suscripción. Si no conoce el Id. de suscripción, escriba el
comando az account show . El valor de id en la salida es el identificador de la suscripción. Pegue el script
modificado en la sesión de CLI y después pulse Enter .
 # Get the ID for VNet1.
vnet1Id=$(az network vnet show \
--resource-group myResourceGroup \
--name myVnet1 \
--query id --out tsv)

# Peer VNet1 to VNet2.

az network vnet peering create \
--name myVnet1ToMyVnet2 \
--resource-group myResourceGroup \
--vnet-name myVnet1 \
--remote-vnet-id /subscriptions/<subscription id>/resourceGroups/Default-
Networking/providers/[Link]/virtualNetworks/myVnet2 \
--allow-vnet-access

6. Una vez que se ejecute el script, revise los emparejamientos de la red virtual (Resource Manager). Copie el
comando siguiente, péguelo en la sesión de la CLI y después presione Enter :

az network vnet peering list \

--resource-group myResourceGroup \
--vnet-name myVnet1 \
--output table

La salida muestra Conectado en la columna PeeringState .

Los recursos de Azure que cree en cualquiera de las redes virtuales ahora se pueden comunicar entre sí
mediante sus direcciones IP. Si usa la resolución de nombres predeterminada de Azure para las redes
virtuales, los recursos de las redes virtuales no pueden resolver nombres entre las redes virtuales. Si desea
resolver nombres entre las redes virtuales de un emparejamiento, debe crear su propio servidor DNS.
Obtenga información sobre cómo configurar la resolución de nombres mediante su propio servidor DNS.
7. Opcional : Si bien este tutorial no aborda la creación de máquinas virtuales, puede crear una máquina
virtual en cada red virtual y conectar de una máquina virtual a la otra para así validar la conectividad.
8. Opcional : para eliminar los recursos creados en este tutorial, complete los pasos de la sección Eliminar
recursos de este artículo.

Creación de emparejamiento: PowerShell

1. Instale la versión más reciente de los módulos Azure y Az de PowerShell. Si no está familiarizado con Azure
PowerShell, consulte Introducción a Azure PowerShell.
2. Inicie una sesión de PowerShell.
3. En PowerShell, inicie sesión en Azure especificando el comando Add-AzureAccount . La cuenta con la que
inicie sesión debe tener todos los permisos necesarios para crear un emparejamiento de redes virtuales.
Para ver una lista de permisos, consulte Permisos de emparejamiento de red virtual.
4. Para crear una red virtual (clásica) con PowerShell, debe crear o modificar un archivo de configuración de
red existente. Obtenga información sobre cómo exportar, actualizar e importar archivos de configuración de
red. El archivo debe incluir el siguiente elemento Vir tualNetworkSite para la red virtual que se usa en
este tutorial:
 <VirtualNetworkSite name="myVnet2" Location="East US">
<AddressSpace>
<AddressPrefix>[Link]/16</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="default">
<AddressPrefix>[Link]/24</AddressPrefix>
</Subnet>
</Subnets>
</VirtualNetworkSite>

WARNING
Importar un archivo de configuración de red modificada puede producir cambios en las redes virtuales (clásicas)
existentes en la suscripción. Asegúrese de agregar solo la red virtual anterior y que no cambia o quita ninguna red
virtual existente de la suscripción.

5. Inicie sesión en Azure para crear la red virtual (Resource Manager) escribiendo el comando
Connect-AzAccount . La cuenta con la que inicie sesión debe tener todos los permisos necesarios para crear
un emparejamiento de redes virtuales. Para ver una lista de permisos, consulte Permisos de
emparejamiento de red virtual.
6. Cree un grupo de recursos y una red virtual (Resource Manager). Copie el script, péguelo en PowerShell y, a
continuación, pulse Enter .

# Create a resource group.

New-AzResourceGroup -Name myResourceGroup -Location eastus

# Create the virtual network (Resource Manager).

$vnet1 = New-AzVirtualNetwork `
-ResourceGroupName myResourceGroup `
-Name 'myVnet1' `
-AddressPrefix '[Link]/16' `
-Location eastus

7. Cree un emparejamiento de redes virtuales entre las dos redes virtuales creadas mediante los modelos de
implementación diferentes. Copie el script siguiente en un editor de texto del equipo. Reemplace
<subscription id> con el Id. de suscripción. Si no conoce el identificador de la suscripción, escriba el
comando Get-AzSubscription para verlo. El valor de id en la salida devuelta es el identificador de la
suscripción. Para ejecutar el script, copie el script modificado del editor de texto, haga clic con el botón
derecho en la sesión de PowerShell y, a continuación, pulse Enter .

# Peer VNet1 to VNet2.

Add-AzVirtualNetworkPeering `
-Name myVnet1ToMyVnet2 `
-VirtualNetwork $vnet1 `
-RemoteVirtualNetworkId /subscriptions/<subscription Id>/resourceGroups/Default-
Networking/providers/[Link]/virtualNetworks/myVnet2

8. Una vez que se ejecute el script, revise los emparejamientos de la red virtual (Resource Manager). Copie el
comando siguiente, péguelo en la sesión de PowerShell y después presione Enter :
 Get-AzVirtualNetworkPeering `
-ResourceGroupName myResourceGroup `
-VirtualNetworkName myVnet1 `
| Format-Table VirtualNetworkName, PeeringState

La salida muestra Conectado en la columna PeeringState .

Los recursos de Azure que cree en cualquiera de las redes virtuales ahora se pueden comunicar entre sí
mediante sus direcciones IP. Si usa la resolución de nombres predeterminada de Azure para las redes
virtuales, los recursos de las redes virtuales no pueden resolver nombres entre las redes virtuales. Si desea
resolver nombres entre las redes virtuales de un emparejamiento, debe crear su propio servidor DNS.
Obtenga información sobre cómo configurar la resolución de nombres mediante su propio servidor DNS.
9. Opcional : Si bien este tutorial no aborda la creación de máquinas virtuales, puede crear una máquina
virtual en cada red virtual y conectar de una máquina virtual a la otra para así validar la conectividad.
10. Opcional : para eliminar los recursos creados en este tutorial, complete los pasos de la sección Eliminar
recursos de este artículo.

Eliminación de recursos
Cuando haya terminado este tutorial, es posible que quiera eliminar los recursos que creó en el tutorial, para no
incurrir en gastos de uso. Al eliminar un grupo de recursos se eliminan también todos los recursos contenidos en
el mismo.
Azure Portal
1. En el cuadro de búsqueda del portal, escriba myResourceGroup . En los resultados de la búsqueda, haga clic
en myResourceGroup .
2. En la hoja myResourceGroup , haga clic en el icono Eliminar .
3. Para confirmar la eliminación, en el cuadro ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS , escriba
myResourceGroup y, luego, haga clic en Eliminar .
Azure CLI
1. Use la CLI de Azure para eliminar la red virtual (Resource Manager) con el siguiente comando:

az group delete --name myResourceGroup --yes

2. Use la CLI clásica para eliminar la red virtual (clásica) con los siguientes comandos:

azure config mode asm

azure network vnet delete --vnet myVnet2 --quiet

PowerShell
1. Especifique el siguiente comando para eliminar la red virtual (Resource Manager):

Remove-AzResourceGroup -Name myResourceGroup -Force

2. Para eliminar la red virtual (clásica) con PowerShell, debe modificar un archivo de configuración de red
existente. Obtenga información sobre cómo exportar, actualizar e importar archivos de configuración de
red. Quite el siguiente elemento VirtualNetworkSite para la red virtual que se usa en este tutorial:
 <VirtualNetworkSite name="myVnet2" Location="East US">
<AddressSpace>
<AddressPrefix>[Link]/16</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="default">
<AddressPrefix>[Link]/24</AddressPrefix>
</Subnet>
</Subnets>
</VirtualNetworkSite>

WARNING
Importar un archivo de configuración de red modificada puede producir cambios en las redes virtuales (clásicas)
existentes en la suscripción. Asegúrese de quitar solo la red virtual anterior y que no cambia o quita ninguna red
virtual existente de la suscripción.

Pasos siguientes
Conozca en profundidad las restricciones y comportamientos importantes del emparejamiento de redes
virtuales antes de crear un emparejamiento de redes virtuales para su uso en el entorno de producción.
Conozca toda la configuración de emparejamiento de redes virtuales.
Obtenga información sobre cómo crear una topología de red de concentrador y radio con emparejamiento de
redes virtuales.
 Crear un emparejamiento de redes virtuales de
Azure: diferentes modelos de implementación y
suscripciones
23/09/2020 • 29 minutes to read • Edit Online

En este tutorial aprenderá a crear un emparejamiento de redes virtuales entre dos redes virtuales creadas
mediante diferentes modelos de implementación. Las redes virtuales se encuentran en suscripciones diferentes.
Emparejar dos redes virtuales permite que los recursos en distintas redes virtuales se comuniquen entre sí con el
mismo ancho de banda y latencia que tendrían los recursos si estuvieran en la misma red virtual. Obtenga más
información sobre el Emparejamiento de redes virtuales.
Los pasos para crear un emparejamiento de redes virtuales cambian en función de si las redes virtuales se
encuentran en la misma suscripción o en suscripciones diferentes, y en función del modelo de implementación de
Azure con el que se han creado las redes virtuales. Para más información sobre cómo crear un emparejamiento de
redes virtuales en otros escenarios, haga clic en el escenario en la tabla siguiente:

M O DELO DE IM P L EM EN TA C IÓ N DE A Z URE SUSC RIP C IÓ N DE A Z URE

Ambas mediante Resource Manager Iguales

Ambas mediante Resource Manager Diferentes

Una mediante Resource Manager y la otra clásica Iguales

No se puede crear un emparejamiento de redes virtuales entre dos redes virtuales implementadas mediante el
modelo de implementación clásico. En este tutorial se usan las redes virtuales de la misma región. En este tutorial
se emparejan redes virtuales de la misma región. También puede emparejar redes virtuales en distintas regiones
compatibles. Se recomienda que se familiarice con los requisitos y restricciones de emparejamiento antes de
emparejar redes virtuales.
Al crear un emparejamiento de redes virtuales entre redes virtuales que se encuentran en suscripciones diferentes,
las suscripciones pueden estar asociadas al mismo inquilino de Azure Active Directory. Si todavía no tiene un
inquilino de Azure Active Directory, puede crear uno rápidamente.
Puede usar Azure Portal, la interfaz de la línea de comandos (CLI) de Azure o Azure PowerShell para crear un
emparejamiento de redes virtuales. Haga clic en cualquiera de los vínculos anteriores de herramientas para ir
directamente a los pasos para crear un emparejamiento de redes virtuales con la herramienta de su preferencia.

Creación de emparejamiento: Azure Portal

En este tutorial se usan cuentas diferentes para cada suscripción. Si está usando una cuenta que tiene permisos
para ambas suscripciones puede usar la misma cuenta para todos los pasos, y omitir los pasos para cerrar sesión
en el portal y para asignar a otro usuario permisos para las redes virtuales.
1. Inicie sesión en Azure Portal como UserA. La cuenta con la que inicie sesión debe tener todos los permisos
necesarios para crear un emparejamiento de redes virtuales. Para ver una lista de permisos, consulte
Permisos de emparejamiento de red virtual.
2. Haga clic en + Nuevo , Redes y, luego, en Red vir tual .
 3. En la hoja Crear red vir tual , escriba o seleccione valores para la configuración siguiente y, luego, haga clic
en Crear :
Nombre : myVnetA
Espacio de direcciones : [Link]/16
Nombre de subred : default
Rango de direcciones de subred : [Link]/24
Suscripción : Seleccione la suscripción A.
Grupo de recursos : seleccione Crear nuevo y escriba myResourceGroupA.
Ubicación : Este de EE. UU.
4. En el cuadro Buscar recursos en la parte superior del portal, escriba myVnetA. Haga clic en myVnetA
cuando aparezca en los resultados de la búsqueda. Aparece una hoja para la red virtual myVnetA .
5. En la hoja myVnetA que aparece, haga clic en Control de acceso (IAM) en la lista vertical de opciones
que aparece a la izquierda de la hoja.
6. En la hoja myVnetA - Control de acceso (IAM) que aparece, haga clic en + Agregar asignación de
roles .
7. En la hoja Agregar asignación de roles que aparece, seleccione Colaborador de la red en el cuadro
Rol .
8. En el cuadro Seleccionar , seleccione otro usuario (UserB) o escriba la dirección de correo de UserB para
buscarlo. La lista de usuario que se muestra proviene del mismo inquilino de Azure Active Directory que la
red virtual para la que configura el emparejamiento. Haga clic en UserB cuando aparezca en la lista.
9. Haga clic en Save (Guardar).
10. Cierre sesión en el portal como UserA e inicie sesión como UserB.
11. Haga clic en + Nuevo , escriba Red virtual en el cuadro Buscar en el Marketplace y después haga clic en
Red vir tual en los resultados de la búsqueda.
12. En la hoja Vir tual Network que aparece, seleccione Clásica en el cuadro Seleccionar un modelo de
implementación y haga clic en Crear .
13. En el cuadro Crear red virtual (clásica) que aparece, escriba los valores siguientes:
Nombre : myVnetB
Espacio de direcciones : [Link]/16
Nombre de subred : default
Rango de direcciones de subred : [Link]/24
Suscripción : Seleccione la suscripción B.
Grupo de recursos : haga clic en Crear nuevo y escriba myResourceGroupB.
Ubicación : Este de EE. UU.
14. En el cuadro Buscar recursos en la parte superior del portal, escriba myVnetB. Haga clic en myVnetB
cuando aparezca en los resultados de la búsqueda. Aparece una hoja para la red virtual myVnetB .
15. En la hoja myVnetB que aparece, haga clic en Propiedades en la lista vertical de opciones que aparece a la
izquierda de la hoja. Copie el ID. DE RECURSO , ya que se usará en un paso posterior. El id. de recurso es
similar al del siguiente ejemplo:
/subscriptions/<Subscription
ID>/resourceGroups/myResourceGroupB/providers/[Link]/virtualNetworks/myVnetB

16. Complete los pasos 5 a 9 para myVnetB y escriba UserA en el paso 8.

17. Cierre sesión en el portal como UserB e inicie sesión como UserA.
18. En el cuadro Buscar recursos en la parte superior del portal, escriba myVnetA. Haga clic en myVnetA
cuando aparezca en los resultados de la búsqueda. Aparece una hoja para la red virtual myVnet .
19. Haga clic en myVnetA .
20. En la hoja myVnetA que aparece, haga clic en Emparejamientos en la lista vertical de opciones que
aparece a la izquierda de la hoja.
21. En la hoja myVnetA - Emparejamientos que aparece, haga clic en + Agregar .
22. En la hoja Agregar emparejamiento que aparece, escriba o seleccione las opciones siguientes y, luego,
haga clic en Aceptar :
Nombre : myVnetAToMyVnetB
Modelo de implementación de red vir tual : Seleccione Clásico .
Conozco mi Id. de recurso : Active esta casilla.
Identificador de recurso : escriba el identificador de recurso de myVnetB del paso 15.
Permitir acceso a red vir tual : asegúrese de que está seleccionada la opción Habilitado . En este
tutorial no se usa ninguna otra configuración. Para conocer todas las configuraciones de
emparejamiento, lea Manage virtual network peerings (Administración de emparejamientos de redes
virtuales).
23. Una vez que haga clic en Aceptar en el paso anterior, se cerrará la hoja Agregar emparejamiento y se
volverá a mostrar la hoja myVnetA - Emparejamientos . Unos segundos después, el emparejamiento que
creó aparece en la hoja. El estado Conectado aparece en la columna ESTADO DE EMPAREJAMIENTO
correspondiente al emparejamiento myVnetAToMyVnetB que ha creado. El emparejamiento está ahora
establecido. No es necesario emparejar la red virtual (clásica) a la red virtual (Resource Manager).
Los recursos de Azure que cree en cualquiera de las redes virtuales ahora se pueden comunicar entre sí
mediante sus direcciones IP. Si usa la resolución de nombres predeterminada de Azure para las redes
virtuales, los recursos de las redes virtuales no pueden resolver nombres entre las redes virtuales. Si desea
resolver nombres entre las redes virtuales de un emparejamiento, debe crear su propio servidor DNS.
Obtenga información sobre cómo configurar la resolución de nombres mediante su propio servidor DNS.
24. Opcional : Si bien este tutorial no aborda la creación de máquinas virtuales, puede crear una máquina
virtual en cada red virtual y conectar de una máquina virtual a la otra para así validar la conectividad.
25. Opcional : para eliminar los recursos que crea en este tutorial, complete los pasos que aparecen en la
sección Eliminación de recursos de este artículo.

Creación de emparejamiento: CLI de Azure

En este tutorial se usan cuentas diferentes para cada suscripción. Si está usando una cuenta que tiene permisos
para ambas suscripciones, puede usar la misma cuenta para todos los pasos, omitir los pasos para cerrar sesión en
Azure y quitar las líneas del script que crean las asignaciones de roles de usuario. Reemplace UserA@[Link] y
UserB@[Link] en todos los scripts siguientes por los nombres de usuario que está usando para UserA y UserB.
Complete los pasos siguientes mediante la CLI de Azure clásica y la CLI de Azure. Puede completar los pasos desde
Azure Cloud Shell. Para ello solo tiene que seleccionar el botón Tr y it (Pruébelo) en cualquiera de los pasos
siguientes o instalar la CLI clásica y la CLI, y ejecutar los comandos en el equipo local.
1. Si usa Cloud Shell, vaya al paso 2, ya que Cloud Shell inicia automáticamente la sesión de Azure. Abra una
sesión de comandos e inicie sesión en Azure mediante el comando azure login .
2. Ejecute la CLI clásica en modo de Administración de servicios escribiendo el comando
azure config mode asm .

3. Escriba el siguiente comando de la CLI clásica para crear la red virtual (clásica):
 azure network vnet create --vnet myVnetB --address-space [Link] --cidr 16 --location "East US"

4. Los pasos restantes tienen que realizarse mediante un shell de bash con la CLI de Azure (no la CLI clásica).
5. Copie el script siguiente en un editor de texto del equipo. Reemplace <SubscriptionB-Id> con el Id. de
suscripción. Si no conoce el Id. de suscripción, escriba el comando az account show . El valor de id en la
salida es el identificador de la suscripción. Copie el script modificado, péguelo en la sesión de la CLI y,
después, presione Enter .

az role assignment create \

--assignee UserA@[Link] \
--role "Classic Network Contributor" \
--scope /subscriptions/<SubscriptionB-Id>/resourceGroups/Default-
Networking/providers/[Link]/virtualNetworks/myVnetB

Cuando creó la red virtual (clásica) en el paso 4, Azure creó la red virtual en el grupo de recursos Default-
Networking.
6. Cierre sesión en Azure como UserB e inicie sesión como UserA en la CLI.
7. Cree un grupo de recursos y una red virtual (Resource Manager). Copie el script siguiente, péguelo en la
sesión de la CLI y después presione Enter .

#!/bin/bash

# Variables for common values used throughout the script.

rgName="myResourceGroupA"
location="eastus"

# Create a resource group.

az group create \
--name $rgName \
--location $location

# Create virtual network A (Resource Manager).

az network vnet create \
--name myVnetA \
--resource-group $rgName \
--location $location \
--address-prefix [Link]/16

# Get the id for myVnetA.

vNetAId=$(az network vnet show \
--resource-group $rgName \
--name myVnetA \
--query id --out tsv)

# Assign UserB permissions to myVnetA.

az role assignment create \
--assignee UserB@[Link] \
--role "Network Contributor" \
--scope $vNetAId

8. Cree un emparejamiento de redes virtuales entre las dos redes virtuales creadas mediante los modelos de
implementación diferentes. Copie el script siguiente en un editor de texto del equipo. Reemplace
<SubscriptionB-id> con el Id. de suscripción. Si no conoce el Id. de suscripción, escriba el comando
az account show . El valor de id en la salida es el identificador de la suscripción. Azure creó la red virtual
(clásica) que creó en el paso 4 en un grupo de recursos denominado Default-Networking. Pegue el script
modificado en la sesión de CLI y después presione Enter .
 # Peer VNet1 to VNet2.
az network vnet peering create \
--name myVnetAToMyVnetB \
--resource-group $rgName \
--vnet-name myVnetA \
--remote-vnet-id /subscriptions/<SubscriptionB-id>/resourceGroups/Default-
Networking/providers/[Link]/virtualNetworks/myVnetB \
--allow-vnet-access

9. Una vez que se ejecute el script, revise los emparejamientos de la red virtual (Resource Manager). Copie el
script siguiente y péguelo en la sesión de la CLI:

az network vnet peering list \

--resource-group $rgName \
--vnet-name myVnetA \
--output table

La salida muestra Conectado en la columna PeeringState .

Los recursos de Azure que cree en cualquiera de las redes virtuales ahora se pueden comunicar entre sí
mediante sus direcciones IP. Si usa la resolución de nombres predeterminada de Azure para las redes
virtuales, los recursos de las redes virtuales no pueden resolver nombres entre las redes virtuales. Si desea
resolver nombres entre las redes virtuales de un emparejamiento, debe crear su propio servidor DNS.
Obtenga información sobre cómo configurar la resolución de nombres mediante su propio servidor DNS.
10. Opcional : Si bien este tutorial no aborda la creación de máquinas virtuales, puede crear una máquina
virtual en cada red virtual y conectar de una máquina virtual a la otra para así validar la conectividad.
11. Opcional : para eliminar los recursos creados en este tutorial, complete los pasos de la sección Eliminar
recursos de este artículo.

Creación de emparejamiento: PowerShell

En este tutorial se usan cuentas diferentes para cada suscripción. Si está usando una cuenta que tiene permisos
para ambas suscripciones, puede usar la misma cuenta para todos los pasos, omitir los pasos para cerrar sesión en
Azure y quitar las líneas del script que crean las asignaciones de roles de usuario. Reemplace UserA@[Link] y
UserB@[Link] en todos los scripts siguientes por los nombres de usuario que está usando para UserA y UserB.
1. Instale la versión más reciente de los módulos Azure y Az de PowerShell. Si no está familiarizado con Azure
PowerShell, consulte Introducción a Azure PowerShell.
2. Inicie una sesión de PowerShell.
3. En PowerShell, inicie sesión en la suscripción de UserB como UserB escribiendo el comando
Add-AzureAccount . La cuenta con la que inicie sesión debe tener todos los permisos necesarios para crear
un emparejamiento de redes virtuales. Para ver una lista de permisos, consulte Permisos de
emparejamiento de red virtual.
4. Para crear una red virtual (clásica) con PowerShell, debe crear o modificar un archivo de configuración de
red existente. Obtenga información sobre cómo exportar, actualizar e importar archivos de configuración de
red. El archivo debe incluir el siguiente elemento Vir tualNetworkSite para la red virtual que se usa en
este tutorial:
 <VirtualNetworkSite name="myVnetB" Location="East US">
<AddressSpace>
<AddressPrefix>[Link]/16</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="default">
<AddressPrefix>[Link]/24</AddressPrefix>
</Subnet>
</Subnets>
</VirtualNetworkSite>

WARNING
Importar un archivo de configuración de red modificada puede producir cambios en las redes virtuales (clásicas)
existentes en la suscripción. Asegúrese de agregar solo la red virtual anterior y que no cambia o quita ninguna red
virtual existente de la suscripción.

5. Inicie sesión en la suscripción de UserB como UserB para usar los comandos de Resource Manager
escribiendo el comando Connect-AzAccount .
6. Asigne los permisos de UserA a la red virtual B. Copie el script siguiente en un editor de texto en su PC y
reemplace <SubscriptionB-id> con el Id. de suscripción B. Si no conoce el Id. de suscripción, escriba el
comando Get-AzSubscription para verlo. El valor de id en la salida devuelta es el identificador de la
suscripción. Azure creó la red virtual (clásica) que creó en el paso 4 en un grupo de recursos denominado
Default-Networking. Para ejecutar el script, copie el script modificado, péguelo en PowerShell y pulse Enter
.

New-AzRoleAssignment `
-SignInName UserA@[Link] `
-RoleDefinitionName "Classic Network Contributor" `
-Scope /subscriptions/<SubscriptionB-id>/resourceGroups/Default-
Networking/providers/[Link]/virtualNetworks/myVnetB

7. Cierre sesión en Azure como UserB e inicie sesión en la suscripción de UserA como UserA escribiendo el
comando Connect-AzAccount . La cuenta con la que inicie sesión debe tener todos los permisos necesarios
para crear un emparejamiento de redes virtuales. Para ver una lista de permisos, consulte Permisos de
emparejamiento de red virtual.
8. Para crear la red virtual (Resource Manager) copie el siguiente script, péguelo en PowerShell y después
presione Enter :

# Variables for common values

$rgName='MyResourceGroupA'
$location='eastus'

# Create a resource group.

New-AzResourceGroup `
-Name $rgName `
-Location $location

# Create virtual network A.

$vnetA = New-AzVirtualNetwork `
-ResourceGroupName $rgName `
-Name 'myVnetA' `
-AddressPrefix '[Link]/16' `
-Location $location
 9. Asigne los permisos de UserB a myVnetA. Copie el script siguiente en un editor de texto en su PC y
reemplace <SubscriptionA-Id> con el Id. de la suscripción A. Si no conoce el Id. de la suscripción, escriba el
comando Get-AzSubscription para verlo. El valor de id en la salida devuelta es el identificador de la
suscripción. Pegue la versión modificada del script en PowerShell y después presione Enter para
ejecutarlo.

New-AzRoleAssignment `
-SignInName UserB@[Link] `
-RoleDefinitionName "Network Contributor" `
-Scope /subscriptions/<SubscriptionA-
Id>/resourceGroups/myResourceGroupA/providers/[Link]/VirtualNetworks/myVnetA

10. Copie el script siguiente en un editor de texto de su equipo y reemplace <SubscriptionB-id> por el
identificador de la suscripción B. Para emparejar myVnetA con myVNetB, copie el script modificado, péguelo
en PowerShell y después presione Enter .

Add-AzVirtualNetworkPeering `
-Name 'myVnetAToMyVnetB' `
-VirtualNetwork $vnetA `
-RemoteVirtualNetworkId /subscriptions/<SubscriptionB-id>/resourceGroups/Default-
Networking/providers/[Link]/virtualNetworks/myVnetB

11. Para ver el estado de emparejamiento de myVnetA, copie el siguiente script, péguelo en PowerShell y
presione Enter .

Get-AzVirtualNetworkPeering `
-ResourceGroupName $rgName `
-VirtualNetworkName myVnetA `
| Format-Table VirtualNetworkName, PeeringState

El estado es Conectado . Cuando haya configurado el emparejamiento a myVnetA desde myVnetB,

cambiará a Conectado .
Los recursos de Azure que cree en cualquiera de las redes virtuales ahora se pueden comunicar entre sí
mediante sus direcciones IP. Si usa la resolución de nombres predeterminada de Azure para las redes
virtuales, los recursos de las redes virtuales no pueden resolver nombres entre las redes virtuales. Si desea
resolver nombres entre las redes virtuales de un emparejamiento, debe crear su propio servidor DNS.
Obtenga información sobre cómo configurar la resolución de nombres mediante su propio servidor DNS.
12. Opcional : Si bien este tutorial no aborda la creación de máquinas virtuales, puede crear una máquina
virtual en cada red virtual y conectar de una máquina virtual a la otra para así validar la conectividad.
13. Opcional : para eliminar los recursos creados en este tutorial, complete los pasos de la sección Eliminar
recursos de este artículo.

Eliminación de recursos
Cuando haya terminado este tutorial, es posible que quiera eliminar los recursos que creó en el tutorial, para no
incurrir en gastos de uso. Al eliminar un grupo de recursos se eliminan también todos los recursos contenidos en
el mismo.
Azure Portal
1. En el cuadro de búsqueda del portal, escriba myResourceGroupA . En los resultados de la búsqueda, haga clic
en myResourceGroupA .
2. En la hoja myResourceGroupA , haga clic en el icono Eliminar .
3. Para confirmar la eliminación, en el cuadro ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS , escriba
myResourceGroupA y, luego, haga clic en Eliminar .
4. En el cuadro Buscar recursos en la parte superior del portal, escriba myVnetB. Haga clic en myVnetB cuando
aparezca en los resultados de la búsqueda. Aparece una hoja para la red virtual myVnetB .
5. En la hoja myVnetB , haga clic en Eliminar .
6. Para confirmar la eliminación, haga clic en Sí en el cuadro Eliminar red vir tual .
Azure CLI
1. Inicie sesión en Azure con la CLI para eliminar la red virtual (Resource Manager) con el siguiente comando:

az group delete --name myResourceGroupA --yes

2. Inicie sesión en Azure con la CLI clásica para eliminar la red virtual (clásica) con los siguientes comandos:

azure config mode asm

azure network vnet delete --vnet myVnetB --quiet

PowerShell
1. En el símbolo del sistema de PowerShell, escriba el siguiente comando para eliminar la red virtual
(Resource Manager):

Remove-AzResourceGroup -Name myResourceGroupA -Force

2. Para eliminar la red virtual (clásica) con PowerShell, debe modificar un archivo de configuración de red
existente. Obtenga información sobre cómo exportar, actualizar e importar archivos de configuración de
red. Quite el siguiente elemento VirtualNetworkSite para la red virtual que se usa en este tutorial:

<VirtualNetworkSite name="myVnetB" Location="East US">

<AddressSpace>
<AddressPrefix>[Link]/16</AddressPrefix>
</AddressSpace>
<Subnets>
<Subnet name="default">
<AddressPrefix>[Link]/24</AddressPrefix>
</Subnet>
</Subnets>
</VirtualNetworkSite>

WARNING
Importar un archivo de configuración de red modificada puede producir cambios en las redes virtuales (clásicas)
existentes en la suscripción. Asegúrese de quitar solo la red virtual anterior y que no cambia o quita ninguna red
virtual existente de la suscripción.

Pasos siguientes
Conozca en profundidad las restricciones y comportamientos importantes del emparejamiento de redes
virtuales antes de crear un emparejamiento de redes virtuales para su uso en el entorno de producción.
Conozca toda la configuración de emparejamiento de redes virtuales.
Obtenga información sobre cómo crear una topología de red de concentrador y radio con emparejamiento de
redes virtuales.
 Crear, cambiar o eliminar un emparejamiento de red
virtual
23/09/2020 • 36 minutes to read • Edit Online

Aprenda a crear, cambiar o eliminar un emparejamiento de red virtual. El emparejamiento de red virtual permite
conectar redes virtuales de la misma región y entre regiones (lo que se conoce también como Emparejamiento
de VNET global) mediante la red troncal de Azure. Una vez emparejadas, las redes virtuales se siguen
administrando como recursos separados. Si no está familiarizado con el emparejamiento de redes virtuales,
puede obtener más información sobre él en la información general sobre el emparejamiento de redes virtuales
o si sigue un tutorial.

Antes de empezar
NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca
del nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.

Complete las tareas siguientes antes de seguir los pasos de las secciones de este artículo:
Si todavía no tiene una cuenta de Azure, regístrese para obtener una cuenta de evaluación gratuita.
Si utiliza el portal, abra [Link] e inicie sesión con una cuenta que tenga los permisos
necesarios para trabajar con emparejamientos.
Si usa comandos de PowerShell para completar las tareas de este artículo, ejecute los comandos que se
encuentran en Azure Cloud Shell o ejecute PowerShell en el equipo. Azure Cloud Shell es un shell interactivo
gratuito que puede usar para ejecutar los pasos de este artículo. Tiene las herramientas comunes de Azure
preinstaladas y configuradas para usarlas en la cuenta. Para realizar este tutorial, se necesita la versión 1.0.0
del módulo de Azure PowerShell u otra posterior. Ejecute Get-Module -ListAvailable Az para buscar la
versión instalada. Si necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si está
ejecutando PowerShell localmente, también debe ejecutar Connect-AzAccount con una cuenta que tenga los
permisos necesarios para trabajar con emparejamiento, para crear una conexión con Azure.
Si usa la interfaz de la línea de comandos (CLI) de Azure para completar las tareas de este artículo, ejecute los
comandos que se encuentran en Azure Cloud Shell o ejecute la CLI en el equipo. Para realizar este tutorial, es
necesaria la versión 2.0.31 de la CLI de Azure o una versión posterior. Ejecute az --version para buscar la
versión instalada. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure. Si está ejecutando la
CLI de Azure localmente, también debe ejecutar az login con una cuenta que tenga los permisos necesarios
para trabajar con emparejamiento, para crear una conexión con Azure.
La cuenta en la que inicia sesión o con la que se conecta a Azure debe tener asignado el rol de colaborador de
red o un rol personalizado que tenga asignadas las acciones apropiadas en Permisos.

Creación de un emparejamiento
Antes de crear un emparejamiento, familiarícese con los requisitos y las restricciones, así como los permisos
necesarios.
1. En el cuadro de búsqueda de la parte superior de Azure Portal, escriba redes virtuales. Cuando aparezca
la opción Redes vir tuales en los resultados de la búsqueda, selecciónela. No seleccione Redes
vir tuales (clásico) si aparece en la lista, ya que no se puede crear un emparejamiento de una red virtual
implementada mediante el modelo de implementación clásica.
2. Seleccione en la lista la red virtual que quiera emparejar.
3. En CONFIGURACIÓN , seleccione Emparejamientos .
4. Seleccione +Agregar .
5. Escriba o seleccione valores para la siguiente configuración:
Nombre: el nombre del emparejamiento debe ser único dentro de la red virtual.
Modelo de implementación de red vir tual: seleccione con qué modelo de implementación se
implementó la red virtual con la que quiere realizar el emparejamiento.
Conozco mi Id. de recurso : si tiene acceso de lectura a la red virtual con la que quiere realizar el
emparejamiento, no active esta casilla. Si no tiene acceso de lectura a la red virtual o la suscripción
con la que quiere realizar el emparejamiento, active esta casilla. Escriba el identificador de recurso
completo de la red virtual con la que quiere realizar el emparejamiento en el cuadro Id. de
recurso que aparece cuando se activa la casilla. El identificador de recurso que especifique debe
ser para una red virtual que exista en la misma región de Azure, o en una regióndiferente admitida,
que esta red virtual. El identificador de recurso completo es similar a
/subscriptions/<Id>/resourceGroups/<resource-group-
name>/providers/[Link]/virtualNetworks/<virtual-network-name>
. Para obtener el identificador de recurso de una red virtual, vea las propiedades de la red virtual.
Para obtener información sobre cómo ver las propiedades de una red virtual, consulte
Administración de redes virtuales. Si la suscripción está asociada a un inquilino de Azure Active
Directory que resulte ser diferente al de la suscripción que tiene la red virtual en la que está
creando el emparejamiento, primero debe agregar un usuario de cada inquilino como usuario
invitado en el inquilino opuesto.
Subscription (Suscripción): seleccione la suscripción de la red virtual con la que quiere realizar el
emparejamiento. Se muestran una o varias suscripciones, en función del número de suscripciones
al que tenga acceso de lectura su cuenta. Si ha activado la casilla Id. de recurso , esta opción no
está disponible.
Red vir tual: seleccione la red virtual con la que quiere realizar el emparejamiento. Puede
seleccionar una red virtual creada a través de cualquier modelo de implementación de Azure. Si
desea seleccionar una red virtual en otra región, debe seleccionar una red virtual en una región
admitida. Debe tener acceso de lectura a la red virtual para que sea visible en la lista. Si una red
virtual aparece en gris, puede deberse a que el espacio de direcciones de la red virtual se
superpone con el espacio de direcciones de esta red virtual. Si los espacios de direcciones de las
redes virtuales se superponen, no se pueden emparejar. Si ha activado la casilla Id. de recurso ,
esta opción no está disponible.
Permitir acceso a red vir tual : seleccione Habilitado (valor predeterminado) si quiere habilitar
la comunicación entre las dos redes virtuales. Al habilitar la comunicación entre las redes virtuales,
permite que los recursos conectados a cualquier red virtual se comuniquen entre sí con el mismo
ancho de banda y latencia que si estuvieran conectados a la misma red virtual. Todas las
comunicaciones entre los recursos de las dos redes virtuales se realizan a través de la red privada
de Azure. La etiqueta de servicio Vir tualNetwork para los grupos de seguridad de red abarca la
red virtual y la red virtual emparejada. Para más información acerca de las etiquetas de servicio de
los grupos de seguridad de red, consulte la información general sobre los grupos de seguridad de
red. Seleccione Deshabilitado si no quiere que el tráfico fluya a la red virtual emparejada. Por
ejemplo, podría seleccionar Deshabilitado si ha emparejado una red virtual con otra red virtual
pero quiere deshabilitar en ocasiones el flujo de tráfico entre ambas redes. Le resultará más
cómoda la opción de habilitar y deshabilitar que eliminar y volver a crear emparejamientos. Si esta
opción está deshabilitada, el tráfico no fluye entre las redes virtuales emparejadas.
Permitir tráfico reenviado: seleccione esta casilla para permitir que el tráfico que reenvió una
aplicación virtual de red desde una red virtual (este tráfico no se origina en la red virtual) fluya a
esta red virtual mediante un emparejamiento. Por ejemplo, supongamos que hay tres redes
virtuales llamadas Radio1, Radio2 y Concentrador. Existe un emparejamiento entre cada red virtual
de radio y la red virtual de concentrador, pero no existe ninguno entre las redes virtuales de radio.
Se implementa una aplicación virtual de red en la red virtual de concentrador, y las rutas definidas
por el usuario se aplican a cada red virtual de radio que redirige el tráfico entre las subredes a
través de la aplicación virtual de red. Si esta casilla no está seleccionada para realizar el
emparejamiento entre cada red virtual de radio y la red virtual de concentrador, el tráfico no fluye
entre las redes virtuales de radio porque el concentrador no reenvía el tráfico entre las redes
virtuales. Aunque el hecho de habilitar esta funcionalidad permite el tráfico reenviado a través del
emparejamiento, no se crean rutas definidas por el usuario ni aplicaciones virtuales de red. Las
rutas definidas por el usuario y las aplicaciones virtuales de red se crean por separado. Obtenga
información sobre las rutas definidas por el usuario. No es necesario comprobar esta
configuración si se reenvía el tráfico entre redes virtuales a través de VPN Gateway de Azure.
Permitir tránsito de puer ta de enlace: active esta casilla si tiene una puerta de enlace de red
virtual asociada a esta red virtual y quiere permitir que el tráfico procedente de la red virtual
emparejada fluya a través de la puerta de enlace. Por ejemplo, esta red virtual puede asociarse a
una red local a través de una puerta de enlace de red virtual. La puerta de enlace puede ser una
puerta de enlace de ExpressRoute o VPN. La selección de esta casilla permite que el tráfico
procedente de la red virtual emparejada fluya a través de la puerta de enlace asociada a esta red
virtual hacia la red local. Si activa esta casilla, la red virtual emparejada no puede tener una puerta
de enlace configurada. La red virtual emparejada debe tener seleccionada la casilla Usar puer tas
de enlace remotas cuando se configura el emparejamiento de la otra red virtual a esta red
virtual. Si deja esta casilla sin activar (valor predeterminado), el tráfico procedente de la red virtual
emparejada seguirá fluyendo a esta red virtual, pero no podrá fluir a través de una puerta de
enlace de red virtual asociada a esta red virtual. Si el emparejamiento es entre una red virtual
(Resource Manager) y una red virtual (clásica), la puerta de enlace debe estar en la red virtual
(Resource Manager).
Además de reenviar tráfico a una red local, una puerta de enlace VPN puede reenviar el tráfico de
red entre redes virtuales emparejadas con la red virtual en que se encuentra la puerta de enlace,
sin necesidad de que las redes virtuales se tengan que emparejar entre sí. Usar una puerta de
enlace VPN para reenviar el tráfico es útil si quiere usar una puerta de enlace VPN en una red
virtual de concentrador (vea el ejemplo de concentrador y radio descrito para Permitir tráfico
reenviado ) para redirigir el tráfico entre redes virtuales de radio que no están emparejadas entre
sí. Para obtener más información sobre permitir el uso de una puerta de enlace de tránsito,
consulte Configuración del tránsito de la puerta de enlace de VPN para el emparejamiento de red
virtual. Este escenario requiere la implementación de las rutas definidas por el usuario que
especifican la puerta de enlace de red virtual como el tipo de próximo salto. Obtenga información
sobre las rutas definidas por el usuario. Solo puede especificar una puerta de enlace VPN como un
tipo de próximo salto en una ruta definida por el usuario; no puede especificar una puerta de
enlace de ExpressRoute como el tipo de próximo salto en una ruta definida por el usuario.
Usar puer tas de enlace remotas: active esta casilla para permitir que el tráfico procedente de
esta red virtual fluya a través de la puerta de enlace de red virtual asociada a la red virtual con la
que está realizando el emparejamiento. Por ejemplo, la red virtual con la que está realizando el
emparejamiento tiene una puerta de enlace de VPN asociada que permite la comunicación a una
 red local. La activación de esta casilla permite que el tráfico procedente de esta red virtual fluya a
través de la puerta de enlace de VPN asociada a la red virtual emparejada. Si activa esta casilla, la
red virtual emparejada debe tener asociada una puerta de enlace de red virtual y debe tener
activada la casilla Permitir tránsito de puer ta de enlace . Si deja esta casilla sin activar (valor
predeterminado), el tráfico procedente de la red virtual emparejada todavía puede fluir a esta red
virtual, pero no podrá fluir a través de una puerta de enlace de red virtual asociada a esta red
virtual.
Esta opción puede estar habilitada solo en un emparejamiento de esta red virtual.
No puede usar las puertas de enlace remotas si ya tiene una puerta de enlace configurada en la
red virtual. Para obtener más información sobre el uso de una puerta de enlace de tránsito,
consulte Configuración del tránsito de la puerta de enlace de VPN para el emparejamiento de red
virtual.

NOTE
Si usa una puerta de enlace de red virtual para enviar el tráfico local de manera transitiva a una red virtual
emparejada, el intervalo IP de red virtual emparejada para el dispositivo VPN local debe establecerse en el tráfico
"interesante". De lo contrario, sus recursos locales no podrán comunicarse con recursos en la red virtual
emparejada.

6. Para agregar el emparejamiento a la red virtual que ha seleccionado, elija Aceptar .

Para obtener instrucciones paso a paso para implementar el emparejamiento entre redes virtuales de distintas
suscripciones y los modelos de implementación, consulte los pasos siguientes.
Comandos:
CLI de Azure : az network vnet peering create
PowerShell : Add-AzVirtualNetworkPeering

Visualización o cambio de la configuración de emparejamiento

Antes de cambiar un emparejamiento, familiarícese con los requisitos y las restricciones, así como con los
permisos necesarios.
1. En el cuadro de búsqueda de la parte superior del portal, escriba redes virtuales. Cuando aparezca la opción
Redes vir tuales en los resultados de la búsqueda, selecciónela. No seleccione Redes vir tuales (clásico) si
aparece en la lista, ya que no se puede crear un emparejamiento de una red virtual implementada mediante
el modelo de implementación clásica.
2. Seleccione en la lista la red virtual a la que quiera cambiar la configuración de emparejamiento.
3. En CONFIGURACIÓN , seleccione Emparejamientos .
4. Seleccione el emparejamiento cuya configuración quiere ver o cambiar.
5. Cambie los valores pertinentes. Obtenga información sobre las opciones de cada configuración en el paso 5
de la sección Crear un emparejamiento.
6. Seleccione Guardar .
Comandos
CLI de Azure : az network vnet peering list para mostrar los emparejamientos de una red virtual, az network
vnet peering show para mostrar la configuración de un emparejamiento específico y az network vnet peering
update para cambiar la configuración de emparejamiento.|
PowerShell : Get-AzVirtualNetworkPeering para recuperar y ver la configuración de emparejamiento y Set-
AzVirtualNetworkPeering para cambiar la configuración.
Eliminación de un emparejamiento
Antes de eliminar un emparejamiento, asegúrese de que la cuenta tiene los permisos necesarios.
Cuando se elimina un emparejamiento, el tráfico procedente de una red virtual ya no fluye a la red virtual
emparejada. Cuando se emparejan redes virtuales implementadas mediante el Administrador de recursos, cada
red virtual tiene un emparejamiento con la otra red virtual. Aunque el hecho de eliminar el emparejamiento de
una red virtual deshabilita la comunicación entre las redes virtuales, no elimina el emparejamiento de la otra red
virtual. El estado del emparejamiento que existe en la otra red virtual es Desconectado . Para volver a crear el
emparejamiento, primero tendrá que volver a crear el emparejamiento en la primera red virtual y el estado de
emparejamiento de ambas redes virtuales deberá haber cambiado a Conectado.
Si quiere que las redes virtuales se comuniquen algunas veces pero no siempre, en lugar de eliminar un
emparejamiento, puede establecer el valor Permitir acceso a red vir tual en Deshabilitado . Para información
sobre cómo hacerlo, vea el paso 6 de la sección Crear un emparejamiento de este artículo. Probablemente le
resulte más fácil deshabilitar y habilitar el acceso a la red que eliminar y volver a crear emparejamientos.
1. En el cuadro de búsqueda de la parte superior del portal, escriba redes virtuales. Cuando aparezca la opción
Redes vir tuales en los resultados de la búsqueda, selecciónela. No seleccione Redes vir tuales (clásico) si
aparece en la lista, ya que no se puede crear un emparejamiento de una red virtual implementada mediante
el modelo de implementación clásica.
2. Seleccione en la lista la red virtual de la cual quiera eliminar el emparejamiento.
3. En CONFIGURACIÓN , seleccione Emparejamientos .
4. En el lado derecho del emparejamiento que quiere eliminar, seleccione ... , Eliminar y, a continuación,
seleccione Sí para eliminar el emparejamiento de la primera red virtual.
5. Complete los pasos anteriores para eliminar el emparejamiento de la otra red virtual del emparejamiento.
Comandos
CLI de Azure : az network vnet peering delete
PowerShell : Remove-AzVirtualNetworkPeering

Requisitos y restricciones
Puede emparejar redes virtuales de la misma región o de regiones diferentes. El emparejamiento de
redes virtuales de diferentes regiones se conoce también como emparejamiento de VNet global.
Al crear un emparejamiento global, las redes virtuales emparejadas pueden existir en cualquier región de
la nube pública de Azure, en las regiones de la nube de China o en las regiones de la nube de
Government. No se puede realizar un emparejamiento entre nubes. Por ejemplo, no se puede emparejar
una red virtual en la nube pública de Azure con una red virtual en la nube de Azure China.
Los recursos de una red virtual no pueden comunicarse con la dirección IP de front-end de un
equilibrador de carga interno básico en una red virtual emparejada globalmente. La compatibilidad con el
equilibrador de carga básico solo existe dentro de la misma región. Hay compatibilidad con Standard
Load Balancer para Emparejamiento de VNet y Emparejamiento de VNet Global. Los servicios que usan
un equilibrador de carga básico que no funcionarán a través de Emparejamiento de VNet global se
documentan aquí.
Puede usar puertas de enlace remotas o permitir el tránsito de puerta de enlace en redes virtuales
emparejadas globalmente y redes virtuales emparejadas localmente.
Las redes virtuales pueden estar en la misma suscripción o en suscripciones distintas. Cuando empareja
redes virtuales en distintas suscripciones, ambas suscripciones pueden estar asociadas al mismo inquilino
de Azure Active Directory o a uno diferente. Si todavía no tiene un inquilino de AD, puede crear uno.
Las redes virtuales que empareje deben tener espacios de direcciones IP que no se solapen.
Una vez que una red virtual se ha emparejado con otra red virtual, no se pueden agregar rangos de
direcciones al espacio de direcciones de una red virtual ni pueden eliminarse de este. Para agregar o
quitar rangos de direcciones, elimine el emparejamiento, agregue o quite los rangos de direcciones y, a
continuación, vuelva a crear el emparejamiento. Para agregar rangos de direcciones a las redes virtuales o
quitarlos, consulte Manage virtual networks (Administrar redes virtuales).
Es posible emparejar dos redes virtuales implementadas mediante el Administrador de recursos, o bien
una red virtual implementada mediante el Administrador de recursos con una red virtual implementada
mediante el modelo de implementación clásica. No se pueden emparejar dos redes virtuales creadas
mediante el modelo de implementación clásica. Si no está familiarizado con los modelos de
implementación de Azure, vea el artículo de descripción de los modelos de implementación de Azure.
Puede usar VPN Gateway para conectar dos redes virtuales creadas mediante el modelo de
implementación clásica.
Cuando se emparejan dos redes virtuales creadas mediante el Administrador de recursos, debe
configurarse un emparejamiento para cada red virtual en el emparejamiento. Vea uno de los tipos
siguientes de estado de emparejamiento:
Iniciado: Cuando se crea el emparejamiento a la segunda red virtual desde la primera red virtual, el
estado de emparejamiento es Iniciado.
Conectado: Cuando se crea el emparejamiento desde la segunda red virtual a la primera red virtual, el
estado de emparejamiento es Conectado. Si consulta el estado de emparejamiento de la primera red
virtual, verá que ha cambiado de Iniciado a Conectado. El emparejamiento no se habrá establecido
correctamente mientras el estado de ambos emparejamientos de red virtual no sea Conectado.
Al emparejar una red virtual creada mediante el Administrador de recursos con una red virtual creada
mediante el modelo de implementación clásica, solo se configura un emparejamiento para la red virtual
implementada mediante el Administrador de recursos. No se puede configurar el emparejamiento para
una red virtual (clásica), o bien entre dos redes virtuales implementadas mediante el modelo de
implementación clásica. Cuando se crea el emparejamiento de la red virtual (Administrador de recursos)
a la red virtual (clásica), el estado de emparejamiento es Actualizando, pero en breve cambia a Conectado.
El emparejamiento se establece entre dos redes virtuales. Los emparejamientos por sí solos no son
transitivos. Si crea emparejamientos entre:
VirtualNetwork1 y VirtualNetwork2: VirtualNetwork1 y VirtualNetwork2
VirtualNetwork2 y VirtualNetwork3: VirtualNetwork2 y VirtualNetwork3
No hay ningún emparejamiento entre VirtualNetwork1 y VirtualNetwork3 a través de VirtualNetwork2.
Si desea crear un emparejamiento de red virtual entre VirtualNetwork1 y VirtualNetwork3, debe crear un
emparejamiento entre VirtualNetwork1 y VirtualNetwork3. No hay ningún emparejamiento entre
VirtualNetwork1 y VirtualNetwork3 a través de VirtualNetwork2. Si desea que VirtualNetwork1 y
VirtualNetwork3 se comuniquen directamente, debe crear un emparejamiento explícito entre
VirtualNetwork1 y VirtualNetwork3 o recorrer una NVA en la red del concentrador.
No se pueden resolver nombres en redes virtuales emparejadas mediante la resolución de nombres
predeterminada de Azure. Para resolver nombres de otras redes virtuales, tiene que usar Azure DNS para
dominios privados o un servidor DNS personalizado. Para obtener información sobre cómo configurar el
servidor DNS, consulte Resolución de nombres mediante su propio servidor DNS.
Los recursos de ambas redes virtuales emparejadas en la misma región pueden comunicarse entre sí con
el mismo ancho de banda y latencia que si estuvieran en la misma red virtual. A pesar de ello, el tamaño
de cada máquina virtual tiene su propio ancho de banda de red máximo. Para más información sobre el
ancho de banda de red máximo para los diferentes tamaños de máquina virtual, consulte los artículos
sobre los tamaños de máquina virtual Windows o Linux.
 Una red virtual puede emparejarse con otra red virtual y también conectarse a otra red virtual con una
puerta de enlace de red virtual de Azure. Cuando las redes virtuales están conectadas mediante
emparejamiento y una puerta de enlace, el tráfico entre las redes virtuales fluye a través de la
configuración de emparejamiento, en lugar de la puerta de enlace.
Para asegurarse de que se están descargando las nuevas rutas en el cliente, los clientes VPN de punto a
sitio deben descargarse de nuevo después de que el emparejamiento de red virtual se haya configurado
correctamente.
Hay un cargo nominal para el tráfico de entrada y salida que utiliza un emparejamiento de red virtual.
Consulte la página de preciospara obtener más información.

Permisos
Las cuentas que use para trabajar con el emparejamiento de redes virtuales deben asignarse a los siguientes
roles:
Colaborador de red: para una red virtual implementada mediante Resource Manager.
Colaborador de la red virtual clásica: para una red virtual implementada a través del modelo de
implementación clásico.
Si su cuenta no está asignada a uno de los roles anteriores, se debe asignar a un rol personalizado que tenga
asignadas las acciones necesarias de la tabla siguiente:

A C C IÓ N N O M B RE

[Link]/virtualNetworks/virtualNetworkPeerings/ Necesaria para crear un emparejamiento desde la red virtual

write A hasta la red virtual B. La red virtual A debe ser una red
virtual (Resource Manager)

[Link]/virtualNetworks/peer/action Necesaria para crear un emparejamiento desde la red virtual

B (Resource Manager) a la red virtual A

[Link]/virtualNetworks/peer/action Necesaria para crear un emparejamiento desde la red virtual

B (clásica) a la red virtual A

[Link]/virtualNetworks/virtualNetworkPeerings/r Lectura de un emparejamiento de redes virtuales

ead

[Link]/virtualNetworks/virtualNetworkPeerings/ Eliminación de un emparejamiento de redes virtuales

delete

Pasos siguientes
Un emparejamiento de redes virtuales se crea entre redes virtuales creadas mediante el mismo modelo
de implementación o mediante modelos distintos que existen en la misma suscripción o en cualquier
suscripción diferente. Realice el tutorial para uno de los siguientes escenarios:

M O DELO DE IM P L EM EN TA C IÓ N DE A Z URE SUSC RIP C IÓ N

Ambas mediante Resource Manager La misma

Diferente

Una mediante Resource Manager y la otra clásica La misma

 M O DELO DE IM P L EM EN TA C IÓ N DE A Z URE SUSC RIP C IÓ N

Diferente

Aprenda a crear una topología de red de concentrador y radio

Crear un emparejamiento de redes virtuales con scripts de ejemplo de PowerShell o de la CLI de Azure, o
bien con plantillas de Resource Manager
Crear y asignar definiciones de Azure Policy para redes virtuales
 Configuración de una conexión de VPN Gateway de
red virtual a red virtual mediante PowerShell
23/09/2020 • 36 minutes to read • Edit Online

Este artículo le ayuda a conectarse a redes virtuales mediante el tipo de conexión de red virtual a red virtual. Las
redes virtuales pueden estar en la misma región o en distintas, así como pertenecer a una única suscripción o a
varias. Al conectar redes virtuales de distintas suscripciones, estas no necesitan estar asociadas con el mismo
inquilino de Active Directory.
Los pasos descritos en este artículo se aplican al modelo de implementación de Resource Manager y utilizan
PowerShell. También se puede crear esta configuración con una herramienta o modelo de implementación
distintos, mediante la selección de una opción diferente en la lista siguiente:

Acerca de la conexión de redes virtuales

Hay varias formas de conectar redes virtuales. Las siguientes secciones describen distintas formas de conectar
redes virtuales.
De red virtual a red virtual
La configuración de una conexión entre redes virtuales es una buena manera de conectar redes virtuales
fácilmente. La conexión de una red virtual a otra mediante el tipo de conexión entre redes virtuales (VNet2VNet)
es parecida a la creación de una conexión IPsec de sitio a sitio en una ubicación local. Ambos tipos de conectividad
usan una puerta de enlace de VPN para proporcionar un túnel seguro mediante IPsec/IKE y los dos funcionan de
la misma forma en lo relativo a la comunicación. La diferencia entre ambos tipos de conexión radica en la manera
en que se configura la puerta de enlace de red local. Al crear una conexión entre redes virtuales, no se ve el
espacio de direcciones de la puerta de enlace de red local. Se crea y rellena automáticamente. Si actualiza el
espacio de direcciones de una de las redes virtuales, la otra sabe automáticamente cómo realizar el enrutamiento
al espacio de direcciones actualizado. La creación de una conexión entre redes virtuales suele ser más rápida y
sencilla que la creación de una conexión de sitio a sitio entre redes virtuales.
De sitio a sitio (IPsec)
Si puntualmente trabaja con una configuración de red complicada, puede que prefiera conectar sus redes virtuales
mediante los pasos que se indican en Creación de una red virtual con una conexión VPN de sitio a sitio mediante
PowerShell, en lugar de las instrucciones para la conexión entre redes virtuales. Cuando se usan las instrucciones
para la conexión de sitio a sitio, las puertas de enlace de red locales se crean y se configuran manualmente. La
puerta de enlace de red local de cada red virtual trata a la otra red virtual como un sitio local. De esta forma,
puede especificar más espacio de direcciones para la puerta de enlace de red local a fin de enrutar el tráfico. Si el
espacio de direcciones de una red virtual cambia, es preciso que actualice la puerta de enlace de red local
correspondiente para reflejar dicho cambio. No se actualiza automáticamente.
Emparejamiento de VNET
Puede que desee considerar conectar sus redes virtuales mediante el emparejamiento de VNET. El
emparejamiento de VNET no utiliza una puerta de enlace de VPN y tiene distintas restricciones. Además, los
precios del emparejamiento de VNET se calculan de forma diferente que los precios de VPN Gateway entre redes
virtuales. Para más información, consulte Emparejamiento de VNET.

¿Por qué crear una conexión de red virtual a red virtual?

Puede que desee conectar redes virtuales con una conexión entre redes virtuales por las siguientes razones:
 Presencia geográfica y redundancia geográfica entre regiones
Puede configurar su propia replicación geográfica o sincronización con conectividad segura sin recurrir
a los puntos de conexión a Internet.
Con el Equilibrador de carga y el Administrador de tráfico de Azure, puede configurar cargas de trabajo
de alta disponibilidad con redundancia geográfica en varias regiones de Azure. Por ejemplo, puede
configurar AlwaysOn de SQL con grupos de disponibilidad distribuidos en varias regiones de Azure.
Aplicaciones regionales de niveles múltiples con aislamiento o un límite administrativo
Dentro de la misma región, se pueden configurar aplicaciones de niveles múltiples con varias redes
virtuales conectadas entre sí para cumplir requisitos administrativos o de aislamiento.
Se puede combinar la comunicación entre redes virtuales con configuraciones de varios sitios. Esto permite
establecer topologías de red que combinen la conectividad entre entornos con la conectividad entre redes
virtuales.

¿Qué instrucciones para la conexión entre redes virtuales debo seguir?

En este artículo, verá dos conjuntos de pasos diferentes. Un conjunto de pasos para las redes virtuales que residen
en la misma suscripción y otro para las redes virtuales que residen en suscripciones diferentes. La principal
diferencia entre ambos conjuntos es que debe utilizar sesiones de PowerShell independientes al configurar las
conexiones de redes virtuales que residen en distintas suscripciones.
Para este ejercicio, puede combinar las configuraciones, o bien elegir con la que desea trabajar. Todas las
configuraciones utilizan el tipo de conexión entre redes virtuales. Flujos de tráfico de red entre las redes virtuales
que están directamente conectados entre sí. En este ejercicio, el tráfico de TestVNet4 no se enruta a TestVNet5.
Redes virtuales que residen en la misma suscripción: En los pasos para esta configuración se utilizan
TestVNet1 y TestVNet4.

Redes virtuales que residen en distintas suscripciones: En los pasos para esta configuración se utilizan
TestVNet1 y TestVNet5.

Conexión de redes virtuales que están en la misma suscripción

Antes de empezar
 NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.

Dado que se tarda hasta 45 minutos en crear una puerta de enlace, el tiempo de Azure Cloud Shell expirara
periódicamente durante este ejercicio. Para reiniciar Cloud Shell, haga clic en la esquina superior izquierda
del terminal. No olvide volver a declarar las variables cuando se reinicie el terminal.
Si prefiere instalar la versión más reciente del módulo Azure PowerShell localmente, consulte el artículo de
Instalación y configuración de Azure PowerShell.
Paso 1: Planeamiento de los intervalos de direcciones IP
En los pasos siguientes, se crean dos redes virtuales junto con sus subredes de puerta de enlace y configuraciones
correspondientes. Luego, se crea una conexión VPN entre las dos redes virtuales. Es importante planear los
intervalos de direcciones IP para la configuración de red. Tenga en cuenta que hay que asegurarse de que ninguno
de los intervalos de VNet o intervalos de red local se solapen. En estos ejemplos, no se incluye ningún servidor
DNS. Si desea disponer de resolución de nombres en las redes virtuales, consulte Resolución de nombres.
En los ejemplos usamos los siguientes valores:
Valores para TestVNet1:
Nombre de la red virtual: TestVNet1
Grupo de recursos: TestRG1
Ubicación: Este de EE. UU.
TestVNet1: [Link]/16 y [Link]/16
front-end: [Link]/24
BackEnd: [Link]/24
GatewaySubnet: [Link]/27
GatewayName: VNet1GW
Public IP: VNet1GWIP
VPNType: RouteBased
Connection(1to4): VNet1toVNet4
Connection(1to5): VNet1toVNet5 (para redes virtuales de suscripciones distintas)
ConnectionType: VNet2VNet
Valores para TestVNet4:
Nombre de la red virtual: TestVNet4
TestVNet2: [Link]/16 y [Link]/16
front-end: [Link]/24
BackEnd: [Link]/24
GatewaySubnet: [Link]/27
Grupo de recursos: TestRG4
Ubicación: Oeste de EE. UU.
GatewayName: VNet4GW
Public IP: VNet4GWIP
VPNType: RouteBased
 Conexión: VNet4toVNet1
ConnectionType: VNet2VNet
Paso 2: Creación y configuración de TestVNet1
1. Compruebe la configuración de la suscripción.
Si ejecuta Azure PowerShell localmente en el equipo, conéctese a la cuenta. Si usa Azure Cloud Shell, se
conectará automáticamente.

Connect-AzAccount

Compruebe las suscripciones para la cuenta.

Get-AzSubscription

Si tiene varias suscripciones, seleccione la que quera usar.

Select-AzSubscription -SubscriptionName nameofsubscription

2. Declare las variables. En este ejemplo se declaran las variables con los valores para este ejercicio. En la
mayoría de los casos, deberá reemplazar los valores por los suyos propios. No obstante, puede usar estas
variables si está practicando los pasos para familiarizarse con este tipo de configuración. Si es necesario,
modifique las variables y después cópielas y péguelas en la consola de PowerShell.

$RG1 = "TestRG1"
$Location1 = "East US"
$VNetName1 = "TestVNet1"
$FESubName1 = "FrontEnd"
$BESubName1 = "Backend"
$VNetPrefix11 = "[Link]/16"
$VNetPrefix12 = "[Link]/16"
$FESubPrefix1 = "[Link]/24"
$BESubPrefix1 = "[Link]/24"
$GWSubPrefix1 = "[Link]/27"
$GWName1 = "VNet1GW"
$GWIPName1 = "VNet1GWIP"
$GWIPconfName1 = "gwipconf1"
$Connection14 = "VNet1toVNet4"
$Connection15 = "VNet1toVNet5"

3. Cree un grupo de recursos.

New-AzResourceGroup -Name $RG1 -Location $Location1

4. Cree las configuraciones de subred para TestVNet1. En este ejemplo se crea una red virtual denominada
TestVNet1 y tres subredes llamadas: GatewaySubnet, FrontEnd y Backend. Al reemplazar valores, es
importante que siempre asigne el nombre GatewaySubnet a la subred de la puerta de enlace. Si usa otro,
se produce un error al crear la puerta de enlace. Por esta razón, no se asigna a través de la variable
siguiente.
El siguiente ejemplo usa las variables que estableció anteriormente. En este ejemplo, la subred de la puerta
de enlace está usando un /27. Aunque es posible crear una subred de puerta de enlace tan pequeña como
/29, se recomienda que cree una subred mayor que incluya más direcciones seleccionando al menos /28 o
/27. Esto permitirá suficientes direcciones para dar cabida a posibles configuraciones adicionales que desee
 en el futuro.

$fesub1 = New-AzVirtualNetworkSubnetConfig -Name $FESubName1 -AddressPrefix $FESubPrefix1

$besub1 = New-AzVirtualNetworkSubnetConfig -Name $BESubName1 -AddressPrefix $BESubPrefix1
$gwsub1 = New-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -AddressPrefix $GWSubPrefix1

5. Cree TestVNet1.

New-AzVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1 `

-Location $Location1 -AddressPrefix $VNetPrefix11,$VNetPrefix12 -Subnet $fesub1,$besub1,$gwsub1

6. Solicite que se asigne una dirección IP pública a la puerta de enlace que creará para la red virtual. Observe
que AllocationMethod es dinámico. No puede especificar la dirección IP que desea usar. Se asigna
dinámicamente a la puerta de enlace.

$gwpip1 = New-AzPublicIpAddress -Name $GWIPName1 -ResourceGroupName $RG1 `

-Location $Location1 -AllocationMethod Dynamic

7. Establezca la configuración de la puerta de enlace. La configuración de puerta de enlace define la subred y

la dirección IP pública. Use el ejemplo para crear la configuración de la puerta de enlace.

$vnet1 = Get-AzVirtualNetwork -Name $VNetName1 -ResourceGroupName $RG1

$subnet1 = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet1
$gwipconf1 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName1 `
-Subnet $subnet1 -PublicIpAddress $gwpip1

8. Cree la puerta de enlace para TestVNet1. En este paso, creará la puerta de enlace de red virtual para
TestVNet1. Las configuraciones VNet a VNet requieren un VpnType RouteBased. La creación de una puerta
de enlace suele tardar 45 minutos o más, según la SKU de la puerta de enlace seleccionada.

New-AzVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1 `

-Location $Location1 -IpConfigurations $gwipconf1 -GatewayType Vpn `
-VpnType RouteBased -GatewaySku VpnGw1

Cuando termine con los comandos, esta puerta de enlace tardará hasta 45 minutos en crearse. Si usa Azure Cloud
Shell, puede reiniciar la sesión; para ello, haga clic en la esquina superior izquierda del terminal de Cloud Shell y
configure TestVNet4. No es necesario esperar hasta que se complete la puerta de enlace de TestVNet1.
Paso 3: Creación y configuración de TestVNet4
Una vez que haya configurado TestVNet1, cree TestVNet4. Siga los pasos a continuación y reemplace los valores
por los suyos propios cuando sea necesario.
1. Conéctese y declare las variables. Asegúrese de reemplazar los valores por los que desea usar para su
configuración.
 $RG4 = "TestRG4"
$Location4 = "West US"
$VnetName4 = "TestVNet4"
$FESubName4 = "FrontEnd"
$BESubName4 = "Backend"
$VnetPrefix41 = "[Link]/16"
$VnetPrefix42 = "[Link]/16"
$FESubPrefix4 = "[Link]/24"
$BESubPrefix4 = "[Link]/24"
$GWSubPrefix4 = "[Link]/27"
$GWName4 = "VNet4GW"
$GWIPName4 = "VNet4GWIP"
$GWIPconfName4 = "gwipconf4"
$Connection41 = "VNet4toVNet1"

2. Cree un grupo de recursos.

New-AzResourceGroup -Name $RG4 -Location $Location4

3. Cree las configuraciones de subred para TestVNet4.

$fesub4 = New-AzVirtualNetworkSubnetConfig -Name $FESubName4 -AddressPrefix $FESubPrefix4

$besub4 = New-AzVirtualNetworkSubnetConfig -Name $BESubName4 -AddressPrefix $BESubPrefix4
$gwsub4 = New-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -AddressPrefix $GWSubPrefix4

4. Cree TestVNet4.

New-AzVirtualNetwork -Name $VnetName4 -ResourceGroupName $RG4 `

-Location $Location4 -AddressPrefix $VnetPrefix41,$VnetPrefix42 -Subnet $fesub4,$besub4,$gwsub4

5. Pida una dirección IP pública.

$gwpip4 = New-AzPublicIpAddress -Name $GWIPName4 -ResourceGroupName $RG4 `

-Location $Location4 -AllocationMethod Dynamic

6. Establezca la configuración de la puerta de enlace.

$vnet4 = Get-AzVirtualNetwork -Name $VnetName4 -ResourceGroupName $RG4

$subnet4 = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet4
$gwipconf4 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName4 -Subnet $subnet4 -PublicIpAddress
$gwpip4

7. Creación de la puerta de enlace de TestVNet4. La creación de una puerta de enlace suele tardar 45 minutos
o más, según la SKU de la puerta de enlace seleccionada.

New-AzVirtualNetworkGateway -Name $GWName4 -ResourceGroupName $RG4 `

-Location $Location4 -IpConfigurations $gwipconf4 -GatewayType Vpn `
-VpnType RouteBased -GatewaySku VpnGw1

Paso 4: Creación de las conexiones

Espere hasta que se hayan completado ambas puertas de enlace. Reinicie la sesión de Azure Cloud Shell, y copie y
pegue las variables del principio del paso 2 y el paso 3 en la consola para volver a declarar los valores.
1. Obtenga ambas puertas de enlace de red virtual.
 $vnet1gw = Get-AzVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1
$vnet4gw = Get-AzVirtualNetworkGateway -Name $GWName4 -ResourceGroupName $RG4

2. Cree la conexión de TestVNet1 a TestVNet4. En este paso, creará la conexión de TestVNet1 a TestVNet4. Verá
una clave compartida a la que se hace referencia en los ejemplos. Puede utilizar sus propios valores para la
clave compartida. Lo importante es que la clave compartida coincida en ambas conexiones. Se tardará unos
momentos en terminar de crear la conexión.

New-AzVirtualNetworkGatewayConnection -Name $Connection14 -ResourceGroupName $RG1 `

-VirtualNetworkGateway1 $vnet1gw -VirtualNetworkGateway2 $vnet4gw -Location $Location1 `
-ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'

3. Cree la conexión de TestVNet4 a TestVNet1. Este paso es similar al anterior, salvo en que se crea la conexión
de TestVNet4 a TestVNet1. Asegúrese de que coincidan las claves compartidas. Después de unos minutos,
se habrá establecido la conexión.

New-AzVirtualNetworkGatewayConnection -Name $Connection41 -ResourceGroupName $RG4 `

-VirtualNetworkGateway1 $vnet4gw -VirtualNetworkGateway2 $vnet1gw -Location $Location4 `
-ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'

4. Compruebe la conexión. Consulte la sección Comprobación de la conexión.

Conexión de redes virtuales que están en suscripciones diferentes

En este escenario, se conectan TestVNet1 y TestVNet5. TestVNet1 y TestVNet5 residen en suscripciones diferentes.
Las suscripciones no necesitan estar asociadas con el mismo inquilino de Active Directory.
La diferencia entre estos pasos y el conjunto anterior es que parte de los pasos de configuración se deben realizar
en una sesión de PowerShell distinta en el contexto de la segunda suscripción. Especialmente cuando las dos
suscripciones pertenecen a distintas organizaciones.
Debido al cambio de contexto de la suscripción en este ejercicio, al llegar al paso 8 le resultará más fácil usar
PowerShell localmente en el equipo, en lugar de utilizar Azure Cloud Shell.
Paso 5: Creación y configuración de TestVNet1
Tiene que completar el paso 1 y el paso 2 de la sección anterior para crear y configurar TestVNet1 y VPN Gateway
para TestVNet1. Para esta configuración, no se necesita crear TestVNet4 de la sección anterior, aunque, si la creó,
no entrará en conflicto con estos pasos. Cuando haya completado el paso 1 y el 2, continúe con el paso 6 para
crear TestVNet5.
Paso 6: Comprobación de los intervalos de direcciones IP
Es importante asegurarse de que el espacio de direcciones IP de la red virtual nueva, TestVNet5, no se solape con
ninguno de los intervalos de red virtual o de puerta de enlace de red local. En este ejemplo, las redes virtuales
pueden pertenecer a distintas organizaciones. En este ejercicio, use los siguientes valores para TestVNet5:
Valores para TestVNet5:
Nombre de la red virtual: TestVNet5
Grupo de recursos: TestRG5
Ubicación: Japón Oriental
TestVNet5: [Link]/16 y [Link]/16
front-end: [Link]/24
BackEnd: [Link]/24
 GatewaySubnet: [Link].0/27
GatewayName: VNet5GW
Public IP: VNet5GWIP
VPNType: RouteBased
Conexión: VNet5toVNet1
ConnectionType: VNet2VNet
Paso 7: Creación y configuración de TestVNet5
Este paso debe realizarse en el contexto de la nueva suscripción. Es posible que esta parte la realice el
administrador de otra organización que posea la suscripción.
1. Declare las variables. Asegúrese de reemplazar los valores por los que desea usar para su configuración.

$Sub5 = "Replace_With_the_New_Subscription_Name"
$RG5 = "TestRG5"
$Location5 = "Japan East"
$VnetName5 = "TestVNet5"
$FESubName5 = "FrontEnd"
$BESubName5 = "Backend"
$GWSubName5 = "GatewaySubnet"
$VnetPrefix51 = "[Link]/16"
$VnetPrefix52 = "[Link]/16"
$FESubPrefix5 = "[Link]/24"
$BESubPrefix5 = "[Link]/24"
$GWSubPrefix5 = "[Link]/27"
$GWName5 = "VNet5GW"
$GWIPName5 = "VNet5GWIP"
$GWIPconfName5 = "gwipconf5"
$Connection51 = "VNet5toVNet1"

2. Conéctese con la suscripción 5. Abre la consola de PowerShell y conéctate a tu cuenta. Use el siguiente
ejemplo para ayudarle a conectarse:

Connect-AzAccount

Compruebe las suscripciones para la cuenta.

Get-AzSubscription

Especifique la suscripción que desea usar.

Select-AzSubscription -SubscriptionName $Sub5

3. Cree un nuevo grupo de recursos.

New-AzResourceGroup -Name $RG5 -Location $Location5

4. Cree las configuraciones de subred para TestVNet5.

$fesub5 = New-AzVirtualNetworkSubnetConfig -Name $FESubName5 -AddressPrefix $FESubPrefix5

$besub5 = New-AzVirtualNetworkSubnetConfig -Name $BESubName5 -AddressPrefix $BESubPrefix5
$gwsub5 = New-AzVirtualNetworkSubnetConfig -Name $GWSubName5 -AddressPrefix $GWSubPrefix5

5. Cree TestVNet5.
 New-AzVirtualNetwork -Name $VnetName5 -ResourceGroupName $RG5 -Location $Location5 `
-AddressPrefix $VnetPrefix51,$VnetPrefix52 -Subnet $fesub5,$besub5,$gwsub5

6. Pida una dirección IP pública.

$gwpip5 = New-AzPublicIpAddress -Name $GWIPName5 -ResourceGroupName $RG5 `

-Location $Location5 -AllocationMethod Dynamic

7. Establezca la configuración de la puerta de enlace.

$vnet5 = Get-AzVirtualNetwork -Name $VnetName5 -ResourceGroupName $RG5

$subnet5 = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet5
$gwipconf5 = New-AzVirtualNetworkGatewayIpConfig -Name $GWIPconfName5 -Subnet $subnet5 -PublicIpAddress
$gwpip5

8. Cree la puerta de enlace de TestVNet5.

New-AzVirtualNetworkGateway -Name $GWName5 -ResourceGroupName $RG5 -Location $Location5 `

-IpConfigurations $gwipconf5 -GatewayType Vpn -VpnType RouteBased -GatewaySku VpnGw1

Paso 8: Creación de las conexiones

En este ejemplo, como las puertas de enlace están en suscripciones diferentes, hemos dividido el paso en dos
sesiones de PowerShell marcadas como [Suscripción 1] y [Suscripción 5].
1. [Suscripción 1] Obtenga la puerta de enlace de red virtual para la suscripción 1. Inicie sesión y conéctese
a la Suscripción 1 antes de ejecutar el siguiente ejemplo:

$vnet1gw = Get-AzVirtualNetworkGateway -Name $GWName1 -ResourceGroupName $RG1

Copie la salida de los siguientes elementos y envíesela al administrador de la suscripción 5 por correo
electrónico u otro método.

$[Link]
$[Link]

Estos dos elementos tendrán valores similares a la salida de ejemplo siguiente:

PS D:\> $[Link]
VNet1GW
PS D:\> $[Link]
/subscriptions/b636ca99-6f88-4df4-a7c3-
2f8dc4545509/resourceGroupsTestRG1/providers/[Link]/virtualNetworkGateways/VNet1GW

2. [Suscripción 5] Obtenga la puerta de enlace de red virtual para la suscripción 5. Inicie sesión y conéctese
a la Suscripción 5 antes de ejecutar el siguiente ejemplo:

$vnet5gw = Get-AzVirtualNetworkGateway -Name $GWName5 -ResourceGroupName $RG5

Copie la salida de los siguientes elementos y envíesela al administrador de la suscripción 1 por correo
electrónico u otro método.
 $[Link]
$[Link]

Estos dos elementos tendrán valores similares a la salida de ejemplo siguiente:

PS C:\> $[Link]
VNet5GW
PS C:\> $[Link]
/subscriptions/66c8e4f1-ecd6-47ed-9de7-
7e530de23994/resourceGroups/TestRG5/providers/[Link]/virtualNetworkGateways/VNet5GW

3. [Suscripción 1] Cree la conexión entre TestVNet1 y TestVNet5. En este paso, creará la conexión de
TestVNet1 a TestVNet5. La diferencia en este caso es que no se puede obtener $vnet5gw directamente
porque está en una suscripción diferente. Debe crear un nuevo objeto de PowerShell con los valores que se
le hayan proporcionado para la suscripción 1 en los pasos anteriores. Use el ejemplo siguiente. Reemplace
el nombre (Name), el identificador (Id) y la clave compartida por sus propios valores. Lo importante es que
la clave compartida coincida en ambas conexiones. Se tardará unos momentos en terminar de crear la
conexión.
Conéctese a Suscripción 1 antes de ejecutar el ejemplo siguiente:

$vnet5gw = New-Object -TypeName [Link]

$[Link] = "VNet5GW"
$[Link] = "/subscriptions/66c8e4f1-ecd6-47ed-9de7-
7e530de23994/resourceGroups/TestRG5/providers/[Link]/virtualNetworkGateways/VNet5GW"
$Connection15 = "VNet1toVNet5"
New-AzVirtualNetworkGatewayConnection -Name $Connection15 -ResourceGroupName $RG1 -
VirtualNetworkGateway1 $vnet1gw -VirtualNetworkGateway2 $vnet5gw -Location $Location1 -ConnectionType
Vnet2Vnet -SharedKey 'AzureA1b2C3'

4. [Suscripción 5] Cree la conexión entre TestVNet5 y TestVNet1. Este paso es similar al anterior, salvo en
que se crea la conexión de TestVNet5 a TestVNet1. Aquí también se aplica el mismo proceso de creación de
un objeto de PowerShell basándose en los valores obtenidos de la suscripción 1. En este paso, asegúrese de
que las claves compartidas coincidan.
Conéctese a Suscripción 5 antes de ejecutar el ejemplo siguiente:

$vnet1gw = New-Object -TypeName [Link]

$[Link] = "VNet1GW"
$[Link] = "/subscriptions/b636ca99-6f88-4df4-a7c3-
2f8dc4545509/resourceGroups/TestRG1/providers/[Link]/virtualNetworkGateways/VNet1GW "
$Connection51 = "VNet5toVNet1"
New-AzVirtualNetworkGatewayConnection -Name $Connection51 -ResourceGroupName $RG5 -
VirtualNetworkGateway1 $vnet5gw -VirtualNetworkGateway2 $vnet1gw -Location $Location5 -ConnectionType
Vnet2Vnet -SharedKey 'AzureA1b2C3'

Comprobación de una conexión

IMPORTANT
Cuando trabaje con subredes de la puerta de enlace, evite asociar un grupo de seguridad de red (NSG) a la subred de la
puerta de enlace. La asociación de un grupo de seguridad de red a esta subred puede causar que la puerta de enlace de la
red virtual (VPN, puerta de enlace de Express Route) deje de funcionar como cabría esperar. Para más información acerca de
los grupos de seguridad de red, consulte ¿Qué es un grupo de seguridad de red?
Puede comprobar que la conexión se realizó correctamente mediante el uso del cmdlet "Get-
AzVirtualNetworkGatewayConnection", con o sin "-Debug".
1. Puede usar el siguiente ejemplo de cmdlet, configurando los valores para que coincidan con los tuyos.
Cuando se le pida, seleccione "A" para ejecutar "todo". En el ejemplo, "-Name" hace referencia al nombre de
la conexión que desea probar.

Get-AzVirtualNetworkGatewayConnection -Name VNet1toSite1 -ResourceGroupName TestRG1

2. Cuando el cmdlet haya finalizado, consulte los valores. En el ejemplo siguiente, el estado de conexión
aparece como "Conectado" y pueden verse los bytes de entrada y salida.

"connectionStatus": "Connected",
"ingressBytesTransferred": 33509044,
"egressBytesTransferred": 4142431

P+F sobre conexiones de red virtual a red virtual

Las preguntas más frecuentes sobre red virtual a red virtual se aplican a las conexiones de VPN Gateway. Para
más información sobre el emparejamiento de redes virtuales, consulte Emparejamiento de redes virtuales.
¿Cobra Azure por el tráfico entre redes virtuales?
El tráfico entre redes virtuales dentro de la misma región es gratuito en ambas direcciones cuando se usa una
conexión de puerta de enlace de VPN. El tráfico de salida de red virtual a red virtual entre regiones se cobra según
las tarifas de transferencia de datos de salida entre redes virtuales en función de las regiones de origen. Para más
información, consulte la página de precios de VPN Gateway. Si conecta las redes virtuales mediante el
emparejamiento de redes virtuales en lugar de una puerta de enlace de red virtual, consulte los precios de redes
virtuales.
¿Viaja el tráfico entre dos redes virtuales a través de Internet?
No. Viaja por la red troncal de Microsoft Azure, no por Internet.
¿Puedo establecer una conexión entre dos redes virtuales a través de los inquilinos de Azure Active Directory
(AAD)?
Sí, las conexiones entre dos redes virtuales que usan puertas de enlace de VPN de Azure funcionan en los
inquilinos de AAD.
¿Es seguro el tráfico entre dos redes virtuales?
Sí, se protege mediante cifrado IPsec/IKE.
¿Necesito un dispositivo VPN para conectar redes virtuales?
No. La conexión simultánea de varias redes virtuales de Azure no requiere dispositivos VPN, a menos que sea
necesaria la conectividad entre locales.
¿Deben estar mis redes virtuales en la misma región?
No. Las redes virtuales pueden estar en la misma región de Azure o en regiones distintas (ubicaciones).
Si las redes virtuales no están en la misma suscripción, ¿las suscripciones tienen que estar asociadas con el
mismo inquilino de Active Directory?
No.
¿Puedo usar una conexión entre redes virtuales para conectar redes virtuales en instancias independientes de
Azure?
No. La conexión entre redes virtuales permite conectar redes virtuales dentro de la misma instancia de Azure. Por
ejemplo, no puede crear una conexión entre instancias de Azure del gobierno estadounidense, chino o alemán con
una instancia global de Azure. Considere la posibilidad de usar una conexión VPN de sitio a sitio en estos
escenarios.
¿Puedo usar las conexiones entre dos redes virtuales con conexiones multisitio?
Sí. La conectividad de red virtual se puede usar de forma simultánea con VPN de varios sitios.
¿A cuántos sitios locales y redes virtuales se puede conectar una red virtual?
Consulte la tabla Requisitos de la puerta de enlace.
¿Puedo usar la conexión entre dos redes virtuales para conectar máquinas virtuales o servicios en la nube fuera
de una red virtual?
No. VNet a VNet admite la conexión de redes virtuales. No admite la conexión de máquinas virtuales ni servicios
en la nube que no estén en una red virtual.
¿Abarca redes virtuales un servicio en la nube o un punto de conexión de equilibrio de carga?
No. Un servicio en la nube o un punto de conexión de equilibrio de carga no puede abarcar varias redes virtuales,
aunque estas estén conectadas entre sí.
¿Puedo usar un tipo de VPN PolicyBased para las conexiones entre dos redes virtuales o multisitio?
No. Las conexiones entre dos redes virtuales y multisitio requieren puertas de enlace de VPN de Azure con tipos
de VPN RouteBased (antes denominado enrutamiento dinámico).
¿Puedo conectar una red virtual con un tipo de VPN RouteBased a otra red virtual con un tipo de VPN
PolicyBased?
No, ambas redes virtuales TIENEN que usar VPN basadas en enrutamiento (antes denominado enrutamiento
dinámico).
¿Comparten ancho de banda los túneles de VPN?
Sí. Todos los túneles de VPN de la red virtual comparten el ancho de banda disponible en la puerta de enlace de
VPN de Azure y el mismo SLA de tiempo de actividad de puerta de enlace de VPN en Azure.
¿Se admiten túneles redundantes?
Los túneles redundantes entre dos redes virtuales se admiten cuando la puerta de enlace de una red virtual está
configurada como activa-activa.
¿Puedo tener espacios de direcciones superpuestos para configuraciones de red virtual a red virtual?
No. No puede tener intervalos de direcciones de IP superpuestos.
¿Puede haber espacios de direcciones superpuestos entre las redes virtuales conectadas y los sitios locales?
No. No puede tener intervalos de direcciones de IP superpuestos.

Pasos siguientes
Una vez completada la conexión, puede agregar máquinas virtuales a las redes virtuales. Consulte la
documentación sobre máquinas virtuales para más información.
Para más información acerca de BGP, consulte Información general de BGP y Configuración de BGP.
 Conexión de redes virtuales a partir de diferentes
modelos de implementación con el portal
23/09/2020 • 47 minutes to read • Edit Online

Este artículo muestra cómo conectar redes virtuales clásicas a redes virtuales de Resource Manager para permitir
que los recursos que se encuentran en modelos de implementación independientes se comuniquen entre sí. En los
pasos de este artículo se usa fundamentalmente Azure Portal, pero también se puede crear esta configuración con
PowerShell si se selecciona el artículo en esta lista.
La conexión de una red virtual clásica a una red virtual de Resource Manager es similar a la conexión de una red
virtual a una ubicación de sitio local. Ambos tipos de conectividad usan una puerta de enlace de VPN para
proporcionar un túnel seguro con IPsec/IKE. Puede crear una conexión entre redes virtuales que estén en
diferentes suscripciones y en diferentes regiones. También puede conectar redes virtuales que tengan ya
conexiones a redes locales, siempre que la puerta de enlace con la que se hayan configurado sea dinámica o
basada en ruta. Para más información acerca de las conexiones de red virtual a red virtual, consulte P+F sobre
conexiones de red virtual a red virtual al final de este artículo.
Si aún no tiene una puerta de enlace de red virtual y no desea crear una, considere la posibilidad de conectar sus
redes virtuales mediante Emparejamiento de VNET. El emparejamiento de VNET no usa VPN Gateway. Para más
información, consulte Emparejamiento de VNET.
Antes de empezar
En estos pasos se presume que ya se crearon ambas redes virtuales. Si usa este artículo como ejercicio y no
tiene redes virtuales, los pasos incluyen vínculos que le ayudarán a crearlas.
Compruebe que los intervalos de direcciones de las redes virtuales no se superponen entre sí ni con alguno de
los intervalos de otras conexiones con las que puedan estar conectadas las puertas de enlace.
Instale los cmdlets de PowerShell más recientes para Resource Manager y Service Management (clásico). En
este artículo se usan Azure Portal y PowerShell. PowerShell es necesario para crear la conexión desde la red
virtual clásica a la red virtual de Resource Manager. Para obtener más información, consulte Instalación y
configuración de Azure PowerShell.
Configuración de ejemplo
Puede usar estos valores para crear un entorno de prueba o hacer referencia a ellos para comprender mejor los
ejemplos de este artículo.
Red vir tual clásica
Nombre de red virtual = ClassicVNet
Espacio de direcciones = [Link]/24
Nombre de subred = Subnet-1
Intervalo de direcciones de subred = [Link]/27
Suscripción = la suscripción que desea usar
Grupo de recursos = ClassicRG
Ubicación = Oeste de EE. UU.
GatewaySubnet = [Link]/28
Sitio local = RMVNetLocal
Red vir tual de Resource Manager
Nombre de red virtual = RMVNet
Espacio de direcciones = [Link]/16
Grupo de recursos = GR1
Ubicación = Este de EE. UU.
Nombre de subred = Subnet-1
Intervalo de direcciones = [Link]/24
Subred de la puerta de enlace = [Link]/26
Nombre de la puerta de enlace de red virtual = PuertaDeEnlaceRM
Tipo de puerta de enlace = VPN
Tipo de VPN = basada en enrutamiento
SKU = VpnGw1
Ubicación = Este de EE. UU.
Red virtual = RMVNet
(asocie la puerta de enlace de VPN a esta red virtual) Configuración de la primera dirección IP = rmgwpip
(dirección IP pública de la puerta de enlace) Puerta de enlace de red local = ClassicVNetLocal
Nombre de conexión = RMtoClassic
Información general sobre la conexión
Para esta configuración se crea una conexión de puerta de enlace VPN a través de un túnel VPN de IPsec/IKE entre
las redes virtuales. Asegúrese de que ninguno de los intervalos de red virtual se superponga con otro o con
cualquiera de las redes locales a las que se conectan.
En la tabla siguiente se muestra un ejemplo de cómo se definen los sitios locales y las redes virtuales de ejemplo:

SE C O N EC TA A UN SIT IO DE
VIRT UA L N ET W O RK ESPA C IO DE DIREC C IO N ES REGIO N RED LO C A L

ClassicVNet ([Link]/24) Oeste de EE. UU. RMVNetLocal

([Link]/16)

RMVNet ([Link]/16) Este de EE. UU. ClassicVNetLocal

([Link]/24)

Sección 1: Configuración de la red virtual clásica

En esta sección se crea la red virtual clásica, la red local (sitio local) y la puerta de enlace de red virtual. Las
capturas de pantalla se proporcionan a modo de ejemplo. Asegúrese de reemplazar los valores por los suyos o use
los valores de ejemplo.
1. Creación de una red virtual clásica
Si no tiene una red virtual clásica y lleva a cabo estos pasos como ejercicio, puede crear una red virtual según este
artículo y los valores de configuración de ejemplo indicados anteriormente.
Si ya tiene una red virtual con una puerta de enlace VPN, compruebe que la puerta de enlace sea dinámica. Si es
estática, primero debe eliminar la puerta de enlace de VPN antes de pasar a configurar el sitio local.
1. Abra Azure Portal e inicie sesión con su cuenta de Azure.
2. Haga clic en + Crear un recurso para abrir la página "Nuevo".
3. En el campo "Buscar en el Marketplace", escriba "Virtual Network". Si en su lugar, selecciona Redes -> Virtual
Network, no obtendrá la opción para crear una red virtual clásica.
4. En la lista de resultados, busque "Virtual Network" y haga clic en esa opción para abrir la página Virtual
Network.
5. En la página de red virtual, seleccione "Clásica" para crear una red virtual clásica. Si aquí usa el valor
predeterminado, generará en su lugar una red virtual de Resource Manager.
2. Configuración del sitio local
1. Vaya a Todos los recursos y ubique ClassicVNet en la lista.
2. Haga clic en Puer ta de enlace en la sección Configuración del menú y, a continuación, haga clic en el banner

para crear una puerta de enlace.

3. En la página Nueva conexión de VPN , en la opción Tipo de conexión , seleccione De sitio a sitio .
4. En Sitio local , haga clic en Configurar los valores obligatorios . Con esto se abre la página Sitio local .
5. En la página Sitio Local , cree un nombre para hacer referencia a la red virtual de Resource Manager. Por
ejemplo, "RMVNetLocal".
6. Si la puerta de enlace VPN para la red virtual de Resource Manager ya tiene una dirección IP pública, use el
valor para el campo Dirección IP de la VPN Gateway . Si lleva a cabo estos pasos como ejercicio o todavía no
tiene una puerta de enlace de red virtual para la red virtual de Resource Manager, puede inventar una dirección
IP de marcador de posición. Asegúrese de que la dirección IP de marcador de posición utiliza un formato válido.
Más adelante, reemplaza la dirección IP de marcador de posición por la dirección IP pública de la puerta de
enlace de red virtual de Resource Manager.
7. Para Client Address Space (Espacio de direcciones de clientes), use los valores de los espacios de direcciones
IP de red virtual para la red virtual de Resource Manager. Este valor se usa para especificar los espacios de
direcciones a fin de enrutar a la red virtual de Resource Manager. En el ejemplo usamos [Link]/16, el
intervalo de direcciones de RMVNet.
8. Haga clic en Aceptar para guardar los valores y volver a la página Nueva conexión de VPN .
3. Creación de la puerta de enlace de red virtual
1. En la página Nueva conexión VPN , active la casilla Crear puer ta de enlace inmediatamente .
2. Haga clic en Configuración de puer ta de enlace opcional para abrir la página Configuración de
puer ta de enlace .

3. Haga clic en Subred: configurar los valores obligatorios para abrir la página Agregar subred . El
campo Nombre ya está establecido en el valor apropiado: GatewaySubnet .
4. Inter valo de direcciones hace referencia al intervalo para la subred de puerta de enlace. Si bien puede
 crear una subred de puerta de enlace con un intervalo de direcciones de /29 (3 direcciones), se recomienda
crear una subred de puerta de enlace que incluya más direcciones IP. Esto permitirá configuraciones futuras
que puedan requerir más direcciones IP disponibles. Si es posible, utilice /27 o /28. Si usa estos pasos como
ejercicio, puede hacer referencia a los valores de ejemplo. En este ejemplo se usa "[Link]/28". Haga clic
en Aceptar para crear la subred de puerta de enlace.
5. En la página Configuración de puer ta de enlace , la opción Tamaño hace referencia a la SKU de la
puerta de enlace. Seleccione la SKU de puerta de enlace para la puerta de enlace VPN.
6. Compruebe que el Tipo de enrutamiento sea Dinámico y haga clic en Aceptar para volver a la página
Nueva conexión de VPN .
7. En la página Nueva conexión de VPN , haga clic en Aceptar para empezar a crear la puerta de enlace de
VPN. Una puerta de enlace VPN puede tardar hasta 45 minutos en completarse.
4. Copia de la dirección IP pública de la puerta de enlace de la red virtual
Una vez que se haya creado la puerta de enlace de la red virtual, puede ver la dirección IP de la puerta de enlace.
1. Desplácese a la red virtual clásica y haga clic en Información general .
2. Haga clic en Conexiones de VPN para abrir la página de conexiones. En la página de conexiones de VPN,
puede ver la dirección IP pública. Se trata de la dirección IP pública asignada a la puerta de enlace de red virtual.
Anote la dirección IP. Se usa en pasos posteriores al trabajar con las opciones de configuración de puerta de
enlace de red local de Resource Manager.
3. Puede ver el estado de las conexiones de puerta de enlace. Observe que el sitio de red local que creó aparece
como "Conectando". El estado cambiará una vez creadas las conexiones. Puede cerrar esta página cuando
termine de ver el estado.

Sección 2: Configuración de redes virtuales de Resource Manager

En esta sección se crea la puerta de enlace de red virtual y la puerta de enlace de red local para la red de Resource
Manager. Las capturas de pantalla se proporcionan a modo de ejemplo. Asegúrese de reemplazar los valores por
los suyos o use los valores de ejemplo.
1. Creación de una red virtual
Valores de ejemplo:
Nombre de red virtual = RMVNet
Espacio de direcciones = [Link]/16
Grupo de recursos = GR1
Ubicación = Este de EE. UU.
Nombre de subred = Subnet-1
Intervalo de direcciones = [Link]/24
Si no tiene una red virtual de Resource Manager y va a ejecutar estos pasos como ejercicio, cree una red virtual
con los pasos que se indican en Creación de una red virtual y use los valores de ejemplo.
2. Creación de una puerta de enlace de red virtual
En este paso, se crea la puerta de enlace para la red virtual. La creación de una puerta de enlace suele tardar 45
minutos o más, según la SKU de la puerta de enlace seleccionada.
La puerta de enlace de red virtual usa una subred concreta llamada la subred de la puerta de enlace. Esta subred
forma parte del intervalo de direcciones IP de red virtual que se especifican al configurar una red virtual. Contiene
las direcciones IP que usan los recursos y servicios de puerta de enlace de la red virtual.
Al crear la subred de puerta de enlace, especifique el número de direcciones IP que contiene la subred. El número
de direcciones IP que se necesitan depende de la configuración de puerta de enlace de VPN que se desea crear.
Algunas configuraciones requieren más direcciones IP que otras. Es aconsejable crear una subred de puerta de
enlace que use /27 o /28.
Si ve un error en el que se indica que el espacio de direcciones se solapa con una subred o que la subred no se
encuentra dentro del espacio de direcciones de la red virtual, compruebe el intervalo de direcciones de la red
virtual. Es posible que no tenga suficientes direcciones IP disponibles en el intervalo de direcciones que creó para
la red virtual. Por ejemplo, si la subred predeterminada engloba todo el intervalo de direcciones, no quedan
direcciones IP para crear más subredes. Puede ajustar las subredes en el espacio de direcciones existente para
liberar direcciones IP o especificar un intervalo de direcciones adicionales y crear en él la subred de la puerta de
enlace.
Valores de ejemplo:
Nombre de la puerta de enlace de red virtual = PuertaDeEnlaceRM
Tipo de puerta de enlace = VPN
Tipo de VPN = basada en enrutamiento
SKU = VpnGw1
Ubicación = Este de EE. UU.
Red virtual = RMVNet
Subred de la puerta de enlace = [Link]/26
Configuración de primera dirección IP = rmgwpip
1. En el menú de Azure Portal, seleccione Crear un recurso .

2. En el campo Buscar en el Marketplace , escriba "Puerta de enlace de red virtual". Busque Puer ta de
enlace de red vir tual en los resultados de la búsqueda y seleccione la entrada. En la página Puer ta de
 enlace de red vir tual , seleccione Crear . Se abre la página Crear puer ta de enlace de red vir tual .
3. En la pestaña Aspectos básicos , rellene los valores de la puerta de enlace de red virtual.

Detalles del proyecto

Suscripción : seleccione la suscripción que desea usar en la lista desplegable.
Grupo de recursos : esta configuración se rellena automáticamente cuando selecciona la red virtual en
esta página.
Detalles de instancia
Name : Asigne un nombre a la puerta de enlace. Asignar nombre a la puerta de enlace no es lo mismo
que asignar nombre a una subred de puerta de enlace. Este es el nombre del objeto de puerta de enlace
 que va a crear.
Región : Seleccione la región en la que quiere crear este recurso. La región de la puerta de enlace debe
ser la misma que la red virtual.
Tipo de puer ta de enlace : Seleccione VPN . Las puertas de enlace VPN usan el tipo de puerta de
enlace de red virtual VPN .
Tipo de VPN : seleccione el tipo de VPN que se especifica para la configuración. La mayoría de las
configuraciones requieren un tipo de VPN basada en enrutamiento.
SKU : seleccione la SKU de puerta de enlace en la lista desplegable. Las SKU que aparecen en la lista
desplegable dependen del tipo de VPN que seleccione. Para más información acerca de las SKU de
puerta de enlace, consulte SKU de puerta de enlace.
Generación : para obtener información sobre la generación de VPN Gateway, consulte SKU de puerta de
enlace.
Red vir tual : En el menú desplegable, seleccione la red virtual a la que quiera agregar esta puerta de
enlace.
Inter valo de direcciones de subred de puer ta de enlace : Este campo solo aparece si la red virtual
no tiene una subred de puerta de enlace. Si es posible, intente que el intervalo sea /27, o incluso mayor
(/26, /25, etc.). No se recomienda crear un intervalo inferior a /28. Si ya tiene una subred de puerta de
enlace y desea ver los detalles de GatewaySubnet, vaya a la red virtual. Haga clic en Subnets (Subredes)
para ver el intervalo. Si desea cambiar el intervalo, puede eliminar y volver a crear GatewaySubnet.
Dirección IP pública : esta configuración especifica el objeto de dirección IP pública que se asocia a la
puerta de enlace de VPN. La dirección IP pública se asigna dinámicamente a este objeto cuando se crea la
puerta de enlace de VPN. La única vez que la dirección IP pública cambia es cuando la puerta de enlace se
elimina y se vuelve a crear. No cambia cuando se cambia el tamaño, se restablece o se realizan
actualizaciones u otras operaciones de mantenimiento interno de una puerta de enlace VPN.
Dirección IP pública : Mantenga la opción Crear nueva seleccionada.
Nombre de dirección IP pública : En el cuadro de texto, escriba un nombre para la dirección IP
pública.
Asignación : VPN Gateway solo admite Dinámica.
Modo activo/activo : Seleccione Habilitar el modo activo/activo solo si va a crear una configuración de
puerta de enlace activa/activa. En caso contrario, deje este valor sin seleccionar.
Deje la opción Configurar ASN BGP sin seleccionar, a menos que su configuración requiera
específicamente este valor. Si necesita esta configuración, el valor predeterminado del ASN es 65515,
aunque esto se puede cambiar.
4. Seleccione Revisar y crear para ejecutar la validación. Una vez superada la validación, seleccione Crear
para implementar VPN Gateway. Una puerta de enlace puede tardar hasta 45 minutos en crearse e
implementarse completamente. Puede ver el estado de implementación en la página Información general
de la puerta de enlace.
Una vez creada la puerta de enlace, puede ver la dirección IP que se le ha asignado consultando la red virtual en el
portal. La puerta de enlace aparece como un dispositivo conectado.

IMPORTANT
Cuando trabaje con subredes de la puerta de enlace, evite asociar un grupo de seguridad de red (NSG) a la subred de la
puerta de enlace. La asociación de un grupo de seguridad de red a esta subred puede causar que la puerta de enlace de la
red virtual (VPN, puerta de enlace de Express Route) deje de funcionar como cabría esperar. Para más información acerca de
los grupos de seguridad de red, consulte ¿Qué es un grupo de seguridad de red?

3. Creación de una puerta de enlace de red local

Valores de ejemplo: Puerta de enlace de red local = LocalRedVClásica

DIREC C IÓ N IP
ESPA C IO DE SE C O N EC TA A UN P ÚB L IC A DE P UERTA
VIRT UA L N ET W O RK DIREC C IO N ES REGIO N SIT IO DE RED LO C A L DE EN L A C E

ClassicVNet ([Link]/24) Oeste de EE. UU. RMVNetLocal La dirección IP pública

([Link]/16) que se asigna a la
puerta de enlace
ClassicVNet

RMVNet ([Link]/16) Este de EE. UU. ClassicVNetLocal La dirección IP pública

([Link]/24) que se asigna a la
puerta de enlace
RMVNet.

La puerta de enlace de red local especifica el intervalo de direcciones y la dirección IP pública asociados a la red
virtual clásica y su puerta de enlace de red virtual. Si lleva a cabo estos pasos como un ejercicio, consulte los
valores de ejemplo.
1. En el portal, haga clic en +Crear un recurso .
2. En el cuadro de búsqueda, escriba puer ta de enlace de red local , a continuación, presione Entrar para
buscar. Se devolverá una lista de resultados. Haga clic en Puer ta de enlace de red local y haga clic en el
botón Crear para abrir la página Crear puer ta de enlace de red local .
3. En la página Crear puer ta de enlace de red local , especifique los valores de la puerta de enlace de red
local.
Nombre: especifique el nombre del objeto de puerta de enlace de red local.
Dirección IP: es la dirección IP pública del dispositivo VPN al que desea que Azure se conecte.
Especifique una dirección IP pública válida. Si no tiene la dirección IP en este momento, puede usar los
valores que se muestran en el ejemplo, pero deberá volver y reemplazar la dirección IP del marcador de
posición por la dirección IP pública de su dispositivo VPN. Si no lo hace, Azure no podrá conectarse.
Espacio de direcciones hace referencia a los intervalos de direcciones de la red que representa esta
red local. Puede agregar varios intervalos de espacios de direcciones. Asegúrese de que los intervalos
que especifique aquí no se superpongan con los de otras redes a las que quiera conectarse. Azure
enrutará el intervalo de direcciones que especifique a la dirección IP del dispositivo VPN local. Use sus
propios valores aquí, y no los mostrados en el ejemplo, si quiere conectarse a su sitio local.
Configurar BGP: solo se debe usar al configurar BGP. En caso contrario, no seleccione esta opción.
 Suscripción: compruebe que se muestra la suscripción correcta.
Grupo de recursos: seleccione el grupo de recursos que desea utilizar. Puede crear un grupo de
recursos nuevo o seleccionar uno ya creado.
Ubicación: seleccione la ubicación en la que se creará este objeto. Puede seleccionar la misma ubicación
en la que reside la red, pero no es obligatorio.
4. Cuando haya terminado de especificar los valores, haga clic en el botón Crear para crear la puerta de
enlace de red local.

Sección 3: modificación de la configuración del sitio local de la red

virtual clásica
En esta sección se reemplaza la dirección IP de marcador de posición que usó al especificar la configuración del
sitio local con la dirección IP de puerta de enlace VPN de Resource Manager. Esta sección utiliza los cmdlets de
PowerShell (SM) clásicos.
1. En Azure Portal, vaya a la red virtual clásica.
2. En la página de la red virtual, haga clic en Información general .
3. En la sección Conexiones VPN , haga clic en el nombre del sitio local en el gráfico.

4. En la página Conexiones de VPN de sitio a sitio , haga clic en el nombre del sitio.

5. En la página de conexión del sitio local, haga clic en el nombre del sitio local para abrir la página Sitio local .
6. En la página Sitio local , reemplace la dirección IP de la puer ta de enlace de VPN por la dirección IP
de la puerta de enlace de Resource Manager.

7. Haga clic en Aceptar para actualizar la dirección IP.

Sección 4: Creación de conexión de red virtual de Resource Manager a

red virtual clásica
En estos pasos se configura la conexión desde la red virtual de Resource Manager a la red virtual clásica con Azure
Portal.
1. En Todos los recursos , ubique la puerta de enlace de red local. En el ejemplo, la puerta de enlace de red local
es ClassicVNetLocal .
2. Haga clic en Configuración y compruebe que el valor de dirección IP es la puerta de enlace VPN para la red
virtual clásica. Actualice si es necesario y, luego, haga clic en Guardar . Cierre la página.
3. En Todos los recursos , haga clic en la puerta de enlace de red local.
4. Haga clic en Conexiones para abrir la página Conexiones.
5. En la página Conexiones , haga clic en + para agregar una conexión.
6. En la página Agregar conexión , asigne un nombre a la conexión. Por ejemplo, "RMtoClassic".
7. En esta página ya está seleccionada la opción De sitio a sitio .
8. Seleccione la puerta de enlace de red virtual que desea asociar con este sitio.
9. Cree una clave compar tida . Esta clave se usa también en la conexión que crea desde la red virtual clásica a la
red virtual de Resource Manager. Puede generar la clave o inventar una. En el ejemplo usamos "abc123", pero
 puede (y debe) usar un valor más complejo.
10. Haga clic en Aceptar para crear la conexión.

Sección 5: Creación de conexión de red virtual clásica a red virtual de

Resource Manager
En estos pasos se configura la conexión desde la red virtual clásica a la red virtual de Resource Manager. Estos
pasos requieren PowerShell. Esta conexión no se puede crear en el portal. Asegúrese de que ha descargado e
instalado los cmdlets de PowerShell tanto del modelo clásico (SM) como del modelo de Resource Manager (RM).
1. Conexión a la cuenta de Azure
Abra la consola de PowerShell con derechos elevados e inicie sesión en la cuenta de Azure. Después de iniciar la
sesión, se descarga la configuración de la cuenta para que esté disponible para Azure PowerShell. El siguiente
cmdlet pide las credenciales de inicio de sesión de la cuenta de Azure para el modelo de implementación de
Resource Manager:

Connect-AzAccount

Obtenga una lista de las suscripciones de Azure.

Get-AzSubscription

Si tiene varias suscripciones, seleccione la que quera usar.

Select-AzSubscription -SubscriptionName "Name of subscription"

A continuación, inicie sesión para usar los cmdlets de PowerShell clásicos (administración de servicios). Para
agregar su cuenta de Azure del modelo de implementación clásica, use el siguiente comando:

Add-AzureAccount

Obtenga una lista de las suscripciones. Este paso puede ser necesario al agregar los cmdlets de Service
Management, dependiendo de su módulo de Azure.

Get-AzureSubscription

Si tiene varias suscripciones, seleccione la que quera usar.

Select-AzureSubscription -SubscriptionName "Name of subscription"

2. Visualización de los valores de archivo de configuración de red

Cuando crea una red virtual en Azure Portal, el nombre completo que Azure usa no aparece en Azure Portal. Por
ejemplo, una red virtual que parece llamarse "ClassicVNet" en Azure Portal puede que tenga un nombre mucho
más largo en el archivo de configuración de la red. El nombre debería parecerse al siguiente: "Group ClassicRG
ClassicVNet". En estos pasos se descarga el archivo de configuración de red y se ven los valores.
Cree un directorio en el equipo y, a continuación, exporte el archivo de configuración de red al directorio. En este
ejemplo, se exporta el archivo de configuración de red a C:\AzureNet.
 Get-AzureVNetConfig -ExportToFile C:\AzureNet\[Link]

Abra el archivo con un editor de texto y consulte el nombre de la red virtual clásica. Use los nombres que aparecen
en el archivo de configuración de red cuando ejecute los cmdlets de PowerShell.
Los nombres de las redes virtuales aparecen como Vir tualNetworkSite name =
Los nombres de los sitios aparecen como LocalNetworkSite name=
3. Creación de la conexión
Establezca la clave compartida y cree la conexión desde la red virtual clásica a la red virtual de Resource Manager.
No se puede establecer la clave compartida mediante el portal. Asegúrese de ejecutar estos pasos mientras la
sesión esté iniciada con la versión clásica de los cmdlets de PowerShell. Para ello, use Add-AzureAccount . De lo
contrario, no podrá establecer '-AzureVNetGatewayKey'.
En este ejemplo, -VNetName es el nombre de la red virtual clásica tal como se encuentra en el archivo de
configuración de red.
-LocalNetworkSiteName es el nombre que especificó para el sitio local, según se encontró en el archivo de
configuración de red.
-SharedKey es un valor que se puede generar y especificar. En este ejemplo, hemos utilizado abc123 pero
puede generar algo más complejo. Lo importante es que el valor que especifique aquí debe ser el mismo que el
que se especificó al crear la conexión entre la red virtual de Resource Manager y la red virtual clásica.

Set-AzureVNetGatewayKey -VNetName "Group ClassicRG ClassicVNet" `

-LocalNetworkSiteName "172B9E16_RMVNetLocal" -SharedKey abc123

Sección 6: Comprobación de las conexiones

Puede comprobar las conexiones mediante Azure Portal o PowerShell. Al comprobar, es posible que necesite
esperar un minuto o dos mientras se crea la conexión. Cuando una conexión se realiza correctamente, el estado de
conectividad cambia de "Conectando" a "Conectado".
Comprobación de la conexión de la red virtual clásica a la red virtual de Resource Manager
En Azure Portal, puede ver el estado de la conexión de una instancia de VPN Gateway de la red virtual clásica
navegando a la conexión. Los pasos siguientes muestran una manera de navegar a su conexión y realizar las
comprobaciones necesarias.
1. En Azure Portal, haga clic en Todos los recursos y navegue a la red virtual clásica.
2. En la hoja de la red virtual, haga clic en Información general para acceder a la sección Conexiones VPN
de la hoja.
3. En el gráfico de las conexiones VPN, haga clic en el sitio.
4. En la hoja Conexiones VPN de sitio a sitio , vea la información del sitio.

5. Para ver más información acerca de la conexión, haga clic en el nombre de la conexión para abrir la hoja
Conexión VPN de sitio a sitio .

Comprobación de la conexión de la red virtual de Resource Manager a la red virtual clásica

En Azure Portal, puede ver el estado de la conexión de una instancia de VPN Gateway de Resource Manager
navegando a la conexión. Los pasos siguientes muestran una manera de navegar a su conexión y realizar las
comprobaciones necesarias.
1. En Azure Portal, haga clic en Todos los recursos y navegue a la puerta de enlace de la red virtual.
2. En la hoja de la puerta de enlace de la red virtual, haga clic en Conexiones . Puede ver el estado de cada
conexión.
3. Haga clic en el nombre de la conexión que desee comprobar para abrir Essentials . En Essentials, puede ver
más información acerca de la conexión. El valor de Estado será "Correcto" y "Conectado" cuando haya
realizado una conexión satisfactoria.
P+F sobre conexiones de red virtual a red virtual
Las preguntas más frecuentes sobre red virtual a red virtual se aplican a las conexiones de VPN Gateway. Para más
información sobre el emparejamiento de redes virtuales, consulte Emparejamiento de redes virtuales.
¿Cobra Azure por el tráfico entre redes virtuales?
El tráfico entre redes virtuales dentro de la misma región es gratuito en ambas direcciones cuando se usa una
conexión de puerta de enlace de VPN. El tráfico de salida de red virtual a red virtual entre regiones se cobra según
las tarifas de transferencia de datos de salida entre redes virtuales en función de las regiones de origen. Para más
información, consulte la página de precios de VPN Gateway. Si conecta las redes virtuales mediante el
emparejamiento de redes virtuales en lugar de una puerta de enlace de red virtual, consulte los precios de redes
virtuales.
¿Viaja el tráfico entre dos redes virtuales a través de Internet?
No. Viaja por la red troncal de Microsoft Azure, no por Internet.
¿Puedo establecer una conexión entre dos redes virtuales a través de los inquilinos de Azure Active Directory
(AAD)?
Sí, las conexiones entre dos redes virtuales que usan puertas de enlace de VPN de Azure funcionan en los
inquilinos de AAD.
¿Es seguro el tráfico entre dos redes virtuales?
Sí, se protege mediante cifrado IPsec/IKE.
¿Necesito un dispositivo VPN para conectar redes virtuales?
No. La conexión simultánea de varias redes virtuales de Azure no requiere dispositivos VPN, a menos que sea
necesaria la conectividad entre locales.
¿Deben estar mis redes virtuales en la misma región?
No. Las redes virtuales pueden estar en la misma región de Azure o en regiones distintas (ubicaciones).
Si las redes virtuales no están en la misma suscripción, ¿las suscripciones tienen que estar asociadas con el
mismo inquilino de Active Directory?
No.
¿Puedo usar una conexión entre redes virtuales para conectar redes virtuales en instancias independientes de
Azure?
No. La conexión entre redes virtuales permite conectar redes virtuales dentro de la misma instancia de Azure. Por
ejemplo, no puede crear una conexión entre instancias de Azure del gobierno estadounidense, chino o alemán con
una instancia global de Azure. Considere la posibilidad de usar una conexión VPN de sitio a sitio en estos
escenarios.
¿Puedo usar las conexiones entre dos redes virtuales con conexiones multisitio?
Sí. La conectividad de red virtual se puede usar de forma simultánea con VPN de varios sitios.
¿A cuántos sitios locales y redes virtuales se puede conectar una red virtual?
Consulte la tabla Requisitos de la puerta de enlace.
¿Puedo usar la conexión entre dos redes virtuales para conectar máquinas virtuales o servicios en la nube fuera
de una red virtual?
No. VNet a VNet admite la conexión de redes virtuales. No admite la conexión de máquinas virtuales ni servicios
en la nube que no estén en una red virtual.
¿Abarca redes virtuales un servicio en la nube o un punto de conexión de equilibrio de carga?
No. Un servicio en la nube o un punto de conexión de equilibrio de carga no puede abarcar varias redes virtuales,
aunque estas estén conectadas entre sí.
¿Puedo usar un tipo de VPN PolicyBased para las conexiones entre dos redes virtuales o multisitio?
No. Las conexiones entre dos redes virtuales y multisitio requieren puertas de enlace de VPN de Azure con tipos de
VPN RouteBased (antes denominado enrutamiento dinámico).
¿Puedo conectar una red virtual con un tipo de VPN RouteBased a otra red virtual con un tipo de VPN
PolicyBased?
No, ambas redes virtuales TIENEN que usar VPN basadas en enrutamiento (antes denominado enrutamiento
dinámico).
¿Comparten ancho de banda los túneles de VPN?
Sí. Todos los túneles de VPN de la red virtual comparten el ancho de banda disponible en la puerta de enlace de
VPN de Azure y el mismo SLA de tiempo de actividad de puerta de enlace de VPN en Azure.
¿Se admiten túneles redundantes?
Los túneles redundantes entre dos redes virtuales se admiten cuando la puerta de enlace de una red virtual está
configurada como activa-activa.
¿Puedo tener espacios de direcciones superpuestos para configuraciones de red virtual a red virtual?
No. No puede tener intervalos de direcciones de IP superpuestos.
¿Puede haber espacios de direcciones superpuestos entre las redes virtuales conectadas y los sitios locales?
No. No puede tener intervalos de direcciones de IP superpuestos.
 Creación de una conexión de sitio a sitio mediante
Azure Portal
23/09/2020 • 39 minutes to read • Edit Online

Este artículo muestra cómo usar Azure Portal para crear una conexión de puerta de enlace VPN de sitio a sitio
desde la red local a la red virtual. Los pasos descritos en este artículo se aplican al modelo de implementación de
Resource Manager. También se puede crear esta configuración con una herramienta o modelo de implementación
distintos, mediante la selección de una opción diferente en la lista siguiente:
Se utiliza una conexión de puerta de enlace VPN de sitio a sitio para conectar su red local a una red virtual de
Azure a través de un túnel VPN de IPsec/IKE (IKEv1 o IKEv2). Este tipo de conexión requiere un dispositivo VPN
local que tenga una dirección IP pública asignada. Para más información acerca de las puertas de enlace VPN,
consulte Acerca de VPN Gateway.

Antes de empezar
Antes de comenzar con la configuración, compruebe que se cumplen los criterios siguientes:
Asegúrese de tener un dispositivo VPN compatible y alguien que pueda configurarlo. Para más información
acerca de los dispositivos VPN compatibles y su configuración, consulte Acerca de los dispositivos VPN.
Compruebe que tiene una dirección IPv4 pública externa para el dispositivo VPN.
Si no está familiarizado con los intervalos de direcciones IP ubicados en la red local, necesita trabajar con
alguien que pueda proporcionarle estos detalles. Al crear esta configuración, debe especificar los prefijos del
intervalo de direcciones IP al que Azure enrutará la ubicación local. Ninguna de las subredes de la red local
puede superponerse con las subredes de la red virtual a la que desea conectarse.
Valores del ejemplo
Los ejemplos de este artículo utilizan los valores siguientes. Puede usar estos valores para crear un entorno de
prueba o hacer referencia a ellos para comprender mejor los ejemplos de este artículo. Para más información
sobre la configuración de VPN Gateway en general, consulte Acerca de la configuración de VPN Gateway.
Nombre de la red vir tual: VNet1
Espacio de direcciones: [Link]/16
Suscripción: seleccione la suscripción que desea usar
Grupos de recursos: TestRG1
Región: Este de EE. UU.
Subred: front-end: [Link]/24, back-end: [Link]/24 (opcional para este ejercicio)
Inter valo de direcciones de subred de puer ta de enlace: [Link]/27
Nombre de la puer ta de enlace de red vir tual: VNet1GW
Dirección IP pública: VNet1GWpip
 Tipo de VPN: basada en rutas
Tipo de conexión : de sitio a sitio (IPsec)
Tipo de puer ta de enlace: VPN
Nombre de la puer ta de enlace de red local: Site1
Nombre de la conexión: VNet1toSite1
Clave compar tida: en este ejemplo, usamos abc123. Sin embargo, puede usar cualquiera compatible con el
hardware VPN. Lo importante es que los valores coincidan en ambos lados de la conexión.

1. Creación de una red virtual

Para crear una red virtual con el modelo de implementación de Resource Manager y Azure Portal, siga los pasos
que se indican a continuación. Para más información acerca de redes virtuales, consulte Introducción a las redes
virtuales.

NOTE
Cuando use una red virtual como parte de una arquitectura entre entornos, asegúrese de coordinarse con el administrador
de la red local para delimitar un intervalo de direcciones IP que pueda usar específicamente para esta red virtual. Si existe un
intervalo de direcciones duplicado en ambos lados de la conexión VPN, el tráfico se enrutará de forma inesperada. Además,
si quiere conectar esta red virtual a otra, el espacio de direcciones no puede superponerse con la otra red virtual. Planee la
configuración de red en consecuencia.

1. Inicie sesión en Azure Portal.

2. En Buscar recursos, ser vicios y documentos (G +/) , escriba red virtual.

3. Seleccione Red vir tual en los resultados de Marketplace .

4. En la página Red vir tual , seleccione Crear .

5. Una vez que haya seleccionado Crear , se abrirá la página Crear red vir tual .
6. En la pestaña Aspectos básicos , configure las opciones de configuración de la red virtual Detalles del
proyecto y Detalles de la instancia .

Al rellenar los campos, se mostrará una marca de verificación verde cuando los caracteres escritos en el
campo sean válidos. Algunos valores se rellenan automáticamente, que puede sustituir por sus propios
valores:
Suscripción : compruebe que la suscripción que aparece en la lista es la correcta. Puede cambiar las
suscripciones mediante la lista desplegable.
Grupo de recursos : seleccione uno existente o haga clic en Crear para crear un grupo de recursos
nuevo. Para más información sobre los grupos de recursos, consulte Información general de Azure
Resource Manager.
Name : escriba el nombre de la red virtual.
Región : seleccione la ubicación de la red virtual. La ubicación determina dónde van a residir los
recursos que se implementen en esta red virtual.
7. Configure los valores en la pestaña Direcciones IP . Los valores que se muestran en los ejemplos
siguientes son para fines de demostración. Ajuste estos valores según las opciones de configuración que
necesite.
 Espacio de direcciones IPv4 : de manera predeterminada, se crea automáticamente un espacio de
direcciones. Puede hacer clic en el espacio de direcciones para modificarlo a fin de que refleje sus
valores. También puede agregar espacios de direcciones adicionales.
Subred : si usa el espacio de direcciones predeterminado, se crea automáticamente una subred
predeterminada. Si cambia el espacio de direcciones, debe agregar una subred. Seleccione + Agregar
una subred para abrir la ventana Agregar subred . Configure las siguientes opciones y, a
continuación, seleccione Agregar para agregar los valores:
Nombre de subred : en este ejemplo, asignamos a la subred el nombre "FrontEnd".
Rango de direcciones de subred : intervalo de direcciones para esta subred.
8. En la pestaña Seguridad , en este momento, deje los valores predeterminados:
Protección contra DDos : Básico
Firewall : Disabled
9. Seleccione Revisar y crear para validar la configuración de la red virtual.
10. Una vez validada la configuración, seleccione Crear .

2. Creación de la puerta de enlace VPN

En este paso, se crea la puerta de enlace para la red virtual. La creación de una puerta de enlace suele tardar 45
minutos o más, según la SKU de la puerta de enlace seleccionada.
La puerta de enlace de red virtual usa una subred concreta llamada la subred de la puerta de enlace. Esta subred
forma parte del intervalo de direcciones IP de red virtual que se especifican al configurar una red virtual. Contiene
las direcciones IP que usan los recursos y servicios de puerta de enlace de la red virtual.
Al crear la subred de puerta de enlace, especifique el número de direcciones IP que contiene la subred. El número
de direcciones IP que se necesitan depende de la configuración de puerta de enlace de VPN que se desea crear.
Algunas configuraciones requieren más direcciones IP que otras. Es aconsejable crear una subred de puerta de
enlace que use /27 o /28.
Si ve un error en el que se indica que el espacio de direcciones se solapa con una subred o que la subred no se
encuentra dentro del espacio de direcciones de la red virtual, compruebe el intervalo de direcciones de la red
virtual. Es posible que no tenga suficientes direcciones IP disponibles en el intervalo de direcciones que creó para
la red virtual. Por ejemplo, si la subred predeterminada engloba todo el intervalo de direcciones, no quedan
direcciones IP para crear más subredes. Puede ajustar las subredes en el espacio de direcciones existente para
liberar direcciones IP o especificar un intervalo de direcciones adicionales y crear en él la subred de la puerta de
enlace.
Configuración de ejemplo
Detalles de instancia > Región: Este de EE. UU.
Red vir tual > Red vir tual: VNet1
Detalles de instancia > Nombre: VNet1GW
Detalles de instancia > Tipo de puer ta de enlace: VPN
Detalles de instancia > Tipo de VPN: basada en rutas
Red vir tual > Inter valo de direcciones de subred de la puer ta de enlace: [Link]/27
Dirección IP pública > Nombre de dirección IP pública: VNet1GWpip
1. En el menú de Azure Portal, seleccione Crear un recurso .

2. En el campo Buscar en el Marketplace , escriba "Puerta de enlace de red virtual". Busque Puer ta de
enlace de red vir tual en los resultados de la búsqueda y seleccione la entrada. En la página Puer ta de
enlace de red vir tual , seleccione Crear . Se abre la página Crear puer ta de enlace de red vir tual .
3. En la pestaña Aspectos básicos , rellene los valores de la puerta de enlace de red virtual.
Detalles del proyecto
Suscripción : seleccione la suscripción que desea usar en la lista desplegable.
Grupo de recursos : esta configuración se rellena automáticamente cuando selecciona la red virtual en
esta página.
Detalles de instancia
Name : Asigne un nombre a la puerta de enlace. Asignar nombre a la puerta de enlace no es lo mismo
que asignar nombre a una subred de puerta de enlace. Este es el nombre del objeto de puerta de enlace
que va a crear.
Región : Seleccione la región en la que quiere crear este recurso. La región de la puerta de enlace debe
ser la misma que la red virtual.
 Tipo de puer ta de enlace : Seleccione VPN . Las puertas de enlace VPN usan el tipo de puerta de
enlace de red virtual VPN .
Tipo de VPN : seleccione el tipo de VPN que se especifica para la configuración. La mayoría de las
configuraciones requieren un tipo de VPN basada en enrutamiento.
SKU : seleccione la SKU de puerta de enlace en la lista desplegable. Las SKU que aparecen en la lista
desplegable dependen del tipo de VPN que seleccione. Para más información acerca de las SKU de
puerta de enlace, consulte SKU de puerta de enlace.
Generación : para obtener información sobre la generación de VPN Gateway, consulte SKU de puerta
de enlace.
Red vir tual : En el menú desplegable, seleccione la red virtual a la que quiera agregar esta puerta de
enlace.
Inter valo de direcciones de subred de puer ta de enlace : Este campo solo aparece si la red virtual
no tiene una subred de puerta de enlace. Si es posible, intente que el intervalo sea /27, o incluso mayor
(/26, /25, etc.). No se recomienda crear un intervalo inferior a /28. Si ya tiene una subred de puerta de
enlace y desea ver los detalles de GatewaySubnet, vaya a la red virtual. Haga clic en Subnets
(Subredes) para ver el intervalo. Si desea cambiar el intervalo, puede eliminar y volver a crear
GatewaySubnet.
Dirección IP pública : esta configuración especifica el objeto de dirección IP pública que se asocia a la
puerta de enlace de VPN. La dirección IP pública se asigna dinámicamente a este objeto cuando se crea la
puerta de enlace de VPN. La única vez que la dirección IP pública cambia es cuando la puerta de enlace se
elimina y se vuelve a crear. No cambia cuando se cambia el tamaño, se restablece o se realizan
actualizaciones u otras operaciones de mantenimiento interno de una puerta de enlace VPN.
Dirección IP pública : Mantenga la opción Crear nueva seleccionada.
Nombre de dirección IP pública : En el cuadro de texto, escriba un nombre para la dirección IP
pública.
Asignación : VPN Gateway solo admite Dinámica.
Modo activo/activo : Seleccione Habilitar el modo activo/activo solo si va a crear una configuración
de puerta de enlace activa/activa. En caso contrario, deje este valor sin seleccionar.
Deje la opción Configurar ASN BGP sin seleccionar, a menos que su configuración requiera
específicamente este valor. Si necesita esta configuración, el valor predeterminado del ASN es 65515,
aunque esto se puede cambiar.
4. Seleccione Revisar y crear para ejecutar la validación. Una vez superada la validación, seleccione Crear
para implementar VPN Gateway. Una puerta de enlace puede tardar hasta 45 minutos en crearse e
implementarse completamente. Puede ver el estado de implementación en la página Información general
de la puerta de enlace.
Una vez creada la puerta de enlace, puede ver la dirección IP que se le ha asignado consultando la red virtual en el
portal. La puerta de enlace aparece como un dispositivo conectado.

IMPORTANT
Cuando trabaje con subredes de la puerta de enlace, evite asociar un grupo de seguridad de red (NSG) a la subred de la
puerta de enlace. La asociación de un grupo de seguridad de red a esta subred puede causar que la puerta de enlace de la
red virtual (VPN, puerta de enlace de Express Route) deje de funcionar como cabría esperar. Para más información acerca de
los grupos de seguridad de red, consulte ¿Qué es un grupo de seguridad de red?

3. Creación de la puerta de enlace de red local

La puerta de enlace de red local suele hacer referencia a la ubicación local. Asigne al sitio un nombre al que Azure
pueda hacer referencia y, luego, especifique la dirección IP del dispositivo VPN local con la que creará una
conexión. Especifique también los prefijos de dirección IP que se enrutarán a través de la puerta de enlace VPN al
dispositivo VPN. Los prefijos de dirección que especifique son los prefijos que se encuentran en la red local. Si la
red local cambia o necesita cambiar la dirección IP pública del dispositivo VPN, puede actualizar fácilmente los
valores más adelante.
Valores de ejemplo
Nombre: Site1
Grupos de recursos: TestRG1
Ubicación: Este de EE. UU.
1. En el menú de Azure Portal, seleccione Crear un recurso .

2. En el campo Buscar en Marketplace , escriba Puer ta de enlace de red local y presione Entrar para
comenzar la búsqueda. Se devolverá una lista de resultados. Haga clic en Puer ta de enlace de red local
y haga clic en el botón Crear para abrir la página Crear puer ta de enlace de red local .
3. En la página Crear puer ta de enlace de red local , especifique los valores de la puerta de enlace de red
local.
Nombre: especifique el nombre del objeto de puerta de enlace de red local.
Dirección IP : es la dirección IP pública del dispositivo VPN al que desea que Azure se conecte.
Especifique una dirección IP pública válida. Si no tiene la dirección IP en este momento, puede usar los
valores que se muestran en el ejemplo, pero deberá volver y reemplazar la dirección IP del marcador de
posición por la dirección IP pública de su dispositivo VPN. Si no lo hace, Azure no podrá conectarse.
Espacio de direcciones hace referencia a los intervalos de direcciones de la red que representa esta
red local. Puede agregar varios intervalos de espacios de direcciones. Asegúrese de que los intervalos
que especifique aquí no se superpongan con los de otras redes a las que quiera conectarse. Azure
enrutará el intervalo de direcciones que especifique a la dirección IP del dispositivo VPN local. Use sus
propios valores aquí, y no los mostrados en el ejemplo, si quiere conectarse a su sitio local.
Configurar BGP: usar solo al configurar BGP. En caso contrario, no seleccione esta opción.
 Subscription (Suscripción): compruebe que se muestra la suscripción correcta.
Grupos de recursos: seleccione el grupo de recursos que quiere usar. Puede crear un grupo de
recursos nuevo o seleccionar uno ya creado.
Ubicación: La ubicación es la misma que Región en otros valores. seleccione la ubicación en la que se
creará este objeto. Puede seleccionar la misma ubicación en la que reside la red, pero no es obligatorio.
4. Cuando haya terminado de especificar los valores, haga clic en el botón Crear en la parte inferior de la
página para crear la puerta de enlace de red local.

4. Configurar el dispositivo VPN

Las conexiones de sitio a sitio a una red local requieren un dispositivo VPN. En este paso, se configura el
dispositivo VPN. Al configurar el dispositivo VPN, necesita lo siguiente:
Una clave compartida. Se trata de la misma clave compartida que se especifica al crear la conexión VPN de
sitio a sitio. En estos ejemplos se utiliza una clave compartida básica. Se recomienda que genere y utilice una
clave más compleja.
La dirección IP pública de la puerta de enlace de red virtual. Puede ver la dirección IP pública mediante Azure
Portal, PowerShell o la CLI. Para buscar la dirección IP pública de la puerta de enlace de la VPN mediante Azure
Portal, vaya a Puer tas de enlace de red vir tual y haga clic en el nombre de la puerta de enlace.
Para descargar el script de configuración de dispositivos VPN:
En función del dispositivo VPN que tenga, es posible que pueda descargar un script de configuración del mismo.
Para más información, consulte Descarga de scripts de configuración de dispositivos VPN para conexiones VPN
S2S.
En los siguientes vínculos encontrará más información acerca de la configuración:
Para obtener más información sobre dispositivos VPN compatibles, consulte Dispositivos VPN.
Antes de configurar el dispositivo VPN, compruebe si hay problemas conocidos de compatibilidad para el
dispositivo VPN que desea usar.
Para obtener vínculos a los valores de configuración del dispositivo, consulte Dispositivos VPN validados.
Los vínculos de la configuración de dispositivos se proporcionan dentro de lo posible. Siempre es mejor
ponerse en contacto con el fabricante del dispositivo para obtener la información de configuración más
reciente. La lista muestra las versiones que hemos probado. Si su sistema operativo no está en esa lista,
sigue siendo posible que la versión sea compatible. Póngase en contacto con el fabricante del dispositivo
para comprobar que la versión del sistema operativo para el dispositivo VPN es compatible.
Para ver una introducción a la configuración de dispositivos VPN, consulte Información general sobre
configuraciones de dispositivos VPN de terceros.
Para obtener información sobre cómo modificar los ejemplos de configuración de dispositivo, consulte
Edición de ejemplos.
Para conocer los requisitos criptográficos, consulte About cryptographic requirements and Azure VPN
gateways (Acerca de los requisitos criptográficos y la puertas de enlace de VPN de Azure).
Para obtener información acerca de los parámetros de protocolo de seguridad de Internet/intercambio de
claves por red, consulte Acerca de los dispositivos VPN y los parámetros de IPsec/IKE para conexiones de
VPN Gateway de sitio a sitio. Este vínculo muestra información acerca de la versión de IKE, Grupo Diffie-
Hellman, método de autenticación, algoritmos de cifrado y hash, duración de SA, PFS y DPD, además de
otra información de parámetros que necesita para completar la configuración.
Para conocer los pasos de la configuración de la directiva de protocolo de seguridad de
Internet/intercambio de claves por red, consulte Configure IPsec/IKE policy for S2S VPN or VNet-to-VNet
 connections (Configuración de la directiva de protocolo de seguridad de Internet/intercambio de claves por
red para conexiones para conexiones VPN de sitio a sitio o entre redes virtuales).
Para conectar con dispositivos VPN basados en directivas, consulte Conexión de puertas de enlace Azure
VPN Gateway a varios dispositivos VPN locales basados en directivas con PowerShell.

5. Creación de la conexión VPN

Creación de la conexión VPN de sitio a sitio entre la puerta de enlace de la red virtual y el dispositivo VPN local.
1. Abra la página de la puerta de enlace de red virtual. Hay varias formas de navegar. Para navegar a la puerta
de enlace, vaya a Nombre de la red vir tual -> Información general -> Dispositivos conectados -
> Nombre de la puer ta de enlace .
2. En la página de la puerta de enlace, haga clic en Conexiones . En la parte superior de la página Conexiones,
haga clic en +Agregar para abrir la página Agregar conexión .
3. En la página Agregar conexión , configure los valores de la conexión.
Nombre : asigne un nombre a la conexión.
Tipo de conexión: seleccione Sitio a sitio (IPSec) .
Puer ta de enlace de red vir tual: el valor es fijo porque se conecta desde esta puerta de enlace.
Puer ta de enlace de red local: haga clic en Elegir una puer ta de enlace de red local y
seleccione la puerta de enlace de red local que desea utilizar.
Clave compar tida: este valor debe ser el mismo que el que usa para el dispositivo VPN local. En el
 ejemplo se usa "abc123", pero puede (y debería) utilizar algo más complejo. Lo importante es que el
valor que especifique aquí debe ser el mismo que el que se especificó al configurar el dispositivo VPN.
Los restantes valores de Suscripción , Grupo de recursos y Ubicación son fijos.
4. Haga clic en Aceptar para crear la conexión. El mensaje Creando la conexión aparecerá de forma
intermitente en la pantalla.
5. La conexión se puede ver en la página Conexiones de la puerta de enlace de red virtual. El valor de Estado
pasará de Desconocido a Conectando y luego a Correcto.

6. Comprobación de la conexión VPN

En Azure Portal, puede ver el estado de la conexión de una instancia de VPN Gateway de Resource Manager
navegando a la conexión. Los pasos siguientes muestran una manera de navegar a su conexión y realizar las
comprobaciones necesarias.
1. En el menú de Azure Portal, seleccione Todos los recursos o busque y seleccione Todos los recursos en
cualquier página.
2. Seleccione la puerta de enlace de red virtual.
3. En la hoja de la puerta de enlace de la red virtual, haga clic en Conexiones . Puede ver el estado de cada
conexión.
4. Haga clic en el nombre de la conexión que desee comprobar para abrir Essentials . En Essentials, puede ver
más información acerca de la conexión. El valor de Estado será "Correcto" y "Conectado" cuando haya
realizado una conexión satisfactoria.

Conexión a una máquina virtual

Puede conectarse a una máquina virtual que se ha implementado en la red virtual mediante la creación de una
conexión a Escritorio remoto a la máquina virtual. La mejor manera de comprobar inicialmente que puede
conectarse a la máquina virtual es hacerlo mediante su dirección IP privada, en lugar del nombre de equipo. Con
este método prueba si puede conectarse, no si la resolución de nombres está configurada correctamente.
1. Busque la dirección IP privada. Hay varias formas de encontrar la dirección IP privada de una máquina
virtual. A continuación, se muestran los pasos tanto para Azure Portal como para PowerShell.
Azure Portal: busque la máquina virtual en Azure Portal. Vea las propiedades de la máquina virtual.
Se enumera la dirección IP privada.
PowerShell: utilice el ejemplo para ver una lista de las máquinas virtuales y las direcciones IP
privadas de los grupos de recursos. No es preciso modificar el ejemplo para usarlo.
 $VMs = Get-AzVM
$Nics = Get-AzNetworkInterface | Where VirtualMachine -ne $null

foreach($Nic in $Nics)
{
$VM = $VMs | Where-Object -Property Id -eq $[Link]
$Prv = $[Link] | Select-Object -ExpandProperty PrivateIpAddress
$Alloc = $[Link] | Select-Object -ExpandProperty PrivateIpAllocationMethod
Write-Output "$($[Link]): $Prv,$Alloc"
}

2. Compruebe que está conectado a una red virtual mediante la conexión VPN.
3. Abra Conexión a Escritorio remoto , para lo que debe escribir "RDP" o "Conexión a Escritorio remoto" en
el cuadro de búsqueda de la barra de tareas y, después, seleccione Conexión a Escritorio remoto. Conexión
a Escritorio remoto también se puede abrir con el comando "mstsc" de PowerShell.
4. En Conexión a Escritorio remoto, escriba la dirección IP privada de la máquina virtual. Puede hacer clic en
"Mostrar opciones" para ajustar más parámetros adicionales y, después, conéctese.
Solución de problemas de una conexión de RDP a una máquina virtual
Si tiene problemas para conectarse a una máquina virtual a través de su conexión VPN, compruebe los siguientes
factores:
Compruebe que la conexión VPN se ha establecido correctamente.
Compruebe que se conecta a la dirección IP privada de la máquina virtual.
Si puede conectarse a la máquina virtual mediante la dirección IP privada, pero no el nombre del equipo,
compruebe que ha configurado el DNS correctamente. Para más información acerca de cómo funciona la
resolución de nombres para las máquinas virtuales, consulte Resolución de nombres para las máquinas
virtuales e instancias de rol.
Para más información acerca de las conexiones RDP, consulte Solución de problemas de conexiones del
Escritorio remoto a una máquina virtual de Azure.

Procedimientos para restablecer una puerta de enlace de VPN

Restablecer una puerta de enlace de VPN de Azure es útil si se pierde la conectividad VPN entre locales en uno o
varios túneles VPN de sitio a sitio. En esta situación, todos tus dispositivos VPN locales funcionan correctamente,
pero no pueden establecer túneles IPsec con las Puertas de enlace de VPN de Azure. Para conocer los pasos,
consulte Restablecimiento de una puerta de enlace de VPN.

Procedimientos para cambiar la SKU de una puerta de enlace (cambiar

el tamaño de una puerta de enlace)
Para que conocer los pasos para cambiar la SKU de una puerta de enlace, consulte SKU de puerta de enlace.

Procedimiento para agregar una conexión adicional a una puerta de

enlace VPN
Puede agregar conexiones adicionales, siempre que ninguno de los espacios de direcciones se superpongan entre
las conexiones.
1. Para agregar una conexión adicional, vaya a la puerta de enlace VPN y, a continuación, haga clic en
Conexiones para abrir la página Conexiones.
2. Haga clic en +Agregar para agregar la conexión. Ajuste el tipo de conexión para reflejar una conexión entre
redes virtuales (si se conecta a otra puerta de enlace de red virtual), o de sitio a sitio.
3. Si se conecta de sitio a sitio y aún no ha creado una puerta de enlace de red local para el sitio al que desea
conectarse, puede crear una.
4. Especifique la clave compartida que desee usar y, después, haga clic en Aceptar para crear la conexión.

Pasos siguientes
Para más información acerca de BGP, consulte Información general de BGP y Configuración de BGP.
Para información acerca de la tunelización forzada, consulte la Acerca de la tunelización forzada.
Para obtener información acerca de las conexiones activo/activo de alta disponibilidad, consulte Conectividad
de alta disponibilidad entre locales y de red virtual a red virtual.
Para información acerca de cómo limitar el tráfico de red a los recursos de una red virtual, vea Seguridad de
red.
Para información acerca de cómo enruta Azure el tráfico entre los recursos locales, de Internet y de Azure, vea
Enrutamiento del tráfico de redes virtuales.
Para información acerca de cómo crear una conexión VPN de sitio a sitio mediante una plantilla de Azure
Resource Manager, consulte Create a Site-to-Site VPN Connection (Creación de una conexión VPN de sitio a
sitio).
Para información acerca de cómo crear una conexión VPN entre redes virtuales mediante una plantilla de
Azure Resource Manager, consulte Deploy HBase geo replication (Implementación de replicación geográfica de
HBase).
 Conexión de una red virtual con un circuito de
ExpressRoute mediante el portal
23/09/2020 • 10 minutes to read • Edit Online

Este artículo le ayuda a crear una conexión para vincular una red virtual con un circuito de Azure ExpressRoute
mediante Azure Portal. Las redes virtuales que se conectan al circuito de Azure ExpressRoute pueden estar en la
misma suscripción o formar parte de una suscripción diferente.

Antes de empezar
Revise los requisitos previos, los requisitos de enrutamiento y los flujos de trabajo antes de comenzar la
configuración.
Tiene que tener un circuito ExpressRoute activo.
Siga las instrucciones para crear un circuito ExpressRoute y habilite el circuito mediante el proveedor de
conectividad.
Asegúrese de que dispone de un emparejamiento privado de Azure configurado para el circuito. Consulte
el artículo Creación y modificación del emparejamiento de un circuito ExpressRoute para conocer las
instrucciones de emparejamiento y enrutamiento.
Asegúrese de que el emparejamiento privado de Azure está configurado y el emparejamiento BGP entre
la red y Microsoft está activo para habilitar la conectividad de extremo a extremo.
Asegúrese de que ha creado y aprovisionado totalmente una red virtual y una puerta de enlace de red
virtual. Siga las instrucciones para crear una puerta de enlace de red virtual en ExpressRoute. Una puerta
de enlace de red virtual para ExpressRoute usa el GatewayType "ExpressRoute", no VPN.
Es posible vincular hasta 10 redes virtuales a un circuito ExpressRoute estándar. Todas las redes virtuales
deben pertenecer a la misma región geopolítica al utilizar un circuito de ExpressRoute estándar.
Una red virtual solo se puede vincular a cuatro circuitos ExpressRoute como máximo. Use el procedimiento
siguiente para crear un nuevo objeto de conexión para cada circuito ExpressRoute al que quiere conectarse.
Los circuitos ExpressRoute pueden estar en la misma suscripción, en suscripciones diferentes o en una
combinación de ambas.
Puede vincular una red virtual fuera de la región geopolítica del circuito de ExpressRoute, o bien conectar un
mayor número de redes virtuales a este si habilitó el complemento premium de ExpressRoute. Consulte las
preguntas más frecuentes para obtener más detalles sobre el complemento premium.
Puede ver un vídeo antes de comenzar para entender mejor los pasos.

Conexión de una red virtual con un circuito: misma suscripción

NOTE
La información de la configuración de BGP no aparecerá si el proveedor de nivel 3 configuró los emparejamientos. Si el
circuito tiene un estado aprovisionado, ya puede crear conexiones.

Para crear una conexión

1. Asegúrese de que el circuito ExpressRoute y el emparejamiento privado de Azure estén correctamente
configurados. Siga las instrucciones de Creación de un circuito ExpressRoute y de Creación y modificación
 del emparejamiento de un circuito ExpressRoute. El circuito ExpressRoute debe tener un aspecto similar a la
imagen que aparece a continuación:

2. Ahora puede iniciar el aprovisionamiento de una conexión para vincular la puerta de enlace de red virtual
con el circuito ExpressRoute. Haga clic en Conexión > Agregar para abrir la página Agregar conexión y
configure los valores.

3. Una vez que la conexión esté correctamente configurada, el objeto de conexión mostrará la información de
la conexión.

Conexión de una red virtual con un circuito: otra suscripción

Puede compartir un circuito ExpressRoute entre varias suscripciones. En la ilustración siguiente se muestra un
sencillo esquema de cómo funciona el uso compartido de circuitos ExpressRoute entre varias suscripciones.
 Cada una de las nubes más pequeñas dentro de la nube de gran tamaño se usa para representar las
suscripciones que pertenecen a diferentes departamentos dentro de una organización.
Cada departamento de la organización puede usar su propia suscripción para implementar sus servicios,
pero puede compartir un único circuito ExpressRoute para volver a conectarse a la red local.
Un solo departamento (en este ejemplo: TI) puede ser el propietario de ExpressRoute. Otras suscripciones de
la organización pueden usar el circuito ExpressRoute y autorizaciones asociadas con dicho circuito, incluidas
las suscripciones vinculadas a otros inquilinos de Azure Active Directory e inscripciones al Contrato
Enterprise.

NOTE
Los cargos de conectividad y ancho de banda de un circuito dedicado recaerán en el propietario del circuito
ExpressRoute. Todas las redes virtuales comparten el mismo ancho de banda.

Administración: acerca de los propietarios y los usuarios del circuito

El "propietario del circuito" es un usuario avanzado autorizado del recurso de circuito ExpressRoute. Puede crear
autorizaciones que los "propietarios del circuito", a su vez, pueden canjear. Los usuarios del circuito son
propietarios de puertas de enlace de red virtual que no se incluyen en la misma suscripción que el circuito
ExpressRoute. Los usuarios del circuito pueden canjear autorizaciones (una autorización por red virtual).
El propietario del circuito tiene la capacidad de modificar y revocar las autorizaciones en cualquier momento. La
revocación de una autorización dará como resultado la eliminación de todas las conexiones de vínculos de la
suscripción cuyo acceso se haya revocado.
Operaciones del propietario del circuito
Creación de una autorización de conexión
El propietario del circuito crea una autorización. Esto da lugar a la creación de una clave de autorización que puede
usar un usuario del circuito para conectar sus puertas de enlace de red virtual al circuito ExpressRoute. Una
autorización solo es válida para una conexión.

NOTE
Cada conexión requiere una autorización independiente.

1. En la página de ExpressRoute, haga clic en Autorizaciones , escriba el nombre de la autorización en

Nombre y haga clic en Guardar .
2. Una vez guardada la configuración, copie los valores de Identificador de recurso y Clave de
autorización .

Eliminación de una autorización de conexión

Para eliminar una conexión, seleccione el icono Eliminar en la página correspondiente a su conexión.
Operaciones del usuario del circuito
El usuario del circuito necesita el identificador del recurso y una clave de autorización del propietario del circuito.
Canje de una autorización de conexión
1. Haga clic en el botón +Nuevo .

2. Busque el nombre "Conexión" en Marketplace, selecciónelo y haga clic en Crear .

3. Asegúrese de que Tipo de conexión está establecido en "ExpressRoute".
4. Especifique los datos y haga clic en Aceptar en la página Datos básicos.

5. En la página Configuración , seleccione una opción en Puer ta de enlace de red vir tual y active la casilla
Canjear autorización .
6. Escriba un valor en Clave de autorización y en Peer circuit URI (Emparejar URI de circuito) y asigne un
nombre a la conexión. Haga clic en OK . El URI de circuito del mismo nivel es el identificador de recurso
del circuito ExpressRoute (que puede encontrar en el panel de configuración de las propiedades del circuito
ExpressRoute).
7. Revise la información de la página Resumen y haga clic en Aceptar .
Liberación de una autorización de conexión
Puede liberar una autorización eliminando la conexión que vincula el circuito ExpressRoute a la red virtual.

Eliminación de una conexión para desvincular una red virtual

Puede eliminar una conexión y desvincular la red virtual de un circuito de ExpressRoute; para ello, seleccione el
icono Eliminar en la página de la conexión.

Pasos siguientes
Para obtener más información acerca de ExpressRoute, consulte P+F de ExpressRoute.
 Uso de una instancia de Virtual Network TAP con la
CLI de Azure
23/09/2020 • 7 minutes to read • Edit Online

Azure Virtual Network TAP (punto de acceso del terminal) permite transmitir continuamente el tráfico de red de la
máquina virtual a un recopilador de paquetes de red o a una herramienta de análisis. Un asociado de la aplicación
virtual de red proporciona el recopilador o la herramienta de análisis de la herramienta. Para ver una lista de
soluciones de asociados que estén validadas para funcionar con Virtual Network TAP, consulte las soluciones de
asociados.

Creación de un recurso de Virtual Network TAP

Antes de crear un recurso de Virtual Network TAP, lea los requisitos previos. Puede ejecutar los comandos
siguientes en Azure Cloud Shell, o mediante la ejecución de la interfaz de la línea de comandos (CLI) de Azure en el
equipo. Azure Cloud Shell es un shell interactivo gratuito, que no requiere la instalación de la CLI de Azure en el
equipo. Debe iniciar sesión Azure con una cuenta que tenga los permisos adecuados. En este artículo se necesita la
CLI de Azure versión 2.0.46 o posterior. Ejecute az --version para buscar la versión instalada. Si necesita instalarla
o actualizarla, consulte Instalación de la CLI de Azure 2.0. El punto de acceso de terminal de red virtual está
actualmente disponible como una extensión. Para instalar la extensión, tiene que ejecutar
az extension add -n virtual-network-tap . Si ejecuta de forma local la CLI de Azure, también debe ejecutar
az login para crear una conexión con Azure.

1. Recupere el identificador de su suscripción en una variable que se usará en un paso posterior:

subscriptionId=$(az account show \

--query id \
--out tsv)

2. Establezca el identificador de suscripción que usará para crear un recurso de Virtual Network TAP.

az account set --subscription $subscriptionId

3. Vuelva a registrar el identificador de suscripción que usará para crear un recurso de Virtual Network TAP. Si
recibe un error de registro al crear un recurso TAP, ejecute el siguiente comando:

az provider register --namespace [Link] --subscription $subscriptionId

4. Si el destino de Virtual Network TAP es la interfaz de red en la aplicación virtual de red del recopilador o de
la herramienta de análisis:
Recupere la configuración IP de la interfaz de red de la aplicación virtual de red en una variable que
se usará en un paso posterior. El identificador es el punto de conexión que agregará el tráfico TAP. En
el ejemplo siguiente se recupera el identificador de la configuración IP ipconfig1 de una interfaz de
red llamada myNetworkInterface, en un grupo de recursos llamado myResourceGroup:
 IpConfigId=$(az network nic ip-config show \
--name ipconfig1 \
--nic-name myNetworkInterface \
--resource-group myResourceGroup \
--query id \
--out tsv)

Cree la instancia de Virtual Network TAP en la región westcentralus azure y use el identificador de la
configuración IP como destino y una propiedad de puerto opcional. El puerto especifica el puerto de
destino en la configuración IP de la interfaz de red donde se recibirá el tráfico TAP:

az network vnet tap create \

--resource-group myResourceGroup \
--name myTap \
--destination $IpConfigId \
--port 4789 \
--location westcentralus

5. Si el destino de Virtual Network TAP es un equilibrador de carga interno de Azure:

Recupere la configuración IP de front-end del equilibrador de carga interno de Azure en una variable
que se usará en un paso posterior. El identificador es el punto de conexión que agregará el tráfico TAP.
En el ejemplo siguiente se recupera el identificador de la configuración IP del front-end
frontendipconfig1 para un equilibrador de carga llamado myInternalLoadBalancer, en un grupo de
recursos llamado myResourceGroup:

FrontendIpConfigId=$(az network lb frontend-ip show \

--name frontendipconfig1 \
--lb-name myInternalLoadBalancer \
--resource-group myResourceGroup \
--query id \
--out tsv)

Cree la instancia de Virtual Network TAP y use el identificador de la configuración IP de front-end

como destino y una propiedad de puerto opcional. El puerto especifica el puerto de destino en la
configuración IP del front-end donde se recibirá el tráfico TAP:

az network vnet tap create \

--resource-group myResourceGroup \
--name myTap \
--destination $FrontendIpConfigId \
--port 4789 \
--location westcentralus

6. Confirme la creación de la instancia de Virtual Network TAP:

az network vnet tap show \

--resource-group myResourceGroup
--name myTap

Agregar una configuración de TAP a una interfaz de red

1. Recupere el identificador de un recurso de Virtual Network TAP existente. En el ejemplo siguiente se
recupera una instancia de Virtual Network TAP denominada myTap de un grupo de recursos llamado
myResourceGroup:
 tapId=$(az network vnet tap show \
--name myTap \
--resource-group myResourceGroup \
--query id \
--out tsv)

2. Cree una configuración de TAP en la interfaz de red de la máquina virtual supervisada. En el ejemplo
siguiente se crea una configuración de TAP para una interfaz de red llamada myNetworkInterface:

az network nic vtap-config create \

--resource-group myResourceGroup \
--nic myNetworkInterface \
--vnet-tap $tapId \
--name mytapconfig \
--subscription subscriptionId

3. Confirme la creación de la configuración de TAP:

az network nic vtap-config show \

--resource-group myResourceGroup \
--nic-name myNetworkInterface \
--name mytapconfig \
--subscription subscriptionId

Eliminar la configuración de TAP en una interfaz de red

az network nic vtap-config delete \
--resource-group myResourceGroup \
--nic myNetworkInterface \
--name myTapConfig \
--subscription subscriptionId

Enumerar las instancias de Virtual Network TAP de una suscripción

az network vnet tap list

Eliminar una instancia de Virtual Network TAP de un grupo de recursos

az network vnet tap delete \
--resource-group myResourceGroup \
--name myTap
 Implementación del complemento de interfaz de red
de contenedor de Azure Virtual Network
23/09/2020 • 11 minutes to read • Edit Online

El complemento de interfaz de red de contenedor (CNI) de Azure Virtual Network se instala en una máquina
virtual de Azure y ofrece funcionalidades de red virtual a los pods de Kubernetes y los contenedores de Docker.
Para más información sobre el complemento, consulte Enable containers to use Azure Virtual Network capabilities
(Habilitación de contenedores para que puedan usar las funcionalidades de Azure Virtual Network). Además, el
complemento se puede usar con Azure Kubernetes Service (AKS); para ello, elija la opción Advanced Networking
(Redes avanzadas), que coloca automáticamente los contenedores de AKS en una red virtual.

Implementación del complemento para un clúster de Kubernetes con

ACS-Engine
ACS-Engine implementa un clúster de Kubernetes con una plantilla de Azure Resource Manager. La configuración
del clúster se especifica en un archivo JSON que se pasa a la herramienta al generar la plantilla. Para ver la lista
completa de las configuraciones de clúster compatibles y sus descripciones, consulte Microsoft Azure Container
Service Engine - definición de clúster (Motor de Microsoft Azure Container Service: definiciones de clúster). Este es
el complemento de red predeterminado para los clústeres creados con ACS-Engine. Las siguientes opciones de
configuración de red son importantes a la hora de configurar el complemento:

C O N F IGURA C IÓ N DESC RIP C IÓ N

firstConsecutiveStaticIP Dirección IP que se asigna al nodo maestro. Es una opción de

configuración obligatoria.

clusterSubnet en kubernetesConfig CIDR de la subred de red virtual donde se implementa el

clúster y desde la cuál se asignan las direcciones IP a los pods.

vnetSubnetId en masterProfile Especifica el identificador de recurso de Azure Resource

Manager de la subred en la que el clúster se va a implementar.

vnetCidr CIDR de la red virtual en la que se va a implementar el clúster.

max-Pods en kubeletConfig Número máximo de pods en cada máquina virtual de agente.

Para el complemento, el valor predeterminado es 30. Puede
especificar hasta 250.

Ejemplo de configuración
El siguiente ejemplo JSON es para un clúster con las siguientes propiedades:
Un nodo maestro y dos nodos agente
Se implementa en una subred llamada KubeClusterSubnet ([Link]/20) y los nodos maestro y agente residen
en ella.
 {
"apiVersion": "vlabs",
"properties": {
"orchestratorProfile": {
"orchestratorType": "Kubernetes",
"kubernetesConfig": {
"clusterSubnet": "[Link]/20" --> Subnet allocated for the cluster
}
},
"masterProfile": {
"count": 1,
"dnsPrefix": "ACSKubeMaster",
"vmSize": "Standard_A2",
"vnetSubnetId": "/subscriptions/<subscription ID>/resourceGroups/<Resource Group
Name>/providers/[Link]/virtualNetworks/<Vnet Name>/subnets/KubeClusterSubnet",
"firstConsecutiveStaticIP": "[Link]", --> IP address allocated to the Master node
"vnetCidr": "[Link]/16" --> Virtual network address space
},
"agentPoolProfiles": [
{
"name": "k8sagentpoo1",
"count": 2,
"vmSize": "Standard_A2_v2",
"vnetSubnetId": "/subscriptions/<subscription ID>/resourceGroups/<Resource Group
Name>/providers/[Link]/virtualNetworks/<VNet Name>/subnets/KubeClusterSubnet",
"availabilityProfile": "AvailabilitySet"
}
],
"linuxProfile": {
"adminUsername": "KubeServerAdmin",
"ssh": {
"publicKeys": [
{…}
]
}
},
"servicePrincipalProfile": {
"clientId": "dd438987-aa12-4754-b47d-375811889714",
"secret": "azure123"
}
}
}

Implementación del complemento para un clúster de Kubernetes

Complete los pasos siguientes para instalar el complemento en cada máquina virtual de Azure en un clúster de
Kubernetes:
1. Descarga e instalación del complemento
2. Asigne previamente un grupo de direcciones IP de red virtual a cada máquina virtual desde la cual se
asignarán las direcciones IP a los pods. Cada máquina virtual de Azure viene con una dirección IP privada
de red virtual principal en cada interfaz de red. Las direcciones IP del grupo se agregan como direcciones
secundarias (ipconfigs) en la interfaz de red de la máquina virtual, con una de las siguientes opciones:
CLI : asignación de varias direcciones IP mediante la CLI de Azure
PowerShell : asignación de varias direcciones IP mediante PowerShell
Por tal : asignación de varias direcciones IP mediante Azure Portal
Plantilla de Azure Resource Manager : asignación de varias direcciones IP mediante plantillas
Asegúrese de agregar suficientes direcciones IP para todos los pods que se espera que aparezcan en la
máquina virtual.
3. Seleccione el complemento para proporcionar conexión de red al clúster; para ello, pase al kubelet la
opción de línea de comandos –network-plugin=cni durante la creación del clúster. De forma
predeterminada, Kubernetes busca el complemento y el archivo de configuración en los directorios donde
ya están instalados.
4. Si desea que los pods tengan acceso a Internet, agregue la siguiente regla iptables en las máquinas
virtuales Linux para aplicar NAT de origen al tráfico de Internet. En el ejemplo siguiente, el intervalo IP
especificado es [Link]/8.

iptables -t nat -A POSTROUTING -m iprange ! --dst-range [Link] -m

addrtype ! --dst-type local ! -d [Link]/8 -j MASQUERADE

La regla aplica NAT al tráfico que no está destinado a los intervalos IP especificados. Se da por hecho que
todo el tráfico fuera de los intervalos anteriores es tráfico de Internet. Puede elegir especificar los intervalos
IP de la red virtual de la máquina virtual, los de la red virtual emparejada y los de las redes locales.
Las máquinas virtuales Windows aplican NAT automáticamente al tráfico cuyo destino está fuera de la
subred a la que pertenece la máquina virtual. No es posible especificar intervalos IP personalizados.
Después de completar los pasos anteriores, a los pods que aparecen en las máquinas virtuales de agente de
Kubernetes se les asignan automáticamente direcciones IP privadas de la red virtual.

Implementación del complemento para contenedores de Docker

1. Descarga e instalación del complemento
2. Cree contenedores de Docker con el siguiente comando:

./[Link] \<container-name\> \<container-namespace\> \<image\>

Los contenedores comienzan a recibir automáticamente las direcciones IP del grupo asignado. Si desea cargar
equilibrar el tráfico a los contenedores de Docker, se debe colocar detrás de un equilibrador de carga de software,
y debe configurar un sondeo de equilibrador de carga, de la misma manera que se crea una directiva y los
sondeos para una máquina virtual.
Archivo de configuración de red de CNI
El archivo de configuración de red de CNI se describe en formato JSON. De forma predeterminada, se encuentra
en /etc/cni/net.d para Linux y c:\cni\netconf para Windows. El archivo especifica la configuración del
complemento y es diferente para Windows y Linux. El código JSON siguiente es un archivo de configuración de
Linux de ejemplo, seguido de una explicación de algunas de las opciones de configuración clave. No es necesario
hacer ningún cambio en el archivo:
 {
"cniVersion":"0.3.0",
"name":"azure",
"plugins":[
{
"type":"azure-vnet",
"mode":"bridge",
"bridge":"azure0",
"ipam":{
"type":"azure-vnet-ipam"
}
},
{
"type":"portmap",
"capabilities":{
"portMappings":true
},
"snat":true
}
]
}

Explicación de las opciones de configuración

cniVersion : los complementos de CNI de Azure Virtual Network son compatibles con las versiones 0.3.0 y
0.3.1 de la especificación CNI.
name : nombre de la red. Esta propiedad se puede establecer en un valor único.
type : nombre del complemento de red. Se establece en azure-vnet.
mode : modo de funcionamiento. Este campo es opcional. El único modo admitido es "bridge". Para más
información, consulte los modos de funcionamiento.
bridge : nombre del puente que se usará para conectar los contenedores a una red virtual. Este campo es
opcional. Si se omite, el complemento elige automáticamente un nombre único, basado en el índice de la
interfaz maestra.
ipam type : nombre del complemento de IPAM. Siempre se establece en azure-vnet-ipam.

Descarga e instalación del complemento

Descargue el complemento de GitHub. Descargue la versión más reciente para la plataforma que esté usando:
Linux : azure-vnet-cni-linux-amd64-<version no.>.tgz
Windows : azure-vnet-cni-windows-amd64-<version no.>.zip
Copie el script de instalación para Linux o Windows en su equipo. Guarde el script en un directorio scripts del
equipo y asigne al archivo el nombre [Link] para Linux o install-cni-plugin.ps1 para Windows.
Para instalar el complemento, ejecute el script adecuado para su plataforma y especifique la versión del
complemento que está usando. Por ejemplo, podría especificar v1.0.12-rc3:

\$scripts/[Link] [version]

scripts\\ install-cni-plugin.ps1 [version]

El script instala el complemento en /opt/cni/bin para Linux y en c:\cni\bin para Windows. El complemento
instalado incluye un archivo de configuración de red simple que funciona después de la instalación. No es
necesario actualizarlo. Para más información sobre las opciones de configuración del archivo, consulte Archivo de
configuración de red de CNI.
 Actualización de una aplicación IPv4 a IPv6 en Azure
Virtual Network: PowerShell
23/09/2020 • 8 minutes to read • Edit Online

En este artículo se muestra cómo agregar conectividad IPv6 a una aplicación IPv4 existente en una instancia de
Azure Virtual Network con una instancia de Standard Load Balancer e IP pública. La actualización local incluye:
Espacio de direcciones IPv6 para la red virtual y la subred
Standard Load Balancer con configuraciones de front-end IPv4 e IPV6
Máquinas virtuales con NIC que tienen una configuración IPv4 + IPv6
IP pública de IPv6 para que el equilibrador de carga tenga conectividad IPv6 accesible desde Internet

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar PowerShell de forma local, la versión del módulo de Azure PowerShell que necesita este
artículo es la 6.9.0 u otra posterior. Ejecute Get-Module -ListAvailable Az para buscar la versión instalada. Si
necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se ejecuta localmente,
también debe ejecutar Connect-AzAccount para crear una conexión con Azure.

Prerrequisitos
En este artículo se da por supuesto que implementó una instancia de Standard Load Balancer como se describe en
Inicio rápido: Creación de una instancia de Standard Load Balancer mediante Azure PowerShell.

Recuperación del grupo de recursos

Para poder generar la red virtual de doble pila, debe recuperar el grupo de recursos con Get-AzResourceGroup.

$rg = Get-AzResourceGroup -ResourceGroupName "myResourceGroupSLB"

Creación de direcciones IP IPv6

Cree una dirección IPv6 pública con New-AzPublicIpAddress para su instancia de Standard Load Balancer. En el
ejemplo siguiente, se crea una dirección IP pública IPv6 denominada PublicIP_v6 en el grupo de recursos
myResourceGroupSLB:

$PublicIP_v6 = New-AzPublicIpAddress `
-Name "PublicIP_v6" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Sku Standard `
-AllocationMethod Static `
-IpAddressVersion IPv6

Configuración del front-end del equilibrador de carga

Recupere la configuración del equilibrador de carga existente y, a continuación, agregue la nueva dirección IP IPv6
mediante Add-AzLoadBalancerFrontendIpConfig como se indica a continuación:

# Retrieve the load balancer configuration

$lb = Get-AzLoadBalancer -ResourceGroupName $[Link] -Name "MyLoadBalancer"
# Add IPv6 components to the local copy of the load balancer configuration
$lb | Add-AzLoadBalancerFrontendIpConfig `
-Name "dsLbFrontEnd_v6" `
-PublicIpAddress $PublicIP_v6
#Update the running load balancer with the new frontend
$lb | Set-AzLoadBalancer

Configuración del grupo back-end de equilibradores de carga

Cree el grupo back-end en la copia local de la configuración del equilibrador de carga y actualice el equilibrador de
carga en ejecución con la nueva configuración del grupo back-end como se indica a continuación:

$lb | Add-AzLoadBalancerBackendAddressPoolConfig -Name "LbBackEndPool_v6"

# Update the running load balancer with the new backend pool
$lb | Set-AzLoadBalancer

Creación de reglas de equilibrador de carga

Recupere la configuración existente del grupo back-end y front-end de equilibradores de carga y, a continuación,
agregue nuevas reglas de equilibrio de carga mediante Add-AzLoadBalancerRuleConfig.
 # Retrieve the updated (live) versions of the frontend and backend pool
$frontendIPv6 = Get-AzLoadBalancerFrontendIpConfig -Name "dsLbFrontEnd_v6" -LoadBalancer $lb
$backendPoolv6 = Get-AzLoadBalancerBackendAddressPoolConfig -Name "LbBackEndPool_v6" -LoadBalancer $lb
# Create new LB rule with the frontend and backend
$lb | Add-AzLoadBalancerRuleConfig `
-Name "dsLBrule_v6" `
-FrontendIpConfiguration $frontendIPv6 `
-BackendAddressPool $backendPoolv6 `
-Protocol Tcp `
-FrontendPort 80 `
-BackendPort 80
#Finalize all the load balancer updates on the running load balancer
$lb | Set-AzLoadBalancer

Incorporación de intervalos de direcciones IPv6

Agregue intervalos de direcciones IPv6 a la red virtual y a la subred que hospeda las máquinas virtuales como se
indica a continuación:

#Add IPv6 ranges to the VNET and subnet

#Retreive the VNET object
$vnet = Get-AzVirtualNetwork -ResourceGroupName $[Link] -Name "myVnet"
#Add IPv6 prefix to the VNET
$[Link]("[Link]/48")
#Update the running VNET
$vnet | Set-AzVirtualNetwork

#Retrieve the subnet object from the local copy of the VNET
$subnet= $[Link][0]
#Add IPv6 prefix to the Subnet (subnet of the VNET prefix, of course)
$[Link]("[Link]/64")
#Update the running VNET with the new subnet configuration
$vnet | Set-AzVirtualNetwork

Incorporación de la configuración IPv6 a NIC

Configuración de todas las NIC de máquina virtual con una dirección IPv6 mediante Add-
AzNetworkInterfaceIpConfig como se indica a continuación:

#Retrieve the NIC objects

$NIC_1 = Get-AzNetworkInterface -Name "myNic1" -ResourceGroupName $[Link]
$NIC_2 = Get-AzNetworkInterface -Name "myNic2" -ResourceGroupName $[Link]
$NIC_3 = Get-AzNetworkInterface -Name "myNic3" -ResourceGroupName $[Link]
#Add an IPv6 IPconfig to NIC_1 and update the NIC on the running VM
$NIC_1 | Add-AzNetworkInterfaceIpConfig -Name MyIPv6Config -Subnet $[Link][0] -
PrivateIpAddressVersion IPv6 -LoadBalancerBackendAddressPool $backendPoolv6
$NIC_1 | Set-AzNetworkInterface
#Add an IPv6 IPconfig to NIC_2 and update the NIC on the running VM
$NIC_2 | Add-AzNetworkInterfaceIpConfig -Name MyIPv6Config -Subnet $[Link][0] -
PrivateIpAddressVersion IPv6 -LoadBalancerBackendAddressPool $backendPoolv6
$NIC_2 | Set-AzNetworkInterface
#Add an IPv6 IPconfig to NIC_3 and update the NIC on the running VM
$NIC_3 | Add-AzNetworkInterfaceIpConfig -Name MyIPv6Config -Subnet $[Link][0] -
PrivateIpAddressVersion IPv6 -LoadBalancerBackendAddressPool $backendPoolv6
$NIC_3 | Set-AzNetworkInterface
Visualización de la red virtual de doble pila IPv6 en Azure Portal
Para ver la red virtual de doble pila IPv6 en Azure Portal, siga estos pasos:
1. En la barra de búsqueda del portal, escriba myVnet.
2. Seleccione myVnet cuando aparezca en los resultados de búsqueda. De este modo, se abrirá la página de
información general de la red virtual de doble pila llamada myVnet. En la red virtual de doble pila, se
muestran las tres NIC con las configuraciones IPv4 e IPv6 en una subred de pila doble denominada mySubnet.

Limpieza de recursos
Cuando ya no se necesiten, puede usar el comando Remove-AzResourceGroup para quitar el grupo de recursos, la
máquina virtual y todos los recursos relacionados.

Remove-AzResourceGroup -Name MyAzureResourceGroupSLB

Pasos siguientes
En este artículo, ha actualizado una instancia de Standard Load Balancer existente con una configuración de
direcciones IP de front-end IPv4 a una configuración de doble pila (IPv4 e IPv6). También ha agregado
configuraciones IPv6 a las NIC de las máquinas virtuales en el grupo back-end y a la instancia de Virtual Network
que las hospeda. Para más información sobre la compatibilidad de IPv6 en las redes virtuales de Azure, consulte
¿Qué es IPv6 para Azure Virtual Network?
 Adición de IPv6 a una aplicación IPv4 en Azure
Virtual Network - CLI de Azure
23/09/2020 • 7 minutes to read • Edit Online

En este artículo se muestra cómo agregar direcciones IPv6 a una aplicación que usa una dirección IP pública IPv4
en Azure Virtual Network para una instancia de Standard Load Balancer con la CLI de Azure. La actualización local
incluye una subred y una red virtual, una instancia de Standard Load Balancer con configuraciones de front-end
IPv4 + IPv6, máquinas virtuales con NIC que tienen configuraciones IPv4 + IPv6, un grupo de seguridad de red e IP
públicas.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si, en su lugar, decide instalar y usar la CLI de Azure en un entorno local, para esta guía de inicio rápido se necesita
la versión 2.0.28 de la CLI de Azure o una versión posterior. Ejecute az --version para buscar la versión instalada.
Consulte Instalación de la CLI de Azure para obtener información sobre la instalación o actualización.

Prerrequisitos
En este artículo se da por supuesto que implementó una instancia de Standard Load Balancer como se describe en
Inicio rápido: Creación de una instancia de Standard Load Balancer: CLI de Azure.

Creación de direcciones IPv6

Cree direcciones IPv6 públicas con az network public-ip create para su instancia de Standard Load Balancer. En el
ejemplo siguiente, se crea una dirección IP pública IPv6 denominada PublicIP_v6 en el grupo de recursos
myResourceGroupSLB:

az network public-ip create \

--name PublicIP_v6 \
--resource-group MyResourceGroupSLB \
--location EastUS \
--sku Standard \
--allocation-method static \
--version IPv6

Configuración de un front-end del equilibrador de carga IPv6

Configure el equilibrador de carga con la nueva dirección IP IPv6 mediante az network lb frontend-ip create como
se indica a continuación:

az network lb frontend-ip create \

--lb-name myLoadBalancer \
--name dsLbFrontEnd_v6 \
--resource-group MyResourceGroupSLB \
--public-ip-address PublicIP_v6

Configuración del grupo back-end de equilibradores de carga IPv6

Cree el grupo de back-end para NIC con direcciones IPv6 mediante AZ Network lb Address-Pool Create como se
indica a continuación:

az network lb address-pool create \

--lb-name myLoadBalancer \
--name dsLbBackEndPool_v6 \
--resource-group MyResourceGroupSLB

Configuración de las reglas del equilibrador de carga IPv6

Cree reglas de equilibrador de carga IPv6 con az network lb rule create.

az network lb rule create \

--lb-name myLoadBalancer \
--name dsLBrule_v6 \
--resource-group MyResourceGroupSLB \
--frontend-ip-name dsLbFrontEnd_v6 \
--protocol Tcp \
--frontend-port 80 \
--backend-port 80 \
--backend-pool-name dsLbBackEndPool_v6

Incorporación de intervalos de direcciones IPv6

Agregue intervalos de direcciones IPv6 a la red virtual y a la subred que hospeda el equilibrador de carga como se
indica a continuación:
 az network vnet update \
--name myVnet `
--resource-group MyResourceGroupSLB \
--address-prefixes "[Link]/16" "[Link]/48"

az network vnet subnet update \

--vnet-name myVnet \
--name mySubnet \
--resource-group MyResourceGroupSLB \
--address-prefixes "[Link]/24" "[Link]/64"

Incorporación de la configuración IPv6 a NIC

Configure las NIC de la máquina virtual con una dirección IPv6 mediante az network nic ip-config create como se
indica a continuación:

az network nic ip-config create \

--name dsIp6Config_NIC1 \
--nic-name myNicVM1 \
--resource-group MyResourceGroupSLB \
--vnet-name myVnet \
--subnet mySubnet \
--private-ip-address-version IPv6 \
--lb-address-pools dsLbBackEndPool_v6 \
--lb-name dsLB

az network nic ip-config create \

--name dsIp6Config_NIC2 \
--nic-name myNicVM2 \
--resource-group MyResourceGroupSLB \
--vnet-name myVnet \
--subnet mySubnet \
--private-ip-address-version IPv6 \
--lb-address-pools dsLbBackEndPool_v6 \
--lb-name myLoadBalancer

az network nic ip-config create \

--name dsIp6Config_NIC3 \
--nic-name myNicVM3 \
--resource-group MyResourceGroupSLB \
--vnet-name myVnet \
--subnet mySubnet \
--private-ip-address-version IPv6 \
--lb-address-pools dsLbBackEndPool_v6 \
--lb-name myLoadBalancer

Visualización de la red virtual de doble pila IPv6 en Azure Portal

Para ver la red virtual de doble pila IPv6 en Azure Portal, siga estos pasos:
1. En la barra de búsqueda del portal, escriba myVnet.
2. Seleccione myVnet cuando aparezca en los resultados de búsqueda. De este modo, se abrirá la página de
información general de la red virtual de doble pila llamada myVnet. En la red virtual de doble pila, se
muestran las tres NIC con las configuraciones IPv4 e IPv6 en una subred de pila doble denominada mySubnet.
Limpieza de recursos
Cuando ya no se necesiten, puede usar el comando Remove-AzResourceGroup para quitar el grupo de recursos, la
máquina virtual y todos los recursos relacionados.

Remove-AzResourceGroup -Name MyAzureResourceGroupSLB

Pasos siguientes
En este artículo, ha actualizado una instancia de Standard Load Balancer existente con una configuración de
direcciones IP de front-end IPv4 a una configuración de doble pila (IPv4 e IPv6). También ha agregado
configuraciones IPv6 a las NIC de las máquinas virtuales en el grupo back-end. Para más información sobre la
compatibilidad de IPv6 en las redes virtuales de Azure, consulte ¿Qué es IPv6 para Azure Virtual Network?
 Implementación de una aplicación de doble pila IPv6
con Load Balancer básico: PowerShell
23/09/2020 • 16 minutes to read • Edit Online

En este artículo se explica cómo se implementa una aplicación de doble pila (IPv4 + IPv6) con Load Balancer básico
mediante Azure PowerShell, que incluye una red virtual de doble pila y una subred, una instancia de Load Balancer
básico con configuraciones de front-end duales (IPv4 + IPv6), máquinas virtuales con NIC que tienen una
configuración de IP dual, un grupo de seguridad de red y direcciones IP públicas.
Para implementar una aplicación de doble pila (IPv4 + IPv6) con Standard Load Balancer, consulte Implementación
de una aplicación de doble pila IPv6 con Standard Load Balancer con Azure PowerShell.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar PowerShell de forma local, la versión del módulo de Azure PowerShell que necesita este
artículo es la 6.9.0 u otra posterior. Ejecute Get-Module -ListAvailable Az para buscar la versión instalada. Si
necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se ejecuta localmente,
también debe ejecutar Connect-AzAccount para crear una conexión con Azure.

Crear un grupo de recursos

Para poder generar la red virtual de doble pila, debe crear primero un grupo de recursos con New-
AzResourceGroup. En el ejemplo siguiente, se crea un grupo de recursos llamado myRGDualStack en la ubicación
Este de EE. UU. :

$rg = New-AzResourceGroup `
-ResourceGroupName "dsRG1" `
-Location "east us"

Creación de direcciones IP públicas IPv4 e IPv6

Para obtener acceso a las máquinas virtuales desde Internet, necesita direcciones IP públicas IPv4 e IPv6 para el
equilibrador de carga. Cree las direcciones IP públicas con New-AzPublicIpAddress. En el ejemplo siguiente, se
crean unas direcciones IP públicas IPv4 e IPv6 denominadas dsPublicIP_v4 y dsPublicIP_v6 en el grupo de recursos
dsRG1:

$PublicIP_v4 = New-AzPublicIpAddress `
-Name "dsPublicIP_v4" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-AllocationMethod Dynamic `
-IpAddressVersion IPv4

$PublicIP_v6 = New-AzPublicIpAddress `
-Name "dsPublicIP_v6" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-AllocationMethod Dynamic `
-IpAddressVersion IPv6

Para obtener acceso a las máquinas virtuales mediante una conexión RDP, cree una dirección IP pública de IPV4
para las máquinas virtuales con New AzPublicIpAddress.

$RdpPublicIP_1 = New-AzPublicIpAddress `
-Name "RdpPublicIP_1" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-AllocationMethod Dynamic `
-IpAddressVersion IPv4

$RdpPublicIP_2 = New-AzPublicIpAddress `
-Name "RdpPublicIP_2" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-AllocationMethod Dynamic `
-IpAddressVersion IPv4

Creación de un equilibrador de carga básico

En esta sección, va a configurar la dirección IP del front-end (IPv4 y IPv6) y el grupo de direcciones del back-end
para el equilibrador de carga, además de crear un equilibrador de carga básico.
Creación de una dirección IP de front-end
Cree una dirección IP de front-end con New-AzLoadBalancerFrontendIpConfig. En el ejemplo siguiente, se crean
unas configuraciones de IP de front-end IPv4 e IPv6 llamadas dsLbFrontEnd_v4 y dsLbFrontEnd_v6:
 $frontendIPv4 = New-AzLoadBalancerFrontendIpConfig `
-Name "dsLbFrontEnd_v4" `
-PublicIpAddress $PublicIP_v4

$frontendIPv6 = New-AzLoadBalancerFrontendIpConfig `
-Name "dsLbFrontEnd_v6" `
-PublicIpAddress $PublicIP_v6

Configuración del grupo de direcciones de back-end

Cree un grupo de direcciones de back-end con New-AzLoadBalancerBackendAddressPoolConfig. En el resto de los
pasos, las máquinas virtuales se conectan a este grupo back-end. En el ejemplo siguiente, se crean los grupos de
direcciones de back-end dsLbBackEndPool_v4 y dsLbBackEndPool_v6, que van a incluir máquinas virtuales con
configuraciones de NIC IPV4 e IPv6:

$backendPoolv4 = New-AzLoadBalancerBackendAddressPoolConfig `
-Name "dsLbBackEndPool_v4"

$backendPoolv6 = New-AzLoadBalancerBackendAddressPoolConfig `
-Name "dsLbBackEndPool_v6"

Creación de un sondeo de estado

Utilice Add-AzLoadBalancerProbeConfig para crear un sondeo de estado para supervisar el estado de las VM.

$probe = New-AzLoadBalancerProbeConfig -Name MyProbe -Protocol tcp -Port 3389 -IntervalInSeconds 15 -ProbeCount
2

Creación de una regla de equilibrador de carga

Las reglas de equilibrador de carga se utilizan para definir cómo se distribuye el tráfico a las máquinas virtuales.
Defina la configuración de la IP de front-end para el tráfico entrante y el grupo de IP de back-end para el tráfico
entrante, junto con los puertos de origen y destino requeridos. Para tener la seguridad de que solo reciben tráfico
las máquinas virtuales correctas, también puede definir un sondeo de estado. Los equilibradores de carga básicos
usan un sondeo de IPv4 para evaluar el estado de los puntos de conexión IPv4 e IPv6 de las máquinas virtuales. Los
equilibradores de carga estándar permiten realizar explícitamente sondeos de estado de IPv6.
Cree una regla del equilibrador de carga con Add-AzLoadBalancerRuleConfig. En el ejemplo siguiente, se crean
reglas del equilibrador de carga llamadas dsLBrule_v4 y dsLBrule_v6, y se equilibra el tráfico del puerto TCP 80
dirigido a las configuraciones de IP de front-end IPv4 e IPv6:

$lbrule_v4 = New-AzLoadBalancerRuleConfig `
-Name "dsLBrule_v4" `
-FrontendIpConfiguration $frontendIPv4 `
-BackendAddressPool $backendPoolv4 `
-Protocol Tcp `
-FrontendPort 80 `
-BackendPort 80 `
-probe $probe

$lbrule_v6 = New-AzLoadBalancerRuleConfig `
-Name "dsLBrule_v6" `
-FrontendIpConfiguration $frontendIPv6 `
-BackendAddressPool $backendPoolv6 `
-Protocol Tcp `
-FrontendPort 80 `
-BackendPort 80 `
-probe $probe
Creación de un equilibrador de carga
Cree un equilibrador de carga básico con New-AzLoadBalancer. En el ejemplo siguiente, se crea un equilibrador de
carga básico público llamado myLoadBalancer usando las configuraciones de direcciones IP de front-end IPv4 e
IPv6, grupos de servidores back-end y las reglas de equilibrio de carga que creó en los pasos anteriores:

$lb = New-AzLoadBalancer `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "MyLoadBalancer" `
-Sku "Basic" `
-FrontendIpConfiguration $frontendIPv4,$frontendIPv6 `
-BackendAddressPool $backendPoolv4,$backendPoolv6 `
-LoadBalancingRule $lbrule_v4,$lbrule_v6

Crear recursos de red

Para poder implementar algunas máquinas virtuales y probar el equilibrador, debe crear unos recursos de red que
lo permitan: un conjunto de disponibilidad, un grupo de seguridad de red, una red virtual y varias NIC virtuales.
Crear un conjunto de disponibilidad
Para mejorar la alta disponibilidad de la aplicación, coloque las máquinas virtuales en un conjunto de
disponibilidad.
Cree un conjunto de disponibilidad con New-AzAvailabilitySet. En el ejemplo siguiente se crea un conjunto de
disponibilidad denominado myAvailabilitySet:

$avset = New-AzAvailabilitySet `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "dsAVset" `
-PlatformFaultDomainCount 2 `
-PlatformUpdateDomainCount 2 `
-Sku aligned

Creación de un grupo de seguridad de red

Cree un grupo de seguridad de red para las reglas que van a controlar la comunicación entrante y saliente de la red
virtual.
Creación de una regla de grupo de seguridad de red para el puerto 3389
Cree una regla de grupo de seguridad de red para permitir conexiones RDP en el puerto 3389 con New-
AzNetworkSecurityRuleConfig.

$rule1 = New-AzNetworkSecurityRuleConfig `
-Name 'myNetworkSecurityGroupRuleRDP' `
-Description 'Allow RDP' `
-Access Allow `
-Protocol Tcp `
-Direction Inbound `
-Priority 100 `
-SourceAddressPrefix * `
-SourcePortRange * `
-DestinationAddressPrefix * `
-DestinationPortRange 3389

Creación de una regla de grupo de seguridad de red para el puerto 80

Cree una regla de grupo de seguridad de red para permitir conexiones de Internet a través del puerto 80 con New-
AzNetworkSecurityRuleConfig.

$rule2 = New-AzNetworkSecurityRuleConfig `
-Name 'myNetworkSecurityGroupRuleHTTP' `
-Description 'Allow HTTP' `
-Access Allow `
-Protocol Tcp `
-Direction Inbound `
-Priority 200 `
-SourceAddressPrefix * `
-SourcePortRange 80 `
-DestinationAddressPrefix * `
-DestinationPortRange 80

Crear un grupo de seguridad de red

Cree un grupo de seguridad de red con New-AzNetworkSecurityGroup.

$nsg = New-AzNetworkSecurityGroup `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "dsNSG1" `
-SecurityRules $rule1,$rule2

Creación de una red virtual

Cree una red virtual con New-AzVirtualNetwork. En el ejemplo siguiente se crea una red virtual denominada con
una subred llamada myVnet con mySubnet:

# Create dual stack subnet

$subnet = New-AzVirtualNetworkSubnetConfig `
-Name "dsSubnet" `
-AddressPrefix "[Link]/24","[Link]/64"

# Create the virtual network

$vnet = New-AzVirtualNetwork `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "dsVnet" `
-AddressPrefix "[Link]/16","[Link]/48" `
-Subnet $subnet

Creación de tarjetas NIC

Cree NIC virtuales con New-AzNetworkInterface. En el ejemplo siguiente, se crean dos NIC virtuales, ambas con las
configuraciones IPv4 e IPv6. (Una NIC virtual para cada máquina virtual que cree para la aplicación en los pasos
siguientes).
 $Ip4Config=New-AzNetworkInterfaceIpConfig `
-Name dsIp4Config `
-Subnet $[Link][0] `
-PrivateIpAddressVersion IPv4 `
-LoadBalancerBackendAddressPool $backendPoolv4 `
-PublicIpAddress $RdpPublicIP_1

$Ip6Config=New-AzNetworkInterfaceIpConfig `
-Name dsIp6Config `
-Subnet $[Link][0] `
-PrivateIpAddressVersion IPv6 `
-LoadBalancerBackendAddressPool $backendPoolv6

$NIC_1 = New-AzNetworkInterface `
-Name "dsNIC1" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-NetworkSecurityGroupId $[Link] `
-IpConfiguration $Ip4Config,$Ip6Config

$Ip4Config=New-AzNetworkInterfaceIpConfig `
-Name dsIp4Config `
-Subnet $[Link][0] `
-PrivateIpAddressVersion IPv4 `
-LoadBalancerBackendAddressPool $backendPoolv4 `
-PublicIpAddress $RdpPublicIP_2

$NIC_2 = New-AzNetworkInterface `
-Name "dsNIC2" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-NetworkSecurityGroupId $[Link] `
-IpConfiguration $Ip4Config,$Ip6Config

Creación de máquinas virtuales

Establezca un nombre de usuario de administrador y una contraseña para las máquinas virtuales con Get-
Credential:

$cred = get-credential -Message "DUAL STACK VNET SAMPLE: Please enter the Administrator credential to log into
the VMs."

Ahora puede crear las máquinas virtuales con New-AzVM. En el ejemplo siguiente, se crean dos máquinas virtuales
y los componentes de red virtual necesarios, si aún no existen.
 $vmsize = "Standard_A2"
$ImagePublisher = "MicrosoftWindowsServer"
$imageOffer = "WindowsServer"
$imageSKU = "2019-Datacenter"

$vmName= "dsVM1"
$VMconfig1 = New-AzVMConfig -VMName $vmName -VMSize $vmsize -AvailabilitySetId $[Link] 3> $null | Set-
AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent 3> $null | Set-
AzVMSourceImage -PublisherName $ImagePublisher -Offer $imageOffer -Skus $imageSKU -Version "latest" 3> $null |
Set-AzVMOSDisk -Name "$[Link]" -CreateOption fromImage 3> $null | Add-AzVMNetworkInterface -Id $NIC_1.Id
3> $null
$VM1 = New-AzVM -ResourceGroupName $[Link] -Location $[Link] -VM $VMconfig1

$vmName= "dsVM2"
$VMconfig2 = New-AzVMConfig -VMName $vmName -VMSize $vmsize -AvailabilitySetId $[Link] 3> $null | Set-
AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent 3> $null | Set-
AzVMSourceImage -PublisherName $ImagePublisher -Offer $imageOffer -Skus $imageSKU -Version "latest" 3> $null |
Set-AzVMOSDisk -Name "$[Link]" -CreateOption fromImage 3> $null | Add-AzVMNetworkInterface -Id $NIC_2.Id
3> $null
$VM2 = New-AzVM -ResourceGroupName $[Link] -Location $[Link] -VM $VMconfig2

Determinación de las direcciones IP de los puntos de conexión IPv4 e

IPv6
Obtenga todos los objetos de interfaz de red del grupo de recursos para resumir las direcciones IP que se utilizan
en esta implementación con get-AzNetworkInterface . Obtenga también las direcciones del front-end del
equilibrador de carga de los puntos de conexión IPv4 e IPv6 con get-AzpublicIpAddress .

$rgName= "dsRG1"
$NICsInRG= get-AzNetworkInterface -resourceGroupName $rgName
write-host `nSummary of IPs in this Deployment:
write-host ******************************************
foreach ($NIC in $NICsInRG) {

$VMid= $[Link]
$VMnamebits= $[Link]("/")
$VMname= $VMnamebits[($[Link]-1)]
write-host `nPrivate IP addresses for $VMname
$IPconfigsInNIC= $[Link]
foreach ($IPconfig in $IPconfigsInNIC) {

$IPaddress= $[Link]
write-host " "$IPaddress
IF ($[Link]) {

$IDbits= ($[Link]).split("/")
$PipName= $IDbits[($[Link]-1)]
$PipObject= get-azPublicIpAddress -name $PipName -resourceGroup $rgName
write-host " "RDP address: $[Link]
}
}
}

write-host `nPublic IP addresses on Load Balancer:

(get-AzpublicIpAddress -resourcegroupname $rgName | where { $_.name -notlike "RdpPublicIP*" }).IpAddress

En la ilustración siguiente, se muestra una salida de ejemplo que muestra las direcciones IPv4 e IPv6 privadas de las
dos máquinas virtuales y las direcciones IP IPv4 e IPv6 de front-end del equilibrador de carga.
Visualización de la red virtual de doble pila IPv6 en Azure Portal
Para ver la red virtual de doble pila IPv6 en Azure Portal, siga estos pasos:
1. En la barra de búsqueda del portal, escriba dsVnet.
2. Cuando aparezca la opción myVir tualNetwork en los resultados de la búsqueda, selecciónela. De este modo,
se abrirá la página de información general de la red virtual de doble pila llamada dsVnet. En la red virtual de
doble pila, se muestran las dos NIC con las configuraciones IPv4 e IPv6 en una subred de pila doble denominada
dsSubnet.

Limpieza de recursos
Cuando ya no se necesiten, puede usar el comando Remove-AzResourceGroup para quitar el grupo de recursos, la
máquina virtual y todos los recursos relacionados.

Remove-AzResourceGroup -Name dsRG1

Pasos siguientes
En este artículo, ha creado un equilibrador de carga básico con una configuración de IP de front-end doble (IPv4 e
IPv6). También ha creado dos máquinas virtuales que contienen NIC con configuraciones de IP duales (IPV4 + IPv6)
que se agregaron al grupo de back-end del equilibrador de carga. Para más información sobre la compatibilidad de
IPv6 en las redes virtuales de Azure, consulte ¿Qué es IPv6 para Azure Virtual Network?
 Implementación de una aplicación de pila doble IPv6
con Basic Load Balancer: CLI
23/09/2020 • 15 minutes to read • Edit Online

En este artículo se explica cómo se implementa una aplicación de pila doble (IPv4 + IPv6) con Basic Load Balancer
mediante la CLI de Azure que contiene una red virtual de pila doble y una subred de pila doble, una instancia de
Standard Load Balancer con configuraciones de front-end duales (IPv4 + IPv6), VM con NIC que tienen una
configuración de IP dual, reglas de grupo de seguridad de red dual e IP públicas duales.
Para implementar una aplicación de pila dual (IPv4 + IPv6) con Standard Load Balancer, consulte Implementación
de una aplicación de pila doble IPv6 con Standard Load Balancer con la CLI de Azure.
Si no tiene una suscripción a Azure, cree una cuenta gratuita ahora.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si, en su lugar, decide instalar y usar la CLI de Azure en un entorno local, para esta guía de inicio rápido se necesita
la versión 2.0.49 de la CLI de Azure o una versión posterior. Ejecute az --version para buscar la versión instalada.
Consulte Instalación de la CLI de Azure para obtener información sobre la instalación o actualización.

Crear un grupo de recursos

Para poder generar la red virtual de doble pila, debe crear primero un grupo de recursos con az group create. En el
ejemplo siguiente, se crea un grupo de recursos denominado DsResourceGroup01 en la ubicación eastus:

az group create \
--name DsResourceGroup01 \
--location eastus

Creación de direcciones IP públicas IPv4 e IPv6 para el equilibrador de

carga
Para obtener acceso los puntos de conexión IPv4 e IPv6 en Internet, necesita direcciones IP públicas IPv4 e IPv6
para el equilibrador de carga. Cree una dirección IP pública con az network public-ip create. En el ejemplo siguiente,
se crean unas direcciones IP públicas IPv4 e IPv6 denominadas dsPublicIP_v4 y dsPublicIP_v6 en el grupo de
recursos DsResourceGroup01:

# Create an IPV4 IP address

az network public-ip create \
--name dsPublicIP_v4 \
--resource-group DsResourceGroup01 \
--location eastus \
--sku BASIC \
--allocation-method dynamic \
--version IPv4

# Create an IPV6 IP address

az network public-ip create \
--name dsPublicIP_v6 \
--resource-group DsResourceGroup01 \
--location eastus \
--sku BASIC \
--allocation-method dynamic \
--version IPv6

Creación de direcciones IP públicas para las VM

Para acceder de forma remota a las VM en Internet, necesita las direcciones IP públicas IPv4 de las VM. Cree una
dirección IP pública con az network public-ip create.

az network public-ip create \

--name dsVM0_remote_access \
--resource-group DsResourceGroup01 \
--location eastus \
--sku BASIC \
--allocation-method dynamic \
--version IPv4

az network public-ip create \

--name dsVM1_remote_access \
--resource-group DsResourceGroup01 \
--location eastus \
--sku BASIC \
--allocation-method dynamic \
--version IPv4

Creación de un equilibrador de carga básico

En esta sección, va a configurar la dirección IP del front-end (IPv4 y IPv6) y el grupo de direcciones del back-end
para el equilibrador de carga, además de crear un equilibrador de carga básico.
Creación de un equilibrador de carga
Cree una instancia de Load Balancer básico con az network lb create denominada dsLB que incluya un grupo de
servidores front-end llamado dsLbFrontEnd_v4 y un grupo de servidores back-end llamado
dsLbBackEndPool_v4 que esté asociado a la dirección IP pública IPv4 dsPublicIP_v4 que creó en el paso
anterior.

az network lb create \
--name dsLB \
--resource-group DsResourceGroup01 \
--sku Basic \
--location eastus \
--frontend-ip-name dsLbFrontEnd_v4 \
--public-ip-address dsPublicIP_v4 \
--backend-pool-name dsLbBackEndPool_v4

Creación de un servidor front-end IPv6

Cree una dirección IP de front-end IPV6 con az network lb frontend-ip create. En el ejemplo siguiente, se crea una
configuración de direcciones IP de front-end llamada dsLbFrontEnd_v6 y se asocia a la dirección dsPublicIP_v6:

az network lb frontend-ip create \

--lb-name dsLB \
--name dsLbFrontEnd_v6 \
--resource-group DsResourceGroup01 \
--public-ip-address dsPublicIP_v6

Configuración del grupo de direcciones de back-end IPv6

Cree un grupo de direcciones de back-end IPv6 con az network lb address-pool create. En el ejemplo siguiente, se
crean el grupo de direcciones de back-end denominado dsLbBackEndPool_v6 que va a incluir VM con
configuraciones de NIC IPv6:

az network lb address-pool create \

--lb-name dsLB \
--name dsLbBackEndPool_v6 \
--resource-group DsResourceGroup01

Creación de un sondeo de estado

Cree un sondeo de estado con az network lb probe create para supervisar el estado de las máquinas virtuales.

az network lb probe create -g DsResourceGroup01 --lb-name dsLB -n dsProbe --protocol tcp --port 3389

Creación de una regla de equilibrador de carga

Las reglas de equilibrador de carga se utilizan para definir cómo se distribuye el tráfico a las máquinas virtuales.
Defina la configuración de la IP de front-end para el tráfico entrante y el grupo de IP de back-end para el tráfico
entrante, junto con los puertos de origen y destino requeridos.
Cree una regla de equilibrador de carga con az network lb rule create. En el ejemplo siguiente, se crean reglas del
equilibrador de carga llamadas dsLBrule_v4 y dsLBrule_v6, y se equilibra el tráfico del puerto TCP 80 dirigido a las
configuraciones de IP de front-end IPv4 e IPv6:
 az network lb rule create \
--lb-name dsLB \
--name dsLBrule_v4 \
--resource-group DsResourceGroup01 \
--frontend-ip-name dsLbFrontEnd_v4 \
--protocol Tcp \
--frontend-port 80 \
--backend-port 80 \
--probe-name dsProbe \
--backend-pool-name dsLbBackEndPool_v4

az network lb rule create \

--lb-name dsLB \
--name dsLBrule_v6 \
--resource-group DsResourceGroup01 \
--frontend-ip-name dsLbFrontEnd_v6 \
--protocol Tcp \
--frontend-port 80 \
--backend-port 80 \
--probe-name dsProbe \
--backend-pool-name dsLbBackEndPool_v6

Crear recursos de red

Para poder implementar algunas VM, debe crear recursos de red que lo permitan: un conjunto de disponibilidad, un
grupo de seguridad de red, una red virtual y varias NIC virtuales.
Crear un conjunto de disponibilidad
Para mejorar la disponibilidad de la aplicación, coloque las VM en un conjunto de disponibilidad.
Cree el conjunto de disponibilidad con az vm availability-set create. En el ejemplo siguiente se crea un conjunto de
disponibilidad denominado dsAVset:

az vm availability-set create \
--name dsAVset \
--resource-group DsResourceGroup01 \
--location eastus \
--platform-fault-domain-count 2 \
--platform-update-domain-count 2

Creación de un grupo de seguridad de red

Cree un grupo de seguridad de red para las reglas que van a controlar la comunicación entrante y saliente de la red
virtual.
Crear un grupo de seguridad de red
Cree un grupo de seguridad de red con az network nsg create.

az network nsg create \

--name dsNSG1 \
--resource-group DsResourceGroup01 \
--location eastus

Creación de una regla de grupo de seguridad de red para las conexiones entrantes y salientes
Cree una regla de grupo de seguridad de red para permitir las conexiones RDP a través del puerto 3389, la
conexión a Internet a través del puerto 80 y las conexiones salientes con az network nsg rule create.
 # Create inbound rule for port 3389
az network nsg rule create \
--name allowRdpIn \
--nsg-name dsNSG1 \
--resource-group DsResourceGroup01 \
--priority 100 \
--description "Allow Remote Desktop In" \
--access Allow \
--protocol "*" \
--direction Inbound \
--source-address-prefixes "*" \
--source-port-ranges "*" \
--destination-address-prefixes "*" \
--destination-port-ranges 3389

# Create inbound rule for port 80

az network nsg rule create \
--name allowHTTPIn \
--nsg-name dsNSG1 \
--resource-group DsResourceGroup01 \
--priority 200 \
--description "Allow HTTP In" \
--access Allow \
--protocol "*" \
--direction Inbound \
--source-address-prefixes "*" \
--source-port-ranges 80 \
--destination-address-prefixes "*" \
--destination-port-ranges 80

# Create outbound rule

az network nsg rule create \

--name allowAllOut \
--nsg-name dsNSG1 \
--resource-group DsResourceGroup01 \
--priority 300 \
--description "Allow All Out" \
--access Allow \
--protocol "*" \
--direction Outbound \
--source-address-prefixes "*" \
--source-port-ranges "*" \
--destination-address-prefixes "*" \
--destination-port-ranges "*"

Creación de una red virtual

Cree la red virtual con el comando az network vnet create. En el ejemplo siguiente se crea una red virtual
denominada dsVNET con las subredes dsSubNET_v4 y dsSubNET_v6:
 # Create the virtual network
az network vnet create \
--name dsVNET \
--resource-group DsResourceGroup01 \
--location eastus \
--address-prefixes "[Link]/16" "[Link]/48"

# Create a single dual stack subnet

az network vnet subnet create \

--name dsSubNET \
--resource-group DsResourceGroup01 \
--vnet-name dsVNET \
--address-prefixes "[Link]/24" "[Link]/64" \
--network-security-group dsNSG1

Creación de tarjetas NIC

Cree NIC virtuales para cada VM con az network nic create. El ejemplo siguiente crea una NIC virtual para cada VM.
Cada NIC tiene dos configuraciones IP (una configuración IPv4 y una configuración IPv6). Debe crear la
configuración IPV6 con az network nic ip-config create.
 # Create NICs
az network nic create \
--name dsNIC0 \
--resource-group DsResourceGroup01 \
--network-security-group dsNSG1 \
--vnet-name dsVNET \
--subnet dsSubNet \
--private-ip-address-version IPv4 \
--lb-address-pools dsLbBackEndPool_v4 \
--lb-name dsLB \
--public-ip-address dsVM0_remote_access

az network nic create \

--name dsNIC1 \
--resource-group DsResourceGroup01 \
--network-security-group dsNSG1 \
--vnet-name dsVNET \
--subnet dsSubNet \
--private-ip-address-version IPv4 \
--lb-address-pools dsLbBackEndPool_v4 \
--lb-name dsLB \
--public-ip-address dsVM1_remote_access

# Create IPV6 configurations for each NIC

az network nic ip-config create \

--name dsIp6Config_NIC0 \
--nic-name dsNIC0 \
--resource-group DsResourceGroup01 \
--vnet-name dsVNET \
--subnet dsSubNet \
--private-ip-address-version IPv6 \
--lb-address-pools dsLbBackEndPool_v6 \
--lb-name dsLB

az network nic ip-config create \

--name dsIp6Config_NIC1 \
--nic-name dsNIC1 \
--resource-group DsResourceGroup01 \
--vnet-name dsVNET \
--subnet dsSubNet \
--private-ip-address-version IPv6 \
--lb-address-pools dsLbBackEndPool_v6 \
--lb-name dsLB

Creación de máquinas virtuales

Cree las máquinas virtuales con az vm create. En el ejemplo siguiente, se crean dos máquinas virtuales y los
componentes de red virtual necesarios, si aún no existen.
Cree la máquina virtual dsVM0 de la siguiente manera:

az vm create \
--name dsVM0 \
--resource-group DsResourceGroup01 \
--nics dsNIC0 \
--size Standard_A2 \
--availability-set dsAVset \
--image MicrosoftWindowsServer:WindowsServer:2019-Datacenter:latest

Cree la máquina virtual dsVM1 de la siguiente manera:

 az vm create \
--name dsVM1 \
--resource-group DsResourceGroup01 \
--nics dsNIC1 \
--size Standard_A2 \
--availability-set dsAVset \
--image MicrosoftWindowsServer:WindowsServer:2019-Datacenter:latest

Visualización de la red virtual de doble pila IPv6 en Azure Portal

Para ver la red virtual de doble pila IPv6 en Azure Portal, siga estos pasos:
1. En la barra de búsqueda del portal, escriba dsVnet.
2. Cuando aparezca la opción myVir tualNetwork en los resultados de la búsqueda, selecciónela. De este modo,
se abrirá la página de información general de la red virtual de doble pila llamada dsVnet. En la red virtual de
doble pila, se muestran las dos NIC con las configuraciones IPv4 e IPv6 en una subred de pila doble denominada
dsSubnet.

Limpieza de recursos
Cuando ya no se necesiten, puede usar el comando az group delete para quitar el grupo de recursos, la máquina
virtual y todos los recursos relacionados.

az group delete --name DsResourceGroup01

Pasos siguientes
En este artículo, ha creado un equilibrador de carga básico con una configuración de IP de front-end doble (IPv4 e
IPv6). También ha creado dos máquinas virtuales que contienen NIC con configuraciones de IP duales (IPV4 + IPv6)
que se agregaron al grupo de back-end del equilibrador de carga. Para más información sobre la compatibilidad de
IPv6 en las redes virtuales de Azure, consulte ¿Qué es IPv6 para Azure Virtual Network?
 Implementación de una aplicación de pila doble IPv6
con Basic Load Balancer en Azure: plantilla
23/09/2020 • 3 minutes to read • Edit Online

En este artículo se proporciona una lista de tareas de configuración de IPv6 con la parte de la plantilla de VM de
Azure Resource Manager a la que se aplica. Use la plantilla que se describe en este artículo para implementar una
aplicación de pila doble (IPv4 + IPv6) con Basic Load Balancer que contiene una red virtual de pila doble con
subredes IPv4 e IPv6, Basic Load Balancer con configuraciones de front-end duales (IPv4 + IPv6), VM con NIC que
tienen una configuración de IP dual, un grupo de seguridad de red e IP públicas.
Para implementar una aplicación de pila dual (IPv4 + IPv6) con Standard Load Balancer, consulte Implementación
de una aplicación de pila doble IPv6 con Standard Load Balancer: plantilla.

Configuraciones necesarias
Busque las secciones de la plantilla para ver dónde se deben producir.
Elemento addressSpace de IPv6 para la red virtual
Sección de plantilla que se va a agregar:

"addressSpace": {
"addressPrefixes": [
"[variables('vnetv4AddressRange')]",
"[variables('vnetv6AddressRange')]"

Subred de IPv6 en el elemento addressSpace de la red virtual IPv6

Sección de plantilla que se va a agregar:

{
"name": "V6Subnet",
"properties": {
"addressPrefix": "[variables('subnetv6AddressRange')]"
}

Configuración de IPv6 para la NIC

Sección de plantilla que se va a agregar:

{
"name": "ipconfig-v6",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"privateIPAddressVersion":"IPv6",
"subnet": {
"id": "[variables('v6-subnet-id')]"
},
"loadBalancerBackendAddressPools": [
{
"id": "
[concat(resourceId('[Link]/loadBalancers','loadBalancer'),'/backendAddressPools/LBBAP-v6')]"
}
Reglas del grupo de seguridad de red (NSG ) de IPv6

{
"name": "default-allow-rdp",
"properties": {
"description": "Allow RDP",
"protocol": "Tcp",
"sourcePortRange": "33819-33829",
"destinationPortRange": "5000-6000",
"sourceAddressPrefix": "[Link]/64",
"destinationAddressPrefix": "[Link]/64",
"access": "Allow",
"priority": 1003,
"direction": "Inbound"
}

Configuración condicional
Si usa un dispositivo de red virtual, agregue rutas IPv6 en la tabla de rutas. En caso contrario, esta configuración es
opcional.

{
"type": "[Link]/routeTables",
"name": "v6route",
"apiVersion": "[variables('ApiVersion')]",
"location": "[resourceGroup().location]",
"properties": {
"routes": [
{
"name": "v6route",
"properties": {
"addressPrefix": "[Link]/64",
"nextHopType": "VirtualAppliance",
"nextHopIpAddress": "[Link]"
}

Configuración opcional
Acceso a Internet de IPv6 para la red virtual

{
"name": "LBFE-v6",
"properties": {
"publicIPAddress": {
"id": "[resourceId('[Link]/publicIPAddresses','lbpublicip-v6')]"
}

Direcciones IP públicas IPv6

{
"apiVersion": "[variables('ApiVersion')]",
"type": "[Link]/publicIPAddresses",
"name": "lbpublicip-v6",
"location": "[resourceGroup().location]",
"properties": {
"publicIPAllocationMethod": "Dynamic",
"publicIPAddressVersion": "IPv6"
}
Front-end IPv6 para Load Balancer

{
"name": "LBFE-v6",
"properties": {
"publicIPAddress": {
"id": "[resourceId('[Link]/publicIPAddresses','lbpublicip-v6')]"
}

Grupo de direcciones de back-end IPv6 para Load Balancer

"backendAddressPool": {
"id": "[concat(resourceId('[Link]/loadBalancers', 'loadBalancer'),
'/backendAddressPools/LBBAP-v6')]"
},
"protocol": "Tcp",
"frontendPort": 8080,
"backendPort": 8080
},
"name": "lbrule-v6"

Reglas del equilibrador de carga de IPv6 para asociar puertos de entrada y de salida

{
"name": "ipconfig-v6",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"privateIPAddressVersion":"IPv6",
"subnet": {
"id": "[variables('v6-subnet-id')]"
},
"loadBalancerBackendAddressPools": [
{
"id": "
[concat(resourceId('[Link]/loadBalancers','loadBalancer'),'/backendAddressPools/LBBAP-v6')]"
}

Ejemplo de JSON de plantilla de VM

Para implementar una aplicación de pila doble IPv6 con Basic Load Balancer en Azure Virtual Network mediante
una plantilla de Azure Resource Manager, consulte la plantilla de ejemplo aquí.

Pasos siguientes
Puede encontrar detalles sobre precios de direcciones IP públicas, ancho de banda de red o Load Balancer.
 Implementación de una aplicación de pila doble IPv6
en Azure - PowerShell
23/09/2020 • 16 minutes to read • Edit Online

En este artículo se explica cómo se implementa mediante Standard Load Balancer una aplicación de doble pila
(IPv4 + IPv6) en Azure que contiene una red virtual de doble pila y una subred, un equilibrador de carga estándar
con configuraciones de front-end duales (IPv4 + IPv6), máquinas virtuales con NIC que tienen una configuración
de IP dual, un grupo de seguridad de red y direcciones IP públicas.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar PowerShell de forma local, la versión del módulo de Azure PowerShell que necesita este
artículo es la 6.9.0 u otra posterior. Ejecute Get-Module -ListAvailable Az para buscar la versión instalada. Si
necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se ejecuta localmente,
también debe ejecutar Connect-AzAccount para crear una conexión con Azure.

Crear un grupo de recursos

Para poder generar la red virtual de doble pila, debe crear primero un grupo de recursos con New-
AzResourceGroup. En el ejemplo siguiente, se crea un grupo de recursos llamado myRGDualStack en la ubicación
Este de EE. UU. :
 $rg = New-AzResourceGroup `
-ResourceGroupName "dsRG1" `
-Location "east us"

Creación de direcciones IP públicas IPv4 e IPv6

Para obtener acceso a las máquinas virtuales desde Internet, necesita direcciones IP públicas IPv4 e IPv6 para el
equilibrador de carga. Cree las direcciones IP públicas con New-AzPublicIpAddress. En el ejemplo siguiente, se
crean unas direcciones IP públicas IPv4 e IPv6 denominadas dsPublicIP_v4 y dsPublicIP_v6 en el grupo de
recursos dsRG1:

$PublicIP_v4 = New-AzPublicIpAddress `
-Name "dsPublicIP_v4" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-AllocationMethod Static `
-IpAddressVersion IPv4 `
-Sku Standard

$PublicIP_v6 = New-AzPublicIpAddress `
-Name "dsPublicIP_v6" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-AllocationMethod Static `
-IpAddressVersion IPv6 `
-Sku Standard

Para obtener acceso a las máquinas virtuales mediante una conexión RDP, cree una dirección IP pública de IPV4
para las máquinas virtuales con New AzPublicIpAddress.

$RdpPublicIP_1 = New-AzPublicIpAddress `
-Name "RdpPublicIP_1" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-AllocationMethod Static `
-Sku Standard `
-IpAddressVersion IPv4

$RdpPublicIP_2 = New-AzPublicIpAddress `
-Name "RdpPublicIP_2" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-AllocationMethod Static `
-Sku Standard `
-IpAddressVersion IPv4

Creación de Standard Load Balancer

En esta sección, configurará la dirección IP de front-end doble (IPv4 e IPv6) y el grupo de direcciones de back-end
del equilibrador de carga, además de crear una instancia de Standard Load Balancer.
Creación de una dirección IP de front-end
Cree una dirección IP de front-end con New-AzLoadBalancerFrontendIpConfig. En el ejemplo siguiente, se crean
unas configuraciones de IP de front-end IPv4 e IPv6 llamadas dsLbFrontEnd_v4 y dsLbFrontEnd_v6:
 $frontendIPv4 = New-AzLoadBalancerFrontendIpConfig `
-Name "dsLbFrontEnd_v4" `
-PublicIpAddress $PublicIP_v4

$frontendIPv6 = New-AzLoadBalancerFrontendIpConfig `
-Name "dsLbFrontEnd_v6" `
-PublicIpAddress $PublicIP_v6

Configuración del grupo de direcciones de back-end

Cree un grupo de direcciones de back-end con New-AzLoadBalancerBackendAddressPoolConfig. En el resto de
los pasos, las máquinas virtuales se conectan a este grupo back-end. En el ejemplo siguiente, se crean los grupos
de direcciones de back-end dsLbBackEndPool_v4 y dsLbBackEndPool_v6, que van a incluir máquinas virtuales con
configuraciones de NIC IPV4 e IPv6:

$backendPoolv4 = New-AzLoadBalancerBackendAddressPoolConfig `
-Name "dsLbBackEndPool_v4"

$backendPoolv6 = New-AzLoadBalancerBackendAddressPoolConfig `
-Name "dsLbBackEndPool_v6"

Creación de un sondeo de estado

Utilice Add-AzLoadBalancerProbeConfig para crear un sondeo de estado para supervisar el estado de las VM.

$probe = New-AzLoadBalancerProbeConfig -Name MyProbe -Protocol tcp -Port 3389 -IntervalInSeconds 15 -

ProbeCount 2

Creación de una regla de equilibrador de carga

Las reglas de equilibrador de carga se utilizan para definir cómo se distribuye el tráfico a las máquinas virtuales.
Defina la configuración de la IP de front-end para el tráfico entrante y el grupo de IP de back-end para el tráfico
entrante, junto con los puertos de origen y destino requeridos. Para tener la seguridad de que solo reciben tráfico
las máquinas virtuales correctas, también puede definir un sondeo de estado. Los equilibradores de carga básicos
usan un sondeo de IPv4 para evaluar el estado de los puntos de conexión IPv4 e IPv6 de las máquinas virtuales.
Los equilibradores de carga estándar permiten realizar explícitamente sondeos de estado de IPv6.
Cree una regla del equilibrador de carga con Add-AzLoadBalancerRuleConfig. En el ejemplo siguiente, se crean
reglas del equilibrador de carga llamadas dsLBrule_v4 y dsLBrule_v6, y se equilibra el tráfico del puerto TCP 80
dirigido a las configuraciones de IP de front-end IPv4 e IPv6:

$lbrule_v4 = New-AzLoadBalancerRuleConfig `
-Name "dsLBrule_v4" `
-FrontendIpConfiguration $frontendIPv4 `
-BackendAddressPool $backendPoolv4 `
-Protocol Tcp `
-FrontendPort 80 `
-BackendPort 80 `
-probe $probe

$lbrule_v6 = New-AzLoadBalancerRuleConfig `
-Name "dsLBrule_v6" `
-FrontendIpConfiguration $frontendIPv6 `
-BackendAddressPool $backendPoolv6 `
-Protocol Tcp `
-FrontendPort 80 `
-BackendPort 80 `
-probe $probe
Creación de un equilibrador de carga
Cree una instancia de Standard Load Balancer con New-AzLoadBalancer. En el ejemplo siguiente, se crea una
instancia pública de Standard Load Balancer llamada myLoadBalancer mediante las configuraciones de
direcciones IP de front-end IPv4 e IPv6, grupos de servidores back-end y las reglas de equilibrio de carga que
creó en los pasos anteriores:

$lb = New-AzLoadBalancer `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "MyLoadBalancer" `
-Sku "Standard" `
-FrontendIpConfiguration $frontendIPv4,$frontendIPv6 `
-BackendAddressPool $backendPoolv4,$backendPoolv6 `
-LoadBalancingRule $lbrule_v4,$lbrule_v6

Crear recursos de red

Para poder implementar algunas máquinas virtuales y probar el equilibrador, debe crear unos recursos de red
que lo permitan: un conjunto de disponibilidad, un grupo de seguridad de red, una red virtual y varias NIC
virtuales.
Crear un conjunto de disponibilidad
Para mejorar la alta disponibilidad de la aplicación, coloque las máquinas virtuales en un conjunto de
disponibilidad.
Cree un conjunto de disponibilidad con New-AzAvailabilitySet. En el ejemplo siguiente se crea un conjunto de
disponibilidad denominado myAvailabilitySet:

$avset = New-AzAvailabilitySet `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "dsAVset" `
-PlatformFaultDomainCount 2 `
-PlatformUpdateDomainCount 2 `
-Sku aligned

Creación de un grupo de seguridad de red

Cree un grupo de seguridad de red para las reglas que van a controlar la comunicación entrante y saliente de la
red virtual.
Creación de una regla de grupo de seguridad de red para el puerto 3389
Cree una regla de grupo de seguridad de red para permitir conexiones RDP en el puerto 3389 con New-
AzNetworkSecurityRuleConfig.

$rule1 = New-AzNetworkSecurityRuleConfig `
-Name 'myNetworkSecurityGroupRuleRDP' `
-Description 'Allow RDP' `
-Access Allow `
-Protocol Tcp `
-Direction Inbound `
-Priority 100 `
-SourceAddressPrefix * `
-SourcePortRange * `
-DestinationAddressPrefix * `
-DestinationPortRange 3389
Creación de una regla de grupo de seguridad de red para el puerto 80
Cree una regla de grupo de seguridad de red para permitir conexiones de Internet a través del puerto 80 con
New-AzNetworkSecurityRuleConfig.

$rule2 = New-AzNetworkSecurityRuleConfig `
-Name 'myNetworkSecurityGroupRuleHTTP' `
-Description 'Allow HTTP' `
-Access Allow `
-Protocol Tcp `
-Direction Inbound `
-Priority 200 `
-SourceAddressPrefix * `
-SourcePortRange 80 `
-DestinationAddressPrefix * `
-DestinationPortRange 80

Crear un grupo de seguridad de red

Cree un grupo de seguridad de red con New-AzNetworkSecurityGroup.

$nsg = New-AzNetworkSecurityGroup `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "dsNSG1" `
-SecurityRules $rule1,$rule2

Creación de una red virtual

Cree una red virtual con New-AzVirtualNetwork. En el ejemplo siguiente se crea una red virtual denominada con
una subred llamada dsVnet con mySubnet:

# Create dual stack subnet

$subnet = New-AzVirtualNetworkSubnetConfig `
-Name "dsSubnet" `
-AddressPrefix "[Link]/24","[Link]/64"

# Create the virtual network

$vnet = New-AzVirtualNetwork `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "dsVnet" `
-AddressPrefix "[Link]/16","[Link]/48" `
-Subnet $subnet

Creación de tarjetas NIC

Cree NIC virtuales con New-AzNetworkInterface. En el ejemplo siguiente, se crean dos NIC virtuales, ambas con
las configuraciones IPv4 e IPv6. (Una NIC virtual para cada máquina virtual que cree para la aplicación en los
pasos siguientes).
 $Ip4Config=New-AzNetworkInterfaceIpConfig `
-Name dsIp4Config `
-Subnet $[Link][0] `
-PrivateIpAddressVersion IPv4 `
-LoadBalancerBackendAddressPool $backendPoolv4 `
-PublicIpAddress $RdpPublicIP_1

$Ip6Config=New-AzNetworkInterfaceIpConfig `
-Name dsIp6Config `
-Subnet $[Link][0] `
-PrivateIpAddressVersion IPv6 `
-LoadBalancerBackendAddressPool $backendPoolv6

$NIC_1 = New-AzNetworkInterface `
-Name "dsNIC1" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-NetworkSecurityGroupId $[Link] `
-IpConfiguration $Ip4Config,$Ip6Config

$Ip4Config=New-AzNetworkInterfaceIpConfig `
-Name dsIp4Config `
-Subnet $[Link][0] `
-PrivateIpAddressVersion IPv4 `
-LoadBalancerBackendAddressPool $backendPoolv4 `
-PublicIpAddress $RdpPublicIP_2

$NIC_2 = New-AzNetworkInterface `
-Name "dsNIC2" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-NetworkSecurityGroupId $[Link] `
-IpConfiguration $Ip4Config,$Ip6Config

Creación de máquinas virtuales

Establezca un nombre de usuario de administrador y una contraseña para las máquinas virtuales con Get-
Credential:

$cred = get-credential -Message "DUAL STACK VNET SAMPLE: Please enter the Administrator credential to log
into the VMs."

Ahora puede crear las máquinas virtuales con New-AzVM. En el ejemplo siguiente, se crean dos máquinas
virtuales y los componentes de red virtual necesarios, si aún no existen.
 $vmsize = "Standard_A2"
$ImagePublisher = "MicrosoftWindowsServer"
$imageOffer = "WindowsServer"
$imageSKU = "2019-Datacenter"

$vmName= "dsVM1"
$VMconfig1 = New-AzVMConfig -VMName $vmName -VMSize $vmsize -AvailabilitySetId $[Link] 3> $null | Set-
AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent 3> $null | Set-
AzVMSourceImage -PublisherName $ImagePublisher -Offer $imageOffer -Skus $imageSKU -Version "latest" 3> $null
| Set-AzVMOSDisk -Name "$[Link]" -CreateOption fromImage 3> $null | Add-AzVMNetworkInterface -Id
$NIC_1.Id 3> $null
$VM1 = New-AzVM -ResourceGroupName $[Link] -Location $[Link] -VM $VMconfig1

$vmName= "dsVM2"
$VMconfig2 = New-AzVMConfig -VMName $vmName -VMSize $vmsize -AvailabilitySetId $[Link] 3> $null | Set-
AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent 3> $null | Set-
AzVMSourceImage -PublisherName $ImagePublisher -Offer $imageOffer -Skus $imageSKU -Version "latest" 3> $null
| Set-AzVMOSDisk -Name "$[Link]" -CreateOption fromImage 3> $null | Add-AzVMNetworkInterface -Id
$NIC_2.Id 3> $null
$VM2 = New-AzVM -ResourceGroupName $[Link] -Location $[Link] -VM $VMconfig2

Determinación de las direcciones IP de los puntos de conexión IPv4 e

IPv6
Obtenga todos los objetos de interfaz de red del grupo de recursos para resumir las direcciones IP que se utilizan
en esta implementación con get-AzNetworkInterface . Obtenga también las direcciones del front-end del
equilibrador de carga de los puntos de conexión IPv4 e IPv6 con get-AzpublicIpAddress .

$rgName= "dsRG1"
$NICsInRG= get-AzNetworkInterface -resourceGroupName $rgName
write-host `nSummary of IPs in this Deployment:
write-host ******************************************
foreach ($NIC in $NICsInRG) {

$VMid= $[Link]
$VMnamebits= $[Link]("/")
$VMname= $VMnamebits[($[Link]-1)]
write-host `nPrivate IP addresses for $VMname
$IPconfigsInNIC= $[Link]
foreach ($IPconfig in $IPconfigsInNIC) {

$IPaddress= $[Link]
write-host " "$IPaddress
IF ($[Link]) {

$IDbits= ($[Link]).split("/")
$PipName= $IDbits[($[Link]-1)]
$PipObject= get-azPublicIpAddress -name $PipName -resourceGroup $rgName
write-host " "RDP address: $[Link]
}
}
}

write-host `nPublic IP addresses on Load Balancer:

(get-AzpublicIpAddress -resourcegroupname $rgName | where { $_.name -notlike "RdpPublicIP*" }).IpAddress

En la ilustración siguiente, se muestra una salida de ejemplo que muestra las direcciones IPv4 e IPv6 privadas de
las dos máquinas virtuales y las direcciones IP IPv4 e IPv6 de front-end del equilibrador de carga.
Visualización de la red virtual de doble pila IPv6 en Azure Portal
Para ver la red virtual de doble pila IPv6 en Azure Portal, siga estos pasos:
1. En la barra de búsqueda del portal, escriba dsVnet.
2. Seleccione dsVnet cuando aparezca en los resultados de búsqueda. De este modo, se abrirá la página de
información general de la red virtual de doble pila llamada dsVnet. En la red virtual de doble pila, se
muestran las dos NIC con las configuraciones IPv4 e IPv6 en una subred de pila doble denominada dsSubnet.

Limpieza de recursos
Cuando ya no se necesiten, puede usar el comando Remove-AzResourceGroup para quitar el grupo de recursos,
la máquina virtual y todos los recursos relacionados.
 Remove-AzResourceGroup -Name dsRG1

Pasos siguientes
En este artículo, ha creado una instancia de Standard Load Balancer con una configuración IP de front-end doble
(IPv4 e IPv6). También ha creado dos máquinas virtuales que contienen NIC con configuraciones de IP duales
(IPV4 + IPv6) que se agregaron al grupo de back-end del equilibrador de carga. Para más información sobre la
compatibilidad de IPv6 en las redes virtuales de Azure, consulte ¿Qué es IPv6 para Azure Virtual Network?
 Implementación de una aplicación de pila doble IPv6
en Azure Virtual Network: CLI
23/09/2020 • 15 minutes to read • Edit Online

En este artículo, se explica cómo se implementa en Azure una aplicación de pila doble (IPv4 + IPv6) con Standard
Load Balancer que contiene una red virtual de pila doble y una subred de pila doble, una instancia de Standard
Load Balancer con configuraciones de front-end duales (IPv4 + IPv6), VM con NIC que tienen una configuración de
IP dual, reglas de grupo de seguridad de red dual e IP públicas duales.
Si no tiene una suscripción a Azure, cree una cuenta gratuita ahora.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si, en su lugar, decide instalar y usar la CLI de Azure en un entorno local, para esta guía de inicio rápido se necesita
la versión 2.0.49 de la CLI de Azure o una versión posterior. Ejecute az --version para buscar la versión instalada.
Consulte Instalación de la CLI de Azure para obtener información sobre la instalación o actualización.

Crear un grupo de recursos

Para poder generar la red virtual de doble pila, debe crear primero un grupo de recursos con az group create. En el
ejemplo siguiente, se crea un grupo de recursos denominado DsResourceGroup01 en la ubicación eastus:
 az group create \
--name DsResourceGroup01 \
--location eastus

Creación de direcciones IP públicas IPv4 e IPv6 para el equilibrador de

carga
Para obtener acceso los puntos de conexión IPv4 e IPv6 en Internet, necesita direcciones IP públicas IPv4 e IPv6
para el equilibrador de carga. Cree una dirección IP pública con az network public-ip create. En el ejemplo
siguiente, se crean unas direcciones IP públicas IPv4 e IPv6 denominadas dsPublicIP_v4 y dsPublicIP_v6 en el
grupo de recursos DsResourceGroup01:

# Create an IPV4 IP address

az network public-ip create \
--name dsPublicIP_v4 \
--resource-group DsResourceGroup01 \
--location eastus \
--sku STANDARD \
--allocation-method static \
--version IPv4

# Create an IPV6 IP address

az network public-ip create \
--name dsPublicIP_v6 \
--resource-group DsResourceGroup01 \
--location eastus \
--sku STANDARD \
--allocation-method static \
--version IPv6

Creación de direcciones IP públicas para las VM

Para acceder de forma remota a las VM en Internet, necesita las direcciones IP públicas IPv4 de las VM. Cree una
dirección IP pública con az network public-ip create.

az network public-ip create \

--name dsVM0_remote_access \
--resource-group DsResourceGroup01 \
--location eastus \
--sku Standard \
--allocation-method static \
--version IPv4

az network public-ip create \

--name dsVM1_remote_access \
--resource-group DsResourceGroup01 \
--location eastus \
--sku Standard \
--allocation-method static \
--version IPv4

Creación de Standard Load Balancer

En esta sección, configurará la dirección IP de front-end doble (IPv4 e IPv6) y el grupo de direcciones de back-end
del equilibrador de carga, además de crear una instancia de Standard Load Balancer.
Creación de un equilibrador de carga
Cree una instancia de Standard Load Balancer con az network lb create denominada dsLB que incluya un grupo
de servidores front-end llamado dsLbFrontEnd_v4 y un grupo de servidores back-end llamado
dsLbBackEndPool_v4 que esté asociado a la dirección IP pública IPv4 dsPublicIP_v4 que creó en el paso
anterior.

az network lb create \
--name dsLB \
--resource-group DsResourceGroup01 \
--sku Standard \
--location eastus \
--frontend-ip-name dsLbFrontEnd_v4 \
--public-ip-address dsPublicIP_v4 \
--backend-pool-name dsLbBackEndPool_v4

Creación de un servidor front-end IPv6

Cree una dirección IP de front-end IPV6 con az network lb frontend-ip create. En el ejemplo siguiente, se crea una
configuración de direcciones IP de front-end llamada dsLbFrontEnd_v6 y se asocia a la dirección dsPublicIP_v6:

az network lb frontend-ip create \

--lb-name dsLB \
--name dsLbFrontEnd_v6 \
--resource-group DsResourceGroup01 \
--public-ip-address dsPublicIP_v6

Configuración del grupo de direcciones de back-end IPv6

Cree un grupo de direcciones de back-end IPv6 con az network lb address-pool create. En el ejemplo siguiente, se
crean el grupo de direcciones de back-end denominado dsLbBackEndPool_v6 que va a incluir VM con
configuraciones de NIC IPv6:

az network lb address-pool create \

--lb-name dsLB \
--name dsLbBackEndPool_v6 \
--resource-group DsResourceGroup01

Creación de un sondeo de estado

Cree un sondeo de estado con az network lb probe create para supervisar el estado de las máquinas virtuales.

az network lb probe create -g DsResourceGroup01 --lb-name dsLB -n dsProbe --protocol tcp --port 3389

Creación de una regla de equilibrador de carga

Las reglas de equilibrador de carga se utilizan para definir cómo se distribuye el tráfico a las máquinas virtuales.
Defina la configuración de la IP de front-end para el tráfico entrante y el grupo de IP de back-end para el tráfico
entrante, junto con los puertos de origen y destino requeridos.
Cree una regla de equilibrador de carga con az network lb rule create. En el ejemplo siguiente, se crean reglas del
equilibrador de carga llamadas dsLBrule_v4 y dsLBrule_v6, y se equilibra el tráfico del puerto TCP 80 dirigido a las
configuraciones de IP de front-end IPv4 e IPv6:
 az network lb rule create \
--lb-name dsLB \
--name dsLBrule_v4 \
--resource-group DsResourceGroup01 \
--frontend-ip-name dsLbFrontEnd_v4 \
--protocol Tcp \
--frontend-port 80 \
--backend-port 80 \
--probe-name dsProbe \
--backend-pool-name dsLbBackEndPool_v4

az network lb rule create \

--lb-name dsLB \
--name dsLBrule_v6 \
--resource-group DsResourceGroup01 \
--frontend-ip-name dsLbFrontEnd_v6 \
--protocol Tcp \
--frontend-port 80 \
--backend-port 80 \
--probe-name dsProbe \
--backend-pool-name dsLbBackEndPool_v6

Crear recursos de red

Para poder implementar algunas VM, debe crear recursos de red que lo permitan: un conjunto de disponibilidad,
un grupo de seguridad de red, una red virtual y varias NIC virtuales.
Crear un conjunto de disponibilidad
Para mejorar la disponibilidad de la aplicación, coloque las VM en un conjunto de disponibilidad.
Cree el conjunto de disponibilidad con az vm availability-set create. En el ejemplo siguiente se crea un conjunto de
disponibilidad denominado dsAVset:

az vm availability-set create \
--name dsAVset \
--resource-group DsResourceGroup01 \
--location eastus \
--platform-fault-domain-count 2 \
--platform-update-domain-count 2

Creación de un grupo de seguridad de red

Cree un grupo de seguridad de red para las reglas que van a controlar la comunicación entrante y saliente de la
red virtual.
Crear un grupo de seguridad de red
Cree un grupo de seguridad de red con az network nsg create.

az network nsg create \

--name dsNSG1 \
--resource-group DsResourceGroup01 \
--location eastus

Creación de una regla de grupo de seguridad de red para las conexiones entrantes y salientes
Cree una regla de grupo de seguridad de red para permitir las conexiones RDP a través del puerto 3389, la
conexión a Internet a través del puerto 80 y las conexiones salientes con az network nsg rule create.
 # Create inbound rule for port 3389
az network nsg rule create \
--name allowRdpIn \
--nsg-name dsNSG1 \
--resource-group DsResourceGroup01 \
--priority 100 \
--description "Allow Remote Desktop In" \
--access Allow \
--protocol "*" \
--direction Inbound \
--source-address-prefixes "*" \
--source-port-ranges "*" \
--destination-address-prefixes "*" \
--destination-port-ranges 3389

# Create inbound rule for port 80

az network nsg rule create \
--name allowHTTPIn \
--nsg-name dsNSG1 \
--resource-group DsResourceGroup01 \
--priority 200 \
--description "Allow HTTP In" \
--access Allow \
--protocol "*" \
--direction Inbound \
--source-address-prefixes "*" \
--source-port-ranges 80 \
--destination-address-prefixes "*" \
--destination-port-ranges 80

# Create outbound rule

az network nsg rule create \

--name allowAllOut \
--nsg-name dsNSG1 \
--resource-group DsResourceGroup01 \
--priority 300 \
--description "Allow All Out" \
--access Allow \
--protocol "*" \
--direction Outbound \
--source-address-prefixes "*" \
--source-port-ranges "*" \
--destination-address-prefixes "*" \
--destination-port-ranges "*"

Creación de una red virtual

Cree la red virtual con el comando az network vnet create. En el ejemplo siguiente se crea una red virtual
denominada dsVNET con las subredes dsSubNET_v4 y dsSubNET_v6:
 # Create the virtual network
az network vnet create \
--name dsVNET \
--resource-group DsResourceGroup01 \
--location eastus \
--address-prefixes "[Link]/16" "[Link]/48"

# Create a single dual stack subnet

az network vnet subnet create \

--name dsSubNET \
--resource-group DsResourceGroup01 \
--vnet-name dsVNET \
--address-prefixes "[Link]/24" "[Link]/64" \
--network-security-group dsNSG1

Creación de tarjetas NIC

Cree NIC virtuales para cada VM con az network nic create. El ejemplo siguiente crea una NIC virtual para cada
VM. Cada NIC tiene dos configuraciones IP (una configuración IPv4 y una configuración IPv6). Debe crear la
configuración IPV6 con az network nic ip-config create.
 # Create NICs
az network nic create \
--name dsNIC0 \
--resource-group DsResourceGroup01 \
--network-security-group dsNSG1 \
--vnet-name dsVNET \
--subnet dsSubNet \
--private-ip-address-version IPv4 \
--lb-address-pools dsLbBackEndPool_v4 \
--lb-name dsLB \
--public-ip-address dsVM0_remote_access

az network nic create \

--name dsNIC1 \
--resource-group DsResourceGroup01 \
--network-security-group dsNSG1 \
--vnet-name dsVNET \
--subnet dsSubNet \
--private-ip-address-version IPv4 \
--lb-address-pools dsLbBackEndPool_v4 \
--lb-name dsLB \
--public-ip-address dsVM1_remote_access

# Create IPV6 configurations for each NIC

az network nic ip-config create \

--name dsIp6Config_NIC0 \
--nic-name dsNIC0 \
--resource-group DsResourceGroup01 \
--vnet-name dsVNET \
--subnet dsSubNet \
--private-ip-address-version IPv6 \
--lb-address-pools dsLbBackEndPool_v6 \
--lb-name dsLB

az network nic ip-config create \

--name dsIp6Config_NIC1 \
--nic-name dsNIC1 \
--resource-group DsResourceGroup01 \
--vnet-name dsVNET \
--subnet dsSubNet \
--private-ip-address-version IPv6 \
--lb-address-pools dsLbBackEndPool_v6 \
--lb-name dsLB

Creación de máquinas virtuales

Cree las máquinas virtuales con az vm create. En el ejemplo siguiente, se crean dos máquinas virtuales y los
componentes de red virtual necesarios, si aún no existen.
Cree la máquina virtual dsVM0 de la siguiente manera:

az vm create \
--name dsVM0 \
--resource-group DsResourceGroup01 \
--nics dsNIC0 \
--size Standard_A2 \
--availability-set dsAVset \
--image MicrosoftWindowsServer:WindowsServer:2019-Datacenter:latest

Cree la máquina virtual dsVM1 de la siguiente manera:

 az vm create \
--name dsVM1 \
--resource-group DsResourceGroup01 \
--nics dsNIC1 \
--size Standard_A2 \
--availability-set dsAVset \
--image MicrosoftWindowsServer:WindowsServer:2019-Datacenter:latest

Visualización de la red virtual de doble pila IPv6 en Azure Portal

Para ver la red virtual de doble pila IPv6 en Azure Portal, siga estos pasos:
1. En la barra de búsqueda del portal, escriba dsVnet.
2. Cuando aparezca la opción myVir tualNetwork en los resultados de la búsqueda, selecciónela. De este modo,
se abrirá la página de información general de la red virtual de doble pila llamada dsVnet. En la red virtual
de doble pila, se muestran las dos NIC con las configuraciones IPv4 e IPv6 en una subred de pila doble
denominada dsSubnet.

Limpieza de recursos
Cuando ya no se necesiten, puede usar el comando az group delete para quitar el grupo de recursos, la máquina
virtual y todos los recursos relacionados.

az group delete --name DsResourceGroup01

Pasos siguientes
En este artículo, ha creado una instancia de Standard Load Balancer con una configuración IP de front-end doble
(IPv4 e IPv6). También ha creado dos máquinas virtuales que contienen NIC con configuraciones de IP duales
(IPV4 + IPv6) que se agregaron al grupo de back-end del equilibrador de carga. Para más información sobre la
compatibilidad de IPv6 en las redes virtuales de Azure, consulte ¿Qué es IPv6 para Azure Virtual Network?
 Implementación de una aplicación de pila doble IPv6
en Azure Virtual Network: plantilla
23/09/2020 • 3 minutes to read • Edit Online

En este artículo se proporciona una lista de tareas de configuración de IPv6 con la parte de la plantilla de VM de
Azure Resource Manager a la que se aplica. Use la plantilla que se describe en este artículo para implementar en
Azure una aplicación de pila doble (IPv4 + IPv6) con Standard Load Balancer que incluya una red virtual de pila
doble con subredes IPv4 e IPv6, una instancia de Standard Load Balancer con configuraciones de front-end duales
(IPv4 + IPv6), VM con NIC que tengan una configuración de IP dual, un grupo de seguridad de red e IP públicas.

Configuraciones necesarias
Busque las secciones de la plantilla para ver dónde se deben producir.
Elemento addressSpace de IPv6 para la red virtual
Sección de plantilla que se va a agregar:

"addressSpace": {
"addressPrefixes": [
"[variables('vnetv4AddressRange')]",
"[variables('vnetv6AddressRange')]"

Subred de IPv6 en el elemento addressSpace de la red virtual IPv6

Sección de plantilla que se va a agregar:

{
"name": "V6Subnet",
"properties": {
"addressPrefix": "[variables('subnetv6AddressRange')]"
}

Configuración de IPv6 para la NIC

Sección de plantilla que se va a agregar:

{
"name": "ipconfig-v6",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"privateIPAddressVersion":"IPv6",
"subnet": {
"id": "[variables('v6-subnet-id')]"
},
"loadBalancerBackendAddressPools": [
{
"id": "
[concat(resourceId('[Link]/loadBalancers','loadBalancer'),'/backendAddressPools/LBBAP-v6')]"
}

Reglas del grupo de seguridad de red (NSG ) de IPv6

 {
"name": "default-allow-rdp",
"properties": {
"description": "Allow RDP",
"protocol": "Tcp",
"sourcePortRange": "33819-33829",
"destinationPortRange": "5000-6000",
"sourceAddressPrefix": "[Link]/64",
"destinationAddressPrefix": "[Link]/64",
"access": "Allow",
"priority": 1003,
"direction": "Inbound"
}

Configuración condicional
Si usa un dispositivo de red virtual, agregue rutas IPv6 en la tabla de rutas. En caso contrario, esta configuración
es opcional.

{
"type": "[Link]/routeTables",
"name": "v6route",
"apiVersion": "[variables('ApiVersion')]",
"location": "[resourceGroup().location]",
"properties": {
"routes": [
{
"name": "v6route",
"properties": {
"addressPrefix": "[Link]/64",
"nextHopType": "VirtualAppliance",
"nextHopIpAddress": "[Link]"
}

Configuración opcional
Acceso a Internet de IPv6 para la red virtual

{
"name": "LBFE-v6",
"properties": {
"publicIPAddress": {
"id": "[resourceId('[Link]/publicIPAddresses','lbpublicip-v6')]"
}

Direcciones IP públicas IPv6

{
"apiVersion": "[variables('ApiVersion')]",
"type": "[Link]/publicIPAddresses",
"name": "lbpublicip-v6",
"location": "[resourceGroup().location]",
"sku": {
"name": "Standard"
},
"properties": {
"publicIPAllocationMethod": "Static",
"publicIPAddressVersion": "IPv6"
}
Front-end IPv6 para Load Balancer

{
"name": "LBFE-v6",
"properties": {
"publicIPAddress": {
"id": "[resourceId('[Link]/publicIPAddresses','lbpublicip-v6')]"
}

Grupo de direcciones de back-end IPv6 para Load Balancer

"backendAddressPool": {
"id": "[concat(resourceId('[Link]/loadBalancers', 'loadBalancer'),
'/backendAddressPools/LBBAP-v6')]"
},
"protocol": "Tcp",
"frontendPort": 8080,
"backendPort": 8080
},
"name": "lbrule-v6"

Reglas del equilibrador de carga de IPv6 para asociar puertos de entrada y de salida

{
"name": "ipconfig-v6",
"properties": {
"privateIPAllocationMethod": "Dynamic",
"privateIPAddressVersion":"IPv6",
"subnet": {
"id": "[variables('v6-subnet-id')]"
},
"loadBalancerBackendAddressPools": [
{
"id": "
[concat(resourceId('[Link]/loadBalancers','loadBalancer'),'/backendAddressPools/LBBAP-v6')]"
}

Ejemplo de JSON de plantilla de VM

Para implementar una aplicación de pila doble IPv6 en Azure Virtual Network mediante una plantilla de Azure
Resource Manager, vea la plantilla de ejemplo aquí.

Pasos siguientes
Puede encontrar detalles sobre precios de direcciones IP públicas, ancho de banda de red o Load Balancer.
 Implementación de una aplicación de doble pila IPv6
con equilibrador de carga interno estándar en Azure:
PowerShell (versión preliminar)
23/09/2020 • 17 minutes to read • Edit Online

En este artículo se explica cómo se implementa en Azure una aplicación de doble pila (IPv4 + IPv6) que contiene
una red virtual de pila doble y una subred, un equilibrador de carga interno estándar con configuraciones de front-
end dobles (IPv4 + IPv6), máquinas virtuales con NIC que tienen una configuración de IP doble, un grupo de
seguridad de red e IP públicas.
El procedimiento para crear un equilibrador de carga interno compatible con IPv6 es casi idéntico al del
equilibrador de carga compatible con IPv6 orientado a Internet que se describe aquí. Las únicas diferencias en la
creación de un equilibrador de carga interno se encuentran en la configuración de front-end, tal como se muestra
en el ejemplo de PowerShell siguiente:

$frontendIPv6 = New-AzLoadBalancerFrontendIpConfig `
-Name "dsLbFrontEnd_v6" `
-PrivateIpAddress "[Link]" `
-PrivateIpAddressVersion "IPv6" `
-Subnet $DsSubnet

Los cambios que convierten la anterior en una configuración de front-end de equilibrador de carga interno son:
El PrivateIpAddressVersion se especifica como "IPv6"
El argumento -PublicIpAddress se ha omitido o se ha reemplazado por -PrivateIpAddress . Tenga en cuenta
que la dirección privada debe estar en el intervalo del espacio IP de la subred en el que se implemente el
equilibrador de carga interno. Si se omite una -PrivateIpAddress estática, se seleccionará la siguiente dirección
IPv6 libre de la subred en la que se haya implementado el equilibrador de carga interno.
La subred de doble pila en la que se implementará el equilibrador de carga interno se especifica con un
argumento -Subnet o -SubnetId .

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.
 O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar PowerShell de forma local, la versión del módulo de Azure PowerShell que necesita este
artículo es la 6.9.0 u otra posterior. Ejecute Get-Module -ListAvailable Az para buscar la versión instalada. Si
necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se ejecuta localmente,
también debe ejecutar Connect-AzAccount para crear una conexión con Azure.

Prerrequisitos
Para poder implementar una aplicación de pila doble en Azure, primero debe configurar la suscripción de esta
característica en vista previa (GB) utilizando el siguiente procedimiento de Azure PowerShell:
Regístrese del modo siguiente:

Register-AzProviderFeature -FeatureName AllowIPv6VirtualNetwork -ProviderNamespace [Link]

Register-AzProviderFeature -FeatureName AllowIPv6CAOnStandardLB -ProviderNamespace [Link]

Se tarda hasta 30 minutos en completar el registro de características. Puede comprobar el estado del registro
mediante la ejecución del siguiente comando de Azure PowerShell: Compruebe en el registro del modo siguiente:

Get-AzProviderFeature -FeatureName AllowIPv6VirtualNetwork -ProviderNamespace [Link]

Get-AzProviderFeature -FeatureName AllowIPv6CAOnStandardLB -ProviderNamespace [Link]

Una vez completado el registro, ejecute el siguiente comando:

Register-AzResourceProvider -ProviderNamespace [Link]

Crear un grupo de recursos

Para poder generar la red virtual de doble pila, debe crear primero un grupo de recursos con New-
AzResourceGroup. En el ejemplo siguiente se crea un grupo de recursos llamado dsStd_ILB_RG en la ubicación Este
de EE. UU. :

$rg = New-AzResourceGroup `
-ResourceGroupName "dsStd_ILB_RG" `
-Location "east us"

Creación de direcciones IP públicas IPv4 e IPv6

Para acceder a las máquinas virtuales desde Internet, necesita direcciones IP públicas IPv4 e IPv6 para las
máquinas virtuales. Cree las direcciones IP públicas con New-AzPublicIpAddress. En el ejemplo siguiente se crean
unas direcciones IP públicas IPv4 e IPv6 denominadas RdpPublicIP_1 y RdpPublicIP_2 en el grupo de recursos
dsStd_ILB_RG:

$RdpPublicIP_1 = New-AzPublicIpAddress `
-Name "RdpPublicIP_1" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-AllocationMethod Static `
-IpAddressVersion IPv4 `
-sku Standard

$RdpPublicIP_2 = New-AzPublicIpAddress `
-Name "RdpPublicIP_2" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-AllocationMethod Static `
-IpAddressVersion IPv4 `
-sku Standard

Creación de la red virtual y la subred

Cree una red virtual mediante New-AzVirtualNetwork con doble pila y una configuración de subred mediante
New-AzVirtualNetworkSubnetConfig. En el ejemplo siguiente se crea una red virtual denominada dsVnet con
dsSubnet.

# Create dual stack subnet config

$DsSubnet = New-AzVirtualNetworkSubnetConfig `
-Name "dsSubnet" `
-AddressPrefix "[Link]/24","[Link]/64"

# Create the virtual network

$vnet = New-AzVirtualNetwork `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "dsVnet" `
-AddressPrefix "[Link]/16","[Link]/48" `
-Subnet $DsSubnet

#Refresh the fully populated subnet for use in load balancer frontend configuration
$DsSubnet = get-AzVirtualNetworkSubnetconfig -name dsSubnet -VirtualNetwork $vnet

Creación de Standard Load Balancer

En esta sección, configurará la dirección IP de front-end doble (IPv4 e IPv6) y el grupo de direcciones de back-end
del equilibrador de carga, además de crear una instancia de Standard Load Balancer.
Creación de una dirección IP de front-end
Cree una dirección IP de front-end con New-AzLoadBalancerFrontendIpConfig. En el ejemplo siguiente, se crean
unas configuraciones de IP de front-end IPv4 e IPv6 llamadas dsLbFrontEnd_v4 y dsLbFrontEnd_v6:
 $frontendIPv4 = New-AzLoadBalancerFrontendIpConfig `
-Name "dsLbFrontEnd_v4" `
-PrivateIpAddress "[Link]" `
-PrivateIpAddressVersion "IPv4" `
-Subnet $DsSubnet

$frontendIPv6 = New-AzLoadBalancerFrontendIpConfig `
-Name "dsLbFrontEnd_v6" `
-PrivateIpAddress "[Link]" `
-PrivateIpAddressVersion "IPv6" `
-Subnet $DsSubnet

Configuración del grupo de direcciones de back-end

Cree un grupo de direcciones de back-end con New-AzLoadBalancerBackendAddressPoolConfig. En el resto de los
pasos, las máquinas virtuales se conectan a este grupo back-end. En el ejemplo siguiente, se crean los grupos de
direcciones de back-end dsLbBackEndPool_v4 y dsLbBackEndPool_v6, que van a incluir máquinas virtuales con
configuraciones de NIC IPV4 e IPv6:

$backendPoolv4 = New-AzLoadBalancerBackendAddressPoolConfig -Name "dsLbBackEndPool_v4"

$backendPoolv6 = New-AzLoadBalancerBackendAddressPoolConfig -Name "dsLbBackEndPool_v6"

Creación de una regla de equilibrador de carga

Las reglas de equilibrador de carga se utilizan para definir cómo se distribuye el tráfico a las máquinas virtuales.
Defina la configuración de la IP de front-end para el tráfico entrante y el grupo de IP de back-end para el tráfico
entrante, junto con los puertos de origen y destino requeridos. Para tener la seguridad de que solo reciben tráfico
las máquinas virtuales correctas, también puede definir un sondeo de estado. Los equilibradores de carga básicos
usan un sondeo de IPv4 para evaluar el estado de los puntos de conexión IPv4 e IPv6 de las máquinas virtuales.
Los equilibradores de carga estándar permiten realizar explícitamente sondeos de estado de IPv6.
Cree una regla del equilibrador de carga con Add-AzLoadBalancerRuleConfig. En el ejemplo siguiente, se crean
reglas del equilibrador de carga llamadas dsLBrule_v4 y dsLBrule_v6, y se equilibra el tráfico del puerto TCP 80
dirigido a las configuraciones de IP de front-end IPv4 e IPv6:

$lbrule_v4 = New-AzLoadBalancerRuleConfig `
-Name "dsLBrule_v4" `
-FrontendIpConfiguration $frontendIPv4 `
-BackendAddressPool $backendPoolv4 `
-Protocol Tcp `
-FrontendPort 80 `
-BackendPort 80

$lbrule_v6 = New-AzLoadBalancerRuleConfig `
-Name "dsLBrule_v6" `
-FrontendIpConfiguration $frontendIPv6 `
-BackendAddressPool $backendPoolv6 `
-Protocol Tcp `
-FrontendPort 80 `
-BackendPort 80

Creación de un equilibrador de carga

Cree una instancia de Standard Load Balancer con New-AzLoadBalancer. En el ejemplo siguiente se crea un
equilibrador de carga público estándar denominado myInternalLoadBalancer mediante las configuraciones de
direcciones IP de front-end IPv4 e IPv6, grupos de servidores back-end y las reglas de equilibrio de carga que creó
en los pasos anteriores:
 $lb = New-AzLoadBalancer `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "MyInternalLoadBalancer" `
-Sku "Standard" `
-FrontendIpConfiguration $frontendIPv4,$frontendIPv6 `
-BackendAddressPool $backendPoolv4,$backendPoolv6 `
-LoadBalancingRule $lbrule_v4,$lbrule_v6

Crear recursos de red

Para poder implementar algunas máquinas virtuales y probar el equilibrador, debe crear unos recursos de red que
lo permitan: un conjunto de disponibilidad, un grupo de seguridad de red y varias NIC virtuales.
Crear un conjunto de disponibilidad
Para mejorar la alta disponibilidad de la aplicación, coloque las máquinas virtuales en un conjunto de
disponibilidad.
Cree un conjunto de disponibilidad con New-AzAvailabilitySet. En el ejemplo siguiente se crea un conjunto de
disponibilidad denominado dsAVset:

$avset = New-AzAvailabilitySet `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "dsAVset" `
-PlatformFaultDomainCount 2 `
-PlatformUpdateDomainCount 2 `
-Sku aligned

Creación de un grupo de seguridad de red

Cree un grupo de seguridad de red para las reglas que van a controlar la comunicación entrante y saliente de la
red virtual.
Creación de una regla de grupo de seguridad de red para el puerto 3389
Cree una regla de grupo de seguridad de red para permitir conexiones RDP en el puerto 3389 con New-
AzNetworkSecurityRuleConfig.

$rule1 = New-AzNetworkSecurityRuleConfig `
-Name 'myNetworkSecurityGroupRuleRDP' `
-Description 'Allow RDP' `
-Access Allow `
-Protocol Tcp `
-Direction Inbound `
-Priority 100 `
-SourceAddressPrefix * `
-SourcePortRange * `
-DestinationAddressPrefix * `
-DestinationPortRange 3389

Creación de una regla de grupo de seguridad de red para el puerto 80

Cree una regla de grupo de seguridad de red para permitir conexiones de Internet a través del puerto 80 con New-
AzNetworkSecurityRuleConfig.
 $rule2 = New-AzNetworkSecurityRuleConfig `
-Name 'myNetworkSecurityGroupRuleHTTP' `
-Description 'Allow HTTP' `
-Access Allow `
-Protocol Tcp `
-Direction Inbound `
-Priority 200 `
-SourceAddressPrefix * `
-SourcePortRange 80 `
-DestinationAddressPrefix * `
-DestinationPortRange 80

Crear un grupo de seguridad de red

Cree un grupo de seguridad de red con New-AzNetworkSecurityGroup.

$nsg = New-AzNetworkSecurityGroup `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "dsNSG1" `
-SecurityRules $rule1,$rule2

Creación de tarjetas NIC

Cree NIC virtuales con New-AzNetworkInterface. En el ejemplo siguiente, se crean dos NIC virtuales, ambas con las
configuraciones IPv4 e IPv6. (Una NIC virtual para cada máquina virtual que cree para la aplicación en los pasos
siguientes).
 # Create the IPv4 configuration for NIC 1
$Ip4Config=New-AzNetworkInterfaceIpConfig `
-Name dsIp4Config `
-Subnet $[Link][0] `
-PrivateIpAddressVersion IPv4 `
-LoadBalancerBackendAddressPool $backendPoolv4 `
-PublicIpAddress $RdpPublicIP_1

# Create the IPv6 configuration

$Ip6Config=New-AzNetworkInterfaceIpConfig `
-Name dsIp6Config `
-Subnet $[Link][0] `
-PrivateIpAddressVersion IPv6 `
-LoadBalancerBackendAddressPool $backendPoolv6

# Create NIC 1
$NIC_1 = New-AzNetworkInterface `
-Name "dsNIC1" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-NetworkSecurityGroupId $[Link] `
-IpConfiguration $Ip4Config,$Ip6Config

# Create the IPv4 configuration for NIC 2

$Ip4Config=New-AzNetworkInterfaceIpConfig `
-Name dsIp4Config `
-Subnet $[Link][0] `
-PrivateIpAddressVersion IPv4 `
-LoadBalancerBackendAddressPool $backendPoolv4 `
-PublicIpAddress $RdpPublicIP_2

# Create NIC 2 reusing the IPv6 configuration from NIC 1

$NIC_2 = New-AzNetworkInterface `
-Name "dsNIC2" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-NetworkSecurityGroupId $[Link] `
-IpConfiguration $Ip4Config,$Ip6Config

Creación de máquinas virtuales

Establezca un nombre de usuario de administrador y una contraseña para las máquinas virtuales con Get-
Credential:

$cred = get-credential -Message "DUAL STACK VNET SAMPLE: Please enter the Administrator credential to log
into the VM's"

Ahora puede crear las máquinas virtuales con New-AzVM. En el ejemplo siguiente, se crean dos máquinas
virtuales y los componentes de red virtual necesarios, si aún no existen.
 $vmsize = "Standard_A2"
$ImagePublisher = "MicrosoftWindowsServer"
$imageOffer = "WindowsServer"
$imageSKU = "2019-Datacenter"

$vmName= "dsVM1"
$VMconfig1 = New-AzVMConfig -VMName $vmName -VMSize $vmsize -AvailabilitySetId $[Link] 3> $null | Set-
AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent 3> $null | Set-
AzVMSourceImage -PublisherName $ImagePublisher -Offer $imageOffer -Skus $imageSKU -Version "latest" 3> $null |
Set-AzVMOSDisk -Name "$[Link]" -CreateOption fromImage 3> $null | Add-AzVMNetworkInterface -Id $NIC_1.Id
3> $null
$VM1 = New-AzVM -ResourceGroupName $[Link] -Location $[Link] -VM $VMconfig1

$vmName= "dsVM2"
$VMconfig2 = New-AzVMConfig -VMName $vmName -VMSize $vmsize -AvailabilitySetId $[Link] 3> $null | Set-
AzVMOperatingSystem -Windows -ComputerName $vmName -Credential $cred -ProvisionVMAgent 3> $null | Set-
AzVMSourceImage -PublisherName $ImagePublisher -Offer $imageOffer -Skus $imageSKU -Version "latest" 3> $null |
Set-AzVMOSDisk -Name "$[Link]" -CreateOption fromImage 3> $null | Add-AzVMNetworkInterface -Id $NIC_2.Id
3> $null
$VM2 = New-AzVM -ResourceGroupName $[Link] -Location $[Link] -VM $VMconfig2

Visualización de la red virtual de doble pila IPv6 en Azure Portal

Para ver la red virtual de doble pila IPv6 en Azure Portal, siga estos pasos:
1. En la barra de búsqueda del portal, escriba dsVnet.
2. Seleccione dsVnet cuando aparezca en los resultados de búsqueda. De este modo, se abrirá la página de
información general de la red virtual de doble pila llamada dsVnet. En la red virtual de doble pila, se
muestran las dos NIC con las configuraciones IPv4 e IPv6 en una subred de pila doble denominada dsSubnet.

NOTE
En esta versión preliminar, la dirección IPv6 de la red virtual de Azure está disponible en Azure Portal en modo de solo
lectura.
Limpieza de recursos
Cuando ya no se necesiten, puede usar el comando Remove-AzResourceGroup para quitar el grupo de recursos, la
máquina virtual y todos los recursos relacionados.

Remove-AzResourceGroup -Name dsStd_ILB_RG

Pasos siguientes
En este artículo, ha creado una instancia de Standard Load Balancer con una configuración IP de front-end doble
(IPv4 e IPv6). También ha creado dos máquinas virtuales que contienen NIC con configuraciones de IP duales (IPV4
+ IPv6) que se agregaron al grupo de back-end del equilibrador de carga. Para más información sobre la
compatibilidad de IPv6 en las redes virtuales de Azure, consulte ¿Qué es IPv6 para Azure Virtual Network?
 Implementación de conjuntos de escalado de
máquinas virtuales con IPv6 en Azure
23/09/2020 • 2 minutes to read • Edit Online

En este artículo se muestra cómo implementar un conjunto de escalado de máquinas virtuales de pila doble (IPv4
+ IPv6) con un equilibrador de carga externo de pila doble en una red virtual de Azure. El proceso para crear un
conjunto de escalado de máquinas virtuales compatible con IPv6 es casi idéntico al de crear máquinas virtuales
individuales que se describe aquí. Empezará con los pasos que son similares a los descritos para las máquinas
virtuales individuales:
1. Crear direcciones IP públicas IPv4 e IPv6
2. Crear un equilibrador de carga de pila doble
3. Crear reglas del grupo de seguridad de red (NSG)
El único paso que no es igual en las máquinas virtuales individuales es la creación de la configuración de interfaz
de red (NIC) que usa el recurso del conjunto de escalado de máquinas virtuales
networkProfile/networkInterfaceConfigurations. La estructura JSON es similar a la del objeto
[Link]/networkInterfaces que se usa para las máquinas virtuales individuales, pero se agrega la NIC y
la configuración de IpConfiguration de IPv4 como interfaz principal mediante el atributo "primar y": true , tal como
se aprecia en el ejemplo siguiente:
 "networkProfile": {
"networkInterfaceConfigurations": [
{
"name": "[variables('nicName')]",
"properties": {
"primary": true,
"networkSecurityGroup": {
"id": "[resourceId('[Link]/networkSecurityGroups','VmssNsg')]"
},
"ipConfigurations": [
{
"name": "[variables('ipConfigName')]",
"properties": {
"primary": true,
"subnet": {
"id": "[resourceId('[Link]/virtualNetworks/subnets',
'MyvirtualNetwork','Mysubnet')]"
},
"privateIPAddressVersion":"IPv4",
"publicipaddressconfiguration": {
"name": "pub1",
"properties": {
"idleTimeoutInMinutes": 15
}
},
"loadBalancerBackendAddressPools": [
{
"id": "[resourceId('[Link]/loadBalancers/backendAddressPools',
'loadBalancer', 'bePool'))]"
}
],
"loadBalancerInboundNatPools": [
{
"id": "[resourceId('[Link]/loadBalancers/inboundNatPools',
'loadBalancer', 'natPool')]"
}
]
}
},
{
"name": "[variables('ipConfigNameV6')]",
"properties": {
"subnet": {
"id": "
[resourceId('[Link]/virtualNetworks/subnets','MyvirtualNetwork','Mysubnet')]"
},
"privateIPAddressVersion":"IPv6",
"loadBalancerBackendAddressPools": [
{
"id": "[resourceId('[Link]/loadBalancers/backendAddressPools',
'loadBalancer','bePoolv6')]"
}
],
}
}
]
}
}
]
}

Estructura JSON de ejemplo de la plantilla de conjunto de escalado de

máquinas virtuales
Para implementar un conjunto de escalado de máquinas virtuales de pila doble (IPv4 + IPv6) con un equilibrador
de carga externo de pila doble y la plantilla de ejemplo de vista de red virtual, consulte aquí.

Pasos siguientes
Para más información sobre la compatibilidad con IPv6 en las redes virtuales de Azure, consulte ¿Qué es IPv6 para
Azure Virtual Network?
 Reserva de un prefijo de dirección IPv6 pública
23/09/2020 • 3 minutes to read • Edit Online

IPv6 para Azure Virtual Network (VNet) le permite hospedar aplicaciones en Azure con la conectividad IPv6 e IPv4,
tanto en una red virtual como hacia y desde Internet. Además de reservar direcciones IPv6 individuales, puede
reservar intervalos contiguos de direcciones IPv6 de Azure (conocidos como prefijo IP) para su uso. En este
artículo se describe cómo crear IP públicas IPv6 e intervalos de direcciones mediante Azure PowerShell y la CLI de
Azure.

Creación de una IP pública IPv6 reservada única

Uso de Azure PowerShell
Puede crear una IP pública IPv6 reservada (estática) única con Azure PowerShell con New-AzPublicIpAddress,
como se indica a continuación:

$myOwnIPv6Address = New-AzPublicIpAddress `
-name PIPv6_WestUS `
-ResourceGroup MyRG `
-Location "West US" `
-Sku Standard `
-allocationMethod static `
-IpAddressVersion IPv6

Uso de la CLI de Azure

Puede crear una IP pública IPv6 reservada (estática) única con la CLI de Azure con az network public-ip create,
como se indica a continuación:

az network public-ip create \

--name dsPublicIP_v6 \
--resource-group UpgradeInPlace_CLI_RG1 \
--location WestUS \
--sku Standard \
--allocation-method static \
--version IPv6

Creación de un prefijo IPv6 reservado (intervalo)

Para reservar un prefijo IPv6, agregue la familia de direcciones IP de IPv6 al mismo comando que se usa para crear
prefijos IPv4. Los comandos siguientes crean un prefijo de tamaño /125 (8 direcciones IPv6).
Uso de Azure PowerShell
Puede crear una dirección IPv6 pública con la CLI de Azure con az network public-ip create, como se indica a
continuación:
 $myOwnIPv6Prefix = New-AzPublicIpPrefix `
-name IPv6PrefixWestUS `
-ResourceGroupName MyRG `
-Location "West US" `
-Sku Standard `
-IpAddressVersion IPv6 `
-PrefixLength 125

Uso de la CLI de Azure

Puede crear una dirección IPv6 pública con la CLI de Azure como se indica a continuación:

az network public-ip prefix create \

--name IPv6PrefixWestUS \
--resource-group MyRG \
--location WestUS \
--version IPv6 \
--length 125

Asignación de una IP pública desde un prefijo IPv6 reservado

Uso de Azure PowerShell
Puede crear una IP pública IPv6 estática a partir de un prefijo reservado si agrega el argumento -PublicIpPrefix
al crear la IP pública mediante Azure PowerShell. En el ejemplo siguiente se presupone que se creó un prefijo y se
almacenó en una variable de PowerShell denominada: $myOwnIPv 6Prefix.

$MyIPv6PublicIPFromMyReservedPrefix = New-AzPublicIpAddress \
-name PIPv6_fromPrefix `
-ResourceGroup DsStdLb04 `
-Location "West Central US" `
-Sku Standard `
-allocationMethod static `
-IpAddressVersion IPv6 `
-PublicIpPrefix $myOwnIPv6Prefix

Uso de la CLI de Azure

En el ejemplo siguiente se presupone que se creó un prefijo y se almacenó en una variable de CLI denominada:
IPv6PrefixWestUS .

az network public-ip create \

--name dsPublicIP_v6 \
--resource-group UpgradeInPlace_CLI_RG1 \
--location WestUS \
--sku Standard \
--allocation-method static \
--version IPv6 \
--public-ip-prefix IPv6PrefixWestUS

Pasos siguientes
Obtenga más información sobre el prefijo de dirección IPv6.
Obtenga más información sobre las direcciones IPv6.
 Inicio rápido: Creación de una dirección IP pública
mediante Azure Portal
23/09/2020 • 6 minutes to read • Edit Online

En este artículo se muestra cómo crear un recurso de dirección IP pública mediante Azure Portal. Para más
información sobre los recursos que se pueden asociar, la diferencia entre la SKU básica y estándar y otra
información relacionada, consulte Direcciones IP públicas. En este ejemplo, nos centraremos solo en las direcciones
IPv4. Para más información sobre las direcciones IPv6, consulte IPv6 para la red virtual de Azure.
SKU estándar : uso de zonas
SKU estándar : sin zonas
SKU básica
Use los pasos siguientes para crear una dirección IP pública estándar con redundancia de zona denominada
myStandardZRPublicIP .
1. Inicie sesión en Azure Portal.
2. Seleccione Crear un recurso .
3. En el cuadro de búsqueda, escriba Dirección IP pública.
4. En los resultados de la búsqueda, escriba Dirección IP pública . A continuación, en la página Dirección IP
pública seleccione Crear .
5. En la página Crear dirección IP pública , escriba o seleccione la siguiente información:

C O N F IGURA C IÓ N VA L UE

Versión de la dirección IP Seleccione IPv4

SKU Seleccione Estándar .

Nombre Escriba myStandardZRPublicIP

Asignación de dirección IP Tenga en cuenta que se bloqueará como "estática".

Tiempo de espera de inactividad (minutos) Deje el valor en 4.

Etiqueta de nombre DNS Deje el valor en blanco.

Subscription Seleccione su suscripción.

Resource group Seleccione Crear nuevo , escriba myResourceGroup y

seleccione Aceptar .

Location Seleccione Este de EE. UU. 2 .

Zona de disponibilidad Seleccione Con redundancia de zona o elija una zona

específica (consulte la nota siguiente).
Tenga en cuenta que estas opciones solo son selecciones válidas en regiones con zonas de disponibilidad. (También
puede seleccionar una zona específica en estas regiones, aunque no sea resistente a errores de zona).

Información adicional
Para más información sobre los campos individuales enumerados anteriormente, consulte Administración de
direcciones IP públicas.

Pasos siguientes
Asocie una dirección IP pública a una máquina virtual.
Obtenga más información acerca de las direcciones IP públicas en Azure.
Obtenga más información acerca de toda la configuración de direcciones IP públicas.
 Inicio rápido: Creación de una dirección IP pública
mediante Azure PowerShell
23/09/2020 • 7 minutes to read • Edit Online

En este artículo se muestra cómo crear un recurso de dirección IP pública mediante Azure PowerShell. Para más
información sobre los recursos que se pueden asociar, la diferencia entre la SKU básica y estándar y otra
información relacionada, consulte Direcciones IP públicas. En este ejemplo, nos centraremos solo en las direcciones
IPv4. Para más información sobre las direcciones IPv6, consulte IPv6 para la red virtual de Azure.

Requisitos previos
Azure PowerShell instalado localmente o Azure Cloud Shell

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar PowerShell de forma local, para realizar los pasos de este artículo necesita la versión 5.4.1
del módulo de Azure PowerShell o cualquier versión posterior. Ejecute Get-Module -ListAvailable Az para buscar la
versión instalada. Si necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se
ejecuta localmente, también debe ejecutar Connect-AzAccount para crear una conexión con Azure.

Crear un grupo de recursos

Un grupo de recursos de Azure es un contenedor lógico en el que se implementan y se administran los recursos de
Azure.
Cree un grupo de recursos con New-AzResourceGroup con el nombre myResourceGroup en la ubicación
eastus2 .

## Variables for the command ##

$rg = 'myResourceGroup'
$loc = 'eastus2'

New-AzResourceGroup -Name $rg -Location $loc

SKU estándar : uso de zonas

SKU estándar : sin zonas
SKU básica

NOTE
El siguiente comando funciona con la versión de API 2020-08-01 o posterior. Para más información sobre la versión de API
que se usa actualmente, consulte Tipos y proveedores de recursos.

Use New-AzPublicIpAddress para crear una dirección IP pública estándar con redundancia de zona llamada
myStandardZRPublicIP en myResourceGroup .

## Variables for the command ##

$rg = 'myResourceGroup'
$loc = 'eastus2'
$pubIP = 'myStandardZRPublicIP'
$sku = 'Standard'
$alloc = 'Static'
$zone = 1,2,3

New-AzPublicIpAddress -ResourceGroupName $rg -Name $pubIP -Location $loc -AllocationMethod $alloc -SKU $sku -
zone $zone

IMPORTANT
En el caso de versiones de la API anteriores a 2020-08-01, ejecute el comando anterior sin especificar un parámetro de zona
para crear una dirección IP con redundancia de zona.

Para crear una dirección IP pública estándar de zona en la Zona 2 llamada myStandardZonalPublicIP en
myResourceGroup , use el siguiente comando:
 ## Variables for the command ##
$rg = 'myResourceGroup'
$loc = 'eastus2'
$pubIP = 'myStandardZonalPublicIP'
$sku = 'Standard'
$alloc = 'Static'
$zone = 2

New-AzPublicIpAddress -ResourceGroupName $rg -Name $pubIP -Location $loc -AllocationMethod $alloc -SKU $sku -
zone $zone

Tenga en cuenta que las opciones anteriores para zonas son solo selecciones válidas en regiones con Availability
Zones.

Información adicional
Para más información sobre las variables individuales enumeradas anteriormente, consulte Administración de
direcciones IP públicas.

Pasos siguientes
Asocie una dirección IP pública a una máquina virtual.
Obtenga más información acerca de las direcciones IP públicas en Azure.
Obtenga más información acerca de toda la configuración de direcciones IP públicas.
 Inicio rápido: Creación de una dirección IP pública
mediante la CLI de Azure
23/09/2020 • 6 minutes to read • Edit Online

En este artículo se muestra cómo crear un recurso de dirección IP pública mediante la CLI de Azure. Para más
información sobre los recursos que se pueden asociar, la diferencia entre la SKU básica y estándar y otra
información relacionada, consulte Direcciones IP públicas. En este ejemplo, nos centraremos solo en las direcciones
IPv4. Para más información sobre las direcciones IPv6, consulte IPv6 para la red virtual de Azure.

Requisitos previos
CLI de Azure instalada localmente o Azure Cloud Shell

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar la CLI localmente, para esta guía de inicio rápido se necesita la versión 2.0.28 de la CLI de
Azure o una versión posterior. Para encontrar la versión, ejecute az --version . Si necesita instalarla o actualizarla,
consulte Instalación de la CLI de Azure.

Crear un grupo de recursos

Un grupo de recursos de Azure es un contenedor lógico en el que se implementan y se administran los recursos de
Azure.
Cree un grupo de recursos con az group create llamado myResourceGroup en la ubicación eastus2 .

az group create \
--name myResourceGroup \
--location eastus2

SKU estándar : uso de zonas

SKU estándar : sin zonas
SKU básica

NOTE
El siguiente comando funciona con la versión de API 2020-08-01 o posterior. Para más información sobre la versión de API
que se usa actualmente, consulte Tipos y proveedores de recursos.

Use az network public-ip create para crear una dirección IP pública estándar y con redundancia de zona
denominada myStandardZRPublicIP en myResourceGroup .

az network public-ip create \

--resource-group myResourceGroup \
--name myStandardZRPublicIP \
--sku Standard
--zone 1,2,3

IMPORTANT
En el caso de versiones de la API anteriores a 2020-08-01, ejecute el comando anterior sin especificar un parámetro de zona
para crear una dirección IP con redundancia de zona.

Para crear una dirección IP pública zonal estándar en la Zona 2 denominada myStandardZonalPublicIP en
myResourceGroup , use el siguiente comando:

az network public-ip create \

--resource-group myResourceGroupLB \
--name myStandardZonalPublicIP \
--sku Standard \
--zone 2

Tenga en cuenta que las opciones anteriores para las zonas son solo selecciones válidas en regiones con zonas de
disponibilidad.

Información adicional
Para más información sobre las variables individuales enumeradas anteriormente, consulte Creación, modificación
o eliminación de una dirección IP pública.

Pasos siguientes
Asocie una dirección IP pública a una máquina virtual.
Obtenga más información acerca de las direcciones IP públicas en Azure.
Obtenga más información acerca de toda la configuración de direcciones IP públicas.
 Administración de direcciones IP públicas
23/09/2020 • 23 minutes to read • Edit Online

Obtenga información sobre una dirección IP pública y cómo crearla, modificarla y eliminarla. Una dirección IP
pública es un recurso con sus propios valores de configuración. Asignar una dirección IP pública a un recurso
de Azure que admita direcciones IP públicas permite:
La comunicación entrante desde Internet a los recursos, como Azure Virtual Machines, Azure Application
Gateway, Azure Load Balancer, Azure VPN Gateway y otros. Todavía puede comunicarse con recursos como
máquinas virtuales desde Internet, si una máquina virtual no tiene asignada una dirección IP pública, y
siempre que la máquina virtual forme parte de un grupo de back-end de un equilibrador de carga, y el
equilibrador de carga tenga asignada una dirección IP pública. Para determinar si puede asignarse una
dirección IP pública a un recurso para un servicio específico de Azure, o si es posible comunicarse con él a
través de la dirección IP pública de otro recurso de Azure, consulte la documentación del servicio.
La conectividad saliente a Internet usa una dirección IP predecible. Por ejemplo, una máquina virtual puede
establecer una comunicación saliente a Internet sin tener asignada una dirección IP pública, pero su
dirección es una dirección de red que Azure traduce a una dirección pública impredecible, de manera
predeterminada. Asignar una dirección IP pública a un recurso le permite saber cuál es la dirección IP que
se usa para la conexión saliente. Si bien la dirección es predecible, puede cambiar en función del método de
asignación que se elija. Para más información, consulte Creación de una dirección IP pública. Para obtener
más información sobre las conexiones salientes de recursos de Azure, consulte Conexiones salientes.

Antes de empezar
NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de
AzureRM que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más
información acerca del nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure
PowerShell Az module (Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la
instalación del módulo Az, consulte Instalación de Azure PowerShell.

Complete las tareas siguientes antes de seguir los pasos de las secciones de este artículo:
Si todavía no tiene una cuenta de Azure, regístrese para obtener una cuenta de evaluación gratuita.
Si usa el portal, abra [Link] e inicie sesión con la cuenta de Azure.
Si usa comandos de PowerShell para completar las tareas de este artículo, ejecute los comandos que se
encuentran en Azure Cloud Shell o ejecute PowerShell en el equipo. Azure Cloud Shell es un shell
interactivo gratuito que puede usar para ejecutar los pasos de este artículo. Tiene las herramientas
comunes de Azure preinstaladas y configuradas para usarlas en la cuenta. Para realizar este tutorial, se
necesita la versión 1.0.0 del módulo de Azure PowerShell u otra posterior. Ejecute
Get-Module -ListAvailable Az para buscar la versión instalada. Si necesita actualizarla, consulte Instalación
del módulo de Azure PowerShell. Si PowerShell se ejecuta localmente, también debe ejecutar
Connect-AzAccount para crear una conexión con Azure.
Si usa la interfaz de la línea de comandos (CLI) de Azure para completar las tareas de este artículo, ejecute
los comandos que se encuentran en Azure Cloud Shell o ejecute la CLI en el equipo. Para realizar este
tutorial, es necesaria la versión 2.0.31 de la CLI de Azure o una versión posterior. Ejecute az --version para
buscar la versión instalada. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure. Si ejecuta
 de forma local la CLI de Azure, también debe ejecutar az login para crear una conexión con Azure.
La cuenta en la que inicia sesión o con la que se conecta a Azure debe tener asignado el rol de colaborador de
red o un rol personalizado que tenga asignadas las acciones apropiadas en Permisos.
Las direcciones IP públicas tienen un precio simbólico. Para ver los precios, consulte la página Precios de las
direcciones IP.

Crear una dirección IP pública

1. En el menú de Azure Portal o en la página principal , seleccione Crear un recurso .
2. Escriba dirección ip pública en el cuadro de búsqueda de Marketplace. Seleccione Dirección IP pública
cuando aparezca en los resultados de búsqueda.
3. En Dirección IP pública , seleccione Crear .
4. Escriba o seleccione valores para las siguientes opciones, en Crear dirección IP pública y seleccione
Crear :

C O N F IGURA C IÓ N ¿N EC ESA RIO ? DETA L L ES

Versión de la dirección IP Sí Seleccione IPv4 o IPv6 o ambas.

Seleccionar ambas se traducirá en la
creación de dos direcciones IP
públicas: una dirección IPv4 y una
dirección IPv6. Obtenga más
información sobre IPv6 en las redes
virtuales de Azure.
C O N F IGURA C IÓ N ¿N EC ESA RIO ? DETA L L ES

SKU Sí Todas las direcciones IP públicas

creadas antes de la introducción de
SKU son direcciones IP públicas de
SKU básica . No se puede cambiar
la SKU después de crear la dirección
IP pública. Una máquina virtual
independiente, las máquinas
virtuales dentro de un conjunto de
disponibilidad o los conjuntos de
escalado de máquinas virtuales
pueden usar SKU básicas o
estándar. No se permite la mezcla
de SKU entre máquinas virtuales
dentro de conjuntos de
disponibilidad, conjuntos de
escalado o VM independientes. SKU
básico : si va a crear una dirección
IP pública en una región que
admite zonas de disponibilidad, el
ajuste Zona disponibilidad se
establece en Ninguno de forma
predeterminada. Las IP públicas
básicas no admiten zonas de
disponibilidad. SKU estándar : una
dirección IP pública de SKU
estándar se puede asociar a una
máquina virtual o una front-end de
equilibrador de carga. Si va a crear
una dirección IP pública en una
región que admite zonas de
disponibilidad, el ajuste Zona
disponibilidad se establece en
Con redundancia de zona de forma
predeterminada. Para obtener
información sobre las zonas de
disponibilidad, consulte el ajuste
Zona de disponibilidad . La SKU
estándar es necesaria si se asocia la
dirección a un equilibrador de carga
estándar. Para obtener más
información sobre equilibradores de
carga estándar, consulte Azure load
balancer standard SKU (SLU
estándar para Azure Load Balancer).
Cuando asigna una dirección IP
pública de SKU estándar a una
interfaz de red de una máquina
virtual, debe permitir explícitamente
el tráfico previsto con un grupo de
seguridad de red. Para evitar que se
produzca un error en la
comunicación con el recurso, debe
crear un grupo de seguridad de red,
asociarlo y permitir explícitamente
el tráfico deseado.

Nombre Sí El nombre debe ser único dentro

del grupo de recursos que
seleccione.
C O N F IGURA C IÓ N ¿N EC ESA RIO ? DETA L L ES

Asignación de dirección IP Sí Dinámica: las direcciones

dinámicas se asignan solo después
de que una dirección IP pública se
asocia a un recurso de Azure y el
recurso se inicia por primera vez.
Las direcciones dinámicas pueden
cambiar si se asignan a un recurso,
como una máquina virtual, y la
máquina virtual se detiene
(desasigna) y luego se reinicia. La
dirección sigue siendo la misma si la
máquina virtual se reinicia o se
detiene (pero no se desasigna). Las
direcciones dinámicas se liberan
cuando un recurso de dirección IP
pública se desasocia de un recurso
o se asocia a él. Estática: las
direcciones estáticas se asignan
cuando se crea la dirección IP
pública. Las direcciones estáticas no
se liberan hasta que se elimina un
recurso de dirección IP pública. Si la
dirección no está asociada a un
recurso, puede cambiar el método
de asignación una vez creada la
dirección. Si la dirección está
asociada a un recurso, es posible
que no pueda cambiar el método
de asignación. Si selecciona IPv6
como la versión de dirección IP ,
el método de asignación debe ser
Dinámica para el SKU básico. Las
direcciones de SKU estándar son
estáticas tanto para IPv4 como para
IPv6.

Tiempo de espera de inactividad No Cantidad de minutos para

(minutos) mantener una conexión TCP o HTTP
abierta sin que dependa del envío
de mensajes de mantenimiento de
los clientes. Si selecciona IPv6 como
la versión de dirección IP , no se
puede cambiar este valor.
C O N F IGURA C IÓ N ¿N EC ESA RIO ? DETA L L ES

Etiqueta de nombre DNS No Debe ser único dentro de la

ubicación de Azure en la que cree el
nombre (entre todas las
suscripciones y todos los clientes).
Azure registra automáticamente el
nombre y la dirección IP en el DNS
para que pueda conectarse a un
recurso con el nombre. Azure anexa
una subred predeterminada, como
[Link] (donde
location es la ubicación
seleccionada), al nombre que
proporcione para crear el nombre
DNS completo. Si elige crear ambas
versiones de direcciones, el mismo
nombre DNS se asigna tanto a la
dirección IPv4 como a la IPv6. El
DNS predeterminado de Azure
contiene registros de nombres
AAAA tanto de IPv4 como de IPv6
y responde con ambos registros
cuando se busca el nombre DNS. El
cliente elige con qué dirección (IPv4
o IPv6) comunicarse. En lugar de
usar la etiqueta de nombre DNS
con el sufijo predeterminado, o
además de ello, puede usar el
servicio Azure DNS para configurar
un nombre DNS con un sufijo
personalizado que se resuelva en la
dirección IP pública. Para obtener
más información, vea los detalles
relativos al uso de Azure DNS con
una dirección IP pública de Azure.

Nombre (solo visible si selecciona la Sí, si selecciona la versión de IP de El nombre debe ser distinto del
versión de IP de ambas ) ambas nombre que escribe para el
nombre de esta lista. Si elige crear
tanto una dirección IPv4 como
IPv6, el portal crea dos recursos de
direcciones IP públicas
independientes, uno con cada
versión de dirección IP asignada.

Asignación de direcciones IP (solo Sí, si selecciona la versión de IP de Las mismas restricciones que la
visible si selecciona la versión de IP ambas asignación de direcciones IP
de ambas ) anterior

Subscription Sí Debe existir en la misma suscripción

que el recurso al cual asociará las
direcciones IP públicas.

Resource group Sí Puede existir en el mismo grupo de

recursos o en otro diferente como
recurso al que asociará las
direcciones IP públicas.
 C O N F IGURA C IÓ N ¿N EC ESA RIO ? DETA L L ES

Location Sí Debe existir en la misma ubicación,

a la que también se hace referencia
como región, que el recurso al que
asociará las direcciones públicas.

Zona de disponibilidad No Este ajuste solo aparece si

selecciona una ubicación admitida.
Para una lista de ubicaciones
admitidas, consulte Introducción a
las zonas de disponibilidad. Si
seleccionó la SKU básica , la opción
Ninguna se selecciona
automáticamente. Si prefiere
garantizar una zona específica,
puede seleccionarla. Cualquiera de
las opciones no es con redundancia
de zona. Si seleccionó la SKU
estándar : la opción con
redundancia de zona se selecciona
automáticamente y hace que la ruta
de acceso de datos sea resistente a
errores de zona. Si prefiere
garantizar una zona específica, que
no sea resistente a errores de zona,
puede seleccionarla.

Comandos
Si bien el portal proporciona la opción de crear dos recursos de direcciones IP públicas (una IPv4 y una IPv6),
los comandos de PowerShell y la CLI siguientes crean un recurso con una dirección para una versión de
dirección IP o la otra. Si desea dos recursos de direcciones IP públicas, uno para cada versión de dirección IP,
debe ejecutar dos veces el comando y especificar distintos nombres y versiones de dirección IP para los
recursos de direcciones IP públicas.

H ERRA M IEN TA GET - H EL P

CLI az network public-ip create

PowerShell New-AzPublicIpAddress

Visualización, cambio de la configuración o eliminación de una

dirección IP pública
1. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba
Dirección IP pública. Seleccione Direcciones IP públicas cuando aparezca en los resultados de
búsqueda.
2. Seleccione de la lista el nombre de la dirección IP pública cuya configuración desee ver, cambiar o
eliminar.
3. Complete una de las siguientes opciones en función de si desea ver, eliminar o cambiar la dirección IP
pública.
Ver : la sección Información general muestra la configuración clave de la dirección IP pública,
como la interfaz de red a la que está asociada (si la dirección está asociada a una interfaz de red). El
 portal no muestra la versión de la dirección (IPv4 o IPv6). Para ver información sobre la versión, use
el comando de la CLI o PowerShell para ver la dirección IP pública. Si la versión de la dirección IP es
IPv6, ni el portal, ni PowerShell ni la CLI muestran la dirección asignada.
Eliminar : para eliminar la dirección IP pública, seleccione Eliminar en la sección Información
general . Si la dirección está actualmente asociada a una configuración de IP, no se puede eliminar. Si
la dirección está asociada actualmente con una configuración, seleccione Desasociar para
desasociar la dirección de la configuración de IP.
Cambiar : seleccione Configuración . Cambie la configuración según se indica en el paso 4 de Crear
una dirección IP pública. Para cambiar la asignación de una dirección IPv4 de estática a dinámica,
primero debe desasociar la dirección IPv4 pública de la configuración de IP a que está asociada. A
continuación, puede cambiar el método de asignación a dinámico y seleccionar Asociar para asociar
la dirección IP a la misma configuración de IP, una diferente o dejarla desasociada. Para desasociar
una dirección IP pública, en la sección Información general , seleccione Desasociar .

WARNING
Al cambiar el método de asignación de estático a dinámico, perderá la dirección IP que se asignó a la dirección IP
pública. Aunque los servidores DNS públicos de Azure mantienen una asignación entre las direcciones estáticas o
dinámicas y cualquier etiqueta de nombre DNS (si se han definido), las direcciones IP dinámicas pueden cambiar
cuando se inicia la máquina virtual desde el estado detenido (desasignado). Para evitar que la dirección cambie,
asigne una dirección IP estática.

Comandos

H ERRA M IEN TA GET - H EL P

CLI az network public-ip list para mostrar las direcciones IP

públicas, az network public-ip show para mostrar la
configuración, az network public-ip update para actualizar,
az network public-ip delete para eliminar

PowerShell Get-AzPublicIpAddress para recuperar un objeto de

dirección IP pública y ver su configuración, Set-
AzPublicIpAddress para actualizar la configuración, Remove-
AzPublicIpAddress para eliminar

Asignación de una dirección IP pública

Aprenda a asignar una dirección IP pública a los siguientes recursos:
Una máquina virtual Windows o Linux (durante la creación), o una máquina virtual ya existente
Equilibrador de carga accesible desde Internet
Introducción a Puerta de enlace de aplicaciones
Conexión de sitio a sitio con Azure VPN Gateway
Conjunto de escalado de máquinas virtuales de Azure

Permisos
Para realizar tareas en direcciones IP públicas, su cuenta debe estar asignada al rol de colaborador de red o a
un rol personalizado que tenga asignadas las acciones adecuadas que se muestran en la tabla siguiente:
 A C C IÓ N N O M B RE

[Link]/publicIPAddresses/read Leer una dirección IP pública

[Link]/publicIPAddresses/write Crear o actualizar una dirección IP pública

[Link]/publicIPAddresses/delete Eliminar una dirección IP pública

[Link]/publicIPAddresses/join/action Asociar una dirección IP pública a un recurso

Pasos siguientes
Crear una dirección IP pública con scripts de ejemplo de PowerShell o CLI de Azure o con plantillas de Azure
Resource Manager
Crear y asignar definiciones de Azure Policy para direcciones IP públicas
 Creación, modificación o eliminación del prefijo de
una dirección IP pública
23/09/2020 • 12 minutes to read • Edit Online

Obtenga información sobre el prefijo de una dirección IP pública y cómo crearlo, modificarlo y eliminarlo. El
prefijo de una dirección IP pública es un intervalo contiguo de direcciones basado en el número de direcciones
IP públicas que especifique. Las direcciones se asignan a su suscripción. Al crear un recurso de dirección IP
pública, puede asignar una dirección IP pública estática a partir del prefijo y asociar la dirección a máquinas
virtuales, equilibradores de carga u otros recursos para habilitar la conectividad a Internet. Si no está
familiarizado con los prefijos de las direcciones IP públicas, consulte Información general sobre el prefijo de
una dirección IP pública

Antes de empezar
NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de
AzureRM que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más
información acerca del nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure
PowerShell Az module (Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la
instalación del módulo Az, consulte Instalación de Azure PowerShell.

Complete las tareas siguientes antes de seguir los pasos de las secciones de este artículo:
Si todavía no tiene una cuenta de Azure, regístrese para obtener una cuenta de evaluación gratuita.
Si usa el portal, abra [Link] e inicie sesión con la cuenta de Azure.
Si usa comandos de PowerShell para completar las tareas de este artículo, ejecute los comandos que se
encuentran en Azure Cloud Shell o ejecute PowerShell en el equipo. Azure Cloud Shell es un shell
interactivo gratuito que puede usar para ejecutar los pasos de este artículo. Tiene las herramientas
comunes de Azure preinstaladas y configuradas para usarlas en la cuenta. Para realizar este tutorial, se
necesita la versión 1.0.0 del módulo de Azure PowerShell u otra posterior. Ejecute
Get-Module -ListAvailable Az para buscar la versión instalada. Si necesita actualizarla, consulte Instalación
del módulo de Azure PowerShell. Si PowerShell se ejecuta localmente, también debe ejecutar
Connect-AzAccount para crear una conexión con Azure.
Si usa la interfaz de la línea de comandos (CLI) de Azure para completar las tareas de este artículo, ejecute
los comandos que se encuentran en Azure Cloud Shell o ejecute la CLI en el equipo. Para realizar este
tutorial, es necesaria la versión 2.0.41 de la CLI de Azure o una versión posterior. Ejecute az --version para
buscar la versión instalada. Si necesita instalarla o actualizarla, consulte Instalación de la CLI de Azure 2.0. Si
ejecuta de forma local la CLI de Azure, también debe ejecutar az login para crear una conexión con Azure.
La cuenta en la que inicia sesión o con la que se conecta a Azure debe tener asignado el rol de colaborador de
red o un rol personalizado que tenga asignadas las acciones apropiadas en Permisos.
Los prefijos de las direcciones IP públicas tienen un cargo. Para obtener información detallada, consulte
Precios.

Creación del prefijo de una dirección IP pública

1. En la esquina superior izquierda del portal, seleccione + Crear un recurso .
2. Escriba el prefijo de dirección IP pública en el cuadro Búsqueda en Marketplace. Seleccione Prefijo de
dirección IP pública cuando aparezca en los resultados de búsqueda.
3. En Prefijo de dirección IP pública , seleccione Crear .
4. Escriba o seleccione valores para las siguientes opciones, en Crear prefijo de dirección IP pública , y
seleccione Crear :

C O N F IGURA C IÓ N ¿N EC ESA RIO ? DETA L L ES

Subscription Sí Debe existir en la misma suscripción

que el recurso al cual desee asociar
la dirección IP pública.

Resource group Sí Puede existir en la misma

suscripción que el grupo de
recursos al cual desee asociar la
dirección IP pública o en otra
diferente.

Nombre Sí El nombre debe ser único dentro

del grupo de recursos que
seleccione.

Region Sí Debe existir en la misma región que

las direcciones IP públicas que
asignará a direcciones del intervalo.

Tamaño del prefijo Sí El tamaño del prefijo que necesita.

A/28 o 16 direcciones IP es el valor
predeterminado.

Comandos

H ERRA M IEN TA GET - H EL P

CLI az network public-ip prefix create

PowerShell New-AzPublicIpPrefix

Creación de una dirección IP pública estática a partir de un prefijo

Una vez que cree un prefijo, debe crear las direcciones IP estáticas a partir del prefijo. Para ello, siga estos
pasos.
1. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba Prefijo
de dirección IP pública. Seleccione Prefijos de direcciones IP públicas cuando aparezca en los
resultados de búsqueda.
2. Seleccione el prefijo a partir del cual quiere crear direcciones IP públicas.
3. Cuando aparezca en los resultados de búsqueda, selecciónelo y haga clic en +Agregar dirección IP
en la sección Información general.
4. Escriba o seleccione valores para las siguientes opciones, en Crear dirección IP pública . Puesto que
un prefijo es para SKU estándar, IPv4 y estático, solo deberá proporcionar la información siguiente:
 C O N F IGURA C IÓ N ¿N EC ESA RIO ? DETA L L ES

Nombre Sí El nombre de la dirección IP pública

debe ser único dentro del grupo de
recursos que seleccione.

Tiempo de espera de inactividad No Cantidad de minutos para

(minutos) mantener una conexión TCP o HTTP
abierta sin que dependa del envío
de mensajes de mantenimiento de
los clientes.

Etiqueta de nombre DNS No Debe ser único dentro de la región

de Azure en la que cree el nombre
(entre todas las suscripciones y
todos los clientes). Azure registra
automáticamente el nombre y la
dirección IP en el DNS para que
pueda conectarse a un recurso con
el nombre. Azure anexa una subred
predeterminada, como
[Link] (en
que location es la ubicación
seleccionada), al nombre que
proporcione para crear el nombre
DNS cualificado completo. Para
obtener más información, consulte
Utilizar Azure DNS con una
dirección IP pública de Azure.

También puede usar los comandos CLI y PS que tiene a continuación con los parámetros --public-ip-prefix
(CLI) y -PublicIpPrefix (PS), para crear un recurso de dirección IP pública.

H ERRA M IEN TA GET - H EL P

CLI az network public-ip create

PowerShell New-AzPublicIpAddress

Ver o eliminar un prefijo

1. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba Prefijo de
dirección IP pública. Seleccione Prefijos de direcciones IP públicas cuando aparezca en los resultados
de búsqueda.
2. Seleccione el nombre del prefijo de la dirección IP pública que quiera ver, cambiar la configuración o
eliminar de la lista.
3. Complete una de las siguientes opciones en función de si desea ver, eliminar o cambiar el prefijo de la
dirección IP pública.
Ver : en la sección Información general se muestra la configuración clave del prefijo de una
dirección IP pública, como prefijo.
Eliminar : para eliminar el prefijo de una dirección IP pública, seleccione Eliminar en la sección
Información general . Si las direcciones dentro del prefijo están asociadas a recursos de dirección
IP pública, primero debe eliminar dichos recursos de dirección IP pública. Consulte Eliminar una
dirección IP pública.
Comandos
 H ERRA M IEN TA GET - H EL P

CLI az network public-ip prefix list para mostrar las direcciones

IP públicas, az network public-ip prefix show para mostrar la
configuración, az network public-ip prefix update para
actualizar, az network public-ip prefix delete para eliminar

PowerShell Get-AzPublicIpPrefix para recuperar un objeto de dirección

IP pública y ver su configuración, Set-AzPublicIpPrefix para
actualizar la configuración, Remove-AzPublicIpPrefix para
eliminar.

Permisos
Para realizar tareas en prefijos de direcciones IP públicas, su cuenta debe estar asignada al rol de colaborador
de red o a un rol personalizado que tenga asignadas las acciones adecuadas que se muestran en la tabla
siguiente:

A C C IÓ N N O M B RE

[Link]/publicIPPrefixes/read Leer el prefijo de una dirección IP pública

[Link]/publicIPPrefixes/write Crear o actualizar el prefijo de una dirección IP pública

[Link]/publicIPPrefixes/delete Eliminación del prefijo de una dirección IP pública

[Link]/publicIPPrefixes/join/action Creación de una dirección IP pública a partir de un prefijo

Pasos siguientes
Obtener información sobre los escenarios y las ventajas de usar un prefijo de IP pública
 Incorporación, cambio o eliminación de
direcciones IP para una interfaz de red de Azure
23/09/2020 • 32 minutes to read • Edit Online

Obtenga información sobre cómo agregar, cambiar y quitar direcciones IP públicas y privadas para una
interfaz de red. Las direcciones IP privadas asignadas a una interfaz de red permiten que una máquina virtual
se comunique con otros recursos en una red virtual de Azure y en redes conectadas. Una dirección IP privada
también permite la comunicación saliente a Internet mediante el uso de una dirección IP impredecible. Una
dirección IP pública asignada a una interfaz de red permite la comunicación entrante a una máquina virtual
desde Internet. La dirección también permite la comunicación saliente desde la máquina virtual a Internet
mediante el uso de una dirección IP impredecible. Para detalles, consulte Comprender las conexiones
salientes en Azure.
Si necesita crear, cambiar o eliminar una interfaz de red, lea el artículo sobre cómo administrar una interfaz
de red. Si necesita agregar interfaces de red a una máquina virtual, o quitar interfaces de red de ella, consulte
el artículo Incorporación de interfaces de red a máquinas virtuales o eliminación de estas.

Antes de empezar
NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de
AzureRM que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más
información acerca del nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure
PowerShell Az module (Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la
instalación del módulo Az, consulte Instalación de Azure PowerShell.

Complete las tareas siguientes antes de seguir los pasos de las secciones de este artículo:
Si todavía no tiene una cuenta de Azure, regístrese para obtener una cuenta de evaluación gratuita.
Si usa el portal, abra [Link] e inicie sesión con la cuenta de Azure.
Si usa comandos de PowerShell para completar las tareas de este artículo, ejecute los comandos que se
encuentran en Azure Cloud Shell o ejecute PowerShell en el equipo. Azure Cloud Shell es un shell
interactivo gratuito que puede usar para ejecutar los pasos de este artículo. Tiene las herramientas
comunes de Azure preinstaladas y configuradas para usarlas en la cuenta. Para realizar este tutorial, se
necesita la versión 1.0.0 del módulo de Azure PowerShell u otra posterior. Ejecute
Get-Module -ListAvailable Az para buscar la versión instalada. Si necesita actualizarla, consulte Instalación
del módulo de Azure PowerShell. Si PowerShell se ejecuta localmente, también debe ejecutar
Connect-AzAccount para crear una conexión con Azure.
Si usa la interfaz de la línea de comandos (CLI) de Azure para completar las tareas de este artículo, ejecute
los comandos que se encuentran en Azure Cloud Shell o ejecute la CLI en el equipo. Para realizar este
tutorial, es necesaria la versión 2.0.31 de la CLI de Azure o una versión posterior. Ejecute az --version
para buscar la versión instalada. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure. Si
ejecuta de forma local la CLI de Azure, también debe ejecutar az login para crear una conexión con
Azure.
La cuenta en la que inicia sesión o con la que se conecta a Azure debe tener asignado el rol de colaborador de
red o un rol personalizado que tenga asignadas las acciones apropiadas que figuren en Permisos de interfaz
de red.

Incorporación de direcciones IP
Puede agregar a una interfaz de red tantas direcciones privadas y públicasIPv4 como sea necesario, dentro de
los límites indicados en el artículo sobre los límites de Azure. Puede agregar una dirección IPv6 privada a una
configuración IP secundaria (siempre que no haya ninguna configuración IP secundaria existente) para una
interfaz de red existente. Cada interfaz de red puede tener como máximo una dirección IPv6 privada.
Opcionalmente, puede agregar una dirección IPv6 pública a una configuración de interfaz de red IPv6.
Consulte IPv6 para detalles sobre cómo usar las direcciones IPv6.
1. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba
interfaces de red. Cuando aparezcan las interfaces de red en los resultados de búsqueda,
selecciónelas.
2. En la lista, seleccione la interfaz de red para la que quiere agregar una dirección IPv4.
3. En CONFIGURACIÓN , seleccione Configuraciones IP .
4. En Configuraciones IP , seleccione + Agregar .
5. Especifique lo siguiente y luego seleccione Aceptar :

C O N F IGURA C IÓ N ¿N EC ESA RIO ? DETA L L ES

Nombre Sí Debe ser único para la interfaz de

red

Tipo Sí Debido a que agrega una

configuración IP a una interfaz de
red existente y cada interfaz de red
debe tener una configuración IP
principal, la única opción es
Secundaria .

Método de asignación de Sí Dinámica : Azure asigna la

direcciones IP privadas siguiente dirección disponible para
el intervalo de dirección de subred
en el que se implementa la interfaz
de red. Estática : asigna una
dirección o usada para el intervalo
de dirección de subred en el que se
implementa la interfaz de red.

Dirección IP pública No Deshabilitado: ningún recurso de

dirección IP pública está asociado
actualmente a la configuración de
IP. Habilitada: seleccione una
dirección IP pública IPv4 existente
o cree una nueva. Para más
información sobre cómo crear una
dirección IP pública, lea el artículo
Direcciones IP públicas.

6. Agregue manualmente las direcciones IP privadas secundarias al sistema operativo de la máquina

virtual siguiendo las instrucciones que aparecen en el artículo Asignación de varias direcciones IP a
sistemas operativos de máquinas virtuales. Consulte las direcciones IP privadas para ver
consideraciones especiales antes de agregar manualmente direcciones IP a un sistema operativo de
máquina virtual. No agregue ninguna dirección IP pública al sistema operativo de máquina virtual.
Comandos

H ERRA M IEN TA GET - H EL P

CLI az network nic ip-config create

PowerShell Add-AzNetworkInterfaceIpConfig

Cambio de configuración de las direcciones IP

Es posible que necesite cambiar el método de asignación de una dirección IPv4, cambie la dirección IPv4
estática o cambie la dirección IP pública asignada a una interfaz de red. Si va a cambiar la dirección IPv4
privada de una configuración IP secundaria asociada con una interfaz de red secundaria en una máquina
virtual (más información sobre las interfaces de red principales y secundarias), detenga (desasigne) la
máquina virtual antes de completar los pasos siguientes:
1. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba interfaces
de red. Cuando aparezcan las interfaces de red en los resultados de búsqueda, selecciónelas.
2. En la lista, seleccione la interfaz de red para la que quiere ver o cambiar la configuración de dirección IP.
3. En CONFIGURACIÓN , seleccione Configuraciones IP .
4. En la lista, seleccione la configuración IP que desea modificar.
5. Cambie la configuración según la información que se proporciona en el paso 5 de Incorporación de una
configuración IP.
6. Seleccione Guardar .

NOTE
Si la interfaz de red principal tiene varias configuraciones de IP y cambia la dirección IP privada de la configuración IP
principal, debe reasignar manualmente las direcciones IP principal y secundaria a la interfaz de red en Windows (no es
necesario para Linux). Para asignar manualmente las direcciones IP a una interfaz de red dentro de un sistema
operativo, consulte Asignación de varias direcciones IP a máquinas virtuales con Azure Portal. Para ver consideraciones
especiales antes de agregar manualmente direcciones IP a un sistema operativo de máquina virtual, consulte las
direcciones IP privadas. No agregue ninguna dirección IP pública al sistema operativo de máquina virtual.

Comandos

H ERRA M IEN TA GET - H EL P

CLI az network nic ip-config update

PowerShell Set-AzNetworkInterfaceIpConfig

Eliminación de direcciones IP
Puede quitar direcciones IP privadas y públicas de una interfaz de red, pero una interfaz de red siempre debe
tener asignada al menos una dirección IPv4 privada.
1. En el cuadro que contiene el texto Buscar recursos, en la parte superior de Azure Portal, escriba interfaces
de red. Cuando aparezcan las interfaces de red en los resultados de búsqueda, selecciónelas.
2. En la lista, seleccione la interfaz de red de la que desee quitar direcciones IP.
3. En CONFIGURACIÓN , seleccione Configuraciones IP .
4. Haga clic con el botón derecho en una configuración de IP secundaria (no se puede eliminar la
 configuración principal) que desee eliminar, seleccione Eliminar y, luego, elija Sí para confirmar la
eliminación. Si la configuración tenía asociado un recurso de dirección IP pública, el recurso se desasocia
de la configuración de IP, pero no se elimina.
Comandos

H ERRA M IEN TA GET - H EL P

CLI az network nic ip-config delete

PowerShell Remove-AzNetworkInterfaceIpConfig

Configuraciones IP
Las direcciones IP privadas y (opcionalmente) públicas se asignan a una o más configuraciones IP asignadas a
una interfaz de red. Hay dos tipos de configuraciones IP:
Principal
Cada interfaz de red tiene asignada una configuración IP principal. Una configuración IP principal:
Tiene asignada una dirección IPv4privada. No puede asignar una dirección IPv6 privada a una
configuración IP principal.
También puede tener asignada una dirección IPv4 pública. No puede asignar una dirección IPv6 pública a
una configuración IP principal (IPv4).
Secundario
Además de una configuración IP principal, una interfaz de red puede tener ninguna o más configuraciones IP
secundarias asignadas. Una configuración IP secundaria:
Debe tener asignada una dirección IPv4 o IPv6 privada. Si la dirección es IPv6, la interfaz de red solo puede
tener una configuración IP secundaria. Si la dirección es IPv4, la interfaz de red puede tener asignadas
varias configuraciones IP secundarias. Para más información sobre cuántas direcciones IPv4 privadas y
públicas se pueden asignar a una interfaz de red, consulte el artículo sobre los límites de Azure.
También puede tener asignada una dirección IPv6 o IPv4 pública. Asignar varias direcciones IPv4 a una
interfaz de red resulta útil en escenarios como:
Hospedaje de varios sitios web o servicios con direcciones IP y certificados TLS/SSL diferentes en
un único servidor.
Una máquina virtual que actúa como una aplicación virtual de red, por ejemplo, un firewall o un
equilibrador de carga.
La capacidad de agregar cualquiera de las direcciones IPv4 privadas para cualquiera de las
interfaces de red a un grupo de servidores de back-end de Azure Load Balancer. En el pasado, solo
la dirección IPv4 principal de la interfaz de red principal podía agregarse a un grupo de servidores
back-end. Para más información sobre cómo equilibrar la carga de varias configuraciones IPv4,
consulte el artículo Equilibrio de carga en varias configuraciones IP.
La capacidad de equilibrar carga una vez que se asigna una dirección IPv6 a una interfaz de red.
Para más información sobre cómo equilibrar carga a una dirección IPv6 privada, consulte el artículo
sobre el equilibrio de carga de direcciones IPv6.

Tipos de direcciones
Puede asignar los tipos siguientes de direcciones IP a una configuración IP:
Privada
Las direcciones IPv4 o IPv6 privadas permiten que una máquina virtual se comunique con otros recursos en
una red virtual o en otras redes conectadas.
De manera predeterminada, los servidores DHCP de Azure asignan la dirección IPv4 privada para la
configuración IP principal de la interfaz de red a la interfaz de red de Azure dentro del sistema operativo de la
máquina virtual. A menos que sea necesario, nunca debe establecer la dirección IP de una interfaz de red
dentro del sistema operativo de la máquina virtual.

WARNING
Si la dirección IPv4 establecida como la dirección IP principal de una interfaz de red dentro del sistema operativo de
una máquina virtual alguna vez es distinta de la dirección IPv4 privada asignada a la configuración IP principal de la
interfaz de red principal conectada a una máquina virtual dentro de Azure, se pierde conectividad con la máquina
virtual.

Hay escenarios en los cuales es necesario establecer manualmente la dirección IP de una interfaz de red
dentro del sistema operativo de la máquina virtual. Por ejemplo, debe establecer manualmente las
direcciones IP principales y secundarias de un sistema operativo Windows cuando se agregan varias
direcciones IP a una máquina virtual de Azure. En el caso de una máquina virtual Linux, solo debe establecer
manualmente las direcciones IP secundarias. Consulte Incorporación de direcciones IP a un sistema operativo
de la máquina virtual para detalles. Si alguna vez debe cambiar la dirección asignada a una configuración IP,
se recomienda que haga lo siguiente:
1. Asegúrese de que la máquina virtual recibe una dirección de los servidores DHCP de Azure. Una vez
hecho esto, cambie la asignación de la dirección IP a DHCP en el sistema operativo y reinicie la máquina
virtual.
2. Detenga (desasigne) la máquina virtual.
3. Cambie la dirección IP de la configuración IP dentro de Azure.
4. Inicie la máquina virtual.
5. Configure manualmente las direcciones IP secundarias dentro del sistema operativo (y también la
dirección IP principal dentro de Windows) para que coincidan con las que estableció en Azure.
Si sigue los pasos anteriores, la dirección IP privada asignada a la interfaz de red dentro de Azure y dentro del
sistema operativo de una máquina virtual no serán distintas. Para realizar un seguimiento de las máquinas
virtuales dentro de la suscripción para las cuales estableció manualmente direcciones IP dentro de un sistema
operativo, considere agregar una etiqueta de Azure a las máquinas virtuales. Por ejemplo, puede usar
"Asignación de dirección IP: estática". De este modo, puede encontrar fácilmente las máquinas virtuales
dentro de la suscripción para las cuales estableció manualmente la dirección IP dentro del sistema operativo.
Además de permitir que una máquina virtual se comunique con otros recursos dentro de la misma red
virtual o dentro de redes virtuales conectadas, una dirección IP privada también permite que una máquina
virtual establezca una conexión saliente a Internet. Las conexiones salientes son direcciones de red de origen
que Azure traduce a una dirección IP pública impredecible. Para más información acerca de la conectividad de
salida a Internet de Azure, consulte el artículo de Comprender las conexiones salientes en Azure. No puede
establecer una comunicación entrante a la dirección IP privada de una máquina virtual desde Internet. Si las
conexiones salientes requieren una dirección IP pública predecible, asocie un recurso de dirección IP pública a
una interfaz de red.
Público
Las direcciones IP públicas asignadas a través de un recurso de dirección IP pública permiten la conectividad
entrante a una máquina virtual desde Internet. Las conexiones salientes a Internet usan una dirección IP
predecible. Consulte Comprender las conexiones salientes en Azure para detalles. Puede asignar una
dirección IP pública a una configuración de IP, pero no es obligatorio. Si no asigna una dirección IP pública a
una máquina virtual mediante la asociación de un recurso de direcciones IP públicas, la máquina virtual
puede seguir estableciendo una comunicación saliente a Internet. En este caso, la dirección IP privada es la
dirección de red de origen que Azure traduce a una dirección IP pública impredecible. Para más información
sobre los recursos de direcciones IP públicas, vea Recurso de direcciones IP públicas.
Hay límites en el número de direcciones IP privadas y públicas que se pueden asignar a una interfaz de red.
Para más información, lea el artículo acerca de los límites de Azure.

NOTE
Azure traduce la dirección IP privada de una máquina virtual a una dirección IP pública. Como resultado, el sistema
operativo de una máquina virtual no detecta ninguna de las direcciones IP públicas que tiene asignada, por lo que no
es necesario asignar manualmente una dirección IP pública dentro del sistema operativo.

Métodos de asignación
Las direcciones IP públicas y privadas se asignan con uno de los siguientes métodos de asignación:
Dinámica
Las direcciones IPv4 e IPv6 (opcionalmente) privadas dinámicas se asignan de manera predeterminada.
Solo pública : Azure asigna la dirección de un intervalo único a cada región de Azure. Para saber qué
intervalos se asignan a cada región, vea Intervalos de direcciones IP del centro de datos de Microsoft
Azure. La dirección puede cambiar cuando una máquina virtual está detenida (desasignada) y se vuelve a
iniciar. No puede asignar una dirección IPv6 pública a una configuración IP con un método de asignación.
Solo privado : Azure reserva las cuatro primeras direcciones en cada intervalo de direcciones de subred y
no las asigna. Azure asigna la siguiente dirección disponible a un recurso del intervalo de direcciones de
subred. Por ejemplo, si el intervalo de direcciones de la subred es [Link]/16 y ya están asignadas las
direcciones [Link]-[Link] (.0 a .3 están reservados), Azure asigna [Link] al recurso. Este es el
método de asignación predeterminado. Una vez asignadas, las direcciones IP dinámicas solo se liberan si
se elimina una interfaz de red y se asigna a otra subred diferente de la misma red virtual, o bien el método
de asignación se cambia a estática y se especifica otra dirección IP. De forma predeterminada, cuando se
cambia el método de asignación de dinámica a estática, Azure asigna la dirección asignada dinámicamente
anterior como dirección estática.
estática
De manera opcional, puede asignar una dirección IPv4 o IPv6 estática pública o privada a una configuración
IP. Para más información sobre cómo Azure asigna direcciones IPv4 estáticas públicas, consulte Dirección IP
pública.
Solo pública : Azure asigna la dirección de un intervalo único a cada región de Azure. Puede descargar la
lista de intervalos (prefijos) para las nubes de Azure Pública, Gobierno de Estados Unidos, China y
Alemania. La dirección no cambia hasta que el recurso de dirección IP pública se asigna o se elimina, o el
método de asignación cambia a dinámico. Si el recurso de dirección IP pública está asociado a una
configuración de dirección IP, se debe desasociar de la configuración de dirección IP antes de cambiar su
método de asignación.
Solo privado : se selecciona y asigna una dirección del intervalo de direcciones de la subred. La dirección
que se asigna puede ser cualquiera que esté en el intervalo de direcciones de subred, salvo que sea una de
las cuatro primeras y que no esté asignada a otro recurso de la subred. Las direcciones estáticas solo se
liberan cuando se elimina la interfaz de red. Si cambia el método de asignación a estática, Azure asigna
dinámicamente la dirección IP estática asignada anteriormente como dirección estática, aunque no sea la
siguiente dirección disponible en el intervalo de direcciones de la subred. La dirección también cambia si
la interfaz de red se asigna a otra subred de la misma red virtual, pero para ello, antes hay que cambiar el
 método de asignación de estática a dinámica. Una vez que ha asignado la interfaz de red a otra subred,
puede volver a cambiar el método de asignación a estática y asignar una dirección IP del intervalo de
direcciones de la nueva subred.

Versiones de direcciones IP
Puede especificar las versiones siguientes cuando asigna direcciones:
IPv4
Cada interfaz de red debe tener una configuración de IP principal con una dirección IPv4 privada asignada.
Puede agregar una o más configuraciones IP secundarias en que cada una tenga una dirección IPv4 privada y,
de manera opcional, una dirección IP pública IPv4.
IPv6
Puede no asignar ninguna dirección IPv6 privada o asignar una a una configuración IP secundaria de una
interfaz de red. La interfaz de red no puede tener ninguna configuración IP secundaria existente. Cada interfaz
de red puede tener como máximo una dirección IPv6 privada. Opcionalmente, puede agregar una dirección
IPv6 pública a una configuración de interfaz de red IPv6.

NOTE
Aunque puede crear una interfaz de red con una dirección IPv6 mediante el portal, no se puede agregar una interfaz
de red a una máquina virtual nueva o existente, mediante el portal. Use PowerShell o la CLI de Azure para crear una
interfaz de red con una dirección IPv6 privada y, luego, conectar la interfaz de red cuando crea una máquina virtual. No
puede conectar a una máquina virtual existente una interfaz de red con una dirección IPv6 privada asignada. No puede
agregar una dirección IPv6 privada a una configuración IP para ninguna interfaz de red conectada a una máquina
virtual con ninguna herramienta (portal, CLI o PowerShell).

No puede asignar una dirección IPv6 pública a una configuración IP principal o secundaria.

SKU
Se crea una dirección IP pública con la SKU estándar o básica. Para más información sobre las diferencias
entre SKU, vea Creación, modificación o eliminación de una dirección IP pública.

NOTE
Cuando asigna una dirección IP pública de SKU estándar a una interfaz de red de una máquina virtual, debe permitir
explícitamente el tráfico previsto con un grupo de seguridad de red. Para evitar que se produzca un error en la
comunicación con el recurso, debe crear un grupo de seguridad de red, asociarlo y permitir explícitamente el tráfico
deseado.

Pasos siguientes
Para crear una máquina virtual con distintas configuraciones IP, lea los artículos siguientes:

TA REA H ERRA M IEN TA

Creación de una máquina virtual con varias interfaces de CLI, PowerShell

red

Creación de una máquina virtual con una sola interfaz de CLI, PowerShell
red y varias direcciones IPv4
TA REA H ERRA M IEN TA

Creación de una máquina virtual con una sola interfaz de CLI, PowerShell, Plantilla de Azure Resource Manager
red y una dirección IPv6 privada (detrás de Azure Load
Balancer)
 Configuración de la preferencia de enrutamiento para
una dirección IP pública mediante Azure Portal
23/09/2020 • 4 minutes to read • Edit Online

En este artículo se muestra cómo configurar las preferencias de enrutamiento a través de la red de ISP (opción de
Internet ) para una dirección IP pública. Después de crear la dirección IP pública, puede asociarla a los siguientes
recursos de Azure para el tráfico entrante y saliente de Internet:
Máquina virtual
Conjunto de escalado de máquina virtual
Azure Kubernetes Service (AKS)
Equilibrador de carga accesible desde Internet
Application Gateway
Azure Firewall
De manera predeterminada, la preferencia de enrutamiento de la dirección IP pública se establece en la red global
de Microsoft para todos los servicios de Azure y puede asociarse a cualquier servicio de Azure.

IMPORTANT
La preferencia de enrutamiento se encuentra actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin
Acuerdo de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características
no sean compatibles o que tengan sus funcionalidades limitadas. Para más información, consulte Términos de uso
complementarios de las Versiones Preliminares de Microsoft Azure.

Si no tiene una suscripción a Azure, cree una cuenta gratuita ahora.

Registro de la característica de la suscripción

La característica de preferencias de enrutamiento se encuentra actualmente en versión preliminar. Registre la
característica de la suscripción mediante Azure PowerShell, tal como se indica a continuación:

Register-AzProviderFeature -FeatureName AllowRoutingPreferenceFeature -ProviderNamespace [Link]

Creación de una dirección IP pública con preferencia de enrutamiento

1. Inicie sesión en Azure Portal.
2. Seleccione Crear un recurso .
3. En el cuadro de búsqueda, escriba Dirección IP pública.
4. En los resultados de la búsqueda, escriba Dirección IP pública . A continuación, en la página Dirección IP
pública seleccione Crear .
5. En las opciones de Preferencias de enrutamiento , seleccione Internet .
 NOTE
Las direcciones IP públicas se crean con una dirección IPv4 o IPv6. Sin embargo, la preferencia de enrutamiento solo
admite IPV4 actualmente.

Puede asociar la dirección IP pública creada anteriormente con una máquina virtual de Windows o Linux. Use la
sección CLI en la siguiente página del tutorial: asociación de una dirección IP pública a una máquina virtual para
asociar la dirección IP pública a la VM. Asimismo, puede asociar una dirección IP pública que haya creado con
anterioridad con una instancia de Azure Load Balancer asignándola a la configuración de front-end del
equilibrador de carga. La dirección IP pública actúa como dirección IP virtual (VIP) de carga equilibrada.

Pasos siguientes
Obtenga más información sobre las direcciones IP públicas con preferencia de enrutamiento.
Configuración de la preferencia de enrutamiento de una VM.
Configuración de la preferencia de enrutamiento para una dirección IP pública mediante PowerShell.
Obtenga más información acerca de las direcciones IP públicas en Azure.
Obtenga más información acerca de toda la configuración de direcciones IP públicas.
 Configuración de la preferencia de enrutamiento
para una dirección IP pública mediante Azure
PowerShell
23/09/2020 • 6 minutes to read • Edit Online

En este artículo se muestra cómo configurar las preferencias de enrutamiento a través de la red de ISP (opción de
Internet ) para una dirección IP pública mediante Azure PowerShell. Después de crear la dirección IP pública,
puede asociarla a los siguientes recursos de Azure para el tráfico entrante y saliente de Internet:
Máquina virtual
Conjunto de escalado de máquina virtual
Azure Kubernetes Service (AKS)
Equilibrador de carga accesible desde Internet
Application Gateway
Azure Firewall
De forma predeterminada, la preferencia de enrutamiento de la dirección IP pública se establece en la red global
de Microsoft para todos los servicios de Azure y puede asociarse a cualquier servicio de Azure.

IMPORTANT
La preferencia de enrutamiento se encuentra actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin
Acuerdo de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características
no sean compatibles o que tengan sus funcionalidades limitadas. Para más información, consulte Términos de uso
complementarios de las Versiones Preliminares de Microsoft Azure.

Si no tiene una suscripción a Azure, cree una cuenta gratuita ahora.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.
Para ejecutar el código de este artículo en Azure Cloud Shell:
1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar PowerShell de forma local, la versión del módulo de Azure PowerShell que necesita este
artículo es la 6.9.0 u otra posterior. Ejecute Get-Module -ListAvailable Az para buscar la versión instalada. Si
necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se ejecuta localmente,
también debe ejecutar Connect-AzAccount para crear una conexión con Azure.

Registro de la característica de la suscripción

La característica de preferencias de enrutamiento se encuentra actualmente en versión preliminar. Registre de la
característica de la suscripción tal como se muestra a continuación:

Register-AzProviderFeature -FeatureName AllowRoutingPreferenceFeature -ProviderNamespace [Link]

Crear un grupo de recursos

Cree un grupo de recursos con New-AzResourceGroup. En este ejemplo, se crea un grupo de recursos
denominado myResourceGroup en la ubicación eastus:

$rg = New-AzResourceGroup -Name myResourceGroup -Location EastUS

Creación de una dirección IP pública con preferencia de enrutamiento

de Internet
El siguiente comando crea una nueva dirección IP pública con preferencia de enrutamiento de tipo Internet en la
región de Azure del Este de EE. UU. :

$iptagtype="RoutingPreference"
$tagName = "Internet"
$ipTag = New-AzPublicIpTag -IpTagType $iptagtype -Tag $tagName
# attach the tag
$publicIp = New-AzPublicIpAddress `
-Name "MyPublicIP" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-IpTag $ipTag `
-AllocationMethod Static `
-Sku Standard `
-IpAddressVersion IPv4

Puede asociar la dirección IP pública creada anteriormente con una máquina virtual de Windows o Linux. Use la
sección CLI en la siguiente página del tutorial: asociación de una dirección IP pública a una máquina virtual para
asociar la dirección IP pública a la VM. Asimismo, puede asociar una dirección IP pública que haya creado con
anterioridad con una instancia de Azure Load Balancer asignándola a la configuración de front-end del
equilibrador de carga. La dirección IP pública actúa como dirección IP virtual (VIP) de carga equilibrada.
Limpieza de recursos
Cuando ya no se necesiten, puede usar el comando Remove-AzResourceGroup para quitar el grupo de recursos, la
VM y todos los recursos relacionados.

Remove-AzResourceGroup -Name myResourceGroup

Pasos siguientes
Obtenga más información sobre la preferencia de enrutamiento en direcciones IP públicas.
Configuración de la preferencia de enrutamiento de una VM mediante Azure PowerShell.
 Configuración de la preferencia de enrutamiento para
una dirección IP pública mediante la CLI de Azure
23/09/2020 • 6 minutes to read • Edit Online

En este artículo se muestra cómo configurar las preferencias de enrutamiento a través de la red de ISP (opción de
Internet ) para una dirección IP pública mediante la CLI de Azure. Después de crear la dirección IP pública, puede
asociarla a los siguientes recursos de Azure para el tráfico entrante y saliente de Internet:
Máquina virtual
Conjunto de escalado de máquina virtual
Azure Kubernetes Service (AKS)
Equilibrador de carga accesible desde Internet
Application Gateway
Azure Firewall
De forma predeterminada, la preferencia de enrutamiento de la dirección IP pública se establece en la red global de
Microsoft para todos los servicios de Azure y puede asociarse a cualquier servicio de Azure.

IMPORTANT
La preferencia de enrutamiento se encuentra actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin
Acuerdo de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características
no sean compatibles o que tengan sus funcionalidades limitadas. Para más información, consulte Términos de uso
complementarios de las Versiones Preliminares de Microsoft Azure.

Si no tiene una suscripción a Azure, cree una cuenta gratuita ahora.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si, en su lugar, decide instalar y usar la CLI de Azure en un entorno local, para esta guía de inicio rápido se necesita
la versión 2.0.49 de la CLI de Azure o una versión posterior. Ejecute az --version para buscar la versión instalada.
Consulte Instalación de la CLI de Azure para obtener información sobre la instalación o actualización.

Registro de la característica de la suscripción

La característica de preferencias de enrutamiento se encuentra actualmente en versión preliminar. Registre de la
característica de la suscripción tal como se muestra a continuación:

az feature register --namespace [Link] --name AllowRoutingPreferenceFeature

Crear un grupo de recursos

Para crear un grupo de recursos, use el comando az group create. En el siguiente ejemplo se crea un grupo de
recursos en la región Este de EE. UU. de Azure:

az group create --name myResourceGroup --location eastus

Crear una dirección IP pública

Cree una dirección IP pública con preferencia de enrutamiento y de tipo "Internet" mediante el comando az
network public-ip create, con el formato que se muestra a continuación.
El siguiente comando crea una nueva dirección IP pública con preferencia de enrutamiento de Internet en la
región de Azure del Este de EE. UU. .

az network public-ip create \

--name MyRoutingPrefIP \
--resource-group MyResourceGroup \
--location eastus \
--ip-tags 'RoutingPreference=Internet' \
--sku STANDARD \
--allocation-method static \
--version IPv4

NOTE
Actualmente, la preferencia de enrutamiento solo admite direcciones IP públicas IPV4.

Puede asociar la dirección IP pública creada anteriormente con una máquina virtual de Windows o Linux. Use la
sección CLI en la siguiente página del tutorial: asociación de una dirección IP pública a una máquina virtual para
asociar la dirección IP pública a la VM. Asimismo, puede asociar una dirección IP pública que haya creado con
anterioridad con una instancia de Azure Load Balancer asignándola a la configuración de front-end del
equilibrador de carga. La dirección IP pública actúa como dirección IP virtual (VIP) de carga equilibrada.
Pasos siguientes
Obtenga más información sobre la preferencia de enrutamiento en direcciones IP públicas.
Configure la preferencia de enrutamiento de una VM mediante la CLI de Azure.
 Configuración de la preferencia de enrutamiento de
una VM mediante Azure Portal
23/09/2020 • 5 minutes to read • Edit Online

En este artículo se muestra cómo configurar las preferencias de enrutamiento para una máquina virtual. El tráfico
de Internet enlazado desde la VM se enrutará a través de la red del ISP cuando elija Internet como opción de
preferencia de enrutamiento. El enrutamiento predeterminado se hará a través de la red global de Microsoft.
En este artículo se muestra cómo crear una máquina virtual con una dirección IP pública que esté configurada para
enrutar el tráfico a través de la red pública de Internet mediante Azure Portal.

IMPORTANT
La preferencia de enrutamiento se encuentra actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin
Acuerdo de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características
no sean compatibles o que tengan sus funcionalidades limitadas. Para más información, consulte Términos de uso
complementarios de las Versiones Preliminares de Microsoft Azure.

Registro de la característica de la suscripción

La característica de preferencias de enrutamiento se encuentra actualmente en versión preliminar. Debe registrar la
característica de la suscripción mediante Azure PowerShell, tal como se indica a continuación:

Register-AzProviderFeature -FeatureName AllowRoutingPreferenceFeature ProviderNamespace [Link]

Inicio de sesión en Azure

Inicie sesión en Azure Portal.

Creación de una máquina virtual

1. Seleccione + Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Proceso y, luego, Máquina vir tual de Windows Ser ver 2016 u otro sistema operativo de su
elección.
3. Escriba o seleccione la siguiente información, acepte los valores predeterminados para el resto de la
configuración y luego seleccione Aceptar :

C O N F IGURA C IÓ N VA L UE

Nombre myVM

Nombre de usuario Escriba un nombre de usuario de su elección.

Contraseña Escriba una contraseña de su elección. La contraseña debe

tener al menos 12 caracteres de largo y cumplir con los
requisitos de complejidad definidos.
 C O N F IGURA C IÓ N VA L UE

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y, a continuación,

myResourceGroup .

Location Seleccione Este de EE. UU .

4. Seleccione un tamaño para la máquina virtual y luego Seleccionar .

5. En la pestaña de redes , haga clic en Crear nueva para crear una dirección IP pública .
6. Escriba myPublicIpAddress, seleccione una SKU como estándar y, a continuación, seleccione Internet
como preferencia de enrutamiento; una vez hecho esto, presione Aceptar , tal como se muestra en la
siguiente imagen:

7. Seleccione un puerto o ningún puerto en Seleccionar puer tos de entrada públicos . Se selecciona el
puerto 3389 para permitir el acceso remoto a la máquina virtual Windows Server desde Internet. No se
recomienda abrir el puerto 3389 desde Internet con cargas de trabajo de producción.

8. Acepte los valores predeterminados restantes y seleccione Aceptar .

9. En la página Resumen , seleccione Crear . La máquina virtual tarda minutos en crearse.
10. Una vez implementada la máquina virtual, escriba myPublicIpAddress en el cuadro de búsqueda de la parte
superior del portal. Cuando myPublicIpAddress aparezca en los resultados de búsqueda, selecciónela.
11. Puede ver la dirección IP pública asignada, y que la dirección se asigna a la máquina virtual myVM , como se
muestra en la siguiente imagen:
12. Seleccione Redes y haga clic en el valor NIC mynic ; a continuación, seleccione la dirección IP pública para
confirmar que la preferencia de enrutamiento está asignada como Internet .

Limpieza de recursos
Cuando ya no sea necesario, elimine el grupo de recursos y todos los recursos que contiene:
1. Escriba myResourceGroup en el cuadro Buscar que se encuentra en la parte superior del portal. Seleccione
myResourceGroup cuando lo vea en los resultados de la búsqueda.
2. Seleccione Eliminar grupo de recursos .
3. Escriba myResourceGroup para ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS: y seleccione Eliminar .

Pasos siguientes
Obtenga más información sobre las direcciones IP públicas con preferencia de enrutamiento.
Obtenga más información acerca de las direcciones IP públicas en Azure.
Obtenga más información acerca de toda la configuración de direcciones IP públicas.
 Configuración de la preferencia de enrutamiento de
una VM mediante Azure PowerShell
23/09/2020 • 6 minutes to read • Edit Online

En este artículo se muestra cómo configurar las preferencias de enrutamiento para una máquina virtual. El tráfico
de Internet enlazado desde la VM se enrutará a través de la red del ISP cuando elija Internet como opción de
preferencia de enrutamiento. El enrutamiento predeterminado se hará a través de la red global de Microsoft.
En este artículo se muestra cómo crear una máquina virtual con una dirección IP pública que esté configurada
para enrutar el tráfico a través de la red ISP mediante Azure PowerShell.

IMPORTANT
La preferencia de enrutamiento se encuentra actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin
Acuerdo de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características
no sean compatibles o que tengan sus funcionalidades limitadas. Para más información, consulte Términos de uso
complementarios de las Versiones Preliminares de Microsoft Azure.

Registro de la característica de la suscripción

La característica de preferencias de enrutamiento se encuentra actualmente en versión preliminar. Registre de la
característica de la suscripción tal como se muestra a continuación:

Register-AzProviderFeature -FeatureName AllowRoutingPreferenceFeature -ProviderNamespace [Link]

Crear un grupo de recursos

1. Si usa Cloud Shell, continúe al paso 2. Abra una sesión de comandos e inicie sesión en Azure con
Connect-AzAccount .

2. Cree un grupo de recursos con el comando New-AzResourceGroup. En el siguiente ejemplo se crea un

grupo de recursos en la región Este de EE. UU. de Azure:

$rg = New-AzResourceGroup -Name MyResourceGroup -Location EastUS

Crear una dirección IP pública

Para obtener acceso a las máquinas virtuales desde Internet, necesita tener direcciones IP públicas. Cree las
direcciones IP públicas con New-AzPublicIpAddress. En el ejemplo siguiente se crea una dirección IP pública IPv4
denominada MyPublicIP con una preferencia de enrutamiento de tipo Internet en el grupo de recursos
MyResourceGroup en la región de Este de EE. UU. :
 $iptagtype="RoutingPreference"
$tagName = "Internet"
$ipTag = New-AzPublicIpTag -IpTagType $iptagtype -Tag $tagName
# attach the tag
$publicIp = New-AzPublicIpAddress `
-Name "MyPublicIP" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-IpTag $ipTag `
-AllocationMethod Static `
-Sku Standard `
-IpAddressVersion IPv4

Crear recursos de red

Antes de implementar una VM, debe crear recursos de red compatibles, como un grupo de seguridad de red, una
red virtual y un NIC virtual.
Crear un grupo de seguridad de red
Cree un grupo de seguridad de red con New-AzNetworkSecurityGroup. En el ejemplo siguiente se crea un NSG
denominado myNSG.

$nsg = New-AzNetworkSecurityGroup `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "myNSG"

Creación de una red virtual

Cree una red virtual con New-AzVirtualNetwork. En el ejemplo siguiente se crea una red virtual denominada
myVnet con mySubnet:
Creación de una subred

$subnet = New-AzVirtualNetworkSubnetConfig `
-Name "mySubnet" `
-AddressPrefix "[Link]/24"

# Create a virtual network

$vnet = New-AzVirtualNetwork `
-ResourceGroupName $[Link] `
-Location $[Link] `
-Name "myVNET" `
-AddressPrefix "[Link]/16" `
-Subnet $subnet

Creación de un NIC
Cree NIC virtuales con [New-AzNetworkInterface](/powershell/module/[Link]/new-aznetworkinterface. En el
ejemplo siguiente se crea un NIC virtual.
 # Create an IP Config
$ipconfig=New-AzNetworkInterfaceIpConfig `
-Name myIpConfig `
-Subnet $[Link][0] `
-PrivateIpAddressVersion IPv4 `
-PublicIpAddress $publicIp

# Create a NIC
$nic = New-AzNetworkInterface `
-Name "mynic" `
-ResourceGroupName $[Link] `
-Location $[Link] `
-NetworkSecurityGroupId $[Link] `
-IpConfiguration $ipconfig

Creación de una máquina virtual

Establezca un nombre de usuario de administrador y una contraseña para las máquinas virtuales con Get-
Credential:

$cred = get-credential -Message "Routing Preference SAMPLE: Please enter the Administrator credential to log
into the VM."

Ahora puede crear la máquina virtual con New-AzVM. En el ejemplo siguiente, se crean dos máquinas virtuales y
los componentes de red virtual necesarios, si aún no existen.

$vmsize = "Standard_A2"
$ImagePublisher = "MicrosoftWindowsServer"
$imageOffer = "WindowsServer"
$imageSKU = "2019-Datacenter"

$vmName= "myVM"
$vmconfig = New-AzVMConfig -VMName $vmName -VMSize $vmsize | Set-AzVMOperatingSystem -Windows -ComputerName
$vmName -Credential $cred -ProvisionVMAgent -EnableAutoUpdate | Set-AzVMSourceImage -PublisherName
$ImagePublisher -Offer $imageOffer -Skus $imageSKU -Version "latest" | Set-AzVMOSDisk -Name "$[Link]" -
CreateOption "FromImage" | Add-AzVMNetworkInterface -Id $[Link]
$VM1 = New-AzVM -ResourceGroupName $[Link] -Location $[Link] -VM $vmconfig

Permitir tráfico de red en la VM

Para poder conectarse a la dirección IP pública desde Internet, asegúrese de que tiene los puertos necesarios
abiertos en cualquier grupo de seguridad de red que haya asociado a la interfaz de red o la subred en la que se
encuentra la interfaz de red. Puede ver las reglas de seguridad vigentes para una interfaz de red y su subred
mediante Portal, la CLI o PowerShell.

Limpieza de recursos
Cuando ya no se necesiten, puede usar el comando Remove-AzResourceGroup para quitar el grupo de recursos, la
máquina virtual y todos los recursos relacionados.

Remove-AzResourceGroup -Name MyResourceGroup

Pasos siguientes
Obtenga más información sobre la preferencia de enrutamiento en direcciones IP públicas.
Obtenga más información acerca de las direcciones IP públicas en Azure.
Obtenga más información sobre la configuración de las direcciones IP públicas.
 Configuración de la preferencia de enrutamiento de
una VM mediante la CLI de Azure
23/09/2020 • 5 minutes to read • Edit Online

En este artículo se muestra cómo configurar las preferencias de enrutamiento para una máquina virtual. El tráfico
de Internet enlazado desde la VM se enrutará a través de la red del ISP cuando elija Internet como opción de
preferencia de enrutamiento. El enrutamiento predeterminado se hará a través de la red global de Microsoft.
En este artículo se muestra cómo crear una máquina virtual con una dirección IP pública que esté configurada
para enrutar el tráfico a través de la red pública de Internet mediante la CLI de Azure.

IMPORTANT
La preferencia de enrutamiento se encuentra actualmente en versión preliminar pública. Esta versión preliminar se ofrece sin
Acuerdo de Nivel de Servicio y no se recomienda para cargas de trabajo de producción. Es posible que algunas características
no sean compatibles o que tengan sus funcionalidades limitadas. Para más información, consulte Términos de uso
complementarios de las Versiones Preliminares de Microsoft Azure.

Registro de la característica de la suscripción

La característica de preferencias de enrutamiento se encuentra actualmente en versión preliminar. Registre de la
característica de la suscripción tal como se muestra a continuación:

az feature register --namespace [Link] --name AllowRoutingPreferenceFeature

Crear un grupo de recursos

1. Si usa Cloud Shell, continúe al paso 2. Abra una sesión de comandos e inicie sesión en Azure con az login .
2. Para crear un grupo de recursos, use el comando az group create. En el siguiente ejemplo se crea un grupo
de recursos en la región Este de EE. UU. de Azure:

az group create --name myResourceGroup --location eastus

Crear una dirección IP pública

Para obtener acceso a las máquinas virtuales desde Internet, necesita crear una dirección IP pública. Cree una
dirección IP pública con az network public-ip create. En el ejemplo siguiente se crea una dirección IP pública con
una preferencia de enrutamiento de tipo Internet en la región del Este de EE. UU. :

az network public-ip create \

--name MyRoutingPrefIP \
--resource-group MyResourceGroup \
--location eastus \
--ip-tags 'RoutingPreference=Internet' \
--sku STANDARD \
--allocation-method static \
--version IPv4
Crear recursos de red
Antes de implementar una VM, debe crear recursos de red compatibles, como un grupo de seguridad de red, una
red virtual y un NIC virtual.
Crear un grupo de seguridad de red
Cree un grupo de seguridad de red para las reglas que van a controlar la comunicación entrante y saliente de la
red virtual con az network nsg create.

az network nsg create \

--name myNSG \
--resource-group MyResourceGroup \
--location eastus

Creación de una red virtual

Cree la red virtual con el comando az network vnet create. En el ejemplo siguiente se crea una red virtual
denominada myVnet con las subredes mySubnet:

# Create a virtual network

az network vnet create \
--name myVNET \
--resource-group MyResourceGroup \
--location eastus

# Create a subnet
az network vnet subnet create \
--name mySubNet \
--resource-group MyResourceGroup \
--vnet-name myVNET \
--address-prefixes "[Link]/24" \
--network-security-group myNSG

Creación de un NIC
Cree un NIC virtual para la VM con az network nic create. En el ejemplo siguiente se crea un NIC virtual, que se
conectará a la VM.

# Create a NIC
az network nic create \
--name mynic \
--resource-group MyResourceGroup \
--network-security-group myNSG \
--vnet-name myVNET \
--subnet mySubNet \
--private-ip-address-version IPv4 \
--public-ip-address MyRoutingPrefIP

Creación de una máquina virtual

Cree la máquina virtual con az vm create. En el ejemplo siguiente, se crea una VM de Windows Server 2019 y los
componentes de red virtual necesarios, si aún no existen.
 az vm create \
--name myVM \
--resource-group MyResourceGroup \
--nics mynic \
--size Standard_A2 \
--image MicrosoftWindowsServer:WindowsServer:2019-Datacenter:latest \
--admin-username myUserName

Limpieza de recursos
Cuando ya no se necesiten, puede utilizar az group delete para eliminar el grupo de recursos y todos los recursos
que contenga:

az group delete --name myResourceGroup --yes

Pasos siguientes
Obtenga más información sobre la preferencia de enrutamiento en direcciones IP públicas.
Obtenga más información acerca de las direcciones IP públicas en Azure.
Obtenga más información sobre la configuración de las direcciones IP públicas.
 Tutorial: Filtrado del tráfico de red con un grupo de
seguridad de red mediante Azure Portal
23/09/2020 • 15 minutes to read • Edit Online

Puede filtrar el tráfico de red entrante y saliente de una subred de una red virtual con un grupo de seguridad
de red. Los grupos de seguridad de red contienen reglas de seguridad que filtran el tráfico de red por dirección
IP, puerto y protocolo. Las reglas de seguridad se aplican a los recursos implementados en una subred. En este
tutorial, aprenderá a:
Crear un grupo de seguridad de red y reglas de seguridad
Crear una red virtual y asociar un grupo de seguridad de red a una subred
Implementar máquinas virtuales (VM) en una subred
Probar los filtros de tráfico
Si lo prefiere, puede completar este tutorial con la CLI de Azure o Azure PowerShell.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Inicio de sesión en Azure

Inicie sesión en Azure Portal en [Link]

Creación de una red virtual

1. En el menú de Azure Portal o en la página principal , seleccione Crear un recurso .
2. Seleccione Redes y Red vir tual .
3. Escriba o seleccione la siguiente información, acepte los valores predeterminados para el resto de la
configuración y luego seleccione Crear :

C O N F IGURA C IÓ N VA L UE

Nombre myVirtualNetwork

Espacio de direcciones [Link]/16

Subscription Seleccione su suscripción.

Resource group Haga clic en Crear nuevo y escriba myResourceGroup.

Location Seleccione Este de EE. UU .

Nombre de subred mySubnet

Subred: intervalo de direcciones [Link]/24

Creación de grupos de seguridad de aplicaciones

Un grupo de seguridad de aplicaciones permite agrupar servidores con funciones similares, como servidores
web.
1. En el menú de Azure Portal o en la página principal , seleccione Crear un recurso .
2. En el cuadro Buscar en Marketplace , escriba Grupo de seguridad de aplicaciones. Cuando Grupo de
seguridad de aplicaciones aparezca en los resultados de la búsqueda, selecciónelo, vuelva a
seleccionar Grupo de seguridad de aplicaciones en Todo y, después, haga clic en Crear .
3. Especifique o seleccione los siguientes datos y haga clic en Crear :

C O N F IGURA C IÓ N VA L UE

Nombre myAsgWebServers

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y después seleccione

myResourceGroup .

Location Este de EE. UU.

4. Complete el paso 3 de nuevo, especificando los valores siguientes:

C O N F IGURA C IÓ N VA L UE

Nombre myAsgMgmtServers

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y después seleccione

myResourceGroup .

Location Este de EE. UU.

Crear un grupo de seguridad de red

1. En el menú de Azure Portal o en la página principal , seleccione Crear un recurso .
2. Seleccione Redes y Grupo de seguridad de red .
3. Especifique o seleccione los siguientes datos y haga clic en Crear :

C O N F IGURA C IÓ N VA L UE

Nombre myNsg

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y después seleccione

myResourceGroup.

Location Este de EE. UU.

Asociación del grupo de seguridad de red a la subred

1. En el cuadro Search resources, services, and docs (Buscar en recursos, servicios y documentos) en la
parte superior del portal, comience a escribir myNsg. Cuando myNsg aparezca en los resultados de
búsqueda, selecciónelo.
2. En CONFIGURACIÓN , seleccione Subredes y, luego, + Asociar , como se muestra en la imagen
siguiente:

3. En Asociar subred , seleccione Red vir tual y myVir tualNetwork . Seleccione Subred , MySubnet y, a
continuación, Aceptar .

Creación de reglas de seguridad

1. Seleccione CONFIGURACIÓN , Reglas de seguridad de entrada y, después, + Agregar , tal como se
muestra en la imagen siguiente:

2. Cree una regla de seguridad que permita a los puertos 80 y 443 para el grupo de seguridad de la
aplicación myAsgWebSer vers . En Agregar regla de seguridad de entrada , escriba o seleccione
los valores siguientes, acepte el resto de valores predeterminados y, después, seleccione Agregar :
 C O N F IGURA C IÓ N VA L UE

Destination Seleccione Grupo de seguridad de la aplicación y, a

continuación, seleccione myAsgWebSer vers para
Grupo de seguridad de la aplicación .

Intervalos de puertos de destino Escriba 80,443

Protocolo Selección de TCP

Nombre Allow-Web-All

3. Repita el paso 2 de nuevo, utilizando los siguientes valores:

C O N F IGURA C IÓ N VA L UE

Destination Seleccione Grupo de seguridad de la aplicación y, a

continuación, seleccione myAsgMgmtSer vers para
Grupo de seguridad de la aplicación .

Intervalos de puertos de destino Escriba 3389

Protocolo Selección de TCP

Priority Escriba 110

Nombre Allow-RDP-All (Permitir-RDP-Todo)

En este tutorial, se expone RDP (puerto 3389) a Internet para la máquina virtual que se asigna al grupo
de seguridad de la aplicación myAsgMgmtServers. En entornos de producción, en lugar de exponer el
puerto 3389 a Internet, se recomienda conectarse a los recursos de Azure que desee administrar
mediante una VPN o una conexión de red privada.
Una vez completados los pasos 1 a 3, revise las reglas creadas. La lista debe ser similar a la que aparece en la
siguiente imagen:

Creación de máquinas virtuales

Cree dos máquinas virtuales en la red virtual.
Creación de la primera máquina virtual
1. En el menú de Azure Portal o en la página principal , seleccione Crear un recurso .
2. Seleccione Compute y, después, seleccione Windows Ser ver 2016 Datacenter .
3. Escriba o seleccione la siguiente información y acepte los valores predeterminados para el resto de la
 configuración:

C O N F IGURA C IÓ N VA L UE

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y, a continuación,

myResourceGroup .

Nombre myVmWeb

Location Seleccione Este de EE. UU .

Nombre de usuario Escriba un nombre de usuario de su elección.

Contraseña Escriba una contraseña de su elección. La contraseña

debe tener al menos 12 caracteres de largo y cumplir
con los requisitos de complejidad definidos.

4. Seleccione un tamaño para la máquina virtual y luego Seleccionar .

5. En Redes , seleccione los valores siguientes y acepte los valores predeterminados restantes:

C O N F IGURA C IÓ N VA L UE

Virtual network Seleccione myVir tualNetwork .

Grupo de seguridad de red de NIC Seleccione Ninguno .

6. Seleccione Revisar y crear en la esquina inferior izquierda y seleccione Crear para iniciar la
implementación de la máquina virtual.
Creación de la segunda máquina virtual
Complete de nuevo los pasos 1 a 6, pero recuerde que, en el paso 3, debe nombrar la máquina virtual
myVmMgmt. La maquina virtual tarda unos minutos en implementarse. No continúe con el paso siguiente
hasta que se implemente la máquina virtual.

Asociación de interfaces de red a un ASG

Cuando el portal creó las máquinas virtuales, se creó también una interfaz de red para cada una y la interfaz de
red se asoció a la máquina virtual. Agregue la interfaz de red para cada máquina virtual a uno de los grupos de
seguridad de la aplicación que creó anteriormente:
1. En el cuadro Search resources, services, and docs (Buscar en recursos, servicios y documentos) en la
parte superior del portal, comience a escribir myVmWeb. Cuando la máquina virtual myVmWeb
aparezca en los resultados de búsqueda, selecciónela.
2. En CONFIGURACIÓN , seleccione Redes . Seleccione Configure the application security groups
(Configurar los grupos de seguridad de la aplicación), seleccione myAsgWebSer vers para Grupos de
seguridad de la aplicación y, a continuación, seleccione Guardar , tal y como se muestra en la
siguiente imagen:
3. Complete los pasos 1 y 2 de nuevo, buscando la máquina virtual myVmMgmt y seleccionando el ASG
myAsgMgmtSer vers .

Probar los filtros de tráfico

1. Conéctese a la máquina virtual myVmMgmt. Escriba myVmMgmt en el cuadro de búsqueda que se
encuentra en la parte superior del portal. Seleccione myVmMgmt cuando aparezca en los resultados
de la búsqueda. Seleccione el botón Conectar .
2. Seleccione Descargar archivo RDP .
3. Abra el archivo RDP descargado y seleccione Conectar . Escriba el nombre de usuario y la contraseña
que especificó al crear la máquina virtual. Puede que deba seleccionar More choices (Más opciones) y,
luego, Use a different account (Usar una cuenta diferente), para especificar las credenciales que
escribió al crear la máquina virtual.
4. Seleccione Aceptar .
5. Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Si recibe la
advertencia, seleccione Sí o Continuar para continuar con la conexión.
La conexión se realiza correctamente porque el puerto 3389 tiene permitida la entrada desde Internet al
grupo de seguridad de aplicaciones myAsgMgmtServers en el que se encuentra la interfaz de red
conectada a la máquina virtual myVmMgmt.
6. Para conectarse a la máquina virtual myVmWeb desde la máquina virtual myVmMgmt, escriba el
siguiente comando en una sesión de PowerShell:

mstsc /v:myVmWeb

Es posible conectarse a la máquina virtual myVmWeb desde la máquina virtual myVmMgmt porque las
máquinas virtuales de la misma red virtual pueden comunicarse entre sí a través de cualquier puerto,
de forma predeterminada. Sin embargo, no es posible crear una conexión de escritorio remoto con la
máquina virtual myVmWeb desde Internet porque la regla de seguridad para myAsgWebServers no
permite el puerto 3389 de entrada desde Internet y, de forma predeterminada, al tráfico de entrada
desde Internet se le deniegan todos los recursos.
7. Para instalar Microsoft IIS en la máquina virtual myVmWeb use el siguiente comando desde una sesión
de PowerShell en la máquina virtual myVmWeb:

Install-WindowsFeature -name Web-Server -IncludeManagementTools

8. Una vez completada la instalación de IIS, desconecte la sesión de la máquina virtual myVmWeb, lo que
le deja en la conexión de escritorio remoto de la máquina virtual myVmMgmt.
 9. Desconéctese de la máquina virtual myVmMgmt.
10. En el cuadro Search resources, services, and docs (Buscar recursos, servicios y documentos) en la parte
superior de Azure Portal, comience a escribir myVmWeb desde su equipo. Cuando aparezca
myVmWeb en los resultados de búsqueda, selecciónelo. Anote la Dirección IP pública de la máquina
virtual. La dirección que aparece en la siguiente imagen es [Link], pero su dirección es diferente:

11. Para confirmar que tiene acceso al servidor web myVmWeb desde Internet, abra un explorador de
Internet en el equipo y vaya a [Link] . Ve la pantalla de
bienvenida de IIS, porque el puerto 80 tiene permitida la entrada desde Internet al grupo de seguridad
de aplicaciones myAsgWebServers en el que se encuentra la interfaz de red conectada a la máquina
virtual myVmWeb.

Limpieza de recursos
Cuando ya no sea necesario, elimine el grupo de recursos y todos los recursos que contiene:
1. Escriba myResourceGroup en el cuadro Buscar que se encuentra en la parte superior del portal. Seleccione
myResourceGroup cuando lo vea en los resultados de la búsqueda.
2. Seleccione Eliminar grupo de recursos .
3. Escriba myResourceGroup para ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS: y seleccione
Eliminar .

Pasos siguientes
En este tutorial, ha creado un grupo de seguridad de red y lo ha asociado a una subred de una red virtual. Para
más información acerca de los grupos de seguridad de red, consulte Introducción a los grupos de seguridad de
red y Administración de un grupo de seguridad de red.
De forma predeterminada, Azure enruta el tráfico entre subredes. En su lugar, puede elegir enrutar el tráfico
entre subredes a través de una máquina virtual, que actúa como un firewall, por ejemplo. Para aprender a crear
una tabla de rutas, avance al siguiente tutorial.
Creación de una tabla de rutas
 Filtrado del tráfico de red con un grupo de
seguridad de red mediante PowerShell
23/09/2020 • 15 minutes to read • Edit Online

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.

Puede filtrar el tráfico de red entrante y saliente de una subred de una red virtual con un grupo de seguridad de
red. Los grupos de seguridad de red contienen reglas de seguridad que filtran el tráfico de red por dirección IP,
puerto y protocolo. Las reglas de seguridad se aplican a los recursos implementados en una subred. En este
artículo aprenderá a:
Crear un grupo de seguridad de red y reglas de seguridad
Crear una red virtual y asociar un grupo de seguridad de red a una subred
Implementar máquinas virtuales (VM) en una subred
Probar los filtros de tráfico
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar PowerShell de forma local, para realizar los pasos de este artículo necesita la versión 1.0.0
del módulo de Azure PowerShell o cualquier versión posterior. Ejecute Get-Module -ListAvailable Az para buscar
la versión instalada. Si necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se
ejecuta localmente, también debe ejecutar Connect-AzAccount para crear una conexión con Azure.

Crear un grupo de seguridad de red

Un grupo de seguridad de red contiene reglas de seguridad. Las reglas de seguridad especifican un origen y
destino. Los orígenes y destinos pueden ser grupos de seguridad de aplicaciones.
Creación de grupos de seguridad de aplicaciones
En primer lugar, cree un grupo para todos los recursos generados en este artículo con New-AzResourceGroup. En
el ejemplo siguiente se crea un grupo de recursos en la ubicación eastus:

New-AzResourceGroup -ResourceGroupName myResourceGroup -Location EastUS

Cree un grupo de seguridad de aplicaciones con New-AzApplicationSecurityGroup. Un grupo de seguridad de

aplicaciones permite agrupar servidores con requisitos de filtrado de puertos similar. El ejemplo siguiente crea dos
grupos de seguridad de aplicaciones.

$webAsg = New-AzApplicationSecurityGroup `
-ResourceGroupName myResourceGroup `
-Name myAsgWebServers `
-Location eastus

$mgmtAsg = New-AzApplicationSecurityGroup `
-ResourceGroupName myResourceGroup `
-Name myAsgMgmtServers `
-Location eastus

Creación de reglas de seguridad

Cree una regla de seguridad con New-AzNetworkSecurityRuleConfig. En el ejemplo siguiente se crea una regla
que permite el tráfico entrante desde Internet al grupo de seguridad de aplicaciones myWebServers a través de
los puertos 80 y 443:
 $webRule = New-AzNetworkSecurityRuleConfig `
-Name "Allow-Web-All" `
-Access Allow `
-Protocol Tcp `
-Direction Inbound `
-Priority 100 `
-SourceAddressPrefix Internet `
-SourcePortRange * `
-DestinationApplicationSecurityGroupId $[Link] `
-DestinationPortRange 80,443

The following example creates a rule that allows traffic inbound from the internet to the *myMgmtServers*
application security group over port 3389:

$mgmtRule = New-AzNetworkSecurityRuleConfig `
-Name "Allow-RDP-All" `
-Access Allow `
-Protocol Tcp `
-Direction Inbound `
-Priority 110 `
-SourceAddressPrefix Internet `
-SourcePortRange * `
-DestinationApplicationSecurityGroupId $[Link] `
-DestinationPortRange 3389

En este artículo, se expone RDP (puerto 3389) a Internet para la máquina virtual myAsgMgmtServers. Para
entornos de producción, en lugar de exponer el puerto 3389 a Internet, se recomienda conectarse a los recursos
de Azure que desea administrar mediante una VPN o una conexión de red privada.
Crear un grupo de seguridad de red
Cree un grupo de seguridad de red con New-AzNetworkSecurityGroup. En el ejemplo siguiente se crea un grupo
de seguridad de red llamado myNsg:

$nsg = New-AzNetworkSecurityGroup `
-ResourceGroupName myResourceGroup `
-Location eastus `
-Name myNsg `
-SecurityRules $webRule,$mgmtRule

Creación de una red virtual

Cree una red virtual con New-AzVirtualNetwork. En el ejemplo siguiente se crea una red virtual llamada
myVirtualNetwork:

$virtualNetwork = New-AzVirtualNetwork `
-ResourceGroupName myResourceGroup `
-Location EastUS `
-Name myVirtualNetwork `
-AddressPrefix [Link]/16

Cree una configuración de subred con New-AzVirtualNetworkSubnetConfig y escríbala en la red virtual con Set-
AzVirtualNetwork. En el ejemplo siguiente se agrega una subred llamada mySubnet a la red virtual y se asocia el
grupo de seguridad de red myNsg a dicha subred:
 Add-AzVirtualNetworkSubnetConfig `
-Name mySubnet `
-VirtualNetwork $virtualNetwork `
-AddressPrefix "[Link]/24" `
-NetworkSecurityGroup $nsg
$virtualNetwork | Set-AzVirtualNetwork

Creación de máquinas virtuales

Antes de crear las máquinas virtuales, recupere el objeto de red virtual con la subred mediante Get-
AzVirtualNetwork:

$virtualNetwork = Get-AzVirtualNetwork `
-Name myVirtualNetwork `
-Resourcegroupname myResourceGroup

Cree una dirección IP pública para cada máquina virtual con New-AzPublicIpAddress:

$publicIpWeb = New-AzPublicIpAddress `
-AllocationMethod Dynamic `
-ResourceGroupName myResourceGroup `
-Location eastus `
-Name myVmWeb

$publicIpMgmt = New-AzPublicIpAddress `
-AllocationMethod Dynamic `
-ResourceGroupName myResourceGroup `
-Location eastus `
-Name myVmMgmt

Cree dos interfaces de red con New-AzNetworkInterface y asigne una dirección IP pública a la interfaz de red. En el
ejemplo siguiente se crea una interfaz de red, se asocia la dirección IP pública myVmWeb y se convierte en un
miembro del grupo de seguridad de aplicaciones myAsgWebServers:

$webNic = New-AzNetworkInterface `
-Location eastus `
-Name myVmWeb `
-ResourceGroupName myResourceGroup `
-SubnetId $[Link][0].Id `
-ApplicationSecurityGroupId $[Link] `
-PublicIpAddressId $[Link]

En el ejemplo siguiente se crea una interfaz de red, se asocia la dirección IP pública myVmMgmt y se convierte en
un miembro del grupo de seguridad de aplicaciones myAsgWebServers:

$mgmtNic = New-AzNetworkInterface `
-Location eastus `
-Name myVmMgmt `
-ResourceGroupName myResourceGroup `
-SubnetId $[Link][0].Id `
-ApplicationSecurityGroupId $[Link] `
-PublicIpAddressId $[Link]

Cree dos máquinas virtuales en la red virtual para que pueda validar el filtrado de tráfico en un paso posterior.
Cree una configuración de máquina virtual con New-AzVMConfig y, a continuación, cree la máquina virtual con
New-AzVM. En el ejemplo siguiente se crea una máquina virtual que actúa como un servidor web. La opción
-AsJob crea la máquina virtual en segundo plano, por lo tanto, puede continuar con el siguiente paso:

# Create user object

$cred = Get-Credential -Message "Enter a username and password for the virtual machine."

$webVmConfig = New-AzVMConfig `
-VMName myVmWeb `
-VMSize Standard_DS1_V2 | `
Set-AzVMOperatingSystem -Windows `
-ComputerName myVmWeb `
-Credential $cred | `
Set-AzVMSourceImage `
-PublisherName MicrosoftWindowsServer `
-Offer WindowsServer `
-Skus 2016-Datacenter `
-Version latest | `
Add-AzVMNetworkInterface `
-Id $[Link]
New-AzVM `
-ResourceGroupName myResourceGroup `
-Location eastus `
-VM $webVmConfig `
-AsJob

Cree una máquina virtual para que actúe como un servidor de administración:

# Create user object

$cred = Get-Credential -Message "Enter a username and password for the virtual machine."

# Create the web server virtual machine configuration and virtual machine.
$mgmtVmConfig = New-AzVMConfig `
-VMName myVmMgmt `
-VMSize Standard_DS1_V2 | `
Set-AzVMOperatingSystem -Windows `
-ComputerName myVmMgmt `
-Credential $cred | `
Set-AzVMSourceImage `
-PublisherName MicrosoftWindowsServer `
-Offer WindowsServer `
-Skus 2016-Datacenter `
-Version latest | `
Add-AzVMNetworkInterface `
-Id $[Link]
New-AzVM `
-ResourceGroupName myResourceGroup `
-Location eastus `
-VM $mgmtVmConfig

La creación de la máquina virtual tarda algunos minutos. No continúe con el paso siguiente hasta que Azure
finalice la creación de la máquina virtual.

Probar los filtros de tráfico

Use Get-AzPublicIpAddress para devolver la dirección IP pública de una máquina virtual. En el siguiente ejemplo
se devuelve la dirección IP pública de la máquina virtual myVmMgmt:

Get-AzPublicIpAddress `
-Name myVmMgmt `
-ResourceGroupName myResourceGroup `
| Select IpAddress
Use el comando siguiente para crear una sesión de Escritorio remoto con la máquina virtual myVmMgmt desde su
equipo local. Reemplace <publicIpAddress> con la dirección IP que devolvió el comando anterior.

mstsc /v:<publicIpAddress>

Abra el archivo RDP descargado. Cuando se le pida, seleccione Conectar .

Escriba el nombre de usuario y la contraseña que especificó al crear la máquina virtual (puede que deba
seleccionar Más opciones y luego Usar una cuenta diferente , para especificar las credenciales que escribió
cuando creó la máquina virtual). A continuación, seleccione Aceptar . Puede recibir una advertencia de certificado
durante el proceso de inicio de sesión. Seleccione Sí para continuar con la conexión.
La conexión se realiza correctamente porque el puerto 3389 tiene permitida la entrada desde Internet al grupo de
seguridad de aplicaciones myAsgMgmtServers en el que se encuentra la interfaz de red conectada a la máquina
virtual myVmMgmt.
Use el siguiente comando para crear una conexión de escritorio remoto con la máquina virtual myVmWeb desde
la máquina virtual myVmMgmt desde PowerShell:

mstsc /v:myvmWeb

La conexión se realiza correctamente porque una regla de seguridad predeterminada dentro de cada grupo de
seguridad de red permite el tráfico a través de todos los puertos entre todas las direcciones IP de una red virtual.
No es posible crear una conexión de escritorio remoto con la máquina virtual myVmWeb desde Internet porque la
regla de seguridad para myAsgWebServers no permite el puerto 3389 de entrada desde Internet.
Use el siguiente comando para instalar Microsoft IIS en la máquina virtual myVmWeb desde PowerShell:

Install-WindowsFeature -name Web-Server -IncludeManagementTools

Una vez completada la instalación de IIS, desconecte la sesión de la máquina virtual myVmWeb, lo que le deja en
la conexión de escritorio remoto de la máquina virtual myVmMgmt. Para ver la pantalla de bienvenida de IIS, abra
un explorador de Internet y vaya a [Link]
Desconéctese de la máquina virtual myVmMgmt.
En su equipo, escriba el siguiente comando desde PowerShell para recuperar la dirección IP pública del servidor
myVmWeb:

Get-AzPublicIpAddress `
-Name myVmWeb `
-ResourceGroupName myResourceGroup `
| Select IpAddress

Para confirmar que tiene acceso al servidor web myVmWeb desde fuera de Azure, abra un explorador de Internet
en el equipo y vaya a [Link] . La conexión se realiza correctamente
porque el puerto 80 tiene permitida la entrada desde Internet al grupo de seguridad de aplicaciones
myAsgMgmtServers en el que se encuentra la interfaz de red conectada a la máquina virtual myVmWeb.

Limpieza de recursos
Cuando ya no lo necesite, puede usar Remove-AzResourceGroup para quitar el grupo de recursos y todos los
recursos que contiene:
 Remove-AzResourceGroup -Name myResourceGroup -Force

Pasos siguientes
En este artículo, ha creado un grupo de seguridad de red y lo ha asociado a una subred de una red virtual. Para
más información acerca de los grupos de seguridad de red, consulte Introducción a los grupos de seguridad de
red y Administración de un grupo de seguridad de red.
De forma predeterminada, Azure enruta el tráfico entre subredes. En su lugar, puede elegir enrutar el tráfico entre
subredes a través de una máquina virtual, que actúa como un firewall, por ejemplo. Para obtener información
sobre cómo hacerlo, consulte Creación de una tabla de rutas.
 Filtrado del tráfico de red con un grupo de
seguridad de red mediante la CLI de Azure
23/09/2020 • 14 minutes to read • Edit Online

Puede filtrar el tráfico de red entrante y saliente de una subred de una red virtual con un grupo de seguridad de
red. Los grupos de seguridad de red contienen reglas de seguridad que filtran el tráfico de red por dirección IP,
puerto y protocolo. Las reglas de seguridad se aplican a los recursos implementados en una subred. En este
artículo aprenderá a:
Crear un grupo de seguridad de red y reglas de seguridad
Crear una red virtual y asociar un grupo de seguridad de red a una subred
Implementar máquinas virtuales (VM) en una subred
Probar los filtros de tráfico
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar la CLI localmente, para este artículo es preciso que ejecute la versión 2.0.28 o posterior de
la CLI de Azure. Para encontrar la versión, ejecute az --version . Si necesita instalarla o actualizarla, vea Instalación
de la CLI de Azure.
Crear un grupo de seguridad de red
Un grupo de seguridad de red contiene reglas de seguridad. Las reglas de seguridad especifican un origen y
destino. Los orígenes y destinos pueden ser grupos de seguridad de aplicaciones.
Creación de grupos de seguridad de aplicaciones
En primer lugar, debe crear un grupo de recursos para todos los recursos creados en este artículo con az group
create. En el ejemplo siguiente se crea un grupo de recursos en la ubicación eastus:

az group create \
--name myResourceGroup \
--location eastus

Cree un grupo de seguridad de aplicaciones con az network asg create. Un grupo de seguridad de aplicaciones
permite agrupar servidores con requisitos de filtrado de puertos similar. El ejemplo siguiente crea dos grupos de
seguridad de aplicaciones.

az network asg create \

--resource-group myResourceGroup \
--name myAsgWebServers \
--location eastus

az network asg create \

--resource-group myResourceGroup \
--name myAsgMgmtServers \
--location eastus

Crear un grupo de seguridad de red

Cree un grupo de seguridad de red con az network nsg create. En el ejemplo siguiente se crea un grupo de
seguridad de red llamado myNsg:

# Create a network security group

az network nsg create \
--resource-group myResourceGroup \
--name myNsg

Creación de reglas de seguridad

Cree una regla de seguridad con az network nsg rule create. En el ejemplo siguiente se crea una regla que permite
el tráfico entrante desde Internet al grupo de seguridad de aplicaciones myWebServers a través de los puertos 80
y 443:

az network nsg rule create \

--resource-group myResourceGroup \
--nsg-name myNsg \
--name Allow-Web-All \
--access Allow \
--protocol Tcp \
--direction Inbound \
--priority 100 \
--source-address-prefix Internet \
--source-port-range "*" \
--destination-asgs "myAsgWebServers" \
--destination-port-range 80 443

En el ejemplo siguiente se crea una regla que permite el tráfico entrante desde Internet al grupo de seguridad de
aplicaciones myMgmtServers a través del puerto 22:
 az network nsg rule create \
--resource-group myResourceGroup \
--nsg-name myNsg \
--name Allow-SSH-All \
--access Allow \
--protocol Tcp \
--direction Inbound \
--priority 110 \
--source-address-prefix Internet \
--source-port-range "*" \
--destination-asgs "myAsgMgmtServers" \
--destination-port-range 22

En este artículo, se expone SSH (puerto 22) a Internet para la máquina virtual myAsgMgmtServers. Para entornos
de producción, en lugar de exponer el puerto 22 a Internet, se recomienda conectarse a los recursos de Azure que
desea administrar mediante una VPN o una conexión de red privada.

Creación de una red virtual

Cree la red virtual con el comando az network vnet create. En el ejemplo siguiente se crea una red virtual llamada
myVirtualNetwork:

az network vnet create \

--name myVirtualNetwork \
--resource-group myResourceGroup \
--address-prefixes [Link]/16

Agregue una subred a una red virtual con az network vnet subnet create. En el ejemplo siguiente se agrega una
subred llamada mySubnet a la red virtual y se asocia el grupo de seguridad de red myNsg a dicha subred:

az network vnet subnet create \

--vnet-name myVirtualNetwork \
--resource-group myResourceGroup \
--name mySubnet \
--address-prefix [Link]/24 \
--network-security-group myNsg

Creación de máquinas virtuales

Cree dos máquinas virtuales en la red virtual para que pueda validar el filtrado de tráfico en un paso posterior.
Cree la máquina virtual con az vm create. En el ejemplo siguiente se crea una máquina virtual que actúa como un
servidor web. La opción --asgs myAsgWebServers hace que Azure incluya la interfaz de red que se crea para la
máquina virtual como un miembro del grupo de seguridad de aplicaciones myAsgWebServers.
La opción --nsg "" se especifica para evitar que Azure cree un grupo de seguridad de red predeterminado para
la interfaz de red que Azure crea al generar la máquina virtual. Para simplificar los pasos de este artículo, se usa
una contraseña. Las claves se utilizan habitualmente en las implementaciones de producción. Si utiliza claves,
también debe configurar el agente SSH de reenvío para los pasos restantes. Para más información, consulte la
documentación del cliente SSH. Reemplace <replace-with-your-password> en el siguiente comando por una
contraseña de su elección.
 adminPassword="<replace-with-your-password>"

az vm create \
--resource-group myResourceGroup \
--name myVmWeb \
--image UbuntuLTS \
--vnet-name myVirtualNetwork \
--subnet mySubnet \
--nsg "" \
--asgs myAsgWebServers \
--admin-username azureuser \
--admin-password $adminPassword

La máquina virtual tarda en crearse unos minutos. Una vez creada la máquina virtual, se devuelve una salida
similar a la del siguiente ejemplo:

{
"fqdns": "",
"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/virtualMachines/myVmWeb",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "[Link]",
"publicIpAddress": "[Link]",
"resourceGroup": "myResourceGroup"
}

Anote el valor de publicIpAddress . En un paso posterior, usaremos esta dirección para obtener acceso a la
máquina virtual desde Internet. Cree una máquina virtual para que actúe como un servidor de administración:

az vm create \
--resource-group myResourceGroup \
--name myVmMgmt \
--image UbuntuLTS \
--vnet-name myVirtualNetwork \
--subnet mySubnet \
--nsg "" \
--asgs myAsgMgmtServers \
--admin-username azureuser \
--admin-password $adminPassword

La máquina virtual tarda en crearse unos minutos. Una vez creada la máquina virtual, tome nota de
publicIpAddress en la salida devuelta. Esta dirección se utiliza para acceder a la máquina virtual en el siguiente
paso. No continúe con el paso siguiente hasta que Azure finalice la creación de la máquina virtual.

Probar los filtros de tráfico

Use el siguiente comando para crear una sesión SSH con la máquina virtual myVmMgmt. Reemplace
<publicIpAddress> con la dirección IP pública de la máquina virtual. En el ejemplo anterior, la dirección IP era
[Link].

ssh azureuser@<publicIpAddress>

Cuando se le solicite una contraseña, escriba la que escribió en el artículo de creación de máquinas virtuales.
La conexión se realiza correctamente porque el puerto 22 tiene permitida la entrada desde Internet al grupo de
seguridad de aplicaciones myAsgMgmtServers en el que se encuentra la interfaz de red conectada a la máquina
virtual myVmMgmt.
Utilice el siguiente comando para conectarse mediante SSH a la máquina virtual myVmWeb desde la máquina
virtual myVmMgmt:

ssh azureuser@myVmWeb

La conexión se realiza correctamente porque una regla de seguridad predeterminada dentro de cada grupo de
seguridad de red permite el tráfico a través de todos los puertos entre todas las direcciones IP de una red virtual.
No es posible conectarse mediante SSH a la máquina virtual myVmWeb desde Internet porque la regla de
seguridad para myAsgWebServers no permite el puerto 22 de entrada desde Internet.
Use los siguientes comandos para instalar el servidor web nginx en la máquina virtual myVmWeb:

# Update package source

sudo apt-get -y update

# Install NGINX
sudo apt-get -y install nginx

La máquina virtual myVmWeb tiene permiso de salida a Internet para recuperar nginx porque una regla de
seguridad predeterminada permite todo el tráfico de salida a Internet. Cierre la sesión SSH con myVmWeb, que le
deja en el símbolo del sistema username@myVmMgmt:~$ de la máquina virtual myVmMgmt. Escriba el siguiente
comando para recuperar la pantalla de bienvenida de nginx desde la máquina virtual myVmWeb:

curl myVmWeb

Cierre la sesión de la máquina virtual myVmMgmt. Para confirmar que puede acceder al servidor web myVmWeb
desde fuera de Azure, escriba curl <publicIpAddress> desde su propio equipo. La conexión se realiza
correctamente porque el puerto 80 tiene permitida la entrada desde Internet al grupo de seguridad de
aplicaciones myAsgWebServers en el que se encuentra la interfaz de red conectada a la máquina virtual
myVmWeb.

Limpieza de recursos
Cuando ya no se necesiten, use az group delete para quitar el grupo de recursos y todos los recursos que
contenga.

az group delete --name myResourceGroup --yes

Pasos siguientes
En este artículo, ha creado un grupo de seguridad de red y lo ha asociado a una subred de una red virtual. Para
más información acerca de los grupos de seguridad de red, consulte Introducción a los grupos de seguridad de
red y Administración de un grupo de seguridad de red.
De forma predeterminada, Azure enruta el tráfico entre subredes. En su lugar, puede elegir enrutar el tráfico entre
subredes a través de una máquina virtual, que actúa como un firewall, por ejemplo. Para obtener información
sobre cómo hacerlo, consulte Creación de una tabla de rutas.
 Inicio rápido: Creación de un punto de conexión
privado mediante Azure Portal
23/09/2020 • 14 minutes to read • Edit Online

Un punto de conexión privado es el bloque de creación fundamental para el vínculo privado en Azure. Permite que
los recursos de Azure, como las máquinas virtuales, se comuniquen de manera privada con recursos de vínculos
privados. En este inicio rápido, aprenderá a crear una máquina virtual en una instancia de Azure Virtual Network,
un servidor de SQL Server lógico con un punto de conexión privado de Azure mediante Azure Portal. Después,
puede acceder de forma segura a SQL Database desde la máquina virtual.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Inicio de sesión en Azure

Inicie sesión en Azure Portal en [Link]

Crear una VM
En esta sección, va a crear una red virtual y una subred para hospedar la máquina virtual que se usa para acceder al
recurso de Private Link (un servidor SQL en Azure en este ejemplo).

Red virtual y parámetros

En esta sección, va a crear una red virtual y una subred para hospedar la máquina virtual que se usa para acceder al
recurso de Private Link.
En los pasos de esta sección, tendrá que reemplazar los siguientes parámetros por la siguiente información:

PA RÁ M ET RO VA L UE

<resource-group-name> myResourceGroup

<vir tual-network-name> myVirtualNetwork

<region-name> Centro-Oeste de EE. UU.

<IPv4-address-space> [Link]/16

<subnet-name> mySubnet

<subnet-address-range> [Link]/24

Crear la red virtual

En esta sección, creará una red virtual y una subred.
1. En la parte superior izquierda de la pantalla, seleccione Crear un recurso > Redes > Red vir tual o
busque Red vir tual en el cuadro de búsqueda.
2. En Crear red vir tual , escriba o seleccione esta información en la pestaña Conceptos básicos :
 C O N F IGURA C IÓ N VA LO R

Detalles del proyecto

Suscripción Selección de su suscripción a Azure

Grupo de recursos Seleccione Crear nuevo , escriba <resource-group-

name> , seleccione Aceptar o seleccione un <resource-
group-name> existente basado en parámetros.

Detalles de instancia

Nombre Escriba <vir tual-network-name>

Region Selección de <region-name>

3. Seleccione la pestaña Direcciones IP o el botón Siguiente: Direcciones IP situado en la parte inferior de

la página.
4. En la pestaña Direcciones IP , especifique esta información:

C O N F IGURA C IÓ N VA L UE

Espacio de direcciones IPv4 Escriba <IPv4-address-space>

5. En Nombre de subred , seleccione la palabra predeterminada .

6. En Editar subred , especifique esta información:

C O N F IGURA C IÓ N VA L UE

Nombre de subred Escriba <subnet-name>

Intervalo de direcciones de subred Escriba <subnet-address-range>

7. Seleccione Guardar .
8. Seleccione la pestaña Revisar y crear o el botón Revisar y crear .
9. Seleccione Crear .
Creación de la máquina virtual
1. En la parte superior izquierda de Azure Portal, seleccione Crear un recurso > Proceso > Máquina
vir tual .
2. En Creación de una máquina vir tual: conceptos básicos , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

DETALLES DEL PROYECTO

Subscription Seleccione su suscripción.

Resource group Seleccione myResourceGroup . Lo creó en la sección

anterior.
 C O N F IGURA C IÓ N VA L UE

DETALLES DE INSTANCIA

Nombre de la máquina virtual Escriba myVm.

Region Seleccione WestCentralUS.

Opciones de disponibilidad Deje el valor predeterminado No se requiere

redundancia de la infraestructura .

Imagen Seleccione Windows Ser ver 2019 Datacenter .

Size Deje el valor predeterminado Estándar DS1 v2 .

CUENTA DE ADMINISTRADOR

Nombre de usuario Escriba un nombre de usuario de su elección.

Contraseña Escriba una contraseña de su elección. La contraseña debe

tener al menos 12 caracteres de largo y cumplir con los
requisitos de complejidad definidos.

Confirm Password Vuelva a escribir la contraseña.

REGL AS DE PUERTO DE ENTRADA

Puertos de entrada públicos Deje el valor predeterminado Ninguno .

AHORRE DINERO

¿Ya tiene una licencia de Windows? Deje el valor predeterminado No .

3. Seleccione Siguiente: Discos .

4. En Creación de una máquina vir tual: Discos , deje los valores predeterminados y seleccione Siguiente:
Redes .
5. En Creación de una máquina vir tual: Redes , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Virtual network Deje el valor predeterminado MyVir tualNetwork .

Espacio de direcciones Deje el valor predeterminado [Link]/24 .

Subnet Deje el valor predeterminado mySubnet ([Link]/24) .

Dirección IP pública Deje el valor predeterminado (new) myVm-ip .

Puertos de entrada públicos Seleccione Permitir los puer tos seleccionados .

 C O N F IGURA C IÓ N VA L UE

Selección de puertos de entrada Seleccione HTTP y RDP .

6. Seleccione Revisar + crear . Se le remitirá a la página Revisar y crear , donde Azure validará la
configuración.
7. Cuando reciba el mensaje Validación superada , seleccione Crear .

Creación de un servidor de SQL Server lógico

En esta sección, va a crear un servidor de SQL Server lógico en Azure.
1. En la parte superior izquierda de la pantalla en Azure Portal, seleccione Crear un recurso > Bases de
datos > SQL Database .
2. En Crear SQL Database: Conceptos básicos , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Detalles de la base de datos

Subscription Seleccione su suscripción.

Resource group Seleccione myResourceGroup . Lo creó en la sección

anterior.

DETALLES DE INSTANCIA

Nombre de la base de datos Escriba miBaseDeDatos. Si el nombre ya existe, cree uno

único.

3. En Ser vidor , seleccione Crear nuevo .

4. En Nuevo ser vidor , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Nombre de servidor Escriba miServidor. Si el nombre ya existe, cree uno único.

Inicio de sesión de administrador de servidor Escriba el nombre de administrador que prefiera.

Contraseña Escriba una contraseña de su elección. La contraseña debe

tener al menos ocho caracteres y cumplir con los requisitos
definidos.

Location Seleccione la región de Azure en la que desea que se

encuentre la instancia de SQL Server.

5. Seleccione Aceptar .
6. Seleccione Revisar + crear . Se le remitirá a la página Revisar y crear , donde Azure validará la
configuración.
7. Cuando reciba el mensaje Validación superada, seleccione Crear .
8. Cuando reciba el mensaje Validación superada, seleccione Crear.

Creación de un punto de conexión privado

En esta sección, creará un servidor SQL Server y le agregará un punto de conexión privado.
1. En la parte superior izquierda de la pantalla en Azure Portal, seleccione Crear un recurso > Redes >
Private Link Center (versión preliminar) .
2. En Centro de vínculos privados: Información general , en la opciónBuild a private connection to a
ser vice (Crear una conexión privada a un servicio), seleccione Star t (Iniciar).
3. En Create a private endpoint (Preview) - Basics (Crear un punto de conexión privado [versión
preliminar]: Conceptos básicos), escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Detalles del proyecto

Subscription Seleccione su suscripción.

Resource group Seleccione myResourceGroup . Lo creó en la sección

anterior.

DETALLES DE INSTANCIA

Nombre Escriba myPrivateEndpoint. Si el nombre ya existe, cree

uno único.

Region Seleccione WestCentralUS.

4. Seleccione Siguiente: Resource (Siguiente: Recurso).

5. En Create a private endpoint - Resource (Crear un punto de conexión privado: recurso), escriba o
seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Método de conexión Seleccione Connect to an Azure resource in my directory

(Conectarse a un recurso de Azure en mi directorio).

Subscription Seleccione su suscripción.

Tipo de recurso Seleccione [Link]/ser vers .

Recurso Seleccione miServidor.

Recurso secundario de destino Seleccione sqlServer.

6. Seleccione Siguiente: Configuration (Siguiente: Configuración).

7. En Create a private endpoint (Preview) - Configuración (Crear un punto de conexión privado [versión
 preliminar]: Configuración), escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

REDES

Virtual network Seleccione MyVirtualNetwork.

Subnet Seleccione mySubnet.

INTEGRACIÓN DE DNS PRIVADO

Integración con una zona DNS privada Seleccione Sí.

Zona DNS privada Seleccione (New)[Link]

8. Seleccione Revisar + crear . Se le remitirá a la página Revisar y crear , donde Azure validará la
configuración.
9. Cuando reciba el mensaje Validación superada , seleccione Crear .

Conéctese a una máquina virtual mediante Escritorio remoto (RDP)

Después de crear myVm , conéctese a ella desde Internet como se indica a continuación:
1. En la barra de búsqueda del portal, escriba myVm.
2. Seleccione el botón Conectar . Después de seleccionar el botón Conectar , se abre Conectar a máquina
vir tual .
3. Seleccione Descargar archivo RDP . Azure crea un archivo de Protocolo de Escritorio remoto ( .rdp) y lo
descarga en su equipo.
4. Abra el archivo [Link].
a. Cuando se le pida, seleccione Conectar .
b. Escriba el nombre de usuario y la contraseña que especificó al crear la VM.

NOTE
Es posible que tenga que seleccionar Más opciones > Usar otra cuenta para especificar las credenciales
que escribió al crear la máquina virtual.

5. Seleccione Aceptar .
6. Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Si recibe una advertencia
de certificado, seleccione Sí o Continuar .
7. Una vez que aparezca el escritorio de la máquina virtual, minimícelo para volver a su escritorio local.

Acceso a SQL Database de forma privada desde la máquina virtual

1. En el Escritorio remoto de myVm, abra PowerShell.
2. Escriba nslookup [Link] .
 Recibirá un mensaje similar a este:

Server: UnKnown
Address: [Link]
Non-authoritative answer:
Name: [Link]
Address: [Link]
Aliases: [Link]

3. Instale SQL Server Management Studio.

4. En Conectar con el ser vidor , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Tipo de servidor Seleccione Motor de base de datos .

Nombre de servidor Seleccione [Link].

Nombre de usuario Escriba el nombre de usuario como

username@servername, que se proporciona durante la
creación del servidor SQL Server.

Contraseña Escriba una contraseña proporcionada durante la creación

del servidor SQL Server.

Recordar contraseña Seleccione Sí.

5. Seleccione Conectar .
6. Examine las bases de datos en el menú izquierdo.
7. (Opcionalmente) Cree o consulte la información de mydatabase.
8. Cierre la conexión de Escritorio remoto a myVm.

Limpieza de recursos
Cuando haya terminado mediante el punto de conexión privado, el servidor SQL y la máquina virtual, elimine el
grupo de recursos y todos los recursos que contiene:
1. Escriba myResourceGroup en el cuadro Buscar de la parte superior del portal y seleccione myResourceGroup
en los resultados de búsqueda.
2. Seleccione Eliminar grupo de recursos .
3. Escriba myResourceGroup en ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS y seleccione Eliminar .

Pasos siguientes
En este inicio rápido, ha creado una máquina virtual en una red virtual, un servidor de SQL Server lógico y un
punto de conexión privado para el acceso privado. Se ha conectado a una máquina virtual desde Internet y se ha
comunicado de forma segura con SQL Database mediante Private Link. Para más información sobre los puntos de
conexión privados, consulte ¿Qué es un punto de conexión privado de Azure? .
 Creación de un punto de conexión privado mediante
Azure PowerShell
23/09/2020 • 10 minutes to read • Edit Online

Un punto de conexión privado es el bloque de creación fundamental para el vínculo privado en Azure. Permite que
los recursos de Azure, como las máquinas virtuales, se comuniquen de manera privada con recursos de vínculos
privados.
En este inicio rápido, aprenderá a crear una VM en una instancia de Azure Virtual Network, un servidor de
SQL Server lógico con un punto de conexión privado de Azure mediante Azure PowerShell. Después, puede acceder
de forma segura a SQL Database desde la VM.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.

Crear un grupo de recursos

Para crear los recursos, debe crear un grupo de recursos que hospede la máquina virtual y el punto de conexión
privado con New-AzResourceGroup. En el ejemplo siguiente se crea un grupo de recursos denominado
myResourceGroup en la ubicación WestUS :
 New-AzResourceGroup `
-ResourceGroupName myResourceGroup `
-Location westcentralus

Creación de una red virtual

En esta sección, creará una red virtual y una subred. Después, asociará la subred a la red virtual.
Creación de una red virtual
Cree una red virtual para su punto de conexión privado con New-AzVirtualNetwork. En el ejemplo siguiente se crea
una red virtual llamada MyVirtualNetwork:

$virtualNetwork = New-AzVirtualNetwork `
-ResourceGroupName myResourceGroup `
-Location westcentralus `
-Name myVirtualNetwork `
-AddressPrefix [Link]/16

Adición de una subred

Azure implementa recursos en una subred dentro de una red virtual, por lo que es necesario crear una subred. Cree
una configuración de subred denominada mySubnet con Add-AzVirtualNetworkSubnetConfig. En el ejemplo
siguiente se crea una subred denominada mySubnet con la marca de directiva de la red del punto de conexión
privado establecida en Deshabilitado .

$subnetConfig = Add-AzVirtualNetworkSubnetConfig `
-Name mySubnet `
-AddressPrefix [Link]/24 `
-PrivateEndpointNetworkPoliciesFlag "Disabled" `
-VirtualNetwork $virtualNetwork

Cau t i on

Es fácil confundir el parámetro PrivateEndpointNetworkPoliciesFlagcon otra marca disponible,

PrivateLinkServiceNetworkPoliciesFlag , porque son palabras largas y tienen una apariencia similar. Asegúrese de
que usa el adecuado, PrivateEndpointNetworkPoliciesFlag .
Asociación de la subred a la red virtual
Puede escribir la configuración de la subred en la red virtual con Set-AzVirtualNetwork. Este comando crea la
subred:

$virtualNetwork | Set-AzVirtualNetwork

Creación de una máquina virtual

Cree una máquina virtual en la red virtual con New-AzVM. Cuando ejecute el comando siguiente, se le pedirán las
credenciales. Escriba un nombre de usuario y una contraseña para la máquina virtual:
 New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Name "myVm" `
-Location "westcentralus" `
-VirtualNetworkName "MyVirtualNetwork" `
-SubnetName "mySubnet" `
-SecurityGroupName "myNetworkSecurityGroup" `
-PublicIpAddressName "myPublicIpAddress" `
-OpenPorts 80,3389 `
-AsJob

La opción -AsJob crea la máquina virtual en segundo plano. Puede continuar al paso siguiente.
Cuando Azure empieza a crear la máquina virtual en segundo plano, verá algo como esto:

Id Name PSJobTypeName State HasMoreData Location Command

-- ---- ------------- ----- ----------- -------- -------
1 Long Running... AzureLongRun... Running True localhost New-AzVM

Creación de un servidor de SQL Server lógico

Cree un servidor lógico de SQL Server con el comando New-AzSqlServer. Recuerde que el nombre de la instancia
del servidor debe ser único en Azure, así que reemplace el valor del marcador de posición entre corchetes por su
propio valor único:

$adminSqlLogin = "SqlAdmin"
$password = "ChangeYourAdminPassword1"

$server = New-AzSqlServer -ResourceGroupName "myResourceGroup" `

-ServerName "myserver" `
-Location "WestCentralUS" `
-SqlAdministratorCredentials $(New-Object -TypeName [Link] -ArgumentList
$adminSqlLogin, $(ConvertTo-SecureString -String $password -AsPlainText -Force))

New-AzSqlDatabase -ResourceGroupName "myResourceGroup" `

-ServerName "myserver"`
-DatabaseName "myda"`
-RequestedServiceObjectiveName "S0" `
-SampleName "AdventureWorksLT"

Creación de un punto de conexión privado

Punto de conexión privado para el servidor de la red virtual con New-AzPrivateLinkServiceConnection:
 $privateEndpointConnection = New-AzPrivateLinkServiceConnection -Name "myConnection" `
-PrivateLinkServiceId $[Link] `
-GroupId "sqlServer"

$virtualNetwork = Get-AzVirtualNetwork -ResourceGroupName "myResourceGroup" -Name "MyVirtualNetwork"

$subnet = $virtualNetwork `
| Select -ExpandProperty subnets `
| Where-Object {$_.Name -eq 'mysubnet'}

$privateEndpoint = New-AzPrivateEndpoint -ResourceGroupName "myResourceGroup" `

-Name "myPrivateEndpoint" `
-Location "westcentralus" `
-Subnet $subnet `
-PrivateLinkServiceConnection $privateEndpointConnection

Configuración de la zona DNS privada

Cree una zona de DNS privado para el dominio de SQL Database, cree un vínculo de asociación con la red virtual y
un grupo de zona DNS para asociar el punto de conexión privado con la zona DNS privada.

$zone = New-AzPrivateDnsZone -ResourceGroupName "myResourceGroup" `

-Name "[Link]"

$link = New-AzPrivateDnsVirtualNetworkLink -ResourceGroupName "myResourceGroup" `

-ZoneName "[Link]"`
-Name "mylink" `
-VirtualNetworkId $[Link]

$config = New-AzPrivateDnsZoneConfig -Name "[Link]" -PrivateDnsZoneId

$[Link]

$privateDnsZoneGroup = New-AzPrivateDnsZoneGroup -ResourceGroupName "myResourceGroup" `

-PrivateEndpointName "myPrivateEndpoint" -name "MyZoneGroup" -PrivateDnsZoneConfig $config

Conexión a una máquina virtual desde Internet

Use Get-AzPublicIpAddress para devolver la dirección IP pública de una máquina virtual. Este ejemplo devuelve la
dirección IP pública de la máquina virtual myVM:

Get-AzPublicIpAddress `
-Name myPublicIpAddress `
-ResourceGroupName myResourceGroup `
| Select IpAddress

Abra un símbolo del sistema en el equipo local. Ejecute el comando mstsc. Reemplace por la dirección IP pública
que se devolvió en el último paso:

NOTE
Si ejecutó estos comandos desde un símbolo del sistema de PowerShell en el equipo local y usa la versión 1.0 o posterior del
módulo Az de PowerShell, puede seguir en esa interfaz.

mstsc /v:<publicIpAddress>
1. Cuando se le pida, seleccione Conectar .
2. Escriba el nombre de usuario y la contraseña que especificó al crear la máquina virtual.

NOTE
Es posible que tenga que seleccionar Más opciones > Usar otra cuenta para especificar las credenciales que escribió al crear la
máquina virtual.

3. Seleccione Aceptar .
4. Puede que reciba una advertencia de certificado. Si la recibe, seleccione Sí o Continuar .

Acceso a SQL Database de forma privada desde la VM

1. En el Escritorio remoto de myVm, abra PowerShell.
2. Escriba nslookup [Link] . No olvide reemplazar myserver por el nombre de su
instancia de SQL Server.
Recibirá un mensaje similar a este:

Server: UnKnown
Address: [Link]
Non-authoritative answer:
Name: [Link]
Address: [Link]
Aliases: [Link]

3. Instale SQL Server Management Studio.

4. En Conectar con el ser vidor , escriba o seleccione esta información:

C O N F IGURA C IÓ N VA L UE

Tipo de servidor Motor de base de datos

Nombre de servidor [Link]

Nombre de usuario Escribir el nombre de usuario proporcionado durante la

creación

Contraseña Escribir la contraseña proporcionada durante la creación

Recordar contraseña Sí

5. Seleccione Conectar .
6. Examine las bases de datos en el menú izquierdo.
7. (Opcionalmente) Cree o consulte la información de mydatabase.
8. Cierre la conexión de Escritorio remoto a myVM.

Limpieza de recursos
Cuando haya terminado con el punto de conexión privado, SQL Database y la VM, use Remove-AzResourceGroup
para quitar el grupo de recursos y todos los recursos que tiene:
 Remove-AzResourceGroup -Name myResourceGroup -Force

Pasos siguientes
Más información sobre Azure Private Link.
 Inicio rápido: Creación de un punto de conexión
privado mediante la CLI de Azure
23/09/2020 • 10 minutes to read • Edit Online

Un punto de conexión privado es el bloque de creación fundamental para Private Link en Azure. Permite que los
recursos de Azure, como las máquinas virtuales, se comuniquen de manera privada con recursos de Private Link.
En este inicio rápido, obtendrá información sobre cómo crear una máquina virtual en una red virtual, un servidor
de SQL Database con un punto de conexión privado mediante la CLI de Azure. A continuación, puede acceder a la
máquina virtual y acceder de forma segura al recurso de vínculo privado (un servidor de SQL Database privado en
este ejemplo).

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si, en su lugar, decide instalar y usar la CLI de Azure en un entorno local, para esta guía de inicio rápido se necesita
la versión 2.0.28 de la CLI de Azure o una versión posterior. Ejecute az --version para buscar la versión instalada.
Consulte Instalación de la CLI de Azure para obtener información sobre la instalación o actualización.

Crear un grupo de recursos

Para poder crear un recurso, debe crear un grupo de recursos que hospede la red virtual. Cree un grupo de
recursos con az group create. En el ejemplo, se crea un grupo de recursos denominado myResourceGroup en la
ubicación westcentralus:
 az group create --name myResourceGroup --location westcentralus

Creación de una red virtual

Cree la red virtual con az network vnet create. En este ejemplo se crea una red virtual predeterminada denominada
myVirtualNetwork con una subred denominada mySubnet:

az network vnet create \

--name myVirtualNetwork \
--resource-group myResourceGroup \
--subnet-name mySubnet

Deshabilitación de las directivas de punto de conexión privado

Azure implementa los recursos en una subred de una red virtual, por lo que debe crear o actualizar la subred para
deshabilitar las directivas de red del punto de conexión privado. Actualice una configuración de subred
denominada mySubnet con az network vnet subnet update:

az network vnet subnet update \

--name mySubnet \
--resource-group myResourceGroup \
--vnet-name myVirtualNetwork \
--disable-private-endpoint-network-policies true

Creación de la máquina virtual

Cree la máquina virtual con az vm create. Cuando se le solicite, proporcione una contraseña que se usará como
credenciales de inicio de sesión para la VM. En este ejemplo se crea una máquina virtual llamada myVm:

az vm create \
--resource-group myResourceGroup \
--name myVm \
--image Win2019Datacenter

Anote la dirección IP pública de la máquina virtual. Usará esta dirección para conectarse a la máquina virtual desde
Internet en el paso siguiente.

Creación de un servidor en SQL Database

Cree un servidor de SQL Database con el comando az sql server create. Recuerde que el nombre de la instancia de
SQL Server debe ser único en Azure, así que reemplace el valor de marcador de posición entre corchetes por su
propio valor único:
 # Create a server in the resource group
az sql server create \
--name "myserver"\
--resource-group myResourceGroup \
--location WestUS \
--admin-user "sqladmin" \
--admin-password "CHANGE_PASSWORD_1"

# Create a database in the server with zone redundancy as false

az sql db create \
--resource-group myResourceGroup \
--server myserver \
--name mySampleDatabase \
--sample-name AdventureWorksLT \
--edition GeneralPurpose \
--family Gen4 \
--capacity 1

El identificador del servidor es similar a

/subscriptions/subscriptionId/resourceGroups/myResourceGroup/providers/[Link]/servers/myserver. . Utilizará
este identificador en el paso siguiente.

Creación del punto de conexión privado

Cree un punto de conexión privado para el servidor SQL lógico en la instancia de Virtual Network:

az network private-endpoint create \

--name myPrivateEndpoint \
--resource-group myResourceGroup \
--vnet-name myVirtualNetwork \
--subnet mySubnet \
--private-connection-resource-id "<server ID>" \
--group-ids sqlServer \
--connection-name myConnection

Configuración de la zona DNS privada

Cree una zona DNS privada para el dominio de SQL Database, cree un vínculo de asociación con la red virtual y un
grupo de zona DNS para asociar el punto de conexión privado con la zona DNS privada.

az network private-dns zone create --resource-group myResourceGroup \

--name "[Link]"
az network private-dns link vnet create --resource-group myResourceGroup \
--zone-name "[Link]"\
--name MyDNSLink \
--virtual-network myVirtualNetwork \
--registration-enabled false
az network private-endpoint dns-zone-group create \
--resource-group myResourceGroup \
--endpoint-name myPrivateEndpoint \
--name MyZoneGroup \
--private-dns-zone "[Link]" \
--zone-name sql

Conexión a una máquina virtual desde Internet

Conéctese a la máquina virtual myVm desde Internet de la siguiente manera:
1. En la barra de búsqueda del portal, escriba myVm.
2. Seleccione el botón Conectar . Después de seleccionar el botón Conectar , se abre Conectar a máquina
vir tual .
3. Seleccione Descargar archivo RDP . Azure crea un archivo de Protocolo de Escritorio remoto ( .rdp) y lo
descarga en su equipo.
4. Abra el archivo [Link]*.
a. Cuando se le pida, seleccione Conectar .
b. Escriba el nombre de usuario y la contraseña que especificó al crear la VM.

NOTE
Es posible que tenga que seleccionar Más opciones > Usar otra cuenta para especificar las credenciales
que escribió al crear la máquina virtual.

5. Seleccione Aceptar .
6. Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Si recibe una advertencia
de certificado, seleccione Sí o Continuar .
7. Una vez que aparezca el escritorio de la máquina virtual, minimícelo para volver a su escritorio local.

Acceso a SQL Database de forma privada desde la máquina virtual

En esta sección, se conectará a SQL Database desde la máquina virtual mediante el punto de conexión privado.
1. En el Escritorio remoto de myVm, abra PowerShell.
2. Escriba nslookup [Link].
Recibirá un mensaje similar a este:

Server: UnKnown
Address: [Link]
Non-authoritative answer:
Name: [Link]
Address: [Link]
Aliases: [Link]

3. Instalación de SQL Server Management Studio

4. En Conectar con el servidor, escriba o seleccione esta información:
Tipo de servidor: Seleccione Motor de base de datos.
Nombre del servidor: Seleccione [Link].
Nombre de usuario: escriba un nombre de usuario proporcionado durante la creación.
Contraseña: escriba una contraseña proporcionada durante la creación.
Recordar contraseña: seleccione Sí.
5. Seleccione Conectar .
6. Examine las Bases de datos en el menú izquierdo.
7. (Opcionalmente) Cree o consulte información de mydatabase.
8. Cierre la conexión de Escritorio remoto a myVm.
Limpieza de recursos
Cuando ya no se necesite, puede utilizar az group delete para quitar el grupo de recursos y todos los recursos que
contiene:

az group delete --name myResourceGroup --yes

Pasos siguientes
Más información sobre Azure Private Link.
 Tutorial: Restricción del acceso de la red a los
recursos de PaaS mediante puntos de conexión de
servicio de red virtual mediante Azure Portal.
23/09/2020 • 21 minutes to read • Edit Online

Los puntos de conexión de servicio de red virtual permiten que el acceso de la red a algunos recursos de servicio
de Azure esté restringido a una subred de la red virtual. También se puede quitar el acceso de Internet a los
recursos. Los puntos de conexión de servicio proporcionan a la red virtual conexión directa con los servicios de
Azure compatibles, de modo que se puede usar el espacio de direcciones privadas de la red virtual para acceder a
los servicios de Azure. El tráfico destinado a los recursos de Azure a través de los puntos de conexión de servicio
siempre se mantiene en la red troncal de Microsoft Azure. En este tutorial, aprenderá a:
Crear una red virtual con una subred
Agregar una subred y habilitar un punto de conexión de servicio
Crear un recurso de Azure y permitir que la red solo pueda acceder a él desde una subred
Implementar una máquina virtual en cada subred
Confirmar el acceso a un recurso desde una subred
Confirmar que se ha denegado el acceso a un recurso desde una subred e Internet
Si lo prefiere, puede completar este tutorial con la CLI de Azure o Azure PowerShell.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Inicio de sesión en Azure

Inicie sesión en Azure Portal en [Link]

Creación de una red virtual

1. Seleccione + Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Redes y Red vir tual .
3. Especifique o seleccione los siguientes datos y haga clic en Crear :

C O N F IGURA C IÓ N VA L UE

Nombre myVirtualNetwork

Espacio de direcciones [Link]/16

Subscription Seleccione su suscripción.

Resource group Haga clic en Crear nuevo y escriba myResourceGroup.

Location Seleccione Este de EE. UU .

Nombre de subred Público

 C O N F IGURA C IÓ N VA L UE

Intervalo de direcciones de subred [Link]/24

Protección contra DDOS Básica

Puntos de conexión del servicio Disabled

Firewall Disabled

Habilitación de un punto de conexión de servicio

Los punto de conexión de servicio están habilitados por servicio, por subred. Cree una subred y habilite un punto
de conexión de servicio para ella.
1. En el cuadro Search resources, ser vices, and docs (Buscar recursos, servicios y documentos) que
encontrará en la parte superior del portal, escriba myVirtualNetwork. Cuando aparezca la opción
myVir tualNetwork en los resultados de la búsqueda, selecciónela.
2. Agregue una subred a la red virtual. En Configuración , seleccione Subredes y + Subred , tal y como se
muestra en la imagen siguiente:
3. En Agregar subred , escriba o seleccione los siguientes datos y haga clic en Aceptar :

C O N F IGURA C IÓ N VA L UE

Nombre Privada

Intervalo de direcciones [Link]/24

Puntos de conexión del servicio Seleccione [Link] en Ser vicios .

Cau t i on

Antes de habilitar un punto de conexión de servicio para una subred existente que tenga recursos, consulte
Modificación de la configuración de subred.

Restricción del acceso de la red para una subred

De forma predeterminada, todas las máquinas virtuales de una subred pueden comunicarse con todos los
recursos. Puede limitar la comunicación hacia y desde todos los recursos de una subred mediante la creación de
un grupo de seguridad de red y su asociación a la subred.
1. Seleccione + Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Redes y Grupo de seguridad de red .
3. En Create a network security group (Crear un grupo de seguridad de red), especifique o seleccione los
datos siguientes y haga clic en Crear :

C O N F IGURA C IÓ N VA L UE

Nombre myNsgPrivate

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y, a continuación,

myResourceGroup.
 C O N F IGURA C IÓ N VA L UE

Location Seleccione Este de EE. UU .

4. Cuando haya creado el grupo de seguridad de red, escriba myNsgPrivate en el cuadro Search resources,
ser vices, and docs (Buscar recursos, servicios y documentos) situado en la parte superior del portal.
Cuando aparezca myNsgPrivate en los resultados de búsqueda, selecciónelo.
5. En Configuración , seleccione Reglas de seguridad de salida .
6. Seleccione +Agregar .
7. Cree una regla que permita la comunicación saliente con el servicio Azure Storage. Especifique o seleccione
los siguientes datos y haga clic en Agregar :

C O N F IGURA C IÓ N VA L UE

Source Seleccione Vir tualNetwork

Source port ranges *

Destination Seleccione Ser vice Tag (Etiqueta de servicio)

Etiqueta de servicio de destino Seleccione Storage (Almacenamiento)

Intervalos de puertos de destino *

Protocolo Any

Acción Allow

Priority 100

Nombre Allow-Storage-All (Permitir-almacenar-todo)

8. Cree otra regla de seguridad de salida que deniegue la comunicación a Internet. Esta regla invalida una
regla predeterminada en todos los grupos de seguridad de red que permite la comunicación saliente de
Internet. Repita los pasos 5 a 7 de nuevo, utilizando los siguientes valores:

C O N F IGURA C IÓ N VA L UE

Source Seleccione Vir tualNetwork

Source port ranges *

Destination Seleccione Ser vice Tag (Etiqueta de servicio)

Etiqueta de servicio de destino Seleccione Internet

Intervalos de puertos de destino *

Protocolo Any
 C O N F IGURA C IÓ N VA L UE

Acción Denegar

Priority 110

Nombre Deny-Internet-All

9. En Configuración , seleccione Reglas de seguridad de entrada .

10. Seleccione +Agregar .
11. Cree una regla de seguridad de entrada que permita que el tráfico de Protocolo de escritorio remoto (RDP)
a la subred desde cualquier lugar. La regla invalidará cualquier regla de seguridad predeterminada que
deniegue todo el tráfico de entrada procedente de Internet. Las conexiones entre Escritorio remoto y la
subred están permitidas, por lo que dicha conectividad podrá probarse en un paso posterior. Seleccione
CONFIGURACIÓN , Reglas de seguridad de entrada y, después, + Agregar . Escriba los siguientes
valores y, a continuación, seleccione Agregar :

C O N F IGURA C IÓ N VA L UE

Source Any

Source port ranges *

Destination Seleccione Vir tualNetwork

Intervalos de puertos de destino 3389

Protocolo Any

Acción Allow

Priority 120

Nombre Allow-RDP-All (Permitir-RDP-Todo)

12. En CONFIGURACIÓN , seleccione Subredes .

13. Seleccione + Asociar
14. En Asociar subred , seleccione Red vir tual y, en Elegir red vir tual , seleccione myVir tualNetwork .
15. En Elegir subred , seleccione Privada y después Aceptar .

Restricción del acceso de la red a un recurso

Los pasos que deben seguirse para restringir el acceso de la red a los recursos creados con servicios de Azure
habilitados para puntos de conexión de servicio varían en función del servicio. Consulte en la documentación de
cada servicio concreto los pasos necesarios para dicho servicio. Como ejemplo, de aquí en adelante se explican los
pasos necesarios para restringir el acceso de red en una cuenta de Azure Storage.
Crear una cuenta de almacenamiento
1. Seleccione + Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Almacenamiento y, a continuación, seleccione Cuenta de almacenamiento: blob, archivo,
tabla, cola .
3. Escriba o seleccione la siguiente información, acepte los valores predeterminados restantes y haga clic en
Crear :

C O N F IGURA C IÓ N VA L UE

Nombre Especifique un nombre que sea único en todas las

ubicaciones de Azure, que tenga entre 3 y 24 caracteres
de longitud y que esté compuesto exclusivamente de
números y letras en minúscula.

Tipo de cuenta StorageV2 (uso general v2)

Location Seleccione Este de EE. UU .

Replicación Almacenamiento con redundancia local (LRS)

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y, a continuación,

myResourceGroup.

Creación de un recurso compartido de archivos en la cuenta de almacenamiento

1. Cuando haya creado la cuenta de almacenamiento, especifique su nombre en el cuadro Buscar recursos,
ser vicios y documentos , situado en la parte superior del portal. Cuando el nombre de la cuenta de
almacenamiento aparezca en los resultados de búsqueda, selecciónelo.
2. Seleccione Archivos , tal y como se muestra en la siguiente ilustración:

3. Seleccione + Recurso compar tido de archivos .

4. Escriba my-file-share en Nombre y seleccione Aceptar .
5. Cierre el cuadro Ser vicio Archivo .
Restricción del acceso de la red a una subred
De forma predeterminada, las cuentas de almacenamiento aceptan conexiones de red procedentes de clientes de
cualquier red, incluido Internet. Deniegue el acceso a la red desde Internet y a todas las demás subredes de todas
las redes virtuales, excepto a la subred Private de la red virtual myVirtualNetwork.
1. En la opción Configuración de la cuenta de almacenamiento, seleccione Firewalls and vir tual
networks (Firewalls y redes virtuales).
2. Seleccione Redes seleccionadas .
3. Seleccione +Agregar red vir tual existente .
4. En Agregar redes , seleccione los siguientes valores y haga clic en Agregar :

C O N F IGURA C IÓ N VA L UE

Subscription Seleccione su suscripción.

Redes virtuales Seleccione myVir tualNetwork en Redes vir tuales

Subredes Seleccione Privada en Subredes

5. Seleccione Guardar .
6. Cierre el cuadro Firewalls and vir tual networks (Firewalls y redes virtuales).
7. En la opción Configuración de la cuenta de almacenamiento, seleccione Claves de acceso , tal y como se
muestra en la siguiente ilustración:
8. Anote el valor del campo Clave , ya que tendrá que escribirlo manualmente más adelante, cuando asigne el
recurso compartido de archivos a una letra de unidad de una máquina virtual.

Creación de máquinas virtuales

Para probar el acceso de la red a una cuenta de almacenamiento, implemente una máquina virtual en cada subred.
Creación de la primera máquina virtual
1. Seleccione + Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Compute y, después, seleccione Windows Ser ver 2016 Datacenter .
3. Especifique o seleccione los siguientes datos y haga clic en Aceptar :

C O N F IGURA C IÓ N VA L UE

Nombre myVmPublic

Nombre de usuario Escriba un nombre de usuario de su elección.

Contraseña Escriba una contraseña de su elección. La contraseña debe

tener al menos 12 caracteres de largo y cumplir con los
requisitos de complejidad definidos.

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y, a continuación,

myResourceGroup .

Location Seleccione Este de EE. UU .

4. Seleccione un tamaño para la máquina virtual y luego Seleccionar .
5. En Configuración , seleccione Red y haga clic en myVir tualNetwork . Seleccione Subred y Público , tal y
como se muestra en la ilustración siguiente:
6. En Grupo de seguridad de red , seleccione Avanzado . El portal crea automáticamente un grupo de
seguridad de red que permite el puerto 3389, que debe estar abierto para conectarse a la máquina virtual
en un paso posterior. Seleccione Aceptar en la página Configuración .
7. En la página Resumen , seleccione Crear para iniciar la implementación de la máquina virtual. La máquina
virtual tarda unos minutos en implementarse, pero puede continuar con el paso siguiente mientras se crea.
Creación de la segunda máquina virtual
Repita los pasos 1 a 7, pero, en el paso 3, llame a la máquina virtual myVmPrivate y, en el paso 5, seleccione la
subred Privada .
La maquina virtual tarda unos minutos en implementarse. No avance al paso siguiente hasta que finalice el
proceso y la configuración se abra en el portal.

Confirmación del acceso a la cuenta de almacenamiento

1. Cuando la máquina virtual myVmPrivate termine de crearse, Azure abrirá sus opciones de configuración.
Conéctese a la máquina virtual seleccionando el botón Conectar , tal y como se muestra en la imagen
siguiente:
2. Cuando seleccione el botón Conectar , se creará un archivo de Protocolo de Escritorio remoto (.rdp) y se
descargará en el equipo.
3. Abra el archivo .rdp descargado. Cuando se le pida, seleccione Conectar . Escriba el nombre de usuario y la
contraseña que especificó al crear la máquina virtual. Puede que deba seleccionar More choices (Más
opciones) y, luego, Use a different account (Usar una cuenta diferente), para especificar las credenciales
que escribió al crear la máquina virtual.
4. Seleccione Aceptar .
5. Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Si recibe la advertencia,
seleccione Sí o Continuar para continuar con la conexión.
6. En la máquina virtual myVmPrivate, asigne el recurso compartido de archivos de Azure a la unidad Z con
PowerShell. Antes de ejecutar los comandos que siguen, reemplace <storage-account-key> y
<storage-account-name> por los valores que proporcionó y recuperó en Creación de una cuenta de
almacenamiento.

$acctKey = ConvertTo-SecureString -String "<storage-account-key>" -AsPlainText -Force

$credential = New-Object [Link] -ArgumentList "Azure\<storage-
account-name>", $acctKey
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storage-account-name>.[Link]\my-
file-share" -Credential $credential

PowerShell devuelve una salida similar a la del ejemplo siguiente:

Name Used (GB) Free (GB) Provider Root

---- --------- --------- -------- ----
Z FileSystem \\[Link]\my-f...

El recurso compartido de archivos de Azure se ha asignado correctamente a la unidad Z.

7. Confirme que la máquina virtual no tiene conectividad de salida a Internet desde un símbolo del sistema:

ping [Link]

Dado que el grupo de seguridad de red asociado a la subred Private no permite el acceso de salida a
Internet, no recibirá ninguna respuesta.
8. Cierre la sesión de Escritorio remoto a la máquina virtual myVmPrivate.

Confirmación de la denegación del acceso a la cuenta de

almacenamiento
1. En el cuadro Search resources, services, and docs (Buscar recursos, servicios y documentos) que encontrará
en la parte superior del portal, escriba myVmPublic .
2. Cuando aparezca myVmPublic en los resultados de búsqueda, selecciónelo.
3. Siga los pasos 1 a 6 que se indican en Confirmación del acceso a la cuenta de almacenamiento con la
máquina virtual myVmPublic.
Tras una breve espera, recibirá un error New-PSDrive : Access is denied . El acceso se deniega porque la
máquina virtual myVmPublic está implementada en la subred Public. La subred Public no tiene un punto de
conexión de servicio habilitado para Azure Storage. La cuenta de almacenamiento solo permite el acceso a
la red desde la subred Private, no desde la subred Public.
4. Cierre la sesión de Escritorio remoto a la máquina virtual myVmPublic.
5. En el equipo, vaya a Azure Portal.
6. Escriba el nombre de la cuenta de almacenamiento que creó en el cuadro Search resources, ser vices,
and docs (Buscar recursos, servicios y documentos). Cuando el nombre de la cuenta de almacenamiento
aparezca en los resultados de búsqueda, selecciónelo.
7. Seleccione Archivos .
8. Aparecerá el error que se muestra en la siguiente ilustración:

El acceso se deniega porque el equipo no se encuentra en la subred Privada de la red virtual

MyVirtualNetwork.

Limpieza de recursos
Cuando ya no sea necesario, elimine el grupo de recursos y todos los recursos que contiene:
1. Escriba myResourceGroup en el cuadro Buscar que se encuentra en la parte superior del portal. Seleccione
myResourceGroup cuando lo vea en los resultados de la búsqueda.
2. Seleccione Eliminar grupo de recursos .
3. Escriba myResourceGroup para ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS: y seleccione Eliminar .

Pasos siguientes
En este tutorial, ha habilitado un punto de conexión de servicio en una subred de la red virtual. Ha aprendido que
puede habilitar puntos de conexión de servicio para los recursos implementados desde varios servicios de Azure.
Ha creado una cuenta de Azure Storage y ha restringido el acceso de la red a la cuenta de almacenamiento que se
encuentra en una subred de la red virtual. Para más información acerca de los puntos de conexión de servicio,
consulte Introducción a los puntos de conexión de un servicio y Administración de subredes.
Si tiene varias redes virtuales en la cuenta, es posible que desee conectar dos de ellas para que los recursos que
están dentro de cada red virtual puedan comunicarse entre sí. Para aprender a conectar redes virtuales, pase al
siguiente tutorial.
Conexión de redes virtuales
 Restricción del acceso a la red a los recursos de PaaS
mediante puntos de conexión de servicio de red
virtual mediante PowerShell
23/09/2020 • 21 minutes to read • Edit Online

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.

Los puntos de conexión de servicio de red virtual permiten que el acceso de la red a algunos recursos de servicio
de Azure esté restringido a una subred de la red virtual. También se puede quitar el acceso de Internet a los
recursos. Los puntos de conexión de servicio proporcionan a la red virtual conexión directa con los servicios de
Azure compatibles, de modo que se puede usar el espacio de direcciones privadas de la red virtual para acceder a
los servicios de Azure. El tráfico destinado a los recursos de Azure a través de los puntos de conexión de servicio
siempre se mantiene en la red troncal de Microsoft Azure. En este artículo aprenderá a:
Crear una red virtual con una subred
Agregar una subred y habilitar un punto de conexión de servicio
Crear un recurso de Azure y permitir que la red solo pueda acceder a él desde una subred
Implementar una máquina virtual en cada subred
Confirmar el acceso a un recurso desde una subred
Confirmar que se ha denegado el acceso a un recurso desde una subred e Internet
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.
 O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar PowerShell de forma local, para realizar los pasos de este artículo necesita la versión 1.0.0
del módulo de Azure PowerShell o cualquier versión posterior. Ejecute Get-Module -ListAvailable Az para buscar
la versión instalada. Si necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell
se ejecuta localmente, también debe ejecutar Connect-AzAccount para crear una conexión con Azure.

Creación de una red virtual

Antes de crear una red virtual, cree un grupo de recursos para ella y los demás recursos que se crearon en este
artículo. Cree un grupo de recursos con New-AzResourceGroup. En el ejemplo siguiente se crea un grupo de
recursos denominado myResourceGroup:

New-AzResourceGroup -ResourceGroupName myResourceGroup -Location EastUS

Cree una red virtual con New-AzVirtualNetwork. En el ejemplo siguiente se crea una red virtual denominada
myVirtualNetwork con el prefijo de dirección [Link]/16.

$virtualNetwork = New-AzVirtualNetwork `
-ResourceGroupName myResourceGroup `
-Location EastUS `
-Name myVirtualNetwork `
-AddressPrefix [Link]/16

Cree una configuración de subred con New-AzVirtualNetworkSubnetConfig. En el ejemplo siguiente se crea una
configuración de subred para una subred denominada Public:

$subnetConfigPublic = Add-AzVirtualNetworkSubnetConfig `
-Name Public `
-AddressPrefix [Link]/24 `
-VirtualNetwork $virtualNetwork

Cree la subred en la red virtual escribiendo la configuración de dicha subred en la red virtual con Set-
AzVirtualNetwork:

$virtualNetwork | Set-AzVirtualNetwork

Habilitación de un punto de conexión de servicio

Puede habilitar puntos de conexión de servicio únicamente para los servicios que admiten estos puntos de
conexión. Vea los servicios habilitados para puntos de conexión de servicio disponibles en una ubicación de Azure
con Get-AzVirtualNetworkAvailableEndpointService. En el ejemplo siguiente se devuelve una lista de servicios
habilitados para puntos de conexión de servicio disponibles en la región eastus. La lista de servicios devuelta
crecerá con el tiempo a medida que más servicios de Azure pasan a estar habilitados para puntos de conexión de
servicio.

Get-AzVirtualNetworkAvailableEndpointService -Location eastus | Select Name

Cree una subred adicional en la red virtual. En este ejemplo, se crea una subred denominada Private con un punto
de conexión de servicio para [Link]:

$subnetConfigPrivate = Add-AzVirtualNetworkSubnetConfig `
-Name Private `
-AddressPrefix [Link]/24 `
-VirtualNetwork $virtualNetwork `
-ServiceEndpoint [Link]

$virtualNetwork | Set-AzVirtualNetwork

Restricción del acceso de la red para una subred

Cree reglas de seguridad de grupo de seguridad de red con New-AzNetworkSecurityRuleConfig. La siguiente
regla permite el acceso de salida a las direcciones IP públicas asignadas al servicio Azure Storage:

$rule1 = New-AzNetworkSecurityRuleConfig `
-Name Allow-Storage-All `
-Access Allow `
-DestinationAddressPrefix Storage `
-DestinationPortRange * `
-Direction Outbound `
-Priority 100 `
-Protocol * `
-SourceAddressPrefix VirtualNetwork `
-SourcePortRange *

La siguiente regla deniega el acceso a todas las direcciones IP públicas. La regla anterior invalida esta regla
porque su prioridad es más alta, lo que permite el acceso a las direcciones IP públicas de Azure Storage.

$rule2 = New-AzNetworkSecurityRuleConfig `
-Name Deny-Internet-All `
-Access Deny `
-DestinationAddressPrefix Internet `
-DestinationPortRange * `
-Direction Outbound `
-Priority 110 `
-Protocol * `
-SourceAddressPrefix VirtualNetwork `
-SourcePortRange *

La siguiente regla permite que el tráfico de Protocolo de escritorio remoto (RDP) pueda entrar en la subred desde
cualquier lugar. Se permiten las conexiones de Escritorio remoto a la subred, por lo que puede confirmar acceso a
la red a un recurso en un paso posterior.
 $rule3 = New-AzNetworkSecurityRuleConfig `
-Name Allow-RDP-All `
-Access Allow `
-DestinationAddressPrefix VirtualNetwork `
-DestinationPortRange 3389 `
-Direction Inbound `
-Priority 120 `
-Protocol * `
-SourceAddressPrefix * `
-SourcePortRange *

Cree un grupo de seguridad de red con New-AzNetworkSecurityGroup. En el ejemplo siguiente se crea un grupo
de seguridad de red denominado myNsgPrivate.

$nsg = New-AzNetworkSecurityGroup `
-ResourceGroupName myResourceGroup `
-Location EastUS `
-Name myNsgPrivate `
-SecurityRules $rule1,$rule2,$rule3

Asocie el grupo de seguridad de red a la subred Private con Set-AzVirtualNetworkSubnetConfig y escriba la

configuración de la subred en la red virtual. En el ejemplo siguiente se asocia el grupo de seguridad de red
myNsgPrivate a la subred Private:

Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $VirtualNetwork `
-Name Private `
-AddressPrefix [Link]/24 `
-ServiceEndpoint [Link] `
-NetworkSecurityGroup $nsg

$virtualNetwork | Set-AzVirtualNetwork

Restricción del acceso de la red a un recurso

Los pasos que deben seguirse para restringir el acceso de la red a los recursos creados con servicios de Azure
habilitados para puntos de conexión de servicio varían en función del servicio. Consulte en la documentación de
cada servicio concreto los pasos necesarios para dicho servicio. Como ejemplo, de aquí en adelante se explican
los pasos necesarios para restringir el acceso de red en una cuenta de Azure Storage.
Crear una cuenta de almacenamiento
Cree una cuenta de almacenamiento de Azure con New-AzStorageAccount. Remplace
<replace-with-your-unique-storage-account-name> por un nombre que sea único en todas las ubicaciones de
Azure, que tenga entre 3 y 24 caracteres de longitud y que esté compuesto exclusivamente de números y letras
en minúscula.

$storageAcctName = '<replace-with-your-unique-storage-account-name>'

New-AzStorageAccount `
-Location EastUS `
-Name $storageAcctName `
-ResourceGroupName myResourceGroup `
-SkuName Standard_LRS `
-Kind StorageV2

Después de crear la cuenta de almacenamiento, recupere la clave para dicha cuenta en una variable con Get-
AzStorageAccountKey:

$storageAcctKey = (Get-AzStorageAccountKey `
-ResourceGroupName myResourceGroup `
-AccountName $storageAcctName).Value[0]

La clave se utiliza para crear un recurso compartido de archivos en un paso posterior. Especifique
$storageAcctKey y anote el valor, ya que tendrá que escribirlo manualmente más adelante, cuando asigne el
recurso compartido de archivos a una unidad de una máquina virtual.
Creación de un recurso compartido de archivos en la cuenta de almacenamiento
Cree un contexto para la clave y la cuenta de almacenamiento con New-AzStorageContext. El contexto encapsula
el nombre y la clave de la cuenta de almacenamiento:

$storageContext = New-AzStorageContext $storageAcctName $storageAcctKey

Cree un recurso compartido de archivos con New-AzStorageShare:

$share = New-AzStorageShare my-file-share -Context $storageContext
Denegación de todo el acceso a la red a una cuenta de almacenamiento
De forma predeterminada, las cuentas de almacenamiento aceptan conexiones de red procedentes de clientes de
cualquier red. Para limitar el acceso a redes seleccionadas, cambie la acción predeterminada a Deny con Update-
AzStorageAccountNetworkRuleSet. Una vez que se deniega el acceso a la red, no se puede acceder a la cuenta de
almacenamiento desde ninguna red.

Update-AzStorageAccountNetworkRuleSet `
-ResourceGroupName "myresourcegroup" `
-Name $storageAcctName `
-DefaultAction Deny

Habilitación del acceso de red desde una subred

Recupere la red virtual creada con Get-AzVirtualNetwork y recupere el objeto de subred privada en una variable
con Get-AzVirtualNetworkSubnetConfig:

$privateSubnet = Get-AzVirtualNetwork `
-ResourceGroupName "myResourceGroup" `
-Name "myVirtualNetwork" `
| Get-AzVirtualNetworkSubnetConfig `
-Name "Private"

Permita el acceso a la red a la cuenta de almacenamiento desde la subred Private con Add-
AzStorageAccountNetworkRule.

Add-AzStorageAccountNetworkRule `
-ResourceGroupName "myresourcegroup" `
-Name $storageAcctName `
-VirtualNetworkResourceId $[Link]

Creación de máquinas virtuales

Para probar el acceso de la red a una cuenta de almacenamiento, implemente una máquina virtual en cada
subred.
Creación de la primera máquina virtual
Cree una máquina virtual en la subred Pública con New-AzVM. Cuando ejecute el comando siguiente, se le
solicitarán las credenciales. Los valores que especifique se configuran como el nombre de usuario y la contraseña
de la máquina virtual. La opción -AsJob crea la máquina virtual en segundo plano, así que puede continuar con
el siguiente paso.

New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Location "East US" `
-VirtualNetworkName "myVirtualNetwork" `
-SubnetName "Public" `
-Name "myVmPublic" `
-AsJob

Se devuelve una salida similar a la del siguiente ejemplo:

Id Name PSJobTypeName State HasMoreData Location Command

-- ---- ------------- ----- ----------- -------- -------
1 Long Running... AzureLongRun... Running True localhost New-AzVM

Creación de la segunda máquina virtual

Cree una máquina virtual en la subred Private:

New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Location "East US" `
-VirtualNetworkName "myVirtualNetwork" `
-SubnetName "Private" `
-Name "myVmPrivate"

La operación de creación de la máquina virtual para Azure tarda unos minutos. No continúe con el paso siguiente
hasta que Azure termine de crear la máquina virtual y devuelva la salida a PowerShell.

Confirmación del acceso a la cuenta de almacenamiento

Use Get-AzPublicIpAddress para devolver la dirección IP pública de una máquina virtual. En el siguiente ejemplo
se devuelve la dirección IP pública de la máquina virtual myVmPrivate:

Get-AzPublicIpAddress `
-Name myVmPrivate `
-ResourceGroupName myResourceGroup `
| Select IpAddress

Reemplace <publicIpAddress> en el siguiente comando, por la dirección IP pública devuelta por el comando
anterior y, a continuación, escriba el siguiente comando:

mstsc /v:<publicIpAddress>

Se crea un archivo de Protocolo de Escritorio remoto (.rdp) y se descarga en su equipo. Abra el archivo .rdp
descargado. Cuando se le pida, seleccione Conectar . Escriba el nombre de usuario y la contraseña que especificó
al crear la máquina virtual. Puede que deba seleccionar More choices (Más opciones) y, luego, Use a different
account (Usar una cuenta diferente), para especificar las credenciales que escribió al crear la máquina virtual.
Seleccione Aceptar . Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Si recibe
la advertencia, seleccione Sí o Continuar para continuar con la conexión.
En la máquina virtual myVmPrivate, asigne el recurso compartido de archivos de Azure a la unidad Z con
PowerShell. Antes de ejecutar los comandos que siguen, reemplace <storage-account-key> y
<storage-account-name> por valores que proporcionó o recuperó en Crear una cuenta de almacenamiento.

$acctKey = ConvertTo-SecureString -String "<storage-account-key>" -AsPlainText -Force

$credential = New-Object [Link] -ArgumentList "Azure\<storage-account-
name>", $acctKey
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storage-account-name>.[Link]\my-file-
share" -Credential $credential

PowerShell devuelve una salida similar a la del ejemplo siguiente:

Name Used (GB) Free (GB) Provider Root

---- --------- --------- -------- ----
Z FileSystem \\[Link]\my-f...

El recurso compartido de archivos de Azure se ha asignado correctamente a la unidad Z.

Asegúrese de que la máquina virtual no tiene conectividad de salida con otras direcciones IP públicas:

ping [Link]

Dado que el grupo de seguridad de red asociado a la subred Privada no permite el acceso de salida a otras
direcciones IP públicas que no sean las direcciones asignadas al servicio Azure Storage, no recibirá ninguna
respuesta.
Cierre la sesión de Escritorio remoto a la máquina virtual myVmPrivate.

Confirmación de la denegación del acceso a la cuenta de

almacenamiento
Obtenga la dirección IP pública de la máquina virtual myVmPublic:

Get-AzPublicIpAddress `
-Name myVmPublic `
-ResourceGroupName myResourceGroup `
| Select IpAddress

Reemplace <publicIpAddress> en el siguiente comando, por la dirección IP pública devuelta por el comando
anterior y, a continuación, escriba el siguiente comando:

mstsc /v:<publicIpAddress>

En la máquina virtual myVmPublic, intente asignar el recurso compartido de archivos de Azure a la unidad Z.
Antes de ejecutar los comandos que siguen, reemplace <storage-account-key> y <storage-account-name> por
valores que proporcionó o recuperó en Crear una cuenta de almacenamiento.
 $acctKey = ConvertTo-SecureString -String "<storage-account-key>" -AsPlainText -Force
$credential = New-Object [Link] -ArgumentList "Azure\<storage-account-
name>", $acctKey
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\<storage-account-name>.[Link]\my-file-
share" -Credential $credential

El acceso al recurso compartido se deniega y recibe el error New-PSDrive : Access is denied . El acceso se deniega
porque la máquina virtual myVmPublic está implementada en la subred Public. La subred Public no tiene ningún
punto de conexión de servicio habilitado para Azure Storage y la cuenta de almacenamiento solo permite el
acceso de red desde la subred Private, no desde la subred Public.
Cierre la sesión de Escritorio remoto a la máquina virtual myVmPublic.
Desde su equipo, intente ver los recursos compartidos de archivos en la cuenta de almacenamiento con el
siguiente comando:

Get-AzStorageFile `
-ShareName my-file-share `
-Context $storageContext

Se deniega el acceso y se recibe el error Get-AzStorageFile: Error en el servidor remoto: 403 Prohibido. Código de
estado HTTP: 403 - Mensaje de error HTTP: This request is not authorized to perform this operation (Esta solicitud
no está autorizada para realizar esta operación) porque el equipo no está en la subred Private de la red virtual
MyVirtualNetwork.

Limpieza de recursos
Cuando ya no lo necesite, puede usar Remove-AzResourceGroup para quitar el grupo de recursos y todos los
recursos que contiene:

Remove-AzResourceGroup -Name myResourceGroup -Force

Pasos siguientes
En este artículo, ha habilitado un punto de conexión de servicio en una subred de la red virtual. Ha aprendido que
los puntos de conexión de servicio pueden habilitarse para los recursos implementados con varios servicios de
Azure. Ha creado una cuenta de Azure Storage y ha hecho que el acceso de la red a la cuenta de almacenamiento
esté limitado exclusivamente a los recursos que se encuentran en una subred de la red virtual. Para más
información acerca de los puntos de conexión de servicio, consulte Introducción a los puntos de conexión de un
servicio y Administración de subredes.
Si tiene varias redes virtuales en la cuenta, es posible que desee conectar dos de ellas para que los recursos que
están dentro de cada red virtual puedan comunicarse entre sí. Para obtener información sobre cómo hacerlo,
consulte Conexión de redes virtuales.
 Restricción del acceso a la red a los recursos de PaaS
con puntos de conexión de servicio de red virtual
mediante la CLI de Azure
23/09/2020 • 19 minutes to read • Edit Online

Los puntos de conexión de servicio de red virtual permiten que el acceso de la red a algunos recursos de servicio
de Azure esté restringido a una subred de la red virtual. También se puede quitar el acceso de Internet a los
recursos. Los puntos de conexión de servicio proporcionan a la red virtual conexión directa con los servicios de
Azure compatibles, de modo que se puede usar el espacio de direcciones privadas de la red virtual para acceder a
los servicios de Azure. El tráfico destinado a los recursos de Azure a través de los puntos de conexión de servicio
siempre se mantiene en la red troncal de Microsoft Azure. En este artículo aprenderá a:
Crear una red virtual con una subred
Agregar una subred y habilitar un punto de conexión de servicio
Crear un recurso de Azure y permitir que la red solo pueda acceder a él desde una subred
Implementar una máquina virtual en cada subred
Confirmar el acceso a un recurso desde una subred
Confirmar que se ha denegado el acceso a un recurso desde una subred e Internet
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
 bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar la CLI en un entorno local, para esta guía de inicio rápido es preciso que ejecute la versión
2.0.28 de la CLI de Azure o una versión posterior. Para encontrar la versión, ejecute az --version . Si necesita
instalarla o actualizarla, vea Instalación de la CLI de Azure.

Creación de una red virtual

Antes de crear una red virtual, cree un grupo de recursos para ella y los demás recursos que se crearon en este
artículo. Cree un grupo de recursos con az group create. En el ejemplo siguiente, se crea un grupo de recursos
denominado myResourceGroup en la ubicación eastus.

az group create \
--name myResourceGroup \
--location eastus

Cree una red virtual con una subred con az network vnet create.

az network vnet create \

--name myVirtualNetwork \
--resource-group myResourceGroup \
--address-prefix [Link]/16 \
--subnet-name Public \
--subnet-prefix [Link]/24

Habilitación de un punto de conexión de servicio

Puede habilitar puntos de conexión de servicio únicamente para los servicios que admiten estos puntos de
conexión. Vea los servicios habilitados para puntos de conexión de servicio disponibles en una ubicación de Azure
con az network vnet list-endpoint-services. En el ejemplo siguiente se devuelve una lista de servicios habilitados
para puntos de conexión de servicio disponibles en la región eastus. La lista de servicios devuelta crecerá con el
tiempo a medida que más servicios de Azure pasan a estar habilitados para puntos de conexión de servicio.

az network vnet list-endpoint-services \

--location eastus \
--out table

Cree una subred adicional en la red virtual con az network vnet subnet create. En este ejemplo, se crea un punto
de conexión de servicio para [Link] para la subred:

az network vnet subnet create \

--vnet-name myVirtualNetwork \
--resource-group myResourceGroup \
--name Private \
--address-prefix [Link]/24 \
--service-endpoints [Link]

Restricción del acceso de la red para una subred

Cree un grupo de seguridad de red con az network nsg create. En el ejemplo siguiente se crea un grupo de
seguridad de red denominado myNsgPrivate.
 az network nsg create \
--resource-group myResourceGroup \
--name myNsgPrivate

Asocie el grupo de seguridad de red a la subred Private con az network vnet subnet update. En el ejemplo
siguiente se asocia el grupo de seguridad de red myNsgPrivate a la subred Private:

az network vnet subnet update \

--vnet-name myVirtualNetwork \
--name Private \
--resource-group myResourceGroup \
--network-security-group myNsgPrivate

Cree reglas de seguridad con az network nsg rule create. La regla siguiente permite el acceso de salida a las
direcciones IP públicas asignadas al servicio Azure Storage:

az network nsg rule create \

--resource-group myResourceGroup \
--nsg-name myNsgPrivate \
--name Allow-Storage-All \
--access Allow \
--protocol "*" \
--direction Outbound \
--priority 100 \
--source-address-prefix "VirtualNetwork" \
--source-port-range "*" \
--destination-address-prefix "Storage" \
--destination-port-range "*"

Cada grupo de seguridad de red contiene varias reglas de seguridad predeterminadas. La regla siguiente invalida
una regla de seguridad predeterminada que permite el acceso de salida a todas las direcciones IP públicas. La
opción destination-address-prefix "Internet" deniega el acceso de salida a todas las direcciones IP públicas. La
regla anterior invalida esta regla porque su prioridad es más alta, lo que permite el acceso a las direcciones IP
públicas de Azure Storage.

az network nsg rule create \

--resource-group myResourceGroup \
--nsg-name myNsgPrivate \
--name Deny-Internet-All \
--access Deny \
--protocol "*" \
--direction Outbound \
--priority 110 \
--source-address-prefix "VirtualNetwork" \
--source-port-range "*" \
--destination-address-prefix "Internet" \
--destination-port-range "*"

La siguiente regla permite la entrada de tráfico SSH en la subred desde cualquier lugar. La regla invalidará
cualquier regla de seguridad predeterminada que deniegue todo el tráfico de entrada procedente de Internet. SSH
se admite en la subred, por lo que dicha conectividad podrá probarse en un paso posterior.
 az network nsg rule create \
--resource-group myResourceGroup \
--nsg-name myNsgPrivate \
--name Allow-SSH-All \
--access Allow \
--protocol Tcp \
--direction Inbound \
--priority 120 \
--source-address-prefix "*" \
--source-port-range "*" \
--destination-address-prefix "VirtualNetwork" \
--destination-port-range "22"

Restricción del acceso de la red a un recurso

Los pasos que deben seguirse para restringir el acceso de la red a los recursos creados con servicios de Azure
habilitados para puntos de conexión de servicio varían en función del servicio. Consulte en la documentación de
cada servicio concreto los pasos necesarios para dicho servicio. Como ejemplo, de aquí en adelante se explican
los pasos necesarios para restringir el acceso de red en una cuenta de Azure Storage.
Crear una cuenta de almacenamiento
Cree una cuenta de almacenamiento de Azure con az storage account create. Remplace
<replace-with-your-unique-storage-account-name> por un nombre que sea único en todas las ubicaciones de
Azure, que tenga entre 3 y 24 caracteres de longitud y que esté compuesto exclusivamente de números y letras
en minúscula.

storageAcctName="<replace-with-your-unique-storage-account-name>"

az storage account create \

--name $storageAcctName \
--resource-group myResourceGroup \
--sku Standard_LRS \
--kind StorageV2

Después de crear la cuenta de almacenamiento, recupere la cadena de conexión para dicha cuenta en una variable
con az storage account show-connection-string. La cadena de conexión se utiliza para crear un recurso
compartido de archivos en un paso posterior.

saConnectionString=$(az storage account show-connection-string \

--name $storageAcctName \
--resource-group myResourceGroup \
--query 'connectionString' \
--out tsv)

Vea el contenido de la variable y anote el valor de AccountKey devuelto en la salida, porque se utilizará en un
paso posterior.

echo $saConnectionString

Creación de un recurso compartido de archivos en la cuenta de almacenamiento

Cree un recurso compartido de archivos en la cuenta de almacenamiento con az storage share create. En un paso
posterior, este recurso compartido de archivos está montado para confirmar el acceso de red a él.
 az storage share create \
--name my-file-share \
--quota 2048 \
--connection-string $saConnectionString > /dev/null

Denegación de todo el acceso a la red a una cuenta de almacenamiento

De forma predeterminada, las cuentas de almacenamiento aceptan conexiones de red procedentes de clientes de
cualquier red. Para limitar el acceso a redes seleccionadas, cambie la acción predeterminada a Deny con az
storage account update. Una vez que se deniega el acceso a la red, no se puede acceder a la cuenta de
almacenamiento desde ninguna red.

az storage account update \

--name $storageAcctName \
--resource-group myResourceGroup \
--default-action Deny

Habilitación del acceso de red desde una subred

Permita el acceso a la red a la cuenta de almacenamiento desde la subred Private con az storage account network-
rule add.

az storage account network-rule add \

--resource-group myResourceGroup \
--account-name $storageAcctName \
--vnet-name myVirtualNetwork \
--subnet Private

Creación de máquinas virtuales

Para probar el acceso de la red a una cuenta de almacenamiento, implemente una máquina virtual en cada
subred.
Creación de la primera máquina virtual
Cree una máquina virtual en la subred Public con az vm create. Si las claves SSH no existen en la ubicación de
claves predeterminada, el comando las crea. Para utilizar un conjunto específico de claves, utilice la opción
--ssh-key-value .

az vm create \
--resource-group myResourceGroup \
--name myVmPublic \
--image UbuntuLTS \
--vnet-name myVirtualNetwork \
--subnet Public \
--generate-ssh-keys

La máquina virtual tarda en crearse unos minutos. Después de crear la máquina virtual, la CLI de Azure muestra
información similar a la del ejemplo siguiente:
 {
"fqdns": "",
"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/virtualMachines/myVmPublic",
"location": "eastus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "[Link]",
"publicIpAddress": "[Link]",
"resourceGroup": "myResourceGroup"
}

Tome nota de publicIpAddress en la salida devuelta. En un paso posterior, usaremos esta dirección para obtener
acceso a la máquina virtual desde Internet.
Creación de la segunda máquina virtual

az vm create \
--resource-group myResourceGroup \
--name myVmPrivate \
--image UbuntuLTS \
--vnet-name myVirtualNetwork \
--subnet Private \
--generate-ssh-keys

La máquina virtual tarda en crearse unos minutos. Después de la creación, tome nota de publicIpAddress en la
salida devuelta. En un paso posterior, usaremos esta dirección para obtener acceso a la máquina virtual desde
Internet.

Confirmación del acceso a la cuenta de almacenamiento

SSH en la máquina virtual myVmPrivate. Reemplace <publicIpAddress> por la dirección IP pública de la máquina
virtual myVmPrivate.

ssh <publicIpAddress>

Cree una carpeta para un punto de montaje:

sudo mkdir /mnt/MyAzureFileShare

Monte el recurso compartido de archivos de Azure en el directorio que ha creado. Antes de ejecutar el siguiente
comando, reemplace <storage-account-name> con el nombre de cuenta y <storage-account-key> con la clave que
recuperada en Crear una cuenta de almacenamiento.

sudo mount --types cifs //<storage-account-name>.[Link]/my-file-share /mnt/MyAzureFileShare --

options vers=3.0,username=<storage-account-name>,password=<storage-account-
key>,dir_mode=0777,file_mode=0777,serverino

Recibirá el símbolo del sistema user@myVmPrivate:~$ . El recurso compartido de archivos de Azure se montó
correctamente en /mnt/MyAzureFileShare.
Asegúrese de que la máquina virtual no tiene conectividad de salida con otras direcciones IP públicas:

ping [Link] -c 4
Dado que el grupo de seguridad de red asociado a la subred Privada no permite el acceso de salida a otras
direcciones IP públicas que no sean las direcciones asignadas al servicio Azure Storage, no recibirá ninguna
respuesta.
Salga de la sesión de SSH en la máquina virtual myVmPrivate.

Confirmación de la denegación del acceso a la cuenta de

almacenamiento
Use el siguiente comando para crear una sesión de SSH con la máquina virtual myVmPublic. Reemplace
<publicIpAddress> por la dirección IP pública de la máquina virtual myVmPublic:

ssh <publicIpAddress>

Cree un directorio para un punto de montaje:

sudo mkdir /mnt/MyAzureFileShare

Intente montar el recurso compartido de archivos de Azure en el directorio que ha creado. En este artículo se
asume que ha implementado la versión más reciente de Ubuntu. Si está utilizando versiones anteriores de
Ubuntu, consulte Montaje en Linux para instrucciones adicionales sobre el montaje de recursos compartidos de
archivos. Antes de ejecutar el siguiente comando, reemplace <storage-account-name> con el nombre de cuenta y
<storage-account-key> con la clave que recuperada en Crear una cuenta de almacenamiento:

sudo mount --types cifs //storage-account-name>.[Link]/my-file-share /mnt/MyAzureFileShare --

options vers=3.0,username=<storage-account-name>,password=<storage-account-
key>,dir_mode=0777,file_mode=0777,serverino

El acceso se deniega y recibe un error mount error(13): Permission denied porque la máquina virtual
myVmPublic está implementada dentro la subred Public. La subred Public no tiene ningún punto de conexión de
servicio habilitado para Azure Storage y la cuenta de almacenamiento solo permite el acceso de red desde la
subred Private, no desde la subred Public.
Salga de la sesión de SSH en la máquina virtual myVmPublic.
Desde su equipo, intente ver los recursos compartidos en la cuenta de almacenamiento con az storage share list.
Reemplace <account-name> y <account-key> con el nombre de la cuenta de almacenamiento y la clave de Crear
una cuenta de almacenamiento:

az storage share list \

--account-name <account-name> \
--account-key <account-key>

El acceso se deniega y recibe el error This request is not authorized to perform this operation (Esta solicitud no
está autorizada para realizar esta operación) porque el equipo no está en la subred Private de la red virtual
MyVirtualNetwork.

Limpieza de recursos
Cuando ya no se necesiten, use az group delete para quitar el grupo de recursos y todos los recursos que
contenga.
 az group delete --name myResourceGroup --yes

Pasos siguientes
En este artículo, ha habilitado un punto de conexión de servicio en una subred de la red virtual. Ha aprendido que
los puntos de conexión de servicio pueden habilitarse para los recursos implementados con varios servicios de
Azure. Ha creado una cuenta de Azure Storage y ha hecho que el acceso de la red a la cuenta de almacenamiento
esté limitado exclusivamente a los recursos que se encuentran en una subred de la red virtual. Para más
información acerca de los puntos de conexión de servicio, consulte Introducción a los puntos de conexión de un
servicio y Administración de subredes.
Si tiene varias redes virtuales en la cuenta, es posible que desee conectar dos de ellas para que los recursos que
están dentro de cada red virtual puedan comunicarse entre sí. Para obtener información sobre cómo hacerlo,
consulte Conexión de redes virtuales.
 Creación, cambio o eliminación de la directiva de
punto de conexión de servicio mediante Azure Portal
23/09/2020 • 7 minutes to read • Edit Online

Las directivas de puntos de conexión de servicio le permiten filtrar el tráfico de red virtual a recursos específicos de
Azure, sobre puntos de conexión de servicio. Si no está familiarizado con estas directivas, consulte Directivas de
punto de conexión de servicio para más información.
En este tutorial, aprenderá a:
Creación de una directiva de punto de conexión de servicio
Definición de Crear una directiva de punto de conexión de servicio
Creación de una red virtual con una subred
Asociación una directiva de punto de conexión de servicio a una subred
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Inicio de sesión en Azure

Inicie sesión en Azure Portal en [Link]

Creación de una directiva de punto de conexión de servicio

1. Seleccione + Crear un recurso en la esquina superior izquierda de Azure Portal.
2. En el panel de búsqueda, escriba "directiva de punto de conexión de servicio" y seleccione Directiva de punto
de conexión de ser vicio y, a continuación, seleccione Crear .

3. Escriba o seleccione la siguiente información en Básico .

Suscripción: Seleccione la suscripción por directiva.
Grupo de recursos: Seleccione Crear nuevo y escriba myResourceGroup
Nombre: myEndpointPolicy
Ubicación: Centro de EE. UU.
4. Seleccione + Agregar en Recursos y escriba o seleccione la siguiente información en el panel Agregar
un recurso .
Servicio: Solo Microsoft. Storage está disponible con las directivas de punto de conexión de servicio
Ámbito: Seleccione una de las opciones Cuenta única , Todas las cuentas de la suscripción y Todas
las cuentas del grupo de recursos .
Suscripción: seleccione la suscripción para la cuenta de almacenamiento. Las cuentas de almacenamiento
y las directivas pueden estar en distintas suscripciones.
Grupo de recursos: Seleccione el grupo de recursos que necesite. Requerido, si el ámbito está establecido
como "Todas las cuentas del grupo de recursos" o "Cuenta única".
Recurso: Seleccione el recurso de Azure Storage en la suscripción o el grupo de recursos seleccionado
Haga clic en el botón Agregar en la parte inferior para terminar de agregar el recurso.
 Agregue más recursos repitiendo los pasos anteriores según sea necesario.
5. Opcional: escriba o seleccione la siguiente información en Etiquetas :
Clave: seleccione la clave de la directiva. Por ejemplo: Dept
Valor: escriba el par de valor de la clave. Por ejemplo: Finance
6. Seleccione Revisar + crear . Valide la información y haga clic en Crear . Para hacer más modificaciones,
haga clic en Anterior .

Visualización de directivas de punto de conexión de servicio

1. En el cuadro Todos los servicios del portal, comience a escribir directivas de punto de conexión de servicio.
Seleccione Directivas de punto de conexión de ser vicio .
2. En Suscripciones , seleccione la suscripción y grupo de recursos, tal como se muestra en la siguiente
imagen.

3. Seleccione la directiva y haga clic en Definiciones de directiva para ver o agregar más definiciones.

4. Seleccione Subredes asociadas para ver las subredes asociadas a la directiva. Si todavía no hay ninguna
subred asociada, siga las instrucciones del paso siguiente.
5. Asociación de una directiva a una subred

WARNING
Asegúrese de que todos los recursos a los que se accede desde la subred se agregan a la directiva antes de asociarla a la
subred especificada. Una vez que la directiva está asociada, solo se permitirá el acceso a los recursos de la lista de permitidos
en los puntos de conexión de servicio.
Asegúrese también de que no existe ningún servicio de Azure administrado en la subred que se está asociando a la directiva
de punto de conexión de servicio.

Para poder asociar una directiva a una subred, debe crear una red virtual y una subred. Consulte el artículo
sobre la creación de una red virtual para obtener ayuda.
Cuando haya configurado la red virtual y la subred, debe configurar los puntos de conexión de servicio de
red virtual para Azure Storage. En la hoja Red virtual, seleccione Puntos de conexión de ser vicio y, en el
panel siguiente, seleccione [Link] y en Subredes , seleccione la red virtual o la subred
deseada.
Ahora, puede seleccionar la directiva de punto de conexión de servicio en la lista desplegable del panel
anterior, si ya ha creado directivas de punto de conexión de servicio antes de configurar el punto de
conexión de servicio para la subred, tal como se muestra a continuación.

O bien, si va a asociar las directivas de punto de conexión de servicio después de configurar los puntos de
conexión de servicio, puede elegir asociar la subred desde la hoja Directiva de punto de conexión de
servicio. Para ello, vaya al panel Subredes asociadas como se muestra a continuación.
 WARNING
El acceso a los recursos de Azure Storage en todas las regiones se restringe según la directiva de punto de conexión de
servicio de esta subred.

Pasos siguientes
En este artículo, ha creado una directiva de punto de conexión de servicio y la ha asociado a una subred. Para saber
más de las directivas de punto de conexión de servicio, consulte Directivas de punto de conexión de servicio de
redes virtuales (versión preliminar).
 Administración de la filtración de datos a cuentas de
Azure Storage con directivas de punto de conexión
de servicio de red virtual mediante Azure PowerShell
23/09/2020 • 19 minutes to read • Edit Online

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Las directivas de punto de conexión de servicio de red virtual permiten aplicar el control de acceso en cuentas de
Azure Storage desde una red virtual a través de puntos de conexión de servicio. Se trata de una clave para proteger
las cargas de trabajo, administrar qué cuentas de almacenamiento se permiten y dónde se permite la filtración de
datos. En este artículo aprenderá a:
Cree una red virtual.
Agregue una subred y habilite un punto de conexión de servicio para Azure Storage.
Cree dos cuentas de Azure Storage y permita el acceso de red a estas desde la subred creada anteriormente.
Crear una directiva de punto de conexión de servicio para permitir el acceso solo a una de las cuentas de
almacenamiento.
Implementar una máquina virtual (VM) en la subred.
Confirmar el acceso a la cuenta de almacenamiento permitida desde la subred.
Confirmar que se ha denegado el acceso a la cuenta de almacenamiento no permitida desde la subred.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.
 O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar PowerShell de forma local, para realizar los pasos de este artículo necesita la versión 1.0.0
del módulo de Azure PowerShell o cualquier versión posterior. Ejecute Get-Module -ListAvailable Az para buscar la
versión instalada. Si necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si PowerShell se
ejecuta localmente, también debe ejecutar Connect-AzAccount para crear una conexión con Azure.

Creación de una red virtual

Antes de crear una red virtual, cree un grupo de recursos para ella y los demás recursos que se crearon en este
artículo. Cree un grupo de recursos con New-AzResourceGroup. En el ejemplo siguiente se crea un grupo de
recursos denominado myResourceGroup:

New-AzResourceGroup `
-ResourceGroupName myResourceGroup `
-Location EastUS

Cree una red virtual con New-AzVirtualNetwork. En el ejemplo siguiente se crea una red virtual denominada
myVirtualNetwork con el prefijo de dirección [Link]/16.

$virtualNetwork = New-AzVirtualNetwork `
-ResourceGroupName myResourceGroup `
-Location EastUS `
-Name myVirtualNetwork `
-AddressPrefix [Link]/16

Habilitación de un punto de conexión de servicio

Cree una subred en la red virtual. En este ejemplo, se crea una subred denominada Private con un punto de
conexión de servicio para [Link]:

$subnetConfigPrivate = Add-AzVirtualNetworkSubnetConfig `
-Name Private `
-AddressPrefix [Link]/24 `
-VirtualNetwork $virtualNetwork `
-ServiceEndpoint [Link]

$virtualNetwork | Set-AzVirtualNetwork

Restricción del acceso de la red para la subred

Cree reglas de seguridad de grupo de seguridad de red con New-AzNetworkSecurityRuleConfig. La siguiente regla
permite el acceso de salida a las direcciones IP públicas asignadas al servicio Azure Storage:

$rule1 = New-AzNetworkSecurityRuleConfig `
-Name Allow-Storage-All `
-Access Allow `
-DestinationAddressPrefix Storage `
-DestinationPortRange * `
-Direction Outbound `
-Priority 100 -Protocol * `
-SourceAddressPrefix VirtualNetwork `
-SourcePortRange *

La siguiente regla deniega el acceso a todas las direcciones IP públicas. La regla anterior invalida esta regla porque
su prioridad es más alta, lo que permite el acceso a las direcciones IP públicas de Azure Storage.

$rule2 = New-AzNetworkSecurityRuleConfig `
-Name Deny-Internet-All `
-Access Deny `
-DestinationAddressPrefix Internet `
-DestinationPortRange * `
-Direction Outbound `
-Priority 110 -Protocol * `
-SourceAddressPrefix VirtualNetwork `
-SourcePortRange *

La siguiente regla permite que el tráfico de Protocolo de escritorio remoto (RDP) pueda entrar en la subred desde
cualquier lugar. Se permiten las conexiones de Escritorio remoto a la subred, por lo que puede confirmar acceso a la
red a un recurso en un paso posterior.

$rule3 = New-AzNetworkSecurityRuleConfig `
-Name Allow-RDP-All `
-Access Allow `
-DestinationAddressPrefix VirtualNetwork `
-DestinationPortRange 3389 `
-Direction Inbound `
-Priority 120 `
-Protocol * `
-SourceAddressPrefix * `
-SourcePortRange *

Cree un grupo de seguridad de red con New-AzNetworkSecurityGroup. En el ejemplo siguiente se crea un grupo
de seguridad de red denominado myNsgPrivate.

$nsg = New-AzNetworkSecurityGroup `
-ResourceGroupName myResourceGroup `
-Location EastUS `
-Name myNsgPrivate `
-SecurityRules $rule1,$rule2,$rule3

Asocie el grupo de seguridad de red a la subred Private con Set-AzVirtualNetworkSubnetConfig y escriba la

configuración de la subred en la red virtual. En el ejemplo siguiente se asocia el grupo de seguridad de red
myNsgPrivate a la subred Private:
 Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $VirtualNetwork `
-Name Private `
-AddressPrefix [Link]/24 `
-ServiceEndpoint [Link] `
-NetworkSecurityGroup $nsg

$virtualNetwork | Set-AzVirtualNetwork

Restricción del acceso de red a las cuentas de Azure Storage

Los pasos que deben seguirse para restringir el acceso de la red a los recursos creados con servicios de Azure
habilitados para puntos de conexión de servicio varían en función del servicio. Consulte en la documentación de
cada servicio concreto los pasos necesarios para dicho servicio. Como ejemplo, de aquí en adelante se explican los
pasos necesarios para restringir el acceso de red en una cuenta de Azure Storage.
Creación de dos cuentas de almacenamiento
Cree una cuenta de almacenamiento de Azure con New-AzStorageAccount.

$storageAcctName1 = 'allowedaccount'

New-AzStorageAccount `
-Location EastUS `
-Name $storageAcctName1 `
-ResourceGroupName myResourceGroup `
-SkuName Standard_LRS `
-Kind StorageV2

Después de crear la cuenta de almacenamiento, recupere la clave para dicha cuenta en una variable con Get-
AzStorageAccountKey:

$storageAcctKey1 = (Get-AzStorageAccountKey -ResourceGroupName myResourceGroup -AccountName

$storageAcctName1).Value[0]

La clave se utiliza para crear un recurso compartido de archivos en un paso posterior. Especifique $storageAcctKey
y anote el valor, ya que tendrá que escribirlo manualmente más adelante, cuando asigne el recurso compartido de
archivos a una unidad de una máquina virtual.
Ahora repita los pasos anteriores para crear una segunda cuenta de almacenamiento.

$storageAcctName2 = 'notallowedaccount'

New-AzStorageAccount `
-Location EastUS `
-Name $storageAcctName2 `
-ResourceGroupName myResourceGroup `
-SkuName Standard_LRS `
-Kind StorageV2

Recupere también la clave de la cuenta de almacenamiento de esta cuenta para usarla posteriormente para crear
un recurso compartido de archivos.

$storageAcctKey2 = (Get-AzStorageAccountKey -ResourceGroupName myResourceGroup -AccountName

$storageAcctName2).Value[0]
Creación de un recurso compartido de archivos en cada cuenta de almacenamiento
Cree un contexto para la clave y la cuenta de almacenamiento con New-AzStorageContext. El contexto encapsula el
nombre y la clave de la cuenta de almacenamiento:

$storageContext1 = New-AzStorageContext $storageAcctName1 $storageAcctKey1

$storageContext2 = New-AzStorageContext $storageAcctName2 $storageAcctKey2

Cree un recurso compartido de archivos con New-AzStorageShare:

$share1 = New-AzStorageShare my-file-share -Context $storageContext1

$share2 = New-AzStorageShare my-file-share -Context $storageContext2

Denegación de todo el acceso de red a una cuenta de almacenamiento

De forma predeterminada, las cuentas de almacenamiento aceptan conexiones de red procedentes de clientes de
cualquier red. Para limitar el acceso a redes seleccionadas, cambie la acción predeterminada a Deny con Update-
AzStorageAccountNetworkRuleSet. Una vez que se deniega el acceso a la red, no se puede acceder a la cuenta de
almacenamiento desde ninguna red.

Update-AzStorageAccountNetworkRuleSet `
-ResourceGroupName myresourcegroup `
-Name $storageAcctName1 `
-DefaultAction Deny

Update-AzStorageAccountNetworkRuleSet `
-ResourceGroupName myresourcegroup `
-Name $storageAcctName2 `
-DefaultAction Deny

Habilitación del acceso de red solo desde la subred de red virtual

Recupere la red virtual creada con Get-AzVirtualNetwork y recupere el objeto de subred privada en una variable
con Get-AzVirtualNetworkSubnetConfig:

$privateSubnet = Get-AzVirtualNetwork `
-ResourceGroupName myResourceGroup `
-Name myVirtualNetwork `
| Get-AzVirtualNetworkSubnetConfig -Name Private

Permita el acceso a la red a la cuenta de almacenamiento desde la subred Private con Add-
AzStorageAccountNetworkRule.

Add-AzStorageAccountNetworkRule `
-ResourceGroupName myresourcegroup `
-Name $storageAcctName1 `
-VirtualNetworkResourceId $[Link]

Add-AzStorageAccountNetworkRule `
-ResourceGroupName myresourcegroup `
-Name $storageAcctName2 `
-VirtualNetworkResourceId $[Link]

Aplicación de la directiva para permitir el acceso a una cuenta de

almacenamiento válida
Para asegurarse de que los usuarios de la red virtual solo puedan acceder a las cuentas de Azure Storage seguras y
permitidas, puede crear una directiva de punto de conexión de servicio con la lista de cuentas de almacenamiento
permitidas en la definición. Esta directiva se aplicará a la subred de la red virtual que está conectada al
almacenamiento a través de los puntos de conexión de servicio.
Creación de una directiva de punto de conexión de servicio
En esta sección se crea la definición de directiva con la lista de recursos permitidos para el acceso a través del punto
de conexión de servicio.
Recupere el identificador de recurso de la primera cuenta de almacenamiento (permitida).

$resourceId = (Get-AzStorageAccount -ResourceGroupName myresourcegroup -Name $storageAcctName1).id

Cree la definición de directiva para permitir el recurso anterior.

$policyDefinition = New-AzServiceEndpointPolicyDefinition -Name mypolicydefinition `

-Description "Service Endpoint Policy Definition" `
-Service "[Link]" `
-ServiceResource $resourceId

Cree la directiva de punto de conexión de servicio mediante la definición de directiva creada anteriormente.

$sepolicy = New-AzServiceEndpointPolicy -ResourceGroupName myresourcegroup `

-Name mysepolicy -Location EastUS
-ServiceEndpointPolicyDefinition $policyDefinition

Asociación de la directiva de punto de conexión de servicio a la subred de la red virtual

Después de crear la directiva de punto de conexión de servicio, deberá asociarla a la subred de destino con la
configuración del punto de conexión de servicio de Azure Storage.

Set-AzVirtualNetworkSubnetConfig -VirtualNetwork $VirtualNetwork `

-Name Private `
-AddressPrefix [Link]/24 `
-NetworkSecurityGroup $nsg `
-ServiceEndpoint [Link] `
-ServiceEndpointPolicy $sepolicy

$virtualNetwork | Set-AzVirtualNetwork

Validación de la restricción de acceso a las cuentas de Azure Storage

Implementación de la máquina virtual
Para probar el acceso de red a una cuenta de almacenamiento, implemente una VM en la subred.
Cree una máquina virtual en la subred Private con New-AzVM. Cuando ejecute el comando siguiente, se le
solicitarán las credenciales. Los valores que especifique se configuran como el nombre de usuario y la contraseña
de la máquina virtual. La opción -AsJob crea la máquina virtual en segundo plano, así que puede continuar con el
siguiente paso.
 New-AzVm -ResourceGroupName myresourcegroup `
-Location "East US" `
-VirtualNetworkName myVirtualNetwork `
-SubnetName Private `
-Name "myVMPrivate" -AsJob

Se devuelve una salida similar a la del siguiente ejemplo:

Id Name PSJobTypeName State HasMoreData Location Command

-- ---- ------------- ----- ----------- -------- -------
1 Long Running... AzureLongRun... Running True localhost New-AzVM

Confirmación del acceso a la cuenta de almacenamiento permitida

Use Get-AzPublicIpAddress para devolver la dirección IP pública de una máquina virtual. En el siguiente ejemplo se
devuelve la dirección IP pública de la máquina virtual myVmPrivate:

Get-AzPublicIpAddress `
-Name myVmPrivate `
-ResourceGroupName myResourceGroup `
| Select IpAddress

Reemplace <publicIpAddress> en el siguiente comando, por la dirección IP pública devuelta por el comando
anterior y, a continuación, escriba el siguiente comando:

mstsc /v:<publicIpAddress>

Se crea un archivo de Protocolo de Escritorio remoto (.rdp) y se descarga en su equipo. Abra el archivo .rdp
descargado. Cuando se le pida, seleccione Conectar . Escriba el nombre de usuario y la contraseña que especificó al
crear la máquina virtual. Puede que deba seleccionar More choices (Más opciones) y, luego, Use a different
account (Usar una cuenta diferente), para especificar las credenciales que escribió al crear la máquina virtual.
Seleccione Aceptar . Puede recibir una advertencia de certificado durante el proceso de inicio de sesión. Si recibe la
advertencia, seleccione Sí o Continuar para continuar con la conexión.
En la VM myVmPrivate, asigne el recurso compartido de archivos de Azure de la cuenta de almacenamiento
permitida a la unidad Z con PowerShell.

$acctKey = ConvertTo-SecureString -String $storageAcctKey1 -AsPlainText -Force

$credential = New-Object [Link] -ArgumentList ("Azure\allowedaccount"),
$acctKey
New-PSDrive -Name Z -PSProvider FileSystem -Root "\\[Link]\my-file-share" -
Credential $credential

PowerShell devuelve una salida similar a la del ejemplo siguiente:

Name Used (GB) Free (GB) Provider Root

---- --------- --------- -------- ----
Z FileSystem \\[Link]\my-f...

El recurso compartido de archivos de Azure se ha asignado correctamente a la unidad Z.

Cierre la sesión de Escritorio remoto a la máquina virtual myVmPrivate.
Comprobación del acceso denegado a la cuenta de almacenamiento no permitida
En la misma VM myVmPrivate, intente asignar el recurso compartido de archivos de Azure a la unidad X.

$acctKey = ConvertTo-SecureString -String $storageAcctKey1 -AsPlainText -Force

$credential = New-Object [Link] -ArgumentList "Azure\notallowedaccount",
$acctKey
New-PSDrive -Name X -PSProvider FileSystem -Root "\\[Link]\my-file-share" -
Credential $credential

El acceso al recurso compartido se deniega y recibe el error New-PSDrive : Access is denied . Se denegó el acceso
porque la cuenta de almacenamiento notallowedaccount no está en la lista de recursos permitidos en la directiva
de punto de conexión de servicio.
Cierre la sesión de Escritorio remoto a la máquina virtual myVmPublic.

Limpieza de recursos
Cuando ya no lo necesite, puede usar Remove-AzResourceGroup para quitar el grupo de recursos y todos los
recursos que contiene:

Remove-AzResourceGroup -Name myResourceGroup -Force

Pasos siguientes
En este artículo, ha aplicado una directiva de punto de conexión de servicio a través de un punto de conexión de
servicio de Azure Virtual Network para Azure Storage. Ha creado cuentas de Azure Storage y limitado el acceso de
red solo a determinadas cuentas de almacenamiento (por tanto, denegado a otras) desde una subred de la red
virtual. Para más información sobre las directivas de punto de conexión de servicio, consulte Información general
sobre las directivas de punto de conexión de servicio.
 Administración de la filtración de datos a cuentas de
Azure Storage con directivas de punto de conexión
de servicio de red virtual mediante la CLI de Azure
23/09/2020 • 17 minutes to read • Edit Online

Las directivas de punto de conexión de servicio de red virtual permiten aplicar el control de acceso en cuentas de
Azure Storage desde una red virtual a través de puntos de conexión de servicio. Se trata de una clave para proteger
las cargas de trabajo, administrar qué cuentas de almacenamiento se permiten y dónde se permite la filtración de
datos. En este artículo aprenderá a:
Crear una red virtual y agregar una subred.
Habilitar un punto de conexión de servicio para Azure Storage.
Crear dos cuentas de Azure Storage y permita el acceso de red a estas desde la subred creada anteriormente.
Crear una directiva de punto de conexión de servicio para permitir el acceso solo a una de las cuentas de
almacenamiento.
Implementar una máquina virtual (VM) en la subred.
Confirmar el acceso a la cuenta de almacenamiento permitida desde la subred.
Confirmar que se ha denegado el acceso a la cuenta de almacenamiento no permitida desde la subred.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Si decide instalar y usar la CLI en un entorno local, para esta guía de inicio rápido es preciso que ejecute la versión
2.0.28 de la CLI de Azure o una versión posterior. Para encontrar la versión, ejecute az --version . Si necesita
instalarla o actualizarla, vea Instalación de la CLI de Azure.

Creación de una red virtual

Antes de crear una red virtual, cree un grupo de recursos para ella y los demás recursos que se crearon en este
artículo. Cree un grupo de recursos con az group create. En el ejemplo siguiente, se crea un grupo de recursos
denominado myResourceGroup en la ubicación eastus.

az group create \
--name myResourceGroup \
--location eastus

Cree una red virtual con una subred con az network vnet create.

az network vnet create \

--name myVirtualNetwork \
--resource-group myResourceGroup \
--address-prefix [Link]/16 \
--subnet-name Private \
--subnet-prefix [Link]/24

Habilitación de un punto de conexión de servicio

En este ejemplo, se crea un punto de conexión de servicio para [Link] para la subred Private:

az network vnet subnet create \

--vnet-name myVirtualNetwork \
--resource-group myResourceGroup \
--name Private \
--address-prefix [Link]/24 \
--service-endpoints [Link]

Restricción del acceso de la red para una subred

Cree un grupo de seguridad de red con az network nsg create. En el ejemplo siguiente se crea un grupo de
seguridad de red denominado myNsgPrivate.

az network nsg create \

--resource-group myResourceGroup \
--name myNsgPrivate

Asocie el grupo de seguridad de red a la subred Private con az network vnet subnet update. En el ejemplo siguiente
se asocia el grupo de seguridad de red myNsgPrivate a la subred Private:

az network vnet subnet update \

--vnet-name myVirtualNetwork \
--name Private \
--resource-group myResourceGroup \
--network-security-group myNsgPrivate
Cree reglas de seguridad con az network nsg rule create. La regla siguiente permite el acceso de salida a las
direcciones IP públicas asignadas al servicio Azure Storage:

az network nsg rule create \

--resource-group myResourceGroup \
--nsg-name myNsgPrivate \
--name Allow-Storage-All \
--access Allow \
--protocol "*" \
--direction Outbound \
--priority 100 \
--source-address-prefix "VirtualNetwork" \
--source-port-range "*" \
--destination-address-prefix "Storage" \
--destination-port-range "*"

Cada grupo de seguridad de red contiene varias reglas de seguridad predeterminadas. La regla siguiente invalida
una regla de seguridad predeterminada que permite el acceso de salida a todas las direcciones IP públicas. La
opción destination-address-prefix "Internet" deniega el acceso de salida a todas las direcciones IP públicas. La
regla anterior invalida esta regla porque su prioridad es más alta, lo que permite el acceso a las direcciones IP
públicas de Azure Storage.

az network nsg rule create \

--resource-group myResourceGroup \
--nsg-name myNsgPrivate \
--name Deny-Internet-All \
--access Deny \
--protocol "*" \
--direction Outbound \
--priority 110 \
--source-address-prefix "VirtualNetwork" \
--source-port-range "*" \
--destination-address-prefix "Internet" \
--destination-port-range "*"

La siguiente regla permite la entrada de tráfico SSH en la subred desde cualquier lugar. La regla invalidará cualquier
regla de seguridad predeterminada que deniegue todo el tráfico de entrada procedente de Internet. SSH se admite
en la subred, por lo que dicha conectividad podrá probarse en un paso posterior.

az network nsg rule create \

--resource-group myResourceGroup \
--nsg-name myNsgPrivate \
--name Allow-SSH-All \
--access Allow \
--protocol Tcp \
--direction Inbound \
--priority 120 \
--source-address-prefix "*" \
--source-port-range "*" \
--destination-address-prefix "VirtualNetwork" \
--destination-port-range "22"

Restricción del acceso de red a las cuentas de Azure Storage

En esta sección se enumeran los pasos para restringir el acceso de red a una cuenta de Azure Storage desde la
subred especificada en una red virtual a través de un punto de conexión de servicio.
Crear una cuenta de almacenamiento
Cree dos cuentas de almacenamiento de Azure con az storage account create.

storageAcctName1="allowedstorageacc"

az storage account create \

--name $storageAcctName1 \
--resource-group myResourceGroup \
--sku Standard_LRS \
--kind StorageV2

storageAcctName2="notallowedstorageacc"

az storage account create \

--name $storageAcctName2 \
--resource-group myResourceGroup \
--sku Standard_LRS \
--kind StorageV2

Después de crear las cuentas de almacenamiento, recupere la cadena de conexión para dichas cuentas en una
variable con az storage account show-connection-string. La cadena de conexión se utiliza para crear un recurso
compartido de archivos en un paso posterior.

saConnectionString1=$(az storage account show-connection-string \

--name $storageAcctName1 \
--resource-group myResourceGroup \
--query 'connectionString' \
--out tsv)

saConnectionString2=$(az storage account show-connection-string \

--name $storageAcctName2 \
--resource-group myResourceGroup \
--query 'connectionString' \
--out tsv)

Vea el contenido de la variable y anote el valor de AccountKey devuelto en la salida, porque se utilizará en un paso
posterior.

echo $saConnectionString1

echo $saConnectionString2

Creación de un recurso compartido de archivos en la cuenta de almacenamiento

Cree un recurso compartido de archivos en la cuenta de almacenamiento con az storage share create. En un paso
posterior, este recurso compartido de archivos está montado para confirmar el acceso de red a él.

az storage share create \

--name my-file-share \
--quota 2048 \
--connection-string $saConnectionString1 > /dev/null

az storage share create \

--name my-file-share \
--quota 2048 \
--connection-string $saConnectionString2 > /dev/null

Denegación de todo el acceso de red a la cuenta de almacenamiento

De forma predeterminada, las cuentas de almacenamiento aceptan conexiones de red procedentes de clientes de
cualquier red. Para limitar el acceso a redes seleccionadas, cambie la acción predeterminada a Deny con az storage
account update. Una vez que se deniega el acceso a la red, no se puede acceder a la cuenta de almacenamiento
desde ninguna red.

az storage account update \

--name $storageAcctName1 \
--resource-group myResourceGroup \
--default-action Deny

az storage account update \

--name $storageAcctName2 \
--resource-group myResourceGroup \
--default-action Deny

Habilitación del acceso de red desde la subred de la red virtual

Permita el acceso a la red a la cuenta de almacenamiento desde la subred Private con az storage account network-
rule add.

az storage account network-rule add \

--resource-group myResourceGroup \
--account-name $storageAcctName1 \
--vnet-name myVirtualNetwork \
--subnet Private

az storage account network-rule add \

--resource-group myResourceGroup \
--account-name $storageAcctName2 \
--vnet-name myVirtualNetwork \
--subnet Private

Aplicación de la directiva para permitir el acceso a una cuenta de

almacenamiento válida
Las directivas de punto de conexión de servicio de Azure solo están disponibles para Azure Storage. Por lo tanto,
habilitaremos el punto de conexión de servicio para [Link] en esta subred para este ejemplo de
configuración.
Las directivas de punto de conexión de servicio se aplican a los puntos de conexión de servicio. Comenzaremos por
crear una directiva de punto de conexión de servicio. A continuación, vamos a crear las definiciones de directiva en
esta directiva para las cuentas de Azure Storage que se van a incluir en la lista de permitidos para esta subred.
Creación de una directiva de punto de conexión de servicio

az network service-endpoint policy create \

--resource-group myResourceGroup \
--name mysepolicy \
--location eastus

Guarde el URI de recurso para la cuenta de almacenamiento permitida en una variable. Antes de ejecutar el
comando siguiente, reemplace <your-subscription-id> por el valor real de su identificador de suscripción.

$serviceResourceId="/subscriptions/<your-subscription-
id>/resourceGroups/myResourceGroup/providers/[Link]/storageAccounts/allowedstorageacc"

Cree y agregue una definición de directiva para permitir la cuenta de Azure Storage anterior en la directiva de
punto de conexión de servicio.
 az network service-endpoint policy-definition create \
--resource-group myResourceGroup \
--policy-name mysepolicy \
--name mypolicydefinition \
--service "[Link]" \
--service-resources $serviceResourceId

Y actualice la subred de la red virtual para asociarla a la directiva de punto de conexión de servicio creada en el
paso anterior.

az network vnet subnet update \

--vnet-name myVirtualNetwork \
--resource-group myResourceGroup \
--name Private \
--service-endpoints [Link] \
--service-endpoint-policy mysepolicy

Validación de la restricción de acceso a las cuentas de Azure Storage

Creación de la máquina virtual
Para probar el acceso de red a una cuenta de almacenamiento, implemente una máquina virtual en la subred.
Cree una máquina virtual en la subred Private con az vm create. Si las claves SSH no existen en la ubicación de
claves predeterminada, el comando las crea. Para utilizar un conjunto específico de claves, utilice la opción
--ssh-key-value .

az vm create \
--resource-group myResourceGroup \
--name myVmPrivate \
--image UbuntuLTS \
--vnet-name myVirtualNetwork \
--subnet Private \
--generate-ssh-keys

La máquina virtual tarda en crearse unos minutos. Después de la creación, tome nota de publicIpAddress en la
salida devuelta. En un paso posterior, usaremos esta dirección para obtener acceso a la máquina virtual desde
Internet.
Confirmación del acceso a la cuenta de almacenamiento
SSH en la máquina virtual myVmPrivate. Reemplace <publicIpAddress> por la dirección IP pública de la máquina
virtual myVmPrivate.

ssh <publicIpAddress>

Cree una carpeta para un punto de montaje:

sudo mkdir /mnt/MyAzureFileShare1

Monte el recurso compartido de archivos de Azure en el directorio que ha creado. Antes de ejecutar el comando
siguiente, reemplace <storage-account-key> por el valor de AccountKey de $saConnectionString1 .
 sudo mount --types cifs //[Link]/my-file-share /mnt/MyAzureFileShare1 --
options vers=3.0,username=allowedstorageacc,password=<storage-account-
key>,dir_mode=0777,file_mode=0777,serverino

Recibirá el símbolo del sistema user@myVmPrivate:~$ . El recurso compartido de archivos de Azure se montó
correctamente en /mnt/MyAzureFileShare.
Confirmación de la denegación del acceso a la cuenta de almacenamiento
En la misma máquina virtual myVmPrivate, cree un directorio para un punto de montaje:

sudo mkdir /mnt/MyAzureFileShare2

Intente montar el recurso compartido de archivos de Azure desde la cuenta de almacenamiento

notallowedstorageacc en el directorio creado. En este artículo se asume que ha implementado la versión más
reciente de Ubuntu. Si está utilizando versiones anteriores de Ubuntu, consulte Montaje en Linux para instrucciones
adicionales sobre el montaje de recursos compartidos de archivos.
Antes de ejecutar el comando siguiente, reemplace <storage-account-key> por el valor de AccountKey de
$saConnectionString2 .

sudo mount --types cifs //[Link]/my-file-share /mnt/MyAzureFileShare2 --

options vers=3.0,username=notallowedstorageacc,password=<storage-account-
key>,dir_mode=0777,file_mode=0777,serverino

Se ha denegado el acceso y recibe un error de mount error(13): Permission denied , porque esta cuenta de
almacenamiento no está en la lista de permitidos de la directiva de punto de conexión de servicio que se aplica a la
subred.
Salga de la sesión de SSH en la máquina virtual myVmPublic.

Limpieza de recursos
Cuando ya no se necesiten, use az group delete para quitar el grupo de recursos y todos los recursos que contenga.

az group delete --name myResourceGroup --yes

Pasos siguientes
En este artículo, ha aplicado una directiva de punto de conexión de servicio a través de un punto de conexión de
servicio de Azure Virtual Network para Azure Storage. Ha creado cuentas de Azure Storage y limitado el acceso de
red solo a determinadas cuentas de almacenamiento (por tanto, denegado a otras) desde una subred de la red
virtual. Para más información sobre las directivas de punto de conexión de servicio, consulte Información general
sobre las directivas de punto de conexión de servicio.
 Administración de Protección contra DDoS de Azure
estándar mediante Azure Portal
23/09/2020 • 27 minutes to read • Edit Online

Obtenga información acerca de cómo habilitar y deshabilitar la protección contra denegación de servicio (DDoS)
distribuido y usar la telemetría para mitigar un ataque DDoS con Protección contra DDoS de Azure estándar.
Protección contra DDoS de Azure estándar protege los recursos de Azure, como las máquinas virtuales, los
equilibradores de carga y las puertas de enlace de aplicaciones que disponen de una dirección IP pública de Azure
asignada. Para más información sobre el estándar de protección contra DDoS y sus funcionalidades, vea
Introducción a Protección contra DDoS de Azure estándar.
Antes de completar los pasos de este tutorial, inicie sesión en Azure Portal en [Link] con una
cuenta asignada al rol de colaborador de red o a un rol personalizado que tenga asignadas las acciones apropiadas
en Permisos.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Creación de un plan de protección contra DDoS

Un plan de protección contra DDoS define un conjunto de redes virtuales que tiene habilitada la protección contra
DDoS estándar en distintas suscripciones. Puede configurar un plan de protección contra DDoS para la
organización y vincular redes virtuales de distintas suscripciones al mismo plan. El propio plan de protección
contra DDoS también está asociado a una suscripción, la que selecciona durante la creación del plan. El plan de
DDoS Protection funciona en todas las regiones y suscripciones. Ejemplo: puede crear el plan en la Región Este de
EE. UU. y vincularlo a la suscripción número 1 en su inquilino. El mismo plan se puede vincular a las redes virtuales
de otras suscripciones en diferentes regiones, a través de su inquilino. La suscripción a la que está asociado el plan
incurre en la factura mensual recurrente del plan, además de cargos de uso por encima del límite, en caso de que la
cantidad de direcciones IP públicas protegidas supere las 100. Para más información sobre los precios de DDoS,
consulte los detalles de precios.
En la mayoría de las organizaciones, no es necesario crear más de un plan. Un plan no puede moverse entre
suscripciones. Si desea cambiar la suscripción en que se encuentra un plan, debe eliminar el plan existente y crear
uno nuevo.
1. Seleccione Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Busque DDoS . Seleccione Plan de protección contra DDoS cuando aparezca en los resultados de la
búsqueda.
3. Seleccione Crear .
4. Escriba o seleccione sus propios valores, o bien escriba o seleccione los valores de ejemplo siguientes y,
luego, seleccione Crear :

C O N F IGURA C IÓ N VA L UE

Nombre myDdosProtectionPlan

Subscription Seleccione su suscripción.

Resource group Seleccione Crear nuevo y escriba myResourceGroup

 C O N F IGURA C IÓ N VA L UE

Location Este de EE. UU.

Habilitación de DDoS para una red virtual nueva

1. Seleccione Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Redes y Red vir tual .
3. Escriba o seleccione sus propios valores, o bien escriba o seleccione los valores de ejemplo siguientes,
acepte el resto de los valores predeterminados y, luego, seleccione Crear :

C O N F IGURA C IÓ N VA L UE

Nombre myVirtualNetwork

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y, luego, seleccione

myResourceGroup

Location Este de EE. UU.

DDoS Protection Standard Seleccione Habilitar . El plan que selecciona puede estar
en la misma suscripción que la red virtual, o una
suscripción distinta, pero ambas suscripciones deben estar
asociadas al mismo inquilino de Azure Active Directory.

No puede mover una red virtual a otro grupo de recursos ni a otra suscripción si DDoS Standard está habilitado
para la red virtual. Si tiene que mover una red virtual que tenga habilitado DDoS Standard, primero deshabilítelo,
mueva la red virtual y, luego, habilite DDoS Standard. Después de eso, se restablecen los umbrales de directiva
ajustados automáticamente para todas las direcciones IP públicas protegidas en la red virtual.

Habilitación de DDoS para una red virtual existente

1. Cree un plan de protección contra DDoS con los pasos descritos en Creación de un plan de protección contra
DDoS, si no tiene un plan de protección de DDoS existente.
2. Seleccione Crear un recurso en la esquina superior izquierda de Azure Portal.
3. Escriba el nombre de la red virtual para la que desea habilitar DDoS Protection Standard en el cuadro Buscar
recursos, ser vicios y documentos en la parte superior del portal. Seleccione el nombre de la red virtual
cuando aparezca en los resultados de la búsqueda.
4. Seleccione Protección DDoS en CONFIGURACIÓN .
5. Seleccione Estándar . En Plan de protección contra DDoS , seleccione un plan de protección contra DDoS
existente o el plan que creó en el paso 1 y, luego, seleccione Guardar . El plan que selecciona puede estar en la
misma suscripción que la red virtual, o una suscripción distinta, pero ambas suscripciones deben estar
asociadas al mismo inquilino de Azure Active Directory.
Comandos
CLI de Azure: az network ddos-protection create
Powershell: New-AzDdosProtectionPlan
Deshabilitación de DDoS para una red virtual
1. Escriba el nombre de la red virtual para la que desea deshabilitar DDoS Protection Standard en el cuadro
Buscar recursos, ser vicios y documentos en la parte superior del portal. Seleccione el nombre de la red
virtual cuando aparezca en los resultados de la búsqueda.
2. Seleccione En DDoS Protection estándar , seleccione Deshabilitar .
Comandos
CLI de Azure: az network ddos-protection delete
Powershell: Remove-AzDdosProtectionPlan

Trabajo con planes de protección contra DDoS

1. Seleccione Todos los ser vicios en la parte superior izquierda del portal.
2. Escriba DDoS en el cuadro Filtrar . Seleccione Planes de protección contra DDoS cuando aparezca en los
resultados.
3. Seleccione el plan de protección que desea ver en la lista.
4. Aparecen todas las redes virtuales asociadas al plan.
5. Si desea eliminar un plan, primero debe desasociar todas las redes virtuales que tiene asociadas. Para
desasociar un plan de una red virtual, consulte Deshabilitación de DDoS para una red virtual.

Configuración de alertas para métricas de protección contra DDoS

Puede seleccionar cualquiera de las métricas de protección contra DDoS disponibles para que le avisen cuando hay
una mitigación activa durante un ataque mediante la configuración de alertas de Azure Monitor. Cuando se
cumplan las condiciones, recibirá un correo electrónico de alerta en la dirección especificada:
1. Seleccione Todos los ser vicios en la parte superior izquierda del portal.
2. Escriba Monitor en el cuadro Filtrar . Seleccione Monitor cuando aparezca en los resultados.
3. Seleccione Métricas en SERVICIOS COMPARTIDOS .
4. Escriba o seleccione sus propios valores, o bien escriba los valores de ejemplo siguientes, acepte el resto de
los valores predeterminados y, luego, seleccione Aceptar :

C O N F IGURA C IÓ N VA L UE

Nombre myDdosAlert

Subscription Seleccione la suscripción que contiene la dirección IP

pública para la que desea recibir alertas.

Resource group Seleccione el grupo de recursos que contiene la dirección

IP pública para la que desea recibir alertas.
 C O N F IGURA C IÓ N VA L UE

Resource Seleccione la dirección IP pública que contiene la dirección

IP pública para la que desea recibir alertas. DDoS
supervisa las direcciones IP públicas asignadas a los
recursos dentro de una red virtual. Si no tiene ningún
recurso con direcciones IP públicas en la red virtual,
primero debe crear un recurso con una dirección IP
pública. Puede supervisar la dirección IP pública de todos
los recursos implementados a través de Resource Manager
(no clásico) que aparecen en Red virtual para servicios de
Azure, excepto para entornos de Azure App Service y
Azure VPN Gateway. Para continuar con este tutorial,
puede crear rápidamente una máquina virtual Windows o
Linux.

Métrica Bajo ataque de DDoS o no

Umbral 1: un 1 significa que está siendo atacado. Un 0 significa

que no está siendo atacado.

Período Seleccione el valor que prefiera.

Notificar por correo electrónico Active la casilla de verificación

Administrador adicional Escriba su dirección de correo electrónico si no es

propietario del correo electrónico, colaborador o lector de
la suscripción.

Dentro de unos pocos minutos después de la detección del ataque, recibirá un correo electrónico con
métricas de Azure Monitor que tiene un aspecto similares a la imagen siguiente:

Para simular un ataque de DDoS para validar la alerta, consulte Validación de la detección de DDoS.
Puede aprender más sobre configurar webhooks y aplicaciones lógicas para la creación de alertas.

Uso de telemetría de protección contra DDoS

La telemetría para un ataque se proporciona a través de Azure Monitor en tiempo real. La telemetría está
disponible solo durante el tiempo en que una dirección IP pública está en proceso de mitigación. No ve ninguna
telemetría antes o después de mitigar un ataque.
1. Seleccione Todos los ser vicios en la parte superior izquierda del portal.
2. Escriba Monitor en el cuadro Filtrar . Seleccione Monitor cuando aparezca en los resultados.
3. Seleccione Métricas en SERVICIOS COMPARTIDOS .
4. Seleccione la suscripción y el grupo de recursos que contienen la dirección IP pública para la que desea la
telemetría.
5. Seleccione la dirección IP pública para el tipo de recurso , luego seleccione la dirección IP pública específica
para la que desea la telemetría.
6. En el lado izquierdo de la pantalla se muestra una serie de métricas disponibles . Cuando se seleccionan estas
métricas, se representan en el gráfico de métricas de Azure Monitor , en la pantalla de información general.
7. Seleccione el tipo de agregación como Máximo .
Los nombres de las métricas presentan distintos tipos de paquetes y bytes frente a paquetes, con una construcción
básica de nombres de etiqueta en cada métrica, como se muestra aquí:
Nombre de etiqueta de eliminado (por ejemplo, Paquetes de entrada quitados por DDoS ): El número
de paquetes que el sistema de protección contra DDoS elimina o limpia.
Nombre de etiqueta de reenviado (por ejemplo, Paquetes de entrada reenviados por DDoS ): el
número de paquetes que reenvía el sistema DDoS a la dirección IP virtual de destino (tráfico que no se filtró).
Sin nombre de etiqueta (por ejemplo DDoS de paquetes de entrada ): el número total de paquetes que
han llegado al sistema de limpieza (representa la suma de los paquetes eliminados y los reenviados).
Para simular un ataque de DDoS para validar la telemetría, consulte Validación de la detección de DDoS.

Visualización de las directivas de mitigación de DDoS

DDoS Protection Standard aplica tres directivas de mitigación de ajuste automático (TCP SYN, TCP y UDP) a cada
dirección IP pública del recurso protegido, en la red virtual que tiene habilitado DDoS. Puede ver los umbrales de
directiva si selecciona las métricas Paquetes entrantes TCP para desencadenar la mitigación de DDoS y
Paquetes entrantes UDP para desencadenar la mitigación de DDoS con el tipo de agregación como
"Máximo", tal como se muestra en la siguiente imagen:

Los umbrales de las directivas se configuran automáticamente con nuestro sistema de generación de perfiles de
tráfico de red basado en aprendizaje automático de Azure. Solo cuando se supera el umbral de la directiva, la
mitigación de DDoS se produce para la dirección IP que está siendo atacada.

Configuración del análisis de ataques DDoS

La versión estándar de Azure DDoS Protection proporciona información detallada y visualización de ataques con
DDoS Attack Analytics. Los clientes que protegen sus redes virtuales frente a ataques DDoS disponen de visibilidad
detallada sobre el tráfico de ataques y las acciones llevadas a cabo para mitigarlos mediante informes de
mitigación de ataques y registros de flujo de mitigación.

Configuración de informes de mitigación de ataques DDoS

Los informes de mitigación de ataques usan los datos del protocolo Netflow que se agrega para proporcionar
información detallada sobre el ataque en el recurso. Cada vez que un recurso IP público es objeto de ataque, tan
pronto se inicia la mitigación se inicia la generación de informes. Durante todo el período de mitigación, habrá un
informe incremental que se genera cada cinco minutos y un informe posterior a la mitigación. Su finalidad es
garantizar que en caso de que el ataque DDoS continúe durante mucho tiempo, podrá ver la instantánea más
actual del informe de mitigación cada cinco minutos y un resumen completo una vez finalizada la mitigación del
ataque.
1. Seleccione Todos los ser vicios en la parte superior izquierda del portal.
2. Escriba Monitor en el cuadro Filtrar . Seleccione Monitor cuando aparezca en los resultados.
3. En CONFIGURACIÓN , seleccione Configuración de diagnóstico .
4. Seleccione la suscripción y el grupo de recursos que contienen la dirección IP pública que desea
registrar.
5. Seleccione la dirección IP pública para el tipo de recurso , luego seleccione la dirección IP pública
específica para la que desea registrar las métricas.
6. Seleccione Turn on diagnostics to collect the DDoSMitigationRepor ts log (Activar diagnósticos para
recopilar el registro DDoSMitigationReports) y, luego, seleccione tantas opciones de las siguientes como
necesite:
Archivar en una cuenta de almacenamiento : los datos se escriben en una cuenta de Azure Storage.
Para más información sobre esta opción, consulte Archivo de registros de recursos.
Transmisión a un centro de eventos : permite que un receptor de registros seleccione los registros
mediante una instancia de Azure Event Hub. Los centros de eventos habilitan la integración con Splunk y
otros sistemas SIEM. Para más información sobre esta opción, consulte Transmisión de registros de
recursos a un centro de eventos.
Enviar a Log Analytics : Escribe registros en el servicio Azure Monitor. Para obtener más información
sobre esta opción, consulte Recopilación de registros para su uso en los registros de Azure Monitor.
Tanto los informes de mitigación incremental como los posteriores a los ataques incluyen los siguientes campos:
Vectores de ataque
Estadísticas de tráfico
Motivo de paquetes descartados
Protocolos implicados
10 países o regiones de origen principales
10 ASN de origen principales

Configuración de registros de flujo de mitigación de ataques DDoS

Los registros de flujo de mitigación de ataques le permiten revisar casi en tiempo real el tráfico descartado, el
tráfico reenviado y otros puntos de datos interesantes durante un ataque DDoS activo. Puede ingerir el flujo
constante de estos datos en sus sistemas SIEM mediante un centro de eventos para la supervisión casi en tiempo
real, realizar acciones y solucionar la necesidad de sus operaciones de defensa.
1. Seleccione Todos los ser vicios en la parte superior izquierda del portal.
2. Escriba Monitor en el cuadro Filtrar . Seleccione Monitor cuando aparezca en los resultados.
3. En CONFIGURACIÓN , seleccione Configuración de diagnóstico .
4. Seleccione la suscripción y el grupo de recursos que contienen la dirección IP pública que desea
registrar.
5. Seleccione la dirección IP pública para el tipo de recurso , luego seleccione la dirección IP pública
específica para la que desea registrar las métricas.
6. Seleccione Turn on diagnostics to collect the DDoSMitigationFlowLogs log (Activar diagnósticos
para recopilar el registro DDoSMitigationFlowLogs) y, luego, seleccione tantas opciones de las siguientes
como necesite:
Archivar en una cuenta de almacenamiento : los datos se escriben en una cuenta de Azure Storage.
Para más información sobre esta opción, consulte Archivo de registros de recursos.
Transmisión a un centro de eventos : permite que un receptor de registros seleccione los registros
mediante una instancia de Azure Event Hub. Los centros de eventos habilitan la integración con Splunk y
otros sistemas SIEM. Para más información sobre esta opción, consulte Transmisión de registros de
recursos a un centro de eventos.
Enviar a Log Analytics : Escribe registros en el servicio Azure Monitor. Para obtener más información
sobre esta opción, consulte Recopilación de registros para su uso en los registros de Azure Monitor.
7. Para ver los datos de registros de flujo en el panel de análisis de Azure, puede importar el panel de ejemplo
desde [Link]
Los registros de flujo tienen los siguientes campos:
IP de origen
IP de destino
Puerto de origen
Puerto de destino
Tipo de protocolo
Acción realizada durante la mitigación
El análisis de ataques solo funcionará si el estándar DDoS Protection está habilitado en la red virtual de la dirección
IP pública.

Validación de la detección de DDoS

Microsoft se ha asociado con BreakingPoint Cloud para crear una interfaz en la que pueda generar tráfico
destinado a las direcciones IP públicas que tengan habilitado el servicio DDoS Protection con fines de simulación.
La simulación de BreakPoint Cloud le permite:
Comprobar en qué medida Microsoft Azure DDoS Protection protege sus recursos de Azure frente a ataques de
DDoS.
Optimizar el proceso de respuesta a incidentes durante el ataque de DDoS.
Documentar el cumplimiento normativo de DDoS.
Enseñar a los equipos de seguridad de red.

Ver las alertas de protección DDoS en Azure Security Center

Azure Security Center proporciona una lista de alertas de seguridad, que cuentan con información para ayudarle a
investigar y solucionar problemas. Gracias a esta característica, obtendrá una vista unificada de las alertas,
incluyendo las alertas relacionadas con los ataques DDoS y las acciones que se tomaron para mitigar el ataque a
corto plazo. Hay dos alertas específicas que verá en cualquier mitigación y detección de ataques DDoS:
 Ataque DDoS detectado para IP pública : Esta alerta se genera cuando el servicio de protección contra
DDoS detecta que una de sus direcciones IP públicas es el objetivo de un ataque DDoS.
Ataque DDoS mitigado para IP pública : Esta alerta se genera cuando se ha mitigado un ataque a la
dirección IP pública. Para ver las alertas, abra el Centro de seguridad en Azure Portal. En Protección contra
amenazas , seleccione Aler tas de seguridad . La siguiente captura de pantalla muestra un ejemplo de las
alertas de ataques DDoS.

Las alertas incluyen información general sobre la dirección IP pública que está bajo ataque, información de
inteligencia geográfica y de amenazas y los pasos para solucionar el problema.

Permisos
Para trabajar con planes de protección contra DDoS, su cuenta debe estar asignada al rol de colaborador de red o a
un rol personalizado que tenga asignadas las acciones adecuadas que se muestran en la tabla siguiente:

A C C IÓ N N O M B RE

[Link]/ddosProtectionPlans/read Obtención de un plan de protección contra DDoS

[Link]/ddosProtectionPlans/write Creación o actualización de un plan de protección contra

DDoS

[Link]/ddosProtectionPlans/delete Eliminación de un plan de protección contra DDoS

[Link]/ddosProtectionPlans/join/action Unión a un plan de protección contra DDoS

Para habilitar la protección contra DDoS para una red virtual, su cuenta también debe estar asignada a las acciones
para redes virtuales adecuadas.

Pasos siguientes
Creación y asignación de definiciones de Azure Policy para redes virtuales
 Asociación con Azure DDoS Protection estándar
23/09/2020 • 9 minutes to read • Edit Online

En este artículo se describen las oportunidades de asociación habilitadas por Azure DDoS Protection estándar. Este
artículo está diseñado para ayudar a los administradores de productos y a los roles de desarrollo empresarial a
comprender las rutas de inversión, y para ofrecer información sobre las propuestas de valor de la asociación.

Información previa
Los ataques por denegación de servicio distribuido (DDoS) son uno de los principales problemas de seguridad y
disponibilidad que notifican los clientes que mueven sus aplicaciones a la nube. La extorsión y el hacktivismo son
motivaciones comunes de los ataques DDoS, que han aumentado de forma constante en el tipo, la escala y la
frecuencia de repetición, ya que cometerlos resulta relativamente fácil y económico.
Azure DDoS Protection ofrece técnicas defensivas contra las amenazas de DDoS más sofisticadas, en las que usa la
escala global de Redes de Azure. El servicio proporciona funcionalidades mejoradas de mitigación de DDoS para las
aplicaciones y los recursos implementados en redes virtuales.
Los asociados tecnológicos pueden proteger los recursos de sus clientes de forma nativa con Azure DDoS
Protection estándar para abordar los problemas de disponibilidad y confiabilidad debido a ataques DDoS.

Introducción a Azure DDoS Protection estándar

Azure DDoS Protection estándar proporciona funcionalidades mejoradas de mitigación de DDoS contra ataques
DDoS de nivel 3 y 4. A continuación se describen las características clave del servicio DDoS Protection estándar.
Ajuste adaptable en tiempo real
Para cada aplicación protegida, Azure DDoS Protection estándar ajusta automáticamente los umbrales de la
directiva de mitigación de DDoS en función de los patrones de perfil de tráfico de la aplicación. El servicio consigue
esta personalización basándose en dos tipos de información:
Aprendizaje automático de los patrones de tráfico de los niveles 3 y 4 (por IP) de cada cliente.
Reducción de los falsos positivos ya que el escalado de Azure le permite absorber una cantidad importante de
tráfico.
Análisis, telemetría, supervisión y alertas de los ataques
Azure DDoS Protection identifica y mitiga los ataques DDoS sin intervención del usuario.
Si el recurso protegido está en la suscripción que se trata en Azure Security Center, DDoS Protection estándar
envía automáticamente una alerta a Security Center cada vez que se detecta y mitiga un ataque DDoS en la
aplicación protegida.
De forma alternativa, para recibir una notificación cuando haya una mitigación activa en una dirección IP pública
protegida, puede configurar una alerta en la métrica Under DDoS attack or not (Bajo ataque de DDoS o no).
También puede optar por crear alertas para otras métricas de DDoS y configurar análisis de ataques para
entender la magnitud del ataque, el tráfico que se va a quitar, los vectores de ataque, los principales
colaboradores, etc.

Respuesta rápida de DDoS (DRR )

Los clientes de DDoS Protection estándar ahora tienen acceso al equipo de Rapid Response durante un ataque
activo. DDR puede ayudar con investigación de ataques, las mitigaciones personalizadas cuando se producen y el
análisis posterior a estos.
Protección de costos y garantía del contrato de nivel de servicio
El servicio DDoS Protection estándar está cubierto por un contrato de nivel de servicio del 99,99 % y la protección
de costos proporciona créditos de recursos para el escalado horizontal durante un ataque documentado. Para más
información, consulte Contrato de nivel de servicio para Azure DDoS Protection.

Escenarios de asociación destacados

A continuación se enumeran las principales ventajas que se pueden derivar mediante la integración con Azure
DDoS Protection estándar:
Los servicios ofrecidos por los asociados (equilibrador de carga, firewall de aplicaciones web, firewall, etc.) a sus
clientes se protegen automáticamente (etiqueta blanca) con Azure DDoS Protection estándar en el back-end.
Los asociados tienen acceso a datos de telemetría y análisis de ataques de Azure DDoS Protection que pueden
integrar con sus propios productos para ofrecer una experiencia de cliente unificada.
Los asociados tienen acceso al soporte técnico de respuesta rápida de DDoS, incluso en ausencia de Azure Rapid
Response, para problemas relacionados con DDoS.
Las aplicaciones protegidas de los asociados están respaldados por la protección de costos y la garantía de un
contrato de nivel de servicio de DDoS en caso de producirse ataques DDoS.

Información general sobre la integración técnica

Las oportunidades de asociación de Azure DDoS Protection estándar están disponibles a través de Azure Portal, de
las API y de la CLI/PS.
Integración con DDoS Protection estándar
Los siguientes pasos son necesarios para que los asociados configuren la integración con Azure DDoS Protection
estándar:
1. Cree un plan de DDoS Protection en la suscripción (de asociado) que desee. Para obtener instrucciones paso a
paso, consulte el tema sobre la creación de un plan de DDoS Protection estándar.

NOTE
Solo se debe crear un plan de DDoS Protection para un inquilino determinado.

2. Implemente un servicio con un punto de conexión público en sus suscripciones (de asociado), como el
equilibrador de carga, los firewalls y el firewall de aplicaciones web.
3. Habilite Azure DDoS Protection estándar en la red virtual del servicio que tiene puntos de conexión públicos
mediante el plan de DDoS Protection creado en el primer paso. Para obtener instrucciones detalladas, consulte
el tema sobre la habilitación del plan de DDoS Protection estándar.

IMPORTANT
Una vez habilitado Azure DDoS Protection estándar en una red virtual, todas las direcciones IP públicas de esa red
virtual se protegen automáticamente. El origen de estas direcciones IP públicas puede estar en Azure (suscripción de
cliente) o fuera de Azure.

4. Opcionalmente, integre la telemetría y los análisis de ataques de Azure DDoS Protection estándar en el panel
orientado al cliente específico de la aplicación. Para obtener más información sobre el uso de la telemetría,
consulte el tema sobre el uso de la telemetría de DDoS Protection. Para obtener más información sobre la
configuración de análisis de ataques, consulte Configuración del análisis de ataques DDoS.
Guías de incorporación y documentación técnica
Página del producto Azure DDoS Protection
Documentación de Azure DDoS Protection
 Referencia de la API de Azure DDoS Protection
Referencia de la API de Azure Virtual Network
Obtener ayuda
Si tiene alguna pregunta sobre las integraciones de productos, aplicaciones o servicios con Azure DDoS
Protection estándar, puede ponerse en contacto con la comunidad de seguridad de Azure.
Siga las discusiones sobre Stack Overflow.
Comercialización de productos
El programa principal para la asociación con Microsoft es Microsoft Partner Network. – Las integraciones de
seguridad de Microsoft Graph se incluyen en el seguimiento de fabricante de software independiente (ISV) de
MPN.
Asociación de seguridad inteligente de Microsoft es el programa específico para que los asociados de seguridad
de Microsoft le ayuden a enriquecer sus productos de seguridad y a mejorar la capacidad de detección de los
clientes de sus integraciones con productos de seguridad de Microsoft.

Pasos siguientes
Ver las integraciones de asociados existentes:
Barracuda WAF-as-a-Service
Azure Cloud WAF de Radware
 Crear, modificar o eliminar un grupo de seguridad
de red
23/09/2020 • 33 minutes to read • Edit Online

Las reglas de seguridad de grupos de seguridad de red permiten filtrar el tipo de tráfico de red que puede fluir
dentro y fuera de las interfaces de red y las subredes de redes virtuales. Para más información acerca de los
grupos de seguridad de red, consulte Seguridad de las redes. Después, complete el tutorial Filtrado del tráfico
de red para obtener experiencia con los grupos de seguridad de red.

Antes de empezar
NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de
AzureRM que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más
información acerca del nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure
PowerShell Az module (Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la
instalación del módulo Az, consulte Instalación de Azure PowerShell.

Si no tiene ninguna, configure una cuenta de Azure con una suscripción activa. Cree una cuenta gratuita.
Complete una de estas tareas antes de continuar con este artículo:
Usuarios de Por tal : Inicie sesión en Azure Portal con su cuenta de Azure.
Usuarios de PowerShell : ejecute los comandos en Azure Cloud Shell, o bien ejecute PowerShell en el
equipo. Azure Cloud Shell es un shell interactivo gratuito que puede usar para ejecutar los pasos de este
artículo. Tiene las herramientas comunes de Azure preinstaladas y configuradas para usarlas en la
cuenta. En la pestaña del explorador Azure Cloud Shell, busque la lista desplegable Seleccionar
entorno y, después, elija PowerShell si aún no está seleccionado.
Si ejecuta PowerShell en el entorno local, use la versión del módulo de Azure PowerShell 1.0.0 o una
posterior. Ejecute Get-Module -ListAvailable [Link] para buscar la versión instalada. Si necesita
actualizarla, consulte Instalación del módulo de Azure PowerShell. Ejecute Connect-AzAccount para crear
una conexión con Azure.
Usuarios de la interfaz de la línea de comandos (CLI) de Azure : ejecute los comandos en Azure
Cloud Shell, o bien ejecute la CLI en el equipo. Use la versión 2.0.28 de la CLI de Azure o una posterior si
ejecuta la CLI de Azure en el entorno local. Ejecute az --version para buscar la versión instalada. Si
necesita instalarla o actualizarla, vea Instalación de la CLI de Azure. Ejecute az login para crear una
conexión con Azure.
La cuenta en la que inicia sesión o con la que se conecta a Azure debe tener asignado el rol Colaborador de red
o un rol personalizado que tenga asignadas las acciones apropiadas en Permisos.

Trabajar con grupos de seguridad de red

Los grupos de seguridad de red se pueden crear, ver todos, ver sus detalles, cambiar y eliminar. También puede
asociar o desasociar un grupo de seguridad de red de una interfaz de red o subred.
Crear un grupo de seguridad de red
Existe un límite para la cantidad de grupos de seguridad de red que puede crear por suscripción y ubicación de
Azure. Para obtener más información, consulte Límites, cuotas y restricciones de suscripción y servicios de
Microsoft Azure.
1. En el menú Azure Portal o en la página Inicio , seleccione Crear un recurso .
2. Seleccione Redes y, a continuación, Grupo de seguridad de red .
3. En la página Crear grupo de seguridad de red , en la pestaña Aspectos básicos , establezca los
valores de configuración siguientes:

C O N F IGURA C IÓ N A C C IÓ N

Suscripción Elija su suscripción.

Grupos de recursos Seleccione un grupo de recursos existente o seleccione

Crear nuevo para crear uno nuevo.

Nombre Escriba una cadena de texto única en un grupo de

recursos.

Región Elija la ubicación que desee.

4. Seleccione Revisar + crear .

5. Cuando vea el mensaje Validación superada , seleccione Crear .
Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network nsg create

PowerShell New-AzNetworkSecurityGroup

Ver todos los grupos de seguridad de red

Diríjase a Azure Portal para ver sus grupos de seguridad de red. Busque y seleccione Grupos de seguridad
de red . Aparecerá la lista de grupos de seguridad de red de su suscripción.
Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network nsg list

PowerShell Get-AzNetworkSecurityGroup

Ver detalles de un grupo de seguridad de red

1. Diríjase a Azure Portal para ver sus grupos de seguridad de red. Busque y seleccione Grupos de
seguridad de red .
2. Seleccione el nombre del grupo de seguridad de red.
En la barra de menús del grupo de seguridad de red, en Configuración , puede ver las opciones de Reglas de
seguridad de entrada , Reglas de seguridad de salida , Interfaces de red y Subredes a las que está
asociado el grupo de seguridad de red.
En Super visión , puede habilitar o deshabilitar Configuración de diagnóstico . En Sopor te técnico y
solución de problemas , puede ver Reglas de seguridad vigentes . Para más información, consulte
Registros de diagnóstico de un grupo de seguridad de red y Diagnóstico de problemas al filtrar el tráfico de red
de una VM.
Para más información sobre la configuración común de Azure que se muestra, consulte los artículos siguientes:
Registro de actividad
Control de acceso (IAM)
Etiquetas
Bloqueos
Script de Automation
Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network nsg show

PowerShell Get-AzNetworkSecurityGroup

Cambiar un grupo de seguridad de red

1. Diríjase a Azure Portal para ver sus grupos de seguridad de red. Busque y seleccione Grupos de
seguridad de red .
2. Seleccione el nombre del grupo de seguridad de red que quiere modificar.
Los cambios más comunes son agregar una regla de seguridad, quitar una regla de seguridad y asociar un
grupo de seguridad de red a una subred o una interfaz de red, o desasociarlo.
Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network nsg update

PowerShell Set-AzNetworkSecurityGroup

Asociar o desasociar un grupo de seguridad de red a o de una subred o una interfaz de red
Para asociar un grupo de seguridad de red a una interfaz de red o desasociarlo de esta, consulte Asociar un
grupo de seguridad de red o una interfaz de red o desasociarlo de esta. Para asociar un grupo de seguridad de
red a una subred o desasociarlo de esta, consulte Modificación de la configuración de subred.
Eliminar un grupo de seguridad de red
Si un grupo de seguridad de red está asociado a subredes o interfaces de red, no se puede eliminar. Desasocie
un grupo de seguridad de red de todas las subredes e interfaces de red antes de intentar eliminarlo.
1. Diríjase a Azure Portal para ver sus grupos de seguridad de red. Busque y seleccione Grupos de
seguridad de red .
2. Seleccione el nombre del grupo de seguridad de red que quiere eliminar.
3. En la barra de herramientas del grupo de seguridad de red, seleccione Eliminar . A continuación,
seleccione Sí en el cuadro de diálogo de confirmación.
Comandos:
 H ERRA M IEN TA GET - H EL P

Azure CLI az network nsg delete

PowerShell Remove-AzNetworkSecurityGroup

Trabajar con reglas de seguridad

Un grupo de seguridad de red puede contener una regla de seguridad, varias o ninguna. Las reglas de
seguridad se pueden crear, ver todas, ver sus detalles, cambiar y eliminar.
Creación de una regla de seguridad
Existe un límite para la cantidad de reglas por grupo de seguridad de red que puede crear por suscripción y
ubicación de Azure. Para obtener más información, consulte Límites, cuotas y restricciones de suscripción y
servicios de Microsoft Azure.
1. Diríjase a Azure Portal para ver sus grupos de seguridad de red. Busque y seleccione Grupos de
seguridad de red .
2. Seleccione el nombre del grupo de seguridad de red al que quiere agregar una regla de seguridad.
3. En la barra de menús del grupo de seguridad de red, elija Reglas de seguridad de entrada o Reglas
de seguridad de salida .
Se muestran varias reglas existentes, incluidas algunas que quizás no haya agregado. Cuando se crea un
grupo de seguridad de red, se crean en este varias reglas de seguridad predeterminadas. Para más
información, consulte las reglas de seguridad predeterminadas. Las reglas de seguridad
predeterminadas no se pueden eliminar, pero pueden reemplazarse por reglas de prioridad más alta.
4. Seleccione Agregar . Seleccione o agregue valores para las siguientes opciones y, continuación,
seleccione Aceptar :

C O N F IGURA C IÓ N VA L UE DETA L L ES

Origen Uno de los valores siguientes: Si elige Direcciones IP ,

Cualquiera también debe especificar
Direcciones IP Inter valos de direcciones IP
Etiqueta de ser vicio de origen y CIDR.
(regla de seguridad de
Si elige Etiqueta de ser vicio ,
entrada) o Vir tualNetwork
también puede seleccionar una
(regla de seguridad de
opción de Etiqueta de
salida)
ser vicio de origen .
Grupo de seguridad
de aplicaciones Si elige Grupo de seguridad
de aplicaciones , también
debe seleccionar un grupo de
seguridad de aplicaciones
existente. Si elige Grupo de
seguridad de aplicaciones
en Origen y Destino , las
interfaces de red de ambos
grupos de seguridad de
aplicaciones deben estar en la
misma red virtual.
C O N F IGURA C IÓ N VA L UE DETA L L ES

Inter valos de direcciones IP de Lista delimitada por comas de Esta opción aparece si cambia
origen y CIDR direcciones IP e intervalos de Origen a Direcciones IP .
Enrutamiento de interdominios sin Debe especificar un valor único
clases (CIDR) o una lista de varios valores
separados por comas. Un
ejemplo de varios valores es
[Link]/16, [Link] .
Se aplican límites al número de
valores que puede especificar.
Para más información, consulte
Límites de Azure.
Si la dirección IP que especifica
se asigna a una VM de Azure,
especifique su dirección IP
privada, no la pública. Azure
procesa las reglas de seguridad
después de cambiar la dirección
IP pública por una dirección IP
privada para las reglas de
seguridad de entrada, pero
antes de cambiar una dirección
IP privada por una dirección IP
pública para las reglas de salida.
Para más información sobre las
direcciones IP públicas y
privadas de Azure, consulte
Tipos de direcciones IP.

Etiqueta de ser vicio de origen Una etiqueta de servicio de la lista Esta opción de configuración
desplegable opcional aparece si se establece
Origen en Etiqueta de ser vicio
para una regla de seguridad de
entrada. Una etiqueta de servicio es
un identificador predefinido para
una categoría de direcciones IP. Para
más información sobre las etiquetas
de servicio disponibles y qué
representa cada etiqueta, consulte
Etiquetas de servicio.

Grupo de seguridad de Grupo de seguridad de aplicaciones Esta opción de configuración

aplicación de origen existente aparece si se establece Origen en
Grupo de seguridad de
aplicaciones . Seleccione un grupo
de seguridad de aplicaciones que
exista en la misma región que la
interfaz de red. Obtenga
información sobre cómo crear un
grupo de seguridad de aplicaciones.
C O N F IGURA C IÓ N VA L UE DETA L L ES

Inter valos de puer tos de Uno de los valores siguientes: Esta opción de configuración
origen Un puerto único, como 80 especifica los puertos en los que la
Un intervalo de puertos, regla permite o deniega el tráfico.
como 1024-65535 Se aplican límites al número de
puertos que puede especificar. Para
Una lista de puertos únicos
más información, consulte Límites
o intervalos de puertos
de Azure.
separados por comas, como
80, 1024-65535
Un asterisco ( * ) para
permitir el tráfico en
cualquier puerto

Destino Uno de los valores siguientes: Si selecciona Direcciones IP ,

Cualquiera especifique también los
Direcciones IP Inter valos de direcciones IP
Etiqueta de ser vicio de destino y CIDR.
(regla de seguridad de
Si elige Vir tualNetwork , se
salida) o Vir tualNetwork
permite el tráfico a todas las
(regla de seguridad de
direcciones IP del espacio de
entrada)
direcciones de la red virtual.
Grupo de seguridad Vir tualNetwork es una
de aplicaciones etiqueta de servicio.
Si selecciona Grupo de
seguridad de aplicaciones ,
debe seleccionar un grupo de
seguridad de aplicaciones
existente. Obtenga información
sobre cómo crear un grupo de
seguridad de aplicaciones.
C O N F IGURA C IÓ N VA L UE DETA L L ES

Inter valos de direcciones IP de Lista de direcciones IP e intervalos Esta opción aparece si cambia
destino y CIDR CIDR delimitados por comas Destino a Direcciones IP . De
manera similar a Origen e
Inter valos de direcciones IP
de origen y CIDR, puede
especificar uno o varios
intervalos o direcciones. Se
aplican límites al número que
puede especificar. Para más
información, consulte Límites de
Azure.
Si la dirección IP que especifica
se asigna a una VM de Azure,
asegúrese de especificar su
dirección IP privada, no la
pública. Azure procesa las reglas
de seguridad después de
cambiar la dirección IP pública
por una dirección IP privada
para las reglas de seguridad de
entrada, pero antes de cambiar
una dirección IP privada por
una dirección IP pública para las
reglas de salida. Para más
información sobre las
direcciones IP públicas y
privadas de Azure, consulte
Tipos de direcciones IP.

Etiqueta de ser vicio de destino Una etiqueta de servicio de la lista Esta opción de configuración
desplegable opcional aparece si se establece
Destino en Etiqueta de ser vicio
para una regla de seguridad de
salida. Una etiqueta de servicio es
un identificador predefinido para
una categoría de direcciones IP. Para
más información sobre las etiquetas
de servicio disponibles y qué
representa cada etiqueta, consulte
Etiquetas de servicio.

Grupo de seguridad de Grupo de seguridad de aplicaciones Esta opción de configuración

aplicación de destino existente aparece si se establece Destino en
Grupo de seguridad de
aplicaciones . Seleccione un grupo
de seguridad de aplicaciones que
exista en la misma región que la
interfaz de red. Obtenga
información sobre cómo crear un
grupo de seguridad de aplicaciones.
 C O N F IGURA C IÓ N VA L UE DETA L L ES

Inter valos de puer tos de Uno de los valores siguientes: Como con Inter valos de puer tos
destino Un puerto único, como 80 de origen , puede especificar uno o
Un intervalo de puertos, varios puertos e intervalos. Se
como 1024-65535 aplican límites al número que puede
especificar. Para más información,
Una lista de puertos únicos
consulte Límites de Azure.
o intervalos de puertos
separados por comas, como
80, 1024-65535
Un asterisco ( * ) para
permitir el tráfico en
cualquier puerto

Protocolo Cualquiera , TCP , UDP o ICMP Puede restringir la regla al

Protocolo de control de transmisión
(TCP), el Protocolo de datagramas
de usuario (UDP) y el Protocolo de
mensajes de control de Internet
(ICMP). La opción predeterminada
es que la regla se aplique a todos
los protocolos.

Acción Permitir o Denegar Esta opción de configuración

especifica si esta regla permite o
deniega el acceso a la configuración
de origen y de destino
proporcionada.

Prioridad Escriba un valor de 100 a 4096 que Azure procesa las reglas de
sea único para todas las reglas de seguridad en orden de prioridad.
seguridad del grupo de seguridad Cuanto menor sea el número,
de red mayor será la prioridad. Se
recomienda dejar un espacio entre
los números de prioridad al crear
reglas, como 100, 200 y 300. Dejar
espacios facilita la adición de reglas
en el futuro, de modo que pueda
asignarles una prioridad por encima
o por debajo de las reglas
existentes.

Nombre Nombre único para la regla en el Puede tener hasta 80 caracteres.

grupo de seguridad de red Debe comenzar con una letra o un
número y terminar con una letra,
un número o un carácter de
subrayado. El nombre solo puede
contener letras, números, caracteres
de subrayado, puntos o guiones.

Descripción Descripción de texto Opcionalmente, puede especificar

una descripción de texto para la
regla de seguridad.

Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network nsg rule create

 H ERRA M IEN TA GET - H EL P

PowerShell New-AzNetworkSecurityRuleConfig

Ver todas las reglas de seguridad

Un grupo de seguridad de red contiene varias reglas o ninguna. Para más detalles sobre la información que
aparece al ver las rutas, consulte la introducción a la seguridad de red.
1. Diríjase a Azure Portal para ver las reglas de un grupo de seguridad de red. Busque y seleccione Grupos
de seguridad de red .
2. Seleccione el nombre del grupo de seguridad de red cuyas reglas quiere ver.
3. En la barra de menús del grupo de seguridad de red, elija Reglas de seguridad de entrada o Reglas
de seguridad de salida .
La lista contiene todas las reglas que ha creado y las reglas de seguridad predeterminadas del grupo de
seguridad de red.
Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network nsg rule list

PowerShell Get-AzNetworkSecurityRuleConfig

Ver detalles de una regla de seguridad

1. Diríjase a Azure Portal para ver las reglas de un grupo de seguridad de red. Busque y seleccione Grupos
de seguridad de red .
2. Seleccione el nombre del grupo de seguridad de red del que quiere ver los detalles de una de sus reglas.
3. En la barra de menús del grupo de seguridad de red, elija Reglas de seguridad de entrada o Reglas
de seguridad de salida .
4. Seleccione la regla cuyos detalles quiere ver. Para obtener una explicación de todas las opciones,
consulte Configuración de reglas de seguridad.

NOTE
Este procedimiento solo se aplica a una regla de seguridad personalizada. No funciona si elige una regla de
seguridad predeterminada.

Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network nsg rule show

PowerShell Get-AzNetworkSecurityRuleConfig

Cambiar una regla de seguridad

1. Complete los pasos de Ver detalles de una regla de seguridad.
2. Cambie la configuración según sea necesario y, a continuación, seleccione Guardar . Para obtener una
 explicación de todas las opciones, consulte Configuración de reglas de seguridad.

NOTE
Este procedimiento solo se aplica a una regla de seguridad personalizada. No se permite cambiar una regla de
seguridad predeterminada.

Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network nsg rule update

PowerShell Set-AzNetworkSecurityRuleConfig

Eliminar una regla de seguridad

1. Complete los pasos de Ver detalles de una regla de seguridad.
2. Seleccione Eliminar y, luego, seleccione Sí .

NOTE
Este procedimiento solo se aplica a una regla de seguridad personalizada. No se permite eliminar una regla de
seguridad predeterminada.

Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network nsg rule delete

PowerShell Remove-AzNetworkSecurityRuleConfig

Trabajar con grupos de seguridad de aplicaciones

Un grupo de seguridad de aplicaciones contiene una interfaz de red, varias o ninguna. Para más información,
consulte grupos de seguridad de aplicaciones. Todas las interfaces de red de un grupo de seguridad de
aplicaciones deben existir en la misma red virtual. Para obtener información sobre cómo agregar una interfaz
de red a un grupo de seguridad de aplicaciones, consulte el tema sobre cómo agregar una interfaz de red a un
grupo de seguridad de aplicaciones.
Crear un grupo de seguridad de aplicaciones
1. En el menú Azure Portal o en la página Inicio , seleccione Crear un recurso .
2. En el cuadro de búsqueda, escriba Grupo de seguridad de aplicaciones.
3. En la página Grupo de seguridad de aplicaciones , seleccione Crear .
4. En la página Crear un grupo de seguridad de aplicación , en la pestaña Aspectos básicos ,
establezca los valores de configuración siguientes:

C O N F IGURA C IÓ N A C C IÓ N

Suscripción Elija su suscripción.

 C O N F IGURA C IÓ N A C C IÓ N

Grupos de recursos Seleccione un grupo de recursos existente o seleccione

Crear nuevo para crear uno nuevo.

Nombre Escriba una cadena de texto única en un grupo de

recursos.

Región Elija la ubicación que desee.

5. Seleccione Revisar + crear .

6. En la pestaña Revisar y crear , cuando aparezca el mensaje Validación superada , seleccione Crear .
Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network asg create

PowerShell New-AzApplicationSecurityGroup

Ver todos los grupos de seguridad de aplicaciones

Vaya a Azure Portal para ver sus grupos de seguridad de aplicaciones. Busque y seleccione Grupos de
seguridad de aplicaciones . Azure Portal muestra una lista de sus grupos de seguridad de aplicaciones.
Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network asg list

PowerShell Get-AzApplicationSecurityGroup

Ver detalles de un grupo de seguridad de aplicaciones específico

1. Diríjase a Azure Portal para ver un grupo de seguridad de aplicaciones. Busque y seleccione Grupos de
seguridad de aplicaciones .
2. Seleccione el nombre del grupo de seguridad de aplicaciones del que quiera ver los detalles.
Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network asg show

PowerShell Get-AzApplicationSecurityGroup

Cambiar un grupo de seguridad de aplicaciones

1. Diríjase a Azure Portal para ver un grupo de seguridad de aplicaciones. Busque y seleccione Grupos de
seguridad de aplicaciones .
2. Seleccione el nombre del grupo de seguridad de aplicaciones que quiere cambiar.
3. Seleccione Cambiar junto a la opción de configuración que desea modificar. Por ejemplo, puede
agregar o quitar Etiquetas , o bien cambiar los valores de Grupo de recursos o Suscripción .
 NOTE
No puede cambiar la ubicación.

En la barra de menús, también puede seleccionar Control de acceso (IAM) . En la página Control de
acceso (IAM) , puede asignar o quitar permisos para el grupo de seguridad de aplicaciones.
Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network asg update

PowerShell Ningún cmdlet de PowerShell

Eliminar un grupo de seguridad de aplicaciones

No puede eliminar un grupo de seguridad de aplicaciones si contiene alguna interfaz de red. Para quitar todas
las interfaces de red del grupo de seguridad de aplicaciones, cambie la configuración de la interfaz de red o
elimine las interfaces de red. Para obtener más información, consulte Adición o eliminación de grupos de
seguridad de aplicaciones o Eliminación de una interfaz de red.
1. Vaya a Azure Portal para administrar sus grupos de seguridad de aplicaciones. Busque y seleccione
Grupos de seguridad de aplicaciones .
2. Seleccione el nombre del grupo de seguridad de aplicaciones que quiere eliminar.
3. Haga clic en Eliminar y después en Sí para eliminar el grupo de seguridad de aplicaciones.
Comandos:

H ERRA M IEN TA GET - H EL P

Azure CLI az network asg delete

PowerShell Remove-AzApplicationSecurityGroup

Permisos
Para realizar tareas en grupos de seguridad de red, reglas de seguridad y grupos de seguridad de aplicaciones,
la cuenta debe estar asignada al rol de colaborador de red o a un rol personalizado que tenga asignados los
permisos adecuados que se indican en las tablas siguientes:
Grupo de seguridad de red
A C C IÓ N N O M B RE

[Link]/networkSecurityGroups/read Obtener grupo de seguridad de red

[Link]/networkSecurityGroups/write Crear o actualizar grupo de seguridad de red

[Link]/networkSecurityGroups/delete Eliminar grupo de seguridad de red

[Link]/networkSecurityGroups/join/action Asociar un grupo de seguridad de red a una subred o a una

interfaz de red
Regla de grupo de seguridad de red
A C C IÓ N N O M B RE

[Link]/networkSecurityGroups/securityRules/re Obtener regla

ad

[Link]/networkSecurityGroups/securityRules/wri Crear o actualizar regla

te

[Link]/networkSecurityGroups/securityRules/del Eliminar regla

ete

Grupo de seguridad de aplicaciones

A C C IÓ N N O M B RE

[Link]/applicationSecurityGroups/joinIpConfigu Unir una configuración IP a un grupo de seguridad de

ration/action aplicaciones

[Link]/applicationSecurityGroups/joinNetworkS Unir una regla de seguridad a un grupo de seguridad de

ecurityRule/action aplicaciones

[Link]/applicationSecurityGroups/read Obtener un grupo de seguridad de aplicaciones

[Link]/applicationSecurityGroups/write Crear o actualizar un grupo de seguridad de aplicaciones

[Link]/applicationSecurityGroups/delete Eliminar un grupo de seguridad de aplicaciones

Pasos siguientes
Crear una red o un grupo de seguridad de aplicaciones con scripts de ejemplo de PowerShell o de la CLI de
Azure, o bien con plantillas de Azure Resource Manager
Crear y asignar definiciones de Azure Policy para redes virtuales
 Escenario de aplicación virtual
23/09/2020 • 19 minutes to read • Edit Online

Un escenario común entre los clientes de Azure de mayor tamaño es la necesidad de ofrecer una aplicación en 2
niveles expuesta a Internet a la vez que permiten el acceso al nivel posterior desde un centro de datos local. Este
documento le guiará en un escenario con Rutas definidas por el usuario (UDR), una instancia de VPN Gateway y
aplicaciones virtuales de red para implementar un entorno de 2 niveles que cumple los siguientes requisitos:
Solo se debe poder tener acceso a la aplicación web desde una red pública de Internet.
El servidor web que hospeda la aplicación debe poder tener acceso a un servidor de aplicaciones back-end.
Todo el tráfico desde Internet a la aplicación web debe pasar por una aplicación virtual de firewall. Esta
aplicación virtual se usará solo para el tráfico de Internet.
Todo el tráfico que vaya al servidor de aplicaciones debe pasar por una aplicación virtual de firewall. Esta
aplicación virtual se usará para tener acceso al servidor back-end y el acceso entrante provendrá de la red local
a través de VPN Gateway.
Los administradores deberán poder administrar las aplicaciones virtuales de firewall desde los equipos locales
con una tercera aplicación virtual de firewall que se usará exclusivamente para la administración.
Este es un escenario de red perimetral estándar con una red perimetral y una red protegida. Dicho escenario se
puede construir en Azure con NSG, aplicaciones virtuales de firewall o una combinación de ambos elementos. La
tabla a continuación muestra algunas de las ventajas y desventajas entre los NSG y las aplicaciones virtuales de
firewall.

VEN TA JA S DESVEN TA JA S

NSG No tienen costo. La complejidad podría variar en

Están integrados en Azure RBAC. entornos de mayor tamaño.
Las reglas se pueden crear en plantillas
de Azure Resource Manager.

Firewall Control total sobre el plano de datos. El costo de la aplicación de firewall.

Administración central a través de la No está integrado con Azure RBAC.
consola de firewall.

La solución siguiente usa aplicaciones virtuales de firewall para implementar un escenario de red protegida o red
perimetral.

Consideraciones
Puede implementar el entorno que se explicó anteriormente en Azure con distintas características que actualmente
están disponibles, como se indica a continuación.
Red vir tual . Una red virtual de Azure actúa de manera similar a una red local y se puede segmentar en una o
más subredes para ofrecer el aislamiento del tráfico y la separación de proceso.
Aplicación vir tual . Varios socios proporcionan aplicaciones virtuales en Azure Marketplace que se pueden
usar para los tres firewalls anteriormente descritos.
Rutas definidas por el usuario (UDR) . Las tablas de ruta pueden contener UDR que las redes de Azure usan
para controlar el flujo de paquetes dentro de una red virtual. Estas tablas de ruta se pueden aplicar a las
subredes. Una de las características más nuevas de Azure es la capacidad de aplicar una tabla de ruta a la subred
GatewaySubnet, lo que ofrece la posibilidad de reenviar todo el tráfico entrante a la red virtual de Azure desde
 una conexión híbrida a una aplicación virtual.
Reenvío IP . De manera predeterminada, el motor de redes de Azure reenvía paquetes a las tarjetas de interfaz
de red (NIC) virtuales solo si la dirección IP de destino del paquete coincide con la dirección IP de la NIC. Por lo
tanto, si una UDR define que un paquete se debe enviar a una aplicación virtual determinada, el motor de redes
de Azure descartaría ese paquete. Para asegurarse de que el paquete se entregue a una máquina virtual (en este
caso, una aplicación virtual) que no es el destino real del paquete, debe habilitar Reenvío IP para la aplicación
virtual.
Grupos de seguridad de red (NSG) . El siguiente ejemplo no usa los NSG, pero puede usarlos en las
subredes o las tarjetas NIC de esta solución para filtrar adicionalmente el tráfico que entra y sale de esas
subredes y NIC.

En este ejemplo hay una suscripción que contiene lo siguiente:

Dos grupos de recursos que no aparecen en el diagrama.
ONPREMRG . Contiene todos los recursos que se necesitan para simular una red local.
AZURERG . Contiene todos los recursos que se necesitan para el entorno de red virtual de Azure.
Una red virtual llamada onpremvnet que se usa para simular un centro de datos local segmentado como se
muestra a continuación.
onpremsn1 . Subred que contiene una máquina virtual donde se ejecuta Ubuntu para simular un
servidor local.
onpremsn2 . Subred que contiene una máquina virtual donde se ejecuta Ubuntu para simular el equipo
local que usa un administrador.
Hay una aplicación virtual de firewall llamada OPFW en onpremvnet que se usa para mantener un túnel a
azurevnet .
Una red virtual llamada azurevnet segmentada como se muestra a continuación.
azsn1 . Subred de firewall externo que se usa exclusivamente para el firewall externo. Todo el tráfico de
Internet entrará a través de esta subred. Esta subred contiene sólo una NIC vinculada para el firewall
externo.
azsn2 . Subred de front-end que hospeda una máquina virtual que se ejecuta como servidor web al que
se tendrá acceso desde Internet.
azsn3 . Subred de back-end que hospeda una máquina virtual que ejecuta un servidor de aplicaciones
 back-end al que tendrá acceso el servidor web de front-end.
azsn4 . Subred de administración que se usa exclusivamente para brindar acceso de administración a
todas las aplicaciones virtuales de firewall. Esta subred solo contiene una tarjeta NIC para cada aplicación
virtual de firewall que se usa en la solución.
GatewaySubnet . Subred de conexión híbrida de Azure que se requiere para que ExpressRoute y VPN
Gateway proporcionen conectividad entre redes virtuales de Azure y otras redes.
Hay 3 aplicaciones virtuales de firewall en la red azurevnet .
AZF1 . Firewall externo expuesto a la red pública de Internet mediante un recurso de dirección IP pública
en Azure. Debe asegurarse de tener una plantilla proveniente de Marketplace, o bien directamente desde
el proveedor de aplicaciones, que aprovisione una aplicación virtual de 3 NIC.
AZF2 . Firewall interno que se usa para controlar el tráfico entre azsn2 y azsn3 . También es una
aplicación virtual de 3 NIC.
AZF3 . Firewall de administración al que los administradores tienen acceso desde el centro de datos local
y que está conectado a una subred de administración que se usa para administrar todas las aplicaciones
de firewall. Puede encontrar plantillas de aplicaciones virtuales de 2 NIC en Marketplace, o bien solicitar
una directamente al proveedor de aplicaciones.

Enrutamiento definido por el usuario (UDR)

Cada subred de Azure se puede vincular a una tabla de UDR que se usa para definir cómo se enruta el tráfico que
se inicia en esa subred. Si no hay definida ninguna UDR, Azure usa las rutas predeterminadas para permitir que el
tráfico fluya de una subred a otra. Consulte el artículo ¿Qué son las rutas definidas por el usuario y el reenvío
IP?para comprender mejor las UDR.
Para asegurarse de que la comunicación que se realiza a través de la aplicación de firewall correcta, según el último
requisito mencionado, debe crear la siguiente tabla de ruta que contiene UDR en azurevnet .
azgwudr
En este escenario, el único tráfico que fluye desde el sitio local a Azure se usará para administrar los firewalls a
través de la conexión con AZF3 y ese tráfico debe pasar por el firewall interno, AZF2 . Por lo tanto, solo se necesita
una ruta en GatewaySubnet , tal como se indica a continuación.

DEST IN AT IO N P RÓ XIM O SA LTO EXP L IC A C IÓ N

[Link]/24 [Link] Permite que el tráfico local llegue al

firewall de administración AZF3

azsn2udr
DEST IN AT IO N P RÓ XIM O SA LTO EXP L IC A C IÓ N

[Link]/24 [Link] Permite el tráfico a la red back-end que

hospeda el servidor de aplicaciones a
través de AZF2

[Link]/0 [Link] Permite que todo el tráfico restante se

enrute a través de AZF1

azsn3udr
DEST IN AT IO N P RÓ XIM O SA LTO EXP L IC A C IÓ N
 DEST IN AT IO N P RÓ XIM O SA LTO EXP L IC A C IÓ N

[Link]/24 [Link] Permite que el tráfico a azsn2 fluya

desde el servidor de aplicaciones al
servidor web a través de AZF2

También deberá crear tablas de ruta para que las subredes de onpremvnet simulen el centro de datos local.
onpremsn1udr
DEST IN AT IO N P RÓ XIM O SA LTO EXP L IC A C IÓ N

[Link]/24 [Link] Permite el tráfico a onpremsn2 a

través de OPFW

onpremsn2udr
DEST IN AT IO N P RÓ XIM O SA LTO EXP L IC A C IÓ N

[Link]/24 [Link] Permite el tráfico de la subred back-end

en Azure a través de OPFW

[Link]/24 [Link] Permite el tráfico a onpremsn1 a

través de OPFW

reenvío de IP
UDR y Reenvío de IP son características que se pueden usar en conjunto para permitir que las aplicaciones virtuales
se usen para controlar el flujo de tráfico en una red virtual de Azure. Un dispositivo virtual no es más que una
máquina virtual que ejecuta una aplicación utilizada para controlar el tráfico de red de alguna manera, como un
firewall o un dispositivo NAT.
La máquina virtual de este dispositivo virtual debe ser capaz de recibir el tráfico entrante que no se dirige a sí
mismo. Para permitir que una máquina virtual reciba el tráfico dirigido a otros destinos, debe habilitar el reenvío IP
de la máquina virtual. Esta es una opción de configuración de Azure, no de la configuración del sistema operativo
invitado. De todos modos, la aplicación virtual debe ejecutar algún tipo de aplicación para controlar el tráfico
entrante y enrutarlo como corresponda.
Visite ¿Qué son las rutas definidas por el usuario y el reenvío IP?para obtener más información sobre el reenvío IP.
Como ejemplo, imagine que tiene una red virtual de Azure con la siguiente configuración:
La subred onpremsn1 contiene una máquina virtual llamada onpremvm1 .
La subred onpremsn2 contiene una máquina virtual llamada onpremvm2 .
Una aplicación virtual llamada OPFW está conectada a onpremsn1 y onpremsn2 .
Una ruta definida por el usuario vinculada a onpremsn1 especifica que todo el tráfico a onpremsn2 se debe
enviar a OPFW .
En este punto, si onpremvm1 intenta establecer una conexión con onpremvm2 , se usará la UDR y el tráfico se
enviará a OPFW como el próximo salto. Tenga en cuenta que el destino real del paquete no cambia, el destino
sigue siendo onpremvm2 .
Si Reenvío IP no está habilitado para OPFW , la lógica de la red virtual de Azure descartará los paquetes, debido a
que solo permite que los paquetes se envíen a una máquina virtual si la dirección IP de la máquina virtual es el
destino del paquete.
Con Reenvío IP, la lógica de red virtual de Azure reenviará los paquetes a OPFW sin cambiar la dirección de destino
original. OPFW debe controlar los paquetes y determinar qué hacer con ellos.
Para que el escenario anterior funcione, debe habilitar Reenvío IP en las tarjetas NIC para OPFW , AZF1 , AZF2 y
AZF3 , que se usan para el enrutamiento (todas las tarjetas NIC, excepto las vinculadas a la subred de
administración).

Reglas de firewall
Como se describió anteriormente, Reenvío IP solo asegura que los paquetes se envíen a las aplicaciones virtuales.
De todos modos, la aplicación debe decidir qué hacer con esos paquetes. En el escenario anterior, deberá crear las
siguientes reglas en las aplicaciones:
OPFW
OPFW representa un dispositivo local que contiene las siguientes reglas:
Ruta : todo el tráfico a [Link]/16 (azurevnet ) se debe enviar a través del túnel ONPREMAZURE .
Directiva : permita todo el tráfico bidireccional entre por t2 y ONPREMAZURE .
AZF1
AZF1 representa una aplicación virtual de Azure que incluye las siguientes reglas:
Directiva : permita todo el tráfico bidireccional entre por t1 y por t2 .
AZF2
AZF2 representa una aplicación de Azure que contiene las siguientes reglas:
Ruta : todo el tráfico a [Link]/16 (onpremvnet ) se debe enviar a la dirección IP de la puerta de enlace de
Azure (es decir, [Link]) a través de por t1 .
Directiva : permita todo el tráfico bidireccional entre por t1 y por t2 .

Grupos de seguridad de red (NSG)

En este escenario, no se usan los NSG. Sin embargo, podría aplicar los NSG a cada subred para restringir el tráfico
entrante y saliente. Por ejemplo, podría aplicar las siguientes reglas de NSG a la subred de firewall externo.
Entrante
Permita todo el tráfico TCP desde Internet al puerto 80 en cualquier máquina virtual de la subred.
Deniegue el resto del tráfico que provenga de Internet.
Saliente
Deniegue todo el tráfico hacia Internet.

Pasos de alto nivel

Para implementar este escenario, siga estos pasos de alto nivel.
1. Inicie sesión a su suscripción de Azure.
2. Si desea implementar una red virtual que simule la red local, aprovisione los recursos que son parte de
ONPREMRG .
3. Aprovisione los recursos que son parte de AZURERG .
4. Aprovisione el túnel de onpremvnet a azurevnet .
5. Una vez que se aprovisionen todos los recursos, inicie sesión en onpremvm2 y haga ping a [Link] para
probar la conectividad entre onpremsn2 y azsn3 .
 Creación de una máquina virtual con una dirección IP
pública estática mediante Azure Portal
23/09/2020 • 6 minutes to read • Edit Online

Puede crear una máquina virtual con una dirección IP pública estática. Una dirección IP pública le permite
comunicarse con una máquina virtual desde Internet. Asigne una dirección IP pública estática, en lugar de una
dirección dinámica, para garantizar que la dirección no cambie nunca. Más información sobre direcciones IP
públicas estáticas. Para cambiar una dirección IP pública asignada a una máquina virtual existente de dinámica a
estática, o para trabajar con direcciones IP privadas, consulte Incorporación, cambio o eliminación de direcciones
IP. Las direcciones IP públicas tienen un costo nominal y hay un límite en el número de direcciones IP públicas que
se pueden usar por suscripción.

Inicio de sesión en Azure

Inicie sesión en Azure Portal en [Link]

Creación de una máquina virtual

1. Seleccione + Crear un recurso en la esquina superior izquierda de Azure Portal.
2. Seleccione Proceso y, luego, Máquina vir tual de Windows Ser ver 2016 u otro sistema operativo de su
elección.
3. Escriba o seleccione la siguiente información, acepte los valores predeterminados para el resto de la
configuración y luego seleccione Aceptar :

C O N F IGURA C IÓ N VA L UE

Nombre myVM

Nombre de usuario Escriba un nombre de usuario de su elección.

Contraseña Escriba una contraseña de su elección. La contraseña debe

tener al menos 12 caracteres de largo y cumplir con los
requisitos de complejidad definidos.

Subscription Seleccione su suscripción.

Resource group Seleccione Usar existente y, a continuación,

myResourceGroup .

Location Seleccione Este de EE. UU .

4. Seleccione un tamaño para la máquina virtual y luego Seleccionar .

5. En Configuración , seleccione Dirección IP pública .
6. Escriba myPublicIpAddress, seleccione Estática y luego seleccione Aceptar , tal y como se muestra en la
siguiente imagen:
 Si la dirección IP pública debe ser una SKU estándar, seleccione Estándar en SKU . Más información sobre
las SKU de dirección IP pública. Si la máquina virtual se va a agregar al grupo back-end de una instancia
pública de Azure Load Balancer, la SKU de la dirección IP pública de la máquina virtual debe coincidir con la
SKU de la dirección IP del equilibrador de carga. Para más información, consulte Azure Load Balancer.
7. Seleccione un puerto o ningún puerto en Seleccionar puer tos de entrada públicos . Se selecciona el
puerto 3389 para permitir el acceso remoto a la máquina virtual Windows Server desde Internet. No se
recomienda abrir el puerto 3389 desde Internet con cargas de trabajo de producción.

8. Acepte los valores predeterminados restantes y seleccione Aceptar .

9. En la página Resumen , seleccione Crear . La máquina virtual tarda minutos en crearse.
10. Una vez implementada la máquina virtual, escriba myPublicIpAddress en el cuadro de búsqueda de la parte
superior del portal. Cuando myPublicIpAddress aparezca en los resultados de búsqueda, selecciónela.
11. Puede ver la dirección IP pública asignada, y que la dirección se asigna a la máquina virtual myVM , como se
muestra en la siguiente imagen:
 Azure asigna una dirección IP pública de las direcciones usadas en la región en la que creó la máquina
virtual. Puede descargar la lista de intervalos (prefijos) para las nubes de Azure Pública, Gobierno de
Estados Unidos, China y Alemania.
12. Seleccione Configuración para confirmar que la asignación es Estática .

WARNING
No modifique la configuración de direcciones IP dentro del sistema operativo de la máquina virtual. El sistema operativo no
conoce las direcciones IP públicas de Azure. Aunque puede agregar la configuración de dirección IP privada al sistema
operativo, se recomienda no hacerlo a menos que sea necesario y no hasta después de haber leído Incorporación o
eliminación de direcciones IP privadas a un sistema operativo.

Limpieza de recursos
Cuando ya no sea necesario, elimine el grupo de recursos y todos los recursos que contiene:
1. Escriba myResourceGroup en el cuadro Buscar que se encuentra en la parte superior del portal. Seleccione
myResourceGroup cuando lo vea en los resultados de la búsqueda.
2. Seleccione Eliminar grupo de recursos .
3. Escriba myResourceGroup para ESCRIBA EL NOMBRE DEL GRUPO DE RECURSOS: y seleccione Eliminar .

Pasos siguientes
Más información acerca de direcciones IP públicas en Azure
Más información acerca de toda la configuración de dirección IP pública
Más información acerca de direcciones IP privadas y la asignación de una dirección IP privada estática a una
máquina virtual de Azure
Más información acerca de cómo crear máquinas virtuales Linux y Windows
 Creación de una máquina virtual con una dirección IP
pública estática mediante PowerShell
23/09/2020 • 6 minutes to read • Edit Online

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Puede crear una máquina virtual con una dirección IP pública estática. Una dirección IP pública le permite
comunicarse con una máquina virtual desde Internet. Asigne una dirección IP pública estática, en lugar de una
dirección dinámica, para garantizar que la dirección no cambie nunca. Más información sobre direcciones IP
públicas estáticas. Para cambiar una dirección IP pública asignada a una máquina virtual existente de dinámica a
estática, o para trabajar con direcciones IP privadas, consulte Incorporación, cambio o eliminación de direcciones IP.
Las direcciones IP públicas tienen un costo nominal y hay un límite en el número de direcciones IP públicas que se
pueden usar por suscripción.

Creación de una máquina virtual

Puede realizar los pasos siguientes desde el equipo local o mediante Azure Cloud Shell. Para usar el equipo local,
asegúrese de que tiene instalado Azure PowerShell. Para usar Azure Cloud Shell, seleccione Probar en la esquina
superior derecha de cualquier cuadro de comando que sigue. Cloud Shell inicia su sesión en Azure.
1. Si usa Cloud Shell, continúe al paso 2. Abra una sesión de comandos e inicie sesión en Azure con
Connect-AzAccount .

2. Cree un grupo de recursos con el comando New-AzResourceGroup. En el siguiente ejemplo se crea un

grupo de recursos en la región Este de EE. UU. de Azure:

New-AzResourceGroup -Name myResourceGroup -Location EastUS

3. Cree una máquina virtual con el comando New-AzVM. La opción -AllocationMethod "Static" asigna una
dirección IP pública estática a la máquina virtual. En el ejemplo siguiente se crea una máquina virtual
Windows Server con una dirección IP pública estática, con una SKU básica, denominada myPublicIpAddress.
Cuando se le solicite, proporcione un nombre de usuario y una contraseña; se usarán como credenciales de
inicio de sesión para la máquina virtual:

New-AzVm `
-ResourceGroupName "myResourceGroup" `
-Name "myVM" `
-Location "East US" `
-PublicIpAddressName "myPublicIpAddress" `
-AllocationMethod "Static"

Si la dirección IP pública debe ser una SKU estándar, tiene que crear una dirección IP pública, crear una
interfaz de red, asignar la dirección IP pública a la interfaz de red y luego crear una máquina virtual con la
 interfaz de red, en pasos independientes. Más información sobre las SKU de dirección IP pública. Si la
máquina virtual se va a agregar al grupo back-end de una instancia pública de Azure Load Balancer, la SKU
de la dirección IP pública de la máquina virtual debe coincidir con la SKU de la dirección IP del equilibrador
de carga. Para más información, consulte Azure Load Balancer.
4. Vea la dirección IP pública asignada y confirme que se creó como una dirección estática, con Get-
AzPublicIpAddress:

Get-AzPublicIpAddress `
-ResourceGroupName "myResourceGroup" `
-Name "myPublicIpAddress" `
| Select "IpAddress", "PublicIpAllocationMethod" `
| Format-Table

Azure asigna una dirección IP pública de las direcciones usadas en la región en la que creó la máquina
virtual. Puede descargar la lista de intervalos (prefijos) para las nubes de Azure Pública, Gobierno de Estados
Unidos, China y Alemania.

WARNING
No modifique la configuración de direcciones IP dentro del sistema operativo de la máquina virtual. El sistema operativo no
conoce las direcciones IP públicas de Azure. Aunque puede agregar la configuración de dirección IP privada al sistema
operativo, se recomienda no hacerlo a menos que sea necesario y no hasta después de haber leído Incorporación o
eliminación de direcciones IP privadas a un sistema operativo.

Limpieza de recursos
Cuando ya no lo necesite, puede usar Remove-AzResourceGroup para quitar el grupo de recursos y todos los
recursos que contiene:

Remove-AzResourceGroup -Name myResourceGroup -Force

Pasos siguientes
Más información acerca de direcciones IP públicas en Azure
Más información acerca de toda la configuración de dirección IP pública
Más información acerca de direcciones IP privadas y la asignación de una dirección IP privada estática a una
máquina virtual de Azure
Más información acerca de cómo crear máquinas virtuales Linux y Windows
 Creación de una máquina virtual con una dirección IP
pública estática mediante la CLI de Azure
23/09/2020 • 5 minutes to read • Edit Online

Puede crear una máquina virtual con una dirección IP pública estática. Una dirección IP pública le permite
comunicarse con una máquina virtual desde Internet. Asigne una dirección IP pública estática, en lugar de una
dirección dinámica, para garantizar que la dirección no cambie nunca. Más información sobre direcciones IP
públicas estáticas. Para cambiar una dirección IP pública asignada a una máquina virtual existente de dinámica a
estática, o para trabajar con direcciones IP privadas, consulte Incorporación, cambio o eliminación de direcciones IP.
Las direcciones IP públicas tienen un costo nominal y hay un límite en el número de direcciones IP públicas que se
pueden usar por suscripción.

Creación de una máquina virtual

Puede realizar los pasos siguientes desde el equipo local o mediante Azure Cloud Shell. Para usar el equipo local,
asegúrese de tener instalada la CLI de Azure. Para usar Azure Cloud Shell, seleccione Probar en la esquina superior
derecha de cualquier cuadro de comando que sigue. Cloud Shell inicia su sesión en Azure.
1. Si usa Cloud Shell, continúe al paso 2. Abra una sesión de comandos e inicie sesión en Azure con az login .
2. Para crear un grupo de recursos, use el comando az group create. En el siguiente ejemplo se crea un grupo
de recursos en la región Este de EE. UU. de Azure:

az group create --name myResourceGroup --location eastus

3. Cree la máquina virtual con el comando az vm create. La opción --public-ip-address-allocation=static

asigna una dirección IP pública estática a la máquina virtual. En el ejemplo siguiente se crea una máquina
virtual Ubuntu con una dirección IP pública estática, con una SKU básica, denominada myPublicIpAddress:

az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--admin-username azureuser \
--generate-ssh-keys \
--public-ip-address myPublicIpAddress \
--public-ip-address-allocation static

Si la dirección IP pública debe ser una SKU estándar, agregue --public-ip-sku Standard al comando anterior.
Más información sobre las SKU de dirección IP pública. Si la máquina virtual se va a agregar al grupo back-
end de una instancia pública de Azure Load Balancer, la SKU de la dirección IP pública de la máquina virtual
debe coincidir con la SKU de la dirección IP del equilibrador de carga. Para más información, consulte Azure
Load Balancer.
4. Vea la dirección IP pública asignada y confirme que se creó como una dirección estática con una SKU básica,
con el comando az network public-ip show:
 az network public-ip show \
--resource-group myResourceGroup \
--name myPublicIpAddress \
--query [ipAddress,publicIpAllocationMethod,sku] \
--output table

Azure asigna una dirección IP pública de las direcciones usadas en la región en la que creó la máquina
virtual. Puede descargar la lista de intervalos (prefijos) para las nubes de Azure Pública, Gobierno de Estados
Unidos, China y Alemania.

WARNING
No modifique la configuración de direcciones IP dentro del sistema operativo de la máquina virtual. El sistema operativo no
conoce las direcciones IP públicas de Azure. Aunque puede agregar la configuración de dirección IP privada al sistema
operativo, se recomienda no hacerlo a menos que sea necesario y no hasta después de haber leído Incorporación o
eliminación de direcciones IP privadas a un sistema operativo.

Limpieza de recursos
Cuando ya no se necesiten, puede utilizar az group delete para eliminar el grupo de recursos y todos los recursos
que contenga:

az group delete --name myResourceGroup --yes

Pasos siguientes
Más información acerca de direcciones IP públicas en Azure
Más información acerca de toda la configuración de dirección IP pública
Más información acerca de direcciones IP privadas y la asignación de una dirección IP privada estática a una
máquina virtual de Azure
Más información acerca de cómo crear máquinas virtuales Linux y Windows
 Asociar una dirección IP pública a una máquina
virtual
23/09/2020 • 20 minutes to read • Edit Online

En este artículo, obtendrá información sobre cómo asociar una dirección IP pública a una máquina virtual (VM)
existente. Si quiere conectarse a una VM desde Internet, la VM debe tener una dirección IP pública asociada. Si
quiere crear una nueva VM con una dirección IP pública, puede hacerlo mediante Azure Portal, la interfaz de la
línea de comandos (CLI) de Azure o PowerShell. Las direcciones IP públicas tienen un precio simbólico. Para
obtener información detallada, consulte Precios. Existe un límite para el número de direcciones IP públicas que
puede usar por suscripción. Para obtener información detallada, consulte Límites.
Puede usar Azure Portal, la interfaz de la línea de comandos (CLI) de Azure o PowerShell para asociar una dirección
IP pública a una VM.

Portal de Azure
1. Inicie sesión en Azure Portal.
2. Busque o vaya a la máquina virtual a la que quiere agregar la dirección IP pública y, a continuación,
selecciónela.
3. En Configuración , seleccione Redes y, a continuación, seleccione la interfaz de red a la que quiere agregar
la dirección IP pública, como se muestra en la siguiente imagen:

NOTE
Las direcciones IP públicas están asociadas a las interfaces de red conectadas a una VM. En la imagen anterior, la VM
solo tiene una interfaz de red. Si la VM tiene varias interfaces de red, aparecerán todas y deberá seleccionar la interfaz
de red a la que quiere asociar la dirección IP pública.

4. Seleccione Configuraciones de IP y, a continuación, seleccione una configuración de IP, tal como se

muestra en la siguiente imagen:
 NOTE
Las direcciones IP públicas están asociadas a configuraciones de IP para una interfaz de red. En la imagen anterior, la
interfaz de red tiene una configuración de IP. Si la interfaz de red tiene varias configuraciones de IP, aparecerán todas
en la lista y deberá seleccionar la configuración de IP a la que quiere asociar la dirección IP pública.

5. Seleccione Habilitado y, a continuación, seleccione Dirección IP ( Configurar los valores obligatorios )

. Elija una dirección IP pública existente, que cerrará automáticamente el cuadro Elegir dirección IP
pública . Si no hay ninguna dirección IP pública en la lista, debe crear una. Para obtener información,
consulte Crear una dirección IP pública. Seleccione Guardar , tal como se muestra en la imagen que sigue y,
a continuación, cierre el cuadro de la configuración de IP.

NOTE
Las direcciones IP públicas que aparecen son aquellas que existen en la misma región que la VM. Si tiene varias
direcciones IP públicas creadas en la región, aparecerán todas aquí. Si alguna aparece atenuada, es porque la dirección
ya está asociada a otro recurso.

6. Vea la dirección IP pública asignada a la configuración de IP, como se muestra en la imagen siguiente. Puede
tardar unos segundos en aparecer una dirección IP.
 NOTE
Las direcciones se asignan desde un grupo de direcciones que se usa en cada región de Azure. Para ver una lista de
los grupos de direcciones que se usan en cada región, consulte Microsoft Azure Datacenter IP Ranges (Intervalos IP
del centro de datos de Microsoft Azure). La dirección asignada puede ser cualquiera de los grupos usados para la
región. Si necesita que la dirección se asigne desde un grupo específico de la región, use un prefijo de dirección IP
pública.

7. Permita el tráfico de red en la VM con reglas de seguridad en un grupo de seguridad de red.

Azure CLI
Instale la CLI de Azure o use Azure Cloud Shell. Azure Cloud Shell es un shell de Bash gratuito que se puede
ejecutar directamente en Azure Portal. Tiene la CLI de Azure preinstalada y configurada para utilizarla con la cuenta.
Seleccione el botón Probar en los comandos siguientes de la CLI. Al seleccionar Probar , se invoca una instancia de
Cloud Shell con la que puede iniciar sesión en la cuenta de Azure.
1. Si usa la CLI localmente en Bash, inicie sesión en Azure con az login .
2. Una dirección IP pública está asociada a una configuración de IP de una interfaz de red conectada a una VM.
Use el comando az network nic-ip-config update para asociar una dirección IP pública a una configuración
de IP. El siguiente ejemplo asocia una dirección IP pública denominada myVMPublicIPa la configuración de
IP ipconfigmyVM de una interfaz de red existente myVMVMNic que existe en un grupo de recursos
denominado myResourceGroup.

az network nic ip-config update \

--name ipconfigmyVM \
--nic-name myVMVMNic \
--resource-group myResourceGroup \
--public-ip-address myVMPublicIP

Si no tiene una dirección IP pública existente, use el comando az network public-ip create para crear
una. Por ejemplo, el comando siguiente crea una dirección IP pública denominada myVMPublicIP en
el grupo de recursos denominado myResourceGroup.

az network public-ip create --name myVMPublicIP --resource-group myResourceGroup

 NOTE
El comando anterior crea una dirección IP pública con valores predeterminados para varias configuraciones
que es posible que quiera personalizar. Para más información sobre la configuración de las direcciones IP
públicas, consulte Crear una dirección IP pública. Las direcciones se asignan desde un grupo de direcciones IP
públicas que se usa para cada región de Azure. Para ver una lista de los grupos de direcciones que se usan en
cada región, consulte Microsoft Azure Datacenter IP Ranges (Intervalos IP del centro de datos de Microsoft
Azure).

Si no conoce el nombre de una interfaz de red conectada a la VM, use el comando az vm nic list para
verla. Por ejemplo, el comando siguiente enumera los nombres de las interfaces de red conectadas a
una VM denominada myVM en un grupo de recursos denominado myResourceGroup:

az vm nic list --vm-name myVM --resource-group myResourceGroup

La salida incluye una o varias líneas que son similares al ejemplo siguiente:

"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/networkInterfaces/myVMVMN
ic",

En el ejemplo anterior, myVMVMNic es el nombre de la interfaz de red.

Si no conoce el nombre de una configuración de IP para una interfaz de red, use el comando az
network nic ip-config list para recuperarla. Por ejemplo, el comando siguiente enumera los nombres
de las configuraciones de IP para una interfaz de red denominada myVMVMNic en un grupo de
recursos denominado myResourceGroup:

az network nic ip-config list --nic-name myVMVMNic --resource-group myResourceGroup --out table

3. Vea la dirección IP pública asignada a la configuración de IP con el comando az vm list-ip-addresses. En el

ejemplo siguiente se muestran las direcciones IP asignadas a una VM existente denominada myVM en un
grupo de recursos denominado myResourceGroup.

az vm list-ip-addresses --name myVM --resource-group myResourceGroup --out table

NOTE
Las direcciones se asignan desde un grupo de direcciones que se usa en cada región de Azure. Para ver una lista de
los grupos de direcciones que se usan en cada región, consulte Microsoft Azure Datacenter IP Ranges (Intervalos IP
del centro de datos de Microsoft Azure). La dirección asignada puede ser cualquiera de los grupos usados para la
región. Si necesita que la dirección se asigne desde un grupo específico de la región, use un prefijo de dirección IP
pública.

4. Permita el tráfico de red en la VM con reglas de seguridad en un grupo de seguridad de red.

PowerShell
Instale PowerShell o use Azure Cloud Shell. Azure Cloud Shell es un shell gratuito que se ejecuta directamente en
Azure Portal. Tiene preinstalado y configurado PowerShell para usarlo con su cuenta. Seleccione el botón Probar
en los comandos siguientes de PowerShell. Al seleccionar Probar , se invoca una instancia de Cloud Shell con la
que puede iniciar sesión en la cuenta de Azure.
1. Si usa PowerShell localmente, inicie sesión en Azure con Connect-AzAccount .
2. Una dirección IP pública está asociada a una configuración de IP de una interfaz de red conectada a una VM.
Use los comandos Get-AzVirtualNetwork y Get-AzVirtualNetworkSubnetConfig para obtener la red virtual y
la subred en las que se encuentra la interfaz de red. A continuación, use el comando Get-AzNetworkInterface
para obtener una interfaz de red y el comando Get-AzPublicIpAddress para obtener una dirección IP pública
existente. A continuación, use el comando Set-AzNetworkInterfaceIpConfig para asociar la dirección IP
pública a la configuración de IP y el comando Set-AzNetworkInterface para escribir la nueva configuración
de IP para el interfaz de red.
El siguiente ejemplo asocia una dirección IP pública denominada myVMPublicIP a la configuración de IP
ipconfigmyVM de una interfaz de red existente denominada myVMVMNic que existe en una subred
denominada myVMSubnet en una red virtual denominada myVMVNet. Todos los recursos están en un
grupo de recursos denominado myResourceGroup.

$vnet = Get-AzVirtualNetwork -Name myVMVNet -ResourceGroupName myResourceGroup

$subnet = Get-AzVirtualNetworkSubnetConfig -Name myVMSubnet -VirtualNetwork $vnet
$nic = Get-AzNetworkInterface -Name myVMVMNic -ResourceGroupName myResourceGroup
$pip = Get-AzPublicIpAddress -Name myVMPublicIP -ResourceGroupName myResourceGroup
$nic | Set-AzNetworkInterfaceIpConfig -Name ipconfigmyVM -PublicIPAddress $pip -Subnet $subnet
$nic | Set-AzNetworkInterface

Si no tiene una dirección IP pública existente, use el comando New-AzPublicIpAddress para crear una.
Por ejemplo, el comando siguiente crea una dirección IP pública dinámica denominada
myVMPublicIP en el grupo de recursos denominado myResourceGroup en la región eastus.

New-AzPublicIpAddress -Name myVMPublicIP -ResourceGroupName myResourceGroup -AllocationMethod

Dynamic -Location eastus

NOTE
El comando anterior crea una dirección IP pública con valores predeterminados para varias configuraciones
que es posible que quiera personalizar. Para más información sobre la configuración de las direcciones IP
públicas, consulte Crear una dirección IP pública. Las direcciones se asignan desde un grupo de direcciones IP
públicas que se usa para cada región de Azure. Para ver una lista de los grupos de direcciones que se usan en
cada región, consulte Microsoft Azure Datacenter IP Ranges (Intervalos IP del centro de datos de Microsoft
Azure).

Si no conoce el nombre de una interfaz de red conectada a la VM, use el comando Get-AzVM para
verla. Por ejemplo, el comando siguiente enumera los nombres de las interfaces de red conectadas a
una VM denominada myVM en un grupo de recursos denominado myResourceGroup:

$vm = Get-AzVM -name myVM -ResourceGroupName myResourceGroup

$[Link]

La salida incluye una o varias líneas que son similares al ejemplo siguiente. En la salida de ejemplo,
myVMVMNic es el nombre de la interfaz de red.

"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/networkInterfaces/myVMVMN
ic",
 Si no conoce el nombre de la red virtual o subred en la que se encuentra la interfaz de red, use el
comando Get-AzNetworkInterface para ver la información. Por ejemplo, el comando siguiente obtiene
la información de la red virtual y la subred para una interfaz de red denominada myVMVMNic en un
grupo de recursos denominado myResourceGroup:

$nic = Get-AzNetworkInterface -Name myVMVMNic -ResourceGroupName myResourceGroup

$ipConfigs = $[Link]
$[Link] | Select Id

La salida incluye una o varias líneas que son similares al ejemplo siguiente. En la salida del ejemplo,
myVMVNET es el nombre de la red virtual y myVMSubnet es el nombre de la subred.

"/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/virtualNetworks/myVMVNET/
subnets/myVMSubnet",

Si no conoce el nombre de una configuración de IP para una interfaz de red, use el comando Get-
AzNetworkInterface para recuperarla. Por ejemplo, el comando siguiente enumera los nombres de las
configuraciones de IP para una interfaz de red denominada myVMVMNic en un grupo de recursos
denominado myResourceGroup:

$nic = Get-AzNetworkInterface -Name myVMVMNic -ResourceGroupName myResourceGroup

$[Link]

La salida incluye una o varias líneas que son similares al ejemplo siguiente. En la salida del ejemplo,
ipconfigmyVM es el nombre de una configuración de IP.

Id : /subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/networkInterfaces/myVMVMN
ic/ipConfigurations/ipconfigmyVM

3. Vea la dirección IP pública asignada a la configuración de IP con el comando Get-AzPublicIpAddress. El

ejemplo siguiente muestra la dirección asignada a una dirección IP pública denominada myVMPublicIP en el
grupo de recursos denominado myResourceGroup.

Get-AzPublicIpAddress -Name myVMPublicIP -ResourceGroupName myResourceGroup | Select IpAddress

Si no conoce el nombre de la dirección IP pública asignada a una configuración de IP, ejecute los siguientes
comandos para obtenerlo:

$nic = Get-AzNetworkInterface -Name myVMVMNic -ResourceGroupName myResourceGroup

$[Link]
$address = $[Link]
$address | Select Id

La salida incluye una o varias líneas que son similares al ejemplo siguiente. En la salida del ejemplo,
myVMPublicIP es el nombre de la dirección IP pública asignada a la configuración de IP.

"/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/publicIPAddresses/myVMPublicIP"
 NOTE
Las direcciones se asignan desde un grupo de direcciones que se usa en cada región de Azure. Para ver una lista de
los grupos de direcciones que se usan en cada región, consulte Microsoft Azure Datacenter IP Ranges (Intervalos IP
del centro de datos de Microsoft Azure). La dirección asignada puede ser cualquiera de los grupos usados para la
región. Si necesita que la dirección se asigne desde un grupo específico de la región, use un prefijo de dirección IP
pública.

4. Permita el tráfico de red en la VM con reglas de seguridad en un grupo de seguridad de red.

Permitir tráfico de red en la VM

Para poder conectarse a la dirección IP pública desde Internet, asegúrese de que tiene los puertos necesarios
abiertos en cualquier grupo de seguridad de red que haya asociado a la interfaz de red o la subred en la que se
encuentra la interfaz de red. Aunque los grupo de seguridad de red filtran el tráfico en la dirección IP privada de la
interfaz de red, una vez que el tráfico entrante llega a la dirección IP pública, Azure traduce la dirección pública a la
dirección IP privada, por lo que, si un grupo de seguridad de red evita el flujo de tráfico, la comunicación con la
dirección IP pública produce un error. Puede ver las reglas de seguridad vigentes para una interfaz de red y su
subred mediante Portal, la CLI o PowerShell.

Pasos siguientes
Permita el tráfico entrante de Internet a la VM con un grupo de seguridad de red. Para obtener información sobre
cómo crear un grupo de seguridad de red, consulte Trabajar con grupos de seguridad de red. Para obtener más
información sobre los grupos de seguridad de red, consulte Grupos de seguridad.
 Desasociación de una dirección IP pública de una
máquina virtual de Azure
23/09/2020 • 8 minutes to read • Edit Online

En este artículo aprenderá a desasociar direcciones IP públicas de una máquina virtual (VM) de Azure.
Para disociar una dirección IP pública de una máquina virtual, puede usar Azure Portal, la interfaz de la línea de
comandos (CLI) de Azure o PowerShell.

Azure portal
1. Inicie sesión en Azure Portal.
2. Busque o vaya a la máquina virtual de la que desea disociar la dirección IP pública y selecciónela.
3. En la página de la máquina virtual, seleccione Información general y, después, la dirección IP pública,
como se muestra en la imagen siguiente:

4. En la página de la dirección IP pública, seleccione Información general y, después, Desasociar , como se

muestra en la siguiente imagen:

5. En Desasociar dirección IP pública , seleccione Sí .

Azure CLI
Instale la CLI de Azure o use Azure Cloud Shell. Azure Cloud Shell es un shell de Bash gratuito que se puede
ejecutar directamente en Azure Portal. Tiene la CLI de Azure preinstalada y configurada para utilizarla con la cuenta.
Seleccione el botón Probar en los comandos siguientes de la CLI. Al seleccionar Probar , se invoca una instancia de
Cloud Shell con la que puede iniciar sesión en la cuenta de Azure.
1. Si usa la CLI localmente en Bash, inicie sesión en Azure con az login .
2. Una dirección IP pública está asociada a una configuración de IP de una interfaz de red conectada a una VM.
Use el comando az network nic-ip-config update para desasociar una dirección IP pública de la
configuración de una IP. En el siguiente ejemplo se desasocia una dirección IP pública denominada
myVMPublicIPde la configuración de IP ipconfigmyVM de una interfaz de red existente denominada
myVMVMNic que está asociada a una máquina virtual denominadamyVM de un grupo de recursos
denominado myResourceGroup.

az network nic ip-config update \

--name ipconfigmyVM \
--resource-group myResourceGroup \
--nic-name myVMVMNic \
--remove PublicIpAddress

Si no conoce el nombre de una interfaz de red conectada a la VM, use el comando az vm nic list para verla.
Por ejemplo, el comando siguiente enumera los nombres de las interfaces de red conectadas a una VM
denominada myVM en un grupo de recursos denominado myResourceGroup:

az vm nic list --vm-name myVM --resource-group myResourceGroup

La salida incluye una o varias líneas que son similares al ejemplo siguiente:

"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/networkInterfaces/myVMVMNic",

En el ejemplo anterior, myVMVMNic es el nombre de la interfaz de red.

Si no conoce el nombre de una configuración de IP para una interfaz de red, use el comando az
network nic ip-config list para recuperarla. Por ejemplo, el comando siguiente enumera los nombres
de las configuraciones de IP públicas para una interfaz de red denominada myVMVMNic en un grupo
de recursos denominado myResourceGroup:

az network nic ip-config list --nic-name myVMVMNic --resource-group myResourceGroup --out table

Si no conoce el nombre de una configuración de IP pública para una interfaz de red, use el comando
az network nic ip-config show para recuperarlo. Por ejemplo, el comando siguiente enumera los
nombres de las configuraciones de IP públicas para una interfaz de red denominada myVMVMNic en
un grupo de recursos denominado myResourceGroup:

az network nic ip-config show --name ipconfigmyVM --nic-name myVMVMNic --resource-group

myResourceGroup --query [Link]

PowerShell
Instale PowerShell o use Azure Cloud Shell. Azure Cloud Shell es un shell gratuito que se ejecuta directamente en
Azure Portal. Tiene preinstalado y configurado PowerShell para usarlo con su cuenta. Seleccione el botón Probar
en los comandos siguientes de PowerShell. Al seleccionar Probar , se invoca una instancia de Cloud Shell con la que
puede iniciar sesión en la cuenta de Azure.
1. Si usa PowerShell localmente, inicie sesión en Azure con Connect-AzAccount .
2. Una dirección IP pública está asociada a una configuración de IP de una interfaz de red conectada a una VM.
Use el comando Get-AzNetworkInterface para obtener una interfaz de red. Establezca el valor de Dirección IP
 pública en NULL y, después, use el comando Set-AzNetworkInterface para escribir la nueva configuración de
la IP en la interfaz de red.
En el ejemplo siguiente se desasocia una dirección IP pública denominada myVMPublicIP de una interfaz de
red denominada myVMVMNic que está asociada a una máquina virtual denominada myVM. Todos los
recursos están en un grupo de recursos denominado myResourceGroup.

$nic = Get-AzNetworkInterface -Name myVMVMNic -ResourceGroup myResourceGroup

$[Link] = $null
Set-AzNetworkInterface -NetworkInterface $nic

Si no conoce el nombre de una interfaz de red conectada a la VM, use el comando Get-AzVM para verla. Por
ejemplo, el comando siguiente enumera los nombres de las interfaces de red conectadas a una VM
denominada myVM en un grupo de recursos denominado myResourceGroup:

$vm = Get-AzVM -name myVM -ResourceGroupName myResourceGroup

$[Link]

La salida incluye una o varias líneas que son similares al ejemplo siguiente. En la salida de ejemplo,
myVMVMNic es el nombre de la interfaz de red.

"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/networkInterfaces/myVMVMNic",

Si no conoce el nombre de una configuración de IP para una interfaz de red, use el comando Get-
AzNetworkInterface para recuperarla. Por ejemplo, el comando siguiente enumera los nombres de las
configuraciones de IP para una interfaz de red denominada myVMVMNic en un grupo de recursos
denominado myResourceGroup:

$nic = Get-AzNetworkInterface -Name myVMVMNic -ResourceGroupName myResourceGroup

$[Link]

La salida incluye una o varias líneas que son similares al ejemplo siguiente. En la salida del ejemplo,
ipconfigmyVM es el nombre de una configuración de IP.

"id": "/subscriptions/00000000-0000-0000-0000-
000000000000/resourceGroups/myResourceGroup/providers/[Link]/networkInterfaces/myVMVMNic/ipCo
nfigurations/ipconfigmyVM"

Pasos siguientes
Aprenda a asociar una dirección IP pública a una máquina virtual.
 Configuración de una dirección IP privada para una
VM mediante Azure Portal
23/09/2020 • 7 minutes to read • Edit Online

A una máquina virtual (VM) se le asigna automáticamente una dirección IP privada de un intervalo que el usuario
especifique, en función de la subred en la que se implemente. La VM conserva la dirección hasta que se elimina.
Azure asigna dinámicamente la siguiente dirección IP privada disponible desde la subred en la que se crea una
máquina virtual. Si quiere que se asigne una dirección IP específica de la subred a la VM, asigne una dirección IP
estática.

Escenario
Para ilustrar mejor cómo configurar una dirección IP estática para una máquina virtual, en este documento se usa
este escenario:

En este escenario se crea una máquina virtual denominada DNS01 en la subred FrontEnd y se configura para usar
la dirección IP estática de [Link].
En los siguientes pasos de ejemplo se presupone que ya se ha creado un entorno simple. Si desea ejecutar los
pasos que se indican en este documento, cree primero una red virtual. Sin embargo, en el paso 3, use estos
valores en su lugar:

C O N F IGURA C IÓ N VA L UE

Nombre TestVNet

Espacio de direcciones [Link]/16

Resource group TestRG (si es necesario, seleccione Crear nuevo para crearlo)

Subred: nombre FrontEnd

Subred: intervalo de direcciones [Link]/24

Creación de una VM para probar direcciones IP privadas estáticas
Si crea una VM en el modo de implementación de Resource Manager, no puede establecer una dirección IP privada
estática mediante Azure Portal. En su lugar, primero debe crear la VM. A continuación, puede establecer la
dirección IP privada como estática.
Para crear una VM denominada DNS01 en la subred FrontEnd de una red virtual denominada TestVNet, siga estos
pasos:
1. En el menú de Azure Portal, seleccione Crear un recurso .

2. Seleccione Proceso > Máquina vir tual .

3. En Aspectos básicos , especifique los valores de los elementos como se describe en la tabla siguiente. A
continuación, seleccione Siguiente : Discos y Siguiente : Redes .

EL EM EN TO VA L UE

Suscripción Su suscripción actual

Grupos de recursos TestRG (seleccione la opción en la lista desplegable)

Nombre de la máquina vir tual DNS01

Región (EE. UU.) Este de EE. UU.

Imagen Windows Ser ver 2019 Datacenter

Tamaño Tamaño de VM B1ls , Ofer ta Estándar

Nombre de usuario El nombre de usuario de la cuenta de administrador

Contraseña La contraseña del nombre de usuario de la cuenta de

administrador

Confirmar contraseña La contraseña otra vez

4. En Redes , especifique los valores de los elementos como se describe en la tabla siguiente y, a continuación,
seleccione Siguiente .
EL EM EN TO VA L UE

Red vir tual TestVNet

Subred FrontEnd
5. En Administración , en Cuenta de almacenamiento de diagnóstico , elija vnetstorage . Si esa cuenta
de almacenamiento no aparece en la lista, seleccione Crear nueva , en Nombre especifique vnetstorage y
seleccione Aceptar . Por último, seleccione Revisar y crear .
6. En Revisar y crear , revise la información general y, después, seleccione Crear .
Cuando se crea la VM, aparece el siguiente mensaje.
Recuperación de la información de la dirección IP privada de una VM
Para ver la información de la dirección IP privada de la nueva VM:
1. Vaya a Azure Portal para encontrar la VM. Busque y seleccione Máquinas vir tuales .

2. Seleccione el nombre de la nueva VM (DNS01 ).

3. Elija Redes y seleccione la única interfaz de red que se muestra.

4. Elija Configuraciones de IP y seleccione la configuración de IP que se muestra en la tabla.

5. En Configuración de dirección IP privada , en la red virtual o la subred TestVNet/FrontEnd , anote el

valor de Asignación (Dinámica o Estática ) y la Dirección IP .
Adición de una dirección IP privada estática a una VM existente
Para agregar una dirección IP privada estática para la nueva VM:
1. En la página Configuración de IP, establezca la asignación de la dirección IP privada en Estática .
2. Cambie el valor de Dirección IP privada a [Link] y, a continuación, seleccione Guardar .
 NOTE
Si después de seleccionar Guardar se da cuenta de que la asignación sigue establecida en Dinámica , significa que la
dirección IP que ha escrito sigue estando en uso. Pruebe con otra dirección IP.

Eliminación de una dirección IP privada estática de una VM

Para eliminar una dirección IP privada estática de la VM:
En la página Configuración de IP, establezca la asignación de la dirección IP privada en Dinámica y, a continuación,
seleccione Guardar .

Configuración de direcciones IP en el sistema operativo

Desde dentro del sistema operativo de una VM, no debe asignar estáticamente la IP privada asignada a la VM de
Azure. Realice la asignación estática de una dirección IP privada solo cuando sea necesario, por ejemplo al asignar
muchas direcciones IP a las VM. Si establece manualmente la dirección IP privada en el sistema operativo,
asegúrese de que coincide con la dirección IP privada asignada a la interfaz de red de Azure. De lo contrario, puede
perder la conectividad a la VM. Más información sobre la configuración de la dirección IP privada.
Asimismo, nunca debe asignar manualmente la dirección IP pública asignada a una máquina virtual de Azure en el
sistema operativo de la máquina virtual.

Pasos siguientes
Más información sobre la administración de la configuración de la dirección IP privada.
 Creación de una máquina virtual con una dirección IP
privada estática mediante PowerShell
23/09/2020 • 5 minutes to read • Edit Online

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Puede crear una máquina virtual (VM) con una dirección IP privada estática. Asigne una dirección IP privada
estática en lugar de una dirección dinámica si quiere seleccionar la dirección de una subred que se asignará a una
VM. Obtenga más información sobre las direcciones IP privadas estáticas. Para cambiar una dirección IP privada
asignada a una VM existente de dinámica a estática, o para trabajar con direcciones IP públicas, consulte
Incorporación, cambio o eliminación de direcciones IP.

Creación de una máquina virtual

Puede realizar los pasos siguientes desde el equipo local o mediante Azure Cloud Shell. Para usar el equipo local,
asegúrese de que tiene instalado Azure PowerShell. Para usar Azure Cloud Shell, seleccione Probar en la esquina
superior derecha de cualquier cuadro de comando que sigue. Cloud Shell inicia su sesión en Azure.
1. Si usa Cloud Shell, continúe al paso 2. Abra una sesión de comandos e inicie sesión en Azure con
Connect-AzAccount .

2. Cree un grupo de recursos con el comando New-AzResourceGroup. En el siguiente ejemplo se crea un

grupo de recursos en la región Este de EE. UU. de Azure:

$RgName = "myResourceGroup"
$Location = "eastus"
New-AzResourceGroup -Name $RgName -Location $Location

3. Cree una configuración de subred y una red virtual con los comandos New-AzVirtualNetworkSubnetConfig
y New-AzVirtualNetwork:
 # Create a subnet configuration
$SubnetConfig = New-AzVirtualNetworkSubnetConfig `
-Name MySubnet `
-AddressPrefix [Link]/24

# Create a virtual network

$VNet = New-AzVirtualNetwork `
-ResourceGroupName $RgName `
-Location $Location `
-Name MyVNet `
-AddressPrefix [Link]/16 `
-Subnet $subnetConfig

# Get the subnet object for use in a later step.

$Subnet = Get-AzVirtualNetworkSubnetConfig -Name $[Link] -VirtualNetwork $VNet

4. Cree una interfaz de red en la red virtual y asigne una dirección IP privada de la subred a la interfaz de red
con los comandos New-AzNetworkInterfaceIpConfig y New-AzNetworkInterface:

$IpConfigName1 = "IPConfig-1"
$IpConfig1 = New-AzNetworkInterfaceIpConfig `
-Name $IpConfigName1 `
-Subnet $Subnet `
-PrivateIpAddress [Link] `
-Primary

$NIC = New-AzNetworkInterface `
-Name MyNIC `
-ResourceGroupName $RgName `
-Location $Location `
-IpConfiguration $IpConfig1

5. Cree una configuración de VM con New-AzVMConfig y, a continuación, cree la VM con New-AzVM. Cuando
se le solicite, proporcione un nombre de usuario y una contraseña que se usarán como credenciales de
inicio de sesión para la VM:

$VirtualMachine = New-AzVMConfig -VMName MyVM -VMSize "Standard_DS3"

$VirtualMachine = Set-AzVMOperatingSystem -VM $VirtualMachine -Windows -ComputerName MyServerVM -
ProvisionVMAgent -EnableAutoUpdate
$VirtualMachine = Add-AzVMNetworkInterface -VM $VirtualMachine -Id $[Link]
$VirtualMachine = Set-AzVMSourceImage -VM $VirtualMachine -PublisherName 'MicrosoftWindowsServer' -
Offer 'WindowsServer' -Skus '2012-R2-Datacenter' -Version latest
New-AzVM -ResourceGroupName $RgName -Location $Location -VM $VirtualMachine -Verbose

WARNING
Aunque puede agregar la configuración de dirección IP privada al sistema operativo, se recomienda no hacerlo hasta después
de haber leído el tema sobre la incorporación de una dirección IP privada a un sistema operativo.

IMPORTANT
Para acceder a la VM desde Internet, debe asignar una dirección IP pública a la VM. También puede cambiar una asignación
de dirección IP privada dinámica por una asignación estática. Para obtener más información, consulte Incorporación o
eliminación de direcciones IP. Además, se recomienda limitar el tráfico de red a la VM mediante la asociación de un grupo de
seguridad de red a la interfaz de red, a la subred que creó en la interfaz de red o a ambas. Para más información, consulte el
tema sobre la administración de grupos de seguridad de red.
Limpieza de recursos
Cuando ya no lo necesite, puede usar Remove-AzResourceGroup para quitar el grupo de recursos y todos los
recursos que contiene:

Remove-AzResourceGroup -Name myResourceGroup -Force

Pasos siguientes
Obtener más información acerca de las direcciones IP privadas y la asignación de una dirección IP privada
estática a una máquina virtual de Azure.
Obtener más información acerca de cómo crear máquinas virtuales Linux y Windows.
 Configuración de direcciones IP privadas para una
máquina virtual mediante la CLI de Azure
23/09/2020 • 7 minutes to read • Edit Online

A una máquina virtual (VM) se le asigna automáticamente una dirección IP privada de un intervalo que el usuario
especifique, en función de la subred en la que se implemente. La VM conserva la dirección hasta que se elimina.
Azure asigna dinámicamente la siguiente dirección IP privada disponible desde la subred en la que se crea una
máquina virtual. Si quiere que se asigne una dirección IP específica de la subred a la VM, asigne una dirección IP
estática.

Escenario
Para ilustrar mejor cómo configurar una dirección IP estática para una máquina virtual, en este documento se usa
este escenario:

En este escenario se crea una máquina virtual denominada DNS01 en la subred FrontEnd y se configura para usar
la dirección IP estática de [Link].

NOTE
En los siguientes comandos de ejemplo de la CLI de Azure se espera un entorno simple existente. Si desea ejecutar los
comandos que aparecen en este documento, cree primero el entorno de prueba descrito en creación de una red virtual.

Especificación de una dirección IP privada estática al crear una VM

Para crear una máquina virtual denominada DNS01 en la subred FrontEnd de una red virtual denominada
TestVNet con una dirección IP privada estática de [Link], complete estos pasos:
1. Si aún no lo ha hecho, instale y configure la última versión de la CLI de Azure e inicie sesión en una cuenta
de Azure con az login.
2. Ejecute el comando azure network nic create para crear una NIC con una dirección IP privada estática. En la
lista que se muestra en la salida se explican los parámetros utilizados.
 az network nic create \
--resource-group TestRG \
--name TestNIC \
--location centralus \
--subnet FrontEnd \
--private-ip-address [Link] \
--vnet-name TestVNet

Resultado esperado:

{
"newNIC": {
"dnsSettings": {
"appliedDnsServers": [],
"dnsServers": []
},
"enableIPForwarding": false,
"ipConfigurations": [
{
"etag": "W/\"<guid>\"",
"id":
"/subscriptions/<guid>/resourceGroups/TestRG/providers/[Link]/networkInterfaces/TestNIC/ipCon
figurations/ipconfig1",
"name": "ipconfig1",
"properties": {
"primary": true,
"privateIPAddress": "[Link]",
"privateIPAllocationMethod": "Static",
"provisioningState": "Succeeded",
"subnet": {
"id":
"/subscriptions/<guid>/resourceGroups/TestRG/providers/[Link]/virtualNetworks/TestVNet/subnet
s/FrontEnd",
"resourceGroup": "TestRG"
}
},
"resourceGroup": "TestRG"
}
],
"provisioningState": "Succeeded",
"resourceGuid": "<guid>"
}
}

Parámetros:
--private-ip-address: Dirección IP privada estática para la NIC.
--vnet-name : nombre de la red virtual en la que se va a crear la NIC.
--subnet : nombre de la subred en la que se va a crear la NIC.
3. Ejecute el comando azure vm create para crear la máquina virtual mediante la dirección IP pública y la NIC
creadas anteriormente. En la lista que se muestra en la salida se explican los parámetros utilizados.

az vm create \
--resource-group TestRG \
--name DNS01 \
--location centralus \
--image Debian \
--admin-username adminuser \
--ssh-key-value ~/.ssh/id_rsa.pub \
--nics TestNIC
 Resultado esperado:

{
"fqdns": "",
"id":
"/subscriptions/<guid>/resourceGroups/TestRG/providers/[Link]/virtualMachines/DNS01",
"location": "centralus",
"macAddress": "00-0D-3A-92-C1-66",
"powerState": "VM running",
"privateIpAddress": "[Link]",
"publicIpAddress": "",
"resourceGroup": "TestRG"
}

Parámetros que no sean las opciones básicas de az vm create.

--nics : nombre de la NIC a la que está conectada la máquina virtual.

Se recomienda no asignar estáticamente la dirección IP privada asignada a la máquina virtual de Azure en el

sistema operativo de una máquina virtual, a menos que sea necesario, como al asignar varias direcciones IP a una
máquina virtual Windows. Al establecer manualmente la dirección IP privada en el sistema operativo, asegúrese de
que sea la misma que la asignada a la interfaz de red de Azure; de lo contrario, perderá la conectividad a la
máquina virtual. Más información sobre la configuración de la dirección IP privada.

Recuperación de la información de la dirección IP privada estática para

una VM
Ejecute el siguiente comando de la CLI de Azure para observar los valores de Método de asignación de dirección IP
privada y Dirección IP privada:

az vm show -g TestRG -n DNS01 --show-details --query 'privateIps'

Resultado esperado:

"[Link]"

Para mostrar la información específica de la dirección IP de la NIC de esa máquina virtual, consulte la NIC
específicamente:

az network nic show \

-g testrg \
-n testnic \
--query 'ipConfigurations[0].{PrivateAddress:privateIpAddress,IPVer:privateIpAddressVersion,IpAllocMethod:p
rivateIpAllocationMethod,PublicAddress:publicIpAddress}'

La salida es similar a esta:

{
"IPVer": "IPv4",
"IpAllocMethod": "Static",
"PrivateAddress": "[Link]",
"PublicAddress": null
}
Eliminación de una dirección IP privada estática de una VM
No se puede eliminar una dirección IP privada estática de una NIC en la CLI de Azure para implementaciones de
Azure Resource Manager. Debe:
Crear una nueva NIC que use una dirección IP dinámica.
Establecer que la NIC de la máquina virtual sea la NIC recién creada.
Para cambiar el NIC de la máquina virtual que se utiliza en los comandos anteriores, realice los siguientes pasos:
1. Ejecute el comando azure network nic create para crear una nueva NIC mediante asignación de IP
dinámica con una dirección IP nueva. Como no se especifica ninguna dirección IP, el método de asignación
es Dynamic .

az network nic create \

--resource-group TestRG \
--name TestNIC2 \
--location centralus \
--subnet FrontEnd \
--vnet-name TestVNet

Resultado esperado:

{
"newNIC": {
"dnsSettings": {
"appliedDnsServers": [],
"dnsServers": []
},
"enableIPForwarding": false,
"ipConfigurations": [
{
"etag": "W/\"<guid>\"",
"id":
"/subscriptions/<guid>/resourceGroups/TestRG/providers/[Link]/networkInterfaces/TestNIC2/ipCo
nfigurations/ipconfig1",
"name": "ipconfig1",
"properties": {
"primary": true,
"privateIPAddress": "[Link]",
"privateIPAllocationMethod": "Dynamic",
"provisioningState": "Succeeded",
"subnet": {
"id":
"/subscriptions/<guid>/resourceGroups/TestRG/providers/[Link]/virtualNetworks/TestVNet/subnet
s/FrontEnd",
"resourceGroup": "TestRG"
}
},
"resourceGroup": "TestRG"
}
],
"provisioningState": "Succeeded",
"resourceGuid": "0808a61c-476f-4d08-98ee-0fa83671b010"
}
}

2. Ejecuta el comando azure vm set para cambiar la NIC que usó la VM.

az vm nic set --resource-group TestRG --vm-name DNS01 --nics TestNIC2

 Resultado esperado:

[
{
"id": "/subscriptions/0e220bf6-5caa-4e9f-8383-
51f16b6c109f/resourceGroups/TestRG/providers/[Link]/networkInterfaces/TestNIC3",
"primary": true,
"resourceGroup": "TestRG"
}
]

NOTE
Si la máquina virtual es suficientemente grande para tener más de una NIC, ejecute el comando azure network nic
delete para eliminar la NIC antigua.

Pasos siguientes
Más información sobre la administración de la configuración de la dirección IP privada.
 Configuración de direcciones IP privadas para una
máquina virtual (clásica) mediante Azure Portal
23/09/2020 • 6 minutes to read • Edit Online

A una máquina virtual (VM) se le asigna automáticamente una dirección IP privada de un intervalo que el usuario
especifique, en función de la subred en la que se implemente. La VM conserva la dirección hasta que se elimina.
Azure asigna dinámicamente la siguiente dirección IP privada disponible desde la subred en la que se crea una
máquina virtual. Si quiere que se asigne una dirección IP específica de la subred a la VM, asigne una dirección IP
estática.

IMPORTANT
Actualmente, Azure tiene dos modelos de implementación: Azure Resource Manager y clásico. Asegúrese de que comprende
los modelos de implementación y las herramientas antes de trabajar con recursos de Azure. Para ver la documentación de las
distintas herramientas, seleccione las pestañas que aparecen al principio de este artículo.

Este artículo trata sobre el modelo de implementación clásico. También puede administrar la dirección IP privada
estática en el modelo de implementación del Administrador de recursos.

Escenario
Para ilustrar mejor cómo configurar una dirección IP estática para una máquina virtual, en este documento se usa
este escenario:

En este escenario se crea una máquina virtual denominada DNS01 en la subred FrontEnd y se configura para usar
la dirección IP estática de [Link].
En los siguientes pasos de ejemplo se presupone que ya se ha creado un entorno simple. Si desea ejecutar los
pasos que aparecen en este documento, cree primero el entorno de prueba descrito en creación de una red virtual.

Especificación de una dirección IP privada estática al crear una VM

Para crear una máquina virtual denominada DNS01 en la subred FrontEnd de una red virtual denominada
TestVNet con una dirección IP privada estática de [Link], complete estos pasos:
1. Desde un explorador, vaya a [Link] y, si fuera necesario, inicie sesión con su cuenta de
Azure.
2. Seleccione NUEVO > Compute > Windows Ser ver 2012 R2 Datacenter . Observe que la lista
Seleccionar un modelo de implementación ya muestra Clásico . Seleccione Crear .

3. En Crear máquina vir tual , especifique el nombre de la máquina virtual que se va a crear (DNS01 en este
escenario), la cuenta de administrador local y la contraseña.

4. Seleccione Configuración opcional > Red > Red vir tual y TestVNet . Si TestVNet no está disponible,
asegúrese de que usa la ubicación Centro de EE. UU. y que ha creado el entorno de prueba descrito al
principio de este artículo.
5. En Red , asegúrese de que la subred seleccionada actualmente sea FrontEnd y seleccione Direcciones IP ; en
Asignación de dirección IP , seleccione Estática y especifique [Link] en Dirección IP como se
muestra a continuación.
6. Seleccione Aceptar en Direcciones IP ; Aceptar , en Red , y Aceptar , en Configuración opcional .
7. En Crear máquina vir tual , seleccione Crear . Observe el icono siguiente que aparece en el panel:

Recuperación de la información de la dirección IP privada estática para

una VM
Para ver la información de la dirección IP privada estática para la VM que creó con los pasos anteriores, ejecute los
siguientes pasos.
1. En Azure Portal, seleccione EXAMINAR TODO > Máquinas vir tuales (clásico) > DNS01 > Toda la
configuración > Direcciones IP y observe la asignación de dirección IP y la dirección IP que se muestran
a continuación.

Eliminación de una dirección IP privada estática de una VM

En Direcciones IP , seleccione Dinámica a la derecha del Asignación de dirección IP , seleccione Guardar y Sí ,
tal y como se muestra en la siguiente imagen:
Adición de una dirección IP privada estática a una VM existente
1. En Direcciones IP (que se mostró anteriormente), seleccione Estática a la derecha de Asignación de
dirección IP .
2. Escriba [Link] como Dirección IP , y seleccione Guardar y Sí .

Configuración de direcciones IP en el sistema operativo

Se recomienda no asignar estáticamente la dirección IP privada asignada a la máquina virtual de Azure en el
sistema operativo de una máquina virtual, a menos que sea necesario. Al establecer manualmente la dirección IP
privada en el sistema operativo, asegúrese de que sea la misma que la dirección IP privada asignada a la máquina
virtual de Azure, de lo contrario, perderá la conectividad a la máquina virtual. No asigne manualmente la dirección
IP pública asignada a una máquina virtual de Azure en el sistema operativo de la máquina virtual.

Pasos siguientes
Obtenga más información acerca de las direcciones IP públicas reservadas .
Obtenga información sobre las direcciones IP públicas a nivel de instancia (ILPIP) .
Consulte las API de REST de IP reservada.
 Configuración de direcciones IP privadas para una
máquina virtual (clásica) mediante PowerShell
23/09/2020 • 6 minutes to read • Edit Online

A una máquina virtual (VM) se le asigna automáticamente una dirección IP privada de un intervalo que el usuario
especifique, en función de la subred en la que se implemente. La VM conserva la dirección hasta que se elimina.
Azure asigna dinámicamente la siguiente dirección IP privada disponible desde la subred en la que se crea una
máquina virtual. Si quiere que se asigne una dirección IP específica de la subred a la VM, asigne una dirección IP
estática.

IMPORTANT
Actualmente, Azure tiene dos modelos de implementación: Azure Resource Manager y clásico. Asegúrese de que comprende
los modelos de implementación y las herramientas antes de trabajar con recursos de Azure. Para ver la documentación de las
distintas herramientas, seleccione las pestañas que aparecen al principio de este artículo.

Este artículo trata sobre el modelo de implementación clásico. También puede administrar la dirección IP privada
estática en el modelo de implementación del Administrador de recursos.

Escenario
Para ilustrar mejor cómo configurar una dirección IP estática para una máquina virtual, en este documento se usa
este escenario:

En este escenario se crea una máquina virtual denominada DNS01 en la subred FrontEnd y se configura para usar
la dirección IP estática de [Link].
En los siguientes comandos de PowerShell de ejemplo se presupone que ya se ha creado un entorno simple. Si
desea ejecutar los comandos que aparecen en este documento, cree primero el entorno de prueba descrito en
Creación de una red virtual.

Comprobación de que una dirección IP concreta está disponible

Para comprobar si la dirección IP [Link] está disponible en una red virtual denominada TestVnet, ejecute el
siguiente comando de PowerShell y compruebe el valor de IsAvailable:
 Test-AzureStaticVNetIP –VNetName TestVNet –IPAddress [Link]

Resultado esperado:

IsAvailable : True
AvailableAddresses : {}
OperationDescription : Test-AzureStaticVNetIP
OperationId : fd3097e1-5f4b-9cac-8afa-bba1e3492609
OperationStatus : Succeeded

Especificación de una dirección IP privada estática al crear una VM

El siguiente script de PowerShell crea un servicio en la nube denominado TestService; a continuación, recupera una
imagen de Azure, crea una máquina virtual denominada DNS01 en el nuevo servicio en la nube con la imagen
recuperada, establece que la máquina virtual esté en una subred llamada FrontEnd y establece [Link] como
dirección IP privada estática para la máquina virtual:

New-AzureService -ServiceName TestService -Location "Central US"

$image = Get-AzureVMImage | where {$_.ImageName -like "*RightImage-Windows-2012R2-x64*"}
New-AzureVMConfig -Name DNS01 -InstanceSize Small -ImageName $[Link] |
Add-AzureProvisioningConfig -Windows -AdminUsername adminuser -Password MyP@ssw0rd!! |
Set-AzureSubnet –SubnetNames FrontEnd |
Set-AzureStaticVNetIP -IPAddress [Link] |
New-AzureVM -ServiceName TestService –VNetName TestVNet

Resultado esperado:

WARNING: No deployment found in service: 'TestService'.

OperationDescription OperationId OperationStatus
-------------------- ----------- ---------------
New-AzureService fcf705f1-d902-011c-95c7-b690735e7412 Succeeded
New-AzureVM 3b99a86d-84f8-04e5-888e-b6fc3c73c4b9 Succeeded

Recuperación de la información de la dirección IP privada estática para

una VM
Para ver la información de la dirección IP privada estática para la máquina virtual creada con este script, ejecute el
siguiente comando de PowerShell y observe los valores de IpAddress:

Get-AzureVM -Name DNS01 -ServiceName TestService

Resultado esperado:
 DeploymentName : TestService
Name : DNS01
Label :
VM : [Link]
InstanceStatus : Provisioning
IpAddress : [Link]
InstanceStateDetails : Windows is preparing your computer for first use...
PowerState : Started
InstanceErrorCode :
InstanceFaultDomain : 0
InstanceName : DNS01
InstanceUpgradeDomain : 0
InstanceSize : Small
HostName : rsR2-797
AvailabilitySetName :
DNSName : [Link]
Status : Provisioning
GuestAgentStatus : [Link]
ResourceExtensionStatusList : {[Link]}
PublicIPAddress :
PublicIPName :
NetworkInterfaces : {}
ServiceName : TestService
OperationDescription : Get-AzureVM
OperationId : 34c1560a62f0901ab75cde4fed8e8bd1
OperationStatus : OK

Eliminación de una dirección IP privada estática de una VM

Para quitar la dirección IP privada estática agregada a la máquina virtual en el script anterior, ejecute el siguiente
comando de PowerShell:

Get-AzureVM -ServiceName TestService -Name DNS01 |

Remove-AzureStaticVNetIP |
Update-AzureVM

Resultado esperado:

OperationDescription OperationId OperationStatus

-------------------- ----------- ---------------
Update-AzureVM 052fa6f6-1483-0ede-a7bf-14f91f805483 Succeeded

Adición de una dirección IP privada estática a una VM existente

Para agregar una dirección IP privada estática a la VM creada con el script anterior, ejecute el siguiente comando:

Get-AzureVM -ServiceName TestService -Name DNS01 |

Set-AzureStaticVNetIP -IPAddress [Link] |
Update-AzureVM

Resultado esperado:

OperationDescription OperationId OperationStatus

-------------------- ----------- ---------------
Update-AzureVM 77d8cae2-87e6-0ead-9738-7c7dae9810cb Succeeded
Configuración de direcciones IP en el sistema operativo
Se recomienda no asignar estáticamente la dirección IP privada asignada a la máquina virtual de Azure en el
sistema operativo de una máquina virtual, a menos que sea necesario. Al establecer manualmente la dirección IP
privada en el sistema operativo, asegúrese de que sea la misma que la dirección IP privada asignada a la máquina
virtual de Azure, de lo contrario, perderá la conectividad a la máquina virtual. No asigne manualmente la dirección
IP pública asignada a una máquina virtual de Azure en el sistema operativo de la máquina virtual.

Pasos siguientes
Obtenga más información acerca de las direcciones IP públicas reservadas .
Obtenga información sobre las direcciones IP públicas a nivel de instancia (ILPIP) .
Consulte las API de REST de IP reservada.
 Asignación de varias direcciones IP a máquinas
virtuales con Azure Portal
23/09/2020 • 31 minutes to read • Edit Online

Una máquina virtual (VM) de Azure tiene una o varias interfaces de red (NIC) asociadas a ella. Una NIC puede
tener una o varias direcciones IP públicas o privadas estáticas o dinámicas asignadas. La asignación de varias
direcciones IP a una VM permite las siguientes capacidades:
Hospede varios sitios web o servicios con direcciones IP y certificados SSL diferentes en un único servidor.
Actúe como aplicación de red virtual, como un firewall o equilibrador de carga.
La capacidad de agregar cualquier dirección IP privada para cualquiera de las NIC a un grupo de
servidores de back-end de Azure Load Balancer. En el pasado, solo la dirección IP principal para la NIC
principal podía agregarse a un grupo de back-end. Para más información sobre cómo equilibrar la carga de
varias configuraciones de IP, lea el artículo Load balancing multiple IP configurations (Equilibrio de carga
de varias configuraciones de IP).
Cada NIC conectada a una VM tiene una o varias configuraciones de IP asociadas. Se asigna a cada
configuración una dirección IP privada estática o dinámica. Cada configuración también puede tener un
recurso de dirección IP pública asociado. Un recurso de dirección IP pública tiene una dirección IP pública
dinámica o estática asignada. Para más información sobre las direcciones IP en Azure, lea el artículo sobre
direcciones IP en Azure.
Existe un límite para el número de direcciones IP privadas que pueden asignarse a una NIC. También existe un
límite para el número de direcciones IP públicas que pueden usarse en una suscripción de Azure. Para más
información, consulte el artículo sobre los límites de Azure.
En este artículo se describe cómo crear una máquina virtual con el modelo de implementación de Azure
Resource Manager mediante Azure Portal. No se pueden asignar varias direcciones IP a los recursos creados
mediante el modelo de implementación clásica. Para información acerca de los modelos de implementación
de Azure, lea el artículo Understand deployment models (Descripción de los modelos de implementación).

Escenario
Se crea una máquina virtual con una sola NIC y se conecta a una red virtual. La máquina virtual requiere tres
direcciones IP privadas y dos direcciones IP públicas, todas diferentes. Las direcciones IP se asignan a las
siguientes configuraciones de IP:
IPConfig-1: asigna un dirección IP privada estática y una dirección IP pública estática.
IPConfig-2: asigna un dirección IP privada estática y una dirección IP pública estática.
IPConfig-3: asigna un dirección IP privada estática y ninguna dirección IP pública.
Las configuraciones de IP se asocian a la NIC cuando esta se crea, y la NIC se conecta a la máquina virtual cuando
esta se crea. Los tipos de direcciones IP usados para el escenario tienen fines ilustrativos. Puede asignar cualquier
dirección IP y tipo de asignación que necesite.

NOTE
Aunque los pasos de este artículo asignan todas las configuraciones de IP a una NIC única, también puede asignar varias
configuraciones de IP a cualquiera de las NIC de una máquina virtual con varias NIC. Para aprender a crear una VM con
varias NIC, lea el artículo Implementación de máquinas virtuales con varias NIC mediante PowerShell.

Creación de una máquina virtual con varias direcciones IP

Si desea crear una máquina virtual con varias direcciones IP, o una privada estática, debe crearla mediante
PowerShell o la CLI de Azure. Para saber cómo, haga clic en las opciones de PowerShell o de la CLI en la parte
superior de este artículo. Puede crear una máquina virtual con una única dirección IP privada dinámica y
(opcionalmente) una única dirección IP pública. En el portal, siga los pasos de los artículos Crear una máquina
virtual Windows o Crear una máquina virtual Linux. Después de crear la máquina virtual, puede cambiar los tipos
de direcciones IP de dinámicas a estáticas y agregar más mediante el portal siguiendo los pasos de la sección
Incorporación de direcciones IP a una VM de este artículo.

Incorporación de direcciones IP a una VM

Puede agregar direcciones IP públicas y privadas a una interfaz de red de Azure completando los pasos siguientes.
En los ejemplos de las secciones siguientes se da por sentado que ya tiene una máquina virtual con las tres
configuraciones de IP descritas en el escenario, pero no es un requisito indispensable.
Pasos principales
1. Vaya a Azure Portal en [Link] e inicie sesión, si es necesario.
2. En el portal, haga clic en Más ser vicios > tipo Máquinas virtuales en el cuadro de filtro y luego haga clic
en Máquinas vir tuales .
3. En el panel Máquinas vir tuales , haga clic en la máquina virtual a la que quiere agregar direcciones IP.
Vaya a la pestaña Redes . Haga clic en Interfaz de red en la página. Como se muestra en la figura
siguiente:
4. En la hoja Interfaz de red , seleccione Configuraciones de IP .
5. En el panel que aparece para la NIC que ha seleccionado, haga clic en Configuraciones de IP . Haga clic
en Agregar , complete los pasos de una de las secciones siguientes según el tipo de dirección IP que desea
agregar y, después, haga clic en Aceptar .
Incorporación de una dirección IP privada
Complete los pasos siguientes para agregar una nueva dirección IP privada:
1. Complete los pasos descritos en la sección Pasos básicos de este artículo y asegúrese de que se encuentre
en la sección Configuraciones de IP de la interfaz de red de la máquina virtual. Revise la subred que se
muestra como predeterminada (por ejemplo, [Link]/24).
2. Haga clic en Agregar . En el panel Agregar configuración de IP que aparece, cree una configuración de
IP denominada IPConfig-4 con una nueva dirección IP privada estática. Para ello, seleccione un nuevo
número para el octeto final y haga clic en Aceptar . (Para la subred [Link]/24, una dirección IP de ejemplo
sería [Link]).

NOTE
Al agregar una dirección IP estática, debe especificar una dirección válida no utilizada en la subred a la que la está
conectada la NIC. Si la dirección que seleccionó no está disponible, el portal muestra una X para la dirección IP y
debe seleccionar otra.

3. Al hacer clic en Aceptar, el panel se cierra y puede ver que aparece la nueva configuración de IP. Haga clic en
Aceptar para cerrar el panel Agregar configuración de IP .
4. Puede hacer clic en Agregar agregue más configuraciones IP o cerrar todas las hojas abiertas para
terminar de agregar direcciones IP.
5. Agregue la dirección IP privada al sistema operativo de la máquina virtual mediante los pasos de la sección
Incorporación de direcciones IP a un sistema operativo de la VM de este artículo.
Incorporación de una dirección IP pública
Se agrega una dirección IP pública mediante la asociación de un recurso de dirección IP pública a una nueva
configuración de IP o una configuración de IP existente.

NOTE
Las direcciones IP públicas tienen un precio simbólico. Para más información sobre los precios de las direcciones IP, lea la
página Precios de las direcciones IP . Existe un límite para el número de direcciones IP públicas que pueden usarse dentro de
una suscripción. Para más información sobre los límites, lea el artículo sobre los límites de Azure.

Creación de un recurso de dirección IP pública

Una dirección IP pública es una configuración para un recurso de dirección IP pública. Si tiene un recurso de
dirección IP pública que no está asociado actualmente a una configuración de IP que desea asociar a una
configuración de IP, omita los pasos siguientes y complete los pasos de una de las secciones siguientes, según sea
preciso. Si no tiene un recurso de dirección IP pública disponible, complete los pasos siguientes para crear uno:
1. Vaya a Azure Portal en [Link] e inicie sesión, si es necesario.
2. En el portal, haga clic en Crear un recurso > Redes > Dirección IP pública .
3. En el panel Crear dirección IP pública que aparece, escriba un nombre en Nombre , seleccione un tipo
en Asignación de dirección IP , una suscripción en Suscripción , un grupo de recursos en Grupo de
recursos y una ubicación en Ubicación . Luego, haga clic en Crear tal y como se muestra en la siguiente
imagen:

4. Complete los pasos de una de las secciones siguientes para asociar el recurso de dirección IP pública a una
configuración de IP.
Asociación del recurso de dirección IP pública a una nueva configuración de IP
1. Complete los pasos de la sección Pasos principales de este artículo.
2. Haga clic en Agregar . En el panel Agregar configuración de IP que aparece, cree una configuración de
IP denominada IPConfig 4. Habilite la opción Dirección IP pública y seleccione un recurso de dirección IP
pública existente que esté disponible en el panel Elegir dirección IP pública que aparece.
Cuando haya seleccionado el recurso de dirección IP pública, haga clic en Aceptar y el panel se cierra. Si
no tiene una dirección IP pública existente, puede crear una completando los pasos descritos en la sección
Creación de un recurso de dirección IP pública de este artículo.
3. Revise la nueva configuración de IP. Aunque no se asignara explícitamente una dirección IP privada, se
asigna una automáticamente a la configuración de IP, dado que todas las configuraciones IP deben tener
una dirección IP privada.
4. Puede hacer clic en Agregar agregue más configuraciones IP o cerrar todas las hojas abiertas para
terminar de agregar direcciones IP.
5. Agregue al sistema operativo de la máquina virtual la dirección IP privada siguiendo las instrucciones de la
sección Incorporación de direcciones IP a un sistema operativo de la VM de este artículo. No agregue la
dirección IP pública al sistema [Link].
Asociación del recurso de dirección IP pública a una configuración de IP existente
1. Complete los pasos de la sección Pasos principales de este artículo.
2. Haga clic en la configuración de IP a la que desee asociar el recurso de dirección IP pública.
3. En el panel de configuración de IP que aparece, haga clic en Dirección IP .
4. Haga clic en el panel Elegir dirección IP pública que aparece y seleccione una dirección IP pública.
5. Haga clic en Guardar , el panel se cierra. Si no tiene una dirección IP pública existente, puede crear una
completando los pasos descritos en la sección Creación de un recurso de dirección IP pública de este artículo.
6. Revise la nueva configuración de IP.
7. Puede hacer clic en Agregar agregue más configuraciones IP o cerrar todas las hojas abiertas para terminar
de agregar direcciones IP. No agregue la dirección IP pública al sistema [Link].

Incorporación de direcciones IP a un sistema operativo de la máquina

virtual
Conéctese e inicie sesión en una máquina virtual que creó con múltiples direcciones IP privadas. Debe agregar
manualmente todas las direcciones IP privadas (incluida la principal) que ha agregado a la máquina virtual.
Complete los pasos siguientes para el sistema operativo de su máquina virtual.
Windows Server
Expanda
Linux (Ubuntu 14/16)
Expanda
Linux (Ubuntu 18.04+)
Expanda
Linux (Red Hat, CentOS y otros)
Expanda
 Asignación de varias direcciones IP a máquinas
virtuales mediante PowerShell
23/09/2020 • 37 minutes to read • Edit Online

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.

Una máquina virtual (VM) de Azure tiene una o varias interfaces de red (NIC) asociadas a ella. Una NIC puede
tener una o varias direcciones IP públicas o privadas estáticas o dinámicas asignadas. La asignación de varias
direcciones IP a una VM permite las siguientes capacidades:
Hospede varios sitios web o servicios con direcciones IP y certificados SSL diferentes en un único servidor.
Actúe como aplicación de red virtual, como un firewall o equilibrador de carga.
La capacidad de agregar cualquier dirección IP privada para cualquiera de las NIC a un grupo de servidores
de back-end de Azure Load Balancer. En el pasado, solo la dirección IP principal para la NIC principal podía
agregarse a un grupo de back-end. Para más información sobre cómo equilibrar la carga de varias
configuraciones de IP, lea el artículo Load balancing multiple IP configurations (Equilibrio de carga de varias
configuraciones de IP).
Cada NIC conectada a una VM tiene una o varias configuraciones de IP asociadas. Se asigna a cada configuración
una dirección IP privada estática o dinámica. Cada configuración también puede tener un recurso de dirección IP
pública asociado. Un recurso de dirección IP pública tiene una dirección IP pública dinámica o estática asignada.
Para más información sobre las direcciones IP en Azure, lea el artículo sobre direcciones IP en Azure.
Existe un límite para el número de direcciones IP privadas que pueden asignarse a una NIC. También existe un
límite para el número de direcciones IP públicas que pueden usarse en una suscripción de Azure. Para más
información, consulte el artículo sobre los límites de Azure.
En este artículo se describe cómo crear una máquina virtual (VM) con el modelo de implementación de Azure
Resource Manager mediante PowerShell. No se pueden asignar varias direcciones IP a los recursos creados
mediante el modelo de implementación clásica. Para información acerca de los modelos de implementación de
Azure, lea el artículo Understand deployment models (Descripción de los modelos de implementación).

Escenario
Se crea una máquina virtual con una sola NIC y se conecta a una red virtual. La máquina virtual requiere tres
direcciones IP privadas y dos direcciones IP públicas, todas diferentes. Las direcciones IP se asignan a las
siguientes configuraciones de IP:
IPConfig-1: asigna un dirección IP privada estática y una dirección IP pública estática.
IPConfig-2: asigna un dirección IP privada estática y una dirección IP pública estática.
IPConfig-3: asigna un dirección IP privada estática y ninguna dirección IP pública.
Las configuraciones de IP se asocian a la NIC cuando esta se crea, y la NIC se conecta a la máquina virtual
cuando esta se crea. Los tipos de direcciones IP usados para el escenario tienen fines ilustrativos. Puede asignar
cualquier dirección IP y tipo de asignación que necesite.

NOTE
Aunque los pasos de este artículo asignan todas las configuraciones de IP a una NIC única, también puede asignar varias
configuraciones de IP a cualquiera de las NIC de una máquina virtual con varias NIC. Para aprender a crear una VM con
varias NIC, lea el artículo Implementación de máquinas virtuales con varias NIC mediante PowerShell.

Creación de una máquina virtual con varias direcciones IP

En los pasos siguientes se explica cómo crear una VM de ejemplo con varias direcciones IP, tal como se describe
en el escenario. Cambie los valores de variable según sea necesario para la implementación.
1. Abra un símbolo del sistema de PowerShell y complete los pasos restantes de esta sección en una única
sesión de PowerShell. Si todavía no tiene PowerShell instalado y configurado, complete los pasos del
artículo Cómo instalar y configurar Azure PowerShell .
2. Inicie sesión en la cuenta con el comando Connect-AzAccount .
3. Reemplace myResourceGroup y westus por un nombre y una ubicación de su elección. Cree un grupo de
recursos. Un grupo de recursos es un contenedor lógico en el que se implementan y se administran los
recursos de Azure.

$RgName = "MyResourceGroup"
$Location = "westus"

New-AzResourceGroup `
-Name $RgName `
-Location $Location

4. Cree una red virtual y una subred en la misma ubicación del grupo de recursos:
 # Create a subnet configuration
$SubnetConfig = New-AzVirtualNetworkSubnetConfig `
-Name MySubnet `
-AddressPrefix [Link]/24

# Create a virtual network

$VNet = New-AzVirtualNetwork `
-ResourceGroupName $RgName `
-Location $Location `
-Name MyVNet `
-AddressPrefix [Link]/16 `
-Subnet $subnetConfig

# Get the subnet object

$Subnet = Get-AzVirtualNetworkSubnetConfig -Name $[Link] -VirtualNetwork $VNet

5. Cree un grupo de seguridad de red (NSG) y una regla. El grupo de seguridad de red protege la máquina
virtual con reglas de entrada y salida. En este caso, se crea una regla de entrada para el puerto 3389, que
permite las conexiones entrantes al Escritorio remoto.

# Create an inbound network security group rule for port 3389

$NSGRule = New-AzNetworkSecurityRuleConfig `
-Name MyNsgRuleRDP `
-Protocol Tcp `
-Direction Inbound `
-Priority 1000 `
-SourceAddressPrefix * `
-SourcePortRange * `
-DestinationAddressPrefix * `
-DestinationPortRange 3389 -Access Allow

# Create a network security group

$NSG = New-AzNetworkSecurityGroup `
-ResourceGroupName $RgName `
-Location $Location `
-Name MyNetworkSecurityGroup `
-SecurityRules $NSGRule

6. Defina la configuración de la dirección IP principal para la NIC. Cambie [Link] a una dirección válida en
la subred que creó, si no usó el valor definido anteriormente. Antes de asignar una dirección IP estática, se
recomienda que primero confirme que no está en uso. Escriba el comando
Test-AzPrivateIPAddressAvailability -IPAddress [Link] -VirtualNetwork $VNet . Si la dirección está
disponible, la salida devuelve True. Si no está disponible, la salida devuelve False y una lista de direcciones
que están disponibles.
En los siguientes comandos, reemplace <replace-with-your-unique-name> por el nombre DNS
único que se va a usar. El nombre debe ser único en todas las direcciones IP públicas dentro de una
región de Azure. Se trata de un parámetro opcional. Se puede quitar si solo desea conectarse a la máquina
virtual con la dirección IP pública.
 # Create a public IP address
$PublicIP1 = New-AzPublicIpAddress `
-Name "MyPublicIP1" `
-ResourceGroupName $RgName `
-Location $Location `
-DomainNameLabel <replace-with-your-unique-name> `
-AllocationMethod Static

#Create an IP configuration with a static private IP address and assign the public IP address to it
$IpConfigName1 = "IPConfig-1"
$IpConfig1 = New-AzNetworkInterfaceIpConfig `
-Name $IpConfigName1 `
-Subnet $Subnet `
-PrivateIpAddress [Link] `
-PublicIpAddress $PublicIP1 `
-Primary

Cuando se asignan varias configuraciones de dirección IP a una NIC, se debe asignar una como la
principal.

NOTE
Las direcciones IP públicas tienen un precio simbólico. Para más información sobre los precios de las direcciones IP,
lea la página Precios de las direcciones IP . Existe un límite para el número de direcciones IP públicas que pueden
usarse dentro de una suscripción. Para más información sobre los límites, lea el artículo sobre los límites de Azure.

7. Defina las configuraciones de la dirección IP secundaria para la NIC. Puede agregar o quitar las
configuraciones que sean necesarias. Cada configuración de dirección IP debe tener asignada una
dirección IP privada. Cada configuración puede tener asignada opcionalmente una dirección IP pública.

# Create a public IP address

$PublicIP2 = New-AzPublicIpAddress `
-Name "MyPublicIP2" `
-ResourceGroupName $RgName `
-Location $Location `
-AllocationMethod Static

#Create an IP configuration with a static private IP address and assign the public IP address to it
$IpConfigName2 = "IPConfig-2"
$IpConfig2 = New-AzNetworkInterfaceIpConfig `
-Name $IpConfigName2 `
-Subnet $Subnet `
-PrivateIpAddress [Link] `
-PublicIpAddress $PublicIP2

$IpConfigName3 = "IpConfig-3"
$IpConfig3 = New-AzNetworkInterfaceIpConfig `
-Name $IPConfigName3 `
-Subnet $Subnet `
-PrivateIpAddress [Link]

8. Cree la NIC y asocie las tres configuraciones de dirección IP con ella:

 $NIC = New-AzNetworkInterface `
-Name MyNIC `
-ResourceGroupName $RgName `
-Location $Location `
-NetworkSecurityGroupId $[Link] `
-IpConfiguration $IpConfig1,$IpConfig2,$IpConfig3

NOTE
Aunque en este artículo todas las configuraciones están asignadas a una NIC, puede asignar varias configuraciones
de dirección IP a cada NIC conectada con la máquina virtual. Para aprender a crear una VM con varias NIC, lea el
artículo Implementación de máquinas virtuales con varias NIC mediante PowerShell.

9. Escriba los comandos siguientes para crear la máquina virtual:

# Define a credential object. When you run these commands, you're prompted to enter a username and
password for the VM you're creating.
$cred = Get-Credential

# Create a virtual machine configuration

$VmConfig = New-AzVMConfig `
-VMName MyVM `
-VMSize Standard_DS1_v2 | `
Set-AzVMOperatingSystem -Windows `
-ComputerName MyVM `
-Credential $cred | `
Set-AzVMSourceImage `
-PublisherName MicrosoftWindowsServer `
-Offer WindowsServer `
-Skus 2016-Datacenter `
-Version latest | `
Add-AzVMNetworkInterface `
-Id $[Link]

# Create the VM
New-AzVM `
-ResourceGroupName $RgName `
-Location $Location `
-VM $VmConfig

10. Agregue al sistema operativo de la máquina virtual la dirección IP privada siguiendo las instrucciones de
la sección Incorporación de direcciones IP a un sistema operativo de la VM de este artículo. No agregue
las direcciones IP públicas al sistema operativo.

Incorporación de direcciones IP a una VM

Puede agregar direcciones IP públicas y privadas a una interfaz de red de Azure mediante los pasos que se
indican a continuación. En los ejemplos de las secciones siguientes se da por sentado que ya tiene una máquina
virtual con las tres configuraciones de IP descritas en el escenario de este artículo, pero no es necesario que lo
haga.
1. Abra un símbolo del sistema de PowerShell y complete los pasos restantes de esta sección en una única
sesión de PowerShell. Si todavía no tiene PowerShell instalado y configurado, complete los pasos del
artículo Cómo instalar y configurar Azure PowerShell .
2. Cambie los "valores" de los elementos $Variables siguientes al nombre de la NIC a la que desee agregar
una dirección IP y al grupo de recursos y la ubicación donde existe la NIC:
 $NicName = "MyNIC"
$RgName = "MyResourceGroup"
$Location = "westus"

Si no conoce el nombre de la NIC que desea cambiar, escriba los siguientes comandos y cambie los
valores de las anteriores variables:

Get-AzNetworkInterface | Format-Table Name, ResourceGroupName, Location

3. Cree una variable y establézcala en la NIC existente con el siguiente comando:

$MyNIC = Get-AzNetworkInterface -Name $NicName -ResourceGroupName $RgName

4. En los siguientes comandos, cambie MyVNet y MySubnet a los nombres de la red virtual y la subred a las
que está conectada la NIC. Escriba los comandos para recuperar los objetos de red virtual y subred a las
que está conectada la NIC:

$MyVNet = Get-AzVirtualnetwork -Name MyVNet -ResourceGroupName $RgName

$Subnet = $[Link] | Where-Object { $_.Name -eq "MySubnet" }

Si no conoce el nombre de red virtual o la subred de a la que está conectada la NIC, escriba el siguiente
comando:

$[Link]

En la salida, busque un texto similar a la salida del ejemplo siguiente:

"Id":
"/subscriptions/[Id]/resourceGroups/myResourceGroup/providers/[Link]/virtualNetworks/MyVNet
/subnets/MySubnet"

En esta salida, MyVnet es la red virtual y MySubnet es la subred a la que está conectada la NIC.
5. Complete los pasos de una de las secciones siguientes, según sus requisitos:
Incorporación de una dirección IP privada
Para agregar una dirección IP privada a una NIC, debe crear una configuración de IP. El siguiente comando
crea una configuración con una dirección IP estática de [Link]. Al especificar una dirección IP estática,
debe ser una dirección no utilizada para la subred. Se recomienda que pruebe en primer lugar la dirección
para asegurarse de que está disponible escribiendo el comando
Test-AzPrivateIPAddressAvailability -IPAddress [Link] -VirtualNetwork $myVnet . Si la dirección IP está
disponible, la salida devuelve True. Si no está disponible, la salida devuelve False y una lista de direcciones
que están disponibles.

Add-AzNetworkInterfaceIpConfig -Name IPConfig-4 -NetworkInterface `

$MyNIC -Subnet $Subnet -PrivateIpAddress [Link]

Cree tantas configuraciones como sea necesario mediante nombres de configuración únicos y direcciones
IP privadas (para las configuraciones con direcciones IP estáticas).
Agregue al sistema operativo de la máquina virtual la dirección IP privada siguiendo las instrucciones de
la sección Incorporación de direcciones IP a un sistema operativo de la VM de este artículo.
Incorporación de una dirección IP pública
Se agrega una dirección IP pública mediante la asociación de un recurso de dirección IP pública a una
nueva configuración de IP o una configuración de IP existente. Complete los pasos de una de las secciones
siguientes, según sea preciso.

NOTE
Las direcciones IP públicas tienen un precio simbólico. Para más información sobre los precios de las direcciones IP,
lea la página Precios de las direcciones IP . Existe un límite para el número de direcciones IP públicas que pueden
usarse dentro de una suscripción. Para más información sobre los límites, lea el artículo sobre los límites de Azure.

Asociación del recurso de dirección IP pública a una nueva configuración de IP

Siempre que agregue una dirección IP pública en una nueva configuración de IP, también debe agregar
una dirección IP privada, porque todas las configuraciones de IP deben tener una dirección IP privada.
Puede agregar un recurso de dirección IP pública existente o crear uno nuevo. Para crear uno nuevo,
escriba el comando siguiente:

$myPublicIp3 = New-AzPublicIpAddress `
-Name "myPublicIp3" `
-ResourceGroupName $RgName `
-Location $Location `
-AllocationMethod Static

Para crear una nueva configuración de IP con una dirección IP privada estática y el recurso de dirección IP
pública myPublicIp3, escriba el comando siguiente:

Add-AzNetworkInterfaceIpConfig `
-Name IPConfig-4 `
-NetworkInterface $myNIC `
-Subnet $Subnet `
-PrivateIpAddress [Link] `
-PublicIpAddress $myPublicIp3

Asociación del recurso de dirección IP pública a una configuración de IP existente

Solo se puede asociar un recurso de dirección IP pública a una configuración de IP que ya no tiene
asociado uno. Puede determinar si una configuración de IP tiene una dirección IP pública asociada
escribiendo el comando siguiente:

$[Link] | Format-Table Name, PrivateIPAddress, PublicIPAddress, Primary

Verá un resultado similar al siguiente:

Name PrivateIpAddress PublicIpAddress Primary

IPConfig-1 [Link] [Link] True

IPConfig-2 [Link] [Link] False
IpConfig-3 [Link] False

Puesto que la columna PublicIpAddress para IpConfig-3 está en blanco, ningún recurso de dirección IP
pública está asociado actualmente a ella. Puede agregar un recurso de dirección IP pública existente a
 IpConfig-3 o escribir el siguiente comando para crear uno:

$MyPublicIp3 = New-AzPublicIpAddress `
-Name "MyPublicIp3" `
-ResourceGroupName $RgName `
-Location $Location -AllocationMethod Static

Escriba el siguiente comando para asociar el recurso de dirección IP pública a la configuración de IP

existente llamada IpConfig-3:

Set-AzNetworkInterfaceIpConfig `
-Name IpConfig-3 `
-NetworkInterface $mynic `
-Subnet $Subnet `
-PublicIpAddress $myPublicIp3

6. Establezca la NIC con la nueva configuración de IP escribiendo el siguiente comando:

Set-AzNetworkInterface -NetworkInterface $MyNIC

7. Vea las direcciones IP privadas y los recursos de dirección IP pública asignados a la NIC escribiendo el
siguiente comando:

$[Link] | Format-Table Name, PrivateIPAddress, PublicIPAddress, Primary

8. Agregue al sistema operativo de la máquina virtual la dirección IP privada siguiendo las instrucciones de
la sección Incorporación de direcciones IP a un sistema operativo de la VM de este artículo. No agregue la
dirección IP pública al sistema [Link].

Incorporación de direcciones IP a un sistema operativo de la máquina

virtual
Conéctese e inicie sesión en una máquina virtual que creó con múltiples direcciones IP privadas. Debe agregar
manualmente todas las direcciones IP privadas (incluida la principal) que ha agregado a la máquina virtual.
Complete los pasos siguientes para el sistema operativo de su máquina virtual.
Windows Server
Expanda
Linux (Ubuntu 14/16)
Expanda
Linux (Ubuntu 18.04+)
Expanda
Linux (Red Hat, CentOS y otros)
Expanda
 Asignación de varias direcciones IP a máquinas
virtuales mediante la CLI de Azure
23/09/2020 • 33 minutes to read • Edit Online

Una máquina virtual (VM) de Azure tiene una o varias interfaces de red (NIC) asociadas a ella. Una NIC puede
tener una o varias direcciones IP públicas o privadas estáticas o dinámicas asignadas. La asignación de varias
direcciones IP a una VM permite las siguientes capacidades:
Hospede varios sitios web o servicios con direcciones IP y certificados SSL diferentes en un único servidor.
Actúe como aplicación de red virtual, como un firewall o equilibrador de carga.
La capacidad de agregar cualquier dirección IP privada para cualquiera de las NIC a un grupo de servidores
de back-end de Azure Load Balancer. En el pasado, solo la dirección IP principal para la NIC principal podía
agregarse a un grupo de back-end. Para más información sobre cómo equilibrar la carga de varias
configuraciones de IP, lea el artículo Load balancing multiple IP configurations (Equilibrio de carga de varias
configuraciones de IP).
Cada NIC conectada a una VM tiene una o varias configuraciones de IP asociadas. Se asigna a cada
configuración una dirección IP privada estática o dinámica. Cada configuración también puede tener un recurso
de dirección IP pública asociado. Un recurso de dirección IP pública tiene una dirección IP pública dinámica o
estática asignada. Para más información sobre las direcciones IP en Azure, lea el artículo sobre direcciones IP en
Azure.
Existe un límite para el número de direcciones IP privadas que pueden asignarse a una NIC. También existe un
límite para el número de direcciones IP públicas que pueden usarse en una suscripción de Azure. Para más
información, consulte el artículo sobre los límites de Azure.
En este artículo se describe cómo crear una máquina virtual con el modelo de implementación de Azure
Resource Manager mediante la CLI de Azure. No se pueden asignar varias direcciones IP a los recursos creados
mediante el modelo de implementación clásica. Para información acerca de los modelos de implementación de
Azure, lea el artículo Understand deployment models (Descripción de los modelos de implementación).

Escenario
Se crea una máquina virtual con una sola NIC y se conecta a una red virtual. La máquina virtual requiere tres
direcciones IP privadas y dos direcciones IP públicas, todas diferentes. Las direcciones IP se asignan a las
siguientes configuraciones de IP:
IPConfig-1: asigna un dirección IP privada estática y una dirección IP pública estática.
IPConfig-2: asigna un dirección IP privada estática y una dirección IP pública estática.
IPConfig-3: asigna un dirección IP privada estática y ninguna dirección IP pública.
Las configuraciones de IP se asocian a la NIC cuando esta se crea, y la NIC se conecta a la máquina virtual
cuando esta se crea. Los tipos de direcciones IP usados para el escenario tienen fines ilustrativos. Puede asignar
cualquier dirección IP y tipo de asignación que necesite.

NOTE
Aunque los pasos de este artículo asignan todas las configuraciones de IP a una NIC única, también puede asignar varias
configuraciones de IP a cualquiera de las NIC de una máquina virtual con varias NIC. Para aprender a crear una VM con
varias NIC, lea el artículo Implementación de máquinas virtuales con varias NIC mediante PowerShell.

Creación de una máquina virtual con varias direcciones IP

En los pasos siguientes se explica cómo crear una máquina virtual de ejemplo con varias direcciones IP, tal y
como se describe en el escenario. Cambie los valores de variable de "" y los tipos de direcciones IP según sea
necesario para la implementación.
1. Instale la CLI de Azure, si aún no la tiene instalada.
2. Cree un par de claves pública y privada SSH para máquinas virtuales Linux siguiendo los pasos de Creación
de un par de claves SSH pública y privada para máquinas virtuales Linux.
3. Desde un shell de comandos, inicie sesión con el comando az login y seleccione la suscripción que está
usando.
4. Cree la máquina virtual mediante la ejecución del siguiente script en un equipo Linux o Mac. El script crea un
grupo de recursos, una red virtual (VNet), una NIC con tres configuraciones IP y una máquina virtual con las
dos NIC conectadas a ella. La NIC, la dirección IP pública, la red virtual y los recursos de máquina virtual
deben existir en la misma ubicación y suscripción. Aunque los recursos no tienen por qué existir todos en el
mismo grupo de recursos, en el siguiente script sí lo hacen.

#!/bin/sh

RgName="myResourceGroup"
Location="westcentralus"
az group create --name $RgName --location $Location

# Create a public IP address resource with a static IP address using the `--allocation-method Static`
option. If you
# do not specify this option, the address is allocated dynamically. The address is assigned to the resource
from a pool
# of IP addresses unique to each Azure region. Download and view the file from
# [Link] that lists the ranges for each region.
PipName="myPublicIP"

# This name must be unique within an Azure location.

DnsName="myDNSName"

az network public-ip create \

--name $PipName \
--resource-group $RgName \
--location $Location \
--dns-name $DnsName\
--allocation-method Static

# Create a virtual network with one subnet

VnetName="myVnet"
VnetPrefix="[Link]/16"
VnetSubnetName="mySubnet"
VnetSubnetPrefix="[Link]/24"

az network vnet create \

--name $VnetName \
--resource-group $RgName \
--location $Location \
--address-prefix $VnetPrefix \
--subnet-name $VnetSubnetName \
--subnet-prefix $VnetSubnetPrefix

# Create a network interface connected to the subnet and associate the public IP address to it. Azure will
create the
# first IP configuration with a static private IP address and will associate the public IP address resource
to it.

NicName="MyNic1"
az network nic create \
--name $NicName \
--resource-group $RgName \
--location $Location \
--subnet $VnetSubnet1Name \
--private-ip-address [Link]
--vnet-name $VnetName \
--public-ip-address $PipName

# Create a second public IP address, a second IP configuration, and associate it to the NIC. This
configuration has a
# static public IP address and a static private IP address.

az network public-ip create \

--resource-group $RgName \
--location $Location \
--name myPublicIP2 \
--dns-name mypublicdns2 \
--allocation-method Static

az network nic ip-config create \

--resource-group $RgName \
--nic-name $NicName \
--name IPConfig-2 \
--private-ip-address [Link] \
--public-ip-name myPublicIP2

# Create a third IP configuration, and associate it to the NIC. This configuration has static private IP
address and # no public IP address.

az network nic ip-config create \

--resource-group $RgName \
--nic-name $NicName \
--private-ip-address [Link] \
--name IPConfig-3
 # Note: Though this article assigns all IP configurations to a single NIC, you can also assign multiple IP
configurations
# to any NIC in a VM. To learn how to create a VM with multiple NICs, read the Create a VM with multiple
NICs
# article: [Link]

# Create a VM and attach the NIC.

VmName="myVm"

# Replace the value for the following **VmSize** variable with a value from the
# [Link] article. The script fails if the VM size
# is not supported in the location you select. Run the `azure vm sizes --location eastcentralus` command to
get a full list
# of VMs in US West Central, for example.

VmSize="Standard_DS1"

# Replace the value for the OsImage variable value with a value for *urn* from the output returned by
entering the
# `az vm image list` command.

OsImage="credativ:Debian:8:latest"

Username="adminuser"

# Replace the following value with the path to your public key file. If you're creating a Windows VM, remove
the following
# line and you'll be prompted for the password you want to configure for the VM.

SshKeyValue="~/.ssh/id_rsa.pub"

az vm create \
--name $VmName \
--resource-group $RgName \
--image $OsImage \
--location $Location \
--size $VmSize \
--nics $NicName \
--admin-username $Username \
--ssh-key-value $SshKeyValue

Además de crear una máquina virtual con una NIC con 3 configuraciones IP, el script crea:
Un único disco administrado premium de forma predeterminada, pero tiene otras opciones para el tipo de
disco que puede crear. Consulte el artículo Creación de una máquina virtual Linux con la CLI de Azure para
más información.
Una red virtual con una subred y dos direcciones IP públicas. Como alternativa, puede usar una red virtual,
una subred, una NIC o una dirección IP pública existentes. Para aprender a utilizar los recursos de red
existentes, en lugar de crear recursos adicionales, escriba az vm create -h .
Las direcciones IP públicas tienen un precio simbólico. Para más información sobre los precios de las direcciones
IP, lea la página Precios de las direcciones IP . Existe un límite para el número de direcciones IP públicas que
pueden usarse dentro de una suscripción. Para más información sobre los límites, lea el artículo sobre los límites
de Azure.
Después de crear la máquina virtual, escriba el comando
az network nic show --name MyNic1 --resource-group myResourceGroup para ver la configuración de la NIC. Escriba
el az network nic ip-config list --nic-name MyNic1 --resource-group myResourceGroup --output table para ver
una lista de las configuraciones de IP asociadas a la NIC.
Agregue al sistema operativo de la máquina virtual la dirección IP privada siguiendo las instrucciones de la
sección Incorporación de direcciones IP a un sistema operativo de la VM de este artículo.

Incorporación de direcciones IP a una VM

Puede agregar más direcciones IP públicas y privadas a una interfaz de red de Azure existente completando los
pasos siguientes. Los ejemplos se crean en el escenario descrito en este artículo.
1. Abra un shell de comandos y complete los pasos restantes de esta sección dentro de una sola sesión. Si
todavía no tiene la CLI de Azure instalada y configurada, complete los pasos del artículo Instalación de la
CLI de Azure e inicie sesión en la cuenta de Azure con el comando az-login .
2. Complete los pasos de una de las secciones siguientes, según sus requisitos:
Incorporación de una dirección IP privada
Para agregar una dirección IP privada a una NIC, debe crear una configuración de IP mediante el
comando siguiente. La dirección IP estática debe ser una dirección no utilizada para la subred.

az network nic ip-config create \

--resource-group myResourceGroup \
--nic-name myNic1 \
--private-ip-address [Link] \
--name IPConfig-4

Cree tantas configuraciones como sea necesario mediante nombres de configuración únicos y
direcciones IP privadas (para las configuraciones con direcciones IP estáticas).
Incorporación de una dirección IP pública
Se agrega una dirección IP pública mediante la asociación a una nueva configuración de IP o una
configuración de IP existente. Complete los pasos de una de las secciones siguientes, según sea preciso.
Las direcciones IP públicas tienen un precio simbólico. Para más información sobre los precios de las
direcciones IP, lea la página Precios de las direcciones IP . Existe un límite para el número de direcciones IP
públicas que pueden usarse dentro de una suscripción. Para más información sobre los límites, lea el
artículo sobre los límites de Azure.
Asociación del recurso a una nueva configuración de IP
Siempre que agregue una dirección IP pública en una nueva configuración de IP, también debe
agregar una dirección IP privada, porque todas las configuraciones de IP deben tener una dirección
IP privada. Puede agregar un recurso de dirección IP pública existente o crear uno nuevo. Para
crear uno nuevo, escriba el comando siguiente:

az network public-ip create \

--resource-group myResourceGroup \
--location westcentralus \
--name myPublicIP3 \
--dns-name mypublicdns3

Para crear una nueva configuración de IP con una dirección IP privada estática y el recurso de
dirección IP pública myPublicIP3, escriba el comando siguiente:
 az network nic ip-config create \
--resource-group myResourceGroup \
--nic-name myNic1 \
--name IPConfig-5 \
--private-ip-address [Link]
--public-ip-address myPublicIP3

Asocie el recurso a una configuración de IP existente . Solo se puede asociar un recurso de

dirección IP pública a una configuración de IP que ya no tiene asociado uno. Puede determinar si
una configuración de IP tiene una dirección IP pública asociada escribiendo el comando siguiente:

az network nic ip-config list \

--resource-group myResourceGroup \
--nic-name myNic1 \
--query "[?provisioningState=='Succeeded'].{ Name: name, PublicIpAddressId: [Link]
}" --output table

Salida que se devuelve:

Name PublicIpAddressId

ipconfig1
/subscriptions/[Id]/resourceGroups/myResourceGroup/providers/[Link]/publicIPAddress
es/myPublicIP1
IPConfig-2
/subscriptions/[Id]/resourceGroups/myResourceGroup/providers/[Link]/publicIPAddress
es/myPublicIP2
IPConfig-3

Puesto que la columna PublicIpAddressId para IpConfig-3 está en blanco en la salida, ningún
recurso de dirección IP pública está asociado actualmente a ella. Puede agregar un recurso de
dirección IP pública existente a IpConfig-3 o escribir el siguiente comando para crear uno:

az network public-ip create \

--resource-group myResourceGroup
--location westcentralus \
--name myPublicIP3 \
--dns-name mypublicdns3 \
--allocation-method Static

Escriba el siguiente comando para asociar el recurso de dirección IP pública a la configuración de

IP existente llamada IPConfig-3:

az network nic ip-config update \

--resource-group myResourceGroup \
--nic-name myNic1 \
--name IPConfig-3 \
--public-ip myPublicIP3

3. Vea las direcciones IP privadas y los identificadores de los recursos de dirección IP pública asignados a la
NIC escribiendo el siguiente comando:
 az network nic ip-config list \
--resource-group myResourceGroup \
--nic-name myNic1 \
--query "[?provisioningState=='Succeeded'].{ Name: name, PrivateIpAddress: privateIpAddress,
PrivateIpAllocationMethod: privateIpAllocationMethod, PublicIpAddressId: [Link] }" --
output table

Salida que se devuelve:

Name PrivateIpAddress PrivateIpAllocationMethod PublicIpAddressId

ipconfig1 [Link] Static

/subscriptions/[Id]/resourceGroups/myResourceGroup/providers/[Link]/publicIPAddresses/myPu
blicIP1
IPConfig-2 [Link] Static
/subscriptions/[Id]/resourceGroups/myResourceGroup/providers/[Link]/publicIPAddresses/myPu
blicIP2
IPConfig-3 [Link] Static
/subscriptions/[Id]/resourceGroups/myResourceGroup/providers/[Link]/publicIPAddresses/myPu
blicIP3

4. Agregue al sistema operativo de la VM las direcciones IP privadas que agregó a la NIC siguiendo las
instrucciones de la sección Incorporación de direcciones IP a un sistema operativo de la VM de este
artículo. No agregue las direcciones IP públicas al sistema operativo.

Incorporación de direcciones IP a un sistema operativo de la máquina

virtual
Conéctese e inicie sesión en una máquina virtual que creó con múltiples direcciones IP privadas. Debe agregar
manualmente todas las direcciones IP privadas (incluida la principal) que ha agregado a la máquina virtual.
Complete los pasos siguientes para el sistema operativo de su máquina virtual.
Windows Server
Expanda
Linux (Ubuntu 14/16)
Expanda
Linux (Ubuntu 18.04+)
Expanda
Linux (Red Hat, CentOS y otros)
Expanda
 Incorporación de interfaces de red a máquinas
virtuales o su eliminación de ellas
23/09/2020 • 16 minutes to read • Edit Online

Obtenga información sobre cómo agregar una interfaz de red existente al crear una máquina virtual (VM) de
Azure. Aprenda también a agregar o quitar interfaces de red de una VM existente en estado detenido
(desasignado). Una interfaz de red permite que una VM de Azure se comunique con Internet, Azure y recursos
locales. Una VM puede tener una o varias interfaces de red.
Si tiene que agregar, cambiar o quitar direcciones IP para una interfaz de red, consulte Administración de
direcciones IP de interfaz de red. Para crear, cambiar o eliminar interfaces de red, consulte Administración de
interfaces de red.

Antes de empezar
NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.

Si no tiene ninguna, configure una cuenta de Azure con una suscripción activa. Cree una cuenta gratuita.
Complete una de estas tareas antes de continuar con este artículo:
Usuarios de Por tal : Inicie sesión en Azure Portal con su cuenta de Azure.
Usuarios de PowerShell : ejecute los comandos en Azure Cloud Shell, o bien ejecute PowerShell en el
equipo. Azure Cloud Shell es un shell interactivo gratuito que puede usar para ejecutar los pasos de este
artículo. Tiene las herramientas comunes de Azure preinstaladas y configuradas para usarlas en la cuenta.
En la pestaña del explorador Azure Cloud Shell, busque la lista desplegable Seleccionar entorno y,
después, elija PowerShell si aún no está seleccionado.
Si ejecuta PowerShell en el entorno local, use la versión del módulo de Azure PowerShell 1.0.0 o una
posterior. Ejecute Get-Module -ListAvailable [Link] para buscar la versión instalada. Si necesita
actualizarla, consulte Instalación del módulo de Azure PowerShell. Ejecute Connect-AzAccount para crear
una conexión con Azure.
Usuarios de la interfaz de la línea de comandos (CLI) de Azure : ejecute los comandos en Azure
Cloud Shell, o bien ejecute la CLI en el equipo. Use la versión 2.0.26 de la CLI de Azure o una posterior si
ejecuta la CLI de Azure en el entorno local. Ejecute az --version para buscar la versión instalada. Si
necesita instalarla o actualizarla, vea Instalación de la CLI de Azure. Ejecute az login para crear una
conexión con Azure.

Adición de interfaces de red existentes a una nueva máquina virtual

Al crear una máquina virtual a través del portal, este crea una interfaz de red con la configuración
predeterminada y asocia la interfaz de red a la VM automáticamente. No se puede usar el portal para agregar
interfaces de red existentes a una VM nueva ni para crear una VM con varias interfaces de red. Para ello, puede
usar la CLI o PowerShell. Asegúrese de familiarizarse con las restricciones. Si crea una máquina virtual con varias
interfaces de red, también debe configurar el sistema operativo para usarlas correctamente después de crear la
máquina virtual. Aprenda cómo configurar Linux o Windows para varias interfaces de red.
Comandos:
Antes de crear una VM, cree una interfaz de red.

H ERRA M IEN TA GET - H EL P

CLI az network nic create

PowerShell New-AzNetworkInterface

Incorporación de una interfaz de red a una VM existente

Para agregar una interfaz de red a la máquina virtual:
1. Vaya a Azure Portal para buscar una máquina virtual existente. Busque y seleccione Máquinas vir tuales .
2. Seleccione el nombre de la VM. La máquina virtual debe admitir el número de interfaces de red que
quiere agregar. Para averiguar cuántas interfaces de red admite cada tamaño de VM, consulte los tamaños
de Azure para VM Linux o VM Windows.
3. En la barra de comandos de la VM, seleccione Detener y, a continuación, Aceptar en el cuadro de diálogo
de confirmación. Espere a que el valor de Estado de la VM cambie a Detenido (desasignado) .
4. En la barra de menús de la VM, elija Redes > Asociar interfaz de red . A continuación, en Asociar una
interfaz de red existente , elija la interfaz de red que desea asociar y seleccione Aceptar .

NOTE
La interfaz de red que seleccione no puede tener habilitadas las redes aceleradas, no puede tener asignada una
dirección IPv6 y debe existir en la misma red virtual que la que tiene la interfaz de red actualmente asociada a la
VM.

Si no tiene una interfaz de red existente, debe crear una. Para ello, seleccione Crear interfaz de red . Para
aprender más sobre cómo crear una interfaz de red, consulte Crear una interfaz de red. Para más
información sobre las restricciones adicionales cuando se agregan interfaces de red a las máquinas
virtuales, consulte Restricciones.
5. En la barra de menús de la VM, elija Información general > Iniciar para reiniciar la máquina virtual.
Ahora puede configurar el sistema operativo de la VM para usar varias interfaces de red correctamente. Aprenda
cómo configurar Linux o Windows para varias interfaces de red.
Comandos:
H ERRA M IEN TA GET - H EL P

CLI az vm nic add (referencia); pasos detallados

PowerShell Add-AzVMNetworkInterface (referencia); pasos detallados

Visualización de las interfaces de red de una máquina virtual

Puede ver las interfaces de red asociadas actualmente a una máquina virtual para conocer su configuración y sus
direcciones IP asignadas.
1. Vaya a Azure Portal para buscar una máquina virtual existente. Busque y seleccione Máquinas vir tuales .

NOTE
Inicie sesión con una cuenta que tenga asignado el rol de propietario, colaborador o colaborador de red para la
suscripción. Para más información sobre la asignación de roles a las cuentas, consulte Roles integrados para el
control de acceso basado en roles de Azure.

2. Seleccione el nombre de la VM cuyas interfaces de red asociadas desea ver.

3. En la barra de menús de la VM, seleccione Redes .
Para información sobre la configuración de la interfaz de red y cómo modificarla, consulte Administración de
interfaces de red. Para saber cómo agregar, cambiar o quitar direcciones IP asignadas a una interfaz de red,
consulte Administración de direcciones IP de interfaz de red.
Comandos:
H ERRA M IEN TA GET - H EL P

CLI az vm nic list

PowerShell Get-AzVM

Eliminación de una interfaz de red de una máquina virtual

1. Vaya a Azure Portal para buscar una máquina virtual existente. Busque y seleccione Máquinas vir tuales .
2. Seleccione el nombre de la VM cuyas interfaces de red asociadas desea ver.
3. En la barra de herramientas de la VM, seleccione Detener .
4. Espere a que el estado de la máquina virtual cambie a Detenida (desasignada) .
5. En la barra de menús de la VM, seleccione Redes > Desasociar interfaz de red .
6. En el cuadro de diálogo Desasociar interfaz de red , seleccione la interfaz de red que desea desasociar.
Después, seleccione Aceptar .

NOTE
Si solo se muestra una interfaz de red, no puede desasociarla porque una máquina virtual siempre debe tener al
menos una interfaz de red asociada.

Comandos:
H ERRA M IEN TA GET - H EL P

CLI az vm nic remove (referencia); pasos detallados

PowerShell Remove-AzVMNetworkInterface (referencia); pasos detallados

Restricciones
Una VM debe tener al menos una interfaz de red asociada.
Una VM solo puede tener tantas interfaces de red asociadas como admita el tamaño de la VM. Para
averiguar cuántas interfaces de red admite cada tamaño de VM, consulte los tamaños de Azure para VM
Linux o VM Windows. Todos los tamaños admiten al menos dos interfaces de red.
Actualmente, las interfaces de red que se agregan a una VM no se pueden asociar a otra. Para más
información sobre cómo crear interfaces de red, consulte Crear una interfaz de red.
Anteriormente, solo se podían agregar interfaces de red a las VM que admitían varias interfaces de red y
que se habían creado con al menos dos. No se podía agregar una interfaz de red a una VM que se hubiera
creado con una interfaz de red, aunque el tamaño de la VM admitiera más de una interfaz de red. Y a la
inversa, solo se podían quitar interfaces de red de una máquina virtual que tuviera al menos tres, ya que
las máquinas virtuales creadas con al menos dos interfaces de red siempre debían tener al menos dos.
Estas restricciones ya no se aplican. Ahora puede crear una máquina virtual con cualquier cantidad de
interfaces de red (hasta el máximo que permita el tamaño de la máquina virtual).
De manera predeterminada, la primera interfaz de red asociada a una VM es la interfaz de red principal.
Todas las demás interfaces de red de la máquina virtual son interfaces de red secundarias.
Puede controlar a qué interfaz de red se envía el tráfico de salida. Sin embargo, una VM envía todo el
tráfico de salida a la dirección IP asignada a la configuración de IP principal de la interfaz de red principal
de forma predeterminada.
En el pasado, era un requisito que todas las máquinas virtuales situadas en el mismo conjunto de
disponibilidad debían tener una o varias interfaces de red. Ahora puede haber máquinas virtuales con
cualquier cantidad de interfaces de red en el mismo conjunto de disponibilidad, hasta el máximo que
permita su tamaño. Solo se pueden agregar máquinas virtuales a un conjunto de disponibilidad cuando
se crean. Para más información sobre los conjuntos de disponibilidad, consulte Administración de la
disponibilidad de las máquinas virtuales en Azure.
Puede conectar interfaces de red de la misma VM a diferentes subredes de una red virtual. Sin embargo,
todas las interfaces de red deben estar conectadas a la misma red virtual.
Puede agregar cualquier dirección IP para cualquier configuración de IP de cualquier interfaz de red
principal o secundaria a un grupo de servidores back-end de Azure Load Balancer. En el pasado, solo la
dirección IP principal de la interfaz de red principal podía agregarse a un grupo de servidores back-end.
Para más información sobre las direcciones IP y las configuraciones, consulte incorporación, cambio o
eliminación de direcciones IP.
Al eliminar una VM, no se eliminan las interfaces de red que tiene asociadas. Cuando se elimina una
máquina virtual, las interfaces de red se desasocian de ella. Puede agregar esas interfaces de red a
diferentes VM o eliminarlas.
La obtención de un rendimiento óptimo documentado requiere redes aceleradas. En algunos casos, debe
habilitar explícitamente las redes aceleradas para máquinas virtuales Windows o Linux.

Pasos siguientes
Para crear una VM con varias interfaces de red o direcciones IP, consulte:

TA REA H ERRA M IEN TA

Creación de una máquina virtual con varias NIC CLI, PowerShell

TA REA H ERRA M IEN TA

Creación de una máquina virtual con una sola interfaz de red CLI, PowerShell
y varias direcciones IPv4

Creación de una máquina virtual con una sola interfaz de red CLI, PowerShell, Plantilla de Azure Resource Manager
y una dirección IPv6 privada (detrás de Azure Load Balancer)
 Crear y administrar una máquina virtual con
Windows que tiene varias NIC
23/09/2020 • 15 minutes to read • Edit Online

En Azure, las máquinas virtuales (VM) pueden tener varias tarjetas de interfaz de red virtual (NIC) conectadas
a ellas. Un escenario común es tener distintas subredes para la conectividad front-end y back-end. Puede
asociar varias NIC de una máquina virtual a varias subredes, pero esas subredes deben residir en la misma
red virtual (vNet). En este artículo se describe cómo crear una máquina virtual con varias NIC conectadas.
También obtendrá información sobre cómo agregar o quitar NIC de una máquina virtual existente. Diferentes
tamaños de máquina virtual admiten un número distinto de NIC, así que ajuste el tamaño de su máquina
virtual teniendo esto en cuenta.

Requisitos previos
En los ejemplos siguientes, reemplace los nombres de parámetros de ejemplo por los suyos propios. Los
nombres de parámetro de ejemplo incluyen myResourceGroup, myVnet y myVM.

Creación de una máquina virtual con varias NIC

En primer lugar, cree un grupo de recursos. En el ejemplo siguiente se crea un grupo de recursos
denominado myResourceGroup en la ubicación EastUs:

New-AzResourceGroup -Name "myResourceGroup" -Location "EastUS"

Creación de redes virtuales y subredes

Un escenario común es que una red virtual tenga dos o más subredes. Una subred puede ser para el tráfico
de front-end y la otra para el tráfico de back-end. Para conectarse a las dos subredes, se usan varias NIC en la
máquina virtual.
1. Defina dos subredes de red virtual con New-AzVirtualNetworkSubnetConfig. En el ejemplo siguiente
se definen dos subredes para mySubnetFrontEnd y mySubnetBackEnd:

$mySubnetFrontEnd = New-AzVirtualNetworkSubnetConfig -Name "mySubnetFrontEnd" `

-AddressPrefix "[Link]/24"
$mySubnetBackEnd = New-AzVirtualNetworkSubnetConfig -Name "mySubnetBackEnd" `
-AddressPrefix "[Link]/24"

2. Cree la red virtual y las subredes con New-AzVirtualNetwork. En el ejemplo siguiente se crea una red
virtual denominada myVnet:

$myVnet = New-AzVirtualNetwork -ResourceGroupName "myResourceGroup" `

-Location "EastUs" `
-Name "myVnet" `
-AddressPrefix "[Link]/16" `
-Subnet $mySubnetFrontEnd,$mySubnetBackEnd

Creación de varias NIC

Cree dos NIC con New-AzNetworkInterface. Conecte una NIC a la subred de front-end y la otra a la subred de
back-end. En el ejemplo siguiente se crean las NIC denominadas myNic1 y myNic2:

$frontEnd = $[Link]|?{$_.Name -eq 'mySubnetFrontEnd'}

$myNic1 = New-AzNetworkInterface -ResourceGroupName "myResourceGroup" `
-Name "myNic1" `
-Location "EastUs" `
-SubnetId $[Link]

$backEnd = $[Link]|?{$_.Name -eq 'mySubnetBackEnd'}

$myNic2 = New-AzNetworkInterface -ResourceGroupName "myResourceGroup" `
-Name "myNic2" `
-Location "EastUs" `
-SubnetId $[Link]

Normalmente también crea un grupo de seguridad de red para filtrar el tráfico de red a la máquina virtual y
un equilibrador de carga para distribuir el tráfico entre varias máquinas virtuales.
Creación de la máquina virtual
Comience ahora a compilar la configuración de la máquina virtual. El tamaño de cada máquina virtual tiene
un límite en cuanto al número total de NIC que se pueden agregar a una máquina virtual. Para más
información, vea Tamaños de las máquinas virtuales con Windows.
1. Establezca las credenciales de la máquina virtual en la variable $cred como se indica a continuación:

$cred = Get-Credential

2. Defina la VM con New-AzVMConfig. En el ejemplo siguiente se define una máquina virtual

denominada myVM y se usa un tamaño de máquina virtual que admite hasta dos NIC
(Standard_DS3_v2):

$vmConfig = New-AzVMConfig -VMName "myVM" -VMSize "Standard_DS3_v2"

3. Cree el resto de la configuración de VM con Set-AzVMOperatingSystem y Set-AzVMSourceImage. En

el ejemplo siguiente se crea una máquina virtual con Windows Server 2016:

$vmConfig = Set-AzVMOperatingSystem -VM $vmConfig `

-Windows `
-ComputerName "myVM" `
-Credential $cred `
-ProvisionVMAgent `
-EnableAutoUpdate
$vmConfig = Set-AzVMSourceImage -VM $vmConfig `
-PublisherName "MicrosoftWindowsServer" `
-Offer "WindowsServer" `
-Skus "2016-Datacenter" `
-Version "latest"

4. Conecte las dos NIC que creó anteriormente con Add-AzVMNetworkInterface:

$vmConfig = Add-AzVMNetworkInterface -VM $vmConfig -Id $[Link] -Primary

$vmConfig = Add-AzVMNetworkInterface -VM $vmConfig -Id $[Link]

5. Cree la VM con New-AzVM:

New-AzVM -VM $vmConfig -ResourceGroupName "myResourceGroup" -Location "EastUs"

6. Agregue rutas de tarjetas NIC secundarias al sistema operativo mediante los pasos que se indican en
Configuración del sistema operativo invitado para varias NIC.

Adición de una NIC a una máquina virtual existente

Para agregar una NIC virtual a una máquina virtual existente, se desasigna la máquina virtual, se agrega la
NIC virtual y, después, se inicia la máquina virtual. Diferentes tamaños de máquina virtual admiten un
número distinto de NIC, así que ajuste el tamaño de su máquina virtual teniendo esto en cuenta. Si es
necesario, puede cambiar el tamaño de una máquina virtual.
1. Desasigne la VM con Stop-AzVM. En el ejemplo siguiente se desasigna la máquina virtual denominada
myVM en myResourceGroup:

Stop-AzVM -Name "myVM" -ResourceGroupName "myResourceGroup"

2. Obtenga la configuración existente de la VM con Get-AzVm. En el ejemplo siguiente se obtiene

información de la máquina virtual denominada myVM en myResourceGroup:

$vm = Get-AzVm -Name "myVM" -ResourceGroupName "myResourceGroup"

3. En el ejemplo siguiente se crea una NIC virtual con New-AzNetworkInterface denominada myNic3 que
está conectada a mySubnetBackEnd. Después, la NIC virtual se conecta a la VM denominada myVM en
myResourceGroup con Add-AzVMNetworkInterface:

# Get info for the back end subnet

$myVnet = Get-AzVirtualNetwork -Name "myVnet" -ResourceGroupName "myResourceGroup"
$backEnd = $[Link]|?{$_.Name -eq 'mySubnetBackEnd'}

# Create a virtual NIC

$myNic3 = New-AzNetworkInterface -ResourceGroupName "myResourceGroup" `
-Name "myNic3" `
-Location "EastUs" `
-SubnetId $[Link]

# Get the ID of the new virtual NIC and add to VM

$nicId = (Get-AzNetworkInterface -ResourceGroupName "myResourceGroup" -Name "MyNic3").Id
Add-AzVMNetworkInterface -VM $vm -Id $nicId | Update-AzVm -ResourceGroupName "myResourceGroup"

NIC virtuales principales

En una máquina virtual de varias NIC una de las NIC debe ser la principal. Si una de las NIC virtuales
existentes en la máquina virtual ya se ha establecido como principal, puede omitir este paso. En el
siguiente ejemplo se da por supuesto que hay dos NIC virtuales en una máquina virtual y que se va a
agregar la primera NIC ( [0] ) como la principal:

# List existing NICs on the VM and find which one is primary

$[Link]

# Set NIC 0 to be primary

$[Link][0].Primary = $true
$[Link][1].Primary = $false

# Update the VM state in Azure

Update-AzVM -VM $vm -ResourceGroupName "myResourceGroup"

4. Inicie la VM con Start-AzVm:

 Start-AzVM -ResourceGroupName "myResourceGroup" -Name "myVM"

5. Agregue rutas de tarjetas NIC secundarias al sistema operativo mediante los pasos que se indican en
Configuración del sistema operativo invitado para varias NIC.

Eliminación de una NIC de una máquina virtual existente

Para quitar una NIC virtual de una máquina virtual existente, se desasigna la máquina virtual, se quita la NIC
virtual y, después, se inicia la máquina virtual.
1. Desasigne la VM con Stop-AzVM. En el ejemplo siguiente se desasigna la máquina virtual denominada
myVM en myResourceGroup:

Stop-AzVM -Name "myVM" -ResourceGroupName "myResourceGroup"

2. Obtenga la configuración existente de la VM con Get-AzVm. En el ejemplo siguiente se obtiene

información de la máquina virtual denominada myVM en myResourceGroup:

$vm = Get-AzVm -Name "myVM" -ResourceGroupName "myResourceGroup"

3. Obtenga información sobre la eliminación de NIC con Get-AzNetworkInterface. En el ejemplo siguiente

se obtiene información sobre myNic3:

# List existing NICs on the VM if you need to determine NIC name

$[Link]

$nicId = (Get-AzNetworkInterface -ResourceGroupName "myResourceGroup" -Name "myNic3").Id

4. Quite la NIC con Remove-AzVMNetworkInterface y, después, actualice la VM con Update-AzVm. En el

ejemplo siguiente se quita myNic3 obtenida por $nicId en el paso anterior:

Remove-AzVMNetworkInterface -VM $vm -NetworkInterfaceIDs $nicId | `

Update-AzVm -ResourceGroupName "myResourceGroup"

5. Inicie la VM con Start-AzVm:

Start-AzVM -Name "myVM" -ResourceGroupName "myResourceGroup"

Crear varias NIC con plantillas

Las plantillas de Azure Resource Manager ofrecen una manera de crear varias instancias de un recurso
durante la implementación; por ejemplo, se pueden crear varias NIC. Las plantillas de Resource Manager
usan archivos JSON declarativos para definir el entorno. Para más información, vea Información general de
Azure Resource Manager. Puede usar copy para especificar el número de instancias que se crearán:

"copy": {
"name": "multiplenics",
"count": "[parameters('count')]"
}

Para más información, vea Creación de varias instancias mediante copy.

También puede usar copyIndex() para anexar un número a un nombre de recurso. Después, puede crear
myNic1, MyNic2 y así sucesivamente. En el código siguiente se muestra un ejemplo de cómo anexar el valor
de índice:

"name": "[concat('myNic', copyIndex())]",

Puede leer un ejemplo completo de cómo crear varias NIC mediante plantillas de Resource Manager.
Agregue rutas de tarjetas NIC secundarias al sistema operativo mediante los pasos que se indican en
Configuración del sistema operativo invitado para varias NIC.

Configuración del sistema operativo invitado para varias NIC

Azure asigna una puerta de enlace predeterminada a la primera interfaz de red (principal) conectada a la
máquina virtual. Azure no asigna una puerta de enlace predeterminada a las interfaces de red adicionales
(secundarias) conectadas a una máquina virtual. Por lo tanto, de manera predeterminada, no es posible
comunicarse con recursos externos a la subred en la que se encuentra una interfaz de red secundaria. Sin
embargo, las interfaces de red secundarias pueden comunicarse con recursos externos a su subred, aunque
los pasos necesarios para habilitar la comunicación son diferentes para los distintos sistemas operativos.
1. Desde un símbolo del sistema de Windows, ejecute el comando route print . Este comando devuelve
una salida similar a la siguiente para una máquina virtual con dos interfaces de red conectadas:

===========================================================================
Interface List
3...00 0d 3a 10 92 ce ......Microsoft Hyper-V Network Adapter #3
7...00 0d 3a 10 9b 2a ......Microsoft Hyper-V Network Adapter #4
===========================================================================

En este ejemplo, Microsoft Hyper-V Network Adapter #4 (interfaz 7) es la interfaz de red

secundaria que no tiene una puerta de enlace predeterminada asignada.
2. Desde un símbolo del sistema, ejecute el comando ipconfig para ver la dirección IP asignada a la
interfaz de red secundaria. En este ejemplo, la dirección IP [Link] está asignada a la interfaz 7. No
se devuelve ninguna dirección de puerta de enlace predeterminada para la interfaz de red secundaria.
3. Para que todo el tráfico destinado a direcciones que están fuera de la subred de la interfaz de red
secundaria se enrute a la puerta de enlace de la subred, ejecute el siguiente comando:

route add -p [Link] MASK [Link] [Link] METRIC 5015 IF 7

La dirección de la puerta de enlace para la subred es la primera dirección IP (terminada en .1) del
intervalo de direcciones definido para la subred. Si no quiere enrutar todo el tráfico fuera de la subred,
puede agregar rutas individuales a destinos específicos en su lugar. Por ejemplo, si solo quiere enrutar
el tráfico de la interfaz de red secundaria a la red [Link], escriba el comando:

route add -p [Link] MASK [Link] [Link] METRIC 5015 IF 7

4. Para confirmar la comunicación correcta con un recurso en la red [Link], por ejemplo, escriba el
siguiente comando para hacer ping a [Link] mediante la interfaz 7 ([Link]):

ping [Link] -S [Link]

 Puede que necesite abrir ICMP a través del firewall de Windows del dispositivo en el que está
haciendo ping con el siguiente comando:

netsh advfirewall firewall add rule name=Allow-ping protocol=icmpv4 dir=in action=allow

5. Para confirmar que la ruta agregada está en la tabla de rutas, escriba el comando route print , que
devuelve una salida similar al texto siguiente:

===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
[Link] [Link] [Link] [Link] 15
[Link] [Link] [Link] [Link] 5015

La ruta que se muestra con [Link] debajo de Puer ta de enlace es la ruta que aparece de
manera predeterminada para la interfaz de red principal. La ruta con [Link] debajo de Puer ta de
enlace es la ruta agregada.

Pasos siguientes
Revise Tamaños de máquina virtual con Windows cuando esté intentando crear una máquina virtual que
tiene varias NIC. Preste atención al número máximo de NIC que admite cada tamaño de máquina virtual.
 Cómo crear una máquina virtual Linux en Azure
con red varias tarjetas de interfaz de red
23/09/2020 • 12 minutes to read • Edit Online

En este artículo se describe cómo crear una máquina virtual con varias NIC con la CLI de Azure.

Creación de recursos de apoyo

Instale la última versión de la CLI de Azure e inicie sesión en una cuenta de Azure con az login.
En los ejemplos siguientes, reemplace los nombres de parámetros de ejemplo por los suyos propios. Los
nombres de parámetro de ejemplo incluyen myResourceGroup, mystorageaccount y myVM.
En primer lugar, cree un grupo de recursos con az group create. En el ejemplo siguiente, se crea un grupo de
recursos denominado myResourceGroup en la ubicación eastus:

az group create --name myResourceGroup --location eastus

Cree la red virtual con az network vnet create. En el ejemplo siguiente se crea una red virtual denominada
myVnet y una subred mySubnetFrontEnd:

az network vnet create \

--resource-group myResourceGroup \
--name myVnet \
--address-prefix [Link]/16 \
--subnet-name mySubnetFrontEnd \
--subnet-prefix [Link]/24

Cree una subred para el tráfico de back-end con az network vnet subnet create. En el ejemplo siguiente se crea
una subred denominada mySubnetBackEnd:

az network vnet subnet create \

--resource-group myResourceGroup \
--vnet-name myVnet \
--name mySubnetBackEnd \
--address-prefix [Link]/24

Cree un grupo de seguridad de red con az network nsg create. En el ejemplo siguiente se crea un grupo de
seguridad de red denominado myNetworkSecurityGroup:

az network nsg create \

--resource-group myResourceGroup \
--name myNetworkSecurityGroup

Creación y configuración de varias NIC

Creación de dos NIC con az network nic create. En el ejemplo siguiente se crean dos NIC, denominadas myNic1
y myNic2, conectadas al grupo de seguridad de red, con una NIC conectada con cada subred:
 az network nic create \
--resource-group myResourceGroup \
--name myNic1 \
--vnet-name myVnet \
--subnet mySubnetFrontEnd \
--network-security-group myNetworkSecurityGroup
az network nic create \
--resource-group myResourceGroup \
--name myNic2 \
--vnet-name myVnet \
--subnet mySubnetBackEnd \
--network-security-group myNetworkSecurityGroup

Creación de una máquina virtual y conexión de las NIC

Cuando cree la máquina virtual, especifique las NIC creadas con --nics . También debe tener cuidado al
seleccionar el tamaño de la máquina virtual. Existen límites para el número total de NIC que se pueden agregar
a una máquina virtual. Más información sobre los tamaños de máquina virtual Linux.
Cree la máquina virtual con az vm create. En el ejemplo siguiente se crea una máquina virtual denominada
myVM:

az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--size Standard_DS3_v2 \
--admin-username azureuser \
--generate-ssh-keys \
--nics myNic1 myNic2

Agregue tablas de enrutamiento al sistema operativo invitado completando los pasos descritos en Cómo crear
una máquina virtual Linux en Azure con red varias tarjetas de interfaz de red.

Adición de una NIC a una máquina virtual

Los pasos anteriores crean una máquina virtual con varias NIC. También puede agregar varias NIC a una
máquina virtual existente con la CLI de Azure. Diferentes tamaños de máquina virtual admiten un número
distinto de NIC, así que ajuste el tamaño de su máquina virtual teniendo esto en cuenta. Si es necesario, puede
cambiar el tamaño de una máquina virtual.
Cree otra NIC con az network nic create. En el ejemplo siguiente se crea una NIC denominada myNic3
conectada a la subred de back-end y al grupo de seguridad de red creado en los pasos anteriores:

az network nic create \

--resource-group myResourceGroup \
--name myNic3 \
--vnet-name myVnet \
--subnet mySubnetBackEnd \
--network-security-group myNetworkSecurityGroup

Para agregar una NIC a una máquina virtual existente, en primer lugar desasigne la máquina virtual con az vm
deallocate. En el ejemplo siguiente se desasigna la máquina virtual denominada myVM:

az vm deallocate --resource-group myResourceGroup --name myVM

Agregue la NIC con az vm nic add. En el ejemplo siguiente se agrega myNic3 a myVM:

az vm nic add \
--resource-group myResourceGroup \
--vm-name myVM \
--nics myNic3

Inicie la máquina virtual con az vm start:

az vm start --resource-group myResourceGroup --name myVM

Agregue tablas de enrutamiento al sistema operativo invitado completando los pasos descritos en Cómo crear
una máquina virtual Linux en Azure con red varias tarjetas de interfaz de red.

Eliminación de una NIC de una máquina virtual

Para quitar una NIC de una máquina virtual existente, en primer lugar desasigne la máquina virtual con az vm
deallocate. En el ejemplo siguiente se desasigna la máquina virtual denominada myVM:

az vm deallocate --resource-group myResourceGroup --name myVM

Quite la NIC con az vm nic remove. En el ejemplo siguiente se quita myNic3 de myVM:

az vm nic remove \
--resource-group myResourceGroup \
--vm-name myVM \
--nics myNic3

Inicie la máquina virtual con az vm start:

az vm start --resource-group myResourceGroup --name myVM

Creación de varias NIC con plantillas de Resource Manager

Las plantillas de Azure Resource Manager emplean archivos JSON declarativos para definir el entorno. Puede
leer la introducción a Azure Resource Manager. Las plantillas de Resource Manager ofrecen una manera de
crear varias instancias de un recurso durante la implementación; por ejemplo, se pueden crear varias NIC.
Utilizará el comando copy para especificar el número de instancias que se crearán:

"copy": {
"name": "multiplenics"
"count": "[parameters('count')]"
}

Más información sobre la creación de varias instancias mediante copia.

También puede utilizar copyIndex() para anexar un número a un nombre de recurso, lo que le permite crear
myNic1 , myNic2 , etc. A continuación se muestra un ejemplo de cómo anexar el valor de índice:

"name": "[concat('myNic', copyIndex())]",

Puede leer un ejemplo completo de cómo crear varias NIC con plantillas de Resource Manager.
Agregue tablas de enrutamiento al sistema operativo invitado completando los pasos descritos en Cómo crear
una máquina virtual Linux en Azure con red varias tarjetas de interfaz de red.

Configuración del sistema operativo invitado para varias NIC

En los pasos anteriores se creó una red virtual y una subred, se conectaron las NIC y luego se creó una
máquina virtual. No se creó ninguna regla de grupos de seguridad de red ni ninguna dirección IP pública que
permitieran el tráfico SSH. Para configurar al sistema operativo invitado para varias NIC, tiene que permitir
conexiones remotas y ejecutar comandos localmente en la máquina virtual.
Para permitir el tráfico SSH, cree una regla de grupo de seguridad de red con az network nsg rule create de la
manera siguiente:

az network nsg rule create \

--resource-group myResourceGroup \
--nsg-name myNetworkSecurityGroup \
--name allow_ssh \
--priority 101 \
--destination-port-ranges 22

Cree una dirección IP pública con az network public-ip create y asígnela a la primera NIC con az network nic ip-
config update:

az network public-ip create --resource-group myResourceGroup --name myPublicIP

az network nic ip-config update \

--resource-group myResourceGroup \
--nic-name myNic1 \
--name ipconfig1 \
--public-ip myPublicIP

Para ver la dirección IP pública de la máquina virtual, use az vm show de la manera siguiente:

az vm show --resource-group myResourceGroup --name myVM -d --query publicIps -o tsv

Conéctese ahora por SSH a la dirección IP pública de la máquina virtual. El nombre de usuario predeterminado
indicado en el paso anterior era azureuser. Indique su propio nombre de usuario y la dirección IP pública:

ssh azureuser@[Link]

Para enviar hacia o desde una interfaz de red secundaria, tiene que agregar manualmente rutas persistentes al
sistema operativo para cada interfaz de red secundaria. En este artículo, eth1 es la interfaz secundaria. Las
instrucciones para agregar rutas persistentes al sistema operativo varían según la distribución. Vea la
documentación correspondiente a su distribución para obtener instrucciones.
Al agregar una ruta al sistema operativo, la dirección de puerta de enlace es .1 para la subred en la que se
encuentre la interfaz de red. Por ejemplo, si a la interfaz de red se le asigna la dirección [Link], la puerta de
enlace que se especifica para la ruta es [Link]. Si quiere que todo el tráfico de la interfaz pase por la puerta de
enlace especificada, puede definir una red concreta para el destino de la ruta o especificar un destino de [Link].
La puerta de enlace para cada subred se administra mediante la red virtual.
Cuando haya agregado la ruta para una interfaz secundaria, compruebe que la ruta se encuentra en la tabla de
rutas con route -n . La siguiente salida de ejemplo corresponde a la tabla de rutas en la que se han agregado
las dos interfaces de red para la máquina virtual en este artículo:

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface
[Link] [Link] [Link] UG 0 0 0 eth0
[Link] [Link] [Link] UG 0 0 0 eth1
[Link] [Link] [Link] U 0 0 0 eth0
[Link] [Link] [Link] U 0 0 0 eth1
[Link] [Link] [Link] UGH 0 0 0 eth0
[Link] [Link] [Link] UGH 0 0 0 eth0

Confirme que la ruta agregada se conserva entre un reinicio y el siguiente comprobando de nuevo la tabla de
rutas tras un reinicio. Para probar la conectividad, puede escribir el siguiente comando, por ejemplo, donde
eth1 es el nombre de una interfaz de red secundaria:

ping [Link] -c 4 -I eth1

Pasos siguientes
Revise los tamaños de máquina virtual Linux al intentar crear una máquina virtual con varias NIC. Preste
atención al número máximo de NIC que admite cada tamaño de máquina virtual.
Para proteger más las máquinas virtuales, use acceso Just-In-Time a la máquina virtual. Esta característica abre
reglas del grupo de seguridad de red al tráfico SSH cuando es necesario y durante un período de tiempo
definido. Para más información, consulte Administrar el acceso a máquina virtual mediante Just-In-Time.
 Crear una VM Windows con redes aceleradas
mediante Azure PowerShell
23/09/2020 • 21 minutes to read • Edit Online

En este tutorial, aprenderá a crear una máquina virtual (VM) Windows con redes aceleradas.

NOTE
Para usar redes aceleradas con una máquina virtual Linux, consulte Creación de una máquina virtual Linux con redes
aceleradas.

Accelerated Networking habilita la virtualización de E/S de raíz única (SR-IOV) en una máquina virtual (VM), lo
que mejora significativamente su rendimiento en la red. Este método de alto rendimiento omite el host de la ruta
de acceso de datos, lo que reduce la latencia, la inestabilidad y el uso de la CPU para las cargas de trabajo de red
más exigentes en los tipos de VM admitidos. En el diagrama siguiente, se muestra la comunicación entre dos VM
con y sin redes aceleradas:

Sin Accelerated Networking, todo el tráfico de red de entrada y salida de la máquina virtual tiene que atravesar el
host y el conmutador virtual. El conmutador virtual se encarga de toda la aplicación de directivas, como grupos
de seguridad de red, listas de control de acceso, aislamiento y otros servicios virtualizados de red, al tráfico de
red.

NOTE
Para obtener más información acerca de los conmutadores virtuales, consulte Conmutador virtual de Hyper-V.

Con redes aceleradas, el tráfico de red llega a la interfaz de red (NIC) de la VM y se reenvía después a la VM.
Todas las directivas de red que el conmutador virtual aplica se descargan y aplican en el hardware. Dado que la
directiva se aplica al hardware, la NIC puede reenviar el tráfico de red directamente a la VM. La NIC omite el host
y el conmutador virtual, y mantiene toda la directiva que aplicó en el host.
Las ventajas de las redes aceleradas solo se aplican a la VM en que estén habilitadas. Para obtener resultados
óptimos, habilite esta característica en al menos dos VM conectadas a la misma red virtual de Azure. Al
comunicarse entre redes virtuales o conectarse de forma local, esta característica tiene un efecto mínimo sobre la
latencia general.

Ventajas
Menor latencia / más paquetes por segundo (pps) : Al eliminar el conmutador virtual de la ruta de
acceso de datos, se quita el tiempo que los paquetes pasan en el host para el procesamiento de directivas.
También aumenta el número de paquetes que se pueden procesar dentro de la VM.
Inestabilidad reducida : El procesamiento de conmutadores virtuales depende de la cantidad de directiva
que se deba aplicar. También depende de la carga de trabajo de la CPU que realiza el procesamiento. La
descarga de la aplicación de directivas en el hardware elimina esa variabilidad mediante la entrega de
paquetes directamente a la VM. La descarga también quita la comunicación entre el host y la VM, todas las
interrupciones de software y todos los cambios de contexto.
Disminución de la utilización de la CPU : el pasar por alto el conmutador virtual en el host conlleva
una disminución de la utilización de la CPU para procesar el tráfico de red.

Sistemas operativos admitidos

Se admiten las siguientes distribuciones de fábrica desde la galería de Azure:
Windows Ser ver 2019 Datacenter
Windows Ser ver 2016 Datacenter
Windows Ser ver 2012 R2 Datacenter

Limitaciones y restricciones
Instancias de máquina virtual admitidas
Las redes aceleradas son compatibles con la mayoría de los tamaños de instancia de uso general y optimizados
para procesos con dos o más CPU virtuales (vCPU). Estas series admitidas son: Dv2/DSv2 y F/Fs.
En instancias que admiten hyperthreading, las redes aceleradas se admiten en instancias de VM con cuatro o más
vCPU. Las series admitidas son: D/Dsv3, D/Dsv4, Da/Dasv4, E/Esv3, Ea/Easv4, Fsv2, Lsv2, Ms/Mms y Ms/Mmsv2.
Para obtener más información sobre instancias de VM, consulte Tamaños de las máquinas virtuales Windows en
Azure.
Imágenes personalizadas
Si usa una imagen personalizada compatible con redes aceleradas, asegúrese de que dispone de los
controladores necesarios para trabajar con las NIC ConnectX-3 y ConnectX-4 Lx de Mellanox en Azure.
Regions
Las redes aceleradas están disponibles en todas las regiones globales de Azure y la nube de Azure Government.
Habilitación de redes aceleradas en una VM en ejecución
Un tamaño de VM admitido sin redes aceleradas habilitadas solo puede tener la característica habilitada cuando
se detiene y desasigna.
Implementación mediante Azure Resource Manager
Las máquinas virtuales (clásicas) no se pueden implementar con redes aceleradas.

Creación de VM desde el portal

Aunque en este artículo se explica cómo crear una VM con redes aceleradas mediante Azure PowerShell, también
puede usar Azure Portal para crear una máquina virtual que habilite las redes aceleradas. Al crear una VM en el
portal, en la página Crear una máquina vir tual , seleccione la pestaña Redes . En esta pestaña hay una opción
para Redes aceleradas . Si ha seleccionado un sistema operativo compatible y un tamaño de VM, esta opción se
define automáticamente como Activadas . De lo contrario, la opción se establece en Desactivadas y Azure
muestra el motivo por el que no se pueden habilitar.

NOTE
Solo los sistemas operativos compatibles se pueden habilitar a través del portal. Si usa una imagen personalizada y esta es
compatible con las redes aceleradas, cree la VM mediante la CLI o PowerShell.

Después de crear la VM, puede confirmar si las redes aceleradas están habilitadas. Siga estas instrucciones:
1. Vaya a Azure Portal para administrar sus máquinas virtuales. Busque y seleccione Máquinas vir tuales .
2. En la lista de máquinas virtuales, elija la nueva VM.
3. En la barra de menús de la máquina virtual, elija Redes .
En la información de la interfaz de red, junto a la etiqueta Redes aceleradas , el portal muestra Deshabilitadas
o Habilitadas como estado.

Creación de VM mediante PowerShell

Antes de continuar, instale Azure PowerShell versión 1.0.0 o posterior. Para encontrar la versión instalada
actualmente, ejecute Get-Module -ListAvailable Az . Si necesita instalar o actualizar, instale la versión más reciente
del módulo Az desde la Galería de PowerShell. En una sesión de PowerShell, inicie sesión en una cuenta de Azure
con Connect-AzAccount.
En los ejemplos siguientes, reemplace los nombres de parámetros de ejemplo por los suyos propios. Los
nombres de parámetro de ejemplo incluían myResourceGroup, myNic y myVM.
Creación de una red virtual
1. Cree un grupo de recursos con New-AzResourceGroup. Con el comando siguiente, se crea un grupo de
recursos denominado myResourceGroup en la ubicación centralus:

New-AzResourceGroup -Name "myResourceGroup" -Location "centralus"

2. Cree una configuración de subred con New-AzVirtualNetworkSubnetConfig. Con el comando siguiente se

crea una subred denominada mySubnet:

$subnet = New-AzVirtualNetworkSubnetConfig `
-Name "mySubnet" `
-AddressPrefix "[Link]/24"

3. Cree una red virtual con New-AzVirtualNetwork, con la subred mySubnet.

$vnet = New-AzVirtualNetwork -ResourceGroupName "myResourceGroup" `

-Location "centralus" `
-Name "myVnet" `
-AddressPrefix "[Link]/16" `
-Subnet $Subnet

Crear un grupo de seguridad de red

1. Cree una regla de grupo de seguridad de red con New-AzNetworkSecurityRuleConfig.
 $rdp = New-AzNetworkSecurityRuleConfig `
-Name 'Allow-RDP-All' `
-Description 'Allow RDP' `
-Access Allow `
-Protocol Tcp `
-Direction Inbound `
-Priority 100 `
-SourceAddressPrefix * `
-SourcePortRange * `
-DestinationAddressPrefix * `
-DestinationPortRange 3389

2. Cree un grupo de seguridad de red con New-AzNetworkSecurityGroup y asígnele la regla de seguridad

Allow-RDP-All. Aparte de la regla Allow-RDP-All, el grupo de seguridad de red contiene varias reglas
predeterminadas. Una regla predeterminada deshabilita todo el acceso entrante desde Internet. Una vez
creada, la regla Allow-RDP-All se asigna al grupo de seguridad de red para que pueda conectarse de forma
remota a la VM.

$nsg = New-AzNetworkSecurityGroup `
-ResourceGroupName myResourceGroup `
-Location centralus `
-Name "myNsg" `
-SecurityRules $rdp

3. Asocie el grupo de seguridad de red a la subred mySubnet con Set-AzVirtualNetworkSubnetConfig. La

regla en el grupo de seguridad de red es eficaz para todos los recursos implementados en la subred.

Set-AzVirtualNetworkSubnetConfig `
-VirtualNetwork $vnet `
-Name 'mySubnet' `
-AddressPrefix "[Link]/24" `
-NetworkSecurityGroup $nsg

Creación de una interfaz de red con Accelerated Networking

1. Cree una dirección IP pública con New-AzPublicIpAddress. Una dirección IP pública es innecesaria si no
tiene previsto acceder a la VM desde Internet. Sin embargo, se necesita para completar los pasos de este
artículo.

$publicIp = New-AzPublicIpAddress `
-ResourceGroupName myResourceGroup `
-Name 'myPublicIp' `
-location centralus `
-AllocationMethod Dynamic

2. Cree una interfaz de red con New-AzNetworkInterface con la redes aceleradas habilitadas y asígnele la
dirección IP pública. En el ejemplo siguiente se crea una interfaz de red denominada myNic en la subred
mySubnet de la red virtual myVnet y se le asigna la dirección IP pública myPublicIp :

$nic = New-AzNetworkInterface `
-ResourceGroupName "myResourceGroup" `
-Name "myNic" `
-Location "centralus" `
-SubnetId $[Link][0].Id `
-PublicIpAddressId $[Link] `
-EnableAcceleratedNetworking
Creación de una VM y conexión de la interfaz de red
1. Establezca las credenciales de la VM en la variable $cred con Get-Credential. Se le pedirá que inicie sesión:

$cred = Get-Credential

2. Defina la VM con New-AzVMConfig. En el ejemplo siguiente se define una VM denominada myVM con un
tamaño que admite redes aceleradas (Standard_DS4_v2):

$vmConfig = New-AzVMConfig -VMName "myVm" -VMSize "Standard_DS4_v2"

Para obtener una lista de todos los tamaños de máquinas virtuales y las características, consulte tamaños
de máquina virtual de Windows.
3. Cree el resto de la configuración de VM con Set-AzVMOperatingSystem y Set-AzVMSourceImage. Con el
comando siguiente, se crea una VM con Windows Server 2016:

$vmConfig = Set-AzVMOperatingSystem -VM $vmConfig `

-Windows `
-ComputerName "myVM" `
-Credential $cred `
-ProvisionVMAgent `
-EnableAutoUpdate
$vmConfig = Set-AzVMSourceImage -VM $vmConfig `
-PublisherName "MicrosoftWindowsServer" `
-Offer "WindowsServer" `
-Skus "2016-Datacenter" `
-Version "latest"

4. Adjunte la interfaz de red creada anteriormente con Add-AzVMNetworkInterface:

$vmConfig = Add-AzVMNetworkInterface -VM $vmConfig -Id $[Link]

5. Cree la VM con New-AzVM.

New-AzVM -VM $vmConfig -ResourceGroupName "myResourceGroup" -Location "centralus"

Confirmación de que el controlador de Ethernet está instalado en la VM Windows

Una vez creada la VM en Azure, conéctese a ella y confirme que el controlador de Ethernet está instalado en
Windows.
1. Vaya a Azure Portal para administrar sus máquinas virtuales. Busque y seleccione Máquinas vir tuales .
2. En la lista de máquinas virtuales, elija la nueva VM.
3. En la página información general de la VM, si el Estado de la VM aparece como Creando , espere a que
Azure termine de crear la VM. El Estado cambiará a En ejecución cuando se complete la creación de la
VM.
4. En la barra de herramientas de información general de la VM, seleccione Conectar > RDP > Descargar
archivo RDP .
5. Abra el archivo .rdp y, a continuación, inicie sesión en la VM con las credenciales que especificó en la
sección Creación de una VM y conexión de la interfaz de red. Si nunca se ha conectado a una máquina
virtual Windows en Azure, consulte Conexión a la máquina virtual.
6. Cuando aparezca la sesión de escritorio remoto para la VM, haga clic con el botón derecho en el botón
Inicio de Windows y elija Administrador de dispositivos .
7. En la ventana Administrador de dispositivos , expanda el nodo Adaptadores de red .
8. Compruebe que el Adaptador Ethernet de función vir tual ConnectX-3 de Mellanox aparezca como
se muestra en la siguiente imagen:

Las redes aceleradas ya están habilitadas para su VM.

NOTE
Si el adaptador de Mellanox no se inicia, abra un símbolo del sistema del administrador en la sesión de escritorio remoto y
escriba el siguiente comando:
netsh int tcp set global rss = enabled

Habilitación de redes aceleradas en VM existentes

Si ha creado una VM sin redes aceleradas, es posible habilitar esta característica en una VM existente. Para admitir
redes aceleradas, la VM debe cumplir los siguientes requisitos previos, que también se han descrito antes:
La VM debe tener un tamaño admitido para redes aceleradas.
La VM debe ser una imagen admitida de la galería de Azure (y la versión de kernel de Linux).
Todas las VM de un conjunto de disponibilidad o conjunto de escalado de máquinas virtuales se deben
detener o desasignar antes de habilitar las redes aceleradas en cualquier NIC.
VM individuales y VM de un conjunto de disponibilidad
1. Detenga o desasigne la VM o, en el caso de un conjunto de disponibilidad, todas las VM del conjunto:

Stop-AzVM -ResourceGroup "myResourceGroup" -Name "myVM"

NOTE
Si la VM se crea de forma individual, sin un conjunto de disponibilidad, solo es necesario detener o desasignar esa
VM para habilitar las redes aceleradas. Si la VM se creó con un conjunto de disponibilidad, debe detener o
desasignar todas las VM contenidas en el conjunto de disponibilidad antes de habilitar las redes aceleradas en
cualquiera de las NIC, de modo que las VM terminen en un clúster que admita redes aceleradas. El requisito de
detención o desasignación no es necesario si se deshabilita la aceleración de redes, ya que los clústeres que admiten
redes aceleradas también funcionan correctamente con las NIC que no usan redes aceleradas.

2. Habilite las redes aceleradas en la NIC de la VM:

$nic = Get-AzNetworkInterface -ResourceGroupName "myResourceGroup" `

-Name "myNic"

$[Link] = $true

$nic | Set-AzNetworkInterface

3. Reinicie la VM o, en el caso de un conjunto de disponibilidad, todas las máquinas virtuales del conjunto, y
confirme que las redes aceleradas están habilitadas:

Start-AzVM -ResourceGroup "myResourceGroup" `

-Name "myVM"

Conjunto de escalado de máquina virtual

Un conjunto de escalado de máquinas virtuales es ligeramente diferente, pero sigue el mismo flujo de trabajo.
1. Detenga las VM:

Stop-AzVmss -ResourceGroupName "myResourceGroup" `

-VMScaleSetName "myScaleSet"

2. Actualice la propiedad de redes aceleradas en la interfaz de red:

$vmss = Get-AzVmss -ResourceGroupName "myResourceGroup" `

-VMScaleSetName "myScaleSet"

$[Link][0].EnableAcceleratedNetworki
ng = $true

Update-AzVmss -ResourceGroupName "myResourceGroup" `

-VMScaleSetName "myScaleSet" `
-VirtualMachineScaleSet $vmss

3. Defina las actualizaciones aplicadas como automáticas para recoger los cambios inmediatamente:
 $[Link] = "Automatic"

Update-AzVmss -ResourceGroupName "myResourceGroup" `

-VMScaleSetName "myScaleSet" `
-VirtualMachineScaleSet $vmss

NOTE
Un conjunto de escalado tiene actualizaciones de VM que aplican actualizaciones mediante tres valores diferentes:
automático, gradual y manual. En estas instrucciones, la directiva se define como automática para que el conjunto
de escalado recoja los cambios inmediatamente después de reiniciarse.

4. Reinicie el conjunto de escalado:

Start-AzVmss -ResourceGroupName "myResourceGroup" `

-VMScaleSetName "myScaleSet"

Después de reiniciar, espere a que finalicen las actualizaciones. Una vez finalizadas las actualizaciones, la función
virtual (VF) aparece dentro de la VM. Asegúrese de que usa un tamaño de VM y SO admitidos.
Cambio del tamaño de las VM existentes con redes aceleradas
Si una VM tiene habilitadas las redes aceleradas, solo podrá cambiar su tamaño al de una VM que admita redes
aceleradas.
Una VM con redes aceleradas habilitadas no puede cambiar al tamaño de una instancia de VM que no admite
redes aceleradas mediante la operación de cambio de tamaño. Para cambiar el tamaño de una de estas VM, debe
hacer lo siguiente:
1. Detenga o desasigne la VM. Para un conjunto de disponibilidad o conjunto de escalado, detenga o
desasigne todas las VM del conjunto de disponibilidad o escalado.
2. Deshabilite las redes aceleradas en la NIC de la VM. Para un conjunto de disponibilidad o conjunto de
escalado, deshabilite las redes aceleradas en las NIC de todas las VM del conjunto de disponibilidad o de
escalado.
3. Después de deshabilitar las redes aceleradas, cambie la VM, el conjunto de disponibilidad o el conjunto de
escalado a un nuevo tamaño que no admita redes aceleradas y reinicie.
 Creación de una máquina virtual Linux con
Accelerated Networking con la CLI de Azure
23/09/2020 • 21 minutes to read • Edit Online

En este tutorial, obtendrá información sobre cómo crear una máquina virtual Linux con Accelerated Networking.
Para crear una máquina virtual Windows con Accelerated Networking, consulte Creación de una máquina virtual
Windows con Accelerated Networking. Accelerated Networking habilita la virtualización de E/S de raíz única (SR-
IOV) en una máquina virtual (VM), lo que mejora significativamente su rendimiento en la red. Este método de alto
rendimiento omite el host de la ruta de acceso de datos, lo que reduce la latencia, la inestabilidad y la utilización
de la CPU para usarse con las cargas de trabajo de red más exigentes en los tipos de máquina virtual admitidos.
En la siguiente imagen, se muestra la comunicación entre dos máquinas virtuales (VM) con y sin Accelerated
Networking:

Sin Accelerated Networking, todo el tráfico de red de entrada y salida de la máquina virtual tiene que atravesar el
host y el conmutador virtual. El conmutador virtual se encarga de toda la aplicación de directivas, como grupos
de seguridad de red, listas de control de acceso, aislamiento y otros servicios virtualizados de red, al tráfico de
red. Para más información sobre los conmutadores virtuales, lea el artículo sobre virtualización de red y
conmutador virtual de Hyper-V.
Con Accelerated Networking, el tráfico de red llega a la interfaz de red (NIC) de la máquina virtual y se reenvía
después a la máquina virtual. Todas las directivas de red que el conmutador virtual aplica se descargan y aplican
en el hardware. La aplicación de directivas en hardware permite que la NIC reenvíe el tráfico de red directamente
a la máquina virtual, pasando por alto el host y el conmutador virtual, al mismo tiempo que se mantienen todas
las directivas aplicadas en el host.
Las ventajas de Accelerated Networking solo se aplican a la máquina virtual donde esté habilitado. Para obtener
resultados óptimos, lo ideal es habilitar esta característica en al menos dos máquinas virtuales conectadas a la
misma instancia de Azure Virtual Network (VNet). Al comunicarse entre redes virtuales o conectarse de forma
local, esta característica tiene un efecto mínimo sobre la latencia total.

Ventajas
Menor latencia/Más paquetes por segundo (pps): al quitarse el conmutador virtual de la ruta de acceso
de datos, se elimina el tiempo que los paquetes pasan en el host para el procesamiento de las directivas y se
aumenta el número de paquetes que se pueden procesar dentro de la máquina virtual.
 Inestabilidad reducida: el procesamiento del conmutador virtual depende de la cantidad de directivas que
deben aplicarse y la carga de trabajo de la CPU que se encarga del procesamiento. Al descargarse la aplicación
de directivas en el hardware, se elimina esa variabilidad, ya que los paquetes se entregan directamente a la
máquina virtual y se elimina el host de la comunicación de la máquina virtual, así como todas las
interrupciones de software y los cambios de contexto.
Disminución de la utilización de la CPU: el pasar por alto el conmutador virtual en el host conlleva una
disminución de la utilización de la CPU para procesar el tráfico de red.

Sistemas operativos admitidos

Se admiten las siguientes distribuciones de fábrica desde la galería de Azure:
Ubuntu 14.04 con el kernel linux-azure
Ubuntu 16.04 o posterior
SLES12 SP3 o posterior
RHEL 7.4 o posterior
CentOS 7.4 o posterior
CoreOS Linux
Debian "Stretch" con kernel backpor ts
Oracle Linux 7.4 y posterior con Red Hat Compatible Kernel (RHCK)
Oracle Linux 7.5 y posterior con UEK, versión 5
FreeBSD 10.4, 11.1 y 12.0

Limitaciones y restricciones
Instancias de máquina virtual admitidas
Accelerated Networking se admite con la mayoría de los tamaños de instancia de uso general y optimizados para
procesos de dos o más vCPU. Estas series admitidas son: D/DSv2 y F/Fs
En instancias que admiten hyperthreading, las redes aceleradas se admiten en instancias de máquina virtual con
cuatro o más vCPU. Las series admitidas son: D/Dsv3, D/Dsv4, E/Esv3, Ea/Easv4, Fsv2, Lsv2, Ms/Mms y
Ms/Mmsv2.
Para más información sobre las instancias de máquinas virtuales, consulte Tamaños de las máquinas virtuales
Linux.
Custom Images
Si usa una imagen personalizada compatible con redes aceleradas, asegúrese de disponer de los controladores
necesarios para trabajar con las NIC ConnectX-3 y ConnectX-4 Lx de Mellanox en Azure.
Regions
Está disponible en todas las regiones públicas de Azure y en las nubes de Azure Government.
Habilitación de Accelerated Networking en una máquina virtual en ejecución
Un tamaño de máquina virtual admitido sin tener habilitado Accelerated Networking solo puede tener la
característica habilitada cuando se detiene o se desasigna la máquina virtual.
Implementación mediante Azure Resource Manager
Las máquinas virtuales (clásicas) no se pueden implementar con Accelerated Networking.

Creación de una máquina virtual Linux con Azure Accelerated

Networking
Creación del portal
Aunque en este artículo se explica cómo crear una máquina virtual con redes aceleradas mediante la CLI de
Azure, también puede crear una máquina virtual con redes aceleradas mediante Azure Portal. Al crear una
máquina virtual en el portal, en la hoja Crear una máquina vir tual , seleccione la pestaña Redes . En esta
pestaña hay una opción para Redes aceleradas . Si ha seleccionado un sistema operativo compatible y un
tamaño de máquina virtual, esta opción se rellena automáticamente como "Activado". Si no, se rellena la opción
"Desactivado" para Redes aceleradas y se proporciona al usuario un motivo de por qué no están habilitadas.
Nota: Solo los sistemas operativos compatibles se pueden habilitar a través del portal. Si usa una imagen
personalizada y esta es compatible con Redes aceleradas, cree la máquina virtual mediante la CLI o
PowerShell.
Una vez creada la máquina virtual, puede confirmar que la opción Redes aceleradas está habilitada si sigue las
instrucciones que se indican en Confirmar que las redes aceleradas están habilitadas.

Creación de la CLI
Creación de una red virtual
Instale la última versión de la CLI de Azure e inicie sesión en una cuenta de Azure con az login. En los ejemplos
siguientes, reemplace los nombres de parámetros de ejemplo por los suyos propios. Los nombres de parámetro
de ejemplo incluyen myResourceGroup, myNic y myVM.
Cree un grupo de recursos con az group create. En el ejemplo siguiente, se crea un grupo de recursos
denominado myResourceGroup en la ubicación centralus:

az group create --name myResourceGroup --location centralus

Seleccione una región de Linux admitida enumerada en Linux accelerated networking (Accelerated Networking
para Linux).
Cree la red virtual con el comando az network vnet create. En el ejemplo siguiente se crea una red virtual
denominada myVnet con una subred:

az network vnet create \

--resource-group myResourceGroup \
--name myVnet \
--address-prefix [Link]/16 \
--subnet-name mySubnet \
--subnet-prefix [Link]/24

Crear un grupo de seguridad de red

Cree un grupo de seguridad de red con az network nsg create. En el ejemplo siguiente se crea un grupo de
seguridad de red denominado myNetworkSecurityGroup:

az network nsg create \

--resource-group myResourceGroup \
--name myNetworkSecurityGroup

El grupo de seguridad de red contiene varias reglas predeterminadas, una de las cuales deshabilita todo el acceso
entrante desde Internet. Abra un puerto para permitir el acceso SSH a la máquina virtual con az network nsg rule
create:
 az network nsg rule create \
--resource-group myResourceGroup \
--nsg-name myNetworkSecurityGroup \
--name Allow-SSH-Internet \
--access Allow \
--protocol Tcp \
--direction Inbound \
--priority 100 \
--source-address-prefix Internet \
--source-port-range "*" \
--destination-address-prefix "*" \
--destination-port-range 22

Creación de una interfaz de red con Accelerated Networking

Cree una dirección IP pública con az network public-ip create. No se requiere una dirección IP pública si no tiene
pensado acceder a la máquina virtual desde Internet, pero, para completar los pasos de este artículo, sí es
necesaria.

az network public-ip create \

--name myPublicIp \
--resource-group myResourceGroup

Cree una interfaz de red con az network nic create con Accelerated Networking habilitado. En el ejemplo siguiente
se crea una interfaz de red denominada myNic en la subred mySubnet de la red virtual myVnet y asocia el grupo
de seguridad de red myNetworkSecurityGroup a la interfaz de red:

az network nic create \

--resource-group myResourceGroup \
--name myNic \
--vnet-name myVnet \
--subnet mySubnet \
--accelerated-networking true \
--public-ip-address myPublicIp \
--network-security-group myNetworkSecurityGroup

Creación de una máquina virtual y conexión de NIC

Cuando cree la máquina virtual, especifique las NIC creadas con --nics . Seleccione un tamaño y una
distribución enumerados en Linux accelerated networking (Accelerated Networking para Linux).
Cree la máquina virtual con az vm create. En el ejemplo siguiente se crea una máquina virtual denominada
myVM con la imagen de UbuntuTLS y un tamaño que admite Accelerated Neworking (Standard_DS4_v2):

az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--size Standard_DS4_v2 \
--admin-username azureuser \
--generate-ssh-keys \
--nics myNic

Para obtener una lista de todos los tamaños de máquinas virtuales y las características, consulte Tamaños de
máquina virtual Linux.
Una vez creada la máquina virtual, se devuelve una salida similar a la del siguiente ejemplo. Anote el valor de
publicIpAddress . Esta dirección se utiliza para acceder a la máquina virtual en los pasos posteriores.
 {
"fqdns": "",
"id":
"/subscriptions/<ID>/resourceGroups/myResourceGroup/providers/[Link]/virtualMachines/myVM",
"location": "centralus",
"macAddress": "00-0D-3A-23-9A-49",
"powerState": "VM running",
"privateIpAddress": "[Link]",
"publicIpAddress": "[Link]",
"resourceGroup": "myResourceGroup"
}

Confirmación de que Accelerated Networking esté habilitado

Use el siguiente comando para crear una sesión de SSH con la máquina virtual. Reemplace
<your-public-ip-address> con la dirección IP pública asignada a la máquina virtual que ha creado y reemplace
azureuser si usó un valor diferente para --admin-username cuando creó la máquina virtual.

ssh azureuser@<your-public-ip-address>

En el shell de Bash, escriba uname -r y confirme que la versión de kernel es una de las siguientes o una posterior:
Ubuntu 16.04 : 4.11.0-1013
SLES SP3 : 4.4.92-6.18
RHEL : 7.4.2017120423
CentOS : 7.4.20171206
Con el comando lspci , confirme que el dispositivo Mellanox VF se expone a la máquina virtual. La salida
devuelta será similar a la siguiente:

[Link].0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled) (rev 03)
[Link].0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01)
[Link].1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
[Link].3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
[Link].0 VGA compatible controller: Microsoft Corporation Hyper-V virtual VGA
[Link].0 Ethernet controller: Mellanox Technologies MT27500/MT27520 Family [ConnectX-3/ConnectX-3 Pro
Virtual Function]

Compruebe la actividad en la función virtual con el comando ethtool -S eth0 | grep vf_ . Si recibe un resultado
similar al siguiente ejemplo de salida, Accelerated Networking red está habilitado y en funcionamiento.

vf_rx_packets: 992956
vf_rx_bytes: 2749784180
vf_tx_packets: 2656684
vf_tx_bytes: 1099443970
vf_tx_dropped: 0

Las redes aceleradas ya están habilitadas para su máquina virtual.

Control de la revocación y el enlace dinámicos de la función virtual

Las aplicaciones deben ejecutarse a través del NIC sintético que se expone en la máquina virtual. Si la aplicación
se ejecuta directamente sobre el VF de NIC, no recibirá todos los paquetes destinados a la máquina virtual, ya
que algunos paquetes se mostrarán sobre la interfaz sintética. Si ejecuta una aplicación a través del NIC sintético,
garantiza que la aplicación recibe todos los paquetes que están destinados a él. También se asegura de que la
aplicación sigue ejecutándose, incluso si se revoca el VF cuando el host está en mantenimiento. El enlace de
aplicaciones al NIC sintético es un requisito obligatorio para todas las aplicaciones que usan redes aceleradas .

Habilitación de Accelerated Networking en máquinas virtuales

existentes
Si ha creado una VM sin Accelerated Networking, es posible habilitar esta característica en una VM existente. Para
admitir Accelerated Networking, la VM debe cumplir los siguientes requisitos previos que también se han
descrito anteriormente:
La VM debe tener un tamaño admitido para Accelerated Networking.
La VM debe ser una imagen admitida de la galería de Azure (y la versión de kernel de Linux).
Todas las máquinas virtuales de un conjunto de disponibilidad o VMSS se deben detener o desasignar antes
de habilitar Accelerated Networking en cualquier NIC.
VM individuales y VM de un conjunto de disponibilidad
En primer lugar, detenga o desasigne la VM o, en el caso de un conjunto de disponibilidad, todas las VM del
conjunto:

az vm deallocate \
--resource-group myResourceGroup \
--name myVM

Es importante tener en cuenta que, si la máquina virtual se creó de forma individual, sin un conjunto de
disponibilidad, solo es necesario detener o desasignar esa máquina virtual individual para habilitar Accelerated
Networking. Si la máquina virtual se creó con un conjunto de disponibilidad, será necesario detener o desasignar
todas las máquinas virtuales contenidas en el conjunto de disponibilidad antes de habilitar Accelerated
Networking en cualquiera de las NIC.
Una vez detenida, habilite Accelerated Networking en la NIC de la máquina virtual:

az network nic update \

--name myNic \
--resource-group myResourceGroup \
--accelerated-networking true

Reinicie la máquina virtual o, en el caso de un conjunto de disponibilidad, todas las máquinas virtuales del
conjunto, y confirme que Accelerated Networking está habilitado:

az vm start --resource-group myResourceGroup \

--name myVM

VMSS
VMSS es ligeramente diferente, pero sigue el mismo flujo de trabajo. En primer lugar, detenga las VM:

az vmss deallocate \
--name myvmss \
--resource-group myrg

Una vez detenidas las VM, actualice la propiedad Accelerated Networking bajo la interfaz de red:
 az vmss update --name myvmss \
--resource-group myrg \
--set
[Link][0].enableAcceleratedNetworking=true

Tenga en cuenta que un VMSS tiene actualizaciones de VM que aplican actualizaciones mediante tres valores
diferentes: automático, gradual y manual. En estas instrucciones, la directiva se establece en automático para que
el VMSS recoja los cambios inmediatamente después de reiniciarse. Para establecerla en automático para que los
cambios se recojan inmediatamente:

az vmss update \
--name myvmss \
--resource-group myrg \
--set [Link]="automatic"

Por último, reinicie el VMSS:

az vmss start \
--name myvmss \
--resource-group myrg

Después de reiniciar, espere a que las actualizaciones finalicen y la función virtual aparecerá dentro de la VM.
(Asegúrese de que usa un tamaño admitido de sistema operativo y VM).
Cambio del tamaño de las VM existentes con Accelerated Networking
Las VM con Accelerated Networking habilitado solo pueden cambiar al tamaño de VM que admitan Accelerated
Networking.
Una VM con Accelerated Networking habilitado no puede cambiar al tamaño de una instancia de VM que no
admita Accelerated Networking mediante la operación de cambio de tamaño. Para cambiar el tamaño de una de
estas VM, debe hacer lo siguiente:
Detener o desasignar la VM o, si se trata de un conjunto de disponibilidad o VMSS, detener o desasignar todas
las VM del conjunto o VMSS.
Accelerated Networking debe estar deshabilitado en la NIC de la VM o, si está en un conjunto de
disponibilidad o VMSS, de todas las VM del conjunto o VMSS.
Una vez deshabilitadas, la máquina virtual, el conjunto de disponibilidad o el VMSS se pueden mover a un
nuevo tamaño que no admita redes aceleradas y reiniciarse.
 Configuración de DPDK en una máquina virtual Linux
23/09/2020 • 12 minutes to read • Edit Online

Data Plane Development Kit (DPDK) de Azure ofrece una plataforma más rápida de procesamiento de paquetes de
espacio de usuario para aplicaciones de rendimiento intensivo. Esta plataforma omite la pila re red de kernel de la
máquina virtual.
En un procesamiento normal de paquetes que use la pila de red de kernel, el proceso está controlado por
interrupciones. Cada vez que la interfaz de red recibe paquetes entrantes, hay una interrupción en el kernel para
procesar el paquete y un cambio de contexto del espacio del kernel al espacio del usuario. DPDK elimina el cambio
de contextos y el método controlado por interrupciones en favor de una implementación de espacio de usuario que
usa controladores en modo sondeo para un rápido procesamiento de paquetes.
DPDK consta de conjuntos de bibliotecas de espacio de usuario que proporciona acceso a recursos de nivel inferior.
Estos recursos pueden incluir hardware, núcleos lógicos, administración de memoria y controladores de modo de
sondeo para las tarjetas de interfaz de red.
DPDK se puede ejecutar en máquinas virtuales de Azure que admitan varias distribuciones del sistema operativo.
DPDK proporciona una diferenciación de rendimiento clave en la realización de implementaciones de virtualización
de funciones de red. Estas implementaciones pueden adoptar la forma de aplicaciones virtuales de red, como
enrutadores virtuales, firewalls, redes privadas virtuales, equilibradores de carga, núcleos de paquete
evolucionados y aplicaciones de denegación de servicio.

Ventaja
Más paquetes por segundo (PPS) : si se omite el kernel y se toma el control de los paquetes en el espacio del
usuario se reduce el recuento de ciclos mediante la eliminación de los cambios de contexto. También mejora la tasa
de paquetes que son procesados por segundo en las máquinas virtuales Linux de Azure.

Sistemas operativos admitidos

Se admiten las siguientes distribuciones desde Azure Marketplace:

SO L IN UX VERSIÓ N DEL K ERN EL

Ubuntu 16.04 4.15.0-1014-azure+

Ubuntu 18.04 4.15.0-1014-azure+

SLES 15 SP1 4.12.14-8.19-azure+

RHEL 7.5 3.10.0-862.11.6.el7.x86_64+

CentOS 7.5 3.10.0-862.11.6.el7.x86_64+

Compatibilidad de kernel personalizado

Para cualquier versión de kernel de Linux que no aparezca, consulte las revisiones para la compilación de un kernel
de Linux adaptado a Azure. Para obtener más información, puede también ponerse en contacto con
azuredpdk@[Link].
Regiones admitidas
Todas las regiones de Azure admiten DPDK.

Prerrequisitos
Se deben habilitar las redes aceleradas en una máquina virtual Linux. La máquina virtual debe tener al menos dos
interfaces de red, con una interfaz para la administración. Aprenda a crear una máquina virtual Linux con redes
aceleradas habilitadas.

Instalación de dependencias de DPDK

Ubuntu 16.04

sudo add-apt-repository ppa:canonical-server/dpdk-azure -y

sudo apt-get update
sudo apt-get install -y librdmacm-dev librdmacm1 build-essential libnuma-dev libmnl-dev

Ubuntu 18.04

sudo add-apt-repository ppa:canonical-server/dpdk-azure -y

sudo apt-get update
sudo apt-get install -y librdmacm-dev librdmacm1 build-essential libnuma-dev libmnl-dev

RHEL7.5/CentOS 7.5

yum -y groupinstall "Infiniband Support"

sudo dracut --add-drivers "mlx4_en mlx4_ib mlx5_ib" -f
yum install -y gcc kernel-devel-`uname -r` numactl-devel.x86_64 librdmacm-devel libmnl-devel

SLES 15 SP1
Kernel de Azure

zypper \
--no-gpg-checks \
--non-interactive \
--gpg-auto-import-keys install kernel-azure kernel-devel-azure gcc make libnuma-devel numactl librdmacm1
rdma-core-devel

Kernel predeterminado

zypper \
--no-gpg-checks \
--non-interactive \
--gpg-auto-import-keys install kernel-default-devel gcc make libnuma-devel numactl librdmacm1 rdma-core-devel

Configuración del entorno de la máquina virtual (una vez)

1. Descargue la versión de DPDK más reciente. Se requiere la versión 18.11 LTS o 19.11 LTS para Azure.
2. Cree la configuración predeterminada con make config T=x86_64-native-linuxapp-gcc .
3. Habilite Mellanox PMDs en la configuración generada con sed -ri 's,(MLX._PMD=)n,\1y,' build/.config .
4. Compile con make .
5. Instale con make install DESTDIR=<output folder> .
Configuración del entorno de tiempo de ejecución
Después de reiniciar, ejecute los siguientes comandos una vez:
1. Macropáginas
Configure la macropágina ejecutando el siguiente comando una vez para cada nodo NUMA:

echo 1024 | sudo tee /sys/devices/system/node/node*/hugepages/hugepages-2048kB/nr_hugepages

Cree un directorio para el montaje con mkdir /mnt/huge .

Monte macropáginas con mount -t hugetlbfs nodev /mnt/huge .
Compruebe que las macropáginas están reservadas con grep Huge /proc/meminfo .

[Nota] Hay una manera de modificar el archivo GRUB para que las macropáginas se reserven en
el arranque siguiendo las instrucciones de DPDK. Las instrucciones están en la parte inferior de la
página. Cuando use una máquina virtual Linux de Azure, modifique en su lugar los archivos de
/etc/config/grub.d para reservar las macropáginas en los reinicios.

2. Direcciones MAC e IP: use ifconfig –a para ver la dirección IP y MAC de las interfaces de red. La interfaz de
red VF y la interfaz de red NETVSC tienen la misma dirección MAC, pero solo la interfaz de red NETVSC tiene
una dirección IP. Las interfaces VF se ejecutan como interfaces subordinadas de las interfaces NETVSC.
3. Direcciones PCI
Use ethtool -i <vf interface name> para averiguar qué dirección PCI usar para VF.
Si eth0 tiene las redes aceleradas habilitadas, asegúrese de que testpmd no toma accidentalmente el
control del dispositivo PCI de VF para eth0. Si la aplicación DPDK ha tomado accidentalmente el control
de la interfaz de red de administración y provoca la pérdida de la conexión SSH, use la consola serie para
detener la aplicación DPDK. También puede usar la consola serie para detener o iniciar la máquina virtual.
4. Cargue ibuverbs en cada reinicio con modprobe -a ib_uverbs . Solo para SLES 15, cargue también mlx4_ib
con modprobe -a mlx4_ib .

PMD a prueba de errores

Las aplicaciones de DPDK se deben ejecutar sobre el PMD a prueba de errores que se expone en Azure. Si la
aplicación se ejecuta directamente sobre el PMD de VF, no recibirá todos los paquetes destinados a la máquina
virtual, ya que algunos paquetes se mostrarán sobre la interfaz sintética.
Si ejecuta una aplicación DPDK a través del PMD a prueba de errores, garantiza que la aplicación recibe todos los
paquetes que están destinados a él. También se asegura de que la aplicación sigue ejecutándose en modo DPDK,
incluso si se revoca el VF cuando el host está en mantenimiento. Para más información sobre PMD a prueba de
errores, consulte la biblioteca de controladores de modo de sondeo a prueba de errores.

Ejecutar testpmd
Use sudo antes del comando testpmd para ejecutar testpmd en modo raíz.
Básico: comprobación de integridad, inicialización del adaptador a prueba de errores
1. Ejecute los comandos siguientes para iniciar una aplicación testpmd de puerto único:
 testpmd -w <pci address from previous step> \
--vdev="net_vdev_netvsc0,iface=eth1" \
-- -i \
--port-topology=chained

2. Ejecute los comandos siguientes para iniciar una aplicación testpmd de puerto dual:

testpmd -w <pci address nic1> \

-w <pci address nic2> \
--vdev="net_vdev_netvsc0,iface=eth1" \
--vdev="net_vdev_netvsc1,iface=eth2" \
-- -i

Si ejecuta testpmd con más de 2 NIC, el argumento --vdev seguirá este patrón:
net_vdev_netvsc<id>,iface=<vf’s pairing eth> .

3. Una vez iniciado, ejecute show port info all para comprobar la información de puerto. Debería ver uno o
dos puertos DPDK que son net_failsafe (no net_mlx4).
4. Use start <port> /stop <port> para iniciar el tráfico.

Los comandos anteriores inician testpmd en modo interactivo, lo cual es recomendable para probar comandos
testpmd.
Básico: remitente y receptor únicos
Los siguientes comandos imprimen periódicamente las estadísticas de paquetes por segundo:
1. En el lado de TX, ejecute el comando siguiente:

testpmd \
-l <core-list> \
-n <num of mem channels> \
-w <pci address of the device you plan to use> \
--vdev="net_vdev_netvsc<id>,iface=<the iface to attach to>" \
-- --port-topology=chained \
--nb-cores <number of cores to use for test pmd> \
--forward-mode=txonly \
--eth-peer=<port id>,<receiver peer MAC address> \
--stats-period <display interval in seconds>

2. En el lado de RX, ejecute el comando siguiente:

testpmd \
-l <core-list> \
-n <num of mem channels> \
-w <pci address of the device you plan to use> \
--vdev="net_vdev_netvsc<id>,iface=<the iface to attach to>" \
-- --port-topology=chained \
--nb-cores <number of cores to use for test pmd> \
--forward-mode=rxonly \
--eth-peer=<port id>,<sender peer MAC address> \
--stats-period <display interval in seconds>

Si ejecuta los comandos anteriores en una máquina virtual, cambie IP_SRC_ADDR y IP_DST_ADDR a
app/test-pmd/txonly.c para que coincida con la dirección IP real de las máquinas virtuales antes de realizar la
compilación. En caso contrario, se descartarán los paquetes antes de alcanzar el receptor.
Avanzado: remitente y reenviador únicos
Los siguientes comandos imprimen periódicamente las estadísticas de paquetes por segundo:
1. En el lado de TX, ejecute el comando siguiente:

testpmd \
-l <core-list> \
-n <num of mem channels> \
-w <pci address of the device you plan to use> \
--vdev="net_vdev_netvsc<id>,iface=<the iface to attach to>" \
-- --port-topology=chained \
--nb-cores <number of cores to use for test pmd> \
--forward-mode=txonly \
--eth-peer=<port id>,<receiver peer MAC address> \
--stats-period <display interval in seconds>

2. En el lado de FWD, ejecute el comando siguiente:

testpmd \
-l <core-list> \
-n <num of mem channels> \
-w <pci address NIC1> \
-w <pci address NIC2> \
--vdev="net_vdev_netvsc<id>,iface=<the iface to attach to>" \
--vdev="net_vdev_netvsc<2nd id>,iface=<2nd iface to attach to>" (you need as many --vdev arguments as
the number of devices used by testpmd, in this case) \
-- --nb-cores <number of cores to use for test pmd> \
--forward-mode=io \
--eth-peer=<recv port id>,<sender peer MAC address> \
--stats-period <display interval in seconds>

Si ejecuta los comandos anteriores en una máquina virtual, cambie IP_SRC_ADDR y IP_DST_ADDR a
app/test-pmd/txonly.c para que coincida con la dirección IP real de las máquinas virtuales antes de realizar la
compilación. En caso contrario, se descartarán los paquetes antes de alcanzar el reenviador. No podrá hacer que
una tercera máquina virtual reciba el tráfico reenviado, porque el reenviador de testpmd no modifica las
direcciones de la capa 3, a menos que realice algunos cambios.

Referencias
Opciones EAL
Comandos testpmd
 Optimización del rendimiento de TCP/IP para
máquinas virtuales de Azure
23/09/2020 • 52 minutes to read • Edit Online

En este artículo se describen técnicas de optimización del rendimiento de TCP/IP comunes y algunos aspectos a
tener en cuenta cuando se usan para máquinas virtuales que se ejecutan en Azure. Se proporciona una
introducción básica de las técnicas y se explora cómo se pueden optimizar.

Técnicas de optimización de TCP/IP comunes

MTU, fragmentación y descarga de envíos grandes
MTU
La unidad de transmisión máxima (MTU) es el tamaño de marco más grande (paquete), especificado en bytes, que
se puede enviar mediante una interfaz de red. La MTU es un valor configurable. El valor predeterminado de MTU
utilizado en las máquinas virtuales de Azure y la configuración predeterminada de la mayoría de los dispositivos de
red a nivel global es de 1 500 bytes.
Fragmentación
La fragmentación se produce cuando se envía un paquete que supera la MTU de una interfaz de red. La pila TCP/IP
dividirá el paquete en partes más pequeñas (fragmentos) que se ajusten a la MTU de la interfaz. La fragmentación
se produce en la capa de IP y es independiente del protocolo subyacente (por ejemplo, TCP). Cuando se envía un
paquete de 2 000 bytes a través de una interfaz de red con una MTU de 1 500, el paquete se divide en un paquete
de 1 500 bytes y un paquete de 500 bytes.
Los dispositivos de red de la ruta entre un origen y un destino pueden eliminar los paquetes que superan la MTU o
fragmentar el paquete en partes más pequeñas.
El bit No Fragmentar de un paquete IP
El bit No Fragmentar (DF) es una marca en el encabezado del protocolo IP. El bit DF indica que los dispositivos de
red de la ruta entre el remitente y el receptor no deben fragmentar el paquete. Este bit se puede establecer por
diversos motivos. (Consulte la sección "Detección de la MTU de la ruta" de este artículo para obtener un ejemplo).
Cuando un dispositivo de red recibe un paquete con el bit No Fragmentar establecido y ese paquete supera la MTU
de la interfaz del dispositivo, el comportamiento estándar del dispositivo es eliminar el paquete. El dispositivo envía
de vuelta un mensaje de fragmentación necesaria de ICMP al origen del paquete.
Implicaciones de rendimiento de la fragmentación
La fragmentación puede afectar al rendimiento de forma negativa. Una de las razones principales para el efecto en
el rendimiento es el impacto de la fragmentación y el reensamblado de paquetes en la CPU y la memoria. Cuando
un dispositivo de red tiene que fragmentar un paquete, tendrá que asignar recursos de CPU y memoria para llevar
a cabo la fragmentación.
Lo mismo sucede cuando se vuelve a ensamblar el paquete. El dispositivo de red tiene que almacenar todos los
fragmentos hasta que se reciben para poder reensamblarlos en el paquete original. Este proceso de fragmentación
y reensamblado también puede provocar latencia.
La otra posible implicación negativa de la fragmentación en el rendimiento es que los paquetes fragmentados
pueden llegar desordenados. Cuando se reciben paquetes desordenados, algunos tipos de dispositivos de red
pueden eliminarlos. Cuando esto ocurre, se tiene que retransmitir el paquete completo.
Normalmente, los dispositivos de seguridad, como los firewalls de red o cuando los búferes de recepción de un
dispositivo de red se agotan, eliminan los fragmentos. Cuando se agotan los búferes de recepción de un dispositivo
de red, este intenta volver a ensamblar el paquete fragmentado pero no dispone de recursos para almacenar y
volver a ensamblar el paquete.
La fragmentación se puede ver como una operación negativa, pero la compatibilidad con la fragmentación es
necesaria cuando se conectan redes diversas a través de Internet.
Ventajas y consecuencias de modificar la MTU
Por lo general, puede crear una red más eficaz si aumenta la MTU. Todos los paquetes que se transmiten tienen una
información de encabezado que se agrega al paquete original. Cuando la fragmentación crea más paquetes, hay
más sobrecarga de encabezados y esto hace que la red sea menos eficiente.
Este es un ejemplo. El tamaño del encabezado de Ethernet es de 14 bytes más una secuencia de comprobación del
marco de 4 bytes para garantizar la coherencia del marco. Si se envía un paquete de 2 000 bytes, se agregan los
18 bytes de sobrecarga de Ethernet a la red. Si el paquete se fragmenta en un paquete de 1 500 bytes y un paquete
de 500 bytes, cada paquete tendrá 18 bytes del encabezado de Ethernet, un total de 36 bytes.
Tenga en cuenta que aumentar la MTU no crea necesariamente una red más eficaz. Si una aplicación envía solo
paquetes de 500 bytes, existirá la misma sobrecarga de encabezado si la MTU es de 1 500 bytes o de 9 000 bytes.
La red será más eficaz únicamente si utiliza mayores tamaños de paquete que se ven afectados por la MTU.
Azure y la MTU de la máquina virtual
La MTU predeterminada de las máquinas virtuales de Azure es de 1 500 bytes. La pila de la red virtual de Azure
intentará fragmentar un paquete de 1 400 bytes.
Tenga en cuenta que la pila de la red virtual no es intrínsecamente ineficaz porque fragmenta los paquetes de
1 400 bytes, aunque las máquinas virtuales tengan una MTU de 1 500. Un porcentaje elevado de paquetes de red
son mucho menores de 1 400 o 1 500 bytes.
Azure y la fragmentación
La pila de la red virtual está configurada para eliminar los "fragmentos desordenados", es decir, los paquetes
fragmentados que no llegan en el orden de fragmentación original. Estos paquetes se eliminan principalmente
debido a una vulnerabilidad de la seguridad de la red que se anunció en noviembre de 2018 llamada
FragmentSmack.
FragmentSmack es un defecto de la manera en que el kernel de Linux administra el reensamblado de paquetes
IPv4 e IPv6 fragmentados. Un atacante remoto podría utilizar este defecto para desencadenar operaciones de
reensamblado de fragmentos costosas, lo que puede provocar un aumento del uso de la CPU y una denegación de
servicio en el sistema de destino.
Ajuste de la MTU
Puede configurar un valor de MTU de la máquina virtual de Azure, al igual que es posible en cualquier otro sistema
operativo. Pero se debe tener en cuenta la fragmentación que se produce en Azure, que se ha descrito
anteriormente, cuando se configura una MTU.
No recomendamos a los clientes el aumento de la MTU de la máquina virtual. Esta explicación intenta explicar los
detalles de cómo implementa Azure la MTU y cómo realiza la fragmentación.

IMPORTANT
No está demostrado que el aumento de la MTU mejore el rendimiento y podría tener un impacto negativo en el rendimiento
de la aplicación.

Descarga de envíos grandes

La descarga de envíos grandes (LSO) puede mejorar el rendimiento de la red mediante la descarga de la
segmentación de los paquetes al adaptador Ethernet. Cuando se habilita LSO, la pila TCP/IP crea un paquete TCP
grande y lo envía al adaptador Ethernet para su segmentación antes de reenviarlo. La ventaja de LSO es que puede
liberar a la CPU de la segmentación de los paquetes en tamaños que se ajusten a la MTU y descarga ese
procesamiento a la interfaz Ethernet, donde se realiza en hardware. Para más información acerca de las ventajas de
LSO, consulte Supporting large send offload (Compatibilidad con la descarga de envíos grandes).
Cuando LSO está habilitado, los clientes de Azure podrían ver tamaños de marco grandes al realizar capturas de
paquetes. Estos tamaños de marco grandes podrían llevar a algunos clientes a pensar que se está produciendo la
fragmentación o que se está usando una MTU grande cuando no es así. Con LSO, el adaptador Ethernet puede
anunciar un tamaño de segmento máximo (MSS) mayor a la pila TCP/IP para crear un paquete TCP mayor. Este
marco no segmentado completo se reenvía al adaptador Ethernet y sería visible en una captura de paquetes
realizada en la máquina virtual. Pero el adaptador Ethernet dividirá el paquete en varios marcos más pequeños,
según la MTU del adaptador Ethernet.
Escalado de la ventana de MSS de TCP y PMTUD
Tamaño de segmento máximo de TCP
El tamaño de segmento máximo de TCP (MSS) es una configuración que limita el tamaño de los segmentos TCP, lo
que evita la fragmentación de los paquetes TCP. Los sistemas operativos normalmente utilizan esta fórmula para
establecer el MSS:
MSS = MTU - (IP header size + TCP header size)

El encabezado IP y el encabezado TCP son de 20 bytes cada uno o de 40 bytes en total. Por lo tanto, una interfaz con
una MTU de 1 500 tendrá un MSS de 1 460. Pero el MSS es configurable.
Esta configuración es aceptada en el protocolo de enlace de tres vías de TCP cuando se configura una sesión TCP
entre un origen y un destino. Ambos lados envían un valor de MSS y el menor de los dos se usa para la conexión
TCP.
Tenga en cuenta que las MTU del origen y el destino no son los únicos factores que determinan el valor de MSS.
Los dispositivos de red intermedios, como las puertas de enlace de VPN, incluido Azure VPN Gateway, pueden
ajustar la MTU independientemente del origen y el destino para garantizar un rendimiento óptimo de la red.
Detección de la MTU de la ruta
El MSS se negocia, pero podría no indicar el MSS real que se puede usar. Esto es porque otros dispositivos de red
de la ruta entre el origen y el destino podrían tener un valor de MTU menor que el origen y el destino. En este caso,
el dispositivo cuyo MTU sea menor que el paquete eliminará el paquete. El dispositivo enviará de vuelta un mensaje
de fragmentación necesaria de ICMP (Tipo 3, Código 4) que contiene su MTU. Este mensaje de ICMP permite al host
de origen reducir su MTU de la ruta adecuadamente. El proceso se denomina detección de la MTU de la ruta
(PMTUD).
El proceso PMTUD es ineficaz y afecta al rendimiento de la red. Cuando se envían paquetes que superan la MTU de
la ruta de red, los paquetes se deben retransmitir con un MSS inferior. Si el remitente no recibe el mensaje de
fragmentación necesaria de ICMP, quizás debido a un firewall de red en la ruta (conocido comúnmente como un
agujero negro de PMTUD), el remitente no sabe que necesita reducir el MSS y retransmitirá continuamente el
paquete. Esta es la razón por la que no se recomienda aumentar la MTU de la máquina virtual de Azure.
VPN y MTU
Si usa máquinas virtuales que realizan encapsulación (por ejemplo, las VPN de IPsec), hay algunas consideraciones
adicionales sobre el tamaño de paquete y la MTU. Las VPN agregan más encabezados a los paquetes, lo que
aumenta el tamaño del paquete y requiere un MSS menor.
Para Azure, se recomienda que establezca el bloqueo de MSS de TCP en 1 350 bytes y la MTU de la interfaz del
túnel en 1 400. Para más información, consulte la página de dispositivos VPN y parámetros de IPSec/IKE.
Latencia, tiempo de ida y vuelta y escalado de la ventana de TCP
Latencia y tiempo de ida y vuelta
La latencia de red se rige por la velocidad de la luz en una red de fibra óptica. El rendimiento de red de TCP también
se rige de forma eficaz por el tiempo de ida y vuelta (RTT) entre dos dispositivos de red.
 EN RUTA R DISTA N C IA T IEM P O UN IDIREC C IO N A L RT T

De Nueva York a San 4 148 km 21 ms 42 ms

Francisco

De Nueva York a Londres 5 585 km 28 ms 56 ms

De Nueva York a Sydney 15 993 km 80 ms 160 ms

Esta tabla muestra la distancia en línea recta entre dos ubicaciones. En las redes, la distancia es normalmente mayor
que la distancia en línea recta. Esta es una fórmula sencilla para calcular el RTT mínimo en función de la velocidad
de la luz:
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)

Puede usar 200 para la velocidad de propagación. Se trata de la distancia, en kilómetros, que recorre la luz en
1 milisegundo.
Tomemos de Nueva York a San Francisco como ejemplo. La distancia en línea recta es de 4 148 km. Sustituyendo
ese valor en la ecuación, se obtiene lo siguiente:
Minimum RTT = 2 * (4,148 / 200)

El resultado de la ecuación se expresa en milisegundos.

Si desea obtener el mejor rendimiento de red, la opción lógica consiste en seleccionar destinos con la distancia más
corta entre ellos. También debe diseñar la red virtual para optimizar la ruta del tráfico y reducir la latencia. Para más
información, consulte la sección "Consideraciones de diseño de la red" de este artículo.
Latencia y efectos del tiempo de ida y vuelta en TCP
El tiempo de ida y vuelta tiene un efecto directo en el rendimiento máximo de TCP. En el protocolo TCP, el tamaño de
ventana es la cantidad máxima de tráfico que se puede enviar a través de una conexión TCP antes de que el
remitente deba recibir confirmación por parte del receptor. Si el MSS de TCP está establecido en 1 460 y el tamaño
de ventana de TCP está establecido en 65 535, el remitente puede enviar 45 paquetes antes de que tenga que
recibir confirmación del receptor. Si el remitente no recibe la confirmación, retransmitirá los datos. Esta es la
fórmula:
TCP window size / TCP MSS = packets sent

En este ejemplo, 65 535 / 1 460 se redondea a 45.

Este estado de "en espera de confirmación", un mecanismo para garantizar la entrega confiable de los datos, es lo
que hace que el RTT afecte al rendimiento de TCP. Cuanto más tiempo esté el remitente en espera de confirmación,
más tiempo debe esperar antes de enviar más datos.
Esta es la fórmula para calcular el rendimiento máximo de una única conexión TCP:
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second

Esta tabla muestra el rendimiento máximo en megabytes por segundo de una única conexión TCP. (Para mejorar la
legibilidad, se usan megabytes para la unidad de medida).

TA M A Ñ O DE L A VEN TA N A REN DIM IEN TO M Á XIM O EN REN DIM IEN TO M Á XIM O EN

DE TC P ( B Y T ES) L AT EN C IA DE RT T ( M S) M EGA B Y T ES/ SEGUN DO M EGA B IT S/ SEGUN DO

65 535 1 65,54 524,29

65 535 30 2,18 17,48

 TA M A Ñ O DE L A VEN TA N A REN DIM IEN TO M Á XIM O EN REN DIM IEN TO M Á XIM O EN
DE TC P ( B Y T ES) L AT EN C IA DE RT T ( M S) M EGA B Y T ES/ SEGUN DO M EGA B IT S/ SEGUN DO

65 535 60 1,09 8,74

65 535 90 0,73 5,83

65 535 120 0,55 4.37

Si se pierden paquetes, se reducirá el rendimiento máximo de una conexión TCP mientras el remitente retransmite
datos que ya ha enviado.
Escalado de la ventana de TCP
El escalado de la ventana de TCP es una técnica que aumenta dinámicamente el tamaño de la ventana de TCP para
permitir que se envíen más datos antes de solicitar una confirmación. En el ejemplo anterior, se enviarían 45
paquetes antes de solicitar una confirmación. Si aumenta el número de paquetes que se pueden enviar antes de
necesitar una confirmación, se reduce el número de veces que un remitente está en espera de confirmación, lo que
aumenta el rendimiento máximo de TCP.
Esta tabla muestra esas relaciones:

TA M A Ñ O DE L A VEN TA N A REN DIM IEN TO M Á XIM O EN REN DIM IEN TO M Á XIM O EN

DE TC P ( B Y T ES) L AT EN C IA DE RT T ( M S) M EGA B Y T ES/ SEGUN DO M EGA B IT S/ SEGUN DO

65 535 30 2,18 17,48

131 070 30 4.37 34,95

262 140 30 8,74 69,91

524 280 30 17,48 139,81

Pero el valor del encabezado TCP para el tamaño de la ventana de TCP tiene solo 2 bytes, lo que significa que el
valor máximo de una ventana de recepción es de 65 535. Para aumentar el tamaño máximo de la ventana, se
introdujo un factor de escala de la ventana de TCP.
El factor de escala también es un valor que se puede configurar en un sistema operativo. Esta es la fórmula para
calcular el tamaño de la ventana de TCP mediante el uso de factores de escala:
TCP window size = TCP window size in bytes \* (2^scale factor)

Este es el cálculo para un factor de escala de la ventana de 3 y un tamaño de la ventana de 65 535:

65,535 \* (2^3) = 262,140 bytes

Un factor de escala de 14 da como resultado un tamaño de la ventana de TCP de 14 (el desplazamiento máximo
permitido). El tamaño de la ventana de TCP será de 1 073 725 440 bytes (8,5 gigabits).
Compatibilidad con el escalado de la ventana de TCP
Windows puede establecer diferentes factores de escala para diferentes tipos de conexión. (Las clases de
conexiones incluyen centros de datos, Internet, etc). Puede usar el comando Get-NetTCPConnection de PowerShell
para ver el tipo de conexión del escalado de la ventana:

Get-NetTCPConnection

Puede usar el comando Get-NetTCPSetting de PowerShell para ver los valores de cada clase:
 Get-NetTCPSetting

Puede establecer el tamaño inicial de la ventana de TCP y el factor de escalado de TCP en Windows mediante el
comando Set-NetTCPSetting de PowerShell. Para más información, consulte Set-NetTCPSetting.

Set-NetTCPSetting

Esta es la configuración de TCP eficaz para AutoTuningLevel :

F Ó RM UL A PA RA
M ULT IP L IC A DO R DE C A L C UL A R EL TA M A Ñ O
A UTOT UN IN GL EVEL FA C TO R DE ESC A L A DO ESC A L A DO M Á XIM O DE L A VEN TA N A

Disabled None None Tamaño de la ventana

Restringido 4 2^4 Tamaño de la ventana *

(2^4)

Muy restringido 2 2^2 Tamaño de la ventana *

(2^2)

Normal 8 2^8 Tamaño de la ventana * (2 ^

8)

Experimental 14 2^14 Tamaño de la ventana *

(2^14)

Esta configuración es la que más puede afectar al rendimiento de TCP, pero tenga en cuenta que también pueden
afectar al rendimiento de TCP muchos otros factores de Internet, fuera del control de Azure.
Aumento del tamaño de la MTU
Dado que una MTU mayor implica un mayor MSS, tal vez se pregunte si aumentar la MTU puede aumentar el
rendimiento de TCP. Probablemente no. Existen ventajas y desventajas relativas al tamaño de paquete más allá del
tráfico TCP. Como se explicó anteriormente, los factores más importantes que afectan al rendimiento de TCP son el
tamaño de la ventana de TCP, la pérdida de paquetes y el RTT.

IMPORTANT
No se recomienda que los clientes de Azure cambia el valor de la MTU predeterminada de las máquinas virtuales.

Redes aceleradas y escalado en la recepción

Redes aceleradas
Las funciones de red de las máquinas virtuales históricamente han sido de alto uso de CPU tanto en la máquina
virtual invitada como en el hipervisor o host. La CPU del host procesa por software todos los paquetes que
transitan a través del host, incluida toda la encapsulación y desencapsulación de la red virtual. Por tanto, cuanto
más tráfico pase por el host, mayor será la carga de CPU. Y si la CPU del host está ocupada con otras operaciones,
esto también afectará al rendimiento de la red y la latencia. Azure resuelve este problema con las redes aceleradas.
Las redes aceleradas proporcionan una latencia de red muy baja y coherente mediante el uso de hardware
programable interno de Azure y tecnologías como SR-IOV. Las redes aceleradas trasladan gran parte de la pila de
redes definida por software de Azure desde las CPU a tarjetas SmartNIC basadas en FPGA. Este cambio permite
que las aplicaciones de usuario final puedan reclamar ciclos de proceso, lo que supone una carga menor en la
máquina virtual y reduce la inestabilidad y las incoherencias en la latencia. En otras palabras, el rendimiento puede
ser más determinista.
Las redes aceleradas mejoran el rendimiento al permitir que la máquina virtual invitada pueda omitir el host y
establecer una ruta de datos directamente con una tarjeta SmartNIC del host. Estas son algunas de las ventajas de
las redes aceleradas:
Menor latencia / Más paquetes por segundo (pps) : al eliminarse el conmutador virtual de la ruta de
datos, se elimina el tiempo que los paquetes pasan en el host para el procesamiento de las directivas y se
aumenta el número de paquetes que se pueden procesar en la máquina virtual.
Inestabilidad reducida : el procesamiento del conmutador virtual depende de la cantidad de directivas que
deben aplicarse y la carga de trabajo de la CPU que se encarga del procesamiento. Al descargarse la
aplicación de directivas en el hardware se elimina esa variabilidad, ya que los paquetes se entregan
directamente a la máquina virtual y se elimina la comunicación del host a la máquina virtual, así como todas
las interrupciones de software y los cambios de contexto.
Disminución de la utilización de la CPU : el pasar por alto el conmutador virtual en el host conlleva una
disminución de la utilización de la CPU para procesar el tráfico de red.
Para usar redes aceleradas, las debe habilitar explícitamente en cada máquina virtual aplicable. Consulte Creación
de una máquina virtual Linux con redes aceleradas para obtener instrucciones.
Escalado en la recepción
El escalado en la recepción (RSS) es una tecnología del controlador de red que distribuye la recepción de tráfico de
red de forma más eficaz mediante la distribución del procesamiento de recepción en varias CPU en un sistema
multiprocesador. En términos sencillos, RSS permite a un sistema procesar más tráfico recibido porque usa todas
las CPU disponibles en lugar de una sola. Para obtener una explicación más técnica sobre RSS, consulte
Introduction to Receive Side Scaling (Introducción al escalado en la recepción).
Para obtener el mejor rendimiento cuando se habilitan las redes aceleradas en una máquina virtual, deberá
habilitar RSS. RSS también puede proporcionar ventajas en máquinas virtuales que no usan redes aceleradas. Para
obtener información general sobre cómo determinar si RSS está habilitado y cómo habilitarlo, consulte
Optimización del rendimiento de red para máquinas virtuales de Azure.
TCP TIME_WAIT y TIME_WAIT assassination
TCP TIME_WAIT es otra configuración común que afecta al rendimiento de la red y la aplicación. En máquinas
virtuales ocupadas que abren y cierran muchos sockets, sea como clientes o como servidores (Dirección IP de
origen:Puerto de origen + Dirección IP de destino:Puerto de destino) durante el funcionamiento normal de TCP, un
socket determinado puede acabar en un estado TIME_WAIT durante mucho tiempo. El estado TIME_WAIT está
pensado para permitir que los datos adicionales se entreguen en un socket antes de cerrarlo. Por lo que las pilas
TCP/IP generalmente impiden la reutilización de un socket mediante la eliminación del paquete TCP SYN del cliente
de forma silenciosa.
La cantidad de tiempo que un socket está en estado TIME_WAIT es configurable. Puede variar entre 30 segundos y
240 segundos. Los sockets son un recurso finito y el número de sockets que se pueden usar en un momento dado
es configurable. (El número de sockets disponibles normalmente es de aproximadamente 30 000). Si se consumen
los sockets disponibles o si clientes y servidores tienen una configuración de TIME_WAIT no coincidente y una
máquina virtual intenta volver a usar un socket en un estado de TIME_WAIT, se producirá un error en las nuevas
conexiones, ya que los paquetes TCP SYN se descartan silenciosamente.
El valor del intervalo de puertos para los sockets de salida normalmente es configurable en la pila TCP/IP de un
sistema operativo. Lo mismo ocurre con la configuración de TCP TIME_WAIT y la reutilización de sockets. La
modificación de estos números puede mejorar potencialmente la escalabilidad. Sin embargo, según la situación,
estos cambios podrían causar problemas de interoperabilidad. Debe tener cuidado si cambia estos valores.
Puede usar TIME_WAIT assassination para abordar esta limitación de escalado. TIME_WAIT assassination permite
que un socket se reutilice en determinadas situaciones, como cuando el número de secuencia del paquete IP de la
nueva conexión supera el número de secuencia del último paquete de la conexión anterior. En este caso, el sistema
operativo permitirá que se establezca la nueva conexión (aceptará el nuevo SYN/ACK) y forzará el cierre la conexión
anterior que estaba en un estado de TIME_WAIT. Esta funcionalidad se admite en las máquinas virtuales Windows
de Azure. Para obtener información sobre la compatibilidad con otras máquinas virtuales, póngase en contacto con
el proveedor del sistema operativo.
Para obtener información acerca de cómo configurar los valores de TCP TIME_WAIT y el intervalo de puertos de
origen, consulte Configuración que puede modificarse para mejorar el rendimiento de red.

Factores de red virtual que pueden afectar al rendimiento

Rendimiento máximo de salida de la máquina virtual
Azure proporciona una variedad de tamaños y tipos de máquinas virtuales, cada uno con una combinación
diferente de funcionalidades de rendimiento. Una de estas funcionalidades es el rendimiento de red (o ancho de
banda) medido en megabits por segundo (Mbps). Dado que las máquinas virtuales se hospedan en hardware
compartido, la capacidad de red debe compartirse equitativamente entre las máquinas virtuales que usan el mismo
hardware. A las máquinas virtuales más grandes se les asigna más ancho de banda que a las más pequeñas.
El ancho de banda de red asignado a cada máquina virtual se mide en el tráfico de salida de la máquina virtual.
Todo el tráfico de red que deja la máquina virtual se cuenta para el límite asignado, independientemente del
destino. Por ejemplo, si una máquina virtual tiene un límite de 1 000 Mbps, ese límite se aplica tanto si el tráfico
saliente está destinado a otra máquina virtual en la misma red virtual como a una fuera de Azure.
La entrada no se mide o no está directamente limitada. Sin embargo, hay otros factores, como los límites de la CPU
y de almacenamiento, que pueden afectar a la capacidad de una máquina virtual de procesar los datos entrantes.
Las redes aceleradas están diseñadas para mejorar el rendimiento de red, incluidas la utilización de la CPU, el
rendimiento y la latencia. Las redes aceleradas pueden mejorar el rendimiento de una máquina virtual, pero solo
pueden hacerlo hasta el ancho de banda asignado de la máquina virtual.
Las máquinas virtuales de Azure tienen al menos una interfaz de red conectada. Pueden tener varias. El ancho de
banda asignado a una máquina virtual es la suma de todo el tráfico saliente de todas las interfaces de red
conectadas a la máquina. En otras palabras, el ancho de banda se asigna por máquina virtual, independientemente
de la cantidad de interfaces de red conectadas a la máquina.
El rendimiento de salida esperado y el número de interfaces de red admitidas en cada tamaño de máquina virtual
se detallan en Tamaños de las máquinas virtuales Windows en Azure. Para ver el rendimiento máximo, seleccione
un tipo, como De uso general y, a continuación, busque la sección acerca de los tamaños y las series en la página
resultante (por ejemplo, "Serie Dv2"). Para cada serie, hay una tabla que proporciona las especificaciones de redes
en la última columna, que se titula "Nº máx. de NIC/ancho de banda de red esperado (Mbps)".
El límite de rendimiento se aplica a la máquina virtual. El rendimiento no se ve afectado por estos factores:
Número de interfaces de red : el límite de ancho de banda se aplica a la suma de todo el tráfico de salida
de la máquina virtual.
Redes aceleradas : aunque esta característica puede ser útil para alcanzar el límite publicado, no cambia
dicho límite.
Destino del tráfico : todos los destinos cuentan para el límite de salida.
Protocolo : todo el tráfico saliente a través de todos los protocolos cuenta para el límite.
Para más información, consulte Ancho de banda de red de las máquinas virtuales.
Consideraciones sobre el rendimiento de Internet
Como se describe en este artículo, hay factores en Internet y fuera del control de Azure que pueden afectar al
rendimiento de la red. Estos son algunos de esos factores:
Latencia : el tiempo de ida y vuelta entre dos destinos puede verse afectado por incidencias en redes
intermedias, por tráfico que no toma la ruta de distancia "más corta" y por rutas de emparejamiento poco
óptimas.
Pérdida de paquetes : La pérdida de paquetes se puede deber a la congestión de la red, a incidencias de la
ruta física y al déficit de rendimiento de los dispositivos de red.
Tamaño de MTU y fragmentación : la fragmentación a lo largo de la ruta puede dar lugar a retrasos en la
llegada de los datos o en a paquetes que llegan desordenados, lo que pueden afectar a la entrega de los
paquetes.
Traceroute es una buena herramienta para medir las características de rendimiento de red (como la pérdida de
paquetes o la latencia) a lo largo de cada ruta de red entre un dispositivo de origen y un dispositivo de destino.
Consideraciones de diseño de la red
Junto con los aspectos descritos anteriormente en este artículo, la topología de una red virtual puede afectar al
rendimiento de la red. Por ejemplo, un diseño de concentrador y radios que retorna globalmente el tráfico a una
red virtual de un solo concentrador provocará latencia de red, lo que afectará al rendimiento general de la red.
El número de dispositivos de red que atraviesa el tráfico de red también puede afectar a la latencia total. Por
ejemplo, en un diseño de concentrador y radios, si el tráfico pasa a través de una aplicación virtual de red del radio
y una aplicación virtual del concentrador antes del tránsito a Internet, las aplicaciones virtuales de red pueden
introducir latencia.
Regiones de Azure, redes virtuales y latencia
Las regiones de Azure se componen de varios centros de datos dentro de un área geográfica general. Estos centros
de datos podrían no estar físicamente juntos. En algunos casos les separan hasta 10 kilómetros. La red virtual es
una superposición lógica sobre la red de centros de datos físicos de Azure. Una red virtual no implica una topología
de red específica en el centro de datos.
Por ejemplo, dos máquinas virtuales que se encuentran en la misma red virtual y subred podrían estar en
diferentes bastidores, filas o incluso centros de datos. Pueden estar separadas por metros de cable de fibra óptica o
por kilómetros de cable de fibra óptica. Esta variación puede introducir una latencia variable (una diferencia de
unos pocos milisegundos) entre diferentes máquinas virtuales.
La ubicación geográfica de las máquinas virtuales y la posible latencia resultante entre dos máquinas virtuales
pueden verse influenciadas por la configuración de los conjuntos de disponibilidad y las zonas de disponibilidad.
Pero la distancia entre los centros de datos de una región es específica de dicha región y viene influida
principalmente por la topología de los centros de datos de la región.
Agotamiento de puertos NAT de origen
Una implementación de Azure puede comunicarse con puntos de conexión externos a Azure en el espacio de
direcciones IP públicas o en Internet público. Cuando una instancia inicia una conexión de salida, Azure asigna
dinámicamente la dirección IP privada a una dirección IP pública. Una vez que Azure crea esta asignación, el tráfico
de retorno del flujo originado de salida también puede comunicarse con la dirección IP privada donde se originó el
flujo.
Para todas las conexiones salientes, Azure Load Balancer debe mantener esta asignación durante un período de
tiempo. Dada la naturaleza multiinquilino de Azure, mantener esta asignación para cada flujo de salida de cada
máquina virtual puede consumir muchos recursos. Por lo que se establecen límites que se basan en la
configuración de Azure Virtual Network. O bien, para expresarlo con mayor precisión, una máquina virtual de
Azure solo puede realizar un cierto número de conexiones salientes en un momento dado. Cuando se alcanzan
estos límites, la máquina virtual no podrá realizar más conexiones salientes.
No obstante, este comportamiento es configurable. Para más información acerca de SNAT y el agotamiento de
puertos SNAT, consulte este artículo.

Medición del rendimiento de red en Azure

Varios de los valores máximos de rendimiento de este artículo están relacionados con la latencia de red y el tiempo
de ida y vuelta (RTT) entre dos máquinas virtuales. Esta sección proporciona algunas sugerencias para la prueba de
latencia y RTT y sobre cómo probar el rendimiento de TCP y rendimiento de la red de la máquina virtual. Puede
ajustar y probar el rendimiento de los valores de TCP/IP y de la red mencionados anteriormente mediante el uso de
las técnicas descritas en esta sección. Puede insertar los valores de latencia, MTU, MSS y tamaño de la ventana en
los cálculos que se proporcionaron anteriormente y comparar los valores máximos teóricos con los valores reales
que se observan durante las pruebas.
Medición del tiempo de ida y vuelta y la pérdida de paquetes
El rendimiento de TCP depende en gran medida del RTT y la pérdida de paquetes. La utilidad PING disponible en
Windows y Linux proporciona la manera más fácil de medir el RTT y la pérdida de paquetes. La salida de PING
muestra la latencia mínima, máxima y promedio entre un origen y destino. También muestra la pérdida de
paquetes. PING usa el protocolo ICMP de forma predeterminada. Puede usar PsPing para probar el RTT de TCP. Para
más información, consulte PsPing.
Medición del rendimiento real de una conexión TCP
NTttcp es una herramienta para probar el rendimiento de TCP de una máquina virtual Windows o Linux. Puede
cambiar varios valores de TCP y, a continuación, probar las ventajas con NTttcp. Para obtener más información, vea
estos recursos:
Pruebas de ancho de banda y rendimiento (NTttcp)
Utilidad NTttcp
Medición del ancho de banda real de una máquina virtual
Puede probar el rendimiento de diferentes tipos de máquinas virtuales, redes aceleradas y otros elementos
mediante una herramienta llamada iPerf. iPerf también está disponible en Linux y Windows. iPerf puede usar TCP o
UDP para probar el rendimiento general de la red. Las pruebas de rendimiento de TCP de iPerf se ven influenciadas
por los factores explicados en este artículo (como la latencia y el RTT). Por tanto, UDP podría ofrecer mejores
resultados si solo desea probar el rendimiento máximo.
Para obtener más información, consulte estos artículos:
Solución de problemas de rendimiento de red de ExpressRoute
Validación del rendimiento de la VPN en una red virtual
Detección de comportamientos no eficaces de TCP
En las capturas de paquetes, los clientes de Azure podrían ver paquetes de TCP con marcas de TCP (SACK, DUP ACK,
RETRANSMIT y FAST RETRANSMIT) que podrían indicar problemas de rendimiento de la red. Esos paquetes indican
específicamente problemas de eficacia de la red como resultado de la pérdida de paquetes. Pero la pérdida de
paquetes no es provocada necesariamente por problemas de rendimiento de Azure. Los problemas de rendimiento
podrían ser el resultado de problemas de la aplicación, problemas del sistema operativo u otros problemas que
podrían no estar directamente relacionados con la plataforma de Azure.
Además, tenga en cuenta que algunos elementos ACK de retransmisión o duplicados son normales en una red. Los
protocolos TCP se diseñaron para ser confiables. La evidencia de estos paquetes TCP en una captura de paquetes no
indica necesariamente un problema sistémico de la red a menos que sean excesivos.
Aún así, estos tipos de paquetes son indicaciones de que el rendimiento de TCP no alcanza su rendimiento máximo
por las razones descritas en otras secciones de este artículo.
Pasos siguientes
Ahora que tiene información sobre el ajuste del rendimiento de TCP/IP de las máquinas virtuales de Azure, tal vez
quiera consultar otras consideraciones sobre el planeamiento de redes virtuales u obtener información sobre la
conexión y configuración de redes virtuales.
 Ancho de banda de la red de máquinas virtuales
23/09/2020 • 8 minutes to read • Edit Online

Azure ofrece una variedad de tamaños y tipos de máquinas virtuales, cada uno con una combinación diferente de
funcionalidades de rendimiento. Una de ellas es el rendimiento de red (o ancho de banda) medido en megabits
por segundo (Mbps). Dado que las máquinas virtuales se hospedan en hardware compartido, la capacidad de red
debe compartirse equitativamente entre las máquinas virtuales que compartan el mismo hardware. A las
máquinas virtuales más grandes se les asigna relativamente más ancho de banda que las más pequeñas.
El ancho de banda de red asignado a cada máquina virtual se mide en el tráfico de salida de la máquina virtual.
Todo el tráfico de red que deja la máquina virtual se cuenta para el límite asignado, independientemente del
destino. Por ejemplo, si una máquina virtual tiene un límite de Mbps 1000, ese límite se aplica si el tráfico saliente
está destinado a otra máquina virtual en la misma red virtual, o fuera de Azure.
La entrada no se mide o no está directamente limitada. Sin embargo, hay otros factores, como los límites de la
CPU y de almacenamiento, que pueden afectar la capacidad de una máquina virtual de procesar los datos
entrantes.
Las redes aceleradas son una característica diseñada para mejorar el rendimiento de red, incluida la utilización de
la CPU, el rendimiento y la latencia. Mientras que las redes aceleradas pueden mejorar el rendimiento de una
máquina virtual, puede hacerlo solo hasta el ancho de banda asignado de la máquina virtual. Para más
información sobre las redes aceleradas, consulte los temas sobre redes aceleradas para máquinas virtuales
Windows o Linux.
Las máquinas virtuales de Azure deben tener una interfaz de red, pero pueden tener varias conectadas a ellas. El
ancho de banda asignado a una máquina virtual es la suma de todo el tráfico saliente en todas las interfaces de
red conectadas a una máquina virtual. En otras palabras, el ancho de banda asignado es por máquina virtual,
independientemente de la cantidad de interfaces de red conectadas a la máquina virtual. Para obtener información
sobre la cantidad de interfaces de red que admiten los distintos tamaños de máquinas virtuales de Azure, vea los
tamaños de máquinas virtuales Windows y Linux.

Rendimiento esperado de la red

El rendimiento de salida esperado y el número de interfaces de red compatibles con cada tamaño de máquina
virtual se detallan en los tamaños de máquinas virtuales Windows y Linux de Azure. Seleccione un tipo, como fin
general, y luego seleccione una serie de tamaños en la página resultante, como la serie Dv2. Cada serie tiene una
tabla con las especificaciones de red en la última columna con el nombre N.º máx. NIC/rendimiento de red
esperado (Mbps) .
El límite de rendimiento se aplica a la máquina virtual. El rendimiento no se ve afectado por los siguientes factores:
Número de interfaces de red : el límite de ancho de banda es el cúmulo de todo el tráfico saliente de la
máquina virtual.
Redes aceleradas : aunque la característica puede ser útil para lograr el límite publicado, no cambia el límite.
Destino del tráfico : todos los destinos se cuentan para el límite de salida.
Protocolo : todo el tráfico saliente a través de todos los protocolos cuenta para el límite.

Límites de flujo de red

Además del ancho de banda, el número de conexiones de red presentes en una máquina virtual en un momento
dado puede afectar a su rendimiento de red. La pila de red de Azure mantiene el estado de cada dirección de una
conexión TCP/UDP en estructuras de datos denominadas "flujos". Una conexión TCP/UDP típica tiene dos flujos
creados, uno para la dirección de entrada y otro para la de salida.
La transferencia de datos entre puntos de conexión exige la creación de varios flujos además de los que realizan la
transferencia de datos. Algunos ejemplos son los flujos creados para la resolución DNS y los flujos creados para
los sondeos de estado del equilibrador de carga. Además, tenga en cuenta que las aplicaciones virtuales de red
(NVA), como puertas de enlace, servidores proxy o firewalls, se ocupan de que los flujos creados para las
conexiones terminen en el dispositivo y sean originados por este.

Límites y recomendaciones de flujo

Hoy en día, la pila de red de Azure admite 250 mil flujos de red totales con buen rendimiento para máquinas
virtuales con más de 8 núcleos de CPU y 100 mil flujos totales con buen rendimiento para máquinas virtuales con
menos de 8 núcleos de CPU. Más allá de este límite, el rendimiento de red decae gradualmente para flujos
adicionales hasta un límite máximo de 500 000 flujos totales, 250 000 entrantes y 250 000 salientes, después de
lo cual se eliminan los flujos adicionales.

M Á Q UIN A S VIRT UA L ES C O N M EN O S DE M Á Q UIN A S VIRT UA L ES C O N M Á S DE 8

N IVEL DE REN DIM IEN TO 8 N ÚC L EO S DE C P U N ÚC L EO S DE C P U

Buen rendimiento 100 mil flujos 250 mil flujos

Rendimiento reducido Más de 100 mil flujos Más de 250 mil flujos

Límite de flujos 500 000 flujos 500 000 flujos

Hay métricas disponibles en Azure Monitor para realizar un seguimiento del número de flujos de red y la
velocidad de creación de flujos en las instancias de VM o VMSS.
Las tasas de establecimiento y finalización de conexiones también pueden afectar al rendimiento de red, ya que el
establecimiento y la finalización de conexiones comparten CPU con rutinas de procesamiento de paquetes. Se
recomienda evaluar las cargas de trabajo en patrones de tráfico esperados y escalar horizontalmente las cargas de
trabajo adecuadamente para satisfacer las necesidades de rendimiento.

Pasos siguientes
Optimización del rendimiento de red en un sistema operativo de máquina virtual
Prueba de rendimiento de red para una máquina virtual.
 Movimiento del grupo de seguridad de red (NSG) de
Azure a otra región mediante Azure Portal
23/09/2020 • 9 minutes to read • Edit Online

Hay varios escenarios en los que puede que deba mover los NSG existentes de una región a otra. Por ejemplo,
quiere crear un NSG con las mismas reglas de configuración y seguridad para pruebas. También quiere mover un
NSG a otra región como parte del planeamiento de la recuperación ante desastres.
Los grupos de seguridad de Azure no se pueden mover de una región a otra. Sin embargo, puede usar una plantilla
de Azure Resource Manager para exportar las reglas de seguridad y configuración existentes de un NSG. Después,
puede preparar el recurso en otra región exportando el NSG a una plantilla y modificando los parámetros para que
coincidan con la región de destino, y luego implementar la plantilla en la nueva región. Para más información sobre
Resource Manager y las plantillas, consulte Inicio rápido: Creación e implementación de plantillas de Azure
Resource Manager mediante Azure Portal.

Prerrequisitos
Asegúrese de que el grupo de seguridad de red de Azure se encuentra en la región de Azure desde la que
quiere moverlo.
Los grupos de seguridad de red de Azure no se pueden mover entre regiones. Tendrá que asociar el nuevo
NSG a los recursos de la región de destino.
Para exportar una configuración de NSG e implementar una plantilla para crear un NSG en otra región,
necesitará el rol de colaborador de red u otro superior.
Identifique el diseño de red de origen y todos los recursos que está usando actualmente. Este diseño incluye,
entre otros, los equilibradores de carga, las direcciones IP públicas y las redes virtuales.
Compruebe que su suscripción de Azure permite crear grupos NSG en la región de destino. Para habilitar la
cuota necesaria, póngase en contacto con el soporte técnico.
Asegúrese de que la suscripción tiene suficientes recursos para admitir la adición de grupos NSG para este
proceso. Vea Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.

Preparación y traslado
En los pasos siguientes se muestra cómo preparar el grupo de seguridad de red para mover las reglas de
configuración y seguridad mediante una plantilla de Resource Manager y cómo mover dichas reglas a la región de
destino mediante el portal.
Exportación de la plantilla e implementación desde el portal
1. Inicie sesión en Azure Portal > Grupos de recursos .
2. Busque el grupo de recursos que contiene el NSG de origen y haga clic en él.
3. Seleccione > Configuración > Expor tar plantilla .
4. En la hoja Expor tar plantilla , elija Implementar .
5. Haga clic en PL ANTILL A > Editar parámetros para abrir el archivo [Link] en el editor en
línea.
 6. Para editar el parámetro del nombre de NSG, cambie la propiedad value en parameters :

{
"$schema": "[Link]
"contentVersion": "[Link]",
"parameters": {
"networkSecurityGroups_myVM1_nsg_name": {
"value": "<target-nsg-name>"
}
}
}

7. Cambie el valor del NSG de origen en el editor por un nombre de su elección para el NSG de destino.
Asegúrese de escribir el nombre entre comillas.
8. Haga clic en Guardar en el editor.
9. Haga clic en Plantilla > Editar plantilla para abrir el archivo [Link] en el editor en línea.
10. Para editar la región de destino donde se van a mover las reglas de configuración y seguridad de NSG, vaya
al editor en línea y cambie la propiedad location en resources :

"resources": [
{
"type": "[Link]/networkSecurityGroups",
"apiVersion": "2019-06-01",
"name": "[parameters('networkSecurityGroups_myVM1_nsg_name')]",
"location": "<target-region>",
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "2c846acf-58c8-416d-be97-ccd00a4ccd78",
}
}
]

11. Para obtener los códigos de ubicación de la región, consulte Ubicaciones de Azure. El código de una región es
el nombre de la región sin espacios, Centro de EE. UU. = centralus .
12. También puede cambiar otros parámetros de la plantilla si así lo desea; son opcionales según sus requisitos:
Reglas de seguridad : puede editar las reglas que se implementan en el NSG de destino agregando
o quitando reglas en la sección securityRules del archivo [Link] :
 "resources": [
{
"type": "[Link]/networkSecurityGroups",
"apiVersion": "2019-06-01",
"name": "[parameters('networkSecurityGroups_myVM1_nsg_name')]",
"location": "<target-region>",
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "2c846acf-58c8-416d-be97-ccd00a4ccd78",
"securityRules": [
{
"name": "RDP",
"etag": "W/\"c630c458-6b52-4202-8fd7-172b7ab49cf5\"",
"properties": {
"provisioningState": "Succeeded",
"protocol": "TCP",
"sourcePortRange": "*",
"destinationPortRange": "3389",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*",
"access": "Allow",
"priority": 300,
"direction": "Inbound",
"sourcePortRanges": [],
"destinationPortRanges": [],
"sourceAddressPrefixes": [],
"destinationAddressPrefixes": []
}
},
]
}

Para completar la adición o la eliminación de las reglas en el NSG de destino, también debe editar los
tipos de reglas personalizadas al final del archivo [Link] en el formato del ejemplo siguiente:

{
"type": "[Link]/networkSecurityGroups/securityRules",
"apiVersion": "2019-06-01",
"name": "[concat(parameters('networkSecurityGroups_myVM1_nsg_name'), '/Port_80')]",
"dependsOn": [
"[resourceId('[Link]/networkSecurityGroups',
parameters('networkSecurityGroups_myVM1_nsg_name'))]"
],
"properties": {
"provisioningState": "Succeeded",
"protocol": "*",
"sourcePortRange": "*",
"destinationPortRange": "80",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*",
"access": "Allow",
"priority": 310,
"direction": "Inbound",
"sourcePortRanges": [],
"destinationPortRanges": [],
"sourceAddressPrefixes": [],
"destinationAddressPrefixes": []
}

13. Haga clic en Guardar en el editor en línea.

14. Haga clic en Aspectos básicos > Suscripción para elegir la suscripción en la que se implementará el NSG
de destino.
15. Haga clic en Aspectos básicos > Grupo de recursos para elegir el grupo de recursos donde se
implementará el NSG de destino. Puede hacer clic en Crear nuevo para crear un grupo de recursos para el
NSG de destino. Asegúrese de que el nombre no sea el mismo que el del grupo de recursos de origen del
NSG existente.
16. Compruebe que Aspectos básicos > Ubicación está establecido en la ubicación de destino en la que
quiere que se implemente el NSG.
17. En CONFIGURACIÓN , compruebe que el nombre coincide con el nombre que especificó en el editor de
parámetros anterior.
18. Marque la casilla en TÉRMINOS Y CONDICIONES .
19. Haga clic en el botón Comprar para implementar el grupo de seguridad de red de destino.

Discard (Descartar)
Si quiere descartar el NSG de destino, elimine el grupo de recursos que lo contiene. Para ello, en el portal,
seleccione el grupo de recursos en el panel y, luego, Eliminar en la parte superior de la página de información
general.

Limpieza
Para confirmar los cambios y completar el movimiento del NSG, elimine el NSG de origen o el grupo de recursos.
Para ello, en el portal, seleccione el grupo de seguridad de red o el grupo de recursos en el panel y, luego, Eliminar
en la parte superior de cada página.

Pasos siguientes
En este tutorial, ha movido un grupo de seguridad de red de Azure de una región a otra y ha limpiado los recursos
de origen. Para obtener más información sobre cómo trasladar recursos entre regiones y la recuperación ante
desastres en Azure, consulte:
Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción
Traslado de máquinas virtuales de Azure a otra región
 Traslado del grupo de seguridad de red (NSG) de
Azure a otra región mediante Azure PowerShell
23/09/2020 • 9 minutes to read • Edit Online

Hay varios escenarios en los que puede que deba mover los NSG existentes de una región a otra. Por ejemplo,
quiere crear un NSG con las mismas reglas de configuración y seguridad para pruebas. También quiere mover un
NSG a otra región como parte del planeamiento de la recuperación ante desastres.
Los grupos de seguridad de Azure no se pueden mover de una región a otra. Sin embargo, puede usar una plantilla
de Azure Resource Manager para exportar las reglas de seguridad y configuración existentes de un NSG. Después,
puede preparar el recurso en otra región exportando el NSG a una plantilla y modificando los parámetros para que
coincidan con la región de destino, y luego implementar la plantilla en la nueva región. Para más información sobre
Resource Manager y sus plantillas, consulte Exportación de grupos de recursos a plantillas.

Requisitos previos
Asegúrese de que el grupo de seguridad de red de Azure se encuentra en la región de Azure desde la que
quiere moverlo.
Los grupos de seguridad de red de Azure no se pueden mover entre regiones. Tendrá que asociar el nuevo
NSG a los recursos de la región de destino.
Para exportar una configuración de NSG e implementar una plantilla para crear un NSG en otra región,
necesitará el rol de colaborador de red u otro superior.
Identifique el diseño de red de origen y todos los recursos que está usando actualmente. Este diseño incluye,
entre otros, los equilibradores de carga, las direcciones IP públicas y las redes virtuales.
Compruebe que su suscripción de Azure permite crear grupos NSG en la región de destino. Para habilitar la
cuota necesaria, póngase en contacto con el soporte técnico.
Asegúrese de que la suscripción tiene suficientes recursos para admitir la adición de grupos NSG para este
proceso. Vea Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.

Preparación y traslado
En los pasos siguientes se muestra cómo preparar el grupo de seguridad de red para mover las reglas de
configuración y seguridad mediante una plantilla de Resource Manager y cómo mover dichas reglas a la región de
destino mediante Azure PowerShell.

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Exportación de la plantilla e implementación desde un script

1. Inicie sesión en la suscripción a Azure con el comando Connect-AzAccount y siga las instrucciones de la
pantalla:
 Connect-AzAccount

2. Obtenga el identificador de recurso del NSG que quiere trasladar a la región de destino y colóquelo en una
variable mediante Get-AzNetworkSecurityGroup:

$sourceNSGID = (Get-AzNetworkSecurityGroup -Name <source-nsg-name> -ResourceGroupName <source-resource-

group-name>).Id

3. Exporte el NSG de origen a un archivo .json en el directorio donde se ejecuta el comando Export-
AzResourceGroup:

Export-AzResourceGroup -ResourceGroupName <source-resource-group-name> -Resource $sourceNSGID -

IncludeParameterDefaultValue

4. El nombre del archivo descargado se asignará en función del grupo de recursos desde el que se exportó el
recurso. Busque el archivo que se exportó con el comando denominado <resource-group-name>.json y
ábralo en el editor que prefiera:

notepad <source-resource-group-name>.json

5. Para editar el parámetro del nombre del NSG, cambie el valor defaultValue de la propiedad del nombre del
NSG de origen por el nombre del NSG de destino. Asegúrese de que el nombre se encuentra entre comillas:

{
"$schema": "[Link]
"contentVersion": "[Link]",
"parameters": {
"networkSecurityGroups_myVM1_nsg_name": {
"defaultValue": "<target-nsg-name>",
"type": "String"
}
}

6. Para editar la región de destino donde se van a mover las reglas de configuración y seguridad del NSG,
cambie la propiedad location en resources :

"resources": [
{
"type": "[Link]/networkSecurityGroups",
"apiVersion": "2019-06-01",
"name": "[parameters('networkSecurityGroups_myVM1_nsg_name')]",
"location": "<target-region>",
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "2c846acf-58c8-416d-be97-ccd00a4ccd78",
}
}

7. Para obtener los códigos de ubicación de la región, puede usar el cmdlet Azure PowerShell Get-AzLocation al
ejecutar el siguiente comando:
 Get-AzLocation | format-table

8. Si quiere, también puede cambiar otros parámetros del archivo <resource-group-name>.json . Estos son
opcionales según sus necesidades:
Reglas de seguridad : puede editar las reglas que se implementan en el NSG de destino agregando
o quitando reglas en la sección securityRules del archivo <resource-group-name>.json :

"resources": [
{
"type": "[Link]/networkSecurityGroups",
"apiVersion": "2019-06-01",
"name": "[parameters('networkSecurityGroups_myVM1_nsg_name')]",
"location": "TARGET REGION",
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "2c846acf-58c8-416d-be97-ccd00a4ccd78",
"securityRules": [
{
"name": "RDP",
"etag": "W/\"c630c458-6b52-4202-8fd7-172b7ab49cf5\"",
"properties": {
"provisioningState": "Succeeded",
"protocol": "TCP",
"sourcePortRange": "*",
"destinationPortRange": "3389",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*",
"access": "Allow",
"priority": 300,
"direction": "Inbound",
"sourcePortRanges": [],
"destinationPortRanges": [],
"sourceAddressPrefixes": [],
"destinationAddressPrefixes": []
}
]
}

Para completar la adición o eliminación de las reglas en el grupo de seguridad de red de destino,
también debe editar los tipos de reglas personalizadas al final del archivo <resource-group-
name>.json en el formato del ejemplo siguiente:
 {
"type": "[Link]/networkSecurityGroups/securityRules",
"apiVersion": "2019-06-01",
"name": "[concat(parameters('networkSecurityGroups_myVM1_nsg_name'), '/Port_80')]",
"dependsOn": [
"[resourceId('[Link]/networkSecurityGroups',
parameters('networkSecurityGroups_myVM1_nsg_name'))]"
],
"properties": {
"provisioningState": "Succeeded",
"protocol": "*",
"sourcePortRange": "*",
"destinationPortRange": "80",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*",
"access": "Allow",
"priority": 310,
"direction": "Inbound",
"sourcePortRanges": [],
"destinationPortRanges": [],
"sourceAddressPrefixes": [],
"destinationAddressPrefixes": []
}

9. Guarde el archivo <resource-group-name>.json .

10. Cree un grupo de recursos en la región de destino para el NSG de destino que se va a implementar
mediante New-AzResourceGroup:

New-AzResourceGroup -Name <target-resource-group-name> -location <target-region>

11. Implemente el archivo <resource-group-name>.json editado en el grupo de recursos que creó en el

paso anterior mediante New-AzResourceGroupDeployment:

New-AzResourceGroupDeployment -ResourceGroupName <target-resource-group-name> -TemplateFile <source-

resource-group-name>.json

12. Para comprobar que los recursos se crearon en la región de destino, use los comandos Get-
AzResourceGroup y Get-AzNetworkSecurityGroup:

Get-AzResourceGroup -Name <target-resource-group-name>

Get-AzNetworkSecurityGroup -Name <target-nsg-name> -ResourceGroupName <target-resource-group-name>

Discard (Descartar)
Después de la implementación, si quiere empezar de nuevo o descartar el NSG en el destino, elimine el grupo de
recursos que se creó en el destino y se eliminará el NSG trasladado. Para quitar el grupo de recursos, use Remove-
AzResourceGroup:
 Remove-AzResourceGroup -Name <target-resource-group-name>

Limpieza
Para confirmar los cambios y completar el traslado del NSG, elimine el NSG o el grupo de recursos de origen
mediante Remove-AzResourceGroup o Remove-AzNetworkSecurityGroup:

Remove-AzResourceGroup -Name <source-resource-group-name>

Remove-AzNetworkSecurityGroup -Name <source-nsg-name> -ResourceGroupName <source-resource-group-name>

Pasos siguientes
En este tutorial, ha movido un grupo de seguridad de red de Azure de una región a otra y ha limpiado los recursos
de origen. Para obtener más información sobre cómo trasladar recursos entre regiones y la recuperación ante
desastres en Azure, consulte:
Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción
Traslado de máquinas virtuales de Azure a otra región
 Traslado de una red virtual de Azure a otra región
mediante Azure Portal
23/09/2020 • 10 minutes to read • Edit Online

Hay varios escenarios para mover una red virtual de Azure existente de una región a otra. Por ejemplo, puede que
desee crear una red virtual con la misma configuración que la red virtual existente para realizar pruebas y
conseguir disponibilidad. También es posible que quiera mover una red virtual de producción a otra región como
parte del planeamiento de la recuperación ante desastres.
Puede usar una plantilla de Azure Resource Manager para completar el traslado de la red virtual a otra región. Para
ello, exporte la red virtual a una plantilla, modifique los parámetros para que coincidan con la región de destino y, a
continuación, implemente la plantilla en la región nueva. Para más información sobre las plantillas de Resource
Manager, consulte Inicio rápido: Creación e implementación de plantillas de Azure Resource Manager mediante
Azure Portal.

Prerrequisitos
Asegúrese de que la red virtual se encuentra en la región de Azure desde la que desea moverla.
Para exportar una red virtual e implementar una plantilla para crear una red virtual en otra región,
necesitará tener el rol Colaborador de red u otro superior.
Los emparejamientos de redes virtuales no se volverán a crear y se producirá un error si todavía están
presentes en la plantilla. Antes de exportar la plantilla, debe quitar todos los emparejamientos de red virtual.
Podrá restablecerlos después de mover la red virtual.
Identifique el diseño de red de origen y todos los recursos que está usando actualmente. Este diseño incluye,
pero no se limita a los equilibradores de carga, grupos de seguridad de red (NSG), e IP públicas.
Compruebe que la suscripción de Azure le permite crear redes virtuales en la región de destino. Para
habilitar la cuota necesaria, póngase en contacto con el soporte técnico.
Asegúrese de que la suscripción tiene suficientes recursos para admitir la incorporación de redes virtuales
para este proceso. Para más información, consulte Límites, cuotas y restricciones de suscripción y servicios
de Microsoft Azure.

Preparación para el traslado

En esta sección va a preparar la red virtual para el traslado mediante el uso de una plantilla de Resource Manager.
Después moverá la red virtual a la región de destino mediante Azure Portal.
Para exportar la red virtual e implementar la red virtual de destino mediante Azure Portal, haga lo siguiente:
1. Inicie sesión en Azure Portal y después seleccione Grupos de recursos .
2. Busque el grupo de recursos que contiene la red virtual de origen y selecciónelo.
3. Seleccione Configuración > Expor tar plantilla .
4. En el panel Expor tar plantilla , seleccione Implementar .
5. Para abrir el archivo [Link] en el editor en línea, seleccione Plantilla > Editar parámetros .
6. Para editar el parámetro correspondiente al nombre de la red virtual, cambie la propiedad value de
 parameters :

{
"$schema": "[Link]
"contentVersion": "[Link]",
"parameters": {
"virtualNetworks_myVNET1_name": {
"value": "<target-virtual-network-name>"
}
}
}

7. En el editor, cambie el valor de nombre de la red virtual de origen en el editor por el nombre que desee para
la red virtual de destino. Asegúrese de incluir el nombre entre comillas.
8. Seleccione Guardar en el editor.
9. Para abrir el archivo [Link] en el editor en línea, seleccione Plantilla > Editar plantilla .
10. En el editor en línea, para editar la región de destino a la que se va a trasladar la red virtual, cambie la
propiedad location en resources :

"resources": [
{
"type": "[Link]/virtualNetworks",
"apiVersion": "2019-06-01",
"name": "[parameters('virtualNetworks_myVNET1_name')]",
"location": "<target-region>",
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "6e2652be-35ac-4e68-8c70-621b9ec87dcb",
"addressSpace": {
"addressPrefixes": [
"[Link]/16"
]
},

11. Para obtener los códigos de ubicación de la región, consulte Ubicaciones de Azure. El código de una región
es el nombre en inglés de la región sin espacios (por ejemplo, Centro de EE. UU. es Central US =
centralus ).
12. (Opcional) También puede cambiar otros parámetros de la plantilla, según sus requisitos:
Espacio de direcciones : antes de guardar el archivo, puede modificar el espacio de direcciones de
la red virtual; para ello, modifique la sección resources > addressSpace y cambie la propiedad
addressPrefixes :
 "resources": [
{
"type": "[Link]/virtualNetworks",
"apiVersion": "2019-06-01",
"name": "[parameters('virtualNetworks_myVNET1_name')]",
"location": "<target-region",
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "6e2652be-35ac-4e68-8c70-621b9ec87dcb",
"addressSpace": {
"addressPrefixes": [
"[Link]/16"
]
},

Subred : puede cambiar o agregar el nombre de subred y el espacio de direcciones de subred si

cambia la sección subnets de la plantilla. Para cambiar el nombre de la subred, cambie la propiedad
name . Para cambiar el espacio de direcciones de subred, cambie la propiedad addressPrefix :

"subnets": [
{
"name": "subnet-1",
"etag": "W/\"d9f6e6d6-2c15-4f7c-b01f-bed40f748dea\"",
"properties": {
"provisioningState": "Succeeded",
"addressPrefix": "[Link]/24",
"delegations": [],
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
},
{
"name": "GatewaySubnet",
"etag": "W/\"d9f6e6d6-2c15-4f7c-b01f-bed40f748dea\"",
"properties": {
"provisioningState": "Succeeded",
"addressPrefix": "[Link]/29",
"serviceEndpoints": [],
"delegations": [],
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
}

Para cambiar el prefijo de dirección en el archivo [Link], debe editarlo en dos lugares: en el
código de la sección anterior y en la sección type del siguiente código. Cambie la propiedad
addressPrefix del siguiente código para que coincida con la propiedad addressPrefix del código de
la sección anterior.
 "type": "[Link]/virtualNetworks/subnets",
"apiVersion": "2019-06-01",
"name": "[concat(parameters('virtualNetworks_myVNET1_name'), '/GatewaySubnet')]",
"dependsOn": [
"[resourceId('[Link]/virtualNetworks',
parameters('virtualNetworks_myVNET1_name'))]"
],
"properties": {
"provisioningState": "Succeeded",
"addressPrefix": "[Link]/29",
"serviceEndpoints": [],
"delegations": [],
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
},
{
"type": "[Link]/virtualNetworks/subnets",
"apiVersion": "2019-06-01",
"name": "[concat(parameters('virtualNetworks_myVNET1_name'), '/subnet-1')]",
"dependsOn": [
"[resourceId('[Link]/virtualNetworks',
parameters('virtualNetworks_myVNET1_name'))]"
],
"properties": {
"provisioningState": "Succeeded",
"addressPrefix": "[Link]/24",
"delegations": [],
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
}
]

13. En el editor en línea, seleccione Guardar .

14. Para elegir la suscripción donde se implementará la red virtual de destino, seleccione Datos básicos >
Suscripción .
15. Para elegir el grupo de recursos donde se implementará la red virtual de destino, seleccione Datos básicos
> Grupo de recursos .
Si necesita crear un nuevo grupo de recursos para la red virtual de destino, seleccione Crear nuevo .
Asegúrese de que el nombre no es el mismo que el nombre del grupo de recursos de origen en la red virtual
existente.
16. Compruebe que Datos básicos > Ubicación está establecido en la ubicación de destino en la que quiere
implementar la red virtual.
17. En Configuración , compruebe que el nombre coincide con el nombre que especificó anteriormente en el
editor de parámetros.
18. Active la casilla Términos y condiciones .
19. Para implementar la red virtual de destino, seleccione Adquirir .

Eliminación de la red virtual de destino

Si quiere descartar la red virtual de destino, elimine el grupo de recursos que la contiene. Para ello:
1. En el panel de Azure Portal, seleccione el grupo de recursos.
2. En la parte superior del panel Información general , seleccione Eliminar .
Limpieza
Para confirmar los cambios y completar el traslado de la red virtual, elimine la red virtual o el grupo de recursos de
origen. Para ello:
1. En el panel de Azure Portal, seleccione la red virtual o el grupo de recursos.
2. En la parte superior de cada panel, seleccione Eliminar .

Pasos siguientes
En este tutorial, ha movido una red virtual de Azure de una región a otra mediante Azure Portal y, a continuación,
ha limpiado los recursos de origen innecesarios. Para más información sobre el traslado de recursos entre regiones
y la recuperación ante desastres en Azure, consulte:
Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción
Traslado de máquinas virtuales de Azure a otra región
 Traslado de una red virtual de Azure a otra región
mediante Azure PowerShell
23/09/2020 • 10 minutes to read • Edit Online

Hay varios escenarios para mover una red virtual de Azure existente de una región a otra. Por ejemplo, puede que
desee crear una red virtual con la misma configuración que la red virtual existente para realizar pruebas y
conseguir disponibilidad. También es posible que quiera mover una red virtual de producción a otra región como
parte del planeamiento de la recuperación ante desastres.
Puede usar una plantilla de Azure Resource Manager para completar el traslado de la red virtual a otra región. Para
ello, exporte la red virtual a una plantilla, modifique los parámetros para que coincidan con la región de destino y, a
continuación, implemente la plantilla en la región nueva. Para más información sobre las plantillas de Resource
Manager, consulte Exportación de grupos de recursos a plantillas.

Requisitos previos
Asegúrese de que la red virtual se encuentra en la región de Azure desde la que desea moverla.
Para exportar una red virtual e implementar una plantilla para crear una red virtual en otra región,
necesitará tener el rol Colaborador de red u otro superior.
Los emparejamientos de redes virtuales no se volverán a crear y se producirá un error si todavía están
presentes en la plantilla. Antes de exportar la plantilla, debe quitar todos los emparejamientos de red virtual.
Podrá restablecerlos después de mover la red virtual.
Identifique el diseño de red de origen y todos los recursos que está usando actualmente. Este diseño incluye,
pero no se limita a los equilibradores de carga, grupos de seguridad de red (NSG), e IP públicas.
Compruebe que la suscripción de Azure le permite crear redes virtuales en la región de destino. Para
habilitar la cuota necesaria, póngase en contacto con el soporte técnico.
Asegúrese de que la suscripción tiene suficientes recursos para admitir la incorporación de redes virtuales
para este proceso. Para más información, consulte Límites, cuotas y restricciones de suscripción y servicios
de Microsoft Azure.

Preparación para el traslado

En esta sección va a preparar la red virtual para el traslado mediante el uso de una plantilla de Resource Manager.
Después moverá la red virtual a la región de destino mediante comandos de Azure PowerShell.

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Para exportar la red virtual e implementar la red virtual de destino mediante PowerShell, haga lo siguiente:
1. Inicie sesión en la suscripción de Azure con el comando Connect-AzAccount y siga las instrucciones de la
 pantalla:

Connect-AzAccount

2. Obtenga el identificador de recurso de la red virtual que quiere mover a la región de destino y colóquelo en
una variable mediante Get-AzVirtualNetwork:

$sourceVNETID = (Get-AzVirtualNetwork -Name <source-virtual-network-name> -ResourceGroupName <source-

resource-group-name>).Id

3. Exporte la red virtual de origen a un archivo .json en el directorio donde ejecute el comando Export-
AzResourceGroup:

Export-AzResourceGroup -ResourceGroupName <source-resource-group-name> -Resource $sourceVNETID -

IncludeParameterDefaultValue

4. El archivo descargado tendrá el mismo nombre que el grupo de recursos desde el que se exportó el recurso.
Busque el archivo <resource-group-name>.json, que exportó con el comando y, a continuación, ábralo en el
editor:

notepad <source-resource-group-name>.json

5. Para editar el parámetro del nombre de la red virtual, cambie la propiedad defaultValue del nombre de la
red virtual de origen por el nombre de la red virtual de destino. Asegúrese de incluir el nombre entre
comillas.

"$schema": "[Link]
01/[Link]#",
"contentVersion": "[Link]",
"parameters": {
"virtualNetworks_myVNET1_name": {
"defaultValue": "<target-virtual-network-name>",
"type": "String"
}

6. Para editar la región de destino a la que se va a trasladar la red virtual, cambie la propiedad location en
resources:

"resources": [
{
"type": "[Link]/virtualNetworks",
"apiVersion": "2019-06-01",
"name": "[parameters('virtualNetworks_myVNET1_name')]",
"location": "<target-region>",
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "6e2652be-35ac-4e68-8c70-621b9ec87dcb",
"addressSpace": {
"addressPrefixes": [
"[Link]/16"
]
},

7. Para obtener los códigos de ubicación de la región, puede usar el cmdlet Azure PowerShell Get-AzLocation al
 ejecutar el siguiente comando:

Get-AzLocation | format-table

8. (Opcional) También puede cambiar otros parámetros del archivo <resource-group-name>.json, según sus
requisitos:
Espacio de direcciones : antes de guardar el archivo, puede modificar el espacio de direcciones de
la red virtual; para ello, modifique la sección resources > addressSpace y cambie la propiedad
addressPrefixes :

"resources": [
{
"type": "[Link]/virtualNetworks",
"apiVersion": "2019-06-01",
"name": "[parameters('virtualNetworks_myVNET1_name')]",
"location": "<target-region",
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "6e2652be-35ac-4e68-8c70-621b9ec87dcb",
"addressSpace": {
"addressPrefixes": [
"[Link]/16"
]
},

Subred : puede cambiar o agregar el nombre de subred y el espacio de direcciones de subred si

cambia la sección subnets . Para cambiar el nombre de la subred, cambie la propiedad name . Para
cambiar el espacio de direcciones de subred, cambie la propiedad addressPrefix :

"subnets": [
{
"name": "subnet-1",
"etag": "W/\"d9f6e6d6-2c15-4f7c-b01f-bed40f748dea\"",
"properties": {
"provisioningState": "Succeeded",
"addressPrefix": "[Link]/24",
"delegations": [],
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
},
{
"name": "GatewaySubnet",
"etag": "W/\"d9f6e6d6-2c15-4f7c-b01f-bed40f748dea\"",
"properties": {
"provisioningState": "Succeeded",
"addressPrefix": "[Link]/29",
"serviceEndpoints": [],
"delegations": [],
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
}

Para cambiar el prefijo de dirección, edite el archivo en dos lugares: en el código de la sección anterior
y en la sección type del siguiente código. Cambie la propiedad addressPrefix del siguiente código
para que coincida con la propiedad addressPrefix del código de la sección anterior.
 "type": "[Link]/virtualNetworks/subnets",
"apiVersion": "2019-06-01",
"name": "[concat(parameters('virtualNetworks_myVNET1_name'), '/GatewaySubnet')]",
"dependsOn": [
"[resourceId('[Link]/virtualNetworks',
parameters('virtualNetworks_myVNET1_name'))]"
],
"properties": {
"provisioningState": "Succeeded",
"addressPrefix": "[Link]/29",
"serviceEndpoints": [],
"delegations": [],
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
},
{
"type": "[Link]/virtualNetworks/subnets",
"apiVersion": "2019-06-01",
"name": "[concat(parameters('virtualNetworks_myVNET1_name'), '/subnet-1')]",
"dependsOn": [
"[resourceId('[Link]/virtualNetworks',
parameters('virtualNetworks_myVNET1_name'))]"
],
"properties": {
"provisioningState": "Succeeded",
"addressPrefix": "[Link]/24",
"delegations": [],
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
}
]

9. Guarde el archivo <resource-group-name>.json.

10. Cree un grupo de recursos en la región de destino para la red virtual de destino que se va a implementar,
mediante New-AzResourceGroup:

New-AzResourceGroup -Name <target-resource-group-name> -location <target-region>

11. Implemente el archivo <resource-group-name>.json editado en el grupo de recursos que creó en el paso
anterior mediante el recurso New-AzResourceGroupDeployment:

New-AzResourceGroupDeployment -ResourceGroupName <target-resource-group-name> -TemplateFile <source-

resource-group-name>.json

12. Para comprobar que los recursos se crearon en la región de destino, use Get-AzResourceGroup y Get-
AzVirtualNetwork:

Get-AzResourceGroup -Name <target-resource-group-name>

Get-AzVirtualNetwork -Name <target-virtual-network-name> -ResourceGroupName <target-resource-group-name>

Eliminación de la red virtual o el grupo de recursos
Después de la implementación de la red virtual, si quiere empezar de nuevo o descartar la red virtual en la región
de destino, elimine el grupo de recursos que creó en la región de destino; esto eliminará la red virtual trasladada.
Para quitar el grupo de recursos, use Remove-AzResourceGroup:

Remove-AzResourceGroup -Name <target-resource-group-name>

Limpieza
Para confirmar los cambios y completar el traslado de la red virtual, realice una de las acciones siguientes:
Elimine el grupo de recursos con Remove-AzResourceGroup:

Remove-AzResourceGroup -Name <source-resource-group-name>

Elimine la red virtual de origen con Remove-AzVirtualNetwork:

Remove-AzVirtualNetwork -Name <source-virtual-network-name> -ResourceGroupName <source-resource-group-

name>

Pasos siguientes
En este tutorial, ha movido una red virtual de una región a otra mediante PowerShell y, a continuación, ha limpiado
los recursos de origen innecesarios. Para más información sobre el traslado de recursos entre regiones y la
recuperación ante desastres en Azure, consulte:
Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción
Traslado de máquinas virtuales de Azure a otra región
 Migración de una configuración de dirección IP
pública de Azure a otra región mediante Azure Portal
23/09/2020 • 10 minutes to read • Edit Online

Hay varios escenarios en los que puede ser conveniente migrar las configuraciones existentes de dirección IP
pública de Azure de una región a otra. Por ejemplo, quiere crear una dirección IP pública con la misma
configuración y SKU para las pruebas. También, puede que, como parte del planeamiento de la recuperación ante
desastres, quiera migrar una configuración de dirección IP pública a otra región.
Las direcciones IP públicas de Azure son específicas de la región y no se pueden migrar de una
región a otra. Sin embargo, puede usar una plantilla de Azure Resource Manager para exportar la configuración
actual de una dirección IP pública. Después, puede preparar el recurso en otra región exportando la dirección IP
pública a una plantilla y modificando los parámetros para que coincidan con la región de destino, y luego
implementar la plantilla en la nueva región. Para más información sobre Resource Manager y las plantillas, consulte
Inicio rápido: Creación e implementación de plantillas de Azure Resource Manager mediante Azure Portal.

Requisitos previos
Asegúrese de que la dirección IP pública de Azure se encuentra en la región de Azure desde la que va a
moverla.
Las direcciones IP públicas de Azure no se pueden mover entre regiones. Tendrá que asociar la nueva
dirección IP pública a los recursos de la región de destino.
Para exportar una configuración de IP pública e implementar una plantilla para crear una dirección IP pública
en otra región, necesitará el rol de colaborador de red u otro superior.
Identifique el diseño de red de origen y todos los recursos que está usando actualmente. Este diseño incluye,
pero no se limita a, los equilibradores de carga, los grupos de seguridad de red (NSG) y las redes virtuales.
Compruebe que su suscripción de Azure permite crear direcciones IP públicas en la región de destino que se
usa. Para habilitar la cuota necesaria, póngase en contacto con el soporte técnico.
Asegúrese de que la suscripción tiene suficientes recursos para admitir la adición de direcciones IP públicas
para este proceso. Vea Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.

Preparación y traslado
En los pasos siguientes se muestra cómo preparar la dirección IP pública para mover la configuración mediante
una plantilla de Resource Manager y cómo mover la configuración de IP pública a la región de destino mediante
Azure Portal.
Exportación de la plantilla e implementación desde un script
1. Inicie sesión en Azure Portal > Grupos de recursos .
2. Busque el grupo de recursos que contiene la dirección IP pública de origen y haga clic en él.
3. Seleccione > Configuración > Expor tar plantilla .
4. En la hoja Expor tar plantilla , elija Implementar .
5. Haga clic en PL ANTILL A > Editar parámetros para abrir el archivo [Link] en el editor en
línea.
 6. Para editar el parámetro del nombre de la dirección IP pública, cambie la propiedad en parameters > value
del nombre de la dirección IP pública de origen al nombre de la dirección IP pública de destino. Asegúrese
de que el nombre se encuentra entre comillas:

{
"$schema": "[Link]
"contentVersion": "[Link]",
"parameters": {
"publicIPAddresses_myVM1pubIP_name": {
"value": "<target-publicip-name>"
}
}
}

7. Haga clic en Guardar en el editor.

8. Haga clic en Plantilla > Editar plantilla para abrir el archivo [Link] en el editor en línea.
9. Para editar la región de destino a la que se va a mover la dirección IP pública, cambie la propiedad location
en resources :

"resources": [
{
"type": "[Link]/publicIPAddresses",
"apiVersion": "2019-06-01",
"name": "[parameters('publicIPAddresses_myPubIP_name')]",
"location": "<target-region>",
"sku": {
"name": "Basic",
"tier": "Regional"
},
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "7549a8f1-80c2-481a-a073-018f5b0b69be",
"ipAddress": "[Link]",
"publicIPAddressVersion": "IPv4",
"publicIPAllocationMethod": "Dynamic",
"idleTimeoutInMinutes": 4,
"ipTags": []
}
}
]

10. Para obtener los códigos de ubicación de la región, consulte Ubicaciones de Azure. El código de una región es
el nombre de la región sin espacios, Centro de EE. UU. = centralus .
11. También puede cambiar otros parámetros de la plantilla si así lo desea; son opcionales según sus requisitos:
SKU : puede cambiar la SKU de la dirección IP pública de la configuración de estándar a básica o
viceversa modificando la propiedad sku > name en el archivo [Link] :
 "resources": [
{
"type": "[Link]/publicIPAddresses",
"apiVersion": "2019-06-01",
"name": "[parameters('publicIPAddresses_myPubIP_name')]",
"location": "<target-region>",
"sku": {
"name": "Basic",
"tier": "Regional"
},

Para más información sobre las diferencias entre las direcciones IP públicas de la SKU básica y
estándar, consulte Creación, modificación o eliminación de una dirección IP pública:
Método de asignación de IP pública y tiempo de espera de inactividad : puede cambiar estas
dos opciones en la plantilla si cambia la propiedad publicIPAllocationMethod de Dynamic a Static
o bien de Static a Dynamic . El tiempo de espera de inactividad se puede cambiar modificando la
propiedad idleTimeoutInMinutes con la cantidad deseada. El valor predeterminado es 4 :

"resources": [
{
"type": "[Link]/publicIPAddresses",
"apiVersion": "2019-06-01",
"name": "[parameters('publicIPAddresses_myPubIP_name')]",
"location": "<target-region>",
"sku": {
"name": "Basic",
"tier": "Regional"
},
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "7549a8f1-80c2-481a-a073-018f5b0b69be",
"ipAddress": "[Link]",
"publicIPAddressVersion": "IPv4",
"publicIPAllocationMethod": "Dynamic",
"idleTimeoutInMinutes": 4,
"ipTags": []

Para más información sobre los métodos de asignación y los valores de tiempo de espera de
inactividad, consulte Creación, modificación o eliminación de una dirección IP pública.
12. Haga clic en Guardar en el editor en línea.
13. Haga clic en Aspectos básicos > Suscripción para elegir la suscripción donde se implementará la
dirección IP pública de destino.
14. Haga clic en Aspectos básicos > Grupo de recursos para elegir el grupo de recursos donde se
implementará la dirección IP pública de destino. Puede hacer clic en Crear nuevo para crear un grupo de
recursos para la dirección IP pública de destino. Asegúrese de que el nombre no sea el mismo que el del
grupo de recursos de origen de la dirección IP pública de origen existente.
15. Compruebe que Aspectos básicos > Ubicación está establecido en la ubicación de destino en la que
quiere que se implemente la dirección IP pública.
16. En CONFIGURACIÓN , compruebe que el nombre coincide con el nombre que especificó en el editor de
parámetros anterior.
17. Marque la casilla en TÉRMINOS Y CONDICIONES .
18. Haga clic en el botón Comprar para implementar la dirección IP pública de destino.
Discard (Descartar)
Si quiere descartar la dirección IP pública de destino, elimine el grupo de recursos que la contiene. Para ello, en el
portal, seleccione el grupo de recursos en el panel y, luego, Eliminar en la parte superior de la página de
información general.

Limpieza
Para confirmar los cambios y completar el movimiento de la dirección IP pública de destino, elimine la dirección IP
pública de origen o el grupo de recursos. Para ello, en el portal, seleccione la dirección IP pública o el grupo de
recursos en el panel y seleccione Eliminar en la parte superior de cada página.

Pasos siguientes
En este tutorial, ha movido una dirección IP pública de Azure de una región a otra y ha limpiado los recursos de
origen. Para obtener más información sobre cómo trasladar recursos entre regiones y la recuperación ante
desastres en Azure, consulte:
Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción
Traslado de máquinas virtuales de Azure a otra región
 Migración de la configuración de dirección IP pública
de Azure a otra región mediante Azure PowerShell
23/09/2020 • 10 minutes to read • Edit Online

Hay varios escenarios en los que puede ser conveniente migrar las configuraciones existentes de dirección IP
pública de Azure de una región a otra. Por ejemplo, quiere crear una dirección IP pública con la misma
configuración y SKU para las pruebas. También, puede que, como parte del planeamiento de la recuperación ante
desastres, quiera migrar una configuración de dirección IP pública a otra región.
Las direcciones IP públicas de Azure son específicas de la región y no se pueden migrar de una
región a otra. Sin embargo, puede usar una plantilla de Azure Resource Manager para exportar la configuración
actual de una dirección IP pública. Después, puede preparar el recurso en otra región exportando la dirección IP
pública a una plantilla y modificando los parámetros para que coincidan con la región de destino, y luego
implementar la plantilla en la nueva región. Para más información sobre Resource Manager y sus plantillas, consulte
Exportación de grupos de recursos a plantillas.

Requisitos previos
Asegúrese de que la dirección IP pública de Azure se encuentra en la región de Azure desde la que va a
moverla.
Las direcciones IP públicas de Azure no se pueden migrar entre regiones. Tendrá que asociar la nueva
dirección IP pública a los recursos de la región de destino.
Para exportar una configuración de IP pública e implementar una plantilla para crear una dirección IP pública
en otra región, necesitará el rol de colaborador de red u otro superior.
Identifique el diseño de red de origen y todos los recursos que está usando actualmente. Este diseño incluye,
pero no se limita a, los equilibradores de carga, los grupos de seguridad de red (NSG) y las redes virtuales.
Compruebe que su suscripción de Azure permite crear direcciones IP públicas en la región de destino que se
usa. Para habilitar la cuota necesaria, póngase en contacto con el soporte técnico.
Asegúrese de que la suscripción tiene suficientes recursos para admitir la adición de direcciones IP públicas
para este proceso. Vea Límites, cuotas y restricciones de suscripción y servicios de Microsoft Azure.

Preparación y traslado
En los pasos siguientes se muestra cómo preparar la dirección IP pública para trasladar la configuración mediante
una plantilla de Resource Manager y cómo trasladar la configuración de IP pública a la región de destino mediante
Azure PowerShell.

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Exportación de la plantilla e implementación desde un script

1. Inicie sesión en la suscripción a Azure con el comando Connect-AzAccount y siga las instrucciones de la
pantalla:

Connect-AzAccount

2. Obtenga el Id. de recurso de la dirección IP pública que quiere trasladar a la región de destino y colóquelo en
una variable mediante Get-AzPublicIPAddress:

$sourcePubIPID = (Get-AzPublicIPaddress -Name <source-public-ip-name> -ResourceGroupName <source-

resource-group-name>).Id

3. Exporte la red virtual de origen a un archivo .json en el directorio donde se ejecuta el comando Export-
AzResourceGroup:

Export-AzResourceGroup -ResourceGroupName <source-resource-group-name> -Resource $sourceVNETID -

IncludeParameterDefaultValue

4. El nombre del archivo descargado se asignará en función del grupo de recursos desde el que se exportó el
recurso. Busque el archivo que se exportó con el comando denominado <resource-group-name>.json y
ábralo en el editor que prefiera:

notepad <source-resource-group-name>.json

5. Para editar el parámetro del nombre de la dirección IP pública, cambie el valor defaultValue de la
propiedad del nombre de la IP pública de origen por el nombre de la dirección IP pública de destino.
Asegúrese de que el nombre se encuentra entre comillas:

{
"$schema": "[Link]
"contentVersion": "[Link]",
"parameters": {
"publicIPAddresses_myVM1pubIP_name": {
"defaultValue": "<target-publicip-name>",
"type": "String"
}
}

6. Para editar la región de destino a la que se va a trasladar la dirección IP pública, cambie la propiedad
location en resources:
 "resources": [
{
"type": "[Link]/publicIPAddresses",
"apiVersion": "2019-06-01",
"name": "[parameters('publicIPAddresses_myPubIP_name')]",
"location": "<target-region>",
"sku": {
"name": "Basic",
"tier": "Regional"
},
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "7549a8f1-80c2-481a-a073-018f5b0b69be",
"ipAddress": "[Link]",
"publicIPAddressVersion": "IPv4",
"publicIPAllocationMethod": "Dynamic",
"idleTimeoutInMinutes": 4,
"ipTags": []
}
}
]

7. Para obtener los códigos de ubicación de la región, puede usar el cmdlet Azure PowerShell Get-AzLocation al
ejecutar el siguiente comando:

Get-AzLocation | format-table

8. También puede cambiar otros parámetros de la plantilla si así lo desea; son opcionales según sus requisitos:
SKU : puede cambiar la SKU de la dirección IP pública de la configuración de estándar a básica o
viceversa modificando la propiedad sku > name en el archivo <resource-group-name>.json :

"resources": [
{
"type": "[Link]/publicIPAddresses",
"apiVersion": "2019-06-01",
"name": "[parameters('publicIPAddresses_myPubIP_name')]",
"location": "<target-region>",
"sku": {
"name": "Basic",
"tier": "Regional"
},

Para más información sobre las diferencias entre las IP públicas de la SKU básica y estándar, consulte
Creación, modificación o eliminación de una dirección IP pública.
Método de asignación de IP pública y tiempo de espera de inactividad : puede cambiar estas
dos opciones en la plantilla si cambia la propiedad publicIPAllocationMethod de Dynamic a Static
o bien de Static a Dynamic . El tiempo de espera de inactividad se puede cambiar modificando la
propiedad idleTimeoutInMinutes con la cantidad deseada. El valor predeterminado es 4 :
 "resources": [
{
"type": "[Link]/publicIPAddresses",
"apiVersion": "2019-06-01",
"name": "[parameters('publicIPAddresses_myPubIP_name')]",
"location": "<target-region>",
"sku": {
"name": "Basic",
"tier": "Regional"
},
"properties": {
"provisioningState": "Succeeded",
"resourceGuid": "7549a8f1-80c2-481a-a073-018f5b0b69be",
"ipAddress": "[Link]",
"publicIPAddressVersion": "IPv4",
"publicIPAllocationMethod": "Dynamic",
"idleTimeoutInMinutes": 4,
"ipTags": []
}
}

Para más información sobre los métodos de asignación y los valores de tiempo de espera de
inactividad, consulte Creación, modificación o eliminación de una dirección IP pública.
9. Guarde el archivo <resource-group-name>.json .
10. Cree un grupo de recursos en la región de destino para la dirección IP pública de destino que se va a
implementar mediante New-AzResourceGroup.

New-AzResourceGroup -Name <target-resource-group-name> -location <target-region>

11. Implemente el archivo <resource-group-name>.json editado en el grupo de recursos que creó en el

paso anterior mediante New-AzResourceGroupDeployment:

New-AzResourceGroupDeployment -ResourceGroupName <target-resource-group-name> -TemplateFile <source-

resource-group-name>.json

12. Para comprobar que los recursos se crearon en la región de destino, use los comandos Get-
AzResourceGroup y Get-AzPublicIPAddress:

Get-AzResourceGroup -Name <target-resource-group-name>

Get-AzPublicIPAddress -Name <target-publicip-name> -ResourceGroupName <target-resource-group-name>

Discard (Descartar)
Después de la implementación, si quiere empezar de nuevo o descartar la dirección IP pública en el destino, elimine
el grupo de recursos que se creó en el destino y se eliminará la dirección IP pública trasladada. Para quitar el grupo
de recursos, use Remove-AzResourceGroup:
 Remove-AzResourceGroup -Name <target-resource-group-name>

Limpieza
Para confirmar los cambios y completar el traslado de la red virtual, elimine la red virtual o el grupo de recursos de
origen mediante Remove-AzResourceGroup o Remove-AzPublicIPAddress:

Remove-AzResourceGroup -Name <source-resource-group-name>

Remove-AzPublicIpAddress -Name <source-publicip-name> -ResourceGroupName <resource-group-name>

Pasos siguientes
En este tutorial, ha movido una dirección IP pública de Azure de una región a otra y ha limpiado los recursos de
origen. Para obtener más información sobre cómo trasladar recursos entre regiones y la recuperación ante
desastres en Azure, consulte:
Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción
Traslado de máquinas virtuales de Azure a otra región
 Tutorial: Creación de una puerta de enlace de NAT
mediante Azure PowerShell
23/09/2020 • 16 minutes to read • Edit Online

En este tutorial se muestra cómo usar el servicio Azure Virtual Network NAT. Creará una puerta de enlace de
NAT para proporcionar conectividad saliente para una máquina virtual en Azure.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el
explorador. Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar
los comandos preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada
en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se
copia automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Puede realizar este tutorial con Azure Cloud Shell o ejecutar los comandos de forma local. Si no ha usado Azure
Cloud Shell, inicie sesión ahora.

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de
AzureRM que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más
información acerca del nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure
PowerShell Az module (Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la
instalación del módulo Az, consulte Instalación de Azure PowerShell.
Crear un grupo de recursos
Cree un grupo de recursos con New-AzResourceGroup. Un grupo de recursos de Azure es un contenedor lógico
en el que se implementan y se administran los recursos de Azure.
En el ejemplo siguiente se crea un grupo de recursos llamado myResourceGroupNAT en la ubicación
eastus2 :

$rsg = 'myResourceGroupNAT'
$loc = 'eastus2'

New-AzResourceGroup -Name $rsg -Location $loc

Creación de la puerta de enlace de NAT

Las opciones de IP pública de la puerta de enlace de NAT son:
Direcciones IP públicas
Prefijos de dirección IP pública
Ambos se pueden usar con la puerta de enlace de NAT.
Para demostrarlo, se va a agregar una dirección IP pública y un prefijo de dirección IP pública a este escenario.
Crear una dirección IP pública
Para acceder a Internet, necesita una o varias direcciones IP públicas para la puerta de enlace de NAT. Use New-
AzPublicIpAddress para crear el recurso de dirección IP pública llamado myPublicIP en
myResourceGroupNAT . El resultado de este comando se almacenará en una variable $publicIP para su uso
posterior.

$rsg = 'myResourceGroupNAT'
$loc = 'eastus2'
$sku = 'Standard'
$pbnm = 'myPublicIP'

$publicIP =
New-AzPublicIpAddress -Name $pbnm -ResourceGroupName $rsg -AllocationMethod Static -Location $loc -Sku $sku

Creación de un prefijo de dirección IP pública

Use New-AzPublicIpPrefix para crear un recurso de prefijo de dirección IP pública llamado myPublicIPprefix
en myResourceGroupNAT . El resultado de este comando se almacenará en una variable llamada
$publicIPPrefix para su uso posterior.

$rsg = 'myResourceGroupNAT'
$loc = 'eastus2'
$pxnm = 'myPublicIPprefix'

$publicIPPrefix =
New-AzPublicIpPrefix -Name $pxnm -ResourceGroupName $rsg -Location $loc -PrefixLength 31

Creación de un recurso de puerta de enlace de NAT

En esta sección se detalla cómo crear y configurar los componentes siguientes del servicio NAT mediante el
recurso de puerta de enlace de NAT:
Un grupo de direcciones IP públicas y un prefijo de dirección IP pública que se usarán en los flujos salientes
traducidos por el recurso de puerta de enlace de NAT.
 Cambie el tiempo de espera de inactividad de 4 (el valor predeterminado) a 10 minutos.
Cree una puerta de enlace de NAT de Azure global con New-AzNatGateway. El resultado de este comando
creará un recurso de puerta de enlace llamado myNATgateway que usa la dirección IP pública myPublicIP y
el prefijo de dirección IP pública myPublicIPprefix . El tiempo de espera de inactividad se establece en 10
minutos. El resultado de este comando se almacenará en una variable llamada $natGateway para su uso
posterior.

$rsg = 'myResourceGroupNAT'
$loc = 'eastus2'
$sku = 'Standard'
$gnm = 'myNATgateway'

$natGateway =
New-AzNatGateway -Name $gnm -ResourceGroupName $rsg -PublicIpAddress $publicIP -PublicIpPrefix
$publicIPPrefix -Location $loc -Sku $sku -IdleTimeoutInMinutes 10

En este momento, la puerta de enlace de NAT es funcional y todo lo que queda es configurar qué subredes de
una red virtual deben usarla.

Configurar la red virtual

Cree la red virtual y asocie la subred a la puerta de enlace.
Cree una red virtual denominada myVnet con una subred llamada mySubnet con New-
AzVirtualNetworkSubnetConfig en myResourceGroup usando New-AzVirtualNetwork. El espacio de
direcciones IP de la red virtual es [Link]/16 . La subred de la red virtual es [Link]/24 . El resultado
de los comandos se almacenará en las variables llamadas $subnet y $Vnet para su uso posterior.

$sbnm = 'mySubnet'
$vnnm = 'myVnet'
$rsg = 'myResourceGroupNAT'
$loc = 'eastus2'
$pfxsub = '[Link]/24'
$pfxvn = '[Link]/16'

$subnet =
New-AzVirtualNetworkSubnetConfig -Name $sbnm -AddressPrefix $pfxsub -NatGateway $natGateway

$vnet =
New-AzVirtualNetwork -Name $vnnm -ResourceGroupName $rsg -Location $loc -AddressPrefix $pfxvn -Subnet
$subnet

Todo el tráfico saliente a destinos de Internet usa ahora el servicio NAT. No es necesario configurar una UDR.

Creación de una máquina virtual para usar el servicio NAT

Ahora se va a crear una máquina virtual para usar el servicio NAT. Esta máquina virtual tiene una dirección IP
pública en el nivel de instancia que le permite el acceso a la máquina virtual. El servicio NAT tiene en cuenta la
dirección del flujo y reemplazará el destino predeterminado de Internet en la subred. La dirección IP pública de
la máquina virtual no se usará para las conexiones salientes.
Creación de una dirección IP pública para la máquina virtual de origen
Se va a crear una dirección IP pública que se usará para acceder a la máquina virtual. Use New-
AzPublicIpAddress para crear el recurso de dirección IP pública llamado myPublicIPVM en
myResourceGroupNAT . El resultado de este comando se almacenará en una variable llamada $publicIpVM
para su uso posterior.
 $rsg = 'myResourceGroupNAT'
$loc = 'eastus2'
$ipnm = 'myPublicIPVM'
$sku = 'Standard'

$publicIpVM =
New-AzPublicIpAddress -Name $ipnm -ResourceGroupName $rsg -AllocationMethod Static -Location $loc -Sku $sku

Creación de un grupo de seguridad de red y exposición del punto de conexión de SSH para la máquina
virtual
Las direcciones IP públicas estándar son "seguras de forma predeterminada", por lo que deberá crear un grupo
de seguridad de red para permitir el acceso de entrada mediante SSH. Use New-AzNetworkSecurityGroup para
crear un recurso de grupo de seguridad de red llamado myNSG . Use New-AzNetworkSecurityRuleConfig para
crear una regla de grupo de seguridad de red para el acceso mediante SSH llamada ssh en
myResourceGroupNAT . El resultado de este comando se almacenará en una variable llamada $nsg para su
uso posterior.

$rnm = 'ssh'
$rdesc = 'SSH access'
$acc = 'Allow'
$pro = 'Tcp'
$dir = 'Inbound'
$pri = '100'
$prt = '22'
$rsg = 'myResourceGroupNAT'
$rnm = 'myNSG'
$loc = 'eastus2'

$sshrule =
New-AzNetworkSecurityRuleConfig -Name $rnm -Description $rdesc -Access $acc -Protocol $pro -Direction $dir
-Priority $pri -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange
$prt

$nsg =
New-AzNetworkSecurityGroup -ResourceGroupName $rsg -Name $rnm -Location $loc -SecurityRules $sshrule

Creación de una NIC para una máquina virtual

Cree una interfaz de red con New-AzNetworkInterface llamada myNic . Este comando asocia la dirección IP
pública y el grupo de seguridad de red. El resultado de este comando se almacenará en una variable llamada
$nic para su uso posterior.

$rsg = 'myResourceGroupNAT'
$nmn = 'myNic'
$loc = 'eastus2'

$nic =
New-AzNetworkInterface -ResourceGroupName $rsg -Name $nmn -NetworkSecurityGroupID $[Link] -
PublicIPAddressID $[Link] -SubnetID $[Link][0].Id -Location $loc

Creación de una máquina virtual

Creación del par de claves SSH
Necesita un par de claves SSH para completar esta guía de inicio rápido. Si ya tiene un par de claves SSH, puede
omitir este paso.
Use ssh-keygen para crear un par de claves SSH.
 ssh-keygen -t rsa -b 2048

Para más información sobre cómo crear pares de claves SSH, incluido el uso de PuTTy, consulte Uso de claves
SSH con Windows.
Si crea el par de claves SSH mediante Cloud Shell, se almacenará en una imagen de contenedor. Esta cuenta de
almacenamiento se crea automáticamente. No elimine la cuenta de almacenamiento, ni el recurso compartido
de archivos que contiene, hasta que haya recuperado las claves.
Creación de una configuración de máquina virtual
Para crear una máquina virtual en PowerShell, cree una configuración que tenga valores para la imagen que se
va a usar y las opciones de tamaño y autenticación. La configuración se usa para crear la máquina virtual.
Defina las credenciales de SSH, la información del sistema operativo y el tamaño de máquina virtual. En este
ejemplo, la clave SSH se almacena en ~/.ssh/id_rsa.pub.

#Define a credential object

$securePassword =
ConvertTo-SecureString ' ' -AsPlainText -Force

$cred =
New-Object [Link] ("azureuser", $securePassword)

# Create a virtual machine configuration

$vnm = 'myVM'
$vsz = 'Standard_D1'
$pub = 'Canonical'
$off = 'UbuntuServer'
$sku = '18.04-LTS'
$ver = 'latest'

$vmConfig =
New-AzVMConfig -VMName $vnm -VMSize $vsz

Set-AzVMOperatingSystem -VM $vmConfig -Linux -ComputerName $vnm -Credential $cred -

DisablePasswordAuthentication

Set-AzVMSourceImage -VM $vmConfig -PublisherName $pub -Offer $off -Skus $sku -Version $ver

Add-AzVMNetworkInterface -VM $vmConfig -Id $[Link]

# Configure the SSH key

$sshPublicKey = cat ~/.ssh/id_rsa.pub

Add-AzVMSshPublicKey -VM $vmconfig -KeyData $sshPublicKey -Path "/home/azureuser/.ssh/authorized_keys"

Combine las definiciones de configuración para crear una máquina virtual llamada myVM con New-AzVM en
myResourceGroupNAT .

$rsg = 'myResourceGroupNAT'
$loc = 'eastus2'

New-AzVM -ResourceGroupName $rsg -Location $loc -VM $vmconfig

Espere a que la máquina virtual se prepare para la implementación y continúe con el resto de los pasos.
Detección de la dirección IP de la máquina virtual
En primer lugar, es necesario detectar la dirección IP de la máquina virtual que ha creado. Para obtener la
dirección IP pública de la máquina virtual, use Get-AzPublicIpAddress.

$rsg = 'myResourceGroupNAT'
$nmn = 'myPublicIPVM'

Get-AzPublicIpAddress -ResourceGroupName $rsg -Name $nmn | select IpAddress

IMPORTANT
Copie la dirección IP pública y, luego, péguela en un bloc de notas para que pueda usarla para acceder a la máquina
virtual.

Inicio de sesión en la máquina virtual

Las credenciales de SSH deben almacenarse en la instancia de Cloud Shell de la operación anterior. Abra Azure
Cloud Shell en el explorador. Use la dirección IP recuperada en el paso anterior para conectarse a la máquina
virtual mediante SSH.

ssh azureuser@<ip-address-destination>

Ahora está listo para usar el servicio NAT.

Limpieza de recursos
Cuando ya no lo necesite, puede usar el comando Remove-AzResourceGroup para quitar el grupo de recursos y
todos los recursos que contiene.

Remove-AzResourceGroup -Name myResourceGroupNAT

Pasos siguientes
En este tutorial, ha creado una puerta de enlace de NAT y una máquina virtual para usarla.
Revise las métricas de Azure Monitor para ver el funcionamiento del servicio NAT. Diagnostique problemas
como el agotamiento de recursos de los puertos SNAT disponibles. El agotamiento de recursos de los puertos
SNAT se soluciona agregando recursos de dirección IP pública o recursos de prefijo de dirección IP pública
adicionales (o ambos).
Obtenga más información sobre Azure Virtual Network NAT.
Más información sobre recursos de puerta de enlace de NAT.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con la CLI de Azure.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con PowerShell.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con Azure Portal.
 Creación de una puerta de enlace de NAT con la
CLI de Azure
23/09/2020 • 13 minutes to read • Edit Online

En este tutorial se muestra cómo usar el servicio Azure Virtual Network NAT. Creará una puerta de enlace de
NAT para proporcionar conectividad saliente para una máquina virtual en Azure.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el
explorador. Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar
los comandos preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada
en su entorno local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se
copia automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Puede realizar este tutorial con Azure Cloud Shell o ejecutar los comandos respectivos de forma local. Si nunca
ha usado Azure Cloud Shell, inicie sesión ahora para recorrer la configuración inicial. Si elige ejecutar estos
comandos de forma local, debe instalar la CLI. En este tutorial es necesario ejecutar la versión 2.0.71 de la CLI de
Azure o cualquier versión posterior. Para encontrar la versión, ejecute az --version . Si necesita instalarla o
actualizarla, vea Instalación de la CLI de Azure.

Crear un grupo de recursos

Cree un grupo de recursos con az group create. Un grupo de recursos de Azure es un contenedor lógico en el
que se implementan y se administran los recursos de Azure.
En el ejemplo siguiente se crea un grupo de recursos llamado myResourceGroupNAT en la ubicación
eastus2 :

az group create \
--name myResourceGroupNAT \
--location eastus2

Creación de la puerta de enlace de NAT

Crear una dirección IP pública
Para acceder a la red pública de Internet, necesita una o varias direcciones IP públicas para la puerta de enlace
de NAT. Use az network public-ip create para crear un recurso de dirección IP pública llamado myPublicIP en
myResourceGroupNAT .

az network public-ip create \

--resource-group myResourceGroupNAT \
--name myPublicIP \
--sku standard

Creación de un prefijo de dirección IP pública

Puede usar uno o varios recursos de dirección IP pública o prefijos de dirección IP pública (o ambos) con la
puerta de enlace de NAT. Para demostrarlo, vamos a agregar un recurso de prefijo de dirección IP pública a este
escenario. Use az network public-ip prefix create para crear un recurso de prefijo de dirección IP pública llamado
myPublicIPprefix en myResourceGroupNAT .

az network public-ip prefix create \

--resource-group myResourceGroupNAT \
--name myPublicIPprefix \
--length 31

Creación de un recurso de puerta de enlace de NAT

En esta sección se detalla cómo crear y configurar los componentes siguientes del servicio NAT mediante el
recurso de puerta de enlace de NAT:
Un grupo de direcciones IP públicas y un prefijo de dirección IP pública que se usarán en los flujos salientes
traducidos por el recurso de puerta de enlace de NAT.
Cambie el tiempo de espera de inactividad de 4 (el valor predeterminado) a 10 minutos.
Cree una puerta de enlace de NAT de Azure global con az network nat gateway create llamada myNATgateway .
El comando usa la dirección IP pública myPublicIP y el prefijo de dirección IP pública myPublicIPprefix . El
comando cambia el tiempo de espera de inactividad a 10 minutos.

az network nat gateway create \

--resource-group myResourceGroupNAT \
--name myNATgateway \
--public-ip-addresses myPublicIP \
--public-ip-prefixes myPublicIPprefix \
--idle-timeout 10

En este momento, la puerta de enlace de NAT es funcional y todo lo que queda es configurar qué subredes de
una red virtual deben usarla.

Configurar la red virtual

Antes de implementar una máquina virtual y poder usar la puerta de enlace de NAT, es necesario crear la red
virtual.
Cree una red virtual llamada myVnet con una subred llamada mySubnet en myResourceGroupNAT con el
comando az network vnet create. El espacio de direcciones IP de la red virtual es [Link]/16 . La subred de
la red virtual es [Link]/24 .

az network vnet create \

--resource-group myResourceGroupNAT \
--location eastus2 \
--name myVnet \
--address-prefix [Link]/16 \
--subnet-name mySubnet \
--subnet-prefix [Link]/24

Configuración del servicio NAT para la subred de origen

Se va a configurar la subred de origen mySubnet de la red virtual myVnet para usar el recurso de puerta de
enlace de NAT concreto myNATgateway con az network vnet subnet update. Este comando activará el servicio
NAT en la subred especificada.

az network vnet subnet update \

--resource-group myResourceGroupNAT \
--vnet-name myVnet \
--name mySubnet \
--nat-gateway myNATgateway

Todo el tráfico saliente a destinos de Internet usa ahora la puerta de enlace de NAT. No es necesario configurar
una UDR.

Creación de una máquina virtual para usar el servicio NAT

Ahora se va a crear una máquina virtual para usar el servicio NAT. Esta máquina virtual tiene una dirección IP
pública en el nivel de instancia que le permite el acceso a la máquina virtual. El servicio NAT tiene en cuenta la
dirección del flujo y reemplazará el destino predeterminado de Internet en la subred. La dirección IP pública de
la máquina virtual no se usará para las conexiones salientes.
Creación de una dirección IP pública para la máquina virtual de origen
Se va a crear una dirección IP pública que se usará para acceder a la máquina virtual. Use az network public-ip
create para crear un recurso de dirección IP pública llamado myPublicIPVM en myResourceGroupNAT .

az network public-ip create \

--resource-group myResourceGroupNAT \
--name myPublicIPVM \
--sku standard

Creación de un grupo de seguridad de red para la máquina virtual

Dado que las direcciones IP públicas estándar son "seguras de forma predeterminada", es necesario crear un
grupo de seguridad de red para permitir el acceso de entrada mediante SSH. Use az network nsg create para
crear un recurso de grupo de seguridad de red llamado myNSG en myResourceGroupNAT .

az network nsg create \

--resource-group myResourceGroupNAT \
--name myNSG
Exposición del punto de conexión SSH en la máquina virtual de origen
Se va a crear una regla en el grupo de seguridad de red para el acceso mediante SSH a la máquina virtual de
origen. Use az network nsg rule create para crear una regla de grupo de seguridad de red llamada ssh en el
grupo de seguridad de red llamado myNSG en myResourceGroupNAT .

az network nsg rule create \

--resource-group myResourceGroupNAT \
--nsg-name myNSG \
--priority 100 \
--name ssh \
--description "SSH access" \
--access allow \
--protocol tcp \
--direction inbound \
--destination-port-ranges 22

Creación de una NIC para una máquina virtual

Cree una interfaz de red con el comando az network nic create y asóciela a la dirección IP pública y al grupo de
seguridad de red.

az network nic create \

--resource-group myResourceGroupNAT \
--name myNic \
--vnet-name myVnet \
--subnet mySubnet \
--public-ip-address myPublicIPVM \
--network-security-group myNSG

Creación de una máquina virtual

Cree la máquina virtual con az vm create. Se van a generar claves SSH para esta máquina virtual y se va a
almacenar la clave privada para usarla más adelante.

az vm create \
--resource-group myResourceGroupNAT \
--name myVM \
--nics myNic \
--image UbuntuLTS \
--generate-ssh-keys

Espere a que la máquina virtual se implemente y continúe con el resto de los pasos.

Detección de la dirección IP de la máquina virtual

En primer lugar, es necesario detectar la dirección IP de la máquina virtual que ha creado. Para recuperar la
dirección IP pública de la máquina virtual, use az network public-ip show.

az network public-ip show \

--resource-group myResourceGroupNAT \
--name myPublicIPVM \
--query [ipAddress] \
--output tsv
 IMPORTANT
Copie la dirección IP pública y, luego, péguela en un bloc de notas para que pueda usarla para acceder a la máquina
virtual.

Inicio de sesión en la máquina virtual

Las credenciales de SSH deben almacenarse en la instancia de Cloud Shell de la operación anterior. Abra Azure
Cloud Shell en el explorador. Use la dirección IP recuperada en el paso anterior para conectarse a la máquina
virtual mediante SSH.

ssh <ip-address-destination>

Ahora está listo para usar el servicio NAT.

Limpieza de recursos
Cuando ya no lo necesite, puede usar el comando az group delete para quitar el grupo de recursos y todos los
recursos que contiene.

az group delete \
--name myResourceGroupNAT

Pasos siguientes
En este tutorial, ha creado una puerta de enlace de NAT y una máquina virtual para usarla.
Revise las métricas de Azure Monitor para ver el funcionamiento del servicio NAT. Diagnostique problemas
como el agotamiento de recursos de los puertos SNAT disponibles. El agotamiento de recursos de los puertos
SNAT se soluciona agregando recursos de dirección IP pública o recursos de prefijo de dirección IP pública
adicionales (o ambos).
Obtenga más información sobre Azure Virtual Network NAT.
Más información sobre recursos de puerta de enlace de NAT.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con la CLI de Azure.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con PowerShell.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con Azure Portal.
 Creación de una puerta de enlace NAT - plantilla de
Resource Manager
23/09/2020 • 7 minutes to read • Edit Online

Introducción a Virtual Network NAT mediante una plantilla de Azure Resource Manager. Esta plantilla implementa
una red virtual, un recurso de puerta de enlace NAT y una máquina virtual con Ubuntu. La máquina virtual con
Ubuntu se implementa en una subred que está asociada al recurso de puerta de enlace NAT.
Una plantilla de Resource Manager es un archivo de notación de objetos JavaScript (JSON) que define la
infraestructura y la configuración del proyecto. La plantilla usa sintaxis declarativa, lo que permite establecer lo que
pretende implementar sin tener que escribir la secuencia de comandos de programación para crearla.
Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.

Creación de una puerta de enlace NAT y recursos auxiliares

Esta plantilla está configurada para crear lo siguiente:
Virtual network
Recurso de puerta de enlace NAT
Máquina virtual con Ubuntu
La máquina virtual con Ubuntu se implementa en una subred que está asociada al recurso de puerta de enlace
NAT.
Revisión de la plantilla
La plantilla usada en este inicio rápido forma parte de las plantillas de inicio rápido de Azure.

{
"$schema": "[Link]
"contentVersion": "[Link]",
"parameters": {
"vmname": {
"defaultValue": "myVM",
"type": "String",
"metadata": {
"description": "Name of the virtual machine"
}
},
"vmsize": {
"defaultValue": "Standard_D2s_v3",
"type": "String",
"metadata": {
"description": "Size of the virtual machine"
}
},
"vnetname": {
"defaultValue": "myVnet",
"type": "String",
"metadata": {
"description": "Name of the virtual network"
}
},
"subnetname": {
"defaultValue": "mySubnet",
"type": "String",
"metadata": {
 "metadata": {
"description": "Name of the subnet for virtual network"
}
},
"vnetaddressspace": {
"defaultValue": "[Link]/16",
"type": "String",
"metadata": {
"description": "Address space for virtual network"
}
},
"vnetsubnetprefix": {
"defaultValue": "[Link]/24",
"type": "String",
"metadata": {
"description": "Subnet prefix for virtual network"
}
},
"natgatewayname": {
"defaultValue": "myNATgateway",
"type": "String",
"metadata": {
"description": "Name of the NAT gateway"
}
},
"networkinterfacename": {
"defaultValue": "myvmNIC",
"type": "String",
"metadata": {
"description": "Name of the virtual machine nic"
}
},
"publicipname": {
"defaultValue": "myPublicIP",
"type": "String",
"metadata": {
"description": "Name of the NAT gateway public IP"
}
},
"nsgname": {
"defaultValue": "myVMnsg",
"type": "String",
"metadata": {
"description": "Name of the virtual machine NSG"
}
},
"publicipvmname": {
"defaultValue": "myPublicIPVM",
"type": "String",
"metadata": {
"description": "Name of the virtual machine public IP"
}
},
"publicipprefixname": {
"defaultValue": "myPublicIPPrefix",
"type": "String",
"metadata": {
"description": "Name of the NAT gateway public IP"
}
},
"adminusername": {
"type": "String",
"metadata": {
"description": "Administrator username for virtual machine"
}
},
"adminpassword": {
"type": "secureString",
"metadata": {
"description": "Administrator password for virtual machine"
 "description": "Administrator password for virtual machine"
}
},
"location": {
"defaultValue": "[resourceGroup().location]",
"type": "String",
"metadata": {
"description": "Name of resource group"
}
}
},
"variables": {},
"resources": [
{
"type": "[Link]/networkSecurityGroups",
"apiVersion": "2019-11-01",
"name": "[parameters('nsgname')]",
"location": "[parameters('location')]",
"properties": {
"securityRules": [
{
"name": "SSH",
"properties": {
"protocol": "TCP",
"sourcePortRange": "*",
"destinationPortRange": "22",
"sourceAddressPrefix": "*",
"destinationAddressPrefix": "*",
"access": "Allow",
"priority": 300,
"direction": "Inbound"
}
}
]
}
},
{
"type": "[Link]/publicIPAddresses",
"apiVersion": "2019-11-01",
"name": "[parameters('publicipname')]",
"location": "[parameters('location')]",
"sku": {
"name": "Standard"
},
"properties": {
"publicIPAddressVersion": "IPv4",
"publicIPAllocationMethod": "Static",
"idleTimeoutInMinutes": 4
}
},
{
"type": "[Link]/publicIPAddresses",
"apiVersion": "2019-11-01",
"name": "[parameters('publicipvmname')]",
"location": "[parameters('location')]",
"sku": {
"name": "Standard"
},
"properties": {
"publicIPAddressVersion": "IPv4",
"publicIPAllocationMethod": "Static",
"idleTimeoutInMinutes": 4
}
},
{
"type": "[Link]/publicIPPrefixes",
"apiVersion": "2019-11-01",
"name": "[parameters('publicipprefixname')]",
"location": "[parameters('location')]",
 "sku": {
"name": "Standard"
},
"properties": {
"prefixLength": 31,
"publicIPAddressVersion": "IPv4"
}
},
{
"type": "[Link]/virtualMachines",
"apiVersion": "2019-07-01",
"name": "[parameters('vmname')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('[Link]/networkInterfaces', parameters('networkinterfacename'))]"
],
"properties": {
"hardwareProfile": {
"vmSize": "[parameters('vmsize')]"
},
"storageProfile": {
"imageReference": {
"publisher": "Canonical",
"offer": "UbuntuServer",
"sku": "18.04-LTS",
"version": "latest"
},
"osDisk": {
"osType": "Linux",
"name": "[concat(parameters('vmname'), '_disk1')]",
"createOption": "FromImage",
"caching": "ReadWrite",
"managedDisk": {
"storageAccountType": "Premium_LRS"
},
"diskSizeGB": 30
}

},
"osProfile": {
"computerName": "[parameters('vmname')]",
"adminUsername": "[parameters('adminusername')]",
"adminPassword": "[parameters('adminpassword')]",
"linuxConfiguration": {
"disablePasswordAuthentication": false,
"provisionVMAgent": true
},
"allowExtensionOperations": true
},
"networkProfile": {
"networkInterfaces": [
{
"id": "[resourceId('[Link]/networkInterfaces',
parameters('networkinterfacename'))]"
}
]
}
}
},
{
"type": "[Link]/virtualNetworks",
"apiVersion": "2019-11-01",
"name": "[parameters('vnetname')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('[Link]/natGateways', parameters('natgatewayname'))]"
],
"properties": {
"addressSpace": {
 "addressSpace": {
"addressPrefixes": [
"[parameters('vnetaddressspace')]"
]
},
"subnets": [
{
"name": "[parameters('subnetname')]",
"properties": {
"addressPrefix": "[parameters('vnetsubnetprefix')]",
"natGateway": {
"id": "[resourceId('[Link]/natGateways',
parameters('natgatewayname'))]"
},
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
}
],
"enableDdosProtection": false,
"enableVmProtection": false
}
},
{
"type": "[Link]/natGateways",
"apiVersion": "2019-11-01",
"name": "[parameters('natgatewayname')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('[Link]/publicIPAddresses', parameters('publicipname'))]",
"[resourceId('[Link]/publicIPPrefixes', parameters('publicipprefixname'))]"
],
"sku": {
"name": "Standard"
},
"properties": {
"idleTimeoutInMinutes": 4,
"publicIpAddresses": [
{
"id": "[resourceId('[Link]/publicIPAddresses',
parameters('publicipname'))]"
}
],
"publicIpPrefixes": [
{
"id": "[resourceId('[Link]/publicIPPrefixes',
parameters('publicipprefixname'))]"
}
]
}
},
{
"type": "[Link]/virtualNetworks/subnets",
"apiVersion": "2019-11-01",
"name": "[concat(parameters('vnetname'), '/mySubnet')]",
"dependsOn": [
"[resourceId('[Link]/virtualNetworks', parameters('vnetname'))]",
"[resourceId('[Link]/natGateways', parameters('natgatewayname'))]"
],
"properties": {
"addressPrefix": "[parameters('vnetsubnetprefix')]",
"natGateway": {
"id": "[resourceId('[Link]/natGateways', parameters('natgatewayname'))]"
},
"privateEndpointNetworkPolicies": "Enabled",
"privateLinkServiceNetworkPolicies": "Enabled"
}
},
{
"type": "[Link]/networkInterfaces",
 "type": "[Link]/networkInterfaces",
"apiVersion": "2019-11-01",
"name": "[parameters('networkinterfacename')]",
"location": "[parameters('location')]",
"dependsOn": [
"[resourceId('[Link]/publicIPAddresses', parameters('publicipvmname'))]",
"[resourceId('[Link]/virtualNetworks/subnets', parameters('vnetname'),
'mySubnet')]",
"[resourceId('[Link]/networkSecurityGroups', parameters('nsgname'))]"
],
"properties": {
"ipConfigurations": [
{
"name": "ipconfig1",
"properties": {
"privateIPAddress": "[Link]",
"privateIPAllocationMethod": "Dynamic",
"publicIPAddress": {
"id": "[resourceId('[Link]/publicIPAddresses',
parameters('publicipvmname'))]"
},
"subnet": {
"id": "[resourceId('[Link]/virtualNetworks/subnets',
parameters('vnetname'), 'mySubnet')]"
},
"primary": true,
"privateIPAddressVersion": "IPv4"
}
}
],
"enableAcceleratedNetworking": false,
"enableIPForwarding": false,
"networkSecurityGroup": {
"id": "[resourceId('[Link]/networkSecurityGroups', parameters('nsgname'))]"
}
}
}
]
}

En la plantilla se definen nueve recursos de Azure:

[Link]
[Link]/natGateways : Crea un recurso de puerta de enlace NAT.
[Link]/networkSecurityGroups : Crea un grupo de seguridad de red.
[Link]/networkSecurityGroups/securityRules : Crea una regla de seguridad.
[Link]/publicIPAddresses : Crea una dirección IP pública.
[Link]/publicIPPrefixes : Crea un prefijo de dirección IP pública.
[Link]/vir tualNetworks : Crea una red virtual.
[Link]/vir tualNetworks/subnets : Crea una subred de red virtual.
[Link]/networkinterfaces : Crea una interfaz de red.
[Link]
[Link]/vir tualMachines : Crea una máquina virtual.
Implementación de la plantilla
CLI de Azure
 read -p "Enter the location (i.e. westcentralus): " location
resourceGroupName="myResourceGroupNAT"
templateUri="[Link]
vm/[Link]"

az group create \
--name $resourceGroupName \
--location $location

az group deployment create \

--resource-group $resourceGroupName \
--template-uri $templateUri

Azure PowerShell

$location = Read-Host -Prompt "Enter the location (i.e. westcentralus)"

$templateUri = "[Link]
vm/[Link]"

$resourceGroupName = "myResourceGroupNAT"

New-AzResourceGroup -Name $resourceGroupName -Location $location

New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName -TemplateUri $templateUri

Azure Por tal

Revisión de los recursos implementados

1. Inicie sesión en Azure Portal.
2. Seleccione Grupos de recursos en el panel izquierdo.
3. Seleccione el grupo de recursos que creó en la sección anterior. El nombre predeterminado del grupo de
recursos es myResourceGroupNAT .
4. Compruebe que los recursos siguientes se han creado en el grupo de recursos:
Limpieza de recursos
CLI de Azure
Cuando ya no lo necesite, puede usar el comando az group delete para quitar el grupo de recursos y todos los
recursos que contiene.

az group delete \
--name myResourceGroupNAT

Azure PowerShell
Cuando ya no lo necesite, puede usar el comando Remove-AzResourceGroup para quitar el grupo de recursos y
todos los recursos que contiene.

Remove-AzResourceGroup -Name myResourceGroupNAT

Azure Por tal

Cuando ya no los necesite, elimine el grupo de recursos, la puerta de enlace de NAT y todos los recursos
relacionados. Seleccione el grupo de recursos myResourceGroupNAT que contiene la puerta de enlace de NAT y,
luego, seleccione Eliminar .

Pasos siguientes
En este inicio rápido, ha creado lo siguiente:
Recurso de puerta de enlace NAT
Virtual network
Máquina virtual con Ubuntu
La máquina virtual se implementa en una subred de red virtual asociada a la puerta de enlace NAT.
Para más información sobre Virtual Network NAT y Azure Resource Manager, continúe con los artículos siguientes.
Lea Información general de Virtual Network NAT.
Consulte los recursos de puerta de enlace NAT.
Obtenga más información sobre Azure Resource Manager.
 Tutorial: Creación de una puerta de enlace de NAT
mediante Azure PowerShell y prueba del servicio
NAT
23/09/2020 • 26 minutes to read • Edit Online

En este tutorial, creará una puerta de enlace de NAT para proporcionar conectividad saliente a las máquinas
virtuales de Azure. Para probar la puerta de enlace de NAT, implemente una máquina virtual de origen y destino.
Luego, realizará conexiones salientes a una dirección IP pública. Estas conexiones irán desde la máquina virtual de
origen a la de destino. Para simplificar las cosas, en este tutorial se implementan el origen y el destino en dos
redes virtuales diferentes del mismo grupo de recursos.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Puede realizar este tutorial con Azure Cloud Shell o ejecutar los comandos respectivos de forma local. Si no ha
usado nunca Azure Cloud Shell, debe iniciar sesión ahora.
 NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Crear un grupo de recursos

Cree un grupo de recursos con az group create. Un grupo de recursos de Azure es un contenedor lógico en el que
se implementan y se administran los recursos de Azure.
En el ejemplo siguiente se crea un grupo de recursos llamado myResourceGroupNAT en la ubicación eastus2 :

$rgname = 'myResourceGroupNAT'
$loc = 'eastus2'

$rg = New-AzResourceGroup -Name $rgname -Location $loc

Creación de la puerta de enlace de NAT

Crear una dirección IP pública
Para acceder a Internet, necesita una o varias direcciones IP públicas para la puerta de enlace de NAT. Use New-
AzPublicIpAddress para crear el recurso de dirección IP pública llamado myPublicIPsource en
myResourceGroupNAT . El resultado de este comando se almacenará en una variable llamada $publicIPsource
para su uso posterior.

$pipname = 'myPublicIPsource'
$alm = 'Static'
$sku = 'Standard'

$publicIPsource =
New-AzPublicIpAddress -Name $pipname -ResourceGroupName $[Link] -AllocationMethod $alm -Sku $sku
-Location $[Link]

Creación de un prefijo de dirección IP pública

Use New-AzPublicIpPrefix para crear un recurso de prefijo de dirección IP pública llamado
myPublicIPprefixsource en myResourceGroupNAT . El resultado de este comando se almacenará en una
variable llamada $publicIPPrefixsource para su uso posterior.

$prefixname = 'mypublicIPprefixsource'

$publicIPPrefixsource =
New-AzPublicIpPrefix -Name $prefixname -ResourceGroupName $[Link] -PrefixLength 31 -Location
$[Link]

Creación de un recurso de puerta de enlace de NAT

En esta sección se detalla cómo crear y configurar los componentes siguientes del servicio NAT mediante el
recurso de puerta de enlace de NAT:
 Un grupo de direcciones IP públicas y un prefijo de dirección IP pública que se usarán en los flujos salientes
traducidos por el recurso de puerta de enlace de NAT.
Cambie el tiempo de espera de inactividad de 4 (el valor predeterminado) a 10 minutos.
Cree una puerta de enlace de NAT de Azure global con New-AzNatGateway. El resultado de este comando creará
un recurso de puerta de enlace llamado myNATgateway que usa la dirección IP pública myPublicIPsource y el
prefijo de dirección IP pública myPublicIPprefixsource . El tiempo de espera de inactividad se establece en 10
minutos. El resultado de este comando se almacenará en una variable llamada $natGateway para su uso
posterior.

$sku = 'Standard'
$natname = 'myNATgateway'

$natGateway =
New-AzNatGateway -Name $natname -ResourceGroupName $[Link] -PublicIpAddress $publicIPsource -
PublicIpPrefix $publicIPPrefixsource -Sku $sku -IdleTimeoutInMinutes 10 -Location $[Link]

En este momento, la puerta de enlace de NAT es funcional y todo lo que queda es configurar qué subredes de una
red virtual deben usarla.

Preparación del origen para el tráfico saliente

Se le va a guiar por la configuración de un entorno de prueba completo. Configurará una prueba mediante
herramientas de código abierto para comprobar la puerta de enlace de NAT. Se comenzará con el origen, que
usará la puerta de enlace de NAT que creamos anteriormente.
Configuración de una red virtual para el origen
Cree la red virtual y asocie la subred a la puerta de enlace.
Cree una red virtual llamada myVnetsource con una subred llamada mySubnetsource con New-
AzVirtualNetworkSubnetConfig en myResourceGroupNAT usando New-AzVirtualNetwork. El espacio de
direcciones IP de la red virtual es [Link]/16 . La subred de la red virtual es [Link]/24 . El resultado de
los comandos se almacenará en las variables llamadas $subnetsource y $Vnetsource para su uso posterior.

$subnetname = 'mySubnetsource'
$subnetprefix = '[Link]/24'
$vnetname = 'myVnetsource'
$vnetprefix = '[Link]/16'

$subnetsource =
New-AzVirtualNetworkSubnetConfig -Name $subnetname -AddressPrefix $subnetprefix -NatGateway $natGateway

$vnetsource =
New-AzVirtualNetwork -Name $vnetname -ResourceGroupName $[Link] -AddressPrefix $vnetprefix -
Subnet $subnetsource -Location $[Link]

Todo el tráfico saliente a destinos de Internet usa ahora el servicio NAT. No es necesario configurar una UDR.
Antes de poder probar la puerta de enlace de NAT, es necesario crear una máquina virtual de origen. Se va a
asignar un recurso de dirección IP pública como una dirección IP pública de nivel de instancia para acceder a esta
máquina virtual desde el exterior. Esta dirección solo se usa para el acceso de prueba. Se va a demostrar cómo el
servicio NAT tiene prioridad sobre otras opciones de salida.
Como ejercicio, también puede crear esta máquina virtual sin una dirección IP pública y crear otra máquina virtual
para usarla como JumpBox sin una dirección IP pública.
Creación de una dirección IP pública para la máquina virtual de origen
Se va a crear una dirección IP pública que se usará para acceder a la máquina virtual. Use New-AzPublicIpAddress
para crear el recurso de dirección IP pública llamado myPublicIPVM en myResourceGroupNAT . El resultado de
este comando se almacenará en una variable llamada $publicIpsourceVM para su uso posterior.

$sku = 'Standard'
$pipvmname = 'myPublicIpsourceVM'
$alm = 'Static'

$publicIpsourceVM =
New-AzPublicIpAddress -Name $pipvmname -ResourceGroupName $[Link] -AllocationMethod $alm -sku
$sku -Location $[Link]

Creación de un grupo de seguridad de red y exposición del punto de conexión de SSH para la máquina virtual
Como las direcciones IP públicas estándar son "seguras de forma predeterminada", se debe crear un grupo de
seguridad de red para permitir el acceso de entrada mediante SSH. El servicio NAT depende de la dirección del
flujo. Este grupo de seguridad de red no se usará para la salida una vez que la puerta de enlace de NAT esté
configurada en la misma subred. Use New-AzNetworkSecurityGroup para crear un recurso de grupo de seguridad
de red llamado myNSGsource . Use New-AzNetworkSecurityRuleConfig para crear una regla de grupo de
seguridad de red para el acceso mediante SSH llamada ssh en myResourceGroupNAT . El resultado de este
comando se almacenará en una variable llamada $nsgsource para su uso posterior.

$rnm = 'ssh'
$rdsc = 'SSH access'
$acc = 'Allow'
$prt = 'Tcp'
$dir = 'Inbound'
$nsnm = 'myNSGsource'

$sshrule =
New-AzNetworkSecurityRuleConfig -Name $rnm -Description $rdsc -Access $acc -Protocol $prt -Direction $dir -
Priority 100 -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 22

$nsgsource =
New-AzNetworkSecurityGroup -ResourceGroupName $[Link] -Name $nsnm -SecurityRules $sshrule -
Location $[Link]

Creación de una NIC para la máquina virtual de origen

Cree una interfaz de red con New-AzNetworkInterface llamada myNicsource . Este comando asociará la dirección
IP pública y el grupo de seguridad de red. El resultado de este comando se almacenará en una variable llamada
$nicsource para su uso posterior.

$nin = 'myNicsource'

$nicsource =
New-AzNetworkInterface -ResourceGroupName $[Link] -Name $nin -NetworkSecurityGroupID
$[Link] -PublicIPAddressID $[Link] -SubnetID $[Link][0].Id -Location
$[Link]

Creación de una máquina virtual de origen

Creación del par de claves SSH
Necesita un par de claves SSH para completar esta guía de inicio rápido. Si ya tiene un par de claves SSH, puede
omitir este paso.
Use ssh-keygen para crear un par de claves SSH.

ssh-keygen -t rsa -b 2048

Para más información sobre cómo crear pares de claves SSH, incluido el uso de PuTTy, consulte Uso de claves SSH
con Windows.
Si crea el par de claves SSH mediante Cloud Shell, se almacenará en una imagen de contenedor. Esta cuenta de
almacenamiento se crea automáticamente. No elimine la cuenta de almacenamiento, ni el recurso compartido de
archivos que contiene, hasta que haya recuperado las claves.
Creación de una configuración de máquina virtual
Para crear una máquina virtual en PowerShell, cree una configuración que tenga valores como, por ejemplo, la
imagen que se va a usar, el tamaño y las opciones de autenticación. Después, la configuración se utiliza para crear
la máquina virtual.
Defina las credenciales de SSH, la información del sistema operativo y el tamaño de máquina virtual. En este
ejemplo, la clave SSH se almacena en ~/.ssh/id_rsa.pub.

# Define a credential object

$securePassword =
ConvertTo-SecureString ' ' -AsPlainText -Force
$cred =
New-Object [Link] ("azureuser", $securePassword)

# Create a virtual machine configuration

$vmn = 'myVMsource'
$vms = 'Standard_DS1_v2'
$pub = 'Canonical'
$off = 'UbuntuServer'
$skus = '18.04-LTS'
$ver = 'latest'

$vmConfigsource =
New-AzVMConfig -VMName $vmn -VMSize $vms

Set-AzVMOperatingSystem -VM $vmConfigsource -Linux -ComputerName $vmn -Credential $cred -

DisablePasswordAuthentication

Set-AzVMSourceImage -VM $vmConfigsource -PublisherName $pub -Offer $off -Skus $skus -Version $ver

Add-AzVMNetworkInterface -VM $vmConfigsource -Id $[Link]

# Configure the SSH key

$sshPublicKey = cat ~/.ssh/id_rsa.pub

Add-AzVMSshPublicKey -VM $vmConfigsource -KeyData $sshPublicKey -Path "/home/azureuser/.ssh/authorized_keys"

Combine las definiciones de configuración para crear una máquina virtual llamada myVMsource con New-AzVM
en myResourceGroupNAT .

New-AzVM -ResourceGroupName $[Link] -VM $vmConfigsource -Location $[Link]

Aunque el comando devolverá resultados inmediatamente, la máquina virtual puede tardar unos minutos en
implementarse.
Preparación del destino para el tráfico saliente
Ahora se va a crear un destino para el tráfico saliente traducido por el servicio NAT para que pueda probarlo.
Configuración de una red virtual para el destino
Es necesario crear una red virtual donde estará la máquina virtual de destino. Estos comandos son los mismos que
para la máquina virtual de origen. Se han agregado pequeños cambios para exponer el punto de conexión de
destino.
Cree una red virtual llamada myVnetdestination con una subred llamada mySubnetdestination con New-
AzVirtualNetworkSubnetConfig en myResourceGroupNAT usando New-AzVirtualNetwork. El espacio de
direcciones IP de la red virtual es [Link]/16 . La subred de la red virtual es [Link]/24 . El resultado de
los comandos se almacenará en las variables llamadas $subnetdestination y $Vnetdestination para su uso
posterior.

$sbdn = 'mySubnetdestination'
$spfx = '[Link]/24'
$vdn = 'myVnetdestination'
$vpfx = '[Link]/16'

$subnetdestination =
New-AzVirtualNetworkSubnetConfig -Name $sbdn -AddressPrefix $spfx

$vnetdestination =
New-AzVirtualNetwork -Name $vdn -ResourceGroupName $[Link] -AddressPrefix $vpfx -Subnet
$subnetdestination -Location $[Link]

Creación de una dirección IP pública para la máquina virtual de destino

Se va a crear una dirección IP pública que se usará para acceder a la máquina virtual de destino. Use New-
AzPublicIpAddress para crear el recurso de dirección IP pública llamado myPublicIPdestinationVM en
myResourceGroupNAT . El resultado de este comando se almacenará en una variable llamada
$publicIpdestinationVM para su uso posterior.

$sku = 'Standard'
$all = 'Static'
$pipd = 'myPublicIPdestinationVM'

$publicIpdestinationVM =
New-AzPublicIpAddress -Name $pipd -ResourceGroupName $[Link] -AllocationMethod $all -Sku $sku -
Location $[Link]

Creación de un grupo de seguridad de red y exposición del punto de conexión SSH y HTTP para la máquina
virtual
Las direcciones IP públicas estándar son "seguras de forma predeterminada", así que se debe crear un grupo de
seguridad de red para permitir el acceso de entrada mediante SSH. Use New-AzNetworkSecurityGroup para crear
un recurso de grupo de seguridad de red llamado myNSGdestination . Use New-AzNetworkSecurityRuleConfig
para crear una regla de grupo de seguridad de red para el acceso mediante SSH llamada ssh . Use New-
AzNetworkSecurityRuleConfig para crear una regla de grupo de seguridad de red para el acceso mediante HTTP
llamada http . Ambas reglas se crearán en myResourceGroupNAT . El resultado de este comando se almacenará
en una variable llamada $nsgdestination para su uso posterior.
 $snm = 'ssh'
$sdsc = 'SSH access'
$acc = 'Allow'
$prt = 'Tcp'
$dir = 'Inbound'
$hnm = 'http'
$hdsc = 'HTTP access'
$nsnm = 'myNSGdestination'

$sshrule =
New-AzNetworkSecurityRuleConfig -Name $snm -Description $sdsc -Access $acc -Protocol $prt -Direction $dir -
Priority 100 -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 22

$httprule =
New-AzNetworkSecurityRuleConfig -Name $hnm -Description $hdsc -Access $acc -Protocol $prt -Direction $dir -
Priority 101 -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 80

$nsgdestination =
New-AzNetworkSecurityGroup -ResourceGroupName $[Link] -Name $nsnm -SecurityRules
$sshrule,$httprule -Location $[Link]

Creación de una NIC para la máquina virtual de destino

Cree una interfaz de red con New-AzNetworkInterface llamada myNicdestination . Este comando se asociará con
la dirección IP pública y el grupo de seguridad de red. El resultado de este comando se almacenará en una variable
llamada $nicdestination para su uso posterior.

$nnm = 'myNicdestination'

$nicdestination =
New-AzNetworkInterface -ResourceGroupName $[Link] -Name $nnm -NetworkSecurityGroupID
$[Link] -PublicIPAddressID $[Link] -SubnetID $[Link][0].Id -
Location $[Link]

Creación de una máquina virtual de destino

Creación de una configuración de máquina virtual
Para crear una máquina virtual en PowerShell, cree una configuración que tenga valores como, por ejemplo, la
imagen que se va a usar, el tamaño y las opciones de autenticación. Después, la configuración se utiliza para crear
la máquina virtual.
Defina las credenciales de SSH, la información del sistema operativo y el tamaño de máquina virtual. En este
ejemplo, la clave SSH se almacena en ~/.ssh/id_rsa.pub.
 # Define a credential object

$securePassword =
ConvertTo-SecureString ' ' -AsPlainText -Force
$cred =
New-Object [Link] ("azureuser", $securePassword)

# Create a virtual machine configuration

$vmd = 'myVMdestination'
$vms = 'Standard_DS1_v2'
$pub = 'Canonical'
$off = 'UbuntuServer'
$skus = '18.04-LTS'
$ver = 'latest'

$vmConfigdestination = New-AzVMConfig -VMName $vmd -VMSize $vms

Set-AzVMOperatingSystem -VM $vmConfigdestination -Linux -ComputerName $vmd -Credential $cred -

DisablePasswordAuthentication

Set-AzVMSourceImage -VM $vmConfigdestination -PublisherName $pub -Offer $off -Skus $skus -Version $ver

Add-AzVMNetworkInterface -VM $vmConfigdestination -Id $[Link]

# Configure the SSH key

$sshPublicKey = cat ~/.ssh/id_rsa.pub

Add-AzVMSshPublicKey -VM $vmConfigdestination -KeyData $sshPublicKey -Path

"/home/azureuser/.ssh/authorized_keys"

Combine las definiciones de configuración para crear una máquina virtual llamada myVMdestination con New-
AzVM en myResourceGroupNAT .

New-AzVM -ResourceGroupName $[Link] -VM $vmConfigdestination -Location $[Link]

Aunque el comando devolverá resultados inmediatamente, la máquina virtual puede tardar unos minutos en
implementarse.

Preparación de un servidor web y prueba de la carga en la máquina

virtual de destino
En primer lugar, es necesario detectar la dirección IP de la máquina virtual de destino. Para obtener la dirección IP
pública de la máquina virtual, use Get-AzPublicIpAddress.

$pipname = 'myPublicIPdestinationVM'

$destip = Get-AzPublicIpAddress -ResourceGroupName $[Link] -Name $pipname | select IpAddress

$destip
 IMPORTANT
Copie la dirección IP pública y, luego, péguela en un bloc de notas para que pueda usarla en pasos posteriores. Indique que
esta es la máquina virtual de destino.

Inicio de sesión en la máquina virtual de destino

Las credenciales de SSH deben almacenarse en la instancia de Cloud Shell de la operación anterior. Abra Azure
Cloud Shell en el explorador. Use la dirección IP recuperada en el paso anterior para conectarse a la máquina
virtual mediante SSH.

ssh azureuser@$destip

Una vez que haya iniciado sesión, copie y pegue los siguientes comandos.

sudo apt -y update && \

sudo apt -y upgrade && \
sudo apt -y install nginx && \
sudo ln -sf /dev/null /var/log/nginx/[Link] && \
sudo touch /var/www/html/[Link] && \
sudo rm /var/www/html/[Link] && \
sudo dd if=/dev/zero of=/var/www/html/100k bs=1024 count=100

Estos comandos actualizarán la máquina virtual, instalarán Nginx y crearán un archivo de 100 Kbytes. Este archivo
se recuperará de la máquina virtual de origen mediante el servicio NAT.
Cierre la sesión SSH con la máquina virtual de destino.

Preparación de la prueba en la máquina virtual de origen

En primer lugar, es necesario detectar la dirección IP de la máquina virtual de origen. Para obtener la dirección IP
pública de la máquina virtual, use Get-AzPublicIpAddress.

$pipname = 'myPublicIPsourceVM'

$srcip = Get-AzPublicIpAddress -ResourceGroupName $[Link] -Name $pipname | select IpAddress

$srcip

IMPORTANT
Copie la dirección IP pública y, luego, péguela en un bloc de notas para que pueda usarla en pasos posteriores. Indique que
esta es la máquina virtual de origen.

Inicio de sesión en la máquina virtual de origen

De nuevo, las credenciales de SSH se almacenan en Cloud Shell. Abra una nueva pestaña de Azure Cloud Shell en
el explorador. Use la dirección IP recuperada en el paso anterior para conectarse a la máquina virtual mediante
SSH.
 ssh azureuser@$srcip

Copie y pegue los siguientes comandos para preparar la prueba del servicio NAT.

sudo apt -y update && \

sudo apt -y upgrade && \
sudo apt install -y nload golang && \
echo 'export GOPATH=${HOME}/go' >> .bashrc && \
echo 'export PATH=${PATH}:${GOPATH}/bin' >> .bashrc && \
. ~/.bashrc &&
go get -u [Link]/rakyll/hey

Estos comandos actualizarán la máquina virtual, instalarán Go, instalarán Hey desde GitHub y actualizarán el
entorno de Shell.
Ahora está listo para probar el servicio NAT.

Validación del servicio NAT

Mientras ha iniciado sesión en la máquina virtual de origen, puede usar cURL y Hey para generar solicitudes a la
dirección IP de destino.
Use cURL para recuperar el archivo de 100 Kbytes. Reemplace <ip-address-destination> en el ejemplo
siguiente por la dirección IP de destino que copió anteriormente. El parámetro --output indica que se descartará el
archivo recuperado.

curl [Link] --output /dev/null

También puede generar una serie de solicitudes mediante Hey . Una vez más, reemplace <ip-address-
destination> por la dirección IP de destino que copió anteriormente.

hey -n 100 -c 10 -t 30 --disable-keepalive [Link]

Este comando generará 100 solicitudes, 10 de ellas a la vez, con un tiempo de espera de 30 segundos. La conexión
TCP no se volverá a usar. Cada solicitud recuperará 100 Kbytes. Al final de la ejecución, Hey notificará algunas
estadísticas sobre el rendimiento del servicio NAT.

Limpieza de recursos
Cuando ya no lo necesite, puede usar el comando Remove-AzResourceGroup para quitar el grupo de recursos y
todos los recursos que contiene.

Remove-AzResourceGroup -Name $[Link]

Pasos siguientes
En este tutorial, ha creado una puerta de enlace de NAT y una máquina virtual de origen y destino y, luego, ha
probado la puerta de enlace de NAT.
Revise las métricas de Azure Monitor para ver el funcionamiento del servicio NAT. Diagnostique problemas, como
el agotamiento de recursos de los puertos SNAT disponibles. El agotamiento de los recursos de los puertos SNAT
se soluciona fácilmente agregando recursos de dirección IP pública o recursos de prefijo de dirección IP pública
adicionales (o ambos).
Obtenga más información sobre Virtual Network NAT.
Obtenga más información sobre recursos de puerta de enlace de NAT.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con la CLI de Azure.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con PowerShell.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con Azure Portal.
 Tutorial: Creación de una puerta de enlace de NAT
mediante la CLI de Azure y prueba del servicio NAT
23/09/2020 • 24 minutes to read • Edit Online

En este tutorial, creará una puerta de enlace de NAT para proporcionar conectividad saliente a las máquinas
virtuales de Azure. Para probar la puerta de enlace de NAT, implemente una máquina virtual de origen y destino.
Luego, realizará conexiones salientes a una dirección IP pública. Estas conexiones irán desde la máquina virtual de
origen a la de destino. Para simplificar las cosas, en este tutorial se implementan el origen y el destino en dos
redes virtuales diferentes del mismo grupo de recursos.

Uso de Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador.
Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos
preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno
local.
Para iniciar Azure Cloud Shell:

O P C IÓ N E JEM P LO O VÍN C ULO

Seleccione Pruébelo en la esquina superior derecha de un

bloque de código. Solo con seleccionar Pruébelo no se copia
automáticamente el código en Cloud Shell.

Vaya a [Link] o seleccione el botón Iniciar

Cloud Shell para abrir Cloud Shell en el explorador.

Seleccione el botón Cloud Shell en la barra de menús de la

esquina superior derecha de Azure Portal.

Para ejecutar el código de este artículo en Azure Cloud Shell:

1. Inicie Cloud Shell.
2. Seleccione el botón Copiar de un bloque de código para copiar el código.
3. Pegue el código en la sesión de Cloud Shell. Para ello, seleccione Ctrl +Mayús +V en Windows y Linux, o
bien seleccione Cmd +Mayús +V en macOS.
4. Seleccione Entrar para ejecutar el código.
Puede realizar este tutorial con Azure Cloud Shell o ejecutar los comandos respectivos de forma local. Si no ha
usado Azure Cloud Shell, debe iniciar sesión ahora.
Si elige ejecutar estos comandos de forma local, debe instalar la CLI. En este tutorial es necesario ejecutar la
versión 2.0.71 de la CLI de Azure o cualquier versión posterior. Para encontrar la versión, ejecute az --version . Si
necesita instalarla o actualizarla, vea Instalación de la CLI de Azure.

Crear un grupo de recursos

Cree un grupo de recursos con az group create. Un grupo de recursos de Azure es un contenedor lógico en el que
se implementan y se administran los recursos de Azure.
En el ejemplo siguiente se crea un grupo de recursos llamado myResourceGroupNAT en la ubicación eastus2 :

az group create \
--name myResourceGroupNAT \
--location eastus2

Creación de la puerta de enlace de NAT

Crear una dirección IP pública
Para acceder a la red pública de Internet, necesita una o varias direcciones IP públicas para la puerta de enlace de
NAT. Use az network public-ip create para crear un recurso de dirección IP pública llamado myPublicIPsource en
myResourceGroupNAT .

az network public-ip create \

--resource-group myResourceGroupNAT \
--name myPublicIPsource \
--sku standard

Creación de un prefijo de dirección IP pública

Puede usar uno o varios recursos de dirección IP pública, prefijos de dirección IP pública, o ambos, con la puerta
de enlace de NAT. Para demostrarlo, vamos a agregar un recurso de prefijo de dirección IP pública a este escenario.
Use az network public-ip prefix create para crear un recurso de prefijo de dirección IP pública llamado
myPublicIPprefixsource en myResourceGroupNAT .

az network public-ip prefix create \

--resource-group myResourceGroupNAT \
--name myPublicIPprefixsource \
--length 31

Creación de un recurso de puerta de enlace de NAT

En esta sección se detalla cómo crear y configurar los componentes siguientes del servicio NAT mediante el
recurso de puerta de enlace de NAT:
Un grupo de direcciones IP públicas y un prefijo de dirección IP pública que se usarán en los flujos salientes
traducidos por el recurso de puerta de enlace de NAT.
Cambie el tiempo de espera de inactividad de 4 (el valor predeterminado) a 10 minutos.
Cree una puerta de enlace de NAT de Azure global con az network nat gateway create llamada myNATgateway .
El comando usa la dirección IP pública myPublicIP y el prefijo de dirección IP pública myPublicIPprefix . El
comando también cambia el tiempo de espera de inactividad a 10 minutos.

az network nat gateway create \

--resource-group myResourceGroupNAT \
--name myNATgateway \
--public-ip-addresses myPublicIPsource \
--public-ip-prefixes myPublicIPprefixsource \
--idle-timeout 10
En este momento, la puerta de enlace de NAT es funcional y todo lo que queda es configurar qué subredes de una
red virtual deben usarla.

Preparación del origen para el tráfico saliente

Se le va a guiar por la configuración de un entorno de prueba completo. Configurará una prueba mediante
herramientas de código abierto para comprobar la puerta de enlace de NAT. Se comenzará con el origen, que
usará la puerta de enlace de NAT que creamos anteriormente.
Configuración de una red virtual para el origen
Antes de implementar una máquina virtual y probar la puerta de enlace de NAT, es necesario crear la red virtual.
Cree una red virtual llamada myVnetsource con una subred llamada mySubnetsource en el grupo de recursos
myResourceGroupNAT con az network Microsoft Azure Virtual Network create. El espacio de direcciones IP de la
red virtual es [Link]/16 . La subred de la red virtual es [Link]/24 .

az network vnet create \

--resource-group myResourceGroupNAT \
--name myVnetsource \
--address-prefix [Link]/16 \
--subnet-name mySubnetsource \
--subnet-prefix [Link]/24

Configuración del servicio NAT para la subred de origen

Configure la subred de origen mySubnetsource de la red virtual myVnetsource para usar el recurso de puerta
de enlace de NAT específico myNATgateway con az network Microsoft Azure Virtual Network subnet update. Este
comando activará el servicio NAT en la subred especificada.

az network vnet subnet update \

--resource-group myResourceGroupNAT \
--vnet-name myVnetsource \
--name mySubnetsource \
--nat-gateway myNATgateway

Todo el tráfico saliente a destinos de Internet usa ahora el servicio NAT. No es necesario configurar una UDR.
Antes de poder probar la puerta de enlace de NAT, es necesario crear una máquina virtual de origen. Se va a
asignar un recurso de dirección IP pública como una dirección IP pública de nivel de instancia para acceder a esta
máquina virtual desde el exterior. Esta dirección solo se usa para el acceso de prueba. Se va a demostrar cómo el
servicio NAT tiene prioridad sobre otras opciones de salida.
Como ejercicio, también puede crear esta máquina virtual sin una dirección IP pública y crear otra máquina virtual
para usarla como JumpBox sin una dirección IP pública.
Creación de una dirección IP pública para la máquina virtual de origen
Se va a crear una dirección IP pública que se usará para acceder a la máquina virtual de origen. Use az network
public-ip create para crear un recurso de dirección IP pública llamado myPublicIPsourceVM en
myResourceGroupNAT .
 az network public-ip create \
--resource-group myResourceGroupNAT \
--name myPublicIPsourceVM \
--sku standard

Creación de un grupo de seguridad de red para la máquina virtual de origen

Dado que las direcciones IP públicas estándar son "seguras de forma predeterminada", es necesario crear un
grupo de seguridad de red para permitir el acceso de entrada mediante SSH. El servicio Azure NAT depende de la
dirección del flujo. Este grupo de seguridad de red no se usará para la salida una vez que la puerta de enlace de
NAT esté configurada en la misma subred. Use az network nsg create para crear un recurso de grupo de seguridad
de red llamado myNSGsource en myResourceGroupNAT .

az network nsg create \

--resource-group myResourceGroupNAT \
--name myNSGsource

Exposición del punto de conexión SSH en la máquina virtual de origen

Se va a crear una regla en el grupo de seguridad de red para el acceso mediante SSH a la máquina virtual de
origen. Use az network nsg rule create para crear una regla de grupo de seguridad de red llamada ssh . Esta regla
se creará en el grupo de seguridad de red llamado myNSGsource en el grupo de recursos
myResourceGroupNAT .

az network nsg rule create \

--resource-group myResourceGroupNAT \
--nsg-name myNSGsource \
--priority 100 \
--name ssh \
--description "SSH access" \
--access allow \
--protocol tcp \
--direction inbound \
--destination-port-ranges 22

Creación de una NIC para la máquina virtual de origen

Cree una interfaz de red con el comando az network nic create y asóciela a la dirección IP pública y al grupo de
seguridad de red.

az network nic create \

--resource-group myResourceGroupNAT \
--name myNicsource \
--vnet-name myVnetsource \
--subnet mySubnetsource \
--public-ip-address myPublicIPSourceVM \
--network-security-group myNSGsource

Creación de una máquina virtual de origen

Cree la máquina virtual con az vm create. Se van a generar claves SSH para esta máquina virtual y se va a
almacenar la clave privada para usarla más adelante.
 az vm create \
--resource-group myResourceGroupNAT \
--name myVMsource \
--nics myNicsource \
--image UbuntuLTS \
--generate-ssh-keys \
--no-wait

Aunque el comando devolverá resultados inmediatamente, la máquina virtual puede tardar unos minutos en
implementarse.

Preparación del destino para el tráfico saliente

Ahora se va a crear un destino para el tráfico saliente traducido por el servicio NAT para que pueda probarlo.
Configuración de una red virtual para el destino
Es necesario crear una red virtual donde estará la máquina virtual de destino. Estos comandos son los mismos que
para la máquina virtual de origen con pequeños cambios para exponer el punto de conexión de destino.
Cree una red virtual llamada myVnetdestination con una subred llamada mySubnetdestination en el grupo
de recursos myResourceGroupNAT con az network Microsoft Azure Virtual Network create. El espacio de
direcciones IP de la red virtual es [Link]/16 . La subred de la red virtual es [Link]/24 .

az network vnet create \

--resource-group myResourceGroupNAT \
--name myVnetdestination \
--address-prefix [Link]/16 \
--subnet-name mySubnetdestination \
--subnet-prefix [Link]/24

Creación de una dirección IP pública para la máquina virtual de destino

Se va a crear una dirección IP pública que se usará para acceder a la máquina virtual de origen. Use az network
public-ip create para crear un recurso de dirección IP pública llamado myPublicIPdestinationVM en
myResourceGroupNAT .

az network public-ip create \

--resource-group myResourceGroupNAT \
--name myPublicIPdestinationVM \
--sku standard

Creación de un grupo de seguridad de red para la máquina virtual de destino

Las direcciones IP públicas estándar son "seguras de forma predeterminada", por lo que deberá crear un grupo de
seguridad de red para permitir el acceso de entrada mediante SSH. El servicio Azure NAT depende de la dirección
del flujo. Este grupo de seguridad de red no se usará para la salida una vez que la puerta de enlace de NAT esté
configurada en la misma subred. Use az network nsg create para crear un recurso de grupo de seguridad de red
llamado myNSGdestination en myResourceGroupNAT .

az network nsg create \

--resource-group myResourceGroupNAT \
--name myNSGdestination
Exposición del punto de conexión SSH en la máquina virtual de destino
Se va a crear una regla en el grupo de seguridad de red para el acceso mediante SSH a la máquina virtual de
destino. Use az network nsg rule create para crear una regla de grupo de seguridad de red llamada ssh . Esta regla
se creará en el grupo de seguridad de red llamado myNSGdestination en el grupo de recursos
myResourceGroupNAT .

az network nsg rule create \

--resource-group myResourceGroupNAT \
--nsg-name myNSGdestination \
--priority 100 \
--name ssh \
--description "SSH access" \
--access allow \
--protocol tcp \
--direction inbound \
--destination-port-ranges 22

Exposición de un punto de conexión HTTP en la máquina virtual de destino

Se va a crear una regla en el grupo de seguridad de red para el acceso mediante HTTP a la máquina virtual de
destino. Use az network nsg rule create para crear una regla de grupo de seguridad de red llamada http en el NSG
llamado myNSGdestination en myResourceGroupNAT .

az network nsg rule create \

--resource-group myResourceGroupNAT \
--nsg-name myNSGdestination \
--priority 101 \
--name http \
--description "HTTP access" \
--access allow \
--protocol tcp \
--direction inbound \
--destination-port-ranges 80

Creación de una NIC para la máquina virtual de destino

Cree una interfaz de red con az network nic create y asóciela a la dirección IP pública myPublicIPdestinationVM
y al grupo de seguridad de red myNSGdestination .

az network nic create \

--resource-group myResourceGroupNAT \
--name myNicdestination \
--vnet-name myVnetdestination \
--subnet mySubnetdestination \
--public-ip-address myPublicIPdestinationVM \
--network-security-group myNSGdestination

Creación de una máquina virtual de destino

Cree la máquina virtual con az vm create. Se van a generar claves SSH para esta máquina virtual y se va a
almacenar la clave privada para usarla más adelante.
 az vm create \
--resource-group myResourceGroupNAT \
--name myVMdestination \
--nics myNicdestination \
--image UbuntuLTS \
--generate-ssh-keys \
--no-wait

Aunque el comando devolverá resultados inmediatamente, la máquina virtual puede tardar unos minutos en
implementarse.

Preparación de un servidor web y prueba de la carga en la máquina

virtual de destino
En primer lugar, es necesario detectar la dirección IP de la máquina virtual de destino. Para obtener la dirección IP
pública de la máquina virtual de destino, use az network public-ip show.

az network public-ip show \

--resource-group myResourceGroupNAT \
--name myPublicIPdestinationVM \
--query [ipAddress] \
--output tsv

IMPORTANT
Copie la dirección IP pública y, luego, péguela en un bloc de notas para que pueda usarla en pasos posteriores. Indique que
esta es la máquina virtual de destino.

Inicio de sesión en la máquina virtual de destino

Las credenciales de SSH deben almacenarse en la instancia de Cloud Shell de la operación anterior. Abra Azure
Cloud Shell en el explorador. Use la dirección IP recuperada en el paso anterior para conectarse a la máquina
virtual mediante SSH.

ssh <ip-address-destination>

Una vez que haya iniciado sesión, copie y pegue los siguientes comandos.

sudo apt -y update && \

sudo apt -y upgrade && \
sudo apt -y install nginx && \
sudo ln -sf /dev/null /var/log/nginx/[Link] && \
sudo touch /var/www/html/[Link] && \
sudo rm /var/www/html/[Link] && \
sudo dd if=/dev/zero of=/var/www/html/100k bs=1024 count=100

Estos comandos actualizarán la máquina virtual, instalarán Nginx y crearán un archivo de 100 Kbytes. Este archivo
se recuperará de la máquina virtual de origen mediante el servicio NAT.
Cierre la sesión SSH con la máquina virtual de destino.

Preparación de la prueba en la máquina virtual de origen

En primer lugar, es necesario detectar la dirección IP de la máquina virtual de origen. Para obtener la dirección IP
pública de la máquina virtual de origen, use az network public-ip show.

az network public-ip show \

--resource-group myResourceGroupNAT \
--name myPublicIPsourceVM \
--query [ipAddress] \
--output tsv

IMPORTANT
Copie la dirección IP pública y, luego, péguela en un bloc de notas para que pueda usarla en pasos posteriores. Indique que
esta es la máquina virtual de origen.

Inicio de sesión en la máquina virtual de origen

De nuevo, las credenciales de SSH se almacenan en Cloud Shell. Abra una nueva pestaña de Azure Cloud Shell en
el explorador. Use la dirección IP recuperada en el paso anterior para conectarse a la máquina virtual mediante
SSH.

ssh <ip-address-source>

Copie y pegue los siguientes comandos para preparar la prueba del servicio NAT.

sudo apt -y update && \

sudo apt -y upgrade && \
sudo apt install -y nload golang && \
echo 'export GOPATH=${HOME}/go' >> .bashrc && \
echo 'export PATH=${PATH}:${GOPATH}/bin' >> .bashrc && \
. ~/.bashrc &&
go get -u [Link]/rakyll/hey

Este comando actualizará la máquina virtual, instalará Go, instalará Hey de GitHub y actualizará el entorno de
Shell.
Ahora está listo para probar el servicio NAT.

Validación del servicio NAT

Mientras ha iniciado sesión en la máquina virtual de origen, puede usar cURL y Hey para generar solicitudes a la
dirección IP de destino.
Use cURL para recuperar el archivo de 100 Kbytes. Reemplace <ip-address-destination> en el ejemplo
siguiente por la dirección IP de destino que copió anteriormente. El parámetro --output indica que se descartará
el archivo recuperado.

curl [Link] --output /dev/null

También puede generar una serie de solicitudes mediante Hey . Una vez más, reemplace <ip-address-
destination> por la dirección IP de destino que copió anteriormente.

hey -n 100 -c 10 -t 30 --disable-keepalive [Link]

Este comando generará 100 solicitudes, 10 de ellas a la vez, con un tiempo de espera de 30 segundos. La conexión
TCP no se volverá a usar. Cada solicitud recuperará 100 Kbytes. Al final de la ejecución, Hey notificará algunas
estadísticas sobre el rendimiento del servicio NAT.

Limpieza de recursos
Cuando ya no lo necesite, puede usar el comando az group delete para quitar el grupo de recursos y todos los
recursos que contiene.

az group delete --name myResourceGroupNAT

Pasos siguientes
En este tutorial, ha creado una puerta de enlace de NAT y una máquina virtual de origen y destino y, luego, ha
probado la puerta de enlace de NAT.
Revise las métricas de Azure Monitor para ver el funcionamiento del servicio NAT. Diagnostique problemas, como
el agotamiento de recursos de los puertos SNAT disponibles. El agotamiento de los recursos de los puertos SNAT
se soluciona fácilmente agregando recursos de dirección IP pública o recursos de prefijo de dirección IP pública
adicionales (o ambos).
Obtenga más información sobre Virtual Network NAT.
Obtenga más información sobre recursos de puerta de enlace de NAT.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con la CLI de Azure.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con PowerShell.
Inicio rápido para la implementación de recursos de puerta de enlace de NAT con Azure Portal.
 Solución de problemas de emparejamiento de redes
virtuales
23/09/2020 • 17 minutes to read • Edit Online

En esta guía de solución de problemas se proporcionan los pasos para ayudarle a resolver la mayoría de los
problemas de emparejamiento de redes virtuales.

Configuración de emparejamiento de redes virtuales entre dos redes

virtuales
¿Las redes virtuales pueden estar en la misma suscripción o en suscripciones distintas?
Las redes virtuales deben estar en la misma suscripción
Para configurar el emparejamiento de red virtual para las redes virtuales que están en la misma suscripción, use
los métodos que se indican en los artículos siguientes:
Si las redes virtuales están en la misma región, consulte Creación de un emparejamiento.
Si las redes virtuales están en diferentes regiones, consulte Emparejamiento de red virtual.

NOTE
La conectividad no funciona a través del emparejamiento de red virtual global para los siguientes recursos:
Máquinas virtuales (VM) detrás de la SKU básica del equilibrador de carga interno (ILB)
Redis Cache (usa la SKU básica del ILB)
Application Gateway (usa la SKU básica de ILB)
Conjuntos de escalado de máquinas virtuales (usa la SKU básica de ILB)
Clústeres de Azure Service Fabric (usa la SKU básica de ILB)
Grupos de disponibilidad AlwaysOn de SQL Server (usa la SKU básica de ILB)
Azure App Service Environment para PowerApps (usa la SKU básica de ILB)
Azure API Management (usa la SKU básica de ILB)
Azure Active Directory Domain Services (Azure AD DS) (usa la SKU básica de ILB)

Para más información, consulte los requisitos y restricciones del emparejamiento global.
Las redes virtuales se encuentran en suscripciones o inquilinos de Active Directory diferentes
Para configurar el emparejamiento de redes virtuales que se encuentren en diferentes suscripciones o inquilinos
de Active Directory, consulte Creación de emparejamiento: CLI de Azure.

NOTE
Para configurar el emparejamiento de red, debe tener permisos de colaborador de red en ambas suscripciones. Para
obtener más información, consulte Permisos de emparejamiento.

Configuración del emparejamiento de redes virtuales con una

topología de red en estrella tipo hub-and-spoke que use recursos
locales

Para una conexión de sitio a sitio o una conexión ExpressRoute

Siga los pasos descritos en: Configuración del tránsito de la puerta de enlace de VPN para el emparejamiento de
red virtual.
Para conexiones de punto a sitio
1. Siga los pasos descritos en: Configuración del tránsito de la puerta de enlace de VPN para el emparejamiento
de red virtual.
2. Después de que se establezca o se cambie el emparejamiento de red virtual, descargue y reinstale el paquete de
punto a sitio para que los clientes de punto a sitio obtengan las rutas actualizadas en la red virtual en los radios.

Configuración del emparejamiento de red virtual con una topología de

red en estrella tipo hub-and-spoke
Las redes virtuales están en la misma región
1. En la red virtual del centro, configure un dispositivo virtual de red (NVA).
2. En las redes virtuales en los radios, aplique el siguiente tipo de salto "aplicación virtual de red" a las rutas
definidas por el usuario.
Para más información, consulte Encadenamiento de servicios.

NOTE
Si necesita ayuda para configurar un NVA, póngase en contacto con el proveedor de NVA.

Para obtener ayuda con la solución de problemas de configuración y enrutamiento del dispositivo NVA, consulte
Problemas de aplicaciones virtuales de red en Azure.
Las redes virtuales están en regiones diferentes
Ya se admite el tránsito sobre el emparejamiento de red virtual global. La conectividad no funciona a través del
emparejamiento de red virtual global para los siguientes recursos:
VM tras la SKU de ILB básica
Redis Cache (usa la SKU básica del ILB)
Application Gateway (usa la SKU básica de ILB)
Conjuntos de escalado (usa la SKU de ILB básica)
Clústeres de Service Fabric (usa la SKU de ILB básica)
Grupos de disponibilidad AlwaysOn de SQL Server (usa la SKU básica de ILB)
App Service Environment (usa la SKU de ILB básica)
API Management (usa la SKU de ILB básica)
Azure AD DS (usa la SKU de ILB básica)
Para más información acerca de los requisitos y restricciones del emparejamiento global, consulte Emparejamiento
de red virtual.

Solución de un problema de conectividad entre dos redes virtuales

emparejadas
Inicie sesión en Azure Portal con una cuenta que disponga de los roles y permisos necesarios. Seleccione la red
virtual, seleccione Emparejamiento y, después, compruebe el campo Estado . ¿Cuál es el estado?
El estado de emparejamiento es "Conectado"
Para solucionar esta incidencia:
1. Compruebe los flujos de tráfico de red:
Use Solución de problemas de conexiones y la Comprobación de flujo de IP de la VM de origen a la VM de
destino para determinar si hay un grupo de seguridad de red (NSG) o una ruta definida por el usuario
(UDR) que cause interferencias en los flujos de tráfico.
Si utiliza un firewall o NVA:
a. Documente los parámetros de UDR, con el fin de que pueda restaurarlos una vez completado este paso.
b. Quite el UDR de la subred de la VM de origen o el NIC que apunta a NVA como el próximo salto.
Compruebe la conectividad de la máquina virtual de origen directamente con el destino que está
omitiendo el NVA. Si este paso no funciona, consulte el solucionador de problemas de NVA.
2. Tome un seguimiento de red:
a. Inicie un seguimiento de red en la VM de destino. En Windows, puede usar Netsh . Para Linux, use
TCPDump .
b. Ejecute TcpPing o PsPing de la IP de origen a la de destino.
Este es un ejemplo de un comando TcpPing : [Link] -t <destination VM address> 3389 .
c. Una vez se haya completado TcpPing , detenga el seguimiento de red en el destino.
d. Si los paquetes llegan desde el origen, no hay ningún problema de red. Examine el firewall de la VM y
la aplicación que escucha en ese puerto para localizar el problema de configuración.

NOTE
No se puede conectar a los siguientes tipos de recursos a través del emparejamiento de redes virtuales globales
(redes virtuales en regiones diferentes):
VM tras la SKU de ILB básica
Redis Cache (usa la SKU básica del ILB)
Application Gateway (usa la SKU básica de ILB)
Conjuntos de escalado (usa la SKU de ILB básica)
Clústeres de Service Fabric (usa la SKU de ILB básica)
Grupos de disponibilidad AlwaysOn de SQL Server (usa la SKU básica de ILB)
App Service Environment (usa la SKU de ILB básica)
API Management (usa la SKU de ILB básica)
Azure AD DS (usa la SKU de ILB básica)

Para más información, consulte los requisitos y restricciones del emparejamiento global.
El estado de emparejamiento es "Desconectado"
Para resolver este problema, elimine el emparejamiento de ambas redes virtuales y, después, vuelva a crearlas.

Solución de una incidencia de seguridad entre una red virtual de tipo

hub-and-spoke y un recurso local
¿Usa su red una instancia de VPN Gateway o un NVA de terceros?
Mi red usa una instancia de VPN Gateway o un NVA de terceros
Para solucionar problemas de conectividad que afectan a una instancia de VPN Gateway o un NVA de terceros,
consulte los siguientes artículos:
Solucionador de problemas de NVA
Encadenamiento de servicios
Mi red no usa una instancia de VPN Gateway ni un NVA de terceros
¿Tienen la red virtual del centro y la red virtual en los radios una puerta de enlace de VPN?
Tanto la red virtual del centro como la red virtual en los radios tienen una puerta de enlace de VPN
No se admite el uso de una puerta de enlace remota.
Si la red virtual en los radios ya tiene una puerta de enlace de VPN, la opción Usar puer ta de enlace remota no
se admite debido a la limitación del emparejamiento de red virtual.
Ni la red virtual del centro ni la red virtual en los radios tienen una puerta de enlace de VPN
En el caso de las conexiones de sitio a sitio o de Azure ExpressRoute, compruebe las siguientes causas principales
de las incidencias de conectividad con la red virtual remota desde el entorno local:
En la red virtual que tiene una puerta de enlace, compruebe que la casilla Permitir tráfico reenviado está
seleccionada.
En la red virtual que no tiene una puerta de enlace, compruebe que la casilla Usar puer ta de enlace remota
está seleccionada.
Haga que el administrador de red compruebe los dispositivos locales para comprobar que todos tienen el
espacio de direcciones de red virtual remoto agregado.
Para conexiones de punto a sitio:
En la red virtual que tiene una puerta de enlace, compruebe que la casilla Permitir tráfico reenviado está
seleccionada.
En la red virtual que no tiene una puerta de enlace, compruebe que la casilla Usar puer ta de enlace remota
está seleccionada.
Descargue y vuelva a instalar el paquete de cliente de punto a sitio. Las rutas de red virtual recién emparejadas
no agregan automáticamente rutas a los clientes de punto a sitio.

Solución de una incidencia de conectividad de red de tipo hub-and-

spoke entre redes virtuales de radio de la misma región
Las redes del centro deben incluir un NVA. Configure UDR en los radios que tengan un NVA establecido como
próximo salto y habilite Permitir tráfico reenviado en la red virtual del centro.
Para obtener más información, consulte Encadenamiento de servicios y analice estos requisitos con el proveedor
de NVA de su elección.

Solución de incidencias de conectividad de red de tipo hub-and-spoke

entre redes virtuales de radio de diferentes regiones
Ya se admite el tránsito sobre el emparejamiento de red virtual global. La conectividad no funciona a través del
emparejamiento de red virtual global para los siguientes recursos:
VM tras la SKU de ILB básica
Redis Cache (usa la SKU básica del ILB)
Application Gateway (usa la SKU básica de ILB)
Conjuntos de escalado (usa la SKU de ILB básica)
Clústeres de Service Fabric (usa la SKU de ILB básica)
Grupos de disponibilidad AlwaysOn de SQL Server (usa la SKU básica de ILB)
 App Service Environment (usa la SKU de ILB básica)
API Management (usa la SKU de ILB básica)
Azure AD DS (usa la SKU de ILB básica)
Para más información, consulte los requisitos y restricciones del emparejamiento global y las diferentes topologías
de VPN.

Solución de incidencias de conectividad de red de tipo hub-and-spoke

entre una aplicación web y la red virtual de radio
Para solucionar esta incidencia:
1. Inicie sesión en Azure Portal.
2. En la aplicación web, seleccione Redes y, después, seleccione Integración de VNET .
3. Compruebe si puede ver la red virtual remota. Escriba manualmente el espacio de direcciones de la red virtual
remota (Sincronizar red y Agregar rutas ).
Para más información, consulte los siguientes artículos.
Integración de su aplicación con una instancia de Azure Virtual Network
Información sobre el enrutamiento de VPN de punto a sitio

Solución de problemas de un mensaje de error de configuración de

emparejamiento de red virtual
El inquilino <TENANT ID> actual no está autorizado para acceder a la suscripción vinculada
Para resolver esta incidencia, consulte Creación de emparejamiento: CLI de Azure.
No conectado
Para resolver esta incidencia, elimine el emparejamiento de ambas redes virtuales y, después, vuelva a crearlas.
No se pudo emparejar una red virtual de Databricks
Para resolver esta incidencia, configure el emparejamiento de red virtual en Azure Databricks y, después,
especifique la red virtual de destino mediante el Id. de recurso . Para obtener más información, consulte Peer a
Databricks virtual network to a remote virtual network (Emparejamiento de una red virtual de Databricks con una
red virtual remota).
La red virtual remota no tiene una puerta de enlace
Este problema se produce cuando se emparejan redes virtuales de distintos inquilinos y posteriormente se quiere
configurar Use Remote Gateways . Una limitación de Azure Portal es que no puede validar la presencia de una
puerta de enlace de red virtual en la red virtual de otro inquilino.
Hay dos maneras de resolver este problema:
Elimine los emparejamientos y active la opción Use Remote Gateways cuando cree uno nuevo.
Use PowerShell o la CLI, en lugar de Azure Portal, para habilitar Use Remote Gateways .

Pasos siguientes
Solución de problemas de conectividad entre máquinas virtuales de Azure
 Configuración y validación de conexiones de red
virtual o de VPN
23/09/2020 • 33 minutes to read • Edit Online

Este tutorial proporciona una guía paso a paso para configurar y validar diversas implementaciones de red virtual y
de VPN de Azure. Entre los escenarios se incluyen el enrutamiento de tránsito, las conexiones entre redes, el
Protocolo de puerta de enlace de borde (BGP), las conexiones multisitio y las conexiones de punto a sitio.
Las puertas de enlace VPN de Azure proporcionan flexibilidad al organizar prácticamente cualquier tipo de
topología de red virtual conectada de Azure. Por ejemplo, puede conectar redes virtuales:
Entre regiones.
Entre los tipos de red virtual (Azure Resource Manager frente a clásica).
En Azure o en un entorno híbrido local.
En distintas suscripciones.

Conexión VPN de red a red

La conexión de una red virtual a otra (red a red) a través de VPN es similar a la conexión de una red virtual a la
ubicación de un sitio local. Ambos tipos de conectividad usan una puerta de enlace de VPN para proporcionar un
túnel seguro a través de IPsec e IKE. Las redes virtuales pueden estar en la misma región o en distintas, así como
pertenecer a una única suscripción o a varias.

Si las redes virtuales están en la misma región, también existe la posibilidad de conectarlas mediante el
emparejamiento de red virtual. El emparejamiento de red virtual no usa puerta de enlace de VPN. Aumenta el
rendimiento y reduce la latencia. Para configurar una conexión de emparejamiento de red virtual, seleccione
Configure and validate VNet Peering (Configurar y validar emparejamiento de VNet).
Si las redes virtuales se han creado mediante el modelo de implementación con Azure Resource Manager,
seleccione Configure and validate a Resource Manager VNet to a Resource Manager VNet connection
(Configurar y validar una red virtual de Resource Manager en una conexión de red virtual de Resource Manager)
para configurar una conexión VPN.
Si una de las redes virtuales se ha creado mediante el modelo de implementación clásica de Azure y la otra
mediante Resource Manager, seleccione Configure and validate a classic VNet to a Resource Manager
VNet connection (Configurar y validar una red virtual clásica en una conexión de red virtual de Resource
Manager) para configurar una conexión VPN.
Configuración del emparejamiento de red virtual para dos redes virtuales de la misma región
Antes de empezar a implementar y configurar el emparejamiento de red virtual de Azure, asegúrese de que se
cumplen los siguientes requisitos previos:
Las redes virtuales emparejadas deben existir en la misma región de Azure.
Las redes virtuales emparejadas deben tener espacios de direcciones IP que no se solapen.
 El emparejamiento de red virtual se realiza entre dos redes virtuales. No hay ninguna relación transitiva
derivada entre emparejamientos. Por ejemplo, si VNetA está emparejada con VNetB y VNetB está emparejada
con VNetC, VNetA no está emparejada con VNetC.
Cuando cumpla los requisitos, puede empezar a leer el artículo Tutorial: Conexión de redes virtuales con
emparejamiento de red virtual desde Azure Portal para crear y configurar el emparejamiento.
Para comprobar la configuración del emparejamiento, use el siguiente método:
1. Inicie sesión en Azure Portal con una cuenta que tenga los roles y permisos necesarios.
2. En el cuadro que contiene el texto Buscar recursos , en la parte superior del portal, escriba redes vir tuales .
Cuando aparezca la opción Redes vir tuales en los resultados de búsqueda, selecciónela.
3. En la hoja Redes vir tuales que aparece, haga clic en la red virtual para la que desea crear un emparejamiento.
4. En el panel que aparece para la red virtual, seleccione Emparejamientos en la sección Configuración .
5. Seleccione un emparejamiento y vea los resultados de la configuración.

En el caso de Azure PowerShell, ejecute el comando Get-AzureRmVirtualNetworkPeering para obtener el

emparejamiento de red virtual. Este es un ejemplo:

PS C:\Users\User1> Get-AzureRmVirtualNetworkPeering -VirtualNetworkName Vnet10-01 -ResourceGroupName dev-vnets

Name : LinkToVNET10-02
Id : /subscriptions/GUID/resourceGroups/dev-
vnets/providers/[Link]/virtualNetworks/VNET10-01/virtualNetworkPeerings/LinkToVNET10-0
2
Etag : W/"GUID"
ResourceGroupName : dev-vnets
VirtualNetworkName : vnet10-01
ProvisioningState : Succeeded
RemoteVirtualNetwork : {
"Id": "/subscriptions/GUID/resourceGroups/DEV-VNET
s/providers/[Link]/virtualNetworks/VNET10-02"
}
AllowVirtualNetworkAccess : True
AllowForwardedTraffic : False
AllowGatewayTransit : False
UseRemoteGateways : False
RemoteGateways : null
RemoteVirtualNetworkAddressSpace : null

Conexión de dos redes virtuales de Resource Manager

Puede configurar una conexión de una red virtual de Resource Manager a otra directamente. O bien, se puede
configurar la conexión mediante IPsec.
Configuración de una conexión VPN entre redes virtuales de Resource Manager
Para configurar una conexión entre redes virtuales de Resource Manager sin IPsec, consulte Configuración de una
conexión de VPN Gateway de red a red mediante Azure Portal.
Para configurar una conexión con IPsec entre dos redes virtuales de Resource Manager, siga los pasos del 1 a 5 del
artículo Creación de una conexión de sitio a sitio mediante Azure Portal en todas las redes virtuales.

NOTE
Estos pasos solo funcionan para redes virtuales que están en la misma suscripción. Si las redes virtuales se encuentran en
suscripciones distintas, es preciso usar PowerShell para realizar la conexión. Vea el artículo PowerShell.

Validación de la conexión VPN entre redes virtuales de Resource Manager

Para comprobar que la conexión VPN está configurada correctamente, siga estas instrucciones.

NOTE
Los números que aparecen después de los componentes de la red virtual en estos pasos se corresponden con los números
del diagrama anterior.

1. Asegúrese de que no se solapen espacios de direcciones en las redes virtuales conectadas.

2. Compruebe que el intervalo de direcciones de la red virtual de Azure Resource Manager (1) está definido
correctamente en la instancia del objeto de conexión (4).
3. Compruebe que el intervalo de direcciones de la red virtual de Azure Resource Manager (6) está definido
correctamente en la instancia del objeto de conexión (3).
4. Compruebe que las claves precompartidas coinciden con los objetos de conexión.
5. Compruebe que la IP virtual de la puerta de enlace de la red virtual de Azure Resource Manager (2) está
definida correctamente en la instancia del objeto de conexión (4).
6. Compruebe que la IP virtual de la puerta de enlace de la red virtual de Azure Resource Manager (5) está
definida correctamente en la instancia del objeto de conexión (3).
Conexión de una red virtual clásica a una red virtual de Resource Manager
Puede crear una conexión entre redes virtuales que estén en diferentes suscripciones y regiones. También puede
conectar redes virtuales que ya tengan conexiones a redes locales, siempre que el tipo de puerta de enlace se haya
configurado como basada en ruta.
Para configurar una conexión entre una red virtual clásica y una red virtual de Resource Manager, consulte
Conexión de redes virtuales a partir de diferentes modelos de implementación desde Azure Portal.

Para comprobar la configuración cuando conecte una red virtual clásica a una red virtual de Azure Resource
Manager, siga estas instrucciones.

NOTE
Los números que aparecen después de los componentes de la red virtual en estos pasos se corresponden con los números
del diagrama anterior.

1. Asegúrese de que no se solapen espacios de direcciones en las redes virtuales conectadas.

2. Compruebe que el intervalo de direcciones de la red virtual de Azure Resource Manager (6) se ha incluido
correctamente en la definición de la red local clásica (3).
3. Compruebe que el intervalo de direcciones de la red virtual clásica (1) se ha definido correctamente en la
instancia del objeto de conexión (4) de Azure Resource Manager.
4. Compruebe que la IP virtual de la puerta de enlace de la red virtual clásica (2) se ha definido correctamente en
la instancia del objeto de conexión (4) de Azure Resource Manager.
5. Compruebe que la puerta de enlace de la red virtual de Azure Resource Manager (5) se ha definido
correctamente en la instancia de la definición de la red local (3).
6. Compruebe que las claves precompartidas coinciden en las dos redes virtuales conectadas:
Red virtual clásica: definición de red local (3)
Red virtual de Azure Resource Manager: objeto de conexión (4)

Creación de una conexión VPN de punto a sitio

Las configuraciones de punto a sitio (P2S ) permiten crear una conexión segura entre un equipo cliente individual y
una red virtual. Las conexiones de punto a sitio resultan útiles cuando se desea establecer conexión con una red
virtual desde una ubicación remota; por ejemplo, desde casa o desde una conferencia. También son útiles cuando
hay pocos clientes que necesiten conectarse a una red virtual.
La conexión VPN de punto a sitio se inicia desde el equipo cliente mediante el cliente VPN de Windows nativo. En la
conexión de clientes, se usan certificados para la autenticación.
Las conexiones de punto a sitio no requieren ningún dispositivo VPN. Crean la conexión VPN a través del Protocolo
de túnel de sockets seguros (SSTP). Para establecer una conexión de punto a sitio con una red virtual se pueden
usar varias herramientas y modelos de implementación:
Configuración de una conexión punto a sitio a una red virtual mediante Azure Portal
Configuración de una conexión punto a sitio a una red virtual mediante Azure Portal (clásico)
Configuración de una conexión punto a sitio a una red virtual mediante PowerShell
Validación de una conexión de punto a sitio
En el artículo Solución de problemas: Problemas de conexión de punto a sitio de Azure se describen problemas
comunes con las conexiones de punto a sitio.

Creación de una conexión VPN multisitio

Puede agregar una conexión de sitio a sitio (S2S en el diagrama siguiente) con una red virtual que ya tenga una
conexión de sitio a sitio, una conexión de punto a sitio o una conexión de red a red. Con frecuencia, a este tipo de
conexión se le denomina configuración multisitio.

Azure actualmente funciona con dos modelos de implementación: el de Resource Manager y el clásico. Los dos
modelos no son totalmente compatibles entre sí. Para configurar una conexión multisitio con distintos modelos,
consulte los siguientes artículos:
 Agregar una conexión de sitio a sitio a una red virtual con una conexión de VPN Gateway existente
Agregar una conexión de sitio a sitio a una red virtual con una conexión de VPN Gateway existente (clásico)

NOTE
Los pasos que se indican en estos artículos no se aplican a las configuraciones de conexión coexistentes de ExpressRoute y
sitio a sitio. Para más información, consulte Configuración de conexiones ExpressRoute y de sitio a sitio coexistentes.

Configuración del enrutamiento de tránsito

El enrutamiento de tránsito es un escenario de enrutamiento concreto en el que se conectan varias redes en una
topología de cadena de margarita. Este enrutamiento permite a los recursos de las redes virtuales de cualquiera de
los extremos de la cadena comunicarse entre sí a través de redes virtuales. Sin el enrutamiento de tránsito, las
redes o los dispositivos emparejados a través de un centro de conectividad no se pueden conectar entre sí.
Configuración del enrutamiento de tránsito en una conexión de punto a sitio
Imagine un escenario en el que desea configurar una conexión VPN de sitio a sitio entre VNetA y VNetB. También
desea configurar una VPN de punto a sitio para que el cliente se conecte a la puerta de enlace de VNetA. Luego,
desea habilitar el enrutamiento de tránsito para que los clientes de punto a sitio se conecten a VNetB, que pasa a
través de VNetA.
Este escenario se admite cuando BGP está habilitado en la VPN de sitio a sitio entre VNetA y VNetB. Para más
información, consulte Información sobre el enrutamiento de VPN de punto a sitio.
Configuración del enrutamiento de tránsito en una conexión de ExpressRoute
Azure ExpressRoute le permite ampliar sus redes locales a la nube de Microsoft a través de una conexión privada y
dedicada que facilita un proveedor de conectividad. Con ExpressRoute, se pueden establecer conexiones con
servicios en la nube de Microsoft, como Microsoft Azure, Office 365 y Dynamics 365. Para más información,
consulte Información general sobre ExpressRoute.

NOTE
Si VNetA y VNetB se encuentran en la misma región geográfica, se recomienda vincular ambas redes virtuales al circuito de
ExpressRoute, en lugar de configurar el enrutamiento de tránsito. Si las redes virtuales se encuentran en regiones geopolíticas
distintas, también puede vincularlas directamente al circuito si tiene ExpressRoute Premium.

Si coexisten conexiones ExpressRoute y de sitio a sitio, no se admite el enrutamiento de tránsito. Para más
información, consulte Configuración de conexiones ExpressRoute y de sitio a sitio coexistentes con PowerShell.
Si ha habilitado ExpressRoute para conectar las redes locales a una red virtual de Azure, puede habilitar el
emparejamiento entre las redes virtuales en las que desea tener enrutamiento de tránsito. Para que las redes
locales se conecten a la red virtual remota, debe configurar el emparejamiento de red virtual.
 NOTE
El emparejamiento de red virtual solo está disponible para redes virtuales de la misma región.

Para comprobar si ha configurado el enrutamiento de tránsito para el emparejamiento de red virtual, siga estas
instrucciones:
1. Inicie sesión en Azure Portal con una cuenta que tenga los roles y permisos necesarios.
2. Cree un emparejamiento entre VNetA y VNetB como se muestra en el diagrama anterior.
3. En el panel que aparece para la red virtual, seleccione Emparejamientos en la sección Configuración .
4. Seleccione el emparejamiento que desea ver. Luego, seleccione Configuración para validar que ha habilitado
Permitir tránsito de puer ta de enlace en la red VNetA conectada al circuito ExpressRoute y Usar puer ta
de enlace remota en la red VNetB remota no conectada al circuito ExpressRoute.
Configuración del enrutamiento de tránsito en una conexión de emparejamiento de red virtual
Cuando las redes virtuales están emparejadas, también puede configurar la puerta de enlace de la red virtual
emparejada como punto de tránsito a una red local. Para configurar la ruta de tránsito en el emparejamiento de red
virtual, consulte Conexiones de red a red.

NOTE
No se admite el tránsito de puerta de enlace en la relación de emparejamiento entre las redes virtuales creadas mediante
modelos de implementación diferentes. Para que funcione el tránsito de puerta de enlace, las dos redes virtuales de la
relación de emparejamiento se deben haber creado mediante Resource Manager.

Para comprobar si ha configurado una ruta de tránsito para el emparejamiento de red virtual, siga estas
instrucciones:
1. Inicie sesión en Azure Portal con una cuenta que tenga los roles y permisos necesarios.
2. En el cuadro que contiene el texto Buscar recursos , en la parte superior del portal, escriba redes vir tuales .
Cuando aparezca la opción Redes vir tuales en los resultados de búsqueda, selecciónela.
3. En la hoja Redes vir tuales que aparece, seleccione la red virtual cuyo valor de emparejamiento desea
comprobar.
4. En el panel de la red virtual que ha seleccionado, seleccione Emparejamientos en la sección Configuración .
5. Seleccione el emparejamiento que desea ver. Compruebe que ha habilitado Permitir tránsito de puer ta de
enlace y Usar puer ta de enlace remota en Configuración .

Configuración del enrutamiento de tránsito en una conexión de red a red

Para configurar el enrutamiento de tránsito entre redes virtuales, es preciso habilitar BGP en todas las conexiones
de red a red intermedias mediante el modelo de implementación de Resource Manager y PowerShell. Para conocer
las instrucciones, consulte Configuración de BGP para Azure VPN Gateway con PowerShell.
El tráfico en tránsito a través de Azure VPN Gateway es posible mediante el modelo de implementación clásica,
pero se basa en espacios de direcciones definidos estáticamente en el archivo de configuración de red. BGP aún no
es compatible con las instancias de Azure Virtual Network y VPN Gateway mediante el modelo de implementación
clásica. Sin BGP, se suelen cometer errores al definir manualmente los espacios de direcciones de tránsito, por lo
que no se recomienda.

NOTE
Las conexiones de red a red clásicas se configuran mediante el Portal de Azure clásico o mediante un archivo de configuración
de red en el portal clásico. No se pueden crear ni modificar redes virtuales clásicas mediante el modelo de implementación de
Azure Resource Manager ni mediante Azure Portal. Para más información sobre el enrutamiento de tránsito para redes
virtuales clásicas, consulte el blog de desarrolladores de Microsoft.

Configuración del enrutamiento de tránsito en una conexión de sitio a sitio

Para configurar el enrutamiento de tránsito entre una red local y una red virtual con una conexión de sitio a sitio,
debe habilitar BGP en todas las conexiones de sitio a sitio intermedias mediante el modelo de implementación de
Resource Manager y PowerShell. Para obtener instrucciones al respecto, consulte Configuración de BGP para Azure
VPN Gateway con PowerShell.
El tráfico en tránsito a través de Azure VPN Gateway es posible mediante el modelo de implementación clásica,
pero se basa en espacios de direcciones definidos estáticamente en el archivo de configuración de red. BGP aún no
es compatible con las instancias de Azure Virtual Network y VPN Gateway mediante el modelo de implementación
clásica. Sin BGP, se suelen cometer errores al definir manualmente los espacios de direcciones de tránsito, por lo
que no se recomienda.

NOTE
Las conexiones de sitio a sitio clásicas se configuran mediante el Portal de Azure clásico o mediante un archivo de
configuración de red en el portal clásico. No se pueden crear ni modificar redes virtuales clásicas mediante el modelo de
implementación de Azure Resource Manager ni mediante Azure Portal. Para más información sobre el enrutamiento de
tránsito para redes virtuales clásicas, consulte el blog de desarrolladores de Microsoft.

Configuración de BGP para una instancia de VPN Gateway

BGP es el protocolo de enrutamiento estándar que se usa en Internet para intercambiar información de
enrutamiento y disponibilidad entre dos o más redes. Cuando BGP se usa en el contexto de redes virtuales de
Azure, habilita las puertas de enlace VPN y los dispositivos VPN locales, conocidos como vecinos o pares BGP.
Intercambian "rutas" que informan a ambas puertas de enlace sobre la disponibilidad y accesibilidad de los prefijos
para pasar por las puertas de enlace o los enrutadores pertinentes.
BGP también puede habilitar el enrutamiento de tránsito entre varias redes mediante la propagación de rutas que
una puerta de enlace de BGP aprende de un par BGP a los restantes pares BGP. Para más información, consulte
Introducción a BGP con Azure VPN Gateway.
Configuración de BGP para una conexión VPN
Para configurar una conexión VPN que usa BGP, consulte Configuración de BGP para Azure VPN Gateway con
PowerShell.
Habilite BGP en la puerta de enlace de red virtual mediante la creación de un número de sistema autónomo (AS)
para él. Las puertas de enlace básicas no admiten BGP. Para comprobar la SKU de la puerta de enlace, vaya a la
sección Información general de la hoja VPN Gateway en Azure Portal. Si la SKU es básica , tendrá que
cambiarla (consulte el artículo en el que se indica cómo se cambia el tamaño de la puerta de enlace) a VpnGw1 .
La comprobación de la SKU provocará un tiempo de inactividad que oscila entre 20 y 30 minutos. En cuanto la
puerta de enlace tenga la SKU correcta, se puede agregar el número de sistema autónomo (AS) mediante el cmdlet
Set-AzureRmVirtualNetworkGateway de PowerShell. Después de configurar el número de AS, se proporcionará
automáticamente una dirección IP del par BGP para la puerta de enlace.
Debe especificar manualmente un número de sistema autónomo (AS) y una dirección de par BGP para
LocalNetworkGateway . Puede establecer los valores ASN y -BgpPeeringAddress mediante los cmdlets New-
AzureRmLocalNetworkGateway o Set-AzureRmLocalNetworkGateway de PowerShell. Algunos números de sistema
autónomo (AS) están reservados para Azure y no se pueden usar, como se describe en Acerca de BGP con Azure
VPN Gateway.
El objeto de conexión debe tener BGP habilitado. Puede establecer el valor -EnableBGP en $True mediante New-
AzureRmVirtualNetworkGatewayConnection o Set-AzureRmVirtualNetworkGatewayConnection.
Validación de la configuración de BGP
Para comprobar si BGP está configurado correctamente, puede ejecutar los cmdlets
get-AzureRmVirtualNetworkGateway y get-AzureRmLocalNetworkGateway . Luego, observará la salida relacionada con
BGP en la parte de BgpSettingsText . Por ejemplo:

"Asn": AsnNumber,

"BgpPeeringAddress": "IP address",

"PeerWeight": 0

Creación de una conexión VPN activo-activo de alta disponibilidad

Estas son las principales diferencias entre las puertas de enlace activo-activo y activo-en espera:
Debe crear dos configuraciones de la IP de la puerta de enlace con dos direcciones IP públicas.
Debe establecer la marca EnableActiveActiveFeature .
La SKU de la puerta de enlace debe ser VpnGw1 , VpnGw2 o VpnGw3 .
Para lograr una alta disponibilidad en la conectividad de red a red y entre entornos locales, debe implementar
varias puertas de enlace VPN y establecer varias conexiones en paralelo entre sus redes y Azure. Para obtener
información general de las opciones y topología de conectividad, consulte Conectividad de alta disponibilidad entre
locales y de red virtual a red virtual.
Para crear conexiones activo-activo entre locales y de red a red, siga las instrucciones de Configuración de
conexiones VPN S2S activo-activo con Azure VPN Gateway para configurar Azure VPN Gateway en modo
activo/activo.

NOTE
Al agregar direcciones a la puerta de enlace de red local para el modo activo-activo habilitado para BGP, agregue solo las
direcciones /32 de los pares BGP. Si agrega más direcciones, se considerarán rutas estáticas y tendrán prioridad sobre las
rutas BGP.
Debe usar números de sistema autónomo (AS) de BGP diferentes para las redes locales que se conectan a Azure. (Si son
iguales, tiene que cambiar el número de sistema autónomo (AS) de la red virtual si el dispositivo VPN local ya utiliza el
ASN para emparejarse con otros vecinos de BGP).
Cambio de un tipo de instancia de Azure VPN Gateway tras la
implementación
No se puede cambiar un tipo de puerta de enlace de red virtual de Azure de basada en directivas a basada en el
enrutamiento, o viceversa, directamente. Primero es preciso eliminar la puerta de enlace. Cuando se haga, la
dirección IP y la clave precompartida no se conservarán. Luego, se puede crear una nueva puerta de enlace del tipo
deseado.
Para eliminar y crear una puerta de enlace, siga estos pasos:
1. Elimine también las conexiones asociadas a la puerta de enlace original.
2. Elimine la puerta de enlace mediante Azure Portal, PowerShell o PowerShell clásico:
Eliminación de una puerta de enlace de red virtual mediante Azure Portal
Eliminación de una puerta de enlace de red virtual mediante PowerShell
Eliminación de una puerta de enlace de red virtual mediante PowerShell (clásico)
3. Siga los pasos que se describen en Creación de la puerta de enlace VPN para crear la nueva puerta de enlace del
tipo deseado y completar la configuración de VPN.

NOTE
Este proceso tardará unos 60 minutos.

Pasos siguientes
Solución de problemas de conectividad entre máquinas virtuales de Azure
 Diagnóstico de un problema de filtro del tráfico de
red de una máquina virtual
23/09/2020 • 27 minutes to read • Edit Online

En este artículo, aprenderá a diagnosticar un problema de filtro del tráfico de red mediante la visualización de las
reglas de seguridad del grupo de seguridad de red (NSG) que están vigentes para una máquina virtual (VM).
Los NSG le permiten controlar los tipos de tráfico que entran y salen de una máquina virtual. Puede asociar un
NSG a una subred de una red virtual de Azure, a una interfaz de red conectada a una máquina virtual, o a ambas.
Las reglas de seguridad en vigor aplicadas a una interfaz de red se agregan a las que existen en el NSG asociado
a una interfaz de red y la subred en la que se encuentra la interfaz. Las reglas de diferentes NSG a veces pueden
entrar en conflicto entre sí y afectar la conectividad de red de la máquina virtual. Puede ver todas las reglas de
seguridad vigentes desde los NSG que se aplican a las interfaces de red de la máquina virtual. Si no está
familiarizado con los conceptos de red virtual, interfaz de red o NSG, consulte Introducción a la red virtual,
Interfaz de red e Introducción a los grupos de seguridad de red.

Escenario
Intenta conectarse a una máquina virtual en el puerto 80 desde Internet, pero se produce un error en la conexión.
Para determinar por qué no puede acceder al puerto 80 desde Internet, puede ver las reglas de seguridad
vigentes para una interfaz de red mediante Azure Portal, PowerShell o la CLI de Azure.
En los pasos que se indican a continuación se da por hecho que tiene una maquina virtual para ver las reglas de
seguridad vigentes. Si no tiene una máquina virtual, implemente primero una máquina virtual Linux o Windows
para completar las tareas de este artículo. Los ejemplos de este artículo son para una máquina virtual
denominada myVM con una interfaz de red llamada myVMVMNic. La máquina virtual y la interfaz de red están
en un grupo de recursos llamado myResourceGroup y en la región Este de EE. UU. Cambie los valores de los
pasos, según corresponda, por los de la máquina virtual cuyos problemas va a diagnosticar.

Diagnóstico mediante Azure Portal

1. Inicie sesión en Azure Portal con una cuenta de Azure que disponga de los permisos necesarios.
2. En la parte superior de Azure Portal, vaya al cuadro de búsqueda y escriba el nombre de la máquina
virtual. Cuando el nombre de la máquina virtual aparezca en los resultados de búsqueda, selecciónela.
3. En CONFIGURACIÓN , seleccione Redes , como se muestra en la imagen siguiente:
 Las reglas que se ven en la imagen anterior son para una interfaz de red denominada myVMVMNic . Verá
que hay REGL AS DE PUERTO DE ENTRADA para la interfaz de red de dos grupos de seguridad de red
diferentes:
mySubnetNSG : asociado a la subred que se encuentra en la interfaz de red.
myVMNSG : asociado a la interfaz de red de la máquina virtual denominada myVMVMNic .
La regla denominada DenyAllInBound es lo que impide la comunicación entrante con la máquina virtual
en el puerto 80, desde Internet, tal como se describe en el escenario. La regla enumera [Link]/0 para
ORIGEN , lo que incluye Internet. Ninguna otra regla con una prioridad más alta (número menor) permite
el puerto 80 de entrada. Para permitir el puerto 80 de entrada a la máquina virtual desde Internet, consulte
Resolve a problem (Resolución de un problema). Para más información acerca de las reglas de seguridad y
de la forma en que Azure las aplica, consulte Grupos de seguridad de red.
En la parte inferior de la imagen, también ve REGL AS DEL PUERTO DE SALIDA . Debajo están las reglas
del puerto de salida para la interfaz de red. Aunque la imagen solo muestra cuatro reglas de entrada para
cada NSG, sus NSG pueden tener más de cuatro. En la imagen, ve Vir tualNetwork en SOURCE
(ORIGEN) y DESTINATION (DESTINO) y AzureLoadBalancer en SOURCE (ORIGEN). Vir tualNetwork y
AzureLoadBalancer son etiquetas de servicio. Las etiquetas de servicio representan un grupo de prefijos
de direcciones IP que ayudan a reducir la complejidad de la creación de reglas de seguridad.
4. Asegúrese de que la máquina virtual está en estado de ejecución y luego seleccione Effective security
rules (Reglas de seguridad eficaces), como se muestra en la imagen anterior, para ver las reglas de
seguridad vigentes que se muestran en la siguiente imagen:
 Las reglas que se enumeran son las mismas que vio en el paso 3, aunque hay pestañas diferentes para el
grupo de seguridad de red asociado a la interfaz de red y la subred. Como puede ver en la imagen, solo se
muestran las 50 primeras reglas. Para descargar un archivo .csv que contiene todas las reglas, seleccione
Descargar .
Para ver los prefijos que representa cada etiqueta de servicio, seleccione una regla, por ejemplo, la regla
denominada AllowAzureLoadBalancerInbound . La siguiente imagen muestra los prefijos de la etiqueta
de servicio AzureLoadBalancer :

Aunque la etiqueta de servicio AzureLoadBalancer solo representa un prefijo, otras etiquetas de servicio
representan varios prefijos.
5. Los pasos anteriores mostraban las reglas de seguridad de una interfaz de red denominada
 myVMVMNic , pero también ha visto una interfaz de red llamada myVMVMNic2 en algunas de las
imágenes anteriores. La máquina virtual de este ejemplo tiene dos interfaces de red conectadas. Las reglas
de seguridad vigentes pueden ser diferentes para cada interfaz de red.
Para ver las reglas de la interfaz de red myVMVMNic2 , selecciónela. Como se muestra en la imagen
siguiente, la interfaz de red tiene las mismas reglas asociadas a su subred que la interfaz de red
myVMVMNic , ya que las dos interfaces de red se encuentran en la misma subred. Al asociar un NSG a
una subred, sus reglas se aplican a todas las interfaces de red de la subred.

A diferencia de la interfaz de red myVMVMNic , la interfaz de red myVMVMNic2 no tiene ningún grupo
de seguridad de red asociado. Cada interfaz de red y subred pueden tener un grupo de seguridad de red
asociado, o ninguno. El grupo de seguridad de red asociados a cada interfaz de red o subred puede ser el
mismo o diferente. El mismo grupo de seguridad de red se puede asociar a tantas interfaces de red y
subredes individuales como se desee.
Aunque las reglas de seguridad vigentes se vieron a través de la máquina virtual, también se puede ver a través
de un usuario individual:
Interfaz de red : aprenda a ver una interfaz de red.
NSG : aprenda a ver un grupo de seguridad de red.

Diagnóstico mediante PowerShell

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.
Puede ejecutar los comandos siguientes en Azure Cloud Shell, o mediante la ejecución de PowerShell en el
equipo. Azure Cloud Shell es un shell interactivo gratuito. Tiene las herramientas comunes de Azure preinstaladas
y configuradas para usarlas en la cuenta. Si ejecuta PowerShell desde el equipo, necesita el módulo Azure
PowerShell versión 1.0.0 o posterior. Ejecute Get-Module -ListAvailable Az en el equipo para encontrar la versión
instalada. Si necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si ejecuta PowerShell
localmente, también debe ejecutar Connect-AzAccount para iniciar sesión en Azure con una cuenta que tenga los
permisos necesarios].
Obtenga las reglas de seguridad vigentes para una interfaz de red con Get-AzEffectiveNetworkSecurityGroup. En
el ejemplo siguiente se obtienen las reglas vigentes de una interfaz de red denominada myVMVMNic, que se
encuentra en un grupo de recursos llamado myResourceGroup:

Get-AzEffectiveNetworkSecurityGroup `
-NetworkInterfaceName myVMVMNic `
-ResourceGroupName myResourceGroup

La salida se devuelve en formato json. Para comprender la salida, consulte la sección Interpretación de la salida de
los comandos. La salida solo se devuelve si un NSG está asociado a la interfaz de red, la subred en la que está la
interfaz de red, o a ambas. La máquina virtual debe estar en estado de ejecución. Una máquina virtual puede
tener varias interfaces de red con diferentes grupos de seguridad de red aplicados. Cuando esté intentando
solucionar un problema, ejecute el comando para cada interfaz de red.
Si sigue teniendo problemas de conectividad, consulte las secciones Diagnóstico adicional y Consideraciones.
Si no conoce el nombre de una interfaz de red, pero conoce el nombre de la máquina virtual a la que está
asociada la interfaz de red, los comandos siguientes devuelven los identificadores de todas las interfaces de red
asociadas a una máquina virtual:

$VM = Get-AzVM -Name myVM -ResourceGroupName myResourceGroup

$[Link]

Recibirá una salida similar a la del ejemplo siguiente:

NetworkInterfaces
-----------------
{/subscriptions/<ID>/resourceGroups/myResourceGroup/providers/[Link]/networkInterfaces/myVMVMNic

En la salida anterior, el nombre de la interfaz de red es myVMVMNic.

Diagnóstico mediante la CLI de Azure

Si usa la interfaz de la línea de comandos (CLI) de Azure para completar las tareas de este artículo, ejecute los
comandos que se encuentran en Azure Cloud Shell o ejecute la CLI en el equipo. En este artículo se requiere la CLI
de Azure versión 2.0.32 o posterior. Ejecute az --version para buscar la versión instalada. Si necesita instalarla o
actualizarla, vea Instalación de la CLI de Azure. Si ejecuta la CLI de Azure localmente, también debe ejecutar
az login e iniciar sesión en Azure con una cuenta que tenga los permisos necesarios.

Obtenga las reglas de seguridad vigentes de una interfaz de red con az network nic list-effective-nsg. En el
ejemplo siguiente se obtienen las reglas vigentes de una interfaz de red denominada myVMVMNic, que se
encuentra en un grupo de recursos llamado myResourceGroup:
 az network nic list-effective-nsg \
--name myVMVMNic \
--resource-group myResourceGroup

La salida se devuelve en formato json. Para comprender la salida, consulte la sección Interpretación de la salida de
los comandos. La salida solo se devuelve si un NSG está asociado a la interfaz de red, la subred en la que está la
interfaz de red, o a ambas. La máquina virtual debe estar en estado de ejecución. Una máquina virtual puede
tener varias interfaces de red con diferentes grupos de seguridad de red aplicados. Cuando esté intentando
solucionar un problema, ejecute el comando para cada interfaz de red.
Si sigue teniendo problemas de conectividad, consulte las secciones Diagnóstico adicional y Consideraciones.
Si no conoce el nombre de una interfaz de red, pero conoce el nombre de la máquina virtual a la que está
asociada la interfaz de red, los comandos siguientes devuelven los identificadores de todas las interfaces de red
asociadas a una máquina virtual:

az vm show \
--name myVM \
--resource-group myResourceGroup

En la salida devuelta, verá información similar a la del ejemplo siguiente:

"networkProfile": {
"additionalProperties": {},
"networkInterfaces": [
{
"additionalProperties": {},
"id":
"/subscriptions/<ID>/resourceGroups/myResourceGroup/providers/[Link]/networkInterfaces/myVMVMNic",
"primary": true,
"resourceGroup": "myResourceGroup"
},

En la salida anterior, el nombre de la interfaz de red es myVMVMNic interface.

Interpretación de la salida de los comandos

Independientemente de si ha utilizado PowerShell o la CLI de Azure para diagnosticar el problema, recibirá una
salida que contiene la siguiente información:
NetworkSecurityGroup : el identificador del grupo de seguridad de red.
Asociación : si el grupo de seguridad de red está asociado a una interfaz de red o una subred. Si un NSG está
asociado a ambos, se devuelve la salida con NetworkSecurityGroup , Association y
EffectiveSecurityRules , para cada NSG. Si el grupo de seguridad de red se asocia o disocia inmediatamente
antes de ejecutar el comando para ver las reglas de seguridad vigentes, es posible que tenga que esperar unos
segundos para que el cambio se refleje en la salida del comando.
EffectiveSecurityRules : en Creación de una regla de seguridad se proporciona una explicación de cada
propiedad. Los nombres de regla precedidos por defaultSecurityRules/ son las reglas de seguridad
predeterminadas que existen en todos los grupos de seguridad de red. Los nombres de regla precedidos por
securityRules/ son reglas que ha creado. Las reglas que especifican una etiqueta de servicio, como Internet ,
Vir tualNetwork y AzureLoadBalancer para las propiedades destinationAddressPrefix o
sourceAddressPrefix también tienen valores para la propiedad expandedDestinationAddressPrefix . La
propiedad expandedDestinationAddressPrefix enumera todos los prefijos de dirección representados por
la etiqueta de servicio.
Si ve reglas duplicadas en la salida, es porque hay un grupo de seguridad de red asociado a la interfaz de red y la
subred. Ambos NSG tienen las mismas reglas predeterminadas y pueden tener reglas duplicadas adicionales si
ha creado sus propias reglas y son las mismas en ambos grupos de seguridad de red.
La regla denominada defaultSecurityRules/DenyAllInBound es lo que impide la comunicación entrante con
la máquina virtual en el puerto 80, desde Internet, tal como se describe en el escenario. Ninguna otra regla con
una prioridad más alta (número menor) permite el puerto 80 de entrada desde Internet.

Resolución de un problema
Independientemente de que utilice Azure Portal, PowerShell o la CLI de Azure para diagnosticar el problema que
se presenta en el escenario de este artículo, la solución consiste en crear una regla de seguridad de red con las
siguientes propiedades:

P RO P IEDA D VA L UE

Source Any

Source port ranges Any

Destination La dirección IP de la máquina virtual, un intervalo de

direcciones IP o todas las direcciones de la subred.

Intervalos de puertos de destino 80

Protocolo TCP

Acción Allow

Priority 100

Nombre Allow-HTTP-All

Después de crear la regla, el puerto 80 está permitido de entrada desde Internet, ya que la prioridad de la regla es
mayor que la regla de seguridad predeterminada llamada DenyAllInBound, que deniega el tráfico. Aprenda a
crear una regla de seguridad. Si hay diferentes grupos de seguridad de red asociados tanto a la interfaz de red
como a la subred, debe crear la misma regla en los dos grupos de seguridad de red.
Cuando Azure procesa el tráfico entrante, procesa las reglas del grupo de seguridad de red asociado a la subred
(si hay alguno) y, después, procesa las reglas del grupo de seguridad de red asociado a la interfaz de red. Si hay
un grupo de seguridad de red asociado tanto a la interfaz de red como la subred, el puerto debe estar abierto en
ambos grupos de seguridad de red para que el tráfico llegue a la máquina virtual. Para solucionar los problemas
de administración y la comunicación, se recomienda asociar un grupo de seguridad de red a una subred, en lugar
de a interfaces de red individuales. Si las máquinas virtuales de una subred necesitan reglas de seguridad
diferentes, puede hacer que los miembros de las interfaces de red de un grupo de seguridad de aplicaciones
(ASG) y especifique un ASG como origen y destino de una regla de seguridad. Más información acerca de los
grupos de seguridad de aplicaciones.
Si sigue teniendo problemas de comunicación, consulte las secciones Consideraciones y Diagnóstico adicional.

Consideraciones
Tenga en cuenta los puntos siguientes cuando tenga que solucionar problemas de conectividad:
Las reglas de seguridad predeterminadas bloquean el acceso de entrada desde Internet y solo permiten el
 tráfico entrante desde la red virtual. Para permitir el tráfico entrante desde Internet, agregue reglas de
seguridad con una prioridad más alta que las reglas predeterminadas. Obtenga más información acerca de las
reglas de seguridad predeterminadas o de cómo agregar una regla de seguridad.
Si ha emparejado redes virtuales, de forma predeterminada, la etiqueta de servicio VIRTUAL_NETWORK se
expande automáticamente para incluir prefijos para las redes virtuales emparejadas. Para solucionar los
problemas relacionados con el emparejamiento de redes virtuales, puede ver los prefijos en la lista
ExpandedAddressPrefix . Obtenga más información acerca del emparejamiento de redes virtuales y de las
etiquetas de servicio.
Las reglas de seguridad vigentes solo se muestran para una interfaz de red si hay un grupo de seguridad de
red asociado a la interfaz de red de la máquina virtual o a la subred, y si la máquina virtual está en estado de
ejecución.
Si no hay ningún grupo de seguridad de red asociado a la interfaz de red o a la subred y tiene una dirección IP
pública asignada a una máquina virtual, todos los puertos estarán abiertos para el acceso entrante y saliente a
y desde cualquier lugar. Si la máquina virtual tiene una dirección IP pública, es aconsejable aplicar un grupo de
seguridad de red a la subred o a la interfaz de red.

Diagnóstico adicional
Para ejecutar una prueba rápida para determinar si se permite que haya tráfico que llegué a una máquina
virtual, o que salga de ella, use la funcionalidad de comprobación del flujo de IP de Azure Network Watcher.
Comprobación del flujo de IP indica si el tráfico se permite o se deniega. Si se deniega, Comprobación del flujo
de IP indica la regla de seguridad que deniega el tráfico.
Si no reglas de seguridad de provoquen errores en la conectividad de red de una máquina virtual, el problema
puede deberse a:
Software de firewall que se esté ejecutando en el sistema operativo de la máquina virtual
Rutas configuradas para dispositivos virtuales o para el tráfico local. El tráfico de Internet puede
redirigirse a una red local a través de la tunelización forzada. Si se fuerza el tráfico de Internet del túnel
a una aplicación virtual, o local, es posible que no pueda conectarse a la máquina virtual desde internet.
Para aprender a diagnosticar los problemas de ruta que pueden impedir el flujo del tráfico que sale de
la máquina virtual, consulte Diagnose a virtual machine routing problem (Diagnóstico de un problema
de enrutamiento del tráfico de red de una máquina virtual).

Pasos siguientes
Obtenga información acerca de todas las tareas, propiedades y valores de un grupo de seguridad de red y de
las reglas de seguridad.
Obtenga información acerca de las reglas de seguridad predeterminadas, las etiquetas de servicio, así como
de la forma en que Azure procesa las reglas de seguridad para el tráfico entrante y saliente en una máquina
virtual.
 Diagnóstico de problemas de enrutamiento en una
máquina virtual
23/09/2020 • 20 minutes to read • Edit Online

En este artículo, aprenderá a diagnosticar un problema de enrutamiento mediante la visualización de las rutas
que son eficaces para una interfaz de red en una máquina virtual (VM). Azure crea varias rutas predeterminadas
para cada subred de red virtual. Puede invalidar las rutas predeterminadas de Azure mediante la definición de
rutas en una tabla de rutas y la asociación de dicha tabla a una subred. La combinación de rutas que cree, las
rutas predeterminadas de Azure y las rutas que se propagan desde la red local a través de una puerta de enlace
de VPN de Azure (si la red virtual está conectada a la red local) mediante el protocolo de puerta de enlace de
borde (BGP), son la rutas eficaces para todas las interfaces de red de una subred. Si no está familiarizado con los
conceptos de red virtual, interfaz de red o enrutamiento, consulte Introducción a la red virtual, Interfaz de red e
Introducción al enrutamiento.

Escenario
Intenta conectarse a una máquina virtual, pero se produce un error en la conexión. Para determinar por qué no
puede conectarse a la máquina virtual, puede ver las rutas eficaces para una interfaz de red mediante Azure
Portal, PowerShell o la CLI de Azure.
En los pasos que vienen a continuación se da por hecho que tiene una máquina virtual para la que ver las rutas
eficaces. Si no tiene una máquina virtual, implemente primero una máquina virtual Linux o Windows para
completar las tareas de este artículo. Los ejemplos de este artículo son para una VM denominada myVM con una
interfaz de red llamada myVMNic1. La máquina virtual y la interfaz de red están en un grupo de recursos
llamado myResourceGroup y en la región Este de EE. UU. Cambie los valores de los pasos, según corresponda,
por los de la máquina virtual cuyos problemas va a diagnosticar.

Diagnóstico mediante Azure Portal

1. Inicie sesión en Azure Portal con una cuenta de Azure que disponga de los permisos necesarios.
2. En la parte superior de Azure Portal, vaya al cuadro de búsqueda y escriba el nombre de una máquina
virtual que se encuentre en estado de ejecución. Cuando el nombre de la máquina virtual aparezca en los
resultados de búsqueda, selecciónela.
3. En Configuración a la izquierda, seleccione Redes y navegue hasta el recurso de interfaz de red
seleccionando su nombre.
4. A la izquierda, seleccione Rutas eficaces . Se muestran las rutas eficaces de una interfaz de red llamada
myVMNic1 , como se ilustra en la imagen siguiente:

Si hay varias interfaces de red asociadas a la máquina virtual, puede ver las rutas eficaces de cada interfaz
de red; para ello, basta con seleccionarla. Puesto que cada interfaz de red puede estar en una subred
diferente, también puede tener cada una diferentes rutas eficaces.
En el ejemplo mostrado en la imagen anterior, las rutas enumeradas son rutas predeterminadas que crea
Azure para cada subred. Su lista tiene como mínimo estas rutas, pero puede tener rutas adicionales, según
las funcionalidades que pueda haber habilitado para la red virtual; por ejemplo, estar emparejada con otra
red virtual o conectada a la red local mediante una puerta de enlace VPN de Azure. Para más información
sobre cada una de las rutas y otras rutas que puede ver para la red virtual, consulte Enrutamiento del
tráfico de redes virtuales. Si la lista tiene un gran número de rutas, quizá le resulte más fácil seleccionar
Descargar para descargar un archivo .csv con la lista de rutas.
Aunque las rutas eficaces se vieron mediante la máquina virtual en los pasos anteriores, también puede verlas
mediante una:
Interfaz de red individual : aprenda a ver una interfaz de red.
Tabla de rutas individual : aprenda cómo ver una tabla de rutas.

Diagnóstico mediante PowerShell

 NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module
(Presentación del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az,
consulte Instalación de Azure PowerShell.

Puede ejecutar los comandos siguientes en Azure Cloud Shell, o mediante la ejecución de PowerShell en el
equipo. Azure Cloud Shell es un shell interactivo gratuito. Tiene las herramientas comunes de Azure
preinstaladas y configuradas para usarlas en la cuenta. Si ejecuta PowerShell desde el equipo, necesita el módulo
Azure PowerShell versión 1.0.0 o posterior. Ejecute Get-Module -ListAvailable Az en el equipo para encontrar la
versión instalada. Si necesita actualizarla, consulte Instalación del módulo de Azure PowerShell. Si ejecuta
PowerShell localmente, también debe ejecutar Connect-AzAccount para iniciar sesión en Azure con una cuenta
que tenga los permisos necesarios.
Obtenga rutas eficaces para una interfaz de red con Get-AzEffectiveRouteTable. En el ejemplo siguiente se
obtienen las rutas eficaces de una interfaz de red llamada myVMNic1, que se encuentra en un grupo de recursos
denominado myResourceGroup:

Get-AzEffectiveRouteTable `
-NetworkInterfaceName myVMNic1 `
-ResourceGroupName myResourceGroup `
| Format-Table

Para entender la información devuelta en la salida, consulte Introducción al enrutamiento. Solo se devuelve la
salida si la máquina virtual está en estado de ejecución. Si hay varias interfaces de red asociadas a la máquina
virtual, puede revisar las rutas eficaces para cada interfaz de red. Puesto que cada interfaz de red puede estar en
una subred diferente, también puede tener cada una diferentes rutas eficaces. Si sigue teniendo problemas de
comunicación, consulte las secciones Diagnóstico adicional y Consideraciones.
Si no conoce el nombre de una interfaz de red, pero conoce el nombre de la máquina virtual a la que está
asociada la interfaz de red, los comandos siguientes devuelven los identificadores de todas las interfaces de red
asociadas a una máquina virtual:

$VM = Get-AzVM -Name myVM `

-ResourceGroupName myResourceGroup
$[Link]

Recibirá una salida similar a la del ejemplo siguiente:

NetworkInterfaces
-----------------
{/subscriptions/<ID>/resourceGroups/myResourceGroup/providers/[Link]/networkInterfaces/myVMNic1

En la salida anterior, el nombre de la interfaz de red es myVMNic1.

Diagnóstico mediante la CLI de Azure

Puede ejecutar los comandos siguientes en Azure Cloud Shell, o mediante la ejecución de la CLI en el equipo. En
este artículo se requiere la CLI de Azure versión 2.0.32 o posterior. Ejecute az --version para buscar la versión
instalada. Si necesita instalarla o actualizarla, vea Instalación de la CLI de Azure. Si ejecuta la CLI de Azure
localmente, también debe ejecutar az login e iniciar sesión en Azure con una cuenta que tenga los permisos
necesarios.
Obtenga las rutas eficaces de una interfaz de red con az network nic show-effective-route-table. En el ejemplo
siguiente se obtienen las rutas eficaces de una interfaz de red llamada myVMNic1, que se encuentra en un grupo
de recursos denominado myResourceGroup:

az network nic show-effective-route-table \

--name myVMNic1 \
--resource-group myResourceGroup

Para entender la información devuelta en la salida, consulte Introducción al enrutamiento. Solo se devuelve la
salida si la máquina virtual está en estado de ejecución. Si hay varias interfaces de red asociadas a la máquina
virtual, puede revisar las rutas eficaces para cada interfaz de red. Puesto que cada interfaz de red puede estar en
una subred diferente, también puede tener cada una diferentes rutas eficaces. Si sigue teniendo problemas de
comunicación, consulte las secciones Diagnóstico adicional y Consideraciones.
Si no conoce el nombre de una interfaz de red, pero conoce el nombre de la máquina virtual a la que está
asociada la interfaz de red, los comandos siguientes devuelven los identificadores de todas las interfaces de red
asociadas a una máquina virtual:

az vm show \
--name myVM \
--resource-group myResourceGroup

Resolución de un problema
La resolución de problemas de enrutamiento supone normalmente:
Agregar una ruta personalizada para invalidar una de las rutas predeterminadas de Azure. Aprenda cómo
agregar una ruta personalizada.
Cambiar o quitar una ruta personalizada que puede provocar el enrutamiento a una ubicación no deseada.
Aprenda cómo cambiar o eliminar una ruta personalizada.
Asegurarse de que la tabla de rutas que contiene las rutas personalizadas que ha definido está asociada a la
subred en la que se encuentra la interfaz de red. Aprenda cómo asociar una tabla de rutas a una subred.
Asegurarse de que los dispositivos, como las aplicaciones virtuales de red o de puerta de enlace de VPN que
ha implementado se pueden usar. Use la funcionalidad Diagnósticos de VPN de Network Watcher para
determinar los problemas con una puerta de enlace de VPN de Azure.
Si sigue teniendo problemas de comunicación, consulte las secciones Consideraciones y Diagnóstico adicional.

Consideraciones
Tenga en cuenta los puntos siguientes cuando tenga que solucionar problemas de comunicación:
El enrutamiento se basa en la coincidencia con el prefijo más largo (LPM) entre las rutas que ha definido, el
protocolo de puerta de enlace de borde (BGP) y las rutas del sistema. Si hay más de una ruta con la misma
coincidencia LPM, la ruta se selecciona entonces en función de su origen en el orden enumerado en
Introducción al enrutamiento. En el caso de las rutas eficaces, solo puede ver aquellas que tienen una
coincidencia LPM basada en todas las rutas disponibles. Ver cómo se evalúan las rutas de una interfaz de red
facilita en gran medida la solución de problemas con rutas específicas que podrían estar afectando a la
comunicación desde la máquina virtual.
Si ha definido rutas personalizadas a una aplicación virtual de red (NVA), con Aplicación virtual como el
siguiente tipo de salto, asegúrese de que el reenvío de direcciones IP esté habilitado en la NVA que recibe el
tráfico o se perderán los paquetes. Aprenda más sobre cómo habilitar el reenvío de direcciones IP para una
 interfaz de red. Además, el sistema operativo o la aplicación de la NVA también deben poder reenviar el
tráfico de red y se deben configurar para ello.
Si ha creado una ruta a [Link]/0, todo el tráfico saliente de Internet se enruta al próximo salto que
especifique, por ejemplo, a una NVA o una puerta de enlace de VPN. La creación de una ruta de este tipo se
conoce a veces como tunelización forzada. Puede que las conexiones remotas que usan los protocolos RDP o
SSH desde Internet hasta la máquina virtual no funcionen con esta ruta, en función de cómo el próximo salto
administre el tráfico. Puede habilitar la tunelización forzada:
Cuando se usa VPN de sitio a sitio, mediante la creación de una ruta con un tipo de próximo salto de
Puerta de enlace de VPN. Aprenda más sobre cómo configurar la tunelización forzada.
Si [Link]/0 (ruta predeterminada) se anuncia sobre BGP mediante una puerta de enlace de red virtual
al usar VPN de sitio a sitio o un circuito ExpressRoute. Aprenda más sobre el uso de BGP con una VPN
de sitio a sitio o ExpressRoute.
Para que el tráfico de emparejamiento de red virtual funcione correctamente, debe existir una ruta del
sistema con un tipo de próximo salto de Emparejamiento de VNet para el intervalo de prefijos de la red
virtual emparejada. Si la ruta no existe y el vínculo de emparejamiento de la red virtual es Conectado :
Espere unos segundos e inténtelo de nuevo. Si es un vínculo de emparejamiento recién establecido, en
ocasiones las rutas tardan más tiempo en propagarse a todas las interfaces de red de una subred. Para
más información sobre el emparejamiento de redes virtuales, consulte Introducción al
emparejamiento de redes virtuales y Administración del emparejamientos de redes virtuales.
Las reglas del grupo de seguridad podrían estar afectando a la comunicación. Para más información,
consulte Diagnose a virtual machine network traffic filter problem (Diagnóstico de problemas de filtro
del tráfico de red de la máquina virtual).
Aunque Azure asigna rutas predeterminadas a cada interfaz de red de Azure, si tiene varias interfaces de red
asociadas a la máquina virtual, solo a la interfaz de red principal se le asigna una ruta predeterminada
([Link]/0), o puerta de enlace, dentro del sistema operativo de la máquina virtual. Aprenda a crear una ruta
predeterminada para las interfaces de red secundarias asociadas a una máquina virtual Windows o Linux.
Aprenda más sobre las interfaces de red principales y secundarias.

Diagnóstico adicional
Para ejecutar una prueba rápida con el fin de determinar el tipo de próximo salto para el tráfico destinado a
una ubicación, use la funcionalidad Próximo salto de Azure Network Watcher. El próximo salto indica cuál es
el tipo de próximo salto para el tráfico destinado a una ubicación especificada.
Si no es una ruta la causante del error de comunicación de red de la máquina virtual, el problema puede
deberse a que se está ejecutando software de firewall dentro del sistema operativo de la máquina virtual.
Si está realizando la tunelización forzada del tráfico a un dispositivo local mediante una puerta de enlace de
VPN o una NVA, es posible que no pueda conectarse a una máquina virtual desde Internet, según cómo haya
configurado el enrutamiento en los dispositivos. Confirme que el enrutamiento que ha configurado para el
dispositivo enruta el tráfico a una dirección IP pública o privada de la máquina virtual.
Use la funcionalidad de solución de problemas de conexión de Network Watcher para determinar las causas
de los problemas de comunicación salientes relacionados con el enrutamiento, el filtrado y el sistema
operativo.

Pasos siguientes
Aprenda sobre todas las tareas, propiedades y configuraciones de tablas de rutas y rutas.
Aprenda sobre todos los tipos de próximo salto y rutas del sistema, y cómo Azure selecciona las rutas.
 Pruebas de ancho de banda y rendimiento (NTTTCP)
23/09/2020 • 7 minutes to read • Edit Online

Al probar el rendimiento de la red de Azure, se recomienda usar una herramienta que tenga como destino de la
red para realizar pruebas y minimizar el uso de otros recursos que podrían afectar al rendimiento. Se recomienda
NTTTCP.
Copie la herramienta en dos máquinas virtuales de Azure del mismo tamaño. Una máquina virtual funciona como
remitente y la otra como receptora.
Implementación de máquinas virtuales para pruebas
Para los fines de esta prueba, las dos máquinas virtuales deben tener el mismo servicio en la nube o el mismo
conjunto de disponibilidad para que podamos usar sus direcciones IP internas y excluir los equilibradores de carga
de la prueba. Es posible realizar pruebas con la dirección VIP, pero este tipo de pruebas está fuera del ámbito de
este documento.
Tome nota de la dirección IP del DESTINATARIO. Vamos a llamar a esa dirección IP "a.b.c.r".
Tome nota del número de núcleos de la máquina virtual. Llamémoslo "#num_cores".
Ejecute la prueba NTTTCP durante 300 segundos (o 5 minutos) en la máquina virtual del remitente y en la del
receptor.
Sugerencia: Al configurar esta prueba por primera vez, puede probar un período de prueba más corto para
obtener antes comentarios. Una vez que la herramienta funciona según lo esperado, amplíe el período de prueba
en 300 segundos para obtener resultados más precisos.

NOTE
El remitente y el receptor deben especificar el mismo parámetro de duración de prueba (-t).

Para probar un único flujo TCP durante 10 segundos:

Parámetros de receptor: ntttcp -r -t 10 -P 1
Parámetros de remitente: ntttcp -s10.27.33.7 -t 10 -n 1 -P 1

NOTE
El ejemplo anterior solo debe emplearse para confirmar la configuración. Más adelante en este documento se ofrecen
ejemplos válidos de pruebas.

Pruebas de máquinas virtuales que ejecutan WINDOWS:

Obtenga NTTTCP en las máquinas virtuales.
Descargue la versión más reciente: [Link]
O búsquela si se ha migrado: [Link] (debe ser el primer resultado)
Considere la colocar NTTTCP en una carpeta independiente, como c:\tools.
Procedimiento para permitir NTTTCP a través del Firewall de Windows
En el RECEPTOR, cree una regla Permitir en el Firewall de Windows para permitir la recepción de tráfico NTTTCP. Es
más fácil permitir todo el programa NTTTCP por su nombre en lugar de determinados puertos TCP de entrada.
Permita NTTTCP a través del Firewall de Windows de la siguiente forma:
netsh advfirewall firewall add rule program=<PATH>\[Link] name="ntttcp" protocol=any dir=in action=allow
enable=yes profile=ANY
Por ejemplo, si ha copiado [Link] a la carpeta "c:\tools", este sería el comando:
netsh advfirewall firewall add rule program=c:\tools\[Link] name="ntttcp" protocol=any dir=in action=allow
enable=yes profile=ANY
Ejecución de pruebas de NTTTCP
Inicie NTTTCP en el RECEPTOR (se ejecuta desde CMD , no desde PowerShell):
ntttcp -r –m [2*#num_cores],*,a.b.c.r -t 300
Si la máquina virtual tiene cuatro núcleos y una dirección IP [Link], sería similar al siguiente:
ntttcp -r –m 8,*,[Link] -t 300
Inicie NTTTCP en el REMITENTE (se ejecuta desde CMD , no desde PowerShell)::
ntttcp -s –m 8,*,[Link] -t 300
Espere a que se muestren los resultados.

Pruebas de máquinas virtuales que ejecutan LINUX:

Use nttcp-for-linux. Está disponible en [Link]
En las máquinas virtuales de Linux (REMITENTE y RECEPTOR), ejecute estos comandos para preparar ntttcp-for-
linux en las máquinas virtuales:
CentOS: instalación de Git:

yum install gcc -y

yum install git -y

Ubuntu: instalación de Git:

apt-get -y install build-essential

apt-get -y install git

Cree e instale en ambas:

git clone [Link]

cd ntttcp-for-linux/src
make && make install

Como en el ejemplo de Windows, supongamos que la IP del RECEPTOR Linux es [Link].

Inicie ntttcp-for-linux en el RECEPTOR:

ntttcp -r -t 300

Y en el REMITENTE, ejecute:
 ntttcp -s10.0.0.4 -t 300

Los valores predeterminados de duración de prueba están establecidos en 60 segundos si no hay ningún
parámetro de tiempo.

Pruebas entre máquinas virtuales que ejecutan Windows y Linux:

En estos escenarios, se debería habilitar el modo sin sincronización para que la prueba pueda ejecutarse. Para ello,
use -N flag para Linux y -ns flag para Windows.
De Linux a Windows:
Receptor<Windows>:

ntttcp -r -m <2 x nr cores>,*,<Windows server IP>

Remitente<Linux> :

ntttcp -s -m <2 x nr cores>,*,<Windows server IP> -N -t 300

De Windows a Linux:
Receptor<Linux>:

ntttcp -r -m <2 x nr cores>,*,<Linux server IP>

Remitente<Windows>:

ntttcp -s -m <2 x nr cores>,*,<Linux server IP> -ns -t 300

Prueba de instancias de servicio en la nube:

Debe agregar la siguiente sección en [Link].

<Endpoints>
<InternalEndpoint name="Endpoint3" protocol="any" />
</Endpoints>

Pasos siguientes
Dependiendo de los resultados, puede que haya espacio para optimizar máquinas de rendimiento de red para
su escenario.
Obtenga información acerca de cómo se asigna el ancho de banda a las máquinas virtuales
Obtenga más información con las Preguntas más frecuentes (P+F) acerca de Azure Virtual Network
 Comprobación de la latencia de red de VM
23/09/2020 • 11 minutes to read • Edit Online

Para que los resultados que se logren sean lo más precisos posible, mida la latencia de la red de las máquinas
virtuales (VM) de Azure con una herramienta diseñada para tal fin. Algunas herramientas disponibles
públicamente, como SockPerf (para Linux) y [Link] (para Windows) permiten aislar y medir la latencia de red, a la
vez que excluyen otros tipos de latencia, como la de las aplicaciones. Estas herramientas se centran en el tipo de
tráfico de red que afecta al rendimiento de la aplicación (es decir, el tráfico TCP [protocolo de control de
transmisión] y UDP [protocolo de datagramas de usuario]).
Otras herramientas de conectividad comunes, como Ping, pueden medir la latencia, pero es posible que sus
resultados no representen el tráfico de red que se usa en las cargas de trabajo reales. Eso se debe a que la mayoría
de estas herramientas emplean el protocolo de mensajes de control de Internet (ICMP), que puede tratarse de
forma diferente al tráfico de la aplicación y cuyos resultados es posible que no se apliquen a las cargas de trabajo
en las que se usa TCP y UDP.
Para realizar pruebas precisas de la latencia de red de los protocolos usados por la mayoría de las aplicaciones,
SockPerf (para Linux) y [Link] (para Windows) generan los resultados más pertinentes. En este artículo se
describen ambas herramientas.

Información general
El uso de dos máquinas virtuales, una como remitente y otra como receptor, permite crear un canal de
comunicaciones bidireccional. Con este enfoque, puede enviar y recibir paquetes en ambas direcciones y medir el
tiempo de ida y vuelta (RTT).
También puede usarlo para medir la latencia de red entre dos máquinas virtuales, o incluso entre dos equipos
físicos. Las medidas de latencia pueden ser útiles para los escenarios siguientes:
Establecer una prueba comparativa de la latencia de red entre las máquinas virtuales implementadas.
Comparar los efectos de los cambios en la latencia de red después de que se realicen cambios relacionados en:
El sistema operativo o el software de la pila de red, lo que incluye los cambios de configuración.
Un método de implementación de la máquina virtual, como la implementación en una zona de
disponibilidad o en un grupo de selección de ubicación de proximidad (PPG).
Las propiedades de la máquina virtual, como Redes aceleradas o cambios de tamaño.
Una red virtual, como el enrutamiento o el filtrado de cambios.
Herramientas para pruebas
Para medir la latencia, hay dos herramientas diferentes:
Para sistemas con Windows: [Link] (Windows)
Para sistemas con Linux: SockPerf (Linux)
Con estas herramientas se asegura de que solo se miden los tiempos de entrega de la carga TCP o UDP, pero no
ICMP (ping) u otros tipos de paquetes que no usen las aplicaciones y que no afecten a su rendimiento.
Sugerencias para crear una configuración óptima de las máquinas virtuales
Al crear la configuración de una máquina virtual, tenga en cuenta las siguientes recomendaciones:
Use la versión más reciente de Windows o Linux.
Habilite Redes aceleradas para obtener los mejores resultados.
 Implemente las máquinas virtuales con un grupo de selección de ubicación de proximidad de Azure.
Las máquinas virtuales grandes generalmente funcionan mejor que las pequeñas.
Sugerencias para el análisis
Cuando analice los resultados de las pruebas, tenga en cuenta las siguientes recomendaciones:
Establezca una línea de base rápidamente, en cuanto se completen la implementación, la configuración y las
optimizaciones.
Compare siempre los nuevos resultados con una línea de base o los resultados de una prueba con los de otra
con cambios controlados.
Repita las pruebas cada vez que se observen o se planeen cambios.

Realización de pruebas en máquinas virtuales que usan Windows

Instalación de [Link] en las máquinas virtuales
Descargue la versión más reciente de [Link].
Considere la posibilidad de colocar [Link] en una carpeta independiente, como c:\tools.
Permitir que [Link] pase el Firewall de Windows Defender
En el receptor, cree una regla de permiso en el Firewall de Windows Defender para permitir que llegue el tráfico de
[Link]. Es más fácil permitir todo el programa [Link] por su nombre que determinados puertos TCP de entrada.
Deje que [Link] atraviese el Firewall de Windows Defender, para lo que debe ejecutar el siguiente comando:

netsh advfirewall firewall add rule program=<path>\[Link] name="Latte" protocol=any dir=in action=allow
enable=yes profile=ANY

Por ejemplo, si ha copiado [Link] en la carpeta c:\tools, este sería el comando:

netsh advfirewall firewall add rule program=c:\tools\[Link] name="Latte" protocol=any dir=in action=allow
enable=yes profile=ANY

Ejecución de pruebas de latencia

En el receptor, inicie [Link] (ejecútelo desde la ventana del símbolo del sistema, no desde PowerShell):

latte -a <Receiver IP address>:<port> -i <iterations>

Para obtener unos resultados representativos, es suficiente la realización de unas 65 000 iteraciones.
Cualquier número de puerto disponible es válido.
Si la máquina virtual tiene la dirección IP [Link], el comando sería similar a este:
latte -a [Link]:5005 -i 65100

En el emisor, inicie [Link] (ejecútelo desde la ventana del símbolo del sistema, no desde PowerShell):

latte -c -a <Receiver IP address>:<port> -i <iterations>

El comando resultante es el mismo que en el receptor, salvo que se agrega -c para indicar que se trata del
cliente o emisor:
latte -c -a [Link]:5005 -i 65100

Espere a que se muestren los resultados. En función de la distancia que haya entre las máquinas virtuales, la prueba
podría tardar unos minutos en finalizar. Considere comenzar con menos iteraciones para probar si se ha realizado
correctamente antes de ejecutar pruebas más largas.

Realización de pruebas en máquinas virtuales que usan Linux

Para realizar pruebas en máquinas virtuales en las que se ejecutan Linux, use SockPerf.
Instalación de SockPerf en las máquinas virtuales
En las máquinas virtuales Linux, tanto el emisor como el receptor ejecutan los siguientes comandos para preparar
SockPerf en las máquinas virtuales. Se proporcionan comandos para las principales distribuciones.
Para Red Hat Enterprise Linux (RHEL)/CentOS
Ejecute los comandos siguientes:

#RHEL/CentOS - Install Git and other helpful tools

sudo yum install gcc -y -q
sudo yum install git -y -q
sudo yum install gcc-c++ -y
sudo yum install ncurses-devel -y
sudo yum install -y automake
sudo yum install -y autoconf

Para Ubuntu
Ejecute los comandos siguientes:

#Ubuntu - Install Git and other helpful tools

sudo apt-get install build-essential -y
sudo apt-get install git -y -q
sudo apt-get install -y autotools-dev
sudo apt-get install -y automake
sudo apt-get install -y autoconf

Para todas las distribuciones

Copie, compile e instale SockPerf siguiendo estos pasos:

#Bash - all distros

#From bash command line (assumes Git is installed)

git clone [Link]
cd sockperf/
./[Link]
./configure --prefix=

#make is slower, may take several minutes

make

#make install is fast

sudo make install

Ejecución de SockPerf en las máquinas virtuales

Después de que se complete la instalación de SockPerf, las máquinas virtuales están listas para ejecutar las pruebas
de latencia.
En primer lugar, inicie SockPerf en el receptor.
Cualquier número de puerto disponible es válido. En este ejemplo, se usa el puerto 12345:
 #Server/Receiver - assumes server's IP is [Link]:
sudo sockperf sr --tcp -i [Link] -p 12345

Ahora que el servidor está a la escucha, el cliente puede empezar a enviarle paquetes al puerto en el que realiza la
escucha (en este caso 12345).
Bastan unos 100 segundos para que se devuelvan resultados representativos, como se muestra en el ejemplo
siguiente:

#Client/Sender - assumes server's IP is [Link]:

sockperf ping-pong -i [Link] --tcp -m 350 -t 101 -p 12345 --full-rtt

Espere a que se muestren los resultados. En función de la distancia entre las máquinas virtuales, el número de
iteraciones variará. Para comprobar que las pruebas se realizan de forma correcta, antes de ejecutar pruebas largas
considere la posibilidad comenzar con pruebas cortas, de unos 5 segundos.
En este ejemplo de SockPerf se usa un tamaño de mensaje de 350 bytes, el cual es un paquete medio típico. Puede
aumentar o reducir el tamaño para lograr resultados que representen con mayor precisión la carga de trabajo que
se ejecuta en las máquinas virtuales.

Pasos siguientes
Mejore la latencia con un grupo de selección de ubicación de proximidad de Azure.
Aprenda a optimizar las redes para las máquinas virtuales en su escenario.
Obtenga información acerca de la asignación del ancho de banda a las máquinas virtuales.
Para más información, consulte Preguntas más frecuentes acerca de Azure Virtual Network.
 Solución de problemas: No se pudo eliminar una red
virtual en Azure
23/09/2020 • 5 minutes to read • Edit Online

Podría recibir errores al intentar eliminar una red virtual en Microsoft Azure. Este artículo proporciona pasos de
solución de problemas para ayudarle a resolver este problema.
Si su problema con Azure no se trata en este artículo, visite los foros de Azure en MSDN y Stack Overflow. Puede
publicar su problema en ellos o @AzureSupport en Twitter. También puede enviar una solicitud de soporte técnico
de Azure. Para enviar una solicitud de soporte técnico, en la página de soporte técnico de Azure, seleccione
Obtener sopor te técnico .

Guía de solución de problemas

1. Compruebe si se está ejecutando una puerta de enlace de red virtual en la red virtual.
2. Compruebe si se está ejecutando una puerta de enlace de aplicación en la red virtual.
3. Compruebe si Azure Active Directory Domain Service está habilitado en la red virtual.
4. Compruebe si la red virtual está conectada a otro recurso.
5. Compruebe si aún se está ejecutando una máquina virtual en la red virtual.
6. Compruebe si la red virtual se quedó bloqueada en la migración.

Pasos para solucionar problemas

Compruebe si se está ejecutando una puerta de enlace de red virtual en la red virtual
Para quitar la red virtual, primero debe quitar la puerta de enlace de red virtual.
Para las redes virtuales clásicas, vaya a la página Información general de la red virtual clásica en Azure Portal. En
la sección Conexiones VPN , si la puerta de enlace se está ejecutado en la red virtual, verá la dirección IP de la
puerta de enlace.
En las redes virtuales, vaya a la página Información general de la red virtual. Compruebe si hay Dispositivos
conectados para la puerta de enlace de red virtual.

Para poder quitar la puerta de enlace, quite primero todos los objetos Conexión de la puerta de enlace.
Compruebe si se está ejecutando una puerta de enlace de aplicación en la red virtual
Vaya a la página Información general de la red virtual. Compruebe si hay Dispositivos conectados para la
puerta de enlace de aplicación.

Si hay una puerta de enlace de aplicación, debe quitarla para poder eliminar la red virtual.
Compruebe si Azure Active Directory Domain Services está habilitado en la red virtual
Si Active Directory Domain Services está habilitado y conectado a la red virtual, no se puede eliminar esta red
virtual.
Para deshabilitar el servicio, consulte Deshabilitar Azure Active Directory Domain Services con Azure Portal.
Compruebe si la red virtual está conectada a otro recurso
Busque vínculos de circuito, conexiones y emparejamientos de red virtual. Cualquiera de ellos puede ocasionar
errores en la operación de eliminación de una red virtual.
El orden de eliminación recomendado es como sigue:
1. Conexiones de puerta de enlace
2. Puertas de enlace
3. Direcciones IP
4. Emparejamientos de red virtual
5. App Service Environment (ASE)
Compruebe si aún se está ejecutando una máquina virtual en la red virtual
Asegúrese de que ninguna máquina virtual está en la red virtual.
Compruebe si la red virtual se quedó bloqueada en la migración
Si la red virtual se quedó bloqueada en estado de migración, no se puede eliminar. Ejecute el siguiente comando
para anular la migración y, a continuación, elimine la red virtual.

Move-AzureVirtualNetwork -VirtualNetworkName "Name" -Abort

Pasos siguientes
Azure Virtual Network
Preguntas más frecuentes (P+F) acerca de Azure Virtual Network
 Solución de problemas de conectividad entre
máquinas virtuales de Azure
23/09/2020 • 7 minutes to read • Edit Online

Podría experimentar problemas de conectividad entre máquinas virtuales de Azure. Este artículo proporciona pasos
de solución de problemas para ayudarle a resolver este problema.
Si su problema con Azure no se trata en este artículo, visite los foros de Azure en MSDN y Stack Overflow. Puede
publicar su problema en ellos o @AzureSupport en Twitter. También puede enviar una solicitud de soporte técnico
de Azure. Para enviar una solicitud de soporte técnico, en la página de soporte técnico de Azure, seleccione
Obtener sopor te técnico .

Síntoma
No se puede conectar una máquina virtual de Azure a otra máquina virtual de Azure.

Guía de solución de problemas

1. Compruebe si la NIC está mal configurada
2. Compruebe si un NSG o una UDR bloquea el tráfico de red
3. Compruebe si el firewall de la máquina virtual bloquea el tráfico de red
4. Compruebe si la aplicación o servicio de la máquina virtual está escuchando en el puerto
5. Compruebe si el problema lo provoca SNAT
6. Compruebe si las ACL bloquean el tráfico de la máquina virtual clásica
7. Compruebe si se creó el punto de conexión de la máquina virtual clásica
8. Intente conectarse a un recurso compartido de red de una máquina virtual
9. Compruebe la conectividad entre redes virtuales

Pasos para solucionar problemas

Siga estos pasos para solucionar el problema. Después de completar cada paso, compruebe si el problema se ha
resuelto.
Paso 1: Compruebe si la NIC está mal configurada
Siga los pasos descritos en Restablecimiento de la interfaz de red para VM de Microsoft Azure.
Si el problema se produce después de modificar la interfaz de red (NIC), siga estos pasos:
Máquinas vir tuales con varias NIC
1. Agregue una NIC.
2. Corrija los problemas de la NIC incorrecta o quítela. A continuación, vuelva a agregar la NIC.
Para más información, consulte Incorporación de interfaces de red a máquinas virtuales o eliminación de estas.
Máquina vir tual con una única NIC
Nueva implementación de la máquina virtual en Windows
Nueva implementación de la máquina virtual de Linux
Paso 2: Compruebe si un NSG o una UDR bloquea el tráfico de red
Use Comprobación del flujo de IP de Network Watcher y Registro de flujo de NSG para determinar si hay un grupo
de seguridad de red (NSG) o ruta definida por el usuario (UDR) que esté interfiriendo con el flujo de tráfico.
Paso 3: Compruebe si el firewall de la máquina virtual bloquea el tráfico de red
Deshabilite el firewall y, a continuación, pruebe el resultado. Si se resuelve el problema, compruebe la configuración
de firewall y, a continuación, vuelva a habilitarlo.
Paso 4: Compruebe si la aplicación o servicio de la máquina virtual está escuchando en el puerto
Puede usar alguno de los métodos siguientes para comprobar si la aplicación o servicio de la máquina virtual está
escuchando en el puerto.
Ejecute los comandos siguientes para comprobar si el servidor está escuchando en ese puerto.
Máquina vir tual Windows

netstat –ano

Máquina vir tual Linux

netstat -l

Ejecute el comando telnet en la propia máquina virtual para probar el puerto. Si se produce un error en la
prueba, la aplicación o servicio no está configurado para escuchar en ese puerto.
Paso 5: Compruebe si el problema lo provoca SNAT
En algunos escenarios, la máquina virtual se coloca detrás de una solución de equilibrio de carga que tiene una
dependencia de recursos fuera de Azure. En estos casos, si tiene problemas de conexión intermitentes, el problema
puede deberse al agotamiento de los puertos SNAT. Para resolver el problema, cree una dirección VIP (o ILPIP para
el modelo de implementación clásico) para cada máquina virtual que esté detrás del equilibrador de carga y
protéjala con un NSG o una ACL.
Paso 6: Compruebe si las ACL bloquean el tráfico de la máquina virtual clásica
Una lista de control de acceso (ACL) proporciona la capacidad de permitir o denegar tráfico a un punto de conexión
de la máquina virtual de forma selectiva. Para más información, consulte Administración de la ACL en un punto de
conexión.
Paso 7: Compruebe si se creó el punto de conexión de la máquina virtual clásica
Todas las máquinas virtuales que se crean en Azure con el modelo de implementación clásico pueden comunicarse
automáticamente a través de un canal de red privada con otras máquinas virtuales del mismo servicio en la nube o
de la misma red virtual. Sin embargo, los equipos en otras redes virtuales necesitan puntos de conexión para dirigir
el tráfico de red entrante a una máquina virtual. Para más información, consulte Cómo configurar puntos de
conexión.
Paso 8: Intente conectarse a un recurso compartido de red de una máquina virtual
Si no se puede conectar a un recurso compartido de red de máquina virtual, el problema puede deberse a que la
NIC no está disponible en la máquina virtual. Para eliminar las NIC no disponibles, consulte Eliminación de las NIC
no disponibles
Paso 9: Compruebe la conectividad entre redes virtuales
Use Comprobación del flujo de IP de Network Watcher y Registro de flujo de NSG para determinar si hay un grupo
de seguridad de red (NSG) o ruta definida por el usuario (UDR) que esté interfiriendo con el flujo de tráfico.
También puede comprobar la configuración entre redes virtuales aquí.
¿Necesita ayuda? Póngase en contacto con el servicio de soporte técnico.
Si sigue necesitando ayuda, póngase en contacto con el servicio de soporte técnico para resolver el problema
rápidamente.
 Configuración de zonas de búsqueda inversa para la
comprobación de un banner de SMTP
23/09/2020 • 2 minutes to read • Edit Online

Este artículo describe cómo usar una zona inversa en Azure DNS y crear un registro DNS inverso (PTR) para la
comprobación del banner de SMTP.

Síntoma
Si hospeda un servidor SMTP en Microsoft Azure, puede que reciba el siguiente mensaje de error al enviar o recibir
un mensaje de servidores de correo remotos:
554: no hay ningún registro PTR

Solución
Para una dirección IP virtual de Azure, los registros inversos se crean en zonas de dominio propiedad de Microsoft
y no en las zonas de dominios personalizados.
Para configurar registros PTR en zonas propiedad de Microsoft, use la propiedad -ReverseFqdn en el recurso
PublicIpAddress. Para obtener más información, consulte Configuración de DNS inversos para servicios
hospedados en Azure.
Al configurar registros PTR, asegúrese de que la dirección IP y el FQDN inverso pertenecen a la suscripción. Si
intenta establecer un FQDN inverso que no pertenece a la suscripción, recibirá el siguiente mensaje de error:

Set-AzPublicIpAddress : ReverseFqdn [Link] that PublicIPAddress ip01 is trying to use does not belong
to subscription <Subscription ID>. One of the following conditions need to be met to establish ownership:

1) ReverseFqdn matches fqdn of any public ip resource under the subscription;

2) ReverseFqdn resolves to the fqdn (through CName records chain) of any public ip resource under the
subscription;
3) It resolves to the ip address (through CName and A records chain) of a static public ip resource under the
subscription.

Si cambia manualmente el banner de SMTP para que coincida con el FQDN inverso predeterminado, el servidor de
correo remoto puede seguir generando errores porque es posible que espere que el host del banner de SMTP
coincida con el registro MX para el dominio.
 Problemas de aplicaciones virtuales de red en Azure
23/09/2020 • 12 minutes to read • Edit Online

NOTE
Este artículo se ha actualizado para usar el nuevo módulo Az de Azure PowerShell. Aún puede usar el módulo de AzureRM
que continuará recibiendo correcciones de errores hasta diciembre de 2020 como mínimo. Para más información acerca del
nuevo módulo Az y la compatibilidad con AzureRM, consulte Introducing the new Azure PowerShell Az module (Presentación
del nuevo módulo Az de Azure PowerShell). Para obtener instrucciones sobre la instalación del módulo Az, consulte
Instalación de Azure PowerShell.

Es posible que experimente problemas y errores de conectividad de máquina virtual o de VPN al utilizar la
aplicación virtual de red (NVA) de terceros en Microsoft Azure. En este artículo se proporcionan los pasos básicos
para ayudarle a validar los requisitos básicos de la plataforma Azure para las configuraciones de aplicación virtual
de red.
El soporte técnico para las aplicaciones virtuales de red de terceros y su integración con la plataforma Azure lo
proporciona el proveedor de la aplicación virtual de red.

NOTE
Si tiene un problema de conectividad o de enrutamiento que implica una aplicación virtual de red, debería ponerse en
contacto directamente con el proveedor de la aplicación virtual de red.

Si su problema con Azure no se trata en este artículo, visite los foros de Azure en MSDN y Stack Overflow. Puede
publicar su problema en ellos o @AzureSupport en Twitter. También puede enviar una solicitud de soporte técnico
de Azure. Para enviar una solicitud de soporte técnico, en la página de soporte técnico de Azure, seleccione
Obtener sopor te técnico .

Lista de comprobación para la solución de problemas con el proveedor

de la aplicación virtual de red
Actualizaciones de software para software de máquinas virtuales de aplicaciones virtuales de red
Funcionalidad y configuración de la cuenta de servicio
Rutas definidas por el usuario (UDR) en subredes de red virtual que dirigen el tráfico a la aplicación virtual de
red
Rutas definidas por el usuario (UDR) en subredes de red virtual que dirigen el tráfico de la aplicación virtual de
red
Tablas de enrutamiento y las reglas en la aplicación virtual de red (por ejemplo, de NIC1 a NIC2)
Seguimiento de las NIC de la aplicación virtual de red para comprobar la recepción y el envío del tráfico de red
Cuando usa una SKU estándar y direcciones IP públicas, debe haber creado un grupo de seguridad de red y una
regla explícita para permitir que el tráfico se enrute a la aplicación virtual de red.

Pasos básicos para solucionar problemas

Comprobación de la configuración básica
Comprobación del rendimiento de la aplicación virtual de red
Solución de problemas avanzados de red
Comprobación de los requisitos mínimos de la configuración de las
aplicaciones virtuales de red en Azure
Cada aplicación virtual de red tiene requisitos básicos de configuración para funcionar correctamente en Azure. En
la sección siguiente se proporcionan los pasos para comprobar estas configuraciones básicas. Para más
información, póngase en contacto con el proveedor de la aplicación virtual de red.
Comprobación de si está habilitado el reenvío IP en la aplicación vir tual de red
Usar Azure Portal
1. Busque el recurso de la aplicación virtual de red en Azure Portal, seleccione las redes y, después, seleccione la
interfaz de red.
2. En la página Interfaz de red, seleccione Configuraciones de IP.
3. Asegúrese de que está habilitado el reenvío IP.
Uso de PowerShell
1. Abra PowerShell e inicie sesión en la cuenta de Azure.
2. Ejecute el siguiente comando (reemplace los valores entre corchetes por su información):

Get-AzNetworkInterface -ResourceGroupName <ResourceGroupName> -Name <NicName>

3. Compruebe la propiedad EnableIPFor warding .

4. Si el reenvío IP no está habilitado, ejecute los siguientes comandos para habilitarlo:

$nic2 = Get-AzNetworkInterface -ResourceGroupName <ResourceGroupName> -Name <NicName>

$[Link] = 1
Set-AzNetworkInterface -NetworkInterface $nic2
Execute: $nic2 #and check for an expected output:
EnableIPForwarding : True
NetworkSecurityGroup : null

Comprobación de NSG al usar la dirección IP pública de una SKU estándar Cuando use una SKU estándar
y una dirección IP pública, debe haber creado un grupo de seguridad de red y una regla explícita para permitir el
tráfico a la aplicación virtual de red.
Comprobación de si se puede enrutar el tráfico a la aplicación vir tual de red
1. En Azure Portal, abra Network Watcher , seleccione Próximo salto .
2. Especifique una máquina virtual que esté configurada para redirigir el tráfico a la aplicación virtual de red y una
dirección IP de destino en la cual se va a ver el próximo salto.
3. Si la aplicación virtual de red no aparece como próximo salto , comprueba y actualice las tablas de rutas de
Azure.
Comprobación de si el tráfico puede llegar a la aplicación vir tual de red
1. En Azure Portal, abra Network Watcher y, después, seleccione Comprobación del flujo de IP .
2. Especifique la máquina virtual y la dirección IP de la aplicación virtual de red y, después, compruebe si el tráfico
está bloqueado por algún grupo de seguridad de red (NSG).
3. Si existe una regla del grupo de seguridad de red que bloquee el tráfico, localice dicho grupo en las reglas de
seguridad eficaces y, a continuación, actualícela para permitir el paso del tráfico. A continuación, ejecute
Comprobación del flujo de IP de nuevo y use Solución de problemas de conexión para probar las
comunicaciones TCP de la máquina virtual a la dirección IP interna o externa.
Comprobación de si la aplicación vir tual de red y las máquinas vir tuales están escuchando el tráfico
esperado
1. Conéctese a la aplicación virtual de red mediante RDP o SSH y, después, ejecute el siguiente comando:
Para Windows:

netstat -an

Para Linux:

netstat -an | grep -i listen

2. Si no ve el puerto TCP que utiliza el software de la aplicación virtual de red que aparece en los resultados,
debe configurar la aplicación en la aplicación virtual de red y en la máquina virtual para que escuche y
responda al tráfico que llega a esos puertos. Póngase en contacto con el proveedor de la aplicación virtual
de red para obtener ayuda, según sea necesario.

Comprobación del rendimiento de la aplicación virtual de red

Validación de la CPU de la máquina virtual
Si el uso de CPU se acerca al 100 por ciento, es posible que se produzca un problema que afecte a las colocaciones
de paquetes de red. La máquina virtual notifica la CPU promedio durante un intervalo de tiempo específico en
Azure Portal. Durante un pico de CPU, investigue qué proceso de la máquina virtual invitada está causando la
elevada CPU y lo solucione, si es posible. También es posible que tenga que cambiar el tamaño de la máquina
virtual a un tamaño de SKU más grande o, para el conjunto de escalado de máquinas virtuales, aumentar el
número de instancias o establecer el escalado automático en el uso de CPU. Para cada uno de estos problemas,
póngase en contacto con el proveedor de la aplicación virtual de red para obtener ayuda, según sea necesario.
Validación de las estadísticas de red de la máquina virtual
Si la red de VM utiliza picos o muestra períodos de uso elevado, es posible que también tenga que aumentar el
tamaño de la SKU de la máquina virtual para obtener mayores capacidades de rendimiento. También puede volver
a implementar la máquina virtual con las redes aceleradas habilitadas. Para comprobar si el dispositivo virtual de
red admite la característica de redes aceleradas, póngase en contacto con el proveedor de la aplicación virtual de
red, según sea necesario.

Solución de problemas del administrador de red avanzado

Captura del seguimiento de red
Capture un seguimiento de red simultáneo en la máquina virtual de origen, la aplicación virtual de red y la
máquina virtual de destino mientras ejecuta PsPing o Nmap y, después, detenga el seguimiento.
1. Para capturar un seguimiento de red simultáneo, ejecute el siguiente comando:
Para Windows
netsh trace start capture=yes tracefile=c:\server_IP.etl scenario=netconnection
Para Linux
sudo tcpdump -s0 -i eth0 -X -w [Link]
2. Utilice PsPing o Nmap desde la máquina virtual de origen a la máquina virtual de destino (por ejemplo:
PsPing [Link]:80 o Nmap -p 80 [Link] ).
3. Abra el seguimiento de red desde la máquina virtual de destino mediante el Monitor de red o tcpdump.
Aplique un filtro de visualización para la IP de la máquina virtual de origen desde la que ejecutó PsPing o
Nmap , como [Link]==[Link] (Windows netmon) o
tcpdump -nn -r [Link] src or dst host [Link] (Linux).

Análisis de seguimientos
Si no ve los paquetes de entrada para el seguimiento de la máquina virtual de back-end, es probable que un grupo
de seguridad de red o un enrutamiento definido por el usuario esté interfiriendo o que las tablas de enrutamiento
de la aplicación virtual de red sean incorrectas.
Si ve que los paquetes entran, pero no hay ninguna respuesta, puede ser necesario resolver un problema de la
aplicación de la máquina virtual o del firewall. Para cada uno de estos problemas, póngase en contacto con el
proveedor de la aplicación virtual de red para obtener ayuda, según sea necesario.
 Solución de problemas de conectividad SMTP
saliente en Azure
23/09/2020 • 8 minutes to read • Edit Online

A partir del 15 de noviembre de 2017, los mensajes de correo electrónico salientes que se envían directamente a
dominios externos (como [Link] y [Link]) desde una máquina virtual (VM) solo están disponibles a
ciertos tipos de suscripción de Microsoft Azure. Las conexiones SMTP salientes que usan el puerto TCP 25 se
bloquearon. (El puerto 25 se usa principalmente para la entrega de correo electrónico sin autenticación).
Este cambio de comportamiento solo se aplica a suscripciones e implementaciones nuevas desde el 15 de
noviembre de 2017.

Método recomendado para el envío de correo electrónico

Se recomienda usar servicios de retransmisión SMTP autenticados (que habitualmente se conectan a través del
puerto TCP 587 o 443, pero que también admiten otros puertos) para enviar correo electrónico desde máquinas
virtuales de Azure o desde Azure App Service. Estos servicios se usan para mantener la reputación de IP o dominio
para minimizar la posibilidad de que proveedores de correo electrónico de terceros rechacen el mensaje. Dichos
servicios de retransmisión SMTP incluyen, entre otros, SendGrid. También es posible que tenga un servicio de
retransmisión SMTP seguro que se ejecute de manera local que puede usar.
El uso de estos servicios de entrega de correo electrónico no está restringido en Azure, independientemente del
tipo de suscripción.

Contrato Enterprise
Para los usuarios de Azure de Contrato Enterprise, no hay ningún cambio en la capacidad técnica para enviar correo
electrónico sin usar una retransmisión autenticada. Tanto los usuarios nuevos como existentes de Contrato
Enterprise puede probar la entrega de correo electrónico saliente desde máquinas virtuales de Azure directamente
a proveedores de correo electrónico externos sin ninguna restricción desde la plataforma de Azure. Si bien no se
garantiza que los proveedores de correo electrónico acepten correo electrónico entrante de un usuario cualquiera,
los intentos de entrega no se bloquearán por medio de la plataforma de Azure desde máquinas virtuales dentro de
las suscripciones a Contrato Enterprise. Tendrá que trabajar directamente con proveedores de correo electrónico
para corregir cualquier problema de entrega de mensaje o filtrado de correo no deseado que implique a
proveedores específicos.

Pay-As-You-Go
Si se suscribió antes del 15 de noviembre de 2017 en las ofertas de suscripción de Pago por uso o de Microsoft
Partner Network, no habrá ningún cambio en la capacidad técnica de probar la entrega de correo electrónico
saliente. Seguirá teniendo la posibilidad de probar la entrega de correo electrónico saliente desde máquinas
virtuales de Azure dentro de estas suscripciones directamente a proveedores de correo electrónico externos sin
ninguna restricción desde la plataforma de Azure. Como ya se indicó, no se garantiza que los proveedores de
correo electrónico acepten el correo electrónico entrante de un usuario cualquiera y los usuarios deberán trabajar
directamente con proveedores de correo electrónico para corregir cualquier problema de entrega de mensaje o
filtrado de correo no deseado que implique a proveedores específicos.
Para las suscripciones a Pago por uso o Microsoft Partner Network creadas después del 15 de noviembre de 2017,
habrá restricciones técnicas para bloquear el correo electrónico que se envía directamente desde máquinas
virtuales dentro de estas suscripciones. Si quiere poder enviar correo electrónico desde máquinas virtuales de
Azure directamente a proveedores de correo electrónico externos (sin usar retransmisión SMTP autenticada), puede
hacer una solicitud para quitar la restricción. Las solicitudes se revisarán y aprobarán a discreción de Microsoft y
solo se concederán una vez que se hayan realizado comprobaciones adicionales contra fraudes. Para realizar una
solicitud, abra un caso de soporte técnico mediante el siguiente tipo de incidencia: Técnico > Red vir tual >
Conectividad > No se puede enviar correo (SMTP/Puer to 25) . Asegúrese de agregar detalles sobre por qué
la implementación tiene que enviar correo directamente a los proveedores de correo en lugar de usar una
retransmisión autenticada.
Después de que una suscripción de pago por uso o de Microsoft Partner Network esté exenta y las VM hayan sido
"detenidas" e "iniciadas" desde Azure Portal, todas las VM dentro de esa suscripción quedarán exentas en el futuro.
La exención solo es aplicable a la suscripción solicitada y solo se aplica al tráfico de la máquina virtual que se
enruta directamente a Internet. No se admite el tráfico del puerto 25 de enrutamiento mediante servicios de PaaS
de Azure, como Azure Firewall.

NOTE
Microsoft se reserva el derecho a revocar este exención si se determina que se produjo una infracción en los términos del
servicio.

MSDN, Pase para Azure, Azure bajo licencia Open, Education, BizSpark
y evaluación gratuita
Si creó una suscripción de MSDN, Pase para Azure, Azure bajo licencia Open, Education, BizSpark, Patrocinio de
Azure, Azure para alumnos, Evaluación gratuita o cualquier suscripción a Visual Studio después del 15 de
noviembre de 2017, tendrá restricciones técnicas que bloquearán el correo electrónico que se envía desde
máquinas virtuales dentro de estas suscripciones directamente a los proveedores de correo electrónico. Las
restricciones existen para evitar abusos. No se concederá ninguna solicitud para quitar esta restricción.
Si usa estos tipos de suscripción, se recomienda que use los servicios de retransmisión SMTP tal como se indicó
anteriormente en este artículo, o que cambie el tipo de suscripción.

Proveedor de servicios en la nube (CSP)

Si usa los recursos de Azure a través de CSP, puede solicitar que CSP cree en su nombre una solicitud de exención
de desbloqueo con Microsoft si no se puede usar una retransmisión de SMTP segura.

¿Necesita ayuda? Ponerse en contacto con soporte técnico

Si aún necesita ayuda, póngase en contacto con el soporte técnico para resolver su problema rápidamente; para
ello, use el siguiente tipo de problema: Tipo de problema Administración de suscripciones : Solicitud para
habilitar el flujo de correo electrónico del puer to 25 .
 ¿Qué es la dirección IP [Link]?
23/09/2020 • 5 minutes to read • Edit Online

La dirección IP [Link] es una dirección IP pública virtual que se usa para facilitar un canal de comunicación
a los recursos de la plataforma Azure. Los clientes pueden definir cualquier espacio de direcciones de su red virtual
privada en Azure. Por lo tanto, los recursos de la plataforma Azure se deben presentar como una única dirección IP
pública. Esta dirección IP pública virtual facilita lo siguiente:
Permite al agente de VM comunicarse con la plataforma Azure para indicar que se encuentra en estado "Listo".
Permite la comunicación con el servidor DNS virtual para proporcionar resolución de nombres filtrada a los
recursos (como una máquina virtual) que no tienen un servidor DNS personalizado. Este filtrado garantiza que
los clientes puedan resolver solo los nombres de host de sus recursos.
Permite que los sondeos de estado de Azure Load Balancer determinen el estado de mantenimiento de las VM.
Permite que la máquina virtual obtenga una dirección IP dinámica desde el servicio DHCP en Azure.
Habilita los mensajes de latido del agente invitado para el rol PaaS.

Ámbito de la dirección IP [Link]

La dirección IP pública [Link] se utiliza en todas las regiones y en todas las nubes nacionales. Esta dirección
IP pública especial es propiedad de Microsoft y no se cambiará. Se recomienda que permita esta dirección IP en las
directivas de firewall locales (en la máquina virtual) en la dirección de salida. La comunicación entre esta dirección
IP especial y los recursos es segura porque solo la plataforma interna de Azure puede originar un mensaje desde
esta dirección IP. Si esta dirección se bloquea, puede producirse un comportamiento inesperado en una variedad de
escenarios. [Link] es una dirección IP virtual del nodo de host y, como tal, no está sujeta a las rutas
definidas por el usuario.
El agente de máquina virtual requiere comunicación saliente a través de los puertos 80, 443 y 32526 con
WireServer ([Link]). Estos deben estar abiertos en el firewall local de la máquina virtual. La
comunicación en estos puertos con [Link] no está sujeta a los grupos de seguridad de red configurados.
[Link] puede proporcionar servicios DNS a la máquina virtual. Si no lo desea, este tráfico puede
bloquearse en el firewall local de la máquina virtual. De forma predeterminada, la comunicación de DNS no está
sujeta a los grupos de seguridad de red configurados a menos que se dirija específicamente aprovechando la
etiqueta de servicio AzurePlatformDNS. Para bloquear el tráfico DNS a Azure DNS a través del grupo de
seguridad de red, cree una regla de salida para denegar el tráfico a AzurePlatformDNS y especifique "*" como
"Intervalos de puertos de destino" y "Cualquiera" como protocolo.
Cuando la máquina virtual forma parte de un grupo de back-end del equilibrador de carga, debe permitirse que
la comunicación del sondeo de estado se origine en [Link]. La configuración predeterminada del grupo
de seguridad de red tiene una regla que permite esta comunicación. Esta regla aprovecha la etiqueta de servicio
AzureLoadBalancer. Si lo desea, puede bloquearse este tráfico mediante la configuración del grupo de seguridad
de red; sin embargo, se producirán errores en los sondeos.
En un escenario de red que no es virtual (clásica), el sondeo de estado se origina desde una dirección IP privada y
[Link] no se usa.

Pasos siguientes
Grupos de seguridad
Creación, modificación o eliminación de un grupo de seguridad de red
 Definiciones de directivas integradas de Azure Policy
para Azure Virtual Network
23/09/2020 • 21 minutes to read • Edit Online

Esta página es un índice de las definiciones de directivas integradas de Azure Policy para Azure Virtual Network.
Puede encontrar elementos integrados adicionales de Azure Policy para otros servicios en Definiciones de
elementos integrados de Azure Policy.
El nombre de cada definición de directiva integrada se vincula a la definición de directiva en Azure Portal. Use el
vínculo de la columna Versión para ver el origen en el repositorio de GitHub de Azure Policy.

Azure Virtual Network

N O M B RE VERSIÓ N
( A ZURE PO RTA L) DESC RIP C IÓ N EF EC TO S ( GIT HUB)

Se debe aplicar una directiva Esta directiva garantiza que Audit, Disabled 1.0.0
IPsec/IKE personalizada a todas las conexiones de
todas las conexiones de puerta de enlace de Azure
puerta de enlace de red Virtual Network usen una
virtual de Azure. directiva personalizada de
protocolo de seguridad de
Internet (IPsec) o
Intercambio de claves por
red (IKE). Consulte los
algoritmos y los niveles de
seguridad de las claves
compatibles en
[Link]

Todo el tráfico de Internet Azure Security Center ha AuditIfNotExists, Disabled 3.0.0-preview

debe enrutarse mediante la identificado que algunas de
instancia de Azure Firewall las subredes no están
implementada protegidas con un firewall de
próxima generación. Proteja
las subredes frente a
posibles amenazas mediante
la restricción del acceso a
ellas con Azure Firewall o un
firewall de próxima
generación compatible.

App Service debe usar un Esta directiva audita toda AuditIfNotExists, Disabled 1.0.0
punto de conexión del instancia de App Service no
servicio de red virtual configurada para usar un
punto de conexión del
servicio de red virtual.

Las instancias de Azure VPN Esta directiva garantiza que Audit, Disabled 1.0.0
Gateway no deben usar la las instancias de VPN
SKU "básica". Gateway no usan la SKU
"básica".
N O M B RE VERSIÓ N
DESC RIP C IÓ N EF EC TO S

Container Registry debe usar Esta directiva audita toda Audit, Disabled 1.0.0-preview
un punto de conexión del instancia de Container
servicio de red virtual Registry no configurada para
usar un punto de conexión
del servicio de red virtual.

Cosmos DB debe usar un Esta directiva audita toda Audit, Disabled 1.0.0
punto de conexión del instancia de Cosmos DB no
servicio de red virtual configurada para usar un
punto de conexión del
servicio de red virtual.

Implementación de un Configura el registro de flujo deployIfNotExists 1.0.0

recurso de registro de flujo para un grupo de seguridad
con el grupo de seguridad de red específico. Permitirá
de red de destino registrar información sobre
el flujo de tráfico IP
mediante un grupo de
seguridad de red. El registro
de flujo ayuda a identificar el
tráfico desconocido o no
deseado, comprobar el
aislamiento de la red y el
cumplimiento con las reglas
de acceso de la empresa,
analizar los flujos de red de
direcciones IP e interfaces de
red en peligro.

Implementar Network Esta directiva crea un DeployIfNotExists 1.0.0

Watcher al crear redes recurso de Network Watcher
virtuales. en las regiones con redes
virtuales. Debe asegurarse
de la existencia de un grupo
de recursos denominado
networkWatcherRG, que se
usará para implementar las
instancias de Network
Watcher.

El centro de eventos debe Esta directiva audita todo AuditIfNotExists, Disabled 1.0.0
usar un punto de conexión centro de eventos no
del servicio de red virtual configurado para usar un
punto de conexión del
servicio de red virtual.
N O M B RE VERSIÓ N
DESC RIP C IÓ N EF EC TO S

El registro de flujo se debe Audite los grupos de auditoría 1.0.0

configurar para cada grupo seguridad de red para
de seguridad de red comprobar si se ha
configurado el recurso de
registro de flujo. El registro
de flujo permite registrar
información sobre el flujo de
tráfico IP mediante un grupo
de seguridad de red. Se
puede utilizar para optimizar
flujos de red, supervisar el
rendimiento, comprobar el
cumplimiento, detectar
intrusiones y mucho más.

Las subredes de la puerta de Esta directiva deniega el deny 1.0.0

enlace no se deben acceso si una subred de
configurar con un grupo de puerta de enlace está
seguridad de red configurada con un grupo
de seguridad de red. La
asignación de un grupo de
seguridad de red a una
subred de puerta de enlace
hará que la puerta de enlace
deje de funcionar.

Key Vault debe usar un Esta directiva audita toda Audit, Disabled 1.0.0
punto de conexión del instancia de Key Vault no
servicio de red virtual configurada para usar un
punto de conexión del
servicio de red virtual.

Las interfaces de red deben Esta directiva deniega las deny 1.0.0
deshabilitar el reenvío IP interfaces de red que
habilitaron el reenvío IP. El
valor de reenvío IP
deshabilita la comprobación
que realiza Azure del origen
y destino en una interfaz de
red. Este debe revisarlo el
equipo de seguridad de red.

Las interfaces de red no Esta directiva deniega las deny 1.0.0

deben tener direcciones IP interfaces de red que están
públicas. configuradas con cualquier
dirección IP pública. Las
direcciones IP públicas
permiten la comunicación
entrante de los recursos de
Internet con los recursos de
Azure y la comunicación
saliente de los recursos de
Azure con Internet. Este
debe revisarlo el equipo de
seguridad de red.
N O M B RE VERSIÓ N
DESC RIP C IÓ N EF EC TO S

Network Watcher debe estar Network Watcher es un auditIfNotExists 1.0.0

habilitado servicio regional que permite
supervisar y diagnosticar
problemas en un nivel de
escenario de red mediante
Azure. La supervisión del
nivel de escenario permite
diagnosticar problemas en
una vista de nivel de red de
un extremo a otro. Las
herramientas de
visualización y diagnóstico
de red que incluye Network
Watcher le ayudan a
conocer, diagnosticar y
obtener información acerca
de cualquier red de Azure.

El acceso RDP desde Internet Esta directiva audita Audit, Disabled 2.0.0
debe estar bloqueado cualquier regla de seguridad
de red que permita el acceso
RDP desde Internet.

Service Bus debe usar un Esta directiva audita toda AuditIfNotExists, Disabled 1.0.0
punto de conexión del instancia de Service Bus no
servicio de red virtual configurada para usar un
punto de conexión del
servicio de red virtual.

SQL Server debe usar un Esta directiva audita toda AuditIfNotExists, Disabled 1.0.0
punto de conexión del instancia de SQL Server no
servicio de red virtual configurada para usar un
punto de conexión del
servicio de red virtual.

El acceso SSH desde Internet Esta directiva audita Audit, Disabled 2.0.0
debe estar bloqueado cualquier regla de seguridad
de red que permita el acceso
SSH desde Internet.

Las cuentas de Esta directiva audita todas Audit, Disabled 1.0.0

almacenamiento deben usar las cuentas de
un punto de conexión del almacenamiento no
servicio de red virtual configuradas para usar un
punto de conexión del
servicio de red virtual.

Las máquinas virtuales Esta directiva audita Audit, Deny, Disabled 1.0.0
deben estar conectadas a cualquier máquina virtual
una red virtual aprobada conectada a una red virtual
que no esté aprobada.

Las redes virtuales deben Esta directiva audita AuditIfNotExists, Disabled 1.0.0
usar la puerta de enlace de cualquier red virtual cuya
red virtual especificada ruta predeterminada no
apunte a la puerta de enlace
de red virtual especificada.
 N O M B RE VERSIÓ N
DESC RIP C IÓ N EF EC TO S

El firewall de aplicaciones Requiere el firewall de Audit, Deny, Disabled 1.0.0

web (WAF) debe estar aplicaciones web (WAF) en
habilitado para Application cualquier instancia de
Gateway Application Gateway. Un
firewall de aplicaciones web
proporciona una mayor
seguridad para los demás
recursos de Azure.

El firewall de aplicaciones Requiere el firewall de Audit, Deny, Disabled 1.0.0

web (WAF) debe estar aplicaciones web (WAF) en
habilitado para Azure Front cualquier instancia de Azure
Door Service Front Door Service. Un
firewall de aplicaciones web
proporciona una mayor
seguridad para los demás
recursos de Azure.

El firewall de aplicaciones Exige que el modo de Audit, Deny, Disabled 1.0.0

web (WAF) debe usar el detección o prevención esté
modo especificado para activo en todas las directivas
Application Gateway de firewall de aplicaciones
web para Application
Gateway.

El firewall de aplicaciones Exige que el modo de Audit, Deny, Disabled 1.0.0

web (WAF) debe usar el detección o prevención esté
modo especificado para activo en todas las directivas
Azure Front Door Service de firewall de aplicaciones
web para Azure Front Door
Service.

Etiquetas
N O M B RE VERSIÓ N
( A ZURE PO RTA L) DESC RIP C IÓ N EF EC TO S ( GIT HUB)

Agregar una etiqueta a los Agrega la etiqueta y el valor modify 1.0.0

grupos de recursos especificados cuando se crea
o se actualiza un grupo de
recursos que no tiene esta
etiqueta. Los grupos de
recursos existentes se
pueden corregir con una
tarea de corrección. Si la
etiqueta existe con un valor
diferente, no se cambiará.
N O M B RE VERSIÓ N
DESC RIP C IÓ N EF EC TO S

Agregar una etiqueta a los Agrega la etiqueta y el valor modify 1.0.0

recursos especificados cuando se crea
o se actualiza un recurso que
no tiene esta etiqueta. Los
recursos existentes se
pueden corregir con una
tarea de corrección. Si la
etiqueta existe con un valor
diferente, no se cambiará.
No modifica las etiquetas de
los grupos de recursos.

Agregar o reemplazar una Agrega o reemplaza la modify 1.0.0

etiqueta en los grupos de etiqueta y el valor
recursos especificados cuando se crea
o se actualiza cualquier
grupo de recursos. Los
grupos de recursos
existentes se pueden
corregir con una tarea de
corrección.

Agregar o reemplazar una Agrega o reemplaza la modify 1.0.0

etiqueta en los recursos etiqueta y el valor
especificados cuando se crea
o se actualiza cualquier
recurso. Los recursos
existentes se pueden
corregir con una tarea de
corrección. No modifica las
etiquetas de los grupos de
recursos.

Anexar una etiqueta y su Anexa la etiqueta append 1.0.0

valor desde el grupo de especificada y su valor del
recursos grupo de recursos cuando se
crea o se actualiza un
recurso que no tiene esta
etiqueta. Solo modifica las
etiquetas de los recursos
creados antes de que se
aplicase esta directiva
cuando se cambian esos
recursos. Hay disponibles
nuevas directivas de efecto
"modify" que admiten la
corrección de etiquetas en
recursos existentes (consulte
[Link]
N O M B RE VERSIÓ N
DESC RIP C IÓ N EF EC TO S

Anexar una etiqueta y su Anexa la etiqueta y el valor append 1.0.0

valor a los grupos de especificados cuando se crea
recursos o se actualiza un grupo de
recursos que no tiene esta
etiqueta. Solo modifica las
etiquetas de los grupos de
recursos creados antes de
que se aplicase esta directiva
cuando se cambian esos
grupos de recursos. Hay
disponibles nuevas directivas
de efecto "modify" que
admiten la corrección de
etiquetas en recursos
existentes (consulte
[Link]

Anexar una etiqueta y su Anexa la etiqueta y el valor append 1.0.1

valor a los recursos especificados cuando se crea
o se actualiza un recurso que
no tiene esta etiqueta. Solo
modifica las etiquetas de los
recursos creados antes de
que se aplicase esta directiva
cuando se cambian esos
recursos. No se aplica a los
grupos de recursos. Hay
disponibles nuevas directivas
de efecto "modify" que
admiten la corrección de
etiquetas en recursos
existentes (consulte
[Link]

Heredar una etiqueta del Agrega o reemplaza la modify 1.0.0

grupo de recursos etiqueta y el valor
especificados del grupo de
recursos primario cuando se
crea o actualiza un recurso.
Los recursos existentes se
pueden corregir con una
tarea de corrección.

Heredar una etiqueta del Agrega la etiqueta modify 1.0.0

grupo de recursos si falta especificada y su valor del
grupo de recursos primario
cuando se crea o se actualiza
un recurso que no tiene esta
etiqueta. Los recursos
existentes se pueden
corregir con una tarea de
corrección. Si la etiqueta
existe con un valor diferente,
no se cambiará.
 N O M B RE VERSIÓ N
DESC RIP C IÓ N EF EC TO S

Heredar una etiqueta de la Agrega o reemplaza la modify 1.0.0

suscripción etiqueta y el valor
especificados de la
suscripción contenedora
cuando se crea o actualiza
un recurso. Los recursos
existentes se pueden
corregir con una tarea de
corrección.

Heredar una etiqueta de la Agrega la etiqueta modify 1.0.0

suscripción si falta especificada y su valor en la
suscripción contenedora
cuando se crea o se actualiza
un recurso que no tiene esta
etiqueta. Los recursos
existentes se pueden
corregir con una tarea de
corrección. Si la etiqueta
existe con un valor diferente,
no se cambiará.

Requerir una etiqueta y su Aplica una etiqueta deny 1.0.0

valor en los grupos de obligatoria y su valor en los
recursos grupos de recursos.

Requerir una etiqueta y su Aplica una etiqueta deny 1.0.1

valor en los recursos obligatoria y su valor. No se
aplica a los grupos de
recursos.

Solicitar una etiqueta en los Requiere que se use una deny 1.0.0
grupos de recursos etiqueta en los grupos de
recursos.

Solicitar una etiqueta en los Requiere que haya una deny 1.0.1
recursos etiqueta. No se aplica a los
grupos de recursos.

General
N O M B RE VERSIÓ N
( A ZURE PO RTA L) DESC RIP C IÓ N EF EC TO S ( GIT HUB)

Ubicaciones permitidas Esta directiva permite deny 1.0.0

restringir las ubicaciones que
la organización puede
especificar al implementar
los recursos. Úsela para
aplicar los requisitos de
cumplimiento de replicación
geográfica. Excluye los
grupos de recursos,
[Link]
ry/b2cDirectories, y recursos
que usan la región "global".
 N O M B RE VERSIÓ N
DESC RIP C IÓ N EF EC TO S

Ubicaciones permitidas para Esta directiva permite deny 1.0.0

grupos de recursos restringir las ubicaciones en
las que la organización
puede crear grupos de
recursos. Úsela para aplicar
los requisitos de
cumplimiento de replicación
geográfica.

Tipos de recursos permitidos Esta directiva le permite deny 1.0.0

especificar los tipos de
recursos que puede
implementar su
organización. La directiva
solo se aplicará a los tipos de
recursos que admitan los
valores "tags" y "location".
Para restringir todos los
recursos, duplique esta
directiva y cambie el valor de
"mode" a "All".

La ubicación del recurso de Auditoría cuya ubicación de auditoría 2.0.0

auditoría coincide con la del recursos coincide con la
grupo de recursos ubicación de su grupo de
recursos.

Auditar el uso de reglas de Permite auditar roles Audit, Disabled 1.0.0

RBAC personalizadas integrados, como
"propietario, colaborador,
lector" en lugar de roles
RBAC personalizados, que
son propensos a errores de
auditoría. El uso de roles
personalizados se trata
como una excepción y
requiere una revisión
rigurosa y el modelado de
amenazas.

No deben existir roles de Esta directiva garantiza que Audit, Disabled 2.0.0
propietario de suscripción no existe ningún rol de
personalizados. propietario de suscripción
personalizado.

Tipos de recursos no Esta directiva permite Denegar 1.0.0

permitidos especificar los tipos de
recursos que su organización
no puede implementar.

Pasos siguientes
Los elementos integrados se pueden encontrar en el repositorio de GitHub de Azure Policy.
Revise la estructura de definición de Azure Policy.
Vea la Descripción de los efectos de directivas.
 Preguntas más frecuentes (P+F) acerca de Azure
Virtual Network
23/09/2020 • 64 minutes to read • Edit Online

Conceptos básicos de Virtual Network

¿Qué es Azure Virtual Network?
Azure Virtual Network es una representación de su propia red en la nube. Es un aislamiento lógico de la nube de
Azure dedicada a su suscripción. Puede usar las redes virtuales para aprovisionar y administrar redes privadas
virtuales (VPN) en Azure y, opcionalmente, vincular las redes virtuales con otras redes virtuales en Azure o con
sus infraestructura de TI local para crear soluciones híbridas o entre entornos. Cada red virtual que se crea tiene
su propio bloque CIDR y se puede vincular a otras redes locales y redes virtuales, siempre que los bloques CIDR
no se superpongan. También tiene el control de la configuración del servidor DNS para redes virtuales y de la
segmentación de la red virtual en subredes.
Use las redes virtuales para:
Crear una red virtual dedicada solo en la nube privada. A veces no necesita una configuración entre
entornos para su solución. Cuando se crea una red virtual, los servicios y las máquinas virtuales de la red
virtual pueden comunicarse de forma directa y segura entre ellas en la nube. Sin embargo, puede
configurar conexiones de punto de conexión para las máquinas virtuales y los servicios que requieren la
comunicación a Internet, como parte de la solución.
Extender su centro de datos de forma segura. Con las redes virtuales, puede crear VPN de sitio a sitio (S2S)
tradicionales para ampliar la capacidad del centro de datos de forma segura. Las redes virtuales de sitio a
sitio (S2S) usan IPSEC para proporcionar una conexión segura entre la puerta de enlace VPN corporativa y
Azure.
Habilitar escenarios de nube híbrida. Las redes virtuales proporcionan la flexibilidad para admitir una
variedad de escenarios de nube híbrida. Puede conectar de forma segura aplicaciones basadas en la nube
a cualquier tipo de sistema local como grandes sistemas y sistemas Unix.
¿Cómo empiezo?
Para comenzar, consulte Documentación de Virtual Network. En este artículo encontrará información general y de
implementación de todas las características de una red virtual.
¿Puedo usar redes virtuales sin conectividad entre entornos?
Sí. Puede usar una red virtual sin necesidad de conectarse a su entorno local. Por ejemplo, podría ejecutar
controladores de dominio de Active Directory para Microsoft Windows Server y granjas de servidores de
SharePoint únicamente en una red virtual de Azure.
¿Se puede realizar la optimización de una WAN entre redes virtuales o entre una red virtual y un centro de
datos local?
Sí. A través de Azure Marketplace es posible implementar una aplicación virtual de red de optimización de la
WAN de varios proveedores.

Configuración
¿Qué herramientas debo usar para crear una red virtual?
Para crear o configurar una red virtual se pueden usar las siguientes herramientas:
 Azure portal
PowerShell
Azure CLI
Un archivo de configuración de red (netcfg; solo para redes virtuales clásicas). Consulte el artículo
Configuración de una red virtual con un archivo de configuración de red.
¿Qué intervalos de direcciones puedo usar en mis redes virtuales?
Se recomienda usar los intervalos de direcciones enumerados en RFC 1918, que el IETF ha reservado para los
espacios de direcciones privados y no enrutables:
[Link] a [Link] (prefijo 10/8)
[Link] a [Link] (prefijo 172.16/12)
[Link] a [Link] (prefijo 192.168/16)
Otros espacios de direcciones pueden funcionar, pero es posible que tengan efectos secundarios no deseados.
Además, no se pueden agregar los intervalos de direcciones siguientes:
[Link]/4 (multidifusión)
[Link]/32 (difusión)
[Link]/8 (bucle invertido)
[Link]/16 (local de vínculo)
[Link]/32 (DNS interno)
¿Puedo tener direcciones IP públicas en mis redes virtuales?
Sí. Para más información sobre los intervalos de direcciones IP públicas, consulte Creación de una red virtual. Las
direcciones IP públicas no son accesibles directamente desde Internet.
¿Existe algún límite en el número de subredes de que puede tener una red virtual?
Sí. Para más información, consulte los límites de Azure. Los espacios de direcciones de las subredes no pueden
superponerse entre sí.
¿Hay alguna restricción en el uso de direcciones IP dentro de estas subredes?
Sí. Azure reserva 5 direcciones IP dentro de cada subred. Son x.x.x.0-x.x.x.3 y la última dirección de la subred.
x.x.x.1-x.x.x.3 está reservada en cada subred para los servicios de Azure.
x.x.x.0: Dirección de red
x.x.x.1: Reservado por Azure para la puerta de enlace predeterminada
x.x.x.2, x.x.x.3: Reservado por Azure para asignar las direcciones IP de Azure DNS al espacio de red virtual
x.x.x.255: Dirección de difusión de red
¿Qué tamaños mínimo y máximo pueden tener las redes virtuales y las subredes?
La subred IPv4 más pequeña admitida es /29 y la más grande /8 (mediante definiciones de subred CIDR). Las
subredes IPv6 deben tener un tamaño exactamente de /64.
¿Puedo llevar mis VLAN a Azure mediante redes virtuales?
No. Las redes virtuales son superposiciones de nivel 3. Azure no admite ninguna semántica de nivel 2.
¿Puedo especificar directivas de enrutamiento personalizadas en mis redes virtuales y subredes?
Sí. Puede crear una tabla de rutas y asociarla a una subred. Para más información sobre el enrutamiento en Azure,
consulte Introducción al enrutamiento.
¿Las redes virtuales admiten la multidifusión o la difusión?
No. No se admite difusión ni multidifusión.
¿Qué protocolos puedo usar en las redes virtuales?
En las redes virtuales se pueden usar los protocolos TCP, UDP e ICMP TCP/IP. La unidifusión se admite dentro de
las redes virtuales, a excepción del Protocolo de configuración dinámica de host (DCHP) a través de unidifusión
(puerto de origen UDP/68 / puerto de destino UDP/67) y el puerto de origen UDP 65330, que se reserva para el
anfitrión. La multidifusión, la difusión, los paquetes encapsulados IP en IP y los paquetes de encapsulación de
enrutamiento genérico (GRE) se bloquean en las subredes.
¿Puedo hacer ping a mis enrutadores predeterminados dentro de una red virtual?
No.
¿Puedo usar tracert para diagnosticar la conectividad?
No.
¿Puedo agregar subredes una vez creada la red virtual?
Sí. Se pueden agregar subredes a redes virtuales en cualquier momento siempre y cuando el intervalo de
direcciones de subred no sea parte de otra subred y se haya dejado espacio disponible en el intervalo de
direcciones de la red virtual.
¿Puedo modificar el tamaño de la subred después de crearla?
Sí. Puede agregar, quitar, expandir o contraer una subred si no hay máquinas virtuales ni servicios
implementados en ella.
¿Puedo modificar subredes después de crearlas?
Sí. Puede agregar, quitar y modificar los bloques CIDR usados por una red virtual.
¿Puedo conectarme a Internet si ejecuto mis servicios en una red virtual?
Sí. Todos los servicios implementados dentro de una red virtual pueden establecer una conexión a Internet
saliente. Para más información sobre las conexiones a Internet salientes en Azure, consulte Conexiones salientes
en Azure. Si quiere establecer una conexión entrante a un recurso implementado mediante Resource Manager, el
recurso debe tener asignada una dirección IP pública. Para más información sobre las direcciones IP públicas,
consulte Direcciones IP publicas. Cada servicio en la nube de Azure implementado en Azure tiene asignada una
dirección IP virtual direccionable de forma pública. Para permitir que estos servicios acepten conexiones de
Internet, se definen puntos de conexión de entrada para roles y puntos de conexión de PaaS en las máquinas
virtuales.
¿Las redes virtuales admiten IPv6?
Sí, las redes virtuales pueden ser solo IPv4 o de pila dual (IPv4 + IPv6). Para obtener más información, consulte
Información general de IPv6 para Azure Virtual Networks.
¿Puede una red virtual abarcar varias regiones?
No. Una red virtual está limitada a una única región. Una red virtual, sin embargo, abarca zonas de disponibilidad.
Para más información sobre las zonas de disponibilidad, consulte Introducción a las zonas de disponibilidad.
Puede conectar redes virtuales de diferentes regiones con el emparejamiento de redes virtuales. Para más
información, consulte Emparejamiento de redes virtuales.
¿Puedo conectar una red virtual a otra red virtual en Azure?
Sí. Puede conectar una red virtual a otra mediante los métodos siguientes:
Emparejamiento de redes vir tuales : para obtener más información, consulte la VNet peering overview
(Introducción al emparejamiento de redes virtuales).
Una instancia de Azure VPN Gateway. : para obtener más información, consulte Configure a VNet-to-
VNet connection (Configuración de una conexión de red virtual a red virtual).

resolución de nombres DNS

¿Qué opciones de DNS hay para las redes virtuales?
Use la tabla de decisiones de la página Resolución de nombres para las máquinas virtuales e instancias de rol ; le
guiará por todas las opciones de DNS disponibles.
¿Puedo especificar servidores DNS para una red virtual?
Sí. Puede especificar direcciones IP de servidor DNS en la configuración de la red virtual. La configuración se
aplica al servidor DNS predeterminado en todas las máquinas virtuales de la red virtual.
¿Cuántos servidores DNS puedo especificar?
Consulte los límites de Azure.
¿Puedo modificar mis servidores DNS después de haber creado la red?
Sí. Puede cambiar la lista de servidores DNS de la red virtual en cualquier momento. Si cambia la lista de
servidores DNS, debe realizar una renovación de la concesión DHCP en todas las máquinas virtuales afectadas de
la red virtual para que la nueva configuración de DNS surta efecto. En el caso de las máquinas virtuales que
ejecutan el sistema operativo Windows, puede hacerlo escribiendo ipconfig /renew directamente en la máquina
virtual. Para otros tipos de sistema operativo, consulte la documentación respectiva sobre la renovación de las
concesiones DHCP.
¿Qué es un DNS proporcionado por Azure? ¿Funciona con las redes virtuales?
Un DNS proporcionado por Azure es un servicio DNS multiempresa ofrecido por Microsoft. Azure registra en
este servicio todas las máquinas virtuales y las instancias de rol de servicio en la nube. Este servicio proporciona
la resolución de nombres mediante nombre de host para las máquinas virtuales y las instancias de rol contenidas
en el mismo servicio en la nube y mediante FQDN para las máquinas virtuales y las instancias de rol en la misma
red virtual. Para más información sobre DNS, consulte Resolución de nombres para las máquinas virtuales y las
instancias de rol de Cloud Services.
Existe una limitación de los 100 primeros servicios en la nube en una red virtual para la resolución de nombres
entre inquilinos mediante DNS proporcionado por Azure. Si usa su propio servidor DNS, esta limitación no es
aplicable.
¿Puedo invalidar mi configuración de DNS por máquina virtual o servicio en la nube?
Sí. Puede configurar los servidores DNS por máquina virtual o servicio en la nube para invalidar la configuración
de red predeterminada. Sin embargo, se recomienda usar DNS en toda la red siempre que sea posible.
¿Puedo usar mi propio sufijo DNS?
No. No puede especificar un sufijo DNS personalizado para sus redes virtuales.

Conexión de máquinas virtuales

¿Puedo implementar máquinas virtuales en una red virtual?
Sí. Todas las interfaces de red (NIC) conectadas a una máquina virtual implementada a través del modelo de
implementación de Resource Manager deben estar conectadas a una red virtual. Las máquinas virtuales
implementadas a través del modelo de implementación clásica también se pueden conectar a una red virtual.
¿Cuáles son los distintos tipos de direcciones IP que se pueden asignar a máquinas virtuales?
Privada: se asigna a cada uno de los NIC de todas las máquinas virtuales. Para asignar la dirección se
puede usar el método estático o el dinámico. La direcciones IP privadas se asignan del intervalo
especificado en la configuración de subred de la red virtual. A los recursos implementados a través del
modelo de implementación clásica se les asignan direcciones IP privadas, aunque no estén conectadas a
una red virtual. El comportamiento del método de asignación es diferente en función de si se ha
implementado un recurso con el modelo de implementación clásica o de Resource Manager:
Resource Manager : una dirección IP privada asignada con el método dinámico o estático permanece
 asignada a una máquina virtual (Resource Manager) hasta que se elimina el recurso. La diferencia es
que cuando se usa el método estático el usuario selecciona la dirección que se asigna y cuando se usa
el dinámico es Azure quien la elige.
Clásica : las direcciones IP privadas asignadas con el método dinámico pueden cambiar cuando se
reinicia una máquina virtual (clásica) después de haber estado en un estado detenido (desasignada). Si
necesita asegurarse de que la dirección IP privada de un recurso implementado mediante el modelo de
implementación clásica no cambie nunca, asigne una dirección IP privada con el método estático.
Pública: opcionalmente, se puede asignar a NIC conectadas a máquinas virtuales implementadas a través
del modelo de implementación de Azure Resource Manager. La dirección se puede asignar con el método
de asignación estática o el de asignación dinámica. Todas las máquinas virtuales y las instancias de rol de
Cloud Services implementadas a través del modelo de implementación clásica existen en un servicio en la
nube, al que se asigna una dirección IP virtual (VIP) pública y dinámica. Si se desea, una dirección IP
pública estática, que se denomina dirección IP reservada, puede asignarse como si fuera una VIP. Las
direcciones IP públicas se pueden asignar a máquinas virtuales o instancias de rol de Cloud Services
individuales implementadas mediante el modelo de implementación clásica. Estas direcciones se
denominan direcciones IP públicas a nivel de instancia (ILPIP) y se puede asignar dinámicamente.
¿Puedo reservar una dirección IP interna para una máquina virtual que crearé más adelante?
No. Las direcciones IP privadas no se pueden reservar. Si hay una dirección IP privada disponible, el servidor
DHCP la asigna a una máquina virtual o una instancia de rol. La máquina virtual puede ser, o no, aquella a la que
quiere que se asigne la dirección IP privada. Sin embargo, la dirección IP privada de una máquina virtual ya
creada se puede cambiar por cualquier dirección IP privada disponible.
¿Cambian las direcciones IP privadas de las máquinas virtuales en una red virtual?
Depende. Si se ha implementado la máquina virtual mediante Resource Manager, no, con independencia de si la
dirección IP se asignó con el método de asignación estático o dinámico. Si la máquina virtual se implementó
mediante el modelo de implementación clásica, se pueden cambiar las direcciones IP dinámicas cuando se inicia
una máquina virtual después de haber estado en estado detenido (desasignado). La dirección se libera de una
máquina virtual implementada con cualquiera de los modelos de implementación cuando se elimina la máquina.
¿Se pueden asignar manualmente direcciones IP a las NIC del sistema operativo de la máquina virtual?
Sí, pero no se recomienda a menos que es necesario, por ejemplo, al asignar varias direcciones IP a una máquina
virtual. Para más información, consulte Adición de varias direcciones IP a una máquina virtual. Si la dirección IP
asignada a una NIC de Azure asociada a una máquina virtual cambia, y la dirección IP en el sistema operativo de
la máquina virtual es diferente, se pierde la conectividad a la máquina virtual.
¿Qué les sucede a mis direcciones IP si se detiene una ranura de implementación de un servicio en la nube o se
apaga una máquina virtual desde el sistema operativo?
Nada. Las direcciones IP (VIP pública, pública y privada) siguen estando asignadas a la ranura de implementación
de un servicio en la nube o a la máquina virtual.
¿Puedo mover las máquinas virtuales de una subred a otra en una red virtual sin volver a implementarla?
Sí. Puede encontrar más información en el artículo Traslado de una máquina virtual o una instancia de rol a una
subred diferente.
¿Puedo configurar una dirección MAC estática para mi máquina virtual?
No. Una dirección MAC no se puede configurar de forma estática.
¿Seguirá siendo la dirección MAC la misma en mi máquina virtual una vez que se ha creado?
Sí, la dirección MAC de una máquina virtual no cambia, independientemente de que esta se haya implementado a
través del modelo de implementación clásica o de Resource Manager, hasta que se elimina. Antes, la dirección
MAC se liberaba si la máquina virtual se detenía (se desasignaba), pero ahora la dirección MAC se conserva
aunque la máquina virtual se encuentre en estado desasignada. La dirección MAC permanece asignada a la
interfaz de red hasta que esta se elimina o se cambia la dirección IP privada asignada a la configuración de IP
principal de la interfaz de red principal.
¿Puedo conectarme a Internet desde una máquina virtual de una red virtual?
Sí. Todas las máquinas virtuales y las instancias de rol de Cloud Services implementadas dentro de una red
virtual pueden conectarse a Internet.

Servicios de Azure que se conectan a redes virtuales

¿Se puede usar Azure App Service Web Apps con una red virtual?
Sí. Puede implementar Web Apps dentro de una red virtual mediante un ASE (App Service Environment),
conectar el back-end de las aplicaciones a una red virtual con Integración con red virtual y bloquear el tráfico
entrante a la aplicación con puntos de conexión de servicio. Para más información, consulte los siguientes
artículos.
Características de redes de App Service
Creación de Web Apps en un entorno de App Service Environment
Integración de una aplicación con Azure Virtual Network
Restricciones de acceso de Azure App Service
¿Puedo implementar Cloud Services con los roles web y de trabajo (PaaS ) en una red virtual?
Sí. Opcionalmente, es posible implementar instancias de rol de Cloud Services en redes virtuales. Para hacerlo, es
preciso especificar el nombre de la red virtual y las asignaciones de rol/subred en la sección de configuración de
red de la configuración del servicio. No es necesario actualizar ninguno de los archivos binarios.
¿Se puede conectar un conjunto de escalado de máquinas virtuales a una red virtual?
Sí. Debe conectar un conjunto de escalado de máquinas virtuales a una red virtual.
¿Hay una lista completa de servicios de Azure de la que pueda implementar recursos desde una red virtual?
Sí. Para más información, consulte Integración de red virtual para los servicios de Azure.
¿Cómo se puede restringir el acceso a recursos de PaaS de Azure desde una red virtual?
Los recursos implementados a través de algunos servicios PaaS de Azure (como Azure Storage y
Azure SQL Database) pueden restringir el acceso de red a la red virtual mediante puntos de conexión de servicio
de red virtual o Azure Private Link. Para obtener más información, consulte la información general sobre puntos
de conexión de servicio de red virtual y Azure Private Link
¿Puedo mover mis servicios dentro y fuera de las redes virtuales?
No. No se pueden mover los servicios dentro y fuera de las redes virtuales. Para mover un recurso a otra red
virtual, tendrá que eliminar el recurso y volver a implementarlo.

Seguridad
¿Cuál es el modelo de seguridad de las redes virtuales?
Las redes virtuales están aisladas unas de otras y de otros servicios hospedados en la infraestructura de Azure.
Una máquina virtual es un límite de confianza.
¿Puedo restringir el flujo de tráfico de entrada o salida a los recursos conectados a la red virtual?
Sí. Puede aplicar grupos de seguridad de red a subredes individuales de una red virtual, a los NIC conectados a
una red virtual, o a ambos.
¿Se puede implementar un firewall entre los recursos conectados a una red virtual?
Sí. A través de Azure Marketplace es posible implementar una aplicación virtual de red de firewall de varios
proveedores.
¿Hay información disponible acerca la protección de las redes virtuales?
Sí. Para más información, consulte Información general sobre Azure Network Security.

API, esquemas y herramientas

¿Puedo administrar redes virtuales mediante programación?
Sí. Puede usar API de REST en redes virtuales en los modelos de implementación de Azure Resource Manager y
clásica.
¿Hay compatibilidad con las herramientas para redes virtuales?
Sí. Más información acerca del uso de:
Azure Portal para implementar redes virtuales a través de los modelos de implementación con Azure
Resource Manager y clásica.
PowerShell para administrar redes virtuales que se implementan a través de los modelos de implementación
con Resource Manager y clásica.
La interfaz de la línea de comandos (CLI) de Azure para implementar y administrar redes virtuales
implementadas mediante los modelos de implementación de Resource Manager y clásica.

Emparejamiento de VNET
¿Qué es el emparejamiento de VNet?
El emparejamiento de VNet (o emparejamiento de redes virtuales) permite conectar redes virtuales. Una
conexión de emparejamiento de VNet entre redes virtuales permite enrutar el tráfico entre ellas de manera
privada a través de direcciones IPv4. Las máquinas virtuales de las VNet emparejadas pueden comunicarse entre
sí como si estuvieran dentro de la misma red. Estas redes virtuales pueden estar en la misma región o en
regiones diferentes (también conocidas como emparejamiento de VNet global). También se pueden crear
conexiones de emparejamiento de VNet a través de las suscripciones a Azure.
¿Puedo crear una conexión de emparejamiento a una red virtual en una región diferente?
Sí. El emparejamiento de VNET global permite emparejar redes virtuales en diferentes regiones. Emparejamiento
de VNET global está disponible en todas las regiones públicas de Azure, en las regiones de nube de China y en
regiones de nube gubernamentales. No se puede emparejar globalmente desde las regiones públicas de Azure a
las regiones de nube nacionales.
¿Cuáles son las restricciones relacionadas con Emparejamiento de VNET Global y los equilibradores de carga?
Si las dos redes virtuales en dos regiones diferentes están emparejadas a través del emparejamiento de VNet
global, no se puede conectar a los recursos que están detrás de una instancia básica de Load Balancer a través de
la dirección IP de front-end de Load Balancer. Esta restricción no existe para una instancia de Load Balancer
estándar. Los siguientes recursos pueden usar instancias básicas de Load Balancer, lo que significa que no puede
acceder a ellos desde la dirección IP de front-end de Load Balancer a través del emparejamiento de red virtual
global. Sin embargo, puede usar el emparejamiento de red virtual global para llegar a los recursos directamente
desde sus direcciones IP de red virtual privada, si se permite.
Máquinas virtuales detrás de equilibradores de carga básicos
Conjuntos de escalado de máquinas virtuales con equilibradores de carga básicos
Redis Cache
SKU de Application Gateway (versión 1)
Service Fabric
MI de SQL
API Management
Active Directory Domain Services (ADDS)
 Logic Apps
HDInsight
Azure Batch
Entorno de App Service
Se puede conectar a estos recursos a través de ExpressRoute o de red virtual a red virtual a través de puertas de
enlace de red virtuales.
¿Puedo habilitar el emparejamiento de VNET si mis redes virtuales pertenecen a suscripciones de diferentes
inquilinos de Azure Active Directory?
Sí. No es posible establecer el emparejamiento de VNET (ya sea local o global) si las suscripciones pertenecen a
diferentes inquilinos de Azure Active Directory. Puede hacerlo a través de PowerShell o CLI. Aún no se admite el
Portal.
Mi conexión de emparejamiento de VNET se encuentra en estado Iniciado, ¿por qué no puedo conectarme?
Si la conexión de emparejamiento está en estado Iniciado, esto significa que ha creado un solo vínculo. Se debe
crear un vínculo bidireccional con el fin de establecer una conexión correcta. Por ejemplo, para emparejar VNET A
a VNET B, debe crearse un vínculo de VNET A a VNET B y de VNET B a VNET A. La creación de ambos vínculos
cambiará el estado a Conectado.
Mi conexión de emparejamiento de VNet se encuentra en estado Desconectado, ¿por qué no puedo crear una
conexión de emparejamiento?
Si la conexión de emparejamiento de VNet está en estado Desconectado, significa que se ha eliminado uno de los
vínculos creados. Para volver a establecer una conexión de emparejamiento, deberá eliminar el vínculo y volverlo
a crear.
¿Puedo emparejar mi red virtual con otra en una suscripción diferente?
Sí. Puede emparejar redes virtuales entre suscripciones y entre regiones.
¿Puedo emparejar dos redes virtuales con rangos de direcciones coincidentes o superpuestas?
No. Los espacios de direcciones no deben solaparse para habilitar el emparejamiento de redes virtuales.
¿Cuánto cuestan los vínculos de emparejamiento de redes virtuales?
La creación de una conexión de emparejamiento VNET es gratuita. Se cobra la transferencia de datos a través de
conexiones de emparejamiento. Consulte aquí.
¿Está cifrado el tráfico de emparejamiento de VNET?
No. El tráfico entre recursos en redes virtuales emparejadas es privado y aislado. Sigue estando en la columna
vertebral de Microsoft.
¿Por qué mi conexión de emparejamiento está en estado Desconectado?
Las conexiones de emparejamiento de redes virtuales pasan a un estado Desconectado cuando se elimina un
vínculo de emparejamiento de red virtual. Debe eliminar ambos vínculos para restablecer una conexión de
emparejamiento correcta.
Si se empareja VNETA con VNETB y se empareja VNETB con VNETC, ¿significa que VNETA y VNETC están
emparejadas?
No. No se admite el emparejamiento transitivo. Se deben emparejar VNETA y VNETC para que esto se produzca.
¿Hay alguna limitación de ancho de banda para las conexiones de emparejamiento?
No. El emparejamiento de VNET, ya sea local o global, no impone ninguna restricción de ancho de banda. El
ancho de banda solo está limitado por el recurso de proceso o de máquina virtual.
¿Cómo se pueden solucionar problemas de emparejamiento de redes virtuales?
Pruebe con esta guía de solucionador de problemas.
TAP de red virtual
¿Qué regiones de Azure están disponibles para TAP de red virtual?
La versión preliminar de TAP de red virtual está disponible en todas las regiones de Azure. Las interfaces de red
supervisadas, el recurso TAP de la red virtual y el recopilador o solución de análisis deben implementarse en la
misma región.
¿El TAP de red virtual admite las funcionalidades de filtrado de los paquetes reflejados?
Las funcionalidades de filtrado no son compatibles con la versión preliminar de TAP de la red virtual. Cuando se
agrega una configuración de TAP a una interfaz de red, se transmite una copia en profundidad de todo el tráfico
de entrada y salida de la interfaz de red al destino de TAP.
¿Se pueden agregar varias configuraciones de TAP a una interfaz de red supervisada?
Una interfaz de red supervisada puede tener solo una configuración de TAP. Compruebe con la solución de
asociados individual la funcionalidad de transmitir varias copias del tráfico de TAP a las herramientas de análisis
de su elección.
¿Puede el mismo recurso TAP de red virtual agregar tráfico desde las interfaces de red supervisadas en más de
una red virtual?
Sí. El mismo recurso de TAP de red virtual se puede utilizar para agregar tráfico reflejado desde las interfaces de
red supervisadas en redes virtuales emparejadas en la misma suscripción o en otra. El recurso TAP de red virtual
y el equilibrador de carga de destino o la interfaz de red de destino deben estar en la misma suscripción. Todas
las suscripciones deben estar bajo el mismo inquilino de Azure Active Directory.
¿Existen consideraciones de rendimiento en el tráfico de producción si se habilita una configuración de TAP de
red virtual en una interfaz de red?
TAP de red virtual está en versión preliminar. Durante la versión preliminar no hay ningún Acuerdo de Nivel de
Servicio. La funcionalidad no debe usarse para cargas de trabajo de producción. Cuando se habilita una interfaz
de red de máquina virtual con una configuración de TAP, se utilizan los mismos recursos en el host de Azure
asignados a la máquina virtual para enviar el tráfico de producción para realizar la función de creación de reflejo
y enviar los paquetes reflejados. Seleccione el tamaño correcto de la máquina virtual Linux o Windows para
asegurarse de que dispone de recursos suficientes para que la máquina virtual envíe el tráfico de producción y el
tráfico reflejado.
¿Se admiten redes aceleradas para Linux o Windows con TAP de red virtual?
Podrá agregar una configuración de TAP en una interfaz de red asociada a una máquina virtual que esté
habilitada con redes aceleradas. Pero el rendimiento y la latencia en la máquina virtual se verán afectados por la
adición de la configuración de TAP, ya que la descarga para reflejar el tráfico no se admite actualmente por la red
acelerada de Azure.

Puntos de conexión de servicio de red virtual

¿Cuál es la secuencia correcta de operaciones para configurar los puntos de conexión de servicio en un
servicio de Azure?
Existen dos pasos para asegurar un recurso de servicio de Azure mediante puntos de conexión de servicio:
1. Active los puntos de conexión de servicio para el servicio de Azure.
2. Configure las ACL de red virtual en el servicio de Azure.
El primer paso es realizar una operación del lado de red y, el segundo, es realizar una operación del lado del
recurso de servicio. Según los permisos RBAC otorgados al rol de administrador, el mismo administrador o varios
administradores diferentes pueden realizar ambos pasos. Le recomendamos que primero active los puntos de
conexión de servicio de la red virtual antes de configurar las ACL de red virtual en el lado del servicio de Azure.
Por lo tanto, los pasos deben realizarse en la secuencia que se detalló anteriormente para configurar los puntos
de conexión de servicio de la red virtual.

NOTE
Debe completar las dos operaciones descritas anteriormente antes de poder limitar el acceso del servicio de Azure a la red
virtual y a la subred permitidas. Si solo activa los puntos de conexión de servicio del servicio de Azure en el lado de red no
obtendrá el acceso limitado. Asimismo, también debe configurar las ACL de red virtual en el lado del servicio de Azure.

Ciertos servicios (como SQL y CosmosDB) permiten excepciones en la secuencia anterior si usa la marca
IgnoreMissingVnetSer viceEndpoint . Una vez que la marca se establece en True , las ACL de la red virtual
pueden establecerse en el lado del servicio de Azure antes de configurar los puntos de conexión de servicio en el
lado de red. Los servicios de Azure proporcionan esta marca para ayudar a los clientes en los casos en que los
firewalls de IP específicos estén configurados en los servicios de Azure y la activación de los puntos de conexión
de servicio en el lado de la red pueda provocar una caída de la conectividad, ya que la IP de origen cambia de una
dirección IPv4 pública a una dirección privada. La configuración de las ACL de la red virtual en el lado del servicio
de Azure antes de configurar los puntos de conexión de servicio en el lado de red puede ayudarle a evitar que la
conectividad se vea afectada.
¿Todos los servicios de Azure residen en la red virtual de Azure que proporciona el cliente? ¿Cómo funciona el
punto de conexión de servicio de la red virtual con los servicios de Azure?
No, no todos los servicios de Azure residen en la red virtual del cliente. La mayoría de los servicios de datos de
Azure, como Azure Storage, Azure SQL y Azure Cosmos DB, son servicios de varios inquilinos a los que se puede
obtener acceso a través de direcciones IP públicas. Puede obtener más información sobre la integración de redes
virtuales para los servicios de Azure aquí.
Cuando usa la característica de puntos de conexión de servicio de la red virtual (debe activar el punto de
conexión de servicio de la red virtual en el lado de la red y configurar las ACL de red virtual adecuadas en el lado
del servicio de Azure), el acceso a un servicio de Azure está restringido desde una red y una subred permitidas.
¿Cómo proporciona seguridad el punto de conexión de servicio de la red virtual?
La característica de puntos de conexión de servicio de la red virtual (debe activar el punto de conexión de servicio
de la red virtual en el lado de la red y configurar las ACL de red virtual adecuadas en el lado del servicio de
Azure) limita el acceso a un servicio de Azure a la red virtual y la subred permitidas, lo que proporciona
seguridad a nivel de red y el aislamiento del tráfico de los servicios de Azure. Todo el tráfico que usa los puntos
de conexión de servicio de la red virtual fluye sobre la red troncal de Microsoft, proporcionando así otra capa de
aislamiento de la red pública de Internet. Además, los clientes pueden optar por eliminar completamente el
acceso público de Internet a los recursos del servicio de Azure y permitir el tráfico solo desde su red virtual a
través de una combinación de firewall de IP y ACL de red virtual, lo que les permitirá proteger los recursos del
servicio de Azure de accesos no autorizados.
¿Qué protege el punto de conexión de servicio de la red virtual, los recursos de red virtual o el servicio de
Azure?
Los puntos de conexión de servicio de la red virtual le ayudan a proteger los recursos del servicio de Azure. Los
recursos de red virtual están protegidos mediante grupos de seguridad de red (NSG).
¿Hay algún costo por usar los puntos de conexión de servicio de la red virtual?
No hay ningún cargo adicional para el uso de puntos de conexión de servicio.
¿Puedo activar los puntos de conexión de servicio de la red virtual y configurar las ACL de red virtual si esta y
los recursos del servicio de Azure pertenecen a suscripciones diferentes?
Sí, es posible. Las redes virtuales y los recursos del servicio de Azure pueden estar en la misma o en diferentes
suscripciones. El único requisito es que tanto la red virtual como los recursos del servicio de Azure deben estar
bajo el mismo inquilino de Active Directory (AD).
¿Puedo activar los puntos de conexión de servicio de la red virtual y configurar las ACL de red virtual si esta y
los recursos del servicio de Azure pertenecen a diferentes inquilinos de AD?
Sí, es posible cuando se usan puntos de conexión de servicio para Azure Storage y Azure Key Vault. Para el resto
de servicio, los puntos de conexión de servicio de la red virtual y las ACL de red virtual no se admiten con los
inquilinos de AD.
¿La dirección IP de un dispositivo local que está conectada mediante la puerta de enlace de Azure Virtual
Network (VPN ) o la puerta de enlace de ExpressRoute puede obtener acceso al servicio de Azure PaaS
mediante los puntos de conexión de servicio de la red virtual?
De forma predeterminada, los recursos de servicio de Azure protegidos para las redes virtuales no son accesibles
desde redes locales. Si quiere permitir el tráfico desde el entorno local, también debe permitir las direcciones IP
públicas (normalmente NAT) desde el entorno local o ExpressRoute. Estas direcciones IP se pueden agregar a
través de la configuración del firewall de IP para los recursos de los servicios de Azure.
¿Puedo usar la característica de punto de conexión de servicio de la red virtual para proteger el servicio de
Azure en varias subredes de una o varias redes virtuales?
Para proteger los servicios de Azure en varias subredes que se encuentren en una o varias redes virtuales,
habilite los puntos de conexión de servicio en el lado de red en cada una de las subredes de manera
independiente y, a continuación, proteja los recursos del servicio de Azure en todas las subredes mediante la
configuración de las ACL de red virtual adecuadas en el lado del servicio de Azure.
¿Cómo puedo filtrar el tráfico saliente de una red virtual a los servicios de Azure y seguir usando los puntos de
conexión de servicio?
Si quiere inspeccionar o filtrar el tráfico destinado a un servicio de Azure desde una red virtual, puede
implementar una aplicación virtual de red dentro de la red virtual. Después, puede aplicar los puntos de conexión
de servicio a la subred donde se implementa la aplicación virtual de red y se protegen los recursos de servicio de
Azure solo para esta subred mediante las ACL de red virtual. Este escenario también puede resultar útil si quiere
restringir el acceso de servicio de Azure desde la red virtual solo a recursos específicos de Azure, mediante el
filtrado de la aplicación virtual de red. Para más información, consulte el artículo sobre la salida con las
aplicaciones de redes virtuales.
¿Qué ocurre si accede a una cuenta de servicio de Azure que tiene habilitada la lista de control de acceso (ACL )
de una red virtual que está fuera de la misma red virtual?
Se devuelve el error HTTP 403 o 404.
¿Las subredes de una máquina virtual creada en regiones distintas pueden obtener acceso a una cuenta de
servicio de Azure en otra región?
Sí, para la mayoría de los servicios de Azure, las redes virtuales creadas en diferentes regiones pueden obtener
acceso a los servicios de Azure en otra región a través de los puntos de conexión de servicio de la red virtual. Por
ejemplo, si una cuenta de Azure Cosmos DB está en el Oeste de EE. UU. o el Este de EE. UU. y las redes virtuales
están en varias regiones, la red virtual puede obtener acceso a Azure Cosmos DB. Storage y SQL son excepciones
que son de naturaleza regional, y tanto la red virtual como el servicio de Azure deben estar en la misma región.
¿Puede un servicio de Azure tener una ACL de red virtual y un firewall de IP?
Sí, una ACL de red virtual y el firewall de IP pueden coexistir. Ambas características se complementan entre sí para
garantizar el aislamiento y la seguridad.
¿Qué sucede si se elimina una red virtual o subred que tiene el punto de conexión de servicio activado para el
servicio de Azure?
La eliminación de redes virtuales y subredes son operaciones independientes y se admiten incluso cuando los
puntos de conexión de servicio están activados para los servicios de Azure. En los casos en que los servicios de
Azure tienen configuradas las ACL de red virtual, para esas redes virtuales y subredes, la información de las ACL
de la red virtual asociada con ese servicio de Azure se desactiva cuando se elimina una red virtual o subred que
tiene el punto de conexión de servicio de la red virtual activado.
¿Qué sucede si se elimina una cuenta de servicio de Azure que tiene un punto de conexión de servicio de la
red virtual habilitado?
La eliminación de una cuenta de servicio de Azure es una operación independiente y se admite incluso cuando el
punto de conexión de servicio está habilitado en el lado de la red y las ACL de la red virtual se configuran en el
lado del servicio de Azure.
¿Qué sucede con la dirección IP de origen de un recurso (como una máquina virtual en una subred) que tiene
habilitado el punto de conexión de servicio de la red virtual?
Si los puntos de conexión de servicio de red virtual están habilitados, las direcciones IP de los recursos de la
subred de la red virtual pasarán de usar las direcciones IPV4 públicas a usar las direcciones IP privadas de Azure
Virtual Network para el tráfico que fluye hacia el servicio de Azure. Tenga en cuenta que esto puede provocar un
error en los firewalls de IP específicos que se configuran en una dirección IPV4 pública que estaba anteriormente
en los servicios de Azure.
¿La ruta del punto de conexión de servicio siempre tiene prioridad?
Los puntos de conexión de servicio agregan una ruta de sistema que tiene prioridad sobre las rutas BGP y que
proporciona un enrutamiento óptimo para el tráfico del punto de conexión de servicio. Los puntos de conexión
de servicio siempre toman el tráfico del servicio directamente de la red virtual al servicio en la red troncal de
Microsoft Azure. Para más información sobre cómo Azure selecciona una ruta, vea Enrutamiento del tráfico de
Azure Virtual Network.
¿Cómo funciona NSG en una subred con puntos de conexión de servicio?
Para alcanzar el servicio de Azure, los NSG deben permitir la conectividad de salida. Si los NSG están abiertos a
todo el tráfico saliente de Internet, entonces el tráfico del punto de conexión de servicio debería funcionar.
También puede limitar el tráfico saliente a las IP de servicio mediante las etiquetas de servicio.
¿Qué permisos necesito para configurar los puntos de conexión de servicio?
Un usuario con acceso de escritura a la red virtual puede configurar los puntos de conexión de servicio de forma
independiente en redes virtuales. Para proteger los recursos de servicio de Azure en una red virtual, el usuario
debe tener el permiso [Link]/vir tualNetworks/subnets/joinViaSer viceEndpoint/action en
las subredes que se agreguen. De forma predeterminada, este permiso se incluye en los roles de administrador
de servicios integrado y puede modificarse mediante la creación de roles personalizados. Obtenga más
información sobre los roles integrados y la asignación de permisos específicos a roles personalizados.
¿Puedo filtrar el tráfico de red virtual a los servicios de Azure, permitiendo únicamente recursos de servicio
específicos de Azure, sobre los puntos de conexión de servicio de la red virtual?
Las directivas de punto de conexión de servicio de la red virtual (VNet) le permiten filtrar el tráfico de red virtual
a los servicios de Azure, lo que permite únicamente recursos de servicio específicos de Azure, sobre los puntos de
conexión de servicio. Las directivas de punto de conexión de servicio ofrecen un control de acceso
pormenorizado para el tráfico de red virtual a los servicios de Azure. Puede obtener más información acerca de
las directivas de punto de conexión de servicio aquí.
¿Admite Azure Active Directory (Azure AD) puntos de conexión de servicio de red virtual?
Azure Active Directory (Azure AD) no admite los puntos de conexión de servicio de forma nativa. Aquí encontrará
una lista completa de los servicios de Azure que admiten puntos de conexión de servicio de red virtual. Cabe
mencionar que la etiqueta "[Link]" que aparece bajo los servicios compatibles con los
puntos de conexión de servicio se usa para admitir los puntos de conexión de servicio para ADLS Gen 1. En el
caso de ADLS Gen 1, la integración de red virtual de Azure Data Lake Storage Gen1 emplea la seguridad del
punto de conexión de servicio de red virtual entre la red virtual y Azure Active Directory (Azure AD) para generar
notificaciones de seguridad adicionales en el token de acceso. Estas notificaciones se usan entonces para
autenticar la red virtual en la cuenta de Data Lake Storage Gen1 y permitir el acceso. Más información sobre la
integración con redes virtuales de Azure Data Lake Store Gen 1
¿Hay algún límite en la cantidad de puntos de conexión de servicio de la red virtual que puedo configurar
desde mi red virtual?
No hay límite en el número total de puntos de conexión de servicio de la red virtual en una red virtual. Para un
recurso de servicio de Azure (por ejemplo, una cuenta de Azure Storage), los servicios pueden exigir límites en el
número de subredes que se usan para proteger el recurso. En la tabla siguiente se muestran algunos límites de
ejemplo:

SERVIC IO DE A Z URE L ÍM IT ES EN L A S REGL A S DE RED VIRT UA L

Azure Storage 100

Azure SQL 128

Azure SQL Data Warehouse 128

Azure KeyVault 127

Azure Cosmos DB 64

Centro de eventos de Azure 128

Azure Service Bus 128

Azure Data Lake Store V1 100

NOTE
Los límites están sujetos a cambios a discreción del servicio de Azure. Consulte la documentación de servicio
correspondiente para obtener detalles acerca de los servicios.