آپ کی WebRTC ایپ آپ کے Wi-Fi پر چلتی ہے اور ٹھیک اسی گاہک کے لیے ناکام ہوتی ہے جو ہوٹل سے کال کرتا ہے۔ پیئر ٹو پیئر میڈیا کو دونوں طرف کے درمیان راستہ چاہیے؛ جب دونوں سخت NAT کے پیچھے ہوں، یا فائر وال UDP گرا دے، تو راستہ نہیں ہوتا اور کال جڑتی ہی نہیں۔ کسی کو کوئی ایرر نظر نہیں آتی — بس نہ ختم ہونے والا «کنیکٹ ہو رہا ہے…»۔
TURN سرور ٹھیک انہی کالز کا متبادل راستہ ہے: دونوں طرف اپنا میڈیا اسے بھیجتے ہیں، اور وہ آگے پہنچاتا ہے۔ اگر آپ کسی ایپ میں ویڈیو یا آواز ڈال رہے ہیں، ٹیم کے لیے Matrix یا Jitsi چلا رہے ہیں، یا کسی گیم کے لیے وائس چیٹ بنا رہے ہیں، تو آپ کو ایک چاہیے۔ coturn معیاری اوپن سورس امپلیمنٹیشن ہے، اور ہلکا ہے۔
کون سا پلان
TURN پر CPU اور میموری کا خرچ کم ہے۔ یہ بینڈوڈتھ استعمال کرتا ہے: ہر ریلے اسٹریم سرور سے دو بار گزرتی ہے، اندر اور باہر۔ ہمارے پلانز پر ٹریفک 1 Gbit/s پر لامحدود ہے، اس لیے سوال یہ ہے کہ ایک ساتھ کتنی ریلے کالز چلتی ہیں، یہ نہیں کہ بل کتنا آئے گا۔
| ایک ساتھ ریلے ہونے والی کالز | پلان |
|---|---|
| چند — ایک ٹیم، ایک چھوٹی ایپ | Nano-IP: 2 vCPU، 1 GB، 15 GB ($8/ماہ) |
| درجنوں | Micro-IP: 2 vCPU، 2 GB، 25 GB ($10/ماہ) |
| اور زیادہ، یا ایپ سرور کے ساتھ TURN | Small-IP: 4 vCPU، 4 GB، 35 GB ($16/ماہ) |
پلان اپنے 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 ان کلائنٹس کی مدد کرتا ہے جو اس تک سیدھے نہیں پہنچ پاتے۔
- پوری سکیورٹی کا دارومدار سیکرٹ پر ہے۔ اسے فرنٹ اینڈ سے دور رکھیں، اور اگر کبھی لیک ہو جائے تو بدل دیں۔
متعلقہ
- سرور VPS برائے Jitsi Meet: اپنے سرور پر ویڈیو کالز
- اپنا Matrix Synapse: Matrix کی کالز کو بھی TURN سرور چاہیے
- اپنے IP پر ویب سائٹ کے لیے سرور VPS: وہ ایپ جو اسناد دیتی ہے
- فائر وال ufw کیسے سیٹ کریں
تبصرے
ابھی کوئی تبصرہ نہیں۔ پہلے بنیں۔