Asterisk ohne NAT in DMZ

[_Robby_]

Ich habe folgendes Problem:
Asterisk hängt in einer DMZ mit offizieller IP(!). Von Intern erreiche ich den Server ohne(!) NAT, das Netz 10.1.x.x wird zur DMZ durch geroutet. Von Aussen kann man sich ebenfalls anmelden. Wenn jetzt jemand von draussen einen internen Client anrufen will, so wird Asterisk wohl die interne IP nach draussen reichen, oder irre ich mich? (konnte es leider noch nicht testen)

Ich habe schon gesucht, aber noch keinen Ansatz zur Lösung gefunden. Kann ich Asterisk als Proxy/Gatway/Router(wie auch immer genannt) konfigurieren, so das alle Gesprächen zwischen Drinnen und Draussen direkt über den Server laufen?
Ich kann von beiden Seiten wunderbar über den CAPI in die Telefonanlage telefonieren. Auch interne Clients arbeiten tadellos.

Hat jemand ein paar Stichpunkte, wie ich die Konfiguration bewerkstelle?

Robby

 

[Blackvel]

Also, wenn Du ein internes 10.1.x.x Netz hast, dann gibt es ins Internet NUR NAT!

Ich könnte mich jetzt auch irren, aber ein 10.1.x.x Netz ist vom Internet nicht erreichbar ?

canreinvite=no hilft, dass alles über den Asterisk Server läuft.

Da intern kein NAT zum * ist, sollte man bei SIP Clients auch kein nat=yes einschalten.

Nach aussen gibt es das nat=yes flag bei Peers bzw. externip.

Das braucht man aber nur dann, wenn * HINTER NAT hängt, also nicht vom Internet direkt erreichbar ist.

Vielleicht tut ja canreinvite ja und behebt alle Probleme.
externip auf die statische externe Internet IP zu setzen, kann auf jeden Fall mal nicht schaden.

 

[_Robby_]

Also, wenn Du ein internes 10.1.x.x Netz hast, dann gibt es ins Internet NUR NAT!

Nein, mein * in der DMZ hat eine offizielle IP (212.x.x.x) Die Firewall routet allerdings die 10er nach drinnen (ohne NAT). (ich teste es bei uns in der Firma. Chef will über I-Net kostenlos in die Firma telefonieren)

canreinvite=no hilft, dass alles über den Asterisk Server läuft.

Genau danach habe ich vielleicht gesucht. Hatte diese Option bisher nicht richtig verstanden.
Werde es gleich mal testen. Danke!

Robby

 

[Blackvel]

Die Firewall routet die 10er nach drinnen ?
Hilfe, was auch immer das heissen mag.

Wenn der Firewall offizielle IP Adressen auf interne (10.x) umsetzt, dann dann sich das NAT.
Es sei denn, die 10.x wären routebar, also offizielle IPs vom Internet extern erreichbar (auch wenn der FW dann Requests blocken sollte).

 

[rollo]

Habe es so verstanden, dass in der DMZ zwei subnetze laufen, eins aus dem 10er Kreis und die offiziellen IPs. Der Asterisk müsste demnach 2 IPs haben.

Wenn er dann als externip die offizielle und als bindadress=0.0.0.0 einträgt könnte es klappen.

nat sollte dann global auf no stehen.

Der nat parameter wird übrigens oft missverstanden. Er muss nur auf yes gesetzt werden, wenn die Clients die auf Asterisk zugreifen hinter NAT sitzen, nicht wenn Astersik selbst hinter NAT sitzt.

Muss also ggfs. bei user definitionen gesetzt werden, die nicht aus dem Firmennetz zugreifen.

jo

 

[_Robby_]

Nein, es sieht so aus: die Firewall hat 3 Interfaces. Eines ins Internet, eines in die DMZ und eins für das interne Netz. Zwischen DMZ und Intranet wird geroutet, d.h. * kann sich mit dem 10.1.x.x-Netz direkt unterhalten (also über das default Gateway). * selbst hat nur eine offizielle IP (212.x.x.x). Spricht mein localer Client mit *, so wird die Adresse nicht übersetzt, sondern geroutet.
Melde ich mich aus dem Intranet herraus bei Sipgate an, wird meine Adresse natürlich durch die Firewall mittels NAT übersetzt.
Da gleichzeitig auf meinem *-Server auch ein STUN-Server läuft, funktioniert X-Lite auf meinem Notebook immer, egal, ob ich mich von Zuhause oder vom Büro aus anmelde.
Getestet hatte ich allerdings die ganze Zeit nur das Gateway nach ISDN, SIP-Clients intern, den Echo-Test oder die Konferenzoption.
Mir fiel dann heute ein, daß ich evtl ein Problem bekomme, wenn zwei SIP-Clients miteinader kommunizieren wollen, wo einer draussen und einer drinnen sitzt. Ich muss noch ein Opfer finden, der jetzt die Sache mit mir durchprobiert.

Edit: Nachtrag: Jetzt wo ich das Zauberwort "canreinvite" kenne, finde ich auch die passenden Tipps auf voip-info.org. Da gibt es noch die Option H im Dial-Kommando. Mal sehen, ob ich damit was machen kann. Ich will die internen Clients untereinander direkt sprechen lassen und nur nach draussen soll der Strom immer über * laufen.

Robby