|
Es gibt bereits einige standardisierte Vorschläge das NAT-Traversal Problem zu lösen. Allgemein kann man diese in für
den NAT-Router transparente und nicht transparente Lösungen unterteilen. Bei den nicht transparenten Lösungen wird der
NAT explizit konfiguriert und angewiesen, alle an einem bestimmten Port eingehenden Pakete an einen ausgewählten Host
weiterzuleiten (Port Forwarding). Dies kann jedoch auch von einer Anwendung dynamisch gesteuert werden, Microsoft nennt
dies Universal Plug and Play (UPnP) [MS 01]. Transparente Lösungen ermöglichen NAT-Traversal ohne eine explizite
Konfiguration des NAT. Unter anderem angetrieben von Applikationen wie Skype [Skype], die auch über NAT-Router hinweg
funktionieren, entstanden vor allem im VoIP-Bereich Standards, die transparentes NAT-Traversal ermöglichen. Die
wichtigsten Vertreter hierbei sind STUN [RoW 03] und TURN [RoH 03]. Alle bislang aufgeführten Lösungen haben jedoch den Nachteil, dass sie bei bestimmten Ansätzen für NAT (z.B. symmetrische NATs) nicht funktionieren und es somit dem Benutzer überlassen bleibt, den NAT entsprechend zu konfigurieren. Genau hier setzt ICE [Ros 03] an. Das Framework für VoIP versucht automatisch das am besten geeignete Verfahren für NAT-Traversal zu finden und somit den Benutzer zu entlasten. Leider berücksichtigt ICE bislang lediglich transparente Techniken und ist sehr eng mit VoIP bzw. SIP [RoS 02] verzahnt. Mit einer allgemeinen Lösung für das NAT-Traversal Problem, unabhängig vom Transport-Protokoll und der Anwendung, kann deshalb auch ICE nicht dienen. Des weiteren werden Entscheidungen des Benutzers (z.B. bestimmte Interfaces wie „UMTS nie benutzen“ oder „UMTS nur im Notfall benutzen“) nicht berücksichtigt. Um nun verschiedene NATs testen zu können exisiert ein kleiner Testclient, der eine Request-Response Prozedur durchführt. Zunächst ermittelt der Testclient via STUN die NAT-Topologie. Hierzu wird eine UDP-Verbindung zu einem öffentlichen STUN-Server aufgebaut. Hierbei wird auch ein möglicher öffentlicher Endpunkt (public IP, port) bestimmt. Danach sucht der Client nach möglichen UPnP Geräten und versucht ein Mapping zu erstellen. Schlägt dies fehl, wird der Ansatz UPnP verworfen. Um nun die Konnektivität zu testen, werden alle möglichen (durch STUN und UPnP ermittelten) Endpunkte über eine TCP-Verbindung zu einem öffentlichen Testserver übertragen. Diese Nachricht hat in etwa folgende Struktur: <?xml version="1.0"?> <NATS_Candidates_real> <C0 IP="134.1.2.3" Port="51000" Protocol="tcp" ID="2" Description="UPnP"/> <C1 IP="134.1.2.3" Port="49123" Protocol="tcp" ID="0" Description="STUN"/> </NATS_Candidates_real> Der Testserver wertet die Anfrage aus und schickt daraufhin einen "Hole Punching Request:" <?xml version="1.0"?> <NATS_HolePunchingRequest> <request Protocol="tcp" sPort="17005" dPort="49705" DestIP="82.63.9.28"/> </NATS_HolePunchingRequest> Dieser weist den Testclient an, ein speziell präpariertes Paket zu verschicken und somit einen neuen Zustand im NAT zu generieren. Dieses spezielle Paket muss so aussehen, dass ein nun vom Testserver initiierter Verbindungsaufbau für eine Antwort auf das ausgehende Paket gehalten wird und somit zum internen Host weitergeleitet wird. Diese Technik wird als "Hole Punching" bezeichnet und ist in [DKeg] beschrieben. Man könnte nun Bedenken bezüglich der Sicherheit anmelden, jedoch sollte man wissen, dass ein so generiertes "Loch" nach ca. 30 Sekunden Inaktivität automatisch wieder geschlossen wird. Das Timing spielt beim Hole Punching also eine wichtige Rolle. Übrigens ist Skype eine Anwendung, die ihren Erfolg auch der Hole-Punching-Technik verdankt. Der NAT-Tester führt insgesamt folgende Tests durch: * per STUN wird die Topologie bestimmt und ein öffentlicher Endpunkt ermittelt * es wird nach UPnP fähigen Internet-Gateway-Devices (IGD) gesucht und versucht ein Mapping zu erstellen * jetzt erfolgt ein Konnektivitätstest für UDP: - wenn möglich am UPnP erzeugten Mapping - per UDP-Hole-Punching * danach das selbe für TCP: - wenn möglich am UPnP erzeugten Mapping - per TCP-Hole-Punching * Auswertung des Tests und Weiterleitung auf Ergebniswebseite Um das Vorgehen des Testclients nochmals zu verdeutlichen, hier ein kleines Schaubild: 
Bei weiteren Fragen, einfach eine E-Mail an muellera at ri.uni-tuebingen.de
|
|
Technische Universität München Institut für Informatik Netzarchitekturen und Netzdienste |
Network
Address
Translator - Tester
Kontakt: Andreas Müller - mueller (at) net.in.tum.de Andreas Klenk - klenk (at) informatik.uni-tuebingen.de |