Lync und VPN

VoIP versucht immer die beiden Endpunkte direkt miteinander zu verbinden, um einen kurzen direkten Weg für die Audio- und Video-Daten zu haben. Nicht immer ist ein direkter Weg aber möglich, z.B.: weil die Verbindung über das Internet erfolgt und die Standorte per VPN verbunden sind. Diese Seite beschreibt den Einfluss von VPN-Verbindungen auf Lync und andere VoIP-Lösungen

RTP mit UDP

Als ganz schnelle Vorinformation sehen Sie hier einen WireShark-Mitschnitt einer Richtung einer verschlüsselten SRTP-Verbindung meines internen PC mit dem Lync AudioTestService.

Das Bild zeigt folgende Fakten:

  • 20ms Frameabstand
    Der Client sendet ca. alle 20ms ein Paket zum Ziel.
  • Protokoll UDP
    Audiopakete sollen wenige Overhead nutzen und müssen vor allem nicht transportgesichert sein. Geht ein Paket verloren, dann würde die Erkennung des Verlusts durch den Empfänger mit erneuten Anforderung und Zusendung zu lange dauern um den fehlenden Abschnitt noch abzuspielen. Ein "Retransmit" eines verlorenen Audiopakets ist bei VoIP nicht nützlich.
  • Datengröße 183byte
    Die Nutzlast des UDP-Pakets ist 183 Bytes. Das entspricht etwa den Abtastung von 20ms Audio mit 64kbit/Sek = 50 Pakete/Sek. Würde als Codec G.711 zum Einsatz kommen, dann wäre ein Paket 160byte groß. Dies hier ist etwas größer, das Lync intern RTAUDIO nutze und 128kbit abtastet aber durch Kompression spart. Die meisten einfachen VoIP-Umgebungen nutzen G.711, zumindest wenn eine Telefonverbindung nach außen oder über einen SIP-Trunk genutzt wird.
  • Frame-Overhead 42byte
    Durch den UDP-Header, den IP-Header und das Ethernet-Frame kommen hier noch mal 42bytes dazu, so dass das Gesamtpaket 225 Bytes groß ist.

Sie sehen also, dass schon bei einer einfachen internen UDP-Übertragung das Paket um ca. 20-25% größer wird. Das ist aber nicht zu verhindern und Bestandteil von IP und Ethernet. Bei anderen Übertragungswegen (z.B. Token Ring, FDDI statt Ethernet) und Protokollen (IPX statt IP) sind diese Werte anders aber in ähnlicher Größe. Beim Einsatz von IPV6

VPN Technik

Durch den Einsatz eines VPN verändert sich das Paket. Der Overhead für das Ethernet-Frame bleibt, zumindest solange das Paket noch auf Ethernet übertragen wird, aber je nach VPN werden nun Zwischenschichten eingezogen.

  • Tunnel
    Hierbei wird das komplette Pakete noch ein "eingepackt" über ein neues TCP-Paket übertragen. Die Zwischenstationen sehen also überhaupt nicht, welche Inhalte hier transportiert werden, weder die IP-Adressen der Endpunkte noch die Ports und schon gar nicht die Daten
  • Transparentmode
    Es gibt auch eine VPN-Umsetzung, bei der die Quell und Ziel-IP-Adressen bestehen bleiben und nur die Nutzlast verschlüsselt wird. Das funktioniert natürlich nur, wenn die beiden Endpunkte direkt miteinander kommunizieren können. IPSec ist z.B. so eine Umsetzung.

In den meisten Fällen nutzt VPN auch "TCP" als Tunnelprotokoll und Client nutzen sogar HTTPS (SSL) als Transportmittel, um die Pakete zu verpacken und zu übertragen. Das hat Auswirkungen auf die Nutzbarkeit:

  • Noch mehr Overhead
    VoIP/RTP sind schon viele kleine Pakete und nun wird jedes Paket auch noch in einem VPN-Paket eingepackt. Addiert man vielleicht 40-60bytes für einen VPN-IP-Overhead dazu, dann wird das 200Byte Paket schnell um 20-30% größer". Dieser Mehrbedarf ist deutlich mehr als das Einpacken von 1,5kByte großen SMB-Paketen.
  • Verluste und Retransmit
    Die meisten VPN-Lösungen packen auch UDP-Pakete in „TCP-Tunnelpakete“ ein und die sind eine „gesicherte Verbindung“, d.h. wenn das VPN merkt, dass ein Paket verloren gegangen ist, dann fordert es dieses wieder an um die Vollständigkeit und die Reihenfolge sicher zu stellen. Das führt zu Retransmits, die bei VoIP aber nutzlos sind, da bis dahin der „Ton“ schon lange Vergangenheit ist. Es lohnt sich nicht ein verlorenes RTP-Paket erneut anzufordern. Es müsste schon innerhalb des Jitter-Buffer (20-80ms) ankommen um noch "in Time" angespielt zu werden.
  • Latenz
    Die Verschlüsselung und Entschlüsselung kann nicht "on the fly" erfolgen. Also muss dieses weitere Gateway die Pakete annehmen, dann verschlüsseln und erst dann wieder auf die Leitung setzen. Auch hier verlängert sich die Laufzeit des Pakets.
  • QoS DSCP
    IP-Pakete können über eine entsprechende Kennzeichnung von Routern und Switches erkannt und bevorzugt übertragen werden. Wird ein IP-Paket komplett im VPN-Tunnel verpackt, können die Stationen des VPN-Pakets nicht mehr die Priorität erkennen. Oft ist das aber ein nachrangiges Problem, da VPN-Verbindung meist über das Internet aufgebaut werden und hier QoS in der Regel sowieso nicht beachtet oder sogar entfernt wird. Dies ist also eher eine Aufgabe bei VPNs innerhalb eines selbst verwalteten Netzwerks. Eine Berücksichtigung des QoS-Tagging ist möglich, wenn die VPN-Software z.B. die Kennzeichnung des Nutzpakets auf das VPN-Paket überträgt. Allerdings verrät der Betreiber des VPNs damit natürlich ein bisschen mehr über die verschlüsselte Nutzlast. Fakt ist aber, dass es
  • Doppelte Verschlüsselung
    VPNs werden natürlich primär zur Datenverschlüsselung und nicht nur zum Aufbau von "Tunnels" eingerichtet. Von der Verschlüsselung können natürlich auch VoIP-Verkehre profitieren, so sie nicht selbst verschlüsseln. Lync Clients und Server kommunizieren aber per Default sowohl bei der Signalisierung (SIP) nur verschlüsselt (SIP/TLS über 5061 TCP) und auch die Datenübertragung (RTP) nutzt per Default die Verschlüsselung (SRTP). Dieser Zwang kann natürlich z.B. Um fremde Geräte einzubinden, abgeschaltet werden. Per Default bringt aber die zusätzliche Verschlüsselung eines VPN keinen Vorteil.
  • Doppelte Kompression/WAN Optimizer
    Sehr viele Protokolle gehen recht verschwenderisch mit der Bandbreite um, So kommt bei SMTP, POP, IMAP in der Regel keine Kompression zum Einsatz. Bei der Übertragung per HTTP gibt es entsprechende Erweiterungen um die Nutzdaten zu komprimieren aber bei weitem nicht alle Clients und Server nutzen dies. Auch SMB komprimiert nicht. Hier kann ein VPN oder ein WAN-Optimierer viel Bandbreite einsparen. Allerdings sind Protokolle wie RDP, ICA und insbesondere auch RTP schon hoch komprimiert. Gerade Audio und Video-Daten sind durch eine zweite Komprimierung nicht mehr kleiner zu bekommen. In der Regel nimmt das Datenvolumen durch den Overhead eher zu.

Dies sind eine ganze Menge an Punkten die den Einsatz eines VPN mit Lync unwirtschaftlich erscheinen lassen. Zudem muss natürlich das VPN erst einmal aufgebaut werden und bestehen bleiben.

Hinweis:
All diese "Probleme" treffen natürlich auch für die Nutzer einer "Private Cloud" zu, wenn zwischen den (Lync-)Server im Rechenzentrum eines Betreibers und ihrem lokalen Netzwerk mit den Client die Verbindung ebenfalls über VPN-Router statt MPLS o.ä. hergestellt wird. Oft sind hier aber die bereitgestellten Bandbreiten deutlich höher oder die Entfernungen geringer, so dass die Probleme hier erst bei viel Last spürbar werden.

Ausbruch aus dem VPN

Viele Firmen haben aber eine Sicherheitsrichtlinie, dass alle Clients mit Zugriff auf das Firmennetzwerk zwingend per VPN arbeiten müssen. Zudem muss unterschieden, ob der VPN nur der Zugriff auf die internen Ressourcen der Firma schützt, oder ob jeder Datenverkehr immer durch das VPN zur Zentrale geleitet werden müssen.

In dem Falle geht auch Audio und Video zwingend durch den VPN-Tunnel mit den bekannten Einschränkungen bzw. Nachteilen. Die meisten VPN-Lösungen lenken den Verkehr über eine Umstellung des "Default Gateway" durch den Tunnel aber erlauben den Zugriff auf System im gleichen Subnetz.

Das schwächt etwas die Sicherheit, da der Client damit aus dem gleichen Subnetz erreichbar ist aber so kann der Anwender zuhause zumindest einen lokalen Drucker nutzen und vielleicht einen lokalen NAS-Server. für Lync bietet diese öffnung aber keine Vorteile.

Interessant wird es für Lync, wenn ein VPN-Client bestimmte Ziele am VPN vorbei erreichen kann, z.B. die Updateserver für den Virenscanner oder Zugänge auf alternative Dienste wie Outlook WebApp etc., die nicht zwingend über das VPN genutzt werden müssen und entsprechend auch funktionieren, wenn das VPN nicht zur Verfügung steht.

Sollte die Policy es zulassen, dass der Client einige ausgewählte oder sogar alle "nicht internen" Dienste direkt erreichen kann, dann kann der Lync Client auch Audio/Video am VPN vorbei zum Edge übertragen. Der Edge-Server als Zielsystem für externe Clients kann über die feste bekannte IP (AVEDGE) bestimmt und in einer Clientrichtlinie des VPN zugelassen werden. Dann kann der Anwender mit dem Lync Client weiterhin auch SIP und andere Datendienste über das VPN routen. Natürlich könnte er auch alle Lync-Daten über das Internet zum Edge-Server routen, aber viele Firmen haben z.B. ein Problem damit, die Lync Webdienste aus dem Internet erreichbar zu machen. Da es sich dabei aber um TCP-Traffic handelt (https) ist der Tunnel durch das VPN tolerierbar.

Beim Einsatz von Windows Direct Access ist es z.B. möglich, Domänen, Hosts oder einzelne IP-Adresse aus Direct Access auszunehmen.. Siehe auch Direct Access und Direct Access 2012.

Beim Aufbau einer Audio/Video-Verbindung durchlaufen aber alles Clients den üblichen Handshake (Siehe ICE und Kandidaten) und ein externer Client, der von Außen auf den Edge-Server kommt, bekommt auch von diesem seine Kandidaten die er dem anderen Client anbietet.

Bewertung Edge-Umleitung statt VPN

Es mag Firmen geben, die ihre internes Netzwerk sehr stark abschotten und ich kenne sogar Firmen, bei denen das interne Netzwerk komplett vom Internet abgetrennt ist. Dort ist kein Zugriff per Browser, DNS oder andere Protokolle möglich. Selbst Mail ist teilweise sogar blockiert. Oft haben die Mitarbeiter mit "Internetzugriff" in so einem Netzwerk dann einen zweiten PC oder nutzen eine Terminal Server-Session auf einem "Internet-Server", um eine logische Trennung zu erreichen. Natürlich werden in diesem Umfeldern dann auch USB-Anschlüsse, Audiogeräte und Kameras am PC sehr kritisch beäugt bzw. von vorne herein unterbunden. Diese Firmen werden dann auch keinen Edge-Server installieren und generell die Thematik Lync vielleicht nicht weiter verfolgen.

Alle anderen Firmen mit Lync sollten aber in Erwägung ziehen, einen Edge-Server in die Umgebung zu installieren. Vielleicht wollen Sie diese Komponenten sowieso installieren, um z.B. folgende Dienste zu erlauben:

  • Federation mit anderen Firmen
  • Mobile Clients
  • externe Konferenzteilnehmer in Meetings

Für Remote user, Heimarbeiter o.ä. bietet der Edge im Vergleich zum VPN aber jede Menge Vorteile. Quasi das Gegenstück zu den oben genannten Nachteilen, wenn man RTP/SRTP nicht durch ein VPN senden muss.

  • Geringere Latenzzeiten
  • Möglichkeit der Priorisierung per Port oder QoS
  • Keine überflüssigen Retransmits
  • geringere Bandbreite

Es gibt noch einen Vorteil, den ein Edge-Server mitbringt.

Clients ohne VPN
Sie können mit dem Edge-Server auch Clients verwenden, die vielleicht gar kein VPN aufbauen können wie Lync Telefone oder Homeoffice-PCs, die zwar einen Lync Client nutzen aber ansonsten nicht zum Firmennetzwerk gehören sollen.

Optionen zum Ausbruch

Aus meiner Sicht ist es nur logisch und sinnvoll, dass ein Externer Client über den Edge Server die Audio/Video-Playload sendet und auch die Übertragung von SIP kann durchaus über den Edge gehen und muss daher nicht durch das VPN laufen. Wobei das sicher weniger kritisch ist. Damit ein Client aber nun den "richtigen" Weg für Audio/Video nimmt, muss das VPN entsprechend konfiguriert sein oder Sie durch andere Tricks den Clients dazu bringen, über die externe Verbindung zu gehen.

  • Namensauflösung
    Die meisten Firmen erzwingen, dass VPN-Teilnehmer den internen DNS-Server nutzen, selbst wenn Sie IP-technisch externe Webseiten vielleicht am VPN vorbei direkt ansprechen dürfen. Windows Direct Access macht es per Default so, dass die Domäne definiert wird, für die Anfragen an den internen DNS-Server per VPN gesendet werden. Die Namensauflösung ist aber ein wichtiger Aspekt, da der Client nach _sipinternaltls._tcp.<sipdomain> fragt und so ermittelt, ob er intern oder extern ist. Ein VPN Client, der auch "gefühlt extern" sein soll, sollte die "internen" Namen natürlich nicht auflösen können.
  • ICE-Candidates
    Für eine Audio/Video-Verbindung werden "Candidates" ausgetauscht. Die meisten VPN-Clients bekommen eine "interne routbare IP-Adresse" und damit finden die Clients auch für Audio/Video oft die direkte Verbindung.

Beide Komponenten können Sie auf unterschiedliche Weise beeinflussen oder stören

  • DNS-Ausnahmen im VPN-Client
    Oft können VPN-Clients von Drittherstellern vom Server eine Liste von Namen bekommen, die sie "anders" auflösen. Teilnehmer
    Der Client könnte z.B. per NRPT bestimmte Hosts nicht auf den internen DNS senden. Der Client sucht dann die Namen extern.
  • DNS-Server splitten
    Eine andere Option ist, den VPN-Clients einen anderen DNS-Server oder eine andere Sicht auf die Zone des DNS-Servers zu geben und so serverseitig die internen Lync-Einträge zu verbergen.
  • VPN Blocken 5061
    Etwas härter ist es, den Zugang zum Lync Server per 5061 für VPN-Clients zu blocken. Die Clients können dann per DNS vielleicht noch den internen Pool auflösen aber nicht erreichen. Nach einiger Zeit schwenken die Clients dann doch auf den Edge-Server. Es gibt hier gleich mehrere mehr oder weniger schmutzige Optionen, mit denen Sie spielen können
    • VPN-Router blockt 5061 als Firewallregel
    • Lync FrontendPool nutzt Windows Firewall um VPN-Subnetze zu sperren und so zum Weg über Edge zu zwingen
    • Lync Frontendpool bekommt per "IP Routing Table" einen falschen Leitwege, um die Rückpakete der VPN-Clients zu verhindern.
  • RTP und RTCP
    Bleibt noch das Problem von Audio/Video, die per RTP einen eigenen Weg suchen. Da man dem Client nicht verbieten kann die VPN-IP-Adressen anzubieten und damit die Verbindung intern zu routen, bleibt auch hier nur der Weg die Ports zu blocken.

Weitere Links