Azure Firewall-Szenarien zur Untersuchung des Datenverkehr zu einem privaten Endpunkt
Hinweis
Informationen zum Schützen von Datenverkehr zu privaten Endpunkten in Azure Virtual WAN mithilfe eines geschützten virtuellen Hubs finden Sie unter Schützen von Datenverkehr, der für private Endpunkte von Azure Virtual WAN bestimmt ist.
Der private Azure-Endpunkt ist der grundlegende Baustein für Azure Private Link. Private Endpunkte ermöglichen die Bereitstellung von Azure-Ressourcen in einem virtuellen Netzwerk, um privat mit Private Link-Ressourcen zu kommunizieren.
Private Endpunkte ermöglichen Ressourcenzugriff auf den Private Link-Dienst, der in einem virtuellen Netzwerk bereitgestellt wird. Der Zugriff auf den privaten Endpunkt durch Peering virtueller Netzwerke und lokale Netzwerkverbindungen erweitern die Konnektivität.
Möglicherweise müssen Sie den Datenverkehr von Clients zu den über private Endpunkte verfügbar gemachten Diensten untersuchen oder blockieren. Schließen Sie diese Untersuchung ab, indem Sie Azure Firewall oder ein virtuelles Netzwerkgerät eines Drittanbieters verwenden.
Es gelten die folgenden Einschränkungen:
Datenverkehr von Netzwerksicherheitsgruppen (NSG) wird von privaten Endpunkten umgangen, da Netzwerkrichtlinien für ein Subnetz in einem virtuellen Netzwerk standardmäßig deaktiviert sind. Damit Netzwerkrichtlinien wie benutzerdefinierte Routen- und Netzwerksicherheitsgruppen-Unterstützung genutzt werden können, muss die Netzwerkrichtlinienunterstützung für das Subnetz aktiviert sein. Diese Einstellung gilt nur für private Endpunkte innerhalb des Subnetzes. Diese Einstellung wirkt sich auf alle privaten Endpunkte innerhalb des Subnetzes aus. Für andere Ressourcen im Subnetz wird der Zugriff basierend auf Sicherheitsregeln in der Netzwerksicherheitsgruppe gesteuert.
Der Datenverkehr von benutzerdefinierten Routen (user-defined routes, UDR) wird von privaten Endpunkten umgangen. Benutzerdefinierte Routen können verwendet werden, um Datenverkehr zu überschreiben, der für den privaten Endpunkt bestimmt ist.
Eine einzelne Routingtabelle kann an ein Subnetz angefügt werden
Eine Routingtabelle unterstützt bis zu 400 Routen
Azure Firewall filtert den Datenverkehr mit einer der folgenden Optionen:
FQDN in Netzwerkregeln für TCP- und UDP-Protokolle
FQDN in Anwendungsregeln für HTTP, HTTPS und MSSQL.
Wichtig
Es wird empfohlen Anwendungsregeln anstelle von Netzwerkregeln wird empfohlen, wenn Sie Datenverkehr überprüfen, der an private Endpunkte gerichtet ist, um die Flusssymmetrie zu erhalten. Anwendungsregeln werden gegenüber Netzwerkregeln bevorzugt, um Datenverkehr zu überprüfen, der an private Endpunkte gerichtet ist, da Azure Firewall Datenverkehr mit Anwendungsregeln immer per SNAT neu schreibt. Wenn Netzwerkregeln verwendet werden oder eine NVA anstelle der Azure Firewall verwendet wird, muss SNAT für Datenverkehr konfiguriert werden, der an private Endpunkte gerichtet ist, um die Flowsymmetrie aufrechtzuerhalten.
Hinweis
Die SQL-FQDN-Filterung wird nur im Proxymodus unterstützt (Port 1433). Im Modus Proxy kommt es unter Umständen zu längeren Wartezeiten als im Modus Umleiten. Wenn Sie weiterhin den Umleitungsmodus (Standardmodus für Clients, die eine Verbindung innerhalb von Azure herstellen) verwenden möchten, können Sie den Zugriff mit dem FQDN in Netzwerkregeln der Firewall filtern.
Szenario 1: Hub-and-Spoke-Architektur – Dediziertes virtuelles Netzwerk für private Endpunkte
Dieses Szenario ist die erweiterbarste Architektur, um über private Endpunkte eine private Verbindung mit mehreren Azure-Diensten herzustellen. Es wird eine Route erstellt, die auf den Netzwerkadressraum verweist, in dem die privaten Endpunkte bereitgestellt werden. Diese Konfiguration reduziert den Verwaltungsaufwand und verhindert, dass die Grenze von 400 Routen erreicht wird.
Für Verbindungen von einem virtuellen Client-Netzwerk zur Azure Firewall in einem virtuellen Hub-Netzwerk fallen Gebühren an, wenn die virtuellen Netzwerke gepeert werden. Verbindungen von Azure Firewall in einem virtuellen Hub-Netzwerk zu privaten Endpunkten in einem virtuellen Netzwerk mit Peer-Rechten werden nicht berechnet.
Weitere Informationen zu den Gebühren im Zusammenhang mit Verbindungen mit virtuellen Netzwerken finden Sie im Abschnitt mit den häufig gestellten Fragen auf der Seite Preise.
Szenario 2: Hub-and-Spoke-Architektur – Freigegebenes virtuelles Netzwerk für private Endpunkte und virtuelle Computer
Dieses Szenario wird in folgenden Situationen implementiert:
Es ist nicht möglich, ein dediziertes virtuelles Netzwerk für die privaten Endpunkte zu verwenden
Wenn nur einige wenige Dienste im virtuellen Netzwerk über private Endpunkte verfügbar sind
Die VMs werden über /32 Systemrouten verfügen, die auf jeden privaten Endpunkt zeigen. Eine Route pro privatem Endpunkt ist so konfiguriert, dass der Datenverkehr durch Azure Firewall geleitet wird.
Der Verwaltungsaufwand für die Wartung der Routingtabelle nimmt zu, da die Dienste im virtuellen Netzwerk verfügbar gemacht werden. Auch die Möglichkeit, den Routengrenzwert zu erreichen, nimmt zu.
Abhängig von Ihrer Gesamtarchitektur ist es möglich, den Grenzwert von 400 Routen zu erreichen. Es wird empfohlen, wann immer möglich Szenario 1 zu verwenden.
Für Verbindungen von einem virtuellen Client-Netzwerk zur Azure Firewall in einem virtuellen Hub-Netzwerk fallen Gebühren an, wenn die virtuellen Netzwerke gepeert werden. Verbindungen von Azure Firewall in einem virtuellen Hub-Netzwerk zu privaten Endpunkten in einem virtuellen Netzwerk mit Peer-Rechten werden nicht berechnet.
Weitere Informationen zu den Gebühren im Zusammenhang mit Verbindungen mit virtuellen Netzwerken finden Sie im Abschnitt mit den häufig gestellten Fragen auf der Seite Preise.
Szenario 3: Einzelnes virtuelles Netzwerk
Verwenden Sie dieses Muster, wenn eine Migration zu einer Hub-and-Spoke-Architektur nicht möglich ist. Es gelten dieselben Überlegungen wie in Szenario 2. In diesem Szenario fallen keine Gebühren für das Peering virtueller Netzwerke an.
Szenario 4: Lokaler Datenverkehr zu privaten Endpunkten
Diese Architektur kann implementiert werden, wenn Sie die Konnektivität mit Ihrem lokalen Netzwerk über eine der beiden folgenden Optionen konfiguriert haben:
Wenn Ihre Sicherheitsanforderungen erfordern, dass der Datenverkehr von Clients zu Diensten, die über private Endpunkte verfügbar gemacht werden, über eine Sicherheitsappliance geleitet wird, stellen Sie dieses Szenario bereit.
Es gelten dieselben Überlegungen wie oben in Szenario 2. In diesem Szenario fallen keine Gebühren für das Peering virtueller Netzwerke an. Weitere Informationen zur Konfiguration Ihrer DNS-Server, um lokalen Workloads den Zugriff auf private Endpunkte zu ermöglichen, finden Sie unter Lokale Workloads mithilfe von DNS-Weiterleitungen.
Nächste Schritte
In diesem Artikel haben Sie verschiedene Szenarien untersucht, mit denen Sie den Datenverkehr zwischen einem virtuellen Computer und einem privaten Endpunkt mit Azure Firewall einschränken können.
Ein Tutorial zum Konfigurieren von Azure Firewall zum Überprüfen des an einen privaten Endpunkt gerichteten Datenverkehrs finden Sie unter Tutorial: Überprüfen des Datenverkehrs von privaten Endpunkten mit Azure Firewall
Weitere Informationen zu privaten Endpunkten finden Sie unter Was ist ein privater Endpunkt in Azure?.