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.