Stun/Nat transversal ??

Dieses Thema im Forum "C/C++" wurde erstellt von marcellus, 24.08.2008.

  1. #1 marcellus, 24.08.2008
    marcellus

    marcellus Kaiser

    Dabei seit:
    09.05.2007
    Beiträge:
    1.392
    Zustimmungen:
    0
    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
     
  2. Anzeige

    Schau dir mal diese Kategorie an. Dort findest du bestimmt etwas.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  3. #2 der_Kay, 24.08.2008
    Zuletzt bearbeitet: 24.08.2008
    der_Kay

    der_Kay Doppel-As

    Dabei seit:
    28.02.2006
    Beiträge:
    140
    Zustimmungen:
    0
  4. #3 marcellus, 24.08.2008
    marcellus

    marcellus Kaiser

    Dabei seit:
    09.05.2007
    Beiträge:
    1.392
    Zustimmungen:
    0
    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.
     
  5. #4 der_Kay, 24.08.2008
    Zuletzt bearbeitet: 24.08.2008
    der_Kay

    der_Kay Doppel-As

    Dabei seit:
    28.02.2006
    Beiträge:
    140
    Zustimmungen:
    0
    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
     
  6. #5 marcellus, 24.08.2008
    marcellus

    marcellus Kaiser

    Dabei seit:
    09.05.2007
    Beiträge:
    1.392
    Zustimmungen:
    0
    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?
     
  7. #6 der_Kay, 24.08.2008
    Zuletzt bearbeitet: 24.08.2008
    der_Kay

    der_Kay Doppel-As

    Dabei seit:
    28.02.2006
    Beiträge:
    140
    Zustimmungen:
    0
    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.

    Meiner Kenntnis nach ist genau das der Fall.

    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.
     
  8. Anzeige

    Vielleicht findest du HIER Antworten.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  9. #7 marcellus, 24.08.2008
    marcellus

    marcellus Kaiser

    Dabei seit:
    09.05.2007
    Beiträge:
    1.392
    Zustimmungen:
    0
    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
     
  10. #8 marcellus, 26.08.2008
    marcellus

    marcellus Kaiser

    Dabei seit:
    09.05.2007
    Beiträge:
    1.392
    Zustimmungen:
    0
    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 :D) 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 => Den Anhang stuntest.tar.bz2 betrachten <= 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.
     
Thema:

Stun/Nat transversal ??