Cómo co­n­fi­gu­rar un servidor TURN para Nextcloud Talk paso a paso

Nextcloud Talk permite realizar llamadas de audio y vídeo di­re­c­ta­me­n­te desde Nextcloud. En una red local o cuando la conexión a Internet no presenta re­s­tri­c­cio­nes es­pe­cia­les, suele funcionar sin necesidad de realizar ajustes adi­cio­na­les. Sin embargo, cuando los pa­r­ti­ci­pa­n­tes se en­cue­n­tran detrás de co­r­ta­fue­gos re­s­tri­c­ti­vos, en redes co­r­po­ra­ti­vas o en entornos con de­te­r­mi­na­das co­n­fi­gu­ra­cio­nes NAT, puede que no sea posible es­ta­ble­cer una conexión directa. En estos casos, un servidor TURN para Nextcloud Talk permite mantener la co­mu­ni­ca­ción.

¿Qué es un Nextcloud TURN server?

Un servidor TURN actúa como in­te­r­me­dia­rio: en lugar de in­te­r­ca­m­biar los datos de audio y vídeo di­re­c­ta­me­n­te entre los pa­r­ti­ci­pa­n­tes, el tráfico se transmite a través del servidor TURN. Nextcloud Talk intenta primero es­ta­ble­cer una conexión directa entre los pa­r­ti­ci­pa­n­tes (peer-to-peer). Para ello, puede utilizar un servidor STUN que le ayude a de­te­r­mi­nar la dirección IP pública y la in­fo­r­ma­ción de conexión necesaria. Si no es posible es­ta­ble­cer la conexión directa, recurre al servidor TURN como al­te­r­na­ti­va. Por eso, contar con un servidor TURN propio es re­co­me­n­da­ble para mejorar la fia­bi­li­dad de las llamadas, es­pe­cia­l­me­n­te cuando pa­r­ti­ci­pan usuarios externos o se utilizan redes re­s­tri­c­ti­vas.

¿Qué necesitas para co­n­fi­gu­rar un servidor TURN para Nextcloud Talk?

Antes de empezar, debes tener una in­s­ta­la­ción de Nextcloud en fu­n­cio­na­mie­n­to con la apli­ca­ción Nextcloud Talk activada. Nextcloud Talk necesita una conexión segura mediante HTTPS para utilizar WebRTC. Por tanto, tu instancia de Nextcloud debe ser accesible mediante HTTPS y contar con un ce­r­ti­fi­ca­do TLS válido.

El alo­ja­mie­n­to co­m­pa­r­ti­do presenta li­mi­ta­cio­nes para in­s­ta­la­cio­nes de Talk con muchos usuarios, ya que las llamadas pueden generar una carga adicional en el servidor. Además, para utilizar tu propio servidor TURN, necesitas control sobre los puertos de red y la po­si­bi­li­dad de ejecutar un servicio de forma pe­r­ma­ne­n­te.

Para seguir esta guía, necesitas:

• Una in­s­ta­la­ción de Nextcloud con Nextcloud Talk activado
• Permisos de ad­mi­ni­s­tra­ción en Nextcloud
• Un servidor Linux en el que puedas instalar software
• Acceso SSH con permisos sudo o de root
• Una dirección IPv4 pública
• Un dominio o su­b­do­mi­nio
• Acceso a la co­n­fi­gu­ra­ción DNS del dominio
• Un co­r­ta­fue­gos en el que puedas abrir puertos TCP y UDP

Puedes utilizar, por ejemplo, Ubuntu Server 26.04 LTS, Ubuntu 24.04 LTS o una versión actual de Debian. En esta guía uti­li­za­re­mos el dominio turn.example.com como ejemplo para acceder al servidor TURN. Recuerda su­s­ti­tui­r­lo por tu propio dominio en todos los comandos.

¿Qué servidor elegir para Nextcloud Talk: VPS o servidor dedicado?

Para alojar un servidor TURN para Nextcloud Talk, la potencia de pro­ce­sa­mie­n­to no es el único factor im­po­r­ta­n­te. La conexión de red desempeña un papel fu­n­da­me­n­tal, ya que TURN se encarga de re­tra­n­s­mi­tir los datos de audio y vídeo entre los pa­r­ti­ci­pa­n­tes cuando no es posible es­ta­ble­cer una conexión directa. En estos casos, todo el tráfico mu­l­ti­me­dia de las co­ne­xio­nes que utilizan TURN pasa por el servidor.

Un VPS pequeño o mediano suele ser su­fi­cie­n­te para in­s­ta­la­cio­nes privadas, pequeñas empresas o equipos que realizan pocas llamadas si­mu­l­tá­neas con Nextcloud Talk. Si el VPS se utiliza ex­clu­si­va­me­n­te como servidor TURN, dos CPU virtuales y unos pocos gigabytes de RAM pueden ser su­fi­cie­n­tes. No obstante, es más im­po­r­ta­n­te disponer de una conexión estable, una dirección IP pública y su­fi­cie­n­te capacidad de tra­n­s­fe­re­n­cia de datos.

Si se realizan vi­deo­co­n­fe­re­n­cias fre­cue­n­tes con numerosos pa­r­ti­ci­pa­n­tes si­mu­l­tá­neos, el ancho de banda di­s­po­ni­ble cobra especial im­po­r­ta­n­cia. Para in­s­ta­la­cio­nes de mayor tamaño, puede ser co­n­ve­nie­n­te optar por un VPS más potente, un servidor en la nube o un servidor dedicado. Para in­s­ta­la­cio­nes grandes, se re­co­mie­n­da alojar el servidor TURN en una máquina in­de­pe­n­die­n­te con acceso directo a Internet.

Disponer de un VPS exclusivo para TURN también facilita la co­n­fi­gu­ra­ción de los puertos. Nextcloud re­co­mie­n­da utilizar el puerto 443 para el servicio TURN con el fin de mejorar la co­m­pa­ti­bi­li­dad con redes re­s­tri­c­ti­vas. Si Nextcloud ya se ejecuta en el mismo servidor mediante Apache o NGINX, el puerto TCP 443 suele estar ocupado por HTTPS. Al instalar TURN en un servidor in­de­pe­n­die­n­te, puedes utilizar este puerto sin co­n­fli­c­tos con el servidor web.

Paso 1: co­n­fi­gu­rar un su­b­do­mi­nio para el servidor TURN

Lo primero es asignar un nombre de host al servidor TURN. Para ello, crea, por ejemplo, el siguiente registro A en la co­n­fi­gu­ra­ción de tu proveedor de DNS:

turn.example.com → 203.0.113.10

En este ejemplo, 203.0.113.10 re­pre­se­n­ta la dirección IPv4 pública de tu servidor. Si también dispone de una dirección IPv6 pública, puedes crear un registro AAAA. No obstante, solo debes hacerlo si IPv6 está co­rre­c­ta­me­n­te co­n­fi­gu­ra­do y el servidor TURN es accesible a través de esta dirección.

Los cambios en la co­n­fi­gu­ra­ción DNS pueden tardar algún tiempo en pro­pa­gar­se. Para comprobar que el su­b­do­mi­nio se resuelve co­rre­c­ta­me­n­te, puedes utilizar los comandos dig turn.example.com o nslookup turn.example.com. Si también has creado un registro AAAA, co­m­prué­ba­lo con dig AAAA turn.example.com.

Las di­re­c­cio­nes IP que aparezcan en los re­su­l­ta­dos deben coincidir con las di­re­c­cio­nes públicas de tu servidor, tanto IPv4 como IPv6, si co­rre­s­po­n­de.

Paso 2: co­ne­c­tar­te al servidor y ac­tua­li­zar el sistema

Conéctate al servidor TURN mediante SSH:

ssh usuario@turn.example.com

A co­n­ti­nua­ción, actualiza la lista de paquetes e instala las ac­tua­li­za­cio­nes di­s­po­ni­bles:

sudo apt update
sudo apt upgrade -y

Así te aseguras de partir de un sistema ac­tua­li­za­do antes de continuar con la in­s­ta­la­ción.

Paso 3: instalar coturn

Para co­n­fi­gu­rar el servidor TURN uti­li­za­re­mos coturn, un software di­s­po­ni­ble en los re­po­si­to­rios de Ubuntu y Debian. Puedes in­s­ta­lar­lo di­re­c­ta­me­n­te con el gestor de paquetes:

sudo apt install coturn -y

Una vez co­m­ple­ta­da la in­s­ta­la­ción, comprueba qué versión se ha instalado:

dpkg -s coturn | grep Version

La do­cu­me­n­ta­ción de Nextcloud establece coturn 4.5.0.8 como versión mínima. Sin embargo, para una in­s­ta­la­ción nueva, es re­co­me­n­da­ble utilizar una versión reciente de coturn que reciba ac­tua­li­za­cio­nes de seguridad.

Por último, comprueba que systemd reconoce el servicio:

systemctl status coturn

En las versiones actuales de Ubuntu y Debian, el servicio coturn se ad­mi­ni­s­tra mediante systemd.

Paso 4: generar una clave secreta segura para TURN

Nextcloud Talk y coturn necesitan compartir una clave secreta para generar cre­de­n­cia­les te­m­po­ra­les que permitan acceder al servidor TURN. Puedes crear una clave aleatoria con el siguiente comando:

openssl rand -hex 32

El comando generará una cadena he­xa­de­ci­mal similar a esta:

8c6e8a2a79bd6507e7a5274bc5779ec3a5f6c1f45dbcf420c1a824cd94a25112

Copia la clave generada y guárdala en un lugar seguro. La ne­ce­si­ta­rás más adelante tanto para co­n­fi­gu­rar coturn como para es­ta­ble­cer la au­te­n­ti­ca­ción en los ajustes de Nextcloud Talk.

Al igual que con cualquier co­n­tra­se­ña segura, evita utilizar valores fáciles de adivinar. En un entorno de pro­du­c­ción, genera siempre una clave aleatoria propia y no reuti­li­ces la del ejemplo.

Paso 5: co­n­fi­gu­rar el ce­r­ti­fi­ca­do TLS para TURN

Para ga­ra­n­ti­zar la mayor co­m­pa­ti­bi­li­dad posible, es re­co­me­n­da­ble co­n­fi­gu­rar TURN en el puerto 443 y admitir tanto co­ne­xio­nes co­n­ve­n­cio­na­les (turn:) como co­ne­xio­nes cifradas (turns:). Esto resulta es­pe­cia­l­me­n­te útil en redes re­s­tri­c­ti­vas que solo permiten co­ne­xio­nes a través del puerto 443.

Para admitir co­ne­xio­nes turns:, coturn necesita un ce­r­ti­fi­ca­do TLS. Puedes obtenerlo gra­tui­ta­me­n­te mediante Let’s Encrypt.

Si utilizas un servidor Ubuntu dedicado ex­clu­si­va­me­n­te a TURN, puedes instalar Certbot mediante Snap:

sudo snap install --classic certbot

Si el comando certbot no está di­s­po­ni­ble después de la in­s­ta­la­ción, crea el siguiente enlace:

sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

Antes de solicitar el ce­r­ti­fi­ca­do, abre el puerto TCP 80 en el co­r­ta­fue­gos:

sudo ufw allow 80/tcp

A co­n­ti­nua­ción, solicita el ce­r­ti­fi­ca­do con este comando:

sudo certbot certonly --standalone -d turn.example.com

El modo standalone inicia te­m­po­ra­l­me­n­te un servidor web para verificar que controlas el dominio. Para completar esta va­li­da­ción mediante HTTP-01, el puerto 80 debe ser accesible desde Internet.

Una vez emitido el ce­r­ti­fi­ca­do, en­co­n­tra­rás los archivos co­rre­s­po­n­die­n­tes en las si­guie­n­tes rutas:

/etc/letsencrypt/live/turn.example.com/fullchain.pem
/etc/letsencrypt/live/turn.example.com/privkey.pem

Certbot suele co­n­fi­gu­rar au­to­má­ti­ca­me­n­te la re­no­va­ción de los ce­r­ti­fi­ca­dos. Puedes comprobar que funciona co­rre­c­ta­me­n­te con el siguiente comando:

sudo certbot renew --dry-run

Paso 6: permitir que coturn utilice el puerto 443

En Linux, los puertos in­fe­rio­res al 1024 se co­n­si­de­ran puertos pri­vi­le­gia­dos. Como coturn suele eje­cu­tar­se con un usuario sin pri­vi­le­gios de ad­mi­ni­s­tra­dor, es posible que no pueda abrir di­re­c­ta­me­n­te el puerto 443.

Para so­lu­cio­nar­lo, puedes utilizar las Linux Ca­pa­bi­li­ties, que permiten conceder permisos es­pe­cí­fi­cos a un programa sin necesidad de eje­cu­tar­lo como root.

Ejecuta el siguiente comando para permitir que coturn utilice puertos pri­vi­le­gia­dos:

sudo setcap cap_net_bind_service=+ep /usr/bin/turnserver

Con este ajuste, turnserver obtiene permiso para abrir puertos como el 443 sin recibir todos los pri­vi­le­gios de root.

Ten en cuenta que una ac­tua­li­za­ción del paquete podría eliminar este permiso. Si coturn deja de funcionar en el puerto 443 después de una ac­tua­li­za­ción, comprueba la co­n­fi­gu­ra­ción con:

getcap /usr/bin/turnserver

Paso 7: dar acceso a coturn al ce­r­ti­fi­ca­do TLS

Por motivos de seguridad, la clave privada de Let’s Encrypt no­r­ma­l­me­n­te solo es accesible para el usuario root. Sin embargo, coturn necesita leerla para es­ta­ble­cer co­ne­xio­nes TLS.

Primero, comprueba que el usuario turnserver existe en el sistema:

getent passwd turnserver

A co­n­ti­nua­ción, crea un di­re­c­to­rio protegido donde guardarás las copias del ce­r­ti­fi­ca­do y la clave privada que utilizará coturn:

sudo install -d -m 750 -o root -g turnserver /etc/coturn

Copia ambos archivos al nuevo di­re­c­to­rio y asigna los permisos co­rre­s­po­n­die­n­tes:

sudo install -m 640 -o root -g turnserver \
/etc/letsencrypt/live/turn.example.com/fullchain.pem \
/etc/coturn/fullchain.pem

sudo install -m 640 -o root -g turnserver \
/etc/letsencrypt/live/turn.example.com/privkey.pem \
/etc/coturn/privkey.pem

Si tu di­s­tri­bu­ción utiliza otro usuario o grupo para ejecutar coturn, sustituye turnserver por el co­rre­s­po­n­die­n­te.

Au­to­ma­ti­zar la ac­tua­li­za­ción del ce­r­ti­fi­ca­do

Cuando Let’s Encrypt renueva un ce­r­ti­fi­ca­do, actualiza los archivos ori­gi­na­les, pero no las copias que acabas de crear. Por eso, es re­co­me­n­da­ble co­n­fi­gu­rar un deploy hook de Certbot que copie los archivos renovados y reinicie coturn au­to­má­ti­ca­me­n­te.

Crea el siguiente script:

sudo nano /etc/letsencrypt/renewal-hooks/deploy/coturn.sh

Añade este contenido:

#!/bin/sh
install -m 640 -o root -g turnserver \
/etc/letsencrypt/live/turn.example.com/fullchain.pem \
/etc/coturn/fullchain.pem

install -m 640 -o root -g turnserver \
/etc/letsencrypt/live/turn.example.com/privkey.pem \
/etc/coturn/privkey.pem

systemctl restart coturn

Guarda el archivo y concédele permisos de ejecución:

sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/coturn.sh

De este modo, cada vez que se renueve co­rre­c­ta­me­n­te el ce­r­ti­fi­ca­do, el script ac­tua­li­za­rá las copias y re­ini­cia­rá coturn para que utilice los nuevos archivos.

Paso 8: co­n­fi­gu­rar coturn para Nextcloud Talk

El archivo principal de co­n­fi­gu­ra­ción de coturn suele en­co­n­trar­se en /etc/turnserver.conf tanto en Ubuntu como en Debian.

Antes de mo­di­fi­car­lo, crea una copia de seguridad:

sudo cp /etc/turnserver.conf /etc/turnserver.conf.bak

Después, abre el archivo con un editor de texto:

sudo nano /etc/turnserver.conf

Para una in­s­ta­la­ción habitual de Nextcloud Talk, puedes utilizar la siguiente co­n­fi­gu­ra­ción básica:

listening-port=443

fingerprint
use-auth-secret
static-auth-secret=TU_CLAVE_SECRETA
realm=turn.example.com

cert=/etc/coturn/fullchain.pem
pkey=/etc/coturn/privkey.pem

stale-nonce
no-multicast-peers

total-quota=0
bps-capacity=0

min-port=49152
max-port=65535

Sustituye TU_CLAVE_SECRETA por la clave que generaste en el paso 4 y turn.example.com por el dominio de tu servidor TURN.

Estas son las pri­n­ci­pa­les opciones de co­n­fi­gu­ra­ción:

• listening-port=443: establece el puerto por el que los clientes se conectan al servidor TURN.
• fingerprint: añade una suma de co­m­pro­ba­ción CRC-32 que ayuda a di­s­ti­n­guir los mensajes STUN de los paquetes de otros pro­to­co­los.
• use-auth-secret: activa la au­te­n­ti­ca­ción mediante una clave secreta co­m­pa­r­ti­da con Nextcloud Talk.
• static-auth-secret: contiene la clave secreta que utilizan ambos servicios.
• realm: define el dominio de au­te­n­ti­ca­ción del servidor TURN.
• cert y pkey: indican las rutas del ce­r­ti­fi­ca­do TLS y su clave privada.
• stale-nonce: permite renovar pe­rió­di­ca­me­n­te los valores de au­te­n­ti­ca­ción (nonces).
• no-multicast-peers: impide que coturn re­tra­n­s­mi­ta tráfico a di­re­c­cio­nes multicast.
• total-quota=0 y bps-capacity=0: des­ac­ti­van los límites globales de asi­g­na­cio­nes y ancho de banda, re­s­pe­c­ti­va­me­n­te.
• min-port y max-port: definen el intervalo de puertos UDP uti­li­za­dos para re­tra­n­s­mi­tir el tráfico mu­l­ti­me­dia.

Por defecto, coturn utiliza los puertos UDP del 49152 al 65535 para re­tra­n­s­mi­tir datos. Por tanto, también debes permitir este intervalo en el co­r­ta­fue­gos para que las co­ne­xio­nes TURN funcionen co­rre­c­ta­me­n­te.

Además, coturn puede reconocer au­to­má­ti­ca­me­n­te las co­ne­xio­nes TLS en un puerto de escucha co­n­ve­n­cio­nal, siempre que TLS esté ha­bi­li­ta­do y co­n­fi­gu­ra­do co­rre­c­ta­me­n­te. Esto permite admitir co­ne­xio­nes turn: y turns: a través del puerto 443, lo que mejora la co­m­pa­ti­bi­li­dad con redes re­s­tri­c­ti­vas.

Paso 9: proteger el servidor TURN frente a accesos a redes internas

Un servidor TURN no debe co­n­ve­r­ti­r­se en una vía de acceso a servicios internos de tu servidor o de tu red. Si puede co­mu­ni­car­se con redes privadas, es re­co­me­n­da­ble bloquear ex­plí­ci­ta­me­n­te los rangos de di­re­c­cio­nes IP co­rre­s­po­n­die­n­tes.

Para ello, puedes añadir las si­guie­n­tes líneas al archivo de co­n­fi­gu­ra­ción de coturn:

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.0.0.0-192.0.0.255
denied-peer-ip=192.0.2.0-192.0.2.255
denied-peer-ip=192.88.99.0-192.88.99.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=198.18.0.0-198.19.255.255
denied-peer-ip=198.51.100.0-198.51.100.255
denied-peer-ip=203.0.113.0-203.0.113.255
denied-peer-ip=240.0.0.0-255.255.255.255

Si tu servidor TURN también utiliza IPv6, conviene bloquear los rangos de di­re­c­cio­nes internas co­rre­s­po­n­die­n­tes, como las di­re­c­cio­nes locales únicas (Unique Local Addresses, fc00::/7) y de di­re­c­cio­nes de enlace local (Link Local, fe80::/10):

denied-peer-ip=fc00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
denied-peer-ip=fe80::-febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff

Comprueba también si el servidor TURN puede acceder a otras di­re­c­cio­nes IPv6 de tu in­frae­s­tru­c­tu­ra y, si es necesario, bloquea esos destinos de forma es­pe­cí­fi­ca.

Antes de confiar en estas re­s­tri­c­cio­nes, comprueba el estado del paquete instalado en el registro de seguridad de tu di­s­tri­bu­ción. Ac­tua­l­me­n­te, Debian clasifica coturn 4.6.1 de Bookworm y Trixie como vu­l­ne­ra­ble a CVE-2026-73212, que permite eludir las re­s­tri­c­cio­nes IPv4 en de­te­r­mi­na­das co­n­di­cio­nes de en­ru­ta­mie­n­to.

Paso 10: co­n­fi­gu­rar la dirección IP pública si el servidor está detrás de NAT

Un VPS co­n­ve­n­cio­nal suele disponer de una dirección IP pública asignada di­re­c­ta­me­n­te, lo que si­m­pli­fi­ca la co­n­fi­gu­ra­ción de coturn. Sin embargo, si el servidor TURN se encuentra detrás de NAT, debe conocer la co­rre­s­po­n­de­n­cia entre su dirección IP privada y la pública.

En una co­n­fi­gu­ra­ción sencilla, puedes añadir esta línea al archivo de co­n­fi­gu­ra­ción:

external-ip=203.0.113.10

También puedes indicar ex­plí­ci­ta­me­n­te la relación entre ambas di­re­c­cio­nes:

external-ip=203.0.113.10/10.0.0.10

En este segundo ejemplo, 203.0.113.10 es la dirección IP pública y 10.0.0.10 es la privada. El software coturn utiliza esta in­fo­r­ma­ción para comunicar a los clientes la dirección pública correcta a través de la cual pueden acceder al servicio de re­tra­n­s­mi­sión.

Para que funcione, los puertos co­rre­s­po­n­die­n­tes deben re­di­ri­gi­r­se desde el di­s­po­si­ti­vo NAT al servidor TURN sin modificar sus números.

No añadas external-ip si tu servidor dispone de una dirección IP pública directa y no necesita esta co­n­fi­gu­ra­ción. Una asi­g­na­ción in­co­rre­c­ta puede provocar que el servidor TURN responda a las co­ne­xio­nes iniciales, pero no consiga re­tra­n­s­mi­tir el tráfico mu­l­ti­me­dia.

Paso 11: co­n­fi­gu­rar el co­r­ta­fue­gos

El siguiente paso consiste en abrir los puertos ne­ce­sa­rios para que el servidor TURN sea accesible desde Internet.

Antes de modificar las reglas del co­r­ta­fue­gos, asegúrate de que las co­ne­xio­nes SSH están pe­r­mi­ti­das para no perder el acceso remoto al servidor:

sudo ufw allow OpenSSH

Después, permite las co­ne­xio­nes TURN a través del puerto 443, tanto por TCP como por UDP:

sudo ufw allow 443/tcp
sudo ufw allow 443/udp

También debes abrir el intervalo de puertos UDP que utiliza coturn para re­tra­n­s­mi­tir el tráfico mu­l­ti­me­dia:

sudo ufw allow 49152:65535/udp

Si utilizas Certbot con el método de va­li­da­ción HTTP-01, mantén abierto el puerto TCP 80 para permitir la re­no­va­ción de los ce­r­ti­fi­ca­dos:

sudo ufw allow 80/tcp

Comprueba ahora el estado del co­r­ta­fue­gos:

sudo ufw status

Si UFW todavía no está activado, puedes ha­bi­li­tar­lo con el siguiente comando:

sudo ufw enable

Activa UFW úni­ca­me­n­te después de comprobar que las co­ne­xio­nes SSH están pe­r­mi­ti­das, es­pe­cia­l­me­n­te si ad­mi­ni­s­tras el servidor de forma remota.

Ten en cuenta que algunos pro­vee­do­res de hosting utilizan un co­r­ta­fue­gos adicional a nivel de in­frae­s­tru­c­tu­ra. Si es tu caso, tendrás que abrir los mismos puertos también en ese co­r­ta­fue­gos, ya que las reglas de UFW por sí solas no serán su­fi­cie­n­tes.

Paso 12: iniciar coturn

Una vez co­m­ple­ta­da la co­n­fi­gu­ra­ción, reinicia coturn para aplicar los cambios:

sudo systemctl restart coturn

Activa también el servicio para que se inicie au­to­má­ti­ca­me­n­te cada vez que reinicies el servidor:

sudo systemctl enable coturn

A co­n­ti­nua­ción, comprueba su estado:

sudo systemctl status coturn --no-pager

Si aparece active (running), significa que el servicio está en ejecución.

Para comprobar que coturn está es­cu­cha­n­do en el puerto 443, ejecuta:

sudo ss -lntup | grep ':443'

En los re­su­l­ta­dos deberían aparecer entradas co­rre­s­po­n­die­n­tes a turnserver. Esto confirma que el servicio está es­cu­cha­n­do en ese puerto, aunque todavía tendrás que comprobar que sea accesible desde Internet.

Paso 13: co­n­fi­gu­rar el servidor TURN en Nextcloud Talk

Ahora que coturn está en fu­n­cio­na­mie­n­to, debes indicar a Nextcloud Talk cómo co­ne­c­tar­se al servidor TURN.

Inicia sesión en tu instancia de Nextcloud con una cuenta de ad­mi­ni­s­tra­dor y accede a “Ajustes de ad­mi­ni­s­tra­ción”. Después, abre el apartado de co­n­fi­gu­ra­ción de Talk e introduce la siguiente dirección en el campo del servidor TURN:

turn.example.com:443

No añadas https://, turn: ni turns: delante de la dirección. Nextcloud espera úni­ca­me­n­te el nombre de host y el puerto, mientras que el protocolo se se­le­c­cio­na por separado.

En el campo de la clave secreta TURN, introduce exac­ta­me­n­te el mismo valor que co­n­fi­gu­ra­s­te en static-auth-secret= dentro del archivo /etc/turnserver.conf.

Por último, se­le­c­cio­na las si­guie­n­tes opciones:

• UDP y TCP como pro­to­co­los de tra­n­s­po­r­te.
• La opción para utilizar tanto turn: como turns: y admitir co­ne­xio­nes co­n­ve­n­cio­na­les y cifradas.

De este modo, Nextcloud Talk podrá recurrir a tu servidor TURN cuando no sea posible es­ta­ble­cer una conexión directa entre los pa­r­ti­ci­pa­n­tes.

Paso 14: comprobar que el servidor TURN funciona co­rre­c­ta­me­n­te

Que coturn esté en ejecución no garantiza que sea accesible desde Internet ni que Nextcloud Talk pueda uti­li­zar­lo co­rre­c­ta­me­n­te. Por eso, es im­po­r­ta­n­te comprobar tanto la conexión al servidor como su fu­n­cio­na­mie­n­to durante una llamada.

Siempre que sea posible, realiza las pruebas desde otro equipo conectado a una red diferente, en lugar de eje­cu­tar­las di­re­c­ta­me­n­te en el servidor TURN.

En un sistema Ubuntu, puedes instalar las he­rra­mie­n­tas de prueba de coturn con este comando:

sudo apt install coturn

Después, utiliza turnutils_uclient para comprobar la conexión mediante UDP, TCP y TLS:

turnutils_uclient -p 443 -W TU_CLAVE_SECRETA -v -y turn.example.com

turnutils_uclient -t -p 443 -W TU_CLAVE_SECRETA -v -y turn.example.com

turnutils_uclient -t -S -p 443 -W TU_CLAVE_SECRETA -v -y turn.example.com

Sustituye TU_CLAVE_SECRETA por la clave que generaste en el paso 4.

Estas pruebas permiten comprobar si el servidor TURN es accesible desde el exterior y si puede re­tra­n­s­mi­tir tráfico. Sin embargo, su­pe­rar­las no garantiza que Nextcloud Talk esté uti­li­za­n­do co­rre­c­ta­me­n­te el servidor TURN.

Para co­m­pro­bar­lo, puedes forzar te­m­po­ra­l­me­n­te las co­ne­xio­nes de Nextcloud Talk a través de TURN.

Primero, únete a una llamada de Talk y abre la consola de de­sa­rro­lla­dor del navegador. A co­n­ti­nua­ción, ejecuta este comando:

OCA.Talk.SimpleWebRTC.webrtc.config.peerConnectionConfig.iceTransportPolicy = 'relay'

Después, abandona la llamada y vuelve a unirte.

Con este ajuste, el navegador intentará tra­n­s­mi­tir y recibir el audio y el vídeo ex­clu­si­va­me­n­te a través del servidor TURN. Si la llamada sigue fu­n­cio­na­n­do co­rre­c­ta­me­n­te, significa que Nextcloud Talk puede uti­li­zar­lo para re­tra­n­s­mi­tir el tráfico mu­l­ti­me­dia.

Siempre que puedas, realiza esta prueba con dos di­s­po­si­ti­vos co­ne­c­ta­dos a redes di­fe­re­n­tes.

Co­n­clu­sión: un servidor TURN propio mejora la fia­bi­li­dad de Nextcloud Talk

Nextcloud Talk puede es­ta­ble­cer muchas llamadas sin necesidad de disponer de un servidor TURN propio. Sin embargo, cuando se utiliza ha­bi­tua­l­me­n­te desde redes co­r­po­ra­ti­vas, co­ne­xio­nes móviles o entornos con co­n­fi­gu­ra­cio­nes NAT re­s­tri­c­ti­vas, contar con un servidor TURN propio mejora la fia­bi­li­dad de las co­mu­ni­ca­cio­nes.

Para in­s­ta­la­cio­nes pequeñas y medianas, un VPS in­de­pe­n­die­n­te suele ser una buena opción. Permite ejecutar coturn por separado de Nextcloud y utilizar el puerto 443 para mejorar la co­m­pa­ti­bi­li­dad con redes re­s­tri­c­ti­vas.

En in­s­ta­la­cio­nes más grandes, con numerosas llamadas si­mu­l­tá­neas, el ancho de banda di­s­po­ni­ble es uno de los factores más im­po­r­ta­n­tes. En estos casos, puede ser co­n­ve­nie­n­te optar por un VPS de mayor capacidad o un servidor dedicado.