Cómo configurar un servidor TURN externo para Jitsi detrás de NAT

Lo más importante: se debe configurar un servidor TURN externo como alternativa para los clientes que no puedan establecer una conexión WebRTC utilizable debido a NAT o cortafuegos restrictivos. No sustituye al Jitsi Videobridge (JVB) en reuniones multipartitas normales. Si su servidor Jitsi se encuentra detrás de NAT, deberá hacer que el JVB sea accesible desde Internet, normalmente mediante UDP 10000, o configurar correctamente la dirección IP pública anunciada del puente.

Para las implementaciones actuales de Jitsi, el diseño más limpio suele ser un host coturn accesible públicamente con un nombre DNS como turn.example.com, credenciales con tiempo limitado proporcionadas por Prosody a través de XEP-0215, y TURN sobre UDP/TCP más TURN sobre TLS para redes restrictivas. La documentación actual de Jitsi TURN recomienda explícitamente credenciales dinámicas en lugar de incorporar un nombre de usuario y contraseña permanentes en la configuración del navegador. Consulte la documentación oficial de configuración de Jitsi TURN .

Cuando un servidor TURN externo es la solución adecuada

Utilice TURN cuando algunos participantes puedan abrir la página web de Jitsi, pero no puedan establecer una conexión fiable, especialmente desde redes corporativas, Wi-Fi de hoteles, campus universitarios, operadores móviles, VPN u otros entornos que bloqueen o filtren fuertemente el protocolo UDP. TURN también es útil para llamadas individuales de Jitsi cuando no se puede establecer una conexión directa entre pares.

No considere TURN como la primera solución para un Jitsi Videobridge mal configurado. La guía oficial de Jitsi para Debian/Ubuntu indica que, cuando el servidor está detrás de NAT, el enrutador debe reenviar los puertos necesarios y el puente podría requerir una asignación explícita de direcciones locales a públicas. Por defecto, los puertos importantes para Jitsi son TCP 443 y UDP 10000. Consulte la guía actual de Jitsi para Debian/Ubuntu sobre autoalojamiento antes de añadir TURN.

Paso 1: Prepare un host TURN público y un DNS.

La topología más sencilla consiste en una máquina virtual o servidor independiente con una dirección IP pública. Cree un registro A o AAAA que turn.example.comapunte a ese host. Un nombre de host dedicado resulta especialmente útil si posteriormente ofrece TURN sobre TLS, ya que el certificado debe coincidir con el nombre de host que utilizan los clientes.

Si el host TURN se encuentra detrás de NAT, coturn necesita conocer la dirección pública que debe anunciar. Coturn admite un external-ipmapeo, incluyendo pares público/privado como external-ip=203.0.113.10/192.168.1.10. Su documentación también indica que los puertos de retransmisión deben mapearse de forma consistente a través de NAT. Consulte la configuración de ejemplo oficial de coturn .

Paso 2: Instalar coturn

En un sistema Debian o Ubuntu compatible, instale coturn desde el repositorio de la distribución:

sudo apt update
sudo apt install coturn

Las versiones de los paquetes varían según la versión del sistema operativo, así que no copie un número de versión de una captura de pantalla o de otro servidor. Después de la instalación, confirme que la unidad de servicio existe y que el paquete se ha instalado turnserver.

Paso 3: Configurar coturn para la autenticación con clave compartida.

Para Jitsi, una configuración de producción práctica utiliza el mecanismo de clave compartida de coturn para que Prosody pueda generar credenciales TURN temporales. Utilice la misma clave en ambos lados. Un punto de partida mínimo se ve así:

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

Si el host TURN está detrás de NAT, agregue la external-ipasignación correspondiente. Si habilita TURN sobre TLS, configure certy pkeycon un certificado de confianza para turn.example.com. La documentación oficial del contenedor coturn explica que TURN usa un rango de puertos de retransmisión para los medios y que el rango se puede reducir con min-porty max-port. Consulte la documentación oficial de Docker de coturn para el mismo comportamiento de los puertos de retransmisión.

Paso 4: Abra los puertos de escucha y retransmisión.

Un error común es abrir solo los puertos 3478 o 5349 sin tener en cuenta el rango de retransmisión. El receptor de Coturn acepta la conexión TURN inicial, pero los medios retransmitidos utilizan los puertos de retransmisión asignados. Si elige esta opción 49160-49200, permita ese mismo rango a través del firewall del host, el grupo de seguridad de la nube y cualquier NAT ascendente.

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

Si necesita la máxima compatibilidad con redes corporativas restringidas, la guía de Jitsi sobre TURN describe cómo implementar TURN mediante TLS en el puerto TCP 443. Esto puede requerir un nombre de host dedicado para TURN y, cuando HTTPS web comparte la misma dirección pública, multiplexación TLS SNI. No migre TURN al puerto 443 sin antes comprender qué servidor ya lo utiliza.

Paso 5: Configure Jitsi para anunciar el servicio TURN externo.

En una implementación actual del paquete Jitsi de Debian/Ubuntu, Prosody utiliza mod_external_servicespara publicar información STUN/TURN a los clientes. El propio ejemplo de Prosody de Jitsi utiliza un external_service_secretmás una external_servicestabla con secret = true. El secreto compartido debe coincidir con el de 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" }
};

Conserva los módulos existentes y la configuración específica del sitio en tu archivo Prosody generado por Jitsi; no reemplaces todo el archivo con el fragmento anterior. El nombre exacto del archivo normalmente sigue a tu dominio de implementación en /etc/prosody/conf.d/. El ejemplo de configuración de Jitsi original se puede consultar en el repositorio oficial de Jitsi .

Si utiliza la implementación oficial de Docker, prefiera sus variables de entorno documentadas en lugar de editar manualmente los archivos Prosody generados. La documentación actual de Docker expone TURN_CREDENTIALS, TURN_HOST, TURN_PORT, TURN_TRANSPORT, TURNS_HOST, y TURNS_PORT. Revise la guía actual de autoalojamiento de Jitsi Docker, ya que los valores predeterminados de las variables pueden cambiar entre versiones.

Paso 6: Reinicie y valide los servicios.

Después de cambiar el retorno de carro, reinícielo y compruebe su estado:

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

Tras modificar la configuración de Prosody, valide su sintaxis si su paquete de Prosody incluye el verificador y, a continuación, reinicie Prosody. Dependiendo de los cambios realizados en Jitsi, también puede ser conveniente reiniciar los servicios de Jitsi correspondientes.

sudo prosodyctl check config
sudo systemctl restart prosody

Un estado de servicio coturn limpio solo demuestra que el demonio está en ejecución. No demuestra que las credenciales coincidan, que el rango de relés sea accesible o que un navegador pueda obtener un candidato de relé.

Paso 7: Compruebe que TURN realmente puede transmitir contenido multimedia.

No basta con realizar pruebas desde la misma LAN. Utilice al menos un cliente en una red diferente, idealmente una conexión móvil o una red que se sabe que restringe UDP. En el diagnóstico WebRTC del navegador, busque un candidato ICE de tipo relay. Un candidato de retransmisión significa que el navegador obtuvo correctamente las credenciales TURN y creó una asignación TURN.

También revise los registros de coturn mientras el usuario de prueba se une. Debería ver asignaciones autenticadas y tráfico de retransmisión cuando se selecciona TURN. Si observa fallos de autenticación, compare el registro de coturn static-auth-secretcon la clave secreta de Prosody o Docker TURN. Si las asignaciones se realizan correctamente, pero el tráfico multimedia sigue fallando, revise el firewall del puerto de retransmisión y la asignación NAT.

No fuerces el uso de TURN simplemente para comprobar la existencia del servidor, a menos que tengas una razón válida para realizar una prueba controlada. En condiciones normales, ICE elige la mejor ruta de trabajo. Por lo tanto, una implementación exitosa puede incluir muchas reuniones que no requieran el uso de TURN.

Paso 8: Mantenga la configuración NAT de JVB separada de la resolución de problemas de TURN.

Este es el punto que evita la mayor parte del tiempo de resolución de problemas. Un servidor Jitsi detrás de NAT todavía necesita que la accesibilidad pública del puente esté configurada correctamente. La guía de inicio rápido actual de Jitsi dice que el puente normalmente se autoconfigura, pero si las llamadas más grandes fallan, puede agregar una asignación estática ice4j.harvest.mappingen /etc/jitsi/videobridge/jvb.conf:

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

Reenvía el tráfico UDP 10000 desde el borde público al host JVB y asegúrate de que la dirección pública sea la que los clientes remotos puedan alcanzar. TURN puede ser útil para clientes en redes restrictivas, pero no debe usarse para ocultar un mapeo NAT JVB defectuoso.

Lista de verificación para la resolución rápida de problemas

• El nombre de host de TURN no se resuelve: corrija el DNS antes de probar Jitsi.
• 3478/5349 escuchan localmente pero no de forma remota: inspeccionar el firewall del host, el firewall de la nube, el NAT del enrutador y el filtrado del proveedor.
• Las credenciales fallan: verifique que el secreto compartido sea idéntico en coturn y en la configuración de Jitsi/Prosody.
• Aparece un candidato para el relé, pero falla la conexión multimedia: verifique que el rango de puertos de relé configurado esté abierto de extremo a extremo.
• Solo fallan las llamadas multiparte: compruebe JVB UDP 10000 y el anuncio de megafonía de JVB.
• Solo fallan las redes corporativas: agregue o verifique TURN sobre TLS, a menudo en el puerto TCP 443 cuando sea apropiado.
• Los cambios realizados en Docker desaparecen tras reiniciar: configure las .envvariables compatibles en lugar de editar los archivos generados dentro de los contenedores.

Así es como se ve un resultado correcto.

Una configuración óptima presenta tres comportamientos observables. Primero, los usuarios comunes pueden acceder a Jitsi Videobridge directamente sin TURN cuando sus redes lo permiten. Segundo, los usuarios en redes con restricciones pueden recibir credenciales TURN temporales y obtener un relaycandidato ICE. Tercero, coturn muestra las asignaciones autenticadas solo cuando es necesario, en lugar de gestionar todas las reuniones por defecto.

Esta combinación ofrece una solución alternativa útil sin convertir el servidor TURN en un cuello de botella innecesario en el ancho de banda. Además, simplifica la resolución de problemas: los problemas de NAT de JVB siguen siendo problemas de JVB, mientras que TURN resuelve el problema específico de la conectividad WebRTC cuando las rutas directas están bloqueadas.