WebRTC के लिए TURN सर्वर (coturn) का VPS

आपका WebRTC ऐप आपके Wi-Fi पर चलता है और ठीक उसी ग्राहक के लिए फ़ेल होता है जो होटल से कॉल करता है। पीयर-टू-पीयर मीडिया को दोनों तरफ़ के बीच रास्ता चाहिए; जब दोनों सख़्त NAT के पीछे हों, या फ़ायरवॉल UDP गिरा दे, तो रास्ता नहीं होता और कॉल बस जुड़ती ही नहीं। किसी को कोई एरर नहीं दिखती — बस अंतहीन “कनेक्ट हो रहा है…”।

TURN सर्वर ठीक इन्हीं कॉल का बैकअप है: दोनों तरफ़ अपना मीडिया उसे भेजते हैं, और वह आगे पहुँचाता है। अगर आप किसी ऐप में वीडियो या आवाज़ जोड़ रहे हैं, टीम के लिए Matrix या Jitsi चला रहे हैं, या किसी गेम के लिए वॉइस चैट बना रहे हैं, तो आपको एक चाहिए। coturn मानक ओपन-सोर्स इम्प्लीमेंटेशन है, और हल्का है।

कौन-सा प्लान

TURN पर CPU और मेमोरी का ख़र्च कम है। यह बैंडविड्थ इस्तेमाल करता है: हर रिले स्ट्रीम सर्वर से दो बार गुज़रती है, अंदर और बाहर। हमारे प्लान पर ट्रैफ़िक 1 Gbit/s पर असीमित है, इसलिए सवाल यह है कि एक साथ कितनी रिले कॉल चलती हैं, यह नहीं कि बिल कितना आएगा।

प्लान अपने IPv4 वाला होना चाहिए — TURN पूरी तरह कई पोर्ट पर आने वाले कनेक्शन का मामला है, और NAT प्लान बाहर से सिर्फ़ SSH स्वीकार करते हैं। हमारे अलग IP वाले प्लान पर सार्वजनिक पता सीधे सर्वर के इंटरफ़ेस पर होता है, इसलिए coturn उसे external-ip लाइन के बिना ढूँढ लेता है। सर्वर अपने यूज़र्स के पास रखें: जर्मनी या फ़िनलैंड, उपलब्धता ऑर्डर करते समय दिखती है। अगर आपके लिए मायने रखता है तो क्रिप्टो में भुगतान, बिना KYC के।

खोलने वाले पोर्ट: 3478 UDP और TCP, रिले मीडिया के लिए 49152–65535 UDP, और TLS जोड़ें तो 5349 TCP।

इंस्टॉल और कॉन्फ़िगर करें

Ubuntu 24.04 या Debian 12 पर root के रूप में:

apt install -y coturn
ip -4 addr    # आपका पब्लिक IP इंटरफ़ेस पर दिखना चाहिए

नए साझा सीक्रेट के साथ कॉन्फ़िग लिखें:

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"    # यह वैल्यू आपके बैकएंड को चाहिए
systemctl restart coturn
ufw allow 22/tcp && ufw allow 3478 && ufw allow 49152:65535/udp && ufw enable

denied-peer-ip लाइनें न छोड़ें। इनके बिना वैध क्रेडेंशियल वाला कोई भी आपके रिले से निजी पतों तक पहुँच सकता है — सर्वर के अपने अंदरूनी हिस्से की सेवाओं तक भी। हमने जाँचा: इन लाइनों के साथ निजी पते पर रिले “403 Forbidden IP” के साथ ठुकरा दिया जाता है।

समय-सीमा वाले क्रेडेंशियल

use-auth-secret के साथ coturn ऐसा यूज़रनेम स्वीकार करता है जिसमें समाप्ति का समय हो, और ऐसा पासवर्ड जो उसका HMAC हो। इन्हें आपका बैकएंड बनाता है; सीक्रेट सर्वर की तरफ़ से कभी बाहर नहीं जाता। Node.js में:

const crypto = require("crypto");

// TURN के लिए अस्थायी यूज़रनेम/पासवर्ड (TURN REST API स्कीम, जिसे coturn use-auth-secret के ज़रिए समझता है)।
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")));

ब्राउज़र में बैकएंड से नई जोड़ी माँगें और उसे RTCPeerConnection को दें:

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,
    },
  ],
});

जाँचें

सर्वर से, उसी तरीक़े से openssl का उपयोग करके (यह Node.js कोड जैसा ही पासवर्ड बनाता है — हमने मिलाकर देखा):

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

आख़िर में आपको “Total lost packets 0” दिखना चाहिए। ग़लत पासवर्ड के साथ क्लाइंट “Cannot complete Allocation” पर रुक जाता है — यानी सर्वर अपना काम कर रहा है।

हमने असली Chromium से भी जाँचा: iceTransportPolicy: "relay" और ताज़ा क्रेडेंशियल के साथ ब्राउज़र को सर्वर से relay कैंडिडेट मिले; ग़लत पासवर्ड पर एक भी नहीं। अगर आप अपना सेटअप इसी तरह जाँचना चाहते हैं, तो यह विकल्प थोड़ी देर के लिए चालू करें — यह हर कॉल को TURN से गुज़रने पर मजबूर करता है।

TLS, अगर ज़रूरत हो

कुछ नेटवर्क UDP ब्लॉक करते हैं और सादे TCP पर नख़रे करते हैं; TLS पर TURN उनमें से ज़्यादा को पार कर लेता है। turn.example.com के लिए सर्टिफ़िकेट लें (certbot ठीक है)। उसकी फ़ाइलें सिर्फ़ root पढ़ सकता है, जबकि coturn turnserver यूज़र के रूप में चलता है, इसलिए coturn को उसकी अपनी कॉपी दें:

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 सूची में turns:turn.example.com:5349?transport=tcp जोड़ें। सर्टिफ़िकेट कम समय चलते हैं, इसलिए कॉपी को certbot के deploy hook में रखें — वरना पहले नवीनीकरण पर TLS चुपचाप टूट जाएगा।

जानने लायक़

• TURN ख़राब कनेक्शन को अच्छा नहीं बनाता। यह एक हॉप जोड़ता है, इसलिए सर्वर उन लोगों के पास रखें जिन्हें उसकी ज़रूरत है।
• अगर आप SFU चलाते हैं — जैसे Jitsi का videobridge — तो वह अलग हिस्सा है। TURN उन क्लाइंट की मदद करता है जो उस तक सीधे नहीं पहुँच पाते।
• पूरी सुरक्षा व्यवस्था सीक्रेट पर टिकी है। उसे फ़्रंटएंड से दूर रखें, और अगर कभी लीक हो जाए तो बदल दें।

संबंधित

• Jitsi Meet के लिए VPS: अपने सर्वर पर वीडियो कॉल
• अपना Matrix Synapse: Matrix की कॉल को भी TURN सर्वर चाहिए
• अपने IP पर वेबसाइट के लिए VPS: वह ऐप जो क्रेडेंशियल देता है
• ufw फ़ायरवॉल कैसे सेट करें