Compartir vía

Preguntas más frecuentes (P+F) acerca de Azure Virtual Network

  • Artículo

Conceptos básicos

¿Qué es una red virtual?

Una red virtual es una representación de su propia red en la nube, según lo proporcionado por el servicio Azure Virtual Network. Una red virtual es un aislamiento lógico de la nube de Azure dedicado a su suscripción.

Puede usar 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 la infraestructura de TI local, para crear soluciones híbridas o entre locales.

Cada red virtual que cree 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 puede controlar la configuración del servidor DNS para las redes virtuales y la segmentación de la red virtual en subredes.

Use 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 crea una red virtual, los servicios y las máquinas virtuales (VMs) de la red virtual pueden comunicarse de manera directa y segura entre sí en la nube. Aun así, puede configurar conexiones de punto de conexión para las máquinas virtuales y los servicios que requieren la comunicación con Internet, como parte de la solución.

  • Amplíe de forma segura el centro de datos. Con las redes virtuales, puede crear VPN tradicionales de sitio a sitio (S2S) para ampliar de forma segura la capacidad del centro de datos. 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. Puede conectar de forma segura aplicaciones basadas en la nube a cualquier tipo de sistema local incluidos grandes sistemas y sistemas Unix.

¿Cómo comenzar?

Para comenzar, consulte Documentación de Azure 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.

¿Puedo realizar la optimización de WAN entre redes virtuales o entre una red virtual y mi centro de datos local?

Sí. A través de Azure Marketplace es posible implementar una aplicación virtual de red para optimización de la WAN de varios proveedores.

Configuración

¿Qué herramientas debo usar para crear una red virtual?

Puede emplear las siguientes herramientas para crear o configurar una red virtual:

¿Qué intervalos de direcciones puedo usar en mis redes virtuales?

Se recomienda usar los siguientes intervalos de direcciones, que se enumeran en RFC 1918. IETF ha reservado estos intervalos para espacios de direcciones privados y no enrutables.

  • 10.0.0.0 to 10.255.255.255 (10/8 prefijo)
  • 172.16.0.0 to 172.31.255.255 (172.16/12 prefijo)
  • 192.168.0.0 to 192.168.255.255 (192.168/16 prefijo)

También puede implementar el espacio de direcciones compartidas reservado en RFC 6598, que se trata como espacio de direcciones IP privadas en Azure:

  • 100.64.0.0 to 100.127.255.255 (100.64/10 prefijo)

Otros espacios de direcciones, incluidos todos los demás espacios de direcciones privados y no enrutables reconocidos por IETF, pueden funcionar, pero con efectos secundarios no deseados.

Además, no se pueden agregar siguientes intervalos 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 redes para obtener más información. 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 las cuatro primeras direcciones y las últimas direcciones, lo que hace un total de cinco direcciones IP, en 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: reservada por Azure para la puerta de enlace predeterminada.
  • 192.168.1.2, 192.168.1.3: Reservado 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 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 con una subred. Para más información sobre el enrutamiento en Azure, consulte personalizar enrutamiento.

¿Cuál es el comportamiento cuando se aplica tanto NSG como UDR en la subred?

En el caso del tráfico entrante, se procesan las reglas de entrada del grupo de seguridad de red (NSG). En el caso del tráfico saliente, las reglas de salida de NSG se procesan seguidas de las reglas UdR de ruta de usuario definido.

¿Cuál es el comportamiento al aplicar el NSG en la NIC y la subred para una VM?

Al aplicar NSG en un adaptador de red (NIC) y una subred para una máquina virtual:

  • Un NSG de nivel de subred, seguido de un NSG de nivel de NIC, se procesa para el tráfico entrante.
  • Un NSG de nivel de NIC, seguido de un NSG de nivel de subred, se procesa para el tráfico saliente.

¿Admite Virtual Network multidifusión o difusión?

No. No se admite difusión ni multidifusión.

¿Qué protocolos puedo usar en redes virtuales?

En las redes virtuales se pueden usar los protocolos TCP, UDP, ESP, AH e ICMP TCP/IP.

La unidifusión se admite en redes virtuales. 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. No puede usar el 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). Puerto de origen UDP 65330 reservado 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.

El servidor DHCP en Azure se marcó anteriormente como no viable, ya que el tráfico al puerto UDP/67 tenía un límite de velocidad 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 usar pings en las redes virtuales para comprobar la conectividad y solucionar problemas entre máquinas virtuales.

¿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 y cuando existan ambas condiciones:

  • El intervalo de direcciones de subred no forma parte de otra subred.
  • Hay 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 una red virtual después de crearla?

Sí. Puede agregar, quitar y modificar los bloques CIDR que usa una red virtual.

Si estoy ejecutando mis servicios en una red virtual, ¿puedo conectarme a Internet?

Sí. Todos los servicios implementados dentro de una red virtual pueden conectarse a Internet. Para más información sobre las conexiones salientes de internet en Azure, consulte Traducción de direcciones de red de origen (SNAT) para conexiones salientes.

Si quiere establecer una conexión entrante a un recurso implementado mediante Azure Resource Manager, el recurso debe tener asignada una dirección IP pública. Para obtener más información, consulte Creación, modificación o eliminación de una dirección IP pública de Azure.

Cada servicio en la nube implementado en Azure tiene asignada una IP direccionable (VIP) de forma pública. Para permitir que estos servicios acepten conexiones de Internet, se definen puntos de conexión de entrada para plataforma como servicio (PaaS) roles y puntos de conexión en las máquinas virtuales.

¿Las redes virtuales admiten IPv6?

Sí. Las redes virtuales pueden ser solo IPv4 o doble pila (IPv4 + IPv6). Pata obtener detalles, consulte ¿Qué es IPv6 para Azure Virtual Network?.

¿Puede una red virtual abarcar varias regiones?

No. Una red virtual está limitada a una única región. Pero una red virtual abarca zonas de disponibilidad. Para más información sobre availability zones, consulte ¿Qué son las regiones y availability zones de Azure?.

Puede conectar redes virtuales de diferentes regiones al usar el emparejamiento de redes virtuales. Para más información, consulte Emparejamiento de redes virtuales.

Puedo conectar una red virtual con otra red virtual en Azure?

Sí. Puede conectar una red virtual a otra mediante:

Resolución de nombres (DNS)

¿Qué opciones de DNS hay para redes virtuales?

Use la tabla de decisiones de Resolución de nombres para los recursos de redes virtuales de Azure para guiarle a través de las opciones de DNS disponibles.

¿Puedo especificar servidores DNS para una red virtual?

Sí. Puede especificar direcciones IP para servidor DNS en la configuración de la red virtual. La configuración se aplica al servidor DNS predeterminado o servidores en todas las máquinas virtuales 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, debe realizar una renovación de la concesión DHCP en todas las máquinas virtuales afectadas en la red virtual. La nueva configuración de DNS surte efecto después de la renovación de la concesión. Para las máquinas virtuales que ejecutan Windows, puede renovar la concesión escribiendo ipconfig /renew directamente en la máquina virtual. Para otros tipos de sistema operativo, consulte la documentación para la renovación de concesión DHCP.

¿Qué es DNS proporcionado por Azure? ¿Funciona con las redes virtuales?

Un DNS proporcionado por Azure es un servicio DNS multiempresa 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 máquinas virtuales e instancias de rol en el mismo servicio en la nube.
  • Por dominio completo principal (FQDN) para máquinas virtuales e instancias de rol en la misma red virtual.

Para más información sobre la resolución de DNS, consulte Resolución de nombres para recursos de redes virtuales de Azure.

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 la configuración de DNS para cada máquina virtual o servicio en la nube?

Sí. Puede configurar los servidores DNS para cada máquina virtual o servicio en la nube para invalidar 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 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 los adaptadores de red (NICs) conectadas a una máquina virtual que está implementada a través del modelo de implementación de Resource Manager deben estar conectadas a una red virtual. Opcionalmente, puede conectar máquinas virtuales implementadas mediante el modelo de implementación clásica a una red virtual.

¿Cuáles son los tipos de direcciones IP que se pueden asignar a máquinas virtuales?

  • Privado: asignado a cada NIC dentro de cada máquina virtual, a través del método estático o 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 ha implementado un recurso con el modelo de implementación clásica o de Resource Manager:

    • Resource Manager: una dirección IP privada asignada a través del 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ásico: las direcciones IP privadas asignadas a través del método dinámico pueden cambiar cuando se reinicia una máquina virtual (clásico) después de estar en 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 mediante el método estático.

  • Público: opcionalmente, se puede asignar a NIC conectadas a máquinas virtuales implementadas a través del modelo de implementación de Resource Manager. Puede asignar la dirección mediante el método de asignación estático o dinámico.

    Todas las máquinas virtuales y las instancias de rol de Azure Cloud Services implementadas a través del modelo de implementación clásica existen en 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 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 de nivel de instancia 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 asignará 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 existente 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 implementó la máquina virtual mediante Resource Manager, las direcciones IP no pueden cambiar, independientemente de si asignó las direcciones mediante el método de asignación estático o dinámico. Si implementó la máquina virtual mediante el modelo de implementación clásica, las direcciones IP dinámicas pueden cambiar al iniciar una máquina virtual que se encontraba en el 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 virtual.

¿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 Asignación de varias direcciones IP a máquinas virtuales.

Si la dirección IP asignada a una NIC de Azure que está 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 subred 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. No se puede configurar estáticamente una dirección MAC.

¿Sigue siendo la dirección MAC la misma en mi máquina virtual luego 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.

Anteriormente, la dirección MAC se publicó si detuvo (desasignó) la máquina virtual. Pero ahora, la máquina virtual conserva la dirección MAC cuando está 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.

¿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

¿Puedo usar Web Apps con una red virtual?

Sí. Puede implementar la característica de Web Apps de Azure App Service dentro de una red virtual mediante un App Service Environment. Luego, puede:

  • Conecte el back-end de las aplicaciones a las redes virtuales mediante la integración de red virtual.
  • Bloquee el tráfico entrante a la aplicación mediante puntos de conexión de servicio.

Para más información, consulte los siguientes artículos.

¿Puedo implementar servicios en la nube con 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 Implementación de servicios de Azure dedicados en las redes virtuales.

¿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 las redes virtuales mediante puntos de conexión de servicio de red virtual o Azure Private Link. Para obtener más información, consulte Puntos de conexión de servicio 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 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 red virtual es un límite de confianza.

¿Puedo restringir el flujo de tráfico entrante o saliente a los recursos conectados a una 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.

¿Puedo implementar un firewall entre 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 sobre la protección de redes virtuales?

Sí. Consulte Información general sobre Azure Network Security.

¿Las redes virtuales almacenan datos de clientes?

No. Las redes virtuales no almacenan ningún dato de cliente.

¿Puedo establecer la propiedad FlowTimeoutInMinutes para toda una suscripción?

No. Debe establecer la propiedad FlowTimeoutInMinutes en la red virtual. El código siguiente puede ayudarle a establecer esta propiedad automáticamente para suscripciones de mayor tamaño:

$Allvnet = Get-AzVirtualNetwork
$time = 4 #The value should be 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 código?

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.
  • El Azure CLI o clásico CLI de Azure para implementar y administrar redes virtuales implementadas a través de Resource Manager yclásicos modelos de implementación.

Emparejamiento de redes virtuales de Azure

¿Qué es el emparejamiento de red virtual?

El emparejamiento de red virtual permite conectar redes virtuales. Una conexión de emparejamiento 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 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 (también conocidas como emparejamiento de red virtual global).

También puede crear conexiones de emparejamiento de redes virtuales entre suscripciones de Azure.

¿Puedo crear una conexión de emparejamiento a una red virtual en otra región?

Sí. El emparejamiento de redes virtuales globales permite emparejar redes virtuales en distintas regiones. El emparejamiento de redes virtuales globales 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.

Si las dos redes virtuales de dos regiones están emparejadas a través del emparejamiento de red virtual global, no se puede conectar a los recursos que están detrás de un equilibrador de carga básico a través de la dirección IP de front-end del equilibrador de carga. Esta restricción no existe para un equilibrador de carga estándar.

Los siguientes recursos pueden usar equilibradores de carga básicos, lo que significa que no se puede acceder a ellos a través de la dirección IP de front-end de un equilibrador de carga a través del emparejamiento de red virtual global. Pero puede usar el emparejamiento de red virtual global para acceder a los recursos directamente a través de sus direcciones IP de red virtual privadas, si se permite.

  • Máquinas virtuales detrás de los equilibradores de carga básicos
  • Conjuntos de escalado de máquinas virtuales con equilibradores de carga básicos
  • Azure Cache for Redis
  • Azure Application Gateway v1
  • Azure Service Fabric
  • Azure API Management stv1
  • Servicios de dominio de Microsoft Entra
  • 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 a través de puertas de enlace de red virtual.

¿Puedo habilitar el emparejamiento de redes virtuales si mis redes virtuales pertenecen a suscripciones de diferentes inquilinos de Microsoft Entra?

Sí. Es posible establecer el emparejamiento de redes virtuales (ya sea local o global) si las suscripciones pertenecen a distintos inquilinos de Microsoft Entra. Para ello, puede usar Azure Portal, PowerShell, o el CLI de Azure.

Mi conexión de emparejamiento de red virtual se encuentra en estado Iniciado. ¿Por qué no puedo conectarme?

Si la conexión de emparejamiento está en estado Iniciado, ha creado un solo vínculo. Debe crear un vínculo bidireccional para establecer una conexión correcta.

Por ejemplo, para emparejar VNetA a VNetB, debe crearse un vínculo de VNetA a VNetB y de VNetB a VNetA. La creación de ambos vínculos cambia el estado 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 red virtual está en estado Desconectado, se ha eliminado uno de los vínculos creados. Para volver a establecer una conexión de emparejamiento, debe eliminar el vínculo restante y volver a crear ambos.

¿Puedo emparejar mi red virtual con una red virtual que está en una suscripción diferente?

Sí. Puede emparejar redes virtuales entre suscripciones y através de regiones.

¿Puedo emparejar dos redes virtuales que tengan intervalos 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 a dos redes virtuales con la opción Usar puerta de enlace remota habilitada en ambos emparejamientos?

No. Solo puede habilitar la opción Usar puerta de enlace remota en un emparejamiento a 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.

No hay ningún cargo por crear una conexión de emparejamiento de red virtual. Se cobra la transferencia de datos a través de conexiones de emparejamiento. Para obtener más información, consulte la página sobre los precios de la red virtual de Azure.

¿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), se usa el cifrado de capa de vínculo de datos MACsec en el hardware de red subyacente. Este cifrado es aplicable al tráfico de emparejamiento de red virtual.

¿Por qué mi conexión de emparejamiento está en estado Desconectado?

Las conexiones de emparejamiento de red virtual entran en 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. 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. El ancho de banda está limitado solo por el recurso de proceso o de máquina virtual.

¿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 del terminal de red virtual (TAP) está disponible en todas las regiones de Azure. Se deben implementar los adaptadores de red supervisados, el recurso TAP de la red virtual y el recopilador o solución de análisis 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 agrega una configuración de TAP a un adaptador de red, se transmite una copia en profundidad de todo el tráfico de entrada y salida del adaptador de red al destino de TAP.

¿Puedo agregar varias configuraciones tap a un adaptador de red supervisado?

Un adaptador 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 los adaptadores 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 los adaptadores 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 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.

¿Existen consideraciones de rendimiento en el tráfico de producción si se habilita una configuración de TAP de red virtual en un adaptador 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. No debe usar la funcionalidad para cargas de trabajo de producción.

Cuando se habilita un adaptador 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?

Puede agregar una configuración de 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 de TAP afectará al rendimiento y la latencia en la máquina virtual, ya que actualmente las redes aceleradas de Azure no admiten la descarga para el tráfico de creación de reflejo.

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 listas de control de acceso (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. El mismo administrador o administradores diferentes puede realizar los pasos, en función de los permisos de control de acceso basado en rol (RBAC) de Azure concedidos al rol de administrador.

Le recomendamos que 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. Para configurar puntos de conexión de servicio de red virtual, debe realizar los pasos de la secuencia anterior.

Nota:

Debe completar ambas operaciones anteriores para poder limitar el acceso del servicio de Azure a la red virtual y 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. También debe configurar las ACL de red virtual en el lado del servicio de Azure.

Ciertos servicios (como Azure SQL y Azure Cosmos DB) permiten excepciones en la secuencia precedente si usa la marca IgnoreMissingVnetServiceEndpoint. Después de establecer la marca en True, puede configurar las ACL de red virtual en el lado del servicio de Azure antes de activar los puntos de conexión de servicio en el lado de la red. Los servicios de Azure proporcionan esta marca para ayudar a los clientes en los casos en los que los firewalls de IP específicos están configurados en los servicios de Azure.

Habilitar los punto de conexión de servicio en el lado de la red puede llevar a una caída de la conectividad, porque el 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 habilitar los puntos de conexión de servicio en el lado de red puede ayudarle a evitar que la conectividad se vea afectada.

Nota:

Si habilita el punto de conexión de servicio en determinados servicios como "Microsoft.AzureActiveDirectory", puede ver las conexiones de direcciones IPV6 en los registros de inicio de sesión. Microsoft usa un intervalo privado IPV6 interno para este tipo de conexiones.

¿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 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. Para más información, consulte Implementación de servicios de Azure dedicado 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 desde una red virtual y subred permitidas.

¿Cómo proporcionan seguridad los puntos de conexión de servicio de red virtual?

Los puntos de conexión de servicio de red virtual limitan el acceso del servicio de Azure a la red virtual y subred permitidas. De esta manera, proporcionan seguridad de nivel de red y aislamiento del tráfico del servicio de Azure.

Todo el tráfico que usa puntos de conexión de servicio de red virtual fluye a través de la red troncal de Microsoft para proporcionar otra capa de aislamiento de la red pública de Internet. Los clientes también 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 ACLs de red virtual. La eliminación del acceso a Internet ayuda a proteger los recursos del servicio de Azure frente al acceso no autorizado.

¿Qué protege el punto de conexión de servicio de red virtual: recursos de red virtual o recursos de 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.

¿Hay algún costo por usar los puntos de conexión de servicio de la red virtual?

No. No hay ningún costo adicional por usar puntos de conexión de servicio de red virtual.

¿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 de servicio de Azure pueden encontrarse en la misma suscripción 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 Microsoft Entra.

¿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 inquilinos diferentes de Microsoft Entra?

Sí, es posible cuando se usan puntos de conexión de servicio para Azure Storage y Azure Key Vault. Para otros servicios, los puntos de conexión de servicio de red virtual y las ACL de red virtual no se admiten en Microsoft Entra inquilinos.

¿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 a los servicios 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 mediante 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 de varias subredes dentro de una red virtual o entre varias redes virtuales, habilite los puntos de conexión de servicio en el lado de la red de cada una de las subredes de manera independiente. A continuación, proteja los recursos de 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 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 la lista de control de acceso (ACL) de una red virtual que está fuera de la misma 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 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 la región Oeste de EE. UU. o el Este de EE. UU. y las redes virtuales están en varias regiones, las redes virtuales pueden obtener acceso a Azure Cosmos DB.

Azure Storage y Azure SQL son excepciones y son regionales por naturaleza. Tanto la red virtual como el servicio de Azure necesitan 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 un firewall de IP pueden coexistir. Las características se complementan entre sí para ayudar a garantizar el aislamiento y la seguridad.

¿Qué sucede si se elimina una red virtual o subred que tiene los puntos de conexión de servicio activado 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 las ACL de red virtual para los servicios de Azure, la información de ACL asociada a esos servicios de Azure se deshabilita al eliminar una red virtual o subred que tenga activados los puntos de conexión de servicio de red virtual.

¿Qué ocurre si elimino una cuenta de servicio de Azure que tiene activado 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. Se admite incluso si ha activado el punto de conexión de servicio en el lado de la red y ha configurado las ACL de red virtual 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 habilita los puntos de conexión de servicio de red virtual, 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 los servicios de Azure. Este cambio 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 protocolo de puerta de enlace de borde (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 Virtual Network.

¿Funcionan los puntos de conexión de servicio con ICMP?

No. El tráfico ICMP que procede de una subred con puntos de conexión de servicio habilitados no tomará la ruta de acceso del túnel del servicio hacia el punto de conexión deseado. Los puntos de conexión de servicio solo administran el tráfico TCP. Si quiere probar la latencia o la conectividad con un punto de conexión a través de puntos de conexión de servicio, las herramientas como ping y tracert no mostrarán la ruta de acceso verdadera que tomarán los recursos dentro de la subred.

¿Cómo funciona NSGs 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, el tráfico del punto de conexión de servicio debería funcionar. También puede limitar el tráfico saliente solo a direcciones IP de servicio mediante las etiquetas de servicio.

¿Qué permisos necesito para configurar los puntos de conexión de servicio?

Puede configurar puntos de conexión de servicio en una red virtual de forma independiente si tiene acceso de escritura a esa red.

Para proteger los recursos de servicio de Azure en una red virtual, deberá tener el permiso Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/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.

Para obtener más información sobre roles integrador y la asignación de permisos concretos a roles personalizados, consulte Roles personalizados de Azure.

¿Se puede filtrar el tráfico de la red virtual a los servicios de Azure sobre punto de conexión de servicio?

Se pueden utilizar directivas de punto de conexión de servicio de la red virtual (VNet) para 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.

Para más información, consulteDirectivas de punto de conexión de servicio de red virtual para Azure Storage.

¿Microsoft Entra identificador admite puntos de conexión de servicio de red virtual?

Microsoft Entra id. no admite puntos de conexión de servicio de forma nativa. Para obtener una lista de los servicios de Azure completa que admiten puntos de conexión de servicio de red virtual, consulte Puntos de conexión de servicio de red virtual.

Cabe mencionar que en la lista "Microsoft.AzureActiveDirectory" 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 Azure Data Lake Storage Gen1. Para la integración de red virtual en Data Lake Storage Gen1, se usa la seguridad del punto de conexión de servicio de red virtual entre la red virtual y Microsoft Entra ID 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.

¿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 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:

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 64
Azure Event Hubs 128
Azure Service Bus 128

Nota:

Los límites están sujetos al cambio a discreción de los servicios de Azure. Consulte la documentación de servicio correspondiente para obtener detalles.

Migración de recursos de red clásicos a Resource Manager

¿Qué significan Azure Service Manager, y qué significa el término «clásico»?

Azure Service Manager es el modelo de implementación anterior de Azure que era responsable 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 más información, consulte la Comparación de modelos de implementación.

¿Qué es Azure Resource Manager?

Azure Resource Manager es el modelo de implementación y administración más reciente de Azure que es responsable de crear, administrar y eliminar recursos de la suscripción de Azure. Para 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 la reversión al modelo de implementación anterior después de que los recursos se hayan migrado correctamente a través de 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. Ninguna operación de migración, incluida la operación de confirmación, se puede cambiar una vez iniciada. Por consiguiente, se recomienda que vuelva a intentar la operación en breve. 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 se pueden migrar los recursos. Si se produce un error en la validación, recibirá mensajes con todas las razones por las que no se puede completar la migración.

¿Se migran Application Gateway recursos como parte de la migración de red virtual de clásico a Resource Manager?

Los recursos de Application Gateway de Azure no se migran automáticamente como parte del proceso de migración de red virtual. Si hay uno en la red virtual, la migración no se realiza correctamente. Para migrar un recurso de Application Gateway a Resource Manager, tiene que quitar y volver a crear la instancia de Application Gateway luego de completada la migración.

¿Se migran VPN Gateway recursos como parte de la migración de red virtual de clásico a Resource Manager?

Los recursos de VPN Gateway de Azure se migran como parte del proceso de migración de 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 puerta de enlace de VPN.

¿Hay una interrupción del servicio asociada a la migración de puertas de enlace de VPN clásicas a Resource Manager?

No experimentará ninguna interrupción del servicio con la conexión VPN al migrar a Resource Manager. Las cargas de trabajo existentes seguirán funcionando con total conectividad local durante la migración.

¿Es necesario volver a configurar el dispositivo local después de que la instancia de VPN gateway se haya migrado a Resource Manager?

La dirección IP pública asociada a la puerta de enlace de VPN sigue siendo la misma después de la migración. No es necesario volver a configurar el enrutador local.

¿Cuáles son los escenarios admitidos para la migración de VPN gateway desde clásico a Resource Manager?

La migración de clásico a Resource Manager abarca la mayoría de los escenarios comunes de conectividad VPN. Entre los escenarios admitidos, se incluyen los siguientes:

  • Conectividad de punto a sitio.

  • Conectividad de sitio a sitio con una instancia de VPN gateway conectada a una ubicación local.

  • Conectividad de red a red entre dos redes virtuales que usan puertas de enlace de VPN.

  • Varias redes virtuales conectadas a la misma ubicación local.

  • Conectividad de varios sitios.

  • Redes virtuales con tunelización forzada habilitada.

¿Qué escenarios no se admiten en la migración de VPN gateway desde clásico a Resource Manager?

Entre los escenarios que no se admiten se incluyen:

  • Una red virtual con ExpressRoute gateway y VPN gateway.

  • Red virtual con una puerta de enlace de ExpressRoute conectada a un circuito en otra suscripción.

  • 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 de clásico a Resource Manager?

Consulte Preguntas más frecuentes sobre la migración del método clásico al de Azure Resource Manager.

¿Cómo puedo notificar un problema?

Puede publicar preguntas sobre los problemas de migración a la página Microsoft Q&A. Se recomienda publicar todas las preguntas en este foro. Si tiene un contrato de soporte técnico, también puede presentar una solicitud de soporte técnico.