Standaarduitgaande toegang in Azure

Wanneer u in Azure een virtuele machine (VM) in een virtueel netwerk implementeert zonder een expliciet gedefinieerde uitgaande connectiviteitsmethode, wijst Azure deze automatisch een uitgaand openbaar IP-adres toe. Dit IP-adres maakt uitgaande connectiviteit mogelijk van de resources naar internet en naar andere openbare eindpunten binnen Microsoft. Deze toegang wordt standaard uitgaande toegang genoemd.

Voorbeelden van expliciete uitgaande connectiviteit voor virtuele machines zijn:

Geïmplementeerd in een subnet dat is gekoppeld aan een NAT-gateway.
Geïmplementeerd in de back-endpool van een standaard load balancer met gedefinieerde uitgaande regels.
Ingezet in de backend pool van een basis openbare load balancer.
Virtuele machines met openbare IP-adressen die er expliciet aan zijn gekoppeld.

Diagram van expliciete uitgaande opties.

Hoe en wanneer er standaard uitgaande toegang wordt opgegeven

Als een virtuele machine (VM) wordt geïmplementeerd zonder een expliciete uitgaande connectiviteitsmethode, wijst Azure dit toe aan een standaard uitgaand openbaar IP-adres. Dit IP-adres, ook wel het standaard ip-adres voor uitgaande toegang genoemd, is eigendom van Microsoft en kan zonder kennisgeving worden gewijzigd. Het wordt niet aanbevolen voor productieworkloads.

Notitie

In sommige gevallen wordt een standaard uitgaand IP-adres nog steeds toegewezen aan virtuele machines in een niet-persoonlijk subnet, zelfs wanneer een expliciete uitgaande methode, zoals een NAT-gateway of een UDR die verkeer omleidt naar een NVA/firewall, is geconfigureerd. Dit betekent niet dat de standaard uitgaande IP-adressen worden gebruikt voor uitgaand verkeer, tenzij deze expliciete methoden worden verwijderd. Als u de standaard uitgaande IP-adressen volledig wilt verwijderen, moet het subnet privé worden gemaakt en moeten de virtuele machines worden gestopt en de toewijzing ervan ongedaan worden gemaakt.

Belangrijk

Na 31 maart 2026 gebruiken nieuwe virtuele netwerken standaard privésubnetten, wat betekent dat een expliciete uitgaande methode moet worden ingeschakeld om openbare eindpunten op internet en binnen Microsoft te bereiken. Zie de officiële aankondiging voor meer informatie. U wordt aangeraden een van de expliciete vormen van connectiviteit te gebruiken die in de volgende sectie worden besproken. Zie de sectie 'Veelgestelde vragen: Standaardgedragswijziging in privésubnetten' voor andere vragen.

Waarom wordt het uitschakelen van standaardtoegang voor uitgaand verkeer aanbevolen?

Beveiliging: standaardtoegang tot internet komt overeen met zero Trust-principes.
Duidelijkheid: Expliciete connectiviteit heeft de voorkeur boven impliciete toegang.
Stabiliteit: het standaard uitgaande IP-adres is niet eigendom van de klant en kan veranderen, wat leidt tot potentiële onderbrekingen.

Enkele voorbeelden van configuraties die niet werken bij het gebruik van standaard uitgaande toegang:

Meerdere NIC's op een VIRTUELE machine kunnen inconsistente uitgaande IP-adressen opleveren
Het schalen van virtuele-machineschaalsets van Azure kan leiden tot het wijzigen van uitgaande IP-adressen
Uitgaande IP-adressen zijn niet consistent of aaneengesloten tussen instanties van virtuele-machineschaalsets

Bijkomend,

Standaard ip-adressen voor uitgaande toegang bieden geen ondersteuning voor gefragmenteerde pakketten
Standaard-IP-adressen voor uitgaande toegang bieden geen ondersteuning voor ICMP-pings

Hoe kan ik overstappen op een expliciete methode van openbare connectiviteit (en standaard uitgaande toegang uitschakelen)?

Overzicht van privésubnetten

Als u een subnet als privé maakt, voorkomt u dat virtuele machines in het subnet gebruikmaken van standaard uitgaande toegang om verbinding te maken met openbare eindpunten.
VM's in een privésubnet hebben nog steeds toegang tot internet (of openbare eindpunten binnen Microsoft) met behulp van expliciete uitgaande connectiviteit.

Notitie

Bepaalde services werken niet op een virtuele machine in een privésubnet zonder een expliciete methode voor uitgaand verkeer (voorbeelden zijn Windows-activering en Windows-updates).

Privésubnetten configureren

Selecteer in Azure Portal het subnet en schakel het selectievakje in om privésubnet in te schakelen, zoals wordt weergegeven:

Schermopname van Azure Portal met de optie Privésubnet.

Met behulp van PowerShell gebruikt het volgende script de namen van de resourcegroep en het virtuele netwerk en doorloopt elk subnet om het privé-subnet in te schakelen.

$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

Gebruik de CLI om het subnet bij te werken met az network vnet subnet update en stel --default-outbound in op "false"

az network vnet subnet update --resource-group rgname --name subnetname --vnet-name vnetname --default-outbound false

Stel met behulp van een Azure Resource Manager-sjabloon de waarde van defaultOutboundAccess de parameter in op '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
            }
          }
        ]
      }
    }
  ]
}

Beperkingen van privésubnetten

Voor het activeren of bijwerken van besturingssystemen van virtuele machines, zoals Windows, is een expliciete uitgaande connectiviteitsmethode vereist.
In configuraties met behulp van door de gebruiker gedefinieerde routes (UDR's) stoppen geconfigureerde routes met het volgende hoptype Internet in een privé-subnet.
- Een veelvoorkomend voorbeeld is het gebruik van een UDR om verkeer naar een virtueel upstream-netwerkapparaat/firewall te sturen, met uitzonderingen voor bepaalde Azure-servicetags om inspectie te omzeilen. Dit wordt gedaan door routes naar deze Service Tags te configureren met het volgende hoptype Internet. In dit scenario configureert u het volgende:
  - Een standaardroute voor de bestemming 0.0.0.0/0, met als volgende hoptype een virtueel apparaat, is doorgaans van toepassing.
  - Een of meer routes zijn geconfigureerd voor servicetagbestemmingen met het volgende hoptype Internetom de NVA/firewall te omzeilen. Tenzij er ook een expliciete uitgaande connectiviteitsmethode is geconfigureerd voor de bron van de verbinding met deze bestemmingen, mislukken pogingen om verbinding te maken met deze bestemmingen, omdat standaard uitgaande toegang niet standaard beschikbaar is in een privésubnet.
- Deze beperking is niet van toepassing op het gebruik van service-eindpunten, die gebruikmaken van een ander type volgende hop VirtualNetworkServiceEndpoint. Zie Service-eindpunten voor virtueel netwerk.
Virtuele machines hebben nog steeds toegang tot Azure Storage-accounts in dezelfde regio in een privésubnet zonder expliciete methode voor uitgaand verkeer. NSG's worden aanbevolen om uitgaande verbindingen te beheren.
Privésubnetten zijn niet van toepassing op gedelegeerde of beheerde subnetten die worden gebruikt voor het hosten van PaaS-services. In deze scenario's wordt uitgaande connectiviteit beheerd door de afzonderlijke service.

Belangrijk

Wanneer een back-endpool van een load balancer is geconfigureerd op basis van het IP-adres, wordt standaard uitgaande toegang gebruikt vanwege een doorlopend bekend probleem. Voor een veilige standaardconfiguratie en toepassingen met veeleisende uitgaande behoeften koppelt u een NAT-gateway aan de VM's in de back-endpool van uw load balancer om verkeer te beveiligen. Bekijk meer over bestaande bekende problemen.

Een expliciete uitgaande methode toevoegen

Een NAT-gateway koppelen aan het subnet van uw virtuele machine. Houd er rekening mee dat dit de aanbevolen methode is voor de meeste scenario's.
Koppel een standaard load balancer die is geconfigureerd met uitgaande regels.
Koppel een standaard openbaar IP-adres aan een van de netwerkinterfaces van de virtuele machine.
Voeg een firewall of NVA (Network Virtual Appliance) toe aan uw virtuele netwerk en wijs verkeer ernaar aan met behulp van een door de gebruiker gedefinieerde route (UDR).

Flexibele orkestratiemodus gebruiken voor virtuele-machineschaalsets

Flexibele schaalsets zijn standaard veilig. Alle exemplaren die via flexibele schaalsets worden gemaakt, hebben niet het standaard-IP-adres voor uitgaande toegang eraan gekoppeld, dus er is een expliciete uitgaande methode vereist. Voor meer informatie, zie flexibele orkestratiemodus voor virtuele-machineschaalsets

Veelgestelde vragen: Standaardwaarschuwing voor uitgaand IP-adres wissen

Waarom zie ik een waarschuwing waarin wordt weergegeven dat ik een standaard uitgaand IP-adres heb op mijn VM?

Er is een parameter op NIC-niveau (defaultOutboundConnectivityEnabled) waarmee wordt bijgehouden of standaard uitgaand IP-adres wordt toegewezen aan een vm-/virtuele-machineschaalsetinstantie. Dit wordt gebruikt om een banner in de Azure-portal te genereren voor een virtuele machine/virtuele-machineschaalset die deze status markeert. Er zijn ook specifieke Azure Advisor-aanbevelingen met deze informatie voor uw abonnementen. Als u wilt bekijken welke van uw virtuele machines of virtuele-machineschaalsets aan hen een standaard uitgaand IP-adres zijn toegewezen, voert u de volgende stappen uit:

Typ Advisor in de zoekbalk in Azure Portal en selecteer deze optie wanneer deze wordt weergegeven.
Selecteer 'Operational Excellence'
Zoek naar de aanbevelingen 'Expliciete uitgaande methode toevoegen om de standaarduitgaande verbinding uit te schakelen' en/of 'Expliciete uitgaande methode toevoegen om de standaarduitgaande verbinding uit te schakelen voor Virtuele Machine Schaalsets' (opmerken: dit zijn twee verschillende items)
Als een van deze bestaat, selecteert u de respectieve aanbevelingsnaam en ziet u de netwerkinterfacekaarten (NIC's) van alle exemplaren van virtuele machnes/virtuele-machineschaalsets waarvoor standaard uitgaand verkeer is ingeschakeld.

Hoe kan ik deze waarschuwing wissen?

Er moet een expliciete methode voor uitgaand verkeer worden gebruikt voor de gemarkeerde virtuele-machineschaalset/VM. Zie de bovenstaande sectie voor verschillende opties.
Het subnet moet privé worden gemaakt om te voorkomen dat nieuwe standaard uitgaande IP-adressen worden gemaakt.
Alle toepasselijke virtuele machines in het subnet met de vlag moeten worden gestopt en de toewijzing ervan ongedaan worden gemaakt zodat de wijzigingen worden doorgevoerd in de parameter op NIC-niveau en de vlag die moet worden gewist. (Houd er rekening mee dat dit ook waar is in het omgekeerde geval. Als u wilt dat een machine een standaard-uitgaand IP-adres krijgt nadat de parameter op subnetniveau is ingesteld op false, is een stop/toewijzing van de virtuele machine vereist.)

Ik gebruik al een expliciete methode voor uitgaand verkeer, dus waarom zie ik deze waarschuwing nog steeds?

In sommige gevallen wordt een standaard uitgaand IP-adres nog steeds toegewezen aan virtuele machines in een niet-persoonlijk subnet, zelfs wanneer een expliciete uitgaande methode, zoals een NAT-gateway of een UDR die verkeer omleidt naar een NVA/firewall, is geconfigureerd. Dit betekent niet dat de standaard uitgaande IP-adressen worden gebruikt voor uitgaand verkeer, tenzij deze expliciete methoden worden verwijderd. Als u de standaard uitgaande IP-adressen volledig wilt verwijderen (en de waarschuwing wilt verwijderen), moet het subnet privé worden gemaakt en moeten de virtuele machines worden gestopt en de toewijzing ervan ongedaan worden gemaakt.

Veelgestelde vragen: Standaardgedragswijziging in privésubnetten

Wat betekent het standaard maken van privésubnetten en hoe wordt deze geïmplementeerd?

Met de API-versie die na 31 maart 2026 is uitgebracht, wordt de eigenschap defaultOutboundAccess voor subnetten in nieuwe VNET's standaard ingesteld op 'false'. Deze wijziging maakt subnetten standaard privé en voorkomt het genereren van standaard uitgaande IP-adressen voor virtuele machines in deze subnetten. Dit gedrag is van toepassing op alle configuratiemethoden: ARM-sjablonen, Azure Portal, PowerShell en CLI. Eerdere versies van ARM-sjablonen (of hulpprogramma's zoals Terraform die oudere versies kunnen opgeven) blijven standaardOutboundAccess instellen als null, waardoor uitgaande toegang impliciet wordt toegestaan.

Wat gebeurt er met mijn bestaande VNET's en virtuele machines? Hoe zit het met nieuwe virtuele machines die zijn gemaakt in bestaande VNET's?

Er worden geen wijzigingen aangebracht in bestaande VNET's. Dit betekent dat zowel bestaande virtuele machines als nieuw gemaakte virtuele machines in deze VNET's standaard uitgaande IP-adressen blijven genereren, tenzij de subnetten handmatig worden gewijzigd om privé te worden.

Hoe zit het met nieuwe implementaties van virtuele netwerken? Mijn infrastructuur heeft een afhankelijkheid van standaard uitgaande IP-adressen en is op dit moment niet klaar om over te stappen op privésubnetten.

U kunt subnetten nog steeds als niet-gemachtigd configureren met behulp van elke ondersteunde methode (ARM-sjablonen, portal, CLI, PowerShell). Dit zorgt voor compatibiliteit voor infrastructuren die afhankelijk zijn van standaard uitgaande IP-adressen en nog niet gereed zijn om over te stappen op privésubnetten.

Volgende stappen

Zie voor meer informatie over uitgaande verbindingen in Azure:

SNAT (Source Network Address Translation) voor uitgaande verbindingen.
Wat is Azure NAT Gateway?

Feedback

Is deze pagina nuttig?

Last updated on 2025-12-03