Informationen zu virtuellen Azure-Netzwerken

  • 10 Minuten

Virtuelle Azure-Netzwerke (VNets) bilden die Grundlage für Ihr privates Netzwerk in Azure. Mithilfe von VNets können Sie komplexe virtuelle Netzwerke erstellen, die einem lokalen Netzwerk ähneln, aber zusätzliche Vorteile der Azure-Infrastruktur bieten, etwa Skalierung, Verfügbarkeit und Isolation.

Jedes erstellte VNet verfügt über einen eigenen CIDR-Block und kann mit anderen VNets und lokalen Netzwerken verbunden werden, solange sich die CIDR-Blöcke nicht überschneiden. Sie können zudem die DNS-Servereinstellungen für VNets steuern und das VNet in Subnetze segmentieren.

Funktionen virtueller Azure-Netzwerke

Azure-VNets ermöglichen Ressourcen in Azure eine sichere Kommunikation untereinander, mit dem Internet und mit lokalen Netzwerken.

  • Kommunikation mit dem Internet. Alle Ressourcen in einem VNET können standardmäßig in ausgehender Richtung mit dem Internet kommunizieren. Zur Kommunikation in eingehender Richtung muss der entsprechenden Ressource eine öffentliche IP-Adresse oder eine öffentliche Load Balancer-Instanz zugewiesen werden. Die öffentliche IP-Adresse bzw. die öffentliche Load Balancer-Instanz kann auch zum Verwalten der ausgehenden Verbindungen verwendet werden.
  • Kommunikation zwischen Azure-Ressourcen. Es gibt drei wichtige Mechanismen, über die Azure-Ressourcen kommunizieren können: VNets, VNet-Dienstendpunkte und VNet-Peering. Virtuelle Netzwerke können nicht nur eine Verbindung mit VMs herstellen, sondern auch mit anderen Azure-Ressourcen. Hierzu zählen beispielsweise die App Service-Umgebung, Azure Kubernetes Service und Microsoft Azure Virtual Machine Scale Sets. Mithilfe von Dienstendpunkten können Sie eine Verbindung mit anderen Azure-Ressourcentypen herstellen (beispielsweise mit Azure SQL-Datenbanken und Speicherkonten). Wenn Sie ein VNet erstellen, können die Dienste und virtuellen Computer des VNet direkt und sicher in der Cloud miteinander kommunizieren.
  • Kommunikation zwischen lokalen Ressourcen. Sicheres Erweitern des Rechenzentrums. Sie können Ihre lokalen Computer und Netzwerke mithilfe einer der folgenden Optionen mit einem virtuellen Netzwerk verbinden: Point-to-Site-VPN (Virtual Private Network), Site-to-Site-VPN, Azure ExpressRoute.
  • Filterung des Netzwerkdatenverkehrs. Sie können den Netzwerkdatenverkehr zwischen Subnetzen filtern, indem Sie eine beliebige Kombination aus Netzwerksicherheitsgruppen und virtuellen Netzwerkgeräten wie Firewalls, Gateways, Proxys und NAT-Diensten (Network Address Translation) verwenden.
  • Routing des Netzwerkdatenverkehrs. Azure leitet standardmäßig Datenverkehr zwischen Subnetzen, verbundenen virtuellen Netzwerken, lokalen Netzwerken und dem Internet weiter. Sie können Routingtabellen oder BGP-Routen (Border Gateway Protocol) implementieren, um die von Azure erstellten Standardrouten zu überschreiben.

Entwurfsüberlegungen für virtuelle Azure-Netzwerke

Adressraum und Subnetze

Sie können pro Region und Abonnement mehrere virtuelle Netzwerke erstellen. Sie können in jedem virtuellen Netzwerk mehrere Subnetze erstellen.

Virtuelle Netzwerke

Für die VNet-Erstellung wird empfohlen, die in RFC 1918 aufgeführten Adressbereiche zu verwenden, die von der IETF für private, nicht routingfähige Adressräume reserviert wurden:

  • 10.0.0.0 – 10.255.255.255 (10/8-Präfix)
  • 172.16.0.0 – 172.31.255.255 (172.16/12-Präfix)
  • 192.168.0.0 – 192.168.255.255 (Präfix: 192.168/16)

Die folgenden Adressbereiche können nicht hinzugefügt werden:

  • 224.0.0.0/4 (Multicast)
  • 255.255.255.255/32 (Übertragung)
  • 127.0.0.0/8 (Loopback)
  • 169.254.0.0/16 (verbindungslokal)
  • 168.63.129.16/32 (Internes DNS)

Azure weist den Ressourcen in einem virtuellen Netzwerk eine private IP-Adresse aus dem von Ihnen zugewiesenen Adressraum zu. Wenn Sie beispielsweise eine VM in einem VNet mit dem Subnetzadressraum 192.168.1.0/24 bereitstellen, wird der VM eine private IP-Adresse wie 192.168.1.4 zugewiesen. Azure reserviert die ersten vier und die letzte IP-Adresse (insgesamt 5 IP-Adressen) in jedem Subnetz. Dies sind x.x.x.0-x.x.x.3 und die letzte Adresse des Subnetzes.

Der IP-Adressbereich 192.168.1.0/24 weist beispielsweise die folgenden reservierten Adressen auf:

  • 192.168.1.0: Netzwerkadresse
  • 192.168.1.1: Von Azure für das Standardgateway reserviert
  • 192.168.1.2, 192.168.1.3: Von Azure zum Zuordnen der Azure DNS-IPs zum VNet-Adressraum reserviert
  • 192.168.1.255: Netzwerkadresse für Broadcasts

Beim Planen der Implementierung virtueller Netzwerke müssen Sie Folgendes berücksichtigen:

  • Stellen Sie sicher, dass sich Adressräume nicht überschneiden. Stellen Sie sicher, dass der Adressraum Ihres VNET (CIDR-Block) sich nicht mit anderen Netzwerkbereichen Ihrer Organisation überschneidet.
  • Ist eine Sicherheitsisolation erforderlich?
  • Müssen Sie Einschränkungen bei der IP-Adressierung umgehen?
  • Gibt es Verbindungen zwischen Azure-VNets und lokalen Netzwerken?
  • Ist für administrative Zwecke eine Isolation erforderlich?
  • Verwenden Sie Azure-Dienste, die eigene VNets erstellen?

Subnetze

Ein Subnetz ist ein IP-Adressbereich im VNet. Sie können VNets in unterschiedlich große Subnetze unterteilen und so viele Subnetze erstellen, wie Sie für die Organisation und Sicherheit innerhalb des Abonnementlimits benötigen. Dann können Sie Azure-Ressourcen in einem bestimmten Subnetz bereitstellen. Wie in einem herkömmlichen Netzwerk können Sie mit Subnetzen Ihren VNET-Adressraum in Segmente unterteilen, die für das interne Netzwerk des Unternehmens geeignet sind. Dadurch wird auch die Adresszuordnung optimiert. Das kleinste unterstützte IPv4-Subnetz ist /29, das größte Subnetz ist /2 (gemäß CIDR-Subnetzdefinitionen). IPv6-Subnetze müssen exakt /64 groß sein. Beim Planen der Implementierung von Subnetzen müssen Sie Folgendes berücksichtigen:

  • Jedes Subnetz muss einen eindeutigen Adressbereich aufweisen, der im CIDR-Format (Classless Inter-Domain Routing) angegeben wird.
  • Für bestimmte Azure-Dienste ist ein eigenes Subnetz erforderlich.
  • Subnetze können für die Verwaltung des Datenverkehrs verwendet werden. Beispielsweise können Sie Subnetze erstellen, um Datenverkehr über ein virtuelles Netzwerkgerät weiterzuleiten.
  • Sie können den Zugriff auf Azure-Ressourcen mit einem VNet-Dienstendpunkt auf bestimmte Subnetze einschränken. Sie können mehrere Subnetze erstellen und für bestimmte Subnetze einen Dienstendpunkt aktivieren, für andere hingegen nicht.

Festlegen einer Namenskonvention

Im Rahmen des Azure-Netzwerkentwurfs ist es wichtig, die Benennungskonvention für Ihre Ressourcen zu planen. Eine effektive Benennungskonvention setzt Ressourcennamen aus wichtigen Informationen zu der jeweiligen Ressource zusammen. Ein wohlüberlegt ausgewählter Name hilft Ihnen, schnell den Typ der Ressource, deren zugehörige Workload, deren Bereitstellungsumgebung und die Azure-Region zu erkennen, in der sie gehostet wird. Beispielsweise könnte eine öffentliche IP-Ressource für eine SharePoint-Produktionsworkload in der Region „USA, Westen“ den Namen „pip-sharepoint-prod-westus-001“ erhalten.

Azure resource naming example.

Alle Azure-Ressourcentypen weisen einen Bereich auf, der die Ebene definiert, auf der Ressourcennamen eindeutig sein müssen. Eine Ressource muss einen eindeutigen Namen innerhalb ihres Bereichs aufweisen. Es gibt vier Ebenen, für die Sie einen Bereich festlegen können: Verwaltungsgruppe, Abonnement, Ressourcengruppe und Ressource. Bereiche sind hierarchisch aufgebaut, wobei jede Hierarchieebene den Bereich näher bestimmt.

Angenommen, ein virtuelles Netzwerk verfügt über einen Ressourcengruppenbereich. Dies bedeutet, dass es in jeder Ressourcengruppe nur ein Netzwerk namens „vnet-prod-westus-001“ geben darf. Andere Ressourcengruppen können ein eigenes virtuelles Netzwerk mit dem Namen „vnet-prod-westus-001“ aufweisen. Subnetze gehören in den Bereich eines virtuellen Netzwerks, daher muss jedes Subnetz innerhalb eines virtuellen Netzwerks einen eindeutigen Namen besitzen.

Grundlegendes zu Regionen und Abonnements

Alle Azure-Ressourcen werden in einer Azure-Region und unter einem Abonnement erstellt. Eine Ressource kann nur in einem virtuellen Netzwerk erstellt werden, das in derselben Region und unter demselben Abonnement wie die Ressource vorhanden ist. Sie können jedoch virtuelle Netzwerke verbinden, die in unterschiedlichen Abonnements und Regionen vorhanden sind. Azure-Regionen sind wichtig, wenn Sie Ihr Azure-Netzwerk in Bezug auf Infrastruktur, Daten, Anwendungen und Endbenutzer entwerfen.

Innerhalb jedes Abonnements können Sie bis zum geltenden Limit beliebig viele virtuelle Netzwerke bereitstellen. Einige größere Organisationen mit globalen Bereitstellungen verwenden beispielsweise mehrere virtuelle Netzwerke, die regionsübergreifend verbunden sind.

Screen capture of a World map showing Azure global network.

Azure-Verfügbarkeitszonen

Mit einer Azure-Verfügbarkeitszone können Sie eindeutige physische Standorte innerhalb einer Region definieren. Jede Zone besteht aus mindestens einem Rechenzentrum, dessen Stromversorgung, Kühlung und Netzwerkbetrieb unabhängig funktionieren. Die physische Trennung von Verfügbarkeitszonen innerhalb einer Region schützt Anwendungen und Daten vor Rechenzentrumsausfällen und gewährleistet so die Hochverfügbarkeit Ihrer Azure-Dienste.

Azure region showing three availability zones.

Beim Entwerfen Ihres Azure-Netzwerks sollten Sie Verfügbarkeitszonen berücksichtigen und Dienste planen, die Verfügbarkeitszonen unterstützen.

Azure-Dienste mit Unterstützung von Verfügbarkeitszonen können in drei Kategorien unterteilt werden:

  • Zonenbasierte Dienste: Ressourcen können an eine bestimmte Zone angeheftet werden. Beispielsweise können virtuelle Computer, verwaltete Datenträger oder IP-Standardadressen an eine bestimmte Zone angeheftet werden. So können Sie eine bessere Resilienz erzielen, da eine oder mehrere Ressourceninstanzen auf mehrere Zonen verteilt werden.
  • Zonenredundante Dienste: Ressourcen werden automatisch zonenübergreifend repliziert oder verteilt. Azure repliziert die Daten in drei Zonen, damit der Ausfall einer Zone keine Auswirkungen auf deren Verfügbarkeit hat.
  • Nicht regionale Dienste: Dienste sind immer in Azure-Geografien verfügbar und sowohl gegen zonenweite als auch regionsweite Ausfälle resilient.