IAX2 via VPN

[haraldk3]

Hi!

Folgende Konstellation:
Wir haben zwei Asterisk-Server in zwei mit VPN verbundenen Netzwerken: Asterisk-1 - VPN_Gateway1 - VPN_Gateway2 - Asterisk2
Die beiden Server sollen sich per IAX2 unterhalten und tun dies auch ne Zeitlang.

Folgender Fehler:
Nach einer bestimmten Zeit (+- 1 Tag) erscheint bei 'iax2 show peers': UNREACHABLE.

Notlösung: Der einzige Weg, diese Situation zu bereinigen ist, in der iax.conf diesen Peer aus zu kommentieren, 'iax2 reload', dann den Peer wieder rein zu nehmen, 'iax2 reload' und schon ist alles wieder erreichbar :noidea: Das kann's doch nicht wirklich sein???

Was ich bereits versucht habe:
echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
echo 0 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
Hilft aber nüscht. Hat vielleicht wer ne Idee? Many THX!!!

 

[gandalf94305]

Ist der VPN-Tunnel die ganze Zeit über mit den gleichen IP-Adressen (insbes. Endpunktadressen) verfügbar oder wird dieser zwischendurch mal abgebaut?

Laß mal parallel ein ping über einen Tag laufen und protokolliere die Stabilität des Tunnels. Ändert dies etwas? ;-)

--gandalf.

 

[haraldk3]

WOW, das geht ja blitzartig hier! Der VPN-Tunnel läuft mit einer fixen public IP und einer Variablen. wenn der Tunnel sich neu aufbaut (i.e. Neueinwahl des Roadworriers), dann wird auf beiden Seiten das VPN neu gestartet und die Tunnel neu aufgebaut. Danach werden alle Rechner angepingt und sind -zumindest per TCP erreichbar. Nur IAX (udp) funzt nicht mehr, obwohl iptstate keine Verbindungen mehr anzeigt, also die vorherige public IP doch eigentlich vergessen sein sollte?

 

[gandalf94305]

Das hatte ich befürchtet... Die variable IP-Adresse ist das Problem... Ist der Server, auf dem der remote Asterisk läuft, auch der Endpunktrechner? Versuche mal, auf dem remote System eine feste, virtuelle IP-Adresse zu geben, die korrekt per VPN geroutet wird und die sich nicht ändert. Verwende diese als Peer in Asterisk. Damit sollte es funktionieren. Das Problem besteht darin, daß Asterisk leider irgendwo intern sich diese IP-Adressen merkt und somit Tunnel mit variablen Endpunkten ein Problem darstellen können.

--gandalf.

 

[haraldk3]

VPN:
Asterisk-1 - VPN_Gateway1 - VPN_Gateway2 - Asterisk2
192.168.0.10 - 192.168.0.1 - 80.80.80.80 (fix) - 81.81.81.81 (var) - 192.168.1.1 - 192.168.1.10

Bedeutet, in der iax.conf steht eine unveränderte IP (host=192.168.1.10) Ich habe auch bereits nat=yes und nat=no versucht, mit gleichbleibendem Erfolg :nixweiß:

 

[gandalf94305]

Hmm... gute Frage... diese Konfiguration sieht gut aus und für die Server ist das ja völlig transparent (wobei die Nutzung von public IP-Adressen für den Tunnel fragwürdig ist - ich würde lieber 10.x.x.x nehmen).

Ggf. gibt es zwischendurch beim Neuaufbau des Tunnels ein ICMP Unreachable, wenn der Tunnel für einen Moment nicht verfügbar ist, bzw. der Asterisk kann den Peer 2 Sekunden lang nicht erreichen. Hast Du in der Peerkonfiguration qualify=no eingetragen? Oder versuche mal ein qualify mit 5 Sekunden (danach sollte der VPN-Tunnel ja wieder laufen).

--gandalf.

 

[haraldk3]

die public IP's sind defacto public, dazwischen liegt das Internet.

Qualify stand auf yes, das hab ich jetzt mal geändert auf 5, mal sehen, ob es was hilft. Was mich auch irritiert ist die Tatsache, dass eine 'stop now' gefolgt von einem 'asterisk' nicht hilft, aber eingangs beschriebene Rekonfiguration schon. Selbst nach einem bestimt auftretenden icmp unreachable sollte doch der Neustart von * helfen, dachte ich zumindest. :-(

 

[gandalf94305]

Ich glaube, qualify will Millisekunden und nicht Sekunden ;-) 5000 wäre daher besser :mrgreen: Oder zum Testen einfach mal qualify=no.

EDIT: Yep, Millisekunden: http://www.voip-info.org/wiki/view/Asterisk+sip+qualify

--gandalf.

 

[haraldk3]

:-D yep, 5000 ;-)

Meinst du, das Thema könnte interessant genug sein, um es mal bei digium zu posten?

 

[gandalf94305]

Informationen sind immer gut... aber ich glaube, morgen Abend weisst Du mehr, ob es am qualify lag ;-) Mit qualify=yes gibt es ein UNREACHABLE nach 2 s Nichterreichbarkeit. Das kann die Zeit zum Tunnelwiederaufbau sein.

--gandalf.

 

[haraldk3]

Step 1 bei auftretenden Fehlern: Upgrade auf aktuelle Version... :-Ö

Es gibt schon etliche Einträge bezüglich Timingproblemen mit IAX2 poke / pong ;-) Mal sehen, ob der Upgrade auf revision 45927 das Problem bereits beseitigt hat... Wenn ja, dann sorry fürs müllen...

 

[haraldk3]

:lamer: ok, diesmal war's nicht die Asterisk-Version sondern ein profanes Netzwerkthema... die udp-Verbindung war noch im ip_conntrac-table der VPN1 mit der falschen public IP... somit muss man diese tabelle clearen, sofern man mit roadworriern arbeiten muss.

Warum eigentlich nicht diesen ip_conntrac Wert gleich ganz auf 0 stellen? Das wiederum kann den ntpd durcheinander bringen, ist also nicht die Lösung.

...vielleicht nutzt der Thread ja Jemandem, der ein ähnliches Thema hat.

Und hier mal ein fettes DANKESCHÖN an dich, gandalf! Es hilft ja schon mal, wenn man eine weitere Meinung hört und du warst eigentlich recht richtig gelegen ;-)

 

[gandalf94305]

:keks: Na schön, daß nun das Problem erkannt und gelöst ist... aber qualify kann trotzdem auf 5000 stehen bleiben ;-)

Einen schönen Abend noch!
--gandalf.

 

[Thomas007]

qualify ist dafür nicht gedacht, funktioniert z.B. nicht wenn Du mal auf Realtime umstellst.

Wieso startest Du VPN neu wenn sich ein mobiler Benutzer anmeldet?
Das macht doch gar keinen Sinn und kann nur unnötiges Durcheinander insbesondere für bereits angemeldete Clients erzeugen.

Falls Du OpenVPN verwendest schau mal nach keepalive.

 

[fant]

Also ich vernetze hier mit OpenVPN mehrere Standorte und habe durch die Tunnels zum Teil IAX2 und zum Teil SIP laufen. Das geht ohne Probleme und ich kann den Ärger, den Ihr habt, nicht nachvollziehen.

Der ursprüngliche Grund für den Einsatz des ersten VPN zusammen mit Asterisk war, daß das leidige "Ich bin Asterisk und habe jetzt eine andere externe Adresse und deshalb mag ich nicht mehr"-Thema durch feste virtuelle Adressen im VPN ersetzt wurde. Wenn Ihr Config-Schnipsel braucht, dann meldet Euch.

Am OpenVPN-Server (Debian-Linux) hängen folgende Clients:

2xOpenVPN Client unter Linux mit Asterisk IAX2-Gegenstelle
1xOpenVPN Client unter Linux mit FritzBox als SIP-Client
1xOpenVPN-Client auf Fritzbox als SIP-Client.

Hawedieehre.
Fant

 

[stephanw]

IAX2->OpenVPN -> IAX2 Problem

Hallo
der Thread ist zwar etwas alt, aber ich versuchs mal hier. Ich habe folgendes Problem.
Zwei Asteriske sind über OpenVPN verbunden. Dabei benutze ich die TUN Variante. Das sieht dann etwas so aus:

Ast1 (eth0)(192.168.1.10) = TUN1(10.1.1.1) = TUN2(10.1.1.2) = Ast2 (eth0)(192.168.2.10)

Ping von beiden Seiten mit den 192. Adressen funktioniert einwandfrei. Eine IAX2 Verbindung kriege ich aber nur hin, wenn ich jeweils im Eintrag host=10.1.1.1 (bzw. host=10.1.1.2) eintrage. Ueber die 192.x.x.x Adressen kriege ich die Verbindung nicht hin.

Ach ja, Asterisk und OpenVPN Server (Client) laufen jeweils auf der gleichen Maschine.
Hat jemand eine Idee, wieso ich die 192. Adressen nicht verwenden kann?

 

[fant]

Hallo stephanw,

wieso willst Du überhaupt die 192er-Adressen nutzen? Nimm doch die 10er, wenn das geht. Ich nutze zur Asterisk-Kopplung auch die Adressen des VPN-Tunnels.

Ansonsten mußt Du die Routen zu den entsprechenden Rechnern eintragen. Dazu dienen die Befehle iroute und route.

Hawedieehre.
Fant

 

[stephanw]

VPN Adressen

Halllo
danke für die rasche Antwort. Ich habe die Routen eingetragen, die Netze sind von jedem Gerät aus unterneinander zu pingen.
Ich möchte die 192.er Adressen benutzen, da die Maschinen auf dem DNS mit ihren Namen auflösen.
Zudem, sollte ich den Asterisk mal von der VPN Maschine weg nehmen, dann funktionieren die 10er Adressen nicht.
Habe in IAX.conf bindaddr mal auf die 192er Adresse gesetzt. Hat aber nichts gebracht...