Optimieren des Datenverkehrsflusses mit dem Microsoft Entra-Anwendungsproxy
Erfahren Sie mehr über die Optimierung des Datenverkehrsflusses und die Netzwerktopologie bei Verwendung des Microsoft Entra-Anwendungsproxys.
Datenverkehrsfluss
Wenn eine Anwendung über den Microsoft Entra-Anwendungsproxy veröffentlicht wird, fließt der gesamte Datenverkehr von den Benutzer*innen zu den Anwendungen über drei Verbindungen:
- Die Benutzer*innen stellen eine Verbindung mit dem öffentlichen Endpunkt des Microsoft Entra-Anwendungsproxy-Diensts in Azure her.
- Der private Netzwerkconnector stellt eine Verbindung mit dem Anwendungsproxydienst (ausgehend) her.
- Der private Netzwerkconnector stellt eine Verbindung mit der Zielanwendung her.
Optimieren von Connectorgruppen zur Verwendung des nächstgelegenen Anwendungsproxy-Clouddiensts
Wenn Sie sich für einen Microsoft Entra-Mandanten registrieren, wird die Region Ihres Mandanten durch die von Ihnen ausgewählte Region bestimmt. Die Standardinstanzen des Anwendungsproxy-Clouddiensts verwenden dieselbe oder nächstgelegene Region wie Ihr Microsoft Entra-Mandant.
Wenn die Region Ihres Microsoft Entra-Mandanten z. B. „Vereinigtes Königreich“ lautet, werden alle Ihre privaten Netzwerkconnectors standardmäßig Dienstinstanzen in europäischen Rechenzentren zugewiesen. Wenn Ihre Benutzer auf veröffentlichte Anwendungen zugreifen, wird der Datenverkehr über die Clouddienstinstanzen des Anwendungsproxys in dieser Region geleitet.
Wenn Sie Connectors in Regionen installiert haben, die sich von Ihrer Standardregion unterscheiden, kann eine Änderung der Region, für die Ihre Connectorgruppe optimiert ist, von Vorteil sein, um die Leistung beim Zugriff auf diese Anwendungen zu verbessern. Sobald eine Region für eine Connectorgruppe angegeben ist, verbindet sie sich mit den Clouddiensten des Anwendungsproxys in der angegebenen Region.
Um den Datenverkehrsfluss zu optimieren und die Wartezeit für eine Connectorgruppe zu verkürzen, weisen Sie die Connectorgruppe der nächstgelegenen Region zu. So weisen Sie eine Region zu
Wichtig
Für diese Funktion müssen Connectors mindestens die Version 1.5.1975.0 haben.
Melden Sie sich beim Microsoft Entra Admin Center mindestens mit der Rolle Anwendungsadministrator an.
Wählen Sie rechts oben Ihren Benutzernamen aus. Stellen Sie sicher, dass Sie an einem Verzeichnis angemeldet sind, für das der Anwendungsproxy verwendet wird. Wenn Sie das Verzeichnis wechseln möchten, wählen Sie Verzeichnis wechseln und anschließend ein Verzeichnis aus, für das der Anwendungsproxy verwendet wird.
Navigieren Sie zu Identität>Anwendungen>Unternehmensanwendungen>Anwendungsproxy.
Wählen Sie Neue Connectorgruppe aus, und geben Sie einen Namen für die Connectorgruppe an.
Wählen Sie als Nächstes unter Erweiterte Einstellungen das Dropdownmenü unter „Für eine bestimmte Region optimieren“ und anschließend die den Connectors am nächsten liegende Region aus. Klicken Sie dann auf Speichern.
Wählen Sie die Connectors aus, die der Connectorgruppe zugewiesen werden sollen.
Sie können Connectors nur dann in Ihre Connectorgruppe verschieben, wenn sich diese in der Standardregion befindet. Beginnen Sie mit einem Connector in der Standardconnectorgruppe. Verschieben Sie sie dann in die entsprechende Connectorgruppe.
Sie können die Region einer Connectorgruppe nur ändern, wenn ihr keine Connectors oder Anwendungen zugewiesen sind.
Weisen Sie die Connectorgruppe Ihren Anwendungen zu. Der Datenverkehr wird an den Anwendungsproxy-Clouddienst in der Region der optimierten Connectorgruppe.
Reduzieren der Wartezeit
Für alle Proxylösungen kommt es in Bezug auf Ihre Netzwerkverbindungen zu Wartezeit. Unabhängig davon, welche Proxy- oder VPN-Lösung Sie als Lösung für den Remotezugriff wählen, ist immer eine Gruppe von Servern vorhanden, mit denen die Verbindung mit Ihrem Unternehmensnetzwerk ermöglicht wird.
Organisationen integrieren ihre Serverendpunkte normalerweise in ihr Umkreisnetzwerk. Beim Microsoft Entra-Anwendungsproxy fließt der Datenverkehr jedoch über den Proxydienst in der Cloud, während sich die Connectors in Ihrem Unternehmensnetzwerk befinden. Es ist kein Umkreisnetzwerk erforderlich.
Die nächsten Abschnitte enthalten weitere Vorschläge dazu, wie Sie die Wartezeit noch weiter reduzieren können.
Platzierung von Connectors
Der Anwendungsproxy wählt den Standort der Instanzen basierend auf Ihrem Mandantenstandort für Sie aus. Sie können aber entscheiden, wo der Connector installiert werden soll, und die Merkmale der Wartezeit für Ihren Netzwerkdatenverkehr definieren.
Beim Einrichten des Anwendungsproxydiensts sollten Sie die folgenden Fragen stellen:
- Wo befindet sich die App?
- Wo befinden sich die meisten Benutzer, die auf die App zugreifen?
- Wo befindet sich die Anwendungsproxyinstanz?
- Verfügen Sie bereits über eine dedizierte Netzwerkverbindung mit Microsoft-Rechenzentren, z. B. Azure ExpressRoute oder ein ähnliches VPN?
Der Connector muss sowohl mit Microsoft Entra ID als auch mit Ihren Anwendungen kommunizieren. Die Schritte 2 und 3 stellen die Kommunikation im Datenverkehrsflussdiagramm dar. Die Platzierung des Connectors wirkt sich auf die Wartezeit dieser beiden Verbindungen aus. Beachten Sie die folgenden Punkte, wenn Sie die Platzierung des Connectors festlegen:
- Stellen Sie die „Sichtverbindung“ zwischen dem Connector und dem Rechenzentrum für eingeschränkte Kerberos-Delegierung (KCD) sicher. Darüber hinaus muss der Connectorserver in die Domäne eingebunden sein.
- Installieren Sie den Connector so nah wie möglich an der Anwendung.
Allgemeiner Ansatz zum Verringern der Wartezeit
Minimieren Sie die Wartezeit des End-to-End-Datenverkehrs, indem Sie die einzelnen Netzwerkverbindungen optimieren.
- Reduzieren Sie den Abstand zwischen den beiden Enden des Hops.
- Wählen Sie das richtige zu durchlaufende Netzwerk aus. Wenn anstelle des öffentlichen Internets beispielsweise ein privates Netzwerk durchlaufen wird, erfolgt dies aufgrund von dedizierten Verbindungen möglicherweise schneller.
Erwägen Sie die Verwendung einer dedizierten VPN- oder ExpressRoute-Verbindung zwischen Microsoft und Ihrem Unternehmensnetzwerk.
Präzises Ausrichten Ihrer Optimierungsstrategie
Sie können nicht viel tun, um die Verbindung zwischen Ihren Benutzern und dem Anwendungsproxydienst zu steuern. Benutzer können auf Ihre Apps über ein privates Netzwerk, in einem Café oder von einer anderen Region aus zugreifen. Stattdessen können Sie die Verbindungen vom Anwendungsproxydienst mit den privaten Netzwerkconnectors und den Apps optimieren. Halten Sie sich bei der Einrichtung Ihrer Umgebung an folgende Muster.
Muster 1: Platzieren des Connectors in der Nähe der Anwendung
Platzieren Sie den Connector so nah wie möglich an der Zielanwendung im Kundennetzwerk. Mit dieser Konfiguration wird der Aufwand für Schritt 3 im Topografiediagramm verringert, da der Connector und die Anwendung nicht weit voneinander entfernt sind.
Wenn Ihr Connector über eine „Sichtlinie“ zum Domänencontroller verfügen muss, ist dieses Muster vorteilhaft. Sehr viele unserer Kunden verwenden dieses Muster, weil es für die meisten Szenarien gut funktioniert. Das Muster kann auch mit Muster 2 kombiniert werden, um den Datenverkehr zwischen dem Dienst und dem Connector zu optimieren.
Muster 2: Nutzen von ExpressRoute mit Microsoft-Peering
Wenn Sie ExpressRoute mit Microsoft-Peering eingerichtet haben, können Sie die schnellere ExpressRoute-Verbindung für den Datenverkehr zwischen Anwendungsproxy und Connector verwenden. Der Connector befindet sich weiterhin in Ihrem Netzwerk, in der Nähe der App.
Muster 3: Nutzen von ExpressRoute mit privatem Peering
Wenn Sie über ein dediziertes VPN- oder ExpressRoute-Setup mit privatem Peering zwischen Azure und Ihrem Unternehmensnetzwerk verfügen, haben Sie eine weitere Option. Bei dieser Konfiguration wird das virtuelle Netzwerk in Azure normalerweise als Erweiterung des Unternehmensnetzwerks angesehen. Sie können den Connector also im Azure-Rechenzentrum installieren und für die Verbindung vom Connector zur App trotzdem die Anforderungen an eine geringe Latenz erfüllen.
Die Wartezeit wird nicht negativ beeinträchtigt, weil der Datenverkehr über eine dedizierte Verbindung fließt. Auch die Latenz zwischen Anwendungsproxydienst und Connector wird verbessert, da der Connector in einem Azure-Rechenzentrum in der Nähe des Standorts Ihres Microsoft Entra-Mandanten installiert ist.
Andere Ansätze
Der Schwerpunkt dieses Artikels ist zwar die Anordnung des Connectors, aber Sie können die Anordnung der Anwendung auch ändern, um bessere Wartezeiteigenschaften zu erhalten.
Immer mehr Organisationen verschieben ihre Netzwerke in gehostete Umgebungen. Auf diese Weise können sie ihre Apps in einer gehosteten Umgebung anordnen, die gleichzeitig Teil ihres Unternehmensnetzwerks ist und sich noch innerhalb der Domäne befindet. In diesem Fall können die in den vorherigen Abschnitten beschriebenen Muster auf den neuen Anwendungsspeicherort angewendet werden. Informationen zu diesem Ansatz finden Sie unter Microsoft Entra Domain Services.
Erwägen Sie außerdem, Ihre Connectors mithilfe von Connectorgruppen für Apps zu organisieren, die sich an verschiedenen Standorten bzw. in verschiedenen Netzwerken befinden.
Diagramme für gängige Anwendungsfälle
In diesem Abschnitt werden einige häufige Szenarien beschrieben. Angenommen, der Microsoft Entra-Mandant (und somit auch der Proxy-Dienstendpunkt) befindet sich in den USA. Die in diesen Anwendungsfällen beschriebenen Aspekte gelten normalerweise auch für andere Regionen weltweit.
Für diese Szenarien werden die einzelnen Verbindungen als „Hop“ bezeichnet und zur Vereinfachung der Erklärungen durchnummeriert:
- Hop 1: vom Benutzer zum Anwendungsproxydienst
- Hop 2: vom Anwendungsproxydienst zum privaten Netzwerkconnector
- Hop 3: vom privaten Netzwerkconnector zur Zielanwendung
Anwendungsfall 1
Szenario: Die App befindet sich in den USA im Netzwerk einer Organisation mit Benutzern in derselben Region. Zwischen dem Azure-Datencenter und dem Unternehmensnetzwerk besteht keine ExpressRoute- oder VPN-Verbindung.
Empfehlung: Verwenden Sie Muster 1, das im vorherigen Abschnitt beschrieben wird. Erwägen Sie ggf. die Verwendung von ExpressRoute, um die Wartezeit zu verbessern.
Optimieren Sie Hop 3, indem Sie den Connector in der Nähe der App platzieren. Der Connector wird in der Regel mit einer „Sichtverbindung“ zur App und zum Rechenzentrum installiert, um KCD-Vorgänge durchführen zu können.
Anwendungsfall 2
Szenario: Die App befindet sich in den USA im Netzwerk einer Organisation, und die Benutzer sind weltweit verteilt. Zwischen dem Azure-Datencenter und dem Unternehmensnetzwerk besteht keine ExpressRoute- oder VPN-Verbindung.
Empfehlung: Verwenden Sie Muster 1, das im vorherigen Abschnitt beschrieben wird.
Das am häufigsten verwendete Muster ist wieder die Optimierung von Hop 3, bei dem Sie den Connector in der Nähe der App anordnen. Hop 3 ist normalerweise nicht mit hohen Kosten verbunden, wenn sich alles in derselben Region abspielt. Die Kosten für Hop 1 können je nach Standort eines Benutzers dagegen höher sein, da Benutzer aus der ganzen Welt auf die Anwendungsproxyinstanz in den USA zugreifen. Hinweis: Alle Proxylösungen verfügen über ähnliche Merkmale, was die weltweite Verteilung von Benutzern betrifft.
Anwendungsfall 3
Szenario: Die App befindet sich im Netzwerk einer Organisation in den USA. ExpressRoute mit Microsoft-Peering ist zwischen Azure und dem Unternehmensnetzwerk vorhanden.
Empfehlung: Verwenden Sie die Muster 1 und 2, die im vorherigen Abschnitt beschrieben werden.
Platzieren Sie den Connector zuerst so nah wie möglich an der App. Für Hop 2 wird automatisch ExpressRoute verwendet.
Wenn für die ExpressRoute-Verbindung das Microsoft-Peering verwendet wird, fließt der Datenverkehr zwischen dem Proxy und dem Connector über diese Verbindung. Die Wartezeit bei Hop 2 ist optimal.
Anwendungsfall 4
Szenario: Die App befindet sich im Netzwerk einer Organisation in den USA. ExpressRoute mit privatem Peering ist zwischen Azure und dem Unternehmensnetzwerk vorhanden.
Empfehlung: Verwenden Sie Muster 3, das im vorherigen Abschnitt beschrieben wird.
Platzieren Sie den Connector in dem Azure-Datencenter, das über das private ExpressRoute-Peering mit dem Unternehmensnetzwerk verbunden ist.
Der Connector kann im Azure-Datencenter angeordnet werden. Da der Connector weiterhin über das private Netzwerk über eine Sichtverbindung mit der Anwendung und dem Datencenter verfügt, bleibt Hop 3 optimiert. Darüber hinaus wird Hop 2 weiter optimiert.
Anwendungsfall 5
Szenario: Die App befindet sich im Netzwerk einer Organisation in Europa, die Standardregion des Mandanten sind die USA, die meisten Benutzer befinden sich in Europa.
Empfehlung: Platzieren Sie den Connector in der Nähe der App. Aktualisieren Sie die Connectorgruppe so, dass sie für die Verwendung von Dienstinstanzen des Anwendungsproxys in Europa optimiert ist. Anweisungen finden Sie unter Optimieren von Connectorgruppen zur Verwendung des nächstgelegenen Anwendungsproxy-Clouddiensts.
Da Benutzer in Europa auf eine Anwendungsproxyinstanz zugreifen, die sich in derselben Region befindet, sind die Kosten für Hop 1 nicht hoch. Hop 3 ist optimiert. Erwägen Sie die Verwendung von ExpressRoute zur Optimierung von Hop 2.
Anwendungsfall 6
Szenario: Die App befindet sich im Netzwerk einer Organisation in Europa, die Standardregion des Mandanten sind die USA, die meisten Benutzer befinden sich in den USA.
Empfehlung: Platzieren Sie den Connector in der Nähe der App. Aktualisieren Sie die Connectorgruppe so, dass sie für die Verwendung von Dienstinstanzen des Anwendungsproxys in Europa optimiert ist. Anweisungen finden Sie unter Optimieren von Connectorgruppen zur Verwendung des nächstgelegenen Anwendungsproxy-Clouddiensts. Die Kosten für Hop 1 können höher ausfallen, da alle Benutzer in den USA auf die Anwendungsproxyinstanz in Europa zugreifen müssen.
In dieser Situation können Sie auch eine andere Variante verwenden. Wenn sich die meisten Benutzer der Organisation in den USA befinden, ist die Wahrscheinlichkeit hoch, dass auch Ihr Netzwerk bis in die USA reicht. Platzieren Sie den Connector in den USA, nutzen Sie weiterhin die Standardregion USA für Ihre Connectorgruppen, und verwenden Sie die interne Standleitung des Firmennetzwerks mit der Anwendung in Europa. Auf diese Weise werden die Hops 2 und 3 optimiert.