Como Usar Um Coturno

Configurando e usando o Coturn para WebRTC

Coturn é um servidor TURN/STUN que permite que conexões Peer-to-Peer passem quando NATs e firewalls bloqueiam. A maioria das pessoas tenta implementar e depois descobre que esqueceu a parte do relay. Eu gastei três horas num sábado descobrindo que meus peers estavam caindo porque não tinha configurado o relay corretamente no firewall. O primeiro erro comum é achar que instalar o software resolve. Instalar é rápido. Configurar pra funcionar em produção é o que dá trabalho.

Instalação básica

No Ubuntu/Debian, o comando é direto: sudo apt install coturn Depois você edita o arquivo de configuração em /etc/turnserver.conf. O padrão vem comentado quase tudo. A coisa mais importante é descomentar e preencher as linhas certas.

Minha configuração mínima funcional tem esses parâmetros: listening-port = 3478 tls-listening-port = 5349 static-auth-secret = umavalorfortesuaqvocegera realm = seu.dominio.com.br server-name = turn.seu.dominio.com.br O static-auth-secret precisa ser uma string longa e aleatória. Eu vejo muita gente usando valores frágeis que quebram quando você renova credenciais.

Como usar um coturn na prática

O segredo não é só rodar o serviço. É fazer oICE server correto aparecer nos seus peers. A URL de acesso segue o padrão: turn:suuserver:3478?transport=tcp turns:seuserver:5349?transport=tcp Se você tá usando credenciais temporárias (que todo mundo deveria usar depois de algum tempo), precisa implementar o mecanismo de username gerado dinamicamente. O Coturn suporta isso via usersalt ou integrando com um backend REST.

Uma coisa que não falam muito: se seu servidor tem IP público e está atrás de um NAT, você precisa configurar oexternal-ip. Sem isso, o Coturn anuncia o IP interno e os peers nunca conseguem conectar. Passei duas semanas com esse problema num setup AWS antes de perceber que o atributo estava faltando.

Firewall e portas

Você precisa liberar 3478 (UDP e TCP) e 5349 (TLS). Se for usar relay, o intervalo de portas também precisa estar aberto. No Coturn isso é configurado com min-port e max-port. Recomendo um range de pelo menos 100 portas pra evitar gargalo em salas grandes. O erro clássico aqui é abrir só a porta 3478 e esquecer o range de relay. O TURN funciona, mas só pra sinalização. Quando chega nos dados, tudo trava.

Autenticação e segurança

Coturn tem dois modos principais de auth: flat e nonce. O modo flat usa usuário/senha fixos. O nonce gera credenciais temporárias baseadas em timestamp. Pra produção, use nonce. Configure users no arquivo de config com o formato: user=usuario:senha user=aqui:valor_hash

OU use o modo com realm e users-db pra banco de dados. Eu recomendo users-db se você tiver mais de dez usuários, senão o arquivo fica impossível de manter. Uma armadilha que peguei várias vezes: colocar o realm errado. O realm precisa bater exatamente com o domínio que aparece na URL do ICE server. Se não bater, o peer rejeita o TURN como inválido.

Monitoramento básico

O Coturn expõe estatísticas via turnstats ou você pode rastrear logs em /var/log/turnserver.log. As métricas mais úteis são: número de connections ativas, bytes relayados, e falhas de auth. Se as falhas de auth subirem de repente, alguém tá fazendo scan ou brute force no seu servidor. Uma dica prática: ative o log de connected peers periodicamente. Isso ajuda a detectar se o número de conexões bate com o esperado. Se tiver pico estranho fora do horário de uso, vale investigar.

Quando Coturn não é a solução

Se seu uso é muito leve e todos os peers estão na mesma rede ou atrás de NATs abertos, STUN puro pode resolver. Coturn adiciona overhead de servidor e banda. Também não adianta muito se você precisa de conferência com muitos participantes — aí o caminho é um SFU como Janus ou Mediasoup, não TURN puro. Outro cenário onde Coturn falha: quando o provedor de internet do usuário faz NAPT simétrico muito agressivo e bloqueia UDP. Nesse caso, even TURN TLS não ajuda. Você precisa de fallback pra WebRTC datachannels via TCP ou considerar soluções alternatives como relay em camada superior.

Custo operacional

A conta mais importante é banda. TURN relay consome banda proporcional ao tráfego dos peers. Num cenário realista de videoconferência 1080p com 5 participantes, cada relay pode consumir 2 a 5 Mbps por conexão. Isso significa que custos de infraestrutura crescem linearmente com o uso. Se precisar de algo mais escalável sem gerenciar servidores próprios, existem serviços managed como Twilio Network Traversal ou Xirsys. Eles cobram por GB relayado, mas eliminam a dor de cabeça de manutenção.