per OpenVPN an SIP Registrar anmelden kommen 2 IP's an

[greenhornXXL]

Hallo zusammen


Ich habe eine 7270 die sich erfolgreich per OpenVPN im Netzwerk anmeldet.
Routing und PC Kommunikation fkt. auch super.

Nun möchte ich das sich die 7270 per OpenVPN an die Telefonanlage (Avaya Integral I55) per SIP anmeldet.

Im Debug Log der Integral kommen 2 IP's zeitgleich an.
Einmal meine OpenVPN IP und zusätzlich meine IP vom ISP ?!!?

Da sich nun beide IP's zeitgleich um die gleiche Rufnummer schlägen denke ich kommt der Connect nicht zustande.

Hat vielleicht jemand eine Idee wie ich diese Problem lösen könnte ?!

Besten Dank im voraus

greenhornXXL

 

[woprr]

Firewall-/Routingfehler auf dem Server, der darf die VPN-Pakete nicht ins LAN forwarden die dürfen nur den vpn-daemon erreichen.

Trotzdem vpn-konfiguration mit verb 5 checken.

 

[greenhornXXL]

Hallo woprr


Ich habe deinen Ansatz verfolgt und bin zu folgendem Ergebnis gekommen.

Der erste Kontakt zur Telefonanlage kommt mit der VPN-IP zustande.
Anschliessend möchte die Telefonanlage die Regestrierung bestätigen und sendet das Packet an die DSL-IP.

Es sieht für mich so aus das die IP des Quellsystems sich im Paket versteckt was die Telefonanlage auswertet/entpackt und an diese Quell-IP wird dann die antwort geschickt die nicht ankommt da das DSL Netz im internen LAN nicht bekannt ist.

Demzufolge müsste ich dem Client (Fritzbox) mitteilen welche IP es zur regestrierung benutzen soll. Ich könnte auch alternativ die dtmfbox als Client nutzen - wenn mir jemand verrät wie ich diesen Client an das tun0 Interface binden kann, könnte ich die Theorie weiter verfolgen.

Besten Dank für die Infos

 

[woprr]

Es sieht für mich so aus das die IP des Quellsystems sich im Paket versteckt

Ja, in den Daten im SIP REGISTER-Paket. Den SIP-client der 7270 so konfigurieren dass er das WAN-Interface nicht benutzt/sieht.

 

[hermann72pb]

Die Idee an sich ist ein bisschen krank SIP über OpenVPN zu tunneln. Ich bezweifle stark, dass es überhaupt mit brauchbaren Ergebnissen klappt geschweige von eurer Motivation entweder den Admin von eurem Büronetz oder den Provider zu verarschen wenngleich die beiden diese SIP-Verbindung nicht wünschen.

Deswegen überlegt euch bitte gut, was ihr da tut.

MfG

 

[woprr]

Und wie lauten die fachlichen Begründungen für Deine Zweifel?

 

[greenhornXXL]

@woprr

Den SIP-Client würde ich gerne so konfigurieren das er das tun0 Interface nutzt. Allerdings weiss ich nicht wo und wie ich das machen soll.
Hättest du da einen Link / Hinweis für mich wie ich vorgehen soll?

Danke

@hermann72pb
Ich möchte niemanden verarschen, ich wollte lediglich über einen bestenden Tunnel Aussenarbeitsplätze an ein Netzwerk anbinden. Man stelle sich vor das Herr X auch zu Hause unter seiner interne Nst. erreichbar ist.

Wenn du da einige technische Probleme siehst wäre ich dir dankbar dies näher zu erläutern. Ich gehe nämlich davon aus das es dem Provider egal ist was ich durch den tunnel schicke.

Viele Grüsse
greenhornXXL

 

[hermann72pb]

Zum Provider-Verarschen meinte ich einige UMTS-Basierte Pakete, wo es ausdrücklich untersagt ist eine SIP-Verbindung damit zu treiben. Wir hatten hier schon einen Kandidaten, der sowas gerade dafür implementieren wollte.
Zu den technischen Bedenken. Erstmal VOIP heißt schon Voice-over-IP und somit werden voice-Fragmente zu den IP-Pakete zusammengefasst und so versendet. Alleine das an sich ist schon krank und würde keinem der Erfinder der IP-Protokolle in seinem schrecklisten Traum erscheinen. Nun gut, heutige Netzwerke sind so schnell und bandbreitig, dass man sich sowas erlauben kann, auch voice (und sogar video) in fast Realzeit über IP zu übertragen.
Jetzt kommt einer mit einem VPN-Tunnel und will schon einmal verpackte Pakete nochmal umpacken, komprimieren, verschlüsseln und wieder über IP verschicken. Das man dafür eine gewisse Rechenleistung und Resourcen braucht ist schon klar. Auch die Abstimmung und volle Funktion auf allen Ebenen der Umwandlung ist vorausgesetzt. Und es gibt eine Menge Umwandlungsstufen. Die Echtzeitfähigkeit bleibt dadurch auf der Strecke. Delayzeiten wachsen ins Unerträgliche. Echos und sonstige Nebeneffekte sind vorprogrammiert, weil die softwarebasierten Echo-Unterdrücker mit solchen enormen und vor allem variablen Verzögerungen nicht klar kommen werden.
Und vor allem nicht zu vergessen und nicht zu unterschätzen, dass alle IP-basierten Übertragungswege zunächst für Stabilität der Daten ausgelegt sind und nicht für die Echtzeitanwendungen. Entstehen bei der Übertragung Probleme, so wird die Übertragung normalerweise wiederholt, was für Konsistenz der Daten voll logisch ist, für Echtzeitanwendungen aber eher kontraproduktiv ist.
Das sind alles meine Bedenken. Ich würde mich echt freuen, wenn jemand hier durch seine praktischen Erfahrungen meine Zweifel abstreiten könnte. Dies wird aber höchstwahrscheinlich nicht passieren. Denn mir sind keine Berichte darüber bekannt, dass jemand eine stabile und qualitätsmäßig akzeptable VOIP-Verbindung mit einer Fritz!Box und einem OpenVPN-Tunnel zum Laufen gebracht hat.

MfG

 

[woprr]

Den SIP-Client würde ich gerne so konfigurieren das er das tun0 Interface nutzt. Allerdings weiss ich nicht wo und wie ich das machen soll.
Hättest du da einen Link / Hinweis für mich wie ich vorgehen soll?

man openvpn. server.conf

# If enabled, this directive will configure
# all clients to redirect their default
# network gateway through the VPN, causing
# all IP traffic such as web browsing and
# and DNS lookups to go through the VPN
# (The OpenVPN server machine may need to NAT
# the TUN/TAP interface to the internet in
# order for this to work properly).
# CAVEAT: May break client's network config if
# client's local DHCP server packets get routed
# through the tunnel. Solution: make sure
# client's local DHCP server is reachable via
# a more specific route than the default route
# of 0.0.0.0/0.0.0.0.
push "redirect-gateway local def1"


Der openvpn-client müsste die route automatisch eintragen wenn der server so konfiguriert.