Unified-Communications & Collaboration
Der Teufel steckt auch bei WebRTC im Detail
Fortsetzung des Artikels von Teil 1
Die zweite Herausforderung: NAT & Firewall
Neben der Signalisierung muss WebRTC in der Lage sein, mit NAT-Verfahren (Network Adress Translation) und Firewalls umzugehen. Ein NAT ist ein Routing-Verfahren, bei welchem den Rechnern eines privaten Netzes ein gemeinsamer Zugang zum Internet ermöglicht wird. Bei diesem Verfahren werden die privaten IP-Adressen registriert und öffentlich registrierten IP-Adressen zugeordnet. Die internen Adressen bleiben verborgen und werden so vor dem „Internet“ geschützt. Der Router mit NAT steht also zwischen Teilnehmer und Internet und sorgt aus Sicherheitsgründen dafür, dass keine direkte Verbindung zwischen ihnen aufgebaut werden kann. Ein praktisches Beispiel: Die beiden Teilnehmer, welche die Kommunikationsverbindung aufbauen wollen, wissen aufgrund von NAT & Firewall nicht, welche Netzwerk-Topologien zwischen ihnen liegen – der Verbindungsaufbau scheitert.
Der Grund für die Komplexität: Sicherheit
Neben der Signalisierung existiert ein weiterer Prozess. Dieser sorgt für den tatsächlichen Nutzdatenaustausch. In einer idealen Welt würde jeder Teilnehmer über eine eindeutige Adresse verfügen, die es ihm ermöglicht, sich direkt mit anderen Teilnehmern auszutauschen. In der Praxis ist es aber häufig so, dass sich die meisten Geräte hinter einem Router mit NAT und Firewall „verstecken“, welche aus Sicherheitsgründen rigoros bestimmte Ports und Protokolle sperren. Da jedoch die Ad-hoc-Kommunikation von Teilnehmer zu Teilnehmer wesentlicher Bestandteil von Web-RTC-Anwendungen ist, muss es zwingend Möglichkeiten geben, trotz NAT & Firewall schnelle, direkte Verbindungen zu realisieren. Sonst hätten Unternehmen nicht die Chance, die Erreichbarkeit welche sie sich von einer WebRTC-basierten Lösung versprechen, auch zu garantieren. Es gibt drei praktikable Lösungsansätze, die genannten Schwierigkeiten zu überwinden: STUN-Server (Session Traversal Utilities for NAT), TURN-Server (Traversal Using Relays around NAT) und ICE-Agenten (Interactive Connectivity Establishment).
Helfer in der Not: STUN, TURN und ICE
Tatsache ist, dass die oft beschworene direkte Verbindung mitunter schwierig zu erreichen ist. Erleben zwei Nutzer erfolgreiche Audio/Video-Chats über den Browser, so sind diesen zuvor ziemlich sicher zahlreiche Schritte und ausgetauschte Datenströme vorausgegangen, bei denen auch die Helfer Stun, Turn und ICE zum Einsatz kamen.
ICE-Agenten identifizieren die beste Verbindung: Der ICE-Mechanismus ist ein Standard der IETF (Internet Engineering Task Force), welcher es einem IP-System in einem privaten Netz ermöglicht voneinander unabhängige alternative Kontaktinformationen mit einem IP-System im öffent-lichen Netz priorisiert an den jeweiligen Kommunikationspartner zu übergeben. Kurz gesagt suchen die ICE-Agenten den „besten“ Weg, um zwei Teilnehmer miteinander zu verbinden. Alle Möglichkeiten werden dabei parallel getestet und die beste ausgewählt. Zuerst versuchen die ICE-Agenten eine Verbindung herzustellen indem die lokale IP Adresse des Rechners benutzt wird, welche sie vom Betriebssys-tem eines Gerätes erhalten haben. Wenn dies fehlschlägt und das ist immer dann der Fall, wenn das NAT-Verfahren genutzt wird, verwenden die ICE-Agenten im nächs-ten Schritt eine externe Adresse, wofür sie wiederum einen Stun-Server verwenden.
Stun-Server kennt die öffentliche IP-Adresse: Der Stun-Server dient einer Aufgabe, dem Identifizieren der öffentlichen IP-Adresse. Er liegt im öffentlichen Internet und überprüft die IP-Adresse einer eingehenden Anfrage und sendet diese an den Teilnehmer zurück, der sie gestellt hat. So erfährt dieser Teilnehmer seine öffentliche IP-Adresse, die er dann dem anderen via Signalisierung zukommen lässt, um eine direkte Verbindung aufzubauen.
Laut aktuellen Studien kann WebRTC in 86 Prozent der Fälle – Quelle www.webrtcstats.com – mittels Stun eine direkte Verbindung zweier Teilnehmer aufbauen. In den anderen 14 Prozent liegen jedoch sehr komplexe NAT-Verfahren und Firewalls vor. Dann reicht ein Stun-Server alleine nicht mehr aus. Man benötigt die nächste Ins-tanz: Den Turn-Server.
Turn-Server leitet auch im komplizierten Fall Datenströme weiter: Es existieren verschiedene Arten eines NAT-Verfahrens, die unterschiedliche Firewall-Funktionen definieren. Welche auch vorliegen mag, das NAT-Verfahren entscheidet zu welcher privaten IP-Adresse im Unternehmen er die Anfrage eines Teilnehmers verbinden muss. Jetzt kann es allerdings sein, dass eine Firewall im Unternehmen den angemeldeten Datenverkehr aufgrund von Restriktionen nicht durchlässt. Gerade Provider haben in der Regel eine sehr sichere Firewall um die zahlreichen angebundenen Geräte möglichst optimal zu schützen. Ist beispielsweise bei einem Audio/Video-Chat eines der Geräte ein Mobilgerät und noch dazu über 3G eingeloggt, wird der Datenaustausch erschwert. Ist dies der Fall, muss die Versendung der Daten über einen Turn-Server erfolgen. Der Turn-Server enthält Regeln zum Datenversand. Er wird verwendet, um das Audio/Video- und Datenstreaming zwischen Teilnehmern weiterzuleiten. Turn-Server haben immer öffentliche Adressen, sodass sie von Teilnehmern im Internet problemlos kontaktiert werden können. Dies gilt auch wenn sich die Teilnehmer hinter einem Router mit NAT-Funktion und einer Firewall befinden. Folglich kann man sagen: Je höher die Sicherheitsmechanismen von NAT-Verfahren und Firewall, desto wahrscheinlicher wird ein Turn-Server Einsatz, da ein Stun-Server alleine nicht ausreicht.
Resümee und Tipp
Die Analyse hat gezeigt, dass es verschiedene technische Rahmenbedingungen gibt, welche es zu beachten gilt, wennUnternehmen eine WebRTC-basierte Kommunikationslösung als neue Möglichkeit für den Kundenkontakt in Echtzeit nutzen wollen. Als kommender Standard für hürdenlose Echtzeitkommunikation liegen mit Web-RTC definierte Standards beispielsweise für Audio- und Video-Codecs vor. Andere Prozesse, wie für die Signalisierung der Kommunikationssitzung sind jedoch dem Applikationsentwickler überlassen.
Die Analyse hat weiter aufgezeigt, dass Sicherheitsmechanismen, wie das Vorhandensein eines NAT-Verfahrens und Firewalls mitunter den Einsatz von einem Stun-Server, ICE-Agenten oder einem Turn-Server erfordern. Dennoch bietet eine WebRTC-basierte Kommunikationslösung gerade kleineren und mittelständischen Unternehmen eine neue Form der hürdenlosen Kundenkommunikation, die als nichtproprietärer Ansatz ohne Plug-ins auch von weniger technisch affinen Personen genutzt werden kann.
Um die volle Erreichbarkeit und Funktionalität der Lösung zu gewährleisten ist es ratsam, dass ein Fachmann sie im Unternehmen implementiert, der mit den zahlreichen Netzwerkanforderungen vertraut ist. Dann steht der hürdenlosen Kommunikation nichts mehr im Weg.
- Der Teufel steckt auch bei WebRTC im Detail
- Die zweite Herausforderung: NAT & Firewall
- Expertenkommentar: Freie Wahl beim STUN- und TURN-Server
Lesen Sie mehr zum Thema
