Eigener TURN Server für Jitsi Meet bereitstellen

Letzte Aktualisierung am 20.07.2022, 14:07:40 Uhr

Ein eigener TURN Server macht Sinn, wenn man diese Leistung nicht über einen Dienstleister beziehen möchte. Sozusagen die wichtige Infrastruktur selbst betreiben und unter Kontrolle haben möchte. Es gibt natürlich neben den kostenpflichtigen Service auf diverse Server von T-Online, HostEurope, 1und1, Easybell, etc… die kostenlos zur Verfügung gestellt werden. In wie weit diese verfügbar, ausgelastet und performant sind, ist vemutlich in diesen Wochen von der Tageszeit abhängig.

In diesem Fall soll der TURN-Server in Verbindung mit Jitsi Meet betrieben werden. Dazu habe ich bereits diesen Beitrag geschrieben, welcher als Basis für diesen Artikel gilt.

Die Basis ist für den Service ist eine weitere virtuelle Maschine mit 2vCPU, 2GB RAM und 40GB (CPX11) Festplattenspeicherplatz. Die Netzwerkanbindung ist 1000Mbit/s und der Server hat eine IPv4 und IPv6 Adresse. Als Betriebssystem  ist Ubuntu Server 20.04 LTS vorinstalliert.

Die A und PTR-Einträge habe ich in der DNS-Zone angelegt. In meinem Beispiel lautet der FQDN: turn.meet.wydler.eu. Den Namen müsst ihr selbstverständlich bei eurer Installation anpassen. Dies bezieht sich natürlich auch die Dateinamen, in den Änderungen vorgenommen werden.

Installation von Coturn

Definition des DNS-Namen, auf den der TURN Server hören soll.

export FqdnTurnServer=turn.meet.wydler.eu
echo $FqdnTurnServer

Installation der Anwendung.

apt update && apt upgrade -y && apt autoremove -y && apt autoclean
apt install vim htop sudo coturn -y

Zuerst muss der TURN-Server aktiviert werden:

cp /etc/default/coturn /etc/default/coturn.$(date '+%Y-%m-%d_%H-%M-%S')
cat << \EOF >> /etc/default/coturn
TURNSERVER_ENABLED=1
EOF

Abrufen von Let’s Encrypt Zertifikat

Zuerst muss das Tool certbot auf dem Server installieren, falls noch nicht geschehen.

apt install certbot -y

Abrufen des Zertifikats.

certbot certonly --standalone --noninteractive --rsa-key-size 4096 -d $FqdnTurnServer --agree-tos -m hostmaster@domain.de

Damit Coturn die bereitgestellten Zertifikate von Let’s Encrypt nutzen kann, müssen die Dateien noch kopiert werden.

mkdir -p /etc/coturn/certs/


cp -Lr /etc/letsencrypt/live/$FqdnTurnServer/fullchain.pem /etc/coturn/certs/$FqdnTurnServer.fullchain.pem
cp -Lr /etc/letsencrypt/live/$FqdnTurnServer/privkey.pem /etc/coturn/certs/$FqdnTurnServer.privkey.pem

chown -R turnserver:turnserver /etc/coturn/
chmod -R 755 /etc/coturn/
chmod 644 /etc/coturn/certs/$FqdnTurnServer.fullchain.pem
chmod 600 /etc/coturn/certs/$FqdnTurnServer.privkey.pem

Wie bekannt ist, sind Zertifikate welche von Let’s Encrypt ausgestellt worden sind, immer nur 90 Tage gültig. Durch die Verwendung von certbot erfolgt die Erneuerung ohne weitere manuelle Eingriffe. Damit Coturn dies auch mitbekommt ist ein sogenannter Hook notwendig. Dabei handelt es sich um Interaktionen die nach erfolgreichem Abruf des neuen Zertifikats ausgeführt werden sollen.

cat << \EOF > /etc/letsencrypt/renewal-hooks/deploy/coturn-certbot-deploy.sh
#!/bin/sh
 
set -e
 
for domain in $RENEWED_DOMAINS; do
        case $domain in
        turn.meet.wydler.eu)
                daemon_cert_root=/etc/coturn/certs
 
                # Make sure the certificate and private key files are
                # never world readable, even just for an instant while
                # we're copying them into daemon_cert_root.
                umask 077
 
                cp "$RENEWED_LINEAGE/fullchain.pem" "$daemon_cert_root/$domain.fullchain.pem"
                cp "$RENEWED_LINEAGE/privkey.pem" "$daemon_cert_root/$domain.privkey.pem"
 
                # Apply the proper file ownership and permissions for
                # the daemon to read its certificate and key.
                chown turnserver "$daemon_cert_root/$domain.fullchain.pem" \
                        "$daemon_cert_root/$domain.privkey.pem"
                chmod 400 "$daemon_cert_root/$domain.fullchain.pem" \
                        "$daemon_cert_root/$domain.privkey.pem"
 
                service coturn restart
                ;;
        esac
done
EOF

Das Skript stammt von Servervault. In Zeile 7 bitte den DNS-Namen anpassen.

Damit die Datei auch ausfühbar ist, muss das entsprechende Attribut gesetzt werden.

chmod 700 /etc/letsencrypt/renewal-hooks/deploy/coturn-certbot-deploy.sh

Konfiguration von Coturn

Die Original Konfiguration sichere ich wie immer vorher weg.

mv /etc/turnserver.conf /etc/turnserver.conf.$(date '+%Y-%m-%d_%H-%M-%S')

Der Service soll zu dem seine Protokolle in einen separaten Ordner ablegen, damit die Übersicht gewahrt wird.

mkdir -p /var/log/coturn/
chown -R turnserver:turnserver /var/log/coturn/

Es muss vorweg noch ein stärkerer DHE-Parameter erzeugt werden. Das kann ein bisschen Zeit in Anspruch nehmen. Zeit für eine Tasse Tee. 😉

openssl dhparam -out /etc/coturn/certs/dhparam4096.pem 4096

Nachstehend eine vollständige Musterkonfiguration, die bei meinen Tests problemlos funktioniert hat.

cat << EOF > /etc/turnserver.conf
# Listener IP address of relay server. Multiple listeners can be specified.
external-ip=116.203.191.22
external-ip=2a01:4f8:c0c:1c8b::1
 
# TURN listener port for UDP and TCP (Default: 3478).
listening-port=443
 
# TURN listener port for TLS (Default: 5349).
tls-listening-port=443
 
# The default realm to be used for the users when no explicit origin/realm relationship was found in the database. Must be used with long-term
# credentials mechanism or with TURN REST API.
realm=${FqdnTurnServer}
 
# Certificate file.
cert=/etc/coturn/certs/${FqdnTurnServer}.fullchain.pem
 
# Private key file.
pkey=/etc/coturn/certs/${FqdnTurnServer}.privkey.pem
 
#Do not allow an TLS/DTLS version of protocol
no-tlsv1
no-tlsv1_1
 
# Allowed OpenSSL cipher list for TLS/DTLS connections.
cipher-list="ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA"
 
# Use custom DH TLS key, stored in PEM format in the file.
dh-file=/etc/coturn/certs/dhparam4096.pem
 
# Uncomment to use long-term credential mechanism.
# lt-cred-mech
 
# This allows TURN credentials to be accounted for a specific user id.
use-auth-secret
 
# 'Static' authentication secret value (a string) for TURN REST API only.
static-auth-secret=replace-this-secret
 
# Flag that can be used to disallow peers on the loopback addresses (127.x.x.x and ::1).
no-loopback-peers
 
# Flag that can be used to disallow peers on well-known broadcast addresses (224.0.0.0 and above, and FFXX:*).
no-multicast-peers
 
# Uncomment to use fingerprints in the TURN messages.
fingerprint
 
# Total allocation quota.
total-quota=50
 
# Set this option to limit the nonce lifetime.
# It defaults to 600 secs (10 min) if no value is provided. After that delay,
# the client will get 438 error and will have to re-authenticate itself.
stale-nonce=600
 
# Maximum server capacity.
# Total bytes-per-second bandwidth the TURN server is allowed to allocate
bps-capacity=0
 
# Flag to prevent stdout log messages.
#no-stdout-log
 
# Uncomment to run TURN server in 'normal' 'moderate' verbose mode.
verbose
 
# Option to set the log file name.
log-file=/var/log/coturn/coturn.log
 
# User name to run the process.
#proc-user=turnserver
 
# Group name to run the process.
#proc-group=turnserver
 
EOF

Die beiden Platzhalter für die Parameter ’static-auth-secre‘ und ‚user‘ werden nun durch Zufallspasswörter ersetzt. Dazu nehme ich OpenSSL als technische Hilfe zur Hand.

sed -i "s/replace-this-secret/$(openssl rand -hex 32)/" /etc/turnserver.conf

Anpassung des systemd für die Bindung von Coturn auf eine Port < 1024.

cp /lib/systemd/system/coturn.service /lib/systemd/system/coturn.service.orginal
sed -i -e 18i"AmbientCapabilities=CAP_NET_BIND_SERVICE" /lib/systemd/system/coturn.service

systemctl daemon-reload

Vor dem Test der Konfiguration nicht vergessen, den Service neu zu starten.

service coturn restart
service coturn status

Testen der Konfiguration

Jeder Konfiguration muss selbstverständlich auch ausprobiert werden. Dazu greife ich auf die  Trickle ICE (WebRTC) zurück.

Die vorhandenen Einträge entfernen. Anschließend die Zugangsdaten für den eigenen Server hinzufügen.

Den TURN username und TURN password muss mit folgendem Befehl auf dem TURN-Server ausgelesen werden.

secret=$(awk -F "=" '/static-auth-secret/ {print $2}' /etc/turnserver.conf) && time=$(date +%s) && expiry=86400 && \
username=$(( $time + $expiry )) && echo username:$username && \
echo password : $(echo -n $username | openssl dgst -binary -sha1 -hmac $secret | openssl base64)

Als Ausgabe wird ein Benutzername und Passwort ausgegeben. Die Zugangsdaten sind für 24 Stunden (=86400 Sekunden) gültig. Sind die Angaben vollständig über „Add Server“ die Angaben übernehmen.

Der Test wird mit „Gather candidates“ gestartet. Im besten Fall sieht das Resultat so aus.

Wichtig ist, dass in der letzten Zeile, in der Splate „Priority“das Wort „Done“ steht. Anderenfalls war der Test nicht erfolgreich.

Anpassen der Jitsi Meet Konfiguration

Ist der TURN-Server einsatzbereit, muss dieser Jitsi Meet natürlich noch ‚bekannt‘ gemacht werden.

Zuerst lasse ich nochmals auf Kommandozeile die beiden Passwörter aus der Coturn Konfiguration ausgeben. Somit können diese Copy & Paste wendet werden. Die Platzhalter in den nachstehenden Konfigurationen dazu heißen <replace-this-password> und <replace-this-secret>.

awk -F "=" '/static-auth-secret/ {print $2}' /etc/turnserver.conf

Nachfolgende Schritte sind auf dem Server auszuführen, auf dem Jitsi Meet installiert ist.

Definition des DNS-Namen, unter dem die Jitsi Installation erreichbar ist. Somit sind in der Regel keine Anpassungen an den weiteren Befehlen notwendig.

export FqdnJitsiServer=meet.wydler.eu
echo $FqdnJitsiServer

export FqdnTurnServer=turn.meet.wydler.eu
echo $FqdnTurnServer

Anpassungen an Jitsi Meet.

cp /etc/jitsi/meet/$FqdnJitsiServer-config.js /etc/jitsi/meet/$FqdnJitsiServer-config.js.$(date '+%Y-%m-%d_%H-%M-%S')

sed -i -e 482c"\        enabled: false," /etc/jitsi/meet/$FqdnJitsiServer-config.js
sed -i -e 488c"\            { urls: 'stun:$FqdnTurnServer:443' }," /etc/jitsi/meet/$FqdnJitsiServer-config.js
sed -i -e 497c"\        iceTransportPolicy: 'relay'," /etc/jitsi/meet/$FqdnJitsiServer-config.js

Anpassungen am XMPP Server Prosody.

cp /etc/prosody/conf.avail/$FqdnJitsiServer.cfg.lua /etc/prosody/conf.avail/$FqdnJitsiServer.cfg.lua.$(date '+%Y-%m-%d_%H-%M-%S')

sed -i -e 6c"turncredentials_secret = \"<replace-this-secret>\";" /etc/prosody/conf.avail/$FqdnJitsiServer.cfg.lua
sed -i -e 8c"\  { type = \"stun\", host = \"$FqdnTurnServer\", port = \"443\" }," /etc/prosody/conf.avail/$FqdnJitsiServer.cfg.lua
sed -i -e 9c"\  { type = \"turn\", host = \"$FqdnTurnServer\", port = \"443\", transport = \"udp\" }," /etc/prosody/conf.avail/$FqdnJitsiServer.cfg.lua
sed -i -e 10c"\  { type = \"turns\", host = \"$FqdnTurnServer\", port = \"443\", transport = \"tcp\" }" /etc/prosody/conf.avail/$FqdnJitsiServer.cfg.lua

Nicht vergessen beim zweiten Befehl den Ausdruck <replace-this-secret> durch das geheime Passwort des Turnservers zu ersetzen.

cp /etc/jitsi/videobridge/sip-communicator.properties /etc/jitsi/videobridge/sip-communicator.properties.$(date '+%Y-%m-%d_%H-%M-%S')
sed -i -e 2c"org.ice4j.ice.harvest.STUN_MAPPING_HARVESTER_ADDRESSES=$FqdnTurnServer:443" /etc/jitsi/videobridge/sip-communicator.properties

Zu guter Letzt müssen die betroffenen Services neu gestartet werden, damit die Änderungen wirksam werden.

service prosody restart
service jicofo restart
service jitsi-videobridge2 restart

Nachdem Neustart wird im Protokoll des TURN Service folgende Einträge geschrieben.

tail -f /var/log/coturn/coturn_2020-04-18.log

482: handle_udp_packet: New UDP endpoint: local addr 45.12.48.z:443, remote addr 45.12.48.z:58373
482: session 000000000000000001: realm <turn.meet.wydler.eu> user <>: incoming packet BINDING processed, success

Das ist schon einmal die halbe Miete. Um die Funktionalität zu prüfen, muss ein Jitsi Konferenz mit zwei Teilnehmern ausgebaut werden. Sobald die Verbindung steht

114: IPv4. tcp or tls connected to: 37.201.4.z:23881
114: session 000000000000000003: realm <turn.meet.wydler.eu> user <>: incoming packet message processed, error 401: Unauthorized
114: IPv4. Local relay addr: 116.203.191.z:11411
114: session 000000000000000003: new, realm=<turn.meet.wydler.eu>, username=<1587063894>, lifetime=3600, cipher=ECDHE-RSA-AES256-GCM-SHA384, method=TLSv1.2
114: session 000000000000000003: realm <turn.meet.wydler.eu> user <1587063894>: incoming packet ALLOCATE processed, success
114: session 000000000000000003: peer 116.203.40.y lifetime updated: 300
114: session 000000000000000003: realm <turn.meet.wydler.eu> user <1587063894>: incoming packet CREATE_PERMISSION processed, success
115: IPv4. tcp or tls connected to: 109.41.195.z:6046
115: session 001000000000000001: TLS/TCP socket disconnected: 109.41.195.z:6046
115: session 001000000000000001: closed (2nd stage), user <> realm <turn.meet.wydler.eu> origin <>, local 116.203.191.z:443, remote 109.41.195.z:6046, reason: TLS/TCP socket buffer operation error (callback)

Einrichten von Logrotate für Coturn

Es wird grundsätzlich beim Start des Service eine Logdatei angelegt. Die Ausgaben werden fortlaufend in diese geschrieben, bis der Service neu gestartet wird. Je nachdem wird solch eine Datei groß und übersichtlich werden. Zudem wird beim Logging kein Datum und Uhrzeit angegeben. Somit ist eine Zuordnung schwierig. Mit Hilfe von Logrotate kann täglich eine neue Protokolldatei erzeugt werden.

cat << EOF > /etc/logrotate.d/coturn
/var/log/coturn/coturn_*.log
{
    su turnserver turnserver
    rotate 30
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
    create 0640 turnserver:turnserver
    systemctl kill -sHUP coturn.service
    endscript
}
EOF

Ob die Konfiguration sollte natürlich geprüft werden. Entweder man wartet einen Tag ab oder führt folgenden Befehl aus:

logrotate -v -f /etc/logrotate.d/coturn

Firewall

Last but not Least kommen wir nochmals auf den Punkt Sicherheit zurück.  Selbstverständlich darf die Grundkonfiguration einer Firewall grundsätzlich nicht fehlen.  Ich greife ich hier auf UFW zurück. Diese ist inzwischen standardmäßig bei der eingesetzten Distribution und Version standardmäßig dabei.

ufw allow ssh
ufw allow https
ufw allow in 443/udp

echo y | ufw enable
ufw status

Fertig ist der TURN-Server. Viel Spaß beim Ausprobieren. 🙂

Abonnieren
Benachrichtige mich bei
45 Comments
neueste
älteste
Inline Feedbacks
View all comments
Xhulio Berberi
31.03.2022 11:38

Hello,
Congrulation on your work. I wish you all the best. I wanted to ask is this way can work also for NextCloud Talk. I have a problem with an error NO ICE Candidates after I set up the coTurn in my server. I have installed it in the same server NextCloud and the coturn. I have changed also the config file with the proper parameters and still have this error.

Neil Young
31.08.2021 18:07

Deine Zugangsdaten für den TURN server sind nicht correct, deswegen bekommst Du auch nur STUN candidates. Da fehlt ein Semikolon hinter dem Timestamp, wenn Du die Credentials nach diesem RFC gebaut hast

Neil Young
Reply to  Neil Young
31.08.2021 18:08

Sorry, sehe gerade, Du nutzt nur STUN. Dafür braucht’s überhaupt keine Creds 🙂

Mike
29.07.2021 12:36

Hi,
vielen Dank für die Super-Anleitung, hat den Server bei mir zum Laufen gebracht, allerdings habe ich das Problem – *NUR* beim Reboot der Maschine:

Cannot bind TLS/TCP listener socket to addr [2003:f4:u655:c654:bz67:ebff:fe53:55jj]:8346
1: Trying to bind TLS/TCP listener socket to addr [2003:f4:u655:c654:bz67:ebff:fe53:55jj]:8346, again…

Wenn ich im laufenden Betrieb den Coturn-Server restarte kommt die obige Meldung nicht ….

Hat mir jemand einen Tipp?

Danke,
Mike

Mike
Reply to  Daniel
15.08.2021 18:46

Hallo Daniel, danke für den Hinweis, so richtig schlau bin ich daraus nicht geworden. Wenn ich den Thread bis zum Ende durchlese wird es im Endeffekt auf die Cert-Permissions runtergebrochen? Also die Zertifikate privkey.pem und fullchain.pem auf „root:turnserver + mode 640“??? Bei mir aktuell 400 und turnserver:turnserver … (ich habe die lets encrypt Zertifikate in einen extra Ordnung für Coturn kopiert, diese werden beim Zertifikats-Update immer mit angepasst als „hook-script“) AmbientCapabilities=CAP_NET_BIND_SERVICE im service File wird bei mir nix bringen da mein Port > 1024 liegt … ….. war leider nicht die Lösung: 0: Trying to bind fd 88 to <[2003:f6:c70d:d400:ba27:ebff:3353:7777]:8346>:… Weiterlesen »

Mike
Reply to  Daniel
18.08.2021 10:37

Hallo Daniel,
habe es gefixt, scheinbar braucht das NW etwas mehr Zeit, zur Startzeit coturn scheint IPV6 noch nicht „aktiv“ zu sein, Lösung -für mich- Eintrag in /lib/systemd/system/coturn.service ==> ExecStartPre=/bin/sleep 10 unter [Service], danach ist das NW oben und es gibt keine Fehlermeldung mehr. Das erklärt auch warum es bei einem Durchstarten des Service an sich nie auftaucht.
Gruß,
Mike

Markus
31.03.2021 13:01

Ich musste in meiner Konfiguration die external-ip-Einträge ersetzen durch „relay-ip“ – sonst gings nicht (ADDRESS_FAMILY_MISMATCH mit einem Client, der nur eine IPv6-Adresse hatte). Und noch ein Hinweis zu einem Fehler, der mich zwei volle Tage gekostet hat: Dem Turn-Server selbst ist der „Realm“ vollkommen egal, er nimmt alles. Auch einen Namen mit Trailing Whitespace! Zumindest im Zusammenspiel mit Jitsi ist dieser Name aber nicht gültig! Es gibt dann übrigens auch einen entsprechenden Hinweis („wrong realm“) – und wenn man genau hinschaut, sieht man das Leerzeichen auch vor der schließenden spitzen Klammer „realm <example.org >“. Mir ist es leider erst sehr… Weiterlesen »

Sascha
25.02.2021 16:05

Hallo, ich habe das Tutorial auch mal durchgearbeitet und der Turn-Server funktioniert soweit wohl (ICE hat geklappt).
Allerdings bekomme ich keine Verbindung für eine Videokonferenz zu stande. Diese brechen mit einer Fehlermeldung ab Verbindung kann nicht hergestellt werden.
Ich habe folgendes Konstrukt:
Ein Server mit Jicofo, Prosody und Jitsi-Meet
Ein Server mit Coturn
X-mal Server mit der Videobridge

Nun habe ich das Problem dass sich dich Videobridges korrekt am Turn-Server melden, allerdings der Jicofo bekommt nichts davon mit.
Können Sie mir hier ein Tipp geben?

Frank
Reply to  Sascha
02.05.2021 15:05

Hallo Sascha,
ich bin auch gerade dabei eine ähnliche Konfiguration wie du aufzubauen. Leider bin nicht so der Superfachmann. Muss ich denn auf den Servern mit der jeweiligen Videobridge irgendwelche Einstellungen für den Coturn-Einsatz vornehmen? Da hört es gerade ein wenig bei mir auf..
Vielleicht hast du ja ein gutes Tutorial oder einen Tipp für mich?

Hippo
26.01.2021 02:08

Das Tutorial war nuetzlich. Ich hab allerdings ein kleines Vertrauensproblem: Warum muessen auf so einer Seite hier Schneeflocken fallen und unnoetig CPU fressen.

Jens
20.11.2020 16:17

Hallo! Ersteinmal einen großen Dank für die Anleitung! Sie ist meines Wissen nach wohl die einzigste die Vollständig und sauber erklärt wurde, um die Einrichtung Schritt für Schritt umzusetzen. Bei mir hat die Einrichtung gut funktioniert, ich bekomme auch eine Verbindung mit meinem Gegenüber und kann ein Gespräch führen, doch denke, das etwas noch nicht rund läuft, gerade in Bezug auf die TCP Verbindung. Der erste Abschnitt Test (2 Zeilen) ist identisch mit Deinem, praktisch die „Halbe Miete“, allerdings habe ich im letzten Abschnitt „Test der Funktionalität“ die LOG-Datei mit Deiner verglichen und bei mir fehlen anscheinend das Zertifikat und… Weiterlesen »

Jens
Reply to  Jens
22.11.2020 16:10

Hallo! Hier noch mal eine Ergänzung und Frage! Der Fehler liegt wohl darin, das via Ipv4 keine TCP / TLS Verbindung etabliert wird, da die Bindung nicht vorhanden ist. Deine Config beruht auf einer IpV4 und Ipv6. Ich nutze aber nur eine Ipv4 Adresse: xxx@stun:~$ tail -f /var/log/coturn/coturn_2020-11-22.log0: IPv6. SCTP listener opened on : ::1:4430: IPv4. UDP listener opened on: 127.0.0.1:4430: IPv6. TCP listener opened on : ::1:4430: IPv4. UDP listener opened on: 17x.xx.1x.xxx:4430: (das ist OK) IPv6. UDP listener opened on: ::1:4430: Total General servers: 2: IO method (auth thread): epoll (with changelist)0: IO method (auth thread): epoll (with… Weiterlesen »

Joachim
11.11.2020 18:49

Kurze Frage zum Script, das TURN-User und Kennwort für 24h ausliest: bezieht sich der Parameter expiry=8600 auf die Geltungsdauer? Dann müsste der Wert allerdings 86400 betragen wie in der Erklärung angegeben.

Robin
16.09.2020 08:42

In der turn-Config scheint es einen fehler zu geben – evtl. auch nur kosmetisch: lt-cred-mech und use-auth-secret sind gleichzeitig nicht nutzbar: https://github.com/coturn/coturn/issues/459#issuecomment-547844254

Ich weiß nicht, welche Auswirkungen das hat, wollte aber darauf hinweisen.

Johannes
17.05.2020 17:17

Ich habe eine sehr ähnliche Konfiguration (Ubuntu 20.04); leider meldet der Server im Logfile

0: log file opened: /var/log/turn_70603_2020-05-17.log
0: You cannot define external IP more than once in the configuration

das liegt wohl daran, dass ich wie bei Ihnen eine IPv4 und eine IPv6 konfigurieren will. Wissen Sie woran das liegt?

Tobias
14.05.2020 14:41

Hallo, erstmal vielen vielen Dank für diesen Artikel. Gefühlt bringt er mich in meiner Sache jetzt schon weiter. Wir betreiben einen Jitsi in einer DMZ, haben allerdings das Problem , das dieser nur funktioniert wenn man im „gleichen“ Netzwerk ist. Also meetings zwischen Internen (Firmennetzwerk) und Externen(Internet) funktionieren nicht. Ich hoffe das ich dieses Problem mit einem Seperaten Turn Server beseitigen kann. Und dazu hätte ich eine Frage, der sperate Turn Server benötigt eine eigne öffentliche IP? Welche Ports müssen weiter geleitet werden ? Reicht 443 oder bedarf es noch mehr ? Ich bin jetzt schon mega Dankbar und sollte… Weiterlesen »

Tobias
Reply to  Daniel
14.05.2020 17:04

Hi Daniel, danke für deine Antwort! > das dieser nur funktioniert wenn man im „gleichen“ Netzwerk ist. Also meetings zwischen Internen (Firmennetzwerk) und Externen(Internet) funktionieren nicht. >>Könnte daran liegen, dass die Kommunikation über Port 10000/UDP zwischen den Teilnehmer nicht möglich ist. Ja, das habe ich mir auch schon gedachte und habe ein entsprechende Regelungen zwischen DMZ – Intranet für eben genau diesen Port aufgeweicht, und es funktioniert auch in einem 1 zu 1 Fall. Also ein externer und ein interener. Aufjedenfall hoffe ich mit dem Turn Server das in den Griff zu bekommen. > Welche Ports müssen weiter geleitet werden… Weiterlesen »

Tobias
Reply to  Tobias
14.05.2020 18:38

Hallo Daniel, Die Installation des Turnservers hat sehr gut geklappt und Trickle ICE (WebRTC) zeigt an das alles klappt! Allerding muss dich nocheinmal um Rat fragen. Im coturn Log bekomme ich folgenden fehler: o: Cannot bind TLS/TCP listener socket to addr 127.0.0.1:443 0: Trying to bind TLS/TCP listener socket to addr 127.0.0.1:443, again… 0: Trying to bind fd 14 to : errno=13 Ich hab jetzt schon eniges dazu gelesen verstehe aber nicht ganz warum der bind nicht funktioniert. Evtl hast du noch eine Idee. Und ich habe eine weitere Frage: In der Jitsi konfiguration sprichst du von “ und .“… Weiterlesen »

Tobias
Reply to  Daniel
22.05.2020 08:49

Guten Morgen Daniel, danke für deinen Support! Ich hab mittlerweile die Fehler soweit beheben können. Der „Bind Error“ hat sich mit diesem Artikel gut beheben können. https://github.com/coturn/coturn/issues/421 Allerdings geht es weiter. Der Turnserver scheint zu funktionieren, denn Jitsi kann eine Verbindung zu diesem aufbauen. Allerdings ist meine Kernproblematik noch nicht damit behoben. Zudem bekomme ich bei https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ nur „Host“-Verbindungen hin, bräuchte aber, sofern ich das richtig verstanden habe „srflx“ und „relay“ Verbindungen. Dazu evtl. noch eine Frage. Ich habe den Turnserver ebenfalls in der DMZ stehen. Alle Ports werden entsprechend weiter geleitet. Ich frage mich bei meinem derzeitigen Problem, ob… Weiterlesen »

Tobias
Reply to  Daniel
28.05.2020 15:56

Moin Daniel!

Ich hab den coTurn jetzt so ins Netz gehangen.

Da ich ein wenig Paranoid bei sowas bin, bekomme ich immer etwas Bauchschmerzen.

Alles läuft soweit. Jitsi scheint keine Probleme zu haben und coTurn arbeitet ordentlich. Die ersten Tests sind erfolgreich verlaufen.

Vereinzeln treten noch  “ TLS/TCP socket buffer operation error (callback)“ – Fehler auf die ich noch nicht richtig zuordnen kann, aber das bekomme ich schon raus.

Ich habe den Jitsi & coTurn an unsere 1GigaBit Leitung gehangen, ich hoffe die Bandbreite reicht aus.

Ich möchte dir nochmals für alles Danken!

Bleib Gesund!

Grüße

Tobi

Marko
05.05.2020 22:53

Hallo, leider bekomme ich nicht den STUN Server zum laufen..
Die ersten Probleme fangen schon an den USER und das PW auszulesen. Da bekomme ich nur den USER das PW bleibt leer.
Des weiteren kann ich den STUN Server nicht erfolgreich testen da mir die srflx Einträge fehlen.

Auch sehe ich nicht das sich Jitsi Meet mit dem STUN verbindet.

Marko
Reply to  Daniel
10.05.2020 10:59

Hallo Daniel, danke für die schnelle anpassungen. Nun sehe ich auch bei Trickle ICE die werte mit dem relay, auch sehe ich im Log von coturn das eingehende Pakete kommen. Ich habe aber immer noch nicht den erfolg den ich erwarte. Zum Verständniss, der eigen STUN/TURN Server dient doch dazu das der gesamte Traffic für Audio und Video über port 443 geht. Oder habe ich das falsch verstanden? Ich benötige folgendes: Videokonferenzen mit 2 oder mehren Teinehmern über Port 443 TCP da nicht jeder port 10000 UDP nach außen zulässt. Geht das überhaubt oder bin ich da auf dem Holzweg?… Weiterlesen »

Marko
Reply to  Daniel
11.05.2020 08:11

Hallo Daniel,
ich habe nochmal die config für Jitsi nach deinen vorgaben geprüft und auch die config für den Turn, bei Trickle sehe ich die Einträge das passt.

Wenn ich jetzt mit 2 Teilnehme eine Konferenz mache nimmt er immer noch 10000 UDP. Daraufhin habe ich denn 10000 UDP in der FW mal geblockt. jetzt bekomme ich aber kein Bild und Ton zustande. sehe aber in der FW das 443 TCP pakete zum STUN-Server wandern!
Das gleiche verhaltenn auch wenn ich mit 4-5 Teinehmer eine Konferenz starte.

Kannst du dir das erklären oder hast du noch einen Tip.

Marko
Reply to  Daniel
14.05.2020 20:26

Hallo Daniel,
es sind unterschiedliche Server. Die FW habe ich auf beiden deaktiviert und ja der Stun lauscht auf 443.
Aber der Meet will nicht zum Stun er will innerlich den 10000 udp.

Ich verzweifle langsam.

Jan
02.05.2020 17:29

Hallo, vielen Dank für die tolle Beschreibung.. Reicht es eigentlich aus wenn ich den tls-listening-port=443 verwende und auf den listening-port=3478 verzichte? Oder sind da beide Ports zwingend notwendig?

Eduard Itrich
12.04.2020 00:37

Vielen Dank für diese sehr ausführliche Anleitung. Leider erhalte ich lediglich den Fehler: TLS/TCP socket buffer operation error (callback)
Ich nutze coturn 4.5.0.7-1ubuntu2.18.04.1 und betreibe diesen in der Azure Cloud. Lokale und externe IP habe ich eigentlich richtig gesetzt, trotzdem kommt zwischen zwei Teilnehmern kein Austausch zustande.

Ich habe lediglich diesen Issue auf Github https://github.com/coturn/coturn/issues/113#issuecomment-610762334 entdeckt.

Liegt es an einem Fehler in dieser Version von coTURN oder nutzt du dieselbe Version?

Eduard Itrich
Reply to  Daniel
12.04.2020 19:53

Vielen Dank für den Tipp! Nachdem ich in /etc/hosts die FQDN des coTURN auf die private IP gemappt habe, verbindet sich Jitsi nun an coTURN. Bild- und Ton werden nun via UDP übertragen.

Seltsamerweise erhalte ich den Fehler nachwievor im Log:
480: session 000000000000000002: TLS/TCP socket disconnected: 91.14.xx.xx:59673
480: session 000000000000000002: closed (2nd stage), user realm origin , local 10.0.0.5:443, remote 91.14.xx.xx:59673, reason: TLS/TCP socket buffer operation error (callback)

Eduard Itrich
Reply to  Eduard Itrich
12.04.2020 20:21

Geschafft! Nachdem ich nun das Zertifikat nutze, welches in /etc/coturn/certs liegt, taucht auch oben erwähnter Fehler nicht mehr auf: # Certificate file. cert=/etc/coturn/certs/turn.toplevel.domain.fullchain.pem # Private key file. pkey=/etc/coturn/certs/turn.toplevel.domain.privkey.pem # CA file in OpenSSL format. CA-file=/etc/coturn/lets-encrypt-x3-cross-signed.pem Wichtig sind wohl auch die Rechte an den Dateien (chmod 600 sowie 644): -r——– 1 turnserver turnserver 3599 Apr 12 18:08 turn.toplevel.domain.fullchain.pem -r——– 1 turnserver turnserver 1708 Apr 12 18:08 turn.toplevel.domain.privkey.pem -rw-r–r– 1 turnserver turnserver 1647 Apr 12 17:16 lets-encrypt-x3-cross-signed.pem Unter /etc/letsencrypt/renewal-hooks/deploy/0000-coturn-certbot-deploy.sh wird auch ein Skript mitgeliefert, welches das Umkopieren und anpassen der Besitzrechte im Zuge von cerbot-auto renewal automatisiert. Mit großer Unterstützung des Threads:… Weiterlesen »

Eduard Itrich
Reply to  Daniel
14.04.2020 05:47

Tatsächlich tauchen die Meldungen seitdem ich die Zertifikate mit den korrekten Besitzrechten nutze nicht mehr auf. Ändere ich cert=/etc/coturn/certs/turn.toplevel.domain.fullchain.pem allerdings wieder in cert=/etc/letsencrypt/live/turn.toplevel.domain/cert.pem, taucht die Meldung bezüglich TLS/TCP socket buffer operatior error wieder zuverlässig auf.