Migrieren von VPN Gateways aus dem klassischen Modell zu Resource Manager

VPN-Gateways können jetzt aus dem klassischen Bereitstellungsmodell zum Resource Manager-Bereitstellungsmodell migriert werden. Weitere Informationen dazu finden Sie unter Azure Resource Manager-Bereitstellungsmodell. In diesem Artikel wird erklärt, wie man von klassischen Bereitstellungen zum Resource Manager-Modell migriert.

VPN Gateways beginnen mit einer VNet-Migration vom klassischen Modell zu Resource Manager. Diese Migration erfolgt nacheinander für einzelne VNets durch den Kunden. Es gibt keine zusätzlichen Anforderungen in Bezug auf Tools oder Voraussetzungen für den Beginn der VNet-Migration. Die Migrationsschritte sind mit denen der Migration von VNets identisch, und sind auf der Seite Migrieren von IaaS-Ressourcen aufgeführt.

Es gibt keine Downtime von Datenpfaden während der VNet-Migration. Aus diesem Grund können bestehende Workloads während der Migration ohne Verlust der lokalen Konnektivität weiterhin ausgeführt werden. Die dem VPN-Gateway zugeordnete öffentliche IP-Adresse verändert sich während des Migrationsvorgangs nicht. Das bedeutet, dass Sie Ihren lokalen Router nicht neu konfigurieren müssen, wenn die Migration abgeschlossen ist.

Nach Abschluss der VNet-Migration versucht Azure, den Rest der Gateway-Migration zum Ressourcen-Manager abzuschließen. Wenn die Gateway-Migration nicht erfolgreich ist, werden Kunden möglicherweise informiert, ihr VPN Gateway (klassische Bereitstellung) zu löschen und ein neues VPN Gateway (Resource Manager) zu erstellen. Wenn vom Kunden keine Aktion ausgeführt wird, kann das vorhandene VPN Gateway (klassische Bereitstellung) außer Betrieb genommen werden. Kunden können sich die häufig gestellten Fragen für zusätzliche Informationen ansehen und Hilfe erhalten, wie Sie Ausfallzeiten während der Migration von der klassischen Bereitstellung zu Resource Manager minimieren.

Das Resource Manager-Modell unterscheidet sich vom klassischen Modell und besteht aus Gateways der virtuellen Netzwerke, Gateways des lokalen Netzwerks und Verbindungsressourcen. Diese stellen das VPN Gateway selbst dar, den lokalen Standort, der einen lokalen Adressraum und Konnektivität jeweils zwischen den beiden darstellt. Nach Abschluss der Migration sind Ihre Gateways im klassischen Modell nicht mehr verfügbar. Alle Verwaltungsvorgänge über Gateways der virtuellen Netzwerke und Verbindungsobjekte müssen nun im Resource Manager-Modell ausgeführt werden.

Ein klassisches VPN-Gateway finden

Um ein klassisches VPN-Gateway über PowerShell zu finden, müssen Sie das Azure PowerShell-Dienstverwaltungsmodul installieren. Beginnen Sie hier: Installieren des Azure PowerShell-Dienstverwaltungsmoduls. Um klassische Ressourcen anzuzeigen, benötigen Sie die Berechtigung als Co-Admin oder Eigentümer. Sie können keine Az-Cmdlets verwenden, um auf klassische Ressourcen zuzugreifen.

Um ein klassisches VPN-Gateway über das Azure-Portal zu finden, öffnen Sie das Portal und suchen Sie nach „Virtual network(classic)“. Wählen Sie Ihr klassisches virtuelles Netzwerk aus und navigieren Sie zum Gateway-Blatt, um Ihr Gateway für das klassische virtuelle Netzwerk zu finden.

Unterstützte Szenarios

Die meisten gängigen VPN-Konnektivitätsszenarios werden von der Migration vom klassischen zum Resource Manager-Modell unterstützt. Folgende Szenarien werden unterstützt:

• Point-to-Site-Konnektivität
• Site-to-Site-Konnektivität mit VPN-Gateway mit Verbindung zum lokalen Standort
• VNet-zu-VNet-Konnektivität zwischen zwei VNets mithilfe von VPN-Gateways
• Mehrere mit demselben lokalen Standort verbundene VNETs
• Konnektivität für mehrere Standorte
• Tunnelerzwingung für aktivierte VNets

Folgende Szenarien werden nicht unterstützt:

• Ein VNet mit sowohl einem ExpressRoute-Gateway als auch einem VPN-Gateway wird derzeit nicht unterstützt.
• Übertragungsszenarios in denen VM-Erweiterungen mit lokalen Servern verbunden sind. Einschränkungen zur Übertragung mit VPN-Konnektivität sind im nächsten Abschnitt aufgeführt.

Migration der VNet-zu-VNet-Konnektivität

VNet-zu-VNet-Konnektivität im klassischen Bereitstellungsmodell wurde durch das Erstellen eines lokalen Standorts als Darstellung des verbundenen VNets erreicht. Kunden mussten zwei lokale Standorte erstellen, die die beiden miteinander zu verbindenden VNets darstellten. Diese wurden dann mit den entsprechenden VNets mithilfe von IPsec-Tunneln verbunden, um eine Verbindung zwischen den beiden VNets herzustellen. Bei diesem Modell bestehen Herausforderungen mit der Verwaltbarkeit, da alle Änderungen im Adressbereich eines VNets auch in der zugehörigen Darstellung der lokalen Standorte durchgeführt werden müssen. Im Resource Manager-Modell ist diese Problemumgehung nicht länger notwendig. Die Verbindung zwischen den beiden VNets kann mithilfe des Verbindungstyps „Vnet2Vnet“ direkt in der Verbindungsressource hergestellt werden.

Während der VNet-Migration wird festgestellt, dass die mit dem VPN-Gateway des aktuellen VNet verbundene Einheit ein anderes VNet ist. Wir sorgen dafür, dass Sie nach Abschluss der Migration beider VNets nicht mehr zwei lokale Sites sehen, die die beiden VNets repräsentieren. Das klassische Modell mit zwei VPN Gateways, zwei lokalen Standorten und zwei Verbindungen zwischen diesen wird zum Resource Manager-Modell mit zwei VPN Gateways und zwei Verbindungen des Typs „Vnet2Vnet“ transformiert.

Übertragung mit VPN-Konnektivität

Sie können VPN Gateways in einer Topologie konfigurieren, damit die lokale Konnektivität für ein VNet durch Verbindung zu einem anderen VNet hergestellt wird, das direkt lokal verbunden ist. Dies ist die Übertragung mit VPN-Konnektivität, bei der Instanzen im ersten VNet mit den lokalen Ressourcen durch eine Verbindung zum VPN Gateway im verbundenen VNet verbunden werden, das direkt lokal verbunden ist. Um diese Konfiguration im klassischen Modell zu erreichen, müssen Sie einen lokalen Standort erstellen, der über aggregierte Präfixe verfügt, die sowohl das verbundene VNet als auch den lokalen Adressbereich darstellen. Dieser lokale Standort als Darstellung wird dann mit dem VNet verbunden, um Transitkonnektivität herzustellen. Bei diesem klassischen Modell bestehen ähnliche Herausforderungen mit der Verwaltbarkeit, da alle Änderungen im lokalen Adressbereich auch am lokalen Standort durchgeführt werden müssen, der das Aggregieren von VNet und lokaler Verbindung darstellt. Die Einführung von BGB-Unterstützung in von Resource Manager unterstützen Gateways vereinfacht die Verwaltbarkeit, nachdem die verbundenen Gateways Routen ohne die manuelle Modifizierung von Präfixen erlernen können.

Nachdem wir die VNet-zu-VNet-Konnektivität ohne lokale Standorte transformieren, verliert das Übertragungsszenario die lokale Konnektivität für das VNet, das indirekt lokal verbunden ist. Der Verlust der Konnektivität kann durch die folgenden zwei Wege nach Abschluss der Migration ausgeglichen werden:

• Durch Aktivieren von BGP auf VPN Gateways, die miteinander und mit dem lokalen Standort verbunden sind. Durch Aktivieren von BGP wird die Konnektivität ohne andere Änderungen der Konfiguration wiederhergestellt, nachdem zwischen den VNet Gateways Routen gelernt und beworben werden. Beachten Sie, dass die BGP-Option nur unter Standard- oder höheren SKUs verfügbar ist.
• Stellen Sie eine Verbindung vom betroffenen VNet zum lokalen Netzwerkgateway her, das den lokalen Standort darstellt. Das würde auch Änderungen der Einstellungen am lokalen Router erforderlich machen, um den IPsec-Tunnel zu erstellen und zu konfigurieren.

Nächste Schritte

Nachdem Sie Informationen zum VPN-Gateway Migrationssupport erhalten haben, wechseln Sie zu Migrieren von IaaS-Ressourcen aus dem klassischen Bereitstellungsmodell zu Azure Resource Manager mithilfe von Azure PowerShell, um anzufangen.