Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Wenn Sie in Azure einen virtuellen Computer (VM) in einem virtuellen Netzwerk ohne explizit definierte ausgehende Konnektivitätsmethode bereitstellen, weist Azure ihm automatisch eine ausgehende öffentliche IP-Adresse zu. Diese IP-Adresse ermöglicht ausgehende Konnektivität von den Ressourcen zum Internet und zu anderen öffentlichen Endpunkten in Microsoft. Dieser Zugriff wird als Standardzugriff in ausgehender Richtung bezeichnet.
Beispiele für explizite ausgehende Konnektivität für virtuelle Computer sind:
- Bereitgestellt in einem Subnetz, das einem NAT-Gateway zugeordnet ist.
- Im Back-End-Pool einer Load Balancer Standard-Instanz mit definierten Ausgangsregeln bereitgestellt.
- Im Back-End-Pool eines öffentlichen Load Balancer vom Typ „Basic“ bereitgestellt.
- Virtuelle Computer mit ihnen explizit zugeordneten öffentlichen IP-Adressen.
Wie und wann standardmäßiger ausgehender Zugriff bereitgestellt wird
Wenn ein virtueller Computer (VM) ohne explizite ausgehende Konnektivitätsmethode bereitgestellt wird, weist Azure ihm eine standardmäßige öffentliche IP-Adresse zu. Diese IP, die als standardmäßige ausgehende Zugriffs-IP bezeichnet wird, gehört Microsoft und kann sich ohne Vorheriges ändern. Für Produktionsworkloads nicht empfohlen.
Hinweis
In einigen Fällen wird virtuellen Computern in einem nicht privaten Subnetz weiterhin eine ausgehende Standard-IP-Adresse zugewiesen, auch wenn eine explizite ausgehende Methode, z. B. ein NAT Gateway oder eine UDR, die Datenverkehr an ein NVA/eine Firewall weiterleitet, konfiguriert ist. Dies bedeutet nicht, dass die ausgehenden Standard-IP-Adressen für ausgehenden Datenverkehr verwendet werden. Dies geschieht nur, wenn diese expliziten Methoden entfernt werden. Um die ausgehenden Standard-IP-Adressen vollständig zu entfernen, muss das Subnetz privat sein, und die virtuellen Computer müssen beendet und ihre Zuordnung muss aufgehoben werden.
Wichtig
Nach dem 31. März 2026 werden neue virtuelle Netzwerke standardmäßig private Subnetze verwenden, was bedeutet, dass eine explizite ausgehende Methode aktiviert werden muss, um öffentliche Endpunkte im Internet und innerhalb von Microsoft zu erreichen. Weitere Informationen finden Sie in der offiziellen Ankündigung. Es wird empfohlen, eine der expliziten Formen der Konnektivität zu verwenden, die im folgenden Abschnitt erläutert werden. Weitere Fragen finden Sie im Abschnitt „Häufig gestellte Fragen: Änderung des Standardverhaltens in privaten Subnetzen“.
Warum wird das Deaktivieren des ausgehenden Standardzugriffs empfohlen?
Sicherheit: Der Standardzugriff im Internet widerspricht zero Trust-Prinzipien.
Klarheit: Explizite Konnektivität wird gegenüber impliziten Zugriff bevorzugt.
Stabilität: Die standardmäßige ausgehende IP ist nicht im Besitz des Kunden und kann sich ändern, was zu potenziellen Unterbrechungen führt.
Einige Beispiele für Konfigurationen, die bei Verwendung des standardmäßigen ausgehenden Zugriffs nicht funktionieren:
- Mehrere NICs auf einem virtuellen Computer können zu inkonsistenten ausgehenden IPs führen
- Das Skalieren von Skalierungssätzen für virtuelle Azure-Computer kann dazu führen, dass ausgehende IPs geändert werden.
- Ausgehende IPs sind nicht konsistent oder zusammenhängend über Instanzen des Skalierungssatzes für virtuelle Computer hinweg
Außerdem greift
- Standardmäßige ausgehende Zugriffs-IPs unterstützen keine fragmentierten Pakete.
- Standardmäßige IPs für ausgehenden Zugriff unterstützen keine ICMP-Pings
Wie kann ich zu einer expliziten Methode der öffentlichen Konnektivität wechseln (und den standardmäßigen ausgehenden Zugriff deaktivieren)?
Übersicht über private Subnetze
- Das Erstellen eines Subnetzes als „privat“ verhindert, dass VMs im Subnetz standardmäßigen ausgehenden Zugriff verwenden, um eine Verbindung mit öffentlichen Endpunkten herzustellen.
- Virtuelle Computer in einem privaten Subnetz können weiterhin über eine explizite ausgehende Verbindung auf das Internet (oder alle öffentlichen Endpunkte in Microsoft) zugreifen.
Hinweis
Bestimmte Dienste funktionieren nicht auf einem virtuellen Computer in einem privaten Subnetz ohne eine explizite Methode des Ausgangs (Beispiele sind Windows-Aktivierung und Windows-Updates).
So konfigurieren Sie private Subnetze
- Wählen Sie im Azure-Portal das Subnetz aus, und aktivieren Sie das Kontrollkästchen, um das private Subnetz wie gezeigt zu aktivieren:
- Mithilfe von PowerShell verwendet das folgende Skript die Namen der Ressourcengruppe und des virtuellen Netzwerks und durchläuft jedes Subnetz, um ein privates Subnetz zu aktivieren.
$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
- Aktualisieren Sie mithilfe der CLI das Subnetz mit az network vnet subnet update und legen Sie
--default-outboundauf FALSCH fest
az network vnet subnet update --resource-group rgname --name subnetname --vnet-name vnetname --default-outbound false
- Stellen Sie mit einer Azure Resource Manager-Vorlage den Wert des Parameters
defaultOutboundAccessauf „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
}
}
]
}
}
]
}
Einschränkungen privater Subnetze
Zum Aktivieren oder Aktualisieren von Betriebssystemen virtueller Computer, z. B. Windows, ist eine explizite ausgehende Konnektivitätsmethode erforderlich.
Bei Konfigurationen mit benutzerdefinierten Routen (USER Defined Routes, UDRs) funktionieren alle konfigurierten Routen mit dem nächsten Hoptyp
Internetin einem privaten Subnetz nicht mehr.Ein gängiges Beispiel ist die Verwendung einer UDR, um den Datenverkehr zu einer vorgelagerten virtuellen Netzwerk-Appliance/Firewall zu leiten, wobei bestimmte Azure-Diensttags von der Überprüfung ausgenommen sind. Dies geschieht durch die Konfiguration von Routen zu diesen Service-Tags mit dem Typ
Internetdes nächsten Hops. In diesem Szenario konfigurieren Sie Folgendes:Eine Standardroute für das Ziel 0.0.0.0/0, wobei im Allgemeinen der nächste Hoptyp „Virtual Appliance“ gilt.
Mindestens eine Route wird für Diensttagziele mit dem nächsten Hoptyp
Internetkonfiguriert, um die NVA/Firewall zu umgehen. Wenn keine explizite ausgehende Konnektivitätsmethode auch für die Quelle der Verbindung mit diesen Zielen konfiguriert ist, schlagen Versuche zum Herstellen einer Verbindung mit diesen Zielen fehl, da der standardmäßige ausgehende Zugriff in einem privaten Subnetz nicht standardmäßig verfügbar ist.
Diese Einschränkung gilt nicht für die Verwendung von Dienstendpunkten, die einen anderen nächsten Hoptyp
VirtualNetworkServiceEndpointverwenden. Weitere Informationen finden Sie unter Verwenden von VNET-Dienstendpunkten.
Virtuelle Computer können weiterhin ohne explizite Methode für ausgehenden Datenverkehr auf Azure Storage-Konten in derselben Region in einem privaten Subnetz zugreifen. Es wird empfohlen, NSGs zum Steuern der ausgehenden Konnektivität zu verwenden.
Private Subnetze gelten nicht für delegierte oder verwaltete Subnetze, die für das Hosting von PaaS-Diensten verwendet werden. In diesen Szenarien wird die ausgehende Konnektivität vom einzelnen Dienst verwaltet.
Wichtig
Wenn ein Back-End-Pool für das Lastenausgleichsmodul durch IP-Adresse konfiguriert ist, verwendet er den standardmäßigen ausgehenden Zugriff aufgrund eines laufenden bekannten Problems. Für sichere standardmäßige Konfigurationen und Anwendungen mit hohen Anforderungen an ausgehenden Datenverkehr ordnen Sie den VMs im Back-End-Pool Ihres Lastenausgleichs ein NAT-Gateway zu, um den Datenverkehr zu sichern. Weitere Informationen zu vorhandenen bekannten Problemen.
Hinzufügen einer expliziten ausgehenden Methode
- Dem Subnetz Ihres virtuellen Computers ein NAT-Gateway zuordnen. Beachten Sie, dass dies die empfohlene Methode für die meisten Szenarien ist.
- Ordnen Sie Load Balancer Standard mit konfigurierten Ausgangsregeln zu.
- Ordnen Sie einer der Netzwerkschnittstellen des virtuellen Computers eine öffentliche Standard-IP-Adresse zu.
- Fügen Sie ihrem virtuellen Netzwerk eine Firewall oder eine NVA (Network Virtual Appliance) hinzu, und verweisen Sie mithilfe einer benutzerdefinierten Route (UDR) auf den Datenverkehr.
Verwenden des flexiblen Orchestrierungsmodus für Virtual Machine Scale Sets
- Flexible Skalierungen sind standardmäßig sicher. Keiner der Instanzen, die über flexible Skalierungsgruppen erstellt werden, verfügt über die Standard-IP-Adresse für den ausgehenden Zugriff, die ihnen zugeordnet ist, sodass eine explizite ausgehende Methode erforderlich ist. Weitere Informationen finden Sie unter Flexibler Orchestrierungsmodus für Virtual Machine Scale Sets
Häufig gestellte Fragen: Löschen der Standardwarnung für ausgehende IP-Adressen
Warum wird eine Warnung angezeigt, die besagt, dass ich eine ausgehende Standard-IP-Adresse auf meinem virtuellen Computer habe?
Es gibt einen NIC-Level-Parameter (defaultOutboundConnectivityEnabled), der nachverfolgt, ob die Standard-Ausgangs-IP einer VM/Virtual Machine Scale Set-Instanz zugeordnet ist. Dies wird verwendet, um ein Azure Portal-Banner für VM/Virtual Machine Scale Set zu generieren, das diesen Status festlegt. Es gibt auch spezifische Azure Advisor-Empfehlungen mit diesen Informationen für Ihre Abonnements. Wenn Sie sehen möchten, welchen Ihrer virtuellen Maschinen oder Virtual Machine Scale Sets eine ausgehende Standard-IP zugewiesen ist, gehen Sie folgendermaßen vor:
- Geben Sie "Advisor" in die Suchleiste im Azure-Portal ein, und wählen Sie diese Option aus, wenn sie angezeigt wird.
- Wählen Sie "Operational Excellence" aus.
- Suchen Sie nach den Empfehlungen ‚Add explicit outbound method to disable default outbound‘ und/oder ‚Add explicit outbound method to disable default outbound for Virtual Machine Scale Sets‘ (beachten Sie, dass es sich hierbei um zwei verschiedene Elemente handelt)
- Wenn eine dieser Optionen vorhanden ist, wählen Sie den entsprechenden Empfehlungsnamen aus, und Sie sehen die Netzwerkschnittstellenkarten (NICs) aller virtuellen Maschinen/Virtual Machine Scale Set-Instanzen, bei denen standardmäßig der ausgehende Datenverkehr aktiviert ist.
Gewusst wie: Wie lösche ich diese Warnung?
- Eine explizite Methode für den ausgehenden Datenverkehr muss für das gekennzeichnete VM/Virtual Machine Scale Set verwendet werden. Im Abschnitt oben finden Sie verschiedene Optionen.
- Das Subnetz sollte als privat deklariert werden, um zu verhindern, dass neue ausgehende Standard-IP-Adressen erstellt werden.
- Alle anwendbaren virtuellen Computer im Subnetz mit dem Flag müssen beendet und ihre Zuordnung muss aufgehoben werden, damit die Änderungen im Parameter auf NIC-Ebene widergespiegelt und das Flag gelöscht werden kann. (Beachten Sie, dass dies auch im umgekehrten Fall gilt. Damit einem Computer eine ausgehende -Standard-IP-Adresse zugewiesen wird, nachdem der Parameter auf Subnetzebene auf „false“ festgelegt wurde, ist eine Beendigung/Aufhebung der Zuordnung des virtuellen Computers erforderlich.)
Ich verwende bereits eine explizite Methode für ausgehenden Datenverkehr. Warum wird diese Warnung weiterhin angezeigt?
In einigen Fällen wird virtuellen Computern in einem nicht privaten Subnetz weiterhin eine ausgehende Standard-IP-Adresse zugewiesen, auch wenn eine explizite ausgehende Methode, z. B. ein NAT Gateway oder eine UDR, die Datenverkehr an ein NVA/eine Firewall weiterleitet, konfiguriert ist. Dies bedeutet nicht, dass die ausgehenden Standard-IP-Adressen für ausgehenden Datenverkehr verwendet werden. Dies geschieht nur, wenn diese expliziten Methoden entfernt werden. Um die ausgehenden Standard-IP-Adressen vollständig zu entfernen (und die Warnung zu entfernen), muss das Subnetz privat sein, und die virtuellen Computer müssen beendet und ihre Zuordnung aufgehoben werden.
Häufig gestellte Fragen: Änderung des Standardverhaltens auf private Subnetze
Was bedeutet die Standardeinstellung für private Subnetze und wie wird sie implementiert?
Bei der API-Version, die nach dem 31. März 2026 veröffentlicht werden wird, wird die defaultOutboundAccess-Eigenschaft für Subnetze in neuen VNETs standardmäßig auf „false“ festgelegt. Diese Änderung macht Subnetze standardmäßig privat und verhindert die Generierung standardmäßiger ausgehender IPs für virtuelle Computer in diesen Subnetzen. Dieses Verhalten gilt für alle Konfigurationsmethoden – ARM-Vorlagen, Azure-Portal, PowerShell und CLI. Frühere Versionen von ARM-Vorlagen (oder Tools wie Terraform, die ältere Versionen angeben können) legen weiterhin "defaultOutboundAccess" als Null fest, was implizit ausgehenden Zugriff zulässt.
Was geschieht mit meinen vorhandenen VNETs und virtuellen Computern? Was ist mit neuen virtuellen Computern, die in vorhandenen VNETs erstellt wurden?
Es werden keine Änderungen an vorhandenen VNETs vorgenommen. Dies bedeutet, dass sowohl vorhandene virtuelle Computer als auch neu erstellte virtuelle Computer in diesen VNETs weiterhin standardmäßige ausgehende IP-Adressen generieren, es sei denn, die Subnetze werden manuell so geändert, dass sie privat werden.
Was ist mit neuen virtuellen Netzwerkbereitstellungen? Meine Infrastruktur hat eine Abhängigkeit von standardmäßigen ausgehenden IPs und ist derzeit nicht bereit, zu privaten Subnetzen zu wechseln.
Sie können Subnetze weiterhin mit einer beliebigen unterstützten Methode (ARM-Vorlagen, Portal, CLI, PowerShell) als nicht privat konfigurieren. Dadurch wird die Kompatibilität für Infrastrukturen sichergestellt, die auf ausgehenden Standard-IPs basieren und noch nicht für den Übergang zu privaten Subnetzen bereit sind.
Nächste Schritte
Weitere Informationen zu ausgehenden Verbindungen in Azure finden Sie unter: