Azure Virtual Network – häufig gestellte Fragen

  • Artikel

Grundlagen zu Virtual Networks

Was ist ein Azure Virtual Network (VNet)?

Ein Azure Virtual Network (VNet) ist eine Darstellung Ihres eigenen Netzwerks in der Cloud. Es ist eine logische Isolierung von der Azure-Cloud für Ihr Abonnement. Mit VNets können Sie virtuelle private Netzwerke (VPNs) in Azure bereitstellen und verwalten und die VNets optional mit anderen VNets in Azure oder mit Ihrer lokalen IT-Infrastruktur verbinden, um hybride oder standortübergreifende Lösungen zu erstellen. Jedes erstellte VNet verfügt über einen eigenen CIDR-Block und kann mit anderen VNets und lokalen Netzwerken verbunden werden, solange sich die CIDR-Blöcke nicht überlappen. Sie können zudem die DNS-Servereinstellungen für VNets steuern und das VNet in Subnetze segmentieren.

Verwenden Sie VNets für Folgendes:

  • Erstellen eines dedizierten privaten VNET, das auf die Cloud beschränkt ist. Manchmal benötigen Sie keine standortübergreifende Konfiguration für Ihre Lösung. Wenn Sie ein VNet erstellen, können die Dienste und virtuellen Computer des VNet direkt und sicher in der Cloud miteinander kommunizieren. Sie können trotzdem in Ihrer Lösung Endpunktverbindungen für die virtuellen Computer und Dienste konfigurieren, die eine Internetkommunikation erfordern.

  • Sicheres Erweitern des Rechenzentrums. Mit VNets können Sie herkömmliche Standort-zu-Standort (S2S)-VPNs erstellen, um die Kapazität des Rechenzentrums sicher zu skalieren. S2S-VPNs verwenden IPsec, um eine sichere Verbindung zwischen dem unternehmenseigenen VPN-Gateway und Azure bereitzustellen.

  • Unterstützung von Hybrid Cloud-Szenarien. VNets bieten flexible Möglichkeiten, verschiedene Hybrid Cloud-Szenarios zu unterstützen. Sie können cloudbasierte Anwendungen auf sichere Weise mit beliebigen lokalen Systemen wie z. B. Mainframes oder Unix-Systemen verbinden.

Wie fange ich an?

Auf der Webseite Dokumentation zu virtuellen Netzwerken finden Sie Informationen zu den ersten Schritten. Hierbei handelt es sich um Übersichts- und Bereitstellungsinformationen für alle VNET-Features.

Können VNets ohne standortübergreifende Konnektivität verwendet werden?

Ja. Sie können ein VNET verwenden, ohne es mit Ihrer lokalen Umgebung verbinden zu müssen. Sie können beispielsweise Microsoft Windows Server-Active Directory-Domänencontroller und SharePoint-Farmen nur in einem Azure-VNET ausführen.

Kann ich eine WAN-Optimierung zwischen VNets oder einem VNet und meinem lokalen Rechenzentrum durchführen?

Ja. Sie können ein virtuelles Netzwerkgerät für die WAN-Optimierung von mehreren Anbietern über den Azure Marketplace bereitstellen.

Konfiguration

Welche Tools werden zum Erstellen eines VNet verwendet?

Sie können die folgenden Tools zum Erstellen oder Konfigurieren eines VNet verwenden:

Welche Adressbereiche kann ich in meinen VNets verwenden?

Es wird empfohlen, die in RFC 1918 aufgelisteten Adressbereiche zu verwenden, die von der IETF für private, nicht routingfähige Adressräume reserviert wurden:

  • 10.0.0.0 – 10.255.255.255 (10/8-Präfix)
  • 172.16.0.0 – 172.31.255.255 (172.16/12-Präfix)
  • 192.168.0.0 – 192.168.255.255 (Präfix: 192.168/16)

Sie können auch den freigegebenen Adressraum bereitstellen, der in RFC 6598 reserviert ist und in Azure als privater IP-Adressraum behandelt wird:

  • 100.64.0.0 bis 100.127.255.255 (Präfix: 100.64/10)

Andere Adressräume, einschließlich aller anderen von IETF anerkannten privaten, nicht routingbaren Adressräumen, können funktionieren, haben aber möglicherweise unerwünschte Nebenwirkungen.

Die folgenden Adressbereiche können nicht hinzugefügt werden:

  • 224.0.0.0/4 (Multicast)
  • 255.255.255.255/32 (Übertragung)
  • 127.0.0.0/8 (Loopback)
  • 169.254.0.0/16 (verbindungslokal)
  • 168.63.129.16/32 (Internes DNS)

Können öffentliche IP-Adressen in VNets verwendet werden?

Ja. Weitere Informationen zu öffentlichen IP-Adressbereichen finden Sie unter Create, change, or delete a virtual network (Erstellen, Ändern oder Löschen eines virtuellen Netzwerks). Auf öffentliche IP-Adressen kann nicht direkt über das Internet zugegriffen werden.

Ist die Anzahl von Subnetzen im VNet begrenzt?

Ja. Ausführliche Informationen finden Sie im Artikel zu den Einschränkungen für Azure-Abonnements. Die Adressräume von Subnetzen können sich nicht überlappen.

Unterliegen die in den Subnetzen verwendeten IP-Adressen bestimmten Beschränkungen?

Ja. Azure reserviert die ersten vier IP-Adressen und letzte IP-Adresse, d. h. insgesamt 5 IP-Adressen in jedem Subnetz.

Der IP-Adressbereich 192.168.1.0/24 weist beispielsweise die folgenden reservierten Adressen auf:

  • 192.168.1.0: Netzwerkadresse
  • 192.168.1.1: Von Azure für das Standardgateway reserviert
  • 192.168.1.2, 192.168.1.3: Von Azure zum Zuordnen der Azure DNS-IPs zum VNet-Adressraum reserviert
  • 192.168.1.255: Netzwerkadresse für Broadcasts

Wie ist die minimale und maximale Größe von VNets und Subnetzen?

Das kleinste unterstützte IPv4-Subnetz ist /29, das größte Subnetz ist /2 (gemäß CIDR-Subnetzdefinitionen). IPv6-Subnetze müssen exakt /64 groß sein.

Können VLANs mithilfe von VNets in Azure integriert werden?

Nein. VNets sind Layer-3-Overlays. Layer-2-Semantik wird in Azure nicht unterstützt.

Können benutzerdefinierte Routingrichtlinien für VNets und Subnetze angegeben werden?

Ja. Sie können eine Routingtabelle erstellen und einem Subnetz zuordnen. Weitere Informationen zum Routing in Azure finden Sie unter Routing von Datenverkehr für virtuelle Netzwerke.

Was sieht das Verhalten aus, wenn ich sowohl eine Netzwerksicherheitsgruppe (NSG) als auch benutzerdefinierte Routen (UDR) im Subnetz anwende?

Für eingehenden Datenverkehr werden eingehende NSG-Regeln verarbeitet. Für ausgehenden Datenverkehr werden ausgehende NSG-Regeln gefolgt von UDR-Regeln verarbeitet.

Wie sieht das Verhalten aus, wenn ich eine Netzwerksicherheitsgruppe (NSG) für die Netzwerkkarte und ein Subnetz für einen virtuellen Computer anwende?

Wenn NSGs sowohl auf Netzwerkkarten und Subnetze eines virtuellen Computers angewendet werden, wird die NSG auf Subnetzebene gefolgt von der NSG auf Netzwerkkartenebene für eingehenden Datenverkehr und die NSG auf Netzwerkkartenebene gefolgt von der NSG auf Subnetzebene für ausgehenden Datenverkehr verarbeitet.

Unterstützen VNets Multicasting oder Broadcasting?

Nein. Multicast und Broadcast werden nicht unterstützt.

Welche Protokolle werden innerhalb von VNets unterstützt?

Sie können die Protokolle TCP, UDP und ICMP TCP/IP in VNets verwenden. Unicast wird in virtuellen Netzwerken unterstützt. Verkapselte Multicast-, Broadcast- und IP-in-IP-Pakete sowie GRE-Pakete (Generic Routing Encapsulation) werden blockiert. Nicht möglich ist das Verwenden von DHCP (Dynamic Host Configuration Protocol) über Unicast (Quellport UDP/68, Zielport UDP/67). Gleiches gilt für den UDP-Quellport 65330, der für den Host reserviert ist. Unter Kann ich einen DHCP-Server in einem VNet bereitstellen? finden Sie weitere Informationen, was für DHCP unterstützt wird und was nicht.

Kann ich einen DHCP-Server in einem VNet bereitstellen?

Azure-VNets stellen den DHCP-Dienst und DNS für VMs und Client/Server-DHCP (Quellport UDP/68, Zielport UDP/67) bereit. Dies wird in einem VNet nicht unterstützt. Sie können keinen eigenen DHCP-Dienst bereitstellen, um Unicast/Broadcastclient/Server-DHCP-Datenverkehr für Endpunkte in einem VNet zu empfangen und bereitzustellen. Außerdem ist es nicht möglich, einen virtuellen DHCP-Servercomputer mit der Absicht bereitzustellen, DHCP-Datenverkehr vom Typ „Unicast-DHCP-Relay“ (Quellport UDP/67, Zielport UDP/67) zu empfangen.

Kann ich ein Standardgateway in einem VNet pingen?

Nein. Das von Azure bereitgestellte Standardgateway reagiert nicht auf Ping. Sie können jedoch Ihre VNets pingen, um die Konnektivität und Problembehandlung zwischen VMs zu überprüfen.

Können Verbindungsdiagnosen mit "tracert" durchgeführt werden?

Ja.

Können Subnetze hinzugefügt werden, nachdem das VNet erstellt wurde?

Ja. Subnetze können jederzeit zu VNETs hinzugefügt werden, sofern der Subnetzadressbereich nicht Teil eines anderen Subnetzes und ausreichend Platz im Adressbereich des virtuellen Netzwerks verfügbar ist.

Kann die Größe des Subnetzes nach dessen Erstellung geändert werden?

Ja. Sie können ein Subnetz hinzufügen, entfernen, erweitern oder verkleinern, wenn darin keine VMs oder Dienste bereitgestellt werden.

Kann ein VNET nach dem Erstellen geändert werden?

Ja. Sie können die in einem VNet verwendeten CIDR-Blöcke hinzufügen, entfernen und ändern.

Kann eine Verbindung mit dem Internet hergestellt werden, wenn Dienste in einem VNET ausgeführt werden?

Ja. Alle Dienste, die in einem VNET bereitgestellt werden, können eine ausgehende Verbindung mit dem Internet herstellen. Weitere Informationen zu ausgehenden Internetverbindungen in Azure finden Sie unter Ausgehende Verbindungen in Azure. Wenn Sie mit einer Ressource eine Verbindung in eingehender Richtung herstellen möchten, die über Resource Manager bereitgestellt wurde, muss der Ressource eine öffentliche IP-Adresse zugewiesen sein. Weitere Informationen zu öffentlichen IP-Adressen finden Sie unter Erstellen, Ändern oder Löschen einer öffentlichen IP-Adresse. Jeder in Azure bereitgestellte Azure-Clouddienst verfügt über eine öffentlich adressierbare, zugewiesene VIP-Adresse. Sie müssen Eingabeendpunkte für PaaS-Rollen und Endpunkte für virtuelle Computer definieren, damit diese Dienste Verbindungen über das Internet annehmen können.

Unterstützen VNets IPv6?

Ja, VNets können „Nur-IPv4“ oder „Dual-Stack“ sein (IPv4 und IPv6). Ausführliche Informationen finden Sie unter Übersicht über IPv6 für Azure Virtual Networks.

Kann sich ein VNet über mehrere Regionen erstrecken?

Nein. Ein VNet ist auf eine Region beschränkt. Ein virtuelles Netzwerk erstreckt sich jedoch über Verfügbarkeitszonen. Weitere Informationen zu Verfügbarkeitszonen finden Sie unter Overview of Availability Zones in Azure (Preview) (Übersicht über Verfügbarkeitszonen in Azure (Vorschauversion)). Sie können mithilfe von Peering in virtuellen Netzwerken Verbindungen zwischen virtuellen Netzwerken in verschiedenen Regionen herstellen. Weitere Informationen finden Sie unter Peering in virtuellen Netzwerken.

Kann ein VNet mit einem anderen VNet in Azure verbunden werden?

Ja. Sie können zwei VNETs miteinander verbinden, indem Sie Folgendes verwenden:

Namensauflösung (DNS)

Welche DNS-Optionen sind für VNets verfügbar?

Eine Übersicht über die verfügbaren DNS-Optionen finden Sie in der Entscheidungstabelle auf der Seite Namensauflösung für virtuelle Computer und Rolleninstanzen .

Können DNS-Server für ein VNet angegeben werden?

Ja. Sie haben die Möglichkeit, IP-Adressen von DNS-Servern in den Einstellungen des VNet anzugeben. Die Einstellung gilt als DNS-Standardserver für alle virtuellen Computer im VNET.

Wie viele DNS-Server können angegeben werden?

Siehe Einschränkungen für Azure-Abonnements und Dienste, Kontingente und Einschränkungen

Können DNS-Server geändert werden, nachdem das Netzwerk erstellt wurde?

Ja. Sie können die Liste der DNS-Server für das VNet jederzeit ändern. Wenn Sie Ihre DNS-Serverliste ändern, müssen Sie für alle betroffenen VMs im VNET eine Verlängerung der DHCP-Lease durchführen, damit die neuen DNS-Einstellungen wirksam werden. Für VMs, auf denen das Windows-Betriebssystem ausgeführt wird, können Sie hierzu ipconfig /renew direkt auf der VM eingeben. Informationen zu anderen Betriebssystemtypen finden Sie in der Dokumentation zur Verlängerung der DHCP-Lease für den jeweiligen Betriebssystemtyp.

Was ist der von Azure bereitgestellte DNS-Dienst, und wie wird er bei VNets verwendet?

Der von Azure bereitgestellte DNS-Dienst ist ein von Microsoft angebotener mehrinstanzenfähiger DNS-Dienst. In Azure werden Ihre gesamten VMs und Clouddienst-Rolleninstanzen dieses Diensts registriert. Dieser Dienst stellt die Namensauflösung nach dem Hostnamen für virtuelle Computer und Rolleninstanzen, die im gleichen Clouddienst enthalten sind, und nach dem FQDN für virtuelle Computer und Rolleninstanzen im gleichen VNet zur Verfügung. Weitere Informationen zum DNS finden Sie unter Namensauflösung für virtuelle Computer und Rolleninstanzen.

Die mandantenübergreifende Namensauflösung mithilfe des von Azure bereitgestellten DNS-Diensts ist auf die ersten 100 Clouddienste in einem VNET beschränkt. Diese Einschränkung gilt nicht, wenn Sie einen eigenen DNS-Server verwenden.

Können DNS-Einstellungen für einzelne virtuelle Computer oder Clouddienste überschrieben werden?

Ja. Sie können DNS-Server pro VM oder Clouddienst festlegen, um die standardmäßigen Netzwerkeinstellungen zu überschreiben. Es wird jedoch empfohlen, nach Möglichkeit den netzwerkweiten DNS-Server zu verwenden.

Können benutzerdefinierte DNS-Suffixe angegeben werden?

Nein. Sie können kein benutzerdefiniertes DNS-Suffix für die VNets angeben.

Verbinden von virtuellen Computern

Können virtuelle Computer in einem VNet bereitgestellt werden?

Ja. Alle Netzwerkschnittstellen (NICs) einer VM, die mit dem Resource Manager-Bereitstellungsmodell bereitgestellt wurden, müssen mit einem VNet verbunden sein. VMs, die mit dem klassischen Bereitstellungsmodell bereitgestellt wurden, können optional mit einem VNet verbunden werden.

Wie lauten die unterschiedlichen Typen von IP-Adressen, die ich VMs zuweisen kann?

  • Privat: Wird allen NICs jeder einzelnen VM zugewiesen. Die Adresse wird entweder mit der statischen oder dynamischen Methode zugewiesen. Private IP-Adressen werden aus dem Bereich zugewiesen, den Sie in den Subnetzeinstellungen Ihres VNet angegeben haben. Mit dem klassischen Bereitstellungsmodell bereitgestellten Ressourcen werden private IP-Adressen zugewiesen, selbst wenn keine Verbindung mit einem VNet besteht. Das Verhalten der Zuordnungsmethode unterscheidet sich abhängig davon, ob eine Ressource mit dem Resource Manager-Bereitstellungsmodell oder mit dem klassischen Bereitstellungsmodell bereitgestellt wurde:

    • Resource Manager: Eine mit der dynamischen oder statischen Methode zugewiesene private IP-Adresse bleibt einem virtuellen Computer (Resource Manager) zugewiesen, bis die Ressource gelöscht wird. Der Unterschied besteht darin, dass bei Verwendung der statischen Methode Sie die zuzuweisende Adresse auswählen und bei Verwendung der dynamischen Methode Azure die Adresse auswählt.
    • Klassisch: Eine mit der dynamischen Methode zugewiesene private IP-Adresse ändert sich möglicherweise, wenn ein virtueller Computer (klassisch) neu gestartet wird, nachdem er sich im Zustand „Beendet“ (Zuordnung aufgehoben) befand. Wenn Sie sicherstellen müssen, dass sich die private IP-Adresse einer Ressource, die über das klassische Bereitstellungsmodell bereitgestellt wurde, nie ändert, weisen Sie eine private IP-Adresse mit der statischen Methode zu.

  • Öffentlich: Kann optional NICs von VMs zugewiesen werden, die über das Azure Resource Manager-Bereitstellungsmodell bereitgestellt wurden. Die Adresse kann mit der statischen oder der dynamischen Zuteilungsmethode zugewiesen werden. Alle VMs und Cloud Services-Rolleninstanzen, die über das klassische Bereitstellungsmodell bereitgestellt werden, sind in einem Clouddienst vorhanden, dem eine dynamische öffentliche virtuelle IP-Adresse (VIP) zugewiesen ist. Eine öffentliche statische IP-Adresse, die als reservierte IP-Adresse bezeichnet wird, kann optional als VIP zugewiesen werden. Sie können öffentliche IP-Adressen einzelnen VMs oder Cloud Services-Rolleninstanzen zuweisen, die mit dem klassischen Bereitstellungsmodell bereitgestellt wurden. Diese Adressen werden als ILPIP-Adressen (Instance Level Public IP, öffentliche IP-Adresse auf Instanzebene) bezeichnet und können dynamisch zugewiesen werden.

Kann ich eine private IP-Adresse für einen virtuellen Computer reservieren, den ich zu einem späteren Zeitpunkt erstelle?

Nein. Eine private IP-Adresse kann nicht reserviert werden. Wenn eine private IP-Adresse verfügbar ist, wird sie einem virtuellen Computer oder einer Rolleninstanz durch den DHCP-Server zugewiesen. Der virtuelle Computer kann der Computer sein, dem Sie die interne IP-Adresse zuweisen möchten. Es kann aber auch ein anderer Computer sein. Sie können aber die private IP-Adresse eines bereits erstellten virtuellen Computers in eine verfügbare private IP-Adresse ändern.

Ändern sich private IP-Adressen für virtuelle Computer in einem VNet?

Das ist unterschiedlich. Wenn der virtuelle Computer über Resource Manager bereitgestellt wurde, ändern sie sich nicht, unabhängig davon, ob die IP-Adresse mit der statischen oder der dynamischen Zuordnungsmethode zugewiesen wurde. Wenn der virtuelle Computer über das klassische Bereitstellungsmodell bereitgestellt wurde, können sich dynamische IP-Adressen ändern, wenn ein virtueller Computer gestartet wird, nachdem er im beendeten Zustand (Zuordnung aufgehoben) war. Die Adresse eines virtuellen Computers, der über eins der beiden Bereitstellungsmodelle bereitgestellt wurde, wird freigegeben, wenn der virtuelle Computer gelöscht wird.

Kann ich IP-Adressen den NICs im VM-Betriebssystem manuell zuordnen?

Ja, aber dies wird nur empfohlen, wenn es unbedingt notwendig ist, etwa beim Zuweisen mehrerer IP-Adressen zu einem virtuellen Computer. Ausführliche Informationen finden Sie unter Zuweisen von mehreren IP-Adressen zu virtuellen Computern mithilfe des Azure-Portals. Falls sich die IP-Adresse ändert, die einer an einen virtuellen Computer angefügten Azure-NIC zugewiesen ist, und die IP-Adresse im VM-Betriebssystem sich davon unterscheidet, geht die Konnektivität zum virtuellen Computer verloren.

Was passiert mit meinen IP-Adressen, wenn ich einen Clouddienst-Bereitstellungsslot beende oder einen virtuellen Computer über das Betriebssystem herunterfahre?

Nichts. Die IP-Adressen (öffentliche VIP, öffentlich und privat) bleiben dem Clouddienst-Bereitstellungsslot bzw. der VM zugewiesen.

Können virtuelle Computer ohne erneute Bereitstellung zwischen Subnetzen in einem VNET verschoben werden?

Ja. Weitere Informationen finden Sie im Artikel Verschieben eines virtuellen Computers oder einer Rolleninstanz in ein anderes Subnetz.

Kann eine statische MAC-Adresse für einen virtuellen Computer konfiguriert werden?

Nein. Eine MAC-Adresse kann nicht statisch konfiguriert werden.

Bleibt die MAC-Adresse eines virtuellen Computers nach ihrer Erstellung unverändert?

Ja. Die MAC-Adresse bleibt für eine VM so lange erhalten, bis sie gelöscht wird. Dabei spielt es keine Rolle, ob die VM über das Resource Manager- oder das klassische Bereitstellungsmodell bereitgestellt wurde. Bisher wurde die MAC-Adresse freigegeben, wenn die VM beendet (Aufhebung der Zuordnung) wurde, aber jetzt wird die MAC-Adresse auch dann beibehalten, wenn sich die VM im nicht zugeordneten Zustand befindet. Die MAC-Adresse bleibt der Netzwerkschnittstelle zugewiesen, bis die Netzwerkschnittstelle gelöscht oder die private IP-Adresse, die der primären IP-Konfiguration der primären Netzwerkschnittstelle zugewiesen ist, geändert wird.

Kann ich von einem virtuellen Computer in einem VNet eine Verbindung mit dem Internet herstellen?

Ja. Für alle in einem VNet bereitgestellten VMs und Cloud Services-Rolleninstanzen kann eine Verbindung mit dem Internet hergestellt werden.

Azure-Dienste mit Verbindung mit VNets

Kann ich Azure App Service-Web-Apps mit einem VNet verwenden?

Ja. Sie können Web-Apps in einem VNet bereitstellen. Dazu verwenden Sie eine ASE (App Service-Umgebung), verbinden das Back-End Ihrer Apps mit Ihren VNets mit VNet-Integration und sperren den eingehenden Datenverkehr zu Ihrer App mit Dienstendpunkten. Weitere Informationen finden Sie in den folgenden Artikeln:

Können Cloud Services mit Web- und Workerrollen (PaaS) in einem VNet bereitgestellt werden?

Ja. Sie können Cloud Services-Rolleninstanzen (optional) in VNets bereitstellen. Hierfür geben Sie den Namen des VNet und die Rollen-/Subnetzzuordnungen im Netzwerkkonfigurationsabschnitt der Dienstkonfiguration an. Sie müssen keine Binärdateien aktualisieren.

Kann ich für eine VM-Skalierungsgruppe eine Verbindung mit einem VNet herstellen?

Ja. Sie müssen für eine VM-Skalierungsgruppe eine Verbindung mit einem VNet herstellen.

Gibt es eine vollständige Liste der Azure-Dienste, über die ich Ressourcen in einem VNET bereitstellen kann?

Ja. Ausführliche Informationen finden Sie unter Integration virtueller Netzwerke für Azure-Dienste.

Wie kann ich den Zugriff auf Azure PaaS-Ressourcen über ein VNET einschränken?

Ressourcen, die über ausgewählte Azure PaaS-Dienste (wie Azure Storage und Azure SQL-Datenbank) bereitgestellt werden, können den Netzwerkzugriff auf das VNET durch die Verwendung von virtuellen Netzwerkdienstendpunkten oder Azure Private Link einschränken. Weitere Informationen finden Sie in der Übersicht über VNET-Dienstendpunkte und der Übersicht über Azure Private Link.

Können Dienste in und aus VNets verschoben werden?

Nein. Sie können Dienste nicht in oder aus VNets verschieben. Wenn Sie eine Ressource in ein anderes VNET verschieben möchten, müssen Sie die Ressource löschen und neu bereitstellen.

Sicherheit

Welches Sicherheitsmodell wird für VNets verwendet?

VNETs werden von anderen VNETs und von anderen in der Azure-Infrastruktur gehosteten Diensten isoliert ausgeführt. Die Vertrauensstellungsgrenze entspricht der Begrenzung des VNet.

Kann ich den Flow von eingehendem oder ausgehendem Datenverkehr auf Ressourcen mit VNet-Verbindung beschränken?

Ja. Sie können Netzwerksicherheitsgruppen auf einzelne Subnetze in einem VNet, an ein VNet angefügte NICs oder beides anwenden.

Kann ich zwischen Ressourcen mit VNet-Verbindung eine Firewall einrichten?

Ja. Sie können ein virtuelles Netzwerkgerät für eine Firewall von mehreren Anbietern über den Azure Marketplace bereitstellen.

Sind Informationen zum Schützen von VNets verfügbar?

Ja. Ausführliche Informationen finden Sie im Artikel Die Netzwerksicherheit in Azure im Überblick.

Werden in virtuellen Netzwerken Kundendaten gespeichert?

Nein. In virtuellen Netzwerken werden keine Kundendaten gespeichert.

Kann ich die Eigenschaft FlowTimeoutInMinutes für ein ganzes Abonnement festlegen?

Nein. Dies muss beim virtuellen Netzwerk eingestellt werden. Folgendes kann das automatische Festlegen dieser Eigenschaft für größere Abonnements unterstützen:

$Allvnet = Get-AzVirtualNetwork
$time = 4 #The value should be between 4 and 30 minutes (inclusive) to enable tracking, or null to disable tracking. $null to disable. 
ForEach ($vnet in $Allvnet)
{
    $vnet.FlowTimeoutInMinutes = $time
    $vnet | Set-AzVirtualNetwork
}

APIs, Schemas und Tools

Können VNets programmgesteuert verwaltet werden?

Ja. Sie können REST-APIs für VNETs im Rahmen des Azure Resource Manager-Bereitstellungsmodells und des klassischen Bereitstellungsmodells verwenden.

Sind Tools zur Unterstützung von VNets verfügbar?

Ja. Weitere Informationen zur Verwendung von folgenden Tools:

VNet-Peering

Was ist VNET-Peering?

VNET-Peering (das Peering virtueller Netzwerke) ermöglicht Ihnen das Verbinden von virtuellen Netzwerken. Über eine VNET-Peeringverbindung zwischen virtuellen Netzwerken können Sie Datenverkehr zwischen diesen privat über IPv4-Adressen weiterleiten. Virtuelle Computer in den mittels Peering verknüpften VNETs können miteinander kommunizieren, als ob sie sich im gleichen Netzwerks befinden. Diese virtuellen Netzwerke können sich in derselben oder in unterschiedlichen Regionen (dann auch als globales VNET-Peering bezeichnet) befinden. VNET-Peeringverbindungen können auch über mehrere Azure-Abonnements hinweg erstellt werden.

Kann ich eine Peeringverbindung mit einem VNET in einer anderen Region herstellen?

Ja. Globales VNET-Peering ermöglicht Ihnen das Peering mit VNETs in unterschiedlichen Regionen. Globales VNet-Peering ist in allen öffentlichen Azure-Regionen, China-Cloudregionen und Government-Cloudregionen verfügbar. Das globale Peering von öffentlichen Azure-Regionen in nationale Cloudregionen ist nicht möglich.

Wenn die beiden virtuellen Netzwerke in zwei verschiedenen Regionen mittels Peering über das globale VNET-Peering verbunden sind, können Sie über die Front-End-IP des Load Balancer keine Verbindung mit Ressourcen herstellen, die sich hinter einem Load Balancer im Tarif „Basic“ befinden. Diese Einschränkung gilt nicht für einen Load Balancer Standard. Die folgenden Ressourcen können Load Balancer im Tarif „Basic“ verwenden, d. h. Sie können sie nicht über die Front-End-IP-Adresse des Load Balancer über globales VNET-Peering erreichen. Sie können jedoch das globale VNET-Peering verwenden, um die Ressourcen direkt über ihre privaten VNET-IP-Adressen zu erreichen, falls zulässig.

  • VMs hinter Basic-Load Balancern
  • VM-Skalierungsgruppen mit Basic-Load Balancern
  • Redis Cache
  • Application Gateway (v1) SKU
  • Service Fabric
  • API Management (stv1)
  • Active Directory Domain Service (ADDS)
  • Logic Apps
  • HDInsight
  • Azure Batch
  • App Service-Umgebung

Sie können sich mit diesen Ressourcen über ExpressRoute oder VNET-zu-VNET über VNet-Gateways verbinden.

Kann ich VNET-Peering aktivieren, wenn meine virtuellen Netzwerke zu Abonnements in verschiedenen Azure Active Directory-Mandanten gehören?

Ja. Es ist möglich, VNET-Peering (lokal oder global) einzurichten, wenn Ihre Abonnements zu verschiedenen Azure Active Directory-Mandanten gehören. Dies kann über das Portal, mit PowerShell oder mit der CLI erfolgen.

Meine VNET-Peeringverbindung befindet sich im Status Initiiert – warum kann ich keine Verbindung herstellen?

Wenn Ihre Peeringverbindung sich im Status Initiiert befindet, bedeutet dies, dass Sie nur einen Link erstellt haben. Damit eine Verbindung erfolgreich hergestellt werden kann, muss ein bidirektionaler Link erstellt werden. Um beispielsweise eine Peeringverbindung zwischen VNET A und VNET B herzustellen, muss ein Link von VNetA zu VNetB und von VNetB zu VNetA erstellt werden. Nach dem Erstellen beider Links ändert sich der Status in Verbunden.

Meine VNET-Peeringverbindung befindet sich im Zustand Getrennt. Warum kann ich keine Peeringverbindung herstellen?

Wenn Ihre VNET-Peeringverbindung den Zustand Getrennt aufweist, bedeutet dies, dass eine der erstellen Verknüpfungen gelöscht wurde. Um die Peeringverbindung erneut herzustellen, müssen Sie die Verknüpfung löschen und neu erstellen.

Kann ich eine Peeringverbindung meines VNETs mit einem VNET in einem anderen Abonnement herstellen?

Ja. Sie können Peeringverbindungen zwischen VNETs Abonnements und Regionen übergreifend herstellen.

Kann ich eine Peeringverbindung zwischen zwei VNETs mit übereinstimmenden oder sich überlappenden Adressbereichen herstellen?

Nein. Bei sich überlappenden Adressbereichen ist kein VNET-Peering möglich.

Kann ich ein VNet per Peering mit zwei verschiedenen VNets koppeln, wenn die Option „Remotegateway verwenden“ für beide Peerings aktiviert ist?

Nein. Sie können die Option „Remotegateway verwenden“ nur bei einem Peering in einem der VNETs aktivieren.

Für das Erstellen einer VNET-Peeringverbindung fallen keine Gebühren an. Die Datenübertragung über Peeringverbindungen wird in Rechnung gestellt. Siehe hier.

Wird VNET-Peeringdatenverkehr verschlüsselt?

Wenn Azure-Datenverkehr zwischen Rechenzentren (außerhalb physischer Grenzen, die nicht von Microsoft oder im Auftrag von Microsoft kontrolliert werden) bewegt wird, wird auf der zugrunde liegenden Netzwerkhardware eine MACsec-Verschlüsselung der Sicherungsschicht verwendet. Dies gilt für VNET-Peeringdatenverkehr.

Warum hat meine Peeringverbindung den Status Getrennt?

VNET-Peeringverbindungen wechseln in den Status Getrennt, wenn ein VNET-Peeringlink gelöscht wird. Sie müssen beide Links löschen, um erfolgreich eine Peeringverbindung wiederherzustellen.

Wenn ich eine Peeringverbindung zwischen VNetA und VNetB sowie VNetB und VNetC herstelle, bedeutet dies, dass eine Peeringverbindung zwischen VNetA und VNetC besteht?

Nein. Transitives Peering wird nicht unterstützt. Sie müssen hierzu eine Peeringverbindung zwischen VNetA und VNetC herstellen.

Gibt es Bandbreiteneinschränkungen für Peeringverbindungen?

Nein. Für VNET-Peering, ob lokal oder global, bestehen keine Bandbreiteneinschränkungen. Die Bandbreite wird nur durch die VM oder die Computeressource beschränkt.

Wie kann ich Probleme beim VNet-Peering beheben?

Hier ist eine Anleitung zur Problembehandlung, die Sie ausprobieren können.

TAP eines virtuellen Netzwerks

Welche Azure-Regionen sind für den TAP eines virtuellen Netzwerks verfügbar?

Die Vorschau des TAPs für virtuelle Netzwerke ist in allen Azure-Regionen verfügbar. Die überwachten Netzwerkschnittstellen, die TAP-Ressource des virtuellen Netzwerks und die Collector- oder Analyselösung müssen in der gleichen Region bereitgestellt werden.

Unterstützt der TAP eines virtuellen Netzwerks Filterfunktionen für die gespiegelten Pakete?

Filterfunktionen werden in der Vorschauversion des TAP für ein virtuelles Netzwerk nicht unterstützt. Beim Hinzufügen einer TAP-Konfiguration zu einer Netzwerkschnittstelle wird eine Tiefenkopie des gesamten eingehenden und ausgehenden Datenverkehrs an das TAP-Ziel gestreamt.

Können einer überwachten Netzwerkschnittstelle mehrere TAP-Konfigurationen hinzugefügt werden?

Eine überwachte Netzwerkschnittstelle kann nur über eine TAP-Konfiguration verfügen. Überprüfen Sie die einzelne Partnerlösung auf die Möglichkeit zum Streamen mehrerer Kopien des TAP-Datenverkehrs an die Analysetools Ihrer Wahl.

Kann dieselbe TAP-Ressource eines virtuellen Netzwerks Datenverkehr von überwachten Netzwerkschnittstellen in mehr als einem virtuellen Netzwerk aggregieren?

Ja. Dieselbe TAP-Ressource eines virtuellen Netzwerks kann zum Aggregieren von gespiegeltem Datenverkehr von überwachten Netzwerkschnittstellen in virtuellen Netzwerken mit Peering im gleichen Abonnement oder in einem anderen Abonnement verwendet werden. Die TAP-Ressource des virtuellen Netzwerks und der Lastenausgleich oder die Zielnetzwerk-Schnittstelle müssen sich im selben Abonnement befinden. Alle Abonnements müssen demselben Azure Active Directory-Mandanten zugeordnet sein.

Gibt es Überlegungen zur Leistung für Produktionsdatenverkehr, wenn ich eine TAP-Konfiguration für ein virtuelles Netzwerk an einer Netzwerkschnittstelle aktiviere?

Der TAP für virtuelle Netzwerke befindet sich in der Vorschau. Während der Vorschau gibt es keine Vereinbarung zum Servicelevel. Die Funktion darf nicht für Produktionsworkloads verwendet werden. Wenn die Netzwerkschnittstelle eines virtuellen Computers mit einer TAP-Konfiguration aktiviert ist, werden mit den Ressourcen auf dem Azure-Host, der dem virtuellen Computer für das Senden des Produktionsdatenverkehrs zugeordnet ist, auch die Spiegelungsfunktion ausgeführt und die gespiegelten Pakete versendet. Wählen Sie die richtige Größe für einen virtuellen Linux- oder Windows-Computer aus, um sicherzustellen, dass für den virtuellen Computer genügend Ressourcen zum Senden des Produktionsdatenverkehrs und des gespiegelten Datenverkehrs verfügbar sind.

Wird beschleunigter Netzwerkbetrieb für Linux oder Windows mit TAP eines virtuellen Netzwerks unterstützt?

Sie haben die Möglichkeit, eine TAP-Konfiguration an einer Netzwerkschnittstelle hinzuzufügen, die einem virtuellen Computer angefügt ist, für den beschleunigter Netzwerkbetrieb aktiviert ist. Die Leistung und Latenz auf dem virtuellen Computer werden durch das Hinzufügen einer TAP-Konfiguration jedoch beeinträchtigt, da die Auslagerung für Spiegelungsdatenverkehr vom beschleunigten Netzwerkbetrieb in Azure derzeit nicht unterstützt wird.

VNET-Dienstendpunkte

Was ist die richtige Reihenfolge der Vorgänge zum Einrichten von Endpunkten für einen Azure-Dienst?

Das Schützen einer Azure-Dienstressource über Dienstendpunkte erfolgt in zwei Schritten:

  1. Aktivieren von Dienstendpunkten für den Azure-Dienst
  2. Einrichten von VNET-ACLs für den Azure-Dienst

Der erste Schritt ist ein netzwerkseitiger Vorgang, und der zweite Schritt ist ein Vorgang auf der Seite der Dienstressource. Beide Schritte können durch denselben oder verschiedene Administratoren erfolgen, basierend auf den Azure RBAC-Berechtigungen der Administratorrolle. Es wird empfohlen, zunächst Dienstendpunkte für Ihr virtuelles Netzwerk zu aktivieren, bevor Sie VNET-ACLs auf der Seite des Azure-Diensts einrichten. Die Schritte müssen daher in der oben angegebenen Reihenfolge ausgeführt werden, um VNET-Dienstendpunkte einzurichten.

Hinweis

Beide der oben beschriebenen Verfahren müssen ausgeführt werden, bevor Sie den Zugriff auf den Azure-Dienst auf das zulässige VNET und Subnetz einschränken können. Wenn Sie nur die Dienstendpunkte für den Azure-Dienst auf der Netzwerkseite aktivieren, erhalten Sie noch keinen eingeschränkten Zugriff. Sie müssen zusätzlich auch VNET-ACLs auf der Seite des Azure-Diensts festlegen.

Bestimmte Dienste (z. B. Azure SQL und Azure Cosmos DB) lassen Ausnahmen für die oben angegebene Reihenfolge über das Flag IgnoreMissingVnetServiceEndpoint zu. Sobald das Flag auf True festgelegt wurde, können vor dem Einrichten der Dienstendpunkte auf der Netzwerkseite VNET-ACLs auf der Seite des Azure-Diensts festgelegt werden. Azure-Dienste stellen dieses Flag bereit, um Kunden in Fällen zu unterstützen, bei denen Firewalls mit spezifischen IP-Adressen für Azure-Dienste konfiguriert wurden und das Aktivieren der Dienstendpunkte auf der Netzwerkseite zu Verbindungsausfällen führen kann, da die Quell-IP-Adresse von einer öffentlichen IPv4-Adresse in eine private Adresse geändert wird. Durch Einrichten der VNET-ACLs auf der Azure-Dienstseite vor dem Festlegen von Dienstendpunkten auf der Netzwerkseite können Sie Verbindungsausfälle vermeiden.

Befinden sich alle Azure-Dienste in dem vom Kunden bereitgestellten virtuellen Azure-Netzwerk? Wie funktioniert der VNET-Dienstendpunkt mit Azure-Diensten?

Nein, es befinden sich nicht alle Azure-Dienste im virtuellen Netzwerk des Kunden. Bei einem Großteil der Azure-Datendienste wie Azure Storage, Azure SQL und Azure Cosmos DB handelt es sich um mehrmandantenfähige Dienste, auf die über öffentliche IP-Adressen zugegriffen werden kann. Hier erfahren Sie mehr über die Integration virtueller Netzwerke für Azure-Dienste.

Wenn Sie die Funktion für VNET-Dienstendpunkte (Aktivieren eines VNET-Dienstendpunkts auf der Netzwerkseite und Einrichten der entsprechenden VNET-ACLs auf der Azure-Dienstseite) verwenden, wird der Zugriff auf Azure-Dienste auf zulässige VNETs und Subnetze beschränkt.

Wie stellt der VNET-Dienstendpunkt Sicherheit bereit?

Die Funktion für VNET-Dienstendpunkte (Aktivieren eines VNET-Dienstendpunkts auf der Netzwerkseite und Einrichten der entsprechenden VNET-ACLs auf der Azure-Dienstseite) beschränkt den Zugriff für Azure-Dienste auf das zulässige VNET und Subnetz und stellt somit Sicherheit auf Netzwerkebene und Isolierung des Azure-spezifischen Datenverkehrs bereit. Sämtlicher über VNET-Dienstendpunkte geleiteter Datenverkehr durchläuft den Microsoft-Backbone, dadurch wird eine andere Ebene der Isolation über das öffentliche Internet bereitgestellt. Darüber hinaus können Kunden den Zugriff vom öffentlichen Internet auf die Azure-Dienstressourcen auch vollständig entfernen und nur Datenverkehr vom eigenen virtuellen Netzwerk über eine Kombination aus IP-Firewall und VNET-ACLs zulassen, sodass die Azure-Dienstressourcen vor nicht autorisierten Zugriffen geschützt sind.

Was schützt der VNET-Dienstendpunkt – VNET-Ressourcen oder Azure-Dienste?

VNET-Dienstendpunkte helfen dabei, Azure-Dienstressourcen zu schützen. VNET-Ressourcen werden über Netzwerksicherheitsgruppen (NSGs) geschützt.

Fallen Kosten für die Verwendung von VNET-Dienstendpunkten an?

Nein, es fallen keinerlei zusätzliche Kosten für die Verwendung von VNET-Dienstendpunkten an.

Kann ich VNET-Dienstendpunkte aktivieren und VNET-ACLs einrichten, wenn das virtuelle Netzwerk und die Azure-Dienstressourcen zu unterschiedlichen Abonnements gehören?

Ja, das ist möglich. Virtuelle Netzwerke und Ressourcen von Azure-Diensten können sich in demselben oder in unterschiedlichen Abonnements befinden. Es gilt lediglich die Voraussetzung, dass sich das virtuelle Netzwerk und die Azure-Dienstressourcen zu demselben Active Directory-Mandanten gehören.

Kann ich VNET-Dienstendpunkte aktivieren und VNET-ACLs einrichten, wenn das virtuelle Netzwerk und die Azure-Dienstressourcen zu unterschiedlichen AD-Mandanten gehören?

Ja. Dies ist möglich, wenn Sie Dienstendpunkte für Azure Storage und Azure Key Vault verwenden. Für die restlichen Dienste werden VNET-Dienstendpunkte und VNET-ACLs für AD-Mandanten nicht übergreifend unterstützt.

Kann die IP-Adresse eines lokalen Geräts, das über ein Azure Virtual Network-Gateway (VPN) oder ein ExpressRoute-Gateway verbunden ist, über VNet-Dienstendpunkte auf einen Azure-PaaS-Dienst zugreifen?

Standardmäßig sind Azure-Dienstressourcen, die auf virtuelle Netzwerke beschränkt und so geschützt sind, über lokale Netzwerke nicht erreichbar. Wenn Sie Datenverkehr aus der lokalen Umgebung zulassen möchten, müssen Sie auch öffentliche IP-Adressen (meist NAT) aus der lokalen Umgebung bzw. per ExpressRoute zulassen. Diese IP-Adressen können über die Konfiguration der IP-Firewall für die Azure-Dienstressourcen hinzugefügt werden.

Kann ich mit dem VNET-Dienstendpunktfeature Azure-Dienste in mehreren Subnetzen innerhalb eines virtuellen Netzwerks oder mehrerer virtueller Netzwerke verwenden?

Aktivieren Sie zum Schützen von Azure-Diensten in mehreren Subnetzen innerhalb eines virtuellen Netzwerks oder mehrerer virtueller Netzwerke netzwerkseitige Dienstendpunkte in den einzelnen Subnetzen unabhängig voneinander, und schützen Sie Azure-Dienstressourcen dann in allen diesen Subnetzen, indem Sie geeignete VNET-ACLs auf der Azure-Dienstseite einrichten.

Wie kann ich ausgehenden Datenverkehr aus einem virtuellen Netzwerk an Azure-Dienste filtern und weiterhin Dienstendpunkte verwenden?

Wenn Sie den Datenverkehr, der aus dem virtuellen Netzwerk an einen Azure-Dienst fließen soll, untersuchen und filtern möchten, können Sie in diesem virtuellen Netzwerk ein virtuelles Netzwerkgerät bereitstellen. Anschließend können Sie Dienstendpunkte auf das Subnetz anwenden, in dem das virtuelle Netzwerkgerät bereitgestellt wurde, und Ressourcen des Azure-Diensts mithilfe von VNET-ACLs auf dieses Subnetz beschränken. Dieses Szenario kann auch hilfreich sein, wenn Sie den Zugriff auf den Azure-Dienst aus Ihrem virtuellen Netzwerk per Filterung durch ein virtuelles Netzwerkgerät nur auf bestimmte Azure-Ressourcen beschränken möchten. Weitere Informationen finden Sie unter egress with network virtual appliances (Ausgehender Datenverkehr mit virtuellen Netzwerkgeräten).

Was passiert, wenn von außerhalb des VNET auf ein Azure-Dienstkonto zugegriffen wird, für das eine VNET-Zugriffssteuerungsliste (ACL) aktiviert ist?

Es wird einer der HTTP-Fehler 403 oder 404 zurückgegeben.

Können Subnetze eines virtuellen Netzwerks, die in verschiedenen Regionen erstellt wurden, auf ein Azure-Dienstkonto in einer anderen Region zugreifen?

Ja, für die meisten Azure-Dienste können in unterschiedlichen Regionen erstellte virtuelle Netzwerke über die VNET-Dienstendpunkte auf Azure-Dienste in einer anderen Region zugreifen. Wenn sich ein Azure Cosmos DB-Konto z.B. in einer der Regionen „USA, Westen“ oder „USA, Osten“ befindet und sich virtuelle Netzwerke in mehreren Regionen befinden, kann das virtuelle Netzwerk auf Azure Cosmos DB zugreifen. Storage und SQL sind Ausnahmen, die ihrer Natur nach regional sind. Sowohl das virtuelle Netzwerk als auch der Azure-Dienst müssen sich hierbei in derselben Region befinden.

Kann ein Azure-Dienst sowohl eine VNET-ACL als auch eine IP-Firewall aufweisen?

Ja, eine VNET-ACL und eine IP-Firewall können gleichzeitig vorhanden sein. Beide Features ergänzen einander, um Isolation und Sicherheit zu gewährleisten.

Was passiert beim Löschen eines virtuellen Netzwerks oder Subnetzes, das als Dienstendpunkt für Azure-Dienste festgelegt ist?

Das Löschen von VNETs und von Subnetzen sind unabhängige Vorgänge, die auch dann unterstützt werden, wenn Dienstendpunkte für Azure-Dienste aktiviert sind. Wenn für Azure-Dienste VNETs eingerichtet sind, werden beim Löschen eines VNET oder Subnetzes, das als VNET-Dienstendpunkt aktiviert wurde, die mit diesem Azure-Dienst verknüpften VNET-ACL-Informationen für diese VNETs und Subnetze deaktiviert.

Was passiert, wenn ein Azure-Dienstkonto, für das ein VNET-Dienstendpunkt aktiviert ist, gelöscht wird?

Das Löschen eines Azure-Dienstkontos ist ein unabhängiger Vorgang, der auch dann unterstützt wird, wenn der Dienstendpunkt auf der Netzwerkseite aktiviert und VNET-ACLs auf der Azure-Dienstseite eingerichtet sind.

Was passiert mit der IP-Quelladresse einer Ressource (z.B. eines virtuellen Computers in einem Subnetz), für die ein VNET-Dienstendpunkt aktiviert ist?

Wenn VNET-Dienstendpunkte aktiviert sind, verwenden die IP-Quelladressen der Ressourcen im Subnetz des virtuellen Netzwerks keine öffentlichen IPv4-Adressen mehr, sondern private IP-Adressen des virtuellen Azure-Netzwerks, um Datenverkehr an den Azure-Dienst zu leiten. Beachten Sie, dass dies zu Fehlern bei bestimmten IP-Firewalls, die zuvor in den Azure-Diensten für öffentliche IPv4-Adressen festgelegt wurden, führen kann.

Hat die Dienstendpunktroute immer Vorrang?

Dienstendpunkte fügen eine Systemroute hinzu, die Vorrang vor BGP-Routen hat und eine optimale Weiterleitung für den Dienstendpunkt-Datenverkehr ermöglicht. Dienstendpunkte leiten den Datenverkehr der Dienste immer direkt aus Ihrem virtuellen Netzwerk an den Dienst im Microsoft Azure-Backbonenetzwerk weiter. Weitere Informationen zum Auswählen einer Route durch Azure finden Sie unter Datenverkehrsrouting für virtuelle Azure-Netzwerke.

Funktionieren Dienstendpunkte mit ICMP?

Nein. ICMP-Datenverkehr, der aus einem Subnetz mit aktivierten Dienstendpunkten stammt, fließt nicht über den Diensttunnelpfad zum gewünschten Endpunkt. Von Dienstendpunkten wird nur TCP-Datenverkehr verarbeitet. Dies bedeutet Folgendes: Wenn Sie die Latenz oder Konnektivität für einen Endpunkt über Dienstendpunkte testen möchten, wird mit Tools wie Ping und tracert nicht der Pfad angezeigt, der von den Ressourcen im Subnetz genutzt wird.

Wie arbeiten NSGs in einem Subnetz mit Dienstendpunkten zusammen?

Um den Azure-Dienst zu erreichen, müssen NSGs ausgehende Verbindungen zulassen. Wenn Ihre NSGs für sämtlichen ausgehenden Internet-Datenverkehr geöffnet sind, sollte der Datenverkehr für den Dienstendpunkt funktionieren. Sie können den ausgehenden Datenverkehr über Diensttags auch auf Dienst-IP-Adressen beschränken.

Welche Berechtigungen benötige ich, um Dienstendpunkte einzurichten?

Dienstendpunkte können in einem virtuellen Netzwerken unabhängig durch einen Benutzer konfiguriert werden, der Schreibzugriff auf das virtuelle Netzwerk hat. Um Azure-Dienstressourcen in einem VNET zu sichern, muss der Benutzer für die hinzuzufügenden Subnetze über die Berechtigung für „Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action“ verfügen. Diese Berechtigung ist standardmäßig in den integrierten Dienstadministratorrollen enthalten und kann durch Erstellen von benutzerdefinierten Rollen geändert werden. Erfahren Sie mehr über integrierte Rollen und das Zuweisen bestimmter Berechtigungen zu benutzerdefinierten Rollen.

Kann ich über VNET-Dienstendpunkte Datenverkehr aus virtuellen Netzwerken an Azure-Dienste filtern, sodass nur bestimmte Azure-Dienstressourcen zugelassen werden?

Richtlinien für Dienstendpunkte in virtuellen Azure-Netzwerken (VNETs) ermöglichen es Ihnen, virtuellen Netzwerkdatenverkehr an Azure-Dienste zu filtern, sodass nur bestimmte Azure-Dienstressourcen über Dienstendpunkte zugelassen werden. Endpunktrichtlinien bieten eine differenzierte Zugriffssteuerung für virtuellen Netzwerkdatenverkehr an Azure-Dienste. Weitere Informationen zu den Richtlinien für Dienstendpunkte finden Sie hier.

Unterstützt Azure Active Directory (Azure AD) VNet-Dienstendpunkte?

Azure Active Directory (Azure AD) unterstützt nativ keine Dienstendpunkte. Eine vollständige Liste der Azure-Dienste, die VNet-Dienstendpunkte unterstützen, finden Sie hier. Beachten Sie, dass das „Microsoft.AzureActiveDirectory“-Tag, das in den dienstunterstützenden Dienstendpunkten aufgeführt ist, nur für die Unterstützung von Dienstendpunkten für ADLS Gen 1 verwendet wird. Bitte beachten Sie für ADLS Gen1, dass die Integration virtueller Netzwerke für Azure Data Lake Storage Gen1 die Sicherheit von VNET-Dienstendpunkten zwischen Ihrem virtuellen Netzwerk und Azure Active Directory (Azure AD) nutzt, um zusätzliche Sicherheitsansprüche im Zugriffstoken zu generieren. Diese Ansprüche werden dann genutzt, um Ihr virtuelles Netzwerk mit Ihrem Data Lake Storage Gen1-Konto zu authentifizieren und den Zugriff zu ermöglichen. Erfahren Sie mehr über die VNET-Integration für Azure Data Lake Storage Gen1.

Gibt es eine Grenze für die Anzahl der VNET-Dienstendpunkte, die ich in meinem VNET einrichten kann?

Für die Gesamtzahl von VNET-Dienstendpunkten in einem virtuellen Netzwerk gilt keine Beschränkung. Für die Ressource eines Azure-Diensts (z.B. ein Azure Storage-Konto) können Dienste Beschränkungen in Bezug auf die Anzahl von Subnetzen erzwingen, die zum Schützen der Ressource verwendet werden. Die folgende Tabelle zeigt einige Beispielgrenzwerte:

Azure-Dienst Grenzwerte für VNET-Regeln
Azure Storage 200
Azure SQL 128
Azure Synapse Analytics 128
Azure Key Vault 200
Azure Cosmos DB 64
Azure Event Hub 128
Azure-Servicebus 128
Azure Data Lake Store V1 100

Hinweis

Die Grenzwerte unterlegen Änderungen im alleinigen Ermessen des Azure-Diensts. Details zu den einzelnen Diensten finden Sie in der jeweiligen Dokumentation.

Migrieren klassischer Netzwerkressourcen zu Resource Manager

Was ist Azure Service Manager, und was bedeutet der Begriff „Klassisch“?

Azure Service Manager ist das alte, für das Erstellen, Verwalten und Löschen von Ressourcen zuständige Bereitstellungsmodell von Azure. Das Wort klassisch in einem Netzwerkdienst bezieht sich auf Ressourcen, die vom Azure Service Manager-Modell verwaltet werden. Weitere Informationen finden Sie unter Azure Resource Manager und klassische Bereitstellung: Grundlegendes zu Bereitstellungsmodellen und zum Status von Ressourcen.

Was ist Azure Resource Manager?

Azure Resource Manager ist das neueste, für das Erstellen, Verwalten und Löschen von Ressourcen in Ihrem Azure-Abonnement verantwortliche Bereitstellungs- und Verwaltungsmodell in Azure. Weitere Informationen finden Sie unter Was ist Azure Resource Manager?

Kann ich die Migration rückgängig machen, nachdem Ressourcen an Resource Manager committet worden sind?

Sie können die Migration abbrechen, solange sich die Ressourcen noch im Zustand „Vorbereitet“ befinden. Ein Rollback zum vorherigen Bereitstellungsmodell wird nicht unterstützt, nachdem Ressourcen erfolgreich über den Commitvorgang migriert wurden.

Kann ich die Migration rückgängig machen, wenn der Commitvorgang nicht erfolgreich war?

Sie können eine Migration nicht umkehren, wenn der Commitvorgang nicht erfolgreich war. Alle Migrationsvorgänge einschließlich Commit können nach dem Start nicht mehr geändert werden. Sie sollten den Vorgang nach kurzer Zeit erneut versuchen. Wenn der Vorgang weiterhin nicht erfolgreich ist, senden Sie eine Supportanfrage.

Kann ich mein Abonnement oder meine Ressourcen überprüfen, um zu ermitteln, ob sie für die Migration geeignet sind?

Ja. Im Rahmen des Migrationsverfahrens besteht der erste Schritt bei der Vorbereitung der Migration in der Überprüfung, ob Ressourcen migriert werden können. Falls beim Überprüfungsvorgang ein Fehler auftritt, erhalten Sie alle Meldungen über alle Gründe, aus denen die Migration nicht abgeschlossen werden kann.

Werden Application Gateway-Ressourcen im Rahmen der VNET-Migration von „klassisch“ zu Resource Manager migriert?

Application Gateway-Ressourcen werden nicht automatisch im Rahmen des VNET-Migrationsprozesses migriert. Wenn eine solche Ressource im virtuellen Netzwerk vorhanden ist, ist die Migration nicht erfolgreich. Um eine Application Gateway-Ressource zu Resource Manager zu migrieren, müssen Sie das Application Gateway entfernen und neu erstellen, sobald die Migration abgeschlossen ist.

Wird das VPN-Gateway im Rahmen der VNET-Migration von „klassisch“ zu Resource Manager migriert?

VPN-Gateway-Ressourcen werden im Rahmen des VNET-Migrationsprozesses migriert. Es wird jeweils ein virtuelles Netzwerk ohne andere Anforderungen ausgeführt. Die Migrationsschritte entsprechen der Migration eines virtuellen Netzwerks ohne VPN-Gateway.

Tritt im Zusammenhang mit der Migration klassischer VPN-Gateways zu Resource Manager eine Dienstunterbrechung auf?

Bei der Migration zu Resource Manager tritt keine Dienstunterbrechung bei Ihrer VPN-Verbindung auf. Vorhandene Workloads funktionieren während der Migration weiterhin ohne Verlust der Konnektivität.

Muss ich nach der Migration des VPN-Gateways zu Resource Manager mein lokales Gerät neu konfigurieren?

Die öffentliche IP-Adresse, die dem VPN-Gateway zugeordnet ist, bleibt auch nach der Migration unverändert. Sie müssen Ihren lokalen Router nicht neu konfigurieren.

Welche Szenarien werden für die Migration klassischer VPN-Gateways zu Resource Manager unterstützt?

Die meisten gängigen VPN-Konnektivitätsszenarios werden von der Migration von „klassisch“ zu Resource Manager unterstützt. Folgende Szenarien werden unterstützt:

  • Point-to-Site-Konnektivität

  • Site-to-Site-Konnektivität mit einem VPN-Gateway mit Verbindung zu einem lokalen Standort

  • VNET-zu-VNET-Konnektivität zwischen zwei VNETs mithilfe von VPN-Gateways

  • Mehrere mit demselben lokalen Standort verbundene VNETs

  • Konnektivität für mehrere Standorte

  • Für erzwungenes Tunneling aktivierte virtuelle Netzwerke

Welche Szenarien werden für die Migration klassischer VPN-Gateways zu Resource Manager nicht unterstützt?

Folgende Szenarien werden nicht unterstützt:

  • Ein virtuelles Netzwerk mit sowohl einem ExpressRoute-Gateway als auch VPN-Gateway wird derzeit nicht unterstützt.

  • Virtuelles Netzwerk mit einem ExpressRoute-Gateway, das mit einem Netzwerk in einem anderen Abonnement verbunden ist.

  • Übertragungsszenarios in denen VM-Erweiterungen mit lokalen Servern verbunden sind.

Wo finde ich weitere Informationen zur Migration vom klassischen Bereitstellungsmodell zum Azure Resource Manager-Bereitstellungsmodell?

Weitere Informationen finden Sie unter Häufig gestellte Fragen zur Migration vom klassischen Bereitstellungsmodell zum Azure Resorce Manager-Bereitstellungsmodell.

Wie kann ich ein Problem melden?

Sie können Ihre Fragen zu Ihren Migrationsproblemen auf der Q&A-Seite von Microsoft veröffentlichen. Sie sollten alle Ihre Fragen in diesem Forum veröffentlichen. Wenn Sie über einen Supportvertrag verfügen, können Sie auch eine Supportanfrage stellen.