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 verfügt über viele Funktionen, die in einer zentralen Benutzeroberfläche zusammengefasst sind, z. B. Site-/Site-to-Site-VPN-Konnektivität, Benutzer-/P2S-Konnektivität, ExpressRoute-Konnektivität, Virtual Network-Konnektivität, VPN/ExpressRoute-Konnektivität, transitive VNET-zu-VNET-Konnektivität, zentralisiertes Routing, Azure Firewall- und Firewall Manager-Sicherheit, Überwachung, ExpressRoute-Verschlüsselung und viele mehr. Sie müssen nicht all diese Anwendungsfälle abdecken, um Virtual WAN nutzen zu können. 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.
Virtual WAN-Partner ermöglichen die Automatisierung in Bezug auf die Konnektivität. Hierbei handelt es sich um eine Option zum Exportieren der Geräteinformationen nach Azure, Herunterladen der Azure-Konfiguration und Herstellen der Konnektivität mit dem Azure Virtual WAN-Hub. 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.
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 Virtual WAN-Hub gibt es mehrere Dienste wie VPN, ExpressRoute usw. Jeder dieser Dienste wird automatisch für Verfügbarkeitszonen übergreifend bereitgestellt (mit Ausnahme von Azure Firewall), sofern Verfügbarkeitszonen für die Region unterstützt werden. 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 zur Unterstützung von Verfügbarkeitszonen über das Azure Firewall Manager-Portal, über PowerShell oder die CLI bereitgestellt werden. 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-Instanz 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. Falls die virtuelle WAN-Region selbst ein Problem aufweisen sollte, werden alle Hubs in diesem virtuellen WAN weiterhin unverändert funktionieren, aber der Benutzer kann keine neuen Hubs erstellen, bis die virtuelle WAN-Region verfügbar ist.
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 benutzerdefinierter Routen, die auf die Firewall eines anderen gesicherten Hubs verweisen, schlägt fehl und wird nicht erfolgreich abgeschlossen. Bitte ziehen Sie in Betracht, diese Hubs in gesicherte Hubs mit ihren eigenen Firewalls zu konvertieren.
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. 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.
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 serversFalls 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 nachstehenden Tabelle wird die Anzahl gleichzeitiger Verbindungen und der aggregierte Durchsatz des Point-to-Site-VPN Gateway beschrieben, die in verschiedenen Skalierungseinheiten unterstützt werden.
| Skalierungseinheit | Gateway-Instanzen | Support gleichzeitiger Verbindungen | Aggregierter Durchsatz |
|---|---|---|---|
| 1 | 2 | 500 | 0.5 GBit |
| 2 | 2 | 500 | 1 GBit/s |
| 3 | 2 | 500 | 1,5 GBit/s |
| 4 | 2 | 1000 | 2 GBit/s |
| 5 | 2 | 1000 | 2,5 GBit/s |
| 6 | 2 | 1000 | 3 GBit/s |
| 7 | 2 | 5.000 | 3,5 GBit/s |
| 8 | 2 | 5.000 | 4 GBit/s |
| 9 | 2 | 5.000 | 4,5 GBit/s |
| 10 | 2 | 5.000 | 5 GBit/s |
| 11 | 2 | 10000 | 5,5 GBit/s |
| 12 | 2 | 10000 | 6 GBit/s |
| 13 | 2 | 10000 | 6,5 GBit/s |
| 14 | 2 | 10000 | 7 GBit/s |
| 15 | 2 | 10000 | 7,5 GBit/s |
| 16 | 2 | 10000 | 8 GBit/s |
| 17 | 2 | 10000 | 8,5 GBit/s |
| 18 | 2 | 10000 | 9 GBit/s |
| 19 | 2 | 10000 | 9,5 GBit/s |
| 20 | 2 | 10000 | 10 GBit/s |
| 40 | 4 | 20000 | 20GBit/s |
| 60 | 6 | 30.000 | 30 GBit/s |
| 80 | 8 | 40.000 | 40 GBit/s |
| 100 | 10 | 50000 | 50 GBit/s |
| 120 | 12 | 60000 | 60 GBit |
| 140 | 14 | 70000 | 70 GBit/s |
| 160 | 16 | 80.000 | 80 GBit/s |
| 180 | 18 | 90000 | 90 GBit |
| 200 | 20 | 100.000 | 100 GBit/s |
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.
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 verwenden, was bedeutet, dass Sie mehr als 1.000 Branches mit einer einzelnen Azure-Region verbinden können, indem Sie mehrere Virtual WAN-Hubs in dieser Azure-Region bereitstellen, jeder mit seinem eigenen Site-to-Site-VPN-Gateway.
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 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.
Virtual WAN bietet Konzepte wie VPN-Verbindung, Linkverbindung und Tunnel. 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 enden können, beträgt 1.000. Dies bedeutet auch, dass der Durchsatz für eine Instanz aggregiert über alle Tunnel verfügbar ist, die eine Verbindung mit dieser Instanz herstellen. 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
| Skalierungseinheit | Max. Durchsatz pro Tunnel (MBit/s) | Max. PPS pro Tunnel | Max. Durchsatz pro Instanz (MBit/s) | Max. PPS pro Instanz |
|---|---|---|---|---|
| 1 | 500 | 47.000 | 500 | 47.000 |
| 2 | 1000 | 94.000 | 1000 | 94.000 |
| 3 | 1500 | 140 Tsd. | 1500 | 140 Tsd. |
| 4 | 1500 | 140 Tsd. | 2000 | 187.000 |
| 5 | 1500 | 140 Tsd. | 2500 | 234.000 |
| 6 | 1500 | 140 Tsd. | 3000 | 281.000 |
| 7 | 2300 | 215.000 | 3500 | 328.000 |
| 8 | 2300 | 215.000 | 4000 | 374.000 |
| 9 | 2300 | 215.000 | 4500 | 421.000 |
| 10 | 2300 | 215.000 | 5.000 | 468.000 |
| 11 | 2300 | 215.000 | 5500 | 515.000 |
| 12 | 2300 | 215.000 | 6000 | 562.000 |
| 13 | 2300 | 215.000 | 6500 | 609.000 |
| 14 | 2300 | 215.000 | 7000 | 655.000 |
| 15 | 2300 | 215.000 | 7.500 | 702.000 |
| 16 | 2300 | 215.000 | 8.000 | 749.000 |
| 17 | 2300 | 215.000 | 8500 | 796.000 |
| 18 | 2300 | 215.000 | 9000 | 843.000 |
| 19 | 2300 | 215.000 | 9500 | 889.000 |
| 20 | 2300 | 215.000 | 10000 | 936.000 |
Hinweis
Alle Zahlen basieren auf dem GCM-Algorithmus.
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?
Nein. 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 dem Ökosystem eines Virtual WAN-Partners stammt, müssen Sie die Azure-Konfiguration manuell übernehmen und Ihr Gerät aktualisieren, um eine IPsec-Verbindung 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. Nachdem das Unternehmen die Automatisierungsarbeiten für sein CPE-Gerät auf der Grundlage der oben genannten Automatisierungsrichtlinien abgeschlossen hat, können Sie sich an azurevirtualwan@microsoft.com wenden, um hier aufgeführt zu werden: azurevirtualwan@microsoft.com. 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 es sich bei dem Virtual WAN-Partner um einen SD-WAN-Anbieter handelt, schließt dies ein, dass der SD-WAN-Controller die Automatisierung und IPsec-Verbindung 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 allerdings nur einen einzelnen Tunnel zu einer Instanz des Virtual WAN-VPN-Gateways verwenden möchte, gilt Folgendes: Falls die Gatewayinstanz aus irgendeinem Grund (Wartung, Patching usw.) in den Offlinezustand versetzt wird, wird der Tunnel auf die sekundäre aktive Instanz verlagert, wodurch es für den Benutzer zu einer erneuten Verbindungsherstellung kommen kann. 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. Beachten Sie außerdem, dass durch das Zurücksetzen der Gateways Ihre öffentlichen IP-Adressen nicht geändert werden.
Dieses Szenario gilt nur für die Site-to-Site-Verbindungen.
Kann vom lokalen VPN-Gerät eine Verbindung mit mehreren Hubs hergestellt werden?
Ja. 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 ein Spoke-VNET über ein Gateway für virtuelle Netzwerke verfügen?
Nein. 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?
Nein. 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 impliziert, dass alle in Azure für diesen Standort erstellten Verbindungen für BGP aktiviert sind.
Sind Informationen zu Lizenzen oder Preisen für Virtual WAN vorhanden?
Ja. 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)?
Ja. 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. Im Virtual WAN-Kontext werden diese Pfade für VNETs, die mit einem Virtual WAN-Hub in nur einer Region verbunden sind, als „lokaler VNET-Transit für Virtual WANs“ bezeichnet. Für VNETs, die über mehrere Virtual WAN-Hubs in mindestens zwei Regionen verbunden sind, werden sie als „globaler VNET-Transit für Virtual WAN“ bezeichnet.
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?
Ja. Datenverkehr zwischen Branches durchläuft Azure Virtual WAN.
Ist für die Virtual WAN-Instanz eine ExpressRoute-Verbindung mit jeder Site erforderlich?
Nein. 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 Kapazität im Voraus zu sichern, ohne darauf warten zu müssen, dass der virtuelle Hub skaliert wird, wenn mehr Durchsatz benötigt wird, 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 virtuellem 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?
Navigieren Sie im Portal zum VPN-Gateway innerhalb eines Hubs, und klicken Sie auf die Skalierungseinheit, um die entsprechende Einstellung festzulegen.
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?
Ja. 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 auf dem Virtual WAN-Hub. Sie wird weitergegeben, wenn sie dem Virtual WAN-Hub bereits bekannt ist, weil darin eine Firewall bereitgestellt wurde, oder wenn für eine andere verbundene Site die Tunnelerzwingung aktiviert ist. Eine Standardroute wird nicht zwischen Hubs weitergegeben.
Ist es möglich, mehrere Virtual WAN-Hubs in derselben Region zu erstellen?
Ja. 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?
Die Übertragung zwischen ER-zu-ER erfolgt immer über Global Reach. 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.
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?
Ja. 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.
Falls die VPN-Verbindung aus irgendeinem Grund zum primären Medium für den virtuellen Hub wird und Routen von dieser Verbindung erhalten soll (z. B. bei Failoverszenarien zwischen ExpressRoute und VPN), passiert Folgendes: Sofern der VPN-Standort nicht über längere AS-Pfade verfügt, gibt der virtuelle Hub erlernte VPN-Routen weiterhin an das ExpressRoute-Gateway weiter. 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-Verbindungen mit einem Virtual WAN-Hub verbunden sind, ermöglicht ECMP die Verteilung des über ExpressRoute geleiteten Datenverkehrs von virtuellen Spokenetzwerken an lokale Netzwerke über alle ExpressRoute-Verbindungen, die die gleichen lokalen Routen bedienen. ECMP wird derzeit für Virtual WAN-Hubs nicht standardmäßig aktiviert.
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 Umschaltpunkte deaktiviert zu lassen 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 enthält das ExpressRoute-Gateway, das niedrigere Bandbreitenbeschränkungen als der Hubrouter hat, sowie die Microsoft Enterprise Edge-Router/MSEE, die einen zusätzlichen Hop im Datenpfad darstellen.
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).
Können Hubs in anderen Ressourcengruppen in Virtual WAN erstellt werden?
Ja. 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 Virtual WAN-Hubadressraum ist /23. Der Virtual WAN-Hub weist Subnetze verschiedenen Gateways zu (ExpressRoute, Site-to-Site-VPN, Point-to-Site-VPN, Azure Firewall, virtueller Hubrouter). In Szenarien, in denen NVAs innerhalb eines virtuellen Hubs bereitgestellt werden, wird in der Regel /28 für die NVA-Instanzen verwendet. Wenn der Benutzer jedoch mehrere NVAs bereitstellt, wird möglicherweise ein Subnetz vom Typ „/27“ zugewiesen. Virtual WAN-Hubs werden zwar mit einer Mindestgröße von /24 bereitgestellt, in Anbetracht der Entwicklung zukünftiger Architekturen wird für den Benutzer zum Zeitpunkt der Erstellung aber die Eingabe eines Hubadressraums der Größe /23 empfohlen.
Wird IPv6 in Virtual WAN unterstützt?
IPv6 wird im Virtual WAN-Hub und seinen Gateways nicht unterstützt. Wenn Sie über ein VNET mit IPv4- und IPv6-Unterstützung verfügen und das VNET mit einer Virtual WAN-Instanz verbinden möchten, wird dieses Szenario derzeit nicht unterstützt.
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?
Nein. 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?
Ja. 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 ASNs: 65515, 65517, 65518, 65519, 65520
- Von IANA reservierte ASNs: 23456, 64496-64511, 65535-65551
Gibt es eine Möglichkeit, das ASN für ein VPN-Gateway zu ändern?
Nein Virtual WAN unterstützt keine ASN-Änderungen (Autonomous System Number, autonome Systemnummer) für VPN-Gateways.
Wie hoch ist die geschätzte Leistung der ExpressRoute-Gateway-SKU in Virtual WAN?
| Skalierungseinheit | Verbindungen pro Sekunde | Megabits pro Sekunde | Pakete pro Sekunde |
|---|---|---|---|
| 1 Skalierungseinheit |
14.000 | 2\.000 | 200.000 |
| 2 Skalierungseinheiten |
28.000 | 4\.000 | 400.000 |
| 3 Skalierungseinheiten |
42.000 | 6\.000 | 600.000 |
| 4 Skalierungseinheiten |
56.000 | 8\.000 | 800.000 |
| 5 Skalierungseinheiten |
70.000 | 10.000 | 1\.000.000 |
| 6 Skalierungseinheiten |
84.000 | 12.000 | 1\.200.000 |
| 7 Skalierungseinheiten |
98.000 | 14.000 | 1.400.000 |
| 8 Skalierungseinheiten |
112.000 | 16.000 | 1\.600.000 |
| 9 Skalierungseinheiten |
126.000 | 18.000 | 1.800.000 |
| 10 Skalierungseinheiten |
140.000 | 20.000 | 2\.000.000 |
Skalierungseinheiten von 2 bis 10 behalten während Wartungsvorgängen den aggregierten Durchsatz bei. Bei Skalierungseinheit 1 kann es jedoch während eines Wartungsvorgangs zu einer geringfügigen Abweichung bei den Durchsatzwerten führen.
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 wird im Portal eine Meldung und Schaltfläche mit dem Namen „Update router to latest software version“ (Router auf die neueste Softwareversion aktualisieren) angezeigt?
Hinweis
Ab dem 1. Juli 2024 werden Hubs, auf denen die alte Version ausgeführt wird, schrittweise außer Betrieb genommen und funktionieren nicht mehr wie erwartet.
Die Azure-weite Cloud Services-basierte Infrastruktur wird eingestellt. Deshalb hat das Virtual WAN-Team daran gearbeitet, virtuelle Router von der aktuellen Cloud Services-Infrastruktur auf VMSS-basierte Bereitstellungen zu aktualisieren. Alle neu erstellten virtuellen Hubs werden automatisch in der neuesten auf Virtual Machine Scale Sets basierenden Infrastruktur bereitgestellt. Wenn Sie zu Ihrer Virtual WAN-Hubressource navigieren und diese Meldung und Schaltfläche sehen, können Sie ihren Router auf die neueste Version aktualisieren, indem Sie auf die Schaltfläche klicken. Wenn Sie neue Virtual WAN-Features nutzen möchten, z. B. BGP-Peering mit dem Hub, müssen Sie Ihren virtuellen Hubrouter über das Azure-Portal aktualisieren. Wenn die Schaltfläche nicht sichtbar ist, öffnen Sie einen Supportfall.
Sie können Ihren virtuellen Hubrouter nur aktualisieren, wenn sich alle Ressourcen (Gateways/Routingtabellen/VNET-Verbindungen) in Ihrem Hub im Zustand „Erfolgreich“ befinden. Bitte stellen Sie sicher, dass sich alle Ihre Spoke-VNets in aktiven/aktivierten Abonnements befinden und sie nicht gelöscht werden. Da für diesen Vorgang außerdem die Bereitstellung neuer virtueller Hubrouter auf Basis von VM-Skalierungsgruppen erforderlich ist, wird eine erwartete Downtime von einer bis zwei Minuten für den VNet-zu-VNet-Datenverkehr über denselben Hub und fünf bis sieben Minuten für alle anderen Datenverkehrsflüsse über den Hub erwartet. Planen Sie ein Wartungsfenster von mindestens 30 Minuten ein, da im schlimmsten Fall Downtime von bis zu 30 Minuten auftreten kann. Innerhalb einer einzelnen Virtual WAN-Ressource müssen Hubs nacheinander aktualisiert werden, anstatt mehrere gleichzeitig zu aktualisieren. Wenn die Routerversion als „aktuell“ angegeben ist, ist die Aktualisierung des Hubs abgeschlossen. Nach diesem Update treten keine Änderungen im Routingverhalten auf.
Beim Upgrade des virtuellen Hubrouters sind mehrere Punkte zu beachten:
Wenn Sie bereits das BGP-Peering zwischen Ihrem Virtual WAN-Hub und einem NVA in einem Spoke-VNet konfiguriert haben, müssen Sie den BGP-Peer löschen und dann neu erstellen. Da sich die IP-Adressen des virtuellen Hubrouters nach dem Upgrade ändern, müssen Sie auch Ihre NVA neu konfigurieren, um Peering mit den neuen IP-Adressen des virtuellen Hubrouters zu erreichen. Diese IP-Adressen werden als das Feld „virtualRouterIps“ im JSON-Ressourcencode des virtuellen Hubs dargestellt.
Wenn Sie über ein virtuelles Netzwerkgerät (Virtual Network Appliance, NVA) im virtuellen Hub verfügen, wenden Sie sich an Ihren NVA-Partner, um Anweisungen zum Upgrade Ihres Virtual WAN-Hubs zu erhalten.
Wenn Ihr virtueller Hub mit mehr als 15 Routinginfrastruktureinheiten konfiguriert ist, skalieren Sie bitte in Ihrem virtuellen Hub auf 2 Routinginfrastruktureinheiten, bevor Sie versuchen, ein Upgrade durchzuführen. Sie können Ihren Hub nach dem Upgrade des Hubs auf mehr als 15 Routinginfrastruktureinheiten skalieren.
Wenn das Update aus irgendeinem Grund fehlschlägt, wird auf Ihrem Hub automatisch die alte Version wiederhergestellt, um sicherzustellen, dass noch eine funktionierende Konfiguration vorhanden ist.
Weitere wichtige Hinweise:
Der Benutzer muss über die Rolle Besitzer oder Mitwirkender verfügen, um einen genauen Status der Hubrouterversion anzuzeigen. Wenn einem Benutzer die Rolle Leser für die Virtual WAN-Ressource und das Abonnement zugewiesen wird, wird dem Benutzer im Azure-Portal angezeigt, dass der Hubrouter auf die neueste Version aktualisiert werden muss, auch wenn der Hub bereits der neuesten Version entspricht.
Wenn Sie den Status des Abonnements für das Spoke-VNet von „deaktiviert“ in „aktiviert“ ändern und dann den virtuellen Hub aktualisieren, müssen Sie die virtuelle Netzwerkverbindung nach der Aktualisierung des virtuellen Hubs aktualisieren. (Sie können die virtuelle Netzwerkverbindung beispielsweise so konfigurieren, dass sie an eine Dummy-Bezeichnung weitergegeben wird.)
Wenn Ihr Hub mit einer großen Anzahl von virtuellen Spoke-Netzwerken (60 oder mehr) verbunden ist, werden Sie möglicherweise feststellen, dass ein oder mehrere Spoke-VNet-Peerings nach dem Upgrade in einen Fehlerzustand versetzt werden. Um den erfolgreichen Zustand dieser VNet-Peerings nach dem Upgrade wiederherzustellen, können Sie die virtuellen Netzwerkverbindungen so konfigurieren, dass sie auf eine Dummy-Bezeichnung übertragen werden, oder Sie können die entsprechenden VNet-Verbindungen löschen und neu erstellen.
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 worden ist, synchronisiert sich das VNet-Peering automatisch mit dem VNet des virtuellen Hubs.
- 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 hier.
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 mit einem einzelnen Virtual WAN-Hub direkt verbunden sind, beträgt 400. 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.
Dieser Grenzwert ist anpassbar. Weitere Informationen zum Grenzwert, zum Verfahren zum Anfordern einer Begrenzungserhöhung und Beispielskripts zum Bestimmen der Anzahl der Adressräume in virtuellen Netzwerken, die mit einem virtuellen WAN-Hub verbunden sind, finden Sie unter Routingabsicht – Grenzwerte für den Adressraum des virtuellen Netzwerks.
Kundenseitig gesteuerte Wartung von Virtual WAN-Gateways
Welche Dienste sind im Bereich der Wartungskonfiguration von Netzwerkgateways enthalten?
Sie können für Virtual WAN Wartungsfenster für Site-to-Site-VPN-Gateways und ExpressRoute-Gateways konfigurieren.
Welche Wartung wird von der kundenseitig gesteuerten Wartung unterstützt?
Azure-Dienste durchlaufen regelmäßige Wartungsupdates, um Funktionen, die Zuverlässigkeit, Leistung und Sicherheit zu verbessern. Nachdem Sie ein Wartungsfenster für Ihre Ressourcen konfiguriert haben, werden die Gastbetriebssystem- und 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. Dies kommt äußerst selten und nur in extremen Fällen vor.
Kann ich eine frühzeitige Benachrichtigung über die Wartung erhalten?
Zurzeit kann die frühzeitige Benachrichtigung 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 müssen Sie ein tägliches Wartungsfenster konfigurieren.
Müssen sich Ressourcen für die Wartungskonfiguration in derselben Region befinden wie die Gatewayressource?
Ja.
Muss ich eine Mindestskalierungseinheit für ein Gateway bereitstellen, um die kundenseitig gesteuerte Wartung nutzen zu können?
Nein.
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 ein VPN und ExpressRoute verwende?
Wenn Sie ein VPN und ExpressRoute nebeneinander verwenden oder Sie Ressourcen haben, 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 angehalten?
Nein. Wartungsaktivitäten werden im Zeitraum vor dem geplanten Wartungsfenster nicht für Ihre Ressource angehalten. 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.
Nächste Schritte
Weitere Informationen zu Virtual WAN finden Sie unter Informationen zu Virtual WAN.