Turn Server coturn Installieren

[Lockslay]

Hallo zusammen,

ich brauche für meine Videokonferenzen unter Matrix einen eigenen Turn Server.
Leider hat sich das als schwieriger herausgestellt als ich es mir vorgestellt habe.


Ich habe in einer VM, lokal ein Debian laufen und möchte mit dyndns einen eigenen turn Server aufsetzte.

apt-get install coturn
habe ich Installiert:

nano /etc/turnserver.conf:

Code: Alles auswählen

listening-port=3478
relay-ip= lokale IP
external-ip= IP ISP 
realm=turn.Namedyndns.org
server-name=turn.Namedyndns.org

ls-cred-mech user=User:Password

Der port 3478 ist als TCP und UDP weitergeleitet.
Ich wollte meinen Turn Server testen:
https://webrtc.github.io/samples/src/co ... ickle-ice/

Nur es kommt die Meldung:

URI scheme turnname.dyndns.org is not valid

Kann mir bei der Einrichtung bitte einer helfen?

[mat6937]

Nur es kommt die Meldung:

URI scheme turnname.dyndns.org is not valid

Kann mir bei der Einrichtung bitte einer helfen?

Versuch mal mit einem SSL-Zertifikat, wie in dieser Anleitung: https://gabrieltanner.org/blog/turn-server

beschrieben.

[Lockslay]

Hallo und Danke für den hilfreichen Link.
Der ist sicherlich wichtig und richtig.
Er steht aber unter Optional.

Ich habe den Server leider noch nicht zum Laufen gebracht und glaube, es liegt an der /etc/turnserver.conf

Code: Alles auswählen

listening-port=3478
relay-ip= lokale IP  ??
external-ip= IP ISP  ??
realm=turn.Namedyndns.org
server-name=turn.Namedyndns.org

ls-cred-mech user=User:Password

Kann mir bitte einer was zu den IP Eingaben sagen ?

Danke!

[jph]

möchte mit dyndns einen eigenen turn Server aufsetzte.

Viel Glück: „We do not recommend running a TURN server behind NAT, and are not aware of anyone doing so successfully.“ https://github.com/matrix-org/synapse/b ... n-howto.md

[Lockslay]

Hallo

We do not recommend running a TURN server behind NAT, and are not aware of anyone doing so successfully.
Und nun, gibt es keine freien Turn Server die man verwenden kann?

Habe hier mal mit gearbeitet
https://gist.github.com/sagivo/3a4b2f2c ... 1f59ac6c6b
Das ist aber wie in einer Lotterie, mal ging es und mal nicht.

[Ano]

Hallo!

Die Portfreigaben im Router hast du gemacht?

Bei mir funktioniert diese turnserver.conf (41348).
Die Ports habe ich zumindest für SSL angepasst, da noch ein weiterer Dienst 443 nutzt.

Den ip-relay-Eintrag habe/brauche ich nicht.

Damit laufe die Tests auf https://webrtc.github.io/samples/src/co ... ickle-ice/ durch.

Zum Beispiel in Nextcloud Hub 21 funktioniert der SSL-Test (turns) nicht. Der turn-Server wird jedoch auch hier als funktional angezeigt.

Viel Glück!

[jph]

We do not recommend running a TURN server behind NAT, and are not aware of anyone doing so successfully.
Und nun, gibt es keine freien Turn Server die man verwenden kann?

Der Hinweis ist m.E. folgendermaßen zu verstehen: die Anleitung ist für einen „offen“ im Internet stehenden Server gedacht, also bspw. für einen Rootserver, den du irgendwo anmietest. Nicht aber dafür, das auf einem Raspberry Pi 4 hinter dem heimischen Router zum Laufen zu bringen. (Was irgendwie schade ist, weil man einen Matrix-Synapse problemlos dergestalt betreiben kann, sofern man nicht zu viele User hat und sich nach Möglichkeit aus den ganz großen Räumen raus hält.)

[Ano]

übrigens noch ein Hinweis zu Trickle ICE:

If you test a STUN server, it works if you can gather a candidate with type "srflx". If you test a TURN server, it works if you can gather a candidate with type "relay".

- mit user:password zeigte er auch "srflx" an - jetzt mit "static-auth-secret" nur noch "host"

- du kannst aber auch selber testen

- mit "static-auth-secret" kannst du hier testen - keine Ahnung wie sicher es ist, dort dein Auth-Secret hochzuladen!?

[am2]

Ich wollte einen neuen Thread eröffnen, aber hier passt es auch, denke ich. Falls nicht - sorry und bitte verschieben...

Ich habe folgendes Szenario:
Ein Server mit Domain und Letsencrypt-Zertifikaten, läuft mit Debian 10 und ISPConfig (alles soweit ok).
Auf dem Server laufen u.a. Postgresql, matrix-synapse und coturn, alles aus den buster-Repos, ebenfalls soweit ok.

Mit soweit ok meine ich, dass der Matrix-Chat funktioniert, SSL bzw. TLS einwandfrei funktioniert und die Telefonie mit Hilfe von coturn klappt auch, aber...
Im Log sehe ich laufend solche Einträge:

Code: Alles auswählen

369: session 002000000000000028: TLS/TCP socket disconnected: client_ip:57723
369: session 003000000000000021: closed (2nd stage), user <@ich:mein-matrix.doimain.tld> realm <mein-turn.domain.tld> origin <>, local server_ip:443, remote client_ip:53584, reason: TLS/TCP socket buffer operation error (callback)

Dieses Problem existiert lt. Github schon seit 2017 und scheint noch nicht aus der Welt zu sein. Ich wollte fragen, ob das jemand netzwerktechnisch (z.B. Wireshark o.a.) untersucht hat. Kann man die Verschlüsselung der Anrufe damit vergessen oder bleiben sie dennoch verschlüsselt. Wenn ich der Sache mit Wireshark auf den Grund gehe, sehe ich eine Mischung aus TLSv1.2, STUN und TCP-Paketen und werde nicht so richtig schlau daraus.

[HolgerWeiss]

We do not recommend running a TURN server behind NAT, and are not aware of anyone doing so successfully.
Und nun, gibt es keine freien Turn Server die man verwenden kann?

Der Hinweis ist m.E. folgendermaßen zu verstehen: die Anleitung ist für einen „offen“ im Internet stehenden Server gedacht, also bspw. für einen Rootserver, den du irgendwo anmietest. Nicht aber dafür, das auf einem Raspberry Pi 4 hinter dem heimischen Router zum Laufen zu bringen. (Was irgendwie schade ist, weil man einen Matrix-Synapse problemlos dergestalt betreiben kann, sofern man nicht zu viele User hat und sich nach Möglichkeit aus den ganz großen Räumen raus hält.)

Ja, der Hinweis ist sicher so gemeint, und ich kann ihn auch nachvollziehen: TURN ist nicht wirklich dafür gedacht, hinter einem NAT-Router mit dynamischer IP-Adresse betrieben zu werden. Es braucht eine gewisse Bandbreite und möglichst geringe Latenz, das Forwarding von allerlei (UDP-)Ports muss passen, und der TURN-Server muss zwingend seine öffentliche IP-Adresse kennen. Wenn man diese Dinge auch zu Hause hinbekommt, funktioniert das aber durchaus. Ich maintaine selbst einen TURN-Server und habe im Repository ein Beispiel-Skript zur Aktualisierung der IP-Adresse, FWIW.

[HolgerWeiss]

Mit soweit ok meine ich, dass der Matrix-Chat funktioniert, SSL bzw. TLS einwandfrei funktioniert und die Telefonie mit Hilfe von coturn klappt auch, aber...
Im Log sehe ich laufend solche Einträge:

Code: Alles auswählen

369: session 002000000000000028: TLS/TCP socket disconnected: client_ip:57723
369: session 003000000000000021: closed (2nd stage), user <@ich:mein-matrix.doimain.tld> realm <mein-turn.domain.tld> origin <>, local server_ip:443, remote client_ip:53584, reason: TLS/TCP socket buffer operation error (callback)

Dieses Problem existiert lt. Github schon seit 2017 und scheint noch nicht aus der Welt zu sein. Ich wollte fragen, ob das jemand netzwerktechnisch (z.B. Wireshark o.a.) untersucht hat. Kann man die Verschlüsselung der Anrufe damit vergessen oder bleiben sie dennoch verschlüsselt. Wenn ich der Sache mit Wireshark auf den Grund gehe, sehe ich eine Mischung aus TLSv1.2, STUN und TCP-Paketen und werde nicht so richtig schlau daraus.

Speziell zu Coturn kann ich nicht viel sagen, (in eturnal versuche ich, klarere Log-Meldungen zu produzieren ), aber:

1. Die Meldung kann sicherlich kommen, wenn der Client den Aufbau der TLS-Verbindung abbricht, weil er mit dem Zertifikat unglücklich ist. Da müsste man schauen, ob der Client Debug-Logs produzieren kann, aus denen das hervorgeht.
2. Ich kann mir vorstellen, dass eine solche Meldung auch unter anderen Umständen kommen kann. TURN-Clients beenden die Session manchmal nicht sauber. Gab's vorherige Einträge zu derselben Session-ID?
3. Anrufe sind (mittels DTLS-SRTP) Ende-zu-Ende-verschlüsselt, so dass TLS keinen Sicherheitsgewinn bringt. In aller Regel werden Clients UDP bevorzugen, um Latenzen zu minimieren. TURN via TLS (auf Port 443) anzubieten kann aber ggf. als Fallback für Clients hinter restriktiven Firewalls (die nur vermeintlichen HTTPS-Traffic erlauben) sinnvoll sein. Im Übrigen ist, auch wenn die Verbindung zwischen Deinem Client und dem TURN-Server TLS-verschlüsselt ist, die zwischen Server und Gegenüber immer unverschlüsseltes UDP (habe ich hier versucht, kurz zu erläutern).

[am2]

Das Problem ist behoben. In der turnserver.conf musste ich gaaanz unten diese Zeilen aktivieren:

Code: Alles auswählen

no-sslv2
no-sslv3
no-tlsv1
no-tlsv1_1
no-tlsv1_2

Somit läuft nur noch TLS1.3. Ich habe lange gesucht und bin dann auf github auf das gleiche Problem gestoßen. Der Mann hatte exakt die gleichen Logzeilen (mit dem buffer-error). Irgendwann kam mir die Idee nur noch TLS1.3 für Coturn zu erlauben und siehe da - es läuft. Er hat es dann auch gemacht, hat sich bei mir bedankt und die Issue wurde geschlossen.