Verbinden eines lokalen Netzwerks mit Azure

In diesem Artikel werden die drei primären Optionen zum Verbinden eines lokalen Netzwerks mit einem Azure virtuellen Netzwerk verglichen: Azure VPN Gateway, Azure ExpressRoute und nicht Microsoft IPsec- oder SD-WAN-Lösungen, die in Azure gehostet werden. Für jede Option fasst es das Konnektivitätsmodell zusammen, wenn die Option geeignet ist, die wichtigsten Vorteile und Kompromisse sowie Links zu einer detaillierten Referenzarchitektur.

Dieser Artikel zielt auf Netzwerk- und Cloudarchitekten ab, die die Standort-zu-Standort-Konnektivität zwischen einem Unternehmens- oder Rechenzentrumsnetzwerk und einem oder mehreren Azure virtuellen Netzwerken auswerten. Separate Dokumentation befasst sich mit Point-to-Site-VPN und Vnet-zu-Vnet-Konnektivität, die hier außerhalb des Gültigkeitsbereichs liegen.

Azure VPN-Konnektivität

Ein Azure VPN-Gateway ist eine Art virtuelles Netzwerkgateway, das verschlüsselten Datenverkehr zwischen einem Azure virtuellen Netzwerk und einem lokalen Standort sendet, in der Regel über das öffentliche Internet.

Diese Architektur eignet sich für Hybridanwendungen, bei denen Datenverkehr zwischen lokaler und Azure leicht ist oder eine höhere Latenz im Austausch für Flexibilität und Cloud-Skalierbarkeit akzeptabel ist.

Diagramm, das die Hybridkonnektivität mit einem VPN-Gateway zeigt.

Azure VPN wird am häufigsten für die Standort-zu-Standort-VPN-Konnektivität (S2S) verwendet, die verschlüsselte, weitergeleitete Konnektivität zwischen einem lokalen Netzwerk und Azure virtuellen Netzwerken über IPsec/IKE-Tunnel bereitstellt. Azure VPN unterstützt auch Szenarien mit Point-to-Site (P2S) und VNet-to-VNet, aber diese Szenarien betreffen den Remotebenutzerzugriff bzw. die Inter-VNet-Konnektivität und sind hier nicht der primäre Fokus.

Vorteile

Die folgenden Funktionen machen Azure VPN für Hybridszenarien geeignet, die keine dedizierte Konnektivität erfordern.

  • Einfachere Konfiguration. Die Einrichtung ist einfacher als dedizierte Konnektivitätsoptionen wie ExpressRoute, da die Verbindung über das öffentliche Internet übertragen wird und keinen Verbindungsanbieter oder einen Schaltkreisbereitstellungsworkflow erfordert.
  • Verschlüsselt während der Übertragung. Standort-zu-Standort-Verbindungen verwenden IPsec/IKE-Tunnel, sodass der Datenverkehr zwischen dem lokalen VPN-Gerät und dem Azure VPN-Gateway standardmäßig auf der Netzwerkebene verschlüsselt wird.
  • Hohe Aggregatbandbreite. VPN Gateway unterstützt bis zu 10 GBit/s-Aggregat in Standard-Hub-and-Spoke-Topologien. Mit Azure Virtual WAN unterstützt jeder virtuelle Hub bis zu 20 GBit/s Aggregat. Sowohl der aggregierte Durchsatz als auch die Zonenredundanz hängen von der gewählten VPN Gateway SKU ab, sodass die SKU für den benötigten Durchsatz und die Resilienz groß ist. (Siehe Zuverlässigkeit.) Ausführliche Informationen finden Sie unter VPN Gateway Topologie und Design und Virtual WAN HÄUFIG gestellte Fragen.

Challenges

Berücksichtigen Sie die folgenden Einschränkungen, bevor Sie Azure VPN für eine Hybridworkload auswählen.

  • Lokales VPN-Gerät erforderlich. Sie betreiben und verwalten ein kompatibles lokales VPN-Gerät, das sich außerhalb der Azure verwalteten Grenze befindet.
  • SLA deckt nur das Gateway ab. Microsoft bietet eine SLA für die Verfügbarkeit von 99,9% für VPN Gateway. Die SLA für höhere Verfügbarkeit hängt von der SKU ab. Details zur SKU-Ebene finden Sie unter Zuverlässigkeit in Azure virtuellen Netzwerkgateways. Die SLA deckt das VPN-Gateway nur ab und deckt nicht den öffentlichen Internetpfad zwischen lokal und dem Gateway ab.

Referenzarchitektur

Eine vollständige exemplarische Vorgehensweise für die Implementierung dieser Option finden Sie in der folgenden Referenzarchitektur.

Azure ExpressRoute Konnektivität

ExpressRoute ist eine private, redundante und dedizierte Verbindung zwischen Ihrem lokalen Netzwerk und Azure. Ein nicht Microsoft Verbindungsanbieter liefert den Schaltkreis, oder Sie verwenden ExpressRoute Direct für eine direkte Verbindung zwischen Microsoft und Ihrem Netzwerk. Eine Übersicht darüber, wie der Schaltkreis geliefert werden kann, finden Sie unter ExpressRoute-Verbindungsmodelle.

ExpressRoute eignet sich für Hybridanwendungen, die große, unternehmenskritische Workloads ausführen, die eine hohe Bandbreite und vorhersehbare Leistung erfordern.

Diagramm, das die Hybridkonnektivität mit einem ExpressRoute-Gateway zeigt.

Note

Im Kontext von ExpressRoute bezieht sich der Microsoft Enterprise Edge (MSEE) auf die Edgerouter auf der Microsoft Seite des ExpressRoute-Schaltkreises. Diese Router sind der Einstiegspunkt in das Microsoft Netzwerk.

ExpressRoute wird am häufigsten mit privatem ExpressRoute-Peering verwendet, das private Verbindungen zu Azure virtuellen Netzwerken bereitstellt. Es unterstützt auch Microsoft Peering für die Konnektivität mit Microsoft öffentlichen Diensten wie Microsoft 365 und Azure öffentlichen Dienstendpunkten. Dieser Artikel konzentriert sich auf privates Peering.

Vorteile

Die folgenden Funktionen eignen sich gut für Hybridworkloads, die dedizierte, vorhersehbare Konnektivität benötigen.

  • Hohe Bandbreite. ExpressRoute bietet bis zu 10 GBit/s pro Schaltkreis über Verbindungsanbieter und zwei 10 GBit/s, 100-Gbps oder 400-GBit/s-Portoptionen mit ExpressRoute Direct. Der in-Azure-Durchsatz wird auch von der SKU des virtuellen ExpressRoute-Netzwerkgateways mit einer eigenen Bandbreitenobergrenze pro SKU gegatet, sodass der Workloaddurchsatz das Minimum des Schaltkreises, der Gateway-SKU und der lokalen Edgegeräte ist.
  • Vorhersehbare Latenz. Ein dedizierter Schaltkreis vermeidet die Pfadvariabilität des öffentlichen Internets und den Pro-Paket-IPsec-Verarbeitungsaufwand eines VPN-Tunnels. Mit diesem Design wird die Roundtriplatenz niedriger und konsistenter als internetbasierte Verbindungen.
  • Dynamische Bandbreitenskalierung. Sie können die Schaltkreisbandbreite erhöhen, ohne die Verbindung zu entfernen, wenn diese Funktion vom Verbindungsanbieter unterstützt wird.
  • Nationaler Cloudzugriff. ExpressRoute unterstützt den direkten Zugriff auf nationale Clouds, je nach Verbindungsanbieter.
  • SLA auf Schaltkreisebene. ExpressRoute bietet eine SLA mit hoher Verfügbarkeit auf dem dedizierten ExpressRoute-Schaltkreis zwischen dem Microsoft Netzwerk-Edge und dem Verbindungsanbieter oder der Partnerinfrastruktur. Die SLA deckt nicht den lokalen Pfad zum Anbieter oder dem virtuellen ExpressRoute-Netzwerkgateway in Azure ab.

Challenges

Berücksichtigen Sie die folgenden Einschränkungen, bevor Sie ExpressRoute für eine Hybridworkload auswählen.

  • Die Anbieterkoordination ist erforderlich. Für die Bereitstellung eines anderen Schaltkreises als ExpressRoute Direct ist eine Koordination mit einem Konnektivitätsanbieter erforderlich, der die Leadzeit und eine Abhängigkeit außerhalb der Azure verwalteten Grenze hinzufügt.
  • Lokale Router mit hoher Kapazität. Sie können Ihre lokalen Edgegeräte für die ausgewählte Schaltkreisbandbreite anpassen, einschließlich redundanter BGP-Sitzungen für beide MSEEs.
  • Private Peering nicht standardmäßig verschlüsselt. ExpressRoute private Peering stellt einen privaten Schaltkreis bereit, verschlüsselt jedoch standardmäßig keinen Datenverkehr auf der Netzwerkebene. Verwenden Sie für Workloads, die eine Verschlüsselung während der Übertragung erfordern, MACsec auf ExpressRoute Direct oder IPsec über ExpressRoute , um eine Verschlüsselungsebene hinzuzufügen.

Referenzarchitektur

Eine vollständige exemplarische Vorgehensweise für die Implementierung dieser Option finden Sie in der folgenden Referenzarchitektur.

Nicht-Microsoft SD-WAN- oder IPsec-Konnektivität

Azure unterstützt das Hosten von Lösungen ohne Microsoft SD-WAN oder IPsec, um eine vorhandene Netzwerkarchitektur in die Cloud zu erweitern. Mit diesen nicht nativen Optionen können Sie eine bevorzugte Konnektivitätstechnologie verwenden, während sie in Azure integriert wird, in der Regel indem Sie die Appliance des Anbieters als virtuelle Netzwerk-Appliance (NVA) in einem virtuellen Hubnetzwerk oder durch Anfügen an einen Virtual WAN Hub ausführen.

Diagramm, das die Hybridkonnektivität mit SD-WAN zeigt.

Vorteile

Die folgenden Funktionen machen eine nicht Microsoft SD-WAN- oder IPsec-Bereitstellung gut geeignet, wenn Sie einen vorhandenen Verbindungsstapel beibehalten möchten.

  • Architekturkontinuität. Erweitern Sie eine vorhandene Netzwerkarchitektur in Azure mithilfe bevorzugter Konnektivitätstechnologien, sodass die lokalen und Cloudseiten dasselbe Betriebs- und Routingmodell nutzen.
  • Azure Reichweite und Skalierung. Halten Sie ein konsistentes Netzwerkdesign, während Sie die globale Reichweite und Skalierbarkeit von Azure nutzen.

Challenges

Berücksichtigen Sie die folgenden Einschränkungen, bevor Sie eine Nicht-Microsoft SD-WAN- oder IPsec-Bereitstellung für eine Hybridworkload auswählen.

  • Implementierungskomplexität. Nicht native Lösungen erfordern mehr Entwurfs- und Integrationsschritte als Azure systemeigene Konnektivitätsoptionen. Überprüfen Sie vorgeschlagene Architekturen mit Microsoft und dem SD-WAN- oder IPsec-Partner vor der Bereitstellung.
  • Vom Anbieter definierte hohe Verfügbarkeit und Skalierung. Hohe Verfügbarkeit, Durchsatz und Skalierungsverhalten hängen vom Referenzdesign des Herstellers und von der SKU und der Instanzgröße des NVA in Azure ab. Die Plattform-SLAs für VPN Gateway und ExpressRoute erstrecken sich nicht auf eine nicht Microsoft NVA, die in Ihrem Abonnement ausgeführt wird. Das Laufzeit-, Patching- und Failoververhalten dieser Appliance bleibt Ihre Verantwortung und die Verantwortung Ihres Partners.

Referenzarchitekturen

Eine vollständige exemplarische Implementierung dieser Optionen finden Sie in den folgenden Referenzarchitekturen.

Considerations

Diese Zuverlässigkeitsüberlegungen wenden die Zuverlässigkeitssäule des Azure Well-Architected Frameworks auf hybride Konnektivität an. Die anderen Säulen (Sicherheit, Kostenoptimierung, Operative Exzellenz und Leistungseffizienz) weisen jeweils eigene Überlegungen für VPN, ExpressRoute und nicht Microsoft Konnektivität auf. Eine vollständige Säulenüberprüfung finden Sie unter Microsoft Azure Well-Architected Framework.

Reliability

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie ihren Kunden leisten. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Die Zuverlässigkeit für die Hybridkonnektivität hängt von der Resilienz sowohl des Azure-side Gateways oder schaltkreises als auch der lokalen und Netzwerkpfade ab, die eine Verbindung mit ihr herstellen.

  • Zonenredundante Gateways. Wenn die Region Verfügbarkeitszonen unterstützt, stellen Sie VPN Gateway- und ExpressRoute-Gateways auf zonenredundanten SKUs bereit, sodass Azure die Gateway-VMs über Verfügbarkeitszonen verteilt und das Gateway einen ausfallfreien Bereich übersteht. Weitere Informationen finden Sie unter Zuverlässigkeit in Azure virtuellen Netzwerkgateways (VPN) und design and architect Azure ExpressRoute für Resilienz.
  • Aktiv-aktive VPN-Gateways. Stellen Sie für Workloads, die eine höhere Resilienz und einen Aggregatdurchsatz von einer VPN-Verbindung benötigen, das Azure VPN-Gateway im aktiven Modus bereit, sodass beide Gatewayinstanzen Datenverkehr und einen Tunnel von jeder Instanz auf dem lokalen VPN-Gerät beenden. Koppeln Sie diese Konfiguration mit zwei lokalen VPN-Geräten, um den lokalen einzelnen Fehlerpunkt zu entfernen.
  • Redundante BGP-Sitzungen für ExpressRoute. ExpressRoute stellt ein redundantes BGP-Sitzungspaar pro Peering für zwei Microsoft Enterprise Edge (MSEE)-Router in einer aktiven Konfiguration bereit. Vergrößern Sie lokale Kunden-Edgegeräte, um beide Sitzungen zu beenden, und ziehen Sie die Bidirektionale Weiterleitungserkennung (Bidirectional Forwarding Detection, BFD) in Betracht, um die Erkennung von Verknüpfungsfehlern unter dem standardmäßigen BGP-Timeout zu verkürzen.
  • VPN als Failoverpfad für ExpressRoute. Konfigurieren Sie für Workloads, die einen sekundären Pfad erfordern, ein Standort-zu-Standort-VPN als koexistierende Sicherung für einen privaten ExpressRoute-Peering-Schaltkreis. Der ExpressRoute-Schaltkreis bleibt primär, und Datenverkehr verwendet den VPN-Pfad nur, wenn der Schaltkreis nicht verfügbar ist. Konfigurieren Sie lokales Routing (z. B. lokale Einstellungen), um den ExpressRoute-Pfad zu bevorzugen und asymmetrisches Routing zu vermeiden.
  • Regionales Failover. Die vorstehenden Elemente adressiert die Resilienz im Bereich der Zone und pfadbezogenen Resilienz innerhalb einer einzelnen Azure Region. Workloads, die eine Kontinuität während eines regionalen Ausfalls erfordern, benötigen ein zweites Gateway oder einen zweiten Schaltkreis in der Failoverregion, und die Auswahl des PFADs auf DNS-Ebene oder Routingebene, um den Datenverkehr an die überlebende Region zu leiten. Weitere Informationen finden Sie unter Entwerfen der Notfallwiederherstellung mit privatem ExpressRoute-Peering.
  • Komponenten, die Sie verwalten. Das lokale VPN-Gerät, lokale Edgerouter und alle nicht Microsoft SD-WAN oder IPsec NVAs, die in Azure ausgeführt werden, befinden sich außerhalb der SLA der Azure Plattform. Planen Sie Redundanz auf Geräteebene, Patching und Failover für diese Komponenten im Einklang mit dem Referenzdesign des Herstellers.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächste Schritte

Implementierungsanleitungen für die ausgewählte Konnektivitätsoption finden Sie in der passenden Referenzarchitektur:

Die folgenden Artikel behandeln verwandte Azure Netzwerktopologien, die häufig hybride Konnektivitätsdesigns begleiten:

  • Last updated on