WebRTC için TURN sunucusu (coturn) için VPS

WebRTC uygulamanız kendi Wi-Fi'ınızda çalışıyor ve otelden arayan o tek müşteride başarısız oluyor. Eşler arası medya iki taraf arasında bir yola ihtiyaç duyar; ikisi de katı NAT arkasındaysa veya bir güvenlik duvarı UDP'yi düşürüyorsa yol yoktur ve arama bir türlü bağlanmaz. Kimse hata görmez — yalnızca bitmek bilmeyen bir „bağlanıyor…”.

TURN sunucusu tam da bu aramalar için yedek yoldur: iki taraf da medyasını ona gönderir, o da aktarır. Bir uygulamaya görüntü veya ses ekliyorsanız, ekip için Matrix ya da Jitsi çalıştırıyorsanız veya bir oyun için sesli sohbet yapıyorsanız, bir tane istersiniz. coturn standart açık kaynaklı uygulamadır ve hafiftir.

Hangi plan

TURN, CPU ve bellek açısından ucuzdur. Kullandığı şey bant genişliğidir: aktarılan her akış sunucudan iki kez geçer, içeri ve dışarı. Planlarımızda trafik 1 Gbit/s'de sınırsızdır; yani soru, ne kadar fatura edileceğiniz değil, aynı anda kaç aktarılan arama olduğudur.

Kendi IPv4'ü olan bir plan olmalı — TURN tamamen çok sayıda porttaki gelen bağlantılarla ilgilidir ve NAT planları dışarıdan yalnızca SSH kabul eder. Ayrı IP'li planlarımızda genel adres doğrudan sunucunun arayüzündedir, bu yüzden coturn onu external-ip satırı olmadan bulur. Sunucuyu kullanıcılarınıza yakın koyun: Almanya veya Finlandiya, uygunluk sipariş sırasında görünür. Sizin için önemliyse kriptoyla ödeme, KYC yok.

Açılacak portlar: UDP ve TCP 3478, aktarılan medya için UDP 49152–65535, TLS eklerseniz TCP 5349.

Kurulum ve yapılandırma

Ubuntu 24.04 veya Debian 12 üzerinde root olarak:

apt install -y coturn
ip -4 addr    # genel IP adresiniz arayüzde görünmeli

Yapılandırmayı yeni bir paylaşılan sırla yazın:

SECRET=$(openssl rand -hex 32)
cat > /etc/turnserver.conf <<EOF
listening-port=3478
fingerprint
use-auth-secret
static-auth-secret=$SECRET
realm=turn.example.com
min-port=49152
max-port=65535
no-cli
no-multicast-peers
denied-peer-ip=0.0.0.0-0.255.255.255
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=100.64.0.0-100.127.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=169.254.0.0-169.254.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.168.0.0-192.168.255.255
EOF
echo "$SECRET"    # bu değer arka ucunuza lazım
systemctl restart coturn
ufw allow 22/tcp && ufw allow 3478 && ufw allow 49152:65535/udp && ufw enable

denied-peer-ip satırlarını atlamayın. Bunlar olmadan geçerli kimlik bilgilerine sahip herkes aktarıcınızı özel adreslere ulaşmak için kullanabilir — sunucunun kendi iç tarafındaki servisler dahil. Kontrol ettik: bu satırlarla özel bir adrese aktarma „403 Forbidden IP” ile reddedilir.

Süresi dolan kimlik bilgileri

use-auth-secret ile coturn, son kullanma zamanı içeren bir kullanıcı adını ve onun HMAC'i olan bir parolayı kabul eder. Bunları arka ucunuz üretir; sır sunucu tarafından hiç çıkmaz. Node.js'te:

const crypto = require("crypto");

// Geçici TURN kullanıcı adı/parolası (coturn'ün use-auth-secret ile anladığı TURN REST API şeması).
function turnCredentials(secret, user, ttlSeconds = 3600) {
  const username = `${Math.floor(Date.now() / 1000) + ttlSeconds}:${user}`;
  const credential = crypto.createHmac("sha1", secret).update(username).digest("base64");
  return { username, credential };
}

console.log(JSON.stringify(turnCredentials(process.env.TURN_SECRET, "alice")));

Tarayıcıda arka ucunuzdan yeni bir çift isteyin ve RTCPeerConnection'a verin:

const { username, credential } = await fetch("/api/turn-credentials").then((r) => r.json());

const pc = new RTCPeerConnection({
  iceServers: [
    { urls: "stun:turn.example.com:3478" },
    {
      urls: ["turn:turn.example.com:3478?transport=udp", "turn:turn.example.com:3478?transport=tcp"],
      username,
      credential,
    },
  ],
});

Test edin

Sunucudan, aynı şemayla openssl kullanarak (Node.js koduyla tam olarak aynı parolayı üretir — karşılaştırdık):

U="$(( $(date +%s) + 3600 )):test"
P=$(echo -n "$U" | openssl dgst -binary -sha1 -hmac "$SECRET" | base64)
turnutils_uclient -y -n 10 -u "$U" -w "$P" YOUR_SERVER_IP

Sonunda görmek istediğiniz „Total lost packets 0”. Yanlış parolayla istemci „Cannot complete Allocation” noktasında durur — bu, sunucunun işini yaptığı anlamına gelir.

Gerçek bir Chromium'dan da kontrol ettik: iceTransportPolicy: "relay" ve taze kimlik bilgileriyle tarayıcı sunucudan relay adayları aldı; hatalı parolayla hiç almadı. Kendi kurulumunuzu aynı şekilde test etmek isterseniz bu seçeneği bir anlığına açın — her aramayı TURN üzerinden geçmeye zorlar.

Gerekirse TLS

Bazı ağlar UDP'yi engeller ve düz TCP konusunda seçicidir; TLS üzerinden TURN bunların daha fazlasından geçer. turn.example.com için bir sertifika alın (certbot yeterli). Dosyalarını yalnızca root okuyabilir, coturn ise turnserver kullanıcısı olarak çalışır; bu yüzden coturn'e kendi kopyasını verin:

mkdir -p /etc/coturn
cp /etc/letsencrypt/live/turn.example.com/fullchain.pem /etc/letsencrypt/live/turn.example.com/privkey.pem /etc/coturn/
chown turnserver: /etc/coturn/*.pem && chmod 640 /etc/coturn/privkey.pem
cat >> /etc/turnserver.conf <<'EOF'
tls-listening-port=5349
cert=/etc/coturn/fullchain.pem
pkey=/etc/coturn/privkey.pem
EOF
systemctl restart coturn && ufw allow 5349/tcp

urls listesine turns:turn.example.com:5349?transport=tcp ekleyin. Sertifikalar kısa ömürlüdür, bu yüzden kopyalamayı bir certbot deploy hook'una koyun — aksi halde TLS ilk yenilemede sessizce bozulur.

Bilmekte fayda var

• TURN kötü bir bağlantıyı iyi yapmaz. Bir atlama ekler, bu yüzden sunucuyu ona ihtiyaç duyanlara yakın konumlandırın.
• Bir SFU çalıştırıyorsanız — örneğin Jitsi'nin videobridge'i — bu ayrı bir parçadır. TURN, ona doğrudan ulaşamayan istemcilere yardım eder.
• Güvenlik modelinin tamamı sırdır. Onu ön uçtan uzak tutun ve bir gün sızarsa değiştirin.

İlgili

• Jitsi Meet için VPS: kendi sunucunuzda görüntülü aramalar
• Matrix Synapse'i kendiniz barındırın: Matrix aramaları da bir TURN sunucusuna ihtiyaç duyar
• Kendi IP'sinde bir web sitesi için VPS: kimlik bilgilerini dağıtan uygulama
• ufw güvenlik duvarı nasıl yapılandırılır