Cum se configurează un server TURN extern pentru Jitsi în spatele NAT

Cel mai important aspect: un server TURN extern ar trebui configurat ca rezervă pentru clienții care nu pot stabili o cale WebRTC utilizabilă din cauza NAT sau a firewall-urilor restrictive. Nu înlocuiește Jitsi Videobridge (JVB) în întâlnirile normale cu mai multe părți. Dacă serverul Jitsi în sine se află în spatele NAT, trebuie să faceți totuși JVB accesibil de pe internet, de obicei pe UDP 10000, sau să configurați corect adresa publică anunțată a bridge-ului.

Pentru implementările Jitsi actuale, cel mai curat design este de obicei o gazdă coturn accesibilă publicului cu un nume DNS precum turn.example.com, acreditări limitate în timp furnizate de Prosody prin XEP-0215 ​​și TURN peste UDP/TCP plus TURN peste TLS pentru rețele restrictive. Documentația actuală TURN a Jitsi recomandă în mod explicit acreditările dinamice în loc să se integreze un nume de utilizator și o parolă permanente în configurația browserului. Consultați documentația oficială de configurare Jitsi TURN .

Când un server TURN extern este soluția potrivită

Folosește TURN atunci când unii participanți pot deschide pagina web Jitsi, dar nu pot stabili conexiuni media fiabile, în special din rețele corporative, Wi-Fi hotelier, campusuri, operatori de telefonie mobilă, VPN-uri sau alte medii care blochează sau filtrează puternic UDP. TURN este util și pentru apelurile Jitsi unu-la-unu atunci când conectivitatea peer-to-peer nu poate fi stabilită direct.

Nu considerați TURN ca prima soluție pentru o configurație greșită a unui Jitsi Videobridge. Ghidul oficial Jitsi Debian/Ubuntu spune că atunci când serverul se află în spatele NAT, routerul trebuie să redirecționeze porturile necesare, iar bridge-ul poate necesita o mapare explicită a adreselor locale-publice. În mod implicit, porturile importante orientate către Jitsi sunt TCP 443 și UDP 10000. Consultați ghidul actual de auto-găzduire Jitsi pentru Debian/Ubuntu înainte de a adăuga TURN.

Pasul 1: Pregătiți o gazdă TURN publică și un DNS

Cea mai simplă topologie este o mașină virtuală sau un server separat cu o adresă IP publică. Creați o înregistrare A sau AAAA, cum ar fi turn.example.comaceasta, care să se rezolve la gazda respectivă. Un nume de gazdă dedicat este util în special dacă oferiți ulterior TURN peste TLS, deoarece certificatul trebuie să corespundă numelui de gazdă utilizat de clienți.

Dacă gazda TURN se află ea însăși în spatele NAT-ului, coturn trebuie să știe adresa publică pe care ar trebui să o promoveze. Coturn acceptă o external-ipmapare, inclusiv perechi public/privat, cum ar fi external-ip=203.0.113.10/192.168.1.10. Documentația sa menționează, de asemenea, că porturile de retransmisie trebuie mapate în mod consecvent prin NAT. Consultați exemplul oficial de configurare coturn .

Pasul 2: Instalați coturn

Pe un sistem Debian sau Ubuntu compatibil, instalați coturn din depozitul de distribuție:

sudo apt update
sudo apt install coturn

Versiunile pachetului variază în funcție de versiunea sistemului de operare, așadar nu copiați un număr de versiune dintr-o captură de ecran sau de pe un alt server. După instalare, confirmați că unitatea de service există și că pachetul a fost instalat turnserver.

Pasul 3: Configurați coturn pentru autentificarea cu secret partajat

Pentru Jitsi, o configurație practică de producție folosește mecanismul de secret partajat al coturn, astfel încât Prosody să poată genera acreditări TURN temporare. Folosiți același secret pe ambele părți. Un punct de plecare minim arată astfel:

listening-port=3478
tls-listening-port=5349
realm=turn.example.com

fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_A_LONG_RANDOM_SECRET

min-port=49160
max-port=49200

no-multicast-peers
no-cli

Dacă gazda TURN se află în spatele NAT, adăugați external-ipmaparea corespunzătoare. Dacă activați TURN prin TLS, configurați certși pkeycu un certificat de încredere pentru turn.example.com. Documentația oficială a containerului coturn explică faptul că TURN utilizează un interval de porturi de retransmitere pentru media și că intervalul poate fi restrâns cu min-portși max-port. Consultați documentația oficială a containerului coturn Docker pentru același comportament al porturilor de retransmitere.

Pasul 4: Deschideți porturile de ascultare și de retransmitere

O eroare frecventă este deschiderea doar a porților 3478 sau 5349, uitându-se intervalul de retransmisie. Listener-ul Coturn acceptă conexiunea TURN inițială, dar mediul de retransmisie utilizează porturi de retransmisie alocate. Dacă ați ales 49160-49200, permiteți același interval prin firewall-ul gazdă, grupul de securitate cloud și orice NAT din amonte.

sudo ufw allow 3478/udp
sudo ufw allow 3478/tcp
sudo ufw allow 5349/tcp
sudo ufw allow 49160:49200/udp

Dacă aveți nevoie de cea mai largă compatibilitate cu rețelele corporative blocate, ghidul TURN de la Jitsi descrie servirea TURN prin TLS pe ​​TCP 443. Aceasta poate necesita un nume de gazdă TURN dedicat și, atunci când HTTPS web partajează aceeași adresă publică, multiplexare TLS SNI. Nu mutați orbește TURN la 443 decât dacă înțelegeți ce deține deja acel port.

Pasul 5: Configurați Jitsi pentru a face publicitate serviciului TURN extern

Pe o implementare curentă de pachete Debian/Ubuntu Jitsi, Prosody folosește mod_external_servicescodul STUN/TURN pentru a publica informații către clienți. Exemplul Prosody al lui Jitsi folosește un external_service_secretplus și un external_servicestabel cu secret = true. Secretul partajat trebuie să corespundă codului . al codului coturn static-auth-secret.

external_service_secret = "REPLACE_WITH_THE_SAME_LONG_RANDOM_SECRET";

external_services = {
    { type = "stun", host = "turn.example.com", port = 3478 },
    { type = "turn", host = "turn.example.com", port = 3478,
       transport = "udp", secret = true, ttl = 86400, algorithm = "turn" },
    { type = "turns", host = "turn.example.com", port = 5349,
       transport = "tcp", secret = true, ttl = 86400, algorithm = "turn" }
};

Păstrați modulele existente și setările specifice site-ului în fișierul Prosody generat de Jitsi; nu înlocuiți întregul fișier cu fragmentul de cod de mai sus. Numele exact al fișierului urmează în mod normal domeniului de implementare sub /etc/prosody/conf.d/. Exemplul de configurare Jitsi din amonte poate fi verificat în depozitul oficial Jitsi .

Dacă utilizați implementarea oficială Docker, este de preferat variabilele de mediu documentate ale acesteia în locul editării manuale a fișierelor Prosody generate. Documentația Docker actuală expune TURN_CREDENTIALS, TURN_HOST, TURN_PORT, , TURN_TRANSPORT, TURNS_HOSTși TURNS_PORT. Consultați ghidul curent de auto-găzduire Jitsi Docker, deoarece valorile implicite ale variabilelor se pot schimba între versiuni.

Pasul 6: Reporniți și validați serviciile

După schimbarea coturn-ului, reporniți-l și verificați starea acestuia:

sudo systemctl restart coturn
sudo systemctl status coturn
sudo ss -lntup | grep -E '3478|5349'

După modificarea configurației Prosody, validați sintaxa acesteia dacă pachetul Prosody oferă verificatorul, apoi reporniți Prosody. În funcție de ce ați modificat în Jitsi, poate fi potrivită și repornirea serviciilor Jitsi relevante:

sudo prosodyctl check config
sudo systemctl restart prosody

O stare curată a serviciului coturn dovedește doar că daemonul rulează. Nu dovedește că acreditările se potrivesc, că intervalul de retransmisie este accesibil sau că un browser poate obține un candidat de retransmisie.

Pasul 7: Testați dacă TURN poate transmite efectiv media

Testarea din aceeași rețea locală nu este suficientă. Folosiți cel puțin un client dintr-o rețea diferită, ideal o conexiune mobilă sau o rețea despre care se știe că restricționează UDP. În diagnosticarea WebRTC a browserului, căutați un candidat ICE de tip relay. Un candidat de retransmisie înseamnă că browserul a obținut cu succes acreditările TURN și a creat o alocare TURN.

De asemenea, urmăriți jurnalele coturn în timp ce utilizatorul de test se conectează. Ar trebui să vedeți alocări autentificate și trafic de retransmitere atunci când este selectat TURN. Dacă observați erori de autentificare, comparați coturn static-auth-secretcu secretul de acreditare TURN din Prosody sau Docker. Dacă alocările reușesc, dar mediul tot eșuează, verificați firewall-ul portului de retransmitere și maparea NAT.

Nu forțați TURN doar să demonstreze că serverul există, decât dacă aveți un motiv controlat pentru testare. În condiții normale, ICE alege cea mai bună cale de lucru. Prin urmare, o implementare reușită poate avea multe întâlniri care nu necesită niciodată TURN.

Pasul 8: Păstrați configurația JVB NAT separat de depanarea TURN

Acesta este punctul care previne cea mai mare pierdere de timp în depanare. Un server Jitsi în spatele NAT necesită în continuare configurarea corectă a accesibilității publice a podului. Ghidul actual de pornire rapidă Jitsi spune că podul se configurează în mod normal automat, dar dacă apelurile mai mari eșuează, puteți adăuga o mapare statică ice4j.harvest.mappingsub /etc/jitsi/videobridge/jvb.conf:

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "192.168.1.20"
          public-address = "203.0.113.20"
        }
      ]
    }
  }
}

Redirecționați UDP 10000 de la marginea publică către gazda JVB și asigurați-vă că adresa publică este cea pe care clienții la distanță o pot accesa efectiv. TURN poate ajuta clienții din rețele restrictive, dar nu ar trebui utilizat pentru a ascunde o mapare NAT JVB defectă.

Listă de verificare rapidă pentru depanare

• Numele de gazdă TURN nu se rezolvă: corectați DNS-ul înainte de a testa Jitsi.
• 3478/5349 ascultă local, dar nu de la distanță: inspectează firewall-ul gazdă, firewall-ul cloud, NAT-ul routerului și filtrarea furnizorului.
• Acreditările eșuează: verificați dacă secretul partajat este identic în configurația Coturn și Jitsi/Prosody.
• Apare un candidat de retransmisie, dar mediul eșuează: verificați dacă intervalul de porturi de retransmisie configurat este deschis de la un capăt la altul.
• Doar apelurile cu mai multe părți eșuează: verificați JVB UDP 10000 și anunțul JVB pe adresă publică.
• Doar rețelele corporative eșuează: adăugați sau verificați TURN prin TLS, adesea pe TCP 443, acolo unde este cazul.
• Modificările din Docker dispar după repornire: configurați variabilele acceptate .envîn loc să editați fișierele generate în interiorul containerelor.

Cum arată un rezultat corect

O configurație sănătoasă are trei comportamente observabile. În primul rând, utilizatorii obișnuiți pot accesa direct Jitsi Videobridge fără TURN atunci când rețelele lor permit acest lucru. În al doilea rând, utilizatorii din rețele restrictive pot primi acreditări TURN temporare și pot obține un relaycandidat ICE. În al treilea rând, coturn afișează alocări autentificate doar atunci când este necesar, în loc să realizeze fiecare întâlnire în mod implicit.

Această combinație vă oferă o soluție utilă fără a transforma serverul TURN într-un blocaj inutil al lățimii de bandă. De asemenea, menține depanarea curată: problemele JVB NAT rămân probleme JVB, în timp ce TURN rezolvă problema mai restrânsă a conectivității WebRTC atunci când rutele directe sunt blocate.