Como escolher VPS para Asterisk e VoIP no Brasil

Resposta direta

Uma VPS para Asterisk e VoIP no Brasil deve ter endereço IPv4 público estável, rota de rede consistente, baixa variação de latência e recursos suficientes para o número de chamadas simultâneas. Um ambiente pequeno pode começar com 2 vCPUs, 2 GB de RAM e 40 GB de SSD, desde que não faça transcodificação intensa nem grave dezenas de ligações ao mesmo tempo. Operações com filas, URA, gravação e FreePBX costumam trabalhar melhor com 4 vCPUs, 4 a 8 GB de RAM e pelo menos 80 GB de SSD. O firewall deve liberar SIP e RTP apenas para origens necessárias sempre que isso for possível.

O número de ramais cadastrados, sozinho, não determina o tamanho do servidor. Uma central com 300 ramais e 10 chamadas simultâneas pode exigir menos CPU que outra com 40 ramais, 25 chamadas gravadas e conversão entre G.711, Opus e outros codecs. O dimensionamento precisa considerar chamadas concorrentes, transcodificação, conferências, filas, relatórios e retenção das gravações.

Também não basta contratar um plano localizado no Brasil e assumir que a voz ficará perfeita. O caminho entre operadora, servidor e telefones precisa ser medido. Antes de colocar a central em produção, faça chamadas de teste nos horários de maior uso, acompanhe perda de pacotes e confirme se o provedor permite configurar firewall, IP reverso, snapshots e políticas de backup. Recursos e localidades variam por plano e devem ser verificados na página oficial.

Resumo rápido

• Use 2 vCPUs e 2 GB de RAM apenas para laboratório ou operação pequena, com poucas chamadas concorrentes.
• Prefira 4 vCPUs e 4 a 8 GB de RAM quando houver FreePBX, filas, URA, relatórios e gravação.
• Dimensione a central por chamadas simultâneas e codecs, não apenas pela quantidade de ramais.
• Trabalhe com IPv4 público estável e evite colocar o servidor atrás de CGNAT.
• Procure manter latência abaixo de 100 ms, jitter abaixo de 20 a 30 ms e perda de pacotes próxima de zero.
• Restrinja SIP e RTP por origem quando o tronco ou os ramais tiverem endereços conhecidos.
• Mantenha backup externo das configurações, do banco de dados e das gravações que precisem ser preservadas.

Telefonia IP é sensível a interrupções pequenas que passariam despercebidas em um site. Um pico de CPU de dois segundos pode atrasar pacotes de áudio, enquanto uma rota instável pode produzir voz metálica mesmo com bastante RAM disponível. Por isso, rede, segurança e observabilidade têm peso semelhante ao processador na escolha da infraestrutura.

Antes da contratação, registre quantas chamadas simultâneas existem no horário de pico, quais codecs são usados pelo tronco SIP e pelos telefones, se todas as chamadas serão gravadas e por quanto tempo os arquivos ficarão armazenados. Depois, adicione uma margem de 30% a 50% para crescimento e eventos anormais. Essa reserva ajuda durante atualizações, geração de relatórios, campanhas de chamadas e picos de atendimento, mas não substitui testes de carga feitos com o fluxo real da empresa.

Como funciona uma VPS para Asterisk e VoIP

Asterisk, FreePBX e os componentes da telefonia IP

Asterisk é o motor de comunicação responsável por registrar ramais, controlar chamadas, executar URAs, filas, conferências e integrar troncos SIP. FreePBX é uma interface de administração que organiza boa parte dessas configurações, acrescentando banco de dados, servidor web, relatórios e módulos. Essa diferença afeta os recursos. Um Asterisk configurado por arquivos pode usar pouca memória, enquanto uma instalação completa do FreePBX precisa acomodar PHP, MariaDB, interface web, logs e tarefas agendadas.

Em um exemplo simples, uma empresa mantém 30 ramais, um tronco SIP e cinco chamadas simultâneas em G.711. O consumo de CPU tende a ser moderado quando todos os pontos usam o mesmo codec. Se o tronco entrega G.711 e os ramais remotos usam Opus, a central pode precisar transcodificar cada canal. Dez ligações representam até 20 canais de áudio, pois cada chamada possui duas pontas. Essa conversão aumenta o uso de CPU e precisa ser testada com o dialplan real.

VPS tradicional, Cloud Server ou cloud instance

Uma VPS tradicional normalmente oferece recursos virtuais dentro de um host físico, com limites definidos pelo plano. Um Cloud Server ou uma cloud instance pode facilitar redimensionamento, criação por API e substituição da máquina, mas isso não garante alta disponibilidade automática. Se o Asterisk estiver em uma única instância, uma falha nessa instância ainda interrompe as chamadas.

Para um escritório com oito chamadas concorrentes, uma VPS bem administrada pode ser suficiente. Uma central que atende várias filiais talvez precise de duas instâncias, roteamento SIP redundante, banco replicado ou um procedimento rápido de recuperação. Migrar apenas o disco para outra máquina não resolve tudo, pois operadora, DNS, IP público, certificados e regras de firewall também participam do serviço.

Na seleção do provedor, avalie estabilidade da virtualização, política de uso de CPU, disponibilidade de IPv4 público e ferramentas de recuperação. Provedores como DigitalOcean, Vultr, AWS Lightsail e LetsCloud podem aparecer na pesquisa, mas localidade, armazenamento, banda, snapshots e suporte precisam ser confirmados no plano específico. Não há base técnica para declarar um deles superior sem benchmark controlado, monitoramento de rota e teste de chamadas.

Como dimensionar CPU, RAM e armazenamento

Chamadas simultâneas e transcodificação

Comece pelo pico de chamadas, não pelo total de extensões. Suponha 80 ramais registrados, 12 chamadas simultâneas, duas filas e gravação de todas as conversas. Se tronco e terminais usam G.711 sem conversão, 2 vCPUs podem funcionar, mas 4 vCPUs dão margem para FreePBX, relatórios e compressão de backups. Caso cada chamada seja transcodificada, faça um teste de carga e acompanhe tempo de CPU, load average e atrasos no áudio antes de aprovar a configuração.

A memória atende Asterisk, sistema operacional, banco, painel e cache. Uma instalação mínima sem interface gráfica pode operar com 1 a 2 GB, mas isso deixa pouca folga para atualização e diagnóstico. Para FreePBX em produção pequena, 4 GB é um ponto inicial mais seguro. Centrais com relatórios grandes, integrações, gravação e múltiplos serviços podem precisar de 8 GB ou mais. Swap ajuda a evitar encerramentos abruptos, porém atividade frequente de swap durante chamadas indica falta de RAM.

O disco precisa absorver sistema, logs e gravações. Áudio WAV sem compressão pode consumir perto de 1 MB por minuto, dependendo do formato e da implementação. Cem chamadas gravadas de dez minutos podem ocupar aproximadamente 1 GB. Em 22 dias úteis, isso ultrapassa 20 GB antes de considerar cópias, logs e banco. Grave uma amostra real e use o tamanho observado para projetar retenção.

Tabela de recursos por perfil

Perfil operacional	Chamadas simultâneas	CPU e RAM iniciais	Disco sugerido	Cenário típico
Laboratório	1 a 5	2 vCPUs, 2 GB	40 GB SSD	Testes, homologação e poucos ramais
Pequena operação	5 a 15	2 a 4 vCPUs, 4 GB	60 a 80 GB SSD	FreePBX, URA simples e gravação seletiva
Atendimento comercial	15 a 40	4 vCPUs, 8 GB	120 a 250 GB SSD	Filas, gravação, relatórios e integrações
Operação intensiva	40 ou mais	8 vCPUs, 16 GB ou mais	250 GB ou storage externo	Transcodificação, conferências e múltiplas filas

Esses valores são pontos de partida, não garantias de capacidade. Uma instância com vCPU compartilhada pode variar conforme a contenção do host. Rode chamadas simultâneas por pelo menos 30 minutos, gere relatórios e execute uma rotina de backup durante o teste. Se o áudio degradar, investigue CPU steal, I/O wait, rede e transcodificação antes de simplesmente dobrar a RAM.

Latência, jitter, rede e IP dedicado

Metas práticas para uma chamada estável

Latência é o tempo de percurso do pacote. Jitter é a variação desse tempo, e perda indica pacotes que não chegaram. Em telefonia, uma média baixa não compensa picos frequentes. Como referência operacional, busque latência de ida e volta inferior a 100 ms entre telefone e servidor, jitter abaixo de 20 a 30 ms e perda próxima de zero. Chamadas podem funcionar acima desses números, mas a conversa fica mais sujeita a pausas, sobreposição de voz e som robotizado.

Um servidor em São Paulo pode atender bem usuários do Sudeste, mas isso precisa ser medido a partir das redes utilizadas pelos telefones e pelo tronco. Uma filial no Norte pode ter rota melhor para outra localidade, mesmo quando a distância física parece maior. O processo descrito em VPS de baixa latência no Brasil ajuda a comparar ping, traceroute, jitter e perda sem confundir proximidade geográfica com qualidade real de rota.

Faça testes em três horários. Por exemplo, meça às 9h, 14h e 18h durante cinco dias, usando mtr ou ferramenta equivalente. Depois, complete a avaliação com chamadas reais, pois ICMP pode receber tratamento diferente de SIP e RTP. Registre operadora de acesso, codec, duração e ocorrência percebida. Esse histórico facilita separar problema do servidor, da internet do usuário ou da operadora SIP.

NAT, RTP e cálculo de tráfego

Um IPv4 público estável simplifica troncos que autorizam origem por endereço e reduz mudanças de configuração. O conteúdo sobre VPS com IP dedicado no Brasil explica o que confirmar no contrato, inclusive se o endereço é público, exclusivo e mantido durante reinicializações. IP dedicado não significa CPU dedicada e não protege a central por si só.

Com G.711, reserve aproximadamente 80 a 100 Kbps em cada direção por chamada após considerar cabeçalhos e sobrecarga. Vinte chamadas podem consumir perto de 2 Mbps de upload e 2 Mbps de download no servidor, além de sinalização, gravação e administração. A banda nominal costuma ser suficiente, mas limite de transferência, filtragem UDP e qualidade da rota podem ser mais relevantes.

Quando o Asterisk estiver atrás de NAT, configure external_signaling_address, external_media_address e redes locais corretamente. Uma configuração errada costuma produzir áudio unilateral: a chamada completa, mas apenas uma ponta escuta. Confirme também se a faixa RTP configurada no Asterisk coincide com a liberada no firewall.

Firewall e hardening para Asterisk e FreePBX

Exposição mínima de portas

Uma central pública recebe varreduras automatizadas em pouco tempo. A regra mais segura é permitir apenas o necessário. SSH deve aceitar chaves e, de preferência, ficar restrito a uma VPN ou lista de endereços administrativos. A interface do FreePBX pode ser limitada à rede corporativa. SIP e RTP devem aceitar apenas os endereços da operadora quando o tronco usar IPs fixos.

Portas comuns incluem 5060 em UDP ou TCP para SIP, 5061 para SIP sobre TLS e uma faixa UDP para RTP, frequentemente 10000 a 20000. Esses números não são universais. Confira pjsip.conf, rtp.conf, configurações do FreePBX e documentação da operadora. Liberar 10000 a 20000 no firewall enquanto o Asterisk usa outra faixa não produz áudio. Liberar a faixa para toda a internet aumenta a superfície de exposição sem corrigir NAT mal configurado.

Um exemplo com nftables pode aceitar SIP apenas de uma operadora fictícia e liberar RTP para a mesma origem:

nft add rule inet filter input ip saddr 192.0.2.10 udp dport 5060 accept
nft add rule inet filter input ip saddr 192.0.2.10 udp dport 10000-20000 accept

O endereço 192.0.2.10 pertence a uma faixa reservada para documentação. Substitua pela lista oficial da operadora e valide uma sessão aberta antes de ativar a política padrão de bloqueio. Se houver ramais móveis com IP variável, use VPN, TLS, autenticação forte e limites de tentativa em vez de abrir tudo sem controle.

Proteção contra fraude e força bruta

A ameaça mais cara nem sempre é a indisponibilidade. Uma credencial SIP comprometida pode gerar chamadas internacionais e fraude tarifária. Use senhas aleatórias e exclusivas, desative extensões sem uso, limite destinos no dialplan e crie alertas para aumento repentino de chamadas. Fail2ban ajuda contra tentativas repetidas, mas não substitui restrição por origem nem corrige credenciais vazadas.

O roteiro de firewall e hardening de segurança em VPS pode ser aplicado ao sistema base: atualizações, usuário administrativo sem login direto de root, chaves SSH, auditoria de serviços e política de backup. No FreePBX, altere regras pela ferramenta compatível com o painel para evitar que uma atualização sobrescreva ajustes manuais.

TLS protege a sinalização e SRTP pode proteger a mídia, desde que tronco e terminais sejam compatíveis. Guarde certificados e chaves fora de repositórios públicos. Nunca inclua senhas SIP em scripts, tickets ou exemplos compartilhados. Complete o hardening com backup externo, pois snapshot no mesmo provedor não protege contra exclusão de conta ou erro administrativo amplo.

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

Sistema operacional e serviços

Escolha uma distribuição e uma versão compatíveis com a edição do Asterisk ou FreePBX que será instalada. Uma versão recente do Debian pode ser adequada ao FreePBX atual, enquanto uma instalação manual do Asterisk também funciona em outras distribuições suportadas. Confirme a matriz oficial antes do deploy, pois versões de PHP, MariaDB, Node.js e módulos do kernel mudam com o tempo.

Prepare a VPS com hostname válido, fuso horário correto e sincronização NTP. Diferenças no relógio prejudicam logs, certificados, bilhetagem e investigação de incidentes. Em seguida, crie um usuário administrativo, instale atualizações e configure o firewall antes de expor a interface. Em um laboratório Debian, a sequência inicial pode incluir:

apt update && apt upgrade
apt install chrony nftables fail2ban sngrep
systemctl enable --now chrony nftables fail2ban

Não execute instaladores desconhecidos diretamente da internet. Leia o script, confira assinatura ou checksum quando disponível e teste em uma instância descartável. FreePBX reúne vários componentes, então siga o procedimento correspondente à versão oficial em vez de combinar tutoriais produzidos para lançamentos diferentes.

PJSIP, RTP e NAT

No PJSIP, separe transportes, endpoints, autenticação, AORs e identificação do tronco. Não reutilize a mesma senha em ramais. Uma base de transporte UDP pode começar assim:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060
local_net=10.0.0.0/8
external_signaling_address=IP_PUBLICO
external_media_address=IP_PUBLICO

IP_PUBLICO é um marcador, não uma chave. Ajuste a rede local ao ambiente real. Se a VPS possui o IPv4 diretamente na interface, algumas opções de NAT podem ser desnecessárias. Se o provedor aplica NAT, confirme como o endereço externo é associado à instância.

Configure a faixa RTP explicitamente, por exemplo 10000 a 20000, e use a mesma faixa no firewall. Depois, cadastre um ramal de teste, faça chamadas de entrada e saída e capture a sinalização com sngrep. Verifique se os cabeçalhos SDP anunciam o IP correto e se os pacotes RTP fluem nas duas direções.

Para um rollout seguro, comece com dois ramais, depois conecte o tronco e só então adicione filas e gravações. Essa ordem reduz variáveis. Tire um snapshot antes de atualizações grandes, mas mantenha também backup exportável das configurações e do banco. O snapshot facilita rollback da máquina; o backup externo permite reconstrução em outro provedor ou região.

Monitoramento, testes e solução de problemas

Métricas que precisam ser acompanhadas

Monitore CPU, memória, swap, espaço em disco, I/O wait, perda de pacotes, jitter e quantidade de canais ativos. Para CPU, acompanhe também steal, que indica tempo retirado da máquina virtual pelo hipervisor. Um valor persistentemente alto durante chamadas pode apontar contenção no host. Para disco, crie alertas em 70% e 85%, pois gravações podem preencher o volume rapidamente e interromper banco, logs ou correio de voz.

No Asterisk, comandos como core show channels, pjsip show endpoints e pjsip show registrations ajudam a conferir canais e registros. Use sngrep para examinar o fluxo SIP e tcpdump com filtros restritos durante investigações. Capturas podem conter números, endereços e sinalização sensível. Armazene-as pelo menor tempo possível e controle o acesso.

Um teste de aceitação pode gerar 10, 20 e 30 chamadas em etapas de 15 minutos. Durante cada etapa, registre CPU por núcleo, memória, canais, atrasos e tamanho das gravações. Execute também uma consulta de relatório e um backup. Esse cenário se aproxima mais da operação real que um teste de ping isolado.

Diagnóstico de áudio unilateral e chamadas robotizadas

Áudio unilateral costuma apontar para NAT, SDP ou firewall. Confirme o IP anunciado na negociação, compare a faixa RTP e veja se pacotes chegam nos dois sentidos. Se a chamada cai após 30 segundos, investigue respostas SIP que não retornaram pelo caminho esperado, temporizadores de sessão e dispositivos que alteram pacotes, como SIP ALG no roteador.

Voz robotizada geralmente pede análise de perda, jitter, congestionamento ou CPU. Se apenas usuários de uma filial sofrem o problema, examine a conexão dessa filial. Se todos apresentam falhas no mesmo horário, verifique rota do datacenter, CPU steal e uso de rede da VPS. Quando apenas chamadas gravadas ficam ruins, compare o áudio ao vivo e o arquivo para separar problema de mídia de gargalo no armazenamento.

Mantenha um procedimento de recuperação testado. Um backup sem restauração validada é apenas uma expectativa. A cada trimestre, restaure a central em uma instância isolada, confirme ramais, URA, filas e gravações, sem registrar o tronco de produção por acidente.

Recomendações por perfil

Desenvolvedor solo e laboratório

Para desenvolver integrações, testar uma URA ou homologar um tronco, comece com 2 vCPUs, 2 GB de RAM e 40 GB de SSD. Limite o ambiente a cinco chamadas simultâneas e use dados fictícios. Um IPv4 público facilita testes, mas a interface administrativa não precisa ficar aberta para toda a internet. Restrinja SSH e FreePBX ao seu endereço ou a uma VPN. Ative logs detalhados apenas durante o diagnóstico, pois modo verboso aumenta consumo de disco e pode registrar informações sensíveis. Se houver transcodificação ou reconhecimento de voz no mesmo servidor, suba para 4 GB e acompanhe CPU por núcleo.

Pequena equipe e operação comercial

Uma empresa com 20 a 80 ramais, até 15 chamadas simultâneas, uma URA e duas filas pode adotar 4 vCPUs, 4 a 8 GB de RAM e 80 a 120 GB de SSD. Calcule separadamente o volume de gravações e envie arquivos antigos para armazenamento externo. Use monitoramento fora da VPS, alerta de registro do tronco e backup diário com retenção definida. Antes da migração, execute um piloto com alguns ramais durante uma semana. Teste números de emergência, transferências, conferência, retorno de chamada e comportamento quando a internet do escritório cai.

Produção crítica e múltiplas filas

Centrais com 40 ou mais chamadas simultâneas, gravação integral, integrações de CRM e conferências devem partir de 8 vCPUs, 16 GB de RAM e disco dimensionado pela retenção. Essa recomendação precisa ser validada por carga, especialmente quando existe transcodificação. Considere separar gravações, relatórios ou banco de dados se esses componentes competirem com o áudio. Crie uma estratégia de contingência com segundo tronco, cópia recuperável da configuração e instruções para troca de rota. Alta disponibilidade real exige mais que duas VMs: operadora, IP, DNS, banco, certificados e failover precisam ser testados em conjunto.

Em todos os perfis, escolha o provedor depois de medir as rotas relevantes. Confirme política de CPU, tráfego mensal, IPv4, proteção contra ataques, console de emergência e procedimento de recuperação. Se a escolha envolver uma região da LetsCloud ou de qualquer concorrente, valide localidade, tipo de armazenamento e recursos do plano na data da contratação. Especificações comerciais mudam, enquanto a necessidade central permanece a mesma: áudio previsível, superfície de ataque reduzida e recuperação praticável.