philipp711
Goto Top

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?

Content-Key: 594477

Url: https://administrator.de/contentid/594477

Printed on: December 4, 2022 at 13:12 o'clock

Member: Th0mKa
Th0mKa Aug 07, 2020 updated at 15:49:25 (UTC)
Goto Top
Zitat von @Philipp711:
Wegen der NAT-Thematik

Warum macht ihr überhaupt NAT? Normalerweise gehört in die DMZ ein geroutetes IPv4 Netz, dann entfällt das NAT Thema relativ einfach.

/Thomas
Member: beidermachtvongreyscull
beidermachtvongreyscull Aug 08, 2020 at 00:18:05 (UTC)
Goto Top
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).

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
Member: Philipp711
Philipp711 Aug 08, 2020 updated at 08:30:06 (UTC)
Goto Top
Zitat von @beidermachtvongreyscull:

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).

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.
Member: Philipp711
Philipp711 Aug 08, 2020 updated at 08:29:10 (UTC)
Goto Top
Zitat von @Th0mKa:

Zitat von @Philipp711:
Wegen der NAT-Thematik

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
Member: Dani
Dani Aug 09, 2020 at 13:50:17 (UTC)
Goto Top
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.

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. face-wink


Gruß,
Dani
Member: Philipp711
Philipp711 Aug 09, 2020 at 17:14:26 (UTC)
Goto Top
Zitat von @Dani:

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?
Member: Dani
Dani Sep 11, 2020 at 17:25:37 (UTC)
Goto Top
Moin,
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. face-smile


Gruß,
Dani