Aqui estão algumas informações genéricas sobre NAT que podem ajudar na sua situação…
Network Address Translation (NAT – Tradução de Endereços de Rede) é uma prática comum usada em redes, e ela não funciona muito bem com VoIP. Resolver esse problema exige entendimento de NAT, VoIP e da sua configuração de VoIP. O que segue foca no protocolo SIP para VoIP usando Asterisk, mas os problemas e soluções são aplicáveis à maioria das outras situações.
O NAT pode causar problemas em vários pontos. Se um dos PBXs estiver atrás de um gateway NAT, o outro PBX não conseguirá contatá‑lo sem alguma configuração de rede adicional. Se um ou mais telefones estiverem atrás de um gateway NAT, o outro telefone tentará enviar áudio para um endereço não roteável. Isso resulta em chamadas com falha ou áudio ausente.
A alternativa a um re‑invite é fazer com que o PBX retransmita (relay) os pacotes de voz entre os dois endpoints.
Cliente SIP atrás de um gateway NAT conectando‑se a um servidor na Internet
O cliente cria a entrada de tradução para o tráfego SIP quando se registra pela primeira vez. Enquanto houver comunicação frequente entre os dois hosts, como um pacote por minuto, o canal permanecerá aberto. A única configuração necessária é fazer com que o cliente use seu endereço externo em todos os pacotes SDP. Em clientes que o suportam, habilite STUN (Simple Traversal of UDP through NAT), para que o cliente possa determinar dinamicamente o endereço externo, ou insira‑o manualmente. O Asterisk não suporta STUN neste momento, portanto toda a configuração de NAT deve ser feita manualmente. Os seguintes comandos em /etc/asterisk/sip.conf configuram o NAT corretamente:
[general]
localnet=192.168.0.0/255.255.0.0 // ou sua sub‑rede
externip=x.x.x.x // use seu endereço
[YOURREMOTEPEER] // nome do seu peer
nat=yes
qualify=yes // força keepalives
Com essa configuração, o Asterisk usa o endereço definido por externip para todas as chamadas para os peers configurados com nat=yes. A adição de qualify=yes faz com que o Asterisk teste a conexão frequentemente para que as traduções de NAT não sejam removidas do firewall. Com esses dois comandos, sempre haverá um canal de comunicação entre o Asterisk e o peer, e o Asterisk usará o endereço externo ao enviar mensagens SDP.
Múltiplos telefones SIP e um servidor Asterisk atrás de um gateway NAT
Chamadas entre os telefones funcionarão bem porque NAT não é necessário. Para chamadas entre você e outros sistemas na Internet haverá problemas. A menos que você se registre no lado remoto como um cliente (como feito no exemplo anterior), você não conseguirá receber mensagens SIP, portanto não poderá aceitar chamadas. Em segundo lugar, as informações de endereço na sinalização da chamada apontarão para o endereço interno do telefone, e os problemas de áudio unidirecional mencionados anteriormente irão aparecer.
A solução mais fácil para isso é evitar completamente o NAT. Se você tiver um endereço IP público disponível para o seu servidor de chamadas, use‑o. Se o seu servidor Asterisk estiver conectado tanto à Internet quanto à rede interna, a porta SIP será alcançável tanto de dentro quanto de fora, e o único problema será garantir que o RTP flua corretamente. O servidor PBX não precisa ser configurado para rotear entre as interfaces ou fornecer masquerading; ele simplesmente precisa fazer a ponte (bridge) das chamadas de voz de entrada e saída.
Como mencionei antes, o PBX pode permanecer no caminho da voz ou sair do caminho. No último caso, o PBX informa ambos os endpoints um sobre o outro, após o que os endpoints passam a falar diretamente. Entretanto, o Asterisk pode ter uma chamada estabelecida com ambos os endpoints e retransmitir os pacotes RTP em nome de cada endpoint. O host interno estaria falando com o endereço interno, e o host externo estaria falando com o endereço externo. A única configuração necessária para conseguir isso em sip.conf é desabilitar re‑invites:
[general]
canreinvite=no // força o relay
Essa configuração funciona bem porque o servidor Asterisk pode falar livremente com a Internet para enviar e receber chamadas. Ele também pode falar com os telefones internos e, com uma simples ponte, ignorar completamente o NAT.
Acontece que esse comportamento de relay também é necessário quando o servidor Asterisk tem apenas um endereço privado. As portas RTP também terão de ser encaminhadas (forwarded) no firewall. O RTP escolhe números de porta aleatórios com base em limites configurados. Antes que as portas possam ser configuradas, elas devem ser limitadas em faixa. Configurar as regras do firewall é muito mais fácil se a faixa de portas for conhecida de antemão.
A faixa de portas a ser usada para RTP é definida em rtp.conf. A seguinte configuração limitará a escolha de portas RTP do Asterisk de 10000 a 20000:
[general]
rtpstart=10000 // primeira porta a usar
rtpend=20000 // última porta a usar, arredondada para cima se for ímpar
O Asterisk precisará de várias portas RTP para operar corretamente. Apenas portas pares são realmente usadas, e a desativação de re‑invites faz com que duas conexões sejam construídas por chamada. Essas portas e a porta SIP devem então ser encaminhadas para dentro pelo firewall. A sintaxe do iptables é:
iptables -t nat -A PREROUTING -i eth0 -p udp \
-m udp --dport 10000:10100 -j DNAT \
–to-destination 192.168.1.10
iptables -t nat -A PREROUTING -i eth0 -p udp \
-m udp --dport 5060 -j DNAT \
–to-destination 192.168.1.10
Substitua eth0 pela interface externa do seu firewall e 192.168.1.10 pelo endereço do seu servidor Asterisk. Essas regras dizem ao kernel Linux para traduzir o endereço de destino de quaisquer pacotes UDP na faixa fornecida que estejam entrando pela interface externa. Isso deve acontecer na fase PREROUTING em vez da fase POSTROUTING, porque o endereço de destino está sendo traduzido. Neste ponto, qualquer pacote SIP ou RTP vindo da Internet será encaminhado para o servidor Asterisk interno para processamento.
Quando uma estação remota faz uma chamada para o Asterisk, o pacote SIP será encaminhado para dentro por causa das regras do iptables. O Asterisk permanecerá no fluxo de mídia por causa do comando canreinvite=no e usará o endereço externo do firewall em quaisquer pacotes SDP por causa dos comandos de NAT. Finalmente, o fluxo de mídia será encaminhado para o servidor Asterisk devido à combinação do encaminhamento RTP via iptables e das faixas de portas definidas em rtp.conf.
Até este ponto, a configuração focou em fazer o Asterisk funcionar atrás de um gateway NAT, com alguns detalhes extras para fazer os telefones retransmitirem através do Asterisk. Existem, é claro, soluções mais gerais.
Se você puder evitar o NAT em primeiro lugar, é do seu interesse fazê‑lo, porque isso evita todos os problemas encontrados até agora.
O gateway Asterisk pode ter uma política de firewall muito restritiva aplicada a ele – você só precisa permitir UDP 5060 para SIP e qualquer faixa de portas definida em rtp.conf. Nessa configuração, o Asterisk pode contatar tanto os telefones internos quanto o restante da Internet.
Se SIP não for um requisito, e você estiver usando Asterisk, considere usar o protocolo IAX. O IAX encapsula (túnela) tanto o tráfego de controle quanto o tráfego de voz em uma única conversa UDP que pode ser facilmente encaminhada por porta, filtrada ou traduzida. Esse método é limitado a um conjunto estático de túneis, o que é suficiente se você estiver conectando alguns PBXs pela Internet ou conectando‑se a um provedor de longa distância.
Às vezes as soluções acima não estão disponíveis para você. Nesse caso, pode ser aconselhável migrar para um proxy SIP completo e usar o Asterisk apenas para aplicações de voz, como correio de voz. O SIP Express Router (SER) é um poderoso servidor SIP que lida bem com NAT e é usado por vários serviços de alto volume, incluindo o Free World Dialup. O trabalho do SER é apenas estabelecer chamadas entre endpoints, portanto ele deve depender de outras aplicações, como media proxies especializados, para lidar com fluxos RTP, se necessário.
O passo além de um proxy SIP é um Session Border Controller (SBC), que é como um firewall de VoIP. O SBC pode interceder tanto nos caminhos de sinalização quanto de RTP para adicionar recursos extras, como tradução de protocolo de sinalização ou de codec, tudo isso enquanto aplica políticas de segurança. Esses são produtos quase exclusivamente comerciais.