7
Bereitstellung Videokonferenzlösung
Hallo Leute,
wir planen die Bereitstellung einer eigenen Videokonferenz-Lösung über unsere Infrastruktur . Die Voraussetzungen sind vorhanden - dedizierte HW (8 Core Xeon, 64GB Ram etc.) + DeutschlandLAN Connect IP (ehem. Company Connect).
Grundsätzlich bin ich der Meinung, dass alles was aus dem Internet erreichbar ist, hinter eine Firewall/Reverse-Proxy in eine gesonderte DMZ gehört (Dafür verwenden wir einen Sophos UTM-Cluster inkl. r-Proxy mit einem eigenen Interface zu einer DMZ).
Wegen der NAT-Thematik, Performance, große Range an Portweiterleitungen etc. frage ich mich aber bei diesem Projekt, ob man nicht ein Interface direkt an das Internet hängen sollte (durch den DCIP haben wir ja genug öffentliche IPs) und ein internes Interface in die DMZ leitet. Über das DMZ-Interface würde dann die Administration aus dem internen Netz erfolgen, das Monitoring und der Zugriff aufs interne LDAP...das externe Interface ist dann tatsächlich rein für den Zugriff auf die Videokonferenzlösung gedacht und beeinträchtig die Sophos etc. erstmal nicht.
Ich bin unschlüssig welcher Weg (also alles hinter die FW und mit Portweiterleitungen weitergereicht oder Server mit zwei Interfaces) der Beste bzw. der sicherste ist.
Was meint Ihr?
wir planen die Bereitstellung einer eigenen Videokonferenz-Lösung über unsere Infrastruktur . Die Voraussetzungen sind vorhanden - dedizierte HW (8 Core Xeon, 64GB Ram etc.) + DeutschlandLAN Connect IP (ehem. Company Connect).
Grundsätzlich bin ich der Meinung, dass alles was aus dem Internet erreichbar ist, hinter eine Firewall/Reverse-Proxy in eine gesonderte DMZ gehört (Dafür verwenden wir einen Sophos UTM-Cluster inkl. r-Proxy mit einem eigenen Interface zu einer DMZ).
Wegen der NAT-Thematik, Performance, große Range an Portweiterleitungen etc. frage ich mich aber bei diesem Projekt, ob man nicht ein Interface direkt an das Internet hängen sollte (durch den DCIP haben wir ja genug öffentliche IPs) und ein internes Interface in die DMZ leitet. Über das DMZ-Interface würde dann die Administration aus dem internen Netz erfolgen, das Monitoring und der Zugriff aufs interne LDAP...das externe Interface ist dann tatsächlich rein für den Zugriff auf die Videokonferenzlösung gedacht und beeinträchtig die Sophos etc. erstmal nicht.
Ich bin unschlüssig welcher Weg (also alles hinter die FW und mit Portweiterleitungen weitergereicht oder Server mit zwei Interfaces) der Beste bzw. der sicherste ist.
Was meint Ihr?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 594477
Url: https://administrator.de/forum/bereitstellung-videokonferenzloesung-594477.html
Ausgedruckt am: 22.12.2024 um 07:12 Uhr
7 Kommentare
Neuester Kommentar
Warum macht ihr überhaupt NAT? Normalerweise gehört in die DMZ ein geroutetes IPv4 Netz, dann entfällt das NAT Thema relativ einfach.
/Thomas
Mahlzeit zu früher Stunde,
Hab ich auch gemacht, allerdings haben wir eine Lösung eingekauft. Ich hab mich durch verschiedene selfhosting-Lösungen durchprobiert, allen voran Jitsi-Meet und komme immer wieder zum Schluss, dass die Power nie ganz ausreichen kann.
Wir haben eine Kauflösung namens TurboMeeting. Eine erstaunlich kleine Appliance mit proprietärem OS und Client für so ziemlich jedes mögliche Endgerät. Und das Ding war nicht mal teuer.
Aus Erfahrung sage ich Dir: Eine solche Lösung nicht multi-homed. Immer dedizierte Wege.
Da ich nicht weiß, was Du einsetzen willst, kann ich Dir keine Tipps wegen Firewalling geben.
Ich rate mal zu einem Blick auf Turbomeeting.
bdmvg
Zitat von @Philipp711:
wir planen die Bereitstellung einer eigenen Videokonferenz-Lösung über unsere Infrastruktur . Die Voraussetzungen sind vorhanden - dedizierte HW (8 Core Xeon, 64GB Ram etc.) + DeutschlandLAN Connect IP (ehem. Company Connect).
wir planen die Bereitstellung einer eigenen Videokonferenz-Lösung über unsere Infrastruktur . Die Voraussetzungen sind vorhanden - dedizierte HW (8 Core Xeon, 64GB Ram etc.) + DeutschlandLAN Connect IP (ehem. Company Connect).
Hab ich auch gemacht, allerdings haben wir eine Lösung eingekauft. Ich hab mich durch verschiedene selfhosting-Lösungen durchprobiert, allen voran Jitsi-Meet und komme immer wieder zum Schluss, dass die Power nie ganz ausreichen kann.
Wir haben eine Kauflösung namens TurboMeeting. Eine erstaunlich kleine Appliance mit proprietärem OS und Client für so ziemlich jedes mögliche Endgerät. Und das Ding war nicht mal teuer.
Aus Erfahrung sage ich Dir: Eine solche Lösung nicht multi-homed. Immer dedizierte Wege.
Da ich nicht weiß, was Du einsetzen willst, kann ich Dir keine Tipps wegen Firewalling geben.
Ich rate mal zu einem Blick auf Turbomeeting.
bdmvg
Zitat von @beidermachtvongreyscull:
Mahlzeit zu früher Stunde,
Hab ich auch gemacht, allerdings haben wir eine Lösung eingekauft. Ich hab mich durch verschiedene selfhosting-Lösungen durchprobiert, allen voran Jitsi-Meet und komme immer wieder zum Schluss, dass die Power nie ganz ausreichen kann.
Wir haben eine Kauflösung namens TurboMeeting. Eine erstaunlich kleine Appliance mit proprietärem OS und Client für so ziemlich jedes mögliche Endgerät. Und das Ding war nicht mal teuer.
Aus Erfahrung sage ich Dir: Eine solche Lösung nicht multi-homed. Immer dedizierte Wege.
Da ich nicht weiß, was Du einsetzen willst, kann ich Dir keine Tipps wegen Firewalling geben.
Ich rate mal zu einem Blick auf Turbomeeting.
bdmvg
Mahlzeit zu früher Stunde,
Zitat von @Philipp711:
wir planen die Bereitstellung einer eigenen Videokonferenz-Lösung über unsere Infrastruktur . Die Voraussetzungen sind vorhanden - dedizierte HW (8 Core Xeon, 64GB Ram etc.) + DeutschlandLAN Connect IP (ehem. Company Connect).
wir planen die Bereitstellung einer eigenen Videokonferenz-Lösung über unsere Infrastruktur . Die Voraussetzungen sind vorhanden - dedizierte HW (8 Core Xeon, 64GB Ram etc.) + DeutschlandLAN Connect IP (ehem. Company Connect).
Hab ich auch gemacht, allerdings haben wir eine Lösung eingekauft. Ich hab mich durch verschiedene selfhosting-Lösungen durchprobiert, allen voran Jitsi-Meet und komme immer wieder zum Schluss, dass die Power nie ganz ausreichen kann.
Wir haben eine Kauflösung namens TurboMeeting. Eine erstaunlich kleine Appliance mit proprietärem OS und Client für so ziemlich jedes mögliche Endgerät. Und das Ding war nicht mal teuer.
Aus Erfahrung sage ich Dir: Eine solche Lösung nicht multi-homed. Immer dedizierte Wege.
Da ich nicht weiß, was Du einsetzen willst, kann ich Dir keine Tipps wegen Firewalling geben.
Ich rate mal zu einem Blick auf Turbomeeting.
bdmvg
Danke!
Es läuft auf Jitsi-Meet oder Bigbluebutton heraus - Tendenz zu Bigbluebutton inkl. Greenlight.
Multihomeing ist generell irgendwie doof, da hast du recht (ist mir aber erst eingefallen als dieser Beitrag schon geschrieben war). Außerdem gefällt mir die Tatsache nicht, dass der Server mit einem Bein direkt im inet steht und das andere Bein in die interne Infrastruktur geht und somit die Firewall umgangen wird.
Auf der anderen Seite soll es ja auch reibungslos funktionieren und da nervt das NAT usw.
Zitat von @Th0mKa:
Warum macht ihr überhaupt NAT? Normalerweise gehört in die DMZ ein geroutetes IPv4 Netz, dann entfällt das NAT Thema relativ einfach.
/Thomas
Warum macht ihr überhaupt NAT? Normalerweise gehört in die DMZ ein geroutetes IPv4 Netz, dann entfällt das NAT Thema relativ einfach.
/Thomas
Naja, das gibt der Anschluss ja nicht her.
Wir haben zwar ein v4-Netz mit 8 Adressen zugewiesen bekommen, aber davon können wir nur 5 nutzen (bisschen wenig) und das Netz liegt direkt hinter dem Remote-Device an. Auf das Remote-Device habe ich keinen Zugriff, sodass ich gar keine wirkliche DMZ bauen kann.
Inet<-->RemoteDevice<--v4-Netz-->Sophos mit NAT<--DMZ
Moin,
Gruß,
Dani
Wegen der NAT-Thematik, Performance, große Range an Portweiterleitungen etc. frage ich mich aber bei diesem Projekt, ob man nicht ein Interface direkt an das Internet hängen sollte (durch den DCIP haben wir ja genug öffentliche IPs) und ein internes Interface in die DMZ leitet.
Dafür gibt es STUN/TURN Server, somit beschränkt die Anzahl der Ports auf 80, 443 und evtl. 3478. Wobei letzteres durch zwei öffentliche IP-Adressen auch auf 443 gelegt werden kann.Wir haben zwar ein v4-Netz mit 8 Adressen zugewiesen bekommen, aber davon können wir nur 5 nutzen (bisschen wenig) und das Netz liegt direkt hinter dem Remote-Device an.
Man kann problemlos bei der Administration in Kiel ein größeres/weiteres Subnetz anfordern. Gruß,
Dani
Zitat von @Dani:
Moin,
Moin,
Wegen der NAT-Thematik, Performance, große Range an Portweiterleitungen etc. frage ich mich aber bei diesem Projekt, ob man nicht ein Interface direkt an das Internet hängen sollte (durch den DCIP haben wir ja genug öffentliche IPs) und ein internes Interface in die DMZ leitet.
Dafür gibt es STUN/TURN Server, somit beschränkt die Anzahl der Ports auf 80, 443 und evtl. 3478. Wobei letzteres durch zwei öffentliche IP-Adressen auch auf 443 gelegt werden kann.STUN/TURN brauchen wir sowieso. Aber das hat ja nur indirekt bzw.nichts mit der Entscheidung ob Dualhomed oder hinter NAT-FW zu tun, oder sehe ich das falsch?
Moin,
Gruß,
Dani
Aber das hat ja nur indirekt bzw.nichts mit der Entscheidung ob Dualhomed oder hinter NAT-FW zu tun, oder sehe ich das falsch
die Implementierung von STUN/TURN hiner NAT/PAT ist nicht immer ganz einfach. Dualhomed (zwei Netzwerkkarten, 1x LAN, 1x DMZ) hebelt eigentlich die Firewall zwischen DMZ und LAN aus. Gruß,
Dani
