OCS 2007 R2 Edge

Diese Seite beschränkt sich auf "kleine" Umgebungen mit einem Edge-Server für die Firma und deckt keine Load Balancer und andere Hochverfügbarkeitstechniken ab.
Die Seite gilt für den OCS 200 R2-Edge.

Achtung: OCS2007 R2 braucht zwingend zwei Netzwerkkarten. Eine normale Installation benötigt zudem drei offizielle Adressen, wenn Sie mit den Standard-Ports arbeiten wollen.

Testen Sie die Funktion von OCS Edge von Außen unter https://www.testocsconnectivity.com/

Achtung:
Diese Beschreibung gilt nicht für Lync, hier sind z.B.: Post 4443 für die Replikation der Konfigurationsdatenbank dazu gekommen.
Lync Edge - die sichere Außenverbindung
Siehe auch Reference Architecture 1: Port Summary für Single Consolidated Edge
http://technet.microsoft.com/en-us/library/gg425891.aspx
Chapter 06 Planning für External user Access.doc
"http://download.microsoft.com/download/1/A/5/1A5160CE-F5F7-4DFE-8EA0-6E2A3F89AD22/Chapter 06 Planning für External user Access.doc"

Diese Funktionseinheit vermittelt zwischen Teilnehmern im Internet und auf dem internen LAN. Dies bezieht sich auf drei Verbindungstypen:

  • Access Edge Service
    Überträgt die SIP-Kommunikation, d.h. Statusmeldungen aber auch Verbindungssteuerungsdaten für Telefonie. Die interne Gegenstelle ist der OCS Standard Server oder der Enterprise Pool
  • Web Conferencing Edge Service
    Zugriff aus dem Internet auf intern gehostete Webkonferenzen für benannte, anonyme und Benutzer von Partnerfirmen (Federation). Wenn Sie solche Konferenzen nicht extern anbieten wollen, dann können Sie diese Rolle (und das dazu erforderliche Zertifikat) einsparen.
  • A/V Edge Service
    Diese Rolle überträgt die Audio und Video-Daten zwischen den Clients im Internet und dem internen Gegenstellen (Clients, Mediation, OCS-Web Conference Server). Auch die Desktopfreigabe nutzt dies Rolle.
  • Reverse Proxy (Nicht Bestandteil des Edge !)
    Zusätzlich ist noch ein Reverse Proxy erforderlich, über den die Clients die normale IM-Funktionen, Offline Adressbuch Download.

Der Zugriff auf Communicator Web Access oder die Live Meeting Webseite hingegen muss nicht über den Edge laufen. Das sind ganz normale HTTPS-Pakete, die über eine Webveröffentlichungsregel bereit gestellt werden. Zugriff von Clients mit "VPN-Einwahl" können mit Einschränkungen als "interne Clients" betrachtet werden. Details hier finden Sie am Ende der Seite.

Firewall Ports und Kommunikationswege

Die Microsoft Dokumentation (http://technet.microsoft.com/en-us/library/dd441361(office.13).aspx) beschreibt sehr genau, welche Protokolle im Details eingesetzt werden. Damit sollte es auch dem Firewall Admin möglich sein, die entsprechenden Filter vor und nach dem Edge- Server zu konfigurieren.

Info: Dieses Bild ist noch nicht komplett !!. so fehlt z.B. der Adressbuchdownload /ABS

OCS Edge Firewall Ports

Diese Ports sind die StandardPorts und können fast alle nachträglich geändert werden. für die internen Schnittstellen ist dies auch relativ problemlos. Auf den externen Schnittstellen ist jedoch zu prüfen. ob die Funktion in allen Fällen noch gegeben ist.

Ports für OCS 2007 RTM
Die Port 50000-59999 UDP/TCP Inbound sind nur für Kompatibilität mit Federation zu OCS2007RTM erforderlich. Da jeder OCS2007RTM Kunde aber kostenfrei auf 2007 R2 Updaten kann (Arbeitszeit und 64bit Server erforderlich) dürfte es kaum noch solche Systeme geben.

Schematische Anzeige:
Beispiel: Der Edge muss natürlich sowohl interne als auch externe Namen auflösen können. Dazu wird man ihm aber sicher nicht externe und interne DNS-Server eintragen. In der Regel fragt der Edge besser einen internen DNS-Server der sowohl interne Namen kennt aber auch als Forwarder externe Adressenauflösen kann.

Ein ähnliches Bild stellt Microsoft auf http://technet.microsoft.com/en-us/library/dd441361(office.13).aspx bereit

Mit dem OCS 2007 R2 wurden die benötigten Ports weiterhin reduziert. Die komplette Freigabe der Port 50000-59999 für den externen Zugriff ist sogar nur für Federation mit anderen OCS-Servern erforderlich (http://technet.microsoft.com/en-us/library/dd441209(office.13).aspx). Sofern sie sicherstellen können, dass alle anderen Server mindestens R2 nutzen, können die due öffnung auf "TCP" beschränken, so dass Firewalls die Verbindung besser überwachen können.

Edge Planning Tool für Office Communications Server 2007 R2
http://blogs.msdn.com/byrons/archive/2009/05/07/edge-planning-tool-for-office-communications-server-2007-r2.aspx
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ec4b960c-3fe2-41bd-abdf-ae89cfcb8c6c

Zertifikate und Dienstkonten

Wenn Sie sich aber das Diagramm genauer anschauen, dann finden Sie gleich mehrere eingehende Verbindung auf 443/TCP. Also müssen wir uns über HTTPS und Zertifikate unterhalten. Microsoft beschreibt die Anforderungen auf http://technet.microsoft.com/en-us/library/dd425344(office.13).aspx. für den Edge-Server sind folgende Zertifikate erforderlich:

  • Zertifikat auf der internen Schnittstelle
    Dieses wird genutzt, damit der Edge nach innen zu den anderen Server sicher kommunizieren kann, Dies kann durchaus ein privates Zertifikat sein.
  • Externer Access Edge
    Dies muss ein offizielles Zertifikat sein
  • Externer Web Conferencing Edge
    Dies muss ein offizielles Zertifikat sein
  • AV-Edge
    Dies kann ein privates Zertifikat sein.

Die externen Zertifikate sollten natürlich "offizielle" Zertifikate sein, damit fremde und federierte Server die Gültigkeit und damit die Vertrauenswürdigkeit prüfen können. Natürlich können Sie auch "private" Zertifikate nutzen, solange sie nur dafür sorgen, dass alle Partner und externen Clients diesen Vertrauen. Meist ist ein offizielles Zertifikat aber günstiger als die manuelle Arbeit und der Supportaufwand. Wer "Sparen" will, kann alle drei Dienste mit einem Zertifikat betreiben, muss diese dann aber auf unterschiedliche Ports (ungleich 443) konfigurieren, womit nicht immer alle externen Zugriffe funktionieren.

OCS 2007 R2 unterstützt offiziell keine "Wildcard Zertifikate". Erst mit Lync wird die möglich sein, aber auch nur, wenn alle Gegenstellen ebenfalls Lync verwenden.

Externe Namen

Der Edge-Server steht in den meisten Fällen in einer separaten Zone und ist natürlich nicht Mitglied der Domäne. Damit gibt es gleich drei "Probleme, die gelöst werden müssen.

  • Extern auf Edge
    Externe Anwender müssen per DNS den Edge-Server "finden". Dazu dienen einige DNS-Einträge in der offiziellen DNS-Zone:

# Verweise auf den Access Edge aus dem Internet
_sipfederationtls._tcp.firma.tld  SRV 5061  edge.firma.tld
_sip._tls.firma.tld               SRV  443  edge.firma.tld
edge.firma.tld                      A  externe.ip.des.edge

# Weitere A-Records für DeviceUpdate, WebConferencing etc

OCS Federation TLS

  • Edge nach Intern
    Natürlich muss auch der Edge-Server eine Verbindung zum internen Frontend Server aufbauen, um die Anfragen weiter zu geben. Dazu wird im Edge der Server entsprechend konfiguriert. Auch hier sorgen der DNS-Name und das Zertifikat dafür, dass die Verbindung verschlüsselt und gegenseitig authentifiziert worden ist. Da der Edge ja nicht im Active Directory ist, müssen Sie sicherstellen, dass auch in diese Richtung die Namensauflösung gewährleistet ist.
  • Intern zu Edge
    Die internen Server müssen den Edge auflösen können. Sie nutzen dazu den FQDN in der OCS-Konfiguration, zu dem es einen passenden Namenseintrag geben muss, der auf die interne IP-Adresse des Edge verweist.

# Verweise auf den Edge von innen
edgeintern.firma.tld    A  externe.ip.des.edge

Das hört sich alles aber komplizierter an, als es ist. zumindest wenn ihr DNS-Setup korrekt ist und Sie die richtigen Zertifikate auf die richtigen Ports gebunden haben.

Edge Konfiguration per Assistent

Wenn Sie die Edge-Rolle installieren, dann führt Sie ein Assistent sehr elegant durch die erste Konfiguration. Das sollte Sie aber nicht darüber hinweg täuschen, dass Edge nur funktioniert, wenn alle Komponenten korrekt zusammen greifen. Und das sind ganz schön viele (Zertifikate, IP-Adressen, Ports, Firewalls,..)

Internes Interface

Zuerst muss man für den Edge Server das interne Interface definieren, über welches der Edge mit den Frontend Server bzw. Standard Servern kommuniziert. Hier ist auch ein FQDN erforderlich, für welchen auch ein Zertifikat ausgestellt werden muss

Der nächste Schritt definiert die externen Schnittstellen und die Namen:

Die beste Praxis ist die Veröffentlichung von drei Namen mit drei IP-Adressen und den entsprechenden Zertifikaten.

Dass hier private Adressen auftauchen ist ein Zeichen, dass dieser Edge-Server hinter einer Firewall steht, die die ausgewählten Port per NAT nach intern weiter gibt.

Achten Sie hier genau die die FQDNs, die eingetragen sind. Diese werden z.B. im SIP-Handshake über 5061 an die Clients übermittelt. Der OCS-Zertifikatsassistent hat mit SAN-Zertifikaten hier die unschöne Eigenschaft, immer den primären Namen (CN) dort einzutragen. Das ist natürlich nicht passend, wenn sie ein SAN-Zertifikat nutzen und die OCS-Dienste mit einem SAN-Namen arbeiten.

Ein solcher Fehler wirkt sich derart aus, dass Desktopsharing, Voice und Federation etc. nicht funktionieren aber die erste Message per Federation schon bei ihnen ankommt. Die kommt nämlich schon mit dem SIP-INVITE, während folgende Meldungen wieder SIP-Messages sind.

Achtung
Dies ist eine Musterkonfiguration, die so nicht empfohlen ist. Sehr viele Firewalls lassen nur die Standardports 443 für HTTPS-Verbindungen zu, so dass die Funktion nicht sichergestellt ist, wenn Sie wie hier andere Ports verwenden.
Empfohlen ist daher der Einsatz von 443 und drei eigenen IP-Adressen und Namen. für CWA Web Access brauchen Sie dann noch eine vierte Adresse mit Namen.

Einen EDGE-Server installiert man nicht nur, damit Mitarbeiter von extern auch Audio/Video nutzen können, sondern auch für die Verbindung mit anderen Diensten. Diese Funktion muss entsprechend aktiviert werden.

OCS Federation

In den folgenden Dialogen müssen noch Angaben zu Domänen, internen OCS-Servern etc. gemacht werden, ehe am Ende der Assistent eine Zusammenfassung anzeigt, die man sehr gut in eine Dokumentation übernehmen kann.

Edge hinter NAT

Seit OCS 2007 R2 ist es nun auch offiziell möglich, den Edge-Server hinter einer NAT-Firewall zu verbergen. Damit dies aber funktioniert, muss der Edge "wissen", dass er hinter NAT steht u. Und er muss wissen, welches die offizielle Adresse ist, auf die er Anfragen der Clients lenken soll. Das Wissen um NAT muss auf dem Edge Server per Checkbox aktiviert werden

Edge mit NAT

Die externe Adresse kann man dem Edge hier nicht hinterlegen. Der Edge nutzt dazu DNS, um den Namen auf eine externe Adresse aufzulösen. Da die meisten EDGE-Server zwar das externe Internet auflösen können aber vielleicht doch dazu interne DNS-Server nutzen, gibt es ein Problem bei Firmen mit "Split-DNS", d.h. bei denen die interne DNS-Zone mit der externen DNS-Zone identisch ist. Hier müssen Sie dann intern einen DNS-A-Record mit der offiziellen Adresse eintragen. Wohl dem, der intern nicht den gleichen Alias (z.B. avedge.netatwork.de) verwendet hat. Diesen intern aufgelösten Namen sendet der Edge dann über die SIP-Verbindung an den Client, damit der von extern dann die richtige "öffentliche Adresse" verwendet.

Edge Konfiguration auf dem Frontend Server

Dass Sie einen Edge-Server installiert haben, kann ihre restliche OCS-Struktur nicht alleine erkennen, da der Edge nicht im Active Directory ist. Sie müssen also den Edge Server der Infrastruktur bekannt geben. Dazu gibt es in den globalen Eigenschaften eine eigene Karteikarte

Edge im OCS definieren

Über diese Einstellungen wissen dann die OCS-Server, wie sie an die installierten Edge Server Pakete weiter geben können und dass diese Server auch eine Verbindung zur Farm aufbauen können.

Interne Benutzer von Außen

Der Edge Server wird nicht nur zur Verbindung mit Partnern und externen Personen genutzt, sondern dient natürlich auch den eigenen Mitarbeitern als Zugangspunkt für externe Zugriffe, z.B. von unterwegs oder zu Hause ohne VPN. Wenn sich die Anwender hierbei nicht anmelden können, dann liegt dies meist an den Authentifizierungseinstellungen auf dem Frontend Server. Per Default ist hier nämlich nur "Kerberos" aktiviert, wozu der Client natürlich ein gültiges Ticket von einem KDC beziehen muss. Ein denkbar schwieriges unterfangen aus dem Internet. In diesem Fall sollten Sie hier auf NTLM-Kerberos umstellen.

Die Sicherheit der Daten ist ja durch SSL und die NTLM-Verschlüsselung gewährleistet. Die Ursache können Sie übrigens mit dem SIP-Trace des OCS Logging tools sehr einfach ermitteln. Da sieht man auch, dass Der Edge keine Authentifizierung durchführt, sondern diese Anfragen einfach nach intern weiter gibt. Quasi eher ein SIP-Reverse Proxy ist. Aber auch hier zeigt sich wieder, wie wichtig ein Blick ins Eventlog ist, welches sogar die OCS-Management Console quasi direkt präsentiert:

Edge auf Windows 2008

Natürlich funktioniert der Edge Server auch auf Windows 2008 x64 Servern. Allerdings ist dort die Verwaltungskonsole etwas versteckt. man muss nämlich die alte "COMPMGMT.MSC"-Console starten. Hier findet man dann die Verwaltungskonsole für den Edge Server.

Fehlersuche

Die Kommunikation des Edge Servers mit anderen Knoten ist recht umfangreiche und damit gar nicht so einfach zu debuggen. Zwei Werkzeuge stehen bei mir da immer an erster Stelle:

  • Snooper
    Die eingebaute Logging-Funktion in Verbindung mit dem Tool "Snooper" ist das Werkzeug zur Analyse der SIP-Datenverkehre, auch wenn diese "verschlüsselt" sind. Über diesen Weg kann man z.B.: wunderbar erkennen, welche "Candidate" per SIP der Gegenstelle angeboten wird bzw. man selbst angeboten bekommt
  • NetMon 3
    Auch wenn die Nutzdaten und SIP verschlüsselt sind, so besteht der unterbau immer noch aus lesbaren TCP und UDP Verbindungen, dessen Handshake per Netmon analysiert werden können. Dieser Ausschnitt eines Trace, indem z.B.: auf den Prozess "MediaRelaySvc.exe" gefiltert wird, zeigt, dass die Verbindung per STUN (Port 3478) etabliert ist aber der Audiokanal nicht aufgebaut wird.

    Man sieht nur, dass hier die IP-Adresse des lokalen Edge-Server, welcher hier hinter eine NAT-Adresse verborgen ist, eine Verbindung zur öffentlichen IP der Gegenseite aufbauen will (SYN) aber keine Antwort kommt. Allerdings bedarf es schon einiger Erfahrung im Lesen von Netzwerktraces, um alle Feinheiten hier zu erkennen und zu verstehen.
  • Firewall Logs
    Die meisten Firmen stellen den Edge natürlich nicht ungesichert in das Internet, sondern platzieren zumindest davor eine Firewall. Man muss aber auch wissen, dass der Edge nach intern nicht nur mit den Frontend Servern oder Mediation Servern spricht sondern auch normale Client bei einer 1:1 Verbindung mit einem externen Partner direkt den Edge-Server angehen. Der Frontend Server ist nur dann im Boot, wenn eine Konferenz mit drei oder mehr Partnern geführt wird. Insofern ist es immer eine gute Idee zu schauen, welche Pakete von und zu den den IP-Adressen des Edge Servers an anderer Stelle geblockt werden
  • Eventlog
    Und vergessen Sie nicht das Windows Eventlog auf dem Edge Server. Hier sehen Sie z.B.:, wenn der MediaRelayService die Ports nicht binden kann oder Zertifikatsfehler auftreten.

Letztlich ist es manchmal aber auch einfach Glück und Spürsinn, einen Fehler zu finden. Das können abgelaufene Zertifikate sein, aber auch einfache Tippfehler im Servernamen, Zertifikatnamen o.ä.

Edge oder VPN

Der Betrieb eines EDGE-Servers ist natürlich mit Kosten verbunden, die man vielleicht sparen kann, wenn alle Clients als "intern" angesehen werden könnten. Dazu eignet sich natürlich auch ein VPN, zumindest wenn es korrekt konfiguriert ist. Sie dürfen nämlich nicht vergessen, dass der Communicator versucht direkt den Partner zu erreichen, und genau das bei vielen VPNs gar nicht der Fall. Nicht immer ist die IP-Adresse des VPN Clients voll "routbar".

Hinzu kommt natürlich noch, dass ein VPN in der Regel immer erst aufgebaut und Abgebaut werden muss und der Client die passende Software installiert haben muss. Gerade das ist auf mobilen Geräten (Communicator Mobile) oder IP-Telefonen wie einem SNOM oder Tanjay nicht möglich. Selbst wenn das VPN überhaupt erst aufgebaut werden kann und nicht schon durch den Hotspot-Betreiber unterbunden wird, dann werden die Pakete doch erneut umgepackt und eventuell in mehrere kleinere Pakete aufgeteilt, was sich direkt auf die Laufzeit und damit die Sprachqualität auswirkt.

Ein VPN kann also in der ersten Stufe sicher für den Betrieb abgesetzter Clients ein Anfang sein, aber mittelfristig werden sie bei externem Zugriff zum einen Edge-Server nicht wirklich herum kommen. Und erst mit einem Edge-Server haben Sie auch die Möglichkeit der Anbindung an andere Systeme über Federation und MSN PIC

Weitere Links