Sophos Firewall Corrigir problemas de VoIP com SIP e RTP

Os problemas de VoIP por trás de um Sophos Firewall geralmente têm um efeito difuso: os telefones não são registrados, as chamadas são interrompidas, toca sem áudio ou a fala só pode ser ouvida em uma direção. Na prática, a causa raramente se deve a uma única mudança. Sinalização SIP, fluxo de mídia RTP, NAT, regras de firewall, tempos limite UDP ou roteamento geralmente funcionam juntos.

Este artigo apresenta a resolução de problemas VoIP no Sophos Firewall como um processo estruturado. As soluções rápidas habituais, como desativar o SIP Helper ou aumentar um timeout UDP, são apenas testes controlados. Primeiro é necessário identificar o percurso dos pacotes, as regras de firewall e NAT realmente utilizadas e analisar SIP e RTP separadamente.

Compreender SIP, RTP e os sintomas

Que tráfego VoIP atravessa o firewall

VoIP consiste aproximadamente em duas partes:

SIP: controla registro, configuração de chamadas, compensação de chamadas e negociação de parâmetros de mídia. Erros típicos incluem falha no registro, chamadas não estabelecidas ou diálogos SIP rejeitados pelo provedor.
RTP: transporta os dados de voz durante a chamada. Os erros típicos são ausência de áudio, áudio unidirecional ou interrupções após pouco tempo.

O SIP utiliza frequentemente UDP ou TCP 5060, enquanto o SIP cifrado utiliza muitas vezes 5061. Estes valores não são universais. Muitos fornecedores utilizam outras portas, servidores proxy ou requisitos adicionais de NAT keepalive.

O RTP geralmente usa intervalos de portas UDP especificados pelo provedor, pelo sistema telefônico ou pelos dispositivos finais. Para uma análise limpa, você precisa dos servidores SIP específicos, intervalos de portas RTP e protocolos de transporte do provedor ou da documentação do PBX.

Classifique os sintomas corretamente

Antes de fazer qualquer alteração, você deve classificar o sintoma com a maior precisão possível.

Falha no registro: Verifique DNS, roteamento, regra de firewall, NAT, credenciais do provedor ou transporte SIP.
Chamada não conecta: Verifique sinalização SIP, regra de firewall, Application Control e possíveis bloqueios de provedor.
A chamada funciona, mas não há áudio: Verifique o intervalo da porta RTP, NAT, rota de retorno, SD-WAN e SIP Helper.
O áudio só é audível em uma direção: Verifique o caminho de retorno RTP, NAT, roteamento, VPN e SD-WAN.
A conversa é interrompida após 30, 60 ou 120 segundos: Verifique o tempo limite do UDP, manutenção de atividade do NAT, atualização da sessão e expectativas do provedor.
Apenas chamadas recebidas não funcionam: Verifique DNAT, regra de firewall, redes de origem do provedor e compartilhamento de porta PBX.
Apenas uma linha WAN causa problemas: Verifique a rota SD-WAN, caminho de resposta, gateway e ligação de IP do provedor.

Essa classificação impede que você altere as configurações SIP mesmo que o problema real esteja no caminho de retorno RTP ou em uma rota SD-WAN.

Registar o estado inicial antes das alterações

Antes de fazer alterações na CLI, você deve documentar o status atual:

Quais telefones, PBX ou SBC são afetados?
Os dispositivos finais são registrados diretamente no provedor ou tudo funciona através de um sistema telefônico interno?
Quais servidores SIP e intervalos de portas RTP o provedor nomeia?
Qual regra de firewall processa o tráfego VoIP?
Log firewall traffic está habilitado nesta regra?
Qual regra NAT se aplica ao tráfego VoIP de entrada e saída?
Existem múltiplas linhas WAN, rotas SD-WAN ou VPNs baseadas em rotas?
O problema ficou visível após uma atualização de firmware, mudança de provedor ou atualização de PABX?

Testar regras de firewall no Sophos Firewall ajuda a analisar as regras. Para o fluxo real de pacotes, Packet Capture no WebAdmin é normalmente mais informativo do que apenas um Policy Test. Os valores CLI globais só devem ser alterados quando esta linha de base e uma chamada de teste reproduzível estiverem disponíveis.

Verificar o percurso dos pacotes, o encaminhamento e a qualidade

Verifique as regras de firewall e NAT

O NAT está frequentemente envolvido em problemas de VoIP. O Sophos Firewall deve não apenas permitir SIP, mas também traduzir e retornar corretamente os fluxos RTP associados em ambas as direções.

Estes pontos são geralmente relevantes para telefones de saída ou PABX interno:

regra de firewall apropriada da zona VoIP ou zona PBX para WAN
regra SNAT ou MASQ apropriada
Login na regra de firewall
nenhuma regra muito ampla ou posicionada incorretamente acima da regra VoIP
nenhuma Application Control, IPS ou Web Filtering inesperada neste tráfego

A necessidade de DNAT para um trunk SIP de entrada depende do desenho do fornecedor. Os trunks baseados em registo podem utilizar a sessão de saída existente. Os trunks entregues diretamente num endereço público ou os sistemas telefónicos publicados necessitam normalmente de uma regra DNAT com âmbito restrito. Os requisitos do fornecedor ou do operador SBC são determinantes.

Se for necessário DNAT, verificar também estes pontos:

DNAT para o PBX interno ou SBC
Regra de firewall com zona de destino e rede de destino apropriadas
Restrição às redes de origem dos provedores, se possível
apenas portas SIP e RTP necessárias
Logging e Packet Capture para testes

Uma regra NAT não permite tráfego, mas apenas traduz endereços ou portas. As conexões são explicadas em Entenda o NAT em Sophos Firewall. Se um PBX precisar ser acessível pela Internet, Publicar servidor via DNAT é a melhor base para a publicação propriamente dita.

Analise o RTP e a direção do idioma

Se a chamada for estabelecida, mas faltar áudio, o SIP geralmente não é mais o problema principal. Então você deve verificar se o RTP flui nas duas direções.

Processo típico:

Observe o intervalo de portas do provedor ou do PBX RTP.
Inicie Packet Capture com IP de origem do PABX ou telefone e faixa de portas RTP.
Faça uma chamada de teste.
Verifique se os pacotes UDP do dispositivo interno para o provedor estão visíveis.
Verifique se os pacotes UDP estão retornando do provedor.
Comparar NAT ID, Rule ID, In interface e Out interface.

Se o RTP só estiver visível na saída e nada regressar, o problema pode estar no fornecedor, no caminho de retorno, no NAT ou num equipamento a montante. Se o RTP regressar mas não for encaminhado para o PBX, as causas mais prováveis são a regra de firewall, o DNAT, o encaminhamento ou a atribuição da zona.

Para gravações mais precisas ou exportação PCAP, tcpdump via SSH pode ser útil. O processo está descrito em Sophos Firewall Use tcpdump para logs e análises.

SD-WAN, VPN e múltiplas linhas WAN

VoIP é sensível a caminhos assimétricos. Se o SIP for executado em uma linha WAN, mas o RTP retornar em uma linha diferente ou se uma VPN baseada em rota for roteada de maneira diferente, surgirão erros típicos, como áudio unilateral.

Um bug corrigido no SFOS 22.0 MR1 mostra a conexão típica: após uma atualização para SFOS 22.0 GA, o áudio VoIP só poderia funcionar unidirecionalmente em VPN baseada em rota com roteamento SD-WAN. Na prática, isso significa: SD-WAN deve sempre ser verificado ao usar VoIP sobre VPN ou vários caminhos WAN.

Pontos de verificação importantes:

Uma rota SD-WAN acessa o tráfego VoIP?
O SIP e o RTP são roteados pela mesma linha WAN esperada?
Existem especificações do provedor em relação ao IP de origem ou endereço de remetente público?
É usada uma rota VPN baseada em rota com interface XFRM?
As rotas de retorno e NAT correspondem ao caminho escolhido?
Packet Capture apresenta gateways ou interfaces diferentes para direções de ida e retorno?

Para opções SD-WAN específicas do Sophos, Pacote de resposta de roteamento SD-WAN e tráfego do sistema é adequado. Sophos Firewall Solução de problemas de IPsec também ajuda com conexões IPsec.

Modelagem de tráfego para VoIP

A modelagem de tráfego pode estabilizar o VoIP quando as linhas estão estreitas ou quando grandes uploads substituem pacotes de voz. No entanto, não resolve regras NAT incorretas, portas RTP ausentes e rotas de retorno incorretas.

A modelagem de tráfego é particularmente útil se:

O VoIP piora quando a linha da Internet está sobrecarregada,
Uploads ou backups atrapalham as conversas,
vários aplicativos usam a mesma linha,
VoIP deve ser especificamente priorizado.

A configuração está descrita em Modelagem de tráfego de aplicativos em Sophos Firewall. Para VoIP, você não deve apenas verificar os testes de velocidade após a implementação, mas também realizar chamadas de teste reais com carga simultânea.

Testar SIP Helper e UDP Timeout de forma controlada

As definições seguintes afetam mais do que uma única regra VoIP. Só devem ser testadas depois de restringir a causa, com uma linha de base documentada, uma janela de manutenção e um rollback claro.

Verifique o auxiliar SIP

O SIP Helper, muitas vezes também chamado de SIP ALG, tenta reconhecer pacotes SIP e adaptar informações SIP relevantes para NAT. Isso pode ajudar em ambientes simples. No entanto, também pode ser perturbador em muitas configurações de VoIP modernas com provedor SBC, PBX próprio, TLS, manutenção de atividade NAT limpa ou intervalos de portas RTP mais complexos.

O SIP Helper é, portanto, um ponto de teste útil, mas não uma solução permanente universal. A Sophos documenta que os módulos do sistema são carregados por predefinição.

Os comandos são executados através de SSH no Sophos Firewall, em 4. Device Console. O acesso SSH só deve ser permitido a partir de redes de confiança. Os princípios básicos estão descritos em Ligar ao Sophos Firewall através de SSH.

A ajuda CLI do SFOS 22 documenta load e unload para o módulo SIP, mas não um comando geral system system_modules show. Por isso, deve registar-se o estado inicial conhecido e cada comando executado no registo de manutenção, em vez de confiar num suposto comando de estado.

Desative o módulo SIP:

system system_modules sip unload

Reative o módulo SIP:

system system_modules sip load

⚠️ Esta alteração deverá ser feita em janela de manutenção ou com testes claramente definidos. Após desabilitar ou habilitar, o cadastro, as chamadas efetuadas, as chamadas recebidas e o áudio devem ser verificados nos dois sentidos.

Se a mudança não ajudar, você deve retirá-la. É importante documentar a condição antes e depois do teste.

Verifique e ajuste o tempo limite do UDP

VoIP geralmente usa UDP. Se as entradas de NAT ou de sessão expirarem muito cedo, um registro pode parecer funcionar, mas as chamadas caem ou as chamadas recebidas não chegam ao PBX de maneira confiável.

A Sophos distingue dois valores globais:

udp-timeout aplica-se a ligações UDP que ainda não foram reconhecidas como um fluxo bidirecional.
udp-timeout-stream aplica-se a fluxos UDP estabelecidos nos quais ambos os extremos enviaram tráfego pela mesma porta entre segmentos de rede.

No SFOS 22, ambos os valores aceitam entre 30 e 3600 segundos. Os valores atuais de Advanced Firewall são apresentados em Device Console:

show advanced-firewall

Valor do fluxo de tempo limite UDP no Sophos Firewall — O valor do fluxo de tempo limite UDP deve ser documentado antes de qualquer alteração.

180 segundos é um exemplo comum de diagnóstico, não uma recomendação geral da Sophos. Se o Packet Capture e o momento da interrupção indicarem um timeout de fluxo demasiado curto, testar o valor de forma controlada:

set advanced-firewall udp-timeout-stream 180

⚠️ udp-timeout-stream não é uma opção de uma regra VoIP individual. Afeta todos os fluxos UDP correspondentes. Não deve ser aumentado por tentativa nem arbitrariamente. Antes do teste, anotar o valor anterior de show advanced-firewall e restaurá-lo com o mesmo comando set se o teste não resultar.

Se o provedor ou o sistema telefônico suportar NAT keepalive, essa configuração também deverá ser verificada. Uma manutenção de atividade limpa no PBX ou no lado do provedor geralmente é melhor do que um valor de tempo limite global muito alto.

Resolução de problemas e evidências

Fluxo prático de solução de problemas

Sintoma do documento: registro, configuração de chamada, áudio, horário de cancelamento, direção.
Colete dados do provedor: servidor SIP, transporte, intervalo de portas RTP, requisitos de NAT.
Identifique a regra de firewall e a regra NAT.
Ative o login na regra de firewall afetada.
Abra Log Viewer e Packet Capture durante uma chamada de teste.
Verifique se a sinalização SIP funciona em ambas as direções.
Verifique se o RTP funciona nas duas direções.
Se houver múltiplas linhas WAN, verifique SD-WAN e caminho de retorno.
Teste o SIP Helper especificamente e documente os resultados.
Alterar um timeout UDP apenas de forma deliberada e depois de documentar o valor anterior.
Após cada alteração, testar o registo, as chamadas efetuadas, as chamadas recebidas e o áudio nos dois sentidos.

Se várias alterações forem feitas ao mesmo tempo, a causa subsequente será difícil de compreender. Um teste por mudança é melhor.

Colete evidências durante uma chamada de teste

Um teste de VoIP só é útil se o tempo, a direção e o fluxo de pacotes corresponderem. Principalmente nos casos de provedores, a afirmação “Áudio não funciona” não é suficiente. Você precisa de um caso de teste pequeno e reproduzível.

Hora exata com fuso horário: Log Viewer, Packet Capture e os logs do provedor podem ser facilmente comparados posteriormente.
Direção da chamada: chamadas recebidas, chamadas efetuadas e encaminhamento interno não são misturadas.
Números de telefone ou ramais: Provedores e PBXs encontram a chamada específica mais rapidamente.
IP interno do PABX ou telefone: Packet Capture pode ser filtrado de forma restrita.
Servidor SIP do provedor e intervalo de portas RTP: As análises SIP e RTP permanecem separadas.
Rule ID, NAT ID, In interface e Out interface: você pode ver qual regra e qual caminho foi realmente utilizado.
Resultado por teste: Registro, toque, configuração de chamada, áudio esquerdo/direito e tempo de término permanecem rastreáveis.

No caso de erros esporádicos, você também deve fazer backup dos logs relevantes antes de serem substituídos. Para um pacote de log limpo, Sophos Firewall Fazer backup de logs para suporte e análise é adequado. Qual arquivo de log pertence a qual serviço está descrito em Sophos Firewall Solução de problemas: serviços e registros.

Erros comuns

Apenas porta SIP habilitada, esqueci o intervalo da porta RTP: A chamada é configurada, mas o áudio está faltando.
A regra NAT existe, mas nenhuma regra de firewall correspondente: O tráfego é traduzido, mas não é permitido.
Regra de firewall sem registro: A solução de problemas em Log Viewer permanece cega.
SIP Helper desativado ou ativado em geral: O problema é movido aleatoriamente em vez de analisado.
Tempo limite do UDP muito alto: As sessões globais do UDP permanecem abertas desnecessariamente por muito tempo.
Vários caminhos WAN sem uma regra SD-WAN clara: Áudio unidirecional ou tráfego rejeitado pelo provedor tornam-se mais prováveis.
Redes de origem do provedor não restritas: O serviço SIP é desnecessariamente amplamente acessível pela Internet.
Formação de tráfego entendida como um substituto para NAT/roteamento: A qualidade da voz permanece ruim porque a causa está em outro lugar.

Reverter as alterações de forma controlada

Em qualquer alteração VoIP deve ficar claro como voltar atrás:

valores anteriores de udp-timeout e udp-timeout-stream documentados se forem alterados
teste SIP load ou unload e estado final pretendido documentados
regras de firewall e NAT alteradas registadas com data e motivo
chamadas de teste registadas com direção e hora
Packet Capture ou logs relevantes conservados para casos de suporte

Se a mudança não ajudar, não deve ser deixada como um legado acidental. As soluções alternativas de VoIP, em particular, serão difíceis de entender posteriormente.

Lista de verificação operacional

As informações SIP e RTP do provedor estão disponíveis.
A regra de firewall para VoIP é identificada e o registro está ativo.
A regra NAT corresponde à direção do tráfego.
SIP e RTP foram verificados separadamente.
Packet Capture mostra a direção para frente e para trás.
O SIP Helper foi testado apenas especificamente.
O tempo limite do UDP só foi alterado com um valor inicial documentado.
SD-WAN, VPN e múltiplas linhas WAN foram verificadas.
A modelagem de tráfego é usada apenas para controle de qualidade, não como um substituto para roteamento ou correções de NAT.

Perguntas frequentes

Você deve sempre desativar o SIP Helper em Sophos Firewall?

Não. O SIP Helper pode ajudar ou atrapalhar dependendo da operadora e do sistema telefônico. Deve ser testado especificamente. Se a desativação não trouxer nenhuma melhoria, você deverá restaurar o status anterior.

Por que a chamada funciona, mas você não consegue ouvir nada?

Então a sinalização SIP funciona pelo menos parcialmente, mas o fluxo de mídia RTP não funciona corretamente. Você verifica o intervalo de portas RTP, NAT, regra de firewall, rota de retorno e, se houver vários caminhos WAN, SD-WAN.

Um tempo limite de UDP mais alto ajuda com problemas de VoIP?

Às vezes sim, principalmente no caso de chamadas interrompidas ou registros instáveis. No entanto, o valor tem um impacto mais amplo nas sessões UDP e deve, portanto, ser consciente, documentado e não definido desnecessariamente alto.

O que é importante sobre VoIP sobre SD-WAN?

SIP e RTP devem ser executados pelo caminho esperado. Se as viagens de ida e volta usarem linhas WAN ou caminhos VPN diferentes, poderão ocorrer áudio unilateral ou conexões rejeitadas.