Nextcloud Talk mit eigenem TURN-Server (coturn)
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)
- 14.07.2021:
- Anpassungen der Pfade der SSL-Zertifikats-Dateien, damit diese zu den restlichen Artikeln passen.
- Anpassen der Rechte für den privaten SSL-Key, damit coturn diesen lesen kann.
- 08.01.2021:
- Optionen lt-cred-mech und no-loopback-peers aus der coturn-Konfiguration entfernt.
- 12.04.2020:
- Hinweis zu den Einschränkungen von Nextcloud Talk hinzugefügt.
- 03.02.2020:
- Cipher Suite DHE-RSA-AES256-GCM-SHA384 entfernt.
Inhalt
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:
apt-get update && apt-get upgrade -V
Anschließend kann coturn auch schon installiert werden, da es bereits Teil der Ubuntu-Paketquellen ist:
apt-get install coturn
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:
nano /etc/default/coturn
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:
TURNSERVER_ENABLED=1
Als nächstes werden die Einstellungen von coturn bearbeitet.
Diese befinden sich in folgender Datei:
nano /etc/turnserver.conf
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
- use-auth-secret
- static-auth-secret=<secret>
- realm=meinedomain.de
- total-quota=100
- bps-capacity=0
- stale-nonce=600
- cert=/etc/letsencrypt/meinedomain.de/rsa/cert.pem
- pkey=/etc/letsencrypt/meindomain.de/rsa/key.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/nginx/dhparams/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 diesen Anpassungen sollte noch sicher gestellt sein, dass der (private) SSL-Key die richtigen Berechtigungen hat, damit coturn diesen auch lesen kann:
chmod 644 /etc/letsencrypt/meinedomain.de/rsa/key.pemAm Schluss wird coturn neu gestartet, damit die Änderungen übernommen werden.
service coturn restart
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)
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:
ufw allow 5349/tcp ufw allow 5349/udp
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
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
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
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
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:
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
- Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban
- Ubuntu Server 18.04 LTS als Hyper-V Gastsystem installieren und optimal einrichten
- Jitsi Meet: Videokonferenz-System unter Ubuntu Server mit nginx
Links
- Nextcloud Homepage (englisch)
- Übersichtsseite Nextcloud Talk (englisch)
- Nextcloud Talk im Nextcloud App Store
- WebRTC (Wikipedia)
- Peer-to-Peer (Wikipedia)
- Netzwerkadressübersetzung (Wikipedia)
- Session Traversal Utilities for NAT (Wikipedia)
- Traversal Using Relays around NAT (Wikipedia, englisch)
- coturn (GitHub)
Ähnliche Artikel:
Nextcloud: Online-Office mit ONLYOFFICE (mit eigener Subdomain) phpMyAdmin neben Nextcloud installieren (nginx)
IT-Services
Beliebt
-
Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban - Update-Historie
- Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript
- Nextcloud: Direkter Zugriff auf Dateien über das Dateisystem
- Nextcloud: Updates richtig durchführen
- Nextcloud – Tipps & Tricks für Admins (und Benutzer)
- Matrix Synapse auf Ubuntu Server 20.04 LTS mit nginx, PostgreSQL und Let’s Encrypt
- Nextcloud 21: High Performance Backend für Dateien
- Linux: Einfach E-Mails versenden mit msmtp
- DynDNS: Home-Server mit einer FritzBox mit IPv4 und IPv6 (Dual-Stack) betreiben
Ich danke dir! ;)
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)
Wie immer eine sehr gute Anleitung und prima Erklärungen!
Vielen Dank für deine Mühe!
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
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
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!!
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
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!
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
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 ?
Hi Gunnar,
ich glaube, dass dieses Feature zwar geplant, aber noch nicht umgesetzt ist.
Gruß,
Jan
Hallo Jan,
was Du vielleicht schon weißt, das geht über den Umweg einer Nextcloud Freigabe.
LG,
Karsten
Hi Karsten,
ja, dennoch finde ich diese Lösung weder einfach, noch besonders praktikabel. Hier wäre ein direktes Aufnehmen/Teilen sehr sinnvoll (wie man es von den ganzen anderen Messager-Apps gewohnt ist).
Gruß,
Jan
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 :)
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
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
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.
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
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!
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..
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Tolle Anleitung.
Könnte man das auch auf einer Synology DS218+ anwenden ?
Vielleicht sogar in einem Docker Container ?
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
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
Hi,
dann einfach mal ausprobieren. Wenn es nicht klappen sollte, dann ist der Docker-Container ja wieder schnell entfernt.
Gruß,
Jan
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.
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
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…
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
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
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
Hi,
wenn ich talk als Admin installieren möchte, wird es mir bei den Apps nicht angezeigt. Woran könnte das denn liegen?
LG
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
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
Wenn ich andere apps aktivieren möchte, bekomme ich die Meldung:
„The library ldap is not available“
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
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
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
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
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
Hallo Max,
vielen Dank für die Hinweise, ist vielleicht auch für andere mit Debian interessant.
Gruß,
Jan
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
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
Hallo,
müsste
dh-file=/etc/nginx/ssl/dhparams.pem
nicht
dh-file=/etc/nginx/dhparams/dhparams.pem
heißen?
Hi Markus,
das ist wie mit den SSL-Zertifikaten selbst: Es kommt drauf an, wo du diese Datei auf der Platte erzeugt hast. Wenn diese in einem anderen Ordner liegt, dann ist dieser hier anzugeben, korrekt.
Gruß,
Jan
Danke!
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
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
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
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
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
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…
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
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.
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
Hey,
nur als Rückmeldung, Bonnys Tipp mit den Besitzrechte und Berechtigungen für www-data an den Zertifikatsordnern /etc/letsencrypt/ waren auch bei mir erfolgreich.
Frage: Hat der Benutzer letsencrypt dann noch genügend Berechtigungen an den Ordnern für die Erneuerung der Zertifikate?
Danke an Jan und an die vielen Leser*innen!
Hi Amelia,
ja, der User letsencrypt sollte hier noch die entsprechenden Rechte haben. Am besten mal die Neu-Generierung der Zertifikate abwarten. Das einzige, was hier passieren kann, ist, dass acme.sh hier die Besitzrechte eigenständig ändert. Sollte aber eigentlich nicht passieren.
Gruß,
Jan
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
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
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
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
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
Hallo,
also ich habe den corutn Server nach Anleitung aufgesetzt und alles funktionierte soweit, auch der Test in den Einstellungen der Talk App mit der Domain:Port war soweit erfolgreich. Allerdings funktionieren keine Anrufe (Auch nicht im Heimnetz), nur der Nachrichten Chat funktioniert. Der funktioniert allerdings auch, wenn ich den coturn Server komplett entferne.
Leider finde ich nirgend log Dateien zu coturn/turn. Weder im syslog, noch bei nginx noch gibt es einen coturn Ordner.
An was könnte das liegen?
MfG
Amelia
Hi Amelia,
in der turnserver.conf kannst du das Logging aktivieren (Variable „log-file“ bzw. „syslog“). Damit sollte dann auch was geloggt werden.
Am besten auch mal mit
netstat -tuplnchecken, ob coturn auf dem konfigurierten Port läuft. Wenn nicht, dann ist vermutlich die TLS-Konfiguration fehlerhaft (z.B. wenn er die Zertifikate nicht finden kann).Gruß,
Jan
Hallo,
das Logging ist aktiviert, ich habe jetzt eine Log Datei gefunden in /var/tmp/…
Inhalt:
root@server:/var/tmp/systemd-private-f698671a9c1e4382ae0adb93f1ccfe99-coturn.service-h5fz1f/tmp# tail turn_10684_2020-09-29.log
0: log file opened: /var/tmp/turn_10684_2020-09-29.log
0: 0 bytes per second allowed, combined server capacity
coturn lauscht auf den richtigen Port, es tauchen aber auch die Standard Ports 3478 auf. Und in den App Einstellungen werden Stun und Turn Server erfolgreich getestet.
Ich hatte jetzt coturn nochmal neu installiert, genau nach Anleitung, leider mit dem gleichen Ergebnis…
Hi Amelia,
soll er echt auf Port 3478 lauschen? Das ist normalerweise der Port ohne TLS, hier nimmt man oft den 5349. Ich frage nach, da er bei einer falschen Konfiguration der Zertifikate ohne Fehlermeldung einfach auf unverschlüsselte Verbindungen auf Port 3478 umsteigt.
Ansonsten sagt mir die Meldung „0 bytes per second allowed, combined server capacity“ leider auch nichts. Sind wirklich alle Werte in der turnserver.conf genau so angegeben wie im Artikel?
Gruß,
Jan
Hallo,
also er lauscht schon auf 5349 denke ich. Inzwischen hat auch die Verbindung einmal funktioniert, allerdings nur zwischen Browser und Android-App, zwischen zwei Android Geräten überhaupt nicht. Und man muss manuell auf beitreten gehen, es kommt keine Benachrichtigung zum Anruf/VideoCall.
turnserver.conf ist alles so wie in der Anleitung…
Pfad zu den Zertifikaten ist angepasst, das stimmt auch und Domain (realm) ist die gleiche wie die Nextcloud.
Leider habe ich keine Idee, wo ich noch Hinweise zum Problem finden könnte…
Hallo,
ich bin ratlos, aber in positiver Hinsicht. Hatte ein paar andere Sachen auf meinem Server gemacht und jetzt nochmal Talk ausprobiert und es ging. Auch mit zwei Mobilgeräten jeweils im Mobilnetz.
Vielleicht hat ein reboot geholfen?
An der App ist nur komisch, dass man keine Benachrichtigungen bekommt, da muss ich noch mal schauen ob da was möglich ist.
Aber vielen Dank für Deine Anleitung und Deine Hilfe Jan!!!
LG
Amelia
Hi Amelia,
super, dass es nun bei dir funktioniert. Danke für die positive Rückmeldung!
Gruß,
Jan