Come configurare un server TURN esterno per Jitsi dietro NAT

Il punto più importante: un server TURN esterno dovrebbe essere configurato come soluzione di ripiego per i client che non riescono a stabilire un percorso WebRTC utilizzabile a causa di NAT o firewall restrittivi. Non sostituisce Jitsi Videobridge (JVB) nelle normali riunioni multipartecipante. Se il server Jitsi si trova dietro un NAT, è comunque necessario rendere JVB raggiungibile da Internet, normalmente sulla porta UDP 10000, oppure configurare correttamente l'indirizzo pubblico pubblicizzato del bridge.

Per le attuali implementazioni di Jitsi, la configurazione più pulita prevede solitamente un host coturn accessibile pubblicamente con un nome DNS come turn.example.com, credenziali a tempo limitato fornite da Prosody tramite XEP-0215 ​​e TURN su UDP/TCP, oltre a TURN su TLS per le reti con restrizioni. La documentazione TURN di Jitsi raccomanda esplicitamente l'utilizzo di credenziali dinamiche anziché l'inserimento di un nome utente e una password permanenti nella configurazione del browser. Consultare la documentazione ufficiale di configurazione di Jitsi TURN .

Quando un server TURN esterno è la soluzione giusta

Utilizzate TURN quando alcuni partecipanti possono aprire la pagina web di Jitsi ma non riescono a stabilire una connessione affidabile, soprattutto da reti aziendali, Wi-Fi di hotel, campus universitari, operatori di telefonia mobile, VPN o altri ambienti che bloccano o filtrano pesantemente il protocollo UDP. TURN è utile anche per le chiamate Jitsi individuali quando non è possibile stabilire una connessione peer-to-peer diretta.

Non considerate TURN come la prima soluzione per un Jitsi Videobridge configurato in modo errato. La guida ufficiale di Jitsi per Debian/Ubuntu afferma che, quando il server si trova dietro un NAT, il router deve inoltrare le porte necessarie e il bridge potrebbe richiedere una mappatura esplicita degli indirizzi locali a quelli pubblici. Per impostazione predefinita, le porte importanti rivolte a Jitsi sono TCP 443 e UDP 10000. Consultate la guida aggiornata all'hosting self-service di Jitsi per Debian/Ubuntu prima di aggiungere TURN.

Passaggio 1: Preparare un host TURN pubblico e un DNS

La topologia più semplice prevede una macchina virtuale o un server separato con un indirizzo IP pubblico. Crea un record A o AAAA che turn.example.comsi risolva in quell'host. Un nome host dedicato è particolarmente utile se in seguito offri TURN su TLS, poiché il certificato deve corrispondere al nome host utilizzato dai client.

Se l'host TURN si trova a sua volta dietro un NAT, coturn deve conoscere l'indirizzo pubblico da pubblicizzare. Coturn supporta una external-ipmappatura, incluse coppie pubblico/privato come external-ip=203.0.113.10/192.168.1.10. La sua documentazione indica inoltre che le porte di inoltro devono essere mappate in modo coerente tramite NAT. Fare riferimento alla configurazione di esempio ufficiale di coturn .

Passaggio 2: Installare coturn

Su un sistema Debian o Ubuntu supportato, installa coturn dal repository della distribuzione:

sudo apt update
sudo apt install coturn

Le versioni dei pacchetti variano a seconda della versione del sistema operativo, quindi non copiare il numero di versione da uno screenshot o da un altro server. Dopo l'installazione, verificare che l'unità di servizio esista e che il pacchetto sia stato installato correttamente turnserver.

Passaggio 3: Configurare coturn per l'autenticazione tramite chiave condivisa

Per Jitsi, una configurazione di produzione pratica utilizza il meccanismo di segreto condiviso di coturn, in modo che Prosody possa generare credenziali TURN temporanee. Utilizza lo stesso segreto da entrambe le parti. Un punto di partenza minimo potrebbe essere questo:

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

Se l'host TURN si trova dietro un NAT, aggiungere la external-ipmappatura appropriata. Se si abilita TURN su TLS, configurare certe pkeycon un certificato attendibile per turn.example.com. La documentazione ufficiale del container coturn spiega che TURN utilizza un intervallo di porte relay per i media e che l'intervallo può essere ristretto con min-porte max-port. Consultare la documentazione ufficiale di coturn Docker per lo stesso comportamento delle porte relay.

Passaggio 4: Aprire le porte listener e relay

Un errore comune è quello di aprire solo la porta 3478 o 5349 dimenticando l'intervallo di inoltro. Il listener di Coturn accetta la connessione TURN iniziale, ma i media inoltrati utilizzano le porte di inoltro allocate. Se hai scelto questa opzione 49160-49200, consenti lo stesso intervallo attraverso il firewall dell'host, il gruppo di sicurezza cloud e qualsiasi NAT a monte.

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

Se hai bisogno della massima compatibilità con le reti aziendali protette, la guida TURN di Jitsi descrive come utilizzare TURN su TLS sulla porta TCP 443. Ciò potrebbe richiedere un nome host TURN dedicato e, quando HTTPS condivide lo stesso indirizzo pubblico, il multiplexing TLS SNI. Non spostare TURN sulla porta 443 senza prima aver compreso chi la utilizza già.

Passaggio 5: Configurare Jitsi per pubblicizzare il servizio TURN esterno

Su una distribuzione corrente del pacchetto Jitsi per Debian/Ubuntu, Prosody utilizza mod_external_servicesper pubblicare le informazioni STUN/TURN ai client. L'esempio Prosody di Jitsi utilizza un external_service_secretpiù una external_servicestabella con secret = true. Il segreto condiviso deve corrispondere a quello di 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" }
};

Mantieni i moduli esistenti e le impostazioni specifiche del sito nel file Prosody generato da Jitsi; non sostituire l'intero file con il frammento di codice sopra riportato. Il nome esatto del file di solito segue il dominio di distribuzione in /etc/prosody/conf.d/. L'esempio di configurazione Jitsi originale può essere consultato nel repository ufficiale di Jitsi .

Se si utilizza la distribuzione Docker ufficiale, è preferibile utilizzare le variabili d'ambiente documentate anziché modificare manualmente i file Prosody generati. La documentazione Docker attuale espone TURN_CREDENTIALS, TURN_HOST, TURN_PORT, TURN_TRANSPORT, TURNS_HOST, e TURNS_PORT. Consultare la guida all'hosting self-service Docker di Jitsi, poiché i valori predefiniti delle variabili possono cambiare tra le diverse versioni.

Passaggio 6: riavviare e convalidare i servizi

Dopo aver modificato coturn, riavvialo e verifica il suo stato:

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

Dopo aver modificato la configurazione di Prosody, se il pacchetto Prosody in uso fornisce lo strumento di verifica, convalidane la sintassi e poi riavvia Prosody. A seconda delle modifiche apportate a Jitsi, potrebbe essere opportuno anche riavviare i relativi servizi di Jitsi.

sudo prosodyctl check config
sudo systemctl restart prosody

Uno stato del servizio coturn pulito dimostra solo che il demone è in esecuzione. Non dimostra che le credenziali corrispondano, che il range di relay sia raggiungibile o che un browser possa ottenere un candidato relay.

Passaggio 7: Verificare che TURN sia effettivamente in grado di inoltrare i contenuti multimediali

Eseguire i test dalla stessa LAN non è sufficiente. Utilizzare almeno un client su una rete diversa, idealmente una connessione mobile o una rete nota per limitare il protocollo UDP. Nella diagnostica WebRTC del browser, cercare un candidato ICE di tipo relay. Un candidato relay significa che il browser ha ottenuto correttamente le credenziali TURN e creato un'allocazione TURN.

Monitora anche i log di coturn mentre l'utente di test si connette. Dovresti vedere allocazioni autenticate e traffico di inoltro quando viene selezionato TURN. Se riscontri errori di autenticazione, confronta coturn static-auth-secretcon il segreto delle credenziali di Prosody o Docker TURN. Se le allocazioni hanno successo ma il traffico multimediale continua a non funzionare, controlla il firewall della porta di inoltro e il mapping NAT.

Non forzare TURN solo per dimostrare l'esistenza del server, a meno che non si abbia un valido motivo per un test controllato. In condizioni normali, ICE sceglie il percorso di lavoro migliore. Un'implementazione riuscita può quindi prevedere numerose riunioni che non richiedono mai l'utilizzo di TURN.

Passaggio 8: Mantenere la configurazione NAT JVB separata dalla risoluzione dei problemi TURN

Questo è il punto che previene la maggior parte delle perdite di tempo nella risoluzione dei problemi. Un server Jitsi dietro NAT necessita comunque che la raggiungibilità pubblica del bridge sia configurata correttamente. L'attuale guida rapida di Jitsi afferma che il bridge normalmente si configura automaticamente, ma se le chiamate più grandi falliscono, è possibile aggiungere una mappatura statica ice4j.harvest.mappingin /etc/jitsi/videobridge/jvb.conf:

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

Inoltra il traffico UDP sulla porta 10000 dal bordo pubblico all'host JVB e assicurati che l'indirizzo pubblico sia quello effettivamente raggiungibile dai client remoti. TURN può essere utile per i client su reti con restrizioni, ma non dovrebbe essere utilizzato per nascondere un problema di mappatura NAT JVB.

Lista di controllo rapida per la risoluzione dei problemi

• Il nome host TURN non si risolve: correggere il DNS prima di testare Jitsi.
• 3478/5349 ascoltano localmente ma non da remoto: ispeziona il firewall dell'host, il firewall cloud, il NAT del router e il filtro del provider.
• Credenziali non valide: verificare che il segreto condiviso sia identico in coturn e nella configurazione di Jitsi/Prosody.
• Il candidato per il relay risulta presente, ma il supporto di memorizzazione non funziona: verificare che l'intervallo di porte relay configurato sia aperto end-to-end.
• Solo le chiamate multiparte falliscono: verificare JVB UDP 10000 e l'annuncio dell'indirizzo pubblico JVB.
• Solo le reti aziendali presentano problemi: aggiungere o verificare TURN su TLS, spesso sulla porta TCP 443, ove appropriato.
• Le modifiche apportate a Docker scompaiono dopo il riavvio: configura le .envvariabili supportate anziché modificare i file generati all'interno dei container.

Come si presenta un risultato corretto

Una configurazione ottimale presenta tre comportamenti osservabili. In primo luogo, gli utenti ordinari possono accedere direttamente a Jitsi Videobridge senza TURN quando le loro reti lo consentono. In secondo luogo, gli utenti con reti restrittive possono ricevere credenziali TURN temporanee e ottenere un relaycandidato ICE. In terzo luogo, coturn mostra le assegnazioni autenticate solo quando necessario, anziché trasmettere automaticamente ogni riunione.

Questa combinazione offre un'utile soluzione di ripiego senza trasformare il server TURN in un inutile collo di bottiglia per la larghezza di banda. Inoltre, semplifica la risoluzione dei problemi: i problemi NAT di JVB rimangono problemi di JVB, mentre TURN risolve il problema più specifico della connettività WebRTC quando i percorsi diretti sono bloccati.