Freigeben über

Szenario für virtuelle Geräte

  • Artikel

Häufig 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 aus einem lokalen Rechenzentrum ermöglicht. In diesem Artikel 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:

  • Eine Webanwendung darf nur über das öffentliche Internet zugänglich sein.
  • Ein Webserver, auf dem die Anwendung gehostet wird, muss auf einen Back-End-Anwendungsserver Zugriff haben.
  • Der gesamte Datenverkehr aus dem Internet an die Webanwendung muss ein virtuelles Firewallgerät durchlaufen. Dieses virtuelle Gerät wird ausschließlich für Internetdatenverkehr verwendet.
  • Der gesamte Datenverkehr an den Anwendungsserver muss ein virtuelles Firewallgerät durchlaufen. 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 verwendet.
  • 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 verwenden.

Dieses Beispiel zeigt ein Umkreisnetzwerk-Standardszenario (auch als DMZ bezeichnet) mit einer DMZ und einem geschützten Netzwerk. Sie können dieses Szenario in Azure erstellen, indem Sie Netzwerksicherheitsgruppen (NSGs), virtuelle Firewallgeräte oder eine Kombination aus beiden verwenden.

In der folgenden Tabelle werden einige Vor- und Nachteile von Netzwerksicherheitsgruppen und virtuellen Firewallgeräten aufgeführt.

Artikel Vorteile Nachteile
NSG Keine Kosten.
Integriert in die rollenbasierte Zugriffssteuerung in Azure
Möglichkeit zum Erstellen von Regeln in Azure Resource Manager-Vorlagen		 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 die rollenbasierte Zugriffssteuerung in Azure

In der folgenden Lösung wird ein Szenario mit einem Umkreisnetzwerk (DMZ) bzw. ein geschütztes Netzwerk mithilfe virtueller Firewallgeräte implementiert.

Überlegungen

Sie können obige Umgebung in Azure bereitstellen, indem Sie bereits verfügbare Features verwenden:

  • Virtuelles Netzwerk: Ein virtuelles Azure-Netzwerk verhält sich ähnlich wie ein lokales Netzwerk. Sie können es in Subnetze segmentieren, 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. Sie können diese Routingtabellen auf Subnetze anwenden. Sie können eine Routingtabelle auf das GatewaySubnet anwenden, das den gesamten Datenverkehr, der im virtuellen Azure-Netzwerk von einer Hybridverbindung eingeht, an ein virtuelles Gerät weiterleitet.
  • IP-Weiterleitung: Mit der Azure-Netzwerk-Engine werden Pakete standardmäßig nur an virtuelle Netzwerkschnittstellen (NICs) weitergeleitet, wenn die Ziel-IP-Adresse der Pakete der IP-Adresse der NIC entspricht. Wenn 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: Im folgenden Beispiel werden keine NSGs verwendet, Sie können jedoch NSGs verwenden, die auf die Subnetze oder NICs in dieser Lösung angewandt werden. Die NSGs filtern den Datenverkehr an diese Subnetze und NICs und aus diesen Subnetzen und NICs weiter.

Darstellung der IPv6-Konnektivität

In diesem Beispiel enthält ein Abonnement folgende Komponenten:

  • Zwei Ressourcengruppen (in der Abbildung nicht dargestellt):

    • 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 segmentiert ist, um ein lokales Rechenzentrum zu simulieren:

    • onpremsn1 ist ein Subnetz mit einer VM, auf der eine Linux-Distribution ausgeführt wird, um einen lokalen Server zu imitieren.
    • onpremsn2 ist ein Subnetz mit einer VM, auf der eine Linux-Distribution ausgeführt wird, um einen von einem Administrator verwendeten lokalen Computer zu imitieren.

  • Ein virtuelles Firewallgerät namens OPFW in onpremvnet. Es dient dazu, einen Tunnel mit azurevnet aufrechtzuerhalten.

  • Ein virtuelles Netzwerk namens azurevnet, das wie folgt segmentiert ist:

    • azsn1 ist ein 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 Netzwerkschnittstelle, die mit der externen Firewall verknüpft ist.
    • azsn2 ist ein Front-End-Subnetz, in dem eine als Webserver ausgeführte VM gehostet wird, auf die über das Internet zugegriffen wird.
    • azsn3 ist ein 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 ist ein Verwaltungssubnetz, das ausschließlich für die Bereitstellung des Verwaltungszugriffs auf alle virtuellen Firewallgeräte verwendet wird. Dieses Subnetz enthält jeweils nur eine NIC für die in der Lösung verwendeten virtuellen Firewallgeräte.
    • GatewaySubnet ist ein Subnetz für Azure-Hybridverbindungen, das für Azure ExpressRoute und Azure VPN Gateway erforderlich ist, um die Konnektivität zwischen virtuellen Azure-Netzwerken und anderen Netzwerken zu gewährleisten.

  • Im Netzwerk azurevnet befinden sich drei virtuelle Firewallgeräte:

    • AZF1 ist 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 dem Azure Marketplace oder direkt vom Geräteanbieter, über die ein virtuelles Gerät mit drei NICs bereitgestellt wird.
    • AZF2 ist eine 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 ist eine 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. Sie finden Vorlagen für virtuelle Geräte mit zwei NICs im Azure Marketplace. Sie können sie auch direkt von Ihrem Geäteanbieter anfordern.

Routentabellen

Verknüpfen Sie jedes Subnetz in Azure mit einer Routingtabelle, in der definiert wird, wie der im jeweiligen Subnetz initiierte Datenverkehr weitergeleitet wird. Wenn keine benutzerdefinierten Routen definiert sind, verwendet Azure Standardrouten, 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. Es ist nur eine Route in GatewaySubnet erforderlich, wie hier gezeigt:

Destination Nächster Hop Erklärung
10.0.4.0/24 10.0.3.11 Ermöglicht lokalen 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 Datenverkehr an azsn2 vom Anwendungsserver zum Webserver über AZF2

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 Datenverkehr an onpremsn2 über OPFW

onpremsn2udr

Destination Nächster Hop Erklärung
10.0.3.0/24 192.168.2.4 Ermöglicht Datenverkehr zum Back-End-Subnetz in Azure über OPFW
192.168.1.0/24 192.168.2.4 Ermöglicht Datenverkehr an onpremsn1 über OPFW

IP-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 eine VM, die eine Anwendung zur Verarbeitung des Netzwerkverkehrs ausführt, z. B. eine Firewall oder ein NAT-Gerät (Netzwerkadressenübersetzung).

Diese VM muss eingehenden Datenverkehr empfangen können, der nicht an sie selbst adressiert ist. Damit eine VM an andere Ziele gerichteten Datenverkehr empfangen kann, müssen Sie für die VM die IP-Weiterleitung aktivieren. Diese Einstellung ist eine Azure-Einstellung, keine Einstellung im Gastbetriebssystem. Auf dem virtuellen Gerät muss trotzdem 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.

Stellen Sie sich als Beispiel vor, dass Sie über das folgende Setup in einem virtuellen Azure-Netzwerk verfügen:

  • Subnetz onpremsn1 enthält eine VM mit dem Namen onpremvm1.
  • Subnetz onpremsn2 enthält eine VM mit dem Namen onpremvm2.
  • Ein virtuelles Gerät mit dem Namen OPFW ist mit onpremsn1 und onpremsn2 verbunden.
  • Eine mit onpremsn1 verbundene benutzerdefinierte Route (UDR) 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. Das tatsächliche Paketziel bleibt unverändert. onpremvm2 ist weiterhin das Ziel.

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 der Logik der IP-Weiterleitung in Azure werden die Pakete an OPFW weitergeleitet, ohne dass die ursprüngliche Zieladresse geändert wird. OPFW muss die Pakete verarbeiten und festlegen, wie mit den Paketen weiter verfahren wird.

Damit das Szenario oben erfolgreich implementiert wird, müssen Sie die IP-Weiterleitung auf den NICs für OPFW, AZF1, AZF2 und AZF3 aktivieren, die für das 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 auf den Geräten erstellen.

OPFW

OPFW stellt ein lokales Gerät dar, dass die folgenden Regeln enthält:

  • Route: Der gesamte Datenverkehr an 10.0.0.0/16 (azurevnet) muss über den Tunnel ONPREMAZURE gesendet werden.
  • Richtlinie: Zulassen des gesamten bidirektionalen Datenverkehrs zwischen port2 und ONPREMAZURE

AZF1

AZF1 stellt ein virtuelles Azure-Gerät dar, das die folgende Regel enthält:

Richtlinie: Zulassen des gesamten bidirektionalen Datenverkehrs zwischen port1 und port2

AZF2

AZF2 stellt ein virtuelles Azure-Gerät dar, das die folgende Regel enthält:

Richtlinie: Zulassen des gesamten bidirektionalen Datenverkehrs zwischen port1 und port2

AZF3

AZF3 stellt ein virtuelles Azure-Gerät dar, das die folgende Regel enthält:

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 folgenden NSG-Regeln auf das externe Firewallsubnetz anwenden.

Eingehend

  • Zulassen des gesamten TCP-Datenverkehrs aus dem Internet an Port 80 auf allen VMs im Subnetz
  • Verweigern des gesamten anderen Datenverkehrs aus dem Internet

Ausgehend

Verweigern des gesamten Datenverkehrs an das Internet

Wesentliche Schritte

Gehen Sie wie folgt vor, um dieses Szenario zu implementieren:

  1. Melden Sie sich bei Ihrem Azure-Abonnement an.

  2. Wenn Sie ein virtuelles Netzwerk zum Simulieren des lokalen Netzwerks bereitstellen möchten, stellen Sie die Ressourcen bereit, die zu ONPREMRG gehören.

  3. Stellen Sie die Ressourcen bereit, die zu AZURERG gehören.

  4. Stellen Sie den Tunnel von onpremvnet zu azurevnet bereit.

  5. 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.