Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Aspectos básicos
¿Qué es una red virtual?
Una red virtual es una representación de su propia red en la nube, tal y como la proporciona el servicio Azure Virtual Network. Una red virtual es un aislamiento lógico de la nube de Azure dedicado a su suscripción.
Puede utilizar redes virtuales para aprovisionar y administrar redes privadas virtuales (VPN) en Azure. Opcionalmente, puede vincular redes virtuales con otras redes virtuales en Azure, o con su infraestructura de TI local, para crear soluciones híbridas o entre entornos locales.
Cada red virtual que creas tiene su propio bloque CIDR. Puede vincular una red virtual a otras redes virtuales y redes locales siempre que los bloques CIDR no se superpongan. También tiene control sobre la configuración del servidor DNS para redes virtuales, junto con la segmentación de la red virtual en subredes.
Utilice redes virtuales para:
Cree una red virtual dedicada, privada y exclusiva para la nube. A veces no necesita una configuración entre entornos para su solución. Cuando crea una red virtual, sus servicios y máquinas virtuales (VMs) dentro de su red virtual pueden comunicarse entre sí de forma directa y segura en la nube. Aún puede configurar conexiones de punto de conexión para las VMs y los servicios que requieren comunicación por Internet, como parte de su solución.
Amplíe su centro de datos de forma segura. Con las redes virtuales, puede crear VPN tradicionales de sitio a sitio (S2S) para escalar de forma segura la capacidad de su centro de datos. Las VPN S2S utilizan IPsec para proporcionar una conexión segura entre la puerta de enlace VPN corporativa y Azure.
Habilitar escenarios de nube híbrida. Puede conectar de forma segura aplicaciones basadas en la nube a cualquier tipo de sistema local, incluidos mainframes y sistemas Unix.
¿Cómo empiezo?
Visite la documentación de Azure Virtual Network para empezar. Este contenido proporciona información general y de implementación para todas las características de la red virtual.
¿Puedo usar redes virtuales sin conectividad entre entornos locales?
Sí. Puede utilizar una red virtual sin conectarla a sus entornos locales. Por ejemplo, podría ejecutar controladores de dominio de Microsoft Windows Server Active Directory y granjas de SharePoint únicamente en una red virtual de Azure.
¿Puedo realizar la optimización de la WAN entre redes virtuales o entre una red virtual y mi centro de datos local?
Sí. Puede implementar un dispositivo virtual de red para la optimización de la WAN de varios proveedores a través de Azure Marketplace.
Configuración
¿Qué herramientas debo usar para crear una red virtual?
Puede emplear las siguientes herramientas para crear o configurar una red virtual:
- Azure portal
- PowerShell
- Azure CLI
-
Archivo de configuración de red (
netcfg, solo para redes virtuales clásicas)
¿Qué intervalos de direcciones puedo usar en mis redes virtuales?
Recomendamos utilizar los siguientes rangos de direcciones, enumerados en RFC 1918. El IETF ha reservado estos rangos para espacios de direcciones privados y no enrutables.
- 10.0.0.0 a 10.255.255.255 (prefijo 10/8)
- 172.16.0.0 a 172.31.255.255 (prefijo 172.16/12)
- 192.168.0.0 a 192.168.255.255 (prefijo 192.168/16)
También puede implementar el espacio de direcciones compartido reservado en RFC 6598, que se trata como un espacio de direcciones IP privado en Azure:
- 100.64.0.0 a 100.127.255.255 (prefijo 100.64/10)
Otros espacios de direcciones, incluidos todos los demás espacios de direcciones privados y no enrutables reconocidos por el IETF, podrían funcionar, pero tienen efectos secundarios indeseables.
Además, no se pueden agregar los siguientes rangos de direcciones:
- 224.0.0.0/4 (multidifusión)
- 255.255.255.255/32 (difusión)
- 127.0.0.0/8 (bucle invertido)
- 169.254.0.0/16 (vínculo local)
- 168.63.129.16/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 mi red virtual?
Sí. Consulte Límites de red para obtener más información. Los espacios de direcciones de subred no pueden superponerse entre sí.
¿Hay alguna restricción en el uso de direcciones IP dentro de estas subredes?
Sí. Azure reserva las cuatro primeras direcciones y la última dirección, lo que suma un total de cinco direcciones IP dentro de cada subred.
Por ejemplo, el intervalo de direcciones IP de 192.168.1.0/24 tiene las siguientes direcciones reservadas:
- 192.168.1.0: direcciones de red.
- 192.168.1.1: Reservado por Azure para la puerta de enlace predeterminada.
- 192.168.1.2, 192.168.1.3: Reservadas por Azure para asignar las direcciones IP de Azure DNS al espacio de red virtual.
- 192.168.1.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 es /2 (con definiciones de subred CIDR). Las subredes IPv6 deben tener un tamaño exactamente de /64.
¿Puedo llevar mis VLAN a Azure utilizando 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 obtener más información sobre el enrutamiento en Azure, consulte Rutas personalizadas.
¿Cuál es el comportamiento cuando aplico tanto un NSG como un UDR en la subred?
Para el tráfico entrante, se procesan las reglas entrantes del grupo de seguridad de red (NSG). Para el tráfico saliente, se procesan las reglas de salida de NSG, seguidas de las reglas de ruta definidas por el usuario (UDR).
¿Cuál es el comportamiento cuando aplico un NSG a una NIC y una subred para una máquina virtual?
Cuando se aplican NSG tanto en un adaptador de red (NIC) como en una subred para una máquina virtual:
- Se procesa un NSG a nivel de subred, seguido de un NSG a nivel de NIC, para el tráfico entrante.
- Se procesa un NSG a nivel de NIC, seguido de un NSG a nivel de subred, para el tráfico saliente.
¿Las redes virtuales admiten multidifusión o difusión?
No. No se admite difusión ni multidifusión.
¿Qué protocolos puedo utilizar en redes virtuales?
Puede utilizar los protocolos TCP, UDP, ESP, AH e ICMP TCP/IP en redes virtuales.
La unidifusión es compatible con las redes virtuales. Los paquetes multidifusión, difusión, encapsulados IP-in-IP y Generic Routing Encapsulation (GRE) se bloquean en las redes virtuales. No se puede utilizar el Protocolo de configuración dinámica de host (DHCP) a través de Unicast (puerto de origen UDP/68, puerto de destino UDP/67). Los puertos UDP 4791 y 65330 están reservados para el host.
¿Puedo implementar un servidor DHCP en una red virtual?
Las redes virtuales de Azure proporcionan servicios de DHCP y DNS a Azure Virtual Machines. Sin embargo, también puede implementar un servidor DHCP en una máquina virtual de Azure para atender a los clientes locales a través de un agente de retransmisión DHCP.
Anteriormente, los servidores DHCP en Azure se consideraban no factibles, ya que el tráfico al puerto UDP/67 era una velocidad limitada en Azure. Sin embargo, las actualizaciones recientes de la plataforma han eliminado la limitación de velocidad, lo que permite esta funcionalidad.
Nota:
El cliente local al servidor DHCP (puerto de origen UDP/68, puerto de destino UDP/67) todavía no se admite en Azure, ya que este tráfico se intercepta y controla de forma diferente. Esto dará lugar a mensajes de error “Tiempo de espera agotado” en el momento de LA RENOVACIÓN DE DHCP en T1 cuando el cliente intente acceder directamente al servidor DHCP en Azure. La RENOVACIÓN DE DHCP se realizará correctamente cuando se intente RENOVAR EL DHCP en T2 a través del agente de retransmisión DHCP. Para obtener más información sobre los temporizadores de RENOVACIÓN DHCP en T1 y T2, consulte RFC 2131.
¿Puedo hacer ping a una puerta de enlace predeterminada en una red virtual?
No. Una puerta de enlace predeterminada proporcionada por Azure no responde a un ping. Pero puede utilizar pings en sus redes virtuales para comprobar la conectividad y solucionar problemas entre VMs.
¿Puedo usar tracert para diagnosticar la conectividad?
Sí.
¿Puedo agregar subredes una vez creada la red virtual?
Sí. Puede agregar subredes a redes virtuales en cualquier momento, siempre que se cumplan estas dos condiciones:
- El rango de direcciones de subred no forma parte de otra subred.
- Hay espacio disponible en el rango de direcciones de la red virtual.
¿Puedo modificar el tamaño de la subred después de crearla?
Sí. Puede agregar, eliminar, ampliar o reducir una subred si no hay VMs ni servicios implementados en ella.
¿Puedo modificar una red virtual después de crearla?
Sí. Puede agregar, eliminar y modificar los bloques CIDR que utiliza una red virtual.
Si estoy ejecutando mis servicios en una red virtual, ¿puedo conectarme a Internet?
Sí. Todos los servicios implementados en una red virtual pueden conectarse a Internet. Para obtener más información sobre las conexiones de Internet salientes en Azure, consulte Usar la traducción de direcciones de red de origen (SNAT) para conexiones salientes.
Si desea conectarse de forma entrante a un recurso implementado a través de Azure Resource Manager, el recurso debe tener asignada una dirección IP pública. Para obtener más información, consulte Crear, cambiar o eliminar una dirección IP pública de Azure.
Cada servicio en la nube implementado en Azure tiene asignada una IP virtual (VIP) accesible públicamente. Defina los puntos de conexión de entrada para las funciones de plataforma como servicio (PaaS) y los puntos de conexión para máquinas virtuales a fin de permitir que estos servicios acepten conexiones desde Internet.
¿Las redes virtuales admiten IPv6?
Sí. Las redes virtuales pueden ser solo IPv4 o de doble pila (IPv4 + IPv6). Para obtener más información, consulte ¿Qué es IPv6 para Azure Virtual Network?.
¿Puede una red virtual abarcar varias regiones?
No. Una red virtual está limitada a una sola región. Pero una red virtual sí abarca zonas de disponibilidad. Para obtener más información sobre las zonas de disponibilidad, consulte ¿Qué son las regiones y las zonas de disponibilidad de Azure?.
Puede conectar redes virtuales en diferentes regiones mediante el emparejamiento de redes virtuales. Para obtener 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 red virtual utilizando cualquiera de las siguientes opciones:
- Emparejamiento de redes virtuales. Para obtener más información, consulte Emparejamiento de redes virtuales.
- Una puerta de enlace VPN de Azure. Para obtener más información, consulte Configurar una conexión de puerta de enlace VPN de red a red.
Resolución de nombres (DNS)
¿Qué opciones de DNS hay para redes virtuales?
Utilice la tabla de decisiones de Resolución de nombres para recursos en redes virtuales de Azure como guía para conocer las opciones de DNS disponibles.
¿Puedo especificar servidores DNS para una red virtual?
Sí. Puede especificar direcciones IP para servidores DNS en la configuración de la red virtual. La configuración se aplica como servidor o servidores DNS predeterminados para todas las VMs de la red virtual.
¿Cuántos servidores DNS puedo especificar?
Consulte Límites de redes.
¿Puedo modificar mis servidores DNS después de crear la red?
Sí. Puede cambiar la lista de servidores DNS para la red virtual en cualquier momento.
Si cambia la lista de servidores DNS, deberá renovar el arrendamiento DHCP en todas las VMs afectadas de la red virtual. La nueva configuración DNS entra en vigor tras la renovación del contrato de arrendamiento. Para máquinas virtuales que ejecutan Windows, puede renovar el arrendamiento introduciendo ipconfig /renew directamente en la VM. Para otros tipos de sistemas operativos, consulte la documentación sobre la renovación de la concesión DHCP.
¿Qué es el DNS proporcionado por Azure y funciona con redes virtuales?
El DNS proporcionado por Azure es un servicio DNS multiinquilino de Microsoft. Azure registra en este servicio todas las máquinas virtuales y las instancias de rol de servicio en la nube. Este servicio proporciona resolución de nombres:
- Por nombre de host para VMs e instancias de rol en el mismo servicio en la nube.
- Por nombre de dominio completo (FQDN) para VMs e instancias de rol en la misma red virtual.
Para obtener más información sobre DNS, consulte Resolución de nombres para recursos en redes virtuales de Azure.
Existe una limitación para los primeros 100 servicios en la nube de una red virtual en cuanto a la resolución de nombres entre inquilinos a través del DNS proporcionado por Azure. Si utiliza su propio servidor DNS, esta limitación no se aplica.
¿Puedo anular mi configuración DNS para cada máquina virtual o servicio en la nube?
Sí. Puede configurar servidores DNS para cada máquina virtual o servicio en la nube con el fin de anular la configuración de red predeterminada. Sin embargo, recomendamos usar DNS en toda la red siempre que sea posible.
¿Puedo usar mi propio sufijo DNS?
No. No se puede especificar un sufijo DNS personalizado para las redes virtuales.
Conexión de máquinas virtuales
¿Puedo implementar VMs en una red virtual?
Sí. Todos los adaptadores de red (NIC) conectados a una máquina virtual implementada a través del modelo de implementación de Azure Resource Manager deben estar conectados a una red virtual. Opcionalmente, puede conectar VMs implementadas a través del modelo de implementación clásico a una red virtual.
¿Qué tipos de direcciones IP puedo asignar a las VMs?
Privado: asignado a cada NIC dentro de cada máquina virtual, mediante el método estático o dinámico. Las direcciones IP privadas se asignan desde el rango que especificó en la configuración de subred de su red virtual.
Los recursos implementados a través del modelo de implementación clásico se asignan direcciones IP privadas, incluso si no están conectados a una red virtual. El comportamiento del método de asignación varía en función de si se ha implementado un recurso mediante el Azure Resource Manager o el modelo de implementación clásico:
- Administrador de recursos: una dirección IP privada asignada mediante el método dinámico o estático permanece asignada a una máquina virtual (Azure Resource Manager) hasta que se elimina el recurso. La diferencia es que, cuando se utiliza el método estático, usted selecciona la dirección que se va a asignar, mientras que, cuando se utiliza el método dinámico, Azure la elige.
- Clásico: una dirección IP privada asignada mediante el método dinámico puede cambiar cuando se reinicia una máquina virtual (clásica) después de haber estado en estado detenido (desasignado). Si necesita asegurarse de que la dirección IP privada de un recurso implementado mediante el modelo de implementación clásico nunca cambie, asigne una dirección IP privada utilizando el método estático.
Público: asignado opcionalmente a las NIC conectadas a máquinas virtuales implementadas a través del modelo de implementación de Azure Resource Manager. Puede asignar la dirección utilizando el método de asignación estática o dinámica.
Todas las VMs y las instancias de roles de Azure Cloud Services implementadas a través del modelo de implementación clásico existen dentro de un servicio en la nube. Al servicio en la nube se le asigna una dirección VIP pública dinámica. Opcionalmente, puede asignar una dirección IP estática pública, denominada dirección IP reservada, como 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 y se pueden asignar de forma dinámica.
¿Puedo reservar una dirección IP privada para una máquina virtual que crearé más adelante?
No. No se puede reservar una dirección IP privada. Si hay una dirección IP privada disponible, el servidor DHCP la asigna a una máquina virtual o instancia de rol. La máquina virtual puede ser o no ser aquella a la que desea asignar la dirección IP privada. Sin embargo, puede cambiar la dirección IP privada de una máquina virtual existente por cualquier dirección IP privada disponible.
¿Cambian las direcciones IP privadas de las VMs en una red virtual?
Depende. Si ha implementado la máquina virtual mediante Resource Manager, las direcciones IP no se pueden cambiar, independientemente de si las ha asignado mediante el método de asignación estática o dinámica. Si ha implementado la máquina virtual utilizando el modelo de implementación clásico, las direcciones IP dinámicas pueden cambiar al iniciar una máquina virtual que se encontraba en estado detenido (desasignada).
La dirección se libera de una máquina virtual implementada a través de cualquiera de los dos modelos de implementación cuando se elimina la máquina virtual.
¿Se pueden asignar manualmente direcciones IP a las NIC del sistema operativo de la máquina virtual?
Sí, pero no lo recomendamos a menos que sea necesario, como cuando se asignan varias direcciones IP a una máquina virtual. Para obtener más información, consulte Asignar varias direcciones IP a máquinas virtuales.
Si cambia la dirección IP asignada a una NIC de Azure conectada a una máquina virtual y la dirección IP dentro del sistema operativo de la máquina virtual es diferente, se perderá la conectividad con la máquina virtual.
Si detengo una ranura de implementación de servicio en la nube o apago una máquina virtual desde el sistema operativo, ¿qué ocurre con mis direcciones IP?
Nada. Las direcciones IP (VIP públicas, públicas y privadas) permanecen asignadas a la ranura de implementación del servicio en la nube o a la máquina virtual.
¿Puedo mover VMs de una subred a otra dentro de una red virtual sin necesidad de volver a implementarlas?
Sí. Puede encontrar más información en Mover 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. No se puede configurar de forma estática una dirección MAC.
¿La dirección MAC de mi máquina virtual sigue siendo la misma después de crearla?
Sí. La dirección MAC permanece igual para una máquina virtual que haya implementado tanto a través del Azure Resource Manager como de los modelos de implementación clásicos hasta que la elimine.
Anteriormente, la dirección MAC se liberaba si se detenía (desasignaba) la máquina virtual. Pero ahora, la máquina virtual conserva la dirección MAC cuando se encuentra en estado desasignado. La dirección MAC permanece asignada al adaptador de red hasta que realice una de estas tareas:
- Elimine el adaptador de red.
- Cambie la dirección IP privada asignada a la configuración IP principal del adaptador de red principal.
Azure App Service que se conectan a redes virtuales
¿Puedo usar aplicaciones web con una red virtual?
Sí. Puede implementar la característica Aplicaciones web de Azure App Service dentro de una red virtual mediante un entorno de Azure App Service. Seguidamente, puede:
- Conecte la parte trasera de sus aplicaciones a sus redes virtuales mediante la integración de redes virtuales.
- Bloquee el tráfico entrante a su aplicación utilizando puntos finales de servicio.
Para más información, consulte los siguientes artículos.
- Características de redes de App Service
- Uso de una instancia de App Service Environment
- Integración de su aplicación con una instancia de Azure Virtual Network
- Configuración de las restricciones de acceso de Azure App Service
¿Puedo implementar Azure Cloud Services con roles web y de trabajo (PaaS) en una red virtual?
Sí. Puede (opcionalmente) implementar instancias de roles de Cloud Services en redes virtuales. Para ello, especifique el nombre de la red virtual y las asignaciones de roles/subredes en la sección de configuración de red de la configuración del servicio. No es necesario actualizar ninguno de los archivos binarios.
¿Puedo 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.
¿Existe una lista completa de los servicios de Azure desde los que puedo implementar recursos en una red virtual?
Sí. Para más información, consulte Implementación de servicios de Azure dedicados en las redes virtuales.
¿Cómo puedo restringir el acceso a los recursos de Azure PaaS 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 redes virtuales mediante el uso de puntos de conexión de servicios de red virtual o Azure Private Link. Para obtener más información, consulte Puntos de conexión de servicios de red virtual y ¿Qué es Azure Private Link?.
¿Puedo mover mis servicios dentro y fuera de las redes virtuales?
No. No se pueden mover servicios dentro y fuera de redes virtuales. Para mover un recurso a otra red virtual, debe eliminarlo y volver a implementarlo.
Seguridad
¿Cuál es el modelo de seguridad de las redes virtuales?
Las redes virtuales están aisladas entre sí y de otros servicios alojados en la infraestructura de Azure. Una red virtual es un límite de confianza.
¿Puedo restringir el flujo de tráfico entrante o saliente a los recursos que están conectados a una red virtual?
Sí. Puede aplicar grupos de seguridad de red a subredes individuales dentro de una red virtual, a tarjetas NIC conectadas a una red virtual, o a ambas.
¿Puedo implementar un firewall entre recursos que están conectados a una red virtual?
Sí. Puede implementar un dispositivo virtual de red con firewall de varios proveedores a través de Azure Marketplace.
¿Hay información disponible sobre cómo proteger las redes virtuales?
Sí. Consulte Descripción general de la seguridad de red de Azure.
¿Las redes virtuales almacenan datos de los clientes?
No. Las redes virtuales no almacenan ningún dato de los clientes.
¿Puedo establecer la propiedad FlowTimeoutInMinutes para toda una suscripción?
No. Debe configurar la propiedad FlowTimeoutInMinutes en la red virtual. El siguiente código puede ayudarle a configurar esta propiedad automáticamente para suscripciones más grandes:
$Allvnet = Get-AzVirtualNetwork
$time = 4 #The value should be from 4 to 30 minutes (inclusive) to enable tracking, or null to disable tracking.
ForEach ($vnet in $Allvnet)
{
$vnet.FlowTimeoutInMinutes = $time
$vnet | Set-AzVirtualNetwork
}
API, esquemas y herramientas
¿Puedo administrar redes virtuales desde el código?
Sí. Puede utilizar las API REST para redes virtuales en los modelos de implementación Azure Resource Manager y clásico.
¿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 Azure Resource Manager y clásico.
- PowerShell para administrar redes virtuales implementadas a través del modelo de implementación de Azure Resource Manager.
- La CLI de Azure o la CLI clásica de Azure para implementar y administrar redes virtuales implementadas a través de los modelos de implementación Azure Resource Manager y clásico.
Emparejamiento de redes virtuales de Azure
¿Qué es el emparejamiento de redes virtuales?
El emparejamiento de red virtual permite conectar redes virtuales. Una conexión de emparejamiento entre redes virtuales le permite enrutar el tráfico entre ellas de forma privada a través de direcciones IPv4.
Las máquinas virtuales en redes virtuales 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 (lo que también se conoce como emparejamiento de redes virtuales globales).
También puede crear conexiones de emparejamiento de redes virtuales entre suscripciones de Azure.
¿Puedo crear una conexión de emparejamiento con una red virtual en otra región?
Sí. El emparejamiento de redes virtuales globales le permite emparejar redes virtuales en diferentes regiones. El intercambio de tráfico entre redes virtuales globales está disponible en todas las regiones públicas de Azure, las regiones de nube de China y las regiones de nube gubernamentales. No se puede establecer un emparejamiento global desde las regiones públicas de Azure a las regiones de nube nacionales.
¿Cuáles son las limitaciones relacionadas con el emparejamiento de redes virtuales globales y los equilibradores de carga?
Si las dos redes virtuales de dos regiones están emparejadas a través del emparejamiento de redes virtuales globales, no se puede conectar a los recursos que se encuentran detrás de un equilibrador de carga básico a través de la IP frontal del equilibrador de carga. Esta restricción no existe para un equilibrador de carga estándar.
Los siguientes recursos pueden utilizar equilibradores de carga básicos, lo que significa que no se puede acceder a ellos a través de la IP frontal de un equilibrador de carga mediante el emparejamiento de redes virtuales globales. Sin embargo, puede utilizar el emparejamiento de redes virtuales globales para acceder a los recursos directamente a través de sus direcciones IP de red virtual privada, si está permitido.
- VMs detrás de equilibradores de carga básicos
- Conjuntos de escalado de máquinas virtuales con equilibradores de carga básicos
- Caché de Azure para Redis
- Azure Application Gateway v1
- Azure Service Fabric
- Azure API Management stv1
- Microsoft Entra Domain Services
- Azure Logic Apps
- HDInsight de Azure
- Azure Batch
- App Service Environment v1 y v2
Puede conectarse a estos recursos a través de Azure ExpressRoute o conexiones de red a red mediante puertas de enlace de red virtual.
¿Puedo habilitar el emparejamiento de redes virtuales si mis redes virtuales pertenecen a suscripciones dentro de diferentes inquilinos de Microsoft Entra?
Sí. Es posible establecer un emparejamiento de redes virtuales (ya sea local o global) si sus suscripciones pertenecen a diferentes inquilinos de Microsoft Entra. Puede hacerlo a través de Azure Portal, PowerShello laCLI de Azure.
Mi conexión de emparejamiento de redes virtuales se encuentra en estado Iniciado. ¿Por qué no puedo conectarme?
Si su conexión de emparejamiento se encuentra en estado Iniciado, solo ha creado un vínculo. Debe crear un vínculo bidireccional para establecer una conexión correcta.
Por ejemplo, para crear un nodo del mismo nivel de VNetA con VNetB, debe crear un vínculo de VNetA a VNetB y de VNetB a VNetA. Al crear ambos vínculos, el estado cambia a Conectado.
Mi conexión de emparejamiento de red virtual se encuentra en estado Desconectado. ¿Por qué no puedo crear una conexión de emparejamiento?
Si la conexión de emparejamiento de redes virtuales se encuentra en estado Desconectado, significa que uno de los vínculos que ha creado se ha eliminado. Para restablecer una conexión de emparejamiento, debe eliminar el vínculo restante y volver a crear ambos.
¿Puedo conectar mi red virtual con una red virtual que se encuentra en una suscripción diferente?
Sí. Puede conectar redes virtuales entre suscripciones y regiones.
¿Puedo emparejar dos redes virtuales que tengan rangos de direcciones coincidentes o superpuestos?
No. No se puede habilitar el emparejamiento de redes virtuales si los espacios de direcciones se superponen.
¿Puedo emparejar una red virtual con dos redes virtuales con la opción Usar puerta de enlace remota habilitada en ambos emparejamientos?
No. Puede habilitar la opción Usar puerta de enlace remota solo en un emparejamiento con una de las redes virtuales.
¿Puedo mover una red virtual que tenga una conexión de emparejamiento a otra red virtual?
No. No se puede mover una red virtual que tenga una conexión de emparejamiento a otra red virtual. Debe eliminar la conexión de emparejamiento antes de mover la red virtual.
¿Cuál es el coste de los vínculos de emparejamiento de redes virtuales?
No hay ningún cargo por crear una conexión de emparejamiento de redes virtuales. Se cobra la transferencia de datos a través de conexiones de emparejamiento. Para obtener más información, consulte la página de precios de Azure Virtual Network.
¿Está cifrado el tráfico de emparejamiento de red virtual?
Cuando el tráfico de Azure se mueve entre centros de datos (fuera de los límites físicos no controlados por Microsoft o en nombre de Microsoft), el hardware de red subyacente utiliza el cifrado de la capa de vínculo de datos MACsec. Este cifrado es aplicable al tráfico de emparejamiento de redes virtuales.
¿Por qué mi conexión de emparejamiento está en estado Desconectado?
Las conexiones de emparejamiento de redes virtuales pasan al estado Desconectado cuando se elimina un vínculo de emparejamiento de redes virtuales. Debe eliminar ambos vínculos para restablecer una conexión de emparejamiento satisfactoria.
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. Debe emparejar manualmente VNetA con VNetC.
¿Hay alguna limitación de ancho de banda para las conexiones de emparejamiento?
No. El emparejamiento de redes virtuales, ya sea local o global, no impone ninguna restricción de ancho de banda. Bandwidtho está limitado por la máquina virtual o el recurso informático.
¿Cómo puedo solucionar problemas con el emparejamiento de redes virtuales?
Pruebe la guía de solución de problemas.
TAP de red virtual
¿Qué regiones de Azure están disponibles para TAP de red virtual?
La versión preliminar del punto de acceso de terminal de red virtual (TAP) está disponible en todas las regiones de Azure. Debe implementar los adaptadores de red supervisados, el recurso TAP de red virtual y el recopilador o la solución de análisis en la misma región.
¿La red virtual TAP admite alguna función de filtrado en los paquetes duplicados?
Las funcionalidades de filtrado no son compatibles con la versión preliminar de TAP de la red virtual. Cuando se agrega una configuración TAP a un adaptador de red, se transmite una copia completa de todo el tráfico de entrada y salida del adaptador de red al destino TAP.
¿Puedo agregar varias configuraciones TAP a un adaptador de red supervisado?
Un adaptador de red supervisado solo puede tener una configuración 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 de adaptadores de red supervisados en más de una red virtual?
Sí. Puede utilizar el mismo recurso TAP de red virtual para agregar el tráfico duplicado de los adaptadores de red supervisados en redes virtuales emparejadas de la misma suscripción o de una suscripción diferente.
El recurso TAP de red virtual y el equilibrador de carga de destino o el adaptador de red de destino deben estar en la misma suscripción. Todas las suscripciones deben estar bajo el mismo inquilino de Microsoft Entra.
¿Hay alguna consideración de rendimiento en el tráfico de producción si habilito una configuración TAP de red virtual en un adaptador de red?
TAP de red virtual está en versión preliminar. Durante la versión preliminar, no existe ningún acuerdo de nivel de servicio. No se debe utilizar esta función para cargas de trabajo de producción.
Cuando habilita un adaptador de red de máquina virtual con una configuración TAP, los mismos recursos del host de Azure asignados a la máquina virtual para enviar el tráfico de producción se utilizan para realizar la función de duplicación y enviar los paquetes duplicados. 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 admite la conexión en red acelerada para Linux o Windows con la red virtual TAP?
Puede agregar una configuración TAP en un adaptador de red conectado a una máquina virtual habilitada con redes aceleradas para Linux o Windows. Sin embargo, agregar la configuración TAP afectará el rendimiento y la latencia de la máquina virtual, ya que la red acelerada de Azure actualmente no admite la descarga para duplicar el tráfico.
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:
- Active los puntos de conexión de servicio para el servicio de Azure.
- Configure listas de control de acceso (ACL) de red virtual en el servicio Azure.
El primer paso es una operación del lado de la red, y el segundo paso es una operación del lado de los recursos del servicio. El mismo administrador o diferentes administradores pueden realizar los pasos, en función de los permisos de control de acceso basado en roles (RBAC) de Azure concedidos al rol de administrador.
Le recomendamos que active los puntos de conexión de servicio para su red virtual antes de configurar las ACL de red virtual en el lado del servicio de Azure. Para configurar los puntos de conexión del servicio de red virtual, debe seguir los pasos de la secuencia anterior.
Nota:
Debe completar ambas operaciones anteriores antes de poder limitar el acceso al servicio Azure a la red virtual y la subred permitidas. El simple hecho de activar los puntos de conexión del servicio Azure en el lado de la red no le proporciona un acceso limitado. También debe configurar ACL de red virtual en el lado del servicio Azure.
Ciertos servicios (como Azure SQL y Azure Cosmos DB) permiten excepciones a la secuencia anterior mediante el indicador IgnoreMissingVnetServiceEndpoint. Después de establecer el indicador en True, puede configurar las ACL de red virtual en el lado del servicio de Azure antes de activar los puntos de conexión del servicio en el lado de la red. Los servicios de Azure proporcionan esta bandera para ayudar a los clientes en los casos en que se configuran firewalls IP específicos en los servicios de Azure.
Activar los puntos de conexión del servicio en el lado de la red puede 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. Configurar las ACL de red virtual en el lado del servicio Azure antes de activar los puntos de conexión del servicio en el lado de la red puede ayudar a evitar una caída de la conectividad.
Nota:
Si habilita un punto de conexión de servicio en servicios específicos como "Microsoft.AzureActiveDirectory", puede ver conexiones con direcciones IPv6 en los logs de inicio de sesión. Microsoft usa un intervalo privado IPv6 interno para este tipo de conexión.
¿Todos los servicios de Azure residen en la red virtual de Azure que proporciona el cliente? ¿Cómo funciona un punto de conexión de servicio de red virtual con los servicios de Azure?
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 multiinquilino a los que se puede acceder a través de direcciones IP públicas. Para más información, consulte Implementación de servicios de Azure dedicados en redes virtuales.
Al activar los puntos de conexión de servicio de 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 a una red virtual y subred permitidas.
¿Cómo proporcionan seguridad los puntos de conexión de los servicios de red virtual?
Los puntos de conexión del servicio de red virtual limitan el acceso del servicio Azure a la red virtual y la subred permitidas. De esta manera, proporcionan seguridad a nivel de red y aislamiento del tráfico del servicio Azure.
Todo el tráfico que utiliza puntos de conexión de servicios de red virtual fluye a través de la red troncal de Microsoft para proporcionar otra capa de aislamiento de la Internet pública. Los clientes también pueden optar por eliminar por completo el acceso público a Internet a los recursos del servicio Azure y permitir solo el tráfico procedente de su red virtual mediante una combinación de firewall IP y ACL de red virtual. Eliminar el acceso a Internet ayuda a proteger los recursos del servicio Azure contra el acceso no autorizado.
¿Qué protege el punto de conexión del servicio de red virtual: los recursos de red virtual o los recursos del servicio Azure?
Los puntos de conexión del servicio de red virtual ayudan a proteger los recursos del servicio Azure. Los recursos de la red virtual están protegidos mediante grupos de seguridad de red.
¿Hay algún coste por utilizar los puntos de conexión del servicio de red virtual?
No. No hay ningún coste adicional por utilizar los puntos de conexión del servicio de red virtual.
¿Puedo activar los puntos de conexión del servicio de red virtual y configurar las ACL de red virtual si la red virtual y los recursos del servicio Azure pertenecen a suscripciones diferentes?
Sí, es posible. Las redes virtuales y los recursos del servicio Azure pueden estar en la misma suscripción o en suscripciones diferentes. El único requisito es que tanto la red virtual como los recursos del servicio Azure deben estar bajo el mismo inquilino de Microsoft Entra.
¿Puedo activar los puntos de conexión del servicio de red virtual y configurar las ACL de red virtual si la red virtual y los recursos del servicio Azure pertenecen a diferentes inquilinos de Microsoft Entra?
Sí, es posible cuando se utilizan puntos de conexión de servicio para Azure Storage y Azure Key Vault. Para otros servicios, los puntos de conexión de servicios de red virtual y las ACL de red virtual no son compatibles entre inquilinos de Microsoft Entra.
¿Puede la dirección IP de un dispositivo local conectado a través de una puerta de enlace de red virtual (VPN) de Azure o una puerta de enlace ExpressRoute acceder a los servicios PaaS de Azure a través de puntos de conexión de servicios de red virtual?
De forma predeterminada, los recursos de servicio de Azure protegidos para las redes virtuales no son accesibles desde redes locales. Si desea permitir el tráfico desde las instalaciones locales, también debe permitir las direcciones IP públicas (normalmente NAT) desde las instalaciones locales o ExpressRoute. Puede agregar estas direcciones IP a través de la configuración del firewall IP para los recursos del servicio Azure.
Como alternativa, puede implementar puntos de conexión privados para los servicios admitidos.
¿Puedo utilizar puntos de conexión de servicios de red virtual para proteger los servicios de Azure en varias subredes dentro de una red virtual o en varias redes virtuales?
Para proteger los servicios de Azure en varias subredes dentro de una red virtual o en varias redes virtuales, habilite los puntos de conexión de servicio en el lado de la red en cada una de las subredes de forma independiente. A continuación, proteja los recursos del servicio Azure en todas las subredes configurando las ACL de red virtual adecuadas en el lado del servicio 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. A continuación, puede aplicar puntos de conexión de servicio a la subred donde se implementa el dispositivo virtual de red y proteger los recursos del servicio Azure solo para esta subred mediante ACL de red virtual.
Este escenario también puede resultar útil si desea restringir el acceso al servicio Azure desde su red virtual solo a recursos Azure específicos mediante el filtrado de dispositivos virtuales de red. Para obtener más información, consulte Implementación de NVA de alta disponibilidad.
¿Qué ocurre cuando alguien accede a una cuenta de servicio de Azure que tiene habilitada una ACL de red virtual desde fuera de la red virtual?
El servicio devuelve un error HTTP 403 o HTTP 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 acceder a los servicios de Azure en otra región a través de los puntos de conexión del servicio de red virtual. Por ejemplo, si una cuenta de Azure Cosmos DB se encuentra en la región Oeste de EE. UU. o Este de EE. UU. y las redes virtuales están en varias regiones, las redes virtuales pueden acceder a Azure Cosmos DB.
Azure SQL es una excepción y es regional por naturaleza. Tanto la red virtual como el servicio Azure deben estar en la misma región.
¿Puede un servicio de Azure tener tanto una ACL de red virtual como un firewall IP?
Sí. Una ACL de red virtual y un firewall IP pueden coexistir. Las características se complementan entre sí para garantizar el aislamiento y la seguridad.
¿Qué ocurre si elimina una red virtual o una subred que tiene puntos de conexión de servicio habilitados para los servicios de Azure?
La eliminación de redes virtuales y la eliminación de subredes son operaciones independientes. Se admiten incluso cuando se activan los puntos de conexión de servicio para los servicios de Azure.
Si configura ACL de red virtual para servicios de Azure, la información de ACL asociada a esos servicios de Azure se deshabilita cuando elimina una red virtual o subred que tiene habilitados los puntos de conexión del servicio de red virtual.
¿Qué ocurre si elimino una cuenta de servicio de Azure que tiene habilitado un punto de conexión de servicio de red virtual?
La eliminación de una cuenta de servicio de Azure es una operación independiente. Es compatible incluso si ha activado el punto de conexión del servicio en el lado de la red y ha configurado ACL de red virtual en el lado del servicio Azure.
¿Qué ocurre con la dirección IP de origen de un recurso (como una máquina virtual en una subred) que tiene habilitados los puntos de conexión del servicio de red virtual?
Cuando se activan los puntos de conexión del servicio de red virtual, las direcciones IP de origen de los recursos de la subred de la red virtual pasan de utilizar direcciones IPv4 públicas a utilizar direcciones IP privadas de la red virtual de Azure para el tráfico hacia los servicios de Azure. Este cambio puede provocar que fallen determinados cortafuegos IP que están configurados con una dirección IPv4 pública anterior en los servicios de Azure.
¿La ruta del punto de conexión de servicio siempre tiene prioridad?
Los puntos de conexión del servicio agregan una ruta del sistema que tiene prioridad sobre las rutas del Protocolo de puerta de enlace fronteriza (BGP) y proporciona un enrutamiento óptimo para el tráfico del punto de conexión del 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 obtener más información sobre cómo Azure selecciona una ruta, consulte Enrutamiento del tráfico de red virtual.
¿Funcionan los puntos de conexión de servicio con ICMP?
No. El tráfico ICMP procedente de una subred con puntos de conexión de servicio habilitados no tomará la ruta del túnel de servicio hacia el punto de conexión deseado. Los puntos de conexión del servicio solo controlan el tráfico TCP. Si desea comprobar la latencia o la conectividad a un punto de conexión a través de puntos de conexión de servicio, herramientas como ping y tracert no mostrarán la ruta real que seguirán los recursos dentro de la subred.
¿Cómo funcionan los NSG en una subred con los puntos de conexión de servicio?
Para alcanzar el servicio de Azure, los NSG deben permitir la conectividad de salida. Si sus NSG están abiertos a todo el tráfico saliente de Internet, el tráfico del punto de conexión del servicio debería funcionar. También puede limitar el tráfico saliente solo a direcciones IP de servicio utilizando las etiquetas de servicio.
¿Qué permisos necesito para configurar los puntos de conexión de servicio?
Puede configurar los puntos conexión del servicio en una red virtual de forma independiente si tiene acceso de escritura a esa red.
Para asegurar los recursos del servicio Azure a una red virtual, debe tener permiso Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action para las subredes que está agregando. Este permiso está incluido de forma predeterminada en la función de administrador de servicios integrada y se puede modificar mediante la creación de funciones personalizadas.
Para obtener más información sobre las funciones integradas y la asignación de permisos específicos a funciones personalizadas, consulte Roles personalizados de Azure.
¿Puedo filtrar el tráfico de red virtual a los servicios de Azure a través de puntos de conexión de servicio?
Puede utilizar directivas de puntos de conexión de servicios de red virtual para filtrar el tráfico de red virtual a los servicios de Azure, permitiendo solo recursos de servicios de Azure específicos a través de los puntos de conexión de servicios. 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 obtener más información, consulte Directivas de puntos de conexión de servicios de red virtual para Azure Storage.
¿Microsoft Entra ID admite puntos de conexión de servicios de red virtual?
Microsoft Entra id. no admite puntos de conexión de servicio de forma nativa. Para obtener una lista completa de los servicios de Azure que admiten puntos de conexión de servicios de red virtual, consulte Puntos de conexión de servicios de red virtual.
En esa lista, la etiqueta Microsoft.AzureActiveDirectory que aparece en los servicios que admiten puntos de conexión de servicio se utiliza para admitir puntos de conexión de servicio a Azure Data Lake Storage Gen1. La integración de redes virtuales para Azure Data Lake Storage Gen1 utiliza la seguridad del punto de conexión del servicio de red virtual entre su red virtual y Microsoft Entra ID para generar reclamaciones 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.
¿Existe algún límite en cuanto al número de puntos de conexión de servicio que puedo configurar desde mi red virtual?
No hay límite en el número total de puntos de conexión de servicio en una red virtual. En el caso de un recurso de servicio de Azure (como una cuenta de Azure Storage), los servicios pueden aplicar límites al número de subredes que se utilizan para proteger el recurso. En la tabla siguiente se muestran algunos límites de ejemplo:
| Servicio de Azure | Límites en las reglas de red virtual |
|---|---|
| Azure Storage | 200 |
| Azure SQL | 128 |
| Azure Synapse Analytics | 128 |
| Azure Key Vault | 200 |
| Azure Cosmos DB (la base de datos de Azure Cosmos) | 64 |
| Azure Event Hubs | 128 |
| Azure Service Bus (bus de servicios de Azure) | 128 |
Nota:
Los límites están sujetos a cambios a discreción de los servicios de Azure. Consulte la documentación del servicio correspondiente para obtener más detalles.
Migración de recursos de red clásicos a Azure Resource Manager
¿Qué es Azure Service Manager y qué significa el término "clásico"?
Azure Service Manager es el antiguo modelo de implementación de Azure que se encargaba de crear, administrar y eliminar recursos. La palabra clásico en un servicio de red hace referencia a los recursos administrados por el modelo Azure Service Manager. Para obtener más información, consulte la comparación de modelos de implementación.
¿Qué es Azure Resource Manager?
Azure Resource Manager es el último modelo de implementación y administración de Azure, responsable de crear, administrar y eliminar recursos en su suscripción de Azure. Para obtener más información, consulte Qué es Azure Resource Manager?.
¿Se puede revertir la migración después de que los recursos se hayan confirmado en Resource Manager?
Puede cancelar la migración siempre que los recursos se encuentren aún en estado preparado. No se admite volver al modelo de implementación anterior después de migrar correctamente los recursos mediante la operación de confirmación.
¿Se puede revertir la migración si no se ha podido realizar la operación de confirmación?
No se puede revertir una migración si no se ha podido realizar la operación de confirmación. Todas las operaciones de migración, incluida la operación de confirmación, no se pueden modificar una vez iniciadas. Le recomendamos que vuelva a intentar la operación después de un breve periodo de tiempo. Si la operación sigue sin funcionar, envíe una solicitud de soporte técnico.
¿Puedo validar mi suscripción o mis recursos para ver si son aptos para la migración?
Sí. El primer paso para preparar la migración es validar que los recursos se pueden migrar. Si la validación falla, recibirá mensajes con todas las razones por las que no se puede completar la migración.
¿Se migran los recursos de Azure Application Gateway como parte de la migración de la red virtual desde Classic a Azure Resource Manager?
Los recursos de Azure Application Gateway no se migran automáticamente como parte del proceso de migración de la red virtual. Si hay uno en la red virtual, la migración no se realiza correctamente. Para migrar un recurso de Azure Application Gateway a Azure Resource Manager, debe eliminar y volver a crear la instancia de Azure Application Gateway una vez completada la migración.
¿Se migran los recursos de la puerta de enlace VPN como parte de la migración de la red virtual desde Classic a Azure Resource Manager?
Los recursos de Azure VPN Gateway se migran como parte del proceso de migración de la red virtual. La migración se completa en una red virtual cada vez, sin más requisitos. Los pasos de migración son los mismos que para migrar una red virtual sin una VPN gateway
¿Existe alguna interrupción del servicio asociada a la migración de las VPN gateways clásicas a Azure Resource Manager?
No experimentará ninguna interrupción del servicio con su conexión VPN cuando migre a Azure Resource Manager. Las cargas de trabajo existentes seguirán funcionando con conectividad local completa durante la migración.
¿Tengo que volver a configurar mi dispositivo local después de migrar la VPN gateway a Azure Resource Manager?
La dirección IP pública asociada a la VPN gateway sigue siendo la misma después de la migración. No es necesario volver a configurar el enrutador local.
¿Cuáles son los escenarios compatibles para la migración de la VPN gateway desde Classic a Azure Resource Manager?
La migración desde Classic a Azure Resource Manager cubre la mayoría de los escenarios comunes de conectividad VPN. Los escenarios compatibles incluyen:
Conectividad punto a sitio.
Conectividad de sitio a sitio con una VPN gateway conectada a una ubicación local.
Conectividad de red a red entre dos redes virtuales que utilizan VPN gateways.
Varias redes virtuales conectadas a la misma ubicación local.
Conectividad en múltiples sitios.
Redes virtuales con túnel forzado habilitado.
¿Qué escenarios no son compatibles con la migración de la VPN gateway desde Classic a Azure Resource Manager?
Entre los escenarios que no se admiten se incluyen:
Una red virtual con una ExpressRoute gateway y una VPN gateway.
Una red virtual con una ExpressRoute gateway conectada a un circuito en una suscripción diferente.
Escenarios de tránsito donde las extensiones de máquina virtual están conectadas a servidores locales.
¿Dónde puedo encontrar más información sobre la migración desde Classic a Azure Resource Manager?
Consulte Preguntas frecuentes sobre la migración desde Classic a Azure Resource Manager.
¿Puedo recuperar una dirección IP pública eliminada?
No. Una vez eliminada una dirección IP pública de Azure, no se puede recuperar. Para más información, consulte Visualización, modificación de la configuración o eliminación de una dirección IP pública.
¿Cómo puedo informar de un problema?
Puede publicar preguntas sobre los problemas de migración a la página Microsoft Q&A. Le recomendamos que publique todas sus preguntas en este foro. Si tiene un contrato de soporte técnico, también puede presentar una solicitud de soporte técnico.