White paper. Bei der Network Address Translation kann es im Zusammenhang mit VoIP-Applikationen zu folgenden Problemen

Transkript

1 White paper VoIP und Firewalls VoIP-Applikationen werden zum Aufbau von Audioverbindungen zwischen Endsystemen genutzt. Dabei wird, anders als bei der klassischen Telefonie, ein paketvermitteltes IP-Netzwerk als Trägermedium der Sprach- und Signalisierungsdaten verwendet. Die Applikationen können auf verschiedenen Protokollfamilien basieren, wobei im Wesentlichen die H.323- und die SIP-Protokollfamilie eingesetzt werden. Inzwischen ist eine Verschiebung von den den VoIP-Markt dominierenden H.323-Protokollen hin zu den SIP-Protokollen absehbar. Je nach Stand der Technik muss sich der Netzbetreiber im Bereich der Sicherheit mit den Funktionen und Mechanismen der in seinem Netzwerk eingesetzten Protokolle auseinandersetzen. Innerhalb einer vernetzten Umgebung sorgen spezielle Sicherheitsfunktionen für eine Zugangskontrolle an den Netzwerkgrenzen. Hierzu wurden die klassischen Router mit zusätzlichen Firewall-Funktionen ausgestattet oder gänzlich durch Firewall-Systeme ersetzt. Firewalls bestehen in der Regel aus Paketfiltern, Proxies, Stateful Filtern oder aus einer Kombination dieser Komponenten. Eine Firewall analysiert den Netzverkehr zwischen den angeschlossenen Netzwerken und leitet nur Datenströme in das jeweilige andere Netz weiter, die einer vorgegebenen Sicherheitsregel entsprechen. Zusätzlich zur Analyse der Datenströme werden Firewalls teilweise auch dazu eingesetzt, die interne Netzstruktur einer Organisation zu verbergen. Aus dem externen Netz (z.b. dem Internet) ist der einzig sichtbare und deshalb direkt angreifbare Rechner die Firewall selbst. Dieses Verbergen der internen Strukturen wird mit Hilfe eines als Network Adress Translation (NAT) bezeichneten Mechanismus realisiert. Die den Firewalls zugrunde liegenden Architekturen sowie die internen Mechanismen und die Betriebsart der Firewalls haben sich in den letzten Jahren nicht wesentlich geändert. Aus der Einführung neuer Applikationstypen, zu denen auch IP-Telefonie gehört, ergeben sich jedoch neue Anforderungen, denen eine Firewall gerecht werden muss. Existierende Firewalls haben große Probleme, diesen Anforderungen gerecht zu werden, wenn diese IP-Telefonieanwendungen wie es im Augenblick die Regel ist wie herkömmliche Applikationen behandelt werden. Damit die VoIP-Applikationen im täglichen Betrieb eingesetzt werden können, ist es notwendig, ein harmonisches Zusammenwirken mit vorhandenen Security-Policies sicherzustellen. Network Address Translation (NAT) Bei der Network Address Translation kann es im Zusammenhang mit VoIP-Applikationen zu folgenden Problemen kommen: die Anrufsignalisierung scheitert bei eingehenden Gesprächen, es funktioniert zwar die Anrufsignalisierung, doch hört mindestens ein Gesprächspartner den anderen nicht. Das Problem besteht darin, dass aus dem Internet eingehende Datenpakete den Empfänger nicht erreichen. Die VoIP-Pakete müssen hierfür: an eine öffentliche IP-Adresse gerichtet sein, an den korrekten Client (Softphone/VoIP-Hardware) im jeweiligen internen Netz geleitet werden. Hierzu dürfen die VoIP-Daten nicht durch ein NAT-System oder eine Firewall blockiert werden. Viele Router/Firewalls wurden ursprünglich nicht für die Vermittlung von VoIP konzipiert und können die für SEITE 1

2 VoIP notwendigen Protokolle mehr schlecht als recht weiterleiten. Daher gilt als Grundlage für ein ordnungsgemäßes Funktionieren der Firewall: Die von dem Hersteller bereitgestellte aktuelle Firmware muss installiert werden! Breitbandvernetzung Grundsätzlich gehen Breitbandnutzer wie folgt ins Internet: Direktverbindung ins Internet: Ist ein Computer direkt per Ethernet an ein DSL-Modem angeschlossen, erfolgt die Einwahl über den jeweiligen Computer. Der Computer bekommt vom jeweiligen Internet- Provider eine eindeutige öffentliche IP-Adresse zugeteilt, unter der zu diesem Zeitpunkt dieser Computer aus dem Internet erreichbar ist. Alle Anfragen aus dem Internet oder Antworten auf Anfragen vom Computer werden diese öffentliche IP-Adresse erreichen. Je nach Art des Breitbandzuganges können jedoch Router (und damit NAT-Systeme) im Netz des Internet Service Provider Verbindungsprobleme bereiten. Verbindung über ein Gateway (Router): Der Computer ist nicht direkt an das Modem angeschlossen, sondern kommuniziert über einen Router mit dem Internet. Dadurch erfolgt die Einwahl nicht mehr durch den Computer, sondern durch den Router. Die öffentliche IP-Adresse führt nur zum Router. Dieser leitet die Daten anschließend an eine interne IP-Adresse des Zielcomputers (das Endgerät) weiter. Die interne IP- Adresse ist von außerhalb des privaten Netzes (aus dem Internet) somit nicht direkt erreichbar. Der Sinn und Zweck der Network Address Translation (NAT) besteht darin, dass nicht nur ein Computer, sondern mehrere Computer oder sonstige Endgeräte (jeweils mit einer eindeutigen internen IP-Adresse) die Internetanbindung nutzen können. Theoretisch könnte zwar auch jeder Computer eine eigene öffentliche IP-Adresse nutzen (mit der angenehmen Konsequenz, dass man damit sämtliche NAT-Probleme umgehen könnte), doch sind IP-Adressen (bis auf weiteres) ein knappes und damit kostenrelevantes Gut. Das NAT-System ist also eine Art intelligente Weiterleitung. Die Bezeichnung Network Address Translation macht jedoch deutlich, dass es sich bei diesem Verfahren auch um eine Übersetzung handelt. Übersetzt werden interne bzw. private IP-Adressen in externe bzw. öffentliche IP-Adressen. Erweitert man den Übersetzungsprozess um die Port-Nummern, spricht man von der Port Address Translation (PAT; im Englischen auch als Overload bezeichnet). PAT ist also eine spezielle Funktionalität innerhalb der Network Address Translation. Router-Funktionsweise Werden Daten aus dem Internet an den Router gesendet, überprüft der Router in seiner vollautomatisch und laufend aktualisierten internen Routing-Tabelle, ob diese Daten von einem der Computer oder einer anderen Netzwerkkomponente im privaten Netzwerk angefordert wurden. Es gelten folgende Regeln: Weiterleitung aufgrund einer vorhergehenden Benutzeranfrage: Ein Nutzer sendet beispielsweise einen HTTP Request (Aufruf einer Website) an einen Webserver. Dessen Antwort leitet der Router genau an diesen Nutzer weiter. Dazu werden in der internen Routing-Tabelle die jeweiligen Adressinformationen (Absender IP-Adresse und -Port, Empfänger IP-Adresse und -Port) als Address-Mapping für einen bestimmten Zeitraum (Session) gespeichert. Keine Weiterleitung: Wurden Daten dagegen nicht von einem internen Nutzer angefordert oder wurde der Mapping-Eintrag nach Ablauf einer bestimmten Zeit gelöscht, werden die ankommenden Daten vom Router verworfen und an keine interne IP-Adresse weitergeleitet. Weiterleitung an feste Adresseinträge: Um Server und andere interne Ressourcen auch aus dem Internet erreichen zu können, müssen sie über feste Adressen erreichbar sein. Hierfür werden in der internen Routing-Tabelle die jeweiligen Adressinformationen (Absender IP-Adresse und -Port, Empfänger IP-Adresse und -Port) als Address-Mapping permanent gespeichert und die Anfragen aus dem Internet entsprechend weitergeleitet. SEITE 2

3 Rechner A IP: Port: 80 IP: , Port: Public Internet NAT IP: , Port: Rechner B IP: Port: 80 Abbildung: Prinzip der Network Address Translation NAT-Typen Bei NAT-Systemen unterscheidet man zwischen folgenden Typen: Full Cone Restricted Cone Port Restricted Cone Symmetric Cone Full Cone NAT Bei einem Full Cone-System erfolgt die IP-Adressumsetzung unabhängig von einer vorher ausgehenden Verbindung anhand von festen Adresseinträgen. Beispielsweise nutzt ein Computer hinter dem NAT-System die IP-Adresse und sendet bzw. empfängt die Datenpakete über Port Diese Adressen werden vom NAT-System auf die externe (öffentliche) IP-Port-Adresse :12345 umgesetzt. Jeder Nutzer des externen Netzes kann somit seine Pakete an den öffentlichen IP-Port schicken. Diese werden automatisch vom NAT-System an den Computer mit der Adresse :8000 weitergeleitet. Rechner A IP: Port: Client IP: Port: 8000 NAT Rechner B IP: Port: Source IP: Port: Abbildung: Full Cone Restricted Cone Beim Restricted Cone NAT erfolgt ein Address-Mapping nur, wenn dieses durch eine ausgehende Verbindung angestoßen wurde. Sendet ein interner Rechner seine Pakete an einen externen Rechner 1, dann übersetzt SEITE 3

4 das NAT-System per Mapping die Client-Adresse :8000 auf : Der externe Rechner 1 kann dadurch seine Pakete direkt an den internen Client (via Address-Mapping) zurücksenden. Das NAT- System blockiert jedoch alle eingehenden Pakete von anderen Absendern. Port Restricted Cone Das Port Restricted Cone NAT arbeitet vom Prinzip her ähnlich wie das Restricted Cone NAT. Ein Address- Mapping erfolgt nur, wenn dieses durch eine ausgehende Verbindung (Erkennung anhand der IP- und Port- Adresse) angestoßen wurde. Sendet der interne Client einen Datenstrom an den Port eines externen Rechners 1, dann ermöglicht das NAT nur die bidirektionale Übermittlung an dessen IP-Port-Adresse : Übermittelt der Client mehrere Pakete zu mehreren IP-Port-Paaren, können diese selbstverständlich auch parallel über die Mappings mit dem Client kommunizieren. Symmetric Cone Das Symmetric Cone NAT unterscheidet sich grundsätzlich von den bisher dargestellten NAT-Mechanismen. Das Mapping der internen IP-Port-Adresse auf die öffentliche IP-Port-Adresse hängt dabei von der Ziel-IP- Adresse des zu übermittelnden Pakets ab. Sendet beispielsweise ein Client mit dem Adresspaar :8000 an den externen Computer B, wird ein Address-Mapping auf das externe Adresspaar :12345 vorgenommen. Sendet der gleiche Client vom gleichen Port ( :8000) seine Pakete an eine andere Zieladresse (Computer A), wird das Mapping auf die Adresse :45678 vorgenommen. Die externen Rechner (A und B) können nur ihre Pakete an den Client zurückschicken, indem sie die Pakete an die jeweilige NAT Mapping-Adresse schicken. Alle Versuche der externen Rechner, die Pakete an ein anderes Address- Mapping zu übermitteln, führen zu einem Verwerfen (Dropping) der Pakete. Rechner A IP: Port: Port: Client IP: Port: 8000 NAT Rechner B IP: Port: Source IP: Port: Abbildung: Symmetric Cone NAT-Verhalten bei Voice over IP-Endgeräten Eine auf dem Session Initiating-Protokoll (SIP) basierende Telefonverbindung hat zwei Mechanismen als Grundlage: die Signalisierung (Messages zum Aufbau der Telefonverbindung), den Media Stream (die eigentlichen Telefonnutzdaten). Die Anrufsignalisierung, die sich dem Benutzer als Telefonklingeln des Endgeräts bemerkbar macht, wird über das SIP-Protokoll (Session Initiation Protocol) realisiert. Endgeräte können beispielsweise eine Softphone- Anwendung auf einem PC, ein Adapter für den Anschluss von Analog- bzw. ISDN-Telefonen oder ein echtes SEITE 4

5 IP-Telefon sein. Für eine korrekte Anrufsignalisierung eingehender Gespräche müssen die entsprechenden eingehenden SIP-Datenpakete das NAT-System passieren dürfen. Die SIP-Signalisierung wird über ein NAT-System problemlos übertragen. Typischerweise werden die SIP-Pakete immer zuerst vom Client zu einem Proxy (dem ersten Hop nach dem NAT-System) übermittelt. Der Proxy empfängt die SIP Messages vom Client (über das NAT) und antwortet an dessen Adresse. Somit muss der Proxy nur die SIP-Pakete an das gleiche IP-Port-Paar zurückschicken, über das dieser die Pakete empfangen hat. Als Standard-Signalisierungsport wird der UDP Port 5060 genutzt. SIP verfügt über so genannte Tags. Mit Hilfe der rport -Tags wird dem Proxy signalisiert, dass dieser die Beantwortung an eine spezifische IP-Adresse schicken soll. Viele der heute verfügbaren Proxies unterstützen jedoch die rport -Tags nicht. Einige Clients leiten die SIP Messages auch nicht an die von den Tags spezifizierten Ports um. Im Prinzip ist dieser Mechanismus in der Lage, per NAT die Datenströme korrekt zu mappen. Ein anderer und wesentlich einfacher Weg zur korrekten Nutzung der NAT-Dienste besteht im Einsatz des TCP-Protokolls für den Transport der SIP-Signalisierung zwischen Client und Proxy. Eine TCP-Verbindung wird vom Client direkt über das NAT-System zum Proxy geöffnet, und die Informationen werden in beide Richtungen problemlos anhand der Mappings übertragen. Leider unterstützen die meisten Proxies kein TCP und arbeiten ausschließlich auf der Basis des UDP-Protokolls. Die SIP-Signalisierung sollte trotzdem problemlos mit allen vier NAT-Typen arbeiten. Voraussetzung hierfür ist, dass der Proxy die SIP Messages immer von dem gleichen Source Port, über den die Message empfangen wurde, zurückschickt. Zu Beginn der SIP-Signalisierung wird die SIP Message an den Proxy IP-Port übermittelt. Diese Message legt das Mapping im NAT-System an. Über diese Adresszuweisung übermittelt der Proxy seine Antworten an das NAT-System. Die Registrierung eines Clients, der sich hinter einem NAT-System befindet, erfordert folgende Funktionen: einen Registrar, der das betreffende IP-Port-Paar (als Source der SIP Message) in der Registrationsinformation speichert, einen Client, der die extern gemappte Adress- und Port-Informationen kennt und diese in die Kontaktinformationen (als IP-Port, der die SIP Messages empfängt) einfügt. In beiden Fällen ist darauf zu achten, dass das Registrationsintervall immer kürzer als die Keep Alive -Zeit des NAT-Mappings ist. Die eigentliche Audio-Übertragung erfolgt beim VoIP auf Basis des Real Time Transport-Protokolls (RTP). So wie für die Anrufsignalisierung eine Portweiterleitung erforderlich ist, müssen im Prinzip auch die für die Audio-Übertragung benötigten Ports weitergeleitet werden. Die Port-Nummern variieren je nach Endgerät (häufig: UDP-Port 8000). In einer SIP Message werden zwischen den beiden Endpunkten die notwendigen Informationen festgelegt, um direkt miteinander kommunizieren zu können. Die Informationen werden in einer angehängten SDP Message transportiert. Hierfür füllen die Endpunkte (Clients) das entsprechende Header-Feld mit den notwendigen Informationen. Befindet sich ein Client hinter einem NAT-System, kennt dieser selbstverständlich nur seine internen IP-Port-Adressen. Diese Adressinformationen fließen gemäß den SIP-Regeln in die SDP Message ein. Möchte ein Empfänger (Destination Endpoint) seine Pakete an das andere Ende der VoIP-Verbindung schicken, nutzt dieser die empfangenen SDP-Informationen (interne IP-Port-Adresse des ursprünglichen Senders). Da sich auf dem Weg über das NAT-System die IP-Port-Adressen geändert haben, erreicht die Message nie den Kommunikationspartner. Im folgenden Beispiel ist eine vom Gateway empfangene INVITE Message eines SIP-Client (befindet sich hinter einem NAT-System) dargestellt. Der Proxy befindet sich zwischen NAT- System und dem Gateway. Beispiel: 001 INVITE SIP/ Via: SIP/2.0/UDP :5060;branch=a71b6d57-507c77f2 003 Via: SIP/2.0/UDP :5060;received= ;rport= From: SEITE 5

6 005 To: sip: 006 Contact: sip: 007 Call-ID: 008 CSeq: INVITE 009 Content-Length: Content-Type: application/sdp 011 User-Agent: HearMe SoftPHONE v=0 014 o=deltathree 0 0 IN IP s=deltathree 016 c=in IP t= m=audio 8000 RTP/AVP a=ptime: a=x-ssrc:00aea3c0 Die IP-Adresse in Zeile 003 des SIP-Headers enthält die vermeintliche IP-Adresse des Client (beispielsweise die interne IP-Adresse: ). Da der Proxy weiß, von welcher IP-Adresse das Paket empfangen wurde, fügt dieser die Received - und Rport -Tags mit den aus der im NAT-System resultierenden Adressübersetzung IP- und Port-Adressen in die Message ein. Die Tags sorgen auf dem Proxy für das korrekte Zurücksenden der SIP Messages via NAT an den Client. Die notwendigen Informationen zur Übermittlung der Sprachdaten (via RTP) werden in den Zeilen 014 und 016 eingefügt. In diesem Fall erwartet der Client den Empfang von Paketen auf Port 8000 (m=) auf der IP-Adresse (c=). Dieses IP-Port-Paar steht für den Empfang von Daten auf dem internen Netz bereit. Aus diesem Grund wird vom internen Client auch erwartet, dass der Kommunikationspartner seine Pakete an dieses Adresspaar schickt. Die Folge ist, dass zwar eine ordnungsgemäße Signalisierung (Call Set up) via NAT funktioniert, aber keine Nutz-/Sprachdaten übermittelt werden. Befindet sich der Client hinter einem der drei ersten NAT-Typen, dann sieht eine Lösung des Problems wie folgt aus: Der Client muss herausfinden, auf welche öffentliche Adresse das interne IP-Port-Paar übersetzt wurde. Diese Information wird anschließend in die SDP Message (statt der internen IP-Port-Adresse) eingefügt. Hierzu stehen grundsätzlich folgende Methoden zur Verfügung: Anfrage beim NAT-Server, Anfrage bei einem Gerät außerhalb des NAT. Anfrage beim NAT-Server Ein Client kann die Abfrage nach einem bestimmten IP-Port-Mapping beim NAT-Server auf Basis des von Microsoft entwickelten Externer Link Universal Plug & Play (UPnP) durchführen. Externer Link UPnP ermöglicht Windows-Geräten das Erkennen und Steuern von UPnP-Geräten und hat nichts mit den Plug & Play -Funktionen beim Anschluss externer Hardware zu tun. Unterstützt das NAT-Gerät die UPnP-Funktion (und wurde diese auch tatsächlich aktiviert), kann dann auch ein NAT-System als UPnP-Gerät in Windows eingebunden und automatisch konfiguriert werden (und erscheint unter Netzwerkumgebung ). Das heißt, es werden die jeweils nötigen Ports automatisch freigegeben. Der Client fragt beim NAT-Server via UPnP das aktuelle Mapping für den Empfang von Paketen für Port X ab. Der NAT-Server reagiert auf die Abfrage mit einem IP-Port-Paar, über das der Client vom externen Netz erreicht werden kann. Einige Hersteller von NAT-Komponenten unterstützen bereits UPnP in ihren Produkten. UPnP funktioniert nicht in Installationen mit kaskadierten NAT-Systemen. Verfügt beispielsweise ein ISP über einen Block von IP-Adressen, der nicht ausreicht, um alle Nutzer abbilden zu können, nutzt der ISP das NAT, um die verfügbare Anzahl der IP-Adressen zu vergrößern. Benötigt einer der Kunden des ISP mehrere IP-Adressen (beispielsweise ein Internetcafé), wird ein eigenes NAT-System auf der Verbindung zwischen Internetcafé und ISP installiert. Versucht ein Client des Internetcafés per UPnP die öffentliche IP-Port-Adresse abzufragen, erhält dieser nur das lokale Address-Mapping vom NAT des Internetcafés. Da das Address-Mapping des ISP (NAT zwischen dem externen Port des NAT des Internetcafés und dem öffentlichen Internet via NAT des ISP) nicht bekannt ist, lassen sich die Sprache bzw. die RTP-Ströme trotzdem nicht korrekt übermittelt. SEITE 6

7 Anfrage bei einem Gerät ausserhalb des NAT Da das UPnP von vielen Endgeräten nicht unterstützt wird, muss eine offene und allgemein gültige Methode zur Lösung des NAT-Problems gefunden werden. Der Client fragt das externe IP-Port-Address-Mapping bei einem im öffentlichen Internet (außerhalb des NAT-Systems) installierten Server ab. Der Server am öffentlichen Internet wird auch als NAT Probe bezeichnet. Empfängt die NAT Probe ein Anfragepaket, antwortet diese mit dem öffentlichen IP-Port-Paars des Anfragers. In allen der vorher beschriebenen NAT-Lösungen muss der Client nach der Antwort der NAT Probe folgende Entscheidung treffen: Befindet er sich hinter einem NAT-System (die IP-Port-Adresse im Antwortpaket unterscheidet sich von der eigenen IP-Port-Adresse)? Welche öffentliche IP-Port-Adresse muss in die SDP Message eingefügt werden, um für einen externen Kommunikationspartner erreichbar zu sein? Endpunkt Rechner A IP: Port: 8000 NAT IP: Port: NAT Probe Abbildung: Anfrage der öffentlichen IP-Port-Adresse Soll der Client über die Adresse :8000 erreicht werden, sendet dieser von Port 8000 eine Anfrage an die NAT Probe. Die NAT Probe empfängt die Anfrage von der Adresse : Daher beantwortet die NAT Probe mit der IP-Port-Adresse : Anschließend fügt der Client folgende Informationen in sein ausgehendes SDP-Paket: m= AUDIO und c= Danach erwartet er den Empfang von RTP-Paketen auf der IP-Port-Adresse :8000. Diese Lösung geht jedoch von folgenden Voraussetzungen aus: Der Client muss die RTP-Daten über den gleichen Port senden und auch empfangen. Der Client muss die SIP Message kurz nach dem Empfang der Antwort von der NAT Probe aussenden. Eine längere Verzögerung zwischen der Antwort der NAT Probe und dem Aussenden der SIP Message hätte eventuell eine Änderung des NAT-Mappings zur Folge. Im Falle von Restricted Cone oder Port Restricted Cone NATs muss der Client zuerst ein Paket an den zukünftigen Kommunikationspartner (Endpunkt) schicken, um das NAT-System dazu zu bringen, die Pakete vom Kommunikationspartner ordnungsgemäß an den Client durchzulassen. Ausnahme Die dargestellte Lösung funktioniert jedoch im Fall von Symmetric NATs nicht, da sich die IP-Adresse der NAT Probe von der Adresse des Endpunkts unterscheidet. STUN Das Simple Traversal of UDP Through NATs (STUN) ist ein Protokoll zur korrekten Installation der vorher beschriebenen NAT Probe. Mit Hilfe von STUN-Servern können die Datenströme des Datentransportprotokolls SEITE 7

8 UDP durch ein NAT-System zum VoIP-Endgerät geleitet werden. STUN ist nur einsetzbar bei nicht-symmetrischen NAT-Systemen; bei einem symmetrischen NAT-System muss auf einen so genannten Outbound-Proxy- Server ausgewichen werden, über den dann sämtliche SIP Sessions geleitet werden. Viele VoIP-Clients unterstützen bereits den STUN-Mechanismus und setzen die SDP-Informationen daher korrekt. STUN Requests definieren die folgenden Parameter: RESPONSE-ADDRESS Change IP Change Port Der STUN-Server sendet seine Pakete immer an die im RESPONSE ADDRESS-Attribut spezifizierte IP-Port- Adresse. Ist in diesem Feld keine Adresse vermerkt, sendet der Server seine Antwort an das im Request spezifizierte IP-Port-Adresspaar. Wurden sowohl das Change IP als auch das Change Port Flag nicht gesetzt, antwortet der STUN-Server mit dem IP-Port-Adresspaar, an den das ursprüngliche Paket übermittelt wurde. Ein gesetztes Change IP Flag führt zu einer Serverantwort mit unterschiedlicher IP-Adresse; ein gesetztes Change Port Flag führt zu einer Serverantwort mit unterschiedlicher Port-Adresse. Die STUN Response enthält folgende Informationen: MAPPED-ADDRESS: das IP-Port-Adresspaar des Clients aus der Sicht des ersten STUN-Servers außerhalb des NAT, der den STUN Request empfangen hat. CHANGED-ADDRESS: die IP-Adresse des antwortenden STUN-Servers, wenn im Request das Change IP Flag gesetzt war. SOURCE-ADDRESS: das IP-Port-Adresspaar, über den der STUN Response beantwortet wurde. Anhand einer Kombination unterschiedlicher Requests an den STUN-Server kann der Client Folgendes herausfinden: Befindet er sich direkt am Internet? Befindet er sich hinter einer Firewall, welche UDP Messages blockiert? Befindet er sich hinter einem NAT-System, und um welchen NAT-Typen handelt es sich dabei? Automatische Erkennung der NAT-Umgebung Anhand von vier einfachen Tests kann der Client seine NAT-Umgebung erkennen. Die folgende Tabelle zeigt die jeweiligen Testparameter und die zu erwartenden Responses. Aus Gründen der Redundanz stehen zwei STUN-Server (IP1 und IP2) zur Verfügung, die sowohl über Port 1 als auch über Port 2 ihre Antworten schicken können. Die Übermittlung eines Requests an IP1 (ohne Setzen des Change IP oder Change Port Flags) führt zu einer Beantwortung durch den STUN-Server von IP1, Port 1. Das Setzen des Change IP Flag führt zu einer Response von IP2:1 etc. Test Destination Ändern der IP-Adresse Ändern der Port-Adresse Antwort IP-Port Test 1 IP1:1 nein nein IP1:1 Test 2 IP1:1 ja ja IP2:2 Test 3 IP2:1 nein nein IP2:1 Test 4 IP1:1 nein ja IP1:2 SEITE 8

9 Test 1 Test 2 Test 3 Port 1 STUN Server IP2 Port 2 Umgebung STUN Client Port 1 Port 2 STUN Server IP2 Test 4 Abbildung: Tests zur Erkennung der NAT-Umgebung Zur Erkennung der NAT-Umgebung werden die Tests durch einen Client wie folgt durchgeführt: Test 1 wird ausgeführt: Empfängt der Client keine Antwort, weiß dieser, dass er sich hinter einer Firewall befindet, welche die Übermittlung von UDP-Paketen verhindert. Nach einer empfangenen Response wird die IP-Adresse des MAPPED-ADDRESS-Felds der STUN Response mit der ursprünglichen Adresse des Clients verglichen. Sind beide IP-Adressen gleich, wird der Test 2 (Change IP und Port) angestoßen: Wird keine Response empfangen, ist der Client über eine symmetrische UDP-Firewall mit dem Internet (öffentlichen Netz) verbunden. Die Firewall erlaubt jedoch nur die bidirektionale UDP-Kommunikation zu einer Zieladresse, wenn der Client vorher an das Ziel mindestens ein Paket übermittelt hat. Empfängt der Client eine Response, dann weiß der Client, dass er direkt (unblockiert) mit dem öffentlichen Netz verbunden ist. Gleichen sich die IP-Adressen in Schritt 2 nicht, wird Test 2 ausgeführt. Empfängt der Client eine Response, dann befindet er sich hinter einem Full Cone NAT. Empfängt der Client keine Response, startet der Client den Test 3 und vergleicht die im MAPPED-ADDRESS- Feld der STUN Response (empfangen von IP2) enthaltene IP-Adresse mit der im Test 1 (empfangen von IP1) empfangenen IP-Adresse des MAPPED-ADDRESS-Felds. Entsprechen die beiden IP-Adressen nicht einander, befindet sich der Client hinter einem symmetrischen NAT-System. Entsprechen die beiden IP-Adressen einander, führt der Client den Test 4 (Change Port) aus. Empfängt der Client eine Response, dann befindet sich der Client hinter einem Restricted NAT-System. Empfängt der Client keine Response, dann befindet sich der Client hinter einem Port Restricted NAT- System. SEITE 9

10 Test 1 UDP geblockt Response? Gleiche IP? Test 2 nein nein Test 2 Response? Symmetr. NAT Gleiche IP wie 1? Test 3 Response? Offenes Internet ja nein nein ja Symmetr. UDP Firewall ja Test 4 ja Full Cone NAT Response? nein Port Restricted NAT ja Restricted NAT Abbildung: Ablauf des NAT-Discovery Lösungen für symmetrische NATs Die bisher dargestellten Lösungen (NAT Probe oder STUN-Server) arbeiten nur bei den ersten drei NAT-Typen korrekt. Symmetrische NATs nutzen je nach IP-Zieladresse unterschiedliche Adressmappings. Daher ist das Mapping zwischen Client und der NAT Probe unterschiedlich zum Mapping zwischen dem Client und dem Gateway. Im Fall eines symmetrischen NAT-Systems muss der Client die RTP Messages über die gleiche IP-Adresse aussenden und auch empfangen. Jede RTP-Verbindung zwischen einem Endpunkt außerhalb des NAT- Systems und einem Endpunkt innerhalb eines NAT-Systems muss in Form einer Punkt-zu-Punkt-Verbindung aufgebaut werden. Dies gilt auch für den Fall, dass bereits eine SIP-Verbindung aufgebaut wurde. Der VoIP- Endpunkt außerhalb des NAT-Systems muss immer darauf warten, dass der Client ihm zuerst ein Paket schickt, bevor er weiß, wohin er seine Antworten schicken muss. Dieser Vorgang wird auch als verbindungsorientierter Modus bezeichnet. Soll ein Endpunkt sowohl mit Clients hinter dem NAT-System als auch mit Clients am offenen Netz (Internet) kommunizieren, muss dieser wissen, wann er der in der empfangenen SDP Message enthaltenen Information vertrauen kann, wann er warten muss, bis er direkt vom Client ein Paket empfängt, bevor dieser einen Kanal zum Source IP-Port des Pakets aufbaut. Eine Möglichkeit, die notwendige Information zu erlangen, besteht darin, dass der Endpunkt auf ein Paket (wird vom Client hinter dem NAT-System verschickt) wartet, in dem in der SDP Message folgende Zusatzinformation enthalten ist: a=direction:active Empfängt ein Endpunkt diese Zeile, weiß er, dass der Client aktiv eine IP-Port-Adresse festlegt, an die der Endpunkt den RTP Stream schicken soll. Gleichzeitig dient diese Information auch als Hinweis, dass die IP- Port-Informationen in der empfangenen SDP Message ignoriert werden müssen. Die heutigen SIP-Clients unterstützen den a= Tag meist nicht. Daher muss eine Art Übersetzer im SIP-Pfad eingefügt werden, der festlegt, dass sich ein Client hinter einem symmetrischen NAT-System befindet. Der Übersetzer hat darüber hinaus die Aufgabe, die a=direction:active -Zeile in die SIP Message einzufügen. SEITE 10

11 RTP-Relay Unterstützt ein Endpunkt den verbindungsorientierten Modus, sind die Probleme des Übergangs über symmetrische NAT-Systeme gelöst. Folgende Szenarios bleiben jedoch problematisch: Wenn der Endpunkt den a=direction:active Tag nicht unterstützt. Wenn sich beide Endpunkte hinter symmetrischen NATs befinden. In beiden Fällen hilft der Einsatz eines RTP Relays. Diese Komponente wird in den RTP-Strom zwischen den beiden Endpunkten eingefügt. Das RTP Relay agiert dabei als Zwischenendpunkt für die beiden an der Kommunikation beteiligten Endpunkte. Typischerweise wird hierfür ein Server in den SIP-Datenfluss (dieser wird auch als NAT-Proxy bezeichnet) eingefügt. Der NAT-Proxy modifiziert die SDP Message so, dass die beiden Endpunkte ihren RTP-Strom nicht direkt miteinander, sondern über den Relay-Mechanismus miteinander austauschen. Das Relay-System baut anschließend ein eigenes Mapping für die betreffende Session auf und verzeichnet darin die Source IP-Ports der jeweiligen Endpunkte zur Übermittlung des RTP-Datenstroms NAT Proxy User Agent (SIP Telefon) Symmetrische NAT 10 Voice Gateway RTP Relay Abbildung: Ablauf des NAT-Discovery Ablauf der Verbindung: Der UA übermittelt über das NAT-System eine INVITE Message an den NAT-Proxy. Der NAT-Proxy kontaktiert das RTP Relay und fordert dieses zu einem Aufbau einer Session auf. Das RTP Relay ordnet die notwendigen Ports der Verbindung zu. Es antwortet dem NAT-Proxy mit dem verfügbaren Port im RTP Relay. Der NAT-Proxy nutzt diese Information und modifiziert die SDP-Information des empfangenen INVITE Requests. Der NAT-Proxy leitet den SIP INVITE Request mit dem modifizierten SDP (Verweis auf das IP-Port-Adresspaars des RTP Relays) an das Voice Gateway weiter. Das Gateway antwortet (in der 200 OK Message) mit seiner eigenen SDP-Information (inklusive des Ports, über den RTP-Pakete empfangen werden sollen). Der NAT-Proxy kontaktiert das RTP Relay und übermittelt die IP-Port-Information des Gateways. Befindet sich das Gateway hinter einem symmetrischen NAT, dann teilt der NAT-Proxy dem Relay-Mechanismus mit, auf Pakete vom Gateway zu warten, bevor die IP-Port-Informationen zur Weiterleitung der RTP Messages in Richtung Gateway festgelegt werden. Das Relay antwortet dem NAT-Proxy mit dem in der Upstream-Richtung festgelegten RTP-Port. Der NAT-Proxy leitet die Response (nach der Modifikation der Response SDP mit der entsprechenden IP- Port-Information des RTP Relays) zurück an den UA. Der UA übermittelt die RTP-Pakete an den in der 200 OK Message definierten IP-Port des RTP Relays. Der RTP Relay registriert die IP-Port-Informationen des empfangenen Pakets und leitet das Paket an die IP-Port-Adresse des Gateways weiter. Die RTP-Pakete vom Gateway werden an das RTP Relay weitergeleitet. Das RTP Relay leitet die Pakete an den Client weiter. Nach dem Empfang einer BYE Message durch den NAT- Proxy wird diese Information an das RTP Relay weitergeleitet. Dieses baut anschließend die Session ab. SEITE 11

12 Hierbei müssen folgende Aspekte beachtet werden: Der Client muss immer die RTP Messages über den gleichen Port empfangen bzw. übermitteln. Diese Lösung arbeitet grundsätzlich mit allen NAT-Systemen. Sie hat jedoch den Nachteil, dass der RTP Relay unter Umständen erhebliche Verzögerungen hervorruft. So lange der Client noch kein Paket an den RTP Relay übermittelt hat, ist der Client nicht in der Lage, die Sprachpakete zu empfangen. Dies kann beim Empfang einer 183 Message Probleme verursachen. In diesem Fall öffnet das Gateway einen unidirektionalen Mediastream und übermittelt darüber die Network Announcements. Hat der Client noch nicht das erste RTP-Paket, kennt der RTP Relay nicht seine öffentliche IP-Port-Adresse. Eingehende Verbindungen Alle bisher dargestellten Aspekte gelten auch für eingehende Verbindungen. SDP-Manipulation: Empfängt der Client hinter dem NAT-System eine INVITE Message, kontaktiert dieser den STUN Server, ermittelt das aktuelle IP-Port-Mapping und fügt diese Information in die SDP Message der 200 OK-Antwort ein. Connection Oriented Media: Der Client fügt bei der Antwort im SDP der 200 OK Message die Zeilen a=direction:active ein. Für den Fall, dass dieser Mechanismus nicht im Client zur Verfügung steht, kann auch folgende Zeile in die 200 OK Message eingefügt werden: c= Dadurch wird der Übersetzer gezwungen, die a= -Zeile in die Message einzufügen. Das RTP Relay und der NAT-Proxy arbeiten entsprechend und schreiben die entsprechenden Zeilen des SDP Bodys der 200 OK Message um. underground_8 secure computing GmbH assumes no responsibility for any inaccuracies in this document. underground_8 secure computing GmbH reserves the right to change, modify, transfer or revise this publication without notice. AAS, AS, DCI, DLA, LPC, MF, NGTM, PVN, RMF, SPN, Stealth, XC are registered trademarks of underground_8 secure computing GmbH underground_8 secure computing GmbH. All rights reserved. underground_8 secure computing gmbh SEITE 12