Partilhar via


Acesso de saída padrão no Azure

No Azure, quando se implementa uma máquina virtual (VM) numa rede virtual sem um método de conectividade de saída explicitamente definido, o Azure atribui-lhe automaticamente um endereço IP público de saída. Este endereço IP permite a conectividade de saída dos recursos para a Internet e para outros endpoints públicos dentro da Microsoft. Esse acesso é conhecido como acesso de saída padrão.

Exemplos de conectividade de saída explícita para máquinas virtuais são:

  • Implantado em uma sub-rede associada a um gateway NAT.
  • Implantado no pool de backend de um balanceador de carga padrão com regras de saída definidas.
  • Implantado no pool de back-end de um balanceador de carga básico público.
  • Máquinas virtuais com endereços IP públicos explicitamente associados a elas.

Diagrama de opções de saída explícitas.

Como e quando o acesso de saída padrão é fornecido

Se uma Máquina Virtual (VM) for implantada sem um método de conectividade de saída explícito, o Azure atribuirá a ela um endereço IP público de saída padrão. Esse IP, conhecido como IP de acesso de saída padrão, pertence à Microsoft e pode ser alterado sem aviso prévio. Não é recomendado para ambientes de produção.

Diagrama da árvore de decisão para acesso de saída padrão.

Nota

Em alguns casos, um IP de saída padrão ainda é atribuído a máquinas virtuais em uma sub-rede não privada, mesmo quando um método de saída explícito — como um gateway NAT ou um UDR direcionando o tráfego para um NVA/firewall — é configurado. Isso não significa que os IPs de saída padrão sejam usados para saída, a menos que esses métodos explícitos sejam removidos. Para remover completamente os IPs de saída padrão, a sub-rede deve ser privada e as máquinas virtuais devem ser interrompidas e deslocalizadas.

Importante

Após 31 de março de 2026, as novas redes virtuais usarão como padrão sub-redes privadas, o que significa que um método de saída explícito deve ser habilitado para alcançar pontos de extremidade públicos na Internet e na Microsoft. Para obter mais informações, veja o anúncio oficial. Recomendamos que você use uma das formas explícitas de conectividade discutidas na seção a seguir. Para outras perguntas, consulte a seção "Perguntas frequentes: alteração de comportamento padrão para sub-redes privadas".

Segurança: O acesso padrão à Internet contradiz os princípios do Zero Trust.
Clareza: a conectividade explícita é preferível ao acesso implícito.
Estabilidade: O IP de saída padrão não pertence ao cliente e pode mudar, levando a possíveis interrupções.

Alguns exemplos de configurações que não funcionam ao usar o acesso de saída padrão:

  • Várias NICs em uma VM podem gerar IPs de saída inconsistentes
  • O dimensionamento dos Conjuntos de Escala de Máquina Virtual do Azure pode resultar na alteração de IPs de saída
  • IPs de saída não são consistentes nem contíguos entre as instâncias do Conjunto de Escalas de Máquinas Virtuais

Além disso,

  • Os IPs de acesso de saída padrão não suportam pacotes fragmentados
  • IPs de acesso de saída padrão não suportam pings ICMP

Como posso fazer a transição para um método explícito de conectividade pública (e desativar o acesso de saída padrão)?

Visão geral de sub-redes privadas

  • A criação de uma sub-rede para ser privada impede que qualquer máquina virtual na sub-rede utilize o acesso de saída padrão para se conectar a pontos de extremidade públicos.
  • As VMs numa sub-rede privada podem ainda assim aceder à Internet (ou a quaisquer endpoints públicos dentro da Microsoft) utilizando conectividade de saída explícita.

    Nota

    Certos serviços não funcionam em uma máquina virtual em uma sub-rede privada sem um método explícito de saída (exemplos são a Ativação do Windows e as Atualizações do Windows).

Como configurar sub-redes privadas

  • No portal do Azure, selecione a sub-rede e marque a caixa de seleção para habilitar a sub-rede privada, conforme mostrado:

Captura de ecrã do portal do Azure a mostrar a opção de sub-rede privada.

  • Usando o PowerShell, o script a seguir usa os nomes do Grupo de Recursos e da Rede Virtual e percorre cada sub-rede para habilitar a sub-rede 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
az network vnet subnet update --resource-group rgname --name subnetname --vnet-name vnetname --default-outbound false
  • Usando um modelo do Azure Resource Manager, defina o valor do defaultOutboundAccess parâmetro como "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
            }
          }
        ]
      }
    }
  ]
}

Limitações de sub-redes privadas

  • Para ativar ou atualizar sistemas operacionais de máquinas virtuais, como o Windows, é necessário um método de conectividade de saída explícito.

  • Em configurações que usam UDRs (Rotas Definidas pelo Usuário), todas as rotas configuradas com tipo de próximo salto Internet falham numa sub-rede privada.

    • Um exemplo comum é o uso de um UDR para direcionar o tráfego para um dispositivo virtual de rede/firewall upstream, com exceções para certas etiquetas de serviço do Azure para evitar a inspeção. Isto é feito configurando rotas para estas Etiquetas de Serviço com o tipo de próximo salto Internet. Neste cenário, configura o seguinte:

      • Uma rota padrão para o destino 0.0.0.0/0, com um tipo de próximo salto de Dispositivo Virtual aplica-se de forma geral.

      • Uma ou mais rotas estão configuradas para destinos de Etiqueta de Serviço com o tipo Internet de próximo salto, para ignorar o NVA/firewall. A menos que um método explícito de conectividade de saída esteja também configurado para a origem da ligação a estes destinos, as tentativas de ligação a estes destinos falham, porque o acesso de saída por defeito não está disponível por defeito numa sub-rede privada.

    • Essa limitação não se aplica ao uso de pontos de extremidade de serviço, que usam um tipo VirtualNetworkServiceEndpointde salto seguinte diferente. Ver Endpoints de serviço da Rede Virtual.

  • As máquinas virtuais ainda podem acessar contas de Armazenamento do Azure na mesma região em uma sub-rede privada sem um método explícito de saída. Os NSGs são recomendados para controlar a conectividade de saída.

  • As sub-redes privadas não são aplicáveis a sub-redes delegadas ou gerenciadas usadas para hospedar serviços PaaS. Nesses cenários, a conectividade de saída é gerenciada pelo serviço individual.

Importante

Quando um pool de back-end de balanceador de carga é configurado por endereço IP, ele usa o acesso de saída padrão devido a um problema conhecido contínuo. Para configurações seguras por padrão e aplicativos com necessidades de saída exigentes, associe um gateway NAT às VMs no pool de back-end do balanceador de carga para proteger o tráfego. Veja mais sobre problemas conhecidos existentes.

Adicionar um método de saída explícito

  • Associe um NAT Gateway à subrede da máquina virtual. Observe que este é o método recomendado para a maioria dos cenários.
  • Associe um balanceador de carga padrão configurado com regras de saída especificadas.
  • Associe um IP público padrão a qualquer uma das interfaces de rede da máquina virtual.
  • Adicione um Firewall ou Network Virtual Appliance (NVA) à sua rede virtual e aponte o tráfego para ela usando uma UDR (User Defined Route).

Usar o modo de orquestração flexível para Conjuntos de Dimensionamento de Máquinas Virtuais

  • Os conjuntos de escalas flexíveis são seguros por padrão. Todas as instâncias criadas por meio de conjuntos de escala flexível não têm o IP de acesso de saída padrão associado a elas, portanto, um método de saída explícito é necessário. Para obter mais informações, consulte Modo de orquestração flexível para escalões de máquinas virtuais

Perguntas frequentes: Limpar alerta de IP de saída padrão

Por que vejo um alerta mostrando que tenho um IP de saída padrão na minha VM?

Existe um parâmetro a nível da NIC (defaultOutboundConnectivityEnabled) que verifica se o IP de saída por defeito está alocado a uma instância VM/Virtual Machine Scale Set. Isto é usado para gerar um banner do portal Azure para VM/Virtual Machine Scale Set que sinaliza este estado. Existem também recomendações específicas do Azure Advisor com esta informação para as suas subscrições. Se quiser ver quais das suas máquinas virtuais ou Conjuntos de Dimensionamento de Máquinas Virtuais têm um IP de saída predefinido atribuído a eles, siga estes passos:

  1. Escreva 'Advisor' na barra de pesquisa do portal Azure e depois selecione esta opção quando aparecer.
  2. Selecione 'Excelência Operacional'
  3. Procure pelas recomendações 'Adicionar método explícito de saída para desativar a saída predefinida' e/ou 'Adicionar método explícito de saída para desativar a saída predefinida para Conjuntos de Dimensionamento de Máquinas Virtuais' (note que estes são dois itens diferentes).
  4. Se alguma destas existir, selecione o respetivo nome de recomendação e verá as placas de interface de rede (NICs) de todas as instâncias de máquinas virtuais/conjuntos de dimensionamento de máquinas virtuais que têm a saída por defeito ativada.

Como faço para limpar esse alerta?

  1. Deve ser utilizado um método explícito de saída para o VM/Virtual Machine Scale Set sinalizado. Consulte a secção acima para conhecer as diferentes opções.
  2. A sub-rede deve ser privada para evitar que novos IPs de saída padrão sejam criados.
  3. Todas as máquinas virtuais aplicáveis na sub-rede com o sinalizador devem ser interrompidas e desdistribuídas para que as alterações sejam refletidas no parâmetro de nível NIC e o sinalizador seja limpo. (Observe que isso também é verdadeiro no sentido inverso; para que uma máquina receba um IP de saída padrão depois de ter o parâmetro de nível de sub-rede definido como false, é necessário parar/desalocar a máquina virtual.)

Já estou usando um método explícito de saída, então por que ainda vejo esse alerta?

Em alguns casos, um IP de saída padrão ainda é atribuído a máquinas virtuais em uma sub-rede não privada, mesmo quando um método de saída explícito — como um gateway NAT ou um UDR direcionando o tráfego para um NVA/firewall — é configurado. Isso não significa que os IPs de saída padrão sejam usados para saída, a menos que esses métodos explícitos sejam removidos. Para remover completamente os IPs de saída padrão (e remover o alerta), a sub-rede deve ser privada e as máquinas virtuais devem ser interrompidas e deslocalizadas.

Perguntas frequentes: Alteração de comportamento padrão para sub-redes privadas

O que significa tornar as sub-redes privadas padrão e como isso será implementado?

Com a versão da API lançada após 31 de março de 2026, a propriedade defaultOutboundAccess para sub-redes em novas VNETs será definida como "false" por padrão. Essa alteração torna as sub-redes privadas por padrão e impede a geração de IPs de saída padrão para máquinas virtuais nessas sub-redes. Esse comportamento se aplica a todos os métodos de configuração - modelos ARM, portal do Azure, PowerShell e CLI. Versões anteriores de modelos ARM (ou ferramentas como Terraform que podem especificar versões mais antigas) continuarão a definir defaultOutboundAccess como null, o que implicitamente permite acesso de saída.

O que acontece às minhas VNETs e máquinas virtuais existentes? E as novas máquinas virtuais criadas em VNETs existentes?

Nenhuma alteração é feita em VNETs existentes. Isso significa que as máquinas virtuais existentes e as máquinas virtuais recém-criadas nessas VNETs continuam a gerar endereços IP de saída padrão, a menos que as sub-redes sejam modificadas manualmente para se tornarem privadas.

E as novas implantações de rede virtual? Minha infraestrutura depende de IPs de saída padrão e não está pronta para migrar para sub-redes privadas no momento.

Você ainda pode configurar sub-redes como não privadas usando qualquer método suportado (modelos ARM, portal, CLI, PowerShell). Isso garante compatibilidade para infraestruturas que dependem de IPs de saída padrão e ainda não estão prontas para fazer a transição para sub-redes privadas.

Próximos passos

Para obter mais informações sobre conexões de saída no Azure, consulte: