Diskussion:Session Traversal Utilities for NAT

Funktionsweise - Frei erfunden

Das was unter Funktionsweise geschrieben steht, halte ich für frei erfunden...
@Stefreak: Ich würde gerne mal deine Quellen sehen...

• "Sowohl Alice als auch Bob haben eine permanente TCP-Verbindung mit einem STUN-Server aufgebaut ..."
  

Das ist falsch. Die meisten STUN-Server lauschen generell nur auf UDP. Eine TCP-Verbindung zu einem STUN-Server ist erst seit RFC 5389 (erschienen Oktober 2008) möglich. Eine dauerhafte Verbindung zum STUN-Server macht IMHO keinen Sinn. Generell ist die Verwendung von TCP für STUN derzeit noch unüblich. Will man als Transportschicht für die Nutzdaten UDP verwenden, so muss man dies auch für STUN tun. (Edited: 12:55, 6. Mai 2009 (CEST))

• "[...] somit kennt dieser die öffentlichen Adressen von Alice und Bob [...] Der VoIP-Client von Alice fragt den STUN-Server nach der Adresse von Bob ..."
  

Das ist ebenso falsch. Das würde ja auch vorraussetzen, dass man bei dem STUN-Server so etwas wie einen "Account" besitzt. Wie sollte er sonst identifizieren, wer da hinter einer offenen TCP-Verbindung steckt?

Ein STUN-Server kann generell nicht die öffentliche Adresse eines Kommunikationspartners widergeben. Vielmehr gibt er mit Hilfe des STUN-Protokolls Informationen über den Typ des eigenen NATs und die eigene öffentliche Adresse/Port wieder. (Edited: 12:55, 6. Mai 2009 (CEST))

STUN funktioniert im groben Umriss folgendermassen:
Der STUN-Server besteht aus zwei Netzwerk-Devices und hat somit 2 IP-Adressen und 2 Ports auf denen er lauscht (und zwar nur UDP). IP-Adresse1 ist dem Client bekannt bzw. im DNS verzeichnet (z.B. stun.example.com). Port1 ist der in RFC 3489 vorgeschriebene STUN-Port 3478. IP-Adresse2 und Port2 gibt der Server auf Anfrage des Clients heraus. Der Client beginnt nun eine Reihe von Sequenzen unterschiedlicher Anfragen an die IP-Addressen und Ports des Servers zu senden. Aus den Antworten des STUN-Servers auf diese Requests ergibt sich (nach dem z.B. in der englischen Wikipedia abgebildeten Algorithmus) der Typ des NATs/bzw. der Firewall, eine öffentliche IP-Adresse und ein Port für UDP Kommunikation.
Da der Client nun den Typ des NATs kennt, kann er daraus ableiten ob eine direkte Kommunikation über UDP möglich ist oder nicht.
Hier gilt es verschiedene Fälle zu unterscheiden: Oftmals ist eine Direktverbindung nur unter Zuhilfenahme eines Vermittlungsservers zur Intialisierung möglich. In einigen Fällen (z.B. bei sog. "Symmetrischen NATs") ist eine direkte UDP Verbindung mittels STUN überhaupt nicht möglich. In diesem Fall würde beispielsweise ein VoIP Telefonat über einen Proxy-Server (sog. Mediaproxy) laufen.
MfG --WaldorfStatler 17:56, 5. Mai 2009 (CEST) (Edited: 12:55, 6. Mai 2009 (CEST))

Nachtrag: habe soeben den entsprechenden Abschnitt bei der QS-Informatik zur Überarbeitung eingetragen.

--WaldorfStatler 18:42, 5. Mai 2009 (CEST)

Könnte es sein dass stefreak STUN mit TURN verwechselt? Ich werde seinen Beitrag jedenfalls am Wochende löschen, es sei denn es kommt was qualitativ gehaltvolles nach. --Kgfleischmann 18:16, 6. Mai 2009 (CEST)

RFC 5389

Der neue STUN-RFC bringt eine Reihe Änderungen, eine Auswahl

1. Verwendbarkeit mit TCP
2. Aufgabe des Anspruches, ein NAT-Traversal-Verfahren zu sein
3. allerdings Abwärtskompabilität zu RFC3489

Was die verwendbaren NAT-Traversal-Verfahren neueren Datums sind, wird zwar angedeutet, hier scheint in der IETF noch einiges in Bewegung zu sein.

Conclusio: Das im beanstandeten Absatz beschriebene NAT-Traversal-Verfahren ist:

1. aus RFC3489-Sicht schlicht falsch, WaldorfStatler hat das weiter oben nachgewiesen
2. aus RFC5389-Sicht ist es nicht richiger, passt aber zusätzlich nicht in das Lemma. Das Beschreiben etablierter NAT-Traversal-Verfahren könnte Gegenstand eines eigenen Artikels sein.

Der Absatz hat sich also als löschwürdig herausgestellt. --Kgfleischmann 08:53, 10. Mai 2009 (CEST)

Funktionsweise mal bitte genau erklären

Also der bisherige Artikel ist bis jetzt ein Witz. Er geht in keinster Weise darauf ein, wie STUN genau funktioniert. Hier weiter oben in der Diskussion hat Benutzer WaldorfStatler ja schonmal eine Erklärung abgegeben, kann man das nicht irgendwie in den Artikel einarbeiten und weiter ausbauen? Momentan ist der Artikel so gut wie nicht hilfreich. Auf der englischen WP Seite gibt es wenigstens schonmal eine Grafik die versucht die Funktionsweise von STUN zu erklären. --95.208.206.15 22:24, 3. Jan. 2010 (CET)

Die Beanstandungen von WaldorfStatler, was Steafreaks Beitrag anbetrifft, wurden eingearbeitet. Im sonsten bitte nicht STUN mit NAT verwechseln und ggfls. mal ein wenig RFC 5389 schmökern. Gruß --Kgfleischmann 00:38, 4. Jan. 2010 (CET)

Also ich sehe nirgends, daß die Funktionsbeschreibung von WaldorfStatler in den Artikel eingearbeitet wurden. Die letzte Änderung ist vom 4. Januar gegen etwa 0:30. Reden wir über den selben Artikel? --95.208.207.244 19:59, 4. Jan. 2010 (CET)

Und ich sehe nicht, dass du den RFC 5389 gelesen hättest. Im sonsten ist hier niemand verpflichtet irgend etwas einzubauen. --Kgfleischmann 21:53, 4. Jan. 2010 (CET)

Nachdem ich grade mal überlegt hab wie 2 Rechner hinter NAT miteinander eine Verbindung aufbauen können, muss ich auch sagen dass der Artikel nicht wirklich so erhellend ist, aber weiter oben hat WaldorfStatler entscheidendes plausibel erklärt: nicht immer hilft STUN. Ich würde sogar meinen im Standardfall = beide Rechner hinter NAT & keiner im Router als DMZ eingestellt - geht nichts. Hmm... --Itu 12:34, 5. Feb. 2010 (CET)

Auch dir nochmals geflüstert, STUN ist kein NAT-Traversal-Verfahren. STUN nimmt eine unterstützende Funktion ein. Daher ist es nicht die Aufgabe dieses Artikels, NAT-Traversal zu erklären. Im Übrigen, was geht und nicht geht, hängt von den Eigenschaften des benutzten NAT ab. Und hier gibt es bis dato keine Standardisierung die in der Praxis angekommen wäre. --Kgfleischmann 16:22, 5. Feb. 2010 (CET)