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.
En Azure, al implementar una máquina virtual (VM) en una red virtual sin un método de conectividad saliente definido explícitamente, Azure le asigna automáticamente una dirección IP pública saliente. Esta dirección IP permite la conectividad saliente de los recursos a Internet y a otros puntos de conexión públicos dentro de Microsoft. Este acceso se conoce como acceso de salida predeterminado.
Algunos ejemplos de conectividad de salida explícita para máquinas virtuales son:
- Implementado en una subred asociada a una puerta de enlace NAT.
- Implementado en el grupo de back-end de un equilibrador de carga estándar con reglas de salida definidas.
- Implementado en el grupo de back-end de un equilibrador de carga público básico.
- Máquinas virtuales con direcciones IP públicas asociadas explícitamente a ellas.
Cómo y cuándo se proporciona el acceso saliente predeterminado
Si se implementa una máquina virtual (VM) sin un método de conectividad saliente explícito, Azure le asigna una dirección IP pública de salida predeterminada. Esta dirección IP, conocida como ip de acceso de salida predeterminada, es propiedad de Microsoft y puede cambiar sin previo aviso. No se recomienda para cargas de trabajo de producción.
Nota:
En algunos casos, todavía se asigna una dirección IP de salida predeterminada a las máquinas virtuales en una subred no privada, incluso cuando se configura un método de salida explícito, como una puerta de enlace NAT o UDR que dirija el tráfico a una aplicación virtual de red o a un firewall. Esto no significa que las direcciones IP de salida predeterminadas se usarán para la salida a menos que se quiten esos métodos explícitos. Para quitar completamente las direcciones IP de salida predeterminadas, la subred debe ser privada y las máquinas virtuales deben detenerse y desasignarse.
3Importante
Después del 31 de marzo de 2026, las nuevas redes virtuales usarán de forma predeterminada subredes privadas, lo que significa que se debe habilitar un método de salida explícito para llegar a puntos de conexión públicos en Internet y dentro de Microsoft. Para obtener más información, consulte el anuncio oficial. Se recomienda usar una de las formas explícitas de conectividad descritas en la sección siguiente. Para otras preguntas, consulte la sección "Preguntas más frecuentes: Cambio de comportamiento predeterminado de subredes privadas".
¿Por qué se recomienda deshabilitar el acceso de salida predeterminado?
Seguridad: el acceso a Internet predeterminado contradiga los principios de confianza cero.
Claridad: se prefiere conectividad explícita sobre el acceso implícito.
Estabilidad: la dirección IP de salida predeterminada no es propiedad del cliente y puede cambiar, lo que puede provocar posibles interrupciones.
Algunos ejemplos de configuraciones que no funcionan al usar el acceso saliente predeterminado:
- Varias NIC en una máquina virtual pueden producir direcciones IP de salida incoherentes
- El escalado de conjuntos de escalado de máquinas virtuales de Azure puede dar lugar a cambios en las direcciones IP salientes.
- Las direcciones IP salientes no son coherentes ni contiguas entre instancias del conjunto de escalado de máquinas virtuales
Además:
- Las direcciones IP de acceso saliente predeterminadas no admiten paquetes fragmentados
- Las direcciones IP de acceso saliente predeterminadas no admiten pings icMP.
¿Cómo puedo realizar la transición a un método explícito de conectividad pública (y deshabilitar el acceso de salida predeterminado)?
Introducción a las subredes privadas
- La creación de una subred para que sea privada impide que las máquinas virtuales de la subred usen el acceso de salida predeterminado para conectarse a puntos de conexión públicos.
- Las máquinas virtuales de una subred privada todavía pueden acceder a Internet (o a cualquier punto de conexión público dentro de Microsoft) mediante la conectividad saliente explícita.
Nota:
Algunos servicios no funcionan en una máquina virtual en una subred privada sin un método explícito de salida (ejemplos son Activación de Windows y Actualizaciones de Windows).
Configuración de subredes privadas
- En Azure Portal, active la subred y active la casilla para habilitar la subred privada como se muestra:
- Con PowerShell, el siguiente script toma los nombres del grupo de recursos y la red virtual y recorre en bucle cada subred para habilitar la subred privada.
$resourceGroupName = ""
$vnetName = ""
$vnet = Get-AzVirtualNetwork -ResourceGroupName $resourceGroupName -Name $vnetName
foreach ($subnet in $vnet.Subnets) {
if ($subnet.DefaultOutboundAccess -eq $null) {
$subnet.DefaultOutboundAccess = $false
Write-Output "Set 'defaultoutboundaccess' to \$false for subnet: $($subnet.Name)"
}
elseif ($subnet.DefaultOutboundAccess -eq $false) {
# Output message if the value is already $false
Write-Output "already private for subnet: $($subnet.Name)"
}
}
Set-AzVirtualNetwork -VirtualNetwork $vnet
- Con la CLI, actualice la subred con az network vnet subnet update y establezca
--default-outbounden "false"
az network vnet subnet update --resource-group rgname --name subnetname --vnet-name vnetname --default-outbound false
- Con una plantilla de Azure Resource Manager, establezca el valor del parámetro
defaultOutboundAccesscomo "false".
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"vnetName": {
"type": "string",
"defaultValue": "testvm-vnet"
},
"subnetName": {
"type": "string",
"defaultValue": "default"
},
"subnetPrefix": {
"type": "string",
"defaultValue": "10.1.0.0/24"
},
"vnetAddressPrefix": {
"type": "string",
"defaultValue": "10.1.0.0/16"
}
},
"resources": [
{
"type": "Microsoft.Network/virtualNetworks",
"apiVersion": "2023-11-01",
"name": "[parameters('vnetName')]",
"location": "westus2",
"properties": {
"addressSpace": {
"addressPrefixes": [
"[parameters('vnetAddressPrefix')]"
]
},
"subnets": [
{
"name": "[parameters('subnetName')]",
"properties": {
"addressPrefix": "[parameters('subnetPrefix')]",
"defaultoutboundaccess": false
}
}
]
}
}
]
}
Limitaciones de las subredes privadas
Para activar o actualizar sistemas operativos de máquina virtual, como Windows, se requiere un método de conectividad de salida explícito.
En configuraciones mediante rutas definidas por el usuario (UDR), las rutas configuradas con el tipo de próximo salto
Internetse interrumpen en una subred privada.Un ejemplo común es el uso de una UDR para dirigir el tráfico a una aplicación virtual o firewall de red ascendente, con excepciones para que determinadas etiquetas de servicio de Azure omitan la inspección. Esto se hace configurando rutas a estas etiquetas de servicio con el tipo de próximo salto
Internet. En este escenario, configure lo siguiente:Una ruta predeterminada para el destino 0.0.0.0/0, con un tipo de próximo salto de aplicación virtual se aplica en el caso general.
Una o varias rutas se configuran en destinos de etiquetas de servicio con el tipo de próximo salto
Internetpara omitir la aplicación virtual de red o el firewall. A menos que también se configure un método de conectividad saliente explícito para el origen de la conexión a estos destinos, se produce un error en los intentos de conectarse a estos destinos, ya que el acceso saliente predeterminado no está disponible de forma predeterminada en una subred privada.
Esta limitación no se aplica al uso de puntos de conexión de servicio, que usan un tipo de próximo salto diferente
VirtualNetworkServiceEndpoint. Consulte Puntos de conexión de servicio de red virtual.
Las máquinas virtuales todavía pueden acceder a las cuentas de Azure Storage en la misma región de una subred privada sin un método explícito de salida. Se recomienda que los NSG controlen la conectividad de salida.
Las subredes privadas no son aplicables a las subredes delegadas o administradas que se usan para hospedar servicios PaaS. En estos escenarios, el servicio individual administra la conectividad saliente.
3Importante
Cuando una dirección IP configura un grupo de back-end del equilibrador de carga, usa el acceso saliente predeterminado debido a un problema conocido en curso. Para una configuración segura por defecto y aplicaciones con necesidades de salida exigentes, asocie una puerta de enlace NAT a las máquinas virtuales de su grupo de back-end del equilibrador de carga para asegurar el tráfico. Consulte más información sobre los problemas conocidos existentes.
Adición de un método de salida explícito
- Asocie una instancia de NAT Gateway a la subred de la máquina virtual. Tenga en cuenta que este es el método recomendado para la mayoría de los escenarios.
- Asocie un equilibrador de carga estándar configurado con reglas de salida.
- Asocie una dirección IP pública estándar a cualquiera de las interfaces de red de la máquina virtual.
- Agregue un firewall o una aplicación virtual de red (NVA) a la red virtual y apunte el tráfico a ella mediante una ruta definida por el usuario (UDR).
Usar el modo de orquestación flexible para conjuntos de escalado de máquinas virtuales
- Los conjuntos de escalado flexibles son seguros de manera predeterminada. Las instancias creadas a través de conjuntos de escalado flexible no tienen asociada la dirección IP de acceso de salida predeterminada, por lo que se requiere un método de salida explícito. Para obtener más información, consulte Modo de orquestación flexible para conjuntos de escalado de máquinas virtuales.
Preguntas más frecuentes: Borrar alerta de IP de salida predeterminada
¿Por qué veo una alerta que indica que tengo una dirección IP de salida predeterminada en mi máquina virtual?
Hay un parámetro a nivel de NIC (defaultOutboundConnectivityEnabled) que rastrea si la dirección IP de salida predeterminada se asigna a una máquina virtual o a una instancia de un conjunto de escalado de máquinas virtuales. Se utiliza para generar un banner del portal de Azure para la máquina virtual o el conjunto de escalado de máquinas virtuales que señala este estado. También hay recomendaciones específicas de Azure Advisor con esta información para las suscripciones. Si desea ver cuál de las máquinas virtuales o los conjuntos de escalado de máquinas virtuales tiene asignada una dirección IP de salida predeterminada, siga estos pasos:
- Escriba "Advisor" en la barra de búsqueda de Azure Portal y, a continuación, seleccione esta opción cuando aparezca.
- Seleccione "Excelencia operativa"
- Busque las recomendaciones "Agregar método de salida explícito para deshabilitar la salida predeterminada" o "Agregar método de salida explícito para deshabilitar la salida predeterminada para los conjuntos de escalado de máquinas virtuales" (tenga en cuenta que son dos elementos diferentes).
- Si cualquiera de estos existe, seleccione el nombre de recomendación correspondiente y verá las tarjetas de interfaz de red (NIC) de todas las instancias de máquinas virtuales o conjuntos de escalado de máquinas virtuales que tienen habilitada la salida predeterminada.
¿Cómo se borra esta alerta?
- Se debe usar un método explícito de salida para el conjunto de escalado de máquinas virtuales o máquinas virtuales marcado. Consulte la sección anterior para ver las distintas opciones.
- La subred debe ser privada para evitar que se creen nuevas direcciones IP de salida predeterminadas.
- Las máquinas virtuales aplicables de la subred con la marca deben detenerse y desasignarse para que los cambios se reflejen en el parámetro de nivel de NIC y que la marca se borre. (Tenga en cuenta que esto también es cierto en el caso inverso; para que una máquina tenga una dirección IP de salida predeterminada después de tener el parámetro de nivel de subred establecido en false, es necesario detener o desasignar la máquina virtual).
Ya estoy usando un método explícito de salida, ¿por qué todavía veo esta alerta?
En algunos casos, todavía se asigna una dirección IP de salida predeterminada a las máquinas virtuales en una subred no privada, incluso cuando se configura un método de salida explícito, como una puerta de enlace NAT o UDR que dirija el tráfico a una aplicación virtual de red o a un firewall. Esto no significa que las direcciones IP de salida predeterminadas se usarán para la salida a menos que se quiten esos métodos explícitos. Para quitar completamente las direcciones IP de salida predeterminadas (y quitar la alerta), la subred debe volverse privada y las máquinas virtuales deben detenerse y desasignarse.
Preguntas más frecuentes: Cambio de comportamiento predeterminado a subredes privadas
¿Qué significa que las subredes privadas son predeterminadas y cómo se implementará?
Con la versión de la API que se publicará después del 31 de marzo de 2026, la propiedad defaultOutboundAccess para las subredes de las nuevas redes virtuales se establecerá en "false" de forma predeterminada. Este cambio hace que las subredes sean privadas de forma predeterminada e impide la generación de direcciones IP salientes predeterminadas para las máquinas virtuales de esas subredes. Este comportamiento se aplica a todos los métodos de configuración: plantillas de ARM, Azure Portal, PowerShell y la CLI. Las versiones anteriores de plantillas de ARM (o herramientas como Terraform que pueden especificar versiones anteriores) seguirán configurando defaultOutboundAccess como null, lo que permite implícitamente el acceso saliente.
¿Qué ocurrirá con mis redes virtuales y máquinas virtuales existentes? ¿Qué ocurre con las nuevas máquinas virtuales creadas en redes virtuales existentes?
No se realizan cambios en las redes virtuales existentes. Esto significa que las máquinas virtuales existentes y las máquinas virtuales recién creadas en estas redes virtuales siguen generando direcciones IP de salida predeterminadas a menos que las subredes se modifiquen manualmente para que sean privadas.
¿Qué ocurre con las nuevas implementaciones de red virtual? Mi infraestructura tiene una dependencia de las direcciones IP de salida predeterminadas y no está lista para moverse a subredes privadas en este momento.
Todavía puede configurar las subredes como no privadas mediante cualquier método admitido (plantillas de ARM, portal, CLI, PowerShell). Esto garantiza la compatibilidad con las infraestructuras que dependen de direcciones IP de salida predeterminadas y que aún no están listas para realizar la transición a subredes privadas.
Pasos siguientes
Para más información sobre las conexiones salientes en Azure, consulte: