TURN-Kommunikation

Auf dieser Seite versuche ich einen tieferen Blick in die Kommunikation eines VoIP Clients mit dem TURN-Server um Audio/Video u.a. Daten über NAT und Firewalls zu leiten, wenn zwei Endpunkte nicht direkt miteinander kommunizieren können.

TURN ist keine Microsoft-Erfindung, sondern wird von quasi allen VoIP- und Konferenz-Systemen genutzt und Bestandteil von WebRTC - Web Real Time Communication und ICE, Kandidaten, STUN und TURN

Auslöser

Bei der Fehlersuche nach Audio-Problemen habe ich manchmal mit Firewalls zu tun, die IP-Pakete blocken, verfälschen oder anderweitig Eingriff nehmen. Dazu gibt es auch WAN-Optimierer (Cisco, Riverbed u.a.), die Pakete komprimieren oder anderweitig "optimieren". Das ist natürlich für Audio/Video in der Regel wenig sinnvoll. Es passiert also gar nicht mal so selten, dass ich mit Wireshark  und Co den Paketen nachspüre, um Verfälschungen und Verluste zu erkennen.

Wann kommt TURN zum Einsatz?

Bei VoIP versuchen die beiden Endstellen einen möglichst direkten Weg zu finden. Allerdings gibt es viele Situationen, in denen diese nicht möglich ist. So ist schon der klassische DSL-Router zuhause meist nur in eine Richtung durchlässig. Pakete gehen hin aber nicht zurück. Woanders verhindern Firewall gleich komplett die dynamischen Port von VoIP. Office 365 nutzt dazu gerne 50000-50019 für Audio, 50020-50039 für Video und 50040-50059 für Desktop Sharing. Zuletzt gibt es natürlich noch einfach Probleme beim IP-Routing Wenn Clients "private IP-Adressen" nutzen und in unterschiedlichen Firmen sind, dann können Sie sich nicht direkt erreichen.

Daher versuchen Client immer noch einen "TURN-Kandidaten zu erhalten. Dazu gibt es TURN-Server, die in der Regel eine routingfähige öffentlichen IP-Adresse haben und von überall erreichbar sind. Er kann also von allen Clients erreicht werden aber auch Verbindungen zu allen anderen unbekannten Gegenstellen aufnehmen.

Die "Relay-Funktion" wird natürlich nicht "jedem" angeboten, sondern nur bekannten Clients.

Beim ICE-Handshake (Siehe auch ICE, Kandidaten, STUN und TURN) werden die Adressen zwischen Client und TURN-Server nicht sichtbar, da sie für die Gegenseite ja keinen Mehrwert haben. Die Verbindung zwischen Client und TURN-Server ist quasi ein Tunnel aber muss natürlich hinsichtlich QoS etc. wie die normale RTP-Verbindung betrachtet werden.

Während bei einer Installation On-Premises der TURN-Server quas über interne Kanäle mit dem internen Client spricht, ist bei Office 365, d.h. Skype for Business Online und Teams der TURN-Server bei Microsoft in der Cloud.

TURN-Konfiguration auf dem Client

 Wer einen VoIP-Client einrichtet, kann in den Einstellungen in der Regel einen TURN-Server eintragen. Einige Anwendungen benennen den Server auch als STUN, was genau genommen nicht richtig ist. Ein STUN-Server hilft dem Client nur sein möglicherweise funktionierende eigene öffentliche IP-Adresse zu ermitteln aber übernimmt keinen aktiven Teil in der Media-Übertragung. Oft ist aber der STUN-Server zugleich auch der TURN-Server. Hier einmal am Bespiel von X-Lite


Konfigurationsdialog X-Lite

Bei Skype for Business, Lync und Teams bekommen die Anwender mit der Anmeldung die Information vom Backend als Antwort auf einen SERVICE-Request im Rahmen des Inband Provisioning mitgeliefert.

SIP/2.0 200 OK
ms-user-logon-data: RemoteUser
Via: SIP/2.0/TLS 192.168.178.50:56096;received=46.85.242.39;ms-received-port=56096;ms-received-cid=8E7900
Authentication-Info: TLS-DSK qop="auth", opaque="xxx", srand="xxx",  
          snum="xx", rspauth="xxx", targetname="sfbfe1.uclabor.de", realm="SIP Communications Service", version=4
FROM: "Carius, Frank"<sip:user1@uclabor.de>;tag=xx;epid=xx
TO: <sip:sfbedge.uclabor.de@uclabor.de;gruu;opaque=srvr:MRAS:xxxxx>;tag=xx
CSEQ: 1 SERVICE
CALL-ID: xxx
CONTENT-LENGTH: 1204
CONTENT-TYPE: application/msrtc-media-relay-auth+xml
SERVER: RTCC/6.0.0.0 MRAS/3.0

<?xml version="1.0"?>
<response xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  
          requestID="897401560" version="3.0" serverVersion="3.0" 
          to="sip:nawsfbedge.uclabor.de@uclabor.de;gruu;opaque=srvr:MRAS:8Buruu_mTlqTVNfl1Jz1BAAA"  
          from="sip:user1@uclabor.de" reasonPhrase="OK"  
          xmlns="http://schemas.microsoft.com/2006/09/sip/mrasp">
  <credentialsResponse credentialsRequestID="897401560">
    <credentials>
      <username>xx+xx/x+x+x==</username>
      <password>+x+x/x+x=</password>
      <duration>480</duration>
    </credentials>
    <mediaRelayList>
      <mediaRelay>
        <location>internet</location>
        <hostName>avedge.uclabor.de</hostName>
        <udpPort>3478</udpPort>
        <tcpPort>443</tcpPort>
      </mediaRelay>
      <mediaRelay>
        <location>intranet</location>
        <hostName>sfbedge.uclabor.de</hostName>
        <udpPort>3478</udpPort>
        <tcpPort>443</tcpPort>
      </mediaRelay>
    </mediaRelayList>
  </credentialsResponse>
</response>

Hier sind gut die Relay-Server für den internen und externen Zugriff zu sehen. Die Felder für Benutzername und Kennwort (username und password) enthalten keine AD-Benutzer sondern temporäre Einmaldaten, die der Edge-Server zur Laufzeit erstellt. Diese Kommunikation ist zumindest bei Microsoft per TLS gesichert ist.

TURN Client zu Server Verbindung

Wenn sich hinter dem Namen "avedge.uclabor.de" sich dann zwei oder sogar mehr IP-Adressen verbergen, dann macht der Client hier sogar eine Lastverteilung. Ich habe das einmal simuliert, indem ich den Namen per "HOSTS-"Datei auf Server gelenkt, die es nicht gibt und in Wireshark das verhalten betrachtet habe.

Es ist gut zu sehen, dass der Skype for Business Client hier beide Edge-Server parallel anspricht. In dem Beispiel sind beide absichtlich nicht erreichbar. Er wird also bei dem Server "hängen" bleiben, der zuerst antwortet. Sollte hingegen ein anderer Service auf 443 antworten, dann kommt der TLS-Handshake noch zustande aber mit den dann darin übertragenen Daten kann die Gegenseite in der Regel nichts anfangen. Allerdings braucht der Client dann schon etwas länger, um den Fehler zu melden. Der Fall kann also passieren, wenn Sie z.B. in einem WLAN sich anmelden und die Portalseite auch auf HTTPS reagiert.

TURN Authentifizierung

Wenn ihr Client dann eine RTP-Übertragung starten will, dann baut er auch eine Verbindung zum TURN-Server auf, der ihm entsprechende Kandidaten zuweist. Das ist per Wireshark sehr einfach zu erkennen. Dabei nutzt der Client einen Source-Port aus der vom Administrator zugewiesenen Portrange und als Zielport dann 3478 für Audio/Video/Video Based Screen Sharing (VBSS) oder 443 für TCP-Übertragungen, z.B. Dateitransfer oder Desktop-Sharing. Hier exemplarisch eine Anforderung eines TURN-Kandidaten per UDP

Das erste Paket enthält als UDP-Payload die Anmeldung

Die Antwort enthält aber die IP-Adresse per XOR "verschlüsselt".

Wobei ein XOR keine richtige Verschlüsselung ist aber zumindest einfache Firewalls, die im Rahmen von "NAT" vielleicht gerne jede gefundene Adresse stumpf übersetzen, überlisten kann. Eine Firewall, die auch ICE, STUN und TURN versteht, sollte es dann auch richtig machen.

TURN Media UDP

Die eigentlichen Nutzdaten innerhalb einen TURN-Paket sind nur verschlüsselt, wenn der Datentrum generell per SRTP verschlüsselt ist. Wireshark kann das aber per Default erst einmal nicht erkennen. Sie müssen daher die UDP-Verbindung mit "Decode as" auf RTP stellen, um den Inhalt zu sehen.

Hier sehen sie vermutlich eine Teilnahme in einer Konferenz, in der Sprache mittels G.722 vom Edge-Server zum Client zurück gesendet wird. Der Client hat hier wohl mit seinem Source-Port 50008 eine ausgehende Verbindung zum TURN-Server etabliert, die nun in Gegenrichtung genutzt wird. In die andere Richtung wird ein für Wireshark unbekannter Codec 111 genutzt. 111 steht vermutlich für "SIREN/16000". Sicher können Sie aber nur sein, wenn Sie die SIP-Handshake-Messages dazu haben.

TURN Media TCP

Wenn statt Sprache und Bilder aber Daten zu übertragen sind, dann ist die Nutzung von TCP angesagt. Nur mit TCP braucht sich die Anwendung selbst keine Gedanken darüber zu machen, dass die Pakete alles lückenlos und in der richtigen Reihenfolge eintreffen. TURN funktioniert auch über TCP. Skype for Business und Teams nutzen dazu den Port 443, der als generische HTTPS-Port in vielen Firewalls erst einmal erlaubt ist. Wireshark decodiert dies als SSL.

Leider konnte ich bislang diese Daten in Wireshark noch nicht als RTP decodieren lassen, da Wireshark diese Option nur für UDP-Pakete anbietet. Insofern bleibt hier erst mal nur die Betrachtung der Paketanzahl und der Länge, um Veränderungen auf dem Transportweg zu erkennen.

Da es sich bei TCP in der Regel um Übertragungen von Dateien oder Bildinhalten (RDP) handelt, sollten Sie auch Pakete sehen, die die Ethernet-Größe, hier 1514 Bytes) erreichen. Es wird natürlich immer wieder kleinere Pakete geben um z.B. Mausbewegungen und Tastatureingaben zu übertragen. Wenn Sie aber andauern nur kleine Pakete sehen, dann könnte eine Firewall ihre Pakete stören. Achten Sie aber darauf, dass sich auch wirklich den RTP over TCP-Stream analysieren, denn sowohl der Skype als auch Teams-Client senden auch noch andere Pakete über 443, z.B. SIP oder Telemetrie.

Weitere Links