Szenario für virtuelle Geräte
Als gängiges Szenario müssen größere Azure-Kunden eine Anwendung mit zwei Ebenen bereitstellen, die über das Internet verfügbar ist und gleichzeitig den Zugriff auf die Back-End-Ebene über ein lokales Rechenzentrum ermöglicht. In diesem Dokument wird schrittweise ein Szenario mit Routingtabellen, einem VPN-Gateway und virtuellen Netzwerkgeräten zum Bereitstellen einer Umgebung mit zwei Ebenen erläutert, die folgende Anforderungen erfüllt:
Die Webanwendung darf nur über das öffentliche Internet zugänglich sein.
Der Webserver, auf dem die Anwendung gehostet wird, muss auf einen Back-End-Anwendungsserver zugreifen können.
Der gesamte Datenverkehr aus dem Internet an die Webanwendung muss über ein virtuelles Firewallgerät geleitet werden. Dieses virtuelle Gerät wird ausschließlich für Internetdatenverkehr verwendet.
Der gesamte Datenverkehr an den Anwendungsserver muss über ein virtuelles Firewallgerät geleitet werden. Dieses virtuelle Gerät wird für den Zugriff auf den Back-End-Server und den Zugriff auf den vom lokalen Netzwerk über ein VPN-Gateway eingehenden Datenverkehr eingesetzt.
Administratoren müssen die virtuellen Firewallgeräte über ihre lokalen Computer verwalten können, indem sie ein drittes ausschließlich zu Verwaltungszwecken genutztes virtuelles Firewallgerät nutzen.
Dieses Beispiel zeigt ein Umkreisnetzwerk-Standardszenario (auch als DMZ bezeichnet) mit einer DMZ und einem geschützten Netzwerk. Dieses Szenario kann in Azure unter Verwendung von Netzwerksicherheitsgruppen (NSGs) oder virtuellen Firewallgeräten oder einer Kombination aus beiden geschaffen werden.
In der folgenden Tabelle werden einige Vor- und Nachteile im Hinblick auf Netzwerksicherheitsgruppen und virtuelle Firewallgeräte aufgeführt.
| Element | Vorteile | Nachteile |
|---|---|---|
| NSG | Keine Kosten. Integriert in rollenbasierte Azure-Zugriffssteuerung. Regeln können in Azure Resource Manager-Vorlagen erstellt werden. |
Komplexität kann in größeren Umgebungen variieren. |
| Firewall | Vollständige Kontrolle über die Datenebene. Zentrale Verwaltung über Firewallkonsole. |
Kosten der Firewallgeräte. Nicht integriert in rollenbasierte Azure-Zugriffssteuerung. |
In der folgenden Lösung wird ein Szenario mit einem Umkreisnetzwerk (DMZ) bzw. ein geschütztes Netzwerk mithilfe virtueller Firewallgeräte implementiert.
Überlegungen
Die oben beschriebene Umgebung können Sie in Azure mithilfe verschiedener derzeit verfügbarer Features bereitstellen.
Virtuelles Netzwerk. Ein Azure-VNet ähnelt einem lokalen Netzwerk und kann in ein oder mehrere Subnetze segmentiert werden, um die Isolation des Datenverkehrs und eine Trennung von Zuständigkeiten zu gewährleisten.
Virtuelles Gerät. Mehrere Partner bieten im Azure Marketplace virtuelle Geräte an, die für die drei oben beschriebenen Firewalls verwendet werden können.
Routingtabellen. Routingtabellen werden von Azure-Netzwerken verwendet, um den Paketfluss in einem VNet zu steuern. Diese Routingtabellen können auf Subnetze angewendet werden. Sie können eine Routingtabelle auf das GatewaySubnet anwenden, das den gesamten Datenverkehr, der im virtuellen Azure-Netzwerk eingeht, von einer Hybridverbindung an ein virtuelles Gerät weiterleitet.
IP-Weiterleitung. Mit der Azure-Netzwerk-Engine werden Pakete standardmäßig nur an virtuelle Netzwerkkarten (NICs) weitergeleitet, wenn die Ziel-IP-Adresse der Pakete der IP-Adresse der NICs entspricht. Wenn also mit einer Routingtabelle definiert wird, dass ein Paket an ein bestimmtes virtuelles Gerät gesendet werden muss, wird dieses Paket in der Azure-Netzwerk-Engine ignoriert. Um sicherzustellen, dass das Paket an eine VM (in diesem Fall ein virtuelles Gerät) übermittelt wird, die nicht das eigentliche Ziel für das Paket ist, müssen Sie IP-Weiterleitung für das virtuelle Gerät aktivieren.
Netzwerksicherheitsgruppen (NSGs) . Im folgenden Beispiel werden keine NSGs verwendet. Sie könnten aber NSGs verwenden, die auf die Subnetze und/oder NICs in dieser Lösung angewendet werden. Die Netzwerksicherheitsgruppen würden den Datenverkehr in diese Subnetze und NICs und aus diesen Subnetzen und NICs weiter filtern.
Dieses Beispiel umfasst ein Abonnement, das die folgenden Elemente enthält:
Zwei Ressourcengruppen, die im Diagramm nicht abgebildet sind.
ONPREMRG. Enthält alle Ressourcen, die für die Simulation eines lokalen Netzwerks erforderlich sind.
AZURERG. Enthält alle Ressourcen, die für die virtuelle Azure-Netzwerkumgebung erforderlich sind.
Ein virtuelles Netzwerk namens onpremvnet, das wie folgt segmentiert ist, um ein lokales Rechenzentrum zu simulieren.
onpremsn1. Subnetz mit einem virtuellen Computer, auf dem eine Linux-Verteilung ausgeführt wird, um einen lokalen Server zu imitieren.
onpremsn2. Subnetz mit einem virtuellen Computer, auf dem eine Linux-Verteilung ausgeführt wird, um einen von einem Administrator verwendeten lokalen Computer zu imitieren.
Es ist ein virtuelles Firewallgerät mit dem Namen OPFW in onpremvnet vorhanden, über das ein Tunnel zu azurevnet verwaltet wird.
Ein virtuelles Netzwerk namens azurevnet, das wie folgt segmentiert wird.
azsn1. Subnetz, das ausschließlich für die externe Firewall verwendet wird. Der gesamte Internetdatenverkehr geht über dieses Subnetz ein. Dieses Subnetz enthält nur eine Netzwerkkarte, die mit der externen Firewall verknüpft ist.
azsn2. Front-End-Subnetz, in dem eine als Webserver ausgeführte VM gehostet wird, auf die über das Internet zugegriffen wird.
azsn3. Back-End-Subnetz, in dem eine als Back-End-Anwendungsserver ausgeführte VM gehostet wird, auf die über den Front-End-Webserver zugegriffen wird.
azsn4. Verwaltungssubnetz, das ausschließlich für die Bereitstellung des Verwaltungszugriffs auf alle virtuellen Firewallgeräte verwendet wird. Dieses Subnetz enthält jeweils nur eine Netzwerkkarte für die in der Lösung verwendeten virtuellen Firewallgeräte.
GatewaySubnet. Subnetz für Azure-Hybridverbindungen, das für ExpressRoute und VPN Gateway erforderlich ist, um die Konnektivität zwischen Azure-VNETs und anderen Netzwerken zu gewährleisten.
Es gibt drei virtuelle Firewallgeräte im Netzwerk azurevnet .
AZF1. Externe Firewall, die durch Verwendung einer öffentlichen IP-Adressressource in Azure für das öffentliche Internet verfügbar ist. Dazu benötigen Sie eine Vorlage aus Marketplace oder direkt vom Geräteanbieter, über die ein virtuelles Gerät mit drei Netzwerkkarten bereitgestellt wird.
AZF2. Interne Firewall für die Steuerung des Datenverkehrs zwischen azsn2 und azsn3. Auch bei dieser Firewall handelt es sich um ein virtuelles Gerät mit drei NICs.
AZF3. Verwaltungsfirewall, auf die Administratoren über das lokale Rechenzentrum zugreifen können und die mit einem Verwaltungssubnetz verbunden ist, über das alle Firewallgeräte verwaltet werden. Vorlagen für virtuelle Geräte mit zwei Netzwerkkarten finden Sie im Marketplace, oder Sie können sie direkt vom Geräteanbieter anfordern.
Routentabellen
Jedes Subnetz in Azure kann mit einer Routingtabelle verknüpft werden, in der definiert wird, wie der im jeweiligen Subnetz initiierte Datenverkehr weitergeleitet wird. Wenn keine benutzerdefinierten Routen definiert sind, werden Standardrouten verwendet, um die Weiterleitung des Datenverkehrs zwischen den Subnetzen zu ermöglichen. Informationen zum besseren Verständnis von Routingtabellen und Datenverkehrsrouting finden Sie unter Datenverkehrsrouting in virtuellen Azure-Netzwerken.
Um sicherzustellen, dass die Kommunikation über das richtige Firewallgerät erfolgt, müssen Sie auf Grundlage der letzten oben aufgeführten Anforderung die folgende Routingtabelle in azurevnet erstellen.
azgwudr
In diesem Szenario wird nur der Datenverkehr von lokalen Quellen zu Azure zum Verwalten der Firewalls durch Verbinden mit AZF3 verwendet. Dieser Datenverkehr muss über die interne Firewall AZF2 geleitet werden. Daher ist nur eine Route im GatewaySubnet erforderlich, wie unten gezeigt.
| Destination | Nächster Hop | Erklärung |
|---|---|---|
| 10.0.4.0/24 | 10.0.3.11 | Ermöglicht, dass lokaler Datenverkehr zur Verwaltungsfirewall AZF3 |
azsn2udr
| Destination | Nächster Hop | Erklärung |
|---|---|---|
| 10.0.3.0/24 | 10.0.2.11 | Ermöglicht den Datenverkehr zum Back-End-Subnetz, in dem der Anwendungsserver gehostet wird, über AZF2 |
| 0.0.0.0/0 | 10.0.2.10 | Ermöglicht die Weiterleitung des gesamten anderen Datenverkehrs über AZF1 |
azsn3udr
| Destination | Nächster Hop | Erklärung |
|---|---|---|
| 10.0.2.0/24 | 10.0.3.10 | Ermöglicht, dass der Datenverkehr an azsn2 vom Anwendungsserver zum Webserver über AZF2 geleitet wird |
Sie müssen zudem Routingtabellen für die Subnetze in onpremvnet erstellen, um das lokale Rechenzentrum zu imitieren.
onpremsn1udr
| Destination | Nächster Hop | Erklärung |
|---|---|---|
| 192.168.2.0/24 | 192.168.1.4 | Ermöglicht den Datenverkehr zu onpremsn2 über OPFW |
onpremsn2udr
| Destination | Nächster Hop | Erklärung |
|---|---|---|
| 10.0.3.0/24 | 192.168.2.4 | Ermöglicht den Datenverkehr zum Back-End-Subnetz in Azure über OPFW |
| 192.168.1.0/24 | 192.168.2.4 | Ermöglicht den Datenverkehr zu onpremsn1 über OPFW |
SSL-Weiterleitung
Routingtabellen und IP-Weiterleitung sind Features, die Sie kombiniert nutzen können, um über virtuelle Geräte den Datenverkehrsfluss in einem Azure-VNet zu steuern. Ein virtuelles Gerät ist letztlich nur ein virtueller Computer, der eine Anwendung zur Verarbeitung des Netzwerkverkehrs ausführt, z. B. eine Firewall oder ein NAT-Gerät.
Diese VM muss eingehenden Datenverkehr empfangen können, der nicht an sie selbst adressiert ist. Damit ein virtueller Computer an andere Ziele gerichteten Datenverkehr empfangen kann, müssen Sie für den virtuellen Computer die IP-Weiterleitung aktivieren. Diese Einstellung ist eine Azure-Einstellung, keine Einstellung im Gastbetriebssystem. Auf dem virtuellen Gerät muss dennoch eine Anwendung zum Verarbeiten und zur entsprechenden Weiterleitung des eingehenden Datenverkehrs ausgeführt werden.
Weitere Informationen zur IP-Weiterleitung finden Sie unter Datenverkehrsrouting in virtuellen Azure-Netzwerken.
Als Beispiel soll die folgende Konfiguration in einem Azure-VNET dienen:
Das Subnetz onpremsn1 enthält einen virtuellen Computer mit dem Namen onpremvm1.
Das Subnetz onpremsn2 enthält einen virtuellen Computer mit dem Namen onpremvm2.
Ein virtuelles Gerät mit dem Namen OPFW ist mit onpremsn1 und onpremsn2 verbunden.
Eine mit onpremsn1 verbundene benutzerdefinierte Route gibt an, dass der gesamte Datenverkehr für onpremsn2 an OPFW geleitet werden muss.
Wenn nun onpremvm1 versucht, eine Verbindung mit onpremvm2 herzustellen, wird die benutzerdefinierte Route verwendet, und der Datenverkehr wird an OPFW als nächsten Hop gesendet. Bedenken Sie dabei, dass das eigentliche Paketziel nicht geändert wird, als Ziel ist weiterhin onpremvm2 angegeben.
Wenn keine IP-Weiterleitung für OPFW aktiviert ist, werden die Pakete in der Programmlogik des virtuellen Azure-Netzwerks ignoriert, da Pakete nur an eine VM gesendet werden können, wenn die IP-Adresse der VM als Ziel für das Paket festgelegt ist.
Mit IP-Weiterleitung werden die Pakete an OPFW weitergeleitet, ohne dass die ursprüngliche Zieladresse geändert wird. OPFW muss die Pakete verarbeiten. Zudem muss festgelegt werden, wie mit den Paketen weiter verfahren wird.
Damit das oben beschriebene Szenario erfolgreich implementiert wird, müssen Sie IP-Weiterleitung für die NICs für OPFW, AZF1, AZF2 und AZF3 aktivieren, die für Routing verwendet werden (also alle NICs mit Ausnahme derjenigen, die mit dem Verwaltungssubnetz verbunden sind).
Firewallregeln
Wie oben beschrieben, wird mit IP-Weiterleitung nur sichergestellt, dass Pakete an die virtuellen Geräte gesendet werden. Auf den virtuellen Geräten muss dennoch festgelegt werden, wie mit diesen Paketen weiter verfahren wird. Im Szenario oben müssen Sie die folgenden Regeln in den virtuellen Geräten erstellen:
OPFW
OPFW stellt ein lokales Gerät dar, für das folgende Regeln definiert sind:
Route: Der gesamte Datenverkehr an 10.0.0.0/16 (azurevnet) muss über den Tunnel ONPREMAZURE geleitet werden.
Richtlinie: Zulassen des gesamten bidirektionalen Datenverkehrs zwischen port2 und ONPREMAZURE.
AZF1
AZF1 stellt ein virtuelles Azure-Gerät dar, für das folgende Regeln definiert sind:
- Richtlinie: Zulassen des gesamten bidirektionalen Datenverkehrs zwischen port1 und port2.
AZF2
AZF2 stellt ein virtuelles Azure-Gerät dar, für das folgende Regeln definiert sind:
- Richtlinie: Zulassen des gesamten bidirektionalen Datenverkehrs zwischen port1 und port2.
AZF3
AZF3 stellt ein virtuelles Azure-Gerät dar, für das folgende Regeln definiert sind:
- Route: Der gesamte Datenverkehr an 192.168.0.0/16 (onpremvnet) muss über port1 an die IP-Adresse des Azure-Gateways (d. h. 10.0.0.1) geleitet werden.
Netzwerksicherheitsgruppen
In diesem Szenario werden keine Netzwerksicherheitsgruppen (NSGs) verwendet. Sie können jedoch Netzwerksicherheitsgruppen auf jedes Subnetz anwenden, um den ein- und ausgehenden Datenverkehr zu beschränken. So können Sie beispielsweise die folgende NSG-Regel auf das externe FW-Subnetz anwenden.
Eingehend
Zulassen des gesamten TCP-Datenverkehrs aus dem Internet an Port 80 auf allen virtuellen Computern im Subnetz.
Verweigern des gesamten anderen Datenverkehrs aus dem Internet.
Ausgehend
- Verweigern des gesamten Datenverkehrs in das Internet.
Schritte auf oberer Ebene:
Führen Sie zum Bereitstellen dieses Szenarios die folgenden allgemeinen Schritte aus.
Melden Sie sich bei Ihrem Azure-Abonnement an.
Wenn Sie ein VNet zum Simulieren des lokalen Netzwerks bereitstellen möchten, stellen Sie die Ressourcen bereit, die zu ONPREMRG gehören.
Stellen Sie die Ressourcen bereit, die zu AZURERG gehören.
Stellen Sie den Tunnel zwischen onpremvnet und azurevnet bereit.
Nachdem Sie alle Ressourcen angegeben haben, melden Sie sich bei onpremvm2 an, und pingen Sie 10.0.3.101, um die Verbindung zwischen onpremsn2 und azsn3 zu testen.