NAT/SIP + Traffik + Sicherheit

[VOIPmeNOW]

Hallo zusammen,

ich habe Asterisk 1.6 auf einem VServer installiert und mich von meinem Heim-Netzwerk aus per X-Lite mit Asterix verbunden. Der Echo-Test hat dabei erfolgreich funktioniert, was mich wundert, denn ich sitze hinter einem Router. Wieso habe ich hier kein NAT/SIP-Problem?


Ansonsten frage ich mich noch, ob eine interne Verbindung zwischen zwei SIP-Klienten stets immer über Asterisk läuft, oder ob der nur zum IP-Lookup dient, und die beiden Soft/Hardphones anschließend direkt miteinander kommunizieren?


Und zum Schluss: Sind die internen Gespräche verschlüsselt, und wenn ja wie? Sind es auch die Gespräche zur Mailbox (wo ja zwingend der Server direkt mit dem Teilnehmer verbunden ist)?

Viele Grüße
VOIPmeNOW

 

[rentier-s]

Hallo,

X-Lite kann von sich aus sehr gut mit NATs umgehen. Wenn Asterisk direkt erreichbar ist und nur der Client hinter dem NAT hängt, gibt's sowieso weniger Probleme.

Wenn Du canreinvite=no nicht explizit gesetzt hast kann es sein, dass Asterisk nur den Gesprächsaufbau vermittelt, die Audio-Daten aber direkt zwischen den Clients übertragen werden. Kann sein deshalb, weil es noch einiges mehr gibt, was dazu führt, dass Asterisk im Audio-Path bleibt.

SIP ist erst mal nicht verschlüsselt. Es gibt dazu extra "secure SIP".

 

[VOIPmeNOW]

Danke für Deine Antwort.

Wie finde ich denn im Zweifel raus, ob die Verbindung noch über den Server läuft?

Ich hab nochmals zum Thema reinvite gesucht und bin jetzt etwas verwirrt.

Wenn ich "canreinvite = no" setze, bedeutet es doch offenbar gerade, dass Asterisk immer als Mittelsmann zwischen Telefon A und Telefon B bleibt. Bei "canreinvite = yes" wird versucht, eine direkte Verbindung zwischen A und B aufzubauen (wenn beide die selben Codecs unterstützen, etc.), wobei Asterisk zu einem späteren Zeitpunkt wieder mit eingebunden werden kann (um ein Gespräch zu vermitteln, etc.). Andere Dienste wie Recording sind bei einer direkten Verbindung aber nicht möglich

D'Accord?

 

[rentier-s]

Bei eingeschaltetem SIP Debug sollte man das sehen können. Weiß ich aber nicht gewiss.

Warum bist Du verwirrt? canreinvite ist standardmäßig yes, also musst Du ausdrücklich canreinvite=no setzen, damit Asterisk sicher im Audio-Path bleibt. Wenn canreinvite nicht oder =yes gesetzt ist, kann das aber trotzdem der Fall sein, dass Asterisk dazwischen bleibt. Wenn sich zB. die Geräte nicht über einen Codec einigen können, oder wenn Du im Dial eine Option gesetzt hast, die das Überwachen von DTMF-Eingaben erfordert.

 

[VOIPmeNOW]

Ja du hast Recht, da habe ich vorhin deinen Text falsch verstanden. Okay, passt. Mit canreinvite=no bleibt Asterisk in jedem Fall dazwischen.

 

[VOIPmeNOW]

Hallo,

X-Lite kann von sich aus sehr gut mit NATs umgehen. Wenn Asterisk direkt erreichbar ist und nur der Client hinter dem NAT hängt, gibt's sowieso weniger Probleme.

Wieso ist es nicht egal, WER hinter einem NAT hängt? Ich meine, es spielt doch keine Rolle, ob X-Lite und/oder Asterisk die lokale Rechner-IP vom Heim-Netzwerk anstatt die Öffentliche in die Nachricht schreibt. Mindestens ein Datenstrom erreicht seinen Zielrechner nicht und geht verloren?!

 

[rentier-s]

Im Grunde hast Du Recht. Ich weiß nicht genau wie ich das erklären soll (bin auch nicht sooo die Netzwerkexpertin), aber wenn Asterisk hinter restriktiven NAT Typen hängt, kann das aufwendig zu konfigurieren sein. Wenn der Client hinter einem NAT ist, reicht oft schon ein nat=yes beim jeweiligen Client in der sip.conf.
Hier ist das als Punkt 4 aufgeführt, "möglich aber tricky".
Am besten wir streichen das aus dem Protokoll.

(fass mal die zwei Beiträge lieber zusammen, bevor das einer der Mods sieht)

 

[stinkstiefel]

Bei eingeschaltetem SIP Debug sollte man das sehen können. Weiß ich aber nicht gewiss.

Jep, aber RTP Debug ist diesbezüglich etwas übersichtlicher.

 

[schufti]

Hi!

Also zumindest in der 1.6er kann * noch kein STUN, daher ist es mit * hinter NAT nicht so einfach, man muß die externe IP "händisch" eintragen.
Aber mit dem Eintrag und Zugriff auf die FW (Port Forwarding) hat es auch mit * hinter NAT ohne gröbere Probleme geklappt (kann aber Zufall gewesen sein).

schufti