SIP Software Client per Firmen-VPN anbinden

[Shine1002]

Guten Morgen,

ich würde gerne von meinem heimischen PC per SIP Software mit der TK in der Firma verbinden. Der heimische PC über eine Art VPN-Gateway mit dem Firmen LAN verbunden; die TK ist öffentlich nicht zugänglich.

Hier ein grober Netzwerkplan

               Firma                                                                     HomeOffice

               WAN / Internet                                                            WAN / Internet
                     :                                                                         :
                     :                                                                         :
                 WAN : 80.xxx.yyy.0/25                                                     WAN : DSL
                     :                                                                         :
               +-----------+ 80.xxx.yyy.4                                                +-----------+
               |  pfSense  |                                                             |    DSL    |
               |           +-------------+                                               |   Router  +----------------+
               |           |             |                                               |           |                |
172.16.110.254 +-----+-----+       +-----+-----+                                         +-----------+ 192.168.0.1    | LAN
                     |             |  OpenVPN  |                                                                      | 192.168.0.0/24
        Telefone LAN |             |  Server   |                                                                      |
     172.16.110.0/24 |             |           |                                                            +---------+----------+
                     |             +-----------+                                                            |     LAN-Switch     |
               ...+--+--+...             .     VPN-LAN                                                      |                    |
              (Hardware Telefone)        .  192.168.10.0/24                                                 +---------+----------+
                                         .                                                                            |
                                         .                                                                +-----------+------------------+
                                         .                                                                |                              |
                                         .                                                                |                              |
                                         .                                             VPN-Pool IP        |                              |
                                         .                                             192.168.10.1 +-----+-----+ 192.168.0.3      +-----+-----+ 192.168.0.50
                                         .                                                          |  OpenVPN  |                  | PC        |
                                         ...........................................................|  Client   |                  | Software- |
                                                           VPN-Tunnel                               |  Gateway  |                  | Telefon   |
                                                                                                    +-----------+                  +-----------+

Alle Clients auf der HomeOffice Seite kennen den Weg zum Telefon-LAN in der Firma, d.h. man kann die Telefone und TK zB per ping, http, ssh oder RDP erreichen. Lediglich SIP spielt noch nicht mit.
Der Software-SIP Client schickt in den SIP-Paketen als Absender die HomeOffice-LAN IP vom PC, also in dem Fall die 192.168.0.50. Das SIP-Paket sollte auch an der TK bzw. an den Hardware-Telefonen in der Firma ankommen. Die Geräte in der Firma erzeugen aber dann Antworten mit der Ziel IP 192.168.0.50. Da das HomeOffice LAN 192.168.0.0/24 in der Firma unbekannt ist, verschwinden die Pakete im Nirvana.

Mit welcher Komponente kann ich die SIP Pakete so modifizieren, dass der Rückweg funktioniert? Kann man einen STUN-Server oder ähnliches auf der Firmen-Seite einrichten, die den Software SIP Clients eine IP nennt, mit der die Firmen-Geräte dann etwas anfangen können?
Ich bin für jede Idee zu haben. Recht herzlichen Dank.

Gruß
Shine

 

[sonyKatze]

Der Software-SIP Client schickt in den SIP-Paketen als Absender die HomeOffice-LAN IP vom PC, also in dem Fall die 192.168.0.50.

Nur zum Verständnis: Hat der Computer eine IP aus dem VPN-Pool oder spricht der nur mit dem Gateway auf 0.3 = im Subnetz 0.x?

 

[Shine1002]

Hi sonyKatze,
Der PC hat keine IP aus dem VPN-Pool und spricht nur über das Gateway mit dem Firmen LAN.

 

[PeterPawn]

@Shine1002:
Der Punkt, an dem man hier ansetzen sollte, ist u.a. abhängig davon, wieviele solcher Remote-Clients betroffen sind.

Geht es um einen einzelnen Client, müßte man auf der Client-Seite nach einer (doch recht schwierigen) Lösung suchen.

Geht es um mehrere und man hat tatsächlich die Möglichkeit, auf der Firmen-Seite des Schemas weitere Software zu installieren, dann fiele meine eigene Wahl hier auf einen SIP-Proxy zwischen OpenVPN-Gateway und TK-Anlage, wobei ich davon ausginge, daß die verwendeten SIP-Clients die Verwendung eines "Outbound Proxy" erlauben in ihrer Konfiguration.

Nach dem, was Du schreibst (insbesonders angesichts der Tatsache, daß Protokolle funktionieren, die nicht ihrerseits wieder IP-Adressen im Payload benutzen), kann das OpenVPN-Gateway ja nur als Masquerade-Device arbeiten, wenn ansonsten das verwendete Adress-Segment aus dem Client-LAN (192.168.0.0/24) nicht bekannt ist (was Du ja ebenfalls schreibst) und irgendwelche Pakete trotzdem ankommen.

Da wäre dann das OpenVPN-Gateway die "masquerading firewall" in der Dokumentation des "siproxd" und dieser Proxy wäre am besten auch direkt auf diesem Gerät aufgehoben. SIP-Pakete, die dann bei diesem Proxy ankommen, werden (inhaltlich) analysiert und die dort - im Payload - enthaltenen IP-Adressen (und ggf. Portnummern) werden so angepaßt oder passende "Via"-Header zum Payload hinzugefügt, daß der SIP-Registrar dann auch wieder weiß, an welche IP-Adresse er die Pakete für diesen Client adressieren muß, wenn er antworten will. Die solchermaßen geänderten Pakete gehen dann weiter zum SIP-Registrar.

EDIT: Da habe ich doch den Link zum Projekt glatt vergessen oben: http://siproxd.sourceforge.net/index.php?op=overview

 

[Shine1002]

Hi @PeterPawn,

besten Dank für deine Antwort.
Die Lösung muss für mehrere Clients, also für mehrere HomeOffice-Einrichtungen, funktionieren. Auf der Firmenseite kann jegliche Zusatzsoftware eingerichtet werden.

Das VPN-Gateway im HomeOffice ist bei mir ein Raspberry PI und der maskiert alles was das VPN-Interface verläßt.
=> iptables -t nat -I POSTROUTING -s 192.168.0.0/24 -o tun0 -j MASQUERADE

Als SIP Software würde ich PhonerLite ausprobieren. Hier die Einstellmöglichkeiten

[Edit Novize: Bild gemäß der Forumsregeln zur Vorschau verkleinert]
Posting 2:

@PeterPawn,

der Siproxd daemon kann doch bestimmt auch auf dem OpenVPN-Server bzw. dem pfSense-Router (ist ein Rechner) installiert werden, oder?

 

[PeterPawn]

der maskiert alles was das VPN-Interface verläßt.

Danach müßte ja das VPN-Interface des RasPi von der TK aus erreichbar sein und dann wäre u.U. (kommt halt darauf an, wie man es macht und ich hatte die Frage ja so verstanden, daß Du nach Ideen suchst, die Du dann selbst weiter verfolgst) sogar zu erwägen, den Proxy auf dem RasPi zu betreiben (und dann eben doch wieder bei jedem SIP-Client an der "border").

Das muß halt irgendeine Instanz sein, die von beiden Seiten "erreichbar" ist. Die TK scheitert nach #1 ja daran, daß die nicht weiß, wo 192.168.0.0/24 liegt und die SIP-Pakete halt eine Adresse von dort im Payload - und nicht nur in ihrem eigenen IP-Header, denn um den kümmert sich das NAT ja bereits - haben.

Wenn die weiß, wo 192.168.10.1 liegt und das die Adresse ist, an die sie SIP-Pakete (und später RTP) sendet, dann sollten die ja auch ankommen - ggf. wieder mit der Frage der "Lebensdauer" von "outgoing UDP connections" in der Firewall im RasPi verbunden, denn die müßte der Client ja dann dauerhaft offenhalten, damit ihn Pakete von der TK auch erreichen können, wenn sie SIP-Signalisierungen sind und nicht nur unmittelbare (und zeitnahe) Reaktionen auf SIP-Messages von PhonerLite.

Wenn "siproxd" hier als "Stellvertreter" für beide Seiten, die nicht direkt miteinander kommunizieren können, die Weiterleitung an den jeweils anderen Endpunkt übernehmen soll, müssen eben beide Seiten mit dem Host "reden" können, auf dem das ALG arbeitet.

Je nachdem, wo da noch weitere "Übersetzungen" von Netzwerkadressen erfolgen, muß man halt den passenden Installationsort aussuchen - am besten geeignet ist schon derselbe Host, der auch das NAT macht.

Wichtig ist dabei vielleicht noch, daß ein von "siproxd" hinzugefügter "Via"-Header i.d.R. die Adresse des Interfaces, was zum jeweiligen Empfänger zeigt, enthält ... sonst macht es ja wenig Sinn, wenn der dann an diese Adresse antworten würde. Das heißt dann natürlich eben auch, daß der Proxy auf einem Gerät zu installieren ist, welches der Empfänger für den "Rückweg" unter ebendieser Adresse auch erreichen kann.

Wenn das OpenVPN-Gateway hier kein NAT macht (das wäre für mich das Naheliegendste gewesen), kann es aber vermutlich immer noch als SIP-ALG benutzt werden ... das hängt halt auch davon ab, wie das Konstrukt aus pfSense, OpenVPN-Gateway und TK-Anlage im Netz der pfSense ansonsten so konfiguriert ist.

Das Hauptproblem beim SIP ist es dann halt, daß weitere Signalisierungen erst mit ziemlichem zeitlichen Abstand auftauchen können und die müssen dann auch noch ihren Weg durch alle möglichen Firewalls mit NAT finden können - ansonsten gibt es den bekannten Effekt, daß für kurze Zeit alles zu funktionieren scheint, aber später keine Anrufe mehr möglich sind (i.d.R. dann eingehend).

Oder man richtet tatsächlich statische Freigaben ein, dann muß man die Ports für die Via-Header wieder passend im Proxy festlegen, wenn die nicht aus der "Transportverpackung" des eingehende SIP-Payloads entnommen werden sollen.

Es gibt eben viele Möglichkeiten (die zwei wichtigsten Probleme sind eben das Umschreiben von SIP-Payloads und das Offenhalten von Verbindungen durch Firewalls) und die konkrete Konfiguration (und auch die Entscheidung für die Lösung, die man nutzen will) kann man nur "vor Ort" umsetzen (bzw. fällen). Wie gesagt ... ich hatte das so verstanden, daß Du Ideen sammeln wolltest und da ist das auch tatsächlich nur ein Weg, aber eben derjenige, den ich selbst hier nehmen würde, weil er die wenigstens Komplikationen verspricht (was auch nicht heißt, daß das gänzlich ohne abgehen muß mit dem "siproxd").

 

[sonyKatze]

Kann man einen STUN-Server oder ähnliches auf der Firmen-Seite einrichten, die den Software SIP Clients eine IP nennt, mit der die Firmen-Geräte dann etwas anfangen können?

Du könntest einen STUN-Server ins selbe Netz wie die Telefonanlage packen. Falls Du diesen Server von daheim erreichst, gibt er Dir (bzw. Deinem VoIP/SIP-Client PhoneLite) die IP-Adresse, die die Telefonanlage braucht. Das müsste für die SIP-Pakete, also die Signalisierung reichen. Aber ob dann die ganzen NATs bzw. Firewalls auf dem Weg dazwischen die RTP-Pakete (Sprache) richtig durchreichen … puh. Peter empfiehlt Dir (vereinfacht geschrieben) einen SIP-Proxy dazwischen zu schalten, der nicht anhand der IP-Adresse ermittelt aus SIP/SDP routet, sondern der anhand der Quell-IP routet – also woher das SIP-Paket tatsächlich kam. Mein Ansatz wäre, die Telefonanlage rauszuwerfen und durch eine Anlage zu ersetzen, die bereits anhand der Quell-IP routet. Wenn Du diese Telefonanlage ins Internet stellst, können sich die Heim-Arbeiter statt über VPN über „SIP-over-TLS mit SDES-sRTP“ bei der Telefonanlage einbuchen.

 

[Shine1002]

Hi @sonyKatze,

ja, ich sehe schon, die VPN-Sache mit den vielen Netzen ist etwas hakelig; werde mich aber mal in den Siproxd daemon einlesen. Als TK könnte ich eine Swyx oder eine FreePBX anbieten, die aber aktuell (noch) nicht öffentlich erreichbar sind. Weißt du zufällig ob die TKs für das Routen anhand der Quell-IP geeignet sind bzw. welche TK kannst du empfehlen?

 

[sonyKatze]

FreePBX basiert auf Asterisk. In Asterisk stellst Du das über die Konfigurationsdatei sip.conf und den Parameter nat=comedia,force_rport ein. Allerdings empfehle ich FreeSWITCH, weil dessen Kern rein SIP ist. Asterisk ist genial, wenn noch andere Technologien genutzt werden (ISDN, H.323, …) – aber dessen Kern ist – was SIP angeht – beschnitten, weil der Kern der kleinste gemeinsame Nenner von allen unterstützen Technologien ist.

 

[Shine1002]

Hallo,
wie sieht die optimalste Server-Umgebung aus, damit Server und Client von überall erreichbar sind, man überall hin telefonieren kann (HomeOffice<->Firma, HomeOffice<->Extern, HomeOffice<->HomeOffice und umgekehrt) und clientseitíg möglichst wenig einrichten und einstellen muss? Die Clients sitzen i.d.R. hinter einem NAT-Router (vorwiegend eine FritzBox)
Den neuen FreeSWITCH Server könnte ich in der Firma mit einer privaten LAN-IP und mit einer statischen öffentlichen IP einrichten .. oder ich könnten den neuen Server auch auf einem öffentlichen Root-Server einrichten?

 

[sonyKatze]

Ideal ist, wenn der Server nicht hinter einem NAT sitzt. Aber auch hinter einem NAT kannst Du per Exposed-Host solch gute Ergebnisse erzielen. Viel wichtiger: Achte darauf, dass der Server nicht nur mittels IPv4 sondern auch per IPv6 erreichbar ist. Dann gehen die Clients auch an DS-Lite-Anschlüssen bzw. auch dann wenn der DHCPv4-Server die Grätsche gemacht hat. Sollen die Clients auch dauerhaft erreichbar sein, achte auf eine Keep-Alive-Strategie; ich fahre mit einer niedrigen SIP-REGISTER-Expiry von 600 Sekunden ganz gut.

 

[Shine1002]

Hi @sonyKatze,

alles klar .. danke für Infos.

Gruß
Shine