Erforderliche Komponenten für den Zugriff durch externe Benutzer

 

Letztes Änderungsdatum des Themas: 2012-10-17

Die meisten Edgeserver werden in einem Umkreisnetzwerk bereitgestellt (auch als überwachtes Subnetz bezeichnet). Die Edgetopologie des Umkreisnetzwerks umfasst die folgenden Komponenten. Sofern nicht anders vermerkt, sind die Komponenten Bestandteil aller drei Referenzarchitekturen und befinden sich im Umkreisnetzwerk. Eine Edgetopologie umfasst die folgenden Komponenten:

• Edgeserver

• Reverseproxy

• Lastenausgleich für skalierte Edgetopologien (entweder DNS-Lastenausgleich oder Hardwaregerät zum Lastenausgleich)

• Firewall

• Director (im internen Netzwerk)

Edgeserver

Der Edgeserver steuert den Datenverkehr, der die Firewall passiert, sowie die Verwendung der internen Bereitstellung durch externe Benutzer. Auf dem Edgeserver werden die folgenden Dienste ausgeführt:

• Zugriffs-Edgedienst   Der Zugriffs-Edgedienst stellt einen einzelnen vertrauenswürdigen Verbindungspunkt für ausgehenden und eingehenden SIP-Datenverkehr (Session Initiation Protocol) bereit.

• Webkonferenz-Edgedienst   Der Webkonferenz-Edgedienst ermöglicht externen Benutzern, an Besprechungen teilzunehmen, die in der internen Microsoft Lync Server 2010-Bereitstellung gehostet werden.

• A/V-Edgedienst   Der A/V-Edgedienst ermöglicht Audio, Video, Anwendungsfreigabe und Dateiübertragungen für externe Benutzer. Ihre Benutzer können Audio- und Videodaten zu Besprechungen hinzufügen, an denen externe Benutzer teilnehmen. Außerdem können Audio- und Videodaten in Direktsitzungen mit einem externen Benutzer direkt freigegeben werden. Der A/V-Edgedienst bietet außerdem Unterstützung für Desktopfreigabe und Dateiübertragung.

Autorisierte externe Benutzer können auf die Edgeserver zugreifen, um eine Verbindung mit der internen Lync Server-Bereitstellung herzustellen, die Edgeserver bieten jedoch keinen weiteren Zugriff auf das interne Netzwerk.

Hinweis:

Edgeserver werden bereitgestellt, um aktivierten Lync-Clients und anderen Edgeservern (z. B. in Verbundszenarien) Verbindungen zur Verfügung zu stellen. Sie sind nicht darauf ausgelegt, Verbindungen von anderen Typen von Endpunkt-Clients oder -Servern zuzulassen. Der XMPP-Gateway-Server kann bereitgestellt werden, um Verbindungen mit konfigurierten XMPP-Partnern zuzulassen. Der Edgeserver und das XMPP-Gateway können ausschließlich Endpunktverbindungen von diesen Client- und Verbundtypen unterstützen.

Reverseproxy

Bei einem Reverseproxy handelt es sich um eine für die meisten Szenarien erforderliche Infrastrukturkomponente, die Sie als Teil von Microsoft Lync Server 2010 aktivieren. In den meisten Bereitstellungen wird der vorhandene Reverseproxy verwendet, den Sie bereits installiert und für die Verwendung in Ihrer Organisation konfiguriert haben. Gewöhnlich sind neue Veröffentlichungsregeln erforderlich. Eine Änderung der vorhandenen Proxyserverregeln sollte jedoch nicht erforderlich sein. Zu den Typen von Reverseproxys zählen unter anderem die folgenden:

1. Microsoft Internet and Acceleration Server (ISA) 2006 mit Service Pack 1

   Für das Bereitstellungsbeispiel in Bereitstellung von Edgeservern wird eine grundlegende Microsoft Threat Management Gateway 2010-Konfiguration verwendet. Microsoft Threat Management Gateway 2010 und Microsoft Internet and Acceleration Server (ISA) 2006 mit Service Pack 1 ähneln sich in der Konfiguration der Veröffentlichung für Lync Server 2010. Einzelheiten finden Sie unter Konfigurieren von Webveröffentlichungsregeln für einen einzelnen internen Pool in der Dokumentation zur Bereitstellung.

2. Microsoft Threat Management Gateway (TMG) 2010

   Einzelheiten zum Konfigurieren von Microsoft Threat Management Gateway (TMG) 2010 als Reverseproxy für Ihre Lync Server 2010-Bereitstellungen finden Sie unter Konfigurieren von Webveröffentlichungsregeln für einen einzelnen internen Pool in der Dokumentation zur Bereitstellung.

3. Reverseproxyserver von Drittanbietern, die so konfiguriert werden können, dass sie interne HTTP- und HTTPS-Inhalte veröffentlichen

4. Firewalls von Drittanbietern mit der Fähigkeit zum Veröffentlichen interner HTTP- und HTTPS-Inhalte

5. Andere, nicht aufgeführte Geräte wie etwa Hardwaregeräte zum Lastenausgleich und HTTP-Inhaltsenginemodule bieten möglicherweise ebenfalls die erforderlichen Funktionen.

Informationen zum Konfigurieren von Geräten und Servern von Drittanbietern finden Sie in der Dokumentation des jeweiligen Drittanbieters im Abschnitt über das Konfigurieren der Veröffentlichung.

Wichtig:
Eine gemeinsame Bereitstellung der Edgeserver und eines Reverseproxys ist keine gültige Konfigurationsoption. Die Edgeserver muss als dedizierte Rolle für die Verwaltung des Session Initiation-Protokolls und von Webkonferenz- sowie von Audio/Video-Features (auch andere Medientypen) für Ihre Bereitstellung fungieren.

Der Reverseproxy ermöglicht Folgendes:

• Teilnahme an Besprechungen und Einwahlkonferenzen über einfache URLs

• Herunterladen von Besprechungsinhalten durch externe Benutzer

• Erweiterung von Verteilergruppen durch externe Benutzer

• Abrufen eines benutzerbasierten Zertifikats für die auf Clientzertifikaten basierende Authentifizierung

• Herunterladen von Dateien vom Adressbuchserver oder Senden von Abfragen an den Adressbuch-Webabfragedienst durch Remotebenutzer

• Abrufen von Updates für Client- und Gerätesoftware durch Remotebenutzer

• Automatische Ermittlung von Front-End-Servern, die Mobilitätsdienste anbieten, durch mobile Geräte

• Ermöglichen von Pushbenachrichtigungen an mobile Geräte über Office 365- oder Apple-Pushbenachrichtigungsdienste

Hinweis:
Externe Benutzer benötigen keine VPN-Verbindung mit Ihrer Organisation, um an Lync Server-basierten Kommunikationssitzungen teilzunehmen. Externe Benutzer, die per VPN mit dem internen Netzwerk Ihrer Organisation verbunden sind, umgehen den Reverseproxy.

Firewall

Sie können Ihre Edgetopologie mit nur einer externen Firewall oder sowohl mit einer externen als auch einer internen Firewall bereitstellen. Die Referenzarchitekturen enthalten zwei Firewalls. Die Verwendung von zwei Firewalls ist der empfohlene Ansatz, da bei dieser Architektur ein strenges Routing von einem Netzwerkedge zum anderen sichergestellt wird. Darüber hinaus wird das interne Netzwerk durch zwei Firewallebenen geschützt.

Director

In Lync Server 2010 ist ein Director eine separate Lync Server 2010-Serverrolle, die keine Benutzer verwaltet. Stattdessen fungiert der Director als interner Server für den nächsten Hop, an den Edgeserver eingehenden SIP-Datenverkehr weiterleiten, der für interne Server bestimmt ist. Der Director authentifiziert eingehende Anforderungen und leitet diese an den Homepool oder -server des Benutzers weiter.

Wenn Ihre Organisation den externen Zugriff aktivieren möchte, wird empfohlen, dass Sie einen Director bereitstellen. Da der Director die Authentifizierung des von Remotebenutzern eingehenden SIP-Datenverkehrs übernimmt, senkt er die Datenlast auf den Standard Edition-Servern und Front-End-Servern in Enterprise Edition-Front-End-Pools. Der Director trägt außerdem dazu bei, Standard Edition-Server und Front-End-Server in Enterprise Edition-Front-End-Pools vor möglicherweise bösartigem Datenverkehr zu schützen, beispielsweise bei DoS-Angriffen (Denial of Service). Wenn das Netzwerk während eines solchen Angriffs mit ungültigem externen Datenverkehr überflutet wird, endet dieser Datenverkehr beim Director. Interne Benutzer sollten keine Auswirkungen auf die Leistung wahrnehmen. Ausführliche Informationen zur Verwendung des Directors finden Sie unter Director.

Hardwaregeräte zum Lastenausgleich

Die skalierte konsolidierte Edgetopologie von Lync Server 2010 ist für den DNS-Lastenausgleich optimiert und für neue Bereitstellungen geeignet, die hauptsächlich einen Partnerverbund mit Organisationen eingehen, die Lync Server 2010 verwenden. Wenn für eines der folgenden Szenarien hohe Verfügbarkeit erforderlich ist, muss ein Hardwaregerät zum Lastenausgleich für die Edgeserver-Pools verwendet werden:

• Partnerverbund mit Organisationen, die Office Communications Server 2007 R2 oder Office Communications Server 2007 verwenden

• Exchange UM für Remotebenutzer

• Verbindung mit Benutzern öffentlicher Instant Messaging-Dienste

Informationen dazu, ob Ihr Hardwaregerät zum Lastenausgleich die von Lync Server 2010 benötigten Features unterstützt, finden Sie auf der Seite "Lync Server 2010 Load Balancer Partners" unter https://go.microsoft.com/fwlink/?linkid=202452&clcid=0x407.

Anforderungen an das Hardwaregerät zum Lastenausgleich – Allgemeine Überlegungen

• Die Zielnetzwerk-Adressübersetzung (Destination Network Address Translation, DNAT), von der die eingehende Ziel-IP-Adresse der virtuellen IP (VIP) des Lastenausgleichsmoduls verwendet wird, wird in die Ziel-IP-Adresse des Servers umgewandelt. Vom Hersteller Ihres Lastenausgleichsmoduls wird möglicherweise die Verwendung der Quellnetzwerk-Adressübersetzung (Source NAT, SNAT) vorgeschlagen. Wägen Sie gut ab, welchen NAT-Typ Sie verwenden. Berücksichtigen Sie, dass diese NAT spezifisch für das Hardwaregerät zum Lastenausgleich ist, und dass es sich um eine Beziehung zwischen der VIP des Hardwaregeräts zum Lastenausgleich und den gehosteten Servern handelt. Dieser Typ ist nicht identisch mit der an den Umkreisfirewalls verwalteten NAT.

• Verwenden Sie die Quellaffinität (auch als TCP-Affinität bezeichnet – siehe Dokumentation des jeweiligen Herstellers). Der gesamte Verkehr einer einzigen Sitzung sollte dem gleichen Ziel (d. h. Server) zugeordnet werden. Falls mehrere Sitzungen von einer einzigen Quelle aus verfügbar sind, können die Sitzungen verschiedenen Zielservern zugeordnet werden, wobei die Quellaffinität verwendet wird, um den Status der Sitzung bereitzustellen.

• Das TCP-Leerlauftimeout sollte, falls dies nicht aufgrund anderer Informationen (Leistungsanforderungen, Testdefinitionen, Standards oder Herstellerdokumentation) so festgelegt ist, auf 30 Minuten (1.800 Sekunden) eingestellt werden.

Warnung:
Es ist nicht möglich, für eine Schnittstelle den DNS-Lastenausgleich und für eine andere Schnittstelle ein Hardwaregeräte zum Lastenausgleich zu verwenden. Sie müssen entweder für beide Schnittstellen ein Hardwaregerät zum Lastenausgleich oder für beide Schnittstellen den DNS-Lastenausgleich verwenden. Eine Kombination wird nicht unterstützt.

Hinweis:
Wenn Sie ein Hardwaregerät zum Lastenausgleich einsetzen, muss der Lastenausgleich für Verbindungen mit dem internen Netzwerk so konfiguriert werden, dass nur für den Datenverkehr zum Zugriffs-Edgedienst und dem A/V-Edgedienst ein Lastenausgleich stattfindet. Es kann kein Lastenausgleich für den Datenverkehr zum internen Webkonferenz-Edgedienst durchgeführt werden.

Hinweis:
Die DSR-Netzwerkadressenübersetzung (Direct Server Return) wird für Lync Server 2010 nicht unterstützt.

Anforderungen bei Verwendung eines Hardwaregeräts zum Lastenausgleich für Edgeserver, auf denen der A/V-Edgedienst ausgeführt wird

Im Folgenden sind die Anforderungen bei Verwendung eines Hardwaregeräts zum Lastenausgleich für Edgeservern aufgelistet, auf denen der A/V-Edgedienst ausgeführt wird:

Deaktivieren Sie den Nagle-Algorithmus für TCP sowohl für den internen als auch für den externen Port 443. Mit diesem Algorithmus werden mehrere kleine Pakete für eine effizientere Übermittlung zu einem einzigen, größeren Paket zusammengefasst.

• Deaktivieren Sie den Nagle-Algorithmus für TCP für den Bereich der externen Ports 50.000 bis 59.999.

• Verwenden Sie keine Netzwerkadressenübersetzung für die interne oder externe Firewall.

• Die interne Edgeschnittstelle muss sich in einem anderen Netzwerk befinden als die externe Edgeschnittstelle, und das Routing zwischen diesen Schnittstellen muss deaktiviert sein.

• Die externe Schnittstelle des Edgeservers, auf dem der A/V-Edgedienst ausgeführt wird, muss öffentlich routingfähige IP-Adressen und darf keine Netzwerkadressen- oder Portübersetzung für die externen IP-Adressen des Edgeservers verwenden.

Anforderungen bei Verwendung eines Hardwaregeräts zum Lastenausgleich für Webdienste

Im Folgenden sind die Anforderungen bei Verwendung eines Hardwaregeräts zum Lastenausgleich für Director- und Front-End-Pool-Webdienste aufgeführt:

• Legen Sie für die externen Ports 4443 und 8080 auf dem Hardwaregerät zum Lastenausgleich für die virtuellen IP-Adressen der Webdienste eine cookiegestützte Persistenz auf Portbasis fest. Für Lync Server 2010 bedeutet cookiegestützte Persistenz, dass mehrere Verbindungen von einem einzelnen Client zur Beibehaltung des Sitzungsstatus stets an einen einzigen Server gesendet werden. Zur Konfiguration der cookiegestützten Persistenz muss das Hardwaregerät zum Lastenausgleich SSL-Datenverkehr ent- und verschlüsseln. Folglich muss ein Zertifikat, das dem externen FQDN der Webdienste zugewiesen wird, auch der virtuellen IP-Adresse 4443 des Hardwaregeräts zum Lastenausgleich zugewiesen werden.

• Legen Sie für interne virtuelle IP-Adressen der Webdienste die Dauerhaftigkeit von Quelladressen (interner Port 80, 443) für das Hardwaregerät zum Lastenausgleich fest. Für Lync Server 2010 bedeutet Dauerhaftigkeit von Quelladressen, dass mehrere Verbindungen von einer einzelnen IP-Adresse zur Beibehaltung des Sitzungsstatus stets an einen einzigen Server gesendet werden.

• Legen Sie ein TCP-Leerlauftimeout von 1.800 Sekunden fest.

• Erstellen Sie für die Firewall zwischen dem Reverseproxy und dem Hardwaregerät zum Lastenausgleich des nächsten Hoppools eine Regel zum Zulassen von https:-Datenverkehr an Port 4443 – vom Reverseproxy zum Hardwaregerät zum Lastenausgleich. Das Hardwaregerät zum Lastenausgleich muss für die Überwachung der Ports 80, 443 und 4443 konfiguriert werden.