App braucht ein privates Netzwerk? Erstelle ein VNet

Veröffentlicht am:

Die CloudTrips-Anwendung benötigt eine private Netzwerkgrenze für Komponenten, die über private IP-Adressen kommunizieren sollen. Ohne ein geplantes Netzwerk können spätere Bereitstellungen inkompatible Adressbereiche verwenden oder von öffentlicher Konnektivität abhängen.

Erstelle ein virtuelles Azure-Netzwerk, kurz VNet. Ein VNet ist ein softwaredefiniertes, regionales privates Netzwerk in Azure. Sein Adressraum stellt private IP-Adressen bereit, und seine Subnetze unterteilen diesen Raum für verschiedene Workload-Komponenten.

Dieser Trip erstellt nur die Netzwerkgrundlage. Ein VNet platziert eine Anwendung nicht automatisch im Netzwerk, blockiert keinen Datenverkehr, verbindet kein anderes Netzwerk und macht einen öffentlichen Azure-Dienst nicht privat. Spätere Netzwerk-Trips werden diese Kontrollen ergänzen.

Adressraum planen

Verwende für CloudTrips TEST dieses Design:

Abonnement: CloudTrips TEST
Ressourcengruppe: rg-cloudtrips-network-test-weu
Region: West Europe
Virtuelles Netzwerk: vnet-cloudtrips-test-weu
VNet-Adressraum: 10.20.0.0/16
Anwendungssubnetz: snet-app
Subnetzbereich: 10.20.1.0/24
Default outbound access: Disabled

10.20.0.0/16 ist der vollständige private Adressbereich, der für dieses VNet reserviert ist. 10.20.1.0/24 ist ein kleinerer Bereich darin, der für Anwendungsressourcen reserviert wird. Der ungenutzte VNet-Adressraum bleibt für zukünftige Subnetze verfügbar.

Was bedeuten /16 und /24?

Eine IPv4-Adresse besteht aus 32 Binärstellen oder Bits. Die Zahl nach / ist die CIDR-Präfixlänge: Sie gibt der Netzmaske vor, wie viele Bits das Netzwerk identifizieren. Die übrigen Bits können Adressen innerhalb dieses Netzwerks identifizieren.

CIDR-Bereich Entsprechende Netzmaske Fester Netzwerkanteil Vollständiger Bereich Adressen insgesamt
10.20.0.0/16 255.255.0.0 10.20 10.20.0.010.20.255.255 65.536
10.20.1.0/24 255.255.255.0 10.20.1 10.20.1.010.20.1.255 256

Bei /16 bilden die ersten 16 Bits den Netzwerkanteil, während die letzten 16 Bits variieren können. Bei /24 bilden die ersten 24 Bits den Netzwerkanteil, und nur die letzten 8 Bits können variieren. Eine größere Präfixzahl erzeugt deshalb einen kleineren Adressbereich.

Azure reserviert in jedem Subnetz die ersten vier und die letzte Adresse. Das Subnetz 10.20.1.0/24 stellt Azure-Ressourcen daher 251 und nicht alle 256 Adressen zur Verfügung. Der /16-VNet-Bereich wird nicht direkt der Anwendung zugewiesen, sondern in Subnetze wie dieses /24 unterteilt.

Bevor du diese Werte in einer echten Organisation verwendest, bestätige, dass 10.20.0.0/16 sich nicht mit einem anderen VNet, einem lokalen Netzwerk oder einem anderen Cloud-Netzwerk überschneidet, das später mit CloudTrips verbunden werden könnte. Überlappende Bereiche verhindern das normale Routing zwischen verbundenen Netzwerken.

Ressourcengruppe erstellen

Melde dich im Azure-Portal an und öffne:

Resource groups > Create

Konfiguriere:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Region: West Europe

Wähle Review + create und anschließend Create.

Virtuelles Netzwerk erstellen

Suche nach Virtual networks, öffne den Dienst und wähle Create.

Azure-Seite Virtual networks mit der verfügbaren Aktion Create

Konfiguriere unter Basics:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-network-test-weu
Name: vnet-cloudtrips-test-weu
Region: West Europe

Wähle Next, um Security zu öffnen. Stelle in dieser Übung weder Azure Bastion noch Azure Firewall oder einen kostenpflichtigen DDoS-Schutzplan bereit. Diese Dienste lösen andere Probleme und können Kosten verursachen.

Lasse unter Virtual network encryption die Option Enable virtual network encryption deaktiviert. Diese Funktion verschlüsselt Datenverkehr zwischen unterstützten virtuellen Maschinen und VM-Skalierungsgruppen. Das VNet ist in diesem Trip noch leer. Aktiviere die Funktion daher erst später, nachdem die Unterstützung durch die geplanten Compute-Dienste und das Netzwerkdesign geprüft wurde.

Wähle Next, um IP Addresses zu öffnen. Setze den IPv4-Adressraum auf:

10.20.0.0/16

Dieses /16 ist die äußere Grenze des gesamten VNets. Es umfasst den Bereich von 10.20.0.0 bis 10.20.255.255.

Wähle jetzt das Standardsubnetz aus, um es zu bearbeiten. Weise dem Subnetz einen kleineren /24-Ausschnitt innerhalb dieses VNet-Bereichs zu:

Subnet purpose/template: Default
Name: snet-app
Starting address: 10.20.1.0
Subnet size: /24
Default outbound access: Disabled

Das resultierende Subnetz ist 10.20.1.0/24 und umfasst 10.20.1.0 bis 10.20.1.255. Es liegt innerhalb von 10.20.0.0/16, weil jede Adresse weiterhin mit 10.20 beginnt. Das /16 gehört zum VNet; das /24 gehört zu snet-app.

Das Deaktivieren von Default outbound access macht dieses Subnetz zu einem privaten Subnetz. Eine darin platzierte Ressource erhält keine implizite ausgehende Internetverbindung von Azure. Wenn die Anwendung später Internetzugriff benötigt, stelle einen expliziten ausgehenden Pfad wie Azure NAT Gateway oder Azure Firewall bereit.

Speichere das Subnetz.

Registerkarte IP Addresses beim Erstellen des VNets mit VNet-Adressraum und Subnetz snet-app

Füge unter Tags hinzu:

Application: CloudTrips
Environment: TEST
ManagedBy: Portal

Wähle Review + create. Wähle nach erfolgreicher Validierung Create.

Netzwerk überprüfen

Öffne vnet-cloudtrips-test-weu. Bestätige unter Overview:

Resource group: rg-cloudtrips-network-test-weu
Location: West Europe
Address space: 10.20.0.0/16

Erstelltes CloudTrips-TEST-VNet mit dem geplanten Adressraum 10.20.0.0/16

Öffne anschließend Settings > Subnets und bestätige:

Name: snet-app
Address range: 10.20.1.0/24
Default outbound access: Disabled

Seite Subnets des CloudTrips-TEST-VNets mit dem privaten Anwendungssubnetz snet-app

Die Anwendung besitzt jetzt eine geplante private Netzwerkgrundlage. Das VNet stellt den regionalen Adressraum bereit, während snet-app die erste Platzierungsgrenze für Anwendungsressourcen bildet.

Behalte dieses VNet, wenn du mit den Netzwerk-Trips fortfährst. Wenn dies nur ein Test war, lösche rg-cloudtrips-network-test-weu; beim Löschen der Ressourcengruppe werden auch das VNet und sein Subnetz gelöscht.