Virtual WAN – Häufig gestellte Fragen

Ist Azure Virtual WAN allgemein verfügbar?

Ja, Azure Virtual WAN ist allgemein verfügbar. Virtual WAN besteht jedoch aus mehreren Funktionen und Szenarien. In Virtual WAN gibt es Funktionen oder Szenarien, für die Microsoft das Vorschautag anwendet. In diesen Fällen befindet sich die jeweilige Funktion oder das Szenario selbst in der Vorschauphase. Wenn Sie keine bestimmte Previewfunktion verwenden, gilt die reguläre Unterstützung für die allgemeine Verfügbarkeit. Weitere Informationen zur Unterstützung der Vorschau finden Sie unter Zusätzliche Nutzungsbedingungen für Microsoft Azure-Vorschauen.

Welche Standorte und Regionen sind verfügbar?

Die verfügbaren Regionen für Virtual WAN finden Sie unter Verfügbare Produkte nach Region. Geben Sie Virtual WAN als Produktnamen an.

Muss der Benutzer über eine Hub-and-Spoke-Anordnung mit SD-WAN/VPN-Geräten verfügen, um Azure Virtual WAN nutzen zu können?

Virtual WAN bietet viele Funktionen, die in einem einzigen Glasbereich integriert sind. Dazu gehören:

• Standort-zu-Standort-VPN-Konnektivität
• Benutzer-/P2S-Konnektivität
• ExpressRoute-Konnektivität
• Virtuelle Netzwerkkonnektivität
• VPN ExpressRoute-Konnektivität
• Transitive VNet-zu-VNet-Konnektivität
• Zentralisiertes Routing
• Sicherheit von Azure Firewall und Firewall Manager
• Monitoring
• ExpressRoute-Verschlüsselung und
• Viele andere Funktionen

Sie müssen nicht über alle diese Anwendungsfälle verfügen, um mit der Verwendung von Virtual WAN zu beginnen. Sie können mit nur einem Anwendungsfall starten.

Die Virtual WAN-Architektur ist eine Hub-and-Spoke-Architektur mit integrierter Skalierung und Leistung, wobei Branches (VPN/SD-WAN-Geräte), Benutzer (Azure-VPN-, openVPN- oder IKEv2-Clients), ExpressRoute-Leitungen und virtuelle Netzwerke als „Spokes“ für virtuelle Hubs dienen. Alle Hubs sind per Standard-Virtual WAN vollständig miteinander vernetzt, damit Benutzer den Microsoft-Backbone für die Any-to-Any-Konnektivität (alle Spokes) nutzen können. Zur Nutzung einer Hub-and-Spoke-Anordnung mit SD-WAN/VPN-Geräten können Benutzer dies entweder manuell im Azure Virtual WAN-Portal einrichten oder CPE für Virtual WAN-Partner (SD-WAN/VPN) nutzen, um die Konnektivität mit Azure herzustellen.

Virtuelle WAN-Partner bieten Automatisierung für Konnektivität. Es ist die Möglichkeit, die Geräteinformationen in Azure zu exportieren, die Azure-Konfiguration herunterzuladen und eine Verbindung mit dem virtuellen Azure WAN-Hub herzustellen. Für die Point-to-Site/Benutzer-VPN-Konnektivität unterstützen wir den Azure-VPN-, OpenVPN- und IKEv2-Client.

Können Sie vollständig vermaschte Hubs in einem Virtual WAN deaktivieren?

Virtual WAN ist in zwei Varianten verfügbar: Basic und Standard. In Virtual WAN vom Typ „Basic“ sind die Hubs nicht vermascht. In einem Virtual WAN vom Typ „Standard“ werden die Hubs vermascht und automatisch verbunden, wenn das virtuelle WAN zum ersten Mal eingerichtet wird. Für den Benutzer sind keine bestimmten Schritte erforderlich. Der Benutzer muss die Funktionalität auch nicht deaktivieren oder aktivieren, um vermaschte Hubs zu erhalten. Virtual WAN bietet Ihnen viele Routingoptionen zum Steuern des Datenverkehrs zwischen beliebigen Spokes (VNet, VPN oder ExpressRoute). Es bietet die Einfachheit vollständig vermaschter Hubs und auch die Flexibilität, Datenverkehr gemäß Ihren Anforderungen weiterzuleiten.

Warum wird beim Ausführen von Vorgängen auf Virtual WAN-Ressourcen ein Fehler wegen eines ungültigen Geltungsbereichs und einer ungültigen Autorisierung angezeigt?

Wenn im folgenden Format ein Fehler angezeigt wird, stellen Sie sicher, dass die folgenden Berechtigungen konfiguriert sind: Virtuelle WAN-Rollen und -Berechtigungen

Fehlermeldungsformat: „Der Client mit der Objekt-ID {} hat keine Berechtigung zum Durchführen der Aktion {} im Geltungsbereich {}, oder der Geltungsbereich ist ungültig. Weitere Einzelheiten zu den erforderlichen Berechtigungen finden Sie unter {}. Wenn der Zugriff erst vor Kurzem gewährt wurde, sollten Sie Ihre Anmeldeinformationen aktualisieren.

Wie werden Verfügbarkeitszonen und Resilienz in Virtual WAN gehandhabt?

Virtual WAN ist eine Sammlung von Hubs und Diensten, die innerhalb des Hubs zur Verfügung gestellt werden. Der Benutzer kann gemäß seinen Anforderungen beliebig viele Virtual WAN-Instanzen besitzen. In einem virtuellen WAN-Hub gibt es mehrere Dienste wie VPN, ExpressRoute usw. Jeder dieser Dienste wird automatisch über Verfügbarkeitszonen (mit Ausnahme von Azure Firewall) bereitgestellt, wenn die Region Verfügbarkeitszonen unterstützt. Wenn eine Region nach der anfänglichen Bereitstellung im Hub zu einer Verfügbarkeitszone wird, kann der Benutzer die Gateways neu erstellen, wodurch eine Bereitstellung der Verfügbarkeitszone ausgelöst wird. Alle Gateways werden in einem Hub als „Aktiv/Aktiv“ bereitgestellt, was bedeutet, dass die Ausfallsicherheit in einen Hub integriert ist. Benutzer können Verbindungen mit mehreren Hubs herstellen, wenn sie eine regionsübergreifende Resilienz wünschen.

Derzeit kann Azure Firewall bereitgestellt werden, um Verfügbarkeitszonen über das Azure Firewall Manager-Portal, PowerShell oder CLI zu unterstützen. Derzeit gibt es keine Möglichkeit, eine bestehende Firewall für die Bereitstellung über Verfügbarkeitszonen hinweg zu konfigurieren. Sie müssen Ihre Azure-Firewall löschen und erneut bereitstellen.

Obwohl das Konzept von Virtual WAN global ist, basiert die eigentliche virtuelle WAN-Ressource auf dem Resource Manager und wird regional bereitgestellt. Wenn die virtuelle WAN-Region selbst ein Problem hat, funktionieren alle Hubs in diesem virtuellen WAN weiterhin. Der Benutzer kann jedoch erst neue Hubs erstellen, wenn die virtuelle WAN-Region verfügbar ist.

Wie lösche oder räume ich meine virtuellen WAN-Ressourcen auf?

Wenn Sie die von Ihnen erstellten Ressourcen nicht mehr benötigen, löschen Sie sie. Einige der virtuellen WAN-Ressourcen müssen aufgrund von Abhängigkeiten in einer bestimmten Reihenfolge gelöscht werden. Das Löschen kann bis zu 30 Minuten dauern.

1. Öffnen Sie das virtuelle WAN, das Sie erstellt haben.

2. Wählen Sie einen virtuellen Hub aus, der dem virtuellen WAN zugeordnet ist, um die Hubseite zu öffnen.

3. Löschen Sie alle Gatewayentitäten nach der folgenden Reihenfolge für jeden Gatewaytyp. Dies kann 30 Minuten dauern.

   VPN:

   • VPN-Standorte trennen
   • Löschen von VPN-Verbindungen
   • Löschen von VPN-Gateways

   ExpressRoute:

   • Löschen von ExpressRoute-Verbindungen
   • Löschen von ExpressRoute-Gateways

4. Wiederholen Sie diesen Vorgang für alle Hubs, die dem virtuellen WAN zugeordnet sind.

5. Sie können die Hubs an diesem Punkt entweder löschen oder die Hubs später löschen, wenn Sie die Ressourcengruppe löschen.

6. Navigieren Sie im Azure-Portal zur Ressourcengruppe.

7. Wählen Sie die Option Ressourcengruppe löschen. Dadurch werden die anderen Ressourcen in der Ressourcengruppe gelöscht, einschließlich der Hubs und des virtuellen WAN.

Ist es möglich, die Firewall in einem geschützten Hub mit anderen Hubs zu teilen?

Nein, jeder virtuelle Azure Hub muss über eine eigene Firewall verfügen. Die Bereitstellung von benutzerdefinierten Routen, die auf die Firewall eines anderen gesicherten Hubs verweisen, schlägt fehl und wird nicht erfolgreich abgeschlossen. Erwägen Sie die Konvertierung dieser Hubs in gesicherte Hubs mit ihren eigenen Firewalls.

Welcher Client wird für Azure Virtual WAN-Benutzer-VPN (Point-to-Site) unterstützt?

Virtual WAN unterstützt den Azure-VPN-, OpenVPN- oder einen beliebigen IKEv2-Client. Microsoft Entra-Authentifizierung wird mit Azure VPN Client unterstützt. Mindestens Windows 10-Clientbetriebssystem, Version 17763.0 oder höher, ist erforderlich. OpenVPN-Clients können die zertifikatbasierte Authentifizierung unterstützen. Nachdem auf dem Gateway die zertifikatbasierte Authentifizierung ausgewählt wurde, wird die OVPN-Datei zum Herunterladen Ihres Geräts angezeigt. IKEv2 unterstützt sowohl die Zertifikat- als auch die RADIUS-Authentifizierung.

Für Benutzer-VPN (Point-to-Site): Warum ist der P2S-Clientpool in zwei Routen unterteilt?

Jedes Gateway verfügt über zwei Instanzen. Die Aufteilung wird durchgeführt, damit jede Gatewayinstanz separat Client-IP-Adressen für verbundene Clients zuordnen kann und der Datenverkehr aus dem virtuellen Netzwerk (VNet) zurück an die richtige Gatewayinstanz geleitet wird, um Hops zwischen Gatewayinstanzen zu vermeiden.

Wie füge ich DNS-Server für P2S-Clients hinzu?

Es gibt zwei Optionen zum Hinzufügen von DNS-Servern für die P2S-Clients. Die erste Methode wird bevorzugt, da sie die benutzerdefinierten DNS-Server dem Gateway und nicht dem Client hinzufügt.

1. Verwenden Sie das folgende PowerShell-Skript, um die benutzerdefinierten DNS-Server hinzuzufügen. Ersetzen Sie die Werte für Ihre Umgebung.

   // Define variables
   $rgName = "testRG1"
   $virtualHubName = "virtualHub1"
   $P2SvpnGatewayName = "testP2SVpnGateway1"
   $vpnClientAddressSpaces = 
   $vpnServerConfiguration1Name = "vpnServerConfig1"
   $vpnClientAddressSpaces = New-Object string[] 2
   $vpnClientAddressSpaces[0] = "192.168.2.0/24"
   $vpnClientAddressSpaces[1] = "192.168.3.0/24"
   $customDnsServers = New-Object string[] 2
   $customDnsServers[0] = "7.7.7.7"
   $customDnsServers[1] = "8.8.8.8"
   $virtualHub = $virtualHub = Get-AzVirtualHub -ResourceGroupName $rgName -Name $virtualHubName
   $vpnServerConfig1 = Get-AzVpnServerConfiguration -ResourceGroupName $rgName -Name $vpnServerConfiguration1Name
   
   // Specify custom dns servers for P2SVpnGateway VirtualHub while creating gateway
   createdP2SVpnGateway = New-AzP2sVpnGateway -ResourceGroupName $rgname -Name $P2SvpnGatewayName -VirtualHub $virtualHub -VpnGatewayScaleUnit 1 -VpnClientAddressPool $vpnClientAddressSpaces -VpnServerConfiguration $vpnServerConfig1 -CustomDnsServer $customDnsServers
   
   // Specify custom dns servers for P2SVpnGateway VirtualHub while updating existing gateway
   $P2SVpnGateway = Get-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName
   $updatedP2SVpnGateway = Update-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName -CustomDnsServer $customDnsServers 
   
   // Re-generate VPN profile either from PS/Portal for VPN clients to have the specified dns servers
   

2. Falls Sie Azure VPN Client für Windows 10 verwenden, können Sie die heruntergeladene XML-Profildatei ändern und vor dem Importieren die Tags <dnsservers><dnsserver></dnsserver></dnsservers> hinzufügen.

      <azvpnprofile>
      <clientconfig>
   
          <dnsservers>
              <dnsserver>x.x.x.x</dnsserver>
              <dnsserver>y.y.y.y</dnsserver>
          </dnsservers>
   
      </clientconfig>
      </azvpnprofile>
   

Für Benutzer-VPN (Point-to-Site): Wie viele Clients werden unterstützt?

In der folgenden Tabelle wird die Anzahl der gleichzeitigen Verbindungen und der aggregierte Durchsatz des Point-to-Site-VPN-Gateways beschrieben, das in verschiedenen Skalierungseinheiten unterstützt wird.

Ein Beispiel: Angenommen, der Benutzer wählt eine Skalierungseinheit aus. Jede Skalierungseinheit steht für ein bereitgestelltes Aktiv/Aktiv-Gateway, und jede Instanz (in diesem Fall zwei) unterstützt bis zu 500 Verbindungen. Da Sie 500 Verbindungen * 2 pro Gateway erhalten können, bedeutet dies nicht, dass Sie 1000 (statt der 500) für diese Skalierungseinheit einplanen. Möglicherweise müssen Instanzen gewartet werden, wobei die Konnektivität für die zusätzlichen 500 unterbrochen werden kann, wenn Sie die empfohlene Anzahl von Verbindungen überschreiten.

Für Gateways mit Skalierungseinheit, die größer als 20 sind, werden zusätzliche hoch verfügbare Paare von Gateway-Instanzen bereitgestellt, um zusätzliche Kapazität für die Verbindung von Benutzern bereitzustellen. Jedes Paar von Instanzen unterstützt bis zu 10.000 zusätzliche Benutzer. Wenn Sie beispielsweise ein Gateway mit 100 Skalierungseinheiten bereitstellen, werden 5 Gateway-Paare (10 Gesamtinstanzen) bereitgestellt, und bis zu 50.000 (10.000 Benutzer x 5 Gateway-Paare) können gleichzeitige Benutzer verbunden werden.

Planen Sie darüber hinaus auch Ausfallzeit ein, falls Sie für die Skalierungseinheit das Hoch- oder Herunterskalieren durchführen oder die Point-to-Site-Konfiguration auf dem VPN-Gateway ändern möchten.

Wird für Benutzer-VPN (Point-to-Site) die von Microsoft registrierte App in der Entra-ID-Authentifizierung unterstützt?

Ja, die von Microsoft registrierte App wird in Virtual WAN unterstützt. Sie können Ihre Benutzer-VPN von der manuell registrierten App zu einer von Microsoft registrierten App migrieren, um eine sicherere Verbindung zu erhalten.

Was sind Virtual WAN-Gatewayskalierungseinheiten?

Eine Skalierungseinheit ist eine Einheit, die zum Auswählen eines aggregierten Durchsatzes eines Gateways im virtuellen Hub definiert wird. 1 VPN-Skalierungseinheit = 500 MBit/s. 1 ExpressRoute-Skalierungseinheit = 2 GBits/s. Beispiel: Für 10 VPN-Skalierungseinheiten gilt demnach Folgendes: 500 MBit/s * 10 = 5 GBit/s.

Sie können die Skalierungseinheit des Gateways basierend auf Ihren Anforderungen manuell skalieren oder verkleineren. Weitere Informationen zu Gatewayeinstellungen finden Sie unter "Informationen zu den Einstellungen des virtuellen WAN-Gateways ".

Weitere Informationen zu Supportgrenzwerten für Gatewayskalierungseinheiten finden Sie unter:

• In Virtual WAN, was sind die geschätzten Leistungen von ExpressRoute-Gateway-SKU? für ExpressRoute-Gateways
• Welcher Algorithmus und wie viele Pakete pro Sekunde pro Site-to-Site-Instanz werden in einem Virtual WAN-Hub empfohlen? Wie viele Tunnel werden pro Instanz unterstützt? Wie hoch ist der maximale Durchsatz, der in einem einzelnen Tunnel unterstützt wird? für Standort-zu-Standort-VPN-Gateways
• Für Benutzer-VPN (Point-to-Site)- wie viele Clients werden unterstützt? für Benutzer-VPN-Gateways (Point-to-Site)

Welche Auswirkungen hat die Änderung der Gateway-Skalierungseinheiten für ein Virtual WAN ExpressRoute-Gateway?

Beachten Sie beim Ändern von Gatewayskalierungseinheiten die folgenden Überlegungen:

• Datenverkehrskapazität: Stellen Sie sicher, dass die bereitgestellten Skalierungseinheiten Ihre Datenverkehrsanforderungen unterstützen können.

• TCP-Erneute Verbindungen: Während der Skalierungseinheitsänderung können TCP-Verbindungen erneut verbunden werden, was zu geringfügigen Unterbrechungen führen kann.

• Auswirkungen privater Endpunkte: Änderungen der Skalierungseinheit können sich auf die Konnektivität für private Endpunkte auswirken. Überprüfen Sie Ihre Bereitstellung, und befolgen Sie die bewährten Methoden unter "Private Verknüpfung verwenden" in virtuellem WAN.

Weitere Informationen zu Gatewayskalierungseinheiten und Kapazitätsplanung finden Sie unter Informationen zu den Einstellungen für virtuelle WAN-Gateways.

Worin besteht der Unterschied zwischen einem virtuellen Azure-Netzwerkgateway (VPN-Gateway) und einem Azure Virtual WAN-VPN-Gateway?

Virtual WAN ermöglicht eine umfassende Site-to-Site-Konnektivität und ist auf Durchsatz, Skalierbarkeit und Benutzerfreundlichkeit ausgelegt. Wenn Sie einen Standort mit einem Virtual WAN-VPN-Gateway verbinden, unterscheidet sich dies von einem regulären Gateway für virtuelle Netzwerke, für das der Gatewaytyp „Site-to-Site-VPN“ verwendet wird. Wenn Sie Remotebenutzer mit Virtual WAN verbinden möchten, verwenden Sie den Gatewaytyp „Point-to-Site-VPN“. Die „Point-to-Site-“ und „Site-to-Site-VPN-Gateways“ sind separate Entitäten im Virtual WAN-Hub und müssen einzeln bereitgestellt werden. Wenn Sie eine ExpressRoute-Leitung mit einem virtuellen WAN-Hub verbinden, wird eine andere Ressource für das ExpressRoute-Gateway als für das reguläre Gateway für virtuelle Netzwerke mit dem Gatewaytyp „ExpressRoute“ verwendet.

Virtual WAN unterstützt sowohl für VPN als auch für ExpressRoute einen aggregierten Durchsatz von bis zu 20 GBit/s. Das virtuelle WAN verfügt auch über eine Automatisierung in Bezug auf die Konnektivität mit einem Ökosystem aus CPE-Branchgerät-Partnern. CPE-Branchgeräte weisen eine integrierte Automatisierung auf, die automatisch bereitgestellt wird und für die eine Verbindung mit Azure Virtual WAN hergestellt wird. Diese Geräte sind über ein ständig wachsendes Ökosystem von SD-WAN- und VPN-Partnern erhältlich. Siehe die Liste der bevorzugten Partner.

Inwiefern unterscheidet sich Virtual WAN von einem Azure-Gateway für virtuelle Netzwerke?

Das VPN des Gateways für virtuelle Netzwerke ist auf 100 Tunnel begrenzt. Für Verbindungen sollten Sie bei einem größeren VPN-Umfang Virtual WAN verwenden. Sie können bis zu 1.000 Branchverbindungen pro virtuellem Hub mit einer Aggregierung von 20 GBit/s pro Hub verbinden. Eine Verbindung ist ein Aktiv-Aktiv-Tunnel vom lokalen VPN-Gerät zum virtuellen Hub. Sie können auch mehrere virtuelle Hubs pro Region haben. Dies bedeutet, dass Sie mehr als 1.000 Filialen mit einer einzelnen Azure-Region verbinden können, indem Sie mehrere virtuelle WAN-Hubs in dieser Azure-Region bereitstellen, die jeweils über ein eigenes Standort-zu-Standort-VPN-Gateway verfügen.

Welcher Algorithmus und wie viele Pakete pro Sekunde pro Site-to-Site-Instanz werden in einem Virtual WAN-Hub empfohlen? Wie viele Tunnel werden pro Instanz unterstützt? Wie hoch ist der maximale Durchsatz, der in einem einzelnen Tunnel unterstützt wird?

Virtual WAN unterstützt zwei aktive Site-to-Site-VPN-Gatewayinstanzen in einem virtuellen Hub. Dies bedeutet, dass es zwei Aktiv/Aktiv-Instanzen von VPN-Gatewayinstanzen in einem virtuellen Hub gibt. Während Wartungsvorgängen werden die Instanzen nacheinander aktualisiert, wodurch es für einen Benutzer zu einer kurzen Verringerung des aggregierten Durchsatzes eines VPN-Gateways kommt.

Ein Virtual WAN-VPN unterstützt viele Algorithmen, aber wir empfehlen GCMAES256 für IPSEC-Verschlüsselung und -Integrität, um eine optimale Leistung zu erzielen. AES256 und SHA256 gelten als weniger leistungsstark, und daher kann bei ähnlichen Algorithmustypen eine Leistungsbeeinträchtigung wie Wartezeit und Paketverluste erwartet werden.

Pakete pro Sekunde oder PPS sind ein Faktor aus der Gesamtanzahl der Pakete und dem unterstützten Durchsatz pro Instanz. Dies wird am besten anhand eines Beispiels verdeutlicht. Nehmen wir an, eine (1) Site-to-Site-VPN-Gatewayinstanz mit einer Skalierungseinheit von 500 MBit/s wird in einem Virtual WAN-Hub bereitgestellt. Bei einer Paketgröße von 1400 lautet der erwartete PPS-Wert für diese VPN-Gatewayinstanz maximal [(500 MBit/s · 1024 · 1024)/8/1400] ~ 47000.

Virtuelles WAN verfügt über Konzepte von VPN-Verbindungen, Verbindungsverbindungen und Tunneln. Eine einzelne VPN-Verbindung besteht aus Linkverbindungen. Virtual WAN unterstützt bis zu vier Linkverbindungen in einer VPN-Verbindung. Jede Linkverbindung besteht aus zwei IPsec-Tunneln, die in zwei Instanzen eines Aktiv/Aktiv-VPN-Gateways enden, das in einem virtuellen Hub bereitgestellt wird. Die Gesamtzahl der Tunnel, die in einer einzelnen aktiven Instanz beendet werden können, beträgt 1.000. Dies bedeutet auch, dass der Durchsatz für 1 Instanz über alle Tunnel aggregiert ist, die mit dieser Instanz verbunden sind. Jeder Tunnel verfügt zudem über bestimmte Durchsatzwerte. Bei mehreren Tunneln, die mit einem Gateway mit niedrigerer Skalierungseinheit verbunden sind, ist es am besten, den Bedarf pro Tunnel zu bewerten und ein VPN-Gateway zu planen, das einem aggregierten Wert für den Durchsatz aller Tunnel entspricht, die in der VPN-Instanz enden.

Werte für verschiedene in Virtual WAN unterstützte Skalierungseinheiten

Welche Geräteanbieter (Virtual WAN-Partner) werden unterstützt?

Derzeit wird die vollständig automatisierte Virtual WAN-Umgebung von vielen Partnern unterstützt. Weitere Informationen finden Sie auf der Seite mit den Informationen zu Virtual WAN-Partnern.

Was sind die Automatisierungsschritte für Virtual WAN-Partner?

Informationen zu den Automatisierungsschritten für Partner finden Sie unter Konfigurieren von Virtual WAN-Automatisierung – für Virtual WAN-Partner.

Muss ich ein Gerät eines bevorzugten Partners nutzen?

No. Sie können ein beliebiges VPN-fähiges Gerät nutzen, das die Anforderungen von Azure für die IKEv2/IKEv1-IPsec-Unterstützung erfüllt. Virtual WAN verfügt auch über CPE-Partnerlösungen, die die Konnektivität zu Azure Virtual WAN automatisieren und so die Einrichtung von IPsec-VPN-Verbindungen im großem Stil erleichtern.

Wie automatisieren Virtual WAN-Partner die Konnektivität mit Azure Virtual WAN?

Softwaredefinierte Konnektivitätslösungen verwalten ihre Branchgeräte normalerweise mithilfe eines Controllers oder über ein Center für die Gerätebereitstellung. Für den Controller können Azure-APIs verwendet werden, um die Konnektivität mit Azure Virtual WAN zu automatisieren. Die Automatisierung umfasst das Hochladen von Branchinformationen, Herunterladen der Azure-Konfiguration, Einrichten von IPsec-Tunneln zu virtuellen Azure-Hubs und automatische Einrichten der Konnektivität vom Branchgerät zu Azure Virtual WAN. Wenn Sie über Hunderte von Branches verfügen, ist das Verbinden über Virtual WAN-CPE-Partner einfach, weil aufgrund des Onboardingverfahrens das aufwändige Einrichten, Konfigurieren und Verwalten der IPsec-Konnektivität entfällt. Weitere Informationen finden Sie unter Konfigurieren von Virtual WAN-Automatisierung – für Virtual WAN-Partner (Vorschauversion).

Was geschieht, wenn ein von mir verwendetes Gerät nicht in der Liste der Virtual WAN-Partner aufgeführt ist? Kann ich über dieses Gerät dennoch eine Verbindung mit dem Azure Virtual WAN-VPN herstellen?

Ja, solange das Gerät IPsec IKEv1 oder IKEv2 unterstützt. Virtual WAN-Partner automatisieren die Konnektivität vom Gerät zu Azure-VPN-Endpunkten. Dies umfasst die Automatisierung von Schritten wie beispielsweise „Hochladen von Branchinformationen“, „IPsec und Konfiguration“ und „Konnektivität“. Da Ihr Gerät nicht aus einem Virtuellen WAN-Partnerökosystem stammt, müssen Sie die azure-Konfiguration manuell aufheben und Ihr Gerät aktualisieren, um die IPsec-Konnektivität einzurichten.

Wie erfolgt das Onboarding für neue Partner, die nicht in der Liste mit den Einführungspartnern aufgeführt sind?

Alle virtuellen WAN-APIs sind offene APIs. Sie können zur Dokumentation Automatisierung für Virtual WAN-Partner wechseln, um die technische Machbarkeit zu beurteilen. Ein idealer Partner verfügt über ein Gerät, das für IKEv1- oder IKEv2-IPSec-Konnektivität bereitgestellt werden kann. Sobald das Unternehmen die Automatisierungsarbeiten für sein CPE-Gerät basierend auf den zuvor geteilten Automatisierungsrichtlinien abgeschlossen hat, können Sie azurevirtualwan@microsoft.com kontaktieren, um hier unter Connectivity through partners verzeichnet zu werden. Wenn Sie als Kunde eine bestimmte Unternehmenslösung als Virtual WAN-Partner aufgeführt haben möchten, sollten Sie das Unternehmen bitten, sich mit Virtual WAN in Verbindung zu setzen (per E-Mail an azurevirtualwan@microsoft.com).

Wie werden SD-WAN-Geräte durch Virtual WAN unterstützt?

Virtual WAN-Partner automatisieren die IPsec-Verbindung mit Azure-VPN-Endpunkten. Wenn der virtuelle WAN-Partner ein SD-WAN-Anbieter ist, wird impliziert, dass der SD-WAN Controller automatisierungs- und IPsec-Konnektivität mit Azure VPN-Endpunkten verwaltet. Wenn das SD-WAN-Gerät anstelle des Azure-VPN einen eigenen Endpunkt für proprietäre SD-WAN-Funktionen erfordert, können Sie den SD-WAN-Endpunkt in einem virtuellen Azure-Netzwerk bereitstellen, das neben Azure Virtual WAN vorhanden ist.

Virtual WAN unterstützt BGP-Peering und auch die Möglichkeit, NVAs in einem Virtual WAN-Hub bereitzustellen.

Wie viele VPN-Geräte können sich mit einem einzelnen Hub verbinden?

Pro virtuellem Hub werden bis zu 1.000 Verbindungen unterstützt. Jede Verbindung besteht aus vier Verknüpfungen, und jede Verknüpfungsverbindung unterstützt zwei Tunnel mit einer Aktiv/Aktiv-Konfiguration. Die Tunnel enden in einem virtuellen Azure-Hub (VPN-Gateway). Links stellen die physische ISP-Verbindung am Branch/VPN-Gerät dar.

Was ist eine Branchverbindung mit Azure Virtual WAN?

Bei einer Verbindung zwischen einem Branch oder VPN-Gerät und Azure Virtual WAN handelt es sich um eine VPN-Verbindung, die den VPN-Standort und die Azure VPN Gateway-Instanz in einem virtuellen Hub virtuell miteinander verbindet.

Was passiert, wenn das lokale VPN-Gerät nur über einen einzelnen Tunnel zu einem Azure Virtual WAN-VPN-Gateway verfügt?

Eine Azure Virtual WAN-Verbindung umfasst zwei Tunnel. Ein Virtual WAN-VPN-Gateway wird auf einem virtuellen Hub im Aktiv/Aktiv-Modus bereitgestellt, was impliziert, dass separate Tunnel von lokalen Geräten vorhanden sind, die in separaten Instanzen enden. Dies ist die Empfehlung für alle Benutzer. Wenn der Benutzer jedoch nur über 1 Tunnel zu einer der Virtuellen WAN-VPN-Gatewayinstanzen verfügt, wird der Tunnel aus irgendeinem Grund (Wartung, Patches usw.) offline genommen, wird der Tunnel in die sekundäre aktive Instanz verschoben, und der Benutzer kann eine erneute Verbindung haben. BGP-Sitzung werden nicht instanzübergreifend verschoben.

Was geschieht während einer Gatewayzurücksetzung in einem Virtual WAN-VPN-Gateway?

Verwenden Sie die Schaltfläche für die Gatewayzurücksetzung, wenn Ihre lokalen Geräte wie erwartet funktionieren, die Site-to-Site-VPN-Verbindung in Azure jedoch getrennt ist. Virtual WAN-VPN-Gateways werden für Hochverfügbarkeit immer in einem „Aktiv/Aktiv“-Zustand bereitgestellt. Das bedeutet, dass in einem VPN-Gateway zu jedem Zeitpunkt mehr als eine Instanz bereitgestellt wird. Wenn Sie die Schaltfläche für die Gatewayzurücksetzung verwenden, werden die Instanzen des VPN-Gateways nacheinander neu gestartet, sodass Ihre Verbindungen nicht beeinträchtigt werden. Es wird eine kurze Unterbrechung geben, wenn die Verbindungen von einer Instanz zur anderen wechseln, aber diese Unterbrechung sollte weniger als eine Minute betragen. Darüber hinaus ändert das Zurücksetzen der Gateways Ihre öffentlichen IP-Adressen nicht.

Dieses Szenario gilt nur für die Site-to-Site-Verbindungen.

Kann vom lokalen VPN-Gerät eine Verbindung mit mehreren Hubs hergestellt werden?

Yes. Der Datenverkehr erfolgt zu Beginn vom lokalen Gerät zum nächsten Microsoft-Netzwerkedge und dann zum virtuellen Hub.

Sind neue Resource Manager-Ressourcen für Virtual WAN verfügbar?

Ja. Virtual WAN verfügt über neue Resource Manager-Ressourcen. Weitere Informationen finden Sie in der Übersicht.

Kann ich mein bevorzugtes virtuelles Netzwerkgerät (in einem virtuellen NVA-Netzwerk) mit Azure Virtual WAN bereitstellen und verwenden?

Ja. Sie können Ihr bevorzugte virtuelles Netzwerk des virtuellen Netzwerkgeräts mit Azure Virtual WAN verbinden.

Kann ich ein virtuelles Netzwerkgerät innerhalb des virtuellen Hubs erstellen?

Ein virtuelles Netzwerkgerät (Network Virtual Appliance, NVA) kann nicht innerhalb eines virtuellen Hubs bereitgestellt werden. Weitere Informationen finden Sie unter Informationen zu NVAs in einem Virtual WAN-Hub.

Kann ich ein virtuelles Netzwerk mit einem virtuellen Hub in einem anderen Mandanten verbinden?

Yes. Befolgen Sie die Anweisungen in Connect cross-tenant virtual networks to a Virtual WAN hub.

Kann ein Spoke-VNET über ein Gateway für virtuelle Netzwerke verfügen?

No. Das Spoke-VNet kann nicht über ein Gateway für virtuelle Netzwerke verfügen, wenn es mit dem virtuellen Hub verbunden ist.

Kann ein Spoke-VNet über einen Azure Route Server verfügen?

No. Das Spoke-VNet kann nicht über einen Route Server verfügen, wenn es mit dem virtuellen WAN-Hub verbunden ist.

Gibt es Unterstützung für BGP bei VPN-Konnektivität?

Ja. BGP wird unterstützt. Wenn Sie einen VPN-Standort erstellen, können Sie die BGP-Parameter darin angeben. Dies bedeutet, dass alle verbindungen, die in Azure für diese Website erstellt wurden, für BGP aktiviert sind.

Sind Informationen zu Lizenzen oder Preisen für Virtual WAN vorhanden?

Yes. Informieren Sie sich auf der Preisseite.

Ist es möglich, Azure Virtual WAN mit einer Resource Manager-Vorlage zu erstellen?

Eine einfache Konfiguration eines Virtual WAN mit einem Hub und einem VPN-Standort kann mit einer Schnellstartvorlage erstellt werden. Virtual WAN ist in erster Linie ein von REST oder vom Portal gesteuerter Dienst.

Können Spoke-VNETs, die über einen virtuellen Hub verbunden sind, miteinander kommunizieren (V2V-Transit)?

Yes. Eine Virtual WAN-Instanz vom Typ „Standard“ unterstützt die transitive VNET-zu-VNET-Konnektivität über den Virtual WAN-Hub, mit dem die VNETs verbunden sind. In der Terminologie des virtuellen WAN beziehen wir uns auf diese Pfade als "lokale virtuelle WAN-VNet-Übertragung" für VNets, die mit einem virtuellen WAN-Hub in einer einzelnen Region verbunden sind. "Global Virtual WAN VNet transit" ist für VNets, die über mehrere virtuelle WAN-Hubs in zwei oder mehr Regionen verbunden sind.

In einigen Szenarien können Spoke-VNETs auch mittels direktem Peering miteinander verbunden werden. Dazu wird zusätzlich zu lokaler oder globaler Virtual WAN-VNET-Übertragung das Peering virtueller Netzwerke verwendet. In diesem Fall hat das VNET-Peering Vorrang vor der transitiven Verbindung über den Virtual WAN-Hub.

Ist die Konnektivität zwischen Branches für Virtual WAN zulässig?

Ja. Die Konnektivität zwischen Branches ist für Virtual WAN zulässig. Branch ist konzeptionell anwendbar auf VPN-Standort, ExpressRoute-Leitungen oder Point-to-Site-/Benutzer-VPN-Benutzer. Branch zu Branch ist standardmäßig aktiviert. Die entsprechende Einstellung befindet sich in der WAN-Konfiguration. Dies ermöglicht VPN-Branches/-Benutzern die Verbindungsherstellung mit anderen VPN-Branches und ermöglicht außerdem Transitkonnektivität zwischen VPN- und ExpressRoute-Benutzern.

Verläuft der Datenverkehr zwischen den Branches über Azure Virtual WAN?

Yes. Datenverkehr zwischen Branches durchläuft Azure Virtual WAN.

Ist für die Virtual WAN-Instanz eine ExpressRoute-Verbindung mit jeder Site erforderlich?

No. Für Virtual WAN ist keine ExpressRoute-Verbindung mit jedem Standort erforderlich. Ihre Standorte können über eine ExpressRoute-Leitung mit einem Anbieternetzwerk verbunden sein. Für Standorte, die sowohl über ExpressRoute mit einem virtuellen Hub als auch über ein IPsec-VPN mit dem gleichen Hub verbunden sind, bietet der virtuelle Hub Transitkonnektivität zwischen dem VPN- und dem ExpressRoute-Benutzer.

Gibt es bei Verwendung von Azure Virtual WAN einen Grenzwert für den Netzwerkdurchsatz oder die Anzahl der Verbindungen?

Der Netzwerkdurchsatz wird in einem virtuellen WAN-Hub pro Dienst angegeben. In jedem Hub beträgt der aggregierte VPN-Durchsatz bis zu 20 GBit/s, der aggregierte ExpressRoute-Durchsatz bis zu 20 GBit/s und der aggregierte Benutzer-VPN-/Point-to-Site-VPN-Durchsatz bis zu 200 GBit/s. Der Router im virtuellen Hub unterstützt bis zu 50 GBit/s für VNET-zu-VNET-Datenverkehr und geht übergreifend für alle mit einem einzelnen virtuellen Hub verbundenen VNETs von einer Gesamtworkload von 2.000 virtuellen Computern aus.

Um die Vorabkapazität zu sichern, ohne auf das Skalieren des virtuellen Hubs zu warten, wenn mehr Durchsatz erforderlich ist, können Sie die Mindestkapazität festlegen oder nach Bedarf ändern. Weitere Informationen finden Sie unter Informationen zu Einstellungen für virtuelle Hubs – Hubkapazität. Informationen zu den Kostenauswirkungen finden Sie auf der Seite Virtual WAN – Preise unter Kosten für Routinginfrastruktureinheiten.

VPN-Standorte stellen die Konnektivität mit einem Hub über Verbindungen her. Virtual WAN unterstützt bis zu 1.000 Verbindungen oder 2.000 IPsec-Tunnel pro virtuellen Hub. Wenn Remotebenutzer eine Verbindung mit einem virtuellen Hub herstellen, stellen sie eine Verbindung mit dem P2S-VPN-Gateway her, das je nach der für das P2S-VPN-Gateway im virtuellen Hub ausgewählten Skalierungseinheit (Bandbreite) bis zu 100.000 Benutzer unterstützt.

Kann ich NAT-T für meine VPN-Verbindungen verwenden?

Ja, NAT Traversal (NAT-T) wird unterstützt. Das Virtual WAN-VPN-Gateway erfüllt KEINE NAT-ähnliche Funktion für die inneren Pakete, die bei den IPSec-Tunneln ein-/ausgehen. Stellen Sie in dieser Konfiguration sicher, dass das lokale Gerät den IPsec-Tunnel initiiert.

Wie kann ich eine Skalierungseinheit auf eine bestimmte Einstellung wie 20 Gbps konfigurieren?

Wechseln Sie zum VPN-Gateway innerhalb eines Hubs im Portal, und wählen Sie dann die Skalierungseinheit aus, um sie in die entsprechende Einstellung zu ändern.

Lässt Virtual WAN für das lokale Gerät die parallele Nutzung mehrerer ISPs zu, oder wird immer nur ein VPN-Tunnel verwendet?

Lokale Gerätelösungen können Datenverkehrsrichtlinien anwenden, um den Datenverkehr über mehrere Tunnel in den Azure Virtual WAN-Hub (VPN-Gateway im virtuellen Hub) zu lenken.

Was ist die Architektur für globale Übertragungen?

Informationen finden Sie unter Architektur mit einem globalen Transitnetzwerk und Azure Virtual WAN.

Wie wird Datenverkehr über den Azure-Backbone geleitet?

Für den Datenverkehr wird das folgende Muster verwendet: Branchgerät > ISP > Microsoft-Netzwerkedge > Microsoft-Domänencontroller (Hub-VNet) > Microsoft-Netzwerkedge > ISP > Branchgerät

Was wird bei diesem Modell für jede Site benötigt? Nur eine Internetverbindung?

Yes. Eine Internetverbindung und ein physisches Gerät, das IPsec unterstützt – vorzugsweise von einem unserer integrierten Virtual WAN-Partner. Optional können Sie die Konfiguration und Konnektivität mit Azure auf Ihrem bevorzugten Gerät manuell verwalten.

Wie aktiviere ich die Standardroute (0.0.0.0/0) für eine Verbindung (VPN, ExpressRoute oder Virtual Network)?

Ein virtueller Hub kann eine erlernte Standardroute an eine Verbindung vom Typ „Virtuelles Netzwerk“, „Site-to-Site-VPN“ oder „ExpressRoute“ weitergeben, wenn das Flag für die Verbindung auf „Aktiviert“ festgelegt ist. Dieses Flag ist sichtbar, wenn der Benutzer eine VNET-Verbindung, eine VPN-Verbindung oder eine ExpressRoute-Verbindung bearbeitet. Das Flag ist standardmäßig deaktiviert, wenn für eine Site oder eine ExpressRoute-Leitung eine Verbindung mit einem Hub besteht. Es ist standardmäßig aktiviert, wenn eine VNET-Verbindung hinzugefügt wird, um ein VNET mit einem virtuellen Hub zu verbinden.

Der Ursprung der Standardroute liegt nicht im Virtual WAN-Hub. Die Standardroute wird weitergegeben, wenn sie bereits vom virtuellen WAN-Hub als Ergebnis der Bereitstellung einer Firewall im Hub gelernt wird oder wenn ein anderer verbundener Standort die Tunnelung erzwungen hat.

Eine Standardroute wird nicht zwischen Hubs weitergegeben.

Ist es möglich, mehrere Virtual WAN-Hubs in derselben Region zu erstellen?

Yes. Kunden können jetzt mehrere Hubs in derselben Region für dasselbe Azure Virtual WAN erstellen.

Wie wählt der virtuelle Hub in einer Virtual WAN-Instanz den besten Pfad für eine Route von mehreren Hubs aus?

Weitere Informationen finden Sie unter Routingpräferenz für virtuelle Hubs.

Ermöglicht der Virtual WAN-Hub Konnektivität zwischen ExpressRoute-Leitungen?

Der Transit zwischen ER-to-ER ist über Global Reach verfügbar. Virtuelle Hubgateways werden in DC- oder Azure-Regionen bereitgestellt. Wenn zwei ExpressRoute-Leitungen über Global Reach verbunden sind, muss der Datenverkehr nicht den ganzen Weg von den Edgeroutern bis zum virtuellen Hub-DC zurücklegen.

Routingabsicht kann auch mit Richtlinien für privates Datenverkehrsrouting verwendet werden, um die ExpressRoute-Transitkonnektivität über eine sicherheitsrelevante Appliance zu aktivieren, die im virtuellen Hub bereitgestellt wird.

Weitere Informationen finden Sie unter Virtual WAN Global Reach.

Gibt es ein Gewichtungskonzept für Azure Virtual WAN-ExpressRoute-Leitungen oder VPN-Verbindungen?

Wenn mehrere ExpressRoute-Leitungen mit einem virtuellen Hub verbunden sind, bietet die Routinggewichtung für die Verbindung einen Mechanismus, mit dem ExpressRoute im virtuellen Hub eine Leitung der anderen vorzieht. Es gibt keinen Mechanismus zum Gewichten einer VPN-Verbindung. Azure bevorzugt immer eine ExpressRoute-Verbindung gegenüber einer VPN-Verbindung innerhalb eines einzelnen Hubs.

Wird von Virtual WAN für ausgehenden Azure-Datenverkehr ExpressRoute gegenüber VPN bevorzugt?

Yes. Von Virtual WAN wird für ausgehenden Azure-Datenverkehr ExpressRoute gegenüber VPN bevorzugt. Sie können jedoch die Einstellung für das Routing virtueller Hubs konfigurieren, um die Standardeinstellung zu ändern. Die erforderlichen Schritte finden Sie unter Konfigurieren der Routingpräferenz für virtuelle Hubs.

Wenn ein Virtual WAN-Hub über eine ExpressRoute-Leitung und eine damit verbundene VPN-Site verfügt: Wie kann erreicht werden, dass eine VPN-Verbindungsroute gegenüber ExpressRoute bevorzugt wird?

Wenn eine ExpressRoute-Leitung mit einem virtuellen Hub verbunden ist, sind die Microsoft Edge-Router jeweils der erste Knoten für die Kommunikation zwischen der lokalen Umgebung und Azure. Diese Edgerouter kommunizieren mit den Virtual WAN-ExpressRoute-Gateways, die wiederum vom Router des virtuellen Hubs über Routen informiert werden, von dem sämtliche Routen zwischen allen Gateways in Virtual WAN gesteuert werden. Von den Microsoft-Edgeroutern werden ExpressRoute-Routen des virtuellen Hubs mit einer höheren Priorität als Routen verarbeitet, über die von der lokalen Umgebung informiert wird.

Wenn aus irgendeinem Grund die VPN-Verbindung zum primären Medium für den virtuellen Hub wird, um Routen zu lernen (z. B. bei Failoverszenarien zwischen ExpressRoute und VPN), es sei denn, der VPN-Standort hat eine längere AS-Pfadlänge, dann teilt der virtuelle Hub weiterhin die von VPN gelernte Routen mit dem ExpressRoute-Gateway. Dies führt dazu, dass die Microsoft-Edgerouter VPN-Routen gegenüber den Routen der lokalen Umgebung den Vorzug geben.

Unterstützt ExpressRoute ECMP-Routing (Equal-Cost Multi-Path) in Virtual WAN?

Wenn mehrere ExpressRoute-Leitungen mit einem Virtual WAN-Hub verbunden sind, ermöglicht ECMP die Verteilung des über ExpressRoute geleiteten Datenverkehrs von virtuellen Spoke-Netzwerken an lokale Netzwerke über zwei ExpressRoute-Leitungen (entspricht bis zu vier ExpressRoute-Verbindungen), die die gleichen lokalen Routen ankündigen. ECMP wird derzeit für Virtual WAN-Hubs nicht standardmäßig aktiviert. Um ECMP für Ihre Umgebung zu aktivieren, können Sie eine Routenzuordnung für Ihren virtuellen Hub erstellen. Wenn Sie eine Routenkarte erstellen, wird Ihr virtueller Hub automatisch auf die neueste Softwareversion aktualisiert, die ECMP unterstützt, unabhängig davon, ob diese Routenzuordnung auf verbindungen angewendet wird. Daher müssen Sie nur die Schritte 1 bis 7 in "Konfigurieren von Routenkarten" ausführen. Wenn Sie nicht beabsichtigen, die Route-Karte zu verwenden, können Sie die Route-Karte löschen, nachdem Schritt 7 abgeschlossen ist, da Hubs mit einer Routenkarte zusätzliche Kosten verursachen. Es wird empfohlen, eine Routenkarte in Ihrer Testumgebung zu erstellen und Routing und Konnektivität zu validieren, bevor Sie eine Routenkarte in Ihrer Produktionsumgebung erstellen.

Wenn zwei Hubs (Hub 1 und 2) verbunden sind und es eine ExpressRoute-Leitung gibt, die als Schleife mit beiden Hubs verbunden ist, wie ist der Pfad für ein mit Hub 1 verbundenes VNET, um ein mit Hub 2 verbundenes VNET zu erreichen?

Das derzeitige Verhalten besteht darin, für VNET-zu-VNET-Konnektivität den ExpressRoute-Leitungspfad gegenüber Hub-zu-Hub vorzuziehen. In einem Virtual WAN-Setup wird dies jedoch nicht empfohlen. Sie können eine von zwei Möglichkeiten nutzen, um dieses Problem zu beheben:

• Konfigurieren Sie mehrere ExpressRoute-Leitungen (verschiedene Anbieter), um eine Verbindung mit einem Hub herzustellen und die von Virtual WAN bereitgestellte Hub-zu-Hub-Konnektivität für die regionsübergreifende Datenübertragung zu nutzen.

• Konfigurieren Sie AS-Path als Hubroutingpräferenz für Ihren virtuellen Hub. So wird sichergestellt, dass der Datenverkehr zwischen den beiden Hubs den virtuellen Router in den einzelnen Hubs durchläuft und einen Hub-zu-Hub-Pfad anstelle des ExpressRoute-Pfads (der die Microsoft Edge-Router/MSEE durchläuft) verwendet. Weitere Informationen finden Sie unter Konfigurieren der Routingpräferenz für virtuelle Hubs.

Wenn es eine ExpressRoute-Leitung gibt, die als Bow-Tie mit einem Virtual WAN-Hub und einem eigenständigen VNet verbunden ist, wie sieht dann der Pfad aus, über den das eigenständige VNet den Virtual WAN-Hub erreichen kann?

Bei neuen Bereitstellungen ist diese Konnektivität standardmäßig blockiert. Um diese Konnektivität zu ermöglichen, können Sie diese ExpressRoute-Gateway-Umschaltungen in "Virtuellen Hub bearbeiten" und im Portal "Virtuelles Netzwerkgateway" aktivieren. Es wird jedoch empfohlen, diese Umschaltfläche deaktiviert zu halten und stattdessen eine Virtuelle Netzwerkverbindung zu erstellen , um eigenständige VNets direkt mit einem virtuellen WAN-Hub zu verbinden. Anschließend durchläuft VNet-zu-VNet-Datenverkehr den Virtuellen WAN-Hubrouter, der eine bessere Leistung als den ExpressRoute-Pfad bietet. Der ExpressRoute-Pfad umfasst:

• Das ExpressRoute-Gateway mit geringerer Bandbreite als der Hubrouter
• und die Microsoft Enterprise Edge-Router/MSEE, bei denen es sich um einen zusätzlichen Hop im Datenpfad handelt.

Im folgenden Diagramm müssen beide Umschaltvorgänge aktiviert sein, um die Verbindung zwischen dem eigenständigen VNet 4 und den VNets zu ermöglichen, die direkt mit Hub 2 (VNet 2 und VNet 3) verbunden sind: Datenverkehr von remoten virtuellen WAN-Netzwerken für das virtuelle Netzwerkgateway zulassen und Datenverkehr von nicht virtuellen WAN-Netzwerken für das ExpressRoute-Gateway des virtuellen Hubs zulassen. Wenn ein Azure Route Server im eigenständigen VNet 4 bereitgestellt wird und für den Route Server Branch-zu-Branch aktiviert ist, wird die Konnektivität zwischen VNet 1 und dem eigenständigen VNet 4 blockiert.

Das Aktivieren oder Deaktivieren der Umschaltfläche wirkt sich nur auf den folgenden Datenverkehrsfluss aus: Datenverkehr, der zwischen dem Virtual WAN-Hub und eigenständigen VNets über die ExpressRoute-Leitung fließt. Das Aktivieren oder Deaktivieren der Umschaltfläche führt nicht zu einer Downtime für alle anderen Datenverkehrsflüsse (z. B. werden die Datenverkehrsflüsse vom lokalen Standort zu Spoke-VNet 2, von VNet 2 zu VNet 3 usw. nicht beeinträchtigt).

Wenn ich eine ExpressRoute-Verbindung aktualisiere, wirkt sich dies auf die Konnektivität für meine anderen ExpressRoute-Verbindungen aus?

Wenn Sie einen Erstellungs-, Aktualisierungs- oder Löschvorgang für eine ExpressRoute-Verbindung ausführen, werden Ihre anderen ExpressRoute-Verbindungen in einem Status "Aktualisieren" im Portal angezeigt. Die Konnektivität über diese ExpressRoute-Verbindungen wird jedoch nicht beeinträchtigt.

Warum funktioniert die Konnektivität nicht, wenn ich Routen mit einer ASN von 0 im AS-Pfad anbiete?

Der virtuelle WAN-Hub legt Routen mit einem ASN von 0 im AS-Pfad ab. Um sicherzustellen, dass diese Routen erfolgreich in Azure angekündigt werden, sollte der AS-Path nicht 0 enthalten.

Können Hubs in anderen Ressourcengruppen in Virtual WAN erstellt werden?

Yes. Diese Option ist derzeit nur über PowerShell verfügbar. Das Virtual WAN-Portal erfordert, dass sich die Hubs in der gleichen Ressourcengruppe befinden wie die Virtual WAN-Ressource.

Welcher Hubadressraum wird während der Huberstellung empfohlen?

Der empfohlene Adressraum für einen virtuellen WAN-Hub ist /23 oder größer. Es ist wichtig zu beachten, dass der Hubadressraum nach dem Erstellen des Hubs nicht geändert werden kann. Um den Hubadressraum zu ändern, müssen Sie den virtuellen Hub erneut bereitstellen, was zu Ausfallzeiten führen kann.

Der virtuelle WAN-Hub weist Subnetze aus dem angegebenen Adressraum automatisch verschiedenen Azure-Diensten zu, darunter:

• Virtual Hub Router
• ExpressRoute
• Standort-zu-Standort-VPN
• Point-to-Site-VPN
• Azure Firewall

Für Szenarien, in denen Netzwerk virtual Appliances (NVAs) innerhalb des virtuellen Hubs bereitgestellt werden, wird ein zusätzliches Subnetz für die NVA-Instanzen zugewiesen. In der Regel wird ein /28-Subnetz für eine kleine Anzahl von NVAs zugewiesen. Wenn jedoch mehrere NVAs bereitgestellt werden, kann ein /27-Subnetz zugewiesen werden.

Um zukünftige Skalierbarkeits- und Architekturanforderungen zu erfüllen, während der Mindestadressraum für einen virtuellen WAN-Hub /24 beträgt, empfiehlt es sich, einen /23-Adressraum oder einen größeren Adressraum während der Huberstellung anzugeben.

Wird IPv6 in Virtual WAN unterstützt?

IPv6 wird im Virtual WAN-Hub und seinen Gateways nicht unterstützt. Wenn Sie ein Spoke-VNet mit einem IPv6-Adressbereich mit dem Virtual WAN-Hub verbinden, funktioniert nur die IPv4-Konnektivität mit diesem Spoke-VNet. IPv6-Konnektivität mit diesem Speichen-VNet wird nicht unterstützt.

Wenn Sie IPv6-Präfixe lokal bewerben, wird dadurch die IPv4-Konnektivität für Ihre Azure-Ressourcen unterbrochen.

Für das Point-to-Site-VPN-Szenario (Benutzer) mit Internetabzweigung über Azure Firewall müssen Sie wahrscheinlich IPv6-Konnektivität auf Ihrem Clientgerät deaktivieren, um die Weiterleitung des Datenverkehrs an den Virtual WAN-Hub zu erzwingen. Das liegt daran, dass von modernen Geräten IPv6-Adressen verwendet werden.

Welche API-Version wird für die Verwendung durch Skripts empfohlen, mit denen verschiedene Virtual WAN-Funktionen automatisiert werden?

Hierfür ist mindestens Version „05-01-2022“ (1. Mai 2022) erforderlich.

Gibt es Grenzwerte für Virtual WAN?

Informationen finden Sie auf der Seite „Einschränkungen für Azure-Abonnements und Dienste, Kontingente und Einschränkungen“ im Abschnitt Grenzwerte für Virtual WAN.

Welche Unterschiede bestehen zwischen den Virtual WAN-Typen („Basic“ und „Standard“)?

Weitere Informationen finden Sie unter Virtual WANs des Typs „Basic“ und „Standard“. Informationen zu den Preisen finden Sie auf der Seite Virtual WAN – Preise.

Speichert Virtual WAN Kundendaten?

No. Virtual WAN speichert keine Kundendaten.

Gibt es Anbieter verwalteter Dienste (Managed Service Providers, MSPs), die Virtual WAN für Benutzer als Dienst verwalten können?

Yes. Eine Liste mit Lösungen von Anbietern verwalteter Dienste, die über Azure Marketplace erhältlich sind, finden Sie unter Azure Marketplace-Angebote nach Azure Networking-MSP-Partnern.

Inwiefern unterscheidet sich das Routing für den Virtual WAN-Hub von Azure Route Server in einem VNET?

Sowohl der Azure Virtual WAN-Hub als auch Azure Route Server bieten BGP-Peeringfunktionen (Border Gateway Protocol), die von virtuellen Netzwerkgeräten (Network Virtual Appliance, NVA) verwendet werden können, um den virtuellen Azure-Netzwerken des Benutzers bzw. der Benutzerin IP-Adressen des NVAs anzukündigen. Die Bereitstellungsoptionen unterscheiden sich insofern, als dass Azure Route Server in der Regel von einem selbstverwalteten Kundenhub-VNet bereitgestellt wird, wohingegen Azure Virtual WAN einen vollständig vernetzten Zero-Touch-Hubdienst bietet, mit dem die Kunden ihre verschiedenen Spoke-Endpunkte (Azure VNet, lokale Zweigstellen mit Site-to-Site-VPN oder SDWAN, Remotebenutzer mit Point-to-Site-/Remotebenutzer-VPN und private Verbindungen mit ExpressRoute) verbinden und vom BGP-Peering für die im Spoke-VNet bereitgestellten NVAs sowie von anderen vWAN-Funktionen profitieren. Dazu zählen beispielsweise Transitkonnektivität zwischen VNets, Transitkonnektivität zwischen VPN und ExpressRoute, benutzerdefiniertes/erweitertes Routing, benutzerdefinierte Routenzuordnung und -verbreitung, Routingabsicht/-richtlinien für unkomplizierte regionsübergreifende Sicherheit oder Secure Hub/Azure Firewall. Weitere Details zum BGP-Peering in Virtual WAN finden Sie unter BGP-Peering mit einem virtuellen Hub.

Wenn ich einen Drittanbieter für Sicherheit (Zscaler, iBoss oder Checkpoint) verwende, um meinen Datenverkehr zu sichern, warum wird dann im Azure-Portal nicht die VPN-Site angezeigt, die dem Drittanbieter für Sicherheit zugeordnet ist?

Wenn Sie sich für die Bereitstellung eines Sicherheitspartneranbieters entscheiden, um den Internetzugriff Ihrer Benutzer zu schützen, erstellt der Drittanbieter für die Sicherheit in Ihrem Namen einen VPN-Standort. Da der Drittanbieter für die Sicherheit automatisch vom Anbieter erstellt wird und kein vom Benutzer erstellter VPN-Standort ist, wird dieser VPN-Standort nicht im Azure-Portal angezeigt.

Weitere Informationen zu den verfügbaren Optionen von Drittanbietern für die Sicherheit und deren Einrichtung finden Sie unter Bereitstellen eines Sicherheitspartneranbieters.

Bleiben die lokal generierten BGP-Communitys in Virtual WAN erhalten?

Ja, die lokal generierten BGP-Communitys bleiben in Virtual WAN erhalten.

Werden von BGP-Peers generierte BGP-Communitys (in einem angefügten virtuellen Netzwerk) in Virtual WAN beibehalten?

Ja, die von BGP-Peers generierten BGP-Communitys bleiben in Virtual WAN erhalten. Communitys werden über denselben Hub und über Interhub-Verbindungen hinweg beibehalten. Dies gilt auch für Virtual WAN-Szenarien mit Routingabsichtsrichtlinien.

Welche ASN-Nummern werden für remote angefügte lokale Netzwerke unterstützt, die BGP ausführen?

Sie können Ihre eigenen öffentlichen ASNs oder privaten ASNs für Ihre lokalen Netzwerke verwenden. Die von Azure oder IANA reservierten Bereiche können nicht verwendet werden:

• Von Azure reservierte ASNs:
  • Öffentliche ASNs: 8074, 8075, 12076
  • Private AS-Nummern: 65515, 65517, 65518, 65519, 65520
  • Von IANA reservierte ASNs: 23456, 64496-64511, 65535-65551

Gibt es eine Möglichkeit, die ASNs in Virtual WAN zu ändern?

No. Virtual WAN unterstützt keine ASN-Änderungen für Virtual Hubs oder Gateways.

Wie hoch ist die geschätzte Leistung der ExpressRoute-Gateway-SKU in Virtual WAN?

Es ist wichtig, die folgenden Punkte zu berücksichtigen:

• Bei Wartungsvorgängen behalten Skalierungseinheiten 2 bis 10 ihren Aggregatdurchsatz bei. Skalierungseinheit 1 kann jedoch bei solchen Vorgängen geringfügige Durchsatzschwankungen aufweisen.
• Unabhängig von der Anzahl der bereitgestellten Skalierungseinheiten kann die Datenverkehrsleistung beeinträchtigt werden, wenn ein einzelner TCP-Fluss 1,5 GBit/s überschreitet.

Wenn ich eine lokale ExpressRoute-Leitung mit einem Virtual WAN-Hub verbinde, kann ich nur auf Regionen am selben Metro-Standort wie die lokale Leitung zugreifen?

Lokale Leitungen können nur mit ExpressRoute-Gateways in ihrer entsprechenden Azure-Region verbunden werden. Es gibt jedoch keine Einschränkung für die Weiterleitung von Datenverkehr an virtuelle Spoke-Netzwerke in anderen Regionen.

Warum benötigt der virtuelle Hub-Router eine öffentliche IP-Adresse mit offenen Ports?

Diese öffentlichen Endpunkte sind erforderlich, damit die zugrunde liegende SDN- und Verwaltungsplattform von Azure mit dem virtuellen Hubrouter kommunizieren kann. Da der virtuelle Hubrouter als Teil des privaten Netzwerks der Kundinnen und Kunden betrachtet wird, kann die zugrunde liegende Azure-Plattform aufgrund der Complianceanforderungen nicht direkt auf den Hubrouter zugreifen und ihn über die privaten Endpunkte verwalten. Die Konnektivität mit den öffentlichen Endpunkten des Hubrouters wird über Zertifikate authentifiziert, und Azure führt routinemäßige Sicherheitsüberwachungen dieser öffentlichen Endpunkte durch. Daher stellen sie keine Sicherheitsrisiken für Ihren virtuellen Hub dar.

Gibt es ein Routenlimit für OpenVPN-Clients, die eine Verbindung mit einem Azure P2S-VPN-Gateway herstellen?

Das Routenlimit für OpenVPN-Clients beträgt 1.000.

Wie wird die Vereinbarung zum Servicelevel (SLA) für Virtual WAN berechnet?

Virtual WAN ist eine Networking-as-a-Service-Plattform (Netzwerk als Dienst), die über eine SLA von 99,95 % verfügt. Virtual WAN kombiniert jedoch viele verschiedene Komponenten wie Azure Firewall, Site-to-Site-VPN, ExpressRoute, Point-to-Site-VPN und Virtual WAN-Hub/Integrierte virtuelle Netzwerkgeräte (NVA).

Die SLA für jede Komponente wird einzeln berechnet. Bei einer Ausfallzeit von 10 Minuten für ExpressRoute würde die Verfügbarkeit von ExpressRoute als (Maximale Verfügbare Minuten - Ausfallzeit) / Maximale verfügbare Minuten * 100 berechnet.

Können Sie den VNet-Adressraum in einem mit dem Hub verbundenen Spoke-VNet ändern?

Ja, dies kann automatisch vorgenommen werden, ohne dass eine Aktualisierung oder Zurücksetzung für die Peering-Verbindung erforderlich ist. Beachten Sie Folgendes:

• Sie müssen auf dem Blatt „Peering“ nicht auf die Schaltfläche Synchronisieren klicken. Sobald der Adressraum des VNet geändert wurde, wird das VNet-Peering automatisch mit dem VNet des virtuellen Hubs synchronisiert.
• Stellen Sie sicher, dass sich der aktualisierte Adressraum nicht mit dem Adressraum für vorhandene Spoke-VNets in Ihrem Azure Virtual WAN überlappt.

Weitere Informationen zum Ändern des VNet-Adressraums finden Sie unter Erstellen, Ändern oder Löschen eines virtuellen Netzwerks.

Wie viele virtuelle Spoke-Netzwerkadressen werden für Hubs unterstützt, die mit Routingabsicht konfiguriert sind?

Die maximale Anzahl von Adressräumen in allen virtuellen Netzwerken, die direkt mit einem einzelnen virtuellen WAN-Hub verbunden sind, beträgt 600. Dieser Grenzwert wird einzeln auf jeden Virtual WAN-Hub in einer Virtual WAN-Bereitstellung angewendet. VNet-Adressräume, die mit Remote-Hubs (andere Virtual WAN-Hubs in demselben Virtual WAN) verbunden sind, werden nicht auf diesen Grenzwert angerechnet.

Weitere Informationen zum Grenzwert und Beispielskripts zum Bestimmen der Anzahl der Adressräume in virtuellen Netzwerken, die mit einem Virtual WAN-Hub verbunden sind, finden Sie unter Routingabsicht – Grenzwerte für den Adressraum des virtuellen Netzwerks.

Kann ich Azure Bastion mit Virtual WAN verwenden?

Ja, aber es gibt Einschränkungen. Weitere Details finden Sie unter Häufig gestellte Fragen zu Azure Bastion.

Kundenseitig gesteuerte Wartung von Virtual WAN-Gateways

Welche Dienste sind im Bereich der Wartungskonfiguration von Netzwerkgateways enthalten?

Für virtuelles WAN können Sie Wartungsfenster für Standort-zu-Standort-VPN-Gateways, Point-to-Site-VPN-Gateways und ExpressRoute-Gateways konfigurieren.

Dieses Feature wird auch für Azure Firewalls in Virtual WAN-sicheren Hubs unterstützt.

Welche Wartung wird von der kundenseitig gesteuerten Wartung unterstützt?

Azure-Dienste durchlaufen regelmäßige Wartungsupdates, um Funktionen sowie die Zuverlässigkeit, Leistung und Sicherheit zu verbessern. Nachdem Sie ein Wartungsfenster für Ihre Ressourcen konfiguriert haben, werden die Gastbetriebssystem- und die Dienstwartung während dieses Fensters ausgeführt. Diese Updates berücksichtigen die meisten Wartungselemente, die für die Kund*innen problematisch sind.

Updates der zugrunde liegende Hosthardware und der Rechenzentrumsinfrastruktur sind nicht Teil der kundenseitig gesteuerten Wartung. Im Fall eines Sicherheitsproblems mit hohem Schweregrad, das eine Gefahr für unsere Kund*innen darstellt, kann es zudem vorkommen, dass Azure die kundenseitige Steuerung des Wartungsfensters außer Kraft setzen und die Änderung anwenden muss. Das kommt allerdings äußerst selten und nur in Extremfällen vor.

Kann ich eine Vorabbenachrichtigung für die Wartung erhalten?

Zurzeit können Vorabbenachrichtigungen nicht für die Wartung von Netzwerkgatewayressourcen aktiviert werden.

Kann ich ein Wartungsfenster von weniger als fünf Stunden konfigurieren?

Derzeit müssen Sie ein mindestens fünfstündiges Wartungsfenster in Ihrer bevorzugten Zeitzone konfigurieren.

Kann ich einen Wartungszeitplan konfigurieren, der nicht täglich wiederholt wird?

Derzeit muss ein tägliches Wartungsfenster konfiguriert werden.

Müssen sich Ressourcen für die Wartungskonfiguration in der gleichen Region befinden wie die Gatewayressource?

Yes.

Muss ich eine Mindestskalierungseinheit für ein Gateway bereitstellen, um die kundenseitig gesteuerte Wartung nutzen zu können?

No.

Wie lange dauert es, bis die Richtlinie für die Wartungskonfiguration wirksam wird, nachdem sie der Gatewayressource zugewiesen wurde?

Es kann bis zu 24 Stunden dauern, bis Netzwerkgateways dem Wartungszeitplan folgen, nachdem die Wartungsrichtlinie der Gatewayressource zugeordnet wurde.

Wie sollte ich Wartungsfenster planen, wenn ich gleichzeitig VPN und ExpressRoute verwende?

Wenn Sie VPN und ExpressRoute parallel verwenden oder über Ressourcen verfügen, die als Sicherungen fungieren, empfiehlt es sich, separate Wartungsfenster einzurichten. Durch diesen Ansatz wird sichergestellt, dass sich die Wartung nicht gleichzeitig auf Ihre Sicherungsressourcen auswirkt.

Ich habe für eine meiner Ressourcen ein Wartungsfenster für ein zukünftiges Datum geplant. Werden Wartungsaktivitäten für diese Ressource bis zu diesem Datum ausgesetzt?

Nein. Wartungsaktivitäten werden im Zeitraum vor dem geplanten Wartungsfenster nicht für Ihre Ressource ausgesetzt. Für die Tage, die nicht in Ihrem Wartungszeitplan enthalten sind, wird die Wartung wie gewohnt für die Ressource fortgesetzt.

Gibt es Limits hinsichtlich der Anzahl von Routen, die ich ankündigen kann?

Ja, es gibt Grenzwerte. ExpressRoute unterstützt bis zu 4,000 Präfixe für privates Peering und 200 Präfixe für Microsoft-Peering. Mit ExpressRoute Premium können Sie das Limit auf 10.000 Routen für privates Peering erhöhen. Die maximale Anzahl von Routen, die von privatem Azure-Peering über ein ExpressRoute-Gateway über einen ExpressRoute-Schaltkreis angekündigt werden, beträgt 1.000 und ist für Standard- und Premium-ExpressRoute-Leitungen identisch. Weitere Details finden Sie unter ExpressRoute-Routenbeschränkungen auf der Seite „Grenzwerte und Kontingente für Azure-Abonnements“. Beachten Sie, dass IPv6-Routenankündigungen derzeit mit virtual WAN nicht unterstützt werden.

Gibt es Einschränkungen hinsichtlich der IP-Adressbereiche, die ich über die BGP-Sitzung ankündigen kann?

Ja, es gibt Einschränkungen. Private Präfixe (RFC1918) werden in der Microsoft-BGP-Peeringsitzung nicht akzeptiert. Allerdings wird für das Microsoft- und das private Peering eine Präfixgröße bis zu /32 Präfixe akzeptiert.

Was geschieht, wenn das BGP-Routenlimit überschritten wird?

Wenn der BGP-Routengrenzwert überschritten wird, trennen BGP-Sitzungen die Verbindung. Die Sitzungen werden wiederhergestellt, sobald die Präfixanzahl unter den Grenzwert reduziert wurde. Weitere Informationen finden Sie in den ExpressRoute-Routenbeschränkungen auf der Seite „Grenzwerte und Kontingente für Azure-Abonnements.

Kann ich die Anzahl der angekündigten oder empfangenen Routen über eine ExpressRoute-Leitung überwachen?

Ja, das ist möglich. Die bewährten Methoden und Konfigurationen für die metrikbasierte Warnungsüberwachung finden Sie in den bewährten Methoden für die Azure-Überwachung.

Was bedeutet die Empfehlung, die Anzahl der IP-Präfixe zu verringern?

Es wird empfohlen, die Präfixe zu aggregieren, bevor sie über ExpressRoute oder VPN-Gateway angekündigt werden. Darüber hinaus können Sie Routenzuordnungen verwenden, um von/zu virtual WAN angekündigte Routen zusammenzufassen.

Kann ich benutzerdefinierte Routingtabellen in virtuellen Speichen-Netzwerken verwenden, die mit einem virtuellen WAN-Hub verbunden sind?

Yes. Die Routen, die der Virtual WAN Hub für Ressourcen anzeigt, die in verbundenen virtuellen Speichen-Netzwerken eingesetzt werden, sind Routen vom Typ Border Gateway Protocol (BGP). Wenn eine benutzerdefinierte Routingtabelle mit einem Subnetz verbunden ist, das mit Virtual WAN verbunden ist, muss die Einstellung „Gateway Routes verteilen“ auf „Ja“ gesetzt werden, damit Virtual WAN Ressourcen in diesem Subnetz ankündigen kann. Die zugrunde liegende softwaredefinierte Netzwerkplattform von Azure verwendet den folgenden Algorithmus, um Routen basierend auf dem Azure-Routenauswahlalgorithmus auszuwählen.

Warum treten Konnektivitätsprobleme auf, Azure-Routen wieder an Azure angekündigt wurden?

Wenn Sie beabsichtigen, Azure BGP-Communitys aus virtuellen Netzwerken und UDR-Routen zu entfernen, bewerben Sie diese Routen nicht zurück in Azure, da dies Routingprobleme verursacht. Es wird nicht empfohlen, Azure-Routen zurück in Azure anzukündigen.

Nächste Schritte

Weitere Informationen zu Virtual WAN finden Sie unter Informationen zu Virtual WAN.