DecaTec

Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie

Nextcloud Talk mit eigenem TURN-Server (coturn)

Nextcloud Talk Logo

Für Nextcloud ist schon seit einiger Zeit eine Erweiterung als App verfügbar, mit der Chats und (Video-)Telefonate über die eigene Cloud geführt werden können: Nextcloud Talk.

Im Normalfall muss man dafür einfach die App im Nextcloud App Store herunterladen und kann sofort loslegen, mit anderen Nutzern der Cloud zu kommunizieren. Dank der Verfügbarkeit von mobilen Apps für Android und auch iOS kann diese Lösung auch als Alternative zu den bekannten Kommunikation-Apps (wie z.B. WhatsApp) genutzt werden. Das Hauptargument für Nextcloud Talk ist dabei sicherlich, dass Chats und (Video-)Telefonate komplett verschlüsselt über die eigene Nextcloud-Instanz ablaufen und so vor den neugierigen Blicken von Konzernen geschützt sind.

Dennoch treten bei Nextcloud Talk oftmals Probleme auf, wenn sich die genutzten Endgeräte nicht im selben Netzwerk befinden. Hier können dann keine (Video-)Telefonate geführt werden, da sich die Geräte einfach nicht finden können.

Damit über Nextcloud Talk jederzeit problemlos kommuniziert werden kann, ist ein eigener TURN-Server notwendig. Mit coturn ist ein solcher auch unter Ubuntu verfügbar. Dieser Artikel beschreibt daher die Installation und Konfiguration von coturn, um optimal mit Nextcloud Talk zusammen zu arbeiten.

Als Basis dient wie immer der Artikel Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban.

Wichtig: Auch wenn ein eigener TURN-Server bei Nextcloud Talk zum Einsatz kommt, sind dennoch Videokonferenzen mit maximal 4 bis 6 Teilnehmern möglich. Für mehr Teilnehmer ist dann ein externer „Signaling Server“ notwendig, den man allerdings nur in Verbindung mit einer Nextcloud Enterprise Subscription nutzen kann.
Wenn an die Videokonferenz-Lösung höhere Ansprüche gestellt werden, könnte Jitsi Meet eine geeignetere Lösung sein (siehe Artikel Jitsi Meet: Videokonferenz-System unter Ubuntu Server mit nginx)

Update-Historie (letztes Update: 12.04.2020)
  • 12.04.2020:
    • Hinweis zu den Einschränkungen von Nextcloud Talk hinzugefügt.
  • 03.02.2020:
    • Cipher Suite DHE-RSA-AES256-GCM-SHA384 entfernt.

 

Probleme mit Nextcloud Talk mit eigenem STUN/TURN-Server lösen

Nextcloud Talk basiert auf WebRTC. Die bei der Kommunikation beteiligten Endgeräte bauen dabei eine direkte Peer-to-Peer-Verbindung auf.

Im gleichen Netzwerk (LAN) ist dies kein Problem, hier müssen alle Endgeräte lediglich WebRTC unterstützen.

Wenn sich die Geräte in unterschiedlichen Netzwerken befinden, müssen die Geräte sowohl ihre interne, also auch ihre externe IP-Adresse kennen. Diese Umsetzung ist die Aufgabe eines STUN-Servers (Session Traversal Utilities for NAT). Für Nextcloud Talk ist ein eigener STUN-Server verfügbar (stun.nextcloud.com:443), daher sollte dies auch kein Problem darstellen.

Wenn nun allerdings Firewalls mit im Spiel sind, kann der STUN-Server die „Übersetzung“ der Adressen nicht mehr leisten. In diesen Fällen spricht man von einem Symmetric NAT: Hier wird durch die Firewall verhindert, dass von außen (d.h. aus dem Internet) initiierte Verbindungen in das lokale Netzwerk möglich sind. In diesem Szenario ist dann ein TURN-Server (Traversal Using Relays around NAT) notwendig, über den sämtliche Verbindungen geleitet werden.

Diese Thematik ist durchaus komplex, aber vereinfacht kann man sagen, dass man einen TURN-Server benötigt, wenn die Verbindung zwischen Geräten in unterschiedlichen Netzwerken nicht aufgebaut werden kann (z.B. PC im Heimnetzwerk, Smartphone in Mobilfunknetz). Im Heimnetzwerk-Bereich ist dies vermutlich immer der Fall.

Unter Ubuntu ist coturn als quelloffene Implementierung eines STUN/TURN-Servers verfügbar.

Installation und Konfiguration coturn

coturn kann ganz einfach auf dem gleichen System installiert werden, auf dem auch schon Nextcloud läuft.

Zunächst bringen wir das System auf den neusten Stand:

Anschließend kann coturn auch schon installiert werden, da es bereits Teil der Ubuntu-Paketquellen ist:

Nach der Installation muss coturn nun nur noch konfiguriert werden, damit eine optimale Zusammenarbeit mit Nextcloud Talk gewährleistet ist.

Dazu wird coturn erst einmal aktiviert. Dies geschieht in folgender Datei:

Hier muss folgende Zeile eingefügt werden. Diese ist nach der Installation bereits vorhanden, ist allerdings auskommentiert. Daher entfernen wird einfach das Zeichen ‚#‘ am Anfang der Zeile:

Als nächstes werden die Einstellungen von coturn bearbeitet.
Diese befinden sich in folgender Datei:

Hier müssen die folgenden Werte angepasst werden. Die meisten Werte sind hier bereits vorhanden, allerdings auskommentiert. Auch hier entfernen wir die Raute (‚#‘) vor der entsprechenden Zeile.

  • tls-listening-port=5349
  • fingerprint
  • lt-cred-mech
  • use-auth-secret
  • static-auth-secret=<secret>
  • realm=meinedomain.de
  • total-quota=100
  • bps-capacity=0
  • stale-nonce=600
  • cert=/etc/letsencrypt/live/meinedomain.de/cert.pem
  • pkey=/etc/letsencrypt/live/meindomain.de/privkey.pem
  • cipher-list=“ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384″
  • no-loopback-peers
  • no-multicast-peers
  • dh-file=/etc/nginx/ssl/dhparams.pem
  • no-tlsv1
  • no-tlsv1_1
  • no-stdout-log

Zu den angegebenen Werten hier noch ein paar Erklärungen:

  • tls-listening-port: Hier verwende ich den Standard-Port für TLS-Verbindungen zu coturn (5349). Hier könnte man auch einen anderen Port angeben. Diesen sollte man sich merken, da man diesen nachher in der Firewall freischalten muss.
  • static-auth-secret: Dies ist ein Passwort, welches zur Nutzung des TURN-Servers benötigt wird. Dies ist ein Sicherheitsmerkmal, so dass kein Dritter ohne Kenntnis dieses Passwortes den TURN-Server verwenden kann. Dieses Passwort muss man sich nicht merken und wird später nur in den Nextcloud-Einstellungen hinterlegt, daher lässt man sich dies am besten einfach durch folgenden Befehl generieren: openssl rand -hex 32
  • cert/pkey/dh-file: Dies sind die SSL-Zertifikate bzw. Diffie-Hellman-Parameter, die für die verschlüsselte Verbindung über TLS benötigt werden. Hierzu verwenden wir einfach die bereits vorhandenen Zertifikate für die eigene Domain (siehe hier und hier).
  • cipher-list: Legt die Cipher-Suite für die TLS-Verbindung zum TURN-Server fest. Hier kann die Cipher-Suite angegeben werden, die auch schon der Webserver nginx verwendet (hier heißt die Variable ssl_ciphers, siehe hier).

Nach der Anpassung der Konfiguration von coturn wird das Programm neu gestartet, damit die Änderungen übernommen werden.

Portfreigaben einrichten

Nach der Einrichtung des TURN-Servers muss nun noch eine Portfreigabe eingerichtet werden, damit coturn auch „von außen“ erreichbar ist.

Wichtig ist hier der Port, der bei der Variable tls-listening-port in der coturn-Konfiguration angegeben wurde. In diesem Beispiel verwende ich dazu den Standard-Port 5349.

Zunächst muss hier eine entsprechende Portweiterleitung im Router eingerichtet werden. Das genaue Vorgehen unterscheidet sich hier von Router zu Router, daher kann an dieser Stelle keine detaillierte Anleitung erfolgen. Hier sollte man aber alle notwendigen Informationen auf den Hersteller-Seiten finden (so z.B. auf den AVM Hilfeseiten, wenn man eine FritzBox im Einsatz hat). Wichtig ist hier, dass die Freigabe für die beiden Protokolle TCP und UDP angelegt werden. Dazu ist meistens das Anlegen von zwei Freigaben notwendig, hier am Beispiel einer FritzBox:

Portfreigaben für cotun (FritzBox)

Portfreigaben für cotun (FritzBox)

Wenn darüber hinaus auch noch eine Firewall auf dem System installiert ist, auf dem coturn eingerichtet wurde, so muss auch hier eine Freigabe erfolgen. Auf vielen Systemen wird wohl ufw (uncomplicated firewall) eingerichtet sein. Hier erfolgt die Freigabe dann über folgende Befehle:

Nextcloud Talk mit eigenem STUN/TURN-Server

Nun kann Nextcloud Talk mit dem eigenen STUN bzw. TURN-Server betrieben werden.

Zunächst muss – falls noch nicht geschehen – die App Talk aus dem Nextcloud App Store heruntergeladen werden. Diese befindet sich in der Kategorie Kommunikation.

Talk im Nextcloud App Store

Talk im Nextcloud App Store

Nach der Installation der App muss diese noch konfiguriert werden, damit diese coturn als STUN bzw. TURN-Server nutzt. Die dazugehörigen Optionen findet man in den Admin-Einstellungen von Nextcloud unter dem Punkt Talk.

Nextcloud Talk: Einstellungen für eigenen STUN/TURN-Server

Nextcloud Talk: Einstellungen für eigenen STUN/TURN-Server

Zunächst fügen wir mit der Plus-Schaltfläche einen zusätzlichen STUN-Server hinzu:

meinedomain.de:5349

Die Einstellungen für den TURN-Server sehen dann folgendermaßen aus:

  • URI: meinedomain.de:5349: Der Port wurde zuvor in der coturn-Konfiguration (tls-listening-port) hinterlegt.
  • Gemeinsames Geheimnis: Hier muss das Passwort angegeben werden, welches bei der Konfiguration von coturn als Variable static-auth-secret hinterlegt wurde.
  • UDP und TCP: Nextcloud Talk soll hier für maximale Kompatibilität sowohl TCP- als auch UDP-Verbindungen nutzen.

Unter Signalisierungsserver sind keine Eingaben notwendig.

Die Konfiguration kann nun ganz einfach mit der entsprechenden Schaltfläche getestet werden (siehe Pfeil oberes Bild). Hier sollte dann nach einem kurzen Augenblick auch eine Erfolgsmeldung erscheinen:

TURN-Server ist richtig konfiguriert

TURN-Server ist richtig konfiguriert

Chats und (Video-)Telefonie über die eigene Nextcloud

Ab sofort können über Nextcloud Talk Chats, Telefonate und auch Video-Telefonate geführt werden. Dies ist auf den verschiedensten Endgeräten möglich: Zum einen kann Nextcloud Talk ganz einfach im Browser verwendet werden. Dazu in der oberen Menüleiste einfach auf das Talk-Symbol klicken. Nun noch den passenden (Nextcloud-)Kontakt auswählen und schon kann es losgehen.

Nextcloud Talk in Aktion

Nextcloud Talk in Aktion

Richtig interessant wird die Sache allerdings mit mobilen Geräten, wie z.B. Smartphones. Hier stehen App sowohl für iOS, als auch für Android bereit:

Nextcloud Talk
Preis: Kostenlos
‎Nextcloud Talk
Preis: Kostenlos

Der Funktionstest des eigenen TURN-Servers erfolgt am besten mit einem Smartphone: Wenn dieses nicht mit dem Heimnetzwerk, sondern mit dem Mobilfunknetz verbunden ist, sollten sowohl Chats, auch als (Video-)Telefonate mit einem Gerät im Heimnetzwerk problemlos möglich sein.

Troubleshooting

Falls Probleme mit Nextcloud Talk auftreten, sollte zunächst einmal die grundsätzliche Konfiguration durch die entsprechende Schaltfläche in den Admin-Einstellungen zu Talk überprüft werden (siehe Screenshot weiter oben). Anschließend kann es auch sinnvoll sein, die Nextcloud-Logs zu überprüfen. Diese findet man in der Admin-Oberfläche von Nextcloud unter dem Punkt Protokollierung.

Wenn im Nextcloud-Log keine Einträge vorhanden sind, die sich mit Talk in Verbindung bringen lassen, sollte die Funktion von coturn überprüft werden. Die Log-Dateien von coturn befinden sich im Verzeichnis /var/log. Die gesuchten Log-Dateien beginnen alle mit turn_ und beinhalten eine Datumsangabe im Dateinamen, z.B. turn_1352_2018-11-08.log. In diesen Log-Dateien sollte dann zumindest ein Hinweis zu finden sein, warum es zu Problemen gekommen ist.

Fazit

Im Heim-Bereich funktioniert Nextcloud Talk leider nicht immer out-of-the-box – mit dem Aktivieren der App ist es hier meistens nicht getan. Allerdings kann mit coturn recht einfach ein eigener STUN/TURN-Server in Betrieb genommen werden. Der entsprechende Konfigurations-Aufwand hält sich hierfür auch in Grenzen.

Mit Hilfe des eigenen TURN-Servers ist es nun aber möglich, über die eigene Cloud Chats und (Video-)Telefonate zu führen. Dieses Konzept ist im Vergleich zu den bekannten Apps (wie z.B. WhatsApp) besonders interessant, da die Kommunikation ausschließlich verschlüsselt über die persönliche Cloud abläuft, ohne dass hier Konzerne wie Google oder Facebook „mitlesen“ können.

Weiterführende Artikel

Links

, , , , , , , ,

Kommentare: 82

  • Marco sagt:

    Ich danke dir! ;)

  • Tom sagt:

    Wieder eine sehr gute Anleitung !

    Zwei Anmerkungen noch :

    1) man kann für die ufw auch den App-Filter benutzen
    (wenn die Ports nicht verändert wurden):
    sudo ufw allow Turnserver

    2) Server-Sicherheit kann mit den Parametern
    proc-user=turnserver
    proc-group=turnserver

    erhöht werden (dann läuft Cotrun mit reduzierten Rechten).
    Dann aber auch den Parameter syslog aktivieren (hat bei mir sonst Probleme gemacht)

  • Torsten sagt:

    Wie immer eine sehr gute Anleitung und prima Erklärungen!
    Vielen Dank für deine Mühe!

  • Meiko sagt:

    Vielen Dank für die Anleitung!

    Ich habe meinen TURN Server zum Laufen bekommen. Ich konnte mich mit dem Smartphone (nicht im lokalen Netzwerk) und einem Rechner, der sich im lokalen Netzwerk (zusammen mit dem TURN Server) befindet, verbinden. Klappt also.

    Aber: Wenn ich mich mit dem Smartphone und dem Rechner auf der Arbeit verbinden will, bekomme ich keine Video-Verbindung hin. Chat geht. Kann es sein, dass auf der Arbeit bestimmte Ports nach außen gesperrt sind, die benötigt werden? Den IT Admin kann ich nicht fragen. Ich dachte jedoch, dass es nach außen von den Clients über Port 80 läuft, oder ist das falsch?

    Danke dir
    Meiko

    • Jan sagt:

      Hi Meiko,

      da die Verbindung prinzipiell geht, ist coturn/Talk korrekt eingerichtet.
      Da die Chats auf der Arbeit auch „durchkommen“ – eben nur keine Videos – würde ich eher darauf tippen, dass WebRTC auf dem Arbeits-PC deaktiviert wurde. In diesem Fall kann man denke ich nicht viel machen, es sei denn, der Admin schaltet es wieder frei.

      Gruß,
      Jan

  • Horst sagt:

    Hallo, kann man einen Turn Server auch hinter einem Reverse Proxy betreiben? Vor meiner Nextcloud läuft eine pfsense mit Haproxy. Setzte ich einfach den Haproxy vor der Nextcloud dann geht das leider nicht. hat da jemand Erfahrung? Danke!!

    • Jan sagt:

      Hallo Horst,

      leider kenne ich mich weder mit pfsense, noch mit HAproxy aus.
      pfsense sollte hier nicht das Problem sein, wenn die Firewall richtig konfiguriert ist.
      Ich würde den Fehler also erst einmal bei HAproxy suchen. Dieser muss so konfiguriert werden, dass die Protokolle TCP und UDP behandelt werden können.
      Vielleicht hilft hier ein Blick in die Logs aller beteiligten Komponenten?

      Gruß,
      Jan

  • Horst sagt:

    Hallo Jan,
    aber grundsätzlich funktioniert auch ein Turn Server hinter einem Reverse Proxy? Ich dachte vielleicht ist ja ein Reverse Proxy und dann ein dahinter Turn an sich schon ein Widerspruch?
    Danke!

    • Jan sagt:

      Hi Horst,

      nein, ich wüsste nicht, was aus technischer Sicht dagegen sprechen sollte. Ein Kommunikations-Kanal wird durch einen Proxy ja nur durchgeschleust.

      Gruß,
      Jan

  • Gunnar sagt:

    Hallo Jan,

    vielen Dank für deine Anleitung(en), welche ich seit geraumer Zeit fleissig nutze. Ich hab da mal eine Frage zu Nextcloud Talk; ist es möglich Bild-/Videodateien über die mobile clients zu verschicken und wenn ja wie ?

  • Michael sagt:

    Hallo Jan,
    vielen Dank für diese Anleitung!
    Ich habe den Turn Server so eingerichtet wie beschrieben und bekomme auch keine Fehlermeldung. Leider funktioniert aber der Videochat nicht richtig. Wenn ich einen neuen Anruf starte, sieht einer der Teilnehmer den anderen nicht. Oder der Ton funktioniert nicht. Habe es in Google Chrome und in der iOS Talk App probiert. Innerhalb eines Netzwerks und außerhalb. Nichts funktioniert zuverlässig.

    Hast du eine Idee woran es liegen könnte?
    In den Logs gibt es einen komischen Eintrag:

    Cannot bind TLS/TCP listener socket to addr [2001:16b8:XXX:c200:XXX:29ff:feba:3c92]:3478

    Wobei ich den Port 3478 in der turnserver.conf nicht nutze. Alles läuft über Port 5349

    Würde mich freuen wenn du einen Tipp für mich hast :)

    • Michael sagt:

      Die vorherige Fehlermeldung mit der Ipv6 Adresse glaube ich darauf zurückzuführen, dass ich Ipv6 nicht richtig route. Die viel interessantere Fehlermeldung ist folgende:
      130: session 001000000000000001: realm user : incoming packet message processed, error 401: Unauthorized

      • Jan sagt:

        Hi Michael,

        bei „Unauthorized“ muss ich erst einmal an die Variable static-auth-secret denken. Hast du diese in der coturn-Config, als auch in den Nextcloud-Einstellungen korrekt gesetzt?
        Kontrollier auch gleich mal alle anderen Einstellungen in der coturn-Config. Könnte sein, dass sich hier irgendwo ein Tippfehler eingeschlichen hat und daher coturn nicht so recht will.

        Gruß,
        Jan

        • Michael sagt:

          Habe ich schon alles probiert. Die Kommunikation funktioniert immer nur in eine Richtung.
          Coturn habe ich auch schon deinstalliert und wieder neu aufgesetzt inkl. coturn config.
          Google hilft auch nicht wirklich weiter.

          • Jan sagt:

            Hi Michael,

            OK, wenn die Logs nicht mehr hergeben, dann müssen wir hier wohl analytisch rangehen.
            Wenn immer nur ein Teilnehmer den anderen nicht sehen kann, kannst du das Problem weiter eingrenzen? Beispielsweise: Ist immer der Teilnehmer mit der Nextcloud Talk App betroffen, tritt das Problem nur bei den Clients auf, die sich nicht im gleichen LAN befinden, etc.?
            In der Cloud hast du ja sicherlich zwei User angelegt (die dann kommunizieren sollen). Hat einer davon evtl. eine Zwei-Faktor-Authentifizierung aktiviert?
            Erscheinen im Nextcloud Log beim Verbindungsaufbau evtl. auch Fehlermeldungen der Art „Login nicht korrekt“?

            Gruß,
            Jan

  • Michael sagt:

    Ohne Coturn im gleichen LAN funktioniert die Verbindung nicht richtig. Clients: Firefox, Chrome, iPhone 8 und Android getestet.
    Es liegt also nicht unbedingt an Coturn.

    2FA habe ich mal komplett deaktiviert – kein Unterschied

    Welche Logs könnten helfen? Außer die Coturn.

    Vielen Dank für deine Hilfe!

    • Michael sagt:

      Update:
      Videoübertragung zwischen iPad (LAN) und iPhone (LAN & WAN) funktioniert in beide Richtungen.
      Videoübertragung vom iPhone (LAN & WAN) zu Android funktioniert nur sporadisch. Kein Muster zu erkennen.
      Genauso bei Firefox und Chrome.

      Sehr komisches Verhalten..

      • Jan sagt:

        Hi Michael,

        vielleicht ein wichtiger Hinweis, dass es ohne Coturn im LAN auch nicht funktioniert. Im selben LAN sollte Coturn eigentlich gar nicht notwendig sein und es sollte mehr oder weniger out-of-the-box funktionieren (also einfach Nextcloud Talk App aus dem App Store aktivieren und fertig).
        Daher würde ich Coturn fast mal aus der Gleichung rausnehmen. Ist in deinem Netzwerk irgendwas spezielles installiert/eingerichtet? Kommen denn irgendwelche Meldungen in der Developer-Console der Browser (F12), wenn du einen Video-Call starten willst?
        Von den Log her würde ich nochmals alles kontrollieren: Coturn, Nextcloud und evtl. auch das nginx error.log.
        Die Frage ist halt, was es mit dem Unauthorized Error auf sich hat. Wird dieser nur von Coturn geworfen, oder tritt dieser schon in den darunter liegenden Schichten (Nextcloud, nginx) auf?

        Gruß,
        Jan

        • Michael sagt:

          Hallo Jan,

          ich bin genau deinen Anleitungen gefolgt.
          Ja, Talk hat auch schon mal ohne Coturn funktioniert (einmalig). Danach nicht mehr.

          im nginx error log steht ein kritischer Fehler:

          [crit] 1093#1093: *5 connect() to unix:/run/php/php7.2-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /nextcloud/ocs/v2.php/apps/spree$

          und noch viele weitere [error]

          2019/02/09 11:28:28 [error] 1087#1087: *6590 open() „/etc/nginx/html/about.php“ failed (2: No such file or directory), client: 194.147.32.109, server: marwinhugger.de, request: „GET /about.php HTTP/1.1“, host: „meineIP“

          Ansonsten noch:

          2019/02/09 08:16:58 [error] 12060#12060: *6850 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /nextcloud/ocs/v2.php/apps/spreed/api/v1/chat/$
          2019/02/09 08:16:58 [error] 12060#12060: *6856 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: 127.0.0.1, request: „GET /nextcloud/ocs/v2.php/apps/spreed/api/v1/signa$

          Kannst du mit den Fehlern etwas anfangen?
          Ich kann dir auch die vollständigen logs schicken wenn du damit was anfangen kannst.
          Ich bin langsam am verzweifeln :P

          • Jan sagt:

            Hi Michael,

            sieht so aus, als ob der beim API-Zugriff der Spreed-App in Nextcloud (= Nextcloud Talk) den PHP-Socket nicht finden würde.
            Läuft dieser wirklich unter /run/php/php7.2-fpm.sock? Vermutlich schon, sonst würde ja auch alles andere nicht funktionieren.
            Unter welchem User läuft nginx und unter welchem PHP (definiert in der Datei nano /etc/php/7.2/fpm/pool.d/www.conf)?
            Gibt es irgendwo unter /var/log noch Logfiles von PHP, wo vielleicht auch noch Fehler enthalten sind?

            Gruß,
            Jan

          • Michael sagt:

            Nginx läuft unter www-data (wobei unter serice nginx status – worker prozess steht)
            In der /etc/php/7.2/fpm/pool.d/www.conf steht listen=/run/php/php7.2-fpm.sock

            PHP läuft auch unter www-data (service php7.2-fpm status)

            In der php7.2-fpm.log steht noch folgende Meldung:
            [07-Feb-2019 20:51:45] WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

          • Jan sagt:

            Hi Michael,

            dann erhöhe doch mal pm.max_children (hier genauer beschrieben).
            Vielleicht ist das ja schon des Rätsels Lösung, warum es manchmal geht und manchmal nicht…

            Gruß,
            Jan

          • Michael sagt:

            Ok der Fehler mit pm.max_children setting ist jetzt schon mal behoben.

            Im Turn* Log erscheint auch kein Authentifizierungsfehler mehr.

            Am Verhalten hat sich leider noch nichts geändert.

          • Jan sagt:

            Hi Michael,

            puh, ich muss zugeben, dass mir so langsam die Ideen ausgehen, woran das bei dir liegen könnte. Sorry!
            Du könntest aber mal einen Issue im entsprechenden Repository bei GitHub eröffnen. Da hast du dann einen direkten Draht zu den Entwicklern. Vermutlich kann dir da schneller geholfen werden.

            Falls du eine Lösung finden solltest, würde es mich natürlich auch brennend interessieren, wo nun das eigentliche Problem lag.
            Wenn mir dazu noch einfallen sollte, werde ich mich aber nochmal bei dir melden. Sorry nochmal, dass ich da nun auch nicht mehr weiter weiß.

            Gruß,
            Jan

  • Martin sagt:

    Hallo zusammen,

    ich habe eine Verständnisfrage: Meine Nextcloud habe ich via DynDNS im Internet unter meiner täglich wechselnden IP adresse verfügbar gemacht.
    Bisher hatte ich keine Probleme, mit Talk oder der Nextcloud app für File-Zugrioff von überall auf der Welt auf den Server zuhause zuzugreifen.
    Welchen Vorteil würde mir nun ein TURN Server bringen?

    Danke und Gruß,
    Martin

    • Jan sagt:

      Hi Martin,

      wenn bei dir alles funktioniert, dann brauchst du eigentlich auch keinen eigenen TURN-Server. Allerdings habe ich die Erfahrung gemacht, dass gerade mobile Nextcloud Talk Clients Probleme mit der Verbindung zu Talk haben, wenn diese nicht im gleichen Netz (sondern z.B. im Mobilfunknetz) sind.
      Also einfach mal ausprobieren. Wenn es klappt, kannst du dir die Installation des TURN-Servers sparen.

      Gruß,
      Jan

  • Karsten sagt:

    Hallo Jan,
    vielen Dank für die super Anleitungen! Ich habe die Nextcloud und den Coturn nach Deiner Anleitung installiert und alles funktioniert prima. Ich habe nur ein Problem mit der Performance, sobald ich TALK nutze. Der Server langweilt sich (RAM und CPU am unteren Limit) und trotzdem geht die Nextcloud „in die Knie“ und man kann während einer TALK-Session kaum mehr mit der Nextcloud arbeiten. Ab dem 3. User ist auch TALK dann nicht mehr stabil. Muss ggf. etwas an den PHP-Einstellungen oder dem NGINX angepasst werden?

    Gruß
    Karsten

    • Jan sagt:

      Hi Karsten,

      dieses Verhalten konnte ich noch nicht nachvollziehen, allerdings nutze ich Talk auch viel zu selten.
      Hast du schonmal per htop nachgesehen, wie sich die System-Ressourcen bei einer Talk-Session verhalten? Vielleicht kann man das Problem ja eingrenzen (z.B. Webserver/PHP oder nur coturn).
      Irgendwas auffälliges in den Logs zu finden?

      Gruß,
      Jan

      • Karsten sagt:

        Hallo Jan,
        ja, mit htop hatte ich das Verhalten während der Talk-Session beobachtet. Prozessorauslastung ist unter 10% und RAM ist auch noch mehr als ausreichend frei. SWAP wird nicht genutzt. Die Bandbreitenmessung auf dem Server ergab auch keine Hinweise darauf, dass die Bandbreite ausgeschöpft sein könnte. Bei den Port-Zugriffen habe ich gesehen, dass es vwährend der Talk-Session viele Verbindungen zwischen localhost:82 und localdomain.localhost:40000> gibt, die auf „Wait“ stehen. Die Verbindungen zu Coturn sind „established“. Ob die Verbindungen auf „Wait“ den LAN-Traffic so beeinflussen, dass das gesamte System in die Knie geht, kann ich nicht sicher sagen. Woher diese Verbindungen kommen, kann ich leider auch nicht sagen. Aber auf localhost:82 lauscht die Nextcloud-Instanz und die Verbindungen verschwinden nach und nach, wenn alle User die Talk-Session beendet haben.
        Ich habe auch einen anderen TURN-Server über WAN verwendet, hier habe ich das gleiche Problem. Also scheint es nicht am TURN zu liegen.
        Die Instanz läuft hinter einem Reverse Proxy und die Zugriffe der Server ins Internet gehen auch über einen Proxy.
        Hast Du da noch eine Idee? Bei PHP kenne ich mich nicht sonderlich gut aus. Gibt es da evtl. noch sinnvolle Tests, bzw. „Stellschrauben“?

        Viele Grüße
        Karsten

        • Jan sagt:

          Hi Karsten,

          also es sieht für mich nicht so aus, als ob es an den Systemressourcen liegt.
          Was nutzt du denn für eine Internet-Leitung? Ich habe nichts offizielles gefunden, aber hier ist die Rede davon, dass pro User 2 MBit/s der Leitung benötigt werden (ich denke mal Upload!). Vielleicht ist das ja der Flaschenhals.
          Du könntest auch einfach mal im Forum nachfragen, hier ist der Maintainer von Talk auch aktiv unterwegs.

          Gruß,
          Jan

          • Karsten sagt:

            Hallo Jan,
            das Problem ist inzwischen gelöst. Nextcloud Talk geht ab max. 4 Verbindungen in die Knie. Das liegt an den Peer-to-Peer-Verbbindungen die in den Sessions zwischen allen Endgeräten untereinander aufgebaut werden müssen. Das ist sowohl für die Bandbreite, als auch für die Leistungsfähigkeit der Endgeräte ein Problem. Wenn man Talk mit mehreren Teilnehmern nutzen will, benötigt man das Nextcloud High-Performance-Backend, welches man nur gegen den Einwurf großer Münzen bei Nextcloud bekommen kann. Dafür funktioniert das dann auch prima (hab´s getestet).
            Wenn ich das richtig sehe, besteht das Backend aus einem Signaling-Server und einem Janus-Server. Vielleicht hat ja jemand eine Idee, wie man das lizenzkostenfrei nachgebaut bekommt.

            Viele Grüße
            Karsten

          • Jan sagt:

            Hallo Karsten,

            OK, ich dachte, das wichtigste für eine gute Performance/mehrere Talk-Teilnehmer sei ein eigener Turn-Server.
            Leider fehlen mir hier die Erfahrungswerte mit vielen Talk-Teilnehmern.

            Wie konntest du das bezahlte Angebot der Nextcloud GmbH testen? Hast du hier eine Subscription abgeschlossen?

            Gruß,
            Jan

  • Rainer sagt:

    Hallo Jan,
    wie immer, absolut top…ich lerne mit jedem Beitrag dazu. Aber leider reicht mein Verständnis noch nicht ganz…..:

    Ich habe die TLS-Zertifikate erneuert gemäss deiner Anleigung „RSA und ECDSA-Zertifikate mit nginx“ bzw. „TLS1.3…“. Das hat auch alles geklappt, aber nun ist es so, dass ich auf einem Android-Smartphone (Version 7) mich nicht mehr in die Talk-App einloggen kann (error: handshake failed), auf einem aktuellen Android-Smartphone (Version 9) klappt es.
    Hatte es mit beiden Pfadangaben (RSA und ECDSA) sowie der Anpassung der cipher-list ausprobiert. Kannst du mir sagen, woran es liegen könnte bzw was hier die richtigen Parameter sind ?
    P.S: Verbindungsaufbau zur Nextcloud-App funktioniert aber dennoch problemlos auf dem Android 7.0

    • Jan sagt:

      Hi Rainer,

      was sagt der SSL Server Test für deine Cloud-Domain?
      Unter „Handshake simulation“ ist ja auch Android 7 aufgeführt. Wenn das für die Cloud an sich passt und du die gleichen Parameter für Coturn verwendest, dann sollte das auch mit der Talk-App funktionieren.
      Testweise könntest du auch mal für Coturn eine „schwächere“ Cipher List ausprobieren (siehe hier).

      Wenn das alles nichts bringt, dann würde ich mal auf ein App-spezifisches Problem tippen. Hier dann am besten mal im entsprechenden GitHub-Repo einen Issue erfassen.

      Gruß,
      Jan

      • Rainer sagt:

        Hi Jan,
        leider bislang alles erfolglos.
        SSL Server Test bringt ein A+ und bei Handshake Simulation steht bei Android 7 ein „TLS 1.2 > h2 „; einloggen geht trotzdem nicht.

        Auch eine Änderung durch eine älteres CipherList hat nichts geändert.
        Bin auch meine Config mehrmals durchgegangen, alles gut, es war zwar ein kleiner Fehler in der Pfadangabe zu dhparams.pem, aber das hab ich korrigiert (erstaunlicherweise konnte ich trotz dem Fehler vom aktuellen Android als auch von einem iOS v12.3.1 mich erfolgreich in Talk anmelden)
        Das komische ist ja, dass es ja vorher ging, bevor ich die Aktualisierung der Zertifikate angegangen bin. Hast du noch ne Idee?

        Weiss nicht, ob dies damit zu tun hat, aber im(aktuellen Firefox-)Browser zeigt er mir diese Verschlüsselung an: TLS-ECDHE-RSA_WITH_AES_256_GCM_SHA384,256-Bit-Schlüssel,TLS 1.2)
        Heisst doch, er nimmt das „alte“ Zertifikat statt dem neuen ECDSA ??

        Gruss Rainer

        • Jan sagt:

          Hallo Rainer,

          also meine Cipher List in der turnserver.conf sieht momentan so aus:
          cipher-list="TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384"

          Damit habe ich unter Android (9) keine Probleme.
          Was passiert, wenn du nach der Umstellung der Zertifikate trotzdem wieder die Ciper-Lists einsetzt, die du vorher hattest? Dass hier andere Zertifikate installiert wurden, sollte in diesem Zusammenhang ja nicht weiter stören.

          Gruß,
          Jan

          • Rain sagt:

            Hallo Jan,

            ich gebs auf…..hab die Cipher-List genommen, die du in deinem „Talk-Manual“ aufführst, genommen (=wenn du es nicht geändert hast,dann war dies auch meine „alte“), ebenso die, welche du aktuell bei dir verwendest. Ohne Erfolg.
            Hab in der turnserver.conf den Pfad zu den RSA-Zertifikaten als auch zu den ECDSA-Zertifikaten ausprobiert, hab im Gatewayhost der Nextcloud-Installation den Pfad zur ca.pem mit beiden Zertifikaten ausprobiert….alles ohne Erfolg, aber eben immer nur bei Android 7 EMUI 5.0.3.
            Mit meinem aktuellen Android-System als auch auf iOS 12 kann ich mich einloggen.
            Was ich eben nur nicht verstehe, dass es vorher bei diesem Smartphone funktionierte und ich mich auch weiterhin auf der normalen Nextcloudapp problemlos einloggen kann.
            Wenn du noch irgend ein Tip hast..entweder überseh ich ständig was, aber ansonsten bin ich mit meinem Latein am Ende…….das letzte, was ich noch machen kann, ist ein ein Ticket bei github aufzumachen.
            Gruss Rainer

          • Jan sagt:

            Hi,

            leider kann ich dazu nicht mehr sagen, da ich das Problem ja hier nicht mal nachvollziehen kann.
            Die Konfiguration (Nextcloud und coturn) scheint ja soweit zu passen, da andere Clients sich damit verbinden können.
            Am besten wäre wohl wirklich, ein Ticket bei GitHub auf zu machen.

            Sorry, ich wünschte, ich hätte hier noch einen heißen Tipp gehabt.

            Gruß,
            Jan

  • Rainer sagt:

    Hallo Jan,

    ich hab schon nicht mehr daran geglaubt, aber nach unzähligen Versuchen hab ich den Grund doch noch herausbekommen:
    Es lag an der „ssl_ecdh_curve“ >>>hier verlangt Android 7 wohl weiterhin die prime256v1. Nachdem ich diese in der ssl.conf wieder hinzugefügt hatte, klappte der Verbindungsaufbau :-)
    Dir aber nochmals ein dickes Lob für deinen Blog!!

    Gruss Rainer

    • Jan sagt:

      Hallo Rainer,

      OK, dann war es also nur ein simples Problem, auf dessen Lösung man aber erst einmal kommen muss. ;-)

      Auf jeden Fall danke für die Rückmeldung. Super, dass es bei dir nun auch unter Android 7 funktioniert.

      Gruß,
      Jan

  • micky1067 sagt:

    Tolle Anleitung.
    Könnte man das auch auf einer Synology DS218+ anwenden ?
    Vielleicht sogar in einem Docker Container ?

    • Jan sagt:

      Hi,

      ob es dafür einen Docker-Container gibt, kann ich dir gar nicht sagen.
      Sobald zu Root-Zugriff auf das System hast, solltest du coturn installieren können.

      Gruß,
      Jan

      • micky1067 sagt:

        Hallo Jan,
        Einen docker Container gibt es. Ich habe ihn
        nur bisher noch nicht zum laufen gebracht.
        Ich traue mich nur nicht den coturn Server direkt
        ohne Container auf die Diskstation zu installieren.

        Viele Grüße
        micky1067

  • Bernd sagt:

    Danke für die Anleitung.
    Wenn ich auf Verbindung testen klicke, erhalte ich keine Meldung. Die Verbindung von iPhone zu mac oder Tablet funktioniert aber ohne Probleme. Ich gehe also davon aus, dass der turn Server richtig eingerichtet ist.
    Was auffällt. Die Verbindung ist manchmal langsam oder der Videoaufbau braucht ewig. Ein anderer Nutzer konnte sein Bild überhaupt nicht übermitteln. Wie viel gleichzeitige Teilnehmer verkraftet nextcloud Talk? Wo kann man noch an der Performance schrauben bzw. was könnte ein Flaschenhals sein. Ich hatte 5 Teilnehmer getestet.

    • Jan sagt:

      Hallo Bernd,

      konkrete Zahlen kann ich dir zwar nicht nennen, aber NC Talk (bzw. der Turn-Server) verbraucht schon einiges an Bandbreite. Im Heimgebrauch dürfte dann meist eine zu geringe Upload-Geschwindigkeit dazu führen, dass die Talk-Sessions ins Stocken geraten.
      Hängt also hauptsächlich von deiner Internet-Verbindung ab.

      Gruß,
      Jan

  • Micha sagt:

    Also ich krieg das mit dem Parameter „tls-listening-port=5349“ nicht hin, funktioniert das nur wenn die restlichen Parameter für SSL passen? sobald ich tls- entferne sprich listening port dort steht läuft alles direkt…

    • Jan sagt:

      Hi Micha,

      ja, wenn die Verbindung über TLS stattfinden soll, dann müssen auch die restlichen Parameter für TLS/SSL gesetzt werden (Zertifikate, etc.). Sonst kann er ja gar keine Verbindung über TLS aufbauen.

      Gruß,
      Jan

  • Peter sagt:

    Hallo, ich bin ziemlich neu in diesem Thema und habe ein Vertsändnisproblem.
    Aber zuerst mal zur Ist-Situation:

    Ich habe bei 1und1 meine Nextcloud 18.x innerhalb meines Webpakets installiert. Also als ganz normale „Webseite“ ohne Rootzugriff.
    Soweit funktioniert diese auch tadellos. Nun wollte ich Talk aktivieren und stehe vor einen für nich gerade nicht lösbaren Problem hinsichtlich des Turnservers.

    Um Talk mit Video und Audi zu nutzen habe ich einen Turnserver auf Basis von Ubuntu installiert (nach Anleitung). Dieser läuft bei mir zu Hause in einer VM. Da ich eine dynamisch IP Adresse habe, nutze ich DynDNS. In meiner Fritzbox habe ich Portweiterleitung eingerichtet.

    Mein Problem ist nun, dass ich nicht weiß, was ich in der turnserver.conf bei realm und servername eintragen muss?

    Habe dort schon testweise die DynDNS Adresse leider jedoch ohne Erfolg. Ich bekomme keine Videoverbindung zusammen.

    Oder kann das sein, dass es mit meiner Konstellation gar nicht funktioniert?
    Jedenfalls bekomme ich in Nexcloud – dort wo der Turnserver eingetragen wird bei der Prüfung immer ein Ausrufezeichen.

    Vielleicht hat jemand einen Tipp für mich.
    Herzlichen Dank
    Peter

    • Jan sagt:

      Hallo Peter,

      also Talk funktioniert ja auch erst einmal ohne eigenen TURN-Server.
      Generell muss aber auch die Leitung eine echt gute Bandbreite haben, wenn man dies zu Hause betreiben will. Die meisten Anschlüsse für Privatpersonen dürften im Upload etwas beschränkt sein für diese Aufgabe.

      Ansonsten hattest du mit realm = Domain-Name schon recht. Dazu müssen die Ports noch geöffnet werden und (in der hier gezeigten Konfiguration) muss ebenfalls ein gültiges SSL-Zertifikat für die Turn-Domain installiert sein.
      Vielleicht ist es aber auch etwas ganz einfaches, nämlich das „secret“, welches du in der NC-Konfiguration noch nicht angegeben hast?

      Gruß,
      Jan

  • Tim sagt:

    Hi,

    wenn ich talk als Admin installieren möchte, wird es mir bei den Apps nicht angezeigt. Woran könnte das denn liegen?

    LG

    • Jan sagt:

      Hi Tim,

      das kann ich leider nicht genau sagen. Sind alle anderen Apps noch aufgelistet?
      Im App Store ist es auch jeden Fall noch zu finden, siehe hier.

      Gruß,
      Jan

      • Tim sagt:

        Hey,

        danke für deine schnelle Antwort und überhaupt für die tollen Anleitungen! Ich lasse nextcloud über den eigenen Ubuntu Server 18.04 laufen.

        die einzigen Apps, die mir angezeigt werden sind:

        Default encryption module
        External storage support
        LDAP user and group backend

        und natürlich die, die ich schon aktiviert habe. Ich wollte Nextcloud auch schon auf die 18er Version updaten, hatte allerdings immer Verbindungsprobleme.
        Ich weiß leider nicht woran es liegen könnte.

        Sonst funktioniert alles auch wunderbar…

        Beste Grüße

      • Tim sagt:

        Wenn ich andere apps aktivieren möchte, bekomme ich die Meldung:

        „The library ldap is not available“

        • Jan sagt:

          Hi Tim,

          ja, ich denke, der App Store hat heute irgendwie Probleme. Ist mir bei einer NC-Instanz auch aufgefallen.
          Von daher einfach mal ein wenig abwarten.

          Gruß,
          Jan

      • Tim sagt:

        Ich lasse Nextcloud über den eigenen Ubuntu Server laufen (18.04). Angezeigt werden mir nur 3 apps:

        Default encryption module
        External storage support
        LDAP user and group backend

  • Kevin sagt:

    Hi Jan,
    muss ich nach dem Umstieg zur Hybrid-Lösung für Zertifikate hier ebenfalls beide (RSA + ECC) angeben und den cipher-list abändern? Meine die Zertifikat-Pfade passen ja dann auch nicht mehr…

    Außerdem stellt sich mir hier die Frage: „realm=sub.meinedomain.de“ (=die subdomain in der Nextcloud mit aufgesetzt ist)
    Muss ich beim aufsetzen von Jitsu als Turn bzw. Stan-Server diese sub.meinedomain.de verwenden oder stun.sub.meinedomain.de oder meet.meinedomain.de? Verstehst du worauf ich hinaus will?

    Gruß,
    Kevin

    • Jan sagt:

      Hi Kevin,

      ja, die Cipher-List sollte auch in der coturn-Config angepasst werden. Diese Liste kann allerdings einfach aus einem nginx vHost kopiert werden.
      Der realm von coturn muss auf die Domain konfiguriert werden, unter der der TURN-Server erreichbar ist (also die Domain, auf die auch die Zertifikate ausgestellt sind). Also in deinem Fall sub.meinedomain.de
      Das ganze muss dann aber auch korrekt in der Jitsi Config hinterlegt werden.

      Gruß,
      Jan

  • Max sagt:

    Hi,

    vielen Dank für deine Anleitung. Da sie mir gut geholfen hat, möchte ich hier für alle die es interessieren mag kurz ergänzen, was ich abweichend auf einem Debian 10 konfiguriert habe:

    1) Der coturn-Benutzer darf nicht auf die Let’s Encrypt-Pfade zugreifen, darum gibt es ein kleines Deploy-Script.
    2) Um möglichst wenig Hinweis-Meldungen im Log zu erzeugen, habe ich die Konfiguration leicht angepasst (lt-cred-mech und no-loopback-peers nicht setzen, listening-ip und cli-password ergänzt). Das cli-password erzeugt man mit „turnadmin -P -p „.

    Konfiguration für die Zertifikate:
    mkdir -p /etc/turnserver
    chown turnserver:turnserver /etc/turnserver
    chmod 750 /etc/turnserver
    openssl dhparam -out /etc/turnserver/dhparams.pem 4096
    cat >/etc/letsencrypt/renewal-hooks/deploy/coturn.sh <<__EOF__
    #!/bin/bash
    cp /etc/letsencrypt/live/meinedomain.de/cert.pem /etc/turnserver
    cp /etc/letsencrypt/live/meinedomain.de/privkey.pem /etc/turnserver
    service coturn restart
    __EOF__
    chmod +x /etc/letsencrypt/renewal-hooks/deploy/coturn.sh
    /etc/letsencrypt/renewal-hooks/deploy/coturn.sh

    Konfiguration in turnserver.conf:
    tls-listening-port=5349
    listening-ip=1.2.3.4
    fingerprint
    use-auth-secret
    static-auth-secret=
    realm=meinedomain.de
    total-quota=100
    bps-capacity=0
    stale-nonce=600
    cert=/etc/turnserver/cert.pem
    pkey=/etc/turnserver/privkey.pem
    cipher-list=“ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384“
    no-multicast-peers
    dh-file=/etc/turnserver/dhparams.pem
    cli-password=$5$EinSalt$EinPasswort
    no-tlsv1
    no-tlsv1_1
    no-stdout-log

    Viele Grüße
    Max

  • Markus sagt:

    Hallo, vielen Dank für die hervorragende Anleitung.
    Ausgehend von

    ist bei den Zeilen
    cert=/etc/letsencrypt/live/meinedomain.de/cert.pem
    pkey=/etc/letsencrypt/live/meindomain.de/privkey.pem
    eine Inkonsistenz hinsichtlich des Ortes der Keys.
    Ist das „live“ einfach zu entfernen oder durch „ecc“ zu ersetzen

    • Jan sagt:

      Hi Markus,

      ja, die Pfade sind anzupassen. Dieses Tutorial entstand noch in der Zeit, zu der ich certbot für die Zertifikate verwendet hatte. Unter acme.sh (meine momentane Empfehlung) können die Zertifikate ja in einem beliebigen Ordner „installiert“ werden. Diese Pfade sind dann auch in der coturn-Config anzugeben.

      Gruß,
      Jan

  • Markus sagt:

    Hallo,
    müsste
    dh-file=/etc/nginx/ssl/dhparams.pem
    nicht
    dh-file=/etc/nginx/dhparams/dhparams.pem
    heißen?

  • Michael sagt:

    Moin Jan,

    habe eben den Server aufgesetzt. Ich musste, da ich die Hybrid-Lösung nutze, mich entscheiden und nehmen:

    cert=/etc/letsencrypt/live/meinedomain.de/rsa/cert.pem
    pkey=/etc/letsencrypt/live/meindomain.de/rsa/key.pem

    Beim Testen des TURN-Servers erhalte ich eine Fehlermeldung:

    Error: No working ICE candidates returned by the TURN server

    Ich kann damit leider nicht so viel anfangen. Vielleicht kannst Du mir weiterhelfen.

    Herzliche Grüße

    • Jan sagt:

      Hi Michael,

      hier würde ich mal kontrollieren, ob der Turn-Server wirklich auf dem korrekten Port läuft.
      Mir ist nämlich aufgefallen, dass sich der Dienst starten lässt, auch wenn z.B. die Zertifikate gar nicht da sind. Dann läuft er aber per default unverschlüsselt und damit auch auf einem anderen Port (auch wenn du die unverschlüsselten Verbindungen in der Konfiguration auskommentiert hast).

      Gruß,
      Jan

      • Harald sagt:

        Hallo Jan

        Ich habe die gleiche Fehlermeldung wie Michael. Ich habe die Ports kontrolliert in der Fritzbox und in der Konfigurationsdatei: 5349
        Den Nextcloud-Server habe ich nach deiner Anleitung (https://decatec.de/home-server/nextcloud-auf-ubuntu-server-18-04-lts-mit-nginx-mariadb-php-lets-encrypt-redis-und-fail2ban/) eingerichtet. Danke dafür übrigens!

        Leider finde ich zu der Fehlermeldung nicht viel. Hast du vielleicht noch eine Idee?

        Gruß Harald

        • Jan sagt:

          Hi Harald,

          wie gesagt: Einfach mal Checken, ob coturn überhaupt auf den entsprechenden Ports lauscht: sudo netstat -tunlp
          Wenn ein anderer Prozess bereits 5349 nutzen sollte, dann kannst du mit coturn auch auf einen ganz anderen Port ausweichen.

          Gruß,
          Jan

          • Michael sagt:

            Hallo Jan,
            gleiches Problem bei mir: coturn lauscht auf den richtigen Ports, Ports sind weitergeleitet, aber trotzdem erhalte ich die Nachricht „No working ICE candidates returned by the TURN server“. Hast Du noch eine Idee dazu?

            LG, Michael

          • Harald sagt:

            Hallo Jan

            Danke für die Antwort. „netstat“ gibt aus, dass der Turn-Server auf 3478 und 3479 lauscht. Habe das in der turnserver.conf angepasst (tls-listening-port=3478) und die Fritzbox angewiesen auf Port 3478 umzuleiten. In der Konfiguration im Webinterface von Nextcloud habe ich meinedomain.de:3478 angegeben und trotzdem die gleiche Fehlermeldung…

          • Jan sagt:

            Hallo Harald & Michael,

            in ufw habt ihr die Ports auch freigeschaltet?
            Als nächstes würde ich mal die coturn-Logs komplett löschen und coturn neu starten. Oftmals wird hier dann in den Logs angezeigt, dass z.B. eine Zertifikats-Datei nicht geladen werden kann. coturn startet aber dennoch, funktioniert aber nicht richtig.

            Gruß,
            Jan

          • Bonny sagt:

            Hi,

            ich hatte auch das Problem. Coturn fällt anscheinend auf den standard Port 3478 zturück, wenn ihm etwas mit den Zertifikaten nicht passt. Bei mir lag es daran, dass die Rechte für die Zertifikate falsch waren. Nach einem „chown -R www-data:www-data /etc/letsencrypt“ und „chmod -R 775 /etc/letsencrypt“ hats dann geklappt und er hat brav den TLS-Listening Port 5349 genutzt.

          • Jan sagt:

            Hi Bonny,

            genau, normalerweise würde man erwarten, dass coturn eine Fehlermeldung auswirft und nicht startet, wenn die TLS-Konfiguration nicht passt. Stattdessen erfolgt ein „heimlicher“ Fallback auf Non-TLS. Das ist durchaus tückisch. Hier also immer checken, auf welchen Ports coturn nach der Konfiguration lauscht und ggf. die Logs kontrollieren.

            Gruß,
            Jan

  • Harald sagt:

    Hallo Jan

    In ufw habe ich die Ports freigeschaltet – jetzt 3478. Ich habe in der turnserver.conf syslog auskommentiert und einen anderen Pfad eingegeben (home/server/log…) Ich habe dort auch mit touch leere log-Dateien angelegt und Ordner und Dateien dem Nutzer turnserver übergeben. Trotzdem schreibt er keine logs, weil: „ERROR: Cannot open log file for writing“…?!

    Gruß Harald

    • Jan sagt:

      Hi Harald,

      wenn du die syslog-Einstellung in der coturn-Config weglässt, dann sollte er doch eigentlich direkt unter /var/log loggen. Ansonsten einfach das Syslog verwenden: coturn neustarten und direkt das Syslog checken, da sollten am Ende Meldungen kommen, wenn irgendwas beim Starten von coturn nicht funktioniert hat.

      Gruß,
      Jan

      • Harald sagt:

        Hi Jan

        Ich hatte zwischenzeitlich das log-Verzeichnis auf r+w für jeden gesetzt und trotzdem konnte coturn nichts darein schreiben…?

        Mit syslog funktioniert es. Ich glaube, ich hatte ganz zu Anfang im syslog nach „error“ gesucht und das dort nicht gefunden, da die Ausgabe wie folgt ist:

        „[UFW BLOCK] IN=eno1 OUT= MAC=01:00:5e:00:00:01:44:4e:6d:e4:99:a1:08:00 SRC=192.168.178.1 DST=224.0.0.1 LEN=36 TOS=0x00 PREC=0xC0 TTL=1 ID=21370 DF PROTO=2“
        SRC ist meine Fritzbox. Danach folgen im syslog weitere ähnliche Einträge, die alle geblockt werden – unter anderem von meinem per SSH verbundenen PC.

        UFW hatte ich nachinstalliert, da ich auf einem Debian Buster unterwegs bin. Dort sind folgende Ports erlaubt:

        22/tcp ALLOW 192.168.178.0/24
        80 ALLOW Anywhere
        443 ALLOW Anywhere
        5349/tcp DENY Anywhere
        5349/udp DENY Anywhere
        3478/udp ALLOW Anywhere
        3478/tcp ALLOW Anywhere
        80 (v6) ALLOW Anywhere (v6)
        443 (v6) ALLOW Anywhere (v6)
        5349/tcp (v6) DENY Anywhere (v6)
        5349/udp (v6) DENY Anywhere (v6)
        3478/udp (v6) ALLOW Anywhere (v6)
        3478/tcp (v6) ALLOW Anywhere (v6)

        In der Fritzbox habe ich für IPv4 von 5349 (Port extern vergeben) auf 3478 (Port an Gerät) weitergeleitet. Bei IPv6 von 3478 auf 3478.

        Da ich ein bisschen ratlos bin, habe ich ein wenig rumprobiert:

        Ein zusätzliches Freigeben von 5349 in ufw bringt natürlich auch nichts…

        Ich habe dann alles nochmal auf den vorgegebenen Port 5349 abgeändert (turnserver.conf, Fritzbox, Nextcloud).

        Die Ipv6-Port-Freigabe habe ich in der Fritzbox deaktiviert.

        Das Ergebnis bleibt immer gleich…

        Gruß Harald

        • Jan sagt:

          Hi Harald,

          um ufw komplett auszuschließen, würde ich das mal komplett deaktivieren („ufw disable“). Sonst sind einfach zu viele Variablen im Spiel.

          Gruß,
          Jan

          • Harald sagt:

            Hallo Jan

            Habe ufw auf allow all gestellt. Danach gab es keine Fehlermeldungen mehr im syslog. Die Fehlermeldung in der Nextcloud bleibt aber…

            Gruß Harald

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.