Wenn Sie bei uns gehostet werden, ist dies auf Ihrer Website bereits vorkonfiguriert. Diese Anleitung richtet sich an Admins, die Discourse selbst hosten.
Discourse Live nutzt WebRTC für Sprach- und Videoanrufe. Es wird mit öffentlichen STUN-Servern ausgeliefert, die Teilnehmern dabei helfen, direkte Verbindungen herzustellen. Admins können diese Server ersetzen und TURN hinzufügen, um Netzwerke zu unterstützen, in denen direkte Verbindungen fehlschlagen.
Für einen Server, der ausschließlich Ihrer Community gewidmet ist, empfehlen wir, coturn als Ihren STUN- und TURN-Server zu betreiben, mit Shared-Secret-Authentifizierung für TURN. Dies bietet die Ermittlung öffentlicher Adressen und einen Relay-Fallback, ohne ein dauerhaftes TURN-Passwort verteilen oder sich auf STUN-Server von Drittanbietern verlassen zu müssen.
Diese Anleitung gilt für Peer-to-Peer-Anrufe von Live. Räume, die LiveKit verwenden, nutzen stattdessen LiveKits eigene ICE/TURN-Konfiguration. Erfahren Sie mehr über Live’s LiveKit-Konfiguration.
Was machen STUN und TURN?
- STUN hilft einem Browser, seine öffentliche IP-Adresse und Portnummer herauszufinden, damit er eine direkte Verbindung versuchen kann.
- TURN leitet Medien weiter, wenn keine direkte Verbindung hergestellt werden kann.
Ein Browser, der seine öffentliche Adresse erfährt, kann diese als server-reflexive (srflx) Candidate anbieten, was direkte Verbindungen durch NATs von Heim- und Büronetzwerken ermöglicht. Ohne eine solche Candidate fallen die meisten Anrufe auf das TURN-Relay zurück, was Latenz und Relay-Bandbreite erhöht.
STUN muss offen bleiben, auch wenn Sie TURN betreiben. Eine TURN-Allokationsantwort enthält zwar auch die öffentliche Adresse des Browsers, aber nur einige Browser (wie Firefox) verwenden sie als Candidate. Chromium-basierte Browser und Safari erfahren ihre öffentliche Adresse nur aus einer separaten STUN-Binding-Anfrage, und Browser senden bei Binding-Anfragen niemals Anmeldedaten. Wenn der Server STUN deaktiviert (no-stun) oder Authentifizierung dafür erfordert (secure-stun), erhalten diese Browser keine srflx Candidate, und alle von ihnen getätigten Anrufe werden über das Relay geleitet.
Mit konfiguriertem Shared-Secret-TURN erlaubt Live sowohl direkte als auch Relay-Verbindungen. Die Konfiguration von TURN zwingt nicht jeden Anruf über das Relay. Live’s ICE-Konfiguration.
1. Vorbereiten eines TURN-Servers
Sie können einen verwalteten TURN-Dienst nutzen, der die Shared-Secret-Authentifizierung gemäß TURN REST API unterstützt, oder coturn selbst betreiben.
Für ein selbst gehostetes Setup bereiten Sie Folgendes vor:
- Einen Server mit einer öffentlichen IP-Adresse und ausreichender Bandbreite für Relay-Anrufe.
- Einen Hostnamen wie
turn.example.com, der direkt auf diesen Server zeigt. - Firewall-Zugriff für den TURN-Listener und den UDP-Relay-Portbereich.
- Ein gültiges Zertifikat, wenn Sie TURN über TLS anbieten.
Die Browser der Teilnehmer verbinden sich direkt mit TURN. Ein gewöhnlicher HTTP-Reverse-Proxy oder CDN-Proxy kann TURN-Traffic nicht transportieren.
Beispiel-koturn-Konfiguration
Generieren Sie ein zufälliges Secret:
openssl rand -hex 32
Behandeln Sie das Ergebnis vertraulich. Sie müssen denselben Wert in coturn und Discourse eingeben.
Auf einem Server mit direkt zugewiesener öffentlicher IP verwenden Sie Folgendes als Startpunkt in /etc/turnserver.conf:
listening-port=3478
fingerprint
realm=turn.example.com
use-auth-secret
static-auth-secret=REPLACE_WITH_YOUR_RANDOM_SECRET
# Fügen Sie kein no-stun oder secure-stun hinzu: Browser senden STUN-Binding-Anfragen
# ohne Anmeldedaten, und viele verlassen sich darauf, um ihre öffentliche Adresse zu ermitteln.
min-port=49152
max-port=65535
no-multicast-peers
# Dieses Beispiel startet ohne TLS.
no-tls
no-dtls
Ersetzen Sie den Hostnamen und das Secret, schützen Sie die Konfigurationsdatei und starten Sie coturn neu. Entfernen Sie jegliche widersprüchliche no-auth oder statische user= Konfiguration. Der Shared-Secret-Modus von Coturn aktiviert den dafür nötigen Authentifizierungsmechanismus intern. Coturn-Konfigurationsreferenz.
Anonymes STUN meldet nur die eigene Adresse des Clients an diesen zurück; es kann keinen Traffic weiterleiten, wodurch Ihr Server nicht zu einem offenen Relay wird. Neuere coturn-Versionen lassen die optionalen RFC 5780- und MAPPED-ADDRESS-Antwortattribute standardmäßig deaktiviert, was Binding-Antworten nahe an der Anfragegröße hält und deren Nützlichkeit für Reflektionsangriffe einschränkt. Lassen Sie rfc5780 und stun-backward-compatibility deaktiviert.
Erlauben Sie eingehenden Traffic auf:
| Port | Protokoll | Zweck |
|---|---|---|
3478 |
UDP | STUN und TURN |
3478 |
TCP | TURN |
49152–65535 |
UDP | Weitergeleitete Medien |
Erlauben Sie den entsprechenden ausgehenden Traffic ebenfalls. Der Relay-Bereich muss mit min-port und max-port übereinstimmen.
Wenn der Server hinter einer NAT liegt, konfigurieren Sie die coturn-Mapping external-ip=ÖFFENTLICHE_IP/PRIVATE_IP und leiten Sie die Listener- und Relay-Ports weiter. Relay-Ports müssen ihre Portnummern durch NAT hindurch beibehalten. Coturn-Deployments-Optionen.
TLS für restriktive Netzwerke hinzufügen
TURN über TLS bietet eine weitere Verbindungsoption für Teilnehmer, deren Netzwerke UDP blockieren.
Entfernen Sie no-tls und konfigurieren Sie:
tls-listening-port=5349
cert=/pfad/zum/fullchain.pem
pkey=/pfad/zum/privkey.pem
Öffnen Sie 5349/TCP, stellen Sie sicher, dass coturn das Zertifikat und den Schlüssel lesen kann, und starten Sie den Dienst nach Zertifikatsverlängerungen neu.
Sie können stattdessen 443/TCP verwenden, wenn dieser Port auf dem TURN-Server verfügbar ist. Dies kann in restriktiven Netzwerken helfen, obwohl einige Netzwerke auch Non-HTTP-Traffic auf Port 443 inspizieren und blockieren. Der UDP-Relay-Bereich ist weiterhin erforderlich, wenn Browser TURN über TCP oder TLS erreichen. Coturn-Serverdokumentation.
2. Discourse konfigurieren
Suchen Sie in Admin → Einstellungen nach diesen Live-Einstellungen:
| Einstellung | Wert |
|---|---|
live_stun_servers |
Die STUN-URI Ihres coturn-Servers — ersetzen Sie die Standardeinträge |
live_turn_secret |
Der Wert für coturns static-auth-secret |
live_turn_secret_servers |
Ihre TURN-URIs, getrennt durch | |
live_turn_servers |
Leer |
live_turn_username |
Leer |
live_turn_credential |
Leer |
Für die oben genannte Konfiguration geben Sie in live_stun_servers Folgendes ein:
stun:turn.example.com:3478
Und in live_turn_secret_servers:
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp
Wenn Sie TLS aktiviert haben, fügen Sie dessen Endpoint hinzu:
turn:turn.example.com:3478?transport=udp|turn:turn.example.com:3478?transport=tcp|turns:turn.example.com:5349?transport=tcp
Verwenden Sie stun:, turn:- und turns:-URIs, ohne //. Listen Sie nur Endpoints auf, die Ihr Server tatsächlich unterstützt.
Chromium-basierte Browser senden auch STUN-Anfragen an die von Ihnen aufgelisteten TURN-Server, sodass eine leere live_stun_servers-Liste funktionieren kann, solange coturn anonyme STUN-Anfragen beantwortet. Das explizite Auflisten der STUN-URI macht das Setup klarer, deckt andere Browser ab und ermöglicht es Live’s Verbindungsdiagnose, diese eigenständig zu testen.
Die live_turn_secret_servers-Liste verwendet Anmeldedaten, die aus dem Shared Secret generiert werden. Die separate live_turn_servers-Liste verwendet einen festen Benutzernamen und ein festes Passwort. Live-Einstellungsdefinitionen.
Speichern Sie die Einstellungen und bitten Sie die Teilnehmer dann, Anrufe zu verlassen und erneut beizutreten, um die neue Konfiguration zu erhalten.
3. Das Setup überprüfen
Testen Sie mit zwei Teilnehmern in verschiedenen Netzwerken, z. B. Heim-Breitband und Mobile Daten, und in mehr als einem Browser — mindestens einem Chromium-basierten Browser und Firefox. Bestätigen Sie, dass Audio in beide Richtungen funktioniert, und testen Sie dann Video und Bildschirmfreigabe.
Öffnen Sie in einem Peer-to-Peer-Raum das ⋮-Menü des Raums und wählen Sie Verbindungsdiagnose:
- Unter STUN/TURN-Servern sollte jeder Server als Erreichbar angezeigt werden. TURN-Server sollten eine Relay-Adresse auflisten, und UDP-Server sollten eine Öffentliche Adresse auflisten. „Öffentliche Adresse: Keine“ bedeutet, dass STUN-Anfragen keine Antwort erhalten haben — prüfen Sie
no-stun/secure-stunund ob3478/UDPoffen ist. - Unter Peers zeigt die Route, wie jede Verbindung Medien überträgt: Direkt (gleiches Netzwerk), Direkt (durch NAT via STUN) oder Weitergeleitet über TURN. Die meisten Teilnehmer in gewöhnlichen Heimnetzwerken sollten sich direkt verbinden.
- Bericht kopieren erzeugt einen Textbericht, den Sie mit der Person teilen können, die die Fehlerbehebung durchführt. Er enthält die IP-Adressen der Teilnehmer, teilen Sie ihn daher privat.
In Chromium-Browsern zeigt chrome://webrtc-internals dieselben Details auf einer niedrigeren Ebene:
- Eine
srflxCandidate repräsentiert eine ermittelte öffentliche Adresse. - Eine
relayCandidate repräsentiert ein verfügbares TURN-Relay. - Das ausgewählte Candidate-Paar zeigt die Verbindung an, die tatsächlich Medien überträgt.
Ein erfolgreicher direkter Anruf beweist nicht, dass das Relay funktioniert. Testen Sie auch von einem Netzwerk aus, das TURN erfordert, oder verwenden Sie einen WebRTC-Testclient mit iceTransportPolicy: "relay" und temporären Anmeldedaten.
Prüfen Sie die Logs von coturn auf erfolgreiche authentifizierte Allokationen. Anfragen ohne gültige Anmeldedaten dürfen keine Relay-Allokation erhalten. Eine anfängliche 401 Authentifizierungs-Herausforderung ist normal; wiederholte Authentifizierungsfehler müssen untersucht werden.
Den Server ausschließlich für Ihre Community nutzen
Das Shared Secret verbleibt auf Discourse und dem TURN-Server. Teilnehmer erhalten stattdessen temporäre Anmeldedaten. Live generiert derzeit Anmeldedaten, die 12 Stunden gültig sind, um Allokationen zu erstellen; eine bestehende Allokation kann fortgesetzt werden, während sie erneuert wird. Live’s Anmeldedaten-Generierung.
Dies verhindert ein anonymes offenes Relay, aber TURN-Anmeldedaten sind nicht an einen Browser-Origin gebunden: Ein Teilnehmer kann seine temporären Anmeldedaten kopieren und wiederverwenden. Um Missbrauch einzuschränken:
- Schränken Sie den Live-Zugriff auf die vorgesehenen Gruppen ein.
- Überwachen Sie die Relay-Bandbreite und die Anzahl der Allokationen.
- Legen Sie coturn-Allokationsquoten und Bandbreitenlimits fest, die für Ihre Community angemessen sind.
- Blockieren Sie den Relay-Zugriff auf private, Link-Local- und andere interne Ziele, die vom TURN-Host aus erreichbar sind.
- Halten Sie coturn aktuell und rotieren Sie das Shared Secret, falls es kompromittiert wurde.
Verwenden Sie ein dediziertes Secret für diese Discourse-Installation. Ihr Server beantwortet auch anonyme STUN-Anfragen von jedem; dies ist erwartet, benötigt wenig Bandbreite und gewährt keinen Relay-Zugriff. Coturn-Authentifizierung und Zugriffssteuerungen.
Alternativen
Nur die öffentlichen STUN-Server ersetzen
Legen Sie live_stun_servers auf Ihre eigenen STUN-URIs fest, getrennt durch |:
stun:stun.example.com:3478
Lassen Sie die TURN-Einstellungen leer, wenn Sie kein Relay benötigen. STUN allein kann Anrufe nicht in jedem Netzwerk funktionieren lassen.
TURN mit festem Benutzernamen und Passwort verwenden
Wenn Ihr Anbieter keine Shared-Secret-Authentifizierung unterstützt, konfigurieren Sie live_turn_servers, live_turn_username und live_turn_credential. Lassen Sie die Shared-Secret-Einstellungen leer.
Teilnehmer erhalten diese festen Anmeldedaten, was ihre Wiederverwendung außerhalb Ihrer Website erleichtert. Außerdem erzwingt Live derzeit Relay-Verbindungen, wenn statische TURN-Server konfiguriert sind und die STUN-Liste leer ist. Ziehen Sie Shared-Secret-Authentifizierung vor, wenn Ihr Anbieter diese unterstützt. Live’s ICE-Konfiguration.