Hosten eines eigenen Jitsi Videokonferenz-Servers

Ich habe mich entschlossen, meinen eigenen Jitsi Videokonferenz-Server zu hosten.

Ich habe mit diesem Projekt begonnen, nachdem ich nach privatsphäreorientierten Videokonferenzlösungen gesucht habe. Als mich jemand auf Jitsi aufmerksam machte, habe ich angefangen mich über die Software zu informieren. Jitsi ist freie, quelloffene Software, die ziemlich genau das leistet, was ich suche. Weil ich neugierig war wollte ich es selbst ausprobieren.

Jitsi Landing Page German

Die Software

Jitsi ist eine freie und quelloffene Software, die WebRTC für die Verbindungen benutzt. Der Code ist hier auf GitHub verfügbar. Jitsi besteht im Wesentlichen aus zwei Hauptkomponenten, einer SFU (selective forwarding unit), der Jitsi Videobridge (JVB) und der Jitsi Meet Applikation.

Wenn es nur zwei Teilnehmende gibt, wird die Verbindung mit einer P2P WebRTC-Session hergestellt, was heißt, dass der Server nicht mehr zu tun hat als die zwei Teilnehmenden zu verbinden. In diesem Fall kommunizieren die zwei Endpunkte direkt und Ende-zu-Ende-verschlüsselt via DTLS-SRTP.

WebRTC ist (derzeit) nicht in der Lage, Ende-zu-Ende-verschlüsselte Verbindungen bei mehr als zwei Teilnehmenden zu bieten. In diesem Fall sind alle Verbindungen zum Server weiterhin über DTLS-SRTP verschlüsselt. Die JVB entschlüsselt den Stream nur während dieser dort durchgeleitet wird, jedoch werden keine Daten gespeichert (außer natürlich, dass sie durch den Arbeitsspeicher wandern, aber nichts persistierendes). Jitsi hat einen lesenswerten Artikel über die Sicherheit des Systems veröffentlicht.

Jitsi handelt den Wechsel zwischen P2P und JVB nahtlos und automatisch. Außerdem ist die JVB in der Lage, die Verbindungsqualität und -geschwindigkeit zu erkennen und die Videoqualität automatisch anzupassen.

Da Jitsi auf eigenen Servern gehostet werden kann (was empfohlen wird), kann jede Person ihre eigene Instanz laufen lassen, der sie dann vertrauen kann.

Großartig an der JVB ist, dass kein Video neu transkodiert werden muss. So sollte die die Belastung der CPU deutlich in Grenzen halten.

Falls benötigt, kann Jitsi sogar mit einem SIP-Gateway (Jigasi) konfiguriert werden, um Telefoneinwahlen zu ermöglichen.

Installation

Ich habe einen neuen Linode-Server eingerichtet, gehostet in Deutschland. Da ich hauptsächlich neugierig war und das ganze nur für meinen persönlichen Gebrauch gedacht ist, habe ich mich für einen Linode Nano entschieden. Dies ist der Server: Ubuntu 18.04 LTS, Nanode 1GB: 1 CPU, 25GB Storage, 1GB RAM. Der Nanode kommt mit 1 TB monatlichem Outbound-Traffic daher.

Nachdem der Server von Linode deployed wurde habe ich nur noch die A und AAAA DNS-Einträge für die IPv4- und IPv6-Adressen vorgenommen.

Die Installation an sich ist im Detail im Installationsdokument beschrieben. Dort wird das Setup des FQDN als optional beschrieben. Ich habe die /etc/hostname und /etc/hosts aber entsprechend angepasst, damit sie meinen gewählten Domainnamen enthalten. Dieser Name muss auch während der Installation angegeben werden.

Standardmäßig ist die Firewall der Ubuntu-Installation nicht aktiviert, also habe ich sie aktiviert und die Regeln für Jitsi eingetragen. Jitsi benutzt Port 10000 für die UDP-Session und 4443 (TCP) als Fallback. Natürlich sollte auch 443 erlaubt sein, bei Bedarf auch SSH.

Nach der Installation bin ich einmal auf den Fehler gestoßen, dass ich nicht auf die Jitsi Landing Page kam, sonder nur auf die von nginx. Eine Online-Recherche ergab, dass das Einfachste ist, den Server neu mit dem Ubuntu-Image aufzusetzen und den Setup-Prozess nochmal zu durchlaufen. Alles geht so schnell und einfach, dass dies keine besondere Hürde darstellte.

Jitsi, mit den Standardeinstellungen installiert, erstellt ein selbst signiertes Zertifikat. Optional kann auch ein eigenes verwendet werden. Zudem wird ein praktisches Script bereitgestellt, um ein Let’s Encrypt-Zertifikat zu beziehen. Das ist das, was ich gemacht habe.
Die Erneuerung über certbot-auto kann über einen Cronjob automatisiert werden. Das habe ich nicht gemacht (werde es aber sicherlich später), da ich die Software erstmal nur ausprobieren will.

Alles in allem funktioniert Jitsi wie angepriesen. Ein paar Testanrufe mit den Geräten, die ich zu Hause habe, waren erfolgreich. Nun werde ich Jitsi weiter testen und für Videoanrufe benutzen.

Wichtige Details

  • Die mobilen Clients (iOS/Android) brauchen eine Verbindung mit einem gültigen Zertifikat, anderenfalls wird die Verbindung zum Server überhaupt nicht hergestellt.
  • Firefox wird (derzeit) nicht vollständig unterstützt. Jitsi rät davon ab, Firefox derzeit einzusetzen, da es sich negativ auf die Verbindungsqualität auswirkt, selbst für die anderen Teilnehmenden. Dies hängt unter anderem mit einer unzureichenden Unterstützung von Multicast (oder Firefox’ Implementation dessen) zusammen. Die Community scheint an dem Problem zu arbeiten.
  • Safari unterstzützt kein WebRTC Video (mit H.264) (egal mit welcher (Videokonferenz-) Software)
  • Chrome (und andere Ableger wie Chromium, Opera, etc.) funktionieren einwandfrei.
  • Es gibt sogar eine plattformübergreifend verfügbare Electron-App für Windows, macOS, und GNU/Linux. Damit diese funktioniert, muss die externe API aktiviert werden. Darum habe ich mich nicht gekümmert.
  • Let’s Encrypt stellt Zertifikate nur für Domains aus. Wenn der Server ausschließlich über eine IP-Adresse zu erreichen ist, lässt sich also kein Zertifikat über Let’s Encrypt beziehen.

Update

2020-04-11: Cron

Wie sich herausstellt ist die Erneuerung von Let’s Encrypt-Zertifikaten einfacher als gedacht. Es scheint, dass das Installationsskript für das Zertifikat certbot nicht installiert hat. Also habe ich das nachgeholt mit apt-get install certbot.

Ich ließ das einmal mit certbot-auto laufen habe es angewiesen alle Zertifikate zu erneuern und nginx allen Traffic von http auf https umzuleiten.

Zukünftige Erneuerungen des Zertifikats sollten einfach sein mit cerbot renew.

Außerdem scheint certbot automatisch einen Cronjob unter /etc/cron.d/certbot angelegt zu haben.

0 */12 * * * root test -x /usr/bin/certbot -a ! -d /run/systemd/system && perl$ -e 'sleep int(rand(43200))' && certbot -q renew

So sollte ich mir keine Gedanken mehr um das manuelle Erneuern von Zertifikaten machen.

Diese Seiten waren hilfreich für mich.