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.
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:
1 | apt-get update && apt-get upgrade -V |
Anschließend kann coturn auch schon installiert werden, da es bereits Teil der Ubuntu-Paketquellen ist:
1 | 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:
1 | 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:
1 | TURNSERVER_ENABLED=1 |
Als nächstes werden die Einstellungen von coturn bearbeitet.
Diese befinden sich in folgender Datei:
1 | 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
- 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:DHE-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.
1 | 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:
1 2 | 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
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:
ownCloud auf Ubuntu Server mit nginx, MariaDB und PHP ownCloud 9 auf Ubuntu Server 16.04 LTS mit nginx, MariaDB, PHP 7 und Let’s Encrypt 
Nextcloud auf Ubuntu Server mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2banNextcloud: Online-Office mit ONLYOFFICE (mit eigener Subdomain) phpMyAdmin neben Nextcloud installieren (nginx)
Kommentare: 37
Schreibe einen Kommentar
IT-Services
Beliebt
-
Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban -
Nextcloud: Web-Mail mit RainLoop -
Nextcloud: Online-Office mit ONLYOFFICE (mit eigener Subdomain) -
Let’s Encrypt Zertifikate mit acme.sh und nginx -
Nextcloud Talk mit eigenem TURN-Server (coturn) -
Nextcloud – Tipps & Tricks für Admins (und Benutzer) -
Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript -
Nextcloud: Updates richtig durchführen -
Linux: Einfach E-Mails senden mit sSMTP -
Ubuntu Server 18.04 LTS als Hyper-V Gastsystem installieren und optimal einrichten
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,
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,
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