Häufig gestellte Fragen zum VPN-Gateway

  • Artikel

In diesem Artikel werden häufig gestellte Fragen zu standortübergreifenden Azure VPN Gateway-Verbindungen, Hybridkonfigurationsverbindungen und virtuellen Netzwerkgateways beantwortet. Er enthält umfassende Informationen zu den Konfigurationseinstellungen für Point-to-Site (P2S), Site-to-Site (S2S) und VNet-to-VNet, einschließlich der Protokolle Internet Protocol Security (IPsec) und Internet Key Exchange (IKE).

Herstellen einer Verbindung mit virtuellen Netzwerken

Kann ich Verbindungen zwischen virtuellen Netzwerken in verschiedenen Azure-Regionen herstellen?

Ja. Es gibt keine Regionsbeschränkungen. Verbindungen können sowohl zwischen virtuellen Netzwerken in der gleichen Region als auch zwischen virtuellen Netzwerken in unterschiedlichen Azure-Regionen hergestellt werden.

Kann ich Verbindungen zwischen virtuellen Netzwerken in unterschiedlichen Abonnements herstellen?

Ja.

Kann ich beim Konfigurieren eines VPN-Gateways private DNS-Server in meinem VNET angeben?

Wenn Sie einen DNS-Server (Domain Name System) angeben, wenn Sie Ihr virtuelles Netzwerk erstellen, verwendet das VPN Gateway (Virtual Private Network) diese DNS-Server. Stellen Sie sicher, dass die angegebenen DNS-Servers die für Azure erforderlichen Domänennamen auflösen können.

Kann ich eine Verbindung mit mehreren Standorten eines einzelnen virtuellen Netzwerks herstellen?

Verbindungen mit mehreren Standorten können mit Windows PowerShell und den REST-APIs von Azure hergestellt werden. Weitere Informationen finden Sie im FAQ-Abschnitt Mehrere Standorte und VNet-to-VNet-Verbindungen.

Gibt es eine zusätzliche Gebühr für das Einrichten eines VPN-Gateways als aktiv/aktiv?

Nein Kosten für zusätzliche öffentliche IP-Adressen werden jedoch entsprechend in Rechnung gestellt. Weitere Informationen finden Sie unter Preise für IP-Adressen.

Welche Optionen stehen mir bei standortübergreifenden Verbindungen zur Verfügung?

Das Azure VPN Gateway unterstützt die folgenden lokalen Gateway-Verbindungen:

Weitere Informationen zu VPN Gateway-Verbindungen finden Sie unter Was ist das Azure VPN Gateway.

Was ist der Unterschied zwischen Site-to-Site- und Point-to-Site-Verbindungen?

  • Site-to-Site-Konfigurationen (IPsec/IKE-VPN-Tunnel) betreffen Verbindungen zwischen Ihrem lokalen Standort und Azure. Sie können von jedem Ihrer Computer in Ihren Räumlichkeiten eine Verbindung zu jeder VM oder Rolleninstanz innerhalb Ihres virtuellen Netzwerks herstellen, je nachdem, wie Sie das Routing und die Berechtigungen konfigurieren. Diese Option eignet sich hervorragend für eine ständig verfügbare, standortübergreifende Verbindung sowie für Hybridkonfigurationen.

    Dieser Verbindungstyp basiert auf einer (hardware- oder softwarebasierten) IPsec-VPN-Appliance. Die Appliance muss am Rand Ihres Netzwerks bereitgestellt werden. Zum Erstellen dieser Art von Verbindung müssen Sie über eine externe IPv4-Adresse verfügen.

  • Mithilfe von Point-to-Site-Konfigurationen (VPN über SSTP) können Sie ortsunabhängig eine Verbindung zwischen einem einzelnen Computer und einer beliebigen Ressource in Ihrem virtuellen Netzwerk herstellen. Hierbei kommt der in Windows enthaltene VPN-Client zum Einsatz.

    Als Teil der Point-to-Site-Konfiguration installieren Sie ein Zertifikat und ein VPN-Clientkonfigurationspaket. Das Paket enthält die Einstellungen, die es Ihrem Computer ermöglichen, eine Verbindung zu jeder VM oder Rolleninstanz innerhalb des virtuellen Netzwerks herzustellen.

    Diese Konfiguration eignet sich hervorragend, wenn Sie eine Verbindung mit einem virtuellen Netzwerk herstellen möchten, sich aber nicht vor Ort befinden. Er ist auch eine gute Wahl, wenn Ihnen keine VPN-Hardware oder keine extern ausgerichtete IPv4-Adresse zur Verfügung steht (beides Voraussetzungen für eine Standort-zu-Standort-Verbindung).

Sie können Ihr virtuelles Netzwerk für die parallele Verwendung von Site-to-Site- und Point-to-Site-Verbindungen konfigurieren. Hierzu müssen Sie Ihre Site-to-Site-Verbindung mit einem routenbasierten VPN-Typ für Ihr Gateway erstellen. Routenbasierte VPN-Typen werden im klassischen Bereitstellungsmodell als dynamische Gateways bezeichnet.

Stört eine Fehlkonfiguration von benutzerdefiniertem DNS den normalen Betrieb eines VPN Gateways?

Für normales Funktionieren muss das VPN Gateway eine sichere Verbindung mit der Azure-Kontrollebene herstellen, die über öffentliche IP-Adressen ermöglicht wird. Diese Verbindung basiert auf der Auflösung von Kommunikationsendpunkten über öffentliche URLs. Standardmäßig verwenden Azure VNets den integrierten Azure DNS-Dienst (168.63.129.16), um diese öffentlichen URLs aufzulösen. Dieses Standardverhalten sorgt für eine nahtlose Kommunikation zwischen dem VPN Gateway und der Azure-Kontrollebene.

Wenn Sie ein benutzerdefiniertes DNS in einem VNet implementieren, ist es wichtig, einen DNS-Forwarder zu konfigurieren, der auf Azure DNS (168.63.129.16) verweist. Diese Konfiguration sorgt für eine unterbrechungsfreie Kommunikation zwischen dem VPN Gateway und der Steuerungsebene. Fehler beim Einrichten einer DNS-Weiterleitung an das Azure DNS kann verhindern, dass Microsoft Vorgänge und Wartungen auf dem VPN Gateway durchführt, was ein Sicherheitsrisiko darstellt.

Um die ordnungsgemäße Funktionalität und den einwandfreien Zustand Ihres VPN Gateways zu gewährleisten, sollten Sie eine der folgenden DNS-Konfigurationen im VNet in Betracht ziehen:

  • Stellen Sie den standardmäßigen Azure-DNS wieder her, indem Sie das benutzerdefinierte DNS in den VNet-Einstellungen entfernen (empfohlene Konfiguration).
  • Fügen Sie ihrer benutzerdefinierten DNS-Konfiguration eine DNS-Weiterleitung hinzu, die auf das Azure DNS verweist (168.63.129.16). Je nach den spezifischen Regeln und der Art Ihres benutzerdefinierten DNS kann dieses Setup das Problem möglicherweise nicht wie erwartet lösen.

Können zwei VPN-Clients, die in Point-to-Site-Modus mit demselben VPN Gateway verbunden sind, miteinander kommunizieren?

Nein Zwei VPN-Clients, die in Point-to-Site-Modus mit demselben VPN Gateway verbunden sind, können nicht miteinander kommunizieren.

Wenn zwei VPN-Clients mit demselben VPN Gateway für Point-to-Site verbunden sind, kann das VPN Gateway den Datenverkehr zwischen ihnen automatisch routen, indem sie die IP-Adresse bestimmt, die dem jeweiligen Client aus dem Adresspool zugewiesen wird. Sind die VPN-Clients jedoch mit verschiedenen VPN Gateways verbunden, ist ein Routing zwischen den VPN-Clients nicht möglich, da das jeweilige VPN Gateway nicht weiß, welche IP-Adresse dem Client vom anderen Gateway zugewiesen wurde.

Könnten Point-to-Site-VPN-Verbindungen von einer potenziellen Sicherheitslücke betroffen sein, die als „Tunnelblick“ bekannt ist?

Microsoft hat Kenntnis von Berichten über eine Netzwerktechnik, die die VPN-Kapselung umgeht. Dies ist ein branchenweites Problem. Es betrifft alle Betriebssysteme, die einen Dynamic Host Configuration-Protokoll (DHCP)-Client gemäß der RFC-Spezifikation implementieren und die DHCP-Option 121-Routen unterstützen, einschließlich Windows.

Wie in der Studie erwähnt, kann eine Abhilfe im Betrieb des VPN innerhalb einer VM bestehen, die eine Lease von einem virtualisierten DHCP-Server bezieht; so lässt sich verhindern, dass der DHCP-Server für die lokalen Netzwerke überhaupt Routen installiert. Weitere Informationen zu diesem Sicherheitsrisiko finden Sie in der NIST National Vulnerability Database.

Datenschutz

Werden vom VPN-Dienst Kundendaten gespeichert oder verarbeitet?

Nein.

Gateways des virtuellen Netzwerks

Ist ein VPN-Gateway ein virtuelles Netzwerkgateway?

Ein VPN-Gateway ist eine Art virtuelles Netzwerkgateway. Es sendet verschlüsselten Datenverkehr zwischen Ihrem virtuellen Netzwerk und Ihrem lokalen Standort über eine öffentliche Verbindung. Über ein VPN Gateway können Sie auch Datenverkehr zwischen virtuellen Netzwerken senden. Bei der Erstellung eines VPN Gateways verwenden Sie für -GatewayType den Wert Vpn. Weitere Informationen finden Sie unter Informationen zu VPN Gateway-Einstellungen.

Warum kann ich keine richtlinienbasierten und routenbasierten VPN-Typen angeben?

Ab dem 1. Oktober 2023 können Sie kein richtlinienbasiertes VPN Gateway über das Azure-Portal erstellen. Alle neuen VPN Gateways werden automatisch als routenbasierte VPN Gateways erstellt. Wenn Sie bereits über ein richtlinienbasiertes Gateway verfügen, müssen Sie für dieses kein Upgrade auf ein routenbasiertes Gateway durchführen. Sie können Azure PowerShell oder die Azure CLI verwenden, um die richtlinienbasierten Gateways zu erstellen.

Zuvor hatten die älteren Gateway-Produktstufen (SKUs) IKEv1 für routenbasierte Gateways nicht unterstützt. Derzeit werden IKEv1 und IKEv2 von den meisten aktuellen Gateway-SKUs unterstützt.

Gateway-VPN-Typ Gateway-SKU Unterstützte IKE-Versionen
Richtlinienbasiertes Gateway Standard IKEv1
Routenbasiertes Gateway Standard IKEv2
Routenbasiertes Gateway VpnGw1, VpnGw2, VpnGw3, VpnGw4, VpnGw5 IKEv1 und IKEv2
Routenbasiertes Gateway VpnGw1AZ, VpnGw2AZ, VpnGw3AZ, VpnGw4AZ, VpnGw5AZ IKEv1 und IKEv2

Kann ich mein richtlinienbasiertes VPN-Gateway zu einem routenbasierten aktualisieren?

Nein. Ein Gatewaytyp kann nicht von „richtlinienbasiert“ in „routenbasiert“ oder umgekehrt geändert werden. Zum Ändern eines Gatewaytyps müssen Sie das Gateway löschen und erneut erstellen, indem Sie die folgenden Schritte ausführen. Dieser Vorgang dauert etwa 60 Minuten. Wenn Sie ein neues Gateway erstellen, können Sie die IP-Adresse des ursprünglichen Gateways nicht beibehalten.

  1. Löschen Sie alle Verbindungen, die dem Gateway zugeordnet sind.

  2. Befolgen Sie zum Löschen des Gateways die Anleitung in einem der folgenden Artikel:

  3. Erstellen Sie ein neues Gateway mit dem gewünschten Gatewaytyp, und schließen Sie das VPN-Setup ab. Eine Anleitung hierzu finden Sie im Site-to-Site-Tutorial.

Kann ich meine eigenen richtlinienbasierten Datenverkehrsselektoren angeben?

Ja, Sie können Datenverkehrsselektoren mithilfe des PowerShell-Befehls New-AzIpsecTrafficSelectorPolicy über das Attribut trafficSelectorPolicies für eine Verbindung definieren. Damit der angegebene Datenverkehrsselektor wirksam wird, müssen Sie die richtlinienbasierten Datenverkehrsselektoren aktivieren.

Die benutzerdefinierten konfigurierten Datenverkehrsselektoren werden nur vorgeschlagen, wenn ein VPN Gateway die Verbindung initiiert. Ein VPN-Gateway akzeptiert alle Datenverkehrsselektoren, die von einem Remotegateway (lokales VPN-Gerät) vorgeschlagen werden. Dieses Verhalten ist zwischen allen Verbindungsmodi konsistent (Default, InitiatorOnlyund ResponderOnly).

Benötige ich ein Gateway-Subnetz?

Ja. Das Gatewaysubnetz enthält die IP-Adressen, die von den Diensten des virtuellen Netzwerkgateways verwendet werden. Sie müssen ein Gatewaysubnetz für Ihr virtuelles Netzwerk erstellen, um ein virtuelles Netzwerkgateway konfigurieren zu können.

Alle Gateway-Subnetze müssen den Namen GatewaySubnet haben, damit sie einwandfrei funktionieren. Verwenden Sie für Ihr Gatewaysubnetz keinen anderen Namen. Zudem dürfen keine VMs oder anderen Komponenten im Gatewaysubnetz bereitgestellt werden.

Bei der Gatewayerstellung geben Sie die Anzahl der im Subnetz enthaltenen IP-Adressen an. Die IP-Adressen im Gatewaysubnetz werden dem Gatewaydienst zugeordnet.

Die Anzahl von IP-Adressen, die den Gatewaydiensten zugeordnet werden müssen, ist abhängig von der jeweiligen Konfiguration. Stellen Sie sicher, dass Ihr Gateway-Subnetz über genügend IP-Adressen verfügt, und berücksichtigen Sie dabei auch zukünftiges Wachstum sowie mögliche neue Verbindungskonfigurationen.

Sie können zwar ein Gateway-Subnetz mit einer Größe von nur /29 erstellen, aber es empfiehlt sich, ein Gateway-Subnetz mit einer Größe von mindestens /27 (/27, /26, /25 usw.) zu erstellen. Stellen Sie sicher, dass Ihr vorhandenes Gateway-Subnetz die Anforderungen für die Konfiguration erfüllt, die Sie erstellen möchten.

Kann ich VMs oder Rolleninstanzen in meinem Gateway-Subnetz bereitstellen?

Nein.

Kann ich die IP-Adresse meines VPN-Gateways vor dessen Erstellung erhalten?

Ressourcen mit öffentlichen IP-Adressen und Azure-Standard-SKU müssen eine statische Zuordnungsmethode verwenden. Sie erhalten die öffentliche IP-Adresse für Ihr VPN Gateway, sobald Sie die Ressource mit öffentlicher IP-Adresse und Standard-SKU erstellen, die Sie für die Ressource verwenden möchten.

Kann ich eine statische öffentliche IP-Adresse für mein VPN-Gateway anfordern?

Ressourcen mit öffentlichen IP-Adressen und Standard-SKU verwenden eine statische Zuordnungsmethode. Künftig müssen Sie eine öffentliche Standard-SKU-IP-Adresse verwenden, wenn Sie ein neues VPN-Gateway erstellen. Diese Anforderung gilt für alle Gateway-SKUs mit Ausnahme der Standard-SKU. Die Basic-SKU unterstützt derzeit nur öffentliche Basic-SKU-IP-Adressen. Wir arbeiten daran, die Unterstützung von öffentlichen Basic-SKU-IP-Adressen für die Basic SKUs hinzufügen.

Bei nicht zonenredundanten und nicht zonalen Gateways, die zuvor erstellt wurden (Gateway-SKUs, in deren Name AZ nicht vorkommt), wird die dynamische IP-Adresszuweisung unterstützt, aber schrittweise eingestellt. Wenn Sie eine dynamische IP-Adresse verwenden, ändert sich die IP-Adresse nicht, nachdem sie Ihrem VPN Gateway zugewiesen wurde. Die IP-Adresse des VPN Gateways ändert sich nur, wenn das Gateway gelöscht und dann neu erstellt wird. Die öffentliche IP-Adresse ändert sich nicht bei Größenänderungen, beim Zurücksetzen oder bei anderen internen Wartungs- und Upgradeprozessen Ihres VPN Gateways.

Wie wirkt sich die Einstellung der öffentlichen IP-Adressen der Basic-SKU auf meine VPN-Gateways aus?

Wir ergreifen Maßnahmen, um bis zur Einstellung von Basic-IP-Adressen im Seltember 2025 den weiteren Betrieb von bereitgestellten VPN Gateways zu gewährleisten, die öffentliche IP-Adressen der Basic-SKU verwenden. Vor dieser Einstellung bieten wir der Kundschaft einen Migrationspfad von Basic- zu Standard-IP-Adressen.

Öffentliche SKU-Standard-IP-Adressen werden auslaufen. In Zukunft müssen Sie beim Erstellen eines neuen VPN Gateways die öffentliche IP-Adresse der Standard-SKU verwenden. Details zur Deaktivierung öffentlicher Basic SKU IP-Adressen finden Sie in der Azure Updates-Ankündigung.

Wie wird mein VPN-Tunnel authentifiziert?

Azure VPN Gateway verwendet eine PSK-Authentifizierung (Preshared Key). Ein PSK wird bei der Erstellung des VPN-Tunnels generiert. Sie können den automatisch generierten PSK in Ihren eigenen ändern, indem Sie die „Set Pre-Shared Key“ REST-API oder das entsprechende PowerShell Cmdlet verwenden.

Kann ich die „Set Pre-Shared Key“ REST-API verwenden, um mein richtlinienbasiertes (statisches Routing) Gateway-VPN zu konfigurieren?

Ja. Sie können die „Set Pre-Shared Key“ REST-API und das PowerShell-Cmdlet verwenden, um sowohl richtlinienbasierte (statische) Azure-VPNs als auch routenbasierte (dynamische) VPNs zu konfigurieren.

Kann ich andere Authentifizierungsoptionen verwenden?

Für die Authentifizierung können Sie nur vorinstallierte Schlüssel verwenden.

Wie kann ich angeben, welcher Datenverkehr über das VPN-Gateway abgewickelt werden soll?

Für das Azure Resource Manager-Bereitstellungsmodell:

  • Azure PowerShell: Verwenden Sie AddressPrefix, um Datenverkehr für das lokale Netzwerkgateway anzugeben.
  • Azure-Portal: Wechseln Sie zu Lokales Netzwerkgateway>Configuration>Adressraum.

Für das klassische Bereitstellungsmodell:

  • Azure-Portal: Wechseln Sie zum klassischen virtuellen Netzwerk und dann zu VPN-Verbindungen>Site-to-Site-VPN-Verbindungen>Name des lokalen Standorts>Lokaler Standort>Adressraum des Client.

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

Ja, Netzwerkadressenübersetzung-Traversal (NAT-T) wird unterstützt. Azure VPN Gateway setzt keine NAT-ähnliche Funktionalität für die inneren Pakete ein, die bei den IPSec-Tunneln ein-/ausgehen. Stellen Sie in dieser Konfiguration sicher, dass das lokale Gerät den IPSec-Tunnel initiiert.

Kann ich in Azure einen eigenen VPN-Server einrichten und damit eine Verbindung mit meinem lokalen Netzwerk herstellen?

Ja. Sie können in Azure eigene VPN Gateways oder -Server bereitstellen (über Azure Marketplace oder durch Erstellung eines eigenen VPN-Routers). Sie müssen benutzerdefinierte Routen in Ihrem virtuellen Netzwerk konfigurieren, um sicherzustellen, dass der Datenverkehr ordnungsgemäß zwischen Ihren lokalen Netzwerken und den Subnetzen Ihres virtuellen Netzwerks weitergeleitet wird.

Warum sind auf meinem Gateway für virtuelle Netzwerke bestimmte Ports geöffnet?

Sie sind für die Kommunikation mit der Azure-Infrastruktur erforderlich. Azure-Zertifikate tragen zum Schutz bei, indem sie sie sperren. Ohne die richtigen Zertifikate können externe Entitäten, einschließlich der Kunden dieser Gateways, diese Endpunkte nicht ändern.

Ein virtuelles Netzwerk-Gateway ist im Grunde ein Multihomed-Gerät. Ein Netzwerkadapter zapft das private Kundennetzwerk an und ein Netzwerkadapter ist mit dem öffentlichen Netzwerk verbunden. Azure-Infrastrukturentitäten können aus Compliance-Gründen keine privaten Kundennetzwerke nutzen, sodass sie öffentliche Endpunkte für die Kommunikation der Infrastruktur nutzen müssen. Die öffentlichen Endpunkte werden in regelmäßigen Abständen mit der Azure-Sicherheitsüberwachung überprüft.

Kann ich ein VPN Gateway mit der Basic SKU im Portal erstellen?

Nein Die Basic-SKU ist im Portal nicht verfügbar. Sie können ein Basic-SKU VPN Gateway mithilfe den Schritten für Azure CLI oder Azure PowerShell erstellen.

Wo finde ich weitere Informationen zu Gatewaytypen, Anforderungen und Durchsatz?

Weitere Informationen finden Sie in folgenden Artikeln:

Einstellung des Supports für ältere SKUs

Die Standard- und High Performance-SKUs werden am 30. September 2025 eingestellt. Sie können sich die Ankündigung auf der Azure Updates-Website ansehen. Das Produktteam wird bis zum 30. November 2024 einen Migrationspfad für diese SKUs zur Verfügung stellen. Weitere Informationen finden Sie im Artikel zu Legacy-SKUs für VPN-Gateway.

Zu diesem Zeitpunkt gibt es keine Aktion, die Sie ausführen müssen.

Kann ich nach der Ankündigung der Einstellung am 30. November 2023 ein neues Gateway erstellen, das eine Standard-/Hochleistungs-SKU verwendet?

Nein Seit dem 1. Dezember 2023 können Sie keine Gateways erstellen, die Standard- oder Hochleistungs-SKUs verwenden. Sie können neue Gateways mit VpnGw1 und VpnGw2 für den gleichen Preis wie die Standard- bzw. Hochleistungs-SKUs erstellen, die jeweils auf der Preisseite aufgeführt sind.

Wie lange werden meine vorhandenen Gateways mit den Standard-/Hochleistungs-SKUs unterstützt?

Alle vorhandenen Gateways mit der Standard- oder Hochleistungs-SKU werden bis zum 30. September 2025 unterstützt.

Muss ich meine Gateways jetzt aus der Standard- oder Hochleistungs-SKU migrieren?

Nein, im Moment ist keine Aktion erforderlich. Sie können Ihre Gateways ab Dezember 2024 migrieren. Sie erhalten noch eine detaillierte Dokumentation zu den Migrationsschritten.

Zu welcher SKU kann ich meine Gateways migrieren?

Wenn die Migration der Gateway-SKUs verfügbar gemacht wird, können SKUs wie folgt migriert werden:

  • Standard-SKU zu VpnGw1
  • Hochleistungs-SKU zu VpnGw2

Was geschieht, wenn ich zu einer AZ-SKU migrieren möchte?

Sie können Ihre veraltete SKU nicht zu einer AZ-SKU migrieren. Alle Gateways, die nach dem 30. September 2025 noch die Standard- oder Hochleistungs-SKU verwenden, werden jedoch migriert und automatisch auf die folgenden SKUs aktualisiert:

  • Standard-SKU zu VpnGw1AZ
  • Hochleistungs-SKU zu VpnGw2AZ

Sie können diese Strategie anwenden, damit Ihre SKUs automatisch migriert und auf eine AZ-SKU aktualisiert werden. Sie können dann bei Bedarf die Größe Ihrer SKU innerhalb dieser SKU-Familie anpassen. Informationen zu AZ-SKU-Preisen finden Sie auf der Preisseite. Informationen zum Durchsatz nach SKU finden Sie unter Informationen zu Gateway-SKUs.

Gibt es nach der Migration Preisunterschiede für meine Gateways?

Wenn Sie Ihre SKUs bis zum 30. September 2025 migrieren, gibt es keine Preisunterschiede. Die SKUs VpnGw1 und VpnGw2 werden zum gleichen Preis wie die Standard- bzw. Hochleistungs-SKUs angeboten.

Wenn Sie nicht bis zu diesem Datum migrieren, werden Ihre SKUs automatisch migriert und auf AZ-SKUs aktualisiert. In diesem Fall gibt es einen Preisunterschied.

Hat diese Migration Auswirkungen auf die Leistung meiner Gateways?

Ja. Sie erhalten mit VpnGw1 und VpnGw2 eine höhere Leistung. Derzeit bietet VpnGw1 bei 650 MBit/s eine 6,5-fache Leistungsverbesserung zum gleichen Preis wie die Standard-SKU. VpnGw2 bei 1 GBit/s bietet eine 5-fache Leistungsverbesserung zum gleichen Preis wie die Hochleistungs-SKU. Weitere Informationen zum SKU-Durchsatz finden Sie unter Informationen zu Gateway-SKUs.

Was geschieht, wenn ich die Gateways nicht bis zum 30. September 2025 migriere?

Alle Gateways, die weiterhin die Standard- oder Hochleistungs-SKU verwenden, werden automatisch migriert und auf die folgenden AZ-SKUs aktualisiert:

  • Standard-SKU zu VpnGw1AZ
  • Hochleistungs-SKU zu VpnGw2AZ

Wir senden eine Mitteilung, bevor wir die Migration auf den Gateways einleiten.

Wird die VPN Gateway-Basic-SKU ebenfalls eingestellt?

Nein, die VPN Gateway-Basic-SKU wird nicht eingestellt. Sie können mithilfe der Basic-SKU über Azure PowerShell oder die Azure CLI ein VPN Gateway erstellen.

Derzeit unterstützt die VPN Gateway Basic-Gateway-SKU nur die öffentliche IP-Adressressource „Basic SKU“ (die sich auf dem Weg zur Ausmusterung befindet). Wir arbeiten daran, die VPN Gateway-Basic-SKU um die Unterstützung für die öffentliche IP-Adressressource der Standard-SKU zu erweitern.

Site-to-Site-Verbindungen und VPN-Geräte

Was muss ich bei der Wahl eines VPN-Geräts berücksichtigen?

Wir haben in Zusammenarbeit mit Geräteherstellern eine Reihe von VPN-Geräten für standardmäßige Standort-zu-Standort-Verbindungen getestet. Sie finden eine Liste mit kompatiblen VPN-Geräten, entsprechenden Konfigurationsanweisungen oder -beispielen und Gerätespezifikationen im Artikel Informationen zu VPN-Geräten.

Alle Geräte der als kompatibel angegebenen Gerätefamilien sollten mit Virtual Network verwendet werden können. Hilfreiche Informationen zur Konfiguration des VPN-Gerätes finden Sie im entsprechenden Konfigurationsbeispiel oder unter dem Link für die entsprechende Gerätefamilie.

Wo finde ich die Konfigurationseinstellungen für VPN-Geräte?

Abhängig von Ihrem VPN-Gerät können Sie möglicherweise ein Skript zur Konfiguration des VPN-Geräts herunterladen. Weitere Informationen finden Sie unter Herunterladen von VPN-Gerätekonfigurationsskripts für S2S-VPN-Verbindungen.

Weitere Konfigurationsinformationen finden Sie unter den folgenden Links:

Wie kann ich Beispiele für die Konfiguration von VPN-Geräten bearbeiten?

Weitere Informationen finden Sie unter Bearbeiten von Gerätekonfigurationsbeispielen.

Wo finde ich IPsec- und IKE-Parameter?

Siehe IPsec-/IKE-Standardparameter.

Warum fällt mein richtlinienbasierter VPN-Tunnel aus, wenn kein Datenverkehr stattfindet?

Dieses Verhalten wird für richtlinienbasierte VPN Gateways (auch als VPNs mit statischem Routing bezeichnete) erwartet. Wenn im Tunnel länger als fünf Minuten kein Datenverkehr stattfindet, wird der Tunnel geschlossen. Bei erneut einsetzendem Datenverkehr wird der Tunnel umgehend wiederhergestellt. Die Richtung des Datenverkehrs ist dabei unerheblich.

Kann ich VPN-Softwarelösungen verwenden, um eine Verbindung mit Azure herzustellen?

Wir unterstützen Windows Server 2012 Routing- und Remote Access-Server für die standortübergreifende Konfiguration.

Auch andere VPN-Softwarelösungen können mit dem Gateway verwendet werden, sofern sie über branchenübliche IPsec-Implementierungen verfügen. Konfigurations- und Supportinformationen erhalten Sie vom Anbieter der Software.

Kann ich mich über Point-to-Site mit einem VPN-Gateway verbinden, wenn ich mich an einem Standort befinde, der über eine aktive Site-to-Site-Verbindung verfügt?

Ja, aber die öffentlichen IP-Adressen des Point-to-Site-Clients müssen sich von den öffentlichen IP-Adressen unterscheiden, die vom Site-to-Site-VPN-Gerät verwendet werden, sonst funktioniert die Point-to-Site-Verbindung nicht. Point-to-Site-Verbindungen mit IKEv2 können nicht von der- oder denselben öffentlichen IP-Adressen initiiert werden, für die eine Site-to-Site-VPN-Verbindung auf demselben VPN Gateway konfiguriert ist.

Point-to-Site-Verbindungen

Wie viele VPN-Clientendpunkte darf eine Punkt-zu-Standort-Konfiguration enthalten?

Das hängt von der Gateway-SKU ab. Weitere Informationen zur Anzahl von unterstützten Verbindungen finden Sie unter Gateway-SKUs.

Welche Clientbetriebssysteme kann ich für Point-to-Site verwenden?

Folgende Clientbetriebssysteme werden unterstützt:

  • Windows Server 2008 R2 (nur 64 Bit)
  • Windows 8.1 (32 Bit und 64 Bit)
  • Windows Server 2012 (nur 64 Bit)
  • Windows Server 2012 R2 (nur 64 Bit)
  • Windows Server 2016 (nur 64 Bit)
  • Windows Server 2019 (nur 64 Bit)
  • Windows Server 2022 (nur 64 Bit)
  • Windows 10
  • Windows 11
  • macOS Version 10.11 oder höher.
  • Linux (strongSwan)
  • iOS

Können Proxys und Firewalls mit der Point-to-Site-Funktion durchlaufen werden?

Azure unterstützt drei Arten von P2S-VPN-Optionen:

  • Secure Socket Tunneling Protocol (SSTP): Eine Microsoft-eigene SSL-basierte Lösung, die Firewalls durchdringen kann, da die meisten Firewalls den von SSL verwendeten ausgehenden TCP-Port 443 öffnen.

  • OpenVPN: Eine SSL-basierte Lösung, die Firewalls durchdringen kann, weil die meisten Firewalls den von SSL verwendeten ausgehenden TCP-Port 443 öffnen.

  • IKEv2-VPN: Eine standardbasierte IPsec-VPN-Lösung, die die ausgehenden UDP-Ports 500 und 4500 und die IP-Protokollnummer 50 verwendet. Firewalls öffnen diese Ports nicht immer, daher kann ein IKEv2-VPN möglicherweise Proxys und Firewalls nicht durchlaufen.

Wird die VPN-Verbindung eines für Point-to-Site konfigurierten Clientcomputers nach einem Neustart automatisch wiederhergestellt?

Die automatische erneute Verbindung ist eine Funktion des von Ihnen verwendeten Clients. Windows unterstützt die automatische Wiederverbindung durch die Client-Funktion Always On-VPN.

Unterstützt Point-to-Site DDNS auf den VPN-Clients?

Dynamisches DNS (DDNS) wird derzeit in Point-to-Site-VPNs nicht unterstützt.

Können im gleichen virtuellen Netzwerk sowohl Site-to-Site- als auch Point-to-Site-Konfigurationen verwendet werden?

Ja. Beim Resource Manager-Bereitstellungsmodell müssen Sie einen routenbasierten VPN-Typ für Ihr Gateway festlegen. Für das klassische Bereitstellungsmodell benötigen Sie ein dynamisches Gateway. Point-to-Site-Konfigurationen werden für VPN Gateways mit statischem Routing oder für richtlinienbasierte Gateways nicht unterstützt.

Kann ich einen Point-to-Site-Client so konfigurieren, dass er gleichzeitig eine Verbindung mit mehreren Gateways für virtuelle Netzwerke herstellt?

Je nach verwendeter VPN-Clientsoftware können Sie möglicherweise eine Verbindung mit mehreren virtuellen Netzwerkgateways herstellen. Das ist aber nur dann der Fall, wenn die virtuellen Netzwerke, zu denen Sie eine Verbindung herstellen, keine konkurrierenden Adressräume untereinander oder mit dem Netzwerk haben, von dem aus der Client eine Verbindung herstellt. Obwohl der Azure VPN Client viele VPN-Verbindungen unterstützt, können Sie immer nur eine Verbindung auf einmal herstellen.

Kann ein Punkt-zu-Standort-Client so konfiguriert werden, dass er Verbindungen mit mehreren virtuellen Netzwerken gleichzeitig herstellt?

Ja. Point-to-Site Client-Verbindungen zu einem VPN Gateway, das in einem VNet bereitgestellt wird, das mit anderen VNets gepeert ist, können auf die anderen gepeerten VNets zugreifen, sofern sie bestimmte Konfigurationskriterien erfüllen. Damit ein Point-to-Site-Client Zugriff auf ein VNet mit Peer-Rechten hat, muss das VNet mit Peer-Rechten (das VNet ohne Gateway) mit dem Attribut Remote-Gateways verwenden konfiguriert sein. Das VNet mit dem VPN Gateway muss mit Gatewaytransit zulassen konfiguriert werden. Weitere Informationen hierzu finden Sie unter Informationen zu Point-to-Site-VPN-Routing.

Wie viel Durchsatz kann ich bei einer Site-to-Site- oder bei einer Point-to-Site-Verbindung erwarten?

Der genaue Durchsatz der VPN-Tunnel lässt sich nur schwer ermitteln. IPsec und SSTP sind VPN-Protokolle mit hohem Kryptografieaufwand. Der Durchsatz kann auch durch die Latenz und die Bandbreite zwischen Ihrem Standort und dem Internet eingeschränkt werden.

Bei einem VPN Gateway nur mit IKEv2-P2S-VPN-Verbindungen hängt der erwartete Gesamtdurchsatz von der Gateway-SKU ab. Weitere Informationen zum Durchsatz finden Sie unter Gateway-SKUs.

Kann ich für Point-to-Site-Verbindungen einen beliebigen VPN-Softwareclient mit SSTP- oder IKEv2-Unterstützung verwenden?

Nein Sie können nur den nativen VPN-Client unter Windows für SSTP und den nativen VPN-Client unter Mac für IKEv2 verwenden. Allerdings können Sie den OpenVPN-Client auf allen Plattformen verwenden, um über das OpenVPN-Protokoll eine Verbindung herzustellen. Informationen finden Sie in der Liste der unterstützten Clientbetriebssysteme.

Kann ich den Authentifizierungstyp für eine Point-to-Site-Verbindung ändern?

Ja. Wechseln Sie im Portal zu VPN-Gateway>Point-to-Site-Konfiguration. Wählen Sie unter Authentifizierungstyp den Authentifizierungstypen aus, den Sie verwenden möchten.

Aktuelle Clients können nach einer Änderung am Authentifizierungstyp möglicherweise erst dann eine Verbindung herstellen, wenn Sie ein neues VPN-Clientkonfigurationsprofil generiert, heruntergeladen und auf jeden VPN-Client angewendet haben.

Wann muss ich ein neues Konfigurationspaket für das VPN-Clientprofil generieren?

Wenn Sie Änderungen an den Konfigurationseinstellungen für das P2S VPN Gateway vornehmen, z. B. einen Tunneltyp hinzufügen oder einen Authentifizierungstyp ändern, müssen Sie ein neues Konfigurationspaket für das VPN Client-Profil erstellen. Das neue Paket enthält die aktualisierten Einstellungen, die VPN-Clients benötigen, um eine Verbindung mit dem P2S-Gateway herzustellen. Verwenden Sie nach dem Generieren des Pakets die in den Dateien enthaltenen Einstellungen, um die VPN-Clients zu aktualisieren.

Unterstützt Azure IKEv2-VPN unter Windows?

IKEv2 wird unter Windows 10 und Windows Server 2016 unterstützt. Bei bestimmten Betriebssystemversionen müssen Sie für die Verwendung von IKEv2 allerdings Updates installieren und lokal einen Registrierungsschlüsselwert festlegen. Betriebssystemversionen vor Windows 10 werden nicht unterstützt und können nur SSTP oder das OpenVPN-Protokoll verwenden.

Hinweis

Bei Windows-Betriebssystembuilds, die neuer als Version 1709 (Windows 10) bzw. Version 1607 (Windows Server 2016) sind, sind diese Schritte nicht erforderlich.

Vorbereitung von Windows 10 oder Windows Server 2016 für IKEv2:

  1. Installieren Sie das passende Update für Ihre Betriebssystemversion:

    Betriebssystemversion Date Anzahl/Link
    Windows Server 2016
    Windows 10, Version 1607    		 17. Januar 2018 KB4057142
    Windows 10, Version 1703 17. Januar 2018 KB4057144
    Windows 10, Version 1709 22. März 2018 KB4089848

  2. Legen Sie den Registrierungsschlüsselwert fest. Erstellen Sie den HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload REG_DWORD-Schlüssel in der Registrierung, oder legen Sie ihn auf 1 fest.

Wie sieht die IKEv2-Datenverkehrsauswahlgrenze für Point-to-Site-Verbindungen aus?

Windows 10 Version 2004 (veröffentlicht im September 2021) erhöhte die Datenverkehrsauswahlgrenze auf 255. Ältere Windows-Versionen haben eine Datenverkehrsauswahlgrenze von 25.

Die Datenverkehrsauswahlgrenze in Windows bestimmt die maximale Anzahl von Adressräumen in Ihrem virtuellen Netzwerk und die maximale Summe Ihrer lokalen Netzwerke, VNet-to-VNet-Verbindungen und mit dem Gateway verbundenen Peered-VNets. Windows-basierte Point-to-Site-Clients können keine Verbindung über IKEv2 herstellen, wenn sie diese Grenze überschreiten.

Wie sieht die OpenVPN-Datenverkehrsauswahlgrenze für Point-to-Site-Verbindungen aus?

Die Datenverkehrsauswahlgrenze für OpenVPN beträgt 1,000 Routen.

Was geschieht, wenn ich sowohl SSTP als auch IKEv2 für P2S-VPN-Verbindungen konfiguriere?

Wenn Sie sowohl SSTP als auch IKEv2 in einer gemischten Umgebung konfigurieren, die aus Windows- und Mac-Geräten besteht, versucht es der Windows-VPN-Client immer zuerst mit dem IKEv2-Tunnel. Der Client greift auf SSTP zurück, wenn die IKEv2-Verbindung nicht erfolgreich ist. MacOS verbindet sich nur über IKEv2.

Wenn Sie sowohl SSTP als auch IKEv2 auf dem Gateway aktiviert haben, wird der Point-to-Site-Adresspool statisch zwischen beiden Protokollen aufgeteilt, sodass Clients, die unterschiedliche Protokolle verwenden, IP-Adressen aus beiden Unterbereichen zugewiesen werden. Die maximale Anzahl von SSTP-Clients ist immer 128, auch wenn der Adressbereich größer als /24 ist. Das Ergebnis ist eine größere Anzahl von Adressen, die für IKEv2-Clients verfügbar sind. Bei kleineren Bereichen wird der Pool in zwei gleiche Teile geteilt. Datenverkehrsselektoren, die vom Gateway verwendet werden, enthalten möglicherweise nicht den CIDR-Block (Classless Inter-Domain Routing) für den Adressbereich von Point-to-Site, enthalten jedoch den CIDR-Block für die beiden Unterbereiche.

Welche Plattformen unterstützt Azure für P2S VPN?

Azure unterstützt Windows, Mac und Linux für P2S-VPN.

Ich habe bereits ein VPN Gateway bereitgestellt. Kann ich RADIUS oder IKEv2-VPN darauf aktivieren?

Ja. Wenn die verwendete Gateway-SKU RADIUS oder IKEv2 unterstützt, können Sie diese Features auf Gateways, die Sie bereits bereitgestellt haben, mithilfe von Azure PowerShell oder dem Azure-Portal aktivieren. Die Basic-SKU unterstützt weder RADIUS noch IKEv2.

Wie entferne ich die Konfiguration einer P2S-Verbindung?

Sie können eine P2S-Konfiguration mithilfe der folgenden Azure PowerShell- oder Azure CLI-Befehle entfernen:

$gw=Get-AzVirtualNetworkGateway -name <gateway-name>`  
$gw.VPNClientConfiguration = $null`  
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw`

az network vnet-gateway update --name <gateway-name> --resource-group <resource-group name> --remove "vpnClientConfiguration"

Point-to-Site-Verbindungen mit Zertifikatauthentifizierung

Wie muss ich vorgehen, wenn beim Herstellen einer Point-to-Site-Verbindung über die Zertifikatauthentifizierung ein Zertifikatkonflikt gemeldet wird?

Löschen Sie das Kontrollkästchen Identität des Servers mittels Zertifikatprüfung überprüfen. Oder fügen Sie den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Servers zusammen mit dem Zertifikat hinzu, wenn Sie ein Profil manuell erstellen. Sie können dazu rasphone an einer Eingabeaufforderung ausführen und das Profil in der Dropdown-Liste auswählen.

Es wird im Allgemeinen nicht empfohlen, die Validierung der Serveridentität zu umgehen. Bei der Azure-Zertifikatauthentifizierung wird jedoch für die Servervalidierung im VPN-Tunnelingprotokoll (IKEv2/SSTP) als auch im Extensible Authentication Protocol (EAP) das gleiche Zertifikat verwendet. Da das Serverzertifikat und der FQDN bereits vom VPN-Tunnelingprotokoll validiert wurden, ist es redundant, sie in EAP erneut zu validieren.

Screenshot der Eigenschaften für die Point-to-Site-Authentifizierung.

Kann ich meine eigene interne PKI-Stammzertifizierungsstelle verwenden, um Zertifikate für Point-to-Site-Verbindungen zu generieren?

Ja. Bisher konnten Sie nur selbstsignierte Stammzertifikate verwenden. Sie können weiterhin 20 Stammzertifikate hochladen.

Kann ich Zertifikate aus Azure Key Vault verwenden?

Nein.

Mit welchen Tools kann ich Zertifikate erstellen?

Sie können Ihre Unternehmens Public Key (PKI)-Infrastrukturlösung, Azure PowerShell, MakeCert und OpenSSL verwenden.

Gibt es Anleitungen für Zertifikateinstellungen und -parameter?

Informationen zum CER- und PFX-Dateiformat finden Sie unter:

Informationen zum PEM-Dateiformat finden Sie unter:

Point-to-Site-Verbindungen mit RADIUS-Authentifizierung

Wird RADIUS-Authentifizierung von allen Azure-VPN-Gateway-SKUs unterstützt?

RADIUS-Authentifizierung wird mit Ausnahme der Basic-SKU für alle SKUs unterstützt.

Für ältere SKUs wird die RADIUS-Authentifizierung bei Standard- und Hochleistungs-SKUs unterstützt.

Wird die RADIUS-Authentifizierung für das klassische Bereitstellungsmodell unterstützt?

Nein

Welcher Timeoutwert gilt für RADIUS-Anforderungen, die an den RADIUS-Server gesendet werden?

Für RADIUS-Anforderungen ist ein Timeoutwert von 30 Sekunden festgelegt. Benutzerdefinierte Timeoutwerte werden derzeit nicht unterstützt.

Werden RADIUS-Server von Drittanbietern unterstützt?

Ja.

Mit welchen Konnektivitätsanforderungen wird sichergestellt, dass das Azure-Gateway einen lokalen RADIUS-Server erreicht?

Sie benötigen eine Site-to-Site-VPN-Verbindung mit dem Standort vor Ort. (Dabei müssen die korrekten Routen konfiguriert sein.)

Kann Datenverkehr für einen lokalen RADIUS-Server (vom VPN Gateway) über eine ExpressRoute-Verbindung weitergeleitet werden?

Nein Er kann nur über eine S2S-Verbindung weitergeleitet werden.

Hat sich die Anzahl von unterstützten SSTP-Verbindungen mit RADIUS-Authentifizierung geändert? Wie viele SSTP- und IKEv2-Verbindungen werden maximal unterstützt?

Die maximale Anzahl unterstützter SSTP-Verbindungen für ein Gateway mit RADIUS-Authentifizierung hat sich nicht geändert. Es werden nach wie vor maximal 128 SSTP-Verbindungen unterstützt – abhängig von der Gateway-SKU für IKEv2. Weitere Informationen zur Anzahl von unterstützten Verbindungen finden Sie unter Über Gateway-SKUs.

Was ist der Unterschied zwischen der Zertifikatauthentifizierung mithilfe eines RADIUS-Servers und der systemeigenen Azure-Zertifikatauthentifizierung durch Hochladen eines vertrauenswürdigen Zertifikats?

Bei der RADIUS-Zertifikatauthentifizierung wird die Authentifizierungsanforderung an einen RADIUS-Server weitergeleitet, der die Zertifikatüberprüfung durchführt. Diese Option ist nützlich für die Integration in eine bereits vorhandene Zertifikatauthentifizierungsinfrastruktur über RADIUS.

Wenn Sie Azure für die Zertifikatauthentifizierung verwenden, führt das VPN Gateway die Überprüfung des Zertifikats durch. Sie müssen den öffentlichen Schlüssel des Zertifikats in das Gateway hochladen. Sie können auch eine Liste gesperrter Zertifikate angeben, für die die Verbindung nicht zugelassen werden soll.

Unterstützt die RADIUS-Authentifizierung die Netzwerkrichtlinienserver-Integration für die Multi-Faktor-Authentifizierung?

Wenn Ihre Multi-Faktor-Authentifizierung textbasiert ist (z. B. SMS oder ein mobiler App-Verifizierungscode) und die Benutzerin oder der Benutzer einen Code oder Text in die Benutzeroberfläche des VPN-Clients eingeben muss, wird die Authentifizierung nicht erfolgreich sein und ist kein unterstütztes Szenario. Weitere Informationen finden Sie unter Integrieren der RADIUS-Authentifizierung für das Azure-VPN-Gateway in den NPS-Server für Multi-Faktor-Authentifizierung.

Funktioniert die RADIUS-Authentifizierung mit IKEv2 und SSTP VPN?

Ja, die RADIUS-Authentifizierung funktioniert mit IKEv2 und SSTP VPN.

Funktioniert RADIUS-Authentifizierung mit dem OpenVPN-Client?

RADIUS-Authentifizierung wird für das OpenVPN-Protokoll unterstützt.

VNet-zu-VNet- und Multi-Site-Verbindungen

Die VNet-to-VNet-Informationen in diesem Abschnitt gelten für VPN Gateway-Verbindungen. Informationen zum VNET-Peering finden Sie unter Peering virtueller Netzwerke.

Fallen bei Azure Kosten für den Datenverkehr zwischen VNets an?

VNET-zu-VNET-Datenverkehr innerhalb einer Region ist bei Verwendung einer VPN-Gatewayverbindung in beide Richtungen kostenlos. Für regionsübergreifenden VNET-zu-VNET-Datenverkehr in ausgehender Richtung werden Gebühren für ausgehende Datenübertragungen zwischen VNETs basierend auf den Quellregionen berechnet. Weitere Informationen finden Sie unter Azure VPN Gateway: Preise. Wenn Sie eine Verbindung zwischen Ihren VNets mittels VNet-Peering anstelle eines VPN Gateways herstellen, finden Sie weitere Informationen auf der Seite Azure Virtual Network: Preise.

Wird VNET-zu-VNET-Datenverkehr über das Internet übertragen?

Nein. VNET-zu-VNET-Datenverkehr wird über den Microsoft Azure-Backbone übertragen, nicht über das Internet.

Kann ich eine VNet-zu-VNet-Verbindung zwischen Microsoft Entra-Mandanten herstellen?

Ja. VNet-to-VNet-Verbindungen mit VPN Gateways können übergreifend für Microsoft Entra-Mandanten verwendet werden.

Ist VNet-zu-VNet-Datenverkehr sicher?

IPsec- und IKE-Verschlüsselung schützen VNet-to-VNet-Datenverkehr.

Benötige ich ein VPN-Gerät, umVNets miteinander zu verbinden?

Nein Für das Verbinden mehrerer virtueller Azure-Netzwerke sind keine VPN-Geräte erforderlich. Diese werden nur benötigt, wenn Sie standortübergreifende Konnektivität benötigen.

Müssen sich meine VNets in der gleichen Region befinden?

Nein. Die virtuellen Netzwerke können sich in der gleichen Azure-Region oder in verschiedenen Azure-Regionen (Standorte) befinden.

Müssen die Abonnements demselben Microsoft Entra-Mandanten zugeordnet sein, wenn sich VNets nicht im selben Abonnement befinden?

Nein

Kann ich VNet-zu-VNet verwenden, um virtuelle Netzwerke in separaten Azure-Instanzen zu verbinden?

Nein. Für VNet-zu-VNet wird die Verbindungsherstellung von virtuellen Netzwerken in derselben Azure-Instanz unterstützt. Beispielsweise ist es nicht möglich, eine Verbindung zwischen Azure global und den Azure-Instanzen für China, Deutschland oder die US-Regierung herzustellen. Erwägen Sie für diese Szenarien die Verwendung einer Site-to-Site-VPN-Verbindung.

Kann ich VNet-zu-VNet zusammen mit Verbindungen mit mehreren Standorten verwenden?

Ja. Sie können virtuelle Netzwerkverbindungen simultan mit VPNs mit mehreren Standorten verwenden.

Mit wie vielen lokalen Standorten und virtuellen Netzwerken kann ein virtuelles Netzwerk verbunden werden?

Informationen dazu finden Sie in der Tabelle Gatewayanforderungen.

Kann ich VNet-to-VNet für die Verbindung von VMs oder Clouddiensten außerhalb eines VNet verwenden?

Nein VNet-zu-VNet unterstützt das Verbinden virtueller Netzwerke. Nicht unterstützt werden Verbindungen virtueller Computer oder Clouddienste, die sich nicht in einem virtuellen Netzwerk befinden.

Kann sich ein Clouddienst oder ein Lastenausgleichs-Endpunkt über mehrere VNETs erstrecken?

Nein Ein Clouddienst oder Endpunkt mit Lastenausgleich kann nicht mehrere virtuelle Netzwerke umfassen, selbst wenn diese verbunden sind.

Kann ich den richtlinienbasierten VPN-Typ für VNet-to-VNet- oder standortübergreifende Verbindungen verwenden?

Nein VNet-to-VNet- und standortübergreifende Verbindungen erfordern VPN Gateways mit routenbasierten VPN-Typen (zuvor als dynamisches Routing bezeichnet).

Kann ich ein VNet mit einem routenbasierten VPN-Typ mit einem anderen VNet mit einem richtlinienbasierten VPN verbinden?

Nein Beide virtuellen Netzwerke müssen routenbasierte VPNs (zuvor als dynamisches Routing bezeichnet) verwenden.

Verwenden VPN-Tunnel Bandbreite gemeinsam?

Ja. Alle VPN-Tunnel des virtuellen Netzwerks verwenden die verfügbare Bandbreite auf dem VPN Gateway und das gleiche SLA für die Verfügbarkeit des VPN Gateways in Azure gemeinsam.

Werden redundante Tunnel unterstützt?

Redundante Tunnel zwischen einem Paar virtueller Netzwerke werden unterstützt, wenn ein virtuelles Netzwerkgateway als „Aktiv-Aktiv“ konfiguriert ist.

Kann ich für VNet-zu-VNet-Konfigurationen Adressräume verwenden, die sich überschneiden?

Nein. IP-Adressbereiche dürfen sich nicht überschneiden.

Dürfen sich die Adressräume der verbundenen virtuellen Netzwerke und der lokalen Standorte überschneiden?

Nein. IP-Adressbereiche dürfen sich nicht überschneiden.

Wie aktiviere ich das Routing zwischen meiner Site-to-Site-VPN-Verbindung und ExpressRoute?

Wenn Sie das Routing zwischen Ihrer Filiale, die mit ExpressRoute verbunden ist, und Ihrer Filiale, die mit einem Site-to-Site-VPN verbunden ist, aktivieren möchten, müssen Sie den Azure Route Server einrichten.

Kann ich mit einem VPN Gateway Datenverkehr zwischen meinen lokalen Standorten oder an ein anderes virtuelles Netzwerk übertragen?

  • Ressourcen-Manager-Bereitstellungsmodell

    Ja. Weitere Informationen finden Sie im Abschnitt BGP und Routing.

  • Klassisches Bereitstellungsmodell

    Die Durchleitung des Datenverkehrs über ein VPN Gateway ist möglich, wenn Sie das klassische Bereitstellungsmodell verwenden, aber es ist auf statisch definierte Adressräume in der Netzwerkkonfigurationsdatei angewiesen. Border Gateway Protocol (BGP) wird über das klassische Bereitstellungsmodell noch nicht für virtuelle Azure-Netzwerke und VPN Gateways unterstützt. Ohne BGP müssen die Adressräume für die Übertragung manuell definiert werden. Dies ist jedoch fehleranfällig und wird daher nicht empfohlen.

Generiert Azure für alle meine VPN-Verbindungen für das gleiche virtuelle Netzwerk den gleichen vorinstallierten IPsec-/IKE-Schlüssel?

Nein Azure generiert für unterschiedliche VPN-Verbindungen standardmäßig unterschiedliche vorinstallierte Schlüssel. Mit der REST-API oder dem PowerShell-Cmdlet „Set VPN Gateway Key“ können Sie jedoch den Schlüsselwert nach Ihren Vorstellungen festlegen. Der Schlüssel muss ausschließlich druckbare ASCII-Zeichen enthalten, mit Ausnahme von Leerzeichen, Bindestrich (-) oder Tilde (~).

Erhalte ich durch mehr Standort-zu-Standort-VPNs mehr Bandbreite als bei einem einzelnen virtuellen Netzwerk?

Nein Alle VPN-Tunnel (einschließlich Point-to-Site-VPNs) verwenden das gleiche VPN Gateway und die gleiche verfügbare Bandbreite.

Kann ich mithilfe eines VPNs mit mehreren Standorten mehrere Tunnel zwischen meinem virtuellen Netzwerk und meinem lokalen Standort konfigurieren?

Ja. Sie müssen aber BGP für beide Tunnel zu demselben Standort konfigurieren.

Werden bei Azure VPN Gateway vorangestellte AS-Pfade zum Beeinflussen von Routingentscheidungen zwischen mehreren Verbindungen mit meinen lokalen Standorten berücksichtigt?

Ja, das Azure VPN Gateway nutzt den vorangestellten Pfad des autonomen Systems (AS) für Routingentscheidungen, wenn BGP aktiviert ist. Bei der BGP-Pfadauswahl wird ein kürzerer AS-Pfad bevorzugt.

Kann ich beim Erstellen einer neuen VirtualNetworkGateway-VPN-Verbindung die RoutingWeight-Eigenschaft verwenden?

Nein Eine solche Einstellung ist für ExpressRoute-Gatewayverbindungen reserviert. Wenn Sie Routingentscheidungen zwischen mehreren Verbindungen beeinflussen möchten, müssen Sie AS-Pfad voranstellen.

Kann ich Punkt-zu-Standort-VPNs mit meinem virtuellen Netzwerk und mehreren VPN-Tunneln kombinieren?

Ja. Sie können Point-to-Site-VPNs mit den VPN Gateways kombinieren, die Verbindungen mit mehreren lokalen Standorten und anderen virtuellen Netzwerken herstellen.

Kann ich eine Verbindung zwischen einem virtuellen Netzwerk mit IPsec-VPNs und meiner ExpressRoute-Verbindung herstellen?

Ja, das wird unterstützt. Weitere Informationen finden Sie unter Konfigurieren von parallel bestehenden ExpressRoute- und Site-to-Site-Verbindungen.

IPsec-/IKE-Richtlinie

Wird eine benutzerdefinierte IPsec-/IKE-Richtlinie von allen Azure VPN Gateway-SKUs unterstützt?

Eine benutzerdefinierte IPsec-/IKE-Richtlinie wird von allen Azure VPN Gateway-SKUs außer der Basic-SKU unterstützt.

Wie viele Richtlinien kann ich für eine Verbindung angeben?

Pro Verbindung kann jeweils nur eine Richtlinienkombination angegeben werden.

Kann ich eine Teilrichtlinie für eine Verbindung angeben (z. B. nur IKE-Algorithmen, aber nicht IPSec)?

Nein. Sie müssen alle Algorithmen und Parameter für IKE (Hauptmodus) und IPsec (Schnellmodus) angeben. Eine teilweise Angabe von Richtlinien ist unzulässig.

Welche Algorithmen und Schlüsselstärken werden in der benutzerdefinierten Richtlinie unterstützt?

In der folgenden Tabelle sind die unterstützten kryptografischen Algorithmen und Schlüsselstärken aufgeführt, die Sie konfigurieren können. Für jedes Feld muss eine Option ausgewählt werden.

IPsec/IKEv2 Optionen
IKEv2-Verschlüsselung GCMAES256, GCMAES128, AES256, AES192, AES128
IKEv2-Integrität SHA384, SHA256, SHA1, MD5
DH-Gruppe DHGroup24, ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, keine
IPsec-Verschlüsselung GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, keine
IPsec-Integrität GCMAES256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
PFS-Gruppe PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, keine
Lebensdauer der Schnellmodus-SA (Optional; Standardwerte, falls nicht angegeben)
Sekunden (ganze Zahl; mindestens 300, Standardwert: 27.000)
Kilobyte (ganze Zahl; mindestens 1.024, Standardwert: 10.2400.000)
Datenverkehrsselektor UsePolicyBasedTrafficSelectors ($True oder $False, aber optional; Standardwert $False, wenn nicht angegeben)
DPD-Timeout Sekunden (ganze Zahl; mindestens 9, maximal 3.600, Standardwert: 45)

  • Ihre lokale VPN-Gerätekonfiguration muss folgenden Algorithmus- und Parameterangaben für die Azure-IPsec- oder IKE-Richtlinie entsprechen oder selbige enthalten:

    • IKE-Verschlüsselungsalgorithmus (Hauptmodus, Phase 1)
    • IKE-Integritätsalgorithmus (Hauptmodus, Phase 1)
    • DH-Gruppe (Hauptmodus, Phase 1)
    • IPSec-Verschlüsselungsalgorithmus (Schnellmodus, Phase 2)
    • IPSec-Integritätsalgorithmus (Schnellmodus, Phase 2)
    • PFS-Gruppe (Schnellmodus, Phase 2)
    • Datenverkehrsauswahl (bei Verwendung von UsePolicyBasedTrafficSelectors)
    • SA-Lebensdauer (lokale Spezifikationen, die nicht übereinstimmen müssen)

  • Wenn Sie GCMAES als IPsec-Verschlüsselungsalgorithmus verwenden, müssen Sie denselben GCMAES-Algorithmus und dieselbe Schlüssellänge für die IPsec-Integrität auswählen. Verwenden Sie beispielsweise GCMAES128 für beide.

  • In der Tabelle mit Algorithmen und Schlüsseln:

    • IKE entspricht Hauptmodus oder Phase 1.
    • IPsec entspricht Hauptmodus oder Phase 2
    • Die DH-Gruppe gibt die im Hauptmodus oder in Phase 1 verwendete Diffie-Hellman-Gruppe an.
    • Die PFS-Gruppe gibt die im Schnellmodus oder in Phase 2 verwendete Diffie-Hellman-Gruppe an.

  • Die SA-Gültigkeitsdauer des IKE-Hauptmodus ist für die Azure-VPN-Gateways auf 28.800 Sekunden festgelegt.

  • UsePolicyBasedTrafficSelectors ist ein optionaler Parameter für die Verbindung. Wenn Sie UsePolicyBasedTrafficSelectors für eine Verbindung auf $True festgelegt haben, wird das VPN-Gateway so konfiguriert, dass eine Verbindung mit einer lokalen richtlinienbasierten VPN-Firewall hergestellt wird.

    Wenn Sie UsePolicyBasedTrafficSelectors aktivieren, müssen Sie sicherstellen, dass für Ihr VPN-Gerät die entsprechenden Datenverkehrsselektoren mit allen Präfixkombinationen zwischen Ihrem lokalen Netzwerk (lokalen Netzwerkgateway) und den Präfixen des virtuellen Azure-Netzwerks definiert sind (anstelle von Any-to-Any). Das VPN-Gateway akzeptiert die vom Remote-VPN-Gateway vorgeschlagene Datenverkehrsauswahl unabhängig von der Konfiguration des VPN-Gateways.

    Wenn die Präfixe Ihres lokalen Netzwerks also beispielsweise 10.1.0.0/16 und 10.2.0.0/16 lauten und für Ihr virtuelles Netzwerk die Präfixe 192.168.0.0/16 und 172.16.0.0/16 verwendet werden, müssen folgende Datenverkehrsselektoren angegeben werden:

    • 10.1.0.0/16 <====> 192.168.0.0/16
    • 10.1.0.0/16 <====> 172.16.0.0/16
    • 10.2.0.0/16 <====> 192.168.0.0/16
    • 10.2.0.0/16 <====> 172.16.0.0/16

    Weitere Informationen zu richtlinienbasierten Datenverkehrsselektoren finden Sie unter Herstellen einer Verbindung zwischen VPN-Gateways und mehreren lokalen richtlinienbasierten VPN-Geräten.

  • Wenn Sie das Timeout auf einen kürzeren Zeitraum festlegen, wird die Neuverschlüsselung von IKE aggressiver durchgeführt. In manchen Fällen kann die Verbindung dann scheinbar unterbrochen werden. Diese Situation ist möglicherweise nicht wünschenswert, wenn Ihre lokalen Standorte weiter von der Azure-Region entfernt sind, in der sich das VPN-Gateway befindet, oder wenn der Zustand der physischen Verbindung zu Paketverlusten führen könnte. Im Allgemeinen wird empfohlen, für das Timeout einen Wert zwischen 30 und 45 Sekunden festzulegen.

Weitere Informationen finden Sie unter Herstellen einer Verbindung zwischen einem VPN-Gateway und mehreren lokalen richtlinienbasierten VPN-Geräten.

Welche Diffie-Hellman-Gruppen unterstützt die benutzerdefinierte Richtlinie?

Die folgende Tabelle enthält die entsprechenden Diffie-Hellman-Gruppen, die von der benutzerdefinierten Richtlinie unterstützt werden:

Diffie-Hellman-Gruppe DHGroup PFSGroup Schlüssellänge
1 DHGroup1 PFS1 768-Bit-MODP
2 DHGroup2 PFS2 1024-Bit-MODP
14 DHGroup14
DHGroup2048		 PFS2048 2048-Bit-MODP
19 ECP256 ECP256 256-Bit-ECP
20 ECP384 ECP384 384-Bit-ECP
24 DHGroup24 PFS24 2048-Bit-MODP

Weitere Informationen finden Sie unter RFC3526 und RFC5114.

Ersetzt die benutzerdefinierte Richtlinie die IPSec-/IKE-Standardrichtliniensätze für VPN-Gateways?

Ja. Nachdem Sie eine benutzerdefinierte Richtlinie für eine Verbindung angegeben haben, verwendet Azure VPN Gateway nur diese Richtlinie für die Verbindung (sowohl als IKE-Initiator als auch als IKE-Antwortender).

Ist die Verbindung nach dem Entfernen einer benutzerdefinierten IPsec-/IKE-Richtlinie ungeschützt?

Nein, IPsec/IKE trägt weiterhin zum Schutz der Verbindung bei. Nachdem Sie die benutzerdefinierte Richtlinie für eine Verbindung entfernt haben, verwendet das VPN-Gateway wieder die Standardliste mit IPsec-/IKE-Vorschlägen und startet den IKE-Handshake mit Ihrem lokalen VPN-Gerät neu.

Führt das Hinzufügen oder Aktualisieren einer IPsec-/IKE-Richtlinie zu einer Unterbrechung meiner VPN-Verbindung?

Ja. Ein solcher Vorgang kann dazu führen, dass die Verbindung kurzzeitig (für wenige Sekunden) unterbrochen wird, da das VPN-Gateway die vorhandene Verbindung trennt und den IKE-Handshake neu startet, um den IPsec-Tunnel mit den neuen kryptografischen Algorithmen und Parametern einzurichten. Stellen Sie sicher, dass Ihr lokales VPN-Gerät mit den entsprechenden Algorithmen und Schlüssellängen konfiguriert ist, damit die Unterbrechung möglichst kurz ausfällt.

Kann ich unterschiedliche Richtlinien für unterschiedliche Verbindungen verwenden?

Ja. Eine benutzerdefinierte Richtlinien ist verbindungsspezifisch. Sie können verschiedene IPsec-/IKE-Richtlinien für verschiedene Verbindungen erstellen und anwenden.

Außerdem können Sie benutzerdefinierte Richtlinien auf eine Teilmenge der Verbindungen anwenden. Für die restlichen Verbindungen werden die IPsec-/IKE-Standardrichtliniensätze von Azure verwendet.

Kann ich eine benutzerdefinierte Richtlinie für VNet-to-VNet-Verbindungen verwenden?

Ja. Sie können eine benutzerdefinierte Richtlinie sowohl für standortübergreifende IPsec-Verbindungen als auch für VNet-to-VNet-Verbindungen verwenden.

Muss ich die gleiche Richtlinie für beide VNET-zu-VNET-Verbindungsressourcen angeben?

Ja. Ein VNET-zu-VNET-Tunnel besteht aus zwei Verbindungsressourcen in Azure (je eine pro Richtung). Stellen Sie sicher, dass beide Verbindungsressourcen über dieselbe Richtlinie verfügen. Andernfalls wird die VNet-to-VNet-Verbindung nicht hergestellt.

Wie lautet der Standardwert für das DPD-Timeout? Kann ich ein anderes DPD-Timeout angeben?

Das DPD-Timeout wird für VPN-Gateways standardmäßig auf 45 Sekunden festgelegt. Sie können für jede IPsec- oder VNet-to-VNet-Verbindung einen anderen DPD-Timeoutwert zwischen 9 und 3.600 Sekunden angeben.

Hinweis

Wenn Sie das Timeout auf einen kürzeren Zeitraum festlegen, wird die Neuverschlüsselung von IKE aggressiver durchgeführt. In manchen Fällen kann die Verbindung dann scheinbar unterbrochen werden. Diese Situation ist möglicherweise nicht wünschenswert, wenn Ihre lokalen Standorte weiter von der Azure-Region entfernt sind, in der sich das VPN-Gateway befindet, oder wenn der Zustand der physischen Verbindung zu Paketverlusten führen könnte. Im Allgemeinen wird empfohlen, für das Timeout einen Wert zwischen 30 und 45 Sekunden festzulegen.

Kann eine benutzerdefinierte IPsec-/IKE-Richtlinie für ExpressRoute-Verbindungen verwendet werden?

Nein Eine IPsec-/IKE-Richtlinie kann nur für S2S-VPN- und VNet-to-VNet-Verbindungen über VPN-Gateways verwendet werden.

Wie kann ich Verbindungen mit dem IKEv1- oder IKEv2-Protokolltyp erstellen?

Sie können IKEv1-Verbindungen für alle SKUs vom routenbasierten VPN-Typ, mit Ausnahme der Basic-SKU, Standard-SKU und anderen älteren SKUs erstellen.

Sie können beim Erstellen von Verbindungen IKEv1 oder IKEv2 als Verbindungsprotokolltyp angeben. Wenn Sie keinen Verbindungsprotokolltyp angeben, wird IKEv2 als Standardoption verwendet, sofern dies zutreffend ist. Weitere Informationen finden Sie in der Dokumentation zum Azure PowerShell-Cmdlet.

Informationen zu SKU-Typen und Unterstützung für IKEv1 und IKEv2 finden Sie unter Herstellen einer Verbindung zwischen einem VPN-Gateway und mehreren lokalen richtlinienbasierten VPN-Geräten.

Ist die Übertragung zwischen IKEv1- und IKEv2-Verbindungen zulässig?

Ja.

Kann ich IKEv1-Site-to-Site-Verbindungen für die Basic-SKU mit dem routenbasierten VPN-Typ verwenden?

Nein Die Basic-SKU unterstützt diese Konfiguration nicht.

Kann ich den Verbindungsprotokolltyp ändern, nachdem die Verbindung erstellt wurde (IKEv1 in IKEv2 und umgekehrt)?

Nein Nachdem Sie die Verbindung erstellt haben, können Sie die Protokolle IKEv1 und IKEv2 nicht mehr ändern. Sie müssen die Verbindung löschen und eine neue Verbindung mit dem gewünschten Protokolltyp erstellen.

Warum wird meine IKEv1-Verbindung häufig erneut hergestellt?

Wenn das statische Routing oder die routenbasierte IKEv1-Verbindung in regelmäßigen Abständen unterbrochen wird, liegt dies wahrscheinlich daran, dass Ihre VPN-Gateways keine direkte Neuerstellung von Schlüsseln unterstützen. Bei der Neuerstellung der Schlüssel im Hauptmodus werden Ihre IKEv1-Tunnel getrennt, und es dauert bis zu 5 Sekunden, bis die Verbindungen wiederhergestellt sind. Der Timeoutwert der Aushandlung für den Hauptmodus bestimmt, wie häufig die Schlüssel neu erstellt werden. Um diese erneuten Verbindungen zu verhindern, können Sie auf IKEv2 umstellen, das eine direkte Neuerstellung von Schlüsseln unterstützt.

Wenn Ihre Verbindung in unregelmäßigen Abständen neu hergestellt wird, lesen Sie den Leitfaden zur Problembehandlung.

Wo finde ich weitere Informationen und Schritte für die Konfiguration?

Weitere Informationen finden Sie in folgenden Artikeln:

BGP und Routing

Wird BGP von allen Azure-VPN-Gateway-SKUs unterstützt?

BGP wird mit Ausnahme der Basic SKU für alle Azure VPN Gateway-SKUs unterstützt.

Kann ich BGP mit Azure Policy-VPN-Gateways verwenden?

Nein. BGP wird nur für routenbasierte VPN-Gateways unterstützt.

Welche ASNs kann ich verwenden?

Sie können eigene öffentliche Autonome Systemnummern (ASNs) oder private ASNs sowohl für Ihre lokalen Netzwerke als auch für Ihre virtuellen Azure-Netzwerke verwenden.

Sie können die folgenden reservierten ASNs nicht verwenden:

  • Von Azure reserviert:

    • Öffentliche ASNs: 8074, 8075, 12076
    • Private ASNs: 65515, 65517, 65518, 65519, 65520

  • Von IANA reserviert:

    • 23456, 64496-64511, 65535-65551, 429496729

Diese ASNs können beim Herstellen einer Verbindung mit VPN Gateways nicht für Ihre lokalen VPN-Geräte angegeben werden.

Kann ich 32-Bit-ASNs (4 Bytes) verwenden?

Ja, Azure VPN Gateway unterstützt nun 32-Bit-ASNs (4 Bytes). Verwenden Sie zum Konfigurieren mithilfe von ASNs im Dezimalformat Azure PowerShell, die Azure CLI oder das Azure SDK.

Welche privaten ASNs kann ich verwenden?

Die folgenden Bereiche privater ASNs können verwendet werden:

  • 64512-65514 und 65521-65534

Weder IANA noch Azure reserviert diese ASNs, sodass Sie sie Ihrem VPN Gateway zuweisen können.

Welche Adresse verwendet das Azure VPN Gateway als BGP-Peering-IP-Adresse?

Azure VPN Gateway ordnet standardmäßig eine einzelne IP-Adresse aus dem GatewaySubnet-Bereich für Aktiv/Standby VPN Gateways oder zwei IP-Adressen für Aktiv/Aktiv VPN Gateways zu. Diese Adressen werden automatisch zugeordnet, wenn Sie das VPN-Gateway erstellen.

Sie finden die zugeordnete BGP-IP-Adresse mithilfe von Azure PowerShell oder dem Azure-Portal. Verwenden Sie in PowerShell Get-AzVirtualNetworkGateway, und suchen Sie nach der Eigenschaft bgpPeeringAddress. Sehen Sie im Azure-Portal auf der Seite Gatewaykonfiguration unter der Eigenschaft BGP-ASN konfigurieren nach.

Wenn Ihre lokalen VPN-Router Automatische Privat-IP-Adressierung (APIPA) IP-Adressen (169.254.x.x) als BGP-IP-Adressen verwenden, müssen Sie eine oder mehrere Azure-APIPA-BGP-IP-Adressen auf Ihrem VPN Gateway angeben. Azure VPN Gateway wählt die APIPA-Adressen aus, die mit dem lokalen APIPA-BGP-Peer, der im Gateway des lokalen Netzwerks angegeben ist, verwendet werden sollen oder die private IP-Adresse für einen lokalen BGP-Peer ohne APIPA. Weitere Informationen finden Sie unter Konfigurieren von BGP auf Azure VPN Gateways.

Welche Anforderungen müssen die BGP-Peer-IP-Adressen auf meinem VPN-Gerät erfüllen?

Ihre lokale BGP-Peer-Adresse darf nicht der öffentlichen IP-Adresse Ihres VPN-Geräts entsprechen oder aus dem VNet-Adressraum des VPN Gateways stammen. Verwenden Sie als BGP-Peer-IP-Adresse eine andere IP-Adresse für das VPN-Gerät. Dabei kann es sich um eine Adresse handeln, die der Loopbackschnittstelle auf dem Gerät zugewiesen ist (reguläre IP-Adresse oder APIPA-Adresse).

Wenn Ihr Gerät eine APIPA-Adresse für BGP verwendet, müssen Sie eine oder mehrere APIPA-BGP-IP-Adressen auf Ihrem VPN Gateway angeben, wie unter Konfigurieren von BGP für Azure VPN Gateway beschrieben. Geben Sie diese Adressen im entsprechenden lokalen Netzwerkgateway an, das den Standort darstellt.

Was muss ich bei Verwendung von BGP als Adresspräfixe für das lokale Netzwerkgateway angeben?

Wichtig

Hierbei handelt es sich um eine Änderung gegenüber der zuvor dokumentierten Anforderung.

Von Azure VPN Gateway wird intern eine Hostroute zur lokalen BGP-Peer-IP-Adresse über den IPsec-Tunnel hinzugefügt. Fügen Sie die /32-Route nicht dem Feld Adressraum hinzu, da sie redundant ist. Sie kann diesem Feld nicht hinzugefügt werden, wenn als BGP-IP-Adresse des lokalen VPN-Geräts eine APIPA-Adresse verwendet wird.

Wenn Sie im Feld Adressraum andere Präfixe hinzufügen, werden diese zusätzlich zu den über BGP ermittelten Routen als statische Routen für das Azure-VPN-Gateway hinzugefügt.

Kann ich die gleiche ASN sowohl für lokale VPN-Netzwerke als auch für Azure-VNETs verwenden?

Nein Sie müssen lokalen Netzwerken und virtuellen Azure-Netzwerken jeweils eine andere ASN zuweisen, wenn diese per BGP miteinander verbunden werden.

Azure-VPN-Gateways ist standardmäßig die ASN 65515 zugewiesen. Dabei spielt es keine Rolle, ob BGP für Ihre standortübergreifende Konnektivität aktiviert ist. Diesen Standardwert können Sie überschreiben, indem Sie beim Erstellen des VPN-Gateways eine andere ASN zuweisen, oder Sie können die ASN nach der Gatewayerstellung ändern. Ihre lokalen ASNs müssen den entsprechenden lokalen Azure-Netzwerkgateways zugewiesen werden.

Welche Adresspräfixe kündigen Azure VPN Gateways mir gegenüber an?

Die Gateways kündigen Ihren lokalen BGP-Geräten gegenüber folgende Routen an:

  • Ihre VNET-Adresspräfixe
  • Adresspräfixe für die einzelnen lokalen Netzwerkgateways, die mit dem VPN Gateway verbunden sind
  • Routen, die in anderen, mit dem VPN Gateway verbundenen BGP-Peeringsitzungen ermittelt wurden (mit Ausnahme der Standardrouten, die sich mit VNET-Präfixen überschneiden)

Wie viele Präfixe kann ich Azure VPN Gateway ankündigen?

Azure VPN Gateway unterstützt bis zu 4.000 Präfixe. Die BGP-Sitzung wird verworfen, wenn die Anzahl von Präfixen den Grenzwert überschreitet.

Kann ich die Standardroute (0.0.0.0/0) für VPN Gateways ankündigen?

Ja. Denken Sie daran, dass die Ankündigung für die Standardroute den gesamten ausgehenden Datenverkehr des VNet zu Ihrer lokalen Website erzwingt. Außerdem wird verhindert, dass die VMs des virtuellen Netzwerks die öffentliche Kommunikation aus dem Internet direkt akzeptieren, etwa das Remotedesktopprotokoll (RDP) oder Secure Shell (SSH) aus dem Internet an die VMs.

Kann ich die gleichen Präfixe wie meine Präfixe des virtuellen Netzwerks ankündigen?

Nein Azure blockiert oder filtert die Ankündigung für dieselben Präfixe wie eines Ihrer VNet-Adresspräfixe. Sie können jedoch ein Präfix ankündigen, das eine Obermenge der Inhalte Ihres virtuellen Netzwerks ist.

Sie können beispielsweise 10.0.0.0/8 ankündigen, wenn für Ihr virtuelles Netzwerk der Adressraum 10.0.0.0/16 verwendet wird. Das Ankündigen von 10.0.0.0/16 oder 10.0.0.0/24 ist dagegen nicht möglich.

Kann ich BGP für meine Verbindungen zwischen virtuellen Netzwerken verwenden?

Ja. Sie können BGP sowohl für standortübergreifende Verbindungen als auch für Verbindungen zwischen virtuellen Netzwerken verwenden.

Kann ich BGP-Verbindungen mit BGP-fremden Verbindungen für meine Azure-VPN-Gateways kombinieren?

Ja. Für ein Azure-VPN-Gateway kann eine Kombination aus BGP-Verbindungen und BGP-fremden Verbindungen verwendet werden.

Wird BGP-Transitrouting von Azure VPN Gateway unterstützt?

Ja. BGP-Transitrouting wird unterstützt. Einzige Einschränkung: VPN Gateways kündigen gegenüber anderen BGP-Peers keine Standardrouten an. Wenn Sie Transitrouting über mehrere VPN Gateways hinweg nutzen möchten, müssen Sie BGP für alle Zwischenverbindungen für virtuelle Netzwerke aktivieren. Weitere Informationen finden Sie unter Übersicht über BGP mit VPN Gateway.

Kann ich zwischen einem VPN Gateway und meinem lokalen Netzwerk mehrere Tunnel verwenden?

Ja. Zwischen einem VPN Gateway und Ihrem lokalen Netzwerk können mehrere Site-to-Site-VPN-Tunnel eingerichtet werden. Alle diese Tunnel werden auf die Gesamtanzahl von Tunneln für Ihre Azure-VPN-Gateways angerechnet und Sie müssen BGP für beide Tunnel aktivieren.

Wenn also etwa zwischen Ihrem VPN Gateway und einem Ihrer lokalen Netzwerke zwei redundante Tunnel bestehen, werden dadurch zwei Tunnel des Gesamtkontingents für Ihr VPN Gateway belegt.

Kann ich zwischen zwei virtuellen Azure-Netzwerken mit BGP mehrere Tunnel verwenden?

Ja. Aber mindestens eines der virtuellen Netzwerkgateways muss über eine Aktiv/Aktiv-Konfiguration verfügen.

Kann ich BGP für eine S2S-VPN-Verbindungen in einer Konfiguration mit Azure ExpressRoute und S2S-VPN verwenden?

Ja.

Was muss ich meinem lokalen VPN-Gerät für die BGP-Peeringsitzung hinzufügen?

Fügen Sie auf Ihrem VPN-Gerät eine Hostroute der IP-Adresse des Azure-BGP-Peers hinzu. Diese Route verweist auf den IPsec-S2S-VPN-Tunnel.

Lautet die Azure-VPN-Peer-IP-Adresse also etwa 10.12.255.30, müssen Sie eine Hostroute für 10.12.255.30 mit einer Nexthop-Schnittstelle der entsprechenden IPSec-Tunnelschnittstelle auf Ihrem VPN-Gerät hinzufügen.

Unterstützt das Gateway des virtuellen Netzwerks BFD für Site-to-Site-Verbindungen mit BGP?

Nein Bidirectional Forwarding Detection (BFD) ist ein Protokoll, das mit BGP verwendet werden kann, um Nachbar-Downtime schneller zu erkennen als bei Verwendung standardmäßiger BGP-Keepalive-Intervalle. BFD verwendet Zeitgeber im Sekundenbruchteilbereich. Diese sind für den Einsatz in LAN-Umgebungen konzipiert, aber nicht für öffentliche Internetverbindungen oder für WAN-Verbindungen geeignet.

Bei Verbindungen über das öffentliche Internet ist es nicht ungewöhnlich, dass bestimmte Pakete verzögert oder sogar verworfen werden. Daher würde die Einführung dieser aggressiven Zeitgeber zu mehr Instabilität führen. Diese Instabilität kann dazu führen, dass BGP Routen dämpft.

Alternativ können Sie Ihr lokales Gerät mit Zeitgebern konfigurieren, die niedriger sind als das standardmäßige Keepalive-Intervall von bis zu 60 Sekunden und der Hold-Zeitgeber von 180 Sekunden. Mit dieser Konfiguration wird eine schnellere Konvergenz erreicht. Timer unterhalb des Standardintervalls von 60 Sekunden (Keepalive) oder unterhalb des standardmäßigen Haltezeitgebers von 180 Sekunden sind jedoch nicht zuverlässig. Wir empfehlen Ihnen, die Standardwerte für Timer einzuhalten oder zu überschreiten.

Werden von VPN Gateways BGP-Peeringsitzungen oder -verbindungen initiiert?

VPN Gateways initiiert mithilfe der privaten IP-Adressen der VPN Gateways BGP-Peeringsitzungen für die lokalen BGP-Peer-IP-Adressen, die in den Ressourcen des lokalen Netzwerkgateways angegeben sind. Dieser Prozess ist unabhängig davon, ob sich die lokalen BGP-IP-Adressen im APIPA-Bereich befinden oder ob es sich dabei um reguläre private IP-Adressen handelt. Nutzen Ihre lokalen VPN-Geräte APIPA-Adressen als BGP-IP-Adresse, müssen Sie den BGP-Sprecher zum Initiieren der Verbindungen konfigurieren.

Kann ich die Tunnelerzwingung konfigurieren?

Ja. Weitere Informationen finden Sie unter Konfigurieren der Tunnelerzwingung.

NAT

Wird NAT von allen Azure-VPN-Gateway-SKUs unterstützt?

NAT wird unter VpnGw2 zu VpnGw25 und vpnGw2AZ zu VpnGw5AZ unterstützt.

Kann ich NAT bei VNet-to-VNet- oder P2S-Verbindungen verwenden?

Nein

Wie viele NAT-Regeln kann ich auf einem VPN-Gateway verwenden?

Sie können bis zu 100 NAT-Regeln (Ein- und Ausgangsregeln kombiniert) auf einem VPN Gateway erstellen.

Kann ich einen Schrägstrich (/) in einem NAT-Regelnamen verwenden?

Nein Sie werden eine Fehlermeldung erhalten.

Wird NAT auf alle Verbindungen an einem VPN-Gateway angewendet?

NAT wird auf die Verbindungen mit NAT-Regeln angewendet. Wenn eine Verbindung keine NAT-Regel aufweist, wird NAT für diese Verbindung nicht wirksam. Auf demselben VPN Gateway können einige Verbindungen mit NAT und andere Verbindungen ohne NAT zusammenarbeiten.

Welche NAT-Typen unterstützen VPN Gateways?

VPN Gateways unterstützen nur statisches 1:1-NAT und dynamisches NAT. NAT64 wird nicht unterstützt.

Funktioniert NAT bei VPN-Gateways vom Typ „Aktiv-Aktiv“?

Ja. NAT funktioniert sowohl bei VPN-Gateways vom Typ „Aktiv-Aktiv“ als auch „Aktiv-Standby“. Jede NAT-Regel wird auf eine einzelne Instanz des VPN-Gateways angewendet. Erstellen Sie in Aktiv/Aktiv-Gateways eine separate NAT-Regel für jede Gateway-Instanz über das Feld IP-Konfigurations-ID.

Funktioniert NAT mit BGP-Verbindungen?

Ja, Sie können BGP mit NAT verwenden. Hier folgen einige wichtige Überlegungen:

  • Wählen Sie auf der Konfigurationsseite für NAT-Regeln die Option BGP-Routenübersetzung aktivieren aus, um sicherzustellen, dass die erlernten und angekündigten Routen auf der Grundlage der mit den Verbindungen verbundenen NAT-Regeln in Post-NAT-Adresspräfixe (externe Zuordnungen) übersetzt werden. Die lokalen BGP-Router müssen genau die Präfixe ankündigen, die in den IngressSNAT-Regeln definiert sind.

  • Wenn der lokale VPN-Router eine reguläre, nicht-APIPA-Adresse verwendet und diese mit dem VNet-Adressraum oder anderen lokalen Netzwerkräumen kollidiert, stellen Sie sicher, dass die IngressSNAT-Regel die BGP-Peer-IP in eine eindeutige, nicht überlappende Adresse übersetzt. Fügen Sie die Post-NAT-Adresse in das Feld BGP-Peer-IP-Adresse des lokalen Netzwerkgateways ein.

  • NAT wird mit BGP-APIPA-Adressen nicht unterstützt.

Muss ich die passenden DNAT-Regeln für die SNAT-Regel erstellen?

Nein Eine einzelne SNAT-Regel (Übersetzung der Quellnetzwerkadresse) definiert die Übersetzung für beide Richtungen eines bestimmten Netzwerks:

  • Eine IngressSNAT-Regel definiert die Übersetzung der Quell-IP-Adressen, die aus dem lokalen Netzwerk beim VPN Gateway eingehen. Außerdem wird die Übersetzung der Ziel-IP-Adressen verarbeitet, die das virtuelle Netzwerk verlassen und an dasselbe lokale Netzwerk gehen.

  • Eine EgressSNAT-Regel definiert die Übersetzung der Quell-IP-Adressen des VNet, die das VPN Gateway verlassen und an die lokalen Netzwerke gehen. Außerdem wird die Übersetzung der Ziel-IP-Adressen für Pakete verarbeitet, die über die Verbindungen mit der EgressSNAT-Regel beim virtuellen Netzwerk eingehen.

In beiden Fällen benötigen Sie keine DNAT-Regeln (Destination Network Address Translation).

Wie muss ich vorgehen, wenn mein VNet oder mein lokaler Netzwerkgatewayadressraum zwei oder mehr Präfixe aufweist? Kann ich NAT auf alle oder nur auf eine Teilmenge anwenden?

Sie müssen für jedes Präfix eine NAT-Regel erstellen, da jede NAT-Regel nur ein Adresspräfix für NAT enthalten kann. Wenn der Adressraum des lokalen Netzwerkgateways z. B. aus 10.0.1.0/24 und 10.0.2.0/25 besteht, können Sie zwei Regeln erstellen:

  • IngressSNAT-Regel 1: Zuordnung von 10.0.1.0/24 zu 100.0.1.0/24
  • IngressSNAT-Regel 2: Zuordnung von 10.0.2.0/25 zu 100.0.2.0/25

Die beiden Regeln müssen mit den Präfixlängen der entsprechenden Adresspräfixe übereinstimmen. Das Gleiche gilt für EgressSNAT-Regeln für den VNet-Adressraum.

Wichtig

Wenn Sie nur eine Regel mit der obigen Verbindung verknüpfen, wird der andere Adressraum nicht übersetzt.

Welche IP-Bereiche kann ich für die externe Zuordnung verwenden?

Sie können jeden geeigneten IP-Bereich für die externe Zuordnung verwenden, einschließlich öffentlicher und privater IP-Adressen.

Kann ich verschiedene EgressSNAT-Regeln verwenden, um meinen VNet-Adressraum in verschiedene Präfixe für lokale Netzwerke zu übersetzen?

Ja. Sie können mehrere EgressSNAT-Regeln für denselben VNet-Adressraum erstellen und die EgressSNAT-Regeln dann auf verschiedene Verbindungen anwenden.

Kann ich dieselbe IngressSNAT-Regel für verschiedene Verbindungen verwenden?

Ja. Sie verwenden in der Regel dieselbe IngressSNAT-Regel, wenn die Verbindungen für dasselbe lokale Netzwerk bestimmt sind, um Redundanz bereitzustellen. Sie können nicht dieselbe Eingangsregel verwenden, wenn die Verbindungen für verschiedene lokale Netzwerke bestimmt sind.

Benötige ich sowohl Eingangs- als auch Ausgangsregeln für eine NAT-Verbindung?

Sie benötigen sowohl Eingangs- als auch Ausgangsregeln für dieselbe Verbindung, wenn sich der lokale Netzwerkadressraum mit dem VNet-Adressraum überschneidet. Wenn der VNet-Adressraum für alle verbundenen Netzwerke eindeutig ist, benötigen Sie die EgressSNAT-Regel für diese Verbindungen nicht. Sie können die Eingangsregeln verwenden, um Adressüberlappungen zwischen den lokalen Netzwerken zu vermeiden.

Was wähle ich als „IP-Konfigurations-ID“ aus?

IP-Konfigurations-ID ist einfach der Name des IP-Konfigurationsobjekts, das die NAT-Regel verwenden soll. Mit dieser Einstellung wählen Sie einfach aus, welche öffentliche Gateway-IP-Adresse für die NAT-Regel gilt. Wenn Sie zur Erstellungszeit des Gateways keinen benutzerdefinierten Namen angegeben haben, wird die primäre IP-Adresse des Gateways der IP-Konfiguration default zugewiesen, und die sekundäre IP-Adresse wird der IP-Konfiguration activeActive zugewiesen.

Standortübergreifende Konnektivität und virtuelle Computer

Wenn sich mein virtueller Computer in einem virtuellen Netzwerk befindet und ich über eine standortübergreifende Verbindung verfüge, wie sollte ich dann die Verbindung mit dem virtuellen Computer herstellen?

Wenn RDP für Ihren virtuellen Computer aktiviert ist, können Sie die Verbindung mit dem virtuellen Computer über die private IP-Adresse herstellen. Geben Sie in diesem Fall die private IP-Adresse und den Port an, mit dem Sie eine Verbindung herstellen möchten (in der Regel 3389). Auf Ihrer VM müssen Sie den Port für den Datenverkehr konfigurieren.

Außerdem kann die Verbindung mit dem virtuellen Computer von einem anderen virtuellen Computer im gleichen virtuellen Netzwerk über die private IP-Adresse hergestellt werden. Wenn Sie die Verbindung an einem Standort außerhalb Ihres virtuellen Netzwerks herstellen möchten, kann über die private IP-Adresse keine RDP-Verbindung hergestellt werden. Wenn Sie also beispielsweise ein virtuelles Netzwerk mit Punkt-zu-Standort-Verbindung konfiguriert haben und die Verbindung nicht von Ihrem Computer aus herstellen, ist eine Verbindung mit dem virtuellen Computer auf Basis der privaten IP-Adresse nicht möglich.

Wenn sich mein virtueller Computer in einem virtuellen Netzwerk mit standortübergreifender Verbindung befindet, wird dann der gesamte Datenverkehr meines virtuellen Computers über diese Verbindung abgewickelt?

Nein Nur der Datenverkehr mit einer IP-Zieladresse, die innerhalb der angegebenen lokalen Netzwerk-IP-Adressbereiche des virtuellen Netzwerks liegt, wird über das Gateway des virtuellen Netzwerks abgewickelt.

Datenverkehr mit einer IP-Zieladresse im virtuellen Netzwerk bleibt innerhalb des virtuellen Netzwerks. Sonstiger Datenverkehr wird vom Lastenausgleichsmodul an die öffentlichen Netzwerke gesendet. Oder wenn Sie erzwungene Tunneling verwenden, wird der Datenverkehr über das VPN Gateway gesendet.

Wie führe ich die Problembehandlung für die RDP-Verbindung mit einem virtuellen Computer durch?

Falls Sie beim Herstellen einer Verbindung mit einem virtuellen Computer per VPN-Verbindung Probleme haben sollten, überprüfen Sie Folgendes:

  • Stellen Sie sicher, dass die Herstellung der VPN-Verbindung erfolgreich war.
  • Stellen Sie sicher, dass Sie die Verbindung mit der privaten IP-Adresse für die VM herstellen.
  • Falls Sie mithilfe der privaten IP-Adresse eine Verbindung mit der VM herstellen können, aber nicht mit dem Computernamen, überprüfen Sie, dass Sie das DNS ordnungsgemäß konfiguriert haben. Weitere Informationen zur Funktionsweise der Namensauflösung für VMs finden Sie unter Namensauflösung für Ressourcen in virtuellen Azure-Netzwerken.

Wenn Sie eine Point-to-Site-Verbindung herstellen, überprüfen Sie die folgenden zusätzlichen Elemente:

  • Überprüfen Sie mit ipconfig die IPv4-Adresse, die dem Ethernet-Adapter auf dem Computer zugewiesen ist, von dem aus Sie die Verbindung herstellen. Wenn sich die IP-Adresse im Adressbereich des virtuellen Netzwerks befindet, mit dem Sie die Verbindung herstellen, oder im Adressbereich Ihres VPN-Client-Adresspools liegt, wird dies als sich überschneidender Adressraum bezeichnet. Falls sich Ihr Adressraum auf diese Weise überschneidet, kommt der Netzwerkdatenverkehr nicht bei Azure an. Er verbleibt im lokalen Netzwerk.
  • Stellen Sie sicher, dass das VPN-Clientkonfigurationspaket generiert wurde, nachdem Sie die IP-Adressen des DNS-Servers für das virtuelle Netzwerk angegeben haben. Wenn Sie die IP-Adressen des DNS-Servers aktualisiert haben, generieren Sie ein neues VPN-Clientkonfigurationspaket und installieren es.

Weitere Informationen zur Problembehandlung für RDP-Verbindungen finden Sie unter Behandeln von Problemen bei Remotedesktopverbindungen mit einem virtuellen Azure-Computer.

Kundenseitig gesteuerte Gatewaywartung

Welche Dienste sind in der Wartungskonfiguration für den Bereich „Netzwerkgateways“ enthalten?

Der Bereich „Netzwerkgateways“ umfasst Gatewayressourcen in Netztechnologiediensten. Im Bereich „Netzwerkgateways“ gibt es vier Ressourcentypen:

  • Virtuelles Netzwerkgateway im ExpressRoute-Dienst
  • Virtuelles Netzwerkgateway im VPN Gateway-Dienst
  • VPN Gateway (Site-to-Site) im Azure Virtual WAN-Dienst
  • ExpressRoute Gateway im Virtual WAN-Dienst

Welche Wartung unterstützt die kundengesteuerte Wartung?

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 Gastbetriebssystemwartung und die Dienstwartung während dieses Fensters ausgeführt. Die kundengesteuerte Wartung deckt keine Hostupdates (z. B. über die Hostupdates für Ein/Aus hinaus) und kritische Sicherheitsupdates ab.

Kann ich eine frühzeitige Benachrichtigung über die Wartung erhalten?

Derzeit können Sie keine erweiterte Benachrichtigung über die Wartung von Ressourcen des Netzwerkgateways erhalten.

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 ein anderes Wartungsfenster als einen täglichen Zeitplan konfigurieren?

Derzeit müssen Sie ein tägliches Wartungsfenster konfigurieren.

Gibt es Fälle, in denen ich bestimmte Updates nicht steuern kann?

Die kundengesteuerte Wartung unterstützt Gastbetriebssystem- und Dienstupdates. Diese Updates berücksichtigen die meisten Wartungselemente, die für die Kund*innen problematisch sind. Einige andere Arten von Updates, einschließlich Hostupdates, liegen außerhalb des Bereichs der kundengesteuerten Wartung.

Wenn ein schwerwiegendes Sicherheitsproblem Kundinnen und Kunden gefährden könnte, muss Azure möglicherweise die Kontrolle des Kunden über das Wartungsfenster außer Kraft setzen und eine Änderung pushen. Diese Änderungen sind seltene Vorkommnisse, die wir nur in extremen Fällen verwenden.

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

Ja.

Welche Gateway-SKUs kann ich zur Verwendung der kundengesteuerten Wartung konfigurieren?

Alle Azure VPN Gateway-SKUs (mit Ausnahme der Basic-SKU) können zur Verwendung der kundengesteuerten Wartung konfiguriert werden.

Wie lange dauert es, bis eine 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.

Gibt es Einschränkungen für die Verwendung der kundengesteuerten Wartung aufgrund der öffentlichen IP-Adresse einer Basic-SKU?

Ja. Die kundengesteuerte Wartung funktioniert nicht für Ressourcen, die öffentliche IP-Adressen der Basic-SKU verwenden, außer im Fall von Dienstupdates. Bei diesen Gateways erfolgt die Wartung des Gastbetriebssystems aufgrund von Einschränkungen der Infrastruktur nicht nach dem kundengesteuerten Wartungsplan.

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

Wenn Sie in einem Koexistenzszenario mit VPN und ExpressRoute arbeiten, oder wenn Sie über Ressourcen verfügen, die als Backups fungieren, empfehlen wir, 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, Wartungsarbeiten an Ihrer Ressource werden im Zeitraum vor dem geplanten Wartungsfenster nicht angehalten. Für die Tage, die nicht in Ihrem Wartungszeitplan enthalten sind, wird die Wartung wie gewohnt für die Ressource fortgesetzt.

Wo finde ich weitere Informationen zur kundenseitig gesteuerten Gatewaywartung?

Weitere Informationen finden Sie im Artikel Konfigurieren der kundenseitig gesteuerten Gatewaywartung für VPN Gateway.

Zugehöriger Inhalt

„OpenVPN“ ist eine Marke von OpenVPN Inc.