Como configurar servidor TURN com coturn em VPS

Resposta direta

Um servidor TURN com coturn em VPS retransmite mídia do WebRTC quando dois clientes não conseguem estabelecer conexão direta por causa de NAT, firewall corporativo, CGNAT ou restrições de rede. Para começar, uma instância com 1 a 2 vCPUs, 1 a 2 GB de RAM e porta de rede de pelo menos 1 Gbps atende homologação e cargas pequenas, mas a capacidade real depende principalmente da franquia de tráfego e da banda sustentada. Em produção, configure DNS, TLS, credenciais temporárias, firewall e uma faixa UDP limitada, como 49160 a 49260. Monitore sessões, perda de pacotes e tráfego por interface. O coturn consome pouca CPU em comparação com um servidor de vídeo, porém cada fluxo retransmitido entra e sai da VPS, o que torna a rede o recurso decisivo.

Resumo rápido

Um servidor TURN não substitui o servidor de sinalização nem processa o conteúdo do vídeo como uma SFU. Sua função é oferecer um caminho alternativo para pacotes de áudio, vídeo ou dados quando a conectividade direta falha. Isso parece simples, mas uma configuração incompleta costuma funcionar no Wi-Fi doméstico e falhar justamente nas redes corporativas onde o relay é mais necessário.

• STUN ajuda o cliente a descobrir seu endereço público; TURN retransmite o tráfego quando a conexão direta não funciona.
• O coturn é uma implementação aberta de TURN e STUN, compatível com UDP, TCP e TLS.
• A porta 3478 é normalmente usada para TURN e STUN; a 5349 é associada a TURN sobre TLS.
• Uma faixa UDP de relay reduz a superfície de exposição, desde que seja ampla o suficiente para o pico de sessões.
• CPU e RAM raramente são o primeiro gargalo. Banda sustentada, franquia mensal, PPS e qualidade da rota pesam mais.
• Credenciais fixas no JavaScript são inseguras. Prefira usuários temporários assinados pelo backend.
• Testes precisam incluir 4G ou 5G, Wi-Fi residencial e uma rede que bloqueie UDP.
• Em produção, use pelo menos duas instâncias ou tenha um plano documentado de recuperação.

A recomendação de capacidade deve partir da taxa de bits de mídia, do percentual de conexões que usam relay e da simultaneidade. Uma sala com oito participantes em uma arquitetura SFU tem comportamento diferente de uma chamada ponto a ponto entre duas pessoas. Antes de contratar a VPS, confirme limite mensal de transferência, velocidade da interface, política de uso e disponibilidade da região. Esses dados mudam conforme provedor e plano e exigem verificação na página oficial.

Como STUN, TURN e coturn participam do WebRTC

Quando o tráfego precisa ser retransmitido

Durante a negociação ICE, o cliente WebRTC reúne candidatos de conectividade. Um candidato host representa um endereço local. O candidato server reflexive, obtido via STUN, representa o endereço público observado. Já o candidato relay é alocado pelo TURN. Os dois participantes testam combinações e selecionam o caminho viável com melhor prioridade. Se UDP direto funcionar, o TURN pode nem transportar mídia. Se ambos estiverem atrás de NAT simétrico ou uma política bloquear tráfego ponto a ponto, o relay passa a carregar a sessão.

Considere uma chamada entre um notebook em uma empresa e um celular conectado a uma operadora com CGNAT. O notebook pode aceitar somente conexões pela porta TCP 443, enquanto o telefone não possui endereço público utilizável. Um endpoint TURN acessível por turns:turn.exemplo.com:5349?transport=tcp oferece uma saída compatível com regras mais restritivas. Em outro cenário, dois usuários em redes domésticas conseguem usar UDP direto, e o coturn participa apenas da descoberta STUN, consumindo tráfego mínimo.

O coturn implementa STUN e TURN e pode autenticar usuários, alocar portas de relay, registrar sessões e atender por UDP, TCP ou TLS. Ele não mistura áudio, não reduz resolução e não grava conferências. Em aplicações com muitas pessoas, essa função costuma ficar ao lado de uma SFU, como Jitsi Videobridge, Janus ou mediasoup. Quem planeja uma plataforma desse tipo pode complementar o desenho com o artigo sobre infraestrutura para Jitsi Meet no Brasil.

VPS tradicional ou Cloud Server

Uma VPS tradicional normalmente nasce em um host físico específico e recebe recursos virtualizados. Uma cloud instance ou Cloud Server tende a oferecer provisionamento por API, redes privadas e redimensionamento mais ágil, mas isso não garante alta disponibilidade automática. Nos dois modelos, reiniciar ou perder a instância interrompe alocações TURN ativas.

Para laboratório, uma VPS única com IPv4 público funciona. Para produção, procure endereço público estável, controle de firewall, boa conectividade UDP e métricas de rede. Um IP compartilhado por NAT do provedor complica o mapeamento de relay. Se a instância estiver atrás de NAT, o coturn precisa conhecer os endereços público e privado por meio da diretiva external-ip.

Instalação e configuração inicial do coturn

Instalando no Ubuntu

Em Ubuntu Server, a instalação pode ser feita pelos repositórios da distribuição. Primeiro atualize os índices, instale o pacote e confirme a versão disponível. Distribuições LTS podem oferecer uma versão anterior à release mais recente do projeto, então a equipe deve consultar os avisos de segurança antes de decidir entre pacote oficial, contêiner ou compilação.

sudo apt update
sudo apt install coturn
turnserver --version
sudo systemctl enable coturn

Use uma máquina limpa, com endereço IPv4 público e um registro DNS como turn.exemplo.com. Em uma instância com interface privada e IP público traduzido, descubra os dois endereços e configure o mapeamento explicitamente. Um exemplo seria external-ip=203.0.113.20/10.0.2.15, substituindo os endereços documentais pelos valores reais do ambiente.

Configuração básica para produção

O arquivo costuma ficar em /etc/turnserver.conf. A configuração abaixo limita a faixa de relay, habilita autenticação de longo prazo e prepara TLS. O segredo exibido é apenas uma instrução textual, não uma credencial funcional. Gere o valor durante o deploy, armazene-o fora do Git e restrinja a leitura do arquivo ao usuário do serviço.

listening-port=3478
tls-listening-port=5349
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=INSIRA_O_SEGREDO_GERADO_NO_DEPLOY
realm=turn.exemplo.com
server-name=turn.exemplo.com
min-port=49160
max-port=49260
no-cli
no-multicast-peers
no-loopback-peers
stale-nonce=600
cert=/etc/letsencrypt/live/turn.exemplo.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.exemplo.com/privkey.pem
log-file=stdout
simple-log

A combinação use-auth-secret e static-auth-secret permite que o backend gere credenciais temporárias. Não envie o segredo compartilhado ao navegador. O backend cria um nome de usuário contendo a expiração, calcula uma assinatura HMAC e devolve apenas usuário e senha temporários. Para um ambiente interno pequeno, também é possível cadastrar usuários persistentes, mas isso dificulta rotação e revogação.

Depois de salvar, valide sem interromper usuários. Em uma implantação nova, reinicie o serviço e confira socket, logs e portas:

sudo systemctl restart coturn
sudo systemctl status coturn --no-pager
sudo ss -lntup | grep -E '3478|5349'
sudo journalctl -u coturn -n 100 --no-pager

Se o serviço iniciar, mas nenhum relay funcionar, verifique primeiro o firewall externo do provedor. É comum liberar portas no ufw e esquecer o security group, ou fazer o oposto. Também confirme se outro processo ocupa a porta 3478 e se o certificado pode ser lido pelo usuário que executa o coturn.

Como dimensionar CPU, RAM e largura de banda

A conta de banda que realmente importa

O coturn encaminha pacotes e mantém estados de alocação. Por isso, memória e CPU costumam crescer de forma mais suave que o tráfego. Uma base pequena pode começar com 1 vCPU e 1 GB de RAM, enquanto um serviço empresarial normalmente adota 2 a 4 vCPUs e 4 a 8 GB para preservar folga operacional. Esses números não definem capacidade sozinhos. O limite aparece com frequência na interface virtual, na franquia mensal, em pacotes por segundo ou na qualidade da rota.

Para estimar banda, some as taxas dos fluxos efetivamente retransmitidos. Uma chamada com áudio de 64 Kbps e vídeo médio de 1,5 Mbps gera cerca de 1,564 Mbps por direção de mídia. Como o pacote entra no TURN e sai para o destinatário, o consumo agregado da interface se aproxima de 3,128 Mbps para esse fluxo, antes de overhead de IP, UDP, TURN, DTLS e SRTP. Reservar de 15% a 25% para overhead e variação evita um cálculo apertado.

Imagine 50 chamadas simultâneas entre duas pessoas, com todos os fluxos passando pelo relay e 1,2 Mbps por fluxo. Uma aproximação inicial seria 50 × 1,2 × 2 = 120 Mbps, além da margem. Se apenas 20% das chamadas precisarem de TURN, a média cai bastante, mas o dimensionamento deve considerar picos e redes problemáticas. Já uma sala WebRTC em malha completa pode crescer rapidamente, pois cada participante envia múltiplos fluxos. Uma SFU muda esse padrão, mas não elimina a necessidade de TURN para clientes restritos.

Perfis de capacidade

Perfil operacional	CPU e RAM iniciais	Rede recomendada	Faixa de relay	Uso típico
Laboratório	1 vCPU e 1 GB	Interface de 100 Mbps ou mais	49160 a 49200	Testes funcionais e poucas chamadas
Aplicação pequena	2 vCPUs e 2 a 4 GB	Porta de 1 Gbps, com franquia conferida	49160 a 49360	Dezenas de sessões simultâneas
Produção crescente	4 vCPUs e 8 GB	1 Gbps sustentado ou mais, conforme medição	49160 a 50160	Centenas de alocações e redundância
Operação distribuída	2 ou mais nós por região	Capacidade agregada e rotas redundantes	Faixa própria por nó	Serviço crítico e público geograficamente disperso

A tabela é um ponto de partida, não um benchmark. Faça um teste com taxa de bits, codecs, duração e distribuição geográfica semelhantes às da aplicação. Confirme também transferência de saída, porque 100 Mbps contínuos podem superar 30 TB por mês em um cenário teórico de ocupação integral. Planos anunciados com porta de 1 Gbps nem sempre incluem uso sustentado ilimitado.

Portas, TLS, DNS e hardening do servidor TURN

Faixa de portas e firewall

Uma implantação típica libera 3478 em UDP e TCP, 5349 em TCP para TLS e uma faixa UDP para os relays. Se o coturn estiver configurado com min-port=49160 e max-port=49260, o firewall precisa permitir exatamente esse intervalo. Cem portas não equivalem automaticamente a cem usuários, pois uma sessão pode consumir mais de uma alocação. A largura deve ser validada em testes de pico.

Com ufw, uma política inicial pode ser aplicada assim:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 3478/udp
sudo ufw allow 3478/tcp
sudo ufw allow 5349/tcp
sudo ufw allow 49160:49260/udp
sudo ufw enable

Restrinja o SSH ao IP administrativo ou a uma VPN sempre que possível. A porta 22 aberta para toda a internet aumenta ruído de scanners e tentativas de login. Use chaves SSH, desative autenticação por senha e mantenha atualizações de segurança. O artigo sobre firewall e hardening em VPS aprofunda essas medidas sem assumir que o coturn é o único serviço da máquina.

O security group da nuvem e o firewall local devem concordar. Se a VPS usar IPv6, decida conscientemente se o serviço responderá nesse protocolo. Bloquear apenas IPv4 e deixar IPv6 irrestrito cria uma regra incompleta. Também evite permitir acesso a destinos multicast, loopback e faixas internas pelo relay, pois um TURN mal configurado pode ser explorado para alcançar serviços que não deveriam estar expostos.

Certificados e credenciais temporárias

Crie um registro A apontando turn.exemplo.com para o IPv4 público. O certificado TLS deve corresponder a esse nome. Uma alternativa prática consiste em emitir o certificado com um cliente ACME e programar a renovação. Após renovar, recarregue ou reinicie o coturn de maneira controlada para que o processo leia os novos arquivos.

TURN sobre TCP 443 pode ajudar em redes muito restritivas, mas exige planejamento. Se Nginx, Caddy ou a aplicação web já usam a mesma porta e o mesmo IP, os processos não podem escutar simultaneamente sem multiplexação compatível ou endereços separados. Uma solução simples é dedicar um IPv4 ao coturn. Outra é manter 5349 como opção TLS e medir quantos clientes realmente precisam da porta 443.

Credenciais temporárias devem expirar em um intervalo curto, como 15 a 60 minutos, conforme a duração esperada das sessões. Rotacione o segredo compartilhado com transição planejada entre chaves, aplique limites por usuário quando adequados e monitore aumentos súbitos de alocações. Isso reduz abuso, embora não substitua controle de acesso no backend.

Integração com WebRTC, Jitsi e aplicações próprias

Configuração no navegador

A aplicação entrega servidores ICE por meio de RTCPeerConnection. Inclua uma opção UDP, uma alternativa TCP e uma opção TLS. O exemplo usa credenciais recebidas do backend, sem inserir segredo administrativo no código:

const iceServers = [
  { urls: 'stun:turn.exemplo.com:3478' },
  {
    urls: [
      'turn:turn.exemplo.com:3478?transport=udp',
      'turn:turn.exemplo.com:3478?transport=tcp',
      'turns:turn.exemplo.com:5349?transport=tcp'
    ],
    username: session.turnUsername,
    credential: session.turnCredential
  }
];

const peer = new RTCPeerConnection({ iceServers });

O backend deve autenticar o usuário da aplicação antes de emitir essas credenciais. Não coloque o segredo HMAC em um bundle React, Vue ou JavaScript estático. Qualquer visitante conseguiria extraí-lo e gerar acessos válidos. Em sistemas com WebSocket para sinalização, TURN e WebSocket cumprem papéis diferentes: o primeiro retransmite mídia ou dados ICE, enquanto o segundo troca eventos de sessão. O planejamento conjunto é abordado no conteúdo sobre VPS para WebSocket e aplicações em tempo real.

No Jitsi Meet, a integração depende dos componentes e da versão implantada. O TURN pode atender clientes que não conseguem alcançar o Jitsi Videobridge por UDP. Isso não significa que todo vídeo passará pelo coturn. Uma boa implantação preserva o caminho direto até o bridge quando possível e usa TURN como fallback. Verifique a documentação da versão instalada antes de editar arquivos do Prosody, Jicofo ou configuração web.

Testes antes da liberação

O primeiro teste deve confirmar a obtenção de candidato relay. A página Trickle ICE do projeto WebRTC permite informar a URL, o usuário temporário e a senha para observar candidatos. Em linha de comando, as ferramentas fornecidas com coturn ajudam a testar autenticação e throughput entre cliente e servidor:

turnutils_uclient -u USUARIO_TEMPORARIO -w SENHA_TEMPORARIA \
  -p 3478 -v turn.exemplo.com

Faça pelo menos três ensaios. Teste UDP em uma rede doméstica, TCP ou TLS em uma rede que bloqueie UDP e uma conexão móvel sob CGNAT. Depois, force a política ICE para relay no ambiente de homologação e confirme áudio, vídeo e data channel. Inspecione chrome://webrtc-internals ou ferramentas equivalentes para verificar o tipo de candidato selecionado, RTT, jitter, perda de pacotes e taxa de bits.

Monitoramento, troubleshooting e escalabilidade

Métricas operacionais

Uma checagem que apenas confirma a porta 3478 aberta é insuficiente. O processo pode responder ao socket e falhar na alocação por credencial inválida, faixa esgotada ou firewall. O monitoramento sintético deve realizar uma alocação autenticada, enviar tráfego pelo relay e validar retorno. Rode esse teste a partir de uma rede externa, nunca apenas dentro da própria VPS.

Colete bytes recebidos e enviados por interface, pacotes por segundo, drops, uso de CPU, memória, descritores de arquivo e quantidade de sessões. No Linux, ip -s link, ss -s, nload, vnstat e o coletor do Prometheus ajudam a formar a linha de base. Os logs do coturn devem ser enviados para armazenamento central ou para o journal com rotação. Um alerta razoável pode disparar quando a interface sustentar mais de 70% da capacidade planejada durante cinco minutos ou quando a perda de pacotes crescer junto com a fila da interface.

Em um incidente, compare três camadas. Primeiro, confirme resolução DNS e validade do certificado. Depois, teste autenticação e abertura de portas. Por fim, analise a mídia: RTT alto, jitter e perda podem indicar rota ruim mesmo quando a alocação funciona. Se UDP falhar, mas TLS funcionar, investigue regras de firewall. Se nenhum candidato relay surgir, verifique realm, relógio do servidor, expiração da credencial e assinatura HMAC.

Falhas comuns e expansão horizontal

O erro 401 Unauthorized pode fazer parte do desafio de autenticação inicial, mas uma sequência contínua sugere credencial incorreta. Falhas de TLS geralmente vêm de cadeia incompleta, nome DNS divergente ou permissão de leitura da chave. Sessões que conectam e param após alguns minutos podem apontar para expiração inadequada, timeout de NAT ou saturação de rede. Já a ausência de áudio em apenas uma direção pede inspeção das rotas e dos candidatos selecionados nos dois endpoints.

Para escalar, publique dois ou mais servidores ICE e deixe o cliente testar as opções. DNS round-robin distribui consultas, mas oferece pouco controle sobre saúde e proximidade. Um backend pode entregar nós por região, considerando localização aproximada e disponibilidade. Anycast é possível, porém exige maturidade em roteamento e operação UDP. Para a maioria das equipes, instâncias regionais independentes são mais simples.

Não conte com a migração ao vivo de uma sessão TURN durante uma falha. Se o nó cair, as alocações daquele processo desaparecem e o WebRTC precisa reiniciar ICE para selecionar outro relay. Teste esse comportamento desligando uma instância em homologação. Capacidade sobressalente também é necessária: dois nós operando a 60% cada não suportam a perda de um deles sem saturação.

Recomendações por perfil

Desenvolvedor solo e homologação

Para protótipo, demonstração ou aplicação interna, comece com 1 vCPU, 1 a 2 GB de RAM, IPv4 público e pelo menos 20 GB de disco. O armazenamento guarda sistema e logs, não o vídeo. Limite o relay a cerca de 100 portas, habilite UDP, TCP e TLS e configure credenciais temporárias desde o início. Mesmo em laboratório, não publique um usuário fixo dentro do frontend. Teste chamadas em Wi-Fi e rede móvel e acompanhe a transferência mensal no painel do provedor. Uma única VPS é aceitável nesse perfil, desde que a indisponibilidade seja tolerada e exista um procedimento de recriação documentado.

Equipe com aplicação em crescimento

Para dezenas de chamadas simultâneas, adote 2 vCPUs, 4 GB de RAM e interface de 1 Gbps, confirmando franquia e política de uso. Separe métricas por transporte para descobrir quantos clientes dependem de UDP, TCP ou TLS. Amplie a faixa de relay com base no pico observado, não apenas na quantidade cadastrada de usuários. Automatize instalação, DNS, certificado e firewall com uma ferramenta como Ansible ou Terraform, mas mantenha segredos em cofre apropriado. Um segundo nó em outra zona ou provedor reduz dependência operacional. Faça testes de carga com codecs e bitrates próximos aos reais antes de campanhas ou eventos.

Produção crítica e múltiplas regiões

Para videoconferência comercial, atendimento remoto ou comunicação que afeta receita, projete ao menos dois nós por região e capacidade para absorver a falha de uma instância. Quatro vCPUs e 8 GB por nó oferecem folga operacional, mas a escolha final precisa seguir métricas de rede e testes reproduzíveis. Entregue a lista de ICE servers conforme região, monitore alocação autenticada de fora da infraestrutura e defina objetivos de disponibilidade e latência. Planeje rotação de segredos, renovação de certificados, resposta a abuso e atualização do coturn. Revise mensalmente transferência, percentil 95 de banda, perda de pacotes e custo de saída. Se o público estiver espalhado, uma única VPS brasileira pode gerar RTT desnecessário para usuários na Europa ou Ásia.

Em qualquer perfil, escolha o provedor depois de confirmar IP público, suporte a UDP, velocidade da porta, transferência incluída, regiões e regras contra abuso. Não há base técnica para declarar uma VPS específica como a mais rápida sem benchmark controlado. O melhor desenho é aquele que mantém margem de banda, restringe credenciais, oferece caminhos alternativos e pode ser reproduzido quando uma instância falha.