Erforderliche Komponenten für den Zugriff durch externe Benutzer

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.