Встановлення та налаштування TURN-сервера Coturn на VPS для WebRTC: TLS, WebSocket і безпечна авторизація

Що ми налаштовуємо і навіщо

WebRTC дає змогу браузерам, мобільним застосункам і desktop-клієнтам передавати голос, відео, зображення екрана й довільні дані в реальному часі. В ідеальному випадку два клієнти встановлюють пряме P2P-з’єднання. На практиці це регулярно не працює: користувач перебуває за симетричним NAT, мобільним CGNAT, суворим офісним firewall, готельним Wi-Fi або в мережі, де дозволено лише HTTPS-трафік.

STUN-сервер допомагає клієнту дізнатися публічну IP-адресу та тип NAT. Але STUN сам по собі не передає медіа. Якщо прямий маршрут недоступний, WebRTC-клієнт використовує TURN-сервер як relay: обидва учасники надсилають UDP-, TCP- або TLS-трафік на сервер, а Coturn пересилає пакети між ними. Це підвищує надійність дзвінків, але означає, що медіатрафік проходить через ваш VPS.

У результаті буде отримано таку схему:

• STUN/TURN через UDP і TCP на turn.example.com:3478;
• TURN over TLS на turns:turn.example.com:5349;
• діапазон relay-портів, наприклад 49160-49200/udp;
• короткочасна автентифікація користувачів за допомогою спільного серверного секрету;
• автоматичне оновлення TLS-сертифіката Let’s Encrypt;
• за потреби — окремий WebSocket-сигналінг через wss://signal.example.com.

TURN, TLS і WebSocket: важлива відмінність

WebRTC складається з кількох незалежних частин. Сигналінг передає SDP offer/answer та ICE-кандидати. Зазвичай для цього використовують WebSocket, Socket.IO, HTTPS API, XMPP або інший прикладний канал. Для сигнального сервера використовується wss://, тобто WebSocket поверх HTTPS.

TURN розв’язує інше завдання: передає вже узгоджений медіатрафік WebRTC. Coturn підтримує TURN через UDP, TCP і TLS, проте звичайне встановлення Coturn не є WebSocket TURN-сервером. Не можна поставити Caddy або Nginx перед портом 3478 і очікувати, що TURN запрацює через WebSocket: це різні протоколи. Якщо ваша корпоративна мережа пропускає лише TCP/443, використовуйте TURN over TLS на 5349 або виділену IP-адресу й порт 443, якщо немає конфлікту з HTTPS.

Self-hosted TURN чи managed TURN

Self-hosted Coturn доцільний для власного відеочату, SaaS-продукту, Mattermost Calls, Jitsi, LiveKit, Janus, mediasoup, мобільного застосунку або внутрішнього корпоративного зв’язку. Для невеликого продукту він забезпечує передбачувану інфраструктуру. Однак потрібно заздалегідь оцінити вихідний трафік: під час relay-з’єднання сервер зазвичай отримує потік від одного клієнта й надсилає його іншому, тому 1 ГБ переданого відео може потребувати приблизно 2 ГБ мережевого трафіку сервера.

Яка конфігурація VPS потрібна для цього завдання

Coturn ощадливо використовує CPU і RAM, оскільки не перекодовує відео й не аналізує медіапотік. Основне навантаження припадає на пропускну здатність мережі, кількість одночасних allocations і пакетів за секунду. Під час групового дзвінка з SFU трафік TURN зазвичай менший, ніж під час mesh-дзвінка, але це залежить від архітектури застосунку та поведінки клієнтів.

Для першого production-запуску достатньо 2 vCPU, 2 ГБ RAM, 20 ГБ SSD, статичної IPv4-адреси й каналу 1 Гбіт/с. Такий варіант можна вибрати як VPS із зазначеними характеристиками. Важливішими за обсяг диска є гарантована або зрозуміла пропускна здатність, відсутність жорсткого ліміту пакетів за секунду й достатній місячний обсяг вихідного трафіку.

Коли потрібен dedicated, а не VPS

Виділений сервер виправданий, коли relay-трафік стабільно займає сотні мегабіт або гігабіти за секунду, важливі передбачувані PPS, потрібні кілька публічних IP-адрес або сервіс обслуговує сотні й тисячі одночасних відеопотоків. Dedicated також корисний, якщо потрібно розділити TURN на окремі географічні вузли й не залежати від віртуалізації сусідніх орендарів.

Не варто переходити на dedicated лише тому, що в конфігурації є TLS. Шифрування TURN потребує CPU, але на сучасних процесорах кілька сотень помірно активних з’єднань зазвичай не є проблемою. Спочатку виміряйте фактичні метрики: CPU, вхідний і вихідний трафік, кількість allocations, packet loss і latency.

Як вибрати локацію

TURN додає затримку до шляху медіапакетів, тому розміщуйте сервер ближче до більшої частини аудиторії. Для користувачів із Німеччини, Польщі та Нідерландів підійде центральноєвропейська локація. Якщо учасники розмови перебувають у різних регіонах, один TURN-сервер буде компромісом: трафік обох проходитиме через нього.

Для глобального продукту використовують кілька вузлів Coturn і передають клієнту регіональний список ICE-серверів. Не вибирайте локацію лише за ціною: втрата пакетів, поганий peering і висока затримка помітніші під час дзвінків, ніж на звичайному вебсайті.

Підготовка сервера

Нижче передбачається чистий Ubuntu Server 24.04 LTS із публічною IPv4-адресою. Виконайте початкове підключення під root, а потім створіть звичайного адміністратора. Перш ніж налаштовувати DNS, створіть A-запис turn.example.com, який вказуватиме на IP-адресу VPS. Для TLS-перевірки запис уже має поширитися в DNS.

Оновіть систему й установіть базові утиліти

apt update && apt upgrade -y
apt install -y sudo curl ca-certificates gnupg ufw fail2ban dnsutils jq
reboot

Перша команда оновлює пакети Ubuntu, встановлює інструменти адміністрування й перезавантажує сервер, якщо було оновлено ядро або системні бібліотеки.

Створіть користувача для адміністрування

adduser deploy
usermod -aG sudo deploy
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys

Вставте в authorized_keys свій публічний SSH-ключ одним рядком. Перш ніж вимикати вхід root, обов’язково відкрийте другу SSH-сесію й переконайтеся, що вхід під deploy справді працює.

Вимкніть вхід SSH за паролем

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
cat > /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
EOF
sshd -t && systemctl restart ssh

Файл у sshd_config.d перевизначає небезпечні значення без редагування основного файлу. Команда sshd -t перевіряє синтаксис перед перезапуском SSH.

Налаштуйте UFW і Fail2ban

Для Coturn потрібні UDP і TCP на порту 3478, TCP на 5349, UDP на 5349 для варіантів із DTLS, а також relay-діапазон. У прикладі використовується обмежений діапазон 49160:49200: 41 UDP-порт. Цього достатньо для тестового або невеликого сервісу. Що більше одночасних relay-сеансів, то ширшим має бути діапазон.

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 3478/tcp
ufw allow 3478/udp
ufw allow 5349/tcp
ufw allow 5349/udp
ufw allow 49160:49200/udp
ufw enable
ufw status numbered

Порти 80/tcp і 443/tcp потрібні для випуску сертифіката й майбутнього HTTPS/WSS-сигналінгу. Якщо на сервері не буде сигнального застосунку, після випуску сертифіката порт 80 можна закрити за умови використання DNS challenge, але для стандартного поновлення HTTP-01 він має залишатися доступним.

systemctl enable --now fail2ban
fail2ban-client status
timedatectl set-timezone UTC
timedatectl status

Fail2ban захищає передусім SSH. TURN-автентифікація буде захищена короткочасними credential, тому блокування окремих помилок TURN через Fail2ban зазвичай менш корисне, ніж обмеження доступу firewall і відстеження аномалій трафіку.

Встановлення ПЗ — покроково

В Ubuntu 24.04 LTS доступний пакет Coturn гілки 4.6.x. Для production доцільно використовувати пакет дистрибутива: він отримує оновлення безпеки разом із системою, коректно інтегрований із systemd і містить утиліти діагностики. Під час планування інфраструктури у 2026 році орієнтуйтеся на актуальний стабільний реліз гілки Coturn 4.6.x або новіший, доступний у репозиторії безпеки вашого дистрибутива.

Установіть Coturn і Certbot

apt update
apt install -y coturn certbot
turnserver --version
certbot --version

Команда встановлює TURN/STUN-сервер і ACME-клієнт Let’s Encrypt. Перевірте версію Coturn: пакет не має бути застарілим або зібраним із неперевіреного стороннього репозиторію.

Увімкніть службу systemd Coturn

systemctl unmask coturn
systemctl enable coturn
systemctl status coturn --no-pager

У деяких збірках Ubuntu службу може бути замасковано до первинного налаштування. Поки конфігурацію не створено, служба може завершувати роботу з помилкою — це нормально. Остаточно запускатимемо її після створення конфігурації.

Отримайте TLS-сертифікат

Перш ніж виконувати команду, переконайтеся, що turn.example.com спрямовує на публічну IP-адресу цього сервера, а порт 80/tcp доступний ззовні. На час перевірки Certbot запустить власний тимчасовий HTTP-сервер.

systemctl stop coturn
certbot certonly --standalone \
  --non-interactive \
  --agree-tos \
  --email [email protected] \
  -d turn.example.com

Замініть [email protected] і домен на реальні значення. Сертифікати з’являться в каталозі /etc/letsencrypt/live/turn.example.com/. Не копіюйте закритий ключ у домашні каталоги й не додавайте його до Git.

Створіть окрему групу для читання сертифіката

Служба Coturn зазвичай запускається від системного користувача turnserver. Доступ до privkey.pem має бути надано лише користувачу, якому він необхідний, через групу ssl-cert.

usermod -aG ssl-cert turnserver
chgrp ssl-cert /etc/letsencrypt/live/turn.example.com/privkey.pem
chmod 640 /etc/letsencrypt/live/turn.example.com/privkey.pem
namei -l /etc/letsencrypt/live/turn.example.com/privkey.pem

Символічні посилання з live ведуть до каталогу archive, тому після оновлення сертифіката права можуть змінюватися. Далі буде додано deploy hook, який повторно задає права й перезапускає Coturn.

Згенеруйте секрет для REST-автентифікації

install -d -m 750 /etc/coturn
umask 077
openssl rand -hex 32 > /etc/coturn/auth-secret
chown root:turnserver /etc/coturn/auth-secret
chmod 640 /etc/coturn/auth-secret
cat /etc/coturn/auth-secret

Ця команда створює 256-бітний секрет. Збережіть його в захищеному сховищі секретів. Остання команда виведе значення лише для безпечного перенесення до backend застосунку; не запускайте її в терміналі з журналюванням історії або демонстрацією екрана.

Конфігурація Coturn, TLS і WebSocket-сигналінгу

У production не використовуйте lt-cred-mech із постійними користувачами, якщо ваш backend може видавати тимчасові credentials. Режим use-auth-secret дає змогу застосунку сформувати ім’я користувача у вигляді часу завершення дії за Unix та ідентифікатора користувача, а пароль обчислити як HMAC-SHA1 від імені користувача із серверним секретом. Coturn перевіряє credential локально, без бази даних.

Створіть основну конфігурацію Coturn

Замініть IP-адресу, домен і адресу інтерфейсу на свої. Якщо VPS має одну публічну IPv4-адресу без внутрішнього NAT, external-ip можна вказати як публічну адресу. Якщо VPS розташований за NAT, використовуйте формат PUBLIC_IP/PRIVATE_IP.

# /etc/turnserver.conf

listening-port=3478
tls-listening-port=5349

listening-ip=0.0.0.0
relay-ip=PUBLIC_IPV4
external-ip=PUBLIC_IPV4

realm=turn.example.com
server-name=turn.example.com
fingerprint

min-port=49160
max-port=49200

use-auth-secret
static-auth-secret=REPLACE_WITH_SECRET_FROM_AUTH_SECRET_FILE

no-multicast-peers
no-loopback-peers
stale-nonce=600

cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem

no-tlsv1
no-tlsv1_1
cipher-list=HIGH:!aNULL:!MD5:!RC4

no-cli
no-tcp-relay

log-file=/var/log/turnserver/turnserver.log
simple-log
syslog

Параметр no-tcp-relay вимикає TCP relay allocations, але не вимикає приймання TURN через TCP або TLS. Для більшості сценаріїв WebRTC relay через UDP є кращим варіантом: менша затримка й менше head-of-line blocking. Якщо вашим клієнтам справді потрібен relay через TCP, видаліть цей рядок і окремо протестуйте навантаження.

Опція fingerprint вмикає обов’язковий атрибут FINGERPRINT для сумісності й цілісності STUN-повідомлень. no-multicast-peers і no-loopback-peers не дають використовувати TURN як проксі до multicast- або loopback-адрес. Обмеження портів дає змогу контролювати firewall і зменшує поверхню для зловживань.

Підставте секрет, не зберігаючи його в Git

Файл Coturn читається службою і містить секрет, тому встановіть суворі права доступу. Якщо конфігурацією керує Ansible, Terraform чи інший інструмент IaC, передавайте секрет через зашифровані variables або secret manager, а не зберігайте його в репозиторії.

SECRET="$(cat /etc/coturn/auth-secret)"
sed -i "s/REPLACE_WITH_SECRET_FROM_AUTH_SECRET_FILE/${SECRET}/" /etc/turnserver.conf
chown root:turnserver /etc/turnserver.conf
chmod 640 /etc/turnserver.conf
install -d -m 750 -o turnserver -g turnserver /var/log/turnserver
turnserver -c /etc/turnserver.conf -o -v

Остання команда запускає Coturn у foreground із докладним виведенням. Якщо синтаксис, IP-адреса, сертифікат або права на ключ неправильні, помилку буде одразу видно. Після перевірки зупиніть тестовий процес комбінацією Ctrl+C.

Запустіть службу й перевірте порти, що прослуховуються

systemctl restart coturn
systemctl enable coturn
systemctl status coturn --no-pager
ss -lntup | grep -E ':(3478|5349)\b'
journalctl -u coturn -n 100 --no-pager

Очікуються UDP і TCP на 3478, TCP на 5349 і, залежно від збірки та налаштувань TLS/DTLS, UDP на 5349. Не публікуйте адміністративний CLI Coturn в інтернеті: у конфігурації його вимкнено директивою no-cli.

Налаштуйте автоматичне оновлення сертифіката

cat > /etc/letsencrypt/renewal-hooks/deploy/reload-coturn.sh <<'EOF'
#!/bin/sh
chgrp ssl-cert /etc/letsencrypt/live/turn.example.com/privkey.pem
chmod 640 /etc/letsencrypt/live/turn.example.com/privkey.pem
systemctl restart coturn
EOF
chmod 750 /etc/letsencrypt/renewal-hooks/deploy/reload-coturn.sh
certbot renew --dry-run
systemctl list-timers | grep certbot

Deploy hook перезапускає Coturn лише після успішного оновлення сертифіката. Команда --dry-run перевіряє, чи пройде оновлення до закінчення строку дії сертифіката. Короткочасний перезапуск може скинути активні allocations, тому виконуйте ручні зміни сертифікатів у вікно обслуговування.

Як backend формує тимчасові TURN credentials

Ім’я користувача зазвичай має вигляд EXPIRES:USER_ID, де EXPIRES — Unix timestamp. Пароль — це Base64-представлення HMAC-SHA1 імені користувача зі спільним секретом. Час життя від 1 до 24 годин вибирають відповідно до тривалості сесій: для відеодзвінка часто достатньо 3600–7200 секунд. Не видавайте credential на місяці: витік такого пароля дасть змогу використовувати ваш relay для чужого трафіку.

import crypto from 'node:crypto';

const secret = process.env.TURN_AUTH_SECRET;
const ttlSeconds = 3600;
const expires = Math.floor(Date.now() / 1000) + ttlSeconds;
const username = ${expires}:user-12345;

const credential = crypto
  .createHmac('sha1', secret)
  .update(username)
  .digest('base64');

const iceServers = [
  {
    urls: [
      'turn:turn.example.com:3478?transport=udp',
      'turn:turn.example.com:3478?transport=tcp',
      'turns:turn.example.com:5349?transport=tcp'
    ],
    username,
    credential
  }
];

Передавайте секрет застосунку через змінну оточення, systemd credentials, Kubernetes Secret або vault. Не повертайте TURN_AUTH_SECRET у браузер. Браузеру передаються лише тимчасові username і credential.

Приклад змінних оточення backend

cat > /etc/myapp/turn.env <<'EOF'
TURN_HOST=turn.example.com
TURN_TLS_PORT=5349
TURN_AUTH_SECRET=replace-with-the-same-secret
TURN_CREDENTIAL_TTL=3600
EOF
chmod 600 /etc/myapp/turn.env

Файл /etc/myapp/turn.env є прикладом для вашого сигнального API. Сам Coturn не зчитує цей файл: він використовує значення static-auth-secret зі своєї конфігурації. Обидва значення мають збігатися.

Перевірка TLS і функціональний тест

openssl s_client -connect turn.example.com:5349 \
  -servername turn.example.com -brief < /dev/null

turnutils_uclient -u "EXPIRES:user-12345" \
  -w "GENERATED_PASSWORD" \
  -p 3478 turn.example.com

tail -f /var/log/turnserver/turnserver.log

Перша команда перевіряє сертифікат і TLS-рукостискання. Друга входить до пакета Coturn і створює клієнтський тест; підставте свіжу пару тимчасових credentials. У журналі шукайте успішну автентифікацію та створення allocation. Щоб перевірити роботу з браузера, скористайтеся тестовою сторінкою вашого застосунку, відкрийте chrome://webrtc-internals і переконайтеся, що в мережі, де P2P недоступний, вибрана пара candidate має тип relay.

WebSocket-сигналінг через Caddy

Якщо у вас є сигнальний сервер на локальному порту 3000, Caddy може автоматично обслуговувати HTTPS і проксирувати WebSocket-з’єднання. Це окрема служба й окремий домен, наприклад signal.example.com. Не спрямовуйте UDP-порти Coturn через Caddy і не проксируйте TURN як HTTP.

signal.example.com {
    reverse_proxy 127.0.0.1:3000
}

Caddy автоматично підтримує перехід до WebSocket і отримує HTTPS-сертифікат для домену сигналінгу. На клієнті підключайтеся до wss://signal.example.com, а конфігурацію ICE з TURN credentials отримуйте через авторизований API або через цей самий сигнальний канал. Якщо сигнальний сервер розташований на іншому вузлі, це не заважає йому видавати короткочасні credentials для Coturn.

Резервне копіювання та обслуговування

Coturn у режимі use-auth-secret не зберігає користувачів, записи дзвінків або медіадані. Тому резервно копіювати потрібно не relay-трафік, а конфігурацію, TLS-матеріали, секрети, правила firewall та інфраструктурні скрипти. Якщо ваш backend зберігає користувачів, кімнати, історію або записи, резервуйте його базу даних окремим процесом.

Що включити до резервної копії

• /etc/turnserver.conf і файл секрету /etc/coturn/auth-secret;
• /etc/letsencrypt, якщо потрібне швидке відновлення наявних сертифікатів;
• конфігурації Caddy та сигнального застосунку;
• дампи PostgreSQL, MySQL або іншої БД backend-застосунку;
• список пакетів, правила UFW і документацію щодо DNS-записів;
• необов’язково: журнали Coturn із коротким строком зберігання для розслідування інцидентів.

Не зберігайте єдину копію секрету на тому самому VPS. У разі втрати секрету можна згенерувати новий, але всі чинні credentials негайно перестануть працювати. Це допустимий аварійний сценарій, однак краще виконувати його контрольовано.

Приклад резервного копіювання за допомогою Restic

apt install -y restic
export RESTIC_REPOSITORY="s3:https://s3.example.net/turn-backups"
export RESTIC_PASSWORD_FILE="/root/.config/restic/password"
export AWS_ACCESS_KEY_ID="REPLACE_ME"
export AWS_SECRET_ACCESS_KEY="REPLACE_ME"

restic init
restic backup /etc/turnserver.conf /etc/coturn /etc/letsencrypt /etc/caddy
restic snapshots

Замініть адресу S3 і облікові дані. У production передавайте змінні через захищений environment-файл, доступний лише root, або systemd unit, а не зберігайте ключі в історії shell. Альтернатива — окремий backup VPS через SSH, BorgBackup або rsync через SSH із ключем, обмеженим лише командою резервного копіювання.

Скрипт і cron

cat > /usr/local/sbin/backup-coturn.sh <<'EOF'
#!/bin/sh
set -eu
. /root/.config/restic/env
restic backup /etc/turnserver.conf /etc/coturn /etc/letsencrypt /etc/caddy
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
EOF
chmod 700 /usr/local/sbin/backup-coturn.sh

cat > /etc/cron.d/backup-coturn <<'EOF'
17 3   * root /usr/local/sbin/backup-coturn.sh >> /var/log/backup-coturn.log 2>&1
EOF

Файл /root/.config/restic/env повинен мати права 600 і містити змінні Restic. Раз на квартал виконуйте тестове відновлення на окремій машині: резервна копія без перевірки відновлення не є надійною резервною копією.

Оновлення та вікно обслуговування

Оновлення безпеки Ubuntu можна встановлювати регулярно, але оновлення Coturn, OpenSSL або перезапуск служби можуть перервати активні relay allocations. Для невеликого сервісу виберіть коротке вікно обслуговування, заздалегідь попередьте користувачів і виконайте:

apt update
apt list --upgradable
apt upgrade -y
systemctl restart coturn
systemctl status coturn --no-pager
journalctl -u coturn -n 50 --no-pager

Для високої доступності використовуйте щонайменше два TURN-вузли в різних зонах і повертайте клієнтам кілька URL в iceServers. Тоді оновлення можна виконувати по черзі: припинити видачу вузлом нових credentials, дочекатися завершення дзвінків, оновити його та повернути до пулу.

Усунення несправностей + поширені запитання

Чому браузер не використовує relay-кандидата, хоча Coturn запущено?

Це не завжди помилка. WebRTC надає перевагу прямому маршруту host або server-reflexive, якщо він працює. Щоб перевірити TURN, протестуйте двох клієнтів із різних мереж, наприклад мобільного інтернету та корпоративної мережі. У chrome://webrtc-internals перегляньте вибрану пару кандидатів. Якщо relay-кандидати взагалі не з’являються, перевірте правильність URL, тимчасових credentials, DNS, доступність 3478/udp і рядки журналу Coturn із помилками автентифікації.

Помилка 401 Unauthorized або Wrong credentials під час підключення до TURN: що робити?

Перевірте, що backend і Coturn використовують той самий static-auth-secret. Ім’я користувача має містити майбутню часову позначку Unix, а пароль має бути Base64 від HMAC-SHA1 саме рядка username. Поширена помилка — використовувати HMAC-SHA256, hex-кодування замість Base64 або часову позначку в мілісекундах. Також синхронізуйте час сервера за допомогою systemd-timesyncd або chrony: Coturn відхилить прострочені credentials.

Чому TURN через UDP працює, а turns:// на 5349 не підключається?

Спочатку перевірте openssl s_client із параметром -servername. Якщо сертифікат не читається, перевірте права доступу до privkey.pem, групу ssl-cert і журнал journalctl -u coturn. Потім переконайтеся, що 5349/tcp відкрито в UFW і зовнішньому firewall панелі провайдера. Перевірте, чи збігається DNS-ім’я в сертифікаті з ім’ям у TURN URL, інакше браузер відхилить TLS-з’єднання.

Чому дзвінки працюють удома, але не працюють із мобільної чи корпоративної мережі?

Домашня мережа може дозволяти P2P, тому TURN там не використовується. У проблемній мережі UDP часто заблоковано або NAT симетричний. Переконайтеся, що ви надаєте клієнту не лише turn: з UDP, а й варіант TCP на 3478, а також turns: на 5349. Перевірте, чи не ввімкнено no-tcp-relay, якщо вашим клієнтам потрібен саме TCP relay, а не лише TCP-підключення до сервера.

Що означає помилка Allocate request timed out?

Зазвичай запит дійшов до Coturn, але сервер не зміг створити або використати relay-сокет. Перевірте external-ip, relay-ip, діапазон min-port/max-port і дозвіл цього діапазону в UFW та мережевому firewall. На VPS за приватним NAT обов’язково вкажіть відповідність публічної та внутрішньої IP-адрес у форматі external-ip=PUBLIC/PRIVATE. Також перевірте, чи не вичерпано вузький relay-діапазон за великої кількості дзвінків.

Яка мінімальна конфігурація VPS підійде?

Для розробки, тестування та десятків нечастих дзвінків достатньо 1 vCPU, 1 ГБ RAM, 10 ГБ SSD і публічної IPv4-адреси. Для невеликого production-сервісу розумний мінімум — 2 vCPU, 2 ГБ RAM, 20 ГБ SSD і канал 1 Гбіт/с. Оцінюйте не лише обчислювальні ресурси: TURN споживає трафік в обох напрямках, тому ліміт включених гігабайтів і якість мережі часто важливіші за RAM.

Що вибрати для цього завдання — VPS чи dedicated?

VPS підходить більшості невеликих і середніх WebRTC-проєктів: Coturn не потребує багато дискового простору й легко масштабується додаванням нових вузлів. Вибирайте dedicated за стабільного високого навантаження, вимог до передбачуваного packet rate, гігабітів relay-трафіку або потреби в багатьох публічних IP. Почніть із VPS-вузла, параметри якого можна вимірювати, збирайте метрики реальних дзвінків і переходьте на dedicated лише за підтвердженого мережевого або CPU-навантаження.

Чи можна використовувати порт 443 для TURN, якщо його вже зайнято HTTPS-сайтом?

На одній IP-адресі й одному TCP-порті неможливо одночасно безпосередньо приймати з’єднання HTTPS-сайту й TURN-TLS без спеціального L4-мультиплексування. Стандартний і простий варіант — HTTPS/WSS на 443, TURN-TLS на 5349. Якщо користувачі перебувають за дуже суворим firewall, використовуйте окрему IP-адресу для TURN на 443 або окремий TURN-вузол. Не намагайтеся розв’язати проблему звичайним HTTP reverse proxy: TURN не є HTTP-протоколом.

Висновки та наступні кроки

Тепер у вас є Coturn TURN/STUN-сервер з обмеженим relay-діапазоном, TLS-сертифікатом, захистом firewall і безпечною авторизацією з коротким строком дії. Така схема дає змогу клієнтам WebRTC надійно переходити на relay-маршрут, коли пряме P2P-з’єднання неможливе.

1. Інтегруйте генерацію REST credentials в авторизований backend і видавайте їх лише учасникам активного дзвінка.
2. Додайте моніторинг доступності портів, строку дії TLS-сертифіката, CPU, трафіку та кількості allocations.
3. У разі зростання аудиторії розгорніть кілька регіональних Coturn-вузлів і поступово оновлюйте їх, не зупиняючи всю мережу.