Häufig gestellte Fragen zum VPN-Gateway

  • Artikel

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 beim Erstellen Ihres virtuellen Netzwerks einen oder mehrere DNS-Server angegeben haben, werden diese in VPN Gateway verwendet. Achten Sie bei der Angabe eines DNS-Servers darauf, dass dieser die für Azure erforderlichen Domänennamen auflösen kann.

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 Abschnitt Mehrere Standorte und VNet-zu-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?

Die folgenden standortübergreifenden Gateway-Verbindungen für virtuelle Netzwerke werden unterstützt:

Weitere Informationen zu VPN Gateway-Verbindungen finden Sie unter Informationen zu VPN Gateway.

Was ist der Unterschied zwischen einer Standort-zu-Standort- und einer Punkt-zu-Standort-Verbindung?

Site-to-Site-Konfigurationen (IPsec/IKE-VPN-Tunnel) betreffen Verbindungen zwischen Ihrem lokalen Standort und Azure. Dies bedeutet, dass Sie eine Verbindung zwischen einem beliebigen lokalen Computer und einem beliebigen virtuellen Computer oder einer Rolleninstanz in Ihrem virtuellen Netzwerk herstellen können (abhängig von der Routingkonfiguration und den Berechtigungen). 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 am Rand des Netzwerks bereitgestellt werden muss. 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 Bestandteil der Punkt-zu-Standort-Konfiguration installieren Sie ein Zertifikat und ein VPN-Clientkonfigurationspaket, das die Einstellungen enthält, die es Ihrem Computer ermöglichen, Verbindungen mit virtuellen Computern oder Rolleninstanzen innerhalb des virtuellen Netzwerks herzustellen. Dieser Verbindungstyp 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.

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 Powershell oder die CLI verwenden, um die richtlinienbasierten Gateways zu erstellen.

Zuvor hatten die älteren Gateway-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. Wenn Sie den Gatewaytyp ändern möchten, müssen Sie das Gateway löschen und neu erstellen. 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 Tutorial: Erstellen einer Site-to-Site-Verbindung im Azure-Portal.

Kann ich meine eigenen richtlinienbasierten Datenverkehrsselektoren angeben?

Ja. Datenverkehrsselektoren können mithilfe des PowerShell-Befehls New-AzIpsecTrafficSelectorPolicy über das Attribut trafficSelectorPolicies für eine Verbindung definiert werden. Achten Sie darauf, dass die Option Use policy based traffic selectors (Richtlinienbasierte Datenverkehrsselektoren verwenden) aktiviert ist, damit der angegebene Datenverkehrsselektor wirksam wird.

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

Benötige ich ein Gatewaysubnetz?

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 Gatewaysubnetze müssen den Namen „GatewaySubnet“ besitzen, 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 Gatewaysubnetz ü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 Gatewaysubnetz mit einer Größe von nur /29 erstellen, aber es empfiehlt sich, ein Gatewaysubnetz mit einer Größe von mindestens /27 (/27, /26, /25 usw.) zu erstellen. Sehen Sie sich die Anforderungen für die Konfiguration an, die Sie erstellen möchten, und vergewissern Sie sich, dass Ihr Gatewaysubnetz diese Anforderungen erfüllt.

Kann ich virtuelle Computer oder Rolleninstanzen in meinem Gatewaysubnetz 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. Daher erhalten Sie 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. Dies gilt für alle Gateway-SKUs mit Ausnahme der Standard-SKU. Die Basic-Gateway-SKU unterstützt derzeit nur öffentliche Basic-SKU-IP-Adressen. Wir werden in Kürze die Unterstützung von öffentlichen Basic-SKU-IP-Adressen für Basic-Gateway-SKUs hinzufügen.

Bei nicht zonenredundanten und nicht zonalen Gateways, die zuvor erstellt wurden (Gateway-SKUs, die nicht über AZ im Namen verfügen), 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 des VPN-Gateways ä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 Basic-SKU für öffentliche IP-Adressen auf meine VPN-Gateways aus?

Wir ergreifen Maßnahmen, um den weiteren Betrieb von bereitgestellten VPN-Gateways zu gewährleisten, die öffentliche IP-Adressen der Basic-SKU verwenden. Wenn Sie bereits über VPN-Gateways mit öffentlichen IP-Adressen der Basic-SKU verfügen, müssen Sie keine Maßnahmen ergreifen.

Es ist jedoch wichtig zu beachten, dass öffentliche SKU-Standard-IP-Adressen auslaufen. In Zukunft müssen Sie beim Erstellen eines neuen VPN-Gateways die öffentliche IP-Adresse der Standard-SKU verwenden. Weitere Details zur Einstellung der öffentlichen IP-Adressen der Basic-SKU finden Sie hier.

Wie wird mein VPN-Tunnel authentifiziert?

Beim Azure-VPN erfolgt die Authentifizierung mittels vorinstalliertem Schlüssel (Pre-Shared Key, PSK). Der vorinstallierte Schlüssel wird bei der Erstellung des VPN-Tunnels generiert. Der automatisch generierte PSK kann mit dem PowerShell-Cmdlet „Set Pre-Shared Key“ oder der REST-API angepasst werden.

Kann ich mit der API „Set Pre-Shared Key“ mein richtlinienbasiertes VPN mit statischem Routing-Gateway konfigurieren?

Ja. Mit der API „Set Pre-Shared Key“ und dem PowerShell-Cmdlet können Sie sowohl richtlinienbasierte (statische) Azure-VPNs als auch routenbasierte (dynamische) VPNs konfigurieren.

Kann ich andere Authentifizierungsoptionen verwenden?

Für die Authentifizierung können nur vorinstallierte Schlüssel (Pre-Shared Keys, PSKs) verwendet werden.

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

Ressourcen-Manager-Bereitstellungsmodell

  • PowerShell: Verwenden Sie „AddressPrefix“, um Datenverkehr für das lokale Netzwerkgateway anzugeben.
  • Azure-Portal: Navigieren Sie zum lokalen Netzwerkgateway > Konfiguration > Adressraum.

Klassisches Bereitstellungsmodell

  • Azure-Portal: Navigieren Sie zum klassischen virtuellen Netzwerk > VPN-Verbindungen > Standort-zu-Standort-VPN-Verbindungen > Name des lokalen Standorts > Lokaler Standort > Clientadressraum.

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

Ja, NAT 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 bei 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 (entweder ü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. Sie werden von Azure-Zertifikaten geschützt (gesperrt). Ohne die richtigen Zertifikate werden externe Entitäten, einschließlich der Kunden dieser Gateways, sich nicht auf diese Endpunkte auswirken.

Ein Gateway für virtuelle Netzwerke ist im Grunde ein mehrfach vernetztes Gerät mit einem Netzwerkadapter, der das private Netzwerk des Kunden nutzt, und einem Netzwerkadapter für das öffentliche Netzwerk. Azure-Infrastrukturentitäten können aus Compliance-Gründen keine privaten Netzwerke von Kunden 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 Gateway-SKU „Basic“ im Portal erstellen?

Nein. Die Basic-SKU ist im Portal nicht verfügbar. Sie können über die Azure CLI oder mithilfe von PowerShell ein VPN-Gateway mit Basic-SKU erstellen.

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

Weitere Informationen finden Sie in folgenden Artikeln:

SKU-Einstellung von Legacy-SKUs

Die Standard- und High Performance-SKUs werden am 30. September 2025 eingestellt. Sie können sich die Ankündigung hier 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 neue Standard-/Hochleistungs-SKUs erstellen?

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

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

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

Muss ich jetzt meine Gateways mit Standard-/Hochleistungs-SKUs migrieren?

Nein, im Moment ist keine Aktion erforderlich. Sie können Ihre SKUs 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 > VpnGw1
  • Hochleistung > VpnGw2

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

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

  • Standard > VpnGw1AZ
  • Hochleistung > 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. Auf der Preisseite finden Sie die Preise für AZ-SKUs. 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 die 6,5-fache und VpnGw2 bei 1 GBit/s die 5-fache Leistung zum gleichen Preis wie die älteren Standard- bzw. Hochleistungsgateways. Weitere Informationen zum SKU-Durchsatz finden Sie unter Informationen zu Gateway-SKUs.

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

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

  • Standard > VpnGw1AZ
  • Hochleistung > VpnGw2AZ

Sie werden benachrichtigt, bevor die Migration auf Ihren Gateways initiiert wird.

Wird die VPN Gateway Basic SKU ebenfalls eingestellt?

Nein, die VPN-Gateway Basic-SKU ist hier, um zu bleiben. Sie können ein VPN-Gateway mithilfe der Standardgateway-SKU über PowerShell oder CLI erstellen. Derzeit unterstützen VPN Gateway Basic-Gateway-SKUs nur die öffentliche IP-Adressressource "Basic SKU" (die sich auf einem Pfad zur Einstellung befindet). Wir arbeiten daran, unterstützung zur SKU des VPN-Gateways Basic für die öffentliche IP-Adressressource der Standard-SKU hinzuzufügen.

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. Eine Liste mit kompatiblen VPN-Geräten, entsprechenden Konfigurationsanweisungen oder -beispielen und Gerätespezifikationen finden Sie 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?

So laden Sie VPN-Gerätekonfigurationsskripts herunter:

Abhängig von Ihrem VPN-Gerät können Sie ggf. ein VPN-Gerätekonfigurationsskript herunterladen. Weitere Informationen finden Sie unter Herunterladen von VPN-Gerätekonfigurationsskripts für S2S-VPN-Verbindungen.

Weitere Informationen zur Konfiguration finden Sie unter den folgenden Links:

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

Informationen zur Bearbeitung von Gerätekonfigurationsbeispielen finden Sie unter Bearbeiten von Gerätekonfigurationsbeispielen.

Wo finde ich IPsec- und IKE-Parameter?

Informationen zu IPsec/IKE-Parametern finden Sie unter Parameter.

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

Dabei handelt es sich um einen Standardvorgang bei richtlinienbasierten (auch als „statisches Routing“ bezeichnet) VPN-Gateways. Wenn im Tunnel länger als 5 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ützten Windows Server 2012 RRAS-Server (Routing und RAS) für eine standortübergreifende Standort-zu-Standort-Konfiguration.

Auch andere VPN-Softwarelösungen können mit unserem 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 derselben/denselben öffentlichen IP-Adresse(n) initiiert werden, für die eine Site-to-Site-VPN-Verbindung auf demselben Azure VPN Gateway konfiguriert ist.

Point-to-Site – Zertifikatauthentifizierung

Dieser Abschnitt gilt für das Ressourcen-Manager-Bereitstellungsmodell.

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 unter Verwendung der Punkt-zu-Standort-Funktion durchquert werden?

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

  • Secure Sockets Tunneling Protocol (SSTP). SSTP ist 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. OpenVPN ist eine SSL-basierte Lösung, die Firewalls durchdringen kann, weil die meisten Firewalls den von SSL verwendeten ausgehenden TCP-Port 443 öffnen.

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

Wird das VPN automatisch erneut verbunden, wenn ich einen für Punkt-zu-Standort-Verbindungen konfigurierten Clientcomputer neu starte?

Die automatische Wiederverbindung ist eine Funktion des verwendeten Clients. Windows unterstützt die automatische Wiederverbindung durch Konfiguration der Client-Funktion Always On-VPN.

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

DDNS wird derzeit in Point-to-Site-VPNs nicht unterstützt.

Kann ich im gleichen virtuellen Netzwerk sowohl Site-to-Site- als auch Point-to-Site-Konfigurationen verwenden?

Ja. Beim Resource Manager-Bereitstellungsmodell müssen Sie als VPN-Typ für Ihr Gateway „RouteBased“ 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?

Abhängig von der verwendeten VPN-Clientsoftware kannst Du unter Umständen eine Verbindung mit mehreren Gateways für virtuelle Netzwerke herstellen. Voraussetzung dafür ist, dass für die virtuellen Netzwerke, mit denen eine Verbindung hergestellt wird, keine Adressräume vorliegen, die miteinander oder mit dem Netzwerk in Konflikt stehen, aus dem der Client eine Verbindung herstellt. Azure VPN Client unterstützt zwar viele VPN-Verbindungen, es kann jedoch immer nur eine Verbindung aktiv sein.

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

Ja. Point-to-Site-Clientverbindungen mit einem Gateway für virtuelle Netzwerke, das in einem VNet bereitgestellt wird, für das ein Peering mit anderen VNets besteht, haben unter Umständen Zugriff auf andere per Peering verknüpfte VNets. Point-to-Site-Clients können eine Verbindung mit VNets herstellen, die per Peering verknüpft sind, solange diese VNets die Features „UseRemoteGateway“ oder „AllowGatewayTransit“ verwenden. Weitere Informationen hierzu findest Du unter Informationen zu Point-to-Site-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. Außerdem wird der Durchsatz durch die Latenz und die Bandbreite zwischen Ihrem Standort und dem Internet eingeschränkt. 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- und/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. Navigieren Sie im Portal zur Seite VPN-Gateway -> Point-to-Site-Konfiguration. Wähle unter Authentifizierungstyp die Authentifizierungstypen aus, die Du verwenden möchtest. Beachte, dass aktuelle Clients nach einer Änderung an einem Authentifizierungstyp möglicherweise erst dann eine Verbindung herstellen können, wenn ein neues VPN-Clientkonfigurationsprofil generiert, heruntergeladen und auf jeden VPN-Client angewendet wurde.

Unterstützt Azure IKEv2-VPN unter Windows?

IKEv2 wird unter Windows 10 und 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 OpenVPN® Protocol 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 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 REG_DWORD-Schlüssel „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload“, oder legen Sie ihn in der Registrierung 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. Frühere 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-zu-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.

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

Wenn Du sowohl SSTP als auch IKEv2 in einer gemischten Umgebung (bestehend aus Windows- und Mac-Geräten) konfigurierst, versucht der Windows-VPN-Client immer zuerst den IKEv2-Tunnel, weicht jedoch auf SSTP aus, wenn die IKEv2-Verbindung nicht erfolgreich ist. MacOSX stellt nur eine Verbindung über IKEv2 her.

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. Beachten Sie, dass die maximale Anzahl von SSTP-Clients immer 128 beträgt, auch wenn der Adressbereich größer als /24 ist, was zu einer größeren Anzahl von Adressen führt, 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 für den Point-to-Site-Adressbereich, sondern die beiden Unterbereichs-CIDRs.

Welche anderen Plattformen, außer Windows und Mac, werden von Azure für P2S-VPN unterstützt?

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

Ich verfüge bereits über ein bereitgestelltes Azure-VPN-Gateway. Kann ich RADIUS und/oder IKEv2-VPN darauf aktivieren?

Ja, wenn die von Dir verwendete Gateway-SKU RADIUS und/oder IKEv2 unterstützt, kannst Du diese Features auf Gateways, die Du bereits bereitgestellt hast, mithilfe von PowerShell oder dem Azure-Portal aktivieren. Die Basic-SKU unterstützt weder RADIUS noch IKEv2.

Wie entferne ich die Konfiguration einer P2S-Verbindung?

Eine P2S-Konfiguration kann über die Azure CLI und PowerShell mit folgenden Befehlen entfernt werden:

Azure PowerShell

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

Azure CLI

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

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

Deaktivieren Sie „Identität des Servers durch Validierung des Zertifikat überprüfen“, oder fügen Sie den Server-FQDN 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 EAP-Protokoll das gleiche Zertifikat verwendet. Da das Serverzertifikat und der FQDN bereits vom VPN-Tunnelingprotokoll validiert wurden, ist es redundant, das gleiche in EAP erneut zu validieren.

Point-to-Site-Authentifizierung

Kann ich meine eigene interne PKI-Stammzertifizierungsstelle verwenden, um Zertifikate für Punkt-zu-Standort-Verbindungen zu generieren?

Ja. Bisher konnten nur selbstsignierte Stammzertifikate verwendet werden. 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-PKI-Lösung (interne PKI), Azure PowerShell, MakeCert und OpenSSL verwenden.

Gibt es Anleitungen für Zertifikateinstellungen und -parameter?

  • Interne PKI/Unternehmens-PKI-Lösung: Sehen Sie sich die Schritte zum Generieren von Zertifikaten an.

  • Azure PowerShell: Entsprechende Schritte finden Sie im Artikel zu Azure PowerShell.

  • MakeCert: Die erforderlichen Schritte finden Sie im Artikel zu MakeCert.

  • OpenSSL:

    • Stellen Sie beim Exportieren von Zertifikaten sicher, dass das Stammzertifikat in Base64 konvertiert wird.

    • Clientzertifikat:

      • Geben Sie beim Erstellen des privaten Schlüssels als Länge 4096 an.
      • Geben Sie beim Erstellen des Zertifikats für den -extensions-Parameter usr_cert an.

Point-to-Site – RADIUS-Authentifizierung

Dieser Abschnitt gilt für das Ressourcen-Manager-Bereitstellungsmodell.

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 unter Verwendung der Punkt-zu-Standort-Funktion durchquert werden?

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

  • Secure Sockets Tunneling Protocol (SSTP). SSTP ist 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. OpenVPN ist eine SSL-basierte Lösung, die Firewalls durchdringen kann, weil die meisten Firewalls den von SSL verwendeten ausgehenden TCP-Port 443 öffnen.

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

Wird das VPN automatisch erneut verbunden, wenn ich einen für Punkt-zu-Standort-Verbindungen konfigurierten Clientcomputer neu starte?

Die automatische Wiederverbindung ist eine Funktion des verwendeten Clients. Windows unterstützt die automatische Wiederverbindung durch Konfiguration der Client-Funktion Always On-VPN.

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

DDNS wird derzeit in Point-to-Site-VPNs nicht unterstützt.

Kann ich im gleichen virtuellen Netzwerk sowohl Site-to-Site- als auch Point-to-Site-Konfigurationen verwenden?

Ja. Beim Resource Manager-Bereitstellungsmodell müssen Sie als VPN-Typ für Ihr Gateway „RouteBased“ 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?

Abhängig von der verwendeten VPN-Clientsoftware kannst Du unter Umständen eine Verbindung mit mehreren Gateways für virtuelle Netzwerke herstellen. Voraussetzung dafür ist, dass für die virtuellen Netzwerke, mit denen eine Verbindung hergestellt wird, keine Adressräume vorliegen, die miteinander oder mit dem Netzwerk in Konflikt stehen, aus dem der Client eine Verbindung herstellt. Azure VPN Client unterstützt zwar viele VPN-Verbindungen, es kann jedoch immer nur eine Verbindung aktiv sein.

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

Ja. Point-to-Site-Clientverbindungen mit einem Gateway für virtuelle Netzwerke, das in einem VNet bereitgestellt wird, für das ein Peering mit anderen VNets besteht, haben unter Umständen Zugriff auf andere per Peering verknüpfte VNets. Point-to-Site-Clients können eine Verbindung mit VNets herstellen, die per Peering verknüpft sind, solange diese VNets die Features „UseRemoteGateway“ oder „AllowGatewayTransit“ verwenden. Weitere Informationen hierzu findest Du unter Informationen zu Point-to-Site-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. Außerdem wird der Durchsatz durch die Latenz und die Bandbreite zwischen Ihrem Standort und dem Internet eingeschränkt. 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- und/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. Navigieren Sie im Portal zur Seite VPN-Gateway -> Point-to-Site-Konfiguration. Wähle unter Authentifizierungstyp die Authentifizierungstypen aus, die Du verwenden möchtest. Beachte, dass aktuelle Clients nach einer Änderung an einem Authentifizierungstyp möglicherweise erst dann eine Verbindung herstellen können, wenn ein neues VPN-Clientkonfigurationsprofil generiert, heruntergeladen und auf jeden VPN-Client angewendet wurde.

Unterstützt Azure IKEv2-VPN unter Windows?

IKEv2 wird unter Windows 10 und 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 OpenVPN® Protocol 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 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 REG_DWORD-Schlüssel „HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\ IKEv2\DisableCertReqPayload“, oder legen Sie ihn in der Registrierung 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. Frühere 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-zu-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.

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

Wenn Du sowohl SSTP als auch IKEv2 in einer gemischten Umgebung (bestehend aus Windows- und Mac-Geräten) konfigurierst, versucht der Windows-VPN-Client immer zuerst den IKEv2-Tunnel, weicht jedoch auf SSTP aus, wenn die IKEv2-Verbindung nicht erfolgreich ist. MacOSX stellt nur eine Verbindung über IKEv2 her.

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. Beachten Sie, dass die maximale Anzahl von SSTP-Clients immer 128 beträgt, auch wenn der Adressbereich größer als /24 ist, was zu einer größeren Anzahl von Adressen führt, 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 für den Point-to-Site-Adressbereich, sondern die beiden Unterbereichs-CIDRs.

Welche anderen Plattformen, außer Windows und Mac, werden von Azure für P2S-VPN unterstützt?

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

Ich verfüge bereits über ein bereitgestelltes Azure-VPN-Gateway. Kann ich RADIUS und/oder IKEv2-VPN darauf aktivieren?

Ja, wenn die von Dir verwendete Gateway-SKU RADIUS und/oder IKEv2 unterstützt, kannst Du diese Features auf Gateways, die Du bereits bereitgestellt hast, mithilfe von PowerShell oder dem Azure-Portal aktivieren. Die Basic-SKU unterstützt weder RADIUS noch IKEv2.

Wie entferne ich die Konfiguration einer P2S-Verbindung?

Eine P2S-Konfiguration kann über die Azure CLI und PowerShell mit folgenden Befehlen entfernt werden:

Azure PowerShell

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

Azure CLI

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

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 High Performance SKUs unterstützt. In der Basic-Gateway-SKU wird sie nicht unterstützt.

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

Nein. Die RADIUS-Authentifizierung wird für das klassische Bereitstellungsmodell nicht unterstützt.

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, RADIUS-Server von Drittanbietern werden unterstützt.

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

Es ist eine Site-to-Site-VPN-Verbindung mit dem Standort vor Ort erforderlich. (Dabei müssen die korrekten Routen konfiguriert sein.)

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

Nein. Kann nur über eine S2S-Verbindung weitergeleitet werden.

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

Die maximale Anzahl von SSTP-Verbindungen, die für ein Gateway mit RADIUS-Authentifizierung unterstützt werden, 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 Gateway-SKUs.

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

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

Bei Verwendung von Azure für die Zertifikatauthentifizierung führt das Azure-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.

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 häufig gestellten Fragen zu VNET-zu-VNET-Verbindungen 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 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 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-zu-VNET-Verbindungen mit Azure-VPN-Gateways können übergreifend für Microsoft Entra-Mandanten verwendet werden.

Ist VNet-zu-VNet-Datenverkehr sicher?

Ja, er wird mittels IPsec-/IKE-Verschlüsselung geschützt.

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 standortübergreifende Konnektivität erforderlich ist.

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 Active Directory-Mandanten zugeordnet sein, wenn sich die 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 globalen Azure-Instanzen 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. Virtuelle Netzwerkverbindungen können simultan mit VPNs mit mehreren Standorten verwendet werden.

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-zu-VNet für die Verbindung von virtuellen Computern 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 VPN-Typ „PolicyBased“ für VNET-zu-VNET- oder standortübergreifende Verbindungen verwenden?

Nein. VNET-zu-VNET- und standortübergreifende Verbindungen erfordern Azure-VPN Gateways mit routenbasierten VPN-Typen (zuvor als „dynamisches Routing“ bezeichnet).

Kann ich ein VNet mit einem routenbasierten VPN-Typ (RouteBased) mit einem anderen VNet mit einem richtlinienbasierten VPN (PolicyBased) 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 Azure-VPN-Gateway und die 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 Standort-zu-Standort-VPN-Verbindung und meinem ExpressRoute?

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

Kann ich mit dem Azure-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.

Klassisches Bereitstellungsmodell
Datenverkehr kann bei Verwendung des klassischen Bereitstellungsmodells über das Azure-VPN-Gateway übertragen werden, die Übertragung basiert jedoch auf statisch definierten Adressräumen aus der Netzwerkkonfigurationsdatei. BGP wird noch nicht für virtuelle Azure-Netzwerke und VPN-Gateways unterstützt, wenn das klassische Bereitstellungsmodell verwendet wird. Ohne BGP müssen die Adressräume für die Übertragung manuell definiert werden. Dies ist jedoch sehr 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 Punkt-zu-Standort-VPNs) verwenden das gleiche Azure-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 AS-Pfad 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, diese Einstellung ist für ExpressRoute-Gatewayverbindungen reserviert. Wenn Sie Routingentscheidungen zwischen mehreren Verbindungen beeinflussen möchten, müssen Sie AS PATH voranstellen.

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

Ja. VPNs vom Typ „Punkt zu Standort“ (P2S) können mit den VPN Gateways kombiniert werden, 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 gleichzeitig vorhandenen ExpressRoute- und Standort-zu-Standort-VPN-Verbindungen.

IPsec-/IKE-Richtlinie

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

Eine benutzerdefinierte IPsec-/IKE-Richtlinie wird auf allen Azure-SKUs außer der SKU „Basic“ unterstützt.

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

Pro Verbindung kann jeweils nur eine Richtlinienkombination angegeben werden.

Kann ich eine partielle Richtlinie für eine Verbindung angeben? (Beispielsweise nur IKE-Algorithmen, aber kein 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
QM-SA-Gültigkeitsdauer (Optional: Wenn kein Wert angegeben wird, werden die Standardwerte verwendet)
Sekunden (ganze Zahl; min. 300/Standard: 27.000 Sekunden)
KB (ganze Zahl; min. 1024/Standard: 102.400.000 KB)
Datenverkehrsselektor UsePolicyBasedTrafficSelectors** ($True/$False; Optional, default $False if not specified)
DPD-Timeout Sekunden (Integer: min. 9, max. 3.600, Standard: 45 s)

  • Ihre lokale VPN-Gerätekonfiguration muss folgenden Algorithmus- und Parameterangaben für die Azure-IPsec-/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)
    • Datenverkehrsselektor (bei Verwendung von „UsePolicyBasedTrafficSelectors“)
    • Bei der SA-Lebensdauer handelt es sich lediglich um eine lokale Angabe, die nicht übereinstimmen muss.

  • Wenn GCMAES als IPsec-Verschlüsselungsalgorithmus verwendet wird, müssen Sie für die IPsec-Integrität denselben GCMAES-Algorithmus und dieselbe Schlüssellänge auswählen, z. B. „GCMAES128“ für beides.

  • In der Tabelle Algorithmen und Schlüssel oben gilt:

    • 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.

  • „UsePolicyBasedTrafficSelector“ ist ein optionaler Parameter für die Verbindung. Wenn UsePolicyBasedTrafficSelectors für eine Verbindung auf „$True“ festgelegt wird, wird das Azure-VPN-Gateway für eine Verbindung mit einer richtlinienbasierten lokalen VPN-Firewall konfiguriert. Wenn Sie „PolicyBasedTrafficSelectors“ aktivieren, müssen 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 sein (anstelle von Any-to-Any). Das Azure VPN-Gateway akzeptiert unabhängig davon, welche Datenverkehrsauswahl vom Remote-VPN-Gateway vorgeschlagen wird, unabhängig davon, was auf dem Azure VPN-Gateway konfiguriert ist.

    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 Azure-VPN-Gateways und mehreren lokalen richtlinienbasierten VPN-Geräten mit PowerShell.

  • DPD-Timeout: Der Standardwert beträgt für Azure-VPN-Gateways 45 Sekunden. Wenn das Timeout auf kürzere Zeiträume festgelegt wird, erstellt IKE aggressiver neue Schlüssel, sodass die Verbindung in einigen Fällen getrennt erscheint. Dies 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. Die allgemeine Empfehlung besteht darin, das Timeout auf einen Wert zwischen 30 und 45 Sekunden festzulegen.

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

Welche Diffie-Hellman-Gruppen werden unterstützt?

In der folgende Tabelle sind die entsprechenden Diffie-Hellman-Gruppen aufgeführt, 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

Ausführlichere Informationen finden Sie unter RFC3526 und RFC5114.

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

Ja. Wenn eine benutzerdefinierte Richtlinie für eine Verbindung angegeben wird, verwendet das 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. Die Verbindung ist weiterhin durch IPsec/IKE geschützt. Wenn Sie die benutzerdefinierte Richtlinie für eine Verbindung entfernen, verwendet das Azure-VPN-Gateway wieder die Standardliste mit IPsec-/IKE-Vorschlägen und startet erneut den IKE-Handshake mit Ihrem lokalen VPN-Gerät.

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 Azure-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. Benutzerdefinierte Richtlinien sind 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 die benutzerdefinierte Richtlinie auch für VNET-zu-VNET-Verbindungen verwenden?

Ja. Sie können benutzerdefinierte Richtlinien sowohl für standortübergreifende IPsec-Verbindungen als auch für VNET-zu-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). Damit die VNET-zu-VNET-Verbindung hergestellt werden kann, müssen beide Verbindungsressourcen über die gleiche Richtlinie verfügen.

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

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

Hinweis

Der Standardwert beträgt für Azure-VPN-Gateways 45 Sekunden. Wenn das Timeout auf kürzere Zeiträume festgelegt wird, erstellt IKE aggressiver neue Schlüssel, sodass die Verbindung in einigen Fällen getrennt erscheint. Dies 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, das Timeout auf einen Wert zwischen 30 und 45 Sekunden festzulegen.

Können benutzerdefinierte IPsec-/IKE-Richtlinien für ExpressRoute-Verbindungen verwendet werden?

Nein. IPsec-/IKE-Richtlinien können nur für S2S-VPN- und VNET-zu-VNET-Verbindungen über Azure-VPN-Gateways verwendet werden.

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

IKEv1-Verbindungen können für alle SKUs vom Typ „RouteBased VPN“, mit Ausnahme der SKU „Basic“, „Standard“ und anderen Legacy-SKUs erstellt werden. 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 PowerShell-Cmdlet. Informationen zu den SKU-Typen und zur IKEv1/IKEv2-Unterstützung finden Sie unter Herstellen einer Verbindung zwischen Azure-VPN-Gateways und mehreren lokalen richtlinienbasierten VPN-Geräten mit PowerShell.

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

Ja. Die Übertragung zwischen IKEv1- und IKEv2-Verbindungen wird unterstützt.

Kann ich IKEv1-Site-to-Site-Verbindungen für Basic-SKUs mit dem Typ „RouteBased VPN“ verwenden?

Nein. Die Basic-SKU unterstützt dies nicht.

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

Nein. Nachdem die Verbindung erstellt wurde, können die IKEv1/IKEv2-Protokolle nicht mehr geändert werden. Sie müssen einen Löschvorgang durchführen und eine neue Verbindung mit dem gewünschten Protokolltyp erstellen.

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

Wenn Ihre statische Routing- oder routenbasierte IKEv1-Verbindung in regelmäßigen Abständen unterbrochen wird, liegt dies wahrscheinlich daran, dass 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 Konfigurationsinformationen und -schritte?

Weitere Informationen und Konfigurationsschritte finden Sie in den folgenden Artikeln.

BGP und Routing

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

BGP wird mit Ausnahme der SKU „Basic“ 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 autonomen Systemnummern (ASNs) kann ich verwenden?

Sie können eigene öffentliche ASNs oder private ASNs sowohl für Ihre lokalen Netzwerke als auch für Ihre virtuellen Azure-Netzwerke verwenden. Die von Azure oder IANA reservierten Bereiche können nicht verwendet werden.

Die folgenden ASNs sind für Azure oder IANA reserviert:

  • 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 und 429496729

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

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

Ja, VPN Gateway unterstützt nun 32-Bit-ASNs (4 Bytes). Verwenden Sie zum Konfigurieren mithilfe von ASNs im Dezimalformat 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

Diese ASNs sind nicht für die Verwendung durch IANA oder Azure reserviert und können daher Ihrem Azure-VPN-Gateway zugewiesen werden.

Welche Adresse verwendet VPN Gateway als BGP-Peer-IP-Adresse?

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. Die tatsächlich zugeordnete BGP-IP-Adresse kann mithilfe von PowerShell oder über das Azure-Portal ermittelt werden. 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 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 Azure-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 für Azure-VPN-Gateways.

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

Ihre lokale BGP-Peeradresse 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 Azure-VPN-Gateway angeben, wie unter BGP konfigurieren beschrieben. Geben Sie diese Adressen im entsprechenden Gateway des lokalen Netzwerks an, das den Speicherort 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. Wenn Sie BGP für eine Verbindung verwenden, lassen Sie das Feld Adressraum für die zugehörige lokale Netzwerkgatewayressource leer. 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. Sie ist redundant und 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. Lokalen Netzwerken und virtuellen Azure-Netzwerken muss jeweils eine andere ASN zugewiesen werden, 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 Adresspräfixe des virtuellen Netzwerks
  • Adresspräfixe für die einzelnen lokalen Netzwerkgateways, die mit dem Azure-VPN-Gateway verbunden sind
  • Routen, die in anderen, mit dem Azure-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 Azure VPN Gateways ankündigen?

Ja. Beachten Sie, dass dadurch der gesamte ausgehende Datenverkehr des virtuellen Netzwerks zwangsweise an den lokalen Standort geleitet wird. Außerdem wird verhindert, dass die VMs des virtuellen Netzwerks die öffentliche Kommunikation aus dem Internet direkt akzeptieren, etwa RDP oder SSH aus dem Internet an die VMs.

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

Nein. Das Ankündigen der gleichen Präfixe wie Ihre Adresspräfixe des virtuellen Netzwerks wird von Azure blockiert oder gefiltert. 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. BGP kann sowohl für standortübergreifende Verbindungen als auch für Verbindungen zwischen virtuellen Netzwerken verwendet werden.

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: Azure-VPN-Gateways kündigen gegenüber anderen BGP-Peers keine Standardrouten an. Wenn Sie Transitrouting über mehrere Azure-VPN-Gateways hinweg nutzen möchten, müssen Sie BGP für alle Zwischenverbindungen für virtuelle Netzwerke aktivieren. Weitere Informationen finden Sie in der Übersicht über BGP.

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

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

Wenn also etwa zwischen Ihrem Azure-VPN-Gateway und einem Ihrer lokalen Netzwerke zwei redundante Tunnel bestehen, werden dadurch zwei Tunnel des Gesamtkontingents für Ihr Azure-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 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-Keepalives. 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. Dies hätte unter Umständen eine Dämpfung von Routen durch BGP zur Folge. Alternativ können Sie Ihr lokales Gerät mit Zeitgebern konfigurieren, die niedriger sind als das standardmäßige Keepalive-Intervall von 60 Sekunden und der Hold-Zeitgeber von 180 Sekunden. Damit 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. Es wird empfohlen, die Standardwerte für Timer einzuhalten oder zu überschreiten.

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

Das Gateway 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. Dies 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 bei „VpnGw2~5“ und „VpnGw2AZ~5AZ“ 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 Arten von NAT werden von Azure-VPN-Gateways unterstützt?

Nur statisches 1:1-NAT und dynamisches NAT werden unterstützt. 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. Sie müssen sicherstellen, dass die lokalen BGP-Router 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 virtuellen Netzwerkadressraum oder anderen lokalen Netzwerkräumen kollidiert, stellen Sie sicher, dass die IngressSNAT-Regel die BGP-Peer-IP in eine eindeutige, nicht überlappende Adresse übersetzt und die Post-NAT-Adresse im Feld BGP-Peer-IP-Adresse des lokalen Netzwerkgateways ablegt.

  • 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 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 Azure-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 virtuellen Netzwerks, die das Azure-VPN-Gateway verlassen und an die lokalen Netzwerke gehen. Außerdem wird die Übersetzung der Ziel-IP-Adressen für Pakete verarbeitet, die über diese Verbindungen mit der EgressSNAT-Regel beim virtuellen Netzwerk eingehen.

  • In beiden Fällen werden keine DNAT-Regeln benötigt.

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

Sie müssen für jedes Präfix, das Sie für NAT benötigen, 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 (siehe unten):

  • 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 virtuellen Netzwerkadressraum.

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 verschiedene lokale Netzwerke zu übersetzen?

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

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

Ja, dies wird in der Regel verwendet, wenn die Verbindungen für dasselbe lokale Netz 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 Ingress- als auch Egress-Regeln für dieselbe Verbindung, wenn sich der lokale Netzwerkadressraum mit dem virtuellen Netzwerkadressraum überschneidet. Wenn der virtuelle Netzwerkadressraum 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 IPconfiguration „default“ zugewiesen, und die sekundäre IP-Adresse wird der IPconfiguration „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?

Hier haben Sie mehrere Möglichkeiten: 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 Ihrem virtuellen Computer 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. Anderer Datenverkehr wird über den Load Balancer an die öffentlichen Netzwerke oder (bei erzwungener Tunnelung) über das Azure-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 mit der privaten IP-Adresse eine Verbindung mit der VM herstellen können, aber nicht mit dem Computernamen, sollten Sie sich vergewissern, dass das DNS richtig konfiguriert ist. Weitere Informationen zur Funktionsweise der Namensauflösung für virtuelle Computer finden Sie unter Namensauflösung für virtuelle Computer.

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 von „VPNClientAddressPool“ liegt, wird dies als sich überschneidender Adressraum bezeichnet. Falls sich Ihr Adressraum auf diese Weise überschneidet, kommt der Netzwerkdatenverkehr nicht bei Azure an, sondern verbleibt im lokalen Netzwerk.
  • Stellen Sie sicher, dass das VPN-Clientkonfigurationspaket generiert wurde, nachdem die IP-Adressen des DNS-Servers für das virtuelle Netzwerk angegeben wurden. 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 im Bereich der Wartungskonfiguration von Netzwerkgateways enthalten?

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

  • Gateway für virtuelle Netzwerke im ExpressRoute-Dienst.
  • Gateway für virtuelle Netzwerke im VPN Gateway-Dienst.
  • VPN-Gateway (Site-to-Site) im Virtual WAN-Dienst.
  • ExpressRoute-Gateway im Virtual WAN-Dienst.

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. Hostupdates, über die Hostupdates (TOR, Leistung usw.) hinausgehende Updates und kritische Sicherheitsupdates werden nicht von der kundenseitig gesteuerten Wartung abgedeckt.

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

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

Gibt es Fälle, in denen bestimmte Updates nicht gesteuert werden können?

Die kundenseitig gesteuerte Wartung unterstützt Gastbetriebssystem- und Dienstupdates. Diese Updates berücksichtigen die meisten Wartungselemente, die für die Kund*innen problematisch sind. Einige andere Updatetypen (einschließlich Hostupdates) sind nicht in der kundenseitig gesteuerten Wartung enthalten.

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 pushen muss. Dies kommt äußerst selten und nur in extremen Fällen vor.

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

Ja

Welche Gateway-SKUs können zur Verwendung der kundenseitig gesteuerten Wartung konfiguriert werden?

Alle Gateway-SKUs (mit Ausnahme der Basic-SKU für VPN Gateway) können zur Verwendung der kundenseitig gesteuerten Wartung konfiguriert werden.

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.

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

Ja. Für Gatewayressourcen, die eine öffentliche IP-Adresse einer Basic-SKU verwenden, sind Dienstupdates nur nach dem kundenseitig gesteuerten Wartungszeitplan möglich. Für diese Gateways folgt die Wartung des Gastbetriebssystems aufgrund von Infrastrukturbeschränkungen NICHT dem kundenseitig gesteuerten Wartungszeitplan.

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.

Wo finde ich weitere Informationen zur kundenseitig gesteuerten Gatewaywartung?

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

Nächste Schritte

„OpenVPN“ ist eine Marke von OpenVPN Inc.