Stun/Nat transversal ??

[marcellus]

Hallo, ich bin gerade im begriff einen fernsteuerbaren voip anrufbeantworter zu schreiben bin jetzt aber ziemlich angeeckt. Ich hab mein Programm bis jetzt großteils aus codebeispielen zusammengestöpselt. Nun hab ich das Problem, dass ich audio daten empfangen sollte, aber da kommt nichts an und das wundert mich auch nicht wirklich, weil ich hinter einem nat sitze. Jetzt weis ich allerdings nicht, ob der sdp body den ich verschickt habe falsch ist, oder ich irgendwas mit stun unternehmen sollte.

Laut dem was ich im internet gefunden habe brauche ich stun umbedingt, aber ich tu mir schwer das einzubauen aus 2 gründen:
1. Ich versteh nicht wie das funktionieren soll, dass ein packet durch ein nat durchkommen soll, wenn ein nat ja gerade eingehende verbindungen abfangen soll und
2. Wie ich das ganze implementieren soll, weil die dokumentation ist naja nicht vorhanden.

Ich hab für meinen Anrufbeantworter die libeXosip für sip und ortp für die rtp verbindung verwendet. Wobei ortp ansich mit stun umgehen kann nur es ist halt für mich unübersichtlich dokumentiert, denn es gibt nicht mehr als:

http://download.savannah.gnu.org/releases/linphone/ortp/docs/stun_8h-source.html und http://download.savannah.gnu.org/releases/linphone/ortp/docs/stun__udp_8h-source.html

Tia

 

[der_Kay]

STUN ist kein Übertragungsprotokoll, sondern dient dazu, den Typ von NAT, hinter dem Du sitzt, zu identifizieren. "Typ" soll die Art und Weisen beschreiben, welcher Router wie IP-Adessen und Ports abbildet.

http://en.wikipedia.org/wiki/Simple_traversal_of_UDP_over_NATs

Die Penetration von NATs erreicht man z. B. durch UDP hole punching. Ein Protokoll, das die Unzulänglichkeiten von UDP kompensiert ist das Reliable User Datagram Protocol

 

[marcellus]

Das stun kein übertragungsprotokoll ist wusste ich schon, ich glaub es wäre auch ziemlich respektlos euch gegenüber, wenn ich nicht einmal die dazugehörigen wikipedia einträge gelesen hätte.

Das was mich eher interessiert ist, stun wird ja praktisch von meinem client ausgeführt, damit der client weis wies ums nat steht. Nur muss mein (angerufener)client jetzt dem gateway sagen, dass es packete durchlassen soll, oder dem (anrufenden)client mitteilen, dass der angerufene hinter einem nat sitzt und das er die packete an das gateway schicken soll oder

Naja da harperts irgendwie

Und die sonst übliche dokumentation bringt mich nicht wirklich weiter, weil ich das grundlagenwissen zu nats unterschiede usw nicht hab, aber auch bis jetzt nicht in kindergerechter form gefunden habe.

 

[der_Kay]

In http://en.wikipedia.org/wiki/UDP_hole_punching ist unter "Algorithm" beschrieben, wie es geht. Und grundsätzlich ist die Idee auch sehr einfach: Hosts, die an NAT-traversierer Kommunikation interessiert sind, halten Verbindung zu einem allgemein erreichbaren Server, der Auskunft über IPs und Ports von Kommunikationspartnern gibt. Wollen sich zwei Hosts verbinden, richten sie jeweils einen temporären Port ein, übermitteln diesen an den allgemein erreichbaren Server, der diese Informationen dem anderen Kommunikationspartner mitteilt. Soweit stehts im Algorithmus.

So funtkionierts dann weiter: Beide kennen die Verbindundungsinformationen zum Anderen und versuchen nun zu verbinden, indem sie UDP-Pakete zur jeweiligen Zieladresse schicken. Wenn z. B. Host A das erste Paket verschickt hat, wird dieses wahrscheinlich vom Router, an dem Host B hängt, verworfen, da dessen Firewall B's internes Netz schützt. Entscheidender Nebeneffekt bei A: Damit das UDP-Protokoll überhaupt funtkionieren kann, hat sich A's Router gezwungenermaßen gemerkt, dass A "etwas" vom entfernten Rechner B will und wird zumindest einen bestimmten Zeitraum lang die Firewall für Pakete auf diesem Port für UDP öffnen und etwaige Antwortpakete zu A durchrouten. Währenddessen versendet A periodisch weiter Pakete zu B.

Wenn B ungefähr zur gleichen Zeit anfängt Pakete an A zu schicken, ist wahrscheinlich B's Firewall genauso offen für Pakete von A und irgendwann erreichen alle Pakete in beiden Richtungen ihre Ziele.

Hier geht es mit den Feinheiten los: Müssen notwendigerweise für jeden Client temporäre Ports reserviert werden? STUN kann dies beantworten. Ausserdem ist ein Protokoll von Nöten, dass Verbindungsabbrüche erkennen und kompensieren kann, die z. B. auftreten, wenn ein Router den UDP-Port wieder dicht macht. In RFC908 ist hinten sogar ein Beispiel, das den Kommunikationsaufbau wie hier beschrieben zeigt.

Alle Klarheiten beseitigt?


Grüße,

Kay

 

[marcellus]

Das was mir noch kopfzerbrechen bereitet ist, das beim udp hole punching ja praktisch einer der beiden ein packet zum nat des anderen schickt. Dadurch werden dann eingehende packete auf dem port vom nat weitergeleitet. Das selbe sollte von der anderen seite passieren. Aber wozu dann der stun server, wenn das nat A1 zb sowieso nur packete von B durchlassen soll.

Oder gehts beim stun server nur darum testen zu können in was für einem nat man sitzt und dementsprechend die art der weiterleitung festzulegen?

Ich will eine receive only verbindung haben, heist das, wenn ich auch packete zum anderen schicken würde würds wahrscheinlich auch ohne stun hinhauen?

 

[der_Kay]

Das was mir noch kopfzerbrechen bereitet ist, das beim udp hole punching ja praktisch einer der beiden ein packet zum nat des anderen schickt.

In der Praxis schicken beide gleichzeitig Pakete, selbst wenn der eine nur "keep-alive"-Pakete schickt, damit die Ports offen bleiben und ansonsten nur Infos von einem "Server" entgegennimmt.

Oder gehts beim stun server nur darum testen zu können in was für einem nat man sitzt und dementsprechend die art der weiterleitung festzulegen?

Meiner Kenntnis nach ist genau das der Fall.

Ich will eine receive only verbindung haben, heist das, wenn ich auch packete zum anderen schicken würde würds wahrscheinlich auch ohne stun hinhauen?

Genau davon gehe ich aus. Ich denke, dass der "sichere" Weg ist, wenn beide Maschinen für jeden Verbindungswunsch eines Clients einen temporären Port reservieren und Pakete ausschließlich zum Partner schicken. Damit räumt man das Problem aus dem Weg, dass Pakete vom Router verworfen werden, wenn sie nicht von derselben Quelle kommen und der Router denkt, es handle sich um eine Inkjektionsattacke.

Ganz grundsätzlich ist die Idee beim NAT Traversal sich auf einen kleinsten gemeinsamen Nenner bei der Funktionsweise von NAT-Routern zu verlassen und eben ohne weitere Eingriffe wie Portforwardings Kommunikationskanäle aufzubauen.

 

[marcellus]

Vielen dank für deine Hilfe Kay,

ich glaub ich hab jetzt halbwegs überrissen was stun genau macht. Jetzt weis ich sogar auf was ich beim packet sniffen achten muss. Aber ich hab so irgendwie den verdacht, dass der anrufende client nicht einmal eine ahnung hat wohin er die packete schicken soll.

Ich meld mich wieder, wenns hinhaut

 

[marcellus]

Ich glaub ich bin wieder an dem punkt angekommen, wo ich wieder keine Ahnung davon hab was da genau passiert.

Das große Problem das ich dabei habe ist, dass ich den dump von wireshark nicht lesen kann, da sind zwischendurch packete drinnen bei denen ich nicht weis was da getan wird.

Falls vielleicht jemand da ist, der mir erklären kann was es damit auf sich hat (Kay ) würd mich das viel weiter bringen.

Das nochmal alles beieinander ist:

ortp/stun.h

Und dann natürlich noch mein testprogramm (stuntest.c), die ausgabe von meinem testprogramm (output.txt) und das was wireshark zwichendurch aufschnappt (stuntest.dmp). Alles zusammen in diesem =>Anhang anzeigen stuntest.tar.bz2<= archiv.

Vielleicht noch interessant:
192.168.0.21 ist mein rechner auf dem der test läuft
192.168.0.1 ist mein gateway
83.103.82.85 ist der stun server von ekiga.net
und 81.217.84.20 ist meine globale ip

Es könnte eh sein, dass es funktioniert, aber ich bin mir nicht sicher welche funktion was macht und ich schaff es nicht wirklich ein "fragmented ip protocol" packet einer bestimmten funktion zuzuordnen.