Kwa nini simu za WebRTC zinahitaji seva ya TURN hata kidogo?

WebRTC hujaribu kuunganisha washiriki moja kwa moja, na mara nyingi hufanikiwa. Pande zote mbili zikiwa nyuma ya NAT linganifu au firewall inayotupa UDP — Wi-Fi ya hoteli, mitandao ya ofisi, baadhi ya watoa huduma wa simu — hakuna njia ya moja kwa moja na simu hushindwa kimya kimya. Seva ya TURN hupitisha sauti na video hasa kwa simu kama hizo; sehemu inayotajwa mara nyingi ni karibu simu moja kati ya kumi.

Je, TURN inaweza kuendeshwa kwenye mpango wa NAT?

Hapana. Wateja huunganisha kwenye UDP na TCP 3478 na kwenye safu ya bandari za relay, na mpango wa NAT unapokea kutoka nje bandari yako ya SSH pekee. Unahitaji mpango wenye IPv4 yake.

Inatumia kipimo data kiasi gani?

Kila mkondo unaopitishwa hupita kwenye seva mara mbili — unaingia kutoka upande mmoja, unatoka kwenda upande mwingine. Simu ya video ya mtu mmoja kwa mmoja kwa 1–2 Mbit/s kila upande ni Mbit/s chache kwenye seva. CPU na RAM karibu havitambui; kikomo halisi ni bandari ya 1 Gbit/s.

Kwa nini nisiweke tu jina la mtumiaji na nywila ya kudumu kwenye programu?

Kwa sababu kila kilicho kwenye JavaScript ya kivinjari ni cha umma, na seva ya TURN yenye nywila inayojulikana ni relay ya bure kwa intaneti nzima. Kwa use-auth-secret, backend yako hutoa vitambulisho vinavyoisha muda, vilivyotiwa saini kwa siri ambayo kivinjari hakiioni kamwe.

Je, nahitaji TLS kwenye bandari 5349?

Husaidia kwenye mitandao inayozuia UDP na iliyo kali kwa TCP ya kawaida. Iongeze baada ya TURN ya kawaida kufanya kazi: mpe coturn cheti cha jina la mwenyeji wa TURN na ufungue 5349/tcp. Tulijaribu pia relay kupitia TLS.

VPS kwa seva ya TURN (coturn) kwa WebRTC

Simu zinazoshindwa nyuma ya NAT kali zinahitaji relay ya TURN. coturn kwenye seva yenye IPv4 yake: bandari, vitambulisho vya muda na usanidi uliojaribiwa.

Programu yako ya WebRTC inafanya kazi kwenye Wi-Fi yako na inashindwa kwa mteja yule mmoja anayepiga kutoka hotelini. Sauti na video za peer-to-peer zinahitaji njia kati ya pande mbili; zote zikiwa nyuma ya NAT kali, au firewall ikitupa UDP, hakuna njia na simu haiunganishwi tu. Hakuna anayeona hitilafu — ni «inaunganisha…» isiyoisha tu.

Seva ya TURN ndiyo njia mbadala kwa simu hizo hasa: pande zote mbili hutuma sauti na video kwake, nayo huzipitisha. Ikiwa unaweka video au sauti kwenye programu, unaendesha Matrix au Jitsi kwa timu, au unatengeneza gumzo la sauti kwa mchezo, unahitaji moja. coturn ndiyo utekelezaji huria wa kawaida, na ni mwepesi.

Mpango upi

TURN hutumia CPU na kumbukumbu kidogo sana. Inachotumia ni kipimo data: kila mkondo unaopitishwa hupita kwenye seva mara mbili, kuingia na kutoka. Trafiki kwenye mipango yetu haina kikomo kwa 1 Gbit/s, kwa hiyo swali ni simu ngapi zinazopitishwa zinaendelea kwa wakati mmoja, si utatozwa kiasi gani.

Simu zinazopitishwa kwa wakati mmoja	Mpango
Chache — timu, programu ndogo	Nano-IP: 2 vCPU, 1 GB, 15 GB ($8/mwezi)
Makumi	Micro-IP: 2 vCPU, 2 GB, 25 GB ($10/mwezi)
Zaidi, au TURN kando ya seva ya programu	Small-IP: 4 vCPU, 4 GB, 35 GB ($16/mwezi)

Lazima uwe mpango wenye IPv4 yake — TURN inahusu miunganisho inayoingia kwenye bandari nyingi, na mipango ya NAT inapokea kutoka nje SSH pekee. Kwenye mipango yetu yenye IP yake, anwani ya umma iko moja kwa moja kwenye kiolesura cha seva, kwa hiyo coturn huipata bila mstari wa external-ip. Weka seva karibu na watumiaji wako: Ujerumani au Ufini, upatikanaji unaonekana wakati wa kuagiza. Malipo kwa crypto, bila KYC, kama hilo ni muhimu kwako.

Bandari za kufungua: 3478 UDP na TCP, 49152–65535 UDP kwa sauti na video zinazopitishwa, na 5349 TCP ukiongeza TLS.

Usakinishaji na usanidi

Kama root kwenye Ubuntu 24.04 au Debian 12:

apt install -y coturn
ip -4 addr    # IP yako ya umma inapaswa kuonekana kwenye kiolesura

Andika usanidi kwa siri mpya ya pamoja:

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"    # backend yako inahitaji thamani hii
systemctl restart coturn
ufw allow 22/tcp && ufw allow 3478 && ufw allow 49152:65535/udp && ufw enable

Usiruke mistari ya denied-peer-ip. Bila hiyo, yeyote mwenye vitambulisho halali anaweza kutumia relay yako kufikia anwani za faragha — ikiwemo huduma za upande wa ndani wa seva yenyewe. Tulikagua: kwa mistari hii, relay kwenda anwani ya faragha inakataliwa kwa «403 Forbidden IP».

Vitambulisho vinavyoisha muda

Kwa use-auth-secret, coturn hukubali jina la mtumiaji lenye muda wa kuisha na nywila iliyo HMAC yake. Backend yako ndiyo huvitengeneza; siri haitoki kamwe upande wa seva. Kwa Node.js:

const crypto = require("crypto");

// Jina la mtumiaji/nenosiri la muda la TURN (mpango wa TURN REST API ambao coturn huuelewa kupitia 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")));

Kwenye kivinjari, omba jozi mpya kutoka backend na uipe 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,
    },
  ],
});

Ijaribu

Kutoka kwenye seva, kwa mpango ule ule ukitumia openssl (hutoa nywila ile ile kabisa kama msimbo wa Node.js — tulilinganisha):

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

Mwishoni unataka kuona «Total lost packets 0». Kwa nywila isiyo sahihi, mteja husimama kwenye «Cannot complete Allocation» — hiyo ni seva ikifanya kazi yake.

Pia tulikagua kutoka Chromium halisi: kwa iceTransportPolicy: "relay" na vitambulisho vipya, kivinjari kilipata relay candidates kutoka seva; kwa nywila mbaya, hakuna hata kimoja. Ukitaka kujaribu mpangilio wako kwa njia hiyo hiyo, washa chaguo hilo kwa muda — linalazimisha kila simu kupita kwenye TURN.

TLS, ukiihitaji

Baadhi ya mitandao huzuia UDP na huchagua sana kuhusu TCP ya kawaida; TURN juu ya TLS hupita katika mingi zaidi kati yake. Pata cheti cha turn.example.com (certbot inafaa). Faili zake zinasomwa na root pekee, wakati coturn huendeshwa kama mtumiaji turnserver, kwa hiyo mpe coturn nakala yake:

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

Ongeza turns:turn.example.com:5349?transport=tcp kwenye orodha ya urls. Vyeti huishi muda mfupi, kwa hiyo weka unakili kwenye deploy hook ya certbot — la sivyo TLS itavunjika kimya kimya kwenye usasishaji wa kwanza.

Vizuri kujua

TURN haifanyi muunganisho mbaya kuwa mzuri. Inaongeza hatua moja, kwa hiyo weka seva karibu na wanaoihitaji.
Ukiendesha SFU — kwa mfano videobridge ya Jitsi — hiyo ni sehemu tofauti. TURN huwasaidia wateja wasioweza kuifikia moja kwa moja.
Siri ndiyo mfumo mzima wa usalama. Iweke mbali na frontend, na uibadilishe ikiwahi kuvuja.

Zinazohusiana

VPS kwa Jitsi Meet: simu za video kwenye seva yako
Endesha Matrix Synapse mwenyewe: simu za Matrix pia zinahitaji seva ya TURN
VPS kwa tovuti kwenye IP yako: programu inayotoa vitambulisho
Jinsi ya kusanidi firewall ya ufw