svenkessler Posted February 16, 2018 #1 Share Posted February 16, 2018 Hallo, mein Netzwerkteam besteht darauf, dass wir den RemoteConnector separat in unsere DMZ packen. Mir ist so weit klar, dass ich die Ports 443, 16203 und 57203 vom Internet auf den Remoteconnector lassen muss und Port 9101 vom Internet direkt zur Swyx lassen muss. Aber mir ist nicht wirklich klar, welche Ports zwischen dem RemoteConnector in der DMZ und dem Swyx Server außerhalb der DMZ freigegeben sein müssen. Trotz KB4635 und dem Administratorhandbuch stehe ich irgendwie auf dem Schlauch. Ich hoffe, jemand hat dieses Setup eventuell erfolgreich laufen und kann mir hier weiter helfen. Ziel soll es sein, die iPhone App und den Windows Client ohne VPN nutzen zu können. Danke und Gruß Sven Link to comment Share on other sites More sharing options...
Andreas R Posted February 28, 2018 #2 Share Posted February 28, 2018 Hallo Sven, es ist nicht sinnvoll den RemoteConnector in die DMZ auszulagern, da dieser nicht nur die Tunnel-Aussenseite ins Internet bildet, sondern auf die Tunnel-Innenseite ins LAN. D.h. es muss von dort eine direkte Kommunikation mit ALLEN SwyxWare Serverkomponenten stattfinden können (CDS, REST-API, SIP, RTP usw.) UND (!!!) auch RTP mit ALLEN Endgeräten (!), Gateways, DECT-Basen etc. im internen Netz. Außerdem muss als Dienstekonto ein Domänenkonto verwendet werden, spricht der Server in der DMZ müsste Mitglied in der Domäne sein und auch noch mit dieser kommunizieren dürfen. In Summe also eine riesige Menge an offenen Ports in Richtung internes Netz. Das widerspricht dem Sinn und Zweck einer DMZ. Alternative: Einen Reverse-Proxy in die DMZ stellen und diesen dann auf dem externen Interface die Ports 9101 (oder selbst ausgedachten) und mind. einen der RemoteConnector Ports (443, 16203, 57203 oder einen selbst ausgedachten) auf die passenden internen Ports auf den SwyxWare Server (inkl. RemoteConnector) laufen lassen. Gruß Andreas Link to comment Share on other sites More sharing options...
svenkessler Posted February 28, 2018 Author #3 Share Posted February 28, 2018 Hallo Andeas, danke für deine Erklärung! Das klingt ja gänzlich unerfreulich. Speziell die Tatsache, dass der RemoteConnector selbst eine Verbindung zu allen Endgeräten benötigt. Damit ist es ja in der Tat absolut unsinnig, das ganze in die DMZ zu packen. Leider sind wir auf Grund unserer Struktur nicht in der Lage, komplett frei zu entscheiden wie wir die Systeme nach außen hin anbinden. Unser zuständiges Security Team besteht darauf, interne Systeme nicht direkt über das Internet zur Verfügung zu stellen. Wie sinnvoll, bzw. unsinnig dies in einigen Situationen ist spielt leider keine Rolle. Allerdings sehe ich dann auch die Möglichkeit, den RemoteConnector getrennt installieren zu können als absolut nutzlos an. Oder übersehe ich hier eine mögliche Nutzung? Zudem fehlt mir diese entscheidende Information auch in der Dokumentation. Für mich sieht es in der Doku klar danach aus, als sei die Verbindung von außen komplett über den RemoteConnector möglich, welcher selbst „lediglich“ mit dem Swyx Server kommuniziert. Mal abgesehen von der Erst-Authentifizierung direkt an dem Swxy System. Oder habe ich den entscheidenen Part in der Doku überlesen? Zumal auch dieser Webcast von Swyx nirgendwo darauf hinweist: Gruß Sven Link to comment Share on other sites More sharing options...
Most Valued User srom Posted March 1, 2018 Most Valued User #4 Share Posted March 1, 2018 Juhu ich freu mich, ich habe derzeit auch das selbe Thema und bin mal gespannt wie das nachher läuft Link to comment Share on other sites More sharing options...
Most Valued User Virikas Posted March 1, 2018 Most Valued User #5 Share Posted March 1, 2018 22 hours ago, svenkessler said: Für mich sieht es in der Doku klar danach aus, als sei die Verbindung von außen komplett über den RemoteConnector möglich, welcher selbst „lediglich“ mit dem Swyx Server kommuniziert. Genau das ist aber das Hauptproblem in dem Setup, weil der RemoteConnector eben nicht einfach nur einen Port zu den Swyxserverdiensten braucht. Dadurch wird wie oben schon erwähnt der Sinn der DMZ ziemlich aufgeweicht. Sofern man dem -nicht mehr aktuellen und davon ab selbst für Swyx 2015 schon unvollständigen- KB4635 glauben darf, braucht es vom RemoteConnector aus: CDS: TCP 9094,9095 --> ConfigDatastore SIP: TCP/UDP 10000-15000 -> SwyxServer RTP: UDP 15000-((15000-#ConcurrentCalls)*2) Tunnel: TCP/TLS 16203,57203 --> SwyxServer (Empfehlung gerade für HotSpot Netze in denen gern mal nur http/https Ports erlaubt sind ist definitiv 443 auch aufzumachen) zum Thema ob Mediastreaming wirklich zwischen MobileClient via TLS Tunnel und "LAN Client" fließt oder der SwyxServer dort noch als "Medienpumpe" zwischen steht konnte ich nichts finden. Besonders interessant wird das dann natürlich nochmal mit abgesetzten Gateways. Braucht der RemoteConnector dann noch eine Verbindung zum LinkMgr oder zum Gateway? Die SwyxDoku beschränkt sich hier nahezu komplett auf die Verbindung Client -> RemoteConnector, aber nicht auf die interne Kommunikation. Das gilt aber nicht nur für den RemoteConnector, sondern auch insgesamt für die Interprozesskommunikation zwischen einzelnen Swyxdiensten. Auch bei abgesetztem PhoneMgr, LinkMgr, ConferenceMgr, etc. die man ja prinzipiell alle auf dedizierten Maschinen laufen lassen könnte, kriegt man das nur durch Analysen nach dem Aufbau heraus. Link to comment Share on other sites More sharing options...
Andreas R Posted March 1, 2018 #6 Share Posted March 1, 2018 On 28.2.2018 at 5:05 PM, svenkessler said: Das klingt ja gänzlich unerfreulich. Speziell die Tatsache, dass der RemoteConnector selbst eine Verbindung zu allen Endgeräten benötigt. Damit ist es ja in der Tat absolut unsinnig, das ganze in die DMZ zu packen. Hallo Sven, ja ist unsinnig in so fern, dass es eigentlich keinen wirklichen Vorteil bringt und die Konfiguration deutlich aufwändiger wird. Ich würde es übrigens anders formulieren: Es ist nicht der RemoteConnector selbst der eine Verbindung zu allen Endgeräten benötigt, sondern die dahinterliegenden Clients (SwyxIt!, Swyx Mobile, Swyx Desktop for MacOS). In der Swyx-Architektur kommunizieren nun mal alle internen Endgeräte/Clients immer a) mit dem Server UND tauschen RTP direkt untereinander aus. Der RemoteConnector stellt nur einen propritären TLS-Tunnel zwischen Client-Komponente und internem Netz zur Verfügung (damit eben kein VPN notwendig ist). Durch den stehenden Tunnel kommunizieren die Clients dann aber in Richtung internes Netz natürlich weiterhin ganz normal! Deswegen ist der RemoteConnector aus Sicht aller anderen Komponenten quasi der Medienendpunkt (eigentlich der dahinter liegende Client der den Tunnel aufgebaut hat, aber der RC nimmt dessen Traffic auf der Innenseite stellvertretend in Empfang). Das wäre das gleiche wie wenn Du ein VPN aufbaust, dann hättest Du vom VPN-Endpunkt aus genau den gleichen Traffic in alle Richtungen. Der RemoteConnector entspricht quasi dem VPN-Server. Quote Leider sind wir auf Grund unserer Struktur nicht in der Lage, komplett frei zu entscheiden wie wir die Systeme nach außen hin anbinden. Unser zuständiges Security Team besteht darauf, interne Systeme nicht direkt über das Internet zur Verfügung zu stellen. Wie sinnvoll, bzw. unsinnig dies in einigen Situationen ist spielt leider keine Rolle. Da es sich hier um einen mit X.509 User-Zertifikaten hergestellten TLS Tunnel handelt, würde ich das eigentlich nicht so kritisch sehen. Wenn das aber aufgrund irgendwelcher Policies total egal ist sehe ich nur zwei Möglichkeiten: 1. Kein RemoteConnector nutzen sondern selbst VPN aufbauen. RemoteConnector ist ja kein Muss, sondern nur ein Komfortangebot für diejenigen die sich ein VPN sparen wollen. 2. Wenn VPN nicht in Frage kommt dann doch RemoteConnector benutzen, aber wie schon im ersten Post erwähnt einen Reverse-Proxy in der DMZ betreiben (und den eigentlichen RemoteConnector dann ruhig auf dem SwyxSever selbst oder drittem Server im LAN laufen lassen). Das sollte dann doch eigentlich eine saubere Lösung sein, oder? Quote Allerdings sehe ich dann auch die Möglichkeit, den RemoteConnector getrennt installieren zu können als absolut nutzlos an. Oder übersehe ich hier eine mögliche Nutzung? Die Möglichkeit hat verschiedene Hintergründe, u.a. geht es hier auch um Lastverteilungs- und Redundanz-Aspekte für sehr große Installationen. Ganz klar aber NICHT für ein DMZ-Szenario (was von Swyx auch nirgendwo empfohlen wird). Quote Zudem fehlt mir diese entscheidende Information auch in der Dokumentation. Für mich sieht es in der Doku klar danach aus, als sei die Verbindung von außen komplett über den RemoteConnector möglich, welcher selbst „lediglich“ mit dem Swyx Server kommuniziert. Mal abgesehen von der Erst-Authentifizierung direkt an dem Swxy System. Oder habe ich den entscheidenen Part in der Doku überlesen? Zumal auch dieser Webcast von Swyx nirgendwo darauf hinweist: Das mag sein dass das nicht ausführlich erklärt wird, vermutlich weil es schlicht und einfach kein angedachter Use-Case ist. Es wird auch nirgendwo empfohlen den RC in eine DMZ zu stellen. Es ist IMHO ein Verständnis-Problem was die Funktionalität des RemoteConnectors angeht. Siehe mein Erklärungsversuch oben, es ist lediglich eine Komponente die einen Tunnel zwischen externem Client und internem Netz aufbaut. Der RemoteConnector ist vor allem für Kleinstkunden eingeführt worden, die bisher keine VPN-Infrastuktur haben und auch ansonsten nicht wollen/brauchen. D.h. also Kosten und Komplexität reduzieren. Wie immer und überall stehen maximale Sicherheit und geringste Kosten/Komplexität in einem gewissen Widerspruch zueinander :-) Meiner Ansicht nach stellt die Lösung für normale Sicherheitsansprüche eine sehr gute, günstige und einfache Lösung dar. Wer extreme Sicherheitsansprüche hat, benötigt aber eine andere Lösung (z.B. VPN oder andere Tunnel-Lösungen, Reverse-Proxy). Ich hoffe hiermit ein paar Dinge klarer gemacht zu haben. Gruß Andreas Link to comment Share on other sites More sharing options...
Andreas R Posted March 1, 2018 #7 Share Posted March 1, 2018 19 hours ago, Virikas said: Genau das ist aber das Hauptproblem in dem Setup, weil der RemoteConnector eben nicht einfach nur einen Port zu den Swyxserverdiensten braucht. Richtig. Der RemoteConnector selbst braucht natürlich eine Verbindung zum SwyxServer, aber entscheidend ist eigentlich wohin überall RTP aufgebaut werden muss. Quote Sofern man dem -nicht mehr aktuellen und davon ab selbst für Swyx 2015 schon unvollständigen- KB4635 glauben darf, braucht es vom RemoteConnector aus: CDS: TCP 9094,9095 --> ConfigDatastore SIP: TCP/UDP 10000-15000 -> SwyxServer RTP: UDP 15000-((15000-#ConcurrentCalls)*2) Das sind IMHO nur die Dinge welche der RemoteConnector selbst verwendet. Wenn es darum geht was die Firewall vom RemoteConnector in Richtung SwyxServer und LAN erlauben muss, also welche Ziel- Ports und Protokolle benötigt werden, das hängt ausschließlich davon ab, welche Clients sich hinter dem RemoteConnector befinden und mit welchen Gegenstellen diese kommunizieren. Das kann je nach Client also ggf. unterschiedlich sein. Was in der Liste hier z.B. fehlt, ist der für alle "NG Clients" (aktuell Swyx Mobile und Swyx Desktop for MacOS) wichtige Port der REST-API auf dem SwyxServer 9100. Quote Tunnel: TCP/TLS 16203,57203 --> SwyxServer (Empfehlung gerade für HotSpot Netze in denen gern mal nur http/https Ports erlaubt sind ist definitiv 443 auch aufzumachen) Das würde ich in jedem Fall auch empfehlen. Im Idealfall hat man noch zwei freie öffentliche IPs die den 443 noch nicht nutzen, dann legt man z.B.auf IP1:443 den Auth-Dienst und auf IP2:443 den RemoteConnector. Somit braucht man dann diese Portforwardings: Externe-IP1:443 -> interne-IP:9101 Externe-IP2:443 -> interne-IP:16203 (oder 57203 - ist egal) Die externe Sicht dann schön sauber in den Servereigenchaften, RemoteConnector eintragen (wichtig!). Im Swyx Mobile oder Desktop for Mac trägt man dann wie üblich den internen Server ein plus unter externer Server die IP1 (Auth-Dienst). Die IP2 (RemoteConnector) wird nirgendwo im Client eingetragen, er "lernt" diese nach der Verbindung mit dem Auth-Dienst (sofern korrekt in den Server-Eigenschaften, RemoteConnector hinterlegt) Dann sollte man sich aus den fast allen Fremdnetzen verbinden können. Quote zum Thema ob Mediastreaming wirklich zwischen MobileClient via TLS Tunnel und "LAN Client" fließt oder der SwyxServer dort noch als "Medienpumpe" zwischen steht konnte ich nichts finden. So ist es, der RemoteConnector Dienst ist der interne Medienendpunkt, eine weitere Medienpumpe gibt es in dem Szenario bisher nicht. Wobei man das natürlich in der Firewall zumindest soweit einschränken kann, dass ich zwar RTP nach potentiell überall brauche, aber die Quell-IP kann man auf den RemoteConnector-Dienst eingrenzen. Quote Besonders interessant wird das dann natürlich nochmal mit abgesetzten Gateways. Braucht der RemoteConnector dann noch eine Verbindung zum LinkMgr oder zum Gateway? Klar, bei Bedarf würde er für externe Rufe das RTP auch dorthin schicken. Gruß Andreas Link to comment Share on other sites More sharing options...
svenkessler Posted March 5, 2018 Author #8 Share Posted March 5, 2018 Hallo Andreas, vielen Dank für die sehr ausführliche Erläuterung! Ich werde mit diesen Infos mal an unser Sicherheitsteam ran treten und hoffen, dass ich Gehör finde Gruß Sven Link to comment Share on other sites More sharing options...
Most Valued User seppelswyx Posted April 18, 2018 Most Valued User #9 Share Posted April 18, 2018 Kurze Frage: Läuft die signalisierung auch über die Push-Funktion? Bei uns verliert der Mobile client auch die Verbindung zum Server. In der App steht dann "Offline". Aber sie verbindet sich gleich wieder, wenn man aktiv wird. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.