Wie konfiguriere ich Jitsi Meet für die Nutzung hinter einer Firewall?
- Einleitung und Überblick
- Erforderliche Ports und Protokolle
- TURN/STUN einbinden
- Konfiguration von nginx/Apache und Jitsi-Komponenten
- Firewall-Regeln und NAT
- Tests und Fehlersuche
- Sicherheits- und Performancehinweise
Einleitung und Überblick
Um Jitsi Meet hinter einer Firewall betreiben zu können, muss geprüft werden, welche Ports und Protokolle geöffnet oder weitergeleitet werden müssen. Jitsi verwendet WebRTC für Medienübertragung, einen Webserver für Signalisierung und zusätzliche Komponenten wie Jicofo und Videobridge. Ziel ist, HTTP/HTTPS-Verkehr und UDP/UDP-Fallback für RTP korrekt zu erlauben sowie ggf. TURN-Server einzubinden, damit Clients hinter restriktiven NATs oder Firewalls zuverlässig verbunden werden.
Erforderliche Ports und Protokolle
Der HTTPS-Port 443 (auch HTTP 80 für Weiterleitung) muss von außen zur Jitsi-Instanz geleitet werden, da Signalisierung und Web-UI darüber laufen. WebSocket- oder BOSH-Verbindungen nutzen ebenfalls diesen Port. Für die Medienübertragung bevorzugt Jitsi UDP-Portbereich 10000–20000 (standardmäßig 10000/UDP) für RTP/RTCP über Jitsi Videobridge; dieser Bereich muss geöffnet bzw. per Portweiterleitung zum Videobridge-Host konfiguriert werden. Falls UDP blockiert ist, fällt WebRTC auf TCP über 443 zurück, ist aber deutlich weniger performant. Zusätzlich sollten die Ports für XMPP (5275 intern) und interne Verwaltung nur innerhalb des Servers/Teams bleiben.
TURN/STUN einbinden
Hinter restriktiven Firewalls ist ein TURN-Server oft notwendig, damit Medienstücke über relay statt Peer-to-Peer laufen. Ein Coturn-Server sollte extern auf 3478/UDP/TCP und optional 5349/TCP (TLS) erreichbar sein. In der Jitsi-Konfiguration (sip-communicator.properties / prosody) müssen die TURN-Credentials und URLs eingetragen werden, damit Clients diesen Relay verwenden. STUN allein hilft bei NAT-Erkennung, aber TURN ist erforderlich, wenn direkte UDP-Verbindungen nicht möglich sind.
Konfiguration von nginx/Apache und Jitsi-Komponenten
Der Reverse-Proxy (nginx oder Apache) muss HTTPS terminieren und WebSocket-Pfade (/xmpp-websocket, /http-bind) korrekt weiterleiten. SSL/TLS-Zertifikate sollten gültig sein, sonst brechen Browser WebRTC-Verbindungen ab. In prosody müssen virtuelle Hosts, BOSH und WebSocket-Endpunkte richtig konfiguriert sein. Jicofo und Videobridge sollten auf localhost oder intern erreichbarem Host laufen; die Konfiguration (sip-communicator.properties, jicofo.conf) muss die richtige öffentliche Domain und ggf. die TURN-Server-Informationen enthalten.
Firewall-Regeln und NAT
Auf dem Server-Host muss NAT-Traversal berücksichtigt werden: Falls die VM/Host private IP hat und NAT verwendet wird, ist Portweiterleitung vom Router zu konfigurieren (443 TCP, 10000 UDP etc.). Stateful-Firewalls sollen UDP-Zustände zulassen und timeouts ausreichend lang setzen, da RTP-Flows dauerhaft bestehen. Für maximale Kompatibilität sollte UDP-Forwarding erlaubt sein; andernfalls ist sicherzustellen, dass TCP 443 und TURN erreichbar sind.
Tests und Fehlersuche
Nach Einrichtung sollte man mit zwei Clients in unterschiedlichen Netzwerken testen. Browser-Entwicklertools, jitsi-meet-logger und Videobridge-Logs helfen bei Problemen. Prüfen, ob ICE-Candidates UDP liefern; wenn nur "srflx" und "relay" erscheinen, funktioniert NAT/Firewall-Bypass unterschiedlich. TURN-Relays im SDP bestätigen, dass Client-Verbindungen auch dann aufgebaut werden, wenn UDP blockiert ist.
Sicherheits- und Performancehinweise
Erlauben Sie nur notwendige Ports und schützen Sie administrative Schnittstellen. TURN-Server-Authentifizierung verwenden, um Missbrauch zu vermeiden. Bei vielen Teilnehmern sollte die UDP-Kapazität und CPU der Videobridge dimensioniert sein; SSL-Offloading am Proxy beeinflusst Latenz und CPU-Last.
Wenn Sie konkrete Konfigurationen (nginx-proxy, prosody-TURN-Einträge, iptables-Regeln) wünschen, nennen Sie bitte Ihre Serverumgebung, damit ich ein konkretes Beispiel liefern kann.